
Dell EMC PowerFlex and VMware Cloud Foundation for High Performance Applications
Mon, 17 Aug 2020 21:39:26 -0000
|Read Time: 0 minutes
The world in 2020 has shown all industries that innovation is necessary to thrive in all conditions. VMware Cloud Foundation (VCF) hybrid cloud platform was crafted by innovators who realize the biggest asset our customers have is their information technology and the data that runs the business. The VCF offering takes the complexity out of operationalizing infrastructure to enable greater elasticity, growth, and simplification through improved automation. VCF enables options available using on-premises and multi-cloud deployments to address ever changing enterprise needs.
VMware included design factors that anticipated customers’ use of varying storage options in the flexibility of implementing VCF. VMware vSAN is the standard for VCF hyperconverged infrastructure (HCI) deployments and is directly integrated into vSphere and VCF. For those circumstances where workloads or customer resource usage require alternative storage methods, VMware built flexibility into the VCF storage offering. Just as we see a wide variety in desktop computing devices, one size doesn't fit all applies to the enterprise storage products as well. Dell Technologies’ PowerFlex (formerly VxFlex) provides a software-defined mechanism to add a combination of compute and storage with scale out flexibility. As customers look to software-defined operational constructs for agility, PowerFlex provides an adjustable means to add the right balance of storage resources while enabling non-disruptive additions without painful migrations as demands increase.
Joining the Dell Technologies Cloud family as a validated design, Dell EMC PowerFlex helps customers simplify their path to hybrid cloud by combining the power of Dell EMC infrastructure with VMware Cloud Foundation software as supplemental storage. As a high-performance, scale out, software-defined block storage product, PowerFlex provides a combination of storage and compute in a unified fabric that's well equipped to service particularly challenging workloads. The scalability of compute and/or storage in a modular architecture provides an asymmetrical (2-layer) option to add capacity to either compute or storage independently. PowerFlex makes it possible to transform from a traditional three-tier architecture to a modern data center without any trade-offs between performance, resilience or future expansion.
PowerFlex significantly reduces operational and infrastructure complexity, empowering organizations to move faster by delivering flexibility, elasticity, and simplicity with predictable performance and resiliency at scale for deployments. PowerFlex Manager is a key element of our engineered systems providing a full lifecycle administration experience for PowerFlex from day 0 through expansions and upgrades which is independent, but complementary to the full stack life cycle management available through VCF via SDDC Manager. A cornerstone value proposition of VCF is administering the lifecycle management of OS upgrades, vSphere updates, vRealize monitoring, automation and NSX administration. PowerFlex manager works in parallel with VCF to deliver a comprehensive lifecycle experience for the physical ingredients and for the PowerFlex software-define storage layer. PowerFlex also offers a vRealize Operations plug-in for a unified monitoring capability from VMware vRealize Suite which is included in most VCF editions. From a storage management perspective, PowerFlex utilizes a management system that complements VCF and VMware vSphere by working within the appropriate vCenter management constructs. PowerFlex Manager provides the administration of PowerFlex storage functions, while VCF and vCenter manages the allocation of LUNs to provisioned VMFS file systems to provide data stores for the provisioned workloads.
PowerFlex systems enables customers to scale from a small environment to enterprise scale with over a thousand nodes. In addition, it provides enterprise grade data protection, multi-tenant capabilities, and add-on enterprise features such as QoS, thin provisioning, compression and snapshots. PowerFlex systems deliver the performance and time-to-value required to meet the demands of the modern enterprise data center.
Does Supplemental Storage Mean Slow or Light Workload Use Cases?
PowerFlex provides a Dell Technologies validated design as a supplemental storage platform for VCF, unlocking the value of PowerFlex to be realized by customers within the VCF environment. By providing sub-millisecond latency, high IOPS and high throughput with linearity as nodes join the fabric, the result is a very predictable scaling profile that accelerates the VCF vision within the datacenter.
PowerFlex, as a part of VCF, can help solve for even the most demanding of applications. Using the supplemental capabilities to service workloads with the highest of efficiency provides a best of class performance experience. Some illustrative examples of demanding application workloads validated with PowerFlex, independent of VCF, include the following:
SAP HANA
SAP HANA certified for PowerFlex integrated rack in both 4-socket and 2-socket offerings (certification details). Highly efficient in hosting up to six production HANA instances per 4-socket server. Our capabilities outperform external competitors by hosting 2x the capacity. The Configuration and Deployment Best Practices for SAP HANA white paper provides details. While this white paper illustrates a single layer architecture, even better performance characteristics are achievable using the VCF aligned 2-layer architectural implementation of PowerFlex.
Oracle RAC & Microsoft SQL
Flexibility to run compute and storage on separate hardware results in significant reduction of database licensing cost.
- Oracle RAC Solution (white paper) – Get over 1 Million IOPs with less than 1ms latency with Oracle 12c RAC database transactions in just six nodes delivering 33GB/sec throughput (5.6GB/sec per node).
- Oracle 19c RAC TPC-C achieving more than 10 Million TPMs in eight nodes (white paper).
- MS SQL 2019 Solution (white paper) or MS SQL 2019 Big Data Cluster with Kubernetes (white paper) delivering approximately 9 Million SQL Server transactions (TPMs) with less than 1ms latency using just five storage nodes.
SAS Analytics
Validated/certified by SAS for running SAS mixed analytics workloads (white paper) providing an average throughput of 210 MBs per core (40% greater than their recommended 150 MB/sec needed for certification).
Elastic Stack
The validated solution (white paper) with Elastic provides customers with the required high-performance, scalable, block-based IO with flexible deployment options in multiple operating environments (Windows, Linux, Virtualized/Bare Metal). Elastic validated the efficiency of PowerFlex using only three compute and 4 storage nodes to deliver ~1 billion indexing events measured by Elastic’s Rally benchmarking tool.
EPIC
The validated PowerFlex solution for Epic delivers 6x9’s availability and high performance for critical the EPIC hyperspace workloads while simultaneously enabling hosting the VDI with the operational and analytical databases for a completely integrated infrastructure option.
Cassandra
For customers deploying Kubernetes container-based database deployments like Cassandra, PowerFlex provides 300,000 operations/second for 10 million operations (Read intensive operations) with avg read latency of 1ms on just eight nodes.
PowerFlex gives Dell Technologies the ability to help customers address diverse infrastructure needs. For more information on all of the Dell Technologies storage options with Cloud Validated Designs for VMware Cloud Foundation, please view our white paper. The implementation guide for using PowerFlex for supplemental storage provides the simple steps to provide complementary storage options for VCF deployments. For more information on the PowerFlex product family and workload solutions, please see the product page here. The PowerFlex White Paper - Technical Overview also provides a comprehensive perspective how organizations can begin changing the way they think about a modern data center architecture. Please contact your local Dell sales representative for more information.
Other pre-tested Dell Technologies Storage products validated for VMware Cloud Foundation that provide the capabilities to independently scale storage and compute include the offerings below. You can find more details in the Dell Technologies Cloud Validated Designs document.
Related Blog Posts

