Making sure your cloud is accessible, at all time,  to end users and administrators is an important task. When looking into a cloud based on VMware vCloud Director there are several things to take into consideration. A VMware vCloud can consist of a lot of components. The mandatory components are the following

• VMware vCenter Server (Typically Windows 2008/2012 or Linux Appliance)
• VMware ESXi hosts
• VMware vShield Manager (Linux Appliance)
• VMware Director cell (Red Hat Enterprise Linux)
• Database Server for vCenter and vCloud Director

Optional Components

• vCenter Chargeback
• vCenter Operations Manager
• vCloud Automation Center
• VMware Orchestrator
• …

You have to think about how you want to protect the mandatory and optional components. I will focus on the mandatory now.

VMware vCenter Server

There are different ways to protect the vCenter Server. But before you think about protection you need to think about how you are going to deploy it. Your first option is am I going with the Windows version or going with the Linux appliance. In most cases people go for the Windows version, and that is definitely the safe bet. One of the things the Linux appliance has against it is only support for external Oracle databases. No MS SQL support.

If you choose the Windows version you have to consider if you are a splitting the vCenter roles up on multiple virtual machines. The roles you are considering are the following: SSO, Inventory Service, vCenter Service and Update Manager. For best performance and scalability you would split it up. But that also means you have to consider how to protect each server.

SSO has its own “clustering” functionality. But Inventory Service and vCenter does not. In most situations the software is installed inside a virtual machine running on a ESXi host with VMware HA enabled. This means you don’t need to worry about physical server failure. But it does not protect you against a failure on the software side that could be related to the Operating System or vCenter itself. If you figure out you want to go beyond hardware failure your only option is to deploy VMware vCenter Heartbeat. Heartbeat is able to protect all servers running SSO, Inventory Service and vCenter Service. It does it by replicating the server to another virtual or physical machine. Heartbeat is the tool if you have very strict SLA agreements. It will make your system more secure, but it will be on the cost of losing simplicity.

ESXi hosts

The ESXi hosts are the easiest to protect, and you don’t have to do a lot of planning in this area. Just make sure you have multiple ESXi hosts. All connected to the same network and access to the same shared storage. This way the virtual machines can gets it compute resources from any host in the cluster. On that cluster you will enable the DRS and HA functionality. I would not even worry about backing up the ESXi hosts. If you lose a host just reinstall it.

VMware vShield Manager

The vShield Manager comes as a virtual appliance from VMware. You simply download it and import into your management cluster. There is no native clustering functionality so you have to rely on VMware HA or VMware Fault Tolerance.

VMware Director Cell

The vCloud Director software has to be installed on a Linux machine running Red Hat Enterprise. Luckily for us the software has its own clustering functionality. What you basically do is install multiple Red Hat machines. All of these machine will share the same database on MS SQL or Oracle and the will also have access to the same NFS share. When implementing multiple vCloud Director Cells you would deploy the behind a load balancer. That load balancer could be VMware vShield Edge or you could use something else like Netscaler, F5 etc.

Database Server

The database server is extremely critical in the vCloud Environments. If we are only looking at the mandatory components you will have created three databases on your server. One for the SSO service, One for the vCenter Service and One for the vCloud Director Cell.

What you would normally do with your database is to look into clustering the MS SQL or Oracle with its own tools. If you don’t want to cluster the database. At least make sure that it is running as a virtual machine so you get the benefit of VMware HA. And of course remember to backup all databases at a regular interval.

If you are using a MS SQL cluster you have to know that it is not “officially” supported by VMware for the SSO service. Although they will do their best to help you if you have problems. I have installed all of the components against a MS SQL Cluster and haven’t experienced any problems yet. But we aware of this and set it as a risk.

1. Visit the following website: http://www.vmworld.com/cfp.jspa
   
2. Log in with your VMworld account
3. Vote for the following sessions
   1. 4555 vCenter Operations Manager – Troubleshooting Best Practises
   2. 4799 From vSphere to Hybrid Cloud – Best Practises

The title of the first session is: “vCenter Operations Manager – Troubleshooting Best Practises” #4555. I did a session at the danish VMUG March 7th and it was very well received by the audience. This gave me the confidence that it was ready for a bigger audience and I have submitted it for VMworld US and VMworld Europe. 

The second session is: “From vSphere to Hybrid Cloud – Best Practises” #4799. This is a session I have submitted with Michael Munk Larsen from Zitcom. In this session we are going to be talking about the move from vSphere to the hybrid cloud, and discuss the challenges and how to build the hybrid cloud.

Hopefully one or both of the sessions will be accepted. I know it is extremely hard to get sessions approved, but I keep my fingers crossed. In a few weeks I expect the public voting to start, and during the public voting I need your help to get attention to the sessions.

The first thing you need to do is list your devices. Everything is done from the local ESXi shell:

esxcli storage nmp device list

This gave me the following output. The information you need to look for is the “device id” and the “satp”

The next thing we can do is to mark the device as “Local” and “SSD”. I used the following command:

