Emissary is a 1U form factor, Intel-based, load-balancing appliance running FreeBSD. The device can perform local load-balancing duties as well as global load-balancing. With centralized Web-based management (its command-line interface is used for basic network configuration only) and remote upgrade capabilities, Emissary is very easy to manage. In addition, network-based failover is provided for high-availability configurations.

I tested a beta version of Emissary in our Real-World Labs® in Green Bay, Wis., and was impressed by its flexible geolocation-configuration options and the ease in which the product integrated into our network. Because I looked at a very early beta version, some features -- such as complete geographic mapping of locations to sites at the city level -- were missing via the graphical interface. However, these capabilities were available by using manual techniques.

Simple Setup

I inserted Emissary into the DMZ in our labs and configured both of its network interfaces -- one for public access and the other for internal communication with the Web servers that would make up its clusters. Configuration via the CLI was a breeze, and within minutes I was able to access the Web-based GUI via Emissary's external IP address.

Coyote Point Emissary's Flash(y) interface (screen view) Click here to enlarge

Using the Web interface, I created two clusters, each with a public IP address. For each cluster, I added one internal server. Generally speaking, you'd add more than one, though doing so is not necessary.

Several load-balancing algorithms are available and are based on values such as round-trip time, server load and the assigned weight of a server. The Web servers also require a default gateway change: Emissary does not support a direct-return or an out-of-path configuration. I ran a quick test to confirm that both clusters were ready for use.

Creating GeoTargets

With the general load-balancing configuration out of the way, I moved on to the cool stuff: the geotargeting configuration. I wanted to configure one site to serve California, Colorado and Madison, Wis., specifically. Visitors from other locations would be directed to the second site, which was configured as the default site.

To achieve this, I created a GeoCluster. The GeoCluster must be given a FQDN (Fully Qualified Domain Name) and, just as with any global load-balancing implementation, Emissary would serve as the DNS server for that FQDN. When a request is received by Emissary, it takes the client's location into consideration when determining which site and, therefore, which IP address should process the client request.

Within the GeoCluster I created two sites: Site 1 was for California, Colorado and Madison; Site 2 was for default and De Pere, Wis. Each site was given an IP address that corresponded with an existing cluster. It was then necessary to configure each site to respond to requests based on the location of the client. This is accomplished via a Flash 5-based interface provided by Digital Envoy and integrated directly into Emissary's Web-based interface.

Vendor Information Emissary, $25,000 plus usage-based license fee. Available: Now. Coyote Point Systems, (650) 969-6000; fax (415) 954 8598. www.coyotepoint.com. Digital Envoy, (678) 258-6300; fax (678) 258-6363. www.digitalenvoy.net

Not only is this use of Flash technology effective, it's quite a bit more interesting and, pardon the pun, flashy than using typical Java-based interfaces.

Using the Flash interface, I configured Site 1 to handle traffic from Texas and New York. Because my copy of Emissary was a very early beta, I could not perform city-level designations via the Flash component of the GUI. However, I was able to add the city-level configuration via the HTML interface manually. Coyote Point assures me that Emissary's final release will offer the ability to add city-level designations using the Flash component.

Because I couldn't readily delegate Emissary as the authoritative DNS for the FQDN, I edited my resolv.conf file to use the Emissary IP address as my name server and did a quick lookup on the FQDN. It returned the address for Site 2 without a hitch. I asked a technician at our Madison lab to try this as well, and he received, as expected, the IP for Site 1.

I then reconfigured the Emissary, reversing the designations such that Site 2 serviced Madison, and Site 1 serviced De Pere. Another DNS query confirmed that I would now be directed to Site 1. Our man in Madison did another quick test and confirmed that he was now being directed to the IP address for Site 2.

Rough Reports

Emissary also provides rudimentary reporting features. The reports can be generated by GeoCluster, cluster or individual servers. Each report can be gleaned from statistics gathered from the past five minutes to the past week, and can include site-level details, such as how many requests were handled, network latency and triangulation errors.

At the server level, data about active connections and requests handled is compiled. If there is one place where Emissary could use a bit of work, it's here. The reports aren't very elegant, nor are they rich with detail options. You can zoom in on data in the graphs, but that's all you get -- graphics.

I'd like to see reports that are a bit more usable and specific in terms of actual data points or at least get a textual summary of highs and lows.

Coyote Point Emissary, which includes one year of support and service options in its base price, is an affordable, easy-to-manage Layer 4 load-balancing device. And the product's geotargeting capability makes it a great solution for enterprises and service providers that want to offer personalized, location-specific content for clients without writing a ton of code or investing in a costlier Layer 7 solution.