Oracle Cloud VMware Solution – Spring Release

New hardware! New Hardware! New use-cases, new integrations and new locations.

That’s a lot of “new” for a single release! It doesn’t seem a year since I wrote the last Spring Release post but it is, so what’s new and shiny in the world of Oracle Cloud VMware Solution this time around? In a shameless copy-and-paste from last year’s post, you can read the [new] Oracle post here, but in this post we’ll walk through the announcements and look at each in turn.

Here’s the high-level overview of what’s new for this season;

Let’s start with the new hardware, both/all of them.

• New OCVS ESXi host “shapes” in a broad range of RAM and CPU sizes, in both Intel and AMD guises, but without any local storage. I know! It’s as if a million voices all cried out in terror – “What, no vSAN !?!?”.
• As if that wasn’t enough, OCVS ESXi hosts are now available and equipped with NVIDIA GPUs. These are in beta at the time of writing but see below for how you can try them out.

And as if that wasn’t enough…

• The VMware Telco Cloud Platform – Public Cloud has an OCVS Reference Architecture. This is exciting news, even if you don’t need to build a Telco Cloud. Again, see below to learn more.
• VMware NSX Advanced Load Balancer is certified for use on Oracle Cloud VMware Solution. We let this cat slip out of the bag some time ago, but as of the 22.1.3 release, OCVS has its place in the Supported Cloud Connectors list.
• Expanded global coverage. As a first-class OCI service, OCVS is available in every OCI region, from the day they open. There are too many dots on the map to count, but according to the Oracle post, the answer to the ultimate question of how many is, indeed, 42 (regions).

New hardware.

This release is pretty big news so definitely deserves its own heading. Last year we saw the introduction of the AMD EPYC-powered DenseIO-E4 shapes to OCVS, complementing the existing Intel Xeon-powered DenseIO shapes. This gave us a range of compute sizes from 32 AMD cores (OCPUs) per host, through the 52 cores of the Intel shape, to 64 and 128 cores from the AMD shape. Similarly, that offered a choice of 768GB RAM in the Intel hosts and 2TB in the AMD ones. While that was great, more choice is always better, so let’s see what we have now.

In addition to the existing shapes, we now have three new bare metal “BM” shapes. Like the AMD shape from last year, the new ones are available with different numbers of their cores enabled. This offers the flexibility to “right-size” based on more than just the shapes’ base specs. These new shapes are:

• BM.Standard 2.52: This is a similar base configuration to the original DenseIO2.52 which OCVS began with except now you can choose between 12, 26, 38 or all 52 cores enabled. This version still has the X7 family Intel Xeon Platinum 8167M processor with a base clock of 2GHz and a max turbo of 2.4GHz. All core-counts have 768GB of RAM and 50Gbps of network bandwidth
• BM.Standard3: This is an Intel X9 based shape with Intel’s Xeon Platinum 8358 processor. It has a base clock of 2.6GHz and a max turbo of 3.4GHz. You can choose from 16, 32, 48 or all 64 cores enabled with, in all cases, 1TB of RAM and 100Gbps of network bandwidth.
• BM.StandardE4: This is a similar base configuration to the E4 DenseIO shape from the last Spring release. This “Standard” variant is still based on the AMD EPYC 7J13 processor with a base clock of 2.55GHz and a max boost of 3.5GHz. It’s also available with 32, 64, 96 or all 128 cores enabled and, in all cases, 2TB of RAM and 100Gbps of network bandwidth.

To vSAN, or not to vSAN, that is the question.

The DenseIO versions of these shapes, when used for OCVS are stuffed full of NVMe drives which are used for vSAN. Split across cache and volume tiering, the hosts each contribute over 40TB of useable capacity to their cluster’s vSAN datastore. vSAN has a number of well documented benefits in performance and control, and is often, all that a solution needs. But not always. One disadvantage of Hyperconverged Infrastructure (HCI) is the coupling of compute and storage capacity to each other. Need more compute, then you get more storage. Need more storage, well, you’re getting more compute. When that’s the case, decoupling storage from compute can enable solutions to be right-sized when they have large storage requirements compared to their compute needs or vice-versa.

The OCI Standard shapes don’t have the local storage of their DenseIO siblings and, while that makes things a little different when setting up an SDDC, it means a solution can have the right amount of compute, together with the right amount of storage, even when those two demands don’t fit elegantly into an HCI solution.

But that’s not all. Many existing vSphere solutions are built around a model of separate clusters for separate purposes. These can often be collapsed into a single cluster, but that’s not always ideal. Take the case of the separate management cluster which has been a staple of VMware reference architectures for a long time. Or, how about dedicated clusters which need to be kept small to minimize per-CPU software licensing. The minimum size for a vSAN cluster is three nodes, which is often increased to four to account for host maintenance or failure scenarios. With traditional external storage, often just two hosts are enough with vMotion and vSphere HA taking care of cases where a host needs to be taken offline or fails.

