In football, the “red zone” is the area inside the 20-yard line. Getting into it is a good thing. In IT, what I’m calling the red zone has a different connotation, one that would be more akin to the red line in motor sports. It’s the theoretical point beyond which the system is not designed to be run, ideally. This can be the area outside of best practices that we push gear because we don’t have the resources, time, expertise, etc., to upgrade or implement a system more appropriate for the situation. But, like driving a car past the date for scheduled maintenance, entering the IT red zone doesn’t always mean disaster, at least not right away.
One example is adding storage capacity to a system that can physically support more spindles, but the controller is pretty much maxed out. There’s degraded performance for some users, but it’s something that can worked around, for awhile. Similarly, adding more VMs to a host can push resources past their optimal levels. Again, this can result in degraded performance, and, again, it’s something we can get away with by juggling workloads and schedules.
Using a second tier of storage for primary-tier applications is a tried-and-true red zone “solution” dating back to the first ATA disk arrays. As a VAR, I remember a StorageTek engineer’s dismay as he described customers using their BladeStore Parallel ATA disk systems for general-purpose storage use. These big (at the time), slow disks in a dual-parity configuration were designed for disk backup. But their use as general-purpose storage was bringing users’ applications to a standstill.
Another example of this kind of functional abuse is assuming a backup system can really provide timely recovery — even if a single server goes down. Data protection has historically been focused on meeting backup windows instead of recovery windows, and many IT managers are in a state of denial about their ability to get up and running after an outage. Part of the reason is they assume the cost and complexity of “business continuity” solutions are beyond their means. Now, with server virtualization becoming so common, this red zone practice can be replaced by a best practice.
A system for real disaster recovery — or what I like to call “downtime recovery” — can be implemented using a dedicated hypervisor to support VMs for each of the most critical applications. QuorumLabs makes one of these appliances, which can act as a standby infrastructure, ready to replace a failed server or storage system in a few minutes. The appliance keeps the VMs up to date with the primary servers they’re protecting and provides the ability to regularly test the recovery process — something else that’s not included in the typical red zone solution.
For VARs, uncovering the red zone shortcuts and workarounds that their clients have taken could create some new opportunities. Many solutions can be found that don’t carry the steep price tags that customers often assume, especially for VARs that can leverage an entire line card of products. These are ideal situations to demonstrate your value-add and capture some new business, as well as set yourself up for bigger projects when budgets loosen up.
Follow me on Twitter: EricSSwiss