Monthly Archives: March 2015

What vSphere configuration can you track?

With vRealize Operations 6, VMware has added Configuration Management capability to the core platform. I covered some of them here. My advice is to use the integrated vRealize Operations to do your configuration management. If there are items that cannot be covered, then you review the classic vRealize Configuration Management. It provides a much broader set of properties that can be tracked.

How do you know what it can track? It’s all listed in the manual 🙂

Open the online manual. You will get a screenshot like below.

10

Expand the table of contents until you see vCenter. In the screen below, I’ve expanded it. As you can see, what you can track in vCenter is also listed in the content area.

VCM can track VM, Host, Cluster, Datastore, Folder, Network, and vCenter itself.

Let’s say you want to see what VM properties you can track. Expand the vCenter Guests. vCenter Guest is VM. As you can see below, there are many properties of a VM that you can track.

11 VM

Let’s see some of them. Expand the Guest Summary, and the content will be shown on the right portion of screen. Now, to see the actual properties, you need to click the “View the columns and descriptions” link. I’ve marked it with a large number 2. It will expand, and show you all the properties, together with their description.

12 VM

It’s a pretty long list, so you need to scroll to see the complete list.

13 VM

A VM has many properties. What if you want to see the Networking properties? Click on the vCenter Guest Network link. Again, don’t forget to expand (see the large number 2).

14 VM - network

The above is for VM. What about other objects? Where is Cluster, Folder, Data Center, for example?

Well, they are a part of vCenter Inventory, so that’s where you find them. See screenshot below. Again, don’t forget to click the link to expand 🙂

15 Cluster - it is under Inventory

That’s it. Hope you find it useful.

Capacity Management based on Business Policy – Part 2

Part 1 explained a new concept, where we added Availability SLA and Performance SLA as the basis of Capacity Management. In this part, I will now provide the formula for each charts. We will cover Tier 1, followed by Tier 2 and 3.

You should be performing capacity planning at Cluster level, not Data Center or Host level.

Compute (Tier 1)

To recap, we do not have over-subscription in Tier 1. We only have it in Tier 2 and 3. As a result, it becomes simpler, as we are following Allocation model essentially.

Availability Policy

Super Metric Formula: Max no of allowed VM in 1 cluster – No of VM in the cluster

  • Apply the Availability policy at cluster level since it makes more sense. Applying at ESXi Host level is less applicable due to HA. Yes, the chance of a host going down is higher than entire cluster going down. However, HA will reboot the VMs, and VM owners may not notice if service is not affected. On the other hand, if a cluster goes down, it’s a major issue.
  • The limitation of this formula is it assumes your cluster size may vary. This is a fair assumption. You should keep things consistent. If for some reasons you have say 3 cluster sizes (e.g. 8, 10, 12), then you have 3 super metrics.

CPU

Supply: Total physical cores of all ESXi Hosts – HA buffer

  • We can choose physical Core or physical Threads. One will be conservative, while the other aggressive. Ideal number is 1.5 of physical core. My recommendation: take the core, not the Threads. This is because it is Tier 1, your highest & best tier.
  • Threshold: 10% of your capacity, as it takes time to buy cluster (which also needs storage). You are also not aiming to run your ESXi at 100% utilization.
  • We do not have to build your threshold (which is your buffer actually) into the super metric formula as it’s dynamic. Once it’s hard coded in the super metric, changing it does not change the history. It is dynamic because it depends on business situation. If there is a large project going live in a few weeks, then your buffer needs to cater for it. This is why we need to stay close to the business. It’s also something you should know, based on your actual experience in your company. You have that gut feel and estimate.

Demand: Total vCPU for all the VMs.

  • If we are using virtual threads in your VM, then count them as if they are a full vCPU. For example, a VM with 2 vCPU and 2 threads per core should be counted as 4 vCPU.

RAM

Supply: Total physical RAM of all ESXi Hosts – HA buffer

  • No need to include ESXi vmkernel RAM as it’s negligible. If you are using VSAN & NSX, you can add some buffer. You do not need to include virtual appliance as they take the form of a VM, hence it will be included in the Demand.
  • Threshold: set the name number, which is 10% in this example.

Demand: Total vRAM for all the VMs

Network

Super Metric Formula: Max (ESXi Host vmnic utilization) in the cluster

This number has to be below your physical capacity. Ideally, it has buffer so it can handle spike from network intensive events.

Summary

  • The above formula is all you need for Tier 1.
  • In emergency, temporary solution, you can still deploy VM while waiting for your new cluster to arrive. This is because you have HA buffer. ESXi host is known for its high uptime.

Tier 2 and 3

