AoE

(credit What is Ethernet SAN & 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.

IPv6

(credit Wikimedia Commons)

On February 3, 2011, ICANN/IANA announced, Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied. The problem of IPv4 address exhaustion makes support for IPv6 a necessity, however there are significant challenges in supporting IPv6.

The article, There is no Plan B: why the IPv4-to-IPv6 transition will be ugly, provides a good introduction to some of the challenges. Critically, IPv6 is not backward compatible with IPv4, requiring a complex mixture of dual stack, NAT and tunneling strategies to maintain connectivity between IPv6 and IPv4 hosts:

• Dual-stack
• Dual-stack Lite (DS-Lite)
• NAT64
• 6in4
• 6over4
• 4in6
• Teredo
• ISATAP

In order to help network vendors and service providers test their IPv6 transition solutions, the Internet Society (ISOC) has organized World IPv6 Day for July 8th, 2011.

Visibility into network traffic provides vital information needed to manage IPv6 deployments. Even if an organization has no immediate plans to support IPv6, it is very likely that there is already IPv6 traffic present on the network since IPv6 support is enabled by default on many operating systems. Serious performance and security problems can result if IPv6 traffic isn't carefully monitored and managed.

The sFlow standard fully supports IPv6 monitoring. Most switch vendors include sFlow monitoring within their switch hardware, providing the visibility needed to manage the transition to IPv6, reporting on all IPv4 and IPv6 traffic as well as the different encapsulation and tunneling protocols for IPv6 transition. Switches supporting sFlow don't need to be upgraded in order to report on IPv6 traffic, the sFlow data exported by the switches contains packet header information that allows an sFlow analyzer to report on all different types of traffic on the network. The end-to-end visibility provided by sFlow ensures that traffic can be monitored and problems identified wherever they occur in the network.

For example, Amsterdam Internet Exchange (AMS-IX) uses sFlow to track the growth in IPv6 traffic on their network. The following chart trends IPv6 traffic over the last year:

(credit AMS-IX sFlow Stats)

Enabling sFlow monitoring in the network is a critical first step toward managing a smooth transition to IPv6. Proactive deployment of sFlow monitoring ensures that the data is available to troubleshoot and avoid problems as systems are transitioned to an IPv6 world.

Installing Host sFlow on a FreeBSD server

The Host sFlow agent supports FreeBSD performance monitoring, providing a lightweight, scalable solution for monitoring large numbers of FreeBSD servers.

The following steps demonstrate how to install and configure the Host sFlow agent on a FreeBSD server, sending sFlow to an analyzer with IP address 10.0.0.50.

Note: If there are any firewalls between the FreeBSD servers and the sFlow analyzer, you need to ensure that packets to the sFlow analyzer (UDP port 6343) are permitted.

First go to the Host sFlow web site and download the sources, hsflowd-X.XX.tar.gz.

The following commands build and install the host sFlow agent:

tar -xzf hsflowd-X.XX.tar.gz
cd hsflowd-X.XX
make
make install
make schedule
/etc/rc.d/hsflowd start

The default configuration method for sFlow is DNS-SD; enter the following DNS settings in the site DNS server:

analyzer A 10.0.0.50

_sflow._udp SRV 0 0 6343 analyzer
_sflow._udp TXT (
"txtvers=1"
"polling=20"
"sampling=512"
)

Note: These changes must be made to the DNS zone file corresponding to the search domain in the FreeBSD server's /etc/resolv.conf file.

Once the sFlow settings are added to the DNS server, they will be automatically picked up by the Host sFlow agents. If you need to change sFlow settings, simply change them on the DNS server and the change will automatically be applied to all the FreeBSD systems in the data center.

Manual configuration is an option if you do not want to use DNS-SD. Edit the Host sFlow agent configuration file, /etc/hsflowd.conf, on each FreeBSD server:

sflow{
  DNSSD = off
  polling = 20
  sampling = 512
  collector{
   ip = 10.0.0.50
   udpport = 6343
  }
}

After editing the configuration file you will need to restart the Host sFlow agent:

/etc/rc.d/hsflowd restart

For a complete sFlow monitoring solution you should also collect sFlow from the switches connecting the servers to the network (see Hybrid server monitoring). The sFlow standard is designed to seamlessly integrate monitoring of networks and servers (see sFlow Host Structures).

An sFlow analyzer is needed to receive the sFlow and report on performance (see Choosing an sFlow analyzer). The free sFlowTrend analyzer is a great way to get started, see sFlowTrend adds server performance monitoring to see examples.

XCP 1.0

"Xen Cloud Platform (XCP) is an open source enterprise-ready server virtualization and cloud computing platform." The recent XCP 1.0 release includes support for the OpenStack cloud orchestration software; together XCP and OpenStack provide a complete, open source, solution for building large scale cloud data centers.

One of the benefits of an open source virtualization/cloud stack is the opportunity to customize the commodity components to deliver differentiated services. This article examines the opportunity to dramatically reduce the cost of delivering cloud services using the open source, open standard instrumentation available as part of the Xen Cloud Platform.

The following diagram shown the architectural components of the Xen Cloud Platform and shows how sFlow instrumentation fits within the XCP architecture.

The Control Interface (XE/XAPI) configures and controls resources within the Resource pool (e.g. provisioning, starting, stopping and migrating virtual machine and storage resources). Enabling sFlow in XCP (provided by Open vSwitch and Host sFlow) adds highly scalable performance monitoring and usage metering of the cloud infrastructure; including visibility into physical and virtual network, server and storage activity.

Real-time monitoring allows resources to be optimally provisioned to match demand. Adjusting capacity to demand reduces costs by eliminating over provisioning and applying resources where they are needed to avoid service failures.

In addition, detailed usage data allows for differentiated billing strategies (for example charging different rates for local and non-local network traffic). Aligning billing policies with the cost of delivering services allows services to be delivered at a variety of price points and encourages customers to use resources efficiently.

The steps needed to enable sFlow monitoring in Xen Cloud Platform are described in the article, XCP 1.0 beta. Most switch vendors also support the sFlow standard (instructions for enabling sFlow on most vendor's switches are documented in articles on this blog). The combination of sFlow from switches and XCP provides the data center wide, end-to-end visibility needed for complete control.

For additional information, the sFlow presentation provides a strategic view of the role that sFlow monitoring plays in managing converged, virtualized and cloud environments.