we've used a combination of glusterfs and keepalived to provide completely bumpless failover for the thin clients.
Glusterfs exports a shared NFS filesystem that is identical between servers, ie identical inodes etc. (Glusterfs has it's own inbuilt NFS server) Keepalived uses VRRP to maintain a failover IP address(es) between the servers. So, each server has a glusterfs ltsp filesystem with an IP address that will fail over to the other server. We then hand out round-robin DNS for the server address to the clients. This therefore load balances the clients across the servers. In the event of a failure keepalived will bring up the failed server IP address on the other server completely transparent to the clients. The address (and clients) will swing back once the failed server is returned to service. Similarly, to perform maintenance on a server, simply stop the keepalived service on the server to be maintained and the clients will start using the other server. Darryl On 07/26/14 18:23, Jigish Gohil wrote: > On Sat, Jul 26, 2014 at 1:31 PM, a. <thissid...@riseup.net> wrote: >> Looking through the documentation I only ever find vague explanations of >> how high availability would work with LTSP. The scenario I have in mind >> is that the main ltsp-server crashes, but the clients can simply connect >> to one (or more) other servers where at least the file systems are >> replicated. >> >> Since we are planning to use fat clients, session management should be >> no problem here (afaik that information would live in the ram of the >> clients then anyway). Also it wouldn't be that much of a deal if the >> boot-server would smoke down too. The only real issue are the file >> systems, where we plan to have two or three main read-only roms and >> diff-images for each node using unionfs/aufs. >> >> I understand that LTSP-cluster may be what I am looking for, but as I >> see it, ltsp-cluster is not meant for provisioning a cluster, but to >> scale the ltsp-server across a cluster. In our scenario most of our >> nodes in our cluster are fat clients that should connect to the ltsp >> infrastructure. >> >> How should I go about to avoid a single point of failure using ltsp to >> host multiple fat clients? >> > Here are the basics of HA LTSP server cluster for serving fat-clients: > > 1. You need shared storage, we've use 2 node DRBD cluster for serving > /home to all the clients > 2. LDAP authentication server > 3. VM to serve PXE to all the clients, this serves boot menu > defaulting to fatclient image server(NBD/NFS/AOE) based on client IP > with options to use alternate servers, either dnsmasq or dhcpd+tftp > should work > 4. Fatclient image servers can be real machine or VMs serving images, > we limit to using about 70 clients per giga NIC available on the > server, this can scale depending on NICs bonded > > We use VMs(kvm) for 2,3,4 so they can be migrated on any cluster node > in case of failure on one of them. All the nodes including file server > use SSD storage. > > Unfortunately there is no step-by-step howto, but it is easy to figure > out once you know what exactly is needed. > > Cheers > > -J > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company. ------------------------------------------------------------------------------ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