Tier 2 and 3 will be different, as there is oversubscription. Since we overcommit CPU and RAM, we can no longer use allocation model. We need to take into account performance.

  • Super Metric Formula: Maximum (VM CPU Contention) in the cluster
  • Super Metric Formula: Average (VM CPU Contention) in the cluster
  • Super Metric Formula: Maximum (VM RAM Contention) in the cluster
  • Super Metric Formula: Average (VM RAM Contention) in the cluster

For the total number of VM left in the cluster, see Tier 1. It’s the same formula, just a different policy. You have higher threshold naturally.

For the ESXi vmnic utilization, see Tier 1. Identical formula is used.

Conclusion

Indeed, a few line charts is all you need to manage capacity. I am aware it is not a fully automated solution. However, my customers found it logical and ease to understand. It is following an 80/20 principle, where you are given the 20% room to make the judgement call as the expert.

To see the actual super metric examples, proceed to part 3.

A storage array built purposely for VM only

VMware VSAN demonstrates that you can make storage easier to setup for VMware Administrators. It’s directly integrated with vSphere, with no additional installation. It is purpose built for vSphere.

VSAN is a form of distributed storage, an architectural departure from central array. I certainly like the idea that my data is not put in 1 basket. However, there are thousands of array out there, so there are bound to be customers who want or need a central array. What if your physical Storage array is purpose built for VM? This means it does not support physical servers. Nope, it does not support RDM either. Only VM and its vmdk. What are some of the complexity that can be taken away, making it easier for VMware Admin to master it?

What I like about such storage array is not just what is there, but what is not there.

I had the pleasure playing with Tintri T820. They have kindly loan a unit in VMware ASEAN Lab. It’s a 4RU box. Racking and cabling took only a few minutes. Both Tintri and PTC (our joint reseller) were on site when we set it up, but they let me do the bulk of the setting. No, I did not want to read the manual as I wanted to see how easy it is.

There is no complex cabling connecting the different component of the array. It just have 2 power cable, 2 10GE cable for data, and a few 1 GE cables for replication and management. That’s it! It reminds of me ESXi server.

We booted up. To my surprise, GRUB loaded. Linux then loaded, as you can see below. This feels like a server.

DSC_0542

We waited for it to load. It then prompts the following screen, where I keyed in the IP address and host name. And that’s all it asked.

DSC_0544

Once we got the IP address, it’s all web based, as shown below. There is a one time setup, which is much longer. But the questions are pretty straight forward.

00 - 3

And apparently we’re done with the configuration! I was asked to then create an NFS datastore. Tintr’s recommendation is to present 1 datastore. So I created a datastore as per below. From the screen below, you can see I have 3 vCenter Servers. That means the same Tintri datastore is mounted 3x.

Once mounted, I started migrating VM to it, so I can see some data in Tintri.

00 - 52

Using web browser, we login to Tintri. No annoying Java required. Also, no installation of management software. Just a browser. Below is the main screen. The dashboard tab is the main tab. I’ve already loaded many VMs, as you can see on the right side of the screen.

00 - 4-1

Look at the above screen carefully. Can you see what’s not there? There is no the usual storage concept or object such as LUNs, Volume, Slice, Pools, Aggregate, etc. There is also no choice of interface or protocol. There is no FC, FCoE, iSCSI. Only NFS. The entire array is 1 giant pool of 1 datastore. This is like VSAN, as VSAN also presents 1 datastore.

The next tab is “Virtual Machine”. It has a few sub tabs, which allows you to drill down. The columns on the screen are sortable. You can also filter each column. In the following screen, I have sorted the table by Latency.

00 - 4-2

You can drill down into Virtual Disk! In the screenshow below, I again sorted by latency.

If you look at the Provisioned column, you will see an example of filtering.

00 - 4-21

The next tab is VMStore. In here, you can see performance and other information. My performance was capped at 1 Gb as the ISL between the 2 switches in the lab is 1 Gb.

00 - 4-25

If you have multiple Tintri boxes, you can see them all on 1 dashboard. You need to deploy a vSphere appliance. Again, only took a few minutes to set up. Below is a screenshot from Tintri global center.

00 - 4-29

You might have noticed the Settings link near the top right of the screen. If you guess this is where you edit all the settings, you are right. It just a dialog box. Most of them are pretty self explanatory.

00 - 51

I almost forgot we’re dealing with physical array here! You can bring up a hardware tab. From here, you can see that the box has 24 physical disks, with 14 (yes, 14) being SSD. You can also see that it has 3 networks (Management, Data, Replication).

00 - 4-27

No setup is complete without installing syslog as we need to analyse it. From the Settings dialog box, you configure the target syslog. I specified my Log Insight, and you can see Tintri sends its log. I’d like to see Performance log, and I’ve asked Tintri if this can be done.

00 - 7

And that’s basically it. I’m deeply impressed with its simplicity.