The VMware Cloud Foundation on VxRail solution is integrated end-to-end to fully enable a software-defined cloud platform that is designed to rapidly deploy physical resources into managed consumption pools, and to provision these resource pools on-demand to meet requirements for flexible and resilient workloads.
VxRail provides the physical resource foundation for the cloud delivery platform. VxRail is a set of specially engineered and manufactured compute nodes that when logically bound together after initial configuration, represent a single managed cluster for virtual workloads.
Figure 1. VxRail cluster representing a pool of virtual resources
VxRail integrates software products from VMware with custom software engineered from Dell Technologies so that the physical compute, memory, network, and storage resources are placed under a virtualization layer to be managed and controlled as an adaptable pool of resources. The physical disk devices on each VxRail node are encapsulated under the virtualization layer to create a single consumable data store for the virtual workloads. In addition, a virtual switch is created during initial configuration and distributed across the entire VxRail cluster. The Ethernet ports on each node are placed under the virtualization layer to enable connectivity between virtual machines on the VxRail cluster, and to enable connectivity to end-users.
When integrated with VMware Cloud Foundation, the VxRail cluster is positioned as an individual building block to supply compute resources for consumption in Cloud Foundation virtual workloads. Cloud Foundation allows users to dynamically allocate and assign VxRail clusters into individual consumption pools, known as Virtual Infrastructure (VI) workload domains. A VI workload domain represents the logical boundary of consumable resources, and all functionality within these boundaries is managed through a single vCenter instance. Under this model, VI workload domains can be planned and deployed to support the distinct requirements of individual organizations or a set of applications.
Figure 2. VxRail clusters as building blocks for Cloud Foundation virtual workload consumption
The resources of individual VI workload domains can be expanded by adding individual nodes to a VxRail cluster, or by adding an entire new VxRail cluster into a VI workload domain. When this occurs, the physical resources are automatically added to the VI workload domain pool.
The networking resources for each VI workload domain are also logically segmented, so that the distinct requirements for a set of applications can be individually managed. By layering the VMware’s Cloud Foundation software stack on VxRail virtual switches, enterprise networking features such as routing, VPN, and security from NSX-T are embedded and enabled into each VI workload domain.
Figure 3. Cloud Foundation VI workload domains with fully virtualized resources
With support for NSX-T, virtual machine traffic that previously had to pass upstream through to the physical network for routing purposes can now traverse the virtual network when established on a Cloud Foundation on VxRail VI workload domain.
Virtual machines will connect to the network using a logical switch in a Cloud Foundation domain. Cloud Foundation on VxRail supports the connecting of these virtual switches into an extended logical network, known as a segment. This allows virtual machines in different VI workload domains to connect to each other through this extended switch fabric.
Figure 4. Virtual machines connected to an extended logical network with logical routing services
If a virtual machine requires routing services, the extended logical switch, or segment, can use routing services provided by NSX-T within the virtual network. To support connectivity to applications and end-users outside of the virtual network, the NSX-T virtual routing services form a peer relationship with existing upstream physical routers in the data center to share routing information, and form a seamless connection between the physical and logical networks.
Figure 5. Relationship between physical and virtual networks