Monday, 13 April 2015

VMvSphere - protect your critical applications (7 of 10)

Protect your loved ones.

Your loved ones are typically your critical applications.  These applications are the ones that really need to be available 24/7 and their associated Service levels must be met.  Typically strict financial penalties are involved if such SLA's are breached and events such as loss of service / loss of business are experienced, e.g. if you are an online trading application and your critical application goes down preventing users or customers from accessing  your website and purchasing your products or services. 

What are the implications? How long has it been down? Why is it down?  Is it because you haven’t provisioned enough capacity and you are experiencing poor performance?  How much money will you be losing during the time that application is down?

Your critical applications or "loved ones" should be given the highest priority.  This is achieved through resource pool shares.  Remember that shares only apply when there is resource contention on the host and highest priority pools will normally have no limits set.  You may also use CPU Affinity to gain some extra performance benefit.

Reservations (guarantees) are most often set for highest priority pools.  This ensures that all of the virtual machines running within that pool across your cluster will be guaranteed the CPU and Memory configured over any other virtual machines that are running within that cluster.

VMware also provide high availability (HA) clusters.  If you lose an ESX host, through some kind of hardware or software failure, the virtual machines on that host will be powered up on another member of the cluster.  Moreover, to mitigate some hardware failures even further and to protect your critical applications, VMware provide Fault Tolerance (FT) which creates a secondary virtual machine from the primary.  This secondary virtual machine runs on a different ESX host within the cluster.  If your primary VM is lost through an ESX host failure your secondary VM running in step with your primary takes over immediately and becomes the primary, providing no loss of service.

A couple of key points; it is only for hardware failure, if you have a blue screen on one you’re going to have a blue screen on another.  Also in vSphere 4.1, any FT VM can only have one virtual CPU configured.

Any trade-offs? Well typically in an organisation you’ll have this "just in case capacity management" mind set and this can impact on some other services.

What do we mean by "just in case"?.  Well what we actually mean is that you overprovision, i.e. just in case we get large peaks and need the extra capacity and I’ll be looking at how this mentality affects the business on Wednesday.
Don't forget to register for my next webinar 'Understanding VMware Capacity

Jamie Baker
Principal Consultant.

No comments:

Post a Comment