iSCSI performance tuning: 380 MB/s within a VM with openfiler and ESXi
There is a large gap between entry level Storage appliances like QNAP, Thecus or Buffalo and „large“ SAN-Storages regarding performance, features and very much the price. We have found a solution to fill this gap for our datacenter. Using open source of course!
Our test bed:
- 1 ESXi 4.1 server (Fujitsu RX 200 S6, 8 Cores 2,4 GHz, 48 GB RAM, 6 x GBit-NICs Intel)
- 1 Openfiler 2.3 (Supermicro 8 Cores 2,0 GHz, 8 GB RAM, 3ware 9650SE 8 Ports, 6 x GBit-NICs Intel, 8 disk drives 2 TB SATA 7200U/min)
- 1 switch Cisco Catalyst 2960S (24 port GBit)
We used four GBit NICs on either side for four iSCSI-VLANs with different IP address ranges. The NICs have to be assigned to the iSCSI software initiator to address all paths. We created an iSCSI volume in Openfiler, connected and formatted it in ESXi using VMFS 4 file system. Paths selection was configured „round robin“.
1st step: Where do we start
First we measure the performance of the unoptimized system. The size of the test file we use is smaller than the storage server’s RAM. So any read and written data comes from the cache and we measure only the iSCSI connection.
Not impressive, is it? Accessing the disks locally yields 420 MB/s! What a performance loss in the way to the VM.
2nd step: iSCSI path optimization
Next thing to do is tuning all parameters associated with the iSCSI paths. It is okay in this step to use unsafe settings (e.b. enabling a write buffer without having a BBU). The test file still is smaller than the storage server’s RAM, because we want to measure the iSCSI connection’s speed.
Things to look at:
- Parameters of the network interface card (jumbo frames, TCP-offload)
- iSCSI parameter (round-robin parameter)
- RAID pontroller (enable write-cache)
The boost in performance was obvious:
This is close the theoretical limit.
Beware: Don’t continue if you’re not satisfied. From now on it’s getting worse!
Watching the load of iSCSI paths in vSphere client should give a equal share of traffic over all paths.
Things we stumbled upon:
- bad jumbo frame configuration. Test it with ping using large packets and „dont fragment“-bit set. Our switch needed a „set mtu jumbo 9000“
- VMwares „round robin“ algorithm switches paths only every 1000 IO ops. You have to use „esxcli“ to change that.
3rd step: optimizing storage parameters
Now we set up everything to safe values for the production environment. The IOMETER testfile is twice as big as the storage server’s RAM. Caution: Size is given in blocks of 512 bytes.
We compared different RAID levels (getting practice in online RAID migration while doing so) and different number of disk drives.
Raid-10 with 4 disks: 2 TB (SATA, 7200 U/min):
Raid-10 with 8 disks:
Increasing the number of spindles didn’t improve performance, although we expected better IOPS. So it would be better to use two independent datastores with 4 drives each.
Almost 400 MB/s and >10.000 IOPS makes us very happy. Our x86 server with Openfiler (about $5.500) closes the gap between inexpensive entry level storage appliances ($1.500 Euro for 70 MB/s and2.000 IOPS) and large SAN storages for $15k+.
Further IOPS and latency improvement could be achieved using more and better drives (SSD, SAS). We haven’t tried storage replication yet, but we read reports about users successfully implementing „drbd“ .
IT bleibt spannend,
This article is based on research by Christian Eich, Richard Schunn and Toni Eimansberger.
Author: Christian Eich