VMware Cloud on AWS: SDDC Design Considerations

-
Gilles Chekroun
Lead VMware Cloud on AWS Specialist
---
With the recent August 2019 release of VMware Cloud on AWS 1.8, a few interesting improvements are now available concerning the vSAN and Elastic vSAN storage capabilities.
The goal of this blog article is to recap the different options around SDDC design and specifically about stretched and non-stretched clusters.

AWS EC2 Bare metal Instances

As of now, the VMware Cloud on AWS Service is available with two types of EC2 bare metal instances from AWS:
i3.metal R5.metal
The AWS i3.metal specs are:
              The AWS R5.metal specs are:
- Intel Xeon E5-2686 v4 processors - Intel® Xeon® Platinum 8000 Series (Skylake-SP)
- 36 cores - 48 cores
- 2.3 GHz - 2.5 GHz
- 512 GiB RAM - 768 GiB RAM
- 15TB NVMe flash - EBS Storage only (15-35 TB)
- 25 Gbps Networking - 14 Gbps EBS Bandwidth
- 25 Gbps Networking

Other instances in specific areas like GPU or high memory will come later.

Elastic vSAN

Elastic vSAN, with R5.metal hosts, is a VMware Cloud on AWS cluster type that gives you a choice of storage capacity options ranging from 15TiB to 35TiB per host, in increments of 5TiB. This cluster type is suitable for workloads that require high storage capacity. 
Elastic vSAN builds on automated provisioning and management of Amazon Elastic Block Store (EBS) volumes. R5.metal hosts and Elastic vSAN solution is currently available in Oregon, N. Virginia, Ohio and Frankfurt regions.

Multi-Availability Zones Stretched Cluster

This feature enables customers to deploy a single SDDC across two AWS Availability Zones to support critical applications that require high availability in the event of an AZ failure.  In a Multi-AZ Stretched Cluster, vSAN guarantees synchronous writes across two AZs and logical networks extend to support vMotion between AZs.  In the event of an AZ failure, vSphere HA attempts to restart VMs in the surviving AZ.  Customers can choose a stretched cluster configuration at SDDC creation time and are limited to a single cluster. 

SDDC Design Considerations 

As of SDDC rel. 1.8 the following rules need to be applied

With Stretched Clusters

You can have multiple R5 stretched clusters per SDCC
You can have multiple i3 stretched clusters per SDDC
You can mix i3 and R5 stretched clusters
You can NOT mix stretched and non-stretched in the same SDDC

With Non Stretched Clusters

You can mix i3 and R5 clusters.
No migration from stretched to non-stretched or vice-versa is possible today. A new SDDC will be needed.

Option 1 - R5 Stretched Clusters

SDDC rel 1.8 and up; 8+8 nodes per cluster across 2 AZs; 20 clusters max; 300 nodes max;

Option 2 - R5 non stretched Clusters

16 nodes per Cluster over one AZ; 20 clusters max; 300 nodes max;

Option 3 - i3 stretched Clusters

8+8 nodes per cluster across 2 AZs; 20 clusters max; 300 nodes max;

Option 4 - i3 non stretched Cluster

16 nodes per Cluster over one AZ; 20 clusters max; 300 nodes max;

Option 5 - Mix of i3 and R5 non stretched clusters

16 nodes per Cluster over one AZ; variable storage according to the mix of i3 and R5; Production on i3, dev-test on R5; easy migration of workloads from cluster to cluster (networks are stretched always); 20 clusters max; 300 nodes max;

Option 6 - Mix i3 and R5 stretched Clusters

SDDC rel 1.8 and up; 8+8 nodes per cluster across 2 AZs; 20 clusters max; 300 nodes max;

Option 7 - Mix i3 and R5 non stretched on multiple SDDCs


Option 8 - Stretched R5 and i3 and non-stretched R5 and i3 in Multiple SDDCs


Comments

Post a Comment

Populars

Egress VPC and AWS Transit Gateway (Part1)

-
Image
Gilles Chekroun
 Lead VMware Cloud on AWS Solutions Architect --- Usually my blog posts are customer driven and recently I have been working on a design that would include an Egress VPC and AWS Transit Gateway. This customer is going to use both VMware Managed Transit Gateway and also AWS Transit Gateway. I will split this post in 3 parts: The Egress VPC - this article Adding a VMC SDDC to the Egress VPC here Adding VMware Managed Transit Gateway here Why do we need an Egress VPC? Numerous posts on AWS site  will describe how to build an Egress VPC and the subtleties of the various route tables of the TGW and the Egress VPC itself. The main goal is to have ONE Internet gateway only  that will allow workloads to go out to internet on the Egress VPC. One of the most important point is redundancy and multi-availability zones. Applications usually reside in private subnets, while NAT Gateways reside in a public subnet. NAT Gateways To focus the Internet access to a single point, we can cre
Read more

AWS Transitive routing with Transit Gateways in the same region

-
Image
Gilles Chekroun Lead VMware Cloud on AWS Specialist --- At the AWS Re:invent 2019 conference, the long waited TGW peering functionality was announced and available in a few AWS regions. This is an INTER-REGION peering only meaning that the Transit Gateways need to be in different regions. Hoping that AWS will soon release an INTRA-REGION capability I discussed with a few AWS Solutions Architects in Las Vegas, among them Tom Adamski , about using a VPC as a bridge between two TGWs in the same region. Tom assured me that it is possible opening for the first time the transitive routing capability in AWS networking. Well . . . I needed to test that and see by myself. Test bed For a simple test, I will use 2 TGWs in the same regions with 2 VPCs attached each and another VPC as "bridge" connected to both TGWs. Yes you can connect a VPC up to 5 TGWs . The whole idea is to use this "bridging VPC" and point the default route of the TGWs to it. To do that I c
Read more

Considerations on vTGW to TGW Peering Link

-
Image
   Gilles Chekroun
 Lead VMware Cloud on AWS Solutions Architect --- Recently I was talking with a Customer on designing their VMware Cloud on AWS environment and linking it to their existing AWS infrastructure. The idea was to have 2 SDDCs, Test and Prod, and link them with a VMware Managed TGW and peer it to their existing TGW. The customer requirements were: VMs in each SDDC should have internet access from the SDDC out VMs from Test should be able to talk to VMs in Prod VMs in any SDDC should be able to access their own vCenter but also the other one Some VMs any SDDC should have a Public IP and NAT rule to be accessible from outside VMware traffic should stay within VMware SDDCs Other traffic, like on-prem, should go via the Customer TGW Test Setup Step1 - Create SDDC Group Create an SDDC Group and attach the 2 SDDCs Prod and Test Make sure the proper FireWall rules are open in each SDDC Compute GW. Step 2 - Attach the Customer TGW In the SDDC Groups, under External TGW TAB, add t
Read more