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:

1. Co-locate ObjectScale data services on the same clusters where user application workloads run
2. 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

Twitter: @vWhipperSnapper

Additional Resources

ObjectScale page on InfoHub

VxRail page on DellTechnologies.com

VxRail page on InfoHub

VCF on VxRail Interactive Demos

VxRail Videos

This latest Cloud Foundation (VCF) on VxRail release includes updated versions of software BOM components, a bunch of new VxRail platform enhancements, and some good ol’ under-the-hood improvements that lay the groundwork for future features designed to deliver an even better customer experience. Read on for the highlights…

VCF on VxRail operations and serviceability enhancements

View Nvidia GPU hardware details in VxRail Manager vCenter plugin ‘Physical View’ and VxRail API

Leveraging the power of GPU acceleration with VCF on VxRail delivers a lot of value to organizations looking to harness the power of their data. VCF on VxRail makes operationalizing infrastructure with Nvidia GPUs easier with native GPU visualization and details using the VxRail Manager vCenter Plugin ‘Physical View’ and VxRail API. Administrators can quickly gain deeper-level hardware insights into the health and details of the Nvidia GPUs running on their VxRail nodes, to easily map the hardware layer to the virtual layer, and to help improve infrastructure management and serviceability operations.

Figure 1 shows what this looks like.

Figure 1.  Nvidia GPU visualization and details – VxRail vCenter Plugin ‘Physical View’ UI

Support for the capturing, displaying, and proactive Dell dial home alerting for new VxRail iDRAC system events and alarms

Introduced in VxRail 7.0.450 and available in VCF 4.5.1 on VxRail 7.0.450 are enhancements to VxRail Manager intelligent system health monitoring of iDRAC critical and warning system events. With this new feature, new iDRAC warning and critical system events are captured, and through VxRail Manager integration with both iDRAC and vCenter, alarms are triggered and posted in vCenter.

Customers can view these events and alarms in the native vCenter UI and the VxRail Manager vCenter Plugin Physical View which contains KB article links in the event description to provide added details and guidance on remediation. These new events also trigger call home actions to inform Dell support about the incident.

These improvements are designed to improve the serviceability and support experience for customers of VCF on VxRail. Figures 2 and 3 show these events as they appear in the vCenter UI ‘All Issues’ view and the VxRail Manager vCenter Plugin Physical View UI, respectively.

Figure 2.  New iDRAC events displayed in the vCenter UI ‘All Issues’ view

Figure 3.  New iDRAC events displayed in the VxRail Manager vCenter Plugin UI ‘Physical View’

Support for the capturing, displaying, and proactive dial home alerting for new iDRAC NIC port down events and alarms

To further improve system serviceability and simplify operations, VxRail 7.0.450 introduces the capturing of new iDRAC system events related to host NIC port link status. These include NIC port down warning events, each of which is indicated by a NIC100 event code and a ‘NIC port is started/up’ info event.

A NIC100 event indicates either that a network cable is not connected, or that the network device is not working.

A NIC101 event indicates that the transition from a network link ‘down’ state to a network link ‘started’ or ‘up’ state has been detected on the corresponding NIC port.

VxRail Manager now creates new VxM events that track these NIC port states.

As a result, users can be alerted through an alarm in vCenter when a NIC port is down. VxRail Manager will also generate a dial-home event when a NIC port is down. When the condition is no longer present, VxRail Manager will automatically clear the alarm by generating a clear-alarm event.

Finally, to reduce the number of false positive events and prevent unnecessary alarm and dial home events, VxRail Manager implements an intelligent throttling mechanism to handle situations in which false positive alarms related to network maintenance activities could occur. This makes the alarms/events that are triggered more credible for an admin to act against.

Table 1 contains a summary of the details of these two events and the VxRail Manager serviceability behavior.

Table 1.  iDRAC NIC port down and started event and behavior details

Let’s double click on this serviceability behavior in a bit more detail.

Figure 4 depicts the behavior process flow VxRail Manager takes when iDRAC discovers and triggers a NIC port down system event. Let’s walk through the details now:

1.  The first thing that occurs is that iDRAC discovers that the NIC port state has gone down and triggers a NIC port down event.

2.  Next, iDRAC will send that event to VxRail Manager.

3.  At this stage VxRail Manager will validate how long the NIC port down event has been active and check whether a NIC port started (or up) event has been triggered within a 30-minute time frame since the original NIC port down event occurred. With this check, if there has not been a NIC port started event triggered, VxRail Manager will begin throttling NIC port down event communication in order to prevent duplicate alerts about the same event.

