ClusterFunk

Zeus ZXTM What is it? At its most basic level the ZXTM is a application layer proxy / filter with the capability to (re)direct client requests based on any number of conditions. Any given resource e.g. a web site has its host name resolve to a IP that the ZXTM host. As requests for the resource are received they are inspected and decisions are made on what to do with the requests. The same process is also conducted on the response  

High Availability
The ZXTM works in a clustered configuration with any given IP been associated with a single ZXTM. In the event of a failure the IP is automatically bound to another ZXTM in the cluster and due to the way that state is distributed across the cluster all user connections are maintained including client session affinity (the relationship between a client and a specific host in a load balanced environment).  

Easy of Use
Application load balancing, sound pretty complex to me?  Wrong!
OK well they are but the ZXTM installation and set up is Child’s play.
Don’t believe me? check out this whitepaper, don’t worry its only  its two pages
This is an example of a solution been delivered in hours using ZXTMs. We did this in six hours from initial phone call to finalising load testing.

Capability
It seems that if you can think it, they can do it. The problem with ZXTMs is that they are so capable that you tend to want to use them to solve every problem

Metrics and comment on getting them.

This isn’t scientific because one of the biggest problem is that in order to generate meaningful load, lab equipment isn’t going to cut it. Either the traffic is not representative of the crazy stuff the people do in the real world OR the kit generating the load isn’t up to the task.

You try generating 50,000 concurrent connections to a web server in a manor that doesn’t result in the fantastic system resource optimising techniques kicking in. I’m thinking TCP/IP connection caching, SQL DB caching etc etc. 50,000 clients created by a test script for same query is very, very different to 50,000 live users. You get the picture. (I’m not criticising load testing it is very important but it has its limitations).  

So these figures are fro real live platforms that handle many other services as well as the specifics I mention. For simplicity these are all the same configuration.

Equipment

Hardware
2 x HP DL360 G5 2 x XEON 2.8GHz 8GB RAM, 146GB RAID 1 pair of 10K SAS HDs. Gigabit Ethernet connected to pair of Cisco 6509 switches.    

ZXTM
ZXTM v 5.0 on RHEL v5.01

Configuration

This is how we configured the solution. Mostly a single (Traffic IP or VIP) is shared between a pair of ZXTMs for resilience.

Edge Cache Capability

ZXTMs working as an edge cache for an infrastructure that had been overwhelmed by demand for the site. ZXTM server the site from memory (content cache) and refer to origin if not in memory. Tested 5000 concurrent connections with content severed by ZXTM at around 75Mbps, less than 1Mbps seen at origin even with 2 minute cache flush. CPU utilisation at 2% with 500Mb of 8Gb of RAM utilised. 

Traffic Script
Another application involved the same ZXTMs delivering a web page to client flash application every 5 seconds. 50,000 concurrent connections polled the (active/passive) pair of ZXTMs for three pages every two seconds for one and a half hours five nights a week. The ZXTMs handled 162,000,000* connections over a course of one and a half hours, delivering 200Mbps for the entire period.

Traffic Script is the mechanism used to manipulate protocol request and responses and a lot,lot more. A much more details here.  

* Is that a lot? I think that’s quite a lot  

SSL Offload 
The ZXTMs can offload SSL (very well) which is great because the last thing you want to do is have to try to maintain state* in a load balanced environment were the traffic is encrypted between a point outside your network and a point inside.

As you may or may not know SSL is quite a resource hefty task for a web server or network device to cope with. We had a requirement for a single sign-on solution to be able to handle 330 requests per second. We tested to 150 SSL terminations per second against a single ZXTM before the clients load testing equipment hit its limit. The test connection was a requests against a web server to authenticate the users and issue a session cookie. In production the pair of ZXTMs handled the load whilst delivering 20Mbps for the edge cache for the solution above and handling redirects for a mobile version on the prod site the solution was serving.     

* yet again the good people at Zeus have something called transparent session affinity that can assist if you really, really must not touch the SSL on your perimeter.

Network Through Put

In this environment we have seen a sustained 750Mbps through the ZXTMs while a particularly popular TV program presented an online vote option.   

Peak Load
I have spoken to Zeus about this and the consensus seems to be that the ZXTMs can handle around 2.1Gbps of throughput for this specification. Obviously that very much depends on the nature of what you are doing but if you have an specific question please let me know and if I can’t answer them I know a man that can.  

I am going to present or metric from other deployments and I am collating some information at the moment around a number of VM based deployments I have designed which I will document in the next few weeks  

Some more reading

Capabilities http://www.zeus.com/products/zxtm/options.html 

Lots more information here  http://knowledgehub.zeus.com/docs