Due to updates, I've refreshed the comparison table of available node types. The main changes are: 1.) New nodes M7i.metal-24xl 2.) Available vSAN architecture (ESA and/or OSA) 3.) i3.metal are no longer available for new contracts as Reserved Instances.

So, we come to the second part. You've done all the steps in part one, but you still need more space (or you realize that you can reduce the number of hosts from a Compute perspective, but not Storage). Then you need to start optimizing the VMC on AWS infrastructure itself. There will be 3 main steps here, just like in the last article - optimize storage policies, optimize host types and vSAN, and optimize clusters.

It's no secret that many infrastructures in VMC on AWS are bounded by storage capacity rather than compute resources. That is, the number of hosts is determined by the usable capacity requirements on the cluster, while there are spare/free compute resources. This relationship follows directly from the fact that VMC on AWS utilizes VMware vSAN-based hyperconverged infrastructure as its primary storage, and therefore there is an explicit capacity/compute resource ratio. That said, there are three types of nodes available in VMC on AWS (or even two if we're talking about Reserved Instances since i3 is now available only on demand) and these ratios are not always exactly what is required. Within this article I would like to talk about what...

I have created a map with every region available for VMware Cloud on AWS (VMC on AWS), Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE) and Oracle Cloud VMware Solution (OVS). These are cloud services that allow you to run VMware workloads natively on different cloud platforms.

I created the spreadsheet with all the available regions for VMware Cloud on AWS (VMC-A), including the services available there (like VSR, VCDR, etc), node types (i3, i3en, i4i), and other characteristics (like stretched cluster support and compliance). Also add plans from public roadmaps for both AWS and VMC-A.

With the appearance of i4i nodes in VMC, I realized that I was missing a table in which I could compare all available nodes (i3, i3en, i4i) in details.

Well, let's go through the points outlined in Part 1 and Part 2 and look at an example of how testing might look end-to-end.

As I mentioned in the first part of the guide, defining the goals and success criteria is a mandatory step for a successful POC. Of course, success criteria will vary, but they all have something in common — they should follow the S.M.A.R.T. rules:

For more than ten years in the IT industry, I have conducted a lot of tests and proof-of-concepts (POC) of various storage systems. While it was a completely different type of storage — traditional FC-connected SAN storage, NAS, SDS (Software Defined Storage), and HCI (Hyper Converged Infrastructure) platforms, the challenges were nearly the same. And quite often I faced a situation where tests were not anyhow aligned with the business needs and even were technically incorrect which led to the impossibility to deliver any meaningful results.