Re: Session and Multi Server Architecture

On 2/11/08, Per Jessen <per@computer.org> wrote: > Because you've chosen another option - memcached presumably - which is > more expensive over all. (IMHO). mysql (stated above), and i already have a connection open each page... > On the next request, LVS will know not to try that server, and the user > will move to another one. Obviously the session-context will die, but > is that really a big deal? How often does one of your servers die? > Sure, if you've got 10,000 in a cluster, you'll have fans and harddisks > pop every so often, but I have my doubts about memcached scaling to > that level (please correct me if I'm wrong here, I have _no_ experience > with memcached). actually right now i have an issue on my system i'm working on resolving - and it does create some poor experience for users. when one of my webservers is taken out of the pool (softly due to a healthcheck failure, not via reboot) those clients can get connection refused, or connection reset (if mid-connection) - and if anyone is uploading or downloading a file, they're screwed too. persistence or not, that won't solve this, but it is my note about servers going down and the little bit of non-transparency of the failover... > LVS won't migrate any of your data for you. It'll shift the client to > an available server, that's all. yes i know that. so you're either advocating: a) persistence AND central session management, or b) persistence and not keeping anything important in a session in case the server is pulled out of the pool? (assuming non-centralized session support)