pointer

Tag Archives: Cloud

What Types of Virtualization Are Most Vulnerable to Network Blind Spots

Virtualization helps companies to streamline application deployment, simplify IT operations, and allow IT organizations to respond faster to changing business demands. However, there is a downside when it comes to network analysis. Virtualization introduces network blind spots – areas of application traffic that never cross a physical network interface – which is the typical connection point for network analysis systems.

There are ways to make these network blind spots visible, but to get the right prescription you need to first determine the type of virtualization that needs to be addressed.

Standalone VM Systems
Standalone VM systems have multiple VM guests, but a single VM host. The host is the physical hardware, while the guests refer to the virtual machines running inside of the physical server that can be used to run various applications which share the overall hardware platform. Standalone VM systems are how virtualization got started, and this is probably still the most common type of virtualization in the market. In standalone VM systems you may have one or more virtual network interfaces (vNICs) per guest and one or more physical network interfaces (pNICs) per VM host, creating a complex flow of both virtualized traffic and physical traffic.

A blind spot will occur in standalone VM systems when processes are communicating between different guests inside the same overall physical system. To remedy this, you’ll want to run additional software, like OmniVirtual, as a part of the virtual system to gain access to the traffic crossing the virtual NICs. This will capture inter-VM traffic and provide you with the visibility necessary to properly analyze both your network and application performance.

Coordinated/Distributed Virtualization
In the case of coordinated or distributed virtualization, the system consists of multiple VM hosts connected via a virtual distribution layer, making both inter-VM guest and inter-VM host traffic invisible to traditional network analysis techniques.

To address this more complex situation, a virtual tap is necessary. This is software that acts like a traditional hardware network tap, running at the level of the hypervisor. It allows users to tap into the vNICs and virtual switches that are connecting the various hosts, and gain access to the packet streams of interest for detailed network analysis. Since the virtual tap runs in the VM layer itself, it is typically vendor-specific so keep that in mind when researching virtual taps. Once a virtual tap is in place, network recorders like WildPackets TimeLine or Omnipliance Core can be connected to the virtual tap and capture network and application traffic as if physically connected to the virtual layer.

Cloud
There are three different cloud scenarios, two of which have similar blind spot remedies to our previously mentioned ones in the sections above: in-house and third party. For an in-house cloud server, this is similar to distributed virtualization in that you’ll have physical access to your systems and can add technologies like virtual taps. For a third-party cloud solution, or Infrastructure as a Service (IaaS), you can install your own software – like OmniVirtual – to perform network analysis on remote VM hosts.

The only time when it is truly difficult to perform network analysis in the Cloud is in the case of Software-as-a-Service (SaaS), or hosted services. Here, you are essentially at the mercy of the service provider, as you will not have access to virtual servers to install software of your own.

Regardless of your network virtualization type, there is almost always a solution to gain full visibility into your network. Just follow the steps above or watch our ondemand webcast for further details.

The Cloud: Are You Getting What You Paid For?

Amazon’s AWS was initially created to rent out spare computer power that was only needed during peak times like Cyber Monday, and has since evolved into a service to help other companies during those same crunch times. The convenience of AWS sparked the current wave of Cloud as a scalable and potentially inexpensive way of hosting on-demand computer resources, including many popular websites, streaming video services, and countless number-crunching applications.

While debate rages about what kinds of workloads are appropriate for the cloud, and how (and whether) to migrate applications there, many people don’t realize that answers are available using standard packet capture techniques, even in Cloud environments. Network engineers, running local packet captures on Infrastructure-as-a-Service (IaaS) instances, can provide real numbers on application performance, which will help drive deployment tuning and answer the question of whether the Cloud is really worth the cost.

Local Packet Capture
AWS and many other Cloud providers give customers IaaS, which is essentially a full VM. That means that full packet capture is possible, albeit with some restrictions. The AWS network doesn’t allow promiscuous mode, and there’s some evidence that they’re using a modified form of Proxy ARP. However, non-promiscuous packet capture is a valuable source of networking data for traffic to and from the VM, which allows black box testing of application performance and end-user experience.

When running a linux-based cloud VM, the tcpdump utility will capture packets. Here’s what that would look like:

cloud-vm# tcpdump –p –i eth0 –w capture.pcap

While many people are familiar with tcpdump, not all are familiar with the “-w” flag, which causes tcpdump to write all packets that it captures to a local pcap-format file.  This pcap file can either be locally processed on the VM, or exported and viewed with OmniPeek. Also note the “-p” flag, which tells tcpdump to capture in non-promiscuous mode, i.e. only capture the packets to and from this VM.

If you’re using a Windows-based cloud VM, then WildPackets makes your job even easier. You can deploy OmniVirtual for direct access to those packets from OmniPeek, or use OmniPeek Remote Assistant for a cost-effective way to create encrypted packet capture files on-demand on remote systems.

End-User Experience
It’s possible to judge how well a service is performing from an end-user’s perspective by measuring the application latency at the server from a network perspective. While we go into this in depth in some of our other blog posts, the key is to measure the time between when the user’s request is received and when the server sends the response. It’s a lot easier to do this with the Compass dashboard, which started graphing application latency automatically in OmniPeek version 7.

Application latency correlates with the end-user experience, because it indicates the absolute fastest rate that end users can start receiving their data. If the number is nice and fast, then the cloud VM is doing its job well, indicating that there’s not a need to deploy additional VMs to make the service faster.

Finding the Source of Slowness
If the end-user experience looks poor, based on the application latency measurement, then it’s time to look for root causes for the slowdown. Packet capture can help here too.

Most cloud-based applications are designed using Service-Oriented Architecture (SOA), which breaks the application apart into separate but interconnected modules. The classic example is a multi-tiered web site, with a static front end, dynamic middleware, and database. If the database is slow to return data to the middleware, then the entire application will run slowly.

If your cloud-based application is built with SOA principles to rely on external modules, then you can perform application latency measurement on your database queries, AJP requests, and other connectors between the different layers. That means that, in just a few minutes, you can not only measure how well your application is responding to your users, but also determine which layer of the SOA application is causing the current slowdown.

Cloud-based services have trained engineers to rely on dashboards, plug-ins, and server-specific stats to monitor the state of applications, but there’s a lot that packet capture has to offer, even in the IaaS cloud. The hard numbers that you as a network engineer can provide will help your company analyze their decision to run services in the cloud, and determine whether they’re getting their money’s worth.