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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide