Next up is Openfiler. Openfiler can run as a VM or natively as it includes it’s own operating system. In my case I started running it on Xenserver as a VM.
I found Openfiler to be a bit more difficult to configure than Xenserver. This was mostly due to the fact I had never set up or even used iSCSI before.
The first task was for Openfiler to see the RAID volume in the first place. In order for Openfiler to see it, Xenserver has to first see it, and mount it as a virtual storage repository, this is where the CLI work took place as Xenserver did not automatically mount the two RAID partitions even though it did recognize the 3ware controller card. The two partitions were found easily enough and VMFS repositories were created for Xenserver to make the volume available to it’s VM’s, specifically Openfiler.
It gets a bit confusing when you dive into what’s really going on here. Xenserver mounts the two RAID partitions and formats them as EXT3, a standard Linux filesystem. However, it manages any number of virtual partitions in this space which can themselves be used as RAW volumes by VM’s.
In the case of Openfiler, one assigns the volume to a group, which is assigned iSCSI file system and then assigned a iSCSI target. Once the volume is mounted via a iSCSI initiator, in Windows for instance, Windows see’s the space and will want to format it NTFS.
Now, the limitation of NTFS of course is that it’s not a clustered file-system. Only one Windows mount can be accomodated at any time. iSCSI is meant to allow multiple simultaneous mounts, and if the volume is formatted in a clustered filesystem such as GFS, it will operate as a true SAN… allbeit in a Linux only environment.
My read/write tests gave me 238MB/sec over teamed dual Gigabit LAN, but I have a feeling that the link aggregation wasn’t really working as I know for a fact that my switch doesn’t support it.
