[Systems] migrating to beam rider

[David Farning]

On Tue, Oct 20, 2009 at 1:04 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Mon, 19-10-2009 a las 22:01 -0500, David Farning escribió:
>> Why rsync everything? Maybe I misunderstand what you mean by
>> everything.  One of the goals for migrating is to clean up
>> actiivities.sl.o so it will be easy to replicate across multiple
>> machines.
>
> Ah, ok. I thought we wanted to migrate the current a.sl.o instance with
> the guarantee that it will be exactly as it is now: code, config, db and
> datafiles.

Ok, I started poking around beamrider last night.  I didn't realize
that you had cloned _everything_.    Based on that we can just update
the config files, point activities2.sugarlabs.org at beamrider, and
start testing.

>> 1. Create /srv/www-sugarlabs/activities on beamrider by pulling from
>> the git repo.
>> 2. Copy activities.sl.o config files from sunjammer to beam rider.
>> 3. Insure proper apache mod are installed and enabled on beamrider.
>> 4. Copy the apache activities.conf file from sunjammer to beamrider.
>> Edit as needed
>> 5. Copy /etc/logrotate.d/activities from sunjammer to beamrider.  Edit
>> as needed.
>
> What about the data?

The data is in (1) the data base which could stay on sunjammer for now
and in (2) the two file directories talked about below.

>
>> Questions.
>> In order to scale activities.sl.o across multiple front ends it will
>> be necessary for each front end to mount
>> /srv/www-sugarlabs/activities/files/ and
>> srv/www-sugarlabs/activities/repo/ from a common mount point.  Is
>> setting up a NFS mount the best way to do this?
>
> I'd use NFS, although it makes us rely on a single point of failure and
> scalability bottleneck (although much less critical).

This part can be postponed until later.

> Doesn't remora also offer a distributed filesystem option? How's Mozilla
> deploying it?

Mozilla uses a network attached storage.
/srv/www-sugarlabs/activities/files/ and
/srv/www-sugarlabs/activities/repo/ and
the apache logs are sent to the NAS.

So, if a PHP node goes down nothing is lost.

>> If this is hard, we can post pone it until later and just copy the
>> directories.  The advantage of setting up the common mount point now
>> is that we can share a common database instance, memcache instance,
>> and file directories.  By doing this, we can point activities2.sl.o at
>> beamrider for testing.  From a user pov a.sl.o and a2.sl.o will be
>> exactly the same.  To go live we just need to flip a switch to point
>> a.sl.o from sunjammer to beam rider.
>
> We can do it, but truly scalable and fault-tolerant architectures
> are supposed to be "shared nothing". Or "share as little as required
> for consistency". Perhaps we could get along with sharing just the
> database.

The two files directories are part of the a.sl.o data.

A work flow example using 2 php nodes, PHP1 and PHP2 with _separate_
file stores. --
When a activity developer uploads a new activity to PHP1, the data
about the new activity is stored in the database and the the xo
activity bundle is stored on PHP1:/srv/www-sugarlabs/activities/files/
.

When an editor tries to make the activity public, a.sl. with be in an
inconsistent state _unless_ they happen to hit PHP1.  At first glance
everything is fine, most of the data is in the common database.
However, a.sl.o will not be able to find the file.  The database will
say it is stored in the sandbox
(/srv/www-sugarlabs/activities/files/).   When in fact, the file is
only stored in PHP1:/srv/www-sugarlabs/activities/files/

The shared data consistent of both the files and database.

>> 6. Set up cron job to rsync from common
>> srv/www-sugarlabs/activities/repo/ to /srv/uploads/activites.
>
> Why not just make those two directories the same with a symlink?

Using a NFS mount, it would be possible to do a symlink.

>> > Agreed.  Moreover, the *upload* directory at least needs to be on
>> > sunjammer so that users can actually put things in it.
>>
>> This is also a argument for setting up upload as a NFS for now.
>
> Ok. I wanted NFS for sharing user's homes too.
> It will be a read-only nfs share anyway... quite secure.
>
>
>> If you get a chance to make a fresh karmic VM for
>> launchpad.sugaabs.org, I will retest the install.
>
> Ok, I will. Just be patient as I'm super-overbooked.
No hurry, this has dropped pretty low on my prioritizes list.

david
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>
>