Let’s assume that you have already found the right way to capture traffic inside your virtualized data center (if not, we recommend that you first take a look at the following article “Virtual data center traffic capture and troubleshooting”), you now have to determine how you are going to analyze this traffic.

Virtualized data center traffic capture and troubleshooting

At this level, virtualization will bring a certain number of constraints and you cannot simply apply the same network traffic analysis solutions that you had running on a physical network.

Here are the options, constraints, and prerequisites you should consider when attempting to troubleshoot performance in a virtualized data center. 

Option 1: use a traditional network capture appliance

Once you have defined a way to capture traffic inside your virtualized data center, you can still rely on your good old traffic capture appliance to perform the performance analysis (with all of the traffic capture solutions listed above : promiscuous mode, advanced virtual switch SPAN, Virtual TAPs – see this article to see what is the best way).

Your next challenge will be “how to transfer that traffic from inside the virtualized data center to your old physical appliance?”.

If you consider doing this on one virtualization host, it sounds doable, but pay attention to the following constraints if you plan on rolling out your solution in your whole data center:

• Network capacity on the physical NICs of your virtualization hosts: if you are sending raw traffic capture outside the virtualization host, plan for large capacity and hence dedicated network interfaces (which usually do not exist, which means you will have to change your architecture to do that).
• Aggregating the traffic from all the virtualization hosts: you will have as many capture interfaces as you have virtualization hosts; there are two possibilities:
  • Your network analysis device has that number of interfaces (this is unlikely to happen!)
  • The traffic is aggregated by a network packet broker with as many 10Gbps interfaces as you have ESX hosts.
• Traffic deduplication: remember that you may generate duplicate traffic (i.e., all the traffic transferred from ESXa to ESXb will be captured in both ESXa and ESXb). You need to plan to have a deduplication capability either inside your network packet broker or integrated with your traffic analysis device.

Option 2: using a performance management solution which integrates natively with a virtualized data center

The alternative is to run the traffic analysis inside the virtualized data center and not have to deal with extracting traffic to the outside world. This is a smart idea and it works provided that your solution NATIVELY integrates into your virtualized data center.

Here are the criteria of a native integration:

• The licensing allows you to place as many virtual capture appliances as you have virtualization hosts (to avoid overloading your hosts with captured traffic sent from one to another)
• Having the capture appliance using a reasonable amount of resources (CPU, RAM, Disk) inside each virtualization host
• You have packet deduplication capabilities to compensate for the flaws of SPAN
• Making sure that the centralization of data for reporting purposes consumes a reasonable amount of network capacity.

This is precisely what SkyLIGHT PVX delivers to make sure performance management inside virtual and cloud data center is easy to implement.