Sunday, May 8, 2011

NetFlow lite

Netflow-lite is a recently released packet sampling technology for the Cisco Catalyst 4948E Ethernet switch. The technology is described in Configuring Netflow-lite and at first glance Netflow-lite appears to be random 1 in N packet sampling, exporting sampled packets as IPFIX or Netflow V9 records.

However, looking more closely, the following description raises some questions:

The packet sampling mechanism tries to achieve random 1-in-N sampling. The accuracy of the algorithm is dependent on the size of the packets arriving at a given interface. To tune the relative accuracy of the algorithm, use the average-packet-size parameter. The whole system supports a maximum of 200 monitors.

The system automatically determines the average packet size at an interface based on observation of input traffic and uses that value in rate DBL sampling.


The acronym DBL refers to Cisco's Dynamic Buffer Limiting, a technology for congestions avoidance (see Quality of Service on Cisco Catalyst 4500 Series Supervisor Engines, page 16, for a description). It is clear that the 4948E doesn't have hardware support for 1 in N packet sampling. Instead, an estimate of average packet size is required to allow hardware designed for monitoring data rates to be used to select packets to sample.

This mechanism raises red flags regarding Netflow-lite accuracy, particularly in a data center top of rack setting where 4948E switches are intended to be deployed:
  1. Average packet size. Average packet sizes are highly variable. For example, network storage traffic generates large data packets (as large as 9000 byte jumbo frames) in one direction and small acknowledgement packets in the other (as small as 64 bytes).  Further complicating matters, traffic patterns change quickly, for example changing from storage read to write operations. Thus, the estimate of average packet size from one interval is likely to be a poor estimate of the packet size in the next interval, resulting in large errors in the Netflow-lite measurements. Finally, each class of traffic has its own characteristic packet size distribution. Relying on a single average packet size estimate to control sampling is likely to bias results for classes of traffic that have smaller or larger average packet sizes.
  2. Time. The rate based mechanism of DBL introduces time into the sampling process (since rates are a measure of traffic over some time interval). Time-based sampling methods yield inaccurate results for many typical network traffic patterns.
Before relying on Netflow-lite measurements, it is prudent to run tests to verify accuracy in a production setting. Testing accuracy using a traffic generator is likely to mask errors that will be apparent when monitoring the irregular traffic patterns seen in a production setting.

Netflow-lite exposes an important difference between IPFIX/NetFlow and sFlow. While IPFIX/NetFlow specify the format of data transmitted from a measurement device to a collector, they do not specify how the measurements should be made. The result is that seemingly identical data from different vendor's switches (or even different models of switch from a single vendor) can represent measurements made using very different methodologies. These differences make it very difficult to rely on the measurements or compare data between different devices. In contrast, sFlow standardizes how traffic is measured, ensuring that every device supporting the sFlow standard performs sampling in a standard way, yielding accurate and consistent results.

The article, Complexity kills, describes how sFlow's standard measurements simplify large scale monitoring of data center traffic. Accurate traffic measurements are increasingly important as convergence and virtualization place greater demands on network capacity. For additional information, the Data center convergence, visibility and control presentation describes the critical role that measurement plays in managing costs and optimizing performance.

Wednesday, May 4, 2011

Tomcat


The tomcat-sflow-valve project is an open source implementation of sFlow monitoring for Apache Tomcat, an open source web server implementing the Java Servlet and JavaServer Pages (JSP) specifications.

The advantage of using sFlow is the scalability it offers for monitoring the performance of large web server clusters or load balancers where request rates are high and conventional logging solutions generate too much data or impose excessive overhead. Real-time monitoring of HTTP provides essential visibility into the performance of large-scale, complex, multi-layer services constructed using Representational State Transfer (REST) architectures. In addition, monitoring HTTP services using sFlow is part of an integrated performance monitoring solution that provides real-time visibility into applications, servers and switches (see sFlow Host Structures).

The tomcat-sflow-valve software is designed to integrate with the Host sFlow agent to provide a complete picture of server performance. Download, install and configure Host sFlow before proceeding to install the tomcat-sflow-valve - see Installing Host sFlow on a Linux Server. There are a number of options for analyzing cluster performance using Host sFlow, including Ganglia and sFlowTrend.

Next, download the tomcat-sflow-valve software from http://tomcat-sflow-valve.googlecode.com/. The following steps install the SFlowValve in a Tomcat 7 server.

