Dell AIM automates today's data center

Dell's adaptive infrastructure management framework has something competitors don't: support for heterogeneous hardware

Corralling the myriad physical and virtual servers that exist in IT shops of any size is a daunting task, and management tools that ease the burden are in hot demand. Naturally, all of the big guys are out to win this "adaptive infrastructure management" sweepstakes. HP threw its hat into this ring with HP BladeSystem Matrix in the first half of 2009, and Cisco entered the fray with Cisco UCS later in the year. Now it's Dell's turn.

Like HP and Cisco, Dell has been working on a way to bring all the disparate systems that comprise a data center under a single management umbrella, but with a twist on the HP and Cisco playbooks. The difference is that Dell is trying to remain as vendor-neutral as possible. Largely, it's succeeding.

[ Get the no-nonsense explanations and advice you need to take real advantage of cloud computing in InfoWorld editors' 21-page Cloud Computing Deep Dive PDF special report. | Stay up on the cloud with InfoWorld's Cloud Computing Report newsletter. ]

Dell's AIM (Advanced Infrastructure Manager) software used to be known by another name: Scalent V/OE (Virtual Operating Environment). (Dell began selling Scalent V/OE under the Dell brand in 2009 and finally acquired the company in July.) I last looked at the Scalent offering four years ago, and much has changed since then. Most significantly, Dell has been busy leveraging the Scalent solution throughout its hardware line, including its PowerConnect switches and EqualLogic iSCSI storage arrays. But Dell has also kept the hardware agnosticism of V/OE alive, which is a key differentiator to its main competition.

Whereas HP and Cisco are limited to their own servers, blade chassis, and switches, Dell's AIM can handle a wide variety of vendors at every level of the solution, from servers to Ethernet switches to storage arrays. Deploying HP BladeSystem Matrix or Cisco UCS requires the purchase and installation of their gear, but you can introduce AIM into an existing infrastructure comprising Dell, HP, IBM, Cisco, and other hardware. Not all AIM features are available across all vendors, and some tasks may require a degree of human interaction, but in most cases the main needs are met.

In a nutshell, it's possible to have a completely automated infrastructure using all Dell gear, or a nearly completely automated infrastructure using an array of hardware from other vendors. Either way, it's an impressive value proposition.

Dell AIM: Tale of the test

Like its HP and Cisco counterparts, Dell AIM has been built to turn all the knobs and flip all the switches necessary to deploy, migrate, extend, expand, repurpose, and recover a server infrastructure -- physical or virtual -- without the assistance of an administrator. Throughout my testing, I was impressed with the way AIM handled all the curveballs I threw in its direction.

Test Center Scorecard







Overall score







Dell AIM 3.3








Very Good

