The Policy Driven Data Center

As we work to educate people on the value of a truly converged infrastructure product, two of the things we talk a lot about are the concepts of balance and context.  Balance within your architecture is important because it helps ensure that no part of the stack overwhelms any other, helping eliminate performance and availability issues and preventing costly rework and redesign later in the lifecycle of the infrastructure.  While it’s important and valuable, this sense of balance isn’t easy to achieve, and requires a lot of testing and validation at both the hardware, hypervisor and software layers in order to get it right.  A reference architecture has very limited ability to provide this idea of balance, since it’s only relevant for the single instance that is documented by the vendor.  Because the point of balance may be different at different levels of capacity or with different kinds of applications, the only true way to be sure you have it is to demand that your vendor give you the information and recommendations you need.

Context is even more important, and is impossible to get from a reference architecture.  Context is how you manage an infrastructure stack as a single object, and it’s the key ingredient in everything from operational efficiency to integration with management toolsets.  One of the ways in which context can really benefit customers is by enabling policy enforcement and compliance management and reporting at a very fundamental and foundational level, and in ways that we haven’t been able to before.

First, let’s define some terms, so we are all talking the same language.  “Policy and Compliance” are terms that get used (abused?) in many ways by many people, so to begin, here are the six different kinds of policies that our customers tell us are relevant to them, at an infrastructure level.

1. Component Compliance: At a very basic level, we’re going to define this as the set of components that I’m going to allow into my infrastructure. Maybe this is a type of storage array based on a particular feature set I require. Maybe this is a specific type of processor, or specific network switches. Maybe it’s a brand of hypervisor. In aggregate, it’s my personal definition of converged infrastructure, and it’s used to ruthlessly drive standardization. Policy here could be to validate and track all components that are added into existing platforms and all ensure new platforms only contain the technology that I’ve decided to standardize on. Wouldn’t it be neat if I could publish this policy to my vendors so that I could enforce policy on all orders as they are placed? Not in a “did you check the spreadsheet to see if this order is right” kind of way, but in a way that’s directly tied to how you order the infrastructure from your vendor or partner regardless of which piece of the platform you are ordering, and that could be tracked against?
2. Platform Compliance: This covers the standard logical and physical build of the platforms, based on tested configurations and the interoperability matrix of the components.  This includes how the physical components are racked, thermally oriented, powered and cabled.  Which version of firmware do I use on my blades, switches, HBAs?  What version of storage microcode works with the fabric interconnects I’m using?  Am I going to boot from SAN or use vSphere Auto Deploy?  Generally speaking, this defines the base set of technologies that I’m going to have at my disposal as I put together my service offerings.
3. Enterprise Platform Compliance: Here is where the planning and standardization we’ve put in place turns into the consumable infrastructure that your business uses to run workloads.  We are taking the Lego pieces we’ve defined and are finally putting them together into something that has relevance to the business.  Policy here would define how those physical components are configured for consumption: how do we apply network security models? How do we carve up and allocate storage? How do we define and consume pools of MAC, WWNN and WWPN addresses? How are physical interfaces configured and subsequently virtualized? How are hypervisors configured? How are switch and router configurations standardized and tracked? Again, wouldn’t it be neat if I could define and deploy these policies to my vendor so that at both the physical and logical layer my policies are used in the delivery and configuration of my infrastructure? I’m not talking about building to a published spec after you get the equipment or scripting an install, I’m talking about being able to track compliance against a policy that literally defines every piece of your infrastructure from the day you place an order until it’s ready to run workloads on your data center floor.
4. Regulatory Compliance: For many of you, we are finally in a space that sounds cozy and familiar!  Now that we have the infrastructure in place, we need to define policy based on outside controls that we are obligated to track against.  The added bonus would be that we could reference the hardware platform directly in these policies (if we chose to, or were required to) and integrate that compliance checking with what we do today at the application/OS/InfoSec layers.
5. Enterprise Regulatory Compliance: Of course, there’s the letter of the law, and then there’s the interpretation of the law that your company is going to choose to use.  Since both may be important depending on the situation, let’s make sure we have a way to differentiate between the two!
6. Runtime Logical Configuration Compliance: Finally, we have the workload itself.  Every application has a set of variables and requirements that are defined for it, whether that’s a particular type of blade, a specific storage tiering strategy or QoS policy, or maybe even whether it can run co-resident with other applications.  Since the platform exists to service the applications, wouldn’t it be nice if we could have a process by which we define the infrastructure provisioning by using the application requirements?

If you look at the list above, you can see that while the bottom two levels of compliance will usually be global across an enterprise, you could possibly have many Enterprise Platform Compliance policies depending on what the infrastructure is supporting.  The same could go for the higher tiers of the stack; they apply to successively smaller pieces of the overall system until we are creating them on a per-workload basis.

OK, so let’s look at an example of how all of this could work together on behalf of the customer.  Let’s look at where the rubber might meet the road…

There is a Service Provider who does business internationally, and who provides Vblock platforms for customers to leverage as a private cloud.  They have an existing, US-based customer who wants to do business in the US, and they are going to need to add a blade chassis to their existing Vblock 300 platform, along with a couple shelves of disk to support the business.  The customer has some specific compliance requirements for these workloads, including:

1. The workloads may only run in the provider’s US data centers
2. The workloads are incredibly compute-intensive, and specific CPUs are required
3. The storage requirements include extensive use of FAST Cache in front of a large amount of NL-SAS disk
4. Network latency isn’t a priority, so a lower QoS model needs to be applied
5. The data may include medical data that has personally identifiable information, so standard HIPAA controls need to be tracked.

The customer calls the SP, or submits a work ticket, and the wheels start in motion.  The SP reaches out to VCE, and using the Component Policy that’s been defined and our awareness of the platforms that have been purchased we generate an upgrade quote.  The hardware covered in this quote is certified by VCE and will always be supported and able to run at the current level of the Vblock Compatibility Matrix that the customer is on.  In addition, we’ll make sure to stay within the hardware family that the customer is currently using unless specifically asked not to, in order to maintain VMware HA and vMotion capabilities.

Because there are some additional requirements for these blades, the SP and the customer also put in place detailed Component and Platform Compliance policies.  One of the requirement, workload geo-location assurance, uses a feature of a new Intel processor that is only available in Cisco’s new B200M3 blade.  The FAST Cache implementation required by the application uses a total of (20) 100Gb SSD drives.  The customer already uses the RSA Archer platform to manage compliance levels at an application/OS level.

So what happens if something is done that violates one of those policies?  An alert could be thrown, of course!

Once the policies have been defined, both the SP and the customer could have piece of mind, while maintaining the separation of responsibilities that makes the outsourced private cloud so attractive!  The SP can move with the velocity their business model demands without fear of accidentally provisioning the wrong physical or logical configuration for their customer.  The customer can focus on the application and their business while maintaining a “trust but verify” posture, and can integrate the infrastructure itself into the standard tools they are using to show compliance with relevant controls.  The infrastructure platform, ordered, delivered, consumed, managed and monitored as a single object, becomes just another control that can be managed.

Wouldn’t that be neat? Stay tuned!

•