Performance Study on PMEM in vSphere

Persistent Memory (PMEM) is modern technology that provides us with a new storage tier that will be beneficial for Enterprise Applications that need reduced latency and flexible data access. Examples are (in-memory) database platforms for log acceleration by caching, data writes and reduced recovery times. High Performance Computing (HPC) workloads can also greatly benefit from PMEM for example using it for in-memory check-pointing.

PMEM converges memory and storage. We now have the possibility to store data at unprecedented speed as PMEM its average latency is less than 0.5 microseconds. PMEM is persistent, like storage. That means that it holds its content through power cycles. The beauty of PMEM is that it has characteristics like typical DDR memory; It is byte-addressable allowing for random access to data. Applications can access PMEM directly for load and store instructions without the need to communicate with the storage stack.

 
vPMEMDisk: vSphere presents PMEM as a regular disk attached to the VM. No guest OS or application change is needed to leverage this mode. For example, legacy applications on legacy OSes can utilize this mode.  Note that vPMEMDisk configuration is available only in vSphere and not in bare-metal OS. 2.vPMEM: vSpherepresentsPMEM as a NVDIMM device to the VM. Most of the latest operating systems (for example, Windows Server 2016 and CentOS 7.4) support NVDIMM devices and can expose them to the applications as block or byte-addressable devices. Applications can use vPMEM as a regular storage device by going through the thin layer of the direct-access (DAX) file system or by mapping a region from the device and accessing it directly in a byte-addressable manner. This mode can be used by legacy or newer applications running on newer OSes.

Persistent Memory Performance on vSphere 6.7: Performance Study |  27v. vMotionPerformancevSphere supports vMotion of both vPMEMDisk and vPMEM. vPMEMDisk vMotion is conducted as XvMotion, where both local storage and memory contents are transferred to another host. vPMEM vMotion is conducted as compute vMotion, where vPMEM is transferred as memory along with vRAM. Note that, PMEM is a host local storage and seamless live-migration like vMotion is only possible in vSphere environment (unlike bare-metal OS) We used 2 identical hosts connected over 40 GbE network. We created 3 vmknics for vMotion over the 40 GbE physical NIC.

 

I will share the update information shortly. I hope this has been informative and thank you for reading!

Hybrid Cloud Extension (HCX)

 

Hybrid Cloud Extension (HCX) is an all in one solution for workload mobility. Customers can freely move workloads between multiple on-premises environments as well as VMware Cloud on AWS (VMC). The data center evacuation was using a new HCX migration type called Cloud Motion with vSphere Replication. The workloads were being migrated from an on-premises data center to VMware Cloud on AWS (VMC). The big deal here is the impact during the migration to the users was NONE, ZIP, ZERO downtime. And there was also no replatforming of the workloads or applications.

What is Cross-Cloud Mobility?

Cross-Cloud Mobility is the capability to pair any cloud infrastructure together and expect each cloud to act as an extension to the other(s). The HCX platform becomes the basis on which Cross-Cloud Mobility is provided by leveraging infrastructure services (Any-Any vSphere Zero downtime migration, seamless Disaster Recovery, enabling Hybrid Architectures, etc.) to provide tangible business value.

Hybrid Cloud Extension (HCX) when migrating workloads from one location to another. The network is at the top of the list, ensuring adequate bandwidth and routing is in place. Not only from data center to data center or data center to cloud, but also across regions and remote sites. Validating vSphere version compatibility between the source and destination is also important. Other workload migration considerations could include:

•     Moving across different vSphere SSO domains independent of enhanced linked mode
•     Mapping workload dependencies
•     Older hardware preventing from upgrading to vSphere 6.x
•     Bi-directional migrations independent of vSphere SSO domains, vSphere versions, hardware, or networks
•     Validation of resources (compute and storage) on the destination side
•     SLA and downtime involved
•     Mobility options correlating to SLAs (downtime, low downtime, no downtime)
•     No replatforming of the workloads or applications including no changes to IP or MAC Addresses, VM UUID, certs

 I will share the update information shortly. I hope this has been informative and thank you for reading!

