Exclusive review: HP BladeSystem Matrix

Insight Orchestration offers two main views of the servers within its purview: a logical view that displays physical and virtual servers together, and a physical view that displays virtual servers underneath the physical host header. Physical servers can be broken out into server pools, separated by any number of admin-defined criteria, such as Intel and AMD CPUs, blades that should be used for Windows servers, blades that should be used for VMware ESX hosts, and so forth. This allows admins to specify which hardware gets pulled into service for any given purpose. For instance, a BL460c server blade with dual quad-core CPUs and 32GB of RAM might be in the ESX pool, while a lesser configuration might wind up in the Windows pool.

The datacenter as art
Once the hardware is up and running, the interesting part begins. Using the Insight Orchestration Designer's drag-and-drop interface, templates defining individual servers and entire application suites can be constructed in just a few minutes, verified for compatibility with existing hardware and hypervisors, then published. Next, an admin with rights to that template can fire off a task to build it, and Insight Orchestration does the rest.

[ Datacenter automation and virtualization go hand in hand. See the Test Center reviews of VMware vSphere 4, VMware View, Citrix XenDesktop, and Microsoft's Hyper-V and SCOM Virtual Machine Manager. See Network World's review of VMware vSphere 4 and comparative hypervisor performance tests. ]

The nuts and bolts of how this works is important to understand. Using existing links to all the involved pieces (with some exceptions in the EVA storage management), Orchestration builds each server according to the template specifications. If one or more servers are run under VMware VI3, for instance, Orchestration will use calls to vCenter to define the server parameters, reference an existing VM template, and build the new virtual server automatically. If the server to be built is a physical server, links to the HP ILO management processor for that blade are used to boot the blade, and connections are made to the RDP server to signal the desired operating system and configuration requirements for that particular blade. The blade then PXE boots, hits the RDP server, and begins the build process.

All this happens in the background, with the admin basically pushing a Go button. As an example, I was able to build a new template for a Linux-based application comprising a Web server and database server, then have the servers configured and built about 20 minutes later. I could then repeat that process as many times as I liked, by simply creating a new service from that template.

A few manual steps are required for some builds. Because Insight Orchestration is still missing some links to the EVA storage management software, certain builds must be prepared -- with LUNs defined and activated by a storage administrator -- prior to building of a new server. You can speed up these deployments by predefining significant numbers of LUNs of the required sizes and flagging them with unique keywords to be used by the Orchestration Designer templates to allocate storage. Ideally, Orchestration would allocate the LUN on the fly when the template is used to build a new server, but for now the LUN must already exist -- and contain the appropriate keyword -- in order for the build to succeed. HP hopes to remove this manual step soon by providing better hooks into the EVA management.

Costing, leasing, and clients
I was quite happy to see that the concept of server and service costing has been integrated into the Insight Orchestration solution. When a template is designed, the server and its application can be assigned an overall cost, which is present to the users when they request a service build. Especially with virtual servers, VM proliferation is not a laughing matter, and assigning costs to those servers -- and obviously to physical servers -- can help reign in the number of VMs running on a particular infrastructure. When users see dollar signs, they tend to act more conservatively.

But there's also the option of creating a lease time on a template. In essence, this provides a fixed termination date for a service build. Thus, a working group could request a build of a particular template with a year lease. At the end of the lease duration, the servers will be automatically torn down and the hardware returned to the available pool. This isn't completely automated, requiring administrator approval before any server destruction actually occurs, but it does offer another method to help reduce the number of extraneous servers littered about the network.