Upon completion of the discovery workshop, you will move on to creating the design and architecture for VMware Cloud on AWS. The main goal of your design is to map business and technical requirements into product capabilities, taking constraints and assumptions into account, and mitigating risks whenever possible. All design decisions must be clearly documented, presented, and acknowledged by the project’s stakeholders before moving to the more detailed logical and physical architecture. A solid design is the foundation of the successful operation of the environment. Let’s illustrate the design decision making process using some examples:
- Requirements:
- 5% of the workload must have 99.999%, 15% of the workload must have 99.99%, and the other 80% must have a 99.9% availability guarantee
- The most critical workloads are SQL Server databases
- Constraints:
- Applications using critical SQL Server databases do not support SQL Server Availability Groups
- The design must provide the most cost-effective solution possible
- Assumptions:
- The DBA team has experience of running SQL Server in a virtual environment
- Risks:
- The organization is in the process of negotiating a new ELA with Microsoft. This final negotiating will take place after the deployment phase of VMware Cloud on AWS
Considering the requirements, constraints, assumptions, and risks, outlined here, the following design decisions were made:
- The design will require two separate SDDCs:
- A standard SDDC with a 99.9% availability guarantee
- A stretched cluster SDDC with a 99.99% availability guarantee
Justification: VMware Cloud on AWS does not support a mix of standard and stretched clusters within a single SDDC at this time. Only the stretched cluster will satisfy the requirement for a 99.99% SLA. Using only stretched clusters will violate the budget constraint.
- SQL Server databases must be deployed on the stretched cluster SDDC and leverage a Windows Server Failover Cluster (WSFC) cluster with shared disks. The default managed storage policy must be used to ensure shared Virtual Machine Disk Files (VMDK) are replicated between AZs.
Justification: Critical SQL Server databases require a 99.999% availability guarantee. This availability requirement cannot be achieved by the infrastructure and requires application-level redundancy to ensure the service is available during upgrades/application maintenance. Using SQL Server Availability Groups is not possible with the current version of applications. VMware Cloud on AWS provides support for shared disk clusters (https://blogs.vmware.com/apps/2021/01/wsfc-validation-vmware-vmc.html) natively with vSAN (limitations apply; for example, there’s no support for the online disk extension), including stretched cluster support.
Risk: Stretched clusters have a performance impact on SQL Server workloads due to vSAN synchronous replication between AZs, which adds latency to all write I/O. To mitigate this risk, reconfiguration of the VM and SQL Server may be required.
- Both SDDCs will require activation of Windows Server licenses. SQL Server licenses should follow the BYOL approach.
Justification: The process of the new ELA negotiation with Microsoft is ongoing. The new ELA will have updated terms and conditions reflecting the licensing restrictions introduced on October 1, 2019. These restrictions require Windows Server licenses to be acquired from VMware. SQL Server licenses are still eligible for BYOL with Software Assurance. ELA includes Software Assurance by default.
Risk: The negotiation process is not finalized yet. The total number of available SQL Server licenses cannot be provided on time. An additional budget should be considered if new SQL Server licenses are required.
This example indicates the level of detail needed in your design document. However, by no means is this a full list of possible requirements. It’s not uncommon to see hundreds of different requirements, constraints, assumptions, and risks that need to be considered for design decisions.
Upon completion of the design, key design decisions must be presented to the key stakeholders, along with a high-level architecture proposal and cost estimates. Expect to have corrections from the stakeholders. All corrections must be properly captured; requirements, constraints, assumptions, and risks must be updated accordingly; and design decisions should be reviewed to accommodate the new requirements of the organization.