Clustering LTSP

November 5, 2005
LTSP by the Seaway
Ivan Krstić
Harvard University
part of Ubuntu Below Zero Cambridge, MA, USA
Montreal, Canada krstic@hcs.harvard.edu
Who am I?
 software architect, journalist
 specialize in architecture and security of large-
scale web applications
 currently on leave from Harvard University,
working as Director of Research at the Medical
Informatics Laboratory at Zagreb Children's
Hospital
 run a hospital-wide, clustered LTSP
deployment
Clustering
 30-second primer, two acronyms:
 HPC – high performance computing
 HA – high availability

 What do we want for clustering LTSP?

 definitely HA
 quite possibly some bits of HPC
Why cluster LTSP at all?
 Because you should be scaling out, not up
 ... so any setup that makes it hard to scale
out should scare you!
 There is nothing intrinsically unscalable
about LTSP
 Scaling out to two machines is already
possible with ISC dhcp3-server magic
 But that's it. Can't use the same strategy to
scale past two machines.
Don't get too excited
 The first thing people get happy about
when I talk about clustering LTSP
 “If an LTSP server dies, my users'
sessions will get transparently
moved to another server, and the
users won't notice! Woohoo!”

 Can that be done?

Uh...

NO.
So what's it good for?
 Even if your sessions aren't migrating
transparently, you can still use LTSP
clustering to ensure 100% availability
 Even if a server fails and a session dies, the
users can reboot the client and log in again
immediately!
 On top of this, you get essentially linear
scalability
 Which works beautifully.
What's beautiful scalability?
 Order a server without any disks
 Throw it in your rack
 Turn it on
... profit!
 Configuration is magically handled for
you, and you can now support many
more clients.
What was that about HPC?
 It turns out that not all users are equal
 And neither are applications.
 One user might be running a Java
application that constantly sucks 60% of
the server's CPU
 Other users might generally run resource-
unintensive tasks that sometimes get CPU-
hungry, but you can't tell ahead of time
If you do connection balancing
 These scenarios are a nightmare
 Fifty users
 fair split
 24 very unhappy users
 But you can't predict how much resources a
user will need before he logs in!
 Macromedia Flash
 Java
The kernel knows more than you
 So let it worry about resource
management!
 Introducing OpenSSI
 HP project, now largely community-maintained
 Stable release for 2.4 kernel, development
release on 2.6
 Integrates best of both worlds: HA and HPC in
one convenient, powerful package
 http://www.openssi.org
OpenSSI
 initnode concept, with failover
 usually diskless cluster nodes
 CFS magic
 single transparent cluster-wide IPC space
 process migration!
 load leveling!

Bingo!
How does this help us?
 Set potentially demanding applications to
be load leveled!
 Fifty users?
 No problem.
 OpenSSI won't break a sweat.
 Scales?
 Very, very well, and it'll be even better in the
future.
But I'm not a clustering guy...
 No problem
 Ubuntu integration forthcoming!
 Likely unofficial OpenSSI support in Ubuntu
6.04 (Dapper)
 Working on official OpenSSI support in
Dapper+1, out in October 2006
 Can play with it pretty easily now on
Debian, if you can spare two machines
Boldly going where no thin client
has gone before
 Future: instant gratification?
 Plop in an Edubuntu CD
 Choose to perform a clustered LTSP
installation
 Voila: you get an Edubuntu environment
with pre-installed LTSP and clustering,
and an easy administration GUI!
Conclusion
 Clustering LTSP lets us...
 scale out as much as we like, and trivially
 make optimal use of server resources by
means of automatic load balancing
 essentially guarantee 100% availability for our
deployment
 watch a whole new dimension of clueless
questions on #ltsp!
 Questions?