We first introduced iControl interfaces for ASM in version 9 of LTM, and that support was about what you would expect from a first release – usable, but not expansive. With V10, we have stepped up the number of interfaces and the functionality they offer you access to, and here’s a quick overview of those changes. There is a Tech Tip coming soon about the interfaces themselves and how to use them, this blog is just to help you determine if you can achieve your goals utilizing iControl against ASM. Not that I want that to sound too harsh on the version 9 coverage – you could do most things you needed to in that version – this extension just builds upon that version’s solid base.

So the smart guys on our ASM development team opened up quite an array of APIs for your use, giving us expanded control of our BIG-IP LTM with ASM systems. Let’s chat now about when and where iControl fits in the architecture of your ASM-protected network.

For Web Applications, you can delete ones that are disabled, manage policies and logging policies, enable and disable them, set the language for a given web application, and reset web applications to default settings. That’s a lot. It pretty much gives you control of the web application from end to end, with the only bit not yet implemented being codified creation of web applications.

Nothing changed in the Web Application Groups iControl interface for v.10, but that list of APIs is pretty solid anyway, allowing you to create and delete groups, add web applications to a group, get a list of all web apps in a given group, and remove web applications from a group.

In the Policy interface, we now have a pretty thorough coverage, including creating, deleting, associating WebAccelerator applications with ASM policies.

There’s more, but I’ll let you check them out if you’re interested, or watch the docs for my ASM interface reference Tech Tip coming soon.

At this point, there are things you can do from the ASM Admin UI that aren’t available from iControl, but not much. If you’re using iControl for remote management, and have ASM in place, take a gander at the What’s new in v.10 iControl Wiki Page or the ASM iControl Wiki page, and you’ll see what I mean.

Options, it’s always about options. And now you have more. Can’t kick that a bit.

That’s it for today,

Don.

Lori and I have a larger home network, with several servers, multiple switches, two WAPs, and eight or so clients. Thrown into the middle of all of that is an aging Infrant Technologies (now NetGear) ReadyNAS, 1 Terabyte. The ReadyNAS, from before NetGear purchased Infrant, has had a bad cable for about two years, but has been working just fine otherwise. Of course a bad cable implies one of the drives was down (it was), and that makes RAID kind of redundant. About a week ago the ReadyNAS took itself off-line. We have a lot of data out there that is irreplaceable, so Lori got a bit agitated while I coerced the box back into a normal (for it) state.

And then I went out and purchased a new NAS. I’d been looking at the Seagate BlackArmor NAS for a while, liked everything I saw about it, so decided to pick one up. We received the BlackArmor 440 with 4 TB of disk for $1220 including shipping a couple of days ago.

That’s an astounding price. Think about it, very few people who are only storing legal data need 4 Terabytes of storage. Even RAID 5 enabled (the default for this box) it still offers up 2.6 TB of storage space. You’re talking $0.47 per usable Gig, and it comes ready to rock and roll.

And it’s simple. If your Mom needs a NAS to back up her pictures and such to or your SMB-owning friend needs to store critical data and backups, this is the box for you. Plug it into the network (as with most products in this price-range, on the same subnet as the computer you’re starting it from), install their software, and tell the software to go find it. It does, lets you configure a ton of settings, or optionally nothing. Seriously. It’s got two default shares in one volume defined on it, the volume is RAID-5 enabled, and access control is turned off by default, so you can just set it up, tell it to DHCP (though that still scares me for a NAS), give it a name, and go.

Once it’s configured, you don’t need to be on the same subnet as the box to get access to it of course, that’s just the “need to communicate” start-up issue that most appliances have and either answer with a console or the same subnet to avoid routing issues.

The box comes with desktop backup software that we haven’t tried yet, and integration with workgroup/user settings from windows, and a ton more. Want your data encrypted? It’ll do it. And there’s a USB connector if you need to share more data (though I would only use it to back up the NAS – the NAS is RAIDED, not many USB-connected storage devices are that I’ve seen!)

Our ReadyNAS had about 3/4 of a Terabyte of data on it. Running through Linux we were able to copy that off to the BlackArmor in a pretty quick fashion over our network – which is some 10Meg, lots of 100Meg, and some Gig.

But now I face a quandary. Now we have two NAS boxes, one primary, one secondary. I wonder if there are any tools out there to help me manage them… Like you know, from our Data Solutions Group? Think they’re reading this? Think they have an ARX laying around I can snag? Sure would help with testing and writing for you to have one here on-site (yeah, I’m laying it on thick)…

The best thing you can say about the BlackArmor? That there’s not much to say. I don’t like my NAS to require a team of guys and two weeks to configure – our infrastructure is a single BIG-IP, several servers and a dozen or so workstations on two core switches. We’re not talking large enterprise here, and I don’t want to spend the time a large enterprise is willing to. I didn’t, and didn’t have to.

And for 1200 bucks, that says a lot.

I’d rate it as a five out of five for its target market, 4.5 out of five for workgroups or larger SMBs, still way up there on the scale. Of course over the next three to six months we’ll see if there are any constant-use oddities in it, but I think that’s unlikely. Seagate knows storage, so we’ll work on the assumption that this puppy is tested out and ready to rock. If not, you’ll be hearing from me. In this case though, no news is good news. I won’t post back just to say it’s performing as expected.

I am behind on other writing – like iSessions iControl APIs, but wanted to offer you my impressions of this box. Hopefully some of you will find it useful.

Now, off to watch for the FedEx guy to bring me that ARX box… ;-)

Until next time,

Don.

Well, I’ve covered the basics of iSessions – a secure, optimized tunnel between two BIG-IPs – so now it’s time to talk about usefulness, both today and going forward. Since iSessions are an infrastructure issue, the following works for redundant data centers also, assuming they have BIG-IPs in them, it’s just that cloud is the buzzword du-jour, and there’s actually a teentsy bit more benefit to using them for the cloud.

First off, I assume that your cloud vendor has BIG-IPs (that is a safe assumption as of today), but you’re living in the real world, check with them first, there are a few that haven’t yet realized that BIG-IP should be a key part of their adaptive infrastructure.

Many of you – probably most of you – are not out throwing your proprietary data at clouds any more than most of you threw your proprietary data at SaaS. There are security, control, and ownership issues that (real or not) limit the level of real-world interaction with the cloud. But not all of your systems work with proprietary data, and if your applications are modularized (they are if you have web services interfaces to them), then you can move just the code that doesn’t have data critical to the success of your organization out to the cloud, or as some large organizations are doing, build your own internal cloud services.