The introduction of these Standard shapes allows SDDCs without vSAN to contain clusters of different sizes utilizing Oracle Cloud Block (iSCSI) Storage to provide the shared storage layer underneath the vSphere datastores. With full root access as always with OCVS, customers or partners can deploy SDDCs (which right now still need at least three hosts for production use) and then configure the hosts and storage into the cluster sizes that best suit their requirements. While we can’t currently mix DenseIO and Standard shapes in the same SDDC, separate SDDCs, with both types of storage, can be deployed in to the same OCI Virtual Cloud Network (VCN) with shared or routable network access between them.

You’ll see more posts discussing the addition of external storage but for now, here are the key points to know.

• Each SDDC needs at least one, 8TB VMFS datastore using OCI block storage with 10 volume performance units (VPUs) with 25k IOPS. This will house the SDDC’s management appliances and NSX-T Edge nodes.
• OCI Block Volumes are attached to the ESXi hosts using iSCSI to provide datastore capacity.
• You can disconnect and reconnect block volumes from/to hosts as you need to, if you want to rearrange or replace hosts in a cluster.
• OCI block volumes can be created in sizes from 50GB to 32TB in 1GB increments. You can have up to 32 block volumes giving you 1 petabyte of storage.
• You can scale block volume performance in VPUs, and OCVS supports up to 50 VPUs per volume and you can scale performance up and down as necessary to meet your needs and control your costs.
• You can’t share volumes across clusters, and there are some limits to the number of hosts which can be connected to each block volume. This is likely to be subject to change, so check the OCVS documents on oracle.com for the latest numbers.
• The OCI Block Volume is designed to provide 99.99% annual durability. That’s very good, but it’s not 100% so please make that a part of your BCDR model (rather than all of it), with a regularly tested backup and recovery capability in place too.

More new hardware (but with GPUs)!

As if all that excitement weren’t enough, you can also now try out OCVS hosts with GPUs! Watch out for more news about these, but the TL;DR version is, you can sign up to the public beta (here), for a limited time, to get early access to OCVS based upon the BM.GPU.GU1.4 (also known as the BM.GPU.A10.4) compute shape, before their general release. Equipped with four NVIDIA A10 Tensor Core GPUs Powered by NVIDIA Ampere architecture, these GPUs, together with NVIDIA vGPU software can accelerate graphics-rich virtual desktops in VMware Horizon, or cool new AI workloads, now in a flexible, scalable, cloud model!

The GPUs in these shapes need the CPU and the rest of the system to support them, and these shapes run the Xeon Platinum 8358 processor with 64 cores, 1TB RAM, 100Gbps of network bandwidth and 7TB of local NVMe. The local NVMe drives mean the SDDC will have a small vSAN datastore, but will almost certainly take advantage of the block storage capability we’ve just been hearing about.

VMware Telco Cloud – Flexibility you control.

At Mobile World Congress, among the other news was a small side-note about Oracle and VMware helping Communications Service Providers (CSPs) with a Telco Cloud Platform – Public Cloud (TCP-PC) integration with OCVS. Which, unless you’re in the mobile world, you might have missed. If you’re not in the mobile world, why would you care? Well, operating the network functions which make a mobile network err.. work, is one of the most demanding workloads you’ll find. The TCP-PC reference architecture requires a number of vSphere’s performance dials turned right up to 11, and, because customers (and VMware’s Telco engineering team) get full root access to the OCVS SDDC, this was achieved on a standard OCVS SDDC build. Nothing special. No favors from our friends in Oracle’s Engineering teams, just the controls every customer gets in OCI and OCVS.

Sure, the standard OCVS deployment needs some settings changing and some normally un-used features activating, but the point is, if we can do enough to make our Telco Cloud Platform reference architecture run on OCVS, think about what other, demanding and particular, virtualized workloads that you couldn’t previously make the move to “cloud” that, with the flexibility and performance of OCI and OCVS, you now can. Talk to your VMware or Oracle account teams if you think this might apply to you, we’ll be happy to help.

New VMware product integration.

As well as the existing VMware products which already work with OCVS and which we re-test as new versions are released (see interopmatrix.vmware.com), we recently added NSX Advanced Load Balancer to the list. The testing was completed some time ago, and we noted it more publicly in the 22.1.3 release notes. There’s a full installation guide on our Avi Networks website here but if you’re at all familiar with the product, you’ll have no trouble working out how it can be used in OCVS. It’s worth pointing out, that you’ll need the Enterprise Edition license (see here) but with that you do get the full feature set of this super-capable product.

Tomorrow (well today, actually) the world!

As movie villains have long been so fond of saying, “and tomorrow the world…” but Oracle won’t keep you waiting that long. Their (not even slightly evil) plan is to make Oracle Cloud and with it, Oracle Cloud VMware Solution available in as many Regions (geographic locations) as possible. The number of OCI and hence OCVS regions currently stands at 42, with more to come. Once again, you can see the map on the Oracle website for the up-to-date count.

However, aside from that headline number, it’s worth pointing out that when we say “all” Regions we don’t just mean “all public Regions”. We also mean all the OCI Government Regions, the upcoming EU Sovereign Regions and you can even deploy OCVS in it if you buy your own, private, Cloud@Customer “Dedicated Region”. So, if you’ve been waiting for a Hyperscaler cloud to arrive near where you are, check the map and see if you can become an OCVS customer.