...
Clustering the SP requires that you understand a number of inter-related issues:
Is the application itself clusterable?
How does the application's session management interact with the SP's session management, if at all?
What are the capabilities of your load balancer?
What are your tolerances for single points of failure?
The key issue is session management. The SP does maintain other information in memory, but generally this only includes the replay cache, and the protection you get from replay checks probably isn't enough to justify worrying about clustering it.
...
The overhead of this approach has not been studied extensively, but in 2.0 the design was substantially changed in order to minimize the network traffic needed. For a typical application not under extreme load, this is likely to be viable. However, you have to understand a few things:
Performance becomes pretty horrible very quickly as load increases. This is a bad solution for any but a lightly used site.
The protocol between the servers is NOT secure. It's a simple XML protocol running over TCP. You MUST rely on a secure network between the servers, ideally a private subnet.
The server running
shibdis a single point of failure. If the process fails or the server fails, you'll lose all active sessions. However, you can restart any of the web servers without losing any state. They will reload any sessions as needed.Session affinity is still important here. You'll get much better performance if you keep some locality of reference, because the sessions are cached in the web servers as well.
Shared Database
If you really want to try to cluster the SP in a persistent way, there is a plugin provided for this purpose based on using an ODBC-compliant database. You'll see there are lots of caveats recorded there.
...