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

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.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft TEST CENTER DAILY BLOG Track the latest product reviews and news from the InfoWorld Test Center. Scalent Virtual Operating Environment 2.0 Scalent Systems, scalent.com Very Good  8.5 criteria score weight Interoperability 8 25% Performance 9 20% Management 9 20% Configuration 7 15% Scalability 9 10% Value 9 10% Cost: Licensed at roughly $2,000 per agent Platforms: x86, x86-64, SPARC Bottom Line: Scalent’s V/OE promises much, and it delivers. By separating the server from the hardware, you can move server instances among physical hardware and even among virtualization platforms in a seamless manner that retains all network, iSCSI, and FC connections. Combined with a very attractive and usable Flash-based GUI, V/OE 2.0 is a glimpse of what a truly adaptive datacenter could look like. About our Reviews and Scoring Methodology

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.