Remove active connections from backup system after return to normal

Hi Al,

 

 

Do you want to do this automatically or manually? If manually, you could use 'b conn' to delete the connection table entries for this virtual server (or pool member). For an automatic solution, you could try something like this:

 

 

1. Track when a low priority pool member is selected

 

2. After a low priority pool member is selected and then a higher priority pool member is selected for a new connection, log some special message to syslog-ng

 

3. Use a custom user_alert.conf entry which calls a shell script that uses 'b conn' to delete the relevant connection table entries.

 

 

If the latter option is one you want to explore I can try to give you more detail on how you could do this. If anyone else has a more elegant solution, please reply.

 

 

Aaron

Hi Aaron,

 

 

Thanks for the reply. I'd like it to be automatic. I see what you are proposing, I'd like it to be self contained within the bigIP rule if possible, so I don't have to rely on a syslog server as well.

 

 

Thanks!

 

 

Al

 

The iRule to syslog-ng message would be processed locally and wouldn't require an external syslog server. The one gap I see in this is that the initial trigger would require a new connection to be sent to the virtual server. So the deletion of the "bad" connection table entries wouldn't necessarily occur immediately after a higher priority pool member comes back up.

[LB::server priority] to check whether the selected pool member is a normal or low priority pool member: http://devcentral.f5.com/wiki/default.aspx/iRules/lb__server

A subtable accessed using the table command to track the flip from a low priority to high priority pool member: http://devcentral.f5.com/wiki/default.aspx/iRules/table

A user_alert.conf statement to call a shell script to delete the connection table entries: 'b conn help' and these steps:

1. Create a script file /usr/local/bin/mycustomscript.pl 

   vi /root/mycustomscript.pl

2. Add the script to the file and save: 

   !/usr/bin/perl
   system("echo Alert was triggered > /var/tmp/mycustomscriptoutput.txt");

3. Set the permissions on the file: 

   chmod 755 /root/mycustomscript.pl

4. Edit /config/user_alert.conf and add the following alert definition.  The quoted portion is a regex which must match the syslog message.

   alert my_custom_alert "this is the text we look for in the syslog message" {
      exec command="/usr/local/bin/mycustomscript.pl"
   }

5. Trigger the script: 

   logger -p local0.info "this is the text we look for in the syslog message"

6. Review the script action which was to create a file and output some text: 

    less /var/tmp/mycustomscriptoutput.txt

        Alert was triggered 

If you try this and get stuck, let us know. Else, if you get something working, it would be great if you could share an anonymized copy of it.

Thanks, Aaron

Hello Aaron,

 

 

I have a similar query and will the grateful if you could answer.

 

 

I am trying to Load Balance Microsoft Exchange 2010 servers at one of my clients.

 

 

The Setup is as follows:

 

 

1 Primary Site - Having 2x CAS Servers

 

1 DR Site - Having 1x CAS Servers

 

 

The Pool in the LTM consists of all the 3 CAS servers and has Priority Group Activation = Less than1

 

The 2 CAS Servers have a priority of 4 whereas the CAS at the DR has a priority of 3. So in case both of the CAS servers at the Main site go offline, the users are shifted to the DR Site CAS servers.

 

 

THE PROBLEM

 

 

The problem is that when the CAS Servers are brought back online the users (both new and existing) still keep connected to the CAS at the DR.

 

 

A colleague has given me a suggestion to use iRules, but the thing is that I am not proficient with iRules.

 

 

Would appreciate if you can help me devise an iRule which checks to see that is the Servers with Higher priority are online the users should get connected to them rather than the lower priority servers.

 

 

Are you looking to actually sever active connections to the DR site once the Primary is back online, or are you just looking to ensure that all new requests get routed appropriately?

 

 

Colin

Thanks for your reply Colin!

 

 

Well even if I am able to sever current connections in order to move them back on to the Primary servers it will work for me because as you can imagine everbody connects their email clients first thing at the start of their day so there aren't many new connections coming in till the next morning.

 

 

However if this is not possible somehow the latter (routing the new connections to the Primary Servers) could also be a step forward.

 

 

Thanks for your help!

I don't think iRules would provide a simple efficient option for forcing clients to connect to a higher priority pool member if they've been using a lower priority member and the higher priority pool member comes back up. Doing so, you'd need to constantly check on every connection to see if the client is on a lower priority member and a higher member is available. Though maybe you could use the after command to do this? Colin, do you have any thoughts on how simple this would be?

 

 

Here's the psuedo code I'm thinking of. As you can't check the priority of a member that isn't currently selected, I'd actually change the config to use a main pool and a standby pool. You could then try to implement logic like this in an iRule:

 

 

When a connection is established to the virtual, check if the main pool has any active members. If not, select the standby pool.

 

 

If we've selected the standby pool, run an 'after -periodic' script every X seconds to check if the main pool is back up. If it is, then reset the client connection to force a new connection.

 

 

http://devcentral.f5.com/wiki/iRules.after.ashx

 

http://devcentral.f5.com/wiki/iRules.active_members.ashx

 

 

The downside to this is that you couldn't easily wait until a transaction is complete. So the client might get a reset in the middle of a transaction with this logic. Also, there could be a performance impact on LTM in order to regularly check the status of the main pool

 

 

Else, you could potentially create an external monitor which tracks when a high priority pool member transitions from down to up and then clear any existing connection table entries to the lower priority members. I don't think this would be extremely complicated to implement, but it's definitely not something you could throw together in 10 minutes. If you're up for some shell scripting, you could try this yourself. Else, you could engage an F5 or partner consultant to do this.

 

 

Here's an external monitor template you could use to start with. But the actual script logic is a bit more tricky.

 

http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/TemplateForExternalLtmMonitors.html

 

 

Aaron

Thanks Aaron,

 

 

Here's what I'm gonna do. I'll start by working on the first solution which you have suggested and alongside gather the required knowledge about shell scripting for the external monitor.

 

 

I do have two queries and will appreciate your replies.

 

 

1) How can I have a 'main pool' and a 'standby pool' for a Virtual Server in the LTM?

 

 

2) Is this behaviour (of having to write a irule for switchover when the Higher Priority Member comes back online) specific to Microsoft Exchange or is this how it is with the LTM and other applications as well?

 

 

Thanks once again!

 

 

1) How can I have a 'main pool' and a 'standby pool' for a Virtual Server in the LTM?

You can use the pool command in an iRule to select the remote CAS pool:

when CLIENT_ACCEPTED {
     Check if the VS default pool has no active members
    if {[active_members [LB::server pool]] == 0}{
        pool remote_cas_pool
    }
}

2) Is this behaviour (of having to write a irule for switchover when the Higher Priority Member comes back online) specific to Microsoft Exchange or is this how it is with the LTM and other applications as well?

It's not specific to Microsft Exchange. This scenario could come with any application where clients leave connections open for long periods of time.

Aaron

Thanks alot Aaron!

 

 

The client has gone on vacations for two weeks, I'll try to simulate this scenario and test the iRule in a test environment (if i can gather the required resources) as you have detailed in your reply. I'll get back to you about how it goes!

 

 

Your help is much appreciated, cheers!