Saturday, March 27, 2010

Power


The paper, No "Power" Struggles: Coordinated Multi-level Power Management for the Data Center, examines different power control strategies and suggests that power savings of 20% - 60% are possible using feedback control to optimize and consolidate virtual machine locations and workloads. The paper concludes, "Our results indicate that effective coordination is likely to be more important in future environments with richer diversity in workloads and increased emphasis on power reduction."

The sFlow energy metering extension, currently being developed as part of the sFlow standard, builds on the proven scalability of sFlow's counter polling mechanism to provide real-time metering of all switches, PoE ports, servers, blades and processors in the data center.

Incorporating power metering in sFlow integrates power and temperature information with workload and performance statistics from network devices and servers to deliver the real-time measurements needed for coordinated control and optimization of power usage throughout the data center.

Saturday, March 20, 2010

Host sFlow



Virtualization extends networking into servers through virtual switches, virtual routers and virtual firewalls. The sFlow standard, already built into most vendor's switches, provides visibility and control of traffic on the physical network. As virtual device vendors implement sFlow (e.g. Open vSwitch and Vyatta), visibility is extended into the virtual network on the server. The implementation of sFlow monitoring on servers offers an opportunity to extend visibility into server performance.

Monitoring physical and virtual server performance is a challenging task. Consider that the number of virtual machines per server is going up, currently 20-40 virtual machines per physical machine is not unusual. Monitoring a data center with 10,000 physical switch ports might involve monitoring as many as 5,000 physical servers, 10,000 virtual switches, 200,000 virtual switch ports and 100,000 virtual servers.

The proven scalability of sFlow's counter polling mechanism offers an efficient way to monitor the large number physical and virtual servers in a data center. The Host sFlow extension, currently being developed on sFlow.org, offers a standard way to export physical and virtual server performance statistics (i.e. CPU, memory and I/O metrics).

Host sFlow integrates with sFlow in physical and virtual switches to unify network and system visibility, helping to break down management silos and provide the end-to-end visibility into data center resources needed for effective management and control.

Feb. 15, 2011 Update: To find more recent articles on using sFlow to monitor servers, click on the server label below.

Friday, March 12, 2010

Measurement

"If you cannot measure it, you cannot improve it" - Lord Kelvin

The importance of measurement is widely understood. Measurement is at the heart of the scientific method and an essential activity in science and engineering.

"In God we trust, all others bring data" - Dr. Edwards Deming

In the field of quality control and management, data is collected and analyzed to identify process problems, plan improvements and quantify the effect of process changes.

"You can't control what you can't measure" - Tom DeMarco

In software systems, measurement is a critical component of performance analysis and improvement.

The sFlow standard, built into most vendor's switches, provides the measurements needed for visibility and control of network resources. A measurement-based approach to network management applies the best practices of science and engineering to network operations, replacing guesswork with decisions based on clear, quantifiable data.

Saturday, March 6, 2010

Configuring NETGEAR switches

The following commands configure a NETGEAR switch (10.0.0.250), sampling packets at 1-in-512, polling counters every 30 seconds and sending sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

sflow receiver 1 owner collector1 timeout 4294967295 ip 10.0.0.50

For each interface:

sflow sampler 1 rate 512
sflow poller 1 interval 30


A previous posting discussed the selection of sampling rates. Additional information can be found on the NETGEAR web site.

See Trying out sFlow for suggestions on getting started with sFlow monitoring and reporting.

Configuring D-Link switches

The following commands configure a D-Link xStack® DGS-3600 series switch (10.0.0.250), sampling packets at 1-in-512, polling counters every 20 seconds and sending sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

enable sflow
create sflow analyzer_server 1 owner analyzer1 timeout infinite collectoraddress 10.0.0.50
create sflow counter_poller ports all analyzer_server_id 1 interval 20
create sflow flow_sampler ports all analyzer_server_id 1 rate 512


A previous posting discussed the selection of sampling rates. Additional information can be found on the D-Link web site.

See Trying out sFlow for suggestions on getting started with sFlow monitoring and reporting.

Configuring Enterasys switches

The following commands configure an Enterasys switch (10.0.0.250), sampling packets at 1-in-2048, polling counters every 20 seconds and sending sFlow to an analyzer (10.0.0.50) over UDP using the default sFlow port (6343):

set sflow receiver 1 owner analyzer1 timeout 180000
set sflow receiver 1 ip 10.0.0.50

#configure packet sampling instances on ports 1 through 12
#assign to sFlow Collector 1
set sflow port ge.1.1-12 sampler 1
set sflow port ge.1.1-12 sampler maxheadersize 128
set sflow port ge.1.1-12 sampler rate 2048

#configure counter poller instances on ports 1 through 12
#assign to sFlow Collector 1
set sflow port ge.1.1-12 poller 1
set sflow port ge.1.1-12 poller interval 20


A previous posting discussed the selection of sampling rates. Additional information can be found on the Enterasys web site.

See Trying out sFlow for suggestions on getting started with sFlow monitoring and reporting.

Monday, March 1, 2010

Convergence


The diagram shows technologies that are part of the drive toward converge of storage, server and network technologies in the data center.

Virtualization and the need to support virtual machine mobility (e.g. vMotion/XenMotion/Xen Live Migration) is driving the adoption of large, flat, high-speed, layer-2, switched Ethernet fabrics in the data center. A layer-2 fabric allows a virtual machine to keeps its IP address and maintain network connections when it moves (performing a "live" migration).

Networked storage (iSCSI, NFS, FCoE) is also needed to support virtual machine mobility. In addition, moving storage from dedicated SANs to a converged Ethernet fabric reduced cabling and networking costs and improves flexibility. However, migration of storage traffic onto a converged Ethernet fabric dramatically increases bandwidth demands and is one of the factors accelerating the adoption of 10/40/100G Ethernet.

Ethernet standards are evolving to address the needs of convergence. As well as higher speeds, IEEE data center bridging standards add support for lossless Ethernet to improve storage performance and support Fiber Channel over Ethernet (FCoE). The performance and stability of large layer 2 Ethernets is being addressed through new protocols such as shortest path bridging.

Changes are not limited to storage and data networking. Server architectures are changing as convergence blurs the line between the server and the network, extending the Ethernet fabric into servers through blade switches, network adapters and virtual switches.

The current siloed approach to managing storage, servers and networks no longer works in a converged environment where each of these areas is so closely inter-dependent. Fortunately, convergence to an Ethernet fabric brings with it the data center visibility needed to manage the converged data center.

The sFlow standard, implemented by most vendor's Ethernet switches, simplifies management by providing the unified visibility and control needed to fully realize the benefits of virtualization and convergence.