For example, I took a RHEL5 "persona" (AIM's term for a managed server image) and booted it on a Dell blade, moved it to an HP ProLiant 1U server, next to a VMware vSphere virtual machine, back to a blade, and then to a Microsoft Hyper-V instance. Throughout all those gyrations, the only problem encountered was when Hyper-V had an issue with the ACPI (Advanced Configuration and Power Interface) shutdown and had to be manually powered off -- a problem wholly owned by Hyper-V.

In other cases, I was able to trick AIM into unknown states, but it invariably landed on its feet, such as when I created a new persona from a blade that had a RHEL5 system installed on the local disk, then booted that persona on another blade. The second, target blade was a known AIM server resource, and thus was configured to PXE boot to pick up any new persona it had been assigned. However, I selected to boot from the local disk and thus brought up an identical server to the one I'd just created. In essence, there were two identical servers running, potentially with identical IP information, running identical services. To its credit, AIM threw a stream of notifications into the logs about the mysterious new server that had appeared and didn't attempt any half-cocked remedies.

The testbed I worked with was quite varied in terms of different hardware. There were a half-dozen Dell blades in a Dell PowerEdge M1000e chassis, a few HP ProLiant DL385 G5 servers, Dell PowerEdge R710 and R610 servers, and Cisco and Dell Ethernet switches, backed by a Dell EMC CX4 240 FC array and a Dell EqualLogic PS6000XV iSCSI array. It was a quite reasonable representation of a heterogeneous computing infrastructure, and AIM handled all the pieces fluidly.

AIM could ostensibly be used to manage multiple data centers in different locations, but Dell doesn't recommend it. Dell would have you tie AIM to a single data center, though you could accomplish an end run by deploying an AIM controller in each data center and using SAN replication to sync server LUNs between the two.

VMware vSphere shops should note that AIM currently has no understanding of VMware's vApp concept. AIM can't see the various dependencies among the virtual machines in a vApp and act accordingly. This is a minor quibble, but could be an important factor in some data centers.

While AIM is the centerpiece of Dell's adaptive infrastructure play, it's supported by two other wrap-around components in the Dell Virtual Integrated System (VIS). The new Dell VIS Self-Service Creator adds self-service provisioning to the mix, while the forthcoming Dell VIS Director will handle service monitoring, dependency mapping, capacity planning, and cost allocation for AIM-managed infrastructures. (See the sidebar, "InfoWorld preview: Dell's VIS vision takes shape.")

All in all, AIM is a remarkably complete and very ambitious tool, limited only by the present pain of initial integration and the occasional problem related to someone coloring too far outside the lines. It's largely an all-or-nothing solution, but the benefits provided -- namely, the ability to efficiently and easily move servers across a wide array of hardware and virtualization platforms -- and the degree of automation it brings even to heterogeneous infrastructures are impressive.

Dell AIM: Essentials and prerequisites

AIM provides a Linux-based controller that is tied into just about every aspect of a data center. It has hooks into the physical servers' out-of-band management processors (DRAC, ILOM, or ILO), and can manage blade chassis from a variety of vendors. It has hooks into the relevant portions of the switching infrastructure, be they Cisco, Dell, or Juniper switches, as well as storage switches from Brocade and Cisco. AIM can also reach out to Dell's own EqualLogic iSCSI SAN arrays to automatically provision storage.

Beyond the hardware, the solution also leverages agents running on each server instance, as well as agents installed on VMware ESX servers and other hypervisors. Further, the controller is tied into VMware's vCenter, Microsoft's Hyper-V, and Red Hat Xen virtualization frameworks.

As with any solution so ambitious, there are some up-front requirements. First and foremost is the need for the underlying network topology and configuration to be clean, well defined, and well designed. A normal implementation includes a central L2 network built specifically to allow the AIM controller to discover the various physical and virtual servers in its domain and manage them via DHCP and PXE. However, the controller will function in an L3 network as long as the requisite broadcast packet forwarding configurations are in place on the management VLAN.

As your production networks and VLANs are defined, they are displayed in an interactive network diagram, much like a live-action Visio layout, in the AIM GUI. This GUI drives everything that AIM does. To deploy a server persona -- a complete server profile including OS, applications, and hardware and networking requirements -- to a specific server node or virtual server farm, you simply drag it to a block on the diagram. The end result is that server personas can be run on either physical or virtual servers and remain connected to the networks they require, no matter where in the infrastructure they happen to reside. Personas can even be given minimum and maximum hardware rules, in which case AIM will try to run the persona on a high end system, but if none are available will boot it on a low end box.

AIM accomplishes all of this with the aforementioned switch interaction. When a server persona is booted on a physical server, AIM knows which switch and which switch ports that physical server is connected to, and it makes the requisite configuration changes on that switch to allow the correct networks to be presented to the persona. The switch can also be called upon to create VLAN trunks if required or to link aggregation configurations. On the storage front, if the persona is running on a Fibre Channel SAN, the server's HBAs will be configured to present the appropriate LUNs. If all that sounds like a very complex task, rest assured, it definitely is. But after initial configuration is done, the complexity is hidden beneath AIM's slick, Flash-based GUI.

The other side of that coin is virtualization. AIM is cognizant of the hypervisor configurations via hooks into the management frameworks of the three supported virtualization solutions and can make adjustments to the virtual switches as necessary. AIM can even present the correct VLANs to those hypervisors and ensure they're available to the personas that may be running as guests on those hypervisors.

There are also gradients of automation. For instance, you can instruct AIM to address any particular switch in read-only fashion, where it can gather information from the switch but is not allowed to make any modifications. In this case, when switching changes need to be made, AIM will simply alert admins about what alteration is required. It's also possible to prevent AIM from ever modifying certain switch ports, such as uplinks and so forth. In this way it's possible to implement AIM in baby steps rather than immediately handing over all the keys to the controller.

Dell AIM: Physical and Virtual views

Using the AIM GUI is simple once you get used to the different views and wrap your head around the constant need to save and confirm any actions you may direct. The two main views are Physical and Virtual. The former shows all the physical servers present and known to the controller, and breaks out virtual servers running on any hypervisors by displaying them within the container for the physical host they reside upon. All known Ethernet switches are displayed as well, as are the various physical links between servers and switches.

Server personas are pictured on each physical or virtual server instance they happen to be running on at the time. Clicking on them reveals relevant information for that persona in a sidebar, while contextual menus allow for common administration tasks to be run from this view.

The Virtual view shows each persona as a block with an icon denoting the OS installed and the name of the persona. Links between the servers across the various AIM-controlled networks are then drawn just as you'd expect, with a VLAN represented as a hub and the spokes heading out to the personas connected to that particular network. As with the Physical view, clicking and right-clicking on the personas permits further information displays and actions that can be performed on the servers.

The key here is that in Virtual view, there's no concept of whether the persona is running on a virtual machine or a physical server, or what particular hypervisor or type of physical server that may be. This is by design, as AIM tries to divorce the concept of a server from any specific piece of hardware or software. It's simply a server instance.

Of course there are other views as well, which are largely informational, such as the event log, and a dashboard view, which can show each rack, the personas currently running on it, as well as statistical overviews of the whole infrastructure.

One element that doesn't exist in AIM itself is provisioning new servers. AIM is strictly focused on managing known resources, not creating new resources. Dell's plan for handling service provisioning is through the use of the new VIS Self-Service Creator. Without Creator, adding servers to an AIM-based infrastructure is left up to the admin. All a server needs to be included in the AIM umbrella is to be discovered by the AIM controller, and this can be accomplished with or without running an agent.

An easy way to make a server discoverable would be to leverage templates or cloning on a virtualization hypervisor. For instance, a VMware server template could be created that contains all the requisite AIM agents, and creating a new VM from that template and booting it up would automatically cause that server persona to be manageable by AIM. Of course, building a physical server and running the AIM agents is also an option.

Dell AIM: Personas in motion

AIM provides a variety of ways to move server personas around the infrastructure, depending on the source and destination of that particular persona. Take a physical server, a Dell PowerEdge R710, running a Red Hat Enterprise Linux 5 persona, for example. That particular persona exists on an iSCSI LUN and needs to be booted on another server -- say, an HP ProLiant. Within the GUI, that persona would be shut down, assigned to either a specific ProLiant system or to a pool of ProLiant servers, and then started.

When the start action is made, the controller sinks its hooks into the management processor of the ProLiant and turns the server on. As part of the integration into AIM, the server has been configured to boot from PXE on the management network interface, and proceeds to do so. The controller sees the PXE request and feeds a specific bootstrap shim to the server that causes the necessary MAC address and, if necessary, Fibre Channel WWNN (World Wide Node Name) changes to take place, then reboots the server again.

The subsequent reboot shifts the PXE boot to the iSCSI LUN, and the RHEL5 persona boots on the HP host. With sufficient prep of that persona, the HP OS agents can be present and utilized alongside the Dell tools, VMware tools, Hyper-V tools, and so forth, so that the persona can feel right at home no matter what host it happens to be running on at the moment.

Several layers of network virtualization may come into play here. A virtual NIC controlled by AIM can be presented to each persona and each required network presented to the OS through that conduit. The server OS remains unaware of the underlying hardware changes and simply sees that it has interfaces that are on the right networks.

In other cases, the persona definitely knows that the underlying hardware has changed, as it may have previously booted on an Intel Westmere-based server, and is now running on an AMD Opteron system. Both Linux and Windows will boot gracefully throughout these changes, although Windows is more prone to the occasional hiccup deriving from significant underlying hardware changes between boots.

Dell AIM: Virtual server management

It's also possible to move personas from physical servers to virtual servers and back again, but there are some key differences in management styles and techniques that need to be understood.

First, within AIM, virtual servers are treated much the same as their physical counterparts. For instance, a vCenter configuration might have several physical hosts in a cluster and many dozens of virtual servers running on that cluster. However, those virtual servers are generic -- they're just resources to be used when a persona needs somewhere to run.

This means that they can't be named in any meaningful way or considered as anything other than a collection of resources. You might have virtual machines named VCVM-2P2G-01 through VCVM-2P2G-20, which might represent 20 virtual servers configured with two vCPUs and 2GB of RAM, while another set of VMs might have two vCPUs and 4GB of RAM. Each of these sets of virtual machines might be organized into specific server pools within AIM, and the personas destined to run on them would then be assigned to whichever pool is best suited to handle their particular workload.

Thus, perusing your VMware infrastructure from vCenter will be somewhat opaque, since there's no concept of what server personas are running on what VM; all that information is kept in the AIM GUI. That said, Dell offers a vCenter plug-in that connects to the AIM controller and displays much more information, including hosts, personas, physical servers, and networks from within the vSphere client. It's a handy way to check on AIM information without leaving the vSphere client, but it's not really a substitute for the AIM GUI.

Integration with Microsoft's Hyper-V and Red Hat Xen is handled the same way as with vSphere. These hypervisor managers are simply repositories of computing resources defined and connected to AIM, allowing AIM to place personas when and where needed.

Dell AIM: A long way to the top

While the end result is quite impressive, it's important to note the realities of converting an existing infrastructure for use with AIM. To put it simply, it's a lengthy process.

Each switch, storage array, physical server, and virtual server in the pre-AIM environment must be discovered by the AIM controller. For switches and storage gear, this is handled by configuring the AIM controller with the IP and authentication information for each of these devices. For existing physical and virtual servers, it means defining the management processor IP, type, and authentication, and providing the same pathways to the virtualization solution management tools.

That's the easy part. The hard part is getting all of the existing physical and virtual servers into AIM. This is a manual step that must be done for each server, physical or virtual.

As with many admin tasks, it's easier on Linux. A Linux server can be turned into a persona by installing a few RPMs and running a script, assuming that the destination LUN has been presented to the server already. The script creates the file system on the LUN and copies everything over. Once that's done, the server exists in AIM as a persona and the physical incarnation can be turned off. Generally, this conversion can be scripted rather easily.

On Windows, creating a persona from a server requires downtime. The server must be booted from a Windows PE-based conversion tool that can then be used to mount an existing LUN or to create the LUN if the destination storage array is a Dell EqualLogic box. Following the LUN creation, definition, and mounting, the tool then copies the server over to the new LUN and inserts the required drivers into the system on the fly. After the conversion process is done, the server exists as a persona in AIM and can be assigned to a physical resource and brought back online.

Dell expects that its customers will require the assistance of Dell engineers to get the solution up and running from scratch, with a handoff to IT admins somewhere down the line. However, the company also thinks it's feasible to automate and streamline the installation process in the future.

As with any data center automation solution, AIM will require a substantial up-front investment, both in terms of budget (the solution starts at $1,810 per socket) and effort. Once you're past that hurdle, a solution such as AIM will significantly improve day-to-day operations of the data center. After all, that's the goal. The only question is whether it's time to take the plunge.