IBM SVC - Great Complement to Virtualization and Linux
November 19th, 2007I was reading a recent post about how IBM has now shipped it’s 10000th SAN Volume Controller (SVC). That is remarkable, and says a lot about the industry and the desire for virtualization solutions across all hardware. Server sprawl is the easy and most obvious expanding problem in a data center. But, what about the storage? Solution vendors lock customers into proprietary solutions, and homogeneous environments are difficult to configure and manage. IBM SVC makes that so much easier.
We recently tested an IBM SVC in our lab environment. This was prior to making a purchase decision. To give you an idea, we had 3 classes of storage connected to the IBM SVC. The IBM SVC then provided redundant fibre connectivity to our test server. The storage vendors were 3Par, EMC Clarion, and IBM Shark. We wanted to perform a test that would allow us to observe what happens to servers running off virtual storage. We wanted to observe any changes if virtual storage was moved between the vendors. We also wanted to test Linux; determine if there were any connectivity issues with SVC. We then wanted to actually run virtual servers on the virtual storage! Have a headache yet?
Our configuration was a VMServer connected to the SVC through redundant active-active fibre connections. the SVC was configured to serve 3-50 GB partitions to our server. Interestingly, under Solaris, you had to install each driver for the storage manufacturer to make it work. Under AIX, it just recognized the three partitions.
The first thing we had to do was see how Linux would recognize the storage being presented to the server. We decided to use SLES 10 as the VMServer host operating system. At first glance, we saw lots of storage connections in the YAST Partitioner. IBM had indicated we could use the mpio library to manage the connections. That was easy enough - we found and loaded the mpio libraries, and sure enough, we saw all the virtual connections and the 3-50 GB partitions that we could manage! Very impressive; the storage was served to our server and recognized as the IBM SVC controller. It was not concerned with whether it was EMC, 3Par, etc.
The initial assumption was we would need to format the drives. We found out that we didn’t need to do that at all. Whatever the raw format of the storage was was presented and readable to the Linux VMServer. that’s easy. So, we mounted each of the drives as /test, /test1, and /test2. The reason for the names that way is we did not want to skew any testing by mounting as the original storage manufacturer. So, very benign names.
The next thing I did was create three VM’s. Two on the local disk, and one on a mounted drive from SVC. The first local VM was configured to run a program that would read and write small files to one of the mounts, and then delete them and start the process over again. The second VM was to run a program that would write very large files, read them back one byte at a time, and then delete them and start over. The VM created on the SVC was installed with a Linux O/S (Ubuntu server) running several programs - graphical, looping scripts, and one that measured and recorded time points.
Why large files with one byte reads? Well, that’s a real world example! There was a programmer that had created a program some time back. Instead of reading large buffers, he felt that there was performance gains in reading one byte at a time. Needless to say, the customer was pissed, and it took a few days to figure out the problem because the developer was just sure that wasn’t the problem! It happens!
Okay, so with all three VM’s running, we initiated some SVC exercises. The first was to migrate /test from the current SAN vendor to a different SAN vendor. The move took about 30 seconds total, and the VM did not see any interruption of service.
The next test was to take two of the SVC drives, /test2 and /test3, and swap their hardware SAN. In other words, move between the two vendors. Again, it took about 30 seconds per mount to move, and again the VM’s saw no interruption of service.
Finally, we randomly had the SVC administrator begin moving all mounts to various locations. Throughout the test, we monitored all VM’s and watched in particular how the VM created on the presented SVC drive was functioning. The appearance was everything was good. But, we did want to check the time stamp data. After review, the data showed no degradation in performance during the move.
One thing we noticed with the two VM’s running scripts to read and write was that on what was the higher end enterprise storage solutions, they ran very fast. They did appear to slow slightly after being moved to the slower storage solution. But nothing that was measured - just appearance. It could have been an underlying expectation!
Bottom line, IBM SVC is a really nice solution. It can be very pricey for small to medium enterprises, but well worth it for large enterprises with multiple terrabytes - or even petabytes - of data.
