Swinging with a BigIP LTM
Swing environments are all the rage right now. Ok, maybe not "all" the rage but creating a swing environment can theoretically make your life as a sysadmin a lot easier. What's a swing environment? It's an exact replica of your site's production environment which exists in an almost always ready-to-go-live state. It's not really failover, not really disaster recovery, not really staging. It's a physical copy of your site in hardware but your applications are always one release level different from the currently live site. If you have a BigIP deployed as your load balancer, you can do something interesting that I think is unique to the BigIP, (although I've not used too many load balancers but I know your network engineers would never let you touch their switch-based load balancers).
Picture the following. You've just spent all weekend deploying a large, complex update to your site and it's Monday morning. Site goes down--problems with the release. You need to back out the release but it is going to take hours because you need to redeploy your web content, revert your web and/or container changes, your application war files, database updates, which is essentially hours of lost revenue. It would be so nice to be able to just execute a script that would instantly revert your site back to the "last known good" configuration--especially since every 15 minutes one of the "suits" is breathing down your neck to get the site up.
To keep things simple, picture a typical three tier physical server design. You've got your web server in your dmz, an application server running whatever (tomcat, jboss, geronimo, glassfish, websphere, etc), finally the database. (Remember, I'm keeping this simple so I'm leaving out the multiple web servers, app servers, RAC cluster, etc.) This set of servers will be known as "Peter". The web server is front-ended by a BigIP, which is doing your SSL termination, maybe some caching, and sprinkle in some iRules for redirection, rewrites, whatever. The web server talks mod_jk or mod_proxy to the app server and the app server to your database. This silo of servers is a fixed chain.
Next, convince your CIO that this is a good idea and then build a mirror of this environment, which we'll call "Sylar". To keep yourself sane, know that no component in the "Peter" silo should ever communicate with a component in the "Sylar" silo.
"Peter" is a web server Pool consisting of, in our simple example, one server. "Sylar" is a Pool that contains the mirrored web server. The "www" site VIP currently contains the "Peter" Pool so all your end user requests for www.coolbeans.com get routed to your "Peter" web server. You deploy your next release to Sylar, which you are ready to go live with. Since the BigIP is scriptable with shell commands, you can write two shell scripts. Name one "swingToPeter.sh" the other "swingToSylar.sh". Using bigpipe commands built into the BigIP, your swingToPeter.sh script looks something like this:
Your swingToSylar.sh script will look something like this:
Execute swingToSylar.sh and the new release is live. Need to backout? Execute swingToPeter.sh and you are backed out--instantly.
Granted, having only one VIP where you detach one pool and attach another pool is not all that sexy but this becomes a much more compelling story when you are talking about multi-tiered environments with multiple VIPs and health checks. A simple modification of these scripts allows me today to simultaneously swing an infrastructure of multiple web servers with five different VIPs, multiple application servers with 7 different VIPs and an ESB simultaneously with each VIP using Pools contaning two or more load balanced servers! At the same time, I'm also detaching health checks from the one set of pools and attaching them to the other set of pools--all being done as fast as the BigIP can execute a shell script.
Picture the following. You've just spent all weekend deploying a large, complex update to your site and it's Monday morning. Site goes down--problems with the release. You need to back out the release but it is going to take hours because you need to redeploy your web content, revert your web and/or container changes, your application war files, database updates, which is essentially hours of lost revenue. It would be so nice to be able to just execute a script that would instantly revert your site back to the "last known good" configuration--especially since every 15 minutes one of the "suits" is breathing down your neck to get the site up.
To keep things simple, picture a typical three tier physical server design. You've got your web server in your dmz, an application server running whatever (tomcat, jboss, geronimo, glassfish, websphere, etc), finally the database. (Remember, I'm keeping this simple so I'm leaving out the multiple web servers, app servers, RAC cluster, etc.) This set of servers will be known as "Peter". The web server is front-ended by a BigIP, which is doing your SSL termination, maybe some caching, and sprinkle in some iRules for redirection, rewrites, whatever. The web server talks mod_jk or mod_proxy to the app server and the app server to your database. This silo of servers is a fixed chain.
Next, convince your CIO that this is a good idea and then build a mirror of this environment, which we'll call "Sylar". To keep yourself sane, know that no component in the "Peter" silo should ever communicate with a component in the "Sylar" silo.
"Peter" is a web server Pool consisting of, in our simple example, one server. "Sylar" is a Pool that contains the mirrored web server. The "www" site VIP currently contains the "Peter" Pool so all your end user requests for www.coolbeans.com get routed to your "Peter" web server. You deploy your next release to Sylar, which you are ready to go live with. Since the BigIP is scriptable with shell commands, you can write two shell scripts. Name one "swingToPeter.sh" the other "swingToSylar.sh". Using bigpipe commands built into the BigIP, your swingToPeter.sh script looks something like this:
#!/bin/sh
bigpipe virtual VIRT_www pool POOL_web_Peter
Your swingToSylar.sh script will look something like this:
#!/bin/sh
bigpipe virtual VIRT_www pool POOL_web_Sylar
Execute swingToSylar.sh and the new release is live. Need to backout? Execute swingToPeter.sh and you are backed out--instantly.
Granted, having only one VIP where you detach one pool and attach another pool is not all that sexy but this becomes a much more compelling story when you are talking about multi-tiered environments with multiple VIPs and health checks. A simple modification of these scripts allows me today to simultaneously swing an infrastructure of multiple web servers with five different VIPs, multiple application servers with 7 different VIPs and an ESB simultaneously with each VIP using Pools contaning two or more load balanced servers! At the same time, I'm also detaching health checks from the one set of pools and attaching them to the other set of pools--all being done as fast as the BigIP can execute a shell script.