Having said that, you then have to worry about performance and security. It’s one thing to move an entire application out to a service provider, another to have your application in your data center need to go to a cloud provider to service its requests. And since it’s over the public Internet, the data going to the cloud provider should be encrypted in some manner. You’d be surprised what information can be surmised about your organization just by watching non-critical unencrypted traffic, and in some industries you’d be surprised who’s looking (insurance, for example, has long had competitive intelligence teams that are very Internet savvy).

That’s where iSessions come in. A secure, optimized pipe between two BIG-IPs means that you can move code unchanged out to a cloud provider or another data center – you’ll have a local IP for the service, and that will automatically be forwarded to the remote BIG-IP for routing. Forwarded in an encrypted and optimized tunnel. Of course real-world modularized applications often aren’t that easy to pare out of a core system (ever notice how database lookups sneak their way into the most generic of code in a complex system?), but the direction the data center is headed these days says that you’d better be modular – and truly modular – relatively soon anyway, so I’ll leave the vagaries of your implementation in your capable hands. One suggestion is to make a database proxy in your datacenter and use iSessions to route DB requests through it. You might be able to just use database connections – lots of people are starting to use BIG-IP to load balance databases – but I’ve not tried a database protocol through iSessions yet, and they’re new enough that I don’t know anyone who’s tried. But back to the point, you forward requests and get responses like you’re talking to a local server, and you can put as much power as you need behind the BIG-IP  on the other end. A simple application that just does a couple of quick things and sees medium utilization? A single server is behind that remote BIG-IP. A horrifically complex system that uses seconds of actual computation time to come up with a response? Put a pool of servers at the other end and load balance them (preferably with one of the advanced “Application Delivery Network” algorithms that considers server load in making load balancing decisions).

Then it’s in the cloud, but it’s not like it’s in the cloud. You’re splitting off reasonable and not-too-worrisome parts of your application infrastructure and offloading them to a more dynamic environment, while the code that doesn’t move doesn’t change. Could you do this other ways? Yes. Would it be this easy? Nope. And in the end that’s what adaptive infrastructure should do for you – increase your options without requiring you to re-architect your applications. No doubt they’ll require some tweaks, but full-blown re-architecting is out for most of us in good years, and this isn’t a good year, so tweaks are our answer to your dilemma.

It’s fast, it’s secure, it’s not a massive change to your apps, what’s not to like?

I have some intriguing inter-datacenter replication ideas with iSessions too, but they’ll have to wait until I can test them, and a series of issues – including a new home NAS – have kept me from upgrading my BIG-IP to v.10. Once I get that done, Jason Rahm and I will set up some iSessions tunnels on our BIG-IPs and I’ll start talking more to you about the pie-in-the-sky stuff I’ve been blue-skying.

And yeah, few ideas come out of nowhere these days, so credit where it’s due, Lori and I’ve been talking cloud forever (she has much more tolerance for the hype cycle than I, if XML didn’t show you that, I want usable, not hype), and Erik, one of our VPs sent out some literature that actually spurred me to write this post.

Until next time,

Don.

Amongst the wave of new features that came out in Version 10 of TMOS is a nifty little feature called iSessions. This being the first release of iSessions, there is a lot of curiosity and not as much documentation as we’d like yet. So I’ll walk you through what is available, why you’d want to use it, and what benefits it offers in this blog post. As time goes on we will expand our coverage of iSessions to more fully discuss all of the options and challenges they present.

The concept of iSessions in v.10 is pretty straight-forward… A secure tunnel between two BIG-IP systems to share in load-balancing and failover. The extension is that those BIG-IPs can be (and generally should be) geographically remote. Indeed, the whole point of iSessions is to make WAN communications faster, but we’ve got enough experience to know that some of you will find a use for them inside the datacenter. iSessions only require that the BIG-IPs be able to route between each other, not that they be geographically remote. Since optimization of traffic over an iSessions link is built in, you get both secure and accelerated WAN communications. The type of optimization is configurable, as are several other things about the tunnels.

While this post isn’t intended to be a step-by-step How-To document, it will give you an overview of the steps necessary to get your BIG-IPs talking on the “back channel”, and offer some points of interest for you to be aware of.

Much like some vendors have a remote office solution that is simply an optimizing proxy for their data center products, iSessions will forward requests to a remote BIG-IP. Unlike those solutions, if the connection the iSessions communicate over is down, the BIG-IP can be configured to handle the request locally if you have the servers in-place.

For this blog post we will refer to the “Data Center BIG-IP” and the “Remote BIG-IP” note that the “Remote BIG-IP” could be configured in an alternate data center, and thus could be fulfilling both the role of the Data Center BIG-IP in some instances and that of the Remote BIG-IP in others. For simplicity’s sake, we will not explore that configuration here, simply note that it’s possible. For this blog post, the “Remote BIG-IP” is the device that the user’s requests will come in through, the “Data Center BIG-IP” is the one that will ultimately service requests.

That should be all the background we need to cover, now on with the overview.

The best way to think of iSessions (for me at least) is like a fibre optic cable. iSessions are turned on at both Remote and Data Center BIG-IPs, and that creates the sheath that holds the fibres. When connections are requested on the Remote BIG-IP, an individual fiber (connection) is created in the sheath (tunnel). Depending upon your settings, that connection could exist for a long time, servicing repeated requests from different clients, or it could exist only so long as the requesting connection is live.

At its simplest, the iSessions configuration is easy. On the Remote BIG-IP, you configure a forwarding Virtual Server to forward requests to the Data Center BIG-IP. The Data Center BIG-IP has a Virtual Server configured for iSessions that either maps to a server or forwards to another Virtual Server on the same BIG-IP. Either way, the Data Center BIG-IP services the request, and sends the response along the same iSession connection, assuming the request is for the same target Virtual Server. Note that re-use has some drawbacks in every implementation out there, and you might want to consider their use carefully if you have very bursty traffic patterns. Also note that in this first implementation of iSessions, the longevity of a connection is 10 minutes and cannot be changed.

Note that the iSession Forwarding Virtual Server is different than most Forwarding Virtual Servers – it is configured as a standard Virtual Server with address/port translation turned off and no Pool object associated with it. A destination is then set that is the Data Center BIG-IP’s address. The Virtual Server on the Remote BIG-IP requires a TCP profile to be selected for both the client and server side contexts, and a client SSL profile must be selected so that iSessions info can be decrypted when the other BIG-IP sends responses.

