Announcing all-new VxRail Management Pack for vRealize Operations
Mon, 30 Mar 2020 15:14:28 -0000|
Read Time: 0 minutes
Now adding VxRail awareness to your vRealize Operations
January 22, 2020
As the new year rolls in, VxRail team is now slowly warming up to it. Right as we settle back in after holiday festivities, we’re onto another release announcement. This time, it’s an entirely new software tool: VxRail Management Pack for vRealize Operations.
For those not familiar with what vRealize Operations, it’s VMware’s operations management software tool that provides its customers the ability to maintain and tune their virtual application infrastructure with the aid of artificial intelligence and machine learning. It connects to the vCenter Server and collects metrics, events, configurations, and logs about the vSAN clusters and virtual workloads running on them. vRealize Operations also understands the topology and object relationships of the virtual application infrastructure. With all these features, it is capable of driving intelligent remediation, ensuring configuration compliance, monitoring capacity and cost optimization, and maintaining performance optimization. It’s an outcome-based tool designed to self-drive according to user-defined intents powered by its AI/ML engine.
The VxRail Management Pack is an additional free-of-charge software pack that can be installed onto vRealize Operations to provide VxRail cluster awareness. Without this Management Pack, vRealize Operations can still detect vSAN clusters but cannot discern that they are VxRail clusters. The Management Pack consists of an adapter that collects 65 distinct VxRail events, analytics logic specific to VxRail, and three custom dashboards. These VxRail events are translated into VxRail alerts on vRealize Operations so that users have helpful information to understand health issues along with recommended course of resolution. With custom dashboards, users can easily go to VxRail-specific views to troubleshoot issues and make use of existing vRealize Operations capabilities in the context of VxRail clusters.
The VxRail Management Pack is not for every VxRail user because it requires a vRealize Operations Advanced or Enterprise license. For enterprise customers or customers who have already invested in VMware’s vRealize Operations suite, it can be an easy add-on to help manage your VxRail clusters.
To download the VxRail Management Pack, go to VMware Solution Exchange: https://marketplace.vmware.com/vsx/.
Author: Daniel Chiu, Dell EMC VxRail Technical Marketing
Related Blog Posts
Introducing VxRail 7.0.000 with vSphere 7.0 support
Tue, 28 Apr 2020 13:23:14 -0000|
Read Time: 0 minutes
The VxRail team may all be sheltering at our own homes nowadays, but that doesn’t mean we’re just binging on Netflix and Disney Plus content. We have been hard at work to deliver on our continuing commitment to provide our customers a supporting VxRail software bundle within 30 days of any vSphere release. And this time it’s for the highly touted vSphere 7.0! You can find more information about vSphere and vSAN 7.0 in the vSphere and vSAN product areas in VMware Virtual Blocks blogs.
Here’s what you need to know about VxRail 7.0.000:
- VxRail 7.x train – You may have noticed we’ve jumped from a 4.7 release train to a 7.0 release train. What did you miss?? Well... there is no secret 5.x or 6.x release trains. We have made the decision to align with the vSAN versions, starting with VxRail 7.x. This will make it easier for you to map VxRail versions to vSAN versions.
- Accelerate innovation – The primary focus of this VxRail release is our synchronous release commitment to the vSphere 7.0 release. This release provides our users the opportunity to run vSphere 7.0 on their clusters. The most likely use cases would be for users who are planning to transition production infrastructure to vSphere 7.0 but first want to evaluate it in a test environment, or for users who are keen on running the latest VMware software.
- Operational freedom – You may have heard that vSphere 7.0 introduces an enhanced version of vSphere Update Manager that they call vSphere LCM, or vLCM for short. While vLCM definitely improves upon the automation and orchestration of updating an HCI stack, VxRail’s LCM still has the advantage over vLCM (check out my blog to learn more). For example, VMware is currently not recommending that vSAN Ready Nodes users upgrade to vSphere 7.0 because of drivers forward compatibility issues (you can read more about in this KB article). That doesn’t stop VxRail from allowing you to upgrade your clusters to vSphere 7.0. The extensive research, testing, and validation work that goes into delivering Continuously Validated States for VxRail mitigates that issue.
- Networking flexibility – Aside from synchronous release, the most notable new feature/capability is that VxRail consolidates the switch configuration for VxRail system traffic and NSX-T traffic. You can now run your VM traffic managed by NSX-T Manager on the same two ports used for VxRail system traffic (such as VxRail Management, vSAN, and vMotion) on the Network Daughter Card (NDC). Instead of requiring a 4-port NDC, users can use a 2-port NDC.
Consolidated switch configuration for VxRail system traffic managed by VxRail Manager/vCenter and VM traffic by NSX-T Manager
All said, VxRail 7.0.000 is a critical release that further exemplifies our alignment with VMware’s strategy and why VxRail is the platform of choice for vSAN technology and VMware’s Software-Defined Data Center solutions.
Our commitment to synchronous release for any vSphere release is important for users who want to benefit from the latest VMware innovations or for users who prioritizes a secure platform over everything else. A case in point is the vCenter express patch that rolled out a couple weeks ago to address a critical security vulnerability (you can find out more here). Within eight days of the express patch release, the VxRail team was able to run through all its testing and validation against all supported configurations to deliver a supported software bundle. Our $60M testing lab investment and 100+ team members dedicated to testing and quality assurance make that possible.
If you’re interested in upgrading your clusters to VxRail 7.0.000, please be sure to read the Release Notes.
Daniel Chiu, VxRail Technical Marketing
The Effect of Memory Speed on VDI User Density
Fri, 03 Apr 2020 14:52:54 -0000|
Read Time: 0 minutes
The Effect of Memory Speed on VDI User Density
In most modern-day virtual desktop infrastructure (VDI) deployments, RAM (often referred to as memory) is not a bottleneck. More often, it is the processor that gets saturated before memory and storage does. However, it is not recommended to overcommit memory capacity for VDI deployments. It is important that there is a balance between the memory required by virtual machines and host physical memory. Low memory allocation can cause increased storage I/O due to excessive paging. Conversely, if RAM allocation is too high, it affects storage capacity negatively due to the increased size of page files, virtual machine swap files and suspend files.
Memory speed or speed of the memory bus is one of the other attributes of RAM, apart from memory capacity, that may affect the performance of your VDI system. The Dell EMC Ready Solutions for the VDI team recently completed some performance analysis work to check the impact of memory speeds on the ‘density optimized’ configuration offered as a part of Solutions for VDI. The density optimized configuration is based on Intel Xeon Scalable 2nd generation processors code-named Cascade Lake. In this blog, we will discuss the details of this performance analysis work to understand the effects of memory speed on VDI system performance.
The VDI Engineering team performed tests with Login VSI, an industry standard tool for benchmarking VDI workloads. The tests were done using Login VSI Knowledge Workload running on VMs configured with 2 vCPUs and 4 GB of RAM with that 4 GB of RAM all being reserved memory.
The testbed environment was a 3-node cluster of VxRail V570F appliances that was optimized for VDI workloads. The cluster was configured and tested with 768 GB of memory per node with a speed of 2666 MHz for test1 and a speed of 2933 MHz for test2. The Environment configuration used was:
- PowerEdge R740xd servers
- Intel Xeon Gold 6248, 2 x 20-core, 2.5 GHz processors
- 768 GB memory (24 x 32 GB @ 2666 MHz) (2 DIMMS per channel (DPC) for test1)
- 768 GB memory (12 x 64 GB @ 2933 MHz) (1 DIMM per channel (DPC) for test2)
- vSAN hybrid data store using an SSD caching tier
- VMware ESXi 6.7 hypervisor
- VMware Horizon 7.7 VDI software layer
The compute workload virtual machines were Windows 10, 64-bit, version 1803. One of the VxRail cluster nodes hosted both management and compute virtual machines. The other two nodes were dedicated to workload compute. Figure 1 shows the main components involved in this work.
Figure 1 Dell EMC VxRail Solutions for VDI Stack Components
Now let’s check the Login VSI results from the tests done with memory speeds of 2666 MHz and 2933 MHz. Figure 2 shows the comparison graphs of the Login VSI Index Average values (the average response time for the system). From the graphs, we can see that the difference in response times from the two tests was marginal while sessions were loaded. We can ignore these marginal differences when doing a Login VSI test that is based on random workloads. While reaching a CPU utilization threshold of approximately 85%, active session count was 480 from both tests, implying that memory speed doesn’t affect user densities significantly in a VxRail density optimized configuration based on Intel Xeon Scalable Gold 6248 processors.
Note that the Dell EMC Ready Solutions for VDI team considers 85% of CPU utilization as a threshold because testing and loading the system beyond this value might have a negative impact on the performance and end-user experience. So, in these tests, the system was not stressed to the point of reaching a Login VSIMax. VSIMax shows the number of sessions that can be active on a system before the system is saturated.
Figure 2 Login VSI response time comparison with different memory speeds 2666 MHz vs. 2933 MHz
Login VSI test results metrics are summarized in Table 1 below.
Table 1 Login VSI Test Summary
Figure 3 shows the comparison of processor utilization in tests done with memory speeds of 2666 MHz and 2933 MHz. As shown in the figure, we couldn’t see a notable difference in the processor utilization in these tests. CPU utilization steadily increased during the login phase in both tests. The test with 2933 MHz showed a comparatively lower utilization, however, the difference was marginal. The difference in steady-state average CPU utilization was around 4% in these tests.
Figure 3 Comparison of CPU utilization with 2666 MHz and 2933 MHz memory speed
To summarize, our tests showed that in a VDI system based on the Dell EMC VxRail Density Optimized configuration powered by Intel Xeon Scalable Gold 6248 processors, an increase in memory speed did not improve the overall performance of the selected application workload significantly. It was also evident from our testing that memory was never a bottleneck during the testing. We did not test with other processor models. The results might vary when tested with other models.
In the next blog, we’ll discuss the effect of different Microsoft Windows operating systems versions on VDI user density. So, stay tuned!