Monday, August 5, 2019

Understand how vSAN Data Protects

vSAN Protects data in many different forms. We will discuss these in brief.

Storage Policy-Based Management

Storage Policy-Based Management (SPBM) from VMware enables precise control of storage services. Like other storage solutions, vSAN provides services such as availability levels, capacity consumption, and stripe widths for performance. A storage policy contains one or more rules that define service levels.
 
Storage policies are created and managed using the vSphere Web Client. Policies can be assigned to virtual machines and individual objects such as a virtual disk. Storage policies are easily changed or reassigned if application requirements change. These modifications are performed with no downtime and without the need to migrate virtual machines from one datastore to another. SPBM makes it possible to assign and modify service levels with precision on a per-virtual machine basis.
 
Failures To Tolerance (FTT)

Defines how many failures an object can tolerate before it becomes unavailable.
Fault Domains: “Fault domain” is a term that comes up often in availability discussions. In IT, a fault domain usually refers to a group of servers, storage, and/or networking components that would be impacted collectively by an outage. A common example of this is a server rack. If a top-of-rack switch or the power distribution unit for a server rack would fail, it would take all the servers in that rack offline even though the server hardware is functioning properly. That server rack is considered a fault domain.
 
Each host in a vSAN cluster is an implicit fault domain. vSAN automatically distributes components of a vSAN object across fault domains in a cluster based on the Number of Failures to Tolerate rule in the assigned storage policy. The following diagram shows a simple example of component distribution across hosts (fault domains). The two larger components are mirrored copies of the object and the smaller component represents the witness component.
 


To mitigate this risk, place the servers in a vSAN cluster across server racks and configure a fault domain for each rack in the vSAN UI. This instructs vSAN to distribute components across server racks to eliminate the risk of a rack failure taking multiple objects offline. This feature is commonly referred to as “Rack Awareness”. The diagram below shows component placement when three servers in each rack are configured as separate vSAN fault domains.

 

Disk Group

A disk group is a unit of physical storage capacity on a host and a group of physical devices that provideperformance and capacity to the vSAN cluster. On each ESXi host that contributes its local devices to avSAN cluster, devices are organized into disk groups.Each disk group must have one flash cache device and one or multiple capacity devices. The devicesused for caching cannot be shared across disk groups, and cannot be used for other purposes. A singlecaching device must be dedicated to a single disk group. In hybrid clusters, flash devices are used for thecache layer and magnetic disks are used for the storage capacity layer.

Consumed Capacity

Consumed capacity is the amount of physical capacity consumed by one or more virtual machines at anypoint. Many factors determine consumed capacity, including the consumed size of your VMDKs,protection replicas, and so on. When calculating for cache sizing, do not consider the capacity used forprotection replicas.


Object-Based Storage

vSAN stores and manages data in the form of flexible data containers called objects. An object is a logicalvolume that has its data and metadata distributed across the cluster. For example, every VMDK is anobject, as is every snapshot. When you provision a virtual machine on a vSAN datastore, vSAN creates aset of objects comprised of multiple components for each virtual disk. It also creates the VM homenamespace, which is a container object that stores all metadata files of your virtual machine. Based onthe assigned virtual machine storage policy, vSAN provisions and manages each object individually,which might also involve creating a RAID configuration for every object.When vSAN creates an object for a virtual disk and determines how to distribute the object in the cluster,it considers the following factors:nvSAN verifies that the virtual disk requirements are applied according to the specified virtual machinestorage policy settings.nvSAN verifies that the correct cluster resources are used at the time of provisioning. For example,based on the protection policy, vSAN determines how many replicas to create. The performancepolicy determines the amount of flash read cache allocated for each replica and how many stripes tocreate for each replica and where to place them in the cluster.nvSAN continually monitors and reports the policy compliance status of the virtual disk. If you find anynoncompliant policy status, you must troubleshoot and resolve the underlying problem.

vSAN Datastore