This Virtual Server on the Remote BIG-IP also requires an iSession Profile to be selected so that tells the BIG-IP how to handle tunnel creation when communicating with the Data Center BIG-IP. The iSession profile specifically tells the BIG-IP about mappings to the Data Center BIG-IP, Session re-use, optimizations of the tunnel, and other general connection options like de-duplication (not currently available even if enabled… Check back for more info) and port transparency. Note that while the Endpoint Pool is slipped in at the bottom of the configuration screen, you need it set to a pool of one node that is the forwarding point for iSession Tunnels to the Data Center BIG-IP.

The Data Center BIG-IP has the same iSession Profile, and your choices for tunnel-specific configurations are compared when a tunnel is initiated, and only those settings that are enabled on both sides are used for this tunnel.

On the Data Center side, you must configure the iSession Profile such that it knows what to do with incoming connections – are they simply routed, or do they get sent to Virtual Servers for additional processing, etc. These options are at the bottom of the iSession Profile configuration. For Target Virtual type, your early implementations can probably use Match All, which will match to any Virtual that fits, and route the request on if none matches.

Okay, that’s a ton of info. We’ll call that the quick overview. The salient points are:

1. iSessions create an encrypted, optimized tunnel over the WAN between two BIG-IPs.
2. Both BIG-IPs must be v.10
3. When configuring client and server profiles remember to think of traffic direction… Where the traffic comes in from the client (regardless of which BIG-IP you’re on) is the client side, where it flows back toward the client is the server side.
4. iSessions are always encrypted but you have options for which and how much compression to use (and the ability to choose “adaptive” if you are uncertain which is best for you).
5. Just because this blog post used “Remote BIG-IP” doesn’t mean it can’t also be in a data center, and in some instances it may even be the “Data Center BIG-IP” in highly distributed environments.
6. Session re-use saves the overhead of renegotiating for each connection, but comes with a price of long-lived connections between the two BIG-IPs.

That’s it for now. I’ll be posting soon about how and why this is important if you’re considering using a cloud provider. Check with your SE if you’re interested in more implementation-specific details.

Don.

Note: If you’re here for Load Balancing for Developers or Reasons You Need File Virtualization (both iterated on my team page), I took this week and last off to cover v.10, check back next week.

Forest, Trees…

The new functionality in v.10 is so expansive that it’s easy to get buried and not see the larger picture right away. That’s kind of what happened to me when this blog post came about. Originally I was going to write about using Logical Volume Management (lvm) for testing configurations, but honestly the release of evaluation licensing makes for some other interesting scenarios, so I’m going to make this post about testing new configurations in v.10 with both toolsets – because you don’t work in a vacuum.

The challenge in the enterprise is to set up and test new configurations and updates to firmware on boxes that are, quite often, the gateway to the world. While we would love for all of you to purchase an extra set of BIG-IP devices just to test on, the reality is that some of you do and some of you never will. We want to make certain that those who don’t have an extra set of boxes lying about have the ability to test things without risking their core network. We know that our updates are solid, and presumably before you roll them into testing you know your configuration changes are solid, but mistakes happen, and we don’t know your specific network’s quirks when we ship an update. Prudence dictates that if you must test on your core network, you have a path of recovery.

Credit Where Due…

We are aware of your issues, and our Product Management and Product Development folks have stepped up and improved our already solid upgrade/config testing. So while I sound great, remember I’m just the guy with the pen, a lot of other people put their hard work into making this stuff happen, I’m just the lucky stiff that gets to talk about it.

Two Great Tastes…

One of the core advantages of lvm is the ability to create a huge number of volumes on the disks installed in your BIG-IP and then switch to boot from different ones at different times. While the partitioning scheme used prior to v.10 allowed you to have more than one partition, that number was extremely limited. This bit of functionality will be helpful in creating and updating a test volume every time you wish to make high-risk changes to the BIG-IP.

One of the core advantages of Evaluation Licensing is that you can say “I want to try this module out” and it runs for the time period and then expires, leaving the volume and the TMOS install on it otherwise unchanged. This gives you the ability to test functionality in a known good configuration before committing to putting it into production.

But when these to functions are combined… Well how about you copy your current production volume to a new volume called Test1, then you activate Evaluation Licensing on Test1 for the module you’re interested in, and then, when things are quiet (are they ever quiet these days?) on the network, you reboot to Test1 and try it out. When done testing, you boot back to your production volume and life continues on – no matter what you thought of Test1. Then if you liked the module, you license it in production and delete volume Test1 or the or clean the configuration on it and save it for next time.

And Standalone as Well…

While combined there is power behind these technologies, the wizardry is not (as you probably already guessed) all in the combinatorics. Having the ability to make a bunch of volumes and test on them means that you can try out a whole lot of different configuration changes all at the same time, and keep them between tests. While our secret ability to let you change configurations via iControl and not save them was great, this gives you a more cohesive testing environment where you can make the changes in the UI, save them, and test to your hearts content without fear of running out of time before a reboot. And having the ability to turn on a module that you think you need and test it for a limited time without any worries about the impact to the rest of your configuration is huge too. Like test-driving a car, you have the whole enchilada in your hand for that time period and can make an informed decision about usefulness to your team.

I don’t know about you, but assuming you can find the man-hours, try it before you buy it has always been my preference for the short list in any given evaluation. Sales guys are great and all, but every sales person is highly motivated to sell you product that they truly believe will solve your problems. Throwing it into your specific environment and kicking the tires is the best way to see if they’re right given your circumstances, network architecture, application needs, etc.

There is too much, let me sum up…

I could blather on and delve into deep technical detail here, but it’s a blog post, so instead, I’ll point you direct to the source of all the great information I would be pulling from to give you more detail. Our Technical Publications team has written a lot about this stuff that is available on ask.f5.com in the v.10 area (ask.f5.com login required), I’ve already linked to Jeff’s Evaluation Licensing article above, I have a short blog on the joys of lvm, Alan Murphy, one of our Technical Management folks, has written a great whitepaper on lvm and the new Live-Install functionality that is also available in audio. That should be enough to get you started, I would think.

The best part of these two bits of functionality, from my perspective, is that they are forward looking. They are designed to enable us to offer you more functionality over time without disrupting your work flow. That’s huge in my book, you have quite enough problems already, I love it when we focus on making your life easier.

Don.

One of the cool new items in v.10 is the use of a logical volume manager (LVM) to create and manage multiple “partitions”. This is the last time I will use the term “partition” to refer to v.10 disk space in this post, since partitioning was the way things were done prior to v.10, moving forward we use the volume system.

Considerations

