Automated offerings

The offerings are described in detail in the following documents:

• VCF for Classic - Automated as a single site deployment - This offering deploys a VMware® based platform in a single IBM Cloud data center automatically.
• VCF for Classic - Automated as a multisite deployment - This offering deploys a secondary VMware VCF for Classic - Automated® instance in a single IBM Cloud data center automatically. It is linked to a primary VCF for Classic - Automated single site previously deployed. Multiple secondary instances can be created.
• VCF for Classic - Automated dual-site - This deployment pattern is based on two VCF for Classic - Automated single site deployments but not in a primary-secondary relationship as in the VCF for Classic - Automated multisite pattern. This is typically used in a production-disaster recovery pattern by using Zerto or Veeam® replication between the two sites.

In the VCF for Classic - Automated deployments, each site, and each instance has its own NSX-T Manager cluster. In the multisite deployments, the vCenter, NSX-T managers, and domain controller components are deployed per site. Each instance on each site has a default NSX-T overlay topology and no networking integrations nor dependencies exist between the sites.

The following diagram can be used to compare and contrast the features that are offered by these offerings.

In the previous diagram, the following terms require some additional comments:

• Single SSO and root domain - A single instance of Active Directory™ and Domain Name Services is automatically deployed with replication if more than one domain controller is selected for automatic deployment. For more information, see Multisite deployment components.
• Two SSO and root domains - A single instance of Active Directory and Domain Name Services is deployed, one for each instance. No replication occurs between the two sites.
• Single vCenter - The automation deploys a single vCenter appliance.
• Dual vCenters with ELM - Enhanced Link Mode (ELM) offers a single window of glass across multiple VCF for Classic - Automated instances that are in the same vSphere Single-Sing-On (SSO) domain. This allows the management of multiple sites from one vCenter. For more information, see vCenter Enhanced Linked Mode. The automation deploys and configures the vCenter appliances.
• Dual vCenters - Each site has a vCenter deployed automatically. However, they are not linked.
• Single NSX-T Manager cluster - The automation deploys three NSX-T Manager appliances in a cluster with a Virtual IP address.
• Dual NSX-T Manager clusters - Each site has its own NSX-T Manager cluster that is deployed automatically, which is independent of each other. In NSX-T, it doesn't exist a concept equivalent to Cross-vCenter NSX-V.
• Active NSX-T data plane - All site ingress and egress traffic traverses through the single edge cluster that is deployed in that site automatically.
• No stretched L2 capability - The stretching of layer 2 NSX-T overlay segments across sites cannot be done.
• Single edge gateway - Each virtual data center uses an active-standby edge gateway for external access to the public network or the services network. This gateway includes features such as NAT, IPsec VPN, and load balancing.
• Single edge cluster Tier-0 gateway for workloads - The automation deploys a single NSX-T edge cluster, consisting of a pair of edge appliances, hosting an active/standby Tier-0 gateway for use by the workload VMs. These VMs provide connection between the overlay and underlay networks. For more information, see Single-site - single-tenant and Single-site - multitenant.
• Single-zone NFS storage - vSphere data stores that use IBM Cloud File Storage for Classic of different IOPS ratings are available and deployed automatically. IBM Cloud File Storage for Classic can be accessed only from hosts in the same site as the vSphere hosts. For more information, see Shared File-level storage across hosts.
• Single-zone vSAN™ - The VCF for Classic - Automated instance can be ordered with VMware vSAN and it uses disks in the vSphere hosts as a consolidated data store.

The vCenter dual site topology is a candidate for NSX Federation. NSX-T Federation is a relatively new NSX-T feature and architecture. Before you plan to use it, you must know what features are supported, and how NSX Federation works for your use case. NSX-T Federation is not validated by IBM Cloud fully, but it is a solution and architecture that is supported by VMware.

Regulated Workloads offering

The Regulated Workloads offering is suitable for clients that require a prescriptive reference architecture that matches the IBM Cloud Framework for Financial Services. For more information, see VMware Regulated Workloads as a single site deployment.

The following diagram can be used to compare and contrast the features that are offered by these offerings.

In the previous diagram, the following terms require some additional comments:

