Nimbostratus
Nimbostratus
I just might have that ability to make the developers read the correct books. The power that I might achieve with being able to leverage these requirements on the developer has no bound at this moment. Though you are absolutely right on the documentation. I am so used to having a firehose and just keeping things running that I do not make the time to get that done.
I wanted to keep it general to catch any "ah-ha" type things. But I guess describing my specific environment might have help with my examples.
We have 6 locations around the globe. We have GTM doing the wide area. The main application has about 30 VIPs, going to 150 webservers, that go to about 50 Dbs. They are distributed evenly about the globe. Some of the reasoning is vague as to why, but lets see if I can sum up. The user's session must persist to a database. Each VIP has a pool of webservers that point to the same Db. Dbs are in a multimaster replication. They can be 5 minutes between sites and sometimes up to 30 minutes if congestion is bad.
On the issue mentioned before about moving from VIP to VIP during a POST happened on the wide area. I cannot visualize how cookies might help in that instance, but ready to learn.
I am not sure why we didn't try wide area persistence on the old 4.6 3DNSes, but when I tried to turn persistence on the new GTMs, we lost a VIP, but users persisted to that VIP even when it was down (by F5 design, have submitted RFE). Another Grand Master "RAHM" helped with an iRule to just persist none when LB::FAIL. He and F5 Professional services helped with an iRule layout to put an warning screen "the data you were working on may not be available until replication catches up sorry" on the VIPs so when users are moved from VIP to a different VIP they are not caught off guard. MGMT seems fine with this for the most part. The bad is there are a few application screens that take 30 minutes for the users to fill out, if they are moved in the middle, they loose 30 minutes worth of work.
Thank You,