VMware: vSphere Replication Part 2 - Installation

Let's continue with vSphere Replication series after last vSphere Replication Part 1 - Introduction post.

vSphere Replication installation is a pretty straigth-forward process since in most cases it is just necessary to deploy a single appliance to have everything setup and properly running.

vSphere Replication can replicate VMs between different datastores managed by the same vCenter or across sites managed by different vCenters.

Test scenario comprises two vCenter Servers managing two different datacenters:

1)SiteA with "localhost" vCenter that manages one host
2)SiteB with "vcenter-test" vCenter that also manages one host

vSphere Replication will be configured from SiteA to SiteB.

Installation will be shown just for SiteA, if your deployment comprises multiple vCenters to install vSphere Replication in SiteB you need to do repeat the same procedure as for SiteA.

Right click Cluster or alternatively one host and select Deploy OVF Template

Select the vSphere Replication OVF file, in this case: vSphere_Replication_OVF10.ovf

Review details

Choose where to deploy

Setup network connections by setting up IP allocation, DNS server, Gateway and Netmask.

Enter administrative password and, if Static - Manual IP Allocation was selected, enter IP address for vSphere Replication Appliance.

Verify that vSphere Replication binds to your correct vCenter identified by IP address or, as best practice, by FQDN.

Press Finish and wait for the appliance to be deployed and powered on. It will automatically integrate with vSpehere Web Client.
A logout/login is required after vSphere Replication startup is finished in order to view the new vSphere Replication plugin enabled in vSpehere Web Client.

vSphere Replication is now deployed and fully functional, ready to replicate VMs.

Other blog posts in vSphere Replication Series:

vSphere Replication Part 1 - Introduction
vSphere Replication Part 2 - Installation
vSphere Replication Part 3 - Roles & Permissions
vSphere Replication Part 4 - Configuration 
vSphere Replication Part 5 - Enable Replication  
vSphere Replication Part 6 - Perform Recovery  
vSphere Replication Part 7 - Provision additional Replication Servers 

VMware: vSphere Replication Part 1 - Introduction

Today I decided to start a vSphere Replication blog post series in which I will cover replication functionalities offered by vSphere.

What is vSphere Replication?

vSphere Replication as name suggest is a replication appliance deployed in vSphere that allows VMs to be replicated between different datastores. Replication can occur within the same vSphere cluster managed by a single vCenter Server, or across clusters managed by different vCenter Servers.

A major benefit of vSphere Replication is the possibility to set RPO of VMs replication between 15mins up to 24hours, this means that in the worst case (assuming RPO of 15mins) you can loose up to 15mins of data.
Since replication can be performed on powered on VMs, and due to quiescing mechanisms involved during replication, more aggressive RPOs under 15mins were avoided since they could introduce performance problems in VMs quiesced too frequently.

vSphere Replication differs from standard array based replication by being hardware agnostic, no hardware prerequisites exist between source and destination storage, plus they don't have to share same communication protocol (i.e. iSCSI,FC,FCoE,etc.) to be connected neither they must be explicitly supported/certified for replication. It also differs from standard array based replication due to the fact that vSphere Replication can copy invidual VMs and not entire LUNs to destination array despite standard array replication offers an hardware offloaded transfer that does not contend for hypervisor's resources.

Another features is the support of replication seeds for VMs copying. Let's assume you have a VM with a 1.5TB vmdk disk. If you are replicating this VM over the internet sending to destination site 1.5TB may involve some time regardless of your internet connection speed. Replication seed allows to transfer this base vmdk using an out-of-band mechanism (i.e. transfer vmdk using an USB HDD) to destination datastore. Once replication is enabled on a VM with a replication seed vSphere Replication will notice vmdk already exists at destination datastore so it will transfer only changes occurred in VM disk using CBT evaluating source vmdk and destination vmdk.

How does it work?

vSphere Replication simply copies VMs from source datastore to destination datastore to meet configured RPOs.
VM at source site is quiesced and then whole vmdk, or delta-vmdk if base disk already exists at destination, is copied to target datastore.

vSphere Replication allows retaining point in time -PIT- copies of the VM that will be seen as VM snapshots once VM is recovered.

As said before vSphere Replication doesen't care if you are replicating VMs within same local site or across the network to a remote site managed by a different vCenter, all you have to do is properly configure Replication Server used by vCenter to connect to in order to set up replication.

vSphere Replication is available as a virtual appliance that comprises a vSphere Replication Management Server that provides replication management, a vSphere Replication Server that is in charge of performing actual data transfer between source and destination, an embedded database to store data and replication schedules, and a plug-in for vSphere Web Client that provides management capabilities for vSphere Replication within Web Client.

vSphere Replication can be managed only from vSphere Web Client.

Up to 10 optional vSphere Replication Servers can be deployed and managed by a single Management Server in order to provide replication load balancing. Up to 500VMs can be replicated from source to destination datastores.

How much does it cost?

vSphere Replication is included in vSphere Essential Plus or higher so it is "free" if you already purchased at least Ess+ license.


Other blog posts in vSphere Replication Series:

vSphere Replication Part 1 - Introduction
vSphere Replication Part 2 - Installation 
vSphere Replication Part 3 - Roles & Permissions
vSphere Replication Part 4 - Configuration
vSphere Replication Part 5 - Enable Replication  
vSphere Replication Part 6 - Perform Recovery  
vSphere Replication Part 7 - Provision additional Replication Servers 

