Matt Pson Just another dead sysadmin blog


On using Cisco’s UCS servers as normal servers

"So you are using the whole Cisco UCS system ...and how?"

I have gotten the above question in some different flavors quite a few times lately. And the answer is: no we do not, we use them as normal, single, rackservers just as you would with a rackserver from any other vendor.

The Cisco C200 M2 comes with a decent CPU (has 2 CPU sockets) and a few slots for RAM (up to 192GB), 3 PCI Express slots (one is low-profile) and you can install up to 4 standard 3,5" SATA disks of  your choice (no more having to stick with what other vendors can supply) plus a very decent out-of-band management card as standard (compare DRAC or iLo) and all that at quite a lower price than a comparable system from say Dell. Sure, the standard included warranty and support is far from what Dell or HP offers but I'm sure that Cisco will happily supply that for an additional fee if you want. We recently saw a increase in baseprice of this system but it is still 25-50% off from the prices that Dell keeps flooding our mailboxes with (which I know is not the prices we would pay after phoning our Dell representative).

The Cisco C210 M2 is much the same basic system but still quite a bit different as it has 16 2,5" diskslots in a 2U chassis where you have to get the disks from Cisco (which can take quite some time if unlucky) and 5 PCI Express slots. Apart from those two things it seems that the C200 and C210 shares all other properties.

I have earlier reported about a newer system, the C260 monster (64 DIMM slots and 16 drives in a 2U chassis with the new Intel Xeon family processors!), but I have yet to see it in real life (and more importantly in a pricelist).

But yes, these are usable as normal rackservers without any modifications and provides good value in the low-end range of rackservers. I would recommend them to anyone just looking for a decent rackserver any day.


Proving a point – building a SAN

A few weeks back I noticed that patching a bunch of virtual machines running Windows felt slower than it used to do. Not that patching Windows servers ever felt quick and there was a big list of patched going onto these systems, but something was not quite right that afternoon. All these VMs had in common that they ran of a Sun Storage 7210 SAN that we got a few years back that has served us well. After some detective work using the awesome DTrace analytics of this box combined with the ESXi statistics it was quite obvious that write latency was suffering when patching several VMs in parallel.

As this SAN is using the ZFS filesystem I knew that there was an option when we bought it to add a "Logzilla", a SSD device to speed up and cache write requests which in combination with VMware ESXi always doing sync-writes over NFS should solve the write latency problems (well, there wasn't a problem with those just yet unless we did heavy random writes in multiple VMs at the same time - but it was a first indication that we would sooner or later have a problem with that). VMware provides a troubleshooting guide that recommends that the average write latency should stay below 20ms under load and let's just say that we saw numbers way higher than that when we patched.

Ok, so I dropped a mail to our Oracle dealer asking for a price on those SSD devices. They phoned back a bit later sounding really hesitant to give me a quote, telling me that the price obviously had went up a bit since Oracle bought Sun. Uh-huh, so what was the price then? Over €10000 for a 18GB SSD disk?! Wait? What? So, um, we were expected to pay big for something that, probably, could improve write latency on this SAN.

What to do? Our first decision was to figure out if that "Logzilla" would actually improve the situation if we were to add it (doubtful given the price, but anyway) . But how?  Why not build a SAN? To the batcave...

Using mostly equipment that we had spare I managed to get hold of a Cisco UCS C200 M2 server with 4GB RAM and 3 Samsung 1Tb consumer-grade desktop SATA disks. We picked up a €150 standard 60Gb SSD disk from the local computer shop (we picked a cheap one that had decent write speed according to the datasheet, probably around 220Mb/s). Adding the free version of NexentaStor (SAN-appliance software based on Solaris, good stuff) on top of that turning our equipment into something best descibed as a getto-SAN.

Doing a next-next-next install using one of the SATA disks as a single system disk, using the other two as a mirror with the SSD as a log device - all using the onboard SATA controller in the server. Hooking up the SAN to the storage network using a single gigabit port and using Storage vMotion to move a couple of, non-critical but live production, VMs to our testing SAN. They have been running there for almost two weeks now in order to gather some real numbers and the statistics tell us that the average write latency stay well below the 20ms level defined by VMware, most about 1/10th of that, 2ms. Throughput maxed out the gigabit connection more or less, we saw speeds around 80-100MB/s.

Hm, yeah, our getto-SAN that cost us less than €1000 to put together outperformed our €30000+ SAN from 2 years back thanks to a log device for the ZFS filesystem. Sure, the workload maybe wasn't comparable but we still regard this as proof that ZFS performance improves greatly if you give it a "Logzilla". Still, €10000 for a 18GB SSD disk feels a bit steep as it doesn't add anything else to the SAN. So next step for us is to build a "real" SAN to use in production to see what performance we can get if we use 'proper' hardware.

I'll write more when I have put together what I can get for my limited budget of €4-5000.