Enhanced vMotion Compatibility (EVC) Explained

vSphere Enhanced vMotion Compatibility (EVC) ensures that workloads can be live migrated, using vMotion, between ESXi hosts in a cluster that are running different CPU generations. The general recommendation is to have EVC enabled as it will help you in the future where you’ll be scaling your clusters with new hosts that might contain new CPU models. To enable EVC in a brownfield scenario can be challenging.  That why we stress to have it enabled from the get-go. This blog post will go into details about EVC and the per-VM EVC feature.

How does EVC work?

The way EVC allows for uniform vMotion compatibility, is by enforcing a CPUID (instruction) baseline for the virtual machines running on the ESXi hosts. That means EVC will allow and expose CPU instruction-sets to the virtual machines depending on the chosen and supported compatibility level. If you would add a newer host to the cluster, containing newer CPU packages, EVC would potentially hide the new CPU instructions to the virtual machines. By doing so, EVC ensures that all virtual machines in the cluster are running on the same CPU instructions allowing for virtual machines to be live migrated (vMotion) between the ESXi hosts.

EVC determines what instructions to mask from the guest OS by using the CPUID. Basically, you can look at the CPUID being an API for the CPU. It allows EVC to learn what instruction-sets the CPU is capable of doing, and what instructions needs to be masked depending on the configured EVC baseline. When EVC is enabled on the cluster, all ESXi hosts in the cluster must adhere to that setting.

This VMware KB article goes into more detail about all current EVC baselines and what CPU instructions they expose to the virtual machines.

Per-VM EVC

EVC is a cluster level setting that supports virtual machine mobility within a cluster. When a virtual machine is moved to another cluster, either on-prem or in a hybrid cloud environment, it loses its EVC configuration depending on the destination environment. Next to that, it is challenging to change a cluster EVC baseline in a environment with live workloads.

By implementing per-VM EVC, the EVC mode becomes an attribute of the virtual machine rather than the specific processor generation it happens to be booted on in the cluster. This helps to be more flexible with EVC enablement and baselines. We introduced the per-VM EVC feature in vSphere 6.7. Virtual machine hardware version 14 or up is required to enable per-VM EVC. When a virtual machine is powered off, you can change the per-VM EVC baseline.

 

The per-EVC configuration is saved in the vmx file. The vmx file is the file used as a value dictionary that provides the configuration of the virtual machine. If the virtual machine is migrated to another cluster, the per-EVC configuration is moving along with the virtual machine itself. The vmx file will contain featMask.vm.cpuid lines like the following when per-VM EVC is enabled:

featMask.vm.cpuid.Intel = “Val:1”
featMask.vm.cpuid.FAMILY = “Val:6”
featMask.vm.cpuid.MODEL = “Val:0x4f”
featMask.vm.cpuid.STEPPING = “Val:0”
featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

I will share the update information shortly. I hope this has been informative and thank you for reading!

Introducing the Network Insight Virtual Machine Search Poster

VMware vRealize Network Insight can be a revealing experience. It has every single bit of data you ever wanted to see about anything in your infrastructure and it’s available at your fingertips. Because of the vast amount of available data, the search engine is extremely versatile and there are many options available in its syntax.

To make traversing the search engine a bit easier, we’re launching a Search Poster series that will be showcasing the most useful search queries for a specific area. Starting with virtual machines, you can find the first poster in this series on our vRealize microsite here. This will certainly kickstart your search engine learning!

https://vrealize.vmware.com/t/vmware-network-management/virtual-machine-search-poster/

I will share the update information shortly. I hope this has been informative and thank you for reading!

 

NSX 9 free VMware NSX eBooks!

VMware Press NSX Guides are authored and technically reviewed by VMware subject-matter experts and cover networking and security essentials.

Below you will find a description of the current books in our library along with a downloadable PDF link

New Release: VMware NSX Automation Fundamentals Guide