The first thing to do is decide if LVM is the right tool for you. Like most massively cool technologies, it supersedes the system it is designed to replace. While we do our best to provide backward compatibility, this is one instance where the systems were different enough that we settled on an “either/or” version of backward compatibility. Thus, if you intend to continue using version 9.x products, you should not install LVM. The benefits of LVM are legion, but due to its adaptability, it does not sit well on the same machine as version 9 partitioning. The best bet is to check and make certain you can/have upgraded all of your modules, and then proceed if you are prepared to completely replace your systems with v.10 systems. You can run v.10 in a 9.x partition, more on that in a moment.

Preparation

Lets be straight-up about this, I’m not trying to give you a complete set of installation instructions in a blog post, we have an excellent technical publications group that covers this in Chapter Two of our Getting Started Guide (ask.f5.com login required), there’s no reason for me to reinvent wheel when they have done the work of figuring it out and documenting it for you step by step. But I do want to give you an idea of what to expect when you upgrade your system for v.10 and that includes installing LVM and volumes.

First off, you have to use the img2disk utility to transfer the lvm and system volumes to the BIG-IP. There are good instructions on that in Appendix A of the Getting Started Guide. If you think you have a very good reason for running 9.x and v.10 on the same BIG-IP, there are instructions for how to do that also. In this scenario, LVM is not used, so it is outside the scope of this blog post. The short list of items required to get this done is

1. Download the 10.x iso
2. us im to transfer the iso to disk
3. use image2disk to install and set up basic volumes
4. from the Web GUI run the configuration utility

That’s it. Of course “run the configuration utility” has a bunch of options, you can create, delete, rename, make active, and install volumes, but all of this is well covered in the Getting Started Guide.

Usefulness

Now we come to the meat of the discussion where most of us are concerned – all this rigmarole, what do we get out of it? Well, some modules in the future will utilize configured volumes for things like swap space, but in the short term, the big benefit is that you can maintain multiple versions of v.10 on your BIG-IP. That means that you can have one configuration ready to roll if testing bears out its usefulness and another running production. If you only have one set of BIG-IPs and want to test the upgrade to 10.0.9, for example (no, 10.0.9 doesn’t exist as of this writing, I’m looking forward), you can configure it on a separate volume, and during your scheduled testing period, reboot the BIG-IP to run off of that volume. When testing is done, you can either leave it running on the new version (don’t forget to set that to be the active or “boot” volume!), or you can reboot and come back to the old version.

That also means that you can make a build with your current configuration, test license a module (see Jeff’s article for more on this topic), and if it works, just run off the new volume, if it causes you unforeseen issues, reboot to the old one – but you can keep the one you’re not using around, there’s no longer a limitation (other than available disk space) on the number of partitions/volumes you can have on the disk.

Conclusions

This is a useful set of tools that from a user perspective expands what is already available, and from a module perspective, expands what can be offered to users. All in all I think we’ll see more and more uses for LVM to come about as DevCentral users get out there and install it. Auto switching between volumes based upon events seems possible, though I can’t for the life of me imagine why you’d want to, someone will find a good reason. It might even be a reason that makes us all go “Heyyy…”

I haven’t actually installed v.10 on Lori and I’s box yet, but it’s coming – I have a project rooted in 9.x that has to be cleared up first – and then we’ll start playing more with LVM. After that I’ll circle back and offer you all an update.

Until next time,

Don.

For those who missed it, we’re in the middle of the IT Revolution lead by our v.10 release of TMOS and our new 8900 model. Due to all the great stuff to talk about in the new version of TMOS, I have put off the Load Balancing for Developers and Reasons You Need File Virtualization series on hold for this week, and possibly next. Then I’ll hop back on them and we’ll explore ADCs for Developers and more Reasons You Need File Virtualization.

As part of the revolution, you need more control. Or iControl, as the case may be. We heard that, and the mighty smart folks in our Product Development and Product Management groups have cooked up just such a recipe for your enjoyment.

Like so many things, iControl has grown with the release of v.10. While the changes are not as sweeping as they are in some parts of the BIG-IP architecture, there are enough new interfaces to warrant their own blog entry.

The biggest change in the iControl Interfaces (in terms of number of new APIs) is support for iSessions, but that gets us into a chicken-and-egg scenario, so I’ll hold off on talking about them in detail until I cover iSessions in the coming weeks from end-to-end. They short version is that iSessions allow you to create tunnels between BIG-IPs to help manage geographically dispersed data centers, and the iControl APIs give you fine-grained control of this capability on the BIG-IP.

The TCP and SIP profiles got facelifts with a couple of new APIs to help you set their profile-specific information, Clustering and Configsync both have added capabilities to help you manage your box or cluster, and the inet module now lets you set the hostname through iControl.Software Management got a ton of new routines that revolve around the new Logical Volume Manager (lvm) that will help you manage the version and test environments on your box (more on LVM next week), and System/Failover has some new routines for setting a box as manually offline.

As you can see, the changes are pretty pervasive, but they’re additive. To my knowledge there aren’t changes to existing calls, so you should be able to download the v.10 API and rebuild your existing applications with it (or change your environment to point to it for script-based solutions), and you’ll be off to the races.

The most exciting APIs to me are the system/software management ones. With them you have a new world of possibilities for testing on different versions of TMOS, for hotfixing boxes and checking results, even for controlling which image boots for the cluster – but more on that in our LVM articles. If you can’t wait, our Technical Marketing Managers have penned an excellent whitepaper on the topic, read it here. Indeed, find the full list of whitepapers they’ve developed, datasheets, and links to other documentation here.

Joe has thrown together a list of the changes iControl has undergone in Version 10 on the wiki, and each line of that list links to a Wiki page with details about the command. A handy reference for keeping in your back pocket.

That’s it for today, until next time!

Don.

For a good long while, bigpipe has been the command line tool for use with BIG-IP products. It worked admirably, and has lasted a good long while, but as with everything that is vibrant and successful, BIG-IP outgrew bigpipe.

Starting with v.10, you have access to a new command processor – tmsh. While you can still call bigpipe, tmsh offers such power that we figure you won’t be doing that for long.

Offering a full blown scripting language based on tcl, tmsh gives you functionality that makes this author wonder if a whole lot of work currently doled out to iControl will end up as tmsh scripts.

Over the coming days, weeks, and months we’ll be delving into how, when, and where to use tmsh in your overall network architecture, but for now, I’ve written an introductory article, and the Tech Pubs people have written an excellent reference.

Find the article here, and the tmsh Reference Guide here (requires a valid login to ask.f5.com). That’s enough to get us started down the path of on-box automation for the BIG-IP, there’s plenty more on the way.

Until next time,

Don.

Continuing the Friday Funny series (some missed that when I didn’t disclaim it last week, so “Fridays are the days I think I’m funny”).

