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.
- 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?
- 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.
- 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.
- 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.
- 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!
- 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:
- The workloads may only run in the provider’s US data centers
- The workloads are incredibly compute-intensive, and specific CPUs are required
- The storage requirements include extensive use of FAST Cache in front of a large amount of NL-SAS disk
- Network latency isn’t a priority, so a lower QoS model needs to be applied
- 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!
Any views or opinions expressed here are strictly my own. I am solely responsible for all content published here. This is a personal blog, not a VCE blog. Content published here is not read, reviewed, or approved in advance by VCE and does not necessarily represent or reflect the views or opinions of VCE or any of its parent companies, partners or affiliates
Most Popular Posts
- VMware, Cisco, Nicira: The Devil You Know
- 2013 vExpert Group, By the Numbers
- Take your MacBook and Shove It: How the Asus Zenbook Prime Saved My Life
- Cisco Acquires Cloupia: No Such Thing As Too Many Choices
- vSphere 5.1 and VCE Vblock Systems: Right Here, Right Now
- VMAX 40K+Vblock = ((Powerful, Trusted, Smart) ^ More) - Risk
- VCE 2013 Launch Resources
Tag CloudAWS CAWorld2011 Cisco Cisco Live 2011 Cisco Live London 2012 Cisco Live US 2012 Cloud Converged Infrastructure data center design EMC EMCWorld2011 EMCWorld2012 Featured Gartner Home Lab HP Hyper-V Licensing Microsoft NetApp OpenStack Personal ProLiant SP Business Storage UCS Uncategorized Vblock VCE VCE Vision vExpert Virtual Launch 2013 VMAX VMware VMworld2011 VMworld2012 VNX vSphere5
- May 2013 (3)
- April 2013 (2)
- February 2013 (3)
- January 2013 (2)
- December 2012 (4)
- November 2012 (1)
- September 2012 (1)
- August 2012 (6)
- July 2012 (2)
- June 2012 (6)
- May 2012 (2)
- April 2012 (4)
- February 2012 (3)
- January 2012 (3)
- December 2011 (1)
- November 2011 (5)
- October 2011 (1)
- September 2011 (4)
- August 2011 (3)
- July 2011 (10)
- June 2011 (2)
- May 2011 (8)
- April 2011 (5)
- March 2011 (1)
- February 2011 (1)
- January 2011 (4)
- November 2010 (3)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- June 2010 (1)
- May 2010 (10)
- April 2010 (3)
- March 2010 (5)
- February 2010 (11)