VMWare vSphere 5 vCenter Server Appliance (vCSA)

As you know to install vCenter, we need a dedicated infrastructure which includes VM, patching stuff, anti-virus and other management tasks for smoothly running of vCenter that involves costs and time overheads. With the introduction of vCenter Server Appliance (vCSA), cost and time can be minimized by installing pre-configured linux-based .ovf image to an ESX/ESXi server. We don’t needs any dedicated VM for installing and configuring vCenter.

.OVF stands for open virtualization format. Downloaded .OVF images consists of SUSE-based VM setup with a default resource utilization of 2vCPU, 8GB RAM and 5GB of disk space will be used for installation if we chose thin provisioning.

Downloading vCSA has 3 files for making it to run, .OVF file, the .VMDK system disk, and .VMDK data disk. While downloading, make sure all three files resides in the same directory as the .OVF file as the .OVF file execution look for the two .VMDK files.

These are the Prerequisites for installing vCenter Server Appliance:-

·         vSphere Client should be already installed

·         Host should be ESX version 4.x or ESXi 4.x later to deploy vCenter Appliance

·         VSA  reuire at least 7GB of disk space which is limited to a maximum size of 80 GB

·         Only Oracle database is supported

Do remember that below features are not supported by vCenter Server Appliance:-

·         MS SQL Server

·         IPv6 configuration

How to download vCenter Server Appliance

You may not be able to find so easily the VSA, therefore I’ve decided to guide you through steps.

1.       Select Support & Downloads and click on Account Login.

2.       Log in to the by entering user credential if account already exists or create a new account by registering yourself.

3.       Select Evaluation and Free Products as Destination, then vSphere Datacenter Products and Submit.

4.        Expand the Download the management server and select below products for download.

How to install vCSA on ESX/ESXi

Follow the below mentioned steps to install vCSA on ESX/ESXi:-

1.       Connect your vSphere Client to the ESXi server where you want vCSA to run.

2.       Click File and select Deploy OVF Template…

3.       In the Source page, click Browse and enter the location of .OVF file.

4.       The vCSA application will be recognized and will display vCSA details like version, size etc. Click Next.

5.       In the Name and Location wizard, enter any user friendly name and click Next.

6.       In the Storage window, select which datastore would be used to store this VM. We can select local disk as well, but NAS/SAN is recommended. Click Next.

7.       In the next screen, select VM disk format, Flat, thick or thin provision. Flat is recommended for the best performance, and thick is typically selected when using VMWare Fault Tolerance. Click Next.

8.       Click Finish to start the installation process.

9.       Once deployment is successful, you will see the new vCenter appliance as a new VM on your ESXi server.

New Features in Microsoft System Center Virtual Machine Manager (SCVMM) 2012

1.       Discover physical computers on the network, automatically install Windows Server 2008 R2 and manage it as Hyper-V hosts

2.       Use VMM console to create a Hyper-V cluster from two or more stand-alone Hyper-V hosts that are managed by VMM 2012

3.       Create profiles like hardware profiles, guest operating system profiles, SQL Server profiles and application profiles

4.       Create virtual machine templates for creating new virtual machines for deploying to private clouds

5.       Use VMM to configure Networking and Storage resources

6.       Dynamic Optimization (Equals to VMWare’s Distributed Resource Scheduler (DRS) ) performs resource balancing by migrating VMs within host clusters. Read more on Fabric Management as below.

7.       Enhanced Placement determines on which host a workload will run by using placement algorithms and 100 placement checks and validations.

8.       Power Management feature like VMWare’s Distributed Power Management (DPM) which will power down the Hyper-V hosts during times of low utilization. Read more on Fabric Management as below.

9.       Create private cloud by configuring the fabric (combining hosts, storage and networking) then create a cloud from the fabric and delegate the cloud to a Self Service User for creating VMs and Services in the cloud. Read more on Fabric Management as below.

10.   Self-service users can now use the VMM console instead of the VMM Self-Service Portal to perform tasks, such as deploying virtual machines and services.

11.   SQL Server Express is no longer supported for the VMM database.

12.   Virtual machine hosts that are running Microsoft Virtual Server 2005 are no longer supported.

13.   Virtual machine hosts that are running VMware ESX 3.0 or ESXi 3.0 are no longer supported.

14.   Refined Cluster Patching

Dynamic Optimization Example

Let’s take the case of CPU as a basic example (please do, however, keep in mind that DO works across multiple resource dimensions such as Memory, Network I/O and Disk I/O, including Hyper-V Dynamic Memory enabled environments). By default, we have the following CPU levels defined:

·         Host Reserve Threshold – 10%

·         Dynamic Optimization Threshold – 30%

·         Power Optimization Threshold – 40%

When DO runs, it will actively try to migrate VMs off hosts which have exceeded the DO level (in this case, hosts which have less than 30% CPU available). The target host of the migration could be any host. It could even cause a host to rise above the DO level, as long as the new level is significantly better than was the old one. The amount of improvement required to trigger a migration is dictated by the aggressiveness setting.

Here are a couple of scenarios to consider:

