Capacity Management,Telling the Story (1 of 17)

In Capacity Management we need to produce reports and make presentations, sometimes to our technical colleagues and sometimes to more senior people. 

In this blog series I’m going to be discussing the best ways to present technical information, your capacity management story, to all levels of audience.

To begin with what is a Story?

It is either:

a : an account of incidents or events, either fact or fictional

b : a statement regarding the facts pertinent to a situation in question

Data is nothing more than 1’S and 0’s. It’s what we do with it that makes it powerful.

We can collect or capture as much data as we want to from our systems, from our business level, from our service delivery level and store it but it’s what we do with this data that is the important thing.

Data used in a meaningful way is very powerful.

My series will look at ways in which you can tell your capacity management story to your audience in a meaningful way.

On Wednesday I'll begin with 'What is the Capacity Management story'?

In the meantime sign up and come along to one of our Capacity Management workshops.
http://www.metron-athene.com/services/online-workshops/index.html

Charles Johnson

Principal Consultant

Top 5 Dont's for VMware

As promised today I’ll be dealing with the TOP 5 Don’ts for VMware.

DON’T

1)       Overcommit CPU  (unless ESX Host usage is less than 50%)

I’m sure that most of you have heard of CPU Ready Time. CPU Ready Time is the time spent (msecs) that a guest vCPUs are waiting to run on the ESX Hosts physical CPUs.  This wait time can occur due to the co-scheduling constraints of operating systems and a higher CPU scheduling demand due to an overcommitted number of guest vCPUs against pCPUs.  The likelihood is that if all the ESX hosts within your environment have on average a lower CPU usage demand, then overcommitting vCPUs to pCPUs is unlikely to see any significant rise in CPU Ready Time or impact on guest performance.

2)       Overcommit virtual memory to the point of heavy memory reclamation on the ESX host. 

Memory over-commitment is supported within your vSphere environment by a combination of Transparent Page Sharing, memory reclamation (Ballooning & Memory Compression) and vSwp files (Swapping).  When memory reclamation takes place it incurs some memory management overhead and if DRS is enabled automatically, an increase in the number of vMotion migrations. Performance at this point can degrade due to the increase in overhead required to manage these operations.

3)       Set CPU or Memory limits (unless absolutely necessary). 

Do you really need to apply a restriction on usage to a guest or set of guests in a Resource Pool?  By limiting usage, you may unwittingly restrict the performance of a guest.  In addition, maintaining these limits incurs overhead, especially for memory, where the limits are enforced by Memory Reclamation.  A better approach is to perform some proactive monitoring to identify usage patterns and peaks, then adjust the amount of CPU (MHz) and Memory (MB) allocated to your guest virtual machine.   Where necessary guarantee resources by applying reservations.

4)       Use vSMP virtual machines when running single-threaded workloads. 

vSMP virtual machines have more than one vCPU assigned.  A single-threaded workload running on your guest will not take advantage of those “extra” executable threads.  Therefore extra CPU cycles used to schedule those vCPUs will be wasted.

5)       Use 64-bit operating systems unless you are running 64-bit  applications. 

Whilst 64-bit operating systems are near enough the norm these days, do check that you need to use 64 bit as these require more memory overhead than 32-bit.  Compare the benchmarks of 32/64-bit applications to determine whether it is necessary to use the 64-bit version.

We're running a webinar on VMware Capacity Management on May 25th visit our website and sign up to come along.

http://www.metron-athene.com/services/webinars/index.html

Jamie Baker

Principal Consultant

Performance concerns - Top 5 Key Capacity Management Concerns for Unix/Linux (5 of 12)

Just think about this for a moment – it’s just you and your workstation.  No contention.  Introduce a server which hosts one or many applications and can be accessed by one or many users simultaneously and you are likely to get contention.  Where contention exists you get queuing and inevitably response times will suffer.

With UNIX/Linux virtualization we have two main concerns: 

1) Will virtual systems hosted on shared hardware (via Hypervisor) will impact one another?

2) What additional overhead and impact on performance does requesting hardware resources through a hypervisor cost?

To answer question 1, we have to understand what resources each virtual machine is requesting at the same time.  So it's prudent to produce performance reports for each hosted VM. 

Do they conflict with each other or complement each other? There are virtualization tools that have been developed to keep VMs apart if they conflict and together if they complement to improve performance.

To answer question 2, initial software virtualization techniques such as Binary Translation allowed for existing x86 operating systems to be virtualized.  The hardware call request had to go via the hypervisor thus adding on an additional overhead, somewhere between 10-20% on average.  As time progressed a combination of hardware virtualization and paravirtualized operating systems have reduced overhead and improved virtualized application response times.

Paravirtualization is built in to all recent Linux kernels. For those that don't know what paravirtualization is it's a virtualization technique that presents a software interface to VMs that is similar, but not identical to that of the underlying hardware. The intention is to reduce the guest's execution time spent performing operations which are substantially more difficult to run in a virtual environment compared to a non-virtualized environment. It provides specially defined 'hooks' to allow the VMs and underlying host to request and acknowledge these tasks, which would otherwise be executed in the virtual domain (where execution performance is worse). A successful paravirtualized platform may allow the virtual machine monitor (VMM) to be simpler (by relocating execution of critical tasks from the virtual domain to the host domain), and/or reduce the overall performance degradation of machine-execution inside the virtual-guest.

To produce and analyze the recommended performance reports we need to capture and store performance data and I'll be discussing this on Monday.

Sign up to our Community where you'll gain access to some great white papers and downloads of our webinars

http://www.metron-athene.com/_resources/index.html

Jamie Baker

Principal Consultant