VMware NSX Automation Fundamentals delivers the roadmap to understanding networking and security automation challenges in today’s data centers.  It explains the fundamental nature of VMware NSX Data Center architecture while detailing integrated solutions for both VMware and third party offerings (such as VMware vRealize Automation, OpenStack, Puppet, Chef, PowerNSX) that assist in creating networking and security components on-demand.

Follow Caio on Twitter! And follow Thiago on Twitter too!

New Release: VMware NSX Network Virtualization Fundamentals

During their digital transformation process, many IT organizations still struggle with traditional networking methods and security approaches. By successfully addressing these challenges in thousands of real-world implementations, VMware NSX Data Center has established itself as the leading network virtualization platform, revolutionizing the way data center networks are designed and operated. In this book, Gustavo Santana examines the specific circumstances that created such challenges and explains how NSX Data Center overcomes them.

Follow Gustavo on Twitter!

New Release: VMware NSX Multi-site Solutions and Cross-vCenter NSX Design: Day 1 Guide

In this Day 1 Guide, the authors walk through multi-site and its traditional challenges, and discuss some of the short-comings of traditional multi-site solutions, compare different multi-site solutions provided by VMware NSX Data Center, discuss the advantages of NSX and how it can be used for different use-cases, and go into detail on Cross-vCenter NSX for multi-site solutions.

Follow Humair on Twitter!

New Release : VMware NSX for Disaster Recovery : Day 1 Guide

VMware NSX for Disaster Recovery: Day 1 offers the knowledge and guidance for planning, designing, and implementing a disaster recovery architecture for your software-defined data center. VMware NSX Data Center simplifies the DR planning and testing that is required for a resilient infrastructure and drastically reduces the time it takes to recover from an event. It enables true workload portability between data centers, private clouds, or public clouds. NSX Data Center has helped enterprises recover from natural disasters and outages as well as simplified the mergers and acquisitions of organizations and their networks. Follow Brad on Twitter! or Follow Sean on Twitter

Building VMware NSX Powered Clouds and Data Centers for Small and Medium Businesses

Building VMware NSX Powered Clouds and Data Centers for Small and Medium Businesses details how the NSX Data Center platform will allow you to redesign your data center and build and run private clouds. NSX DC also serves as the integration point between the private and public clouds with offerings such as VMware Cloud on AWS. Shahzad Ali gives readers the tools and techniques required to transform legacy architecture into a software-defined cloud based architecture.

Follow Shahzad on Twitter!

VMware NSX Micro-segmentation : Day 1 Guide 

VMware NSX Micro-segmentation: Day 1 provides insights and recommendations proven to move an organization from a perimeter-centric security posture to a micro-segmented architecture with enhanced security and visibility. NSX DC enables granular firewalling and security policy enforcement for each workload, independent of network topology and complexity. Wade Holmes explains how to effectively plan, design, and implement a data center security strategy based around micro-segmentation.

Follow Wade on Twitter!

VMware NSX Micro-segmentation: Day 2 Guide

As a follow-up to Wade’s Day 1 Guide, Geoff Wilmington published this day 2 operations guide. Geoff provides the knowledge needed to begin building scalable methodology and planning for the applications you are going to secure. With step-by-step processes for using tools and products including VMware Log Insight, Application Rule Manager, and vRealize Network Insight, you will be armed with practical information so that planning micro-segmentation for thousands of applications is no longer an overwhelming task.

Follow Geoff on Twitter! Or check out his blog.

Operationalizing VMware NSX

Operationalizing VMware NSX offers insight into optimizing the ongoing operations of NSX DC. Kevin Lees covers both tactical optimizations – such as tooling for monitoring and troubleshooting, and strategic organization – including team structure, culture, roles, responsibilities, and skillsets. NSX has helped over a thousand organizations improve their software-defined data center by fundamentally changing the way they approach network and security architecture. You will find proven recommendations to enhance the way you organize and operate your environment, unlocking its full potential to provide the flexibility and agility your business requires.