tar -xvzf tomcat-sflow-valve-0.5.1.tar.gz
cp sflowvalve.jar $TOMCAT_HOME/lib/

Edit the $TOMCAT_HOME/conf/server.xml file and insert the following Valve statement in the Host section of the Tomcat configuration file:

<Host>
...
  <Valve className="com.sflow.catalina.SFlowValve" />
</Host>

Restart Tomcat:

/sbin/service tomcat restart

Once installed, the sFlow Valve will stream measurements to a central sFlow Analyzer. Currently the only software that can decode HTTP sFlow is sflowtool. Download, compile and install the latest sflowtool sources on the system your are using to receive sFlow from the servers in the Tomcat cluster.

Running sflowtool will display output of the form:

[pp@test]$ /usr/local/bin/sflowtool
startDatagram =================================
datagramSourceIP 10.0.0.111
datagramSize 116
unixSecondsUTC 1294273499
datagramVersion 5
agentSubId 6486
agent 10.0.0.150
packetSequenceNo 6
sysUpTime 44000
samplesInPacket 1
startSample ----------------------
sampleType_tag 0:2
sampleType COUNTERSSAMPLE
sampleSequenceNo 6
sourceId 3:65537
counterBlock_tag 0:2201
http_method_option_count 0
http_method_get_count 247
http_method_head_count 0
http_method_post_count 2
http_method_put_count 0
http_method_delete_count 0
http_method_trace_count 0
http_methd_connect_count 0
http_method_other_count 0
http_status_1XX_count 0
http_status_2XX_count 214
http_status_3XX_count 35
http_status_4XX_count 0
http_status_5XX_count 0
http_status_other_count 0
endSample   ----------------------
startSample ----------------------
sampleType_tag 0:1
sampleType FLOWSAMPLE
sampleSequenceNo 3434
sourceId 3:65537
meanSkipCount 2
samplePool 7082
dropEvents 0
inputPort 0
outputPort 1073741823
flowBlock_tag 0:2100
extendedType socket4
socket4_ip_protocol 6
socket4_local_ip 10.0.0.150
socket4_remote_ip 10.1.1.63
socket4_local_port 80
socket4_remote_port 61401
flowBlock_tag 0:2201
flowSampleType http
http_method 2
http_protocol 1001
http_uri /favicon.ico
http_host 10.0.0.150
http_referrer http://10.0.0.150/membase.php
http_useragent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleW
http_bytes 284
http_duration_uS 335
http_status 404
endSample   ----------------------
endDatagram   =================================

The -H option causes sflowtool to output the HTTP request samples using the combined log format:

[pp@test]$ /usr/local/bin/sflowtool -H
10.1.1.63 - - [05/Jan/2011:22:39:50 -0800] "GET /membase.php HTTP/1.1" 200 3494 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleW"
10.1.1.63 - - [05/Jan/2011:22:39:50 -0800] "GET /favicon.ico HTTP/1.1" 404 284 "http://10.0.0.150/membase.php" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleW"

Converting sFlow to combined logfile format allows existing log analyzers to be used to analyze the sFlow data. For example, the following commands use sflowtool and webalizer to create reports:

