Forum Discussion
Chris_Miller
Altostratus
AltostratusSelective Persistence with Priority Grouping
1. All users are in DC1.
2. F5 exists in DC1.
3. The Pool contains 2 Servers in DC1 and 2 Servers in DC2. Using Priority Group Activation, the Servers in DC1 will receive all traffic as long as at least 1 of them is up.
4. Server persistence is not required, DC persistence is.
5. Traffic is SNATd to 1 of 4 possible addresses before hitting this F5.
6. If DC1 goes down, users will lose session when failing over to DC2. when DC1 comes back up, I'd like users to remain in DC2 so they don't lose session again.
I'm not entirely sure of the best way to handle this situation. I only need persistence if the 2 DC1 servers have failed and that persistence simply needs to keep users in DC2. I can't use cookie persistence and source_address persistence seems like it would keep me from distributing load to each of the 2 servers in DC1 while they were up. Thoughts?
- Chris_MillerMy thought so far:
I'm using priority "10" for DC1 and "5" for DC2.
So, I could do something like this:when LB_SELECTED { if { [ LB::server priority ] eq 5 } { pool DC2 } }
That essentially solves my problems, right? 
naladar_65658I think this may be a good case for universal persistence. I have not used that before, but basically you create an iRule that looks at the traffic and persists based on things that may be unique. What kind of traffic are you sending, is there anything like a session ID that would be unique to each connection that you could use?- naladar_65658Here is a post that seems like a good example running off the jsessionid for persistence:
http://devcentral.f5.com/Forums/tabid/1082223/asg/50/showtab/groupforums/afv/topic/aff/5/aft/56918/Default.aspx - Chris_MillerPosted By naladar on 08/11/2010 07:47 AM
I think this may be a good case for universal persistence. I have not used that before, but basically you create an iRule that looks at the traffic and persists based on things that may be unique. What kind of traffic are you sending, is there anything like a session ID that would be unique to each connection that you could use?
It'll typically be HTTP traffic...but our app folks aren't confident enough in using anything L7 for persistence...I'll get them there eventually...need something short-term though. - Chris_MillerThinking of my example more...I need to add a persistence method to it...otherwise when DC1 comes back up, users will get sent over there.
- naladar_65658Have you look at destination address affinity persistence?
- Chris_MillerPosted By naladar on 08/11/2010 08:24 AM
Have you look at destination address affinity persistence?
I've admittedly not...I understand how destination address works for outbound traffic where it chooses a gateway pool member...how does it work for inbound traffic? Since example IPs 1.1.1.1-1.1.1.4 will hit my VIP which has pool members 2.2.2.2 and 2.2.2.3, what will my persistence table look like? - naladar_65658I haven't used it before, but here is what the manual says about it. "DAAP- Also known as sticky persistence, daap supports TCP and UDP protocols, and directs session requests to the same server based solely on the destination IP address of a packet."
- Chris_MillerAm gonna give this a shot...see any issues?
when LB_SELECTED { if { [LB::server priority] eq 10 } { persist none } else { persist source_addr 255.255.255.255 3600 } }
When DC1 comes back up, I want to ensure persistence table is checked before this rule is. 
hoolioCirrostratus
I'm pretty sure destination address persistence would use the pre-translation destination IP (the IP the client makes the request to, not the selected pool member).
Your latest example looks like it should work for the scenario.
Aaron