VMware: Increasing VM read performances using vFRC

Virtual Flash Read Cache (vFRC) is a VMware storage solution that leverages host-side SSDs to create a caching layer for VMs.
It allows to offload IOs from SAN to host SSDs. vFRC is defined on a per-VM basis and affects only VM reads while writes are still write-through to SAN.
SSD acts only as caching stage, SAN or DAS is still used as persistent storage. A prerequisite for enabling vFRC on a host is one or more host local SSDs (up to eight) without an existing filesystem on top of them, this is because vFRC will format them using a new filesystem, named Virtual Flash FileSystem (VFFS), a VMFS highly optimized for SSDs.
It is important to say that by enabling vFRC you can still run vMotion, HA and DRS in your cluster.

vFRC reserves a portion of space on VFFS volume per-VM basis and for individual vmdks, this means that if a VM has more drives (i.e. more vmdks) you can select which one, if any, to enable vFRC on. This reservation takes place only when VMs are powered on, when VMs are powered off chaching reserved space is reclaimed and freed.

vFRC has the following requirements:

• vCenter Server 5.5
• At least one ESXi 5.5 host
• vFRC is configured & managed only by using vSphere Web Client
• SSDs without filesystem. If VMFS or other filesystem is already on SSD remove it in order to create VFFS.

And the following maximums:

• One Virtual Flash Resource (VFFS) per vSphere host
• Eight Flash devices per Virtual Flash Resource (VFFS)
• 4TB physical Flash-based device size
• 400GB of Virtual Flash Read Cache per Virtual Machine Disk (VMDK)
• 4TB of Virtual Flash Host Swap Cache per vSphere host
• 32TB Virtual Flash Resource total size


To enable vFRC open vSphere Web Client, select one host then Manage -> Settings -> Virtual Flash -> Virtual Flash Management Resource -> Add Capacity

All available host local SSDs without VMFS on top of them will be available for vFRC.

Select one or more SSDs and choose how much space will be used for vFRC. There is a minimum value of 1GB and a maximum value equal to SSD's capacity, but you can configure any value between these two limits.

Once added Virtual Flash Resource Management will reflect the size of your vFRC pool.

vFRC is enabled on selected host. If needed repeat the same procedure for other hosts in your cluster.

Next step is to define the VMs that will access vFRC caching layer.

Click on desired VM(s), or create a new one like I did, and go to Edit Settings, expand Hard Disk properties and choose how much MB/GB of vFRC space will this disk use.

If you click Advanced option you can also choose blocksize in KB according to your VM workload characterization.

Please bear in mind that vFRC is only used for reads, hence when VM guest OS reads a data block on a vmdk cached by vFRC, vFRC caching software fetches from SAN that data block plus a portion of data that will be likely soon to be used by VM based on principle of locality and stores it on host SSD.

vFRC does not improve write IOs. Data written to vmdks will pass-by vFRC and is written-through directly to SAN.

Another consideration is that not all workloads may benefit from vFRC, it could bring extremely high benefits to certain IOs and not to others, this primarily depends on workload patterns.

VMware: Users, Groups and Roles management in vSphere 5.5

Since Single Sign-On was completely rebuilt from the ground up in vSphere 5.5  I was in a bit of a struggle while configuring roles and permissions for users accessing VMware vCenter.

With Single Sign-On (from here simply referred as SSO) redesign in vSphere 5.5 VMware introduced a new common domain named vsphere.local.
Users authentication is now managed by SSO server and not by vCenter itself. This is because VMware is looking to provide a common authentication platform across all its services. SSO now lets users authenticate into vCenter, vCD and vCO. New products, like vCOps, will probably authenticate users against SSO in their future releases.

So, here's how to create users, groups and manage permissions in vSphere 5.5.

First login to vSphere 5.5 Web Client which, by default, is accessible from this URL:

https://<your_vCenter_Server_IP_or_FQDN>:9443/vsphere-client


Login into vCenter with following credentials:

User: Administrator@vsphere.local
Password: vmware

NOTE: This is the default password for VMware vCenter Server Appliance. If you deployed vCenter as standalone installation you were prompted to choose for a password during installation process.

Go to Roles -> Single Sign-On -> Users and Groups. Click the green New User button to add new users.

Ensure that vsphere.local is set in Domain picker. This is because our users will not be local users but will be authenticated against SSO server.

Now let's create a Group. Move to Groups tab and click New Group button.

Then to add user(s) to this group select the newly created group, click Add Member icon, select user(s), click Add, then Ok.

Finally we need to assign our user(s) or group(s) permissions within our specific product. In this case we assign permissions within vCenter. Permissions are assigned product-wide and not domain-wide this is because a certain user or group could for example retain administrative permissions in vCenter and read-only permissions in vCD.

Go to your vCenter, click Manage -> Permission tab, add button

Click Add, select VSPHERE.LOCAL in Domain picker, choose your group, or user if want to grant permission only to single user and not to entire group, then click Add -> Ok.

Select role for user/group then click Ok.

You can now login with new user's credentials to verify correct permission grant.

Since in this example TestUser is member of TestGroup which has Read-Only permission assigned we can access vCenter and its object but cannot manage/interact with them as expected.

Permissions can be customized to properly fit your specifications. This can be done by accessing Roles -> Access Control -> Roles.

There are two different groups of roles: system roles, which cannot be modified, and sample roles that can be edited.

If you need to create a custom role best practices suggest you to clone an existing one and edit the cloned one.

That's all!!