[Server-devel] Thoughts on redundancy
Bryan Berry
bryan.berry at gmail.com
Thu Feb 7 15:28:42 EST 2008
Tony,
Great ideas on redundancy. I have put them on the wiki
http://wiki.laptop.org/go/Nepal:Redundancy
Here are some ideas I have on the questions you raised
> LS fails -- students have access to local activities, XS moodle >
lessons,
> and internet, and whatever LS content cached on XS server
We could run a script ahead of the first day of school that locally
caches the library content on the XS. There likely will be some but not
a ton of content on the library by April 13th (first day of school).
Also, we should have a live back up Library Server that mirrors the
production library server
> 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?
The ISP's in Nepal are actually pretty reliable. ISP access will likely
be donated along w/ volunteer support. They should be able to resolve
issues quickly __for this pilot__. For broader implementation we will
need service level agreements and dedicated support, be it volunteer or
paid.
An issue that I am concerned about: What if the mesh network crashes? I
heard this happened in Mongolia and it is still not totally resolved. We
need a way to fall back to non-mesh networking very quickly.
> AA1 fails
Don't know how many clients an active antenna can support. Need to
figure that out
> ----------------------------------------------------------------------
>
> 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
>
> ------------------------------
>
>
> ------------------------------
>
> _______________________________________________
> Server-devel mailing list
> Server-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel
>
>
> End of Server-devel Digest, Vol 10, Issue 10
> ********************************************
More information about the Server-devel
mailing list