“Lights Out” in the Cloud

Options begin to emerge to address a real management issue with virtualized workloads in public cloud computing .

Anyone familiar with enterprise-class infrastructure and servers knows that lights-out management is a must-have; not just in the event of a failure but also in the face of any event that compromises the ability of an admin or operator from accessing the machine. Lights-out management was early on a “nice to have” that evolved steadily into a “must have” feature not just for servers but for network and infrastructure devices, as well. This was particularly important as we saw the impact of excessive traffic and malicious attacks on web sites, many of which disrupted the ability for administrators and operators to access devices and machines in the data center and redress the situation.

With the advent of virtualization we took a few steps back in our ability to lights-out manage “virtual” infrastructure and servers, especially in shared environments such as cloud computing. Because the lights-out management capabilities are generally associated with the physical machine, there was no mechanism for extending that capability to the individual, highly abstracted virtual machines executing atop that hardware platform. The only answer in shared environments is, then, to hit the reset button on the virtual machine. That’s not an ideal way of dealing with what may be an attack or configuration issue because you can’t identify the problem if you reset the instance back to what should be a pristine state.

CLOUD EXACERBATES the PROBLEM

Cloud computing makes this problem even more extreme. The public cloud platforms have been designed around a new cloud model with published APIs and their own control planes. These control planes are extremely powerful, enabling provisioning on demand, and programmatic access to resources. However, many of the clouds have limited or non-existent access to those low-level control functions that enterprises rely on, including (but not limited to): network booting, boot order control, boot and kernel options, the ability to boot to the last known good state, and the ability to attach debuggers to the systems in the cloud.

These challenges have emerged as barriers to enterprise cloud adoption. If administrators can’t control their machines in the cloud as they require, they’ll be reluctant to move any meaningful workloads there. So it’s great to see that CloudSwitch is tackling the issue with the latest version of their Enterprise software, released this week.

One of the key features CloudSwitch now provides is “console” access to the servers within the cloud.  This access is running on an independent control plane so that the CloudSwitch user can access a server in the cloud even if it is having difficulty booting.  The CloudSwitch console allows the user to access the keyboard and “VGA” display of the server in the cloud to be able to control boot parameters, setup (or repair) networking, or boot to safe mode, or even repair file systems.  The enterprise can now administer and repair systems using the tried and true methods that they are used to.

CloudSwitch provides the low-level, independent access to the virtual hardware within cloud deployments to allow administrators the access and control they need. While console access may be a side-effect of the underlying cross-cloud deployment and management “isolation technology” used to enable CloudSwitch to perform its magic, it’s an important feature that should certainly be noticed – and appreciated – by administrators and operators for whom such “technology insurance” is valuable in troubleshooting and responding to issues occurring off-site.


AddThis Feed Button Bookmark and Share

Published Dec 14, 2010
Version 1.0

Was this article helpful?

No CommentsBe the first to comment