Review of Scalent's Virtual Operating Environment
As the use of Linux in the data center continues to expand, the need for management tools for deployment, version control and patch management becomes more critical. In addition, the loads on servers can vary dramatically during special events, bringing a need to be able to reconfigure servers quickly and dynamically from one operating group to another to provide temporary capacity expansion, and then repurpose them back to their original groups once the high levels of demand have passed.
The Virtual Operating Environment (V/OE) from Scalent Systems, Inc., offers a mix of management and deployment tools that provides a flexible and far-ranging system for deploying and managing Linux systems in both standard and virtual environments. Scalent is not simply a deployment management system—it also can manage switches, storage and boot images, enabling a server, for instance, to be repurposed from a Web server on the public network to an application server on the development network, with all necessary changes handled from a single console with a few clicks.
Scalent can migrate a physical server to a virtual server, which is not unusual, but it also can migrate a virtual server back to a physical server easily, which is quite unusual. The way it does this is by integrating the Scalent software with both network and SAN hardware, using boot from SAN to allow a single boot image to be cloned and deployed to one or many servers easily, either physical or virtual. Once deployed, a server also can be migrated automatically in case of failure.
The SAN can be either Fibre Channel or iSCSI, and in the case of iSCSI SANs, Scalent has licensed emBoot, which allows systems to boot from an iSCSI target without requiring an expensive iSCSI-specific Ethernet controller.
The Scalent software can be integrated with many different storage systems and network hardware, allowing enterprises to use their existing hardware if desired. Scalent provides engineering support to integrate the software with your hardware and get everything up and running. For the purposes of my testing, I received a preconfigured rack of equipment that included five servers, one running the Scalent software, a Fibre Channel switch, Ethernet switch and IBM storage system. Scalent sent Field Engineer Steve Leung along with the equipment to help integrate the system into my test network and demo the software.
The first steps—integrating the Scalent software with the switches, storage system and the servers in the rack—already had been done, as they would be for any Scalent customer. In addition to the systems in the rack, we added two servers from my lab to the Scalent network—an HP Proliant ML370G5 and an HP Proliant DL360G3. This involved configuring the servers for PXE boot and setting up the Fibre Channel controllers to boot from the SAN, then connecting them via Ethernet and Fibre Channel.
Adding the new server from my lab to the pod Scalent brought was quick and easy. We were able to create a VLAN that matched the lab network, connect to my network, log in to the server, download and install the agent, connect to the Scalent controller and manage that new server in about 15 minutes total. Then, the Scalent appliance was able to deploy personalities to the VMware ESX 3.5 server on the ML370G5 in less than a minute.
Once a server is connected to the Scalent network, configured to PXE boot, and has boot from SAN enabled on its Fibre Channel adapter, it receives a mini-boot environment from the Scalent server that allows it to boot from SAN and be managed. Then, all that is necessary is to use the Scalent software to create a boot image for that system (which can be cloned from an existing image if desired), set up a LUN for that image, and point the server at that image. The Scalent V/OE system works with a large variety of switches and storage through APIs, and it also is able to talk with load balancers, such as F5's BigIP.
Creating a new OS image is simple—after creating a new LUN from which to boot the server, any OS is installed as if it were being installed to a local disk. Once that image is created, it can be cloned by the storage system and used to boot any other server. Most flavors of Linux are supported, as is Windows 2003 Server.
If a server needs to be repurposed, all that is necessary is to create a new image, point the server at the new image, and reboot it—no copying of files to the actual server is necessary, because the server simply boots from the new LUN. Scalent does support a local boot option, where the boot image is copied to the local drive on the server as well.
Scalent installs an agent on each server instance to monitor server activity and enable failover to another physical or virtual instance if the server goes down. The lightweight agent can be downloaded from the Scalent controller to each server quickly and easily. It shows status, load, operating conditions, connectivity and so forth, giving an excellent overall view of network health from the Scalent controller.
In addition to creating and moving boot images for servers easily, the Scalent system makes it simple to create virtual LAN segments to isolate networks and to create SAN environments with the proper storage connected to each server. This means that moving a server instance from one logical group to another also can change network settings automatically to put it into a different VLAN, change SAN port settings so that the appropriate storage is available, performing all the tasks from a single console rather than having to log in to Fibre Channel and Ethernet switch consoles and the storage systems console separately to move things around.
In the case of large organizations where each of these tasks might be compartmentalized and performed by separate groups, the system supports multiple levels of users with specific, granular permissions.
The easy and quick support for virtual LAN and SAN segments makes it very simple to secure networks by keeping different groups of servers on different segments, but it removes the need to have special-purpose servers physically isolated on separate network switches.
From the fault-tolerance angle, creating failover servers for business-critical systems is quick, easy and flexible. Failover servers don't have to be identical—if a server fails, the system boots the same image on new hardware. The Scalent image creation utility does a full install with all drivers, so images should work on any hardware, although some Linux display drivers may not function without reconfiguration. There also can be some issues with moving from Intel to AMD or vice versa, as well as moving from 32-bit to 64-bit. But in general, the parameters for creating a backup server are much looser than most redundant systems.
The Scalent system can replicate the storage used for boot images to secondary remote storage, and it can bring up an entire server farm on new hardware at a new location in only the time required for bootup. Because all changes are reflected on the boot image in real time, servers are up to date with changes as of the time of failover. The gap in service is limited to the time it takes for the new servers to boot. As the switches, IP addresses, subnets and storage LUNs are all managed together, the new servers in the new location have the same IPs as the originals and continue operation as if there had been no change.
This entire process can be automated, so that an entire data center could be moved to another location automatically in case of failure. This level of functionality is easy to set up with the Scalent system, and without it, nearly impossible to achieve without a great deal of configuration and testing of some platform such as OpenView.
Given the increasing use of virtualization, Scalent's support for a single boot image for both physical and virtual servers is a big deal. This only works with VMware's ESX 3.5, because earlier versions of VMware don't support booting from a block device. Scalent also is partnered with XenSource to enable support for Xen and XenSource virtualization systems as well.
For migration of VMs from one ESX server to another, the Scalent server can handle all partitioning, access to storage, networking and so on. For physical-to-virtual migration or virtual-to-physical migration, the same boot image is used for both physical and virtual servers, so no translation or conversion is required. This enables migration from physical to virtual or virtual to physical with no conversion process or delay required. In contrast, other systems that support migration use a translation process, and although physical-to-virtual conversion works well, virtual-to-physical migration may be problematic.
When using the boot from SAN with Fibre Channel adapters, Scalent supports both Emulex and QLogic HBAs, and it also supports Emulex's world-wide-name (WWN) aliases in BIOS, as well as at the driver level for QLogic. Normally, some back and forth is required to get things set up, as a WWN has to be assigned after a new LUN is created, the server masked to that name, then the image created, an alias WWN assigned by the Scalent controller, and then the WWN on the Fibre Channel HBA changed to match the alias. With the new functionality in Emulex controllers, an alias can be assigned during the initial configuration, which means that the process is simplified considerably.
The Scalent system also supports iSCSI boot from SAN using emBoot. This means that a specialized iSCSI Ethernet controller, also known as a TOE controller, is not required.
Scalent prices its system in packs per managed physical machine CPU socket. For example, 12 sockets could be six two-socket servers or three four-socket servers. Pricing is about $1,000 per physical socket managed. There is no limitation on the number of virtual systems or OS images managed.
Although $1,000 per system is not inexpensive, the ability to migrate systems from one server, network and SAN easily to another provides a degree of flexibility not available with any other system I've used, along with an ease of setup and management that is also unique. As data centers continue to grow, and the need for dynamic capacity management becomes more critical, the Scalent V/OE system starts to look like a real bargain.
Logan G. Harbaugh is a freelance reviewer and IT consultant located in Redding, California. He has been working in IT for almost 20 years and has written two books on networking, as well as articles for most of the major computer publications.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?