Thursday was an insane day, starting with my laptop having VPN issues, and ending with after-hours work calls. Indeed, I’m writing this at 10 PM Central time (GMT – 5) Thursday night, just because I’m here and just finishing up. Not too much work, just one of those days.

So midway through the day, a friend of mine that does freelance in technology and RPGs – Bill Silvey – tried to start an intelligent IM with me. Here’s how it went from when I missed his “Hello” onward…

[13:13] dmacvittie1: I'm am here, and here I am. You?
[13:18] dmacvittie1: You said hi but it was Spam.    
[13:18] dmacvittie1: I do not like the Spam.
[13:18] dmacvittie1: I do not like it in a can.    
[13:18] dmacvittie1: I do not like it Sam I Am.
[13:18] BillSilvey: hee...no, on conference call. Would you like it in the house?
[13:19] dmacvittie1: I would not like it in my house.
[13:19] dmacvittie1: I do not click it with my mouse!
[13:19] BillSilvey: :D
[13:19] BillSilvey: Read my blog today I think you'll like it
[13:21] dmacvittie1: I will not like it in a blog,
[13:21] dmacvittie1: I think I slayed it in a bog!
[13:21] BillSilvey: Would you like a disrto on the SAN?
[13:22] BillSilvey: Would you like it on the WAN?
[13:23] dmacvittie1: I do not like them on my SAN,
[13:23] dmacvittie1: I do not like them, Sam I Am!
[13:24] BillSilvey: Would you eat it by the NAT?  Would you like the file system FAT?
[13:29] dmacvittie1: I would not eat it by the NAT, I'm much much too intelligent for that!
[13:29] dmacvittie1: I do not need all that FAT I do not like it Sam I am!
[13:34] BillSilvey: Would you put it through PCI?  Would you serve it on an SGI?
[13:34] dmacvittie1: I would not put it through PCI, the combination would make me die!
[13:34] dmacvittie1: I would not serve it on an SGI, their technical prowess has gone Bye-Bye!
[13:39] BillSilvey: Would you post it HTTP?  Would you use an asus EE?
[13:39] dmacvittie1: I would not post it on HTTP, unless the version makes it to three!
[13:40] dmacvittie1: I would not use an Asus EE, I have one here, it's pretty crappy!
[13:40] dmacvittie1: I do not like it Sam I Am! I will not take your blog-post Spam!
[13:44] BillSilvey: Can I have the asus ee?  my daughter has a computing need!
[13:45] dmacvittie1: You cannot have the Asus EE,
[13:45] dmacvittie1: I would not do that to a friend of me!
[13:45] dmacvittie1: I do not like it, Sam I Am,
[13:45] dmacvittie1: The Asus EE belongs in a garbage can!
[13:49] BillSilvey: You will not give the asus ee, you will not go and read my blog, you will not accept my friendly spam - just what will you for sam-i-am?
[13:50] dmacvittie1: You may not have the little EE, Your blog I spammed a time or three. I will not take your friendly spam, I will not take it, Sam I Am!

To his credit, Bill played right along. Though I’m thinking that he can have my daughter’s ASUS EE, as I’m angered with it at the moment ;-).

It was fun, and it relieved some of my stress. That’s what friends are for, no? If he was on the conference call I think he was, I believe the topics he chose even came from his call.

Oh yeah, I changed Bill’s super-secret-identity screen name to his real name to protect his hidden identity.

Until next time,

Don.

PS – Visit Seussville if you’re a fan.

If you’re just joining this series, there is a complete list of the Reasons to date on my team member page.

Are we at reason #5 already? Wow. Okay, this is another one that salesmen will tell you because it is truly compelling, but it is truly a good reason, one of the best.

It is also one of the ones that I eschewed before getting to see real numbers that I could quantify were not marketing material.

The disk savings are real.

Yeah, I said it, and it’s true. Sure, you could argue that they’re only disk purchase deferments, I would disagree. If you don’t buy disk next year because you don’t need it, and you buy the year after… Well, if you would have purchased disk this year and next without it, that’s not deferment, it’s cost abatement. But I can see the logic behind calling it deferred purchases – you really aren’t stopping buying disk, only slowing down the rate of growth.

Either way, depending upon your storage architecture, the savings can be huge. I saw one case study that included a regular old enterprise, and an increase in disk utilization of nearly 70%. That’s astounding. And I know the people, so those numbers aren’t marketing fluff, they came from IT folks.

It all sounds so simple – you have BigOldArray1 that has the user directories and the Intranet on it, and seven LittleArrays that hold application-specific data. BigOldArray1 is filling up fast, and you’re going to have to expand it. Buy a whole new rack, or upgrade, whatever. But your LittleArrays are sitting there at 20% utilization, and between them total more disk space than BigOldArray1. That’s what a whole lot of data centers look like. More than you’d believe. Because apps often enter the Data Center through Departmental level IT, and only when they need integration with somewhere else, or they grow too big, or IT staffing consolidation occurs do they move to the DC. Or the project was going to grow into this large thing that did more than it does, but that idea was dropped, and it’s still running on that hardware purchased from the project budget… Due to mergers, one of the applications that warranted that LittleArray is gone…There are a zillion reasons.

But the point is, that 20% utilization number sucks. With File/NAS Virtualization, you can resolve the problem. In the best systems, put them all in a pool and tell the system to manage them. It’ll start shifting data to the under-utilized resources, relieving the need to upgrade. In most systems you have to be a bit more participative and tell the system which files on BigOldArray1 it can move, but you’re still shaving space out of nothing. How much? Well, let’s just use my example. You can figure out the actual numbers for your data center using the same equations. Let’s say that BigOldArray1 is maxed out at 4TB and is hitting 80% utilization – That would leave 800Gigabytes free space. That’s how much room you have in the old system. Let’s further say that your LittleArrays are each 1 TB, and you have the seven I mentioned, utilized at the 20% I mentioned. That would be 80% of 7TB free – or 5.6 TB that you can recover and use with BigOldArray1.

You have more than double the space of your original BigOldArray1, you just need to use it more intelligently. Replication (Reason #4) can quickly get stuff off the old machine and onto the new one without deleting it from the old until you’re certain all is well.

Of course there are caveats. There always are, anyone who sells you a “more than double your space!” line is lying if they don’t admit that.

First, the amount of free space available in your organization won’t match my example, nor will it be as clean as my example. Seriously, how many arrays with exactly 20% free space can you have ;-)? But you can counter this by looking at free space yourself.

