SDDC Stacks – HP, Red Hat, VMware, OpenStack, Avaya, Cisco are all in on it. They’ve all got one. The Software Defined Data Centre stack that is the talk of the town. The term “software defined” was coined a few years ago by VMware marketing and has since been adopted as the new “nom du jour” for the future of the Data Centre.
But what is it? What does it mean? More importantly the question on all CIO’s lips is, what about SDDC do I need to be aware of in relation to my current DC strategy (and existing infrastructure sunk-costs)?
What is SDDC?
“The overarching vision of SDDC (and it is still very much a vision at this stage) is that control of the entire data centre is abstracted from the underlying hardware, with all physical and virtual resources made visible via software programs so that the provision of these resources may be done automatically or by programming according to the immediate needs of the applications and services running in the data centre.”
Essentially SDDC is a similar abstraction for the Data Centre as applied to SDN, which is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices. In fact the control plane for the Software Defined Data Centre is really the most important decision for the enterprise: how the enterprise CIO assesses their data centre strategy, cloud management and their inherent future together presently; will dictate major financial outcomes, both write-offs and future costs. Arguably the control plane will define SDDC success, additionally this correlation of SDN and SDDC is not by definition alone. This article hopes to uncover why CIO’s ought to pay careful attention to DC strategic decisions, since both SDN and SDDC are more tightly linked than they may realise.
Much of the required progress towards the future of SDDC has been achieved in the Data Centre through virtualisation of compute (hypervisor), storage and API automation. We will explore how SDN and deeper Data Centre software enablement will define the SDDC:
Historical Data Centre
Physical equipment; including servers, storage arrays, Routers/Switches, Core/Edge/Distribution separation, management and control by network/security teams. Requires high touch and a vast array of technical skill-sets to maintain; creating intensive labour costs.
Future Software Defined Data Centre
Ubiquitous and instant IT as a service, with centralised policy based management across all facets (compute, storage, network, security, cost/billing), across all providers to seamlessly enable business and users with full self service and no roadblocks. Ubiquitous whether in own DC, CoLo, or Public provider. Essentially this is the SDDC dream.
Confusion and concern around loss of control; with one foot in either historical/future DC camp (if you’re lucky) typically whole enterprise in past and a small dynamic R&D based DevOps team trying to push into the future, but over-worked doing EVERYTHING! Oh and what about all that sunk cost infrastructure. Aargh!
The question many CIOs are asking, is how to utilise existing physical network infrastructure whilst leveraging hybrid cloud and software control of the DC network, not just intra DC but INTER DC as well.
This SDDC challenge inherently lies within the Network. Arguably management, control and security are the biggest constraint in delivering the benefits of DevOps – Automation, Self Service and On-demand. Without these sensible constraints, CIO’s could easily open up the continuous development/integration floodgates.
The key cloud specific challenges in the Data Centre are:
- allowing tenants to create own desired multi-featured and secure network
- enabling customers (business users, tenants) access to Enterprise multi-site, dynamic, complex and secure network environments
- integrating private/public/hybrid cloud with existing enterprise network in secure and compliant manner
Why Hybrid Cloud
Essentially the future of enterprise is Hybrid Cloud: where enterprise users will leverage a mix of AWS, Azure, OpenStack and other providers like Rackspace, Digital Ocean, etc. It is already evident in enterprises across USA, Europe and even Australia, with examples such as a major tier 1 banking organisation (name withheld) entrenched in AWS, but heavily delving into Azure and OpenStack. Key is that CIO’s adopt this hybrid cloud future as a mantra, then implement and develop these as strategic outcomes. The penalties for a single public cloud provider or single vendor strategy is severe: exacerbating IT’s reactive response to business demands, leading to further loss of control and security failure of IT.
The promise of the Hybrid Cloud enabled Data Centre, is that Enterprise will benefit from service provider economies of scale and scope, lower their cost through improved utilisation and improve application performance, resiliency and IT responsiveness. Some specific reasons enterprise are adopting or should adopt hybrid cloud strategies:
- Enterprise want to maintain competitive supplier power in their favour, if one provider fails to deliver (feature, capability, SLA) that offers competitive advantage, then the enterprise can utilise other cloud resources or providers. This gives more choice and range to the development teams.
- Simple price elasticity
- Audit, security & compliance; certain apps cannot go 100% to public cloud, due to security and audit compliance requirements, therefore must be maintained in a private cloud environment, but can leverage capabilities if public cloud offers required compliance or security components
- Intra provider bursting, locality, availability and bandwidth; cloud providers are all still juggling these and will continue to do so as they balance capacity with customer spend. This gives control of the app performance to the enterprise and not the cloud supplier
- Cloud Bursting; a key capability of hybrid cloud, enables enterprise customer to manage each cloud workload within the application, so it intelligently bursts the workload out to either the relevant public cloud supplier or private cloud or an appropriate combination according to predefined business rules
Cloud bursting is the future capability that all intelligent cloud vendors are focusing on, enabling deeper capability (across compute, storage, network and control plane) from within the application. This is the future as I see it. Focus and developing capability is evident, with management and policy control over these being key areas of development by vendors.
OpenStack is the enablement platform for Hybrid Cloud, due to its inherent openness and consequential public/private interoperability. It delivers on the key tenets set out by wise DC strategists on Cloud Management. By nature of being an open platform AND having strong established vendor support with involvement in direction and plug-ins, intelligent enterprises recognise this and are heavily exploring and developing their cloud strategy along these lines.
A key requirement of Hybrid Cloud in relation to the network, is that in order to deliver inter Data Centre and cloud bursting capabilities, by definition Hybrid Cloud interconnects from within and between the Data Centre. Therefore it is imperative that the standard protocols and capabilities of the Hybrid Cloud enabled Data Centre (VxLAN, OpenFlow) are supported across the Provider (MPLS), across the WAN or Internet (BGP), to the other Hybrid Cloud enabled Data Centres.
The key business challenge, is to allow the enterprise customer to use their sunk cost existing hardware infrastructure, provide an open SDN and Policy framework (to manage security, users, groups, etc.), that works with existing customer environment.
The key tenet of SDDC is “abstraction”. Abstraction of existing physical hardware. How is this done?
Compute, yes box ticked. Whether you’re on VMware, KVM or Citrix this is pretty much a done deal. Storage, OK the separation of storage from the compute was achieved with storage virtualisation some time ago. Network, that is a little more tricky. Security and Control, even more difficult and not yet fully realised.
What about the existing network? Sure you use a single vendor across core, edge, and access (don’t you?!) So how do you abstract this? Cisco want you to rip it all out and replace it with all new gleaming Nexus and ACI. I don’t think the CFO will sign off on that.
DC to DC Interoperability
How do the Data Centres interoperate with one another to successfully enable Hybrid Cloud? OpenFlow and VxLAN alone will not suffice. What about migrating workloads and redundancy? These are also particularly important when assessing inter-country or regional SDDC strategy. Redundancy, failover, workload mobility and in-country data compliance all become incredibly complex in a hybrid cloud scenario.
Herein lies the issue. How do you effectively plan a DC fabric across regions and globally? Do you double dip (paying for existing infrastructure replacement and future technology) and implement a full ACI or NSX solution into every DC you operate including Backup or Redundant DC’s? What about CoLo’s and shared environments where you have no control of the Provider Edge or Telco? How do these interoperate with public cloud providers, how do you take advantage of hybrid cloud key benefits such as cloud bursting? By leveraging open standards, the enterprise can more easily achieve this. It is technically feasible, though financially impossible to utilise a single vendor solution across a hybrid cloud SDDC. Do AWS and Azure offer full vSphere, NSX or ACI integration? If they did it certainly would be expensive.
Some key SDDC interoperation tenets:
- No matter what your DC fabric, you MUST interoperate to another DC or outside the DC, therefore it must be an IP Fabric; and
- Customer Edge and Provider Edge MUST reliably and efficiently manage encapsulated traffic (VxLAN, OpenFlow) over standard WAN Edge to Edge protocols (MPLS, BGP)
VMware NSX requires encrypted tunnels to remote sites, as the Data plane is NOT encrypted or secure. NSX controllers communicate across controllers and soft-routers on their Data plane via SSL-TCP. Overhead of managing SSL certs, which is inefficient, high network overhead connection-oriented. What if you move controllers, or have a DC or WAN link failure? These scenarios and the technical complexities are by nature a core component of your SDDC strategy.
VM Mobility and Multihoming
In depth understanding of MP-BGP, EVPN and how this interacts on the Layer 2 planes is beyond the scope of this document (and reaching the limits of my expertise), however suffice to say that VM Mobility (Live Migration) across the WAN and the consequential DC redundancies are very important to your business.
Layer 3 and IP are arguably the best DC to DC interconnect methodologies, MPLS/VPN is scalable however gains complexity. Still DC to DC compute live migration (vMotion, or other hypervisor) is an issue with traffic tromboning. This is due to historical lack of intelligence between the DC interconnect and the DC IP Fabric. VM and VxLAN with MAC and ARP address learning awareness solves this.
Interoperability, Security and Control
“simultaneously provide context and isolation for security controls”
Of course this is VMware steering the conversation towards their desired market position, which is the Context vs. Isolation Hypervisor-centric view of the DC. However control and security of the SDDC is not so simple, that it can be managed and leveraged from the hypervisor control plane alone. Networks and WANs are complex. As reality dictates, the DC is comprised and always will be comprised of existing hardware and hardware running the DC network. How do you establish context and isolate in this real sense? What of inter DC and Hybrid Cloud scenarios? There will always be an Edge, DC infrastructure and host. There will always be hardware and software in the DC.
Key contextual areas that both isolate and manage the security and control are the Control and Data planes. Specifically for enterprise SDDC interoperability and security; the SDDC Control and Data Planes must address respectively:
Control Plane: Open cloud platform and hypervisor, open directory interoperable, policy based – set once & apply many; for successful Hybrid Cloud, ideally implemented across OpenFlow
Data Plane: Reliable, fast, standards based i.e. VxLAN, BGP, MPLS, EVPN protocol support
The Data Plane becomes increasingly complex unless you abstract to Group Policy. It is clear that in an open world (cloud, software, network or whatever), choice and flexibility are key, yet simplicity and centralised management for security, control and audit are increasingly a major requirement in modern enterprise technology. Two seemingly opposing philosophical approaches, tight management control versus a DevOps approach if you will.
When it comes to the Data Centre and moving workloads inter DC, performance is key. Interoperability at Wire Speed, Telco grade WAN connectivity really is the ultimate.
“… an NSX Edge VM can translate from the VXLAN overlay to physical network, the performance isn’t great. Therefore, VXLAN Termination End Point (VTEP) features are needed in the physical hardware of the switch.”
VMware NSX REQUIRES that you leverage hardware in their SDDC network solution, despite their entire go to market highlighting that you can do it all “in the software” distributed across the hypervisors. Hence their recent vendor partnerships. So you need a hardware SDN AND VMware NSX as a solution. Do you really want to rely on two vendors for ONE SDN solution inside your DC?
The advantages of “openness” to the enterprise are vast in particular where an enterprise has a number of vendor technologies already in the Data Centre. Typically enterprise has a vendor for compute virtualisation, several vendors for OS platforms, another vendor for storage, yet another for core networking, probably several for WAN links. openness allows the enterprise organisation to ensure their SDDC strategy “just works” with this pre-existing patchwork of vendor technology. What are “open” technologies and protocols? OpenFlow, VxLAN, NVGRE, EVPN, MPLS, BGP and OVSDB are all open or openly accepted and well-used standards. OpFlex, FabricPath, vPath and NSH are not.
What are “open” vendors or platforms? OpenStack as the cloud platform. Neither Cisco ACI nor VMware NSX as the SDN, as they do not address the need to efficiently work across heterogeneous Provider and DC. Neither are taking an open approach, they are both attempting to lock the customer into their expensive pricing model.
“Many driver and outcome similarities between OpenStack and SDDC, particularly both abstract underlying infra (hypervisor, storage, network, orchestration, management, etc.) of DC; and release from restrictions of closed, proprietary infra stacks”
OpenFlow is considered the first and most utilised software-defined networking (SDN) standard.
Software based switch and router, as well as control stack for silicon based. Open vSwitch supports OpenFlow and OVSDB is a typical controller interconnect.
A Linux Foundation project which further develops SDN and promotes open standard for SDN and hardware integration through open community and open source code.
Open Networking Foundation
Industry member group that promotes and ratifies the OpenFlow protocol standard for SDN.
In an ideal scenario: Red Hat OpenStack, your existing storage vendor PLUS Red Hat Storage (ceph) and Nuage Networks SDN solution. Easy, open and fully supported by large vendors with solid experience in their respective fields. Product solutions which are at minimum second iterative release; and most importantly in use by other enterprise. All offer drop-in interoperability with most major vendors and leverage open standards. OpenStack now has over 4 years growth and maturation, a large vendor ecosystem of over 121 contributing organisations and 2,130 project participants; offers brilliant interoperability with other vendors across hypervisor, storage, SDN and support. In particular Nuage Networks offers open SDN capability in the hypervisor, software and silicon; as well as interoperability back into sunk cost existing hardware infrastructure in the Data Centre and WAN. Their “open and unified approach” in combination with OpenStack is a winner in my opinion. All these approaches maximise openness and minimises the number of vendor SLAs that are needed to successfully deliver to your business.
With flexibility as a consideration, the two main players don’t look so crash hot:
Cisco ACI: Unnecessary proprietary hardware for what should be a software solution.
VMware NSX: Physical servers? Network control? Good luck… get ready to go create “new tenant VLAN on the physical switches and setup a new VNI on the physical VXLAN gateway and map that new VLAN segment to the VNI” each time.
Enterprise ought to seek out vendor technology providers who embrace openness over lock-in. The two SDN vendors whom are regularly mentioned in the tech press: VMware and Cisco; both take a strong lock-in approach to their SDDC stack, even their OpenStack integration. This is against the grain of openness and certainly a far more expensive and difficult scenario for any enterprise who wants to remain open to taking advantage of technology developments whilst embarking on an SDDC implementation.