Accessing and configuring the VMware Cloud Console – Appendix: Preflight before Onboarding

There are a couple of steps required before you can start consuming VMware Cloud on AWS. You use the VMware Cloud Console to provision VMware Cloud on AWS SDDC. If you are already using any of the VMware Cloud services, you can just log in to the VMware Cloud Console and look for VMware Cloud on AWS in the Services inventory:

Figure 12.1 – VMware Cloud Console Services inventory

However, if it’s the first time you’re using VMware Cloud services, you should get access to the VMware Cloud Console.

The following steps outline the procedure to get started with the VMware Cloud Console:

  1. Receive a welcome email: Upon processing your purchase, VMware will send an email with an activation link. Use this link to log in to the VMware Cloud Console.
    NOTE
    VMware will use the email address designated as the “Fund owner’s” to send the activation link.
  2. Setup an Organization. An Organization provides authentication boundaries for your VMware Cloud services. Each Organization can be entitled to different services. A user can access multiple Organizations and switch between them in the VMware Cloud Console.
  3. Setup VMware Cloud service accounts: After gaining initial access to the VMware Cloud Console and creating an Organization, you can entitle user accounts to access to VMware Cloud on AWS. You can use manual assignment, or you can federate VMware Cloud Console with your identity provider. If your design includes federation for the VMware Cloud Console, it’s important to configure the federation feature before you deploy VMware Cloud on AWS SDDC.
  4. Create a term subscription. If you purchased a term subscription, it’s important to create a subscription object in the VMware Cloud Console before you deploy an SDDC. Creating a subscription matching your purchase is a organization’s responsibility – VMware does not pre-create a subscription in your VMware Cloud Organization. Make sure you have all the details of your purchase contract before creating a subscription, including the following:
    • AWS Region
    • Host count and host type
    • Subscription type – flexible or standard
    • Subscription duration – 1 year or 3 years

Figure 12.2 – Creating a subscription for VMware Cloud on AWS
NOTE
You can deploy a VMware Cloud on AWS SDDC without creating a subscription. In this case, VMware will use on-demand prices for billing. If you purchased a subscription but did not create a subscription object in the VMware Cloud Console, on-demand prices will be applied. If you deploy your SDDC using a different AWS Region or host type, or use more hosts, on-demand prices will be applied as well.

Purchasing and onboarding – Appendix: Preflight before Onboarding

In this chapter, we will cover the most important configuration items you need when you deploy the SDDC and configure a hybrid cloud environment.

You will find a detailed description of the configuration steps and items from previous chapters of this book.

Purchasing and onboarding

When purchasing the service and preparing for the first SDDC deployment, you need to choose a couple of options. These options may have a large impact on the further operations of the service, so make sure your choices are well thought out, as you will not be able to change some of them moving forward.

Purchasing and funding

When purchasing the service, you can select one of the following options:

  • A direct VMware purchase
  • AWS resell
  • Purchasing through a Managed Service Provider (MSP)

VMware Cloud on AWS supports all three routes to the market. Depending on your purchase strategy, you may find one or other better suited to your needs.

Note

Some services available for VMware Cloud on AWS can only be purchased directly from VMware, for example, Microsoft host-based licenses for workloads on VMware Cloud on AWS.