Introducing NVMe over TCP (NVMe/TCP) in PowerFlex 4.0
Fri, 26 Aug 2022 18:59:38 -0000
|Read Time: 0 minutes
Anyone who has used or managed PowerFlex knows that an environment is built from three lightweight software components: the MDM, the SDS, and the SDC. To deploy a PowerFlex environment, the typical steps are:
- Deploy an MDM management cluster
- Create a cluster of storage servers by installing and configuring the SDS software component
- Add Protection Domains and Storage Pools
- Install the SDC onto client systems
- Provision volumes and away you go!!*
*No requirement for multipath software, this is all handled by the SDC/SDS
There have been additions to this over the years, such as an SDR component for replication and the configuration of NVDIMM devices to create finegranularity storage pools that provide compression. Also added are PowerFlex rack and appliance environments. This is all automated with PowerFlex Manager. Fundamentally, the process involves the basic steps outlined above.
So, the question is why would we want to change anything from an elegant solution that is so simple?
This is due to where the SDC component ‘lives’ in the operating system or hypervisor hosting the application layer. Referring to the diagram below, it shows that the SDC must be installed in the kernel of the operating system or hypervisor, meaning that the SDC and the kernel must be compatible. Also the SDC component must be installed and maintained, it does not just ‘exist’.
In most cases, this is fine and there are no issues whatsoever. The PowerFlex development team keeps the SDC current with all the major operating system versions and customers are happy to update the SDC within their environment when new versions become available.
There are, however, certain cases where manual deployment and management of the SDC causes significant overhead. There are also some edge use cases where there is no SDC available for specific operating systems. This is why the PowerFlex team has investigated alternatives.
In recent years, the use of Non-Volatile Memory Express (NVMe) has become pervasive within the storage industry. It is seen as the natural replacement to SCSI, due to its simplified command structure and its ability to provide multiple queues to devices, aligning perfectly with modern multi-core processors to provide very high performance.
NVMe appeared initially as a connection directly to disks within a server over a PCIe connection, progressing to being used over a variety of fabric interconnects.
Added to this is the widespread support for NVMe/TCP across numerous operating system and hypervisor vendors. Most include support natively in their kernels.
There have been several announcements by Dell Technologies over the past months highlighting NVMe/TCP as an alternative interconnect to iSCSI across several of the storage platforms within the portfolio. It is therefore a natural progression for PowerFlex to also provide support for NVMe/TCP, particularly because it already uses a TCP-based interconnect.
PowerFlex implements support for NVMe/TCP with the introduction of a new component installed in the storage layer called the SDT.
The SDT is installed at the storage layer. The NVMe initiator in the operating system or hypervisor communicates with the SDT, which then communicates with the SDS. The NVMe initiator is part of the kernel of the operating system or hypervisor.
Of course, because PowerFlex is so ‘flexible,’ both connection methods (SDC and NVMe/TCP) are supported at the same time. The only limitation is that a volume can only be presented using one protocol or the other.
For the initial PowerFlex 4.0 release, the VMware ESXi hypervisor is supported. This support starts with ESXi 7.0 U3f. Support for Linux TCP initiators is currently in “tech preview” as the initiators continue to grow and mature, allowing for all failure cases to be accounted for.
NVMe/TCP is a very powerful solution for the workloads that take advantage of it. If you are interested in discovering more about how PowerFlex can enhance your datacenter, reach out to your Dell representative.
Authors:
Kevin M Jones, PowerFlex Engineering Technologist.
Tony Foster, Senior Principal Technical Marketing Engineer.
Twitter: @wonder_nerd
LinkedIn

Running Dell ObjectScale on VMware vSphere with Tanzu
Fri, 17 Jun 2022 18:24:53 -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
Twitter: @vWhipperSnapper
Additional Resources
VxRail page on DellTechnologies.com