The use of variables inside of iRules is a common practice. Whether you're storing a URI to be re-written on the response from a server, parsing out valuable packet info with a scan, or incrementing that counter to keep track of how many users come in from a given source, there are many ways to use variables to extend and enhance your code. One of the things that gets discussed more and more these days, when talking about variables in iRules, is the use of global variables.

A global variable is a variable that can be set within an iRule that will exist until unset or the config is re-loaded. This is unique because normal, non-global variables, like the iRules themselves, are connection based. After a given connection terminates, any variables that were spun up from an iRule for that connection existed in that context, and are now torn down. This keeps memory free, allows for name re-use between connections, etc. When there is a need for storing data in a variable across multiple connections though, global variables step in to get the job done.

While global variables are a great tool to be used when necessary, we've always cautioned against their over-use, as there are a couple limitations with them. The main concern with global use these days is that they aren't quite Clustered Multi-Processing (CMP) friendly yet. CMP, briefly, is clustered multi-processing. It's how some of our newer gear can go as fast as it does. Using global variables doesn't play well with CMP, and can limit the available resources for processing the iRule they're used in. This isn't a BIG-IP issue though, it's an issue with CMP in general, which isn't a BIG-IP specific concept. Clustered processing has a hard time with global variables in general, we just do our best to work with or around it where we can, as the benefits of CMP far outweigh the issues. I'm happy to say, though, that we're moving in the right direction with BIG-IP v10.

v10 offers a new command that helps with one of the common uses of a global variable - storing static data. There are plenty of times that you'll just need to store a piece (or some pieces) of static information in your iRule that can be referenced across all connections. Before, doing this in a global variable would demote your iRule out of CMP, thereby limiting the available processing power you can throw against it. In v10, the new static:: namespace is a perfect way around this. By making use of this namespace when setting your static, global variables, they'll now be completely CMP compatible, and allow you to use the full power of your device when processing the iRule in question.

A great example of how this works and can be used is the $::tcl_platform variable. This variable is an array that stores information about a given platform. For instance $::tcl_platform(os) might contain "BIG-IP". In v10, the bright Product Development folks here realized that making this readily available within the new static:: namespace would make sense, so that's what they did. You can reference $static::tcl_platform to get the same information that would normally be available inside $::tcl_platform while being CMP friendly and ensuring you're getting the most out of your system. This same treatment will work with all static values in global variables, so be sure to swap those over in your code when you upgrade to get improved performance potential.

Here's a quick recap of the commands I talked about above:

  • static::<variableName> - A useful, new variable namespace to provide a means of using static variables that are global but still CMP compatible.
  • $::tcl_platform - A handy array of data regarding your system. This include os, osversion, etc. This is just an example of a global variable.
  • $static::tcl_platform - The preferred way as of v10 to allow access to the above data in a CMP friendly manner. This is an example of how all static, global variables should look in v10

It's also worth noting that if you were using the global command to work around global variable issues previous to v10, you'll want to go back and change those over to the new format where applicable. The global command will now work properly, and set a given variable to a true global variable, which has the CMP concerns I've already discussed.

Get the Flash Player to see this player.