[Server-devel] Server Redundancy
Greg Smith (gregmsmi)
gregmsmi at cisco.com
Wed Feb 6 09:10:15 EST 2008
Hi Tony et al,
Nice write up on redundancy! I've pasted it verbatim in to the project
plan/requirements doc. Still hoping to enter that in the Nepal Wiki by
Friday.
FYI this URL http://wiki.laptop.org/go/XS reveals several good XS
documentation links in the OLPC Wiki.
More comments and requirement details welcome. I'll watch the list and
extract details and add them to the project tracking pages here:
http://wiki.laptop.org/index.php?title=Nepal#Planning
Thanks,
Greg S
-----Original Message-----
From: server-devel-bounces at lists.laptop.org
[mailto:server-devel-bounces at lists.laptop.org] On Behalf Of
server-devel-request at lists.laptop.org
Sent: Tuesday, February 05, 2008 10:50 PM
To: server-devel at lists.laptop.org
Subject: Server-devel Digest, Vol 10, Issue 9
Send Server-devel mailing list submissions to
server-devel at lists.laptop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.laptop.org/listinfo/server-devel
or, via email, send a message with subject or body 'help' to
server-devel-request at lists.laptop.org
You can reach the person managing the list at
server-devel-owner at lists.laptop.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Server-devel digest..."
Today's Topics:
1. Re: Server-devel Digest, Vol 10, Issue 8 (Tony Pearson)
2. Re: First stab at XS project plan (Adrian Chadd)
----------------------------------------------------------------------
Message: 1
Date: Tue, 5 Feb 2008 18:55:55 -0700
From: Tony Pearson <tpearson at us.ibm.com>
Subject: Re: [Server-devel] Server-devel Digest, Vol 10, Issue 8
To: server-devel at lists.laptop.org
Message-ID:
<OF18EBB7C5.4DC4F92E-ON072573E7.00064E19-072573E7.000A9B65 at us.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Barry,
Here are my thoughts on redundancy. The basic heuristics is as follows:
(a) Determine the minimum setup and identify all components that can
fail individually.
(b) For each failure, what would be the impact to the entire system.
(c) Determine an N+1 or N+2 configuration that might address the
concern.
Let's assume that:
The LS (Library Server) is not located at the school, but somewhere else
in the country, or hosted by the ISP itself.
There is a single ISP provider, who provides a single line to the school
that carries the internet signal.
The ISP provides a single RJ45 terminal cable, which can be connected to
a Hub or XS server A single four-port hub/Wifi router, which allows
laptop use, network printer, or other servers.
The School has a single XS server, two USB ports, two Active Antenna,
and that each antenna handles maximum 100 XO laptops The WiFi router is
WEP-protected so that only teachers/principals/guests have access, all
students on mesh-only There are 200 laptops, at least one per student or
teacher.
LS----(ISP)---Hub----XS----AA1- - - - - XO1, XO2, ... XO100
----AA2- - - - - XO101, XO102, ... XO200
Failure scenarios:
LS fails -- students have access to local activities, XS moodle lessons,
and internet, and whatever LS content cached on XS server
Is that a problem? If there is a central LS for all of Nepal,
they should consider a secondary LS server.
Resolution: Perhaps have some LS content permanently on a local
server, either on XS or other, in event central LS is down
ISP fails -- students have access to local activities, XS moodle
lessons, and whatever LS/Internet cached content on XS server
What is ISP providing for "Service Level Agreement". Can they
resolve this in a single day or two?
Resolution: class might continue without internet access. Some
lessons might be impacted that involve LS or Internet access.
Hub fails -- students lose access to LS and internet. Teachers lose
access to WiFi.
Resolution: XS could be connected directly to ISP until new Hub
replacement made available. Students continue as before.
XS fails -- students lose access to LS, Internet and XS moodle. Can
they
mesh with each other? They can continue using activities on their XO.
The XS failure could be either the disk drive itself fails, or
something else on the system that prevents it from running.
Resolution: it would seem that best option is multiple XS
servers, and perhaps mirrored disk data between the two systems.
AA1 fails -- If one Active Antenna fails, the other Active Antenna will
not be able to handle the total 200 XO laptops. Do we know how
many XO laptops an active antenna can support?
If AA1 was for second graders, and AA2 was for sixth graders,
then perhaps only one grade impacted.
Resolution: Having an AA3 would mean that any one antenna
failure, the remaining two antenna can handle the workload
XO (teacher) fails -- An individual teacher is impacted. For N
teachers,
you should consider N+1 XO laptops, with one or more spare
to handle this situation. The teacher XO would be enabled for
WiFi-WEP key and have whatever extra software was needed on them.
In lieu of an XO, the teacher could have a full PC running QEMU
emulating the XO image, in the event it takes long to repair the
original XO.
XO (student) fails -- An individual student forgets his XO at home,
breaks it, or whatever. Too bad. Student looks over shoulder of
a fellow student. Alternatively, have a few XO student laptops
that can be swapped out with the broken one while the broken
one is getting repaired. Student would lose any work unless it
was backed up to XS server.
Here is an alternative with some redundancy built in:
LS1----(ISP)----Hub------------------------------------------Hub
LS2 XS----AA1, AA2, AA3
In this case, we have two Library Servers in the central location, and
the ISP or the LS-folks handle this so that they are properly available
if one or the other is down.
Alternatives for disk failure can include a LiveCD+USB stick. In this
case, if the disk fails, you boot from a LiveCD, and the USB stick has
all the modified values (conf files, IP settings, etc).
Depending on the size of the USB stick, could contain critical backups
of Moodle lesson plans, etc.
There are also ways to have a "Boot from USB stick" that can then have
either all the modifications needed, or a second USB with the modified
values.
Fedora 7 uses Linux LVM, and I suspect this level of LVM supports disk
mirroring, which makes updates to two disks at the same time. In the
event a single disk fails, the other disk would be used. That needs to
be investigated. In this case, there would be two disks inside one
server, containing identical information.
Three Active Antenna would handle 300 laptops, so losing one can still
handle the 200 XO laptops expected.
A second hub provides wider WiFi access, more ports for
peripherals/printers, etc. In the event a hub fails, the other one can
be connected in its place.
For this to work, you need an XS server with at least 3 USB ports.
Another alternative:
LS1----(ISP)----Hub------------------------------------------Hub
XS1----AA1, AA2 XS2----AA3,
AA4
LS2-Local
In this example, LS2 is a local version or subset of LS1, in the event
the internet or LS1 is down, the LS2 can be used instead.
There can be two XS servers. XS1 for second graders, XS2 for sixth
graders. In the event either one is down, all students can use the
remaining XS server. Each AA can handle 100 XO laptops, so assuming 100
second graders and 100 sixth graders, then this setup can handle loss of
any two active antenna and still be able to handle all students, and
provide room for growth. XS1 and XS2 would send backups to each others
databases to each other as needed, and if needed, an XS could handle the
databases of both sets of students, and possibly have separate Moodle's
on single Apache instance.
XS1 could backup to XS2 and vice versa. This can be scheduled with CRON
and SCP.
Alternatively, LS2 could double as the backup server, with XS1 and XS2
sending backups to LS2.
Tony Pearson
(IBM)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.laptop.org/pipermail/server-devel/attachments/20080205/38f0
fe7c/attachment-0001.htm
------------------------------
More information about the Server-devel
mailing list