Exclusive: Scalent Virtual Operating Environment puts new twist on the adaptive datacenter

Not many products truly deliver what they promise. Scalent V/OE (Virtual Operating Environment) 2.0, however, comes as close to keeping its pledge as anything I’ve seen. Scalent is attempting -- and succeeding -- at reaching the pinnacle of datacenter management: a truly adaptive infrastructure.

Scalent V/OE has three components -- a central Controller, Agents on the servers, and a nifty GUI Console -- that separate the server from the hardware, making it possible to move server instances, called “personas,” between physical hardware and even between virtualization platforms in a seamless manner that retains all network, iSCSI, and FC (Fibre Channel) connections.

Meet your personas

I took a look at the forthcoming release of V/OE 2.0, and it’s quite complex. It involves a controller built on a Red Hat Linux base that essentially has its way with all associated network switches and server hardware. Switch interactions are handled via SNMP; the server side is driven by IPMI (Intelligent Platform Management Interface)-compliant lights-out management features or a virtualization platform such as Microsoft Virtual Server, VMware, or XenSource.

Because of these requirements, V/OE has a relatively short list of supported hardware, including that of major vendors such as Cisco, Dell, HP, and Sun. I worked with a selection of servers, including three HP ProLiant DL360s, a Sun v20x server, and a Dell PowerEdge 2800 that I added later in the testing. One of the DL360s was running VMware ESX Server 2.5.2 with a single local disk, and the others were diskless.

Installation is also quite complex, so Scalent sends an engineer to do the initial build of the infrastructure, including assistance in building the initial server personas.

A server persona is a server built for a certain task, replete with applications installed and configured. For instance, an Apache Web server could be built on any physical server, configured, have an application installed, and then be condensed into a persona. The same goes for Windows 2003 Servers, as well as for Sun Solaris 10 SPARC and x86 systems.

All of this is hardware-independent. A persona could be created on an HP ProLiant DL360, but then deployed on a DL380 or even as a VMware ESX 2.5 guest server.

There are some differences in the way personas are built, depending on operating system. Linux personas are generally built and run as netboot systems, with their file system residing on an NFS server central to the solution. Windows servers cannot leverage the netboot/NFS simplicity, and they are subsequently booted from an iSCSI or FC SAN that contains a disk image of the server. The iSCSI booting is handled via emBoot, with the initial boot stage run via PXE, the same as all other servers.

The Scalent Agent, the second piece of the puzzle, is the key to the true hardware/OS abstraction. Each persona runs an instance of Agent, which interacts with the controller to determine network and SAN connection parameters, IP addresses, and other ancillary data for the proper placement and configuration of the server persona on its hardware. Booting the server personas from the network also eliminates the need for a local disk on most servers.

What’s relatively unique isn’t so much the creation and management of the server personas but rather the persistence of this configuration data across multiple hardware platforms. It’s done by clever use of 802.1q trunking and dynamic switch interaction.

Each time a persona is booted on any piece of hardware, the Scalent agent configures the network interface to be an 802.1q trunk back to the switch and assigns IP and MAC addresses to virtual interfaces within the OS. This ensures that the proper interface exists on the proper network with the proper IP information.

Moving a server persona from one server model to another -- and then to a VMware instance -- now becomes simply a task of instructing the PXE-booting hardware as to what image to load. Slick.

I did have a problem here with Windows servers booting on different hardware. It’s occasionally necessary to reboot a Windows persona a few times so that all the hardware is recognized and becomes available. This is more the fault of Windows itself, which is less forgiving than other OSes when the underlying hardware changes.

Although I’m far from a GUI guy, Scalent’s Console interface is as attractive as it is functional. It’s completely written in Adobe Flash. When viewing the infrastructure in Virtual mode, you see representations of each server persona with “cables” linking those personas to virtual switches, which then link to other servers.

The result appears similar to a Visio diagram with a notable difference -- this one is interactive. Dragging another persona into the diagram and linking it to the proper vSwitches, giving it IP address information, will automatically place that new persona in the right logical network segments.

Booting the server will bring it up right where you expect it to be, regardless of whether it’s running on a physical server. This is also true of software- and hardware-based iSCSI HBAs and FC HBAs. Modifying the WWNN (World Wide Node Name) on iSCSI isn’t terribly hard, but masquerading the same on FC HBAs certainly is, so Scalent supports only a few FC HBAs from QLogic and Emulex.

Data on the move

After the Scalent controller and the HP ProLiant DL380 running NFS and iSCSI target services had booted, I logged in to the GUI and looked through some of Scalent’s pre-built personas. There was a wide variety of OSes and applications, including IBM WebSphere, Oracle, simple Apache and IIS Web servers, Linux-based load balancers, and even Active Directory domain controllers.

Each sample infrastructure was laid out separately from the rest, with personas connected via cables to dedicated vSwitches. I group-selected all of the personas used in a single application instance -- including an Oracle server, two load-balanced BEA servers, three Apache Web servers, and a front-end load balancer -- and then clicked the start button.

Within a few seconds, all three physical servers began booting, as did four of the VMware servers. The controller inspected the dependencies of all the personas and determined that the Oracle and BEA servers should be run on the physical servers to accommodate their high resource utilization; the Web servers and load balancer could run within VMware. Each server came up, the UI automatically updated with the status of the servers, and after a normal boot time, the application was available. Very cool.

My next test was automatic fail-over, so I made sure that none of the physical servers was running a persona and booted several Apache Web servers on VMs within VMware. The personas were configured to prefer a VM, but to move to a physical server if no VMs were available.

With two servers running within the VMware server, I manually shut down that physical server. The UI updated with the status of the VMware server persona showing as down, and the Web servers showing a status of retargeting, but nothing happened.

After waiting several minutes, I decided to manually turn off the VMware server because the server was still powered on. As soon as I shut it down, the VM personas began to migrate to physical hardware.

The delay happened because Scalent is very conservative when it comes to retargeting personas; the controller needs positive evidence that the persona is not truly running before it Click for larger view. will move the persona to another physical resource. It’s a necessary step to prevent one persona from ever running on two systems at the same time. Still, I’d like to see closer interaction with VMware, as well as support for the new VMware Infrastructure server and better logging visibility -- all of which will, hopefully, be available soon.

Another issue involves server network performance. By default, all network interaction for each persona is run through a single NIC, including the NFS root mounting on Linux, iSCSI LUN (logical unit number) connections, and front- and back-end connections, which can create throughput issues.

It is possible to dedicate certain virtual NICs to physical NICs at the persona level, but this requires each physical NIC be connected to separate physical switches to complete the layout. This layout expands with each NIC, so a persona built with a requirement for four dedicated NICs would require four separate switches.

These caveats aside, Scalent V/OE is surprisingly elegant, very usable, and impressive in action. Given what I’ve seen so far, I have every reason to believe that Scalent’s solution will make a big splash.