If during the 30-minute window, a NIC port started event has been detected, VxRail Manager will cease throttling and clear the event.

4. When the VxRail Manager event throttling state is active, VxRail Manager will log it in its event history.

5. VxRail Manager will then trigger a vCenter alarm and post the event to vCenter.

6.  Finally, VxRail Manager will trigger a NIC port down dial home event communication to backend Dell Support Systems, if connected.

  Figure 4.  Processing VxRail NIC port down events, and VxRail Manager throttling logic

Figure 5 shows what this looks like in the vCenter UI.

  Figure 5.  VxRail NIC port down trigger alarm in vCenter UI

Figure 6 shows what this looks like in the VxRail Manager vCenter Plugin ‘Physical View’ UI.

 Figure 6.  VxRail Manager vCenter Plugin ‘Physical View’ UI view of a VxRail NIC port down event

VCF on VxRail storage updates

Support for new PowerMax 2500 and 8500 storage arrays with VxRail 14G and 15G dynamic nodes using VMFS on FC principal storage

Starting in VCF 4.5.1 on VxRail 7.0.450, support has been added for the latest next gen Dell PowerMax 2500 and 8500 storage systems as VMFS on FC principal storage when deployed with 14G and 15G VxRail dynamic node clusters in VI workload domains.

Figure 7 lists the Dell storage arrays that support VxRail dynamic node clusters using VMFS on FC principal storage for VCF on VxRail, along with the corresponding supported FC HBA makes and models.

Note: Compatible supported array firmware and software versions are published in the Dell E-Lab Support Matrix for reference.

  Figure 7.  Supported Dell storage arrays used as VMFS on FC principal storage

VCF on VxRail lifecycle management enhancements

VCF Async Patch Tool 1.0.1.1 update

This tool addresses both LCM and security areas. Although it is not officially a feature of any specific VCF on VxRail release, it does get released asynchronously (pun intended) and is designed for use in VCF and VCF on VxRail environments. Thus, it deserves a call out.

For some background, the VCF Async Patch Tool is a new CLI based tool that allows cloud admins to apply individual component out-of-band security patches to their VCF on VxRail environment, separately from an official VCF LCM update release. This enables organizations to address security vulnerabilities faster without having to wait for a full VCF release update. It also allows admins to install these patches themselves without needing to engage support resources to get them applied manually.

With this latest AP Tool 1.0.1.1 release, the AP Tool now supports the ability to use patch VxRail (which includes all of the components in a VxRail update bundle including VxRail Manager and ESXi software components, and VxRail HW firmware/drivers) within VCF on VxRail environments. This is a great addition to the tool’s initial support for patching vCenter and NSX Manager in its first release. VCF on VxRail customers now have a centralized and standardized process for applying security patches for core VCF and VxRail software and core VxRail HCI stack hardware components (such as server BIOS or pNIC firmware/driver for example), all in a simple and integrated manner that VCF on VxRail customers have come to expect from a jointly engineered integrated turnkey hybrid cloud platform.

Note: Hardware patching is made possible due to how VxRail implements HW updates with the core VxRail update bundle. All VxRail patches for VxRail Manager, ESXi, and HW components are delivered in a the VxRail update bundle and leveraged by the AP Tool to apply.

From an operational standpoint, when patches for the respective software and hardware components have been applied, and a new VCF on VxRail BOM update is available that includes the security fixes, admins can use the tool to download the latest VCF on VxRail LCM release bundles and upgrade their environment back to an official in-band VCF on VxRail release BOM. After that, admins can continue to use the native SDDC Manager LCM workflow process for applying additional VCF on VxRail upgrades. Figure 8 highlights this process at a high level.

  Figure 8.  Async Patch Tool overview                                                  

You can access VCF Async Patch Tool instructions and documentation from VMware’s website.

Summary

In this latest release, the new features and platform improvements help set the stage for even more innovation in the future. For more details about bug fixes in this release, see VMware Cloud Foundation on Dell VxRail Release Notes. For this and other Cloud Foundation on VxRail information, see the following additional resources.

Author: Jason Marques

Twitter: @vWhipperSnapper

Additional Resources

• VMware Cloud Foundation on Dell VxRail Release Notes
• VxRail page on DellTechnologies.com
• VxRail Info Hub
• VCF on VxRail Interactive Demo
• Videos