Automating NSX for vSphere with PowerNSX

PowerNSX is a PowerShell module that abstracts VMware NSX for vSphere API to a set of easily used PowerShell functions. This Guide will teach you what PowerNSX is, as well as the flexibility and control that it brings. It will also provide an overview of PowerNSX architecture and functionality, then cover PowerNSX usage.

Follow Anthony on Twitter! Or check out his blog.

With contributions from fellow Aussies Dale Coghlan and Nick Bradford.

I will share the update information shortly. I hope this has been informative and thank you for reading!

What’s New in vRealize Operations 7.5?

VMware vRealize Operations 7.5, which will continue to refine the foundational “self-driving operations” vision established in the last two releases.

The vision of Self-Driving Operations is to automate and simplify operations management by delivering on four primary tenets:

Use Cases 

• Intent-driven continuous performance optimization
• Efficient capacity management
• Intelligent remediation
• (NEW!) Integrated compliance

Use Cases Unlocked by vRealize Operations 7.5

Self-driving operations has been the fundamental idea behind vRealize Operations for over a year now, and 7.5 is packed with new features and improvements that will continue to make your self-driving datacenter a reality. Additions and improvements in performance, capacity, remediation and compliance have made vRealize Operations 7.5 the version that unlocks some really powerful use cases for managing your private, hybrid-, or multi-cloud environment:

UPDATED: Private cloud operational efficiency

UPDATED: Hyper-converged infrastructure operations

UPDATED: Hybrid/multi-cloud operations

NEW! Application operations for packaged apps

NEW! Configuration and compliance

I will share the update information shortly. I hope this has been informative and thank you for reading!

VSAN ready node Advantages

Most of the Hyper-Converged Infrastructure (HCI) requires computing resources that have been traditionally offloaded to dedicated storage arrays. Nearly all other HCI solutions require the deployment of storage virtual appliances to some or all hosts in the cluster. These appliances provide storage services to each host. Storage virtual appliances typically require dedicated CPU and/or memory to avoid resource contention with other virtual machines.

Running a storage virtual appliance on every host in the cluster reduces the overall amount of computing resources available to run regular virtual machine workloads. Consolidation ratios are the lower and total cost of ownership rises when these storage virtual appliances are present and competing for the same resources as regular virtual machine workloads.

Storage virtual appliances can also introduce additional latency, which negatively affects performance. This is due to the number of steps required to handle and replicate write operations as shown in the figure explained.

Storage Controller Virtual Appliance HCI solution : 

vSAN is Native in the vSphere Hypervisor

vSAN does not require the deployment of storage virtual appliances or the installation of a vSphere Installation Bundle (VIB) on every host in the cluster. vSAN is native in the vSphere hypervisor and typically consumes less than 10% of the computing resources on each host. vSAN does not compete with other virtual machines for resources and the I/O path is shorter. 

A shorter I/O path and the absence of resource-intensive storage virtual appliances enables vSAN to provide excellent performance with minimal overhead. Higher virtual machine consolidation ratios translate into lower total costs of ownership.

vSAN Cluster Types

vSAN Runs on standard x86 servers from more than 15 OEMs. Deployment options include over 500 vSAN ReadyNode choices, integrated systems such as Dell EMC VxRail or , Dell EMC VxRack SDDC systems, and build-your-own using validated hardware on the VMware Compatibility List. A great fit for large and small deployments with options ranging from a 2-node cluster for small implementations to multiple clusters each with as many as 64 nodes—all centrally managed by vCenter Server. 

vSAN support Standard Cluster with 3 nodes, 2 node cluster for remote office  and Stretched Cluster solution.

Standard Cluster

A standard vSAN cluster consists of a minimum of three physical nodes and can be scaled to 64 nodes.All the hosts in a standard cluster are commonly located at a single location and are well-connected on the same Layer-2 network. 10Gb network connections are required for all-flash configurations and highly recommended for hybrid configurations.

2 Node Cluster

