Hi Emnoc,
Thanks for the reply, for us the answer isn' t exactly an easy solution.
As a bit of background our site is primarily e-commerce, around 140 servers with over 60 different applications (with at least two instances of each app). A full site shutdown isn' t feasible, even if our management agreed to let us do it.
While our DR site is a full replica of production, management are extremely reluctant to even consider a failover, majority of the time it is used as perf test environment and isn' t suitable to take a production load. This is a sore point for us in Ops, we want to run out of DR on a regular basis but alas we can' t.
But from my own testing/rehearsal I didn' t see a major impact when doing the switchover in DR. I actually had a SSH connection to a few servers in that environment, all of which maintained the the ssh session. This is one of the reasons I asked the question, it shouldn' t have been like that if the new cluster was looking at it' s empty session table.
There are two things that are in our favour; the majority of our apps do connection validation, so they will reconnect if a connection is broken. Currently we know of four apps that don' t do this properly and we can restart them quickly. And the second thing that actually assists the first is that we have reset-sessionless-tcp enabled.
I was hoping the cluster would operate in a manner similar to a VRRP failover where the unit would go into async routing mode so it could learn it' s session table without killing existing sessions. I could also see another scenario where this could happen; A Fortigate operating as an inter-site router using a dynamic routing protocol, eg; OSPF. A WAN link goes down (physically) and traffic reroutes over a different path, when the link comes back OSPF would re-advertise the path and existing sessions would be thrown back at the Fortigate.
In any case, thank you for your feedback. Either way I' ll be ensuring I have some admins and tester on hand when we do the switch over.
Regards,
Matthew