HOWTO

For my notes.. If you ever wanted to check the status of a bonded interface configure in Linux (esp RHEL), you can check the status by running the following command

[root@serverxyz bin]# cat /proc/net/bonding/bond0

i.e. assuming the name of your bond interface is bond0.

Output from the command

Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth3 (primary_reselect always)
Currently Active Slave: eth3
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth3
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:10:18:6e:b8:1a

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:21:5e:11:34:32

The configuration files involved are

/etc/sysconfig/network-scripts/ifcfg-bond0 (Bond Interface)

DEVICE=bond0
IPADDR=10.10.40.26
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
GATEWAY=10.10.40.1
NETWORK=10.10.40.0
BROADCAST=10.10.40.255
TYPE=Ethernet

/etc/sysconfig/network-scripts/ifcfg-eth3 (Primary Interface)

DEVICE=eth3
BOOTPROTO=none
ONBOOT=yes
HWADDR=00:10:18:6e:b8:1a
MASTER=bond0
SLAVE=yes
TYPE=Ethernet
USERCTL=no

/etc/sysconfig/network-scripts/ifcfg-eth0 (Secondary Interface)

DEVICE=eth0
HWADDR=00:21:5e:11:34:32
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
TYPE=Ethernet

We ran into an issue at work recently, which prompted us to do some performance testing on some of our Linux servers. The requirement was to stress test the key components of the server (CPU, RAM, HDD, Network) and prove that different servers with the same configuration were capable of performing identically. Pretty simple right :).. The challenge was to find tools that could be run to stress test each of the components. There were a lot of tools for CPU and memory (RAM) testing, but not a lot for network and hard drive (HDD) testing. After searching high and low, we found a couple of tools, that I wanted to document here for future reference.

HDD Testing :

I found a pretty interesting tool called Iozone written by William Norcott (Oracle) and Don Capps. You can get the source code and builds for major OSs at http://iozone.org . Despite installing the program using RPM, we were not able to  run the program without specifying the complete path.

There are a ton of options for the program, but the easiest method to run it was in automated mode with the output going to an Excel spreadsheet (more like a glorified CSV file 🙂 ). Here is the command we used

/opt/iozone/bin/iozone -a -Rb output_excel_file.xls

The “-a” is to tell the program in automated mode and the “-Rb” is to tell the program to format the output in Excel format. And you can then go ahead and open the spreadsheet in Excel and create 3D graphs to check and compare the output.

Network Testing :

Most of the information out there in terms of testing the network stack of a machine is either to copy large files over a network share or via FTP. We didn’t find that was enough to really max out a Gigport since there were protocol limitations that didn’t allow us to saturate the network port. After some searching, we stumbled across a tool called “ettcp” on Sourceforge. ettcp itself is an offshoot of ttcp. ttcp (stands for test tcp) was created to test network performance between two nodes. I couldn’t find any place to download ttcp itself, but you can download ettcp at http://ettcp.sourceforge.net/.

We used a server, to act as a common receiver for all the servers we intended to do a performance test on. Here are the commands we used to run the test

RECEIVER (Common Server)
./ettcp -r -s -f M

The options are

• “-r” for designating the machine as receiver
• “-f M” for showing the output in Mega Bytes.

TRANSMITTER (Test Servers)
./ettcp -t -s receiver_hostname -n 10000000 -f M

the options are

• “-t” for designating the machine as transmitter
• “-s receiver_hostname” to define the receiver
• “-n” to define the number of packets to send to the receiver