Posted by: Anonymous Coward
on June 14, 2005 01:03 AM
>The application was originally not written with >load balancing in mind, so all state is kept >locally.
Then you can't have session fail over without fooling the application at a lower level. Depending on the application you might find a technique for doing this without changing the application. If you run on Linux and the state information is written to disk (not a database) then you might be able to use NFS. (Assuming your application allows for multiple concurrently running instances--which means the application is already doing file/record locking of some type).
The best approach, however, is to start thinking about storing state information outside the cluster.
> Keeping state on a database potentially > creates a bottleneck and single point of > failure.
It shouldn't be a performance bottleneck if it is designed properly. There are major web players using flat files. The database or NAS server should be built using HA techniques. A shared SCSI bus between two servers using the Heartbeat package, for example. If the Heartbeat servers are built properly (using STONITH for fencing) then you eliminate single points of failure and the dangers of split brain conditions.
> The application doesn't allow state to be kept > anywhere but locally and fundamentally cannot > be changed (e.g. a cluster of Windows Terminal > Servers).
This is not a good candidate for LVS clustering. You would only achieve load balancing not high availability. You'll have to look to Microsoft for their HA/cluster solution.
The LVS cluster works best for the applications that these users will run rather than a cluster of application servers that are also acting as terminal servers. Best to physically separate the presentation and data tiers from the business tier (put the presentation and data layers outside the load balanced cluster).
Learn about Linux
Download Linux
Get Linux help
Re:How does this work with sessions?
Posted by: Anonymous Coward on June 14, 2005 01:03 AMThen you can't have session fail over without fooling the application at a lower level. Depending on the application you might find a technique for doing this without changing the application. If you run on Linux and the state information is written to disk (not a database) then you might be able to use NFS. (Assuming your application allows for multiple concurrently running instances--which means the application is already doing file/record locking of some type).
The best approach, however, is to start thinking about storing state information outside the cluster.
> Keeping state on a database potentially
> creates a bottleneck and single point of
> failure.
It shouldn't be a performance bottleneck if it is designed properly. There are major web players using flat files. The database or NAS server should be built using HA techniques. A shared SCSI bus between two servers using the Heartbeat package, for example. If the Heartbeat servers are built properly (using STONITH for fencing) then you eliminate single points of failure and the dangers of split brain conditions.
> The application doesn't allow state to be kept
> anywhere but locally and fundamentally cannot > be changed (e.g. a cluster of Windows Terminal
> Servers).
This is not a good candidate for LVS clustering. You would only achieve load balancing not high availability. You'll have to look to Microsoft for their HA/cluster solution.
The LVS cluster works best for the applications that these users will run rather than a cluster of application servers that are also acting as terminal servers. Best to physically separate the presentation and data tiers from the business tier (put the presentation and data layers outside the load balanced cluster).
#