Second is tiering (Reason #3). If you’re using tiering, your options might not be this clean-cut. That’s not to say that you can’t reap benefits, even benefits as large as my example, but you have to make certain you are moving files to the correct tier, which complicates the equation.

Third is politics. You can do to users and just move those departmental apps’ data around, or you can run the gauntlet and get buy-in from all the application owners. I would recommend that you move everything when you first install the File/NAS Virtualization device and inform users that the entire architecture is changing (it is), but that requires a lot of forethought – be thinking about it. Otherwise, you know which of the first two options is best for your users and your organization.

Fourth and final is that you know your Data Center better than I or any salesperson ever will. Yeah, I’m a geek, but I have yet to see the “average” data center, how about you? It is possible to have an array appear “under-utilized” from a disk usage perspective but be hammered from an I/O perspective, or on a slower network segment (though that last is generally easy to fix). You need to validate if File/NAS Virtualization will cause you conflicts in that regard. Trust me, no File/NAS virtualization vendor wants you to put them in and then have performance issues – the promise is great, they don’t want it to backfire on you. ARX can help you evaluate this stuff before making moves (though IIRC the machine needs to be in the virtualization appliance to help, it doesn’t have to be part of the virtual directory), presumably other vendors can too.

That’s it for this week, I do hope you’re finding these posts useful.

Until next time,

Don.

If you’re new to this series, you can find the complete list of articles in the series on my personal page here

If you are writing applications to sit behind a Load Balancer, it behooves you to at least have a clue what the algorithm your load balancer uses is about. We’re taking this week’s installment to just chat about the most common algorithms and give a plain- programmer description of how they work. While historically the algorithm chosen is both beyond the developers’ control, you’re the one that has to deal with performance problems, so you should know what is happening in the application’s ecosystem, not just in the application. Anything that can slow your application down or introduce errors is something worth having reviewed.

For algorithms supported by the BIG-IP, the text here is paraphrased/modified versions of the help text associated with the Pool Member tab of the BIG-IP UI. If they wrote a good description and all I needed to do was programmer-ize it, then I used it. For algorithms not supported by the BIG-IP I wrote from scratch. Note that there are many, many more algorithms out there, but as you read through here you’ll see why these (or minor variants of them) are the ones you’ll see the most.

Plain Programmer Description: Is not intended to say anything about the way any particular dev team at F5 or any other company writes these algorithms, they’re just an attempt to put the process into terms that are easier for someone with a programming background to understand. Hopefully a successful attempt.

Interestingly enough, I’ve pared down what BIG-IP supports to a subset. That means that F5 employees and aficionados will be going “But you didn’t mention…!” and non-F5 employees will likely say “But there’s the Chi-Squared Algorithm…!” (no, chi-squared is theoretical distribution method I know of because it was presented as a proof for testing the randomness of a 20 sided die, ages ago in Dragon Magazine). The point being that I tried to stick to a group that builds on each other in some connected fashion. So send me hate mail… I’m good. Unless you can say more than 2-5% of the world’s load balancers are running the algorithm, I won’t consider that I missed something important. The point is to give developers and software architects a familiarity with core algorithms, not to build the worlds most complete lexicon of algorithms.

• Random: This load balancing method randomly distributes load across the servers available, picking one via random number generation and sending the current connection to it. While it is available on many load balancing products, its usefulness is questionable except where uptime is concerned – and then only if you detect down machines.

Plain Programmer Description: The system builds an array of Servers being load balanced, and uses the random number generator to determine who gets the next connection… Far from an elegant solution, and most often found in large software packages that have thrown load balancing in as a feature.

• Round Robin: Round Robin passes each new connection request to the next server in line, eventually distributing connections evenly across the array of machines being load balanced. Round Robin works well in most configurations, but could be better if the equipment that you are load balancing is not roughly equal in processing speed, connection speed, and/or memory.

Plain Programmer Description: The system builds a standard circular queue and walks through it, sending one request to each machine before getting to the start of the queue and doing it again. While I’ve never seen the code (or actual load balancer code for any of these for that matter), we’ve all written this queue with the modulus function before. In school if nowhere else.

• Weighted Round Robin (called Ratio on the BIG-IP): With this method, the number of connections that each machine receives over time is proportionate to a ratio weight you define for each machine. This is an improvement over Round Robin because you can say “Machine 3 can handle 2x the load of machines 1 and 2”, and the load balancer will send two requests to machine #3 for each request to the others.

Plain Programmer Description: The simplest way to explain for this one is that the system makes multiple entries in the Round Robin circular queue for servers with larger ratios. So if you set ratios at 3:2:1:1 for your four servers, that’s what the queue would look like – 3 entries for the first server, two for the second, one each for the third and fourth. In this version, the weights are set when the load balancing is configured for your application and never change, so the system will just keep looping through that circular queue. Different vendors use different weighting systems – whole numbers, decimals that must total 1.0 (100%), etc. but this is an implementation detail, they all end up in a circular queue style layout with more entries for larger ratings.

• Dynamic Round Robin (Called Dynamic Ratio on the BIG-IP): is similar to Weighted Round Robin, however, weights are based on continuous monitoring of the servers and are therefore continually changing. This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. This Application Delivery Controller method is rarely available in a simple load balancer.

Plain Programmer Description: If you think of Weighted Round Robin where the circular queue is rebuilt with new (dynamic) weights whenever it has been fully traversed, you’ll be dead-on.

• Fastest: The Fastest method passes a new connection based on the fastest response time of all servers. This method may be particularly useful in environments where servers are distributed across different logical networks. On the BIG-IP, only servers that are active will be selected.

Plain Programmer Description: The load balancer looks at the response time of each attached server and chooses the one with the best response time. This is pretty straight-forward, but can lead to congestion because response time right now won’t necessarily be response time in 1 second or two seconds. Since connections are generally going through the load balancer, this algorithm is a lot easier to implement than you might think, as long as the numbers are kept up to date whenever a response comes through.

These next three I use the BIG-IP name for. They are variants of a generalized algorithm sometimes called Long Term Resource Monitoring.

• Least Connections: With this method, the system passes a new connection to the server that has the least number of current connections. Least Connections methods work best in environments where the servers or other equipment you are load balancing have similar capabilities. This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. This Application Delivery Controller method is rarely available in a simple load balancer.

Plain Programmer Description: This algorithm just keeps track of the number of connections attached to each server, and selects the one with the smallest number to receive the connection. Like fastest, this can cause congestion when the connections are all of different durations – like if one is loading a plain HTML page and another is running a JSP with a ton of database lookups. Connection counting just doesn’t account for that scenario very well.

• Observed: The Observed method uses a combination of the logic used in the Least Connections and Fastest algorithms to load balance connections to servers being load-balanced. With this method, servers are ranked based on a combination of the number of current connections and the response time. Servers that have a better balance of fewest connections and fastest response time receive a greater proportion of the connections. This Application Delivery Controller method is rarely available in a simple load balancer.

Plain Programmer Description: This algorithm tries to merge Fastest and Least Connections, which does make it more appealing than either one of the above than alone. In this case, an array is built with the information indicated (how weighting is done will vary, and I don’t know even for F5, let alone our competitors), and the element with the highest value is chosen to receive the connection. This somewhat counters the weaknesses of both of the original algorithms, but does not account for when a server is about to be overloaded – like when three requests to that query-heavy JSP have just been submitted, but not yet hit the heavy work.

• Predictive: The Predictive method uses the ranking method used by the Observed method, however, with the Predictive method, the system analyzes the trend of the ranking over time, determining whether a servers performance is currently improving or declining. The servers in the specified pool with better performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections. The Predictive methods work well in any environment. This Application Delivery Controller method is rarely available in a simple load balancer.

Plain Programmer Description: This method attempts to fix the one problem with Observed by watching what is happening with the server. If its response time has started going down, it is less likely to receive the packet. Again, no idea what the weightings are, but an array is built and the most desirable is chosen.

 

You can see with some of these algorithms that persistent connections would cause problems. Like Round Robin, if the connections persist to a server for as long as the user session is working, some servers will build a backlog of persistent connections that slow their response time. The Long Term Resource Monitoring algorithms are the best choice if you have a significant number of persistent connections. Fastest works okay in this scenario also if you don’t have access to any of the dynamic solutions.

That’s it for this week, next week we’ll start talking specifically about Application Delivery Controllers and what they offer – which is a whole lot – that can help your application in a variety of ways.

Until then!

Don.

My title includes the word architect, and has at several enterprises (in Utilities, finance, and COTS software). For the last month or so, I have been pondering how funny that is. Today I share the top reasons my title (and possibly yours) makes me laugh…

Reason #1: Architects specify materials and get them.

Reason #2: Architects get a dedicated team for each bit of a project until that part is done, not 10% of four people’s time over six months, assuming there is no emergency.

Reason #3: When things go wrong in implementation, if they’re not blue-print problems, the architect isn’t involved in resolving them.

Reason #4: An architect builds for 30 years or more, and gets a budget that reflects this fact.

Reason #5: An architect starts with a blank sheet of paper and creates.

Reason #6: Once a customer signs off on a blueprint, any changes they request during implementation they must pay for.

Reason #7: When an architect says “2x6 boards spaced 16 inches apart”, any deviation from this specification is not allowed.

Reason #8: When re-working someone else’s original, the architect is empowered to rip out the old and start fresh.

Reason #9: An architect can reasonably expect to sleep through every night of the year without a call from work.

Reason #10: By the time an architect’s work is obsolete, he’s likely retired, and more likely not to be involved in replacing it.

There’s a comment section below, feel free to add yours. The tricks: try very hard to be generic – all IT architects, not just your flavor; and try not to mention the IT alternative. If you have to spell it out, it’s probably not funny. Note that #2 is the only one I mention the IT version.

Until next time!

Don.

I took the easy topic this week, and things are so crazy it’s still late in the day that I’m posting this. My apologies. This one also focuses more on ARX than previous ones – this is because replication is a differentiator for many vendors’ products, so I’m being careful to talk about what most can do, then give details for the one I know the best.

If you’re just joining this series, there is a complete list of the Reasons to date on my team member page.

Replication is of growing importance in the enterprise, be it because of distributed data centers or shared folders all over the enterprise. And you guessed it, File/NAS Virtualization will improve your replication strategy.

Most vendors of these products will allow you to write rules (or something similar with a different name) to handle replication, though how they handle it may vary from one to another.

The key here is that if you can drop a rule or schedule or whatever your vendor calls it – ARX calls it rules, hence the reason I’m using that phrase – on your File Virtualization device, you don’t need to waste any CPU cycles on a server doing replication. You can also set all sorts of parameters from aging to file type for doing your replication – in short, no need for a separate replication software package or a complex set of rsync commands to maintain. Or if you’re a huge legacy shop, no lists of xcopy commands ;-). And for most products, a replication failure on a file will merely put that file in retry mode while the system continues to replicate other files – ARX uses five (or is it ten? I always have to look that up but for this blog it isn’t important) minutes after the final (non-shared) lock is released from the file and then it tries to replicate that file again.