When purchasing from VMware, you can choose how you want to pay for the service:

  • VMware Purchasing Programs: You can select from a different range of programs, most of them offering so-called Credits. You can use credits toward payment for VMware Cloud on AWS. Consult a VMware sales representative to get more details about available programs. (More details on VMware Purchasing Programs can be found here: https://customerconnect.vmware.com/web/vmware/spp-landing.)
  • Pay by invoice: You can activate pay by invoice using the VMware Cloud Console.
  • Pay with a credit card: Applicable for small purchases up to $25,000.

Consumption options

When deploying VMware Cloud on AWS SDDC, you have a choice between the following:

  • Subscription: Your commitment to buy a certain amount of host capacity for a defined period. When purchasing a subscription, you select the AWS Region, host type, and the number of hosts. You can pay upfront or monthly. If purchasing from VMware or AWS, you can select the following:
    • Flexible subscription: The terms of the subscription (number of hosts, region, host types) can be changed over time (limitations apply)
    • Standard subscription: The terms of the subscription are fixed and cannot be changed
  • On-demand: You can run VMware Cloud on AWS SDDC using on-demand prices. You are free to select the region, host type, and the number of hosts.

Typically, a standard 3-year term subscription is the most cost-effective option, while on-demand prices are the highest. Depending on your use case, one or another option might work better. In our experience, a flexible subscription is the right balance between flexibility and cost savings.

Networking – Knowing the Best Practices, FAQs, and Common Pitfalls

The network communication with workloads deployed on your SDDC is a key part of the overall user experience and, probably, one of the most complex design sections. Network configuration is under the organization’s control; VMware only provides underlying network connectivity with the hardware AWS infrastructure.

Let’s highlight the most common network misconfigurations:

  • Insufficient connection between on-premises and the VMware Cloud on AWS SDDC

It’s a common practice to initially configure an IPSec VPN over the internet to achieve basic connectivity between on-premises and the SDDC and to secure the traffic flow. However, a VPN tunnel over the internet is not suitable for a mass migration of the workload. Live vMotion over the internet is not supported. Unpredictable bandwidth and latency affect the migration timeline making it unpredictable. For a large-scale migration and/or a hybrid cloud use case, you need to plan for a dedicated private connection to your SDDC.

  • Underestimating Level 2 network extension complexity

HCX and/or NSX Standalone Edge provide a unique feature – the ability to stretch a Layer 2 broadcast domain for a selected VLAN and allow the workload to retain the original IP addresses. This feature enormously helps to seamlessly migrate applications without an impact on the client configuration. On the other hand, this feature has several trade-offs, impacting workload availability and/or performance:

  • For workloads deployed on a Layer 2 extended segment (even with the MON feature enabled), all traffic sent to destinations residing outside of the SDDC network will first reach the default gateway, located on-premises. It may cause unexpected high latency when accessing workloads residing in native AWS VPC, including the connected VPC.
    • Workloads have a clear dependency on the on-premises default gateway. If the link between on-premises and the SDDC stops functioning, the workload on the extended leg of the segment would not be able to reach the default gateway and communicate with the external destination.
    • Undersized HCX Layer 2 extension appliances: All broadcast traffic within the VLAN must traverse the extension appliances on both sides of the tunnel. If the appliance is overloaded and/or does not have enough resources, the workload residing in the SDDC drops all external connections. This scenario is often observed with entry-level clusters based on the i3.metal host type. You can scale out and deploy multiple extension appliance pairs and distribute extended segments between appliances.
    • Extension appliance availability: As mentioned earlier, the Layer 2 extension has a direct dependency on the HCX appliance. If the appliance stops working, becomes corrupted, or restarts, the network communication is affected. If you plan to maintain the extension after the migration is complete, use the HA feature of HCX extension appliances. Bear in mind that for a complex environment with a lot of extended VLANs, configuring HA will reduce compute and storage resources on both sides of the environment, including the SDDC. You may need to scale out the vSphere cluster hosting appliance on the SDDC side, incurring additional costs.
    • Security concerns: Many security teams tend not to allow a Layer 2 extension over the public internet as it poses security risks and exposes sensitive broadcast traffic to the internet. When not properly addressed in the design phase, it might drastically affect your migration plans if you were planning to live migrate and retain the IP addresses. The best solution is to use a dedicated DX line and pass the extension traffic over the DX, which must address most of the concerns of the security team.
  • Identify network dependencies after migration

Many organizations claim that performance suffers after migrating workloads to the cloud. Some of these concerns are due to not following the best practices while migrating; however, in many cases, it has nothing to do with the SDDC. For a complex distributed application when not all components were properly identified and migrated to the cloud, the traffic may have additional hops traversing the WAN link(s), adding not foreseen latency to the application. An example of this is a migration of a SQL Server database warehouse, where the centralized integration service (SSIS) was left on premises, causing all the data to be first moved back to on-premises and then retransmitted to the SDDC. The impact of this configuration on the application was measured at a 300% increase in the OLAP cube generation time. The troubleshooting and search for affected traffic flows may be a complex and time-consuming task. VMware Aria Operations for Networks can help you visualize the traffic flow for a selected application.

Storage – Knowing the Best Practices, FAQs, and Common Pitfalls

Storage resources are crucial for storing an application’s data. You should encompass both capacity and performance requirements while designing, implementing, and operating the infrastructure. We will review the most common misconfigurations and/or suboptimal design choices:

  • Sizing

Storage resources define two different dimensions of resources – storage capacity and storage performance. While sizing an environment, very often only one of these dimensions, in most cases capacity, will be considered. This approach is a direct path to failure. Even if your SDDC will have enough storage to host your workload, the resulting performance in many cases is inadequate and will lead to lengthy and costly escalations.

When sizing storage, make sure to follow the recommendation of VMware Cloud Sizer (https://vmc.vmware.com/sizer) both in terms of capacity and performance. Double-check your sizing assumptions and tweak them using the advanced sizer if needed.

Figure 11.5 – VMware Cloud Sizer – Sizing Assumptions

  • Storage policies

vSAN is very easy and intuitive to manage with storage policies directly in vCenter. There’s no need to work with the storage team, and it’s easy to make changes. However, it could work against you. You could be tempted to use RAID5 for all your workloads and free up more space than you’d get with RAID1. RAID5 has a known performance implication, especially for workloads with predominantly small writes, causing a lot of overhead with RAID5. If the initial sizing has been done with RAID5 configuration, you may not have enough hosts to switch to RAID1 if needed. If you find yourself in this situation, decide whether you can split some of the VMDKs and dedicate small VMDKs to some particular data type – the database transaction log and tempdb are good candidates for such optimizations.

Avoiding common pitfalls – Knowing the Best Practices, FAQs, and Common Pitfalls

In the previous section, we were focused on how to do things right. However, it’s also important to highlight the most common scenarios, configurations, and design decisions where a resulting configuration proved to be ineffective and error-prone.

Compute

Compute resources provide the necessary CPU and memory resources for virtual machines. Let’s review the most common misconfigurations and/or suboptimal design choices:

  • Sizing

It’s often the case that VMware Cloud on AWS SDDCs are either undersized or oversized. Undersized environments lead to low performance and a bad user experience, while oversized environments are expensive in terms of cost per VM. Opting for a right-sizing exercise and expanding on-premises vSphere environments as an afterthought may result in running into extended procurement cycles. However VMware Cloud on AWS benefits from the flexible and elastic capacity of public clouds. Paired with the right Elastic DRS policy, organizations can achieve cost savings by leveraging the scale-in option of the Elastic DRS policy, and performance burst, if required, by scaling out their cluster when demand grows. We recommend using custom Elastic DRS policies, which give you much better control not only over the storage resources, but also CPU and memory.

  • Host type

Another common misconfiguration we observe a lot is selecting the wrong host type. We observe most issues with configurations involving the i3.metal host type. i3.metal might be suitable for running general-purpose workloads, but its outdated CPU (Broadwell) and lack of hyperthreading (and as a result, its low amount of CPU resources) makes resource contention very possible, especially with entry-level clusters (https://vmc.techzone.vmware.com/resource/entry-level-clusters-vmware-cloud-aws). A two-host i3.metal cluster is limited to 35 simultaneously running VMs, as most of the CPU resources are allocated to management VMs. Such a cluster might be suitable as a management cluster but should not be considered for production implementation. i3.metal End of Sale (EoS) naturally eliminates this problem; however, you still might be tempted to take i3.metal using an on-demand subscription for your ongoing project to profit from the cost. We strongly recommend not doing so at this point and consider i4i.metal, which has a much more powerful and modern CPU.

  • SDDC upgrade and lifecycle management

Most of the observed issues are tied with the wrong expectations: VMware releases a new SDDC software bundle every 6 months. This bundle is based on the latest vSphere + NSX version at the release time. With all the excitement, there are a couple of issues to underline:

  • Do not expect your SDDC to be upgraded overnight. For a brownfield (existing) SDDC, the estimated upgrade time is 6+ months. Depending on the complexity of your SDDC, it may be more.
    • Version inconsistency: VMware Cloud on AWS SDDCs always use the latest available build for deployment. You cannot specify a build version when deploying your SDDC. Current bundles use vSphere 8, while your on-premises environment might be still on vSphere 7. It may have a negative effect on reverse migration, potential incompatibility with management/automation/monitoring tools, and prevent you from raising the virtual hardware level of the VMs you migrate to the cloud.
  • Configuration management

VMware Cloud on AWS is offered as a managed service. Most ESXi/vSphere cluster/vCenter configurations are predefined and cannot be changed. If your applications or automation tools depend on a particular advanced setting, make sure to clarify the configuration before deployment. You would not be able to change the value after deployment.

Day 2 operations – Knowing the Best Practices, FAQs, and Common Pitfalls

The Day 2 operations of the infrastructure is one of the key elements of a successful implementation. Often, underestimating Day 2 operations leads to a suboptimal solution design, which is hard to maintain, leading to dissatisfaction. Day 2 operations is the phase when your team will spend most of the time working with the environment.

As a best practice, your architecture should be built with the primary focus on the Day 2 operations:

  • Ensure you engage the IT operations team when presenting key design decisions.
  • Plan to train the IT operations team on the new technologies.
  • Include runbook updates as a part of your design implementation.
  • Explain the key lifecycle management changes when moving to VMware Cloud on AWS.
  • Validate current monitoring/backup/automation tools for compatibility. Recommend updating or switching to other tools if necessary.

VMware Cloud on AWS can streamline the Day 2 operations of the environment:

However, VMware Cloud on AWS also differs from an on-premises vSphere environment in a few key ways:

  • Most of the infrastructure-level settings (ESXi host, vSphere cluster, vCenter) are predefined by VMware and cannot be changed. The settings’ values may be different from what you are using in your environment.
  • The permission model does not allow full access to the environment, including vCenter, ESXi, and NSX manager. This may limit some operations and/or optimization you are performing in your on-premises environment.
  • Backup compatibility: VMware requires each vendor of a backup solution to undergo a certification process to validate the compatibility with VMware Cloud on AWS. Make sure your current backup solution is certified or you will need to plan a transition to a different product/vendor. You can check the following kb article outlining certification for various backup solutions (https://kb.vmware.com/s/article/76753).

Make sure to address key Day 2 operations challenges in the design phase. It’s not helpful if you find out your backup vendor is incompatible after workload migration!

Contract documentation

VMware offers VMware Cloud on AWS as a managed service. As a consumer of cloud services, you should double-check all the relevant contract documentation before making a purchase decision. VMware has simplified and consolidated access to contract documentation on a separate web page (https://www.vmware.com/agreements.html). Use this page to look for terms and agreements for VMware products and services. For VMware Cloud on AWS, we recommend you review the following set of documents: