Running Dell ObjectScale on VMware vSphere with Tanzu
Wed, 15 Jun 2022 15:45:18 -0000|
Read Time: 0 minutes
Underlying HCI infrastructure architecture considerations
As many organizations embrace digital transformation and the application modernization journey that is involved in this process, Dell Technologies and VMware supporting customers by providing them with modern cloud infrastructure and storage solutions that support the demands of this new set of cloud native applications.
Dell ObjectScale, VMware vSphere with Tanzu, and the vSAN Data Persistence Platform (vDPp) are all examples of next generation cloud native technologies that deliver simple, scalable, and enterprise grade Kubernetes native S3 compatible object storage services on a Kubernetes runtime built into the vSphere hypervisor. To learn more about the details of this powerful set of technologies, check out these great blog posts from my colleagues over at VMware here and here. A recently published reference architecture white paper also walks through the steps of deploying these technologies together.
Now let’s get into our primary topic for this blog, which is the underlying HCI infrastructure architecture considerations for running ObjectScale on vSphere with Tanzu.
Setting the stage
Cloud infrastructure administrators have a lot of flexibility in terms of what and how to configure the infrastructure on which Dell ObjectScale runs. These options not only come at the underlying HCI infrastructure implementation layer but also at the VMware SDDC layer. This gives administrators choices on mixing the right combination of the two layers that best meet their business and operational requirements.
So, what are the layers that make up these options? For this discussion we will break it down as follows:
HCI Infrastructure Layer Options
- Construct – Dell vSAN Ready Nodes
- Consume – Dell VxRail HCI Integrated Systems
VMware SDDC Software Layer Options
Construct - VMware vSphere with Tanzu + VMware NSX-T
- Consume - VMware Cloud Foundation (VCF) with Tanzu
After we review these options, we will highlight how they can be used to align to your ObjectScale architecture design and workload requirements.
Construct HCI and Construct VMware SDDC – Dell ObjectScale on Dell vSAN Ready Nodes with VMware vSphere with Tanzu + VMware NSX-T
This option involves deploying ObjectScale on vSphere with Tanzu enabled Dell vSAN Ready Node clusters and then manually deploying and configuring the rest of the required VMware SDDC software stack including NSX-T. This is essentially the builder’s approach to implementing the HCI infrastructure stack and the VMware SDDC stack. This gives infrastructure administrators the most control over their infrastructure configuration and components. The tradeoff, however, is that it adds a bit more complexity and more manual steps to get to an outcome that is ObjectScale ready.
Consume HCI and Construct VMware SDDC – Dell ObjectScale on Dell VxRail with VMware vSphere with Tanzu + VMware NSX-T
With this approach, infrastructure administrators can take advantage of consuming pre-validated and co-engineered Dell VxRail HCI integrated systems, enabling vSphere with Tanzu on them, and then manually deploying the NSX-T components of the solution. This speeds up and simplifies the HCI infrastructure management and operations portion of the stack while still delivering on the required SDDC infrastructure foundations needed for ObjectScale to run.
Construct HCI and Consume VMware SDDC – Dell ObjectScale on VMware Cloud Foundation with Tanzu on Dell vSAN Ready Nodes
This option delivers infrastructure administrators with granular control in constructing the underlying HCI HW components while simplifying the VMware SDDC layer and consuming it as a full cloud platform using VMware Cloud Foundation. This helps streamline the VMware SDDC to include NSX-T out of the box and can automate the deployment and configuration of the VMware SDDC components that are required to enable vSphere with Tanzu and run ObjectScale.
Consume HCI and Consume VMware SDDC – Dell ObjectScale on VMware Cloud Foundation with Tanzu on Dell VxRail
This option provides a true full stack turnkey cloud infrastructure platform for infrastructure administrators to consume. This co-engineered solution between VMware and Dell Technologies delivers the fastest path to hybrid cloud and Kubernetes. Administrators gain the operational and feature benefits of VxRail, the only HCI system with deep VMware Cloud Foundation integration, with the out of the box simplicity and automation of the VMware Cloud Foundation SDDC cloud platform. From an ObjectScale use case perspective, infrastructure administators can accelerate getting all the needed underlying cloud infrastructure up and running so that ObjectScale can be deployed quickly and easily at scale and with a standardized cloud infrastructure architecture built in.
Choosing the right ObjectScale deployment infrastructure architecture
All these options deliver the necessary infrastructure prerequisites required to deploy and run ObjectScale, just through different implementation approaches that align to an organization’s operating model. ObjectScale, however, can also be deployed in several different ways, which can affect the implementation of your underlying infrastructure.
Let’s review what these options are, how our infrastructure can support these deployment models, and when would be the best time to choose one over the other.
First, let’s call out the ObjectScale deployment architecture options available:
- Co-locate ObjectScale data services on the same clusters where user application workloads run
- Run ObjectScale data services on dedicated cluster infrastructure separate from user application workloads
How an infrastructure administrator would configure the underlying HCI and VMware SDDC stack based on these options will ultimately depend on which SDDC deployment method was used, vSphere with Tanzu + NSX-T or VCF with Tanzu.
The infrastructure implementation design details vary slightly since VCF implements a prescriptive cloud architecture using the concept of workload domains. This means that cloud infrastructure administrators must consider how to deploy vSphere with Tanzu enabled clusters to run ObjectScale within the context of this VCF’s workload domain architecture. On the other hand, if administrators were using the build approach of deploying individual vSphere with Tanzu enabled clusters, architecture design decisions are a bit more open ended. Either way, both implementation methods support both ObjectScale deployment architecture models of co-located and dedicated and can be run on both Dell vSAN Ready Nodes and Dell VxRail HCI Integrated Systems.
So, what would the first option look like when co-locating ObjectScale data services on the same cluster as where user application workloads are run?
The following figure provides a visual depiction of what this option may look like in a VCF on VxRail deployment using a single VI workload domain with a single vSphere with Tanzu enabled VxRail cluster in it. In this example, we would deploy ObjectScale to the Supervisor Cluster running on this WLD cluster. Application teams would then have their user application workloads running on the same cluster infrastructure and share the underlying physical HCI compute, network, and storage resources.
Figure 1: VCF on VxRail – ObjectScale co-location cluster deployment
This approach has advantages in terms of minimizing the infrastructure footprint required to run both workload types. It can also help drive improved resource utilization of the HCI infrastructure that has been deployed. This can also be a great fit for minimizing licensing costs if you have containerized user workloads and VM-based workloads that need to consume ObjectScale storage since there is only one cluster you need to enable vSphere with Tanzu on and vSphere can support running containers and VMs on the same vSphere cluster. However, there are possible downsides. These include resource contention for user workloads since you are sharing the same infrastructure to run ObjectScale data services and lack of independent scalability and right sizing of infrastructure resources for ObjectScale and the user applications.
Option 2, running ObjectScale data services on dedicated cluster infrastructure separate from user application workloads, eliminates the resource contention by running ObjectScale on its own dedicated cluster infrastructure separate from user workloads. In a VCF on VxRail deployment, this may be implemented in a couple of ways. The first is to create a single VI WLD with two or more VxRail clusters in it. One cluster would have vSphere with Tanzu enabled on it and is where ObjectScale would be deployed. The other cluster, depending on the types of workloads running (whether they be VM-based only or a mix of containers and VMs) may not require vSphere with Tanzu be enabled on it and can just be used to run user application workloads.
By running ObjectScale on its own workload domain cluster resources, we now have physical resource isolation for both ObjectScale and user application workloads. This avoids resource contention between the two and now have the flexibility to independently scale resources for both as needed. Using this VCF workload domain organizational model may be helpful if your organization is aligning ObjectScale storage and the workloads that consume it as part of a single business unit and you may want to keep all of that together and managed within a single managed pool of cloud infrastructure resources. The following diagram provides an illustration of how this would look.
Figure 2: VCF on VxRail – ObjectScale dedicated cluster deployment with single VI WLD
The other VCF workload domain design approach is to deploy two VI workload domains. One would contain one or more VxRail clusters with vSphere with Tanzu enabled on them and ObjectScale would be deployed on top. The other VI workload domain would contain one or more VxRail clusters that may or may not have vSphere with Tanzu enabled on them and would run user application workloads only. This method still gets you separation of physical resources to avoid resource contention as well as independent scaling for both workload types, but organizationally we have deployed workload domains based on infrastructure service function.
Deploying ObjectScale into its own dedicated workload domain provides the possibility of maximum scale of how many clusters we can deploy into a single domain that can be used solely for running ObjectScale data services. We can also help simplify the networking for those clusters since we only need to accommodate for the networking needs of ObjectScale and not also for user applications workloads, too.
The following example uses dedicated NSX-T instances for each VI workload domain. In VCF, it is possible to share an NSX-T instance across multiple VI workload domains. If we would have done this, we wouldn’t have to deploy another cluster of NSX Edge appliances and could have just used the NSX Edge appliance deployed in VI Workload Domain 2 to meet the requirements that are needed when enabling vSphere with Tanzu on vSphere clusters. But since we are using separate dedicated NSX-T instances, each VI workload domain will require NSX Edge appliances to meet these vSphere with Tanzu and ObjectScale minimum requirements for the clusters contained within them. The following figure shows an illustration of what this multi-workload domain organizational model would look like.
Figure 3: VCF on VxRail – ObjectScale dedicated cluster deployment with two VI WLDs
It is important to call out that these same co-located and dedicated cluster ObjectScale architecture models can be used in vSphere with Tanzu + NSX-T on Dell vSAN Ready Nodes/VxRail deployment options as well and are not tied to just the VCF on VxRail examples shown here. The same overall ObjectScale logical and physical layout considerations would apply. Administrators who choose to approach running ObjectScale in this way would be responsible for determining where the NSX-T Manager VM’s, Edge appliances, and vCenter components would run as there would be no Management Domain construct defined as part of a cloud platform architecture like VCF has.
This is not the end, it’s just the beginning…
I hope you have found this information helpful as you work through your ObjectScale adoption journey. This is not the end of your journey, however. For more information about VxRail and ObjectScale, check out the links at the bottom of this post.
Author: Jason Marques
Related Blog Posts
New Year’s Resolutions Fulfilled: Cloud Foundation on VxRail
Fri, 28 Jan 2022 14:43:21 -0000|
Read Time: 0 minutes
New Year’s Resolutions Fulfilled: VMware Cloud Foundation 4.4 on VxRail 7.0.320
Many of us make New Year’s resolutions for ourselves with each turn of the calendar. We hope everyone is still on track!
The Cloud Foundation on VxRail team wanted to establish our own resolutions too. And with that, Dell Technologies and VMware have come together to fulfill our resolution of continuing to innovate by making operating and securing cloud platforms easier for our customers while helping them unlock the power of their data.
And as a result, we are happy to announce the availability of our first release of the new year: VMware Cloud Foundation 4.4 on Dell VxRail 7.0.320! This release includes Cloud Foundation and VxRail software component version updates that include patches to some recent widely known security vulnerabilities. It also adds support for Dell ObjectScale on the vSAN Data Persistence Platform (vDPp), support for additional 15th generation VxRail platforms, new security hardening features, lifecycle management improvements, new Nvidia GPU workload support, and more. Phew! So be resolute and read on for the details.
VCF on VxRail Storage Enhancements
Support for vSAN Data Persistence Platform and Dell ObjectScale Modern Stateful Object Storage Services
Initially introduced in vSphere 7.0 U1, the vSAN Data Persistence Platform (vDPp) is now supported as part of in VCF 4.4 on VxRail 7.0.320. Check out this great VMware blog post to learn more about vDPp.
Beginning in this release, support for running the new Dell ObjectScale data service on top of vDPp is also available. This new next-gen cloud native software defined object storage service is geared toward those IT teams who are looking to extend their cloud platform to run Kubernetes native stateful modern application data services. To learn more about ObjectScale please refer to this blog post. Note: VCF on VxRail currently supports using vDPp in a vSAN “Shared Nothing Architecture Mode” only.
The following figure illustrates the high-level architecture of vDPp.
Figure 1 – vDPp and ObjectScale
As a result of this new capability, VCF on VxRail customers can further extend the storage flexibility the platform can support with S3 compatible object storage delivered as part of the turnkey cloud infrastructure management/operations experience.
Giving customers more storage flexibility resolution: Check!
VCF on VxRail Lifecycle Management Enhancements
Improved SDDC Manager LCM Prechecks
This release brings even more intelligence that is embedded into the SDDC Manager LCM precheck workflow. When performing an upgrade, the SDDC Manager needs to communicate to various components to complete various actions as well as requiring that certain system resources be configured correctly and are available.
To avoid any potential issues during LCM activities, VCF administrators can run SDDC Manager prechecks to weed any issues out before any LCM operation is executed. In this latest release SDDC Manager now adds six additional checks. These include:
- Password validity (including expired passwords)
- File system permissions
- File system capacity
- CPU reservation for NSX-T Managers
- Hosts in maintenance mode
- DRS configuration mode
All these checks apply to ESXi, vCenter, NSX-T, NSX-T Edge VMs, VxRail Manager, and vRealize Suite components in the VCF on VxRail environment. Figure 2 below illustrates some examples of what these prechecks look like from the SDDC Manager UI.
Figure 2 – New SDDC Manager Prechecks
Giving customers enhanced LCM improvements resolution: Check!
vRealize Suite Lifecycle Manager Flexible Upgrades
VCF 4.4 has been enhanced to allow vRealize suite products to be updated independently without having to upgrade the VCF SDDC stack.
Figure 3 – vRSLCM Flexible Upgrades
This means that from VCF 4.4 on, administrators will use vRSLCM to manage vRealize Suite update bundles and orchestrate and apply those upgrades to vRealize Suite products (vRealize Automation, vRealize Operations, vRealize Log Insight, Workspace ONE Access, and more) independently from the core VCF version upgrade to help better align with an organization’s business requirements. It also helps decouple VCF infrastructure team updates from DevOps team updates enabling teams to consume new vRealize features quickly. And finally, it enables an independent update cadence between VCF and vRealize versions which boosts and improves interoperability flexibility. And who doesn’t like flexibility? Am I right?
One last note with this enhancement: SDDC Manager will no longer be used to manage vRealize Suite component update bundles and orchestrate vRealize Suite component LCM updates. With this change, future versions of VCF will not include vRealize Suite components as part of its software components. vRSLCM will still be a part of VCF software components validated for compatibility for each VCF release since that will continue to be deployed and updated using SDDC Manager. As such, SDDC Manager continues to manage vRSLCM install and update bundles just as it has done up to this point.
Giving customers enhanced LCM flexibility resolution: Check!
VCF on VxRail Hardware Platform Enhancements
Support For New 15th Generation Intel-Based VxRail Dynamic Node Platforms
VxRail 7.0.320 includes support for the latest 15th Generation VxRail dynamic nodes for the E, P, and V series models. These can be used when deploying VMFS on FC Principal storage VxRail VI Workload Domain clusters. Figure 4 below highlights details for each model.
Figure 4 – New 15th Generation VxRail dynamic node models
Also, as it relates to using VxRail dynamic nodes when deploying VMFS on FC Principal storage, support for using NVMe over FC configurations has also been introduced since it is a part of the VxRail 7.0.320 release that VCF on VxRail customers can just inherit from VxRail. It’s like finding a fifth chicken nugget in the bag after ordering the four-piece meal! Wait, it is New Year’s—I should have used a healthier food example. Oops!
Support For New 15th Generation Intel-Based VxRail With vSAN Platforms (S670 and E660N)
In addition to new 15th generation dynamic nodes, this release introduces support for two new 15th generation VxRail node types, the S670 and E660N. The S670 is our 2U storage density optimized hybrid platform based on the PowerEdge R750 while the E660N is our 1U “everything” all NVMe platform based on the PowerEdge R650.
Giving customers more hardware platform choices resolution: Check!
VCF on VxRail Developer and AI-Ready Enterprise Platform Enhancements
NVIDIA GPU Options for AI and ML Workload Use Cases
As AI and ML applications are becoming more critical within organizations, IT teams are looking at the best approaches to run them within their own data centers to ensure ease of manageability and scale, improved security, and maintaining governance.
As a follow on to the innovative and collaborative partnerships between Dell Technologies, VMware, and NVIDIA that were first introduced at VMworld 2021, we are happy to announce, with this VCF on VxRail release, the ability to run GPUs within VMware Cloud Foundation 4.4 on VxRail 7.0.320 to deliver an end-to-end AI-Ready enterprise platform that is simple to deploy and operate.
Figure 5 – VCF with Tanzu on VxRail + NVIDIA AI-Ready Enterprise Platform
VMware Cloud Foundation with Tanzu, when used together with NVIDIA certified systems like VxRail and NVIDIA AI Enterprise Suite software, deliver an end-to-end AI / ML enterprise platform. And with VxRail being the first and only HCI Integrated System certified with NVIDIA AI Enterprise Suite and its supported GPUs, IT teams can deliver and provision GPU resources quickly in a variety of ways, while also allowing data scientists to easily consume and scale GPU resources quickly when they need it.
While getting into all the details on getting this set up is beyond the scope of this blog post, you can find more information on using NVIDIA GPUs with VxRail and NVIDIA AI Enterprise Software Suite using the link at the end of this post. VMware has additional information about this new support in a blog post that you can check out using the link at the bottom of this page.
Giving customers a simple path to unlock the power of their data resolution: Check!
VCF on VxRail Operations Enhancements
Configure DNS/NTP From SDDC Manager UI
This new feature simplifies and streamlines DNS and NTP Day 2 management operations for cloud administrators. In previous releases, all DNS and NTP configuration was included in the VCF Bring Up Parameter file that was used by Cloud Builder at the time of VCF on VxRail installation. But there was no straightforward way to make updates or changes to these settings once VCF on VxRail has been deployed. Now, if additional modifications are needed to these configurations, they can be performed within the SDDC Manager UI as a simple Day 2 operation. This feature integrates SDDC Manager with native VxRail APIs to automate VxRail cluster DNS/NTP settings. The figure below shows what this looks like.
Figure 6 – DNS/NTP Day 2 Configuration From SDDC Manager UI
Giving customers a simpler and more flexible day 2 operations experience resolution: Check!
VCF on VxRail Security Enhancements
Activity Logging For VCF REST API Call-Driven Actions
Administrators can now ensure audit tracking for activity that takes place using the VCF REST API. In this release, SDDC Manager logs capture SDDC Manager API activity from SDDC Manager UI and other sources with user context. This can be used to ensure audit tracking of VCF activity and making analyzing logs easier to understand. Figure 5 below illustrates this activity. The log entries include the following data points:
- Client IP
- User agent
- API called
- API method
Figure 7 – SDDC Manager REST API Activity Logging
Each of the SDDC Manager core services has a dedicated activity log. These logs are in the respective /var/log/vmware/vcf/*service*/ service directories on the SDDC Manager VM.
Giving customers enhanced security logging resolution – Check!
Enhanced Access Security Hardening
This release disables the SSH service on ESXi hosts by default, following the vSphere security configuration guide recommendation.
This applies to new and upgraded VMware Cloud Foundation 4.4 on VxRail 7.0.320 deployments.
Giving customers enhanced default platform security hardening resolution: Check!
Log4j and Apache HTTP Server Fixes
No security conversation is complete without addressing the headache that has been the talk of the technology world recently and that is the Log4j and Apache HTTP Server vulnerability discoveries. VCF on VxRail customers can be rest assured that as a part of this release fixes for these vulnerabilities are included.
Kicking Log4j and Apache HTTP bugs to the curb resolution: Check!
To wrap up…
Well, that about covers it for this new batch of updates. For the full list of new features, please refer to the release notes listed below. There are additional resource links at the bottom of this post. We hope to continue making good on our VCF on VxRail platform resolutions throughout the year! Hopefully, we all can say the same for ourselves in other areas of our lives. Now, where is that treadmill...?
Author: Jason Marques
Simpler Cloud Operations and Even More Deployment Options Please!
Tue, 23 Feb 2021 17:31:49 -0000|
Read Time: 0 minutes
The latest VMware Cloud Foundation on Dell EMC VxRail release debuts LCM and storage enhancements, support for transitioning from VCF Consolidated to VCF Standard Architecture, AMD-based VxRail hardware platforms, and more!
Dell Technologies and VMware are happy to announce the availability of VMware Cloud Foundation 4.2.0 on VxRail 7.0.131.
This release brings about support for the latest versions of VCF and Dell EMC VxRail that provide a simple and consistent operational experience for developer ready infrastructure across core, edge, and cloud. Let’s review these new updates and enhancements.
Some Important Updates:
VCF on VxRail Management Operations
Ability For Customers to Perform Their Own VxRail Cluster Expansion Operations in VCF on VxRail Workload Domains. Sometimes some of the best announcements that come with a new release have nothing to do with a new technical feature but instead are about new customer driven serviceability operations. The VCF on VxRail team is happy to announce this new serviceability enhancement. Customers no longer must purchase a professional services engagement simply to expand a single site layer 2 configured VxRail WLD cluster deployment by adding nodes to it. This should save time and money and give customers the freedom to perform these operations on their own.
This aligns to existing support that already exists for customers performing similar cluster expansion operations for VxRail systems deployed as standard clusters in non-VCF use cases.
Note: There are some restrictions on which cluster configurations support customer driven expansion serviceability. Stretched VxRail cluster deployments and layer 3 VxRail cluster configurations will still require engagement with professional services as these are more advanced deployment scenarios. Please reach out to your local Dell Technologies account team for a complete list of the cluster configurations that are supported for customer driven expansions.
VCF on VxRail Deployment and Services
Support for Transitioning From VCF on VxRail Consolidated Architecture to VCF on VxRail Standard Architecture. Continuing the operations improvements, the VCF on VxRail team is also happy to announce this new capability. We introduced support for VCF Consolidated Architecture deployments in VCF on VxRail back in May 2020. You can read about it here. VCF Consolidated Architecture deployments provide customers a way to familiarize themselves with VCF on VxRail in their core datacenters without a significant investment in cost and infrastructure footprint. Now, with support for transitioning from VCF Consolidated Architecture to VCF Standard Architecture, customers can expand as their scale demands it in their core, edge, or distributed datacenters! Now that’s flexible!
Please reach out to your local Dell Technologies account team for details on the transition engagement process requirements.
And Some Notable Enhancements:
VxRail Hardware Platform
AMD-based VxRail Platform Support in VCF 4.x Deployments. With the latest VxRail 7.0.131 HCI System Software release, ALL available AMD-based VxRail series models are now supported in VCF 4.x deployments. These models include VxRail E-Series and P-Series and support single socket 2nd Gen AMD EYPC™ processors with 8 to 64 cores, allowing for extremely high core densities per socket.
The figure below shows the latest VxRail HW platform family.
For more info on these AMD platforms, check out my colleague David Glynn’s blog post on the subject here when AMD platform support was first introduced to the VxRail family last year. (Note: New 2U P-Series options have been released since that post.)
VCF on VxRail Multi-Site Architecture
NSX-T 3.1 Federation Now Supported with VCF 4.2 on VxRail 7.0.131. NSX-T Federation provides a cloud-like operating model for network administrators by simplifying the consumption of networking and security constructs. NSX-T Federation includes centralized management, consistent networking and security policy configuration with enforcement and synchronized operational state across large scale federated NSX-T deployments. With NSX-T Federation, VCF on VxRail customers can leverage stretched networks and unified security policies across multi-region VCF on VxRail deployments, providing workload mobility and simplified disaster recovery. This initial support will be through prescriptive manual guidance that will be made available soon after VCF on VxRail solution general availability. For a detailed explanation of NSX-T Federation, check out this VMware blog post here.
The figure below depicts what the high-level architecture would look like.
VCF on VxRail Storage
VCF 4.2 on VxRail 7.0.131 Support for VMware HCI Mesh. VMware HCI Mesh is a vSAN feature that provides for “Disaggregated HCI” exclusively through software. In the context of VCF on VxRail, HCI Mesh allows an administrator to easily define a relationship between two or more vSAN clusters contained within a workload domain. It also allows a vSAN cluster to borrow capacity from other vSAN clusters, improving the agility and efficiency in an environment. This disaggregation allows the administrator to separate compute from storage. HCI Mesh uses vSAN’s native protocols for optimal efficiency and interoperability between vSAN clusters. HCI Mesh accomplishes this by using a client/server mode architecture. vCenter is used to configure the remote datastore on the client side. Various configuration options are possible that can allow for multiple clients to access the same datastore on a server. VMs can be created that utilize the storage capacity provided by the server. This can enable other common features, such as performing a vMotion of a VM from one vSAN cluster to another.
The figure below depicts this architecture.
VCF on VxRail Networking
This release continues to extend networking flexibility to further adapt to various customer environments and to reduce deployment efforts.
Customer-Defined IP Pools for NSX-T TEP IP Addresses for the Management Domain and Workload Domain Hosts. To extend networking flexibility, this release introduces NSX-T TEP IP Address Pools. This enhances the existing support for using DHCP to assign NSX-T TEP IPs. This new feature allows customers to avoid deploying and maintaining a separate DHCP server for this purpose. Admins can select to use IP Pools as part of VCF Bring Up by entering this information in the Cloud Builder template configuration file. The IP Pool will then be automatically configured during Bring Up by Cloud Builder. There is also a new option to choose DHCP or IP Pools during new workload domain deployments in the SDDC Manager.
The figure below illustrates what this looks like. Once domains are deployed, IP address blocks are managed through each domain’s NSX Manager respectively.
pNIC-Level Redundancy Configuration During VxRail First Run. Network flexible configurations are further extended with this feature in VxRail 7.0.131. It allows an administrator to configure the VxRail System VDS traffic across NDC and PCIe pNICs automatically during VxRail First Run using a new VxRail Custom NIC Profile option. Not only does this help provide additional high availability network configurations for VCF on VxRail domain clusters, it also helps to further simplify operations by removing the need for additional Day 2 activities in order to get to the same host configuration outcome.
Specify the VxRail Network Port Group Binding Mode During VxRail First Run. To further accelerate and simplify VCF on VxRail deployments, VxRail 7.0.131 has introduced this new enhancement designed with VCF in mind. VCF requires all host Port Group Binding Modes be set to Ephemeral. VxRail First Run now enables admins to have this parameter configured automatically, reducing the number of manual steps needed to prep VxRail hosts for VCF on VxRail use. Admins can set this parameter using the VxRail First Run JSON configuration file or manually enter it into the UI during deployment.
The figure below illustrates an example of what this looks like in the Dell EMC VxRail Deployment Wizard UI.
VCF on VxRail LCM
New SDDC Manager LCM Manifest Architecture. This new LCM Manifest architecture changes the way SDDC Manager handles the metadata required to enable upgrade operations as compared to the legacy architecture used up until this release.
With the legacy LCM Manifest architecture:
- The metadata used to determine upgrade sequencing and availability was published as part of the LCM bundle itself or was part of SDDC Manager VM.
- Did not allow for changes to the metadata after the bundle was published. This limited the ability for VMware to modify upgrade sequencing without requiring an upgrade to a new VCF release.
The newly updated LCM Manifest architecture helps address these challenges by enabling dynamic updates to LCM metadata, enabling future functionality such as recalling upgrade bundles or modifying skip level upgrade sequencing.
VCF Skip-Level Upgrades Using SDDC Manager UI and Public API. Keeping up with new releases can be challenging and scheduling maintenance windows to perform upgrades may not be as readily available for every customer. The goal behind this enhancement is to provide VCF on VxRail administrators the flexibility to reduce the number of stepwise upgrades needed in order to get to the latest SDDC Manager/VCF release if they are multiple versions behind. All required upgrade steps are now automated as a single SDDC Manager orchestrated LCM workflow and is built upon the new SDDC Manager LCM Manifest architecture. VCF skip level upgrades allow admins to quickly and directly adopt code versions of choice and to reduce maintenance window requirements.
Note: To take advantage of VCF skip level upgrades for future VCF releases, customers must be at a minimum of VCF 4.2.
The figure below shows what this option looks like in the SDDC Manager UI.
Improvements to Upgrade Resiliency Through VCF Password Prechecks. Other LCM enhancements in this release come in the area of password prechecks. When performing an upgrade, VCF needs to communicate to various components to complete various actions. Of course, to do this, the SDDC Manager needs to have valid credentials. If the passwords have expired or have been changed outside of VCF, the patching operation fails. To avoid any potential issues, VCF now checks to ensure that the credentials needed are valid prior to commencing the patching operation. These checks will occur both during the execution of the pre-check validation as well as during an upgrade of a resource, such as ESXi, NSX-T, vCenter, or VxRail Manager. Check out what this looks like in the figure below
Automated In-Place vRSLCM Upgrades. Upgrading vRSLCM in the past required the deployment of a net new vRSLCM appliance. With VCF 4.2, the SDDC Manager keeps the existing vRSLCM appliance, takes a snapshot of it, then transfers the upgrade packages directly to it and upgrades everything in place. This provides a more simplified and streamlined LCM experience.
VCF API Performance Enhancements. Administrators who use a programmatic approach will experience a quicker retrieval of information through the caching of certain information when executing API calls.
VCF on VxRail Security
Mitigate Man-In-The-Middle Attacks. Want to prevent Man-In-The-Middle Attacks on your VCF on VxRail cloud infrastructure? This release is for you. Introduced in VCF 4.2, customers can leverage SSH RSA fingerprint and SSL thumbprint enforcement capabilities that are natively built-into SDDC Manager in order to verify the authenticity of cloud infrastructure components (vCenter, ESXi, and VxRail Manager). Customers can choose to enable this feature for their VCF on VxRail deployment during VCF Bring Up by filling in the affiliated parameter fields in the Cloud Builder configuration file.
An SSH RSA Fingerprint comes from the host SSH public key while an SSL Thumbprint comes from the host’s certificates. One or more of these data points can be used to validate the authenticity of VCF on VxRail infrastructure components when being added and configured into the environment. For the Management Domain, both SSH fingerprints and SSL thumbprints are available to use while Workload Domains have SSH Fingerprints available. See what this looks like in the figure below.
Natively Integrated Dell Technologies Next Gen SSO Support With SDDC Manager. Dell Technologies Next Gen SSO is a newly implemented backend service used in authenticating with Dell Technologies support repositories where VxRail update bundles are published. With the native integration that SDDC Manager has with monitoring and downloading the latest supported VxRail upgrade bundles from this depot, SDDC Manager now utilizes this new SSO service for its authentication. While this is completely transparent to customers, existing VCF on VxRail customers may need to log SDDC Manager out of their current depot connection and re-authenticate with their existing credentials to ensure future VxRail updates are accessible by SDDC Manager.
New Advanced Security Add-on for VMware Cloud Foundation License SKUs: Though not necessarily affiliated with the VCF 4.2 on VxRail 7.0.131 BOM directly, new VMware security license SKUs for Cloud Foundation are now available for customers who want to bring their own VCF licenses to VCF on VxRail deployments.
The Advanced Security Add-on for VMware Cloud Foundation now includes advanced threat protection, and workload and endpoint security that provides the following capabilities:
- Carbon Black Workload Advanced: This includes Next Generation Anti-Virus, Workload Audit/Remediation, and Workload EDR.
- Advanced Threat Prevention Add-on for NSX Data Center – Coming in Advanced and Enterprise Plus editions, this includes NSX Firewall, NSX Distributed IDS/IPS, NSX Intelligence, and Advanced Threat Prevention
- NSX Advanced Load Balancer with Web Application Firewall
Updated VMware Cloud Foundation and VxRail BOM
VMware Cloud Foundation 4.2.0 on VxRail 7.0.131 introduces support for the latest versions of the SDDC and VxRail. For the complete list of component versions in the release, please refer to the VCF on VxRail release notes. A link is available at the end of this post.
Well, that about covers it for this release. The innovation continues with co-engineered features coming from all layers of the VCF on VxRail stack. This further illustrates the commitment that Dell Technologies and VMware have to drive simplified turnkey customer outcomes. Until next time, feel free to check out the links below to learn more about VCF on VxRail.
Twitter - @vwhippersnapper
- VMware Cloud Foundation on Dell EMC VxRail Release Notes
- VxRail page on DellTechnologies.com
- VxRail Videos
- VCF on VxRail Interactive Demos
- Blog: 2nd Gen AMD EPYC now available to power your favorite hyperconverged platform: VxRail
- Blog: The Dell Technologies Cloud Platform – Smaller in Size, Big on Features
- Blog: Introducing NSX-T Federation support in VMware Cloud Foundation