Third-party Analysis
A PowerEdge MX environment using OpenManage Enterprise and OpenManage Enterprise Modular can make life easier
Tue, 13 Feb 2024 04:28:44 -0000
|Read Time: 0 minutes
Compared to a Cisco UCS-X environment using Intersight, the Dell environment streamlined making changes to VLANs and helped avoid interventions during scheduled firmware updates
Decision makers who are equipping their data centers with new servers typically weigh many factors as they choose a platform. While performance and pricing are important, another less obvious consideration is how easy server life cycle management will be. The amount of time that IT staff must spend performing routine server management activities can vary greatly depending on the management tools at their disposal. The right tools can significantly streamline and simplify ongoing management tasks such as updating firmware and making changes to virtual local area networks (VLANs). Tools that automate these processes reduce the likelihood of error and save time, which can free administrators to pursue initiatives that add value to the business.
To explore the differences between the solutions, we configured two test environments: (1) a Dell™ PowerEdge™ MX environment using OpenManage™ Enterprise (OME) and the embedded OpenManage Enterprise Modular (OME-M) and (2) a Cisco® UCS® X-series environment using Intersight. We executed two management scenarios, recording the time and steps necessary to use the tools in each environment and noting any differences in approaches.
In the scenarios we tested, completing networking changes in a Dell PowerEdge MX platform required up to 33 percent fewer steps and up to 40 percent less time than carrying out the same tasks on a Cisco UCS platform. Additionally, administrators can schedule updates with the Dell PowerEdge MX platform in advance, which eliminates the need for them to intervene during overnight maintenance windows. These findings suggest that companies planning to upgrade their older Cisco UCS servers may want to consider instead shifting to Dell PowerEdge MX servers and enjoy time savings and these lower management costs.
* Dell PowerEdge MX environment using OpenManage Enterprise and OpenManage Enterprise Modular compared to a Cisco UCS-X environment using Intersight.
About our testing
We compared a Dell PowerEdge MX chassis environment with Dell OpenManage Enterprise and OpenManage Enterprise Modular against a Cisco UCS X-Series chassis environment with Cisco Intersight. We executed two management scenarios in the Dell PowerEdge MX760c environment and the Cisco environment:
- VLAN updates with a requirement for VLAN tagging after deployment
- Automated firmware updates with no administrator intervention required
Figure 1 shows our test environment. The management tools for the Dell PowerEdge MX environment, OME and OME-M, are located on premises. Intersight, the controller for the Cisco environment, resides in the cloud.
Our test environment. Source: Principled Technologies.
About the Dell PowerEdge MX server platform
Dell calls the PowerEdge MX a “modular, 7U integrated solution designed for enterprise data center density with easy deployment, management, and maximum longevity” and says its no-midplane design and scalable fabric architecture allow it to support new processor technologies and connectivity options.[i]
Learn more at https://www.dell.com/en-us/dt/servers/modular-infrastructure/poweredge-mx/index.htm#tab0=0&tab1=0&accordion0.
What we learned
Making VLAN changes
We looked at how much time and effort it took to make changes to the network with the addition of VLANs. For the Dell solution, we leveraged the Dell OpenManage Enterprise Modular console, and for the Cisco solution, we used Cisco Intersight.
We found that using OME-M for deploying changes through the fabric manager took 1 minute and
2 seconds less administrator time, and nine fewer steps, than deploying the same changes through Cisco Intersight (see Figures 2 and 3). Additionally, Cisco requires the (non-disruptive) deployment of the VLAN changes twice—once for the domain profile, and again for the individual blades in question. This yielded a 40.25 percent time savings when using the Dell PowerEdge MX chassis. (To see a list of steps we completed in each environment, see the science behind the report.) Carrying out fewer steps means fewer opportunities for error, and spending less time on routine tasks gives administrators more opportunities to innovate.
Hands-on administrative time (in minutes and seconds) necessary to make VLAN changes. Less time is better. Source: Principled Technologies.
Number of hands-on administrative steps necessary to make VLAN changes. Fewer steps are better. Source: Principled Technologies.
About Dell OpenManage Enterprise and OpenManage Enterprise Modular
OpenManage Enterprise is a one-to-many systems management console for the data center. The console offers a modern HTML5 graphical user interface and deploys as a virtual appliance for VMware ESXi™, Microsoft Hyper-V, and Kernel-based Virtual Machine (KVM) environments. OpenManage Enterprise can discover and inventory on IPV4 and IPV6 networks for up to 8,000 devices, including Dell rack servers, Dell tower servers, and Dell blades and chassis.[ii]
Learn more about OpenManage Enterprise at https://www.dell.com/en-us/lp/dt/open-manage-enterprise.
OpenManage Enterprise – Modular Edition is an embedded systems management solution for the Dell PowerEdge MX chassis. It delivers the primary abilities of OpenManage Enterprise within the server chassis and can manage servers across several PowerEdge MX chassis. A web/RESTful API interface manages all nodes, including compute and networking.[iii]
Learn more about OpenManage Enterprise – Modular Edition: https://www.dell.com/en-us/shop/ipovw/openmanage-modular.
Updating firmware
If you’re an IT administrator, you’ve probably accepted that working in the middle of the night on occasion comes with the territory. However, any management tools that allow you to avoid pulling all-nighters can make your work life much more comfortable.
When we explored the firmware updating process with the Dell solution, we found that we could schedule the update to take place either immediately or at some future date and time of our choosing, and we could select the method by which the reboot would occur. The options for scheduled updates are graceful reboot with forced shutdown, graceful reboot without forced shutdown, or a power cycle, which is a hard reset equivalent to pressing the power button once to shut the server down and a second time to power it back on.[iv] With any of these choices, administrators can schedule updates to occur within an overnight maintenance window, and they would not have to be present or take action unless a server failed to return to service for some reason.
With the Cisco solution, we submitted the firmware update job, and Intersight sent the files to the target servers we had selected. It then performed the update at the next reboot. We could toggle a switch at job submission to force an immediate reboot, but we could not find any timing mechanism specific to the update that would allow us to schedule it for a future time. This means that during an overnight maintenance window, an admin would have to be awake to reboot the servers so the server then applies the update. Also, if an administrator were to submit the package and someone were to reboot the server prior to the maintenance window, cluster members could be subject to inconsistencies.
To summarize the difference between the two environments, in the Dell environment, the updates could be a zero-touch task for admins most of the time; they would be present only in the event of a true incident, and not simply for scheduled maintenance. The Cisco environment, in contrast, requires admins to be present and fully participating every time they wish to update firmware.
To see a list of steps we completed in each environment, see the science behind the report.
Conclusion
We executed two management scenarios in a Dell PowerEdge MX environment with Dell OpenManage Enterprise and OpenManage Enterprise Modular and a Cisco UCS X-Series chassis environment with Cisco Intersight. We learned that the Dell solution’s single-part profile modification for performing VLAN updates was quicker and simpler than the Cisco solution’s two-part profile deployment, requiring 40 percent less time and two-thirds as many steps. We also compared the firmware updating process on the solutions. Being able to schedule these updates to occur automatically from the online Dell repository offered an advantage over having to manually execute the same tasks from the Cisco Intersight repositories. Namely, administrators do not need to take action during maintenance windows but can instead schedule them ahead of time. Saving time on routine tasks frees administrators to pursue innovation, and being able to avoid middle-of-the-night duties helps companies provide a better work experience for admins. Together, these advantages help make Dell PowerEdge MX servers a good candidate for companies considering upgrading the older Cisco UCS servers in their data centers.
This project was commissioned by Dell Technologies.
January 2024
Principled Technologies is a registered trademark of Principled Technologies, Inc.
All other product names are the trademarks of their respective owners.
Resources
[i] Dell, “PowerEdge MX,” accessed December 20, 2023, https://www.dell.com/en-us/dt/servers/modular-infrastructure/poweredge-mx/.
[ii] Dell, “OpenManage Enterprise,” accessed December 20, 2023, https://www.dell.com/en-us/work/learn/openmanage-enterprise.
[iii] Dell, “OpenManage Enterprise.”
[iv] A fourth option is to select to stage the updates for the next sever reboot, but this is not scheduled.
Streamline VMware Server Deployment and Configuration: Dell OpenManage Enterprise Integration for VMware VC
Wed, 21 Jun 2023 16:11:43 -0000
|Read Time: 0 minutes
In our hands-on tests, the OpenManage Enterprise with OMEVV solution took less time and fewer steps than VMware vSphere Auto Deploy for Stateful Installation of ESXi to a bare-metal server host
Expanding your organization’s data center with new servers typically means that admins must devote time to configuring and deploying them. Being able to harness tools that streamline and automate these processes reduces the burden on IT staff and gets the new gear into action sooner.
We compared the process of deploying and configuring ESXi on Dell™ servers in a VMware®-based PowerEdge™ environment using two tools: Dell OpenManage™ Enterprise Integration for VMware vCenter® (OMEVV) 1.1.0.1250 and VMware vSphere® Auto Deploy for Stateful Installation (VMware vSphere Auto Deploy).
We found that the administrative time for one-time setup and configuration was up to 93 percent less for OMEVV and that deploying bare-metal server hosts after the one-time setup and configuration was up to 74 percent less. OMEVV greatly streamlined these activities, reducing the number of required steps by as much as 83 percent for setup and configuration and by up to 34 percent for bare-metal host deployment.
By decreasing the amount of time and number of steps necessary to put new hosts into service, using OpenManage Enterprise Integration for VMware vCenter can free your admins to perform other activities.
How we approached testing
We set up three Dell PowerEdge servers to capture the amount of time and number of steps required to provision Dell servers with ESXi software in a vCenter environment using two different automatic deployment solutions:
- OpenManage Enterprise with OMEVV leveraging agent-free iDRAC
- vSphere Auto Deploy for Stateful Installation using PXE boot
We also explored the features the two solutions offer and noted several advantages that OpenManage Enterprise with OMEVV offers over vSphere Auto Deploy for Stateful Installation.
About the OpenManage Enterprise Integration for VMware vCenter
The latest release of OpenManage Enterprise Integration for VMware vCenter (OMEVV) utilizes OpenManage Enterprise data in the vCenter administration portal. The integration can improve vCenter monitoring and management in a VMware software-based PowerEdge environment by offering the following:1
- Hardware information and alerts pulled into vCenter with controls for notifications
- iDRAC address and service tag details
- Dell warranty information
- Deep-level detail on certified Dell hardware components, including memory and local drives
- Support for both vLCM and VMware Active HA
What we found: The numbers
In this section, we focus on the quantitative advantages of Dell OMEVV over VMware vSphere Auto Deploy for configuration and deployment: less time and fewer steps required to complete tasks.
One-time setup and configuration
In the first phase of testing, we investigated the time requirements and complexity of performing one-time setup and configuration with the two solutions. Before we dive into our detailed findings, let’s look at a high-level overview of what the two processes involve. As Figure 1 illustrates, the Dell OMEVV process consisted of only two phases. In contrast, the VMware vSphere Auto Deploy process consisted of six phases (see Figure 2).
Having more phases does not necessarily equate to requiring more time and steps, but in our testing, it did. As Figure 3 shows, using Dell OMEVV to perform one-time setup and configuration was indeed more streamlined than the process with VMware vSphere Auto Deploy, with the process taking fewer than one-sixth the number of steps. It required less admin time, requiring just over 2 minutes versus nearly half an hour.
Table 1 breaks down the time and steps for each of the two phases of the Dell OMEVV process. As it shows, both were quick for our technician to execute.
| Dell OMEVV | Time (min:sec) | Steps |
|---|---|---|
| Installing OMEVV | 1:19 | 11 |
| Creating ISO profile | 0:42 | 5 |
| Total one-time setup | 02:01 | 16 |
Table 2 breaks down the time and steps for each of the six phases of the VMware vSphere Auto Deploy process. While most of these took our technician a minute or less to execute, setting up and configuring the TFTP server and deploying the reference server took significantly longer.
| VMware vSphere Auto Deploy | Time (min:sec) | Steps |
|---|---|---|
| Enabling vCenter Auto Deploy | 0:40 | 3 |
| Creating Software Depot | 00:42 | 2 |
| Setting up and configuring TFTP server | 13:13 | 37 |
| Configuring DHCP options | 01:23 | 9 |
| Deploying reference server | 12:38 | 25 |
| Creating host profile from reference server | 00:55 | 21 |
| Total one-time setup | 29:31 | 97 |
Deploying hosts
In the second phase of our testing, we investigated the time requirements and complexity of deploying one, two, and three hosts using the two solutions. As we did earlier, let’s start with a high-level overview of what the two processes involve. As Figure 4 illustrates, the Dell OMEVV process of deploying a host consisted of three phases: discovering the servers in OME, discovering those hosts as bare-metal servers in OMEVV within vCenter, and creating a deployment job. In contrast, the VMware vSphere Auto Deploy process consisted of five phases (see Figure 5).
Time and steps to deploy a single host
As Figure 6 shows, using Dell OMEVV to deploy one host was more streamlined than performing the same task using VMware vSphere Auto Deploy, with the process taking fewer steps. Deployment with OMEVV took 2.5 minutes of admin time compared to more than 8 minutes of admin time for vSphere Auto Deploy.
Table 3 provides of breakdown of the time and steps each phase of the Dell OMEVV process required.
| Dell OMEVV | Time (min:sec) | Steps |
|---|---|---|
| Discovering servers in OME | 00:17 | 8 |
| Discovering bare-metal servers | 00:29 | 8 |
| Creating deployment job | 01:44 | 9 |
| Total | 02:30 | 25 |
In contrast to the Dell OMEVV process, the VMware vSphere Auto Deploy process was more complex, with five distinct phases. Four of these took our technician 45 seconds or less to execute, but booting the server through deployment took more than 6 minutes (see Table 4).
| VMware vSphere Auto Deploy | Time (min:sec) | Steps |
|---|---|---|
| Creating new rule | 00:45 | 8 |
| Activating rule | 00:12 | 6 |
| Booting server through deployment | 06:27 | 4 |
| Customizing host | 00:34 | 6 |
| Performing host remediation against profile | 00:08 | 6 |
| Total | 08:06 | 30 |
Time and steps to deploy two hosts
As Figure 7 shows, using Dell OMEVV to deploy two hosts took the same number of steps as deploying one with only 4 additional seconds. In contrast, the process with VMware vSphere Auto Deploy needed four additional steps and 53 additional seconds.
Table 5 provides of breakdown of the time and steps each phase of the Dell OMEVV process required.
| Dell OMEVV | Time (min:sec) | Steps |
|---|---|---|
| Discovering servers in OME | 00:17 | 8 |
| Discovering bare-metal servers | 00:29 | 8 |
| Creating deployment job | 01:48 | 9 |
| Total | 02:34 | 25 |
Table 6 breaks down the time and steps for each of the five phases of the VMware vSphere Auto Deploy process for deploying two hosts. Four of these took our technician 53 seconds or less to execute, but booting the server through deployment took almost 7 minutes.
| VMware vSphere Auto Deploy | Time (min:sec) | Steps |
|---|---|---|
| Creating new rule | 00:53 | 8 |
| Activating rule | 00:12 | 6 |
| Booting server through deployment | 06:59 | 8 |
| Customizing host | 00:47 | 6 |
| Performing host remediation against profile | 00:08 | 6 |
| Total | 08:59 | 34 |
Time and steps to deploy three hosts
As Figure 8 shows, using Dell OMEVV to deploy three hosts took the same number of steps as deploying a single host and only 6 additional seconds. In contrast, the process with VMware vSphere Auto Deploy required eight additional steps and an extra 2 minutes and 11 seconds.
Table 7 provides of breakdown of the time and steps each phase of the Dell OMEVV process required.
| Dell OMEVV | Time (min:sec) | Steps |
|---|---|---|
| Discovering servers in OME | 00:17 | 8 |
| Discovering bare-metal servers | 00:29 | 8 |
| Creating deployment job | 01:50 | 9 |
| Total | 02:36 | 25 |
With three hosts, four of the five phases of the VMware vSphere Auto Deploy process took our technician 1 minute and 19 seconds or less to execute. However, booting the server through deployment took 7 minutes and 40 seconds (see Table 8).
| VMware vSphere Auto Deploy | Time (min:sec) | Steps |
|---|---|---|
| Creating new rule | 00:58 | 8 |
| Activating rule | 00:12 | 6 |
| Booting server through deployment | 07:40 | 12 |
| Customizing host | 01:19 | 6 |
| Performing host remediation against profile | 00:08 | 6 |
| Total | 10:17 | 38 |
As our findings in this section show, the amount of time that administrators save by selecting the Dell solution increased as the number of deployed servers increased. Because the time savings as we added servers was not linear, we can’t reliably extrapolate the savings organizations would see with larger deployments. However, when deploying a large VMware vSphere ESXi cluster of 32 or more servers, the time savings would be even more substantial than what we have shown here.
What we found: The experience
In this section, we present some of the qualitative advantages of Dell OMEVV over VMware vSphere Auto Deploy for configuration and deployment.
Some advantages of Dell OMEVV
- Our team found OMEVV substantially easier to use than vSphere Auto Deploy and found that its documentation covers all of the use cases we tested.
- By reducing complexity, job deployment in OMEVV reduces the likelihood of error. Using vSphere Auto Deploy, it is possible to miss steps when navigating among Profiles, Auto Deploy, Rules, Inventory, and back to Profiles to remediate after the first deployment pass completes.
- OMEVV operates within a single GUI. The user stays within the OMEVV plugin area to complete tasks such as selecting target servers, creating an ISO profile, and creating a deployment job. To create a deployment job, the user stays in a single-pane Deployment Wizard, which functions as a guided tutorial (see Figure 9). In contrast, vSphere Auto Deploy requires the user to move among a variety of different screens and locations.
- Even if an existing OS is present on the server boot volume, OMEVV can perform an installation without intervention by leveraging the Lifecycle Controller; in contrast, using VMware guidance for setting PXE as the secondary boot method, reinstalling using vSphere Auto Deploy requires manual intervention to invoke the boot menu and users must manually select the PXE option for boot.
- OMEVV assigns static IPs before installation; vSphere Auto Deploy does this after installation. In a real-world setting, the vSphere Auto Deploy approach wastes time. Admins must wait, turning the install time into active administration time where the admin is unable to work on other tasks or jobs because another step is waiting for them at the end.
- OMEVV offers additional features beyond deployment that vSphere Auto Deploy does not (see the section "About the OpenManage Enterprise Integration for VMware vCenter"). Once you have added servers using OMEVV, they benefit from OME. For example, OME offers development of firmware setting and support for call-home service, detailed reports, and other plugins.
Some disadvantages of vSphere Auto Deploy
- vSphere Auto Deploy requires PXE boot, which has networking considerations that users must accommodate.
- vSphere Auto Deploy requires a TFTP server, which is a potential disadvantage because their lack of authentication and encryption makes these servers less secure and more prone to attacks.
- In vSphere Auto Deploy, users can only import or extract host profiles and cannot build them from scratch. This limitation means users must have a template server, which adds steps.
- In vSphere Auto Deploy, Server Initial Config is more specific, whereas in OMEVV Server Initial Config only ensures that defaults are enabled. It is possible to work with Dell so that servers come pre-configured and ready to go for OME/OMEVV on the day they arrive; the admin needs only to power them on, discover them in OME, and run a deployment job.
- To use rules that target specific servers in vSphere Auto Deploy, the user must know certain information about the servers ahead of time, such as IP addresses, serial numbers, or drive and driver types for targeted installation. OMEVV does not require this.
Conclusion
Deploying servers can be a time-consuming task but it doesn’t have to be. In a VMware-based Dell PowerEdge environment, we found that using Dell OpenManage Enterprise Integration for VMware vCenter to configure and deploy bare-metal server hosts greatly reduced the administrative burden in terms of time and complexity compared to using VMware vSphere Auto Deploy. In addition, by letting our technician perform these tasks in up to 74 percent less administrative time and with 34 percent fewer steps, Dell OMEVV is the clear winner in efficiency and complexity, all from a single console with the added benefit of introducing customers to the host of other OME features.
To streamline your deployment of new ESXi servers and optimize your administrator’s time, choose Dell OpenManage Enterprise Integration for VMware vCenter.
- Dell, “OpenManage Enterprise Integration for VMware vCenter,” accessed April 14, 2023, https://www.dell.com/support/kbdoc/000176981/openmanage-integration-for-vmware-vcenter.
- Principled Technologies, “Implement cluster-aware firmware updates to save time and effort,” accessed April 18, 2023, https://www.principledtechnologies.com/clients/reports/Dell/OpenManage-Integration-for-VMware-vCenter-1122.pdf.
This project was commissioned by Dell Technologies.