A 2-node cluster consists of two physical nodes in the same location. These hosts are usually connected to the same network switch or are directly connected. Direct connections between hosts eliminate the need to procure and manage an expensive network switch for a 2-node cluster, which lowers costs especially in scenarios such as remote office deployments. While 10Gbps connections may be directly connected, 1Gbps connections will require a crossover cable.

A third “vSAN Witness Host” is required for a 2-node configuration to avoid “split-brain” issues when network connectivity is lost between the two physical nodes. We will discuss the vSAN Witness Host in more detail shortly

Stretched Cluster

A vSAN Stretched Cluster provides resiliency against the loss of an entire site. The hosts in a Stretched Cluster are distributed evenly across two sites. The two sites are well-connected from a network perspective with a round trip time (RTT) latency of no more than five milliseconds (5ms). A vSAN Witness Host is placed at a third site to avoid “split-brain” issues if connectivity is lost between the two Stretched Cluster sites. A vSAN Stretched Cluster may have a maximum of 30 hosts in the cluster and can be distributed proportionally or disproportionately. In cases where there is a need for more hosts across sites, additional vSAN Stretched Clusters may be used.

vSAN Witness Host

While not a cluster type, it is important to understand the use of a vSAN Witness Host in 2 Node and Stretched Cluster vSAN deployments. This “Witness” stores metadata commonly called “witness components” for vSAN objects. Virtual machine data such as virtual disks and virtual machine configuration files are not stored on the vSAN Witness Host. The purpose of the vSAN Witness Host is to serve as a “tie-breaker” in cases where sites are network isolated or disconnected.

A vSAN Witness Host may be a physical vSphere host, or a VMware provided virtual appliance, which can be easily deployed from an OVA. When using a physical host as a vSAN Witness Host, additional licensing is required, and the host must meet some general configuration requirements. When using a vSAN Witness Appliance as the vSAN Witness Host, it can easily reside on other/existing vSphere infrastructure, with no additional need for licensing.

When using 2 Node clusters for deployments such as remote office branch office (ROBO) locations, it is a common practice for vSAN Witness Appliances to reside at a primary datacenter. They may be run at the same ROBO site but would require additional infrastructure at the ROBO site.

vSAN Witness Hosts providing quorum for Stretched Clusters may only be located in a tertiary site that is independent of the Preferred and Secondary Stretched Cluster sites.

One vSAN Witness Host is required for each 2 Node or Stretched Cluster vSAN deployment. Bandwidth requirements to the vSAN Witness Host are determined by the number of vSAN components on a cluster. During failover scenarios, ownership of vSAN components must be moved to the surviving site over a five second (5s) window. The rule of thumb is 2Mbps for every 1000 vSAN components. Maximum latency requirements to/from the vSAN Witness Host depend on the number of hosts in the cluster. 2 Node configurations are allowed up to five hundred milliseconds (500ms) and Stretched Clusters are allowed two hundred milliseconds (200ms) or one hundred milliseconds (100ms) depending on the number of hosts in the Stretched Cluster.

Using the VMware provided vSAN Witness Appliance is generally recommended as a better option for the vSAN Witness Host than using a physical vSphere host. The utilization of a vSAN Witness Appliance is relatively low during normal operations. It is not until a failover process occurs that a vSAN Witness Host will have any significant utilization. Because of this, especially in large 2 Node deployments to ROBO sites, multiple vSAN Witness Appliances may be run on the same shared vSphere infrastructure. VMware supports running the vSAN Witness Appliance on any vSphere 5.5 or higher infrastructure, which can include a standalone ESXi host, a typical vSphere infrastructure, in OVH (the service formally known as vCloud Air), any vCloud Air Network Partner, or any Service Provider/Shared/Co-Location where vSphere is used.

When using a vSAN Witness Appliance, it is patched in the same fashion as any other ESXi host. It is the last host updated when performing 2 Node and Stretched Cluster upgrades and should not be backed up.

I hope this has been informative and thank you for reading!