• Single SSO and root domain - A single instance of Active Directory and Domain Name Services is deployed with replication between the dual domain controllers automatically.
• Single vCenter - The automation deploys a single vCenter appliance.
• vCenter HA - vCenter high availability (HA) protects vCenter against failures by using an active-passive architecture that uses a three-node cluster with active, passive, and witness nodes. For more information about the VMware architecture, see vCenter high availability.
• Single NSX-T Manager cluster - The automation deploys three NSX-T Manager appliances in a cluster with a Virtual IP address.
• Distributed NSX-T Manager cluster - In the regulated workloads multizone architecture, an NSX-T Manager appliance is deployed automatically into each of the three sites along with an IBM Cloud private load balancer.
• Active NSX-T data plane - All site ingress and egress traverses through the single edge cluster that is deployed in that site automatically.
• Active-Active NSX-T data plane - The architecture supports a manually deployed active-active data plane, which enables a dynamic failover due to a failure in one of the sites.
• No stretched L2 capability - The stretching of layer 2 NSX-T overlay segments across sites is not possible.
• Stretched L2 capable - The stretching of layer 2 NSX-T overlay segments across sites is possible by using manual configuration.
• Single edge cluster Tier-0 gateway for workloads - The automation deploys a single NSX-T edge cluster, consisting of a pair of edge appliances, hosting an active standby Tier-0 gateway for use by the workload VMs. These VMs provide connection between the overlay and underlay networks.
• Stretched edge cluster Tier-0 gateways for workloads per site - To enable an active-active data plane, a stretched edge NSX-T cluster is created manually by deploying an edge appliance in each site. This action enables access to the stretched L2 NSX-T overlay segments, which host the workload VMs if a failure occurs in one of the sites.
• Single-zone vSAN - Regulated workloads automatically deploys management and resource clusters with stretched vSAN storage. For more information, see Storage.
• Mandated-regulated workload services - Regulated workloads must include add-on services, such as Veeam, Caveonix RiskForesight™, Entrust CloudControl™, Juniper® vSRX, and VMware Aria® Operations™ and VMware Aria Operations™ for Logs. Service prerequisites are also required, such as Hyper Protect Crypto Services, KMIP™ for VMware and Direct Link Dedicated.

Automated offerings with manual customization tasks

These automated offerings use a VCF for Classic - Automated single site with the Adding clusters to VCF for Classic - Automated instances. Also, they use a number of manual tasks to create a target platform suitable for the following NSX-T patterns:

• NSX-T multisite centralized - Management plane components centralized in one data center.
• NSX-T multisite distributed - Management plane components distributed across multiple data centers.

The automated offerings with manual tasks patterns are not validated by IBM Cloud. After the initial deployment, the Day 2 automation can be used to deploy vSphere clusters in different data centers by following the IBM Cloud documentation. A number of manual tasks can be initiated to create the required configuration. These VMware related tasks, such as redeploying NSX Managers are documented by VMware in their user guides, but are not specific to IBM Cloud. Therefore, extra considerations might apply when following these guides.

The following diagram can be used to compare and contrast the features that are offered by these offerings.

In the previous diagram, the following terms require some additional comments:

• Single SSO and root domain - A single instance of Active Directory and Domain Name Services is deployed automatically. Additional Microsoft® domain controllers must be deployed manually at the other site and replication must be configured to enable this pattern.
• Single vCenter - vCenter is deployed automatically. A manual deployment of a backup server must be done to enable backups of this server to be made available at the other site to enable recovery. During failure of vCenter, some management functions are not available. However, workload VMs are still accessible.
• vCenter HA - vCenter HA protects vCenter against failures by using an active-passive architecture that uses a three-node cluster with active, passive, and witness nodes. For more information about the VMware architecture pattern that must be manually deployed, see vCenter high availability.
• Single NSX-T Manager cluster - The automation deploys three NSX-T Manager appliances in a cluster with a Virtual IP address.
• Distributed NSX-T Manager cluster - The initial single NSX-T Manager cluster that is deployed automatically must be modified.
• Active-DR NSX-T data plane - This pattern is suitable for where the network latency between data centers is more than 10 ms but less than 150 ms, such as across regions. For more information, see NSX-T Data Center Multisite and also NSX-T Multi Location Design Guide.
• Active-Active NSX-T data plane - This pattern is suitable for where the network latency between data centers is less than 10 ms, such as between availability zones in the same region. For more information, see NSX-T Data Center Multisite and also NSX-T Multi Location Design Guide.
• Stretched L2 capable - It is possible to do the stretching of layer 2 NSX-T overlay segments across virtual data centers.
• Single edge cluster Tier-0 gateway for workloads - The automation deploys a single NSX-T edge cluster, consisting of a pair of edge appliances, hosting an active standby Tier-0 gateway for use by the workload VMs. These VMs provide connection between the overlay and underlay networks. For more information, see Single-site - single-tenant and Single-site - multitenant.
• Stretched edge cluster Tier-0 gateways for workloads per site - To enable an active-active data plane, a stretched edge NSX-T cluster is created manually by deploying an edge appliance in each site. This action enables access to the stretched L2 NSX-T overlay segments, which host the workload VMs if a failure occurs in one of the sites. For more information, see Multisite - single-tenant and Multisite - multitenant.
• Single-zone NFS storage - vSphere data stores that use IBM Cloud File Storage for Classic of different IOPS ratings are available. IBM Cloud File Storage for Classic can be accessed only from hosts in the same site as the vSphere hosts. For more information, see Shared File-level storage across hosts.
• Stretch vSAN storage capable - By using the automation, stretched vSAN clusters cannot be deployed. If stretched vSAN is required, vSphere hosts must be deployed manually and a stretched vSAN cluster must be created.
• Optional add-on services - For more information, see Available services for VCF for Classic - Automated instances.

Related links

• VCF for Classic - Automated single site
• VCF for Classic - Automated multisite
• Regulated workloads - single site