VMware Cloud Well-Architected Framework Build Pillar - Infrastructure Services - Azure VMware Solution

Overview

The Plan Pillar described the need to assess options for extending or rearchitecting infrastructure services for consumption by VMware Cloud-based workloads. The Build Pillar addresses considerations and recommendations for the following implementation patterns:

Host Infrastructure Services Locally
Migrate to Native Cloud Services
Implement Shared Infrastructure Services

Connectivity and Accessibility of Infrastructure Services

When a VMware SDDC is deployed in the cloud, a set of default basic configurations related to infrastructure services are implemented to support the VMware components that make up the SDDC. There is no hard requirement to establish infrastructure services in the cloud prior to the deployment of a VMware Cloud SDDC, as the service provider will have accounted for these basic services as part of their provisioning process. After deployment, communication must be established between the VMware Cloud SDDC and any on-premises data centers or other VMware Cloud SDDC deployments that will share a common set of infrastructure services. The connectivity method should be stable and highly available to prevent disconnects resulting in split-brain challenges or service unavailability.

Host Infrastructure Services Locally

The most common and recommended approach to implementing infrastructure services in Azure VMware Solution is to treat the AVS private cloud as an additional data center. Infrastructure services are configured locally or as extensions of existing multi-data center systems, using the same tools deployed in on-premises environments. Benefits to this approach include:

Leveraging existing investments in tooling, processes, and training.
Continuity of infrastructure services in the event of a communication failure between the AVS private cloud and the on-premises environments.

Migrate to Native Cloud Services

In some cases, an Azure native infrastructure service may be a suitable alternative to an extending an existing service to an AVS private cloud. Consider organizational requirements against native tool functionality and cost. For example, Microsoft maintains a robust NTP infrastructure and provides recommendations for configuring Windows and Linux workloads in Azure to use it.

Not all native services are direct replacements to traditional services. Azure Active Directory and Azure Active Directory Domain Services, for example, offer only subsets of the functionality of traditional self-managed Active Directory Domain Services. Notably, Azure Active Directory cannot be used as an identity source for the AVS private cloud vCenter.

Implement Shared Infrastructure Services

When multiple AVS private clouds will be deployed, consider following the Microsoft Cloud Adoption Framework enterprise-scale pattern for deploying shared identity, management, connectivity, and AVS landing zone subscriptions. In this model, additional private clouds connect to the connectivity subscription as spokes and access centralized infrastructure services over the high-speed Azure backbone.

Using an on-premises data center to host shared infrastructure services is possible but recommended against unless warranted by specific customer requirements.

Service-specific recommendations

Specific recommendations by infrastructure service are detailed below:

DNS
- If the AVS private cloud will be isolated from on-premises or other VMware Cloud infrastructure, deploy a new DNS infrastructure with the AVS private cloud.
- If the AVS private cloud will be connected to on-premises or other VMware Cloud infrastructure, extend the existing DNS infrastructure to AVS.
- Configure an FQDN zone for the AVS-hosted domain and add it to the default NSX-T DNS service.
DHCP
- Use the NSX-T DHCP service or a local DHCP server in the private cloud to avoid routing broadcast DHCP traffic back to the on-premises data center.
NTP
- Microsoft maintains time sources for most Azure platform services. For AVS VMs, use a Microsoft default NTP server for time synchronization unless you have a specific requirement.
Log Aggregation and Monitoring
- Syslogs for AVS infrastructure components can be archived to a storage account or streamed to an Azure Event Hub.
- VMware vRealize Operations and vRealize Network Insight can be used to monitor AVS private clouds. vRealize Log Analytics supports pull logging of events, tasks, and alarms. Syslog pushing of unstructured data from vCenter and ESXi hosts to vRealize Log Insight is not currently supported.
- Native Azure services including Log Analytics, Microsoft Defender for Cloud, Microsoft Sentinel, and Azure Monitor can be used to monitor AVS components and workloads.
- Azure Arc can be used to extend native Azure management and monitoring to AVS or on-premises hosted VMs .
Directory Services
- Deploy one or more Active Directory Domain Services (AD DS) domain controllers in the AVS private cloud, or in the identity subscription if centralizing functions. If deploying domain controllers as Azure IaaS VMs, follow high availability recommendations.
- Update Active Directory Sites and Services to direct Azure and Azure VMware Solution AD DS traffic to the appropriate domain controllers.