The Global Leader in Application Delivery Networking

F5 Networks

Subscribe to F5 Networks: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get F5 Networks: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


f5 Authors: Peter Silva, Don MacVittie, Mehdi Daoudi, Lori MacVittie, Jason Rahm

Related Topics: Cloud Computing, Virtualization Magazine, SOA & WOA Magazine, Microservices Journal, Cloud Data Analytics, F5 Networks

Blog Post

“Lights Out” in the Cloud

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

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.

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.