The XML Director -- aka the Intel 7280 -- is a fourth-generation traffic manager that can make routing decisions based on the content of any given field in an XML document. That includes, for example, the cost of a purchase at an e-commerce site. The product provides a host of valuable features, but the XML-based tools are most appealing.
A combination of SSL (Secure Sockets Layer) acceleration, Layer 4 and Layer
7 load-balancing, traffic prioritization based on XML fields, and a highly valuable error-detection and recovery system makes XML Director one of the most robust load-balancing appliances available. It provides both a Java 1.1-based GUI as well as a traditional CLI (command-line interface) for its management and configuration. Management also can be accomplished via SNMP. And a strict set of connection restrictions provides security for both local and remote locations.
But all is not perfect on the Intel farm. The company must work out some configuration and management issues before XML Director can take the market by storm. At a cost of $44,995, Intel's XML Director is functionally worth the price -- assuming that none of its quirky management "features," such as the inability to make modifications to cluster or server definitions, costs you valuable time.
Security and Speed
To test XML Director in our partner labs at Schneider National in Green Bay, Wis., I set up the 2U form-factor appliance to front a three-server cluster and configured the system parameters and security via a console connection. The product ships with all connectivity disabled.
Connection-based security is provided via IP-based ACLs (access-control lists). An interesting and potentially problematic feature is the management of logins. The first login is given read and write access. Any additional concurrent logins are given read-only access. You won't be able to offer more than one administrative connection at a time, and you'll want to guard that single connection by allowing administrative access from a single location.
Once I'd configured the initial security features, I installed and ran the remote-management application. The application allows all features, except certificate creation and management, to be configured and managed remotely via the GUI. I created and configured a key and certificate for the virtual Web site remotely via telnet using the CLI.
One of the product's most impressive features is its handling of SSL. XML Director, unlike many SSL-acceleration devices, terminates the SSL session to decode the traffic and make routing decisions based on the content. SSL functionality is provided via an OEM of a Rainbow Technologies cryptographic acceleration card. Because the SSL session is terminated at the device, all traffic between XML Director and its cluster of servers can occur via an unencrypted channel, relieving Web servers of the burden of providing SSL support.
Unfortunately, the configuration of XML Director is one area that still needs attention. You absolutely do not want to make a mistake with the configuration.
Once an entity, such as a server or a cluster, is configured, its configuration information cannot be edited. To modify a back-end server's configuration, for instance, you must delete the entity and then re-enter its information. This problem is not a small one: A mistake in the configuration of a cluster means you have to start over from scratch.
Advanced Features
I tested several features of XML Director that often are not found in load-balancing products and found its error-recovery feature to be particularly useful. I set up the unit to load-balance between two identical Web servers using a round-robin algorithm.
Using a Web browser, I loaded a single image, bg.jpg, on each machine. The file on one Web server was a block of yellow; on the other, it was a block of red. The first hit to the Web site being served returned a yellow image, and the next returned a red image; they alternated continuously. I then changed the name of the file on one server (the one serving up the yellow image) to bg1.jpg. Every successive request for bg.jpg returned the red version. In other words, when XML Director encountered a request it could not fulfill from its first server choice, it tried another server. In the event of missing content, XML Director attempted to locate that content on other servers to ensure that the user never sees a "missing" image or document.
XML Awareness
I set up a scenario under which I could examine XML Director's XML decision engine. Setting up the XML Director to load-balance based on XML content was simple, but the syntax may be confusing for those not familiar with XML. XML Director uses a subset of the XML Path Language (Xpath) standard for document operations. Pattern matching is available, as are several familiar function calls, such as starts-with and contains.
The XML abilities of XML Director are based on Layer 7, or rich content switching, as it's called in the Intel vocabulary. My XML requests were based on the submission of purchase orders and included a "Value" field representing the amount of the purchase. I set up the test to direct traffic with a "Value" of $10,000 or greater to one server and to send all other traffic to the remaining server.
Using a traffic-generation application developed by Intel, I generated XML requests and examined the results. A real-time graph showed the activity of each Web server and that XML Director was indeed directing traffic based on the XML content.
XML Director also can direct traffic based solely on the dialect of the XML being received. For example, all incoming traffic that uses the BizTalk dialect can be directed to one server, while traffic using cXML (Commerce XML) and CBL (Common Business Library) can be sent to another.
Almost There
I found XML Director to be just what I had hoped it would be -- a robust load-balancing device with features that are well-suited to servicing the business-to-business world. But it will take some additional work by Intel on the configuration and management of the device to make XML Director a best-of-breed appliance.
Send your comments on this article to Lori MacVittie at lmacvittie@nwc.com.