•             Host A running at 75% load migrates one or more virtual machine to Host B with 50% load. After the migration their loads are A: 65% and B: 60%. (Both healthy)

•             Host A running at 90% load migrates one or more virtual machines to Host B with 65% load. After the migration their loads are A: 80% and B: 75%. (B has actually risen above the DO level, which is a valid operation given an aggressiveness setting of Medium.

Power Optimization Example

PO considers the theoretical effect of evacuating each host. If any host, or set of hosts can be powered off and all the target hosts would remain under the PO level, then VMM will consolidate workloads and power off the appropriate hosts.

Continuing with our default levels from above:

·         Host Reserve Threshold – 10%

·         Dynamic Optimization Threshold – 30%

·         Power Optimization Threshold – 40%

Here are a couple of scenarios to consider:

•             Host A running with 20% CPU load evacuates to Host B which is currently running 30% CPU load. After the evacuation, host B is at 50% (meaning it has over 40% available CPU resources) and A is powered off.

•             Same as above, but host C is running at 65% CPU load. DO does nothing (because the DO threshold of 30% has not been violated). PO notices that host A can evacuate to host B and keep it below 60%. It does so. C has no bearing on that evacuation and A is powered off.

Patching cluster hosts in SCVMM 2012

One of the trickier things to manage in a clustered environment is updating the hosts. While management platforms such as Systems Center Configuration Manager can do it they’re not cluster / virtualization aware and are likely to push out patches to all hosts simultaneously, causing an outage as they all reboot. SCVMM works around the issue by integration with a dedicated 64 bit WSUS 3.0 SP2 server and orchestrating cluster patching by Live migrating VMs to other nodes, patching and rebooting the host, moving VMs back and the repeating the process on the next cluster node

Fabric Management:-

•             Physical Server

§  Manage multiple hypervisors – Hyper-V, VMWare, Xen

§  Server hardware management- IPMI, DCMI, SMASH via provider

§  Host provisioning- from baremetal to Hyper-V to Cluster provisioning

•             Network

§  Define logical Networks using VLANs and Subnets per datacenter location

§  Address management for Static IPs, Load Balancer VIPs and MAC address

§  Automated provisioning of load balancers via provider (F5 and Citrix)

•             Storage

§  Storage Management using SMI-S (NetApp, EMC, HP)

§  Discover storage array and pools

§  Classify storage based on throughput and capabilities

§  Discover or configure LUNs and assign to hosts and clusters

§  Rapid cloning of VMs using snap cloning of LUNs

Difference between Quick Migration and Live Migration

Quick Migration was introduced in Hyper-V version 1 and Live Migration in Hyper-V version 2. Both are used for migrating virtual machines from one host to another host with minimum downtime. But when compare both; Live Migration is faster than other. Let’s try to learn the difference between two.

Quick Migration relocates virtual machines between different hosts and migration time depends upon the amount of memory assigned to the VM along with network connection between virtual hosts and shared storage. VMs with more memory but with sluggish networks will take longer to complete migration as compared to other VM having less virtual memory on faster network. Migration taking more than 15-20 seconds may not be consider as viable in many environments due to clients facing outage during that time. We can see in the below table the average time taken by the Quick Migration to move a VM when having different memory sizes.

Why so much time is taken by the Quick Migration? To know this, we should first understand the process by which Quick Migration take place. When Quick Migration process is initiated, a VM is placed in a Saved state (neither shutdown nor paused state). During Saved state, a VM releases its memory reservation on the host machine and stores the contents of its memory pages to disk. Once this has been completed, the target host takes over the ownership of a VM and brings it back to operation. Placing the VM in a Saved state is the most time-consuming aspect of migration.

To reduce this delay, Live Migration pre-copies a VM’s memory from the source to the destination host. Any changes to memory pages during the pre-copy process is also logged which are generally in few number and make the delta copy smaller. Once the pre-copy is completed, VM is paused, copies the memory deltas and then transfer ownership to the target host which saves significant time.

EMC Data Domain – Deduplication Solution

EMC Data Domain (DD) Deduplication has four basic steps:-

1.       Indentify Segments

2.       Determine if those segments are unique or not

3.       If  unique, are they compressed

4.       If compressed, write to Data domain

EMC DD Boost changes this approach. Part of deduplication process is distributed to the Backup servers. Segments are now identified on the backup servers. Backup servers communicate with Data domain to see if segment is unique or not. If segment is unique, segment is compressed on the Backup servers and then sent to Data domain. Deduplicated data backups are stored on NetWorker Data Domain storage devices that are accessed by the NetWorker storage node. Backup stored on Data Domain system may be copied to remote storage for added protection and disaster recovery. Replication between two Data domain is supported.

Data Domain Boost has been fully integrated with NetWorker Server. NetWorker creates index of replicated copies between two Data Domains. Same way, retention policies can be defined either to reside on other Data domains or on tape drive which is indexed by the NetWorker. We can set scheduling on NetWorker to clone Storage nodes on timely basis with retention policies.

In the below diagram, client backups are cloned from primary Data Domain system to the remote Secondary Data Domain system which is further cloned to tape drive.