Skip to content

Virtual poasting

Management industry-wide will from time to time acknowledge the lack of recognition of the efforts of IT – eg nobody notices when things work, only when they don’t work – but more seldomly do they acknowledge the hidden costs of operations. This leads to screwy virtual and real accounting within IT, and a mindset bordering on irrationality. The naivety of the of the open-source anarcho-advocates have unfortunately exacerbated that by creating a critical mass of thinking of “assets without investment”. This is hubris and miscommunication, but the opposing parties tend to be so intractable, irrational, and ignorant as to make arguing it both volatile and futile. But I digress…

Small businesses are among those at the highest risk and likelihood from the DR ‘coffin corner’, eg the confluence where loss of resources and expense of investment combine into a double-negative penalty. There’s a number of different ways that this can be accomplished, but here’s some basic points for reference.

First, there’s the ‘hit by a bus’ scenario. No matter how much documentation you may have, it’s no good unless there’s someone available to execute that plan. It doesn’t matter how much of a contributor to the kernel you may be, if the alternate or remote site fingers-person does not have the comparable experience, you need to revise the DR plan to that common denominator. Do you -both- have time and resources within office operating hours and resources to have the alternate be systems competent? (Tangent about the need for at-work staff development forks here.)

This is the same fuss that many others have thrashed out before hand. This is why buying commodity systems of hardware, software, and solutions is the best business decision.

Here’s a basic scenario pulled off a current deployment.

The basic server is multi-CPU capable with a healthy potential for memory expansion. The configuration ordered was only single-CPU with a modest amount of memory. Expanding it later may likely cost more than buying up front, but the configuration ordered allowed us to significantly reduce initial entry costs, to better afford a storage system.

The internal storage is all RAID’ed at a hardware level below the operating system. The operating system installed there is configured only as a VM host, and is considered disposable. Because the storage is secured at a lower level, the most you have to do reload the host OS, setup networking, and reconnect to storage. That doesn’t take all that much time in a small business environment of a half dozen servers or less, as they’re not likely to all go all at once.

Next, all your business is actually done on VM’s. This way, the complicated-to-rebuild stuff is stored as a portable image that can be put and migrated on scalable and secured storage. It also gives you a convenient vector to put more aggressive DR such as offsite/cold-site on the table, by doing DR at the raw data level with your systems packaged as data.

The VM’s themselves are stored on the attached storage device, along with the virtual hard disks that the VM’s use as ‘local’ data. Performance was more than adequate in an initial test, and this gives us the abstraction that can be relocated from one storage system to another.

One point that was recently made is that iSCSI is a block-level system, and so is intended for use by systems that do block-level management, such as specific application servers. It’s quite likely that performance will not be so wonderful in a file media serving role based on an iSCSI system. In those situations, you just need spindles and lots of them. DFS and similar technologies may have some load-balancing capabilities as well.