/usr/local/bin/sflowtool -H | rotatelogs log/http_log &
webalizer -o report log/*

The resulting webalizer report shows top URLs:


Finally, the real potential of HTTP sFlow is as part of a broader performance management system providing real-time visibility into applications, servers, storage and networking across the entire data center.

Friday, April 29, 2011

Amazon EC2 outage


Amazon cloud glitch knocks out popular websites - Server outage hits sites Reddit, Quora and Foursquare hard, Computerworld, Thursday April 21st, 2011. The article describes the impact of a major three day outage in one of Amazon's Elastic Compute Cloud (EC2) data centers on prominent social networking companies and their services.

The screen shot from the Amazon Service Health Dashboard shows the extent and duration of the failure and the following note that appeared on the dashboard page gives an initial description of the failure:

8:54 AM PDT We’d like to provide additional color on what were working on right now (please note that we always know more and understand issues better after we fully recover and dive deep into the post mortem). A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in US-EAST-1. This re-mirroring created a shortage of capacity in one of the US-EAST-1 Availability Zones, which impacted new EBS volume creation as well as the pace with which we could re-mirror and recover affected EBS volumes. Additionally, one of our internal control planes for EBS has become inundated such that it’s difficult to create new EBS volumes and EBS backed instances. We are working as quickly as possible to add capacity to that one Availability Zone to speed up the re-mirroring, and working to restore the control plane issue. We’re starting to see progress on these efforts, but are not there yet. We will continue to provide updates when we have them.

A detailed postmortem, Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region, was published on April 29.

The failure in this case resulted from interaction between the network and the Elastic Block Store (EBS) storage service. An initial network configuration error resulted in a loss of network capacity that caused the storage service to start replicating volumes, further overloading the network and causing additional disrupted the storage service. A brown out of the network affected not just storage and compute services, but also the control functions needed to recover.

The Amazon failure demonstrates the tight coupling between network, storage and servers in converged cloud environments. Networked storage in particular dramatically increases network loads and must be closely managed in order to avoid congestion.

The sFlow standard provides scalable monitoring of all the application, storage, server and network elements in the data center, both physical and virtual. Implementing an sFlow monitoring solution helps break down management silos, ensuring the coordination of resources needed to manage converged infrastructures, optimize performance and avoid service failures.

Monday, April 25, 2011

NGINX


The nginx-sflow-module project is an open source implementation of sFlow monitoring for the Nginx (pronounced engine x) web server. The module exports the counter and transaction structures discussed in sFlow for HTTP.

The advantage of using sFlow is the scalability it offers for monitoring the performance of large web server clusters or load balancers where request rates are high and conventional logging solutions generate too much data or impose excessive overhead. Real-time monitoring of HTTP provides essential visibility into the performance of large-scale, complex, multi-layer services constructed using Representational State Transfer (REST) architectures. In addition, monitoring HTTP services using sFlow is part of an integrated performance monitoring solution that provides real-time visibility into applications, servers and switches (see sFlow Host Structures).

The nginx-sflow-module software is designed to integrate with the Host sFlow agent to provide a complete picture of server performance. Download, install and configure Host sFlow before proceeding to install nginx-sflow-module - see Installing Host sFlow on a Linux Server. There are a number of options for analyzing cluster performance using Host sFlow, including Ganglia and sFlowTrend.

Note: the nginx-sflow-module picks up its configuration from the Host sFlow agent. The Host sFlow sampling.http setting can be used to override the default sampling setting to set a specific sampling rate for HTTP requests.

Next, download the nginx sources from http://wiki.nginx.org/Install and the nginx-sflow-module sources from http://nginx-sflow-module.googlecode.com/. The following commands compile and install nginx with the sflow-module:

tar -xvzf nginx-sflow-module-0.9.3.tar.gz
tar -xvzf nginx-1.0.0.tar.gz
cd nginx-1.0.0
./configure --add-module=/root/nginx-sflow-module-0.9.3
make
make install

Once installed, the nginx-sflow-module will stream measurements to a central sFlow Analyzer. Currently the only software that can decode HTTP sFlow is sflowtool. Download, compile and install the latest sflowtool sources on the system your are using to receive sFlow from the servers in the nginx cluster.

Running sflowtool will display output of the form:

[pp@test]$ /usr/local/bin/sflowtool
startDatagram =================================
datagramSourceIP 10.0.0.111
datagramSize 116
unixSecondsUTC 1294273499
datagramVersion 5
agentSubId 6486
agent 10.0.0.150
packetSequenceNo 6
sysUpTime 44000
samplesInPacket 1
startSample ----------------------
sampleType_tag 0:2
sampleType COUNTERSSAMPLE
sampleSequenceNo 6
sourceId 3:65537
counterBlock_tag 0:2201
http_method_option_count 0
http_method_get_count 247
http_method_head_count 0
http_method_post_count 2
http_method_put_count 0
http_method_delete_count 0
http_method_trace_count 0
http_methd_connect_count 0
http_method_other_count 0
http_status_1XX_count 0
http_status_2XX_count 214
http_status_3XX_count 35
http_status_4XX_count 0
http_status_5XX_count 0
http_status_other_count 0
endSample   ----------------------
startSample ----------------------
sampleType_tag 0:1
sampleType FLOWSAMPLE
sampleSequenceNo 3434
sourceId 3:65537
meanSkipCount 2
samplePool 7082
dropEvents 0
inputPort 0
outputPort 1073741823
flowBlock_tag 0:2100
extendedType socket4
socket4_ip_protocol 6
socket4_local_ip 10.0.0.150
socket4_remote_ip 10.1.1.63
socket4_local_port 80
socket4_remote_port 61401
flowBlock_tag 0:2201
flowSampleType http
http_method 2
http_protocol 1001
http_uri /favicon.ico
http_host 10.0.0.150
http_referrer http://10.0.0.150/membase.php
http_useragent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleW
http_bytes 284
http_duration_uS 335
http_status 404
endSample   ----------------------
endDatagram   =================================

The -H option causes sflowtool to output the HTTP request samples using the combined log format:

[pp@test]$ /usr/local/bin/sflowtool -H
10.1.1.63 - - [05/Jan/2011:22:39:50 -0800] "GET /membase.php HTTP/1.1" 200 3494 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleW"
10.1.1.63 - - [05/Jan/2011:22:39:50 -0800] "GET /favicon.ico HTTP/1.1" 404 284 "http://10.0.0.150/membase.php" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleW"

Converting sFlow to combined logfile format allows existing log analyzers to be used to analyze the sFlow data. For example, the following commands use sflowtool and webalizer to create reports:

/usr/local/bin/sflowtool -H | rotatelogs log/http_log &
webalizer -o report log/*

The resulting webalizer report shows top URLs:


Finally, the real potential of HTTP sFlow is as part of a broader performance management system providing real-time visibility into applications, servers, storage and networking across the entire data center.


For example, the diagram above shows typical elements in a Web 2.0 data center (e.g. Facebook, Twitter, Wikipedia, Youtube, etc.). A cluster of web servers handles requests from users. Typically, the application logic for the web site will run on the web servers in the form of server side scripts (PHP, Ruby, ASP etc). The web applications access the database to retrieve and update user data. However, the database can quickly become a bottleneck, so a cache is used to store the results of database queries. The combination of sFlow from all the web servers, Memcached servers and network switches provides end-to-end visibility into performance that scales to handle even the largest data center.

Thursday, April 14, 2011

Timeline



The article, Visibility and control in HP Converged Infrastructure: A history of innovation and standards, describes the joint research between HP Labs and CERN that first demonstrated the scalability of packet sampling for monitoring data networks. The article briefly describes some of the factors that led to the adoption of the sFlow standard and goes on to describe the role of sFlow in HP's Converged Infrastructure/FlexFabric architecture.

This article looks at the evolution of the sFlow standard over the last decade and then looks forward to see how sFlow will continue to meet the challenges of scalable performance monitoring in the next decade.

The sFlow standard was developed to monitor high speed switched networks and sFlow's growth has closely tracked developments in Ethernet switching. The chart above plots milestones in the development of sFlow against the growing Ethernet switching market and the adoption of 1 Gigabit, 10 Gigabit and virtual switch technologies.

Ten years ago, the adoption of high speed Ethernet switching had severely limited the value of probes for monitoring network traffic. The sFlow architecture addressed this challenge by embedding instrumentation within the switches in order to provide network-wide visibility. Initially published by InMon Corp. as RFC 3176, the sFlow.org consortium was founded in 2004 in order to further develop and promote solutions based on sFlow technology.

sFlow.org 2004

Since 2004, sFlow has grown into the leading, multi-vendor, standard for monitoring high-speed switched networks. The growth in vendor support of sFlow has been driven by the move to 1G and more recently 10G Ethernet switches.
The sFlow.org site lists the large number of switches with embedded sFlow monitoring. Switch vendors supporting sFlow now include: AlaxalA, Alcatel-Lucent, Allied Telesis, Arista Networks, Blade Network Technologies, Brocade, Dell, D-Link, Enterasys, Extreme Networks, Force10 Networks, Fortinet, Hewlett-Packard, Hitachi, IBM, Juniper Networks, NEC, Netgear, Voltaire and Vyatta.

Strong vendor involvement in the sFlow standard has ensured that new management challenges are quickly addressed. For example, as wireless networking gained popularity, sFlow was extended to provide visibility into wireless networks and available in products by 2007.

The growth in virtualization has led to the adoption of sFlow monitoring in virtual switches, providing visibility in virtualized and cloud networking. Managing converged, virtualized and cloud infrastructures requires a unified view of performance and sFlow was extended to include storage, server and application performance monitoring.

sFlow.org 2010

Where will the next decade take sFlow?

Demand for more energy efficiency is driving current efforts to extend sFlow to include power metering.

Expect to see sFlow in an increasing number of 40G and 100G switching products. The sFlow protocol is designed to monitor high speed switch fabrics and provides low cost, wire-speed monitoring at speeds of 100Gbits/s and beyond with the scalability to monitor the large, flat, layer 2 fabrics emerging to support virtualization.

Finally, the unique scalability of sFlow dramatically simplifies management by providing a single, centralized view of performance across all resources in the data center. Measurement eliminates uncertainty and reduces the complexity of managing large systems. An effective monitoring system is the foundation for automation: reducing costs, improving efficiency and optimizing performance in the data center. In future, expect to see sFlow monitoring tightly integrated in data center orchestration tools, fully exploiting the flexibility of virtualization and convergence to automatically adjust to changing workloads.  For additional information, the Data center convergence, visibility and control presentation describes the critical role that measurement plays in managing costs and optimizing performance.

Monday, April 4, 2011

The s in sFlow


Have you ever wondered what the s in sFlow stands for? While the s is meant to indicate sampling (of counters and packets), the wide range of applications for sFlow suggest additional meanings:
  • s for Standard, the sFlow standard ensures interoperable, multi-vendor performance monitoring.
  • s for Switch, broad support for the sFlow standard by switch vendors allows best-in-class products to be selected while maintaining end-to-end visibility from wireless and wired campus switches to high performance data center switches.
  • s for Storage, sFlow provides visibility into all types of networked storage, including Ethernet Storage Area Network (SAN) technologies, FCoE and AoE
  • s for Server, standard sFlow performance metrics from servers simplifies management by eliminating the need for separate network and server monitoring systems.
  • s for System, sFlow is an integrated measurement system, providing the visibility into switches, storage and servers needed to manage performance in converged, virtualized and cloud environments.
  • s for Service, sFlow embedded in server protocols like HTTP and Memcache provides visibility into application transactions and response times. Linking application, server and network performance allows sFlow to deliver end-to-end visibility into services, mapping services and the resources that they depend on.
  • s for Security, sFlow provides the visibility needed to detect unauthorized activity and enforce security policies.
  • s for Simplify, sFlow eliminates complexity. Simplifying management reduces costs, increases flexibility and improves scalability.
  • s for Scalability, sFlow has the scalability needed to manage the performance of even the largest data center. 
The requirement for scalability brings us back to sampling: sFlow's distributed packet and counter sampling mechanisms are fundamental building blocks that give sFlow the scalability to deliver data center wide visibility and control.

Tuesday, March 29, 2011

AoE


The ATA over Ethernet (AoE) protocol provides a method of carrying Storage Area Network (SAN) traffic over a switched Ethernet network. AoE provides networked storage that supports virtualization and cloud computing applications.

An AoE SAN consists of commodity hardware: SATA disks, Ethernet adapters and switches. The result is a low cost, high performance networked storage solution. The article, What is Ethernet SAN & AoE?, includes technical details and a discussion of the benefits of AoE as a SAN technology.

Visibility into network activity is essential for maintaining optimal performance in a converged network since storage traffic  tends to dominate network workloads. Fortunately, one of the benefits of using an Ethernet SAN is increased network visibility since most switch vendors implement the sFlow standard in their switch hardware.

One of the unique features of the sFlow standard is that any sFlow capable switch will monitor all types of traffic flowing across the network, including non-IP SAN protocols such as AoE and FCoE. The sFlow data exported by the switches includes packet header information that permits an sFlow analyzer to report on new types of traffic as they are deployed on the network without any need to upgrade switch firmware or hardware.

The following chart trends AoE operations on a SAN using sFlow data from Ethernet switches:


The chart shows the detailed visibility into AoE servers, clients, operations and targets available through sFlow monitoring. In addition, sFlow is being used to monitor the performance of the systems attached to the Ethernet SAN. Using sFlow to monitor servers links MAC addresses associated with AoE connections to server host names, UUIDs and performance metrics. The chart above demonstrates the additional context that integrated network and server monitoring provides; showing that while there are two different server MAC addresses (FAA69ECD3D6F and EABF12E86CD0), they are in fact associated with a single storage server (UUID e9d0e087-51c7-429e-9841-4439db35f3be).

The following charts make use of sFlow data from the server to trend server load:


In this case, it appears that the storage server is the performance bottleneck. Upgrading the server, or moving to a dedicated AoE storage appliance (e.g. Coraid EtherDrive) should significantly boost performance.

Network convergence using a high-speed, flat, layer 2 fabric creates a simple, flexible infrastructure that supports virtualization and cloud computing. Choosing switches that support the sFlow standard provides the unified view of network and system performance needed for effective control of data center resources. For additional information, the Data center convergence, visibility and control presentation describes the critical role that measurement plays in managing costs and optimizing performance.