esxcli storage nmp satp rule add –satp VMW_SATP_LOCAL –device mpx.vmhba2:C0:T0:L0 –option “enable_local enable_ssd”

Then we have to claim the new rule:

esxcli storage core claiming reclaim -d mpx.vmhba2:C0:T0:L0

And at the end we can run the following command to verify our changes:

esxcli storage core device list –device=mpx.vmhba2:C0:T0:L0

After doing this ESXi detected the disk as a Local SSD and I could start working in my lab.

The Performance Graphs in vCenter can show information about the following CPU, Datastore, Disk, Memory, Network, Power, System, Virtual disk. You can the select if you want the graph to show: Real-time, Past day, Past week, Past month, past year or Custom. 

 When looking at these graphs the following table sums up what you are seeing.

So by looking at the Real-Time graph you actually looks at a graph that is updated by a frequency of 20 seconds. So 180 datapoints in just one hour. But when you look at Past Day your graph is updated every 5 minutes. This is where rollup occurs. Without rollup you vCenter database would grow a lot in size. Whatever data you look at in the Past Day the graph is updated in 5 minutes interval, but what happens if you look at the graph more than 24 hours ago? Well if it is in the past week your graph will be updated every 30 minutes, but if you are further back your graph is updated every 2 hours! This basicly tells us that vCenter Performance Charts is BEST in Real-Time, it is alright in Past Day but moving further back than 24 hour data is being rolled up and we loose valuable insight. Look at the following screenshots to see what happens:

You should have noticed how we lose information when we try to investigate performance back in time. The further back we go the more we lose. Not only does data points get rolled up. But try and go back to the first graph. On the first graph we had the counters “Ready” and “Used” but on the other two we only have “Ready”. No I did not remove it. This is another feature of vCenter. Not only does it roll up. But it also chooses to remove counters as soon as we are looking at data more than one hour ago.

Now you should know some of the limitation with vCenter. So what is the solution if you want to look at data that is 1) More than one hour ago or 2) more than one day ago. The answer is of course vCenter Operations Managers Metric Charts. vCenter Operations Manager collects every counter and does not remove them when looking back. And vCenter Operations Manager have data points every 5 minutes. So yes you can argue that the past hour graph in vCenter is better than vCenter Operations Manager! That is true. The only time you actually should use vCenter Performance Graphs is when looking at the “Real-Time” graph.

Lets take a look in vCenter Operations Manager:

The graph is for the “Last Hour” but I can dive into any period and see all counters updated every 5 minutes. Maybe it is monday morning now and we have a reported performance problem that happened this saturday between 2am and 3am. Well just change the graph to that interval. Data is there, and you have EVERY counter. 

• June 13th VMUG meeting at VMware in Nærum. This is an Annual event and after the meeting there is a tradition of home brewed beer and BBQ!
• December 3rd. VMUG meeting in Copenhagen @ Bella Centeret. This is the same place as VMworld Europe took place in 2010 and 2011. This VMUG will be a full day conference with 25-30 sessions. They hope to get at least 300 delegates. And of course it is free! So save these two dates. I hope to see you there.

Just click the vote button.

You can register for the event here: http://www.eventbrite.com/event/5299404662#

The subject will be “Admin and Monitor”. I will be doing a 50 minutes presentation on “vCops Best Practises” (still working on the title)

After the event you will get tickets for the move “The Last Stand”. 

I can’t wait! Hope to see you all there!

To understand how it is calculated is just one thing. What is more important is what you do with the sizing recommendation. Even though Operations may find a machine to be oversized it does not necessarily make it true. 

First thing you will need to do is go into “configuration” from the vC Ops website. Here you can configure the thresholds for oversized and undersized VM’s. The settings in the screenshot is right now at default. I have made some marks in the screenshot. “1. Oversized threshold: 1%“, “2 CPU deman less than: 30%“, “3 Memory deman less than: 30%“

What this means is that if a virtual machines is using less than 30%CPU or 30%Memory for 1% of its running time it is considered oversized. Actually it is not based on time. But it is based on “Area” Look at the next screenshot. The threshold of 30% is the “U” and the threshold of 1% is the blue area. So if the area of the blue is more than 1% of the graph it will be considered oversized.

With the default settings of 30% CPU/Memory and oversized threshold of 1% I bet you are going to have A LOT of virtual machines that are considered oversized. For instance if you have some machines who are idling most of the time but in peaks need LOTS of CPU they will definitely be considered oversized even though from the administrator perspective it is not.

I would change the settings for the threshold. Per default you get way too many oversized virtual machines. I recommend the following:

• Oversized Threshold: 10%
• CPU Demand less than: 15%
• Memory Demand less than: 15%

 With these settings a virtual machine is oversized if the area on the graph below the threshold “U” (15% CPU/MEM) is 10% or higher. This is just one recommendation, you can tweak the setting to your own liking.

I think they will have a new draw after this, so check back and see what else you can win.

http://go.veeam.com/cool?ad=home