After you enable vSAN on a cluster, a single vSAN datastore is created. It appears as another type ofdatastore in the list of datastores that might be available, including Virtual Volume, VMFS, and NFS. Asingle vSAN datastore can provide different service levels for each virtual machine or each virtual disk. InvCenter Server, storage characteristics of the vSAN datastore appear as a set of capabilities. You canreference these capabilities when defining a storage policy for virtual machines. When you later deployvirtual machines, vSAN uses this policy to place virtual machines in the optimal manner based on therequirements of each virtual machine.

Objects and Components

Each object is composed of a set of components, determined by capabilities that are in use in the VMStorage Policy. For example, with Primary level of failures to tolerate set to 1, vSAN ensures that theprotection components, such as replicas and witnesses, are placed on separate hosts in the vSANcluster, where each replica is an object component. In addition, in the same policy, if the Number of diskstripes per object configured to two or more, vSAN also stripes the object across multiple capacitydevices and each stripe is considered a component of the specified object. When needed, vSAN mightalso break large objects into multiple components.

Virtual Machine Compliance Status

Compliant and NoncompliantA virtual machine is considered noncompliant when one or more of its objects fail to meet therequirements of its assigned storage policy. For example, the status might become noncompliant whenone of the mirror copies is inaccessible. If your virtual machines are in compliance with the requirementsdefined in the storage policy, the status of your virtual machines is compliant. From the Physical DiskPlacement tab on the Virtual Disks page, you can verify the virtual machine object compliance status.


Component State: Degraded and Absent States

vSAN acknowledges the following failure states for components:nDegraded. A component is Degraded when vSAN detects a permanent component failure anddetermines that the failed component cannot recover to its original working state. As a result, vSANstarts to rebuild the degraded components immediately. This state might occur when a component ison a failed device.nAbsent. A component is Absent when vSAN detects a temporary component failure wherecomponents, including all its data, might recover and return vSAN to its original state. This state mightoccur when you are restarting hosts or if you unplug a device from a vSAN host. vSAN starts torebuild the components in absent status after waiting for 60 minutes.

Object State

Healthy and UnhealthyDepending on the type and number of failures in the cluster, an object might be in one of the followingstates:nHealthy. When at least one full RAID 1 mirror is available, or the minimum required number of datasegments are available, the object is considered healthy.nUnhealthy. An object is considered unhealthy when no full mirror is available or the minimum requirednumber of data segments are unavailable for RAID 5 or RAID 6 objects. If fewer than 50 percent ofan object's votes are available, the object is unhealthy. Multiple failures in the cluster can causeobjects to become unhealthy. When the operational status of an object is considered unhealthy, itimpacts the availability of the associated VM.

Witness

A witness is a component that contains only metadata and does not contain any actual application data. Itserves as a tiebreaker when a decision must be made regarding the availability of the surviving datastorecomponents, after a potential failure. A witness consumes approximately 2 MB of space for metadata onthe vSAN datastore when using on-disk format 1.0, and 4 MB for on-disk format for version 2.0 and later.vSAN 6.0 and later maintains a quorum by using an asymmetrical voting system where each componentmight have more than one vote to decide the availability of objects. Greater than 50 percent of the votesthat make up a VM’s storage object must be accessible at all times for the object to be consideredavailable. When 50 percent or fewer votes are accessible to all hosts, the object is no longer accessibleto the vSAN datastore. Inaccessible objects can impact the availability of the associated VM.

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

Wednesday, July 31, 2019

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!

Wednesday, July 24, 2019

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!

Sunday, July 21, 2019

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!

 

Saturday, May 11, 2019

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.


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.

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.





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

NSX GuidesBuilding 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.


VMware NSX Micro-segmentation : Day 1 Guide 

NSX GuidesVMware 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.


VMware NSX Micro-segmentation: Day 2 Guide

NSX GuidesAs 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.



Operationalizing VMware NSX
NSX GuidesOperationalizing 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.

NSX Guides
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.
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!

Thursday, April 11, 2019

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!


What is FinOps in VMware Cloud Foundation?

FinOps (Financial Operations) is all about helping IT teams and business leaders understand, control, and optimize cloud spending. VMware Cl...