And since you set up replication by folder, merely moving a share under that folder in the virtual tree will include it in the replication. Nice, eh?

Replication is getting out there a bit, it is one of the differentiators that vendors use to show off their products, so I’ll take a minute to talk about what ARX is capable of, you’ll have to check with your vendor about what they do. You can replicate from an ARX in one data center to an ARX in another. That makes a backup or redundant data center pretty easy to maintain. From a NAS perspective at least… All those other issues? Yeah, can’t help you via ARX, but BIG-IP can help with many of them.

You can also turn on differential replication or delta replication, so that only the changed parts are moved across the wire. If your data centers are far apart or on entirely different networks, this is an appealing option.

One of the powerful bits is that all of this can be done to wildly disparate storage systems – because the ARX makes them look the same. So you have three NAS arrays and seven servers on the one side, replicating to a monstrous NAS array on the other side. No matter, the ARX will put sub-directories where it’s told to when configured, so these two different architectures can be mirrors of each other.

Note that with ARX, the replication target is read only, but you can tell it to either show files as they’re replicated or hold the whole thing invisible until the replication is done. A nice touch if you have twitchy admins on the receiving end and applications that count on multiple files being present are waiting to be started.

What do you really gain? Well you get all of the other benefits of File/NAS Virtualization, and you get “free” replication between disparate NAS devices (CIFS/NFS/any vendor). And you get the rules, which can provide you with a mechanism whereby your files are replicated in the manner you choose. If you’re using ARX, you get delta replication, other vendors you’ll have to ask – but delta replication saves a TON of network traffic.

That’s it for this week. There’s a ton more, but I haven’t picked next week’s topic yet. I’m considering migration, but I kind of hit on that in Reason #1 That You Need File Virtualization, so I may do something else.

Until next time,

Don.

Well, now that we have discussed how you got here, and what options load balancing offers you, let’s hit upon what you’re up against when porting your application to run under a load balancer. Many resources online say that most applications can be moved behind a load balancer unchanged. I beg to differ with this view, there are a host of issues that crop up even if your application is not retaining state information. So we’ll hop right into it. Note that all of these core issues have solutions, some have many options for resolving them, but if you don’t know they exist, you’ll be blindsided by them, forewarned is indeed fore-armed.

If you’re new to this series, you can find the complete list of articles in the series on my personal page here

Logging

Your system no doubt uses logs for a variety of things including management reporting, security auditing, and problem resolution. Most applications do, and load balancing makes utilizing logs harder. The problem is that your tools are all pointed at the logs on server1, and that was the entirety of your logs… But now you have logs on server1, server2, server3, server4, and all must be combined in some way to give you accurate reporting. Some load balancers and most ADCs take care of this for you with centralized logging or even reporting replacement functionality. Some, but not all. There are 3rd party tools out there for log aggregation, some commercial, some open source. I’d get one and familiarize yourself with it while your application is still in test – if you can make a log aggregation tool work for you, then your code doesn’t need to change at all, and none of your functionality breaks… You just have to point your reporting mechanisms at the location you use to store your aggregated logs. One problem resolved.

Client IP tracking

Lori and I have an application that records the IP address of those who log in, which sits behind a load balancer (an ADC, actually). While the IP address recording was just thrown in there because we could, I actually started using that information for reporting of people logging in as guest. All it does (and all most of this type of function does) is pull the IP Address out of the headers and throw it into a database. The problem is that our load balancer is a proxy for all users. That allows us to expose the Virtual IP and not actually expose any of our servers to the world except through the IP/Ports we dictate. Unfortunately, by virtue of being a full proxy, it replaces the IP Address field with the load balancers’ IP address. So it appeared that everyone in the world was logging into our app from the load balancer. Not the best situation for the reporting I was doing, and really not the best for our web server logs.

The easy fix for this one is to change your source code to work off of the x-forwarded-for header and make certain that your load-balancer is configured to support x-forwarded-for. Sadly, some load balancers don’t support this header, so you’ll have to think of something more inventive in those cases or eliminate the need to track the IP of users.

Persistence

Whoo boy, there are few words to make a developer with experience developing behind a load balancer shudder like persistence. Here’s the deal, if your app is tracking state, and that state is stored on the web/app server, then when the user returns and gets directed to a different server, you’ve lost all context for their experience. There are a variety of ways to fix this in any load-balanced environment, but they either aren’t optimal or require not just recoding, but re-architecting portions of your application. If you don’t maintain state, or use the browser to maintain state for you by passing it back with each response, then this is a total non-issue for you and you can move along – because the client will supply context info each time it returns, you don’t have to worry about which server you’re going to.

Which brings us back to the first option – use the browser to track state. In large applications with lots of database interaction this option isn’t feasible, but in smaller applications that just have controls on a page being fed back with each submit, you can do this rather readily. It is more difficult in newer applications – AJAX apps and advanced .NET functionality, but it’s wholly doable, just takes some forethought about how your application is used and what goes where.

The easiest solution to this whole problem is the group sidearm/server affinity/persistent connections. All of these options let you pass off a request to the server, and then always return to the same server (though how you return is different for each), but this introduces some issues of its own. For one, the ability to balance load amongst your servers is minimized because the load-balancer makes its decisions only on the first trip to the server – with some advanced load balancing algorithms that take server feedback these technologies can actually negate the benefits of load balancing. Still, this is the right solution for apps that have a pretty evenly spread load across all pages, so consider your client use cases and think about whether one of these technologies will solve your problem.

Another solution is to shift the storage of per-connection persisted data to the database. Unless you have a pretty high-end database server, both in hardware and software, this just moves the problem. If you’re running something like Oracle RAC, it’s a viable option, but if you’ve got a single-instance database on a low-to-mid-tier commodity server, you’re probably not going to be satisfied with this solution – it takes code to implement, and if you rearrange your code and then at the end discover that you have just switched the load and the single point of failure to your database, you will likely not be a happy camper. Thus, I don’t recommend this course, though in some situations it might be the right one.

Finally, you could rewrite the app to not utilize state at all. This is more work if your app is already finished… But it is the most robust of all of these solutions. If you’re just designing an app that you hope to be huge, avoid the Fail Whale and write it this way from day one.

SSL persistence

Another nasty bit – that is very similar to the persistence header above, but has unique problems of its own is SSL persistence. Yes indeedy, it’s passingly difficult to decrypt a stream that was encrypted for another server’s public key. And while this issue can be resolved by giving all the app servers that run a particular application the same cert (this is done, I suspect SANS doesn’t approve), there are other issues. Like the fact that when a client comes back and is directed by the load balancer to a different server, there is no existing connection, so the client and server have to renegotiate. Some load balancers and most ADCs provide SSL termination to resolve this issue, terminating the SSL session at the load balancer and communicating from the load balancer to the backend server – because it is all on your private network – in the clear. For security reasons, in some applications this is not a viable option, and even if it is, you need to check with your load balancing vendor to see if they support this mechanism. The most common solution to this problem is the sidearm/server affinity/persistent connections set of solutions mentioned above, because once a client connects to a server it is always redirected to that same server and all of these issues go away. Just test the effect this will have on your load balancing algorithm before going this route.

 Other options and issues

Of course in this short blog post I can’t hit everything, but these are the major issues I’ve seen. And I’m not touching on the things that a full-blown ADC can do for you that load balancers don’t. I think I’ll take next week’s blog to review load balancing algorithms so you know which does what, then we’ll start to peel away the power of an ADC – which really is amazing in comparison to simple layer 4 (commonly called L4 by networking folks) load balancing.

Until next time,

Don.

Everyone knows one, the person with a ton of great information in their head and difficulty getting it from brain to mouth without a zillion side-tracks.

Put three or five or seven of these people in one room for a meeting, and you get a totally non-productive environment.

Being an empowerment specialist – or just a guy that writes funny blogs on Fridays, you decide which – I have devised the perfect rule that will eliminate the egg timer and the “talking stick” from your conference rooms…

The Twitter Meeting Rule! You must make all of your statements in 140 characters or less, then you have to STFU and let someone else talk.

You will free up conference rooms because meetings will be much shorter, your staff will be more productive because they’re only saying the important bits…

Or your meeting rooms will be full all of the time because your staff is trying to condense important topics into short phrases, your staff will be less productive because key people skip meetings or are always in them, progress will come to a halt…

Of course, I’ve worked in organizations where no meetings would be a productivity increaser ;-).

So there you have it, whether it’s a good idea or a bad idea, it’s a winner!

Your lucky day, I’m here to advise you. Now go forth and be more productive. Or enjoy your Friday, either way. I’ll be on a plane after a long week of meetings.

Don.