Skip to Content.
Sympa Menu

sm-admin - Re: [SM-Admin] Getting things going again...

sm-admin AT lists.ibiblio.org

Subject: Developer Only Discussion List

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: sm-admin AT lists.ibiblio.org
  • Subject: Re: [SM-Admin] Getting things going again...
  • Date: Thu, 20 Oct 2005 19:12:31 -0500

On Oct 20, Eric Sandall [eric AT sandall.us] wrote:
> On Thu, 20 Oct 2005, Jeremy Blosser (emrys) wrote:
> <snip>
> > I think this would make sense if we weren't going with a dedicated hosted
> > box, but when we are going to have that it seems like the value would be
> > less. On a hosted box the worst case scenario is going to be a fried box;
> > replacing that would be a couple hours (at most) for the hosting center to
> > get a new box in place, then time for rebuilding the OS and restoring the
> > data from off-site backups (which will at least exist in my location,
> > anyone else that wants their own will be welcome to them). All told it
> > could take a day or two at most. I just don't know if it's worth the
> > effort to keep looking at a distributed system if we expect to have a
> > resilent enough primary. Either one would have addressed the current
> > outage, but I don't know that we need both.
>
> The distributed system has several purpose:
> 1) If the main server goes out we have backups that can become masters
> within an hour.

Only if we update DNS to point to them, and that propogation can take days.
If we *weren't* getting an SLA-backed line and were just setting up a
distributed system with a lot of individually fallible nodes, we'd probably
handle this by making sure *something* was always available at the primary
listed IP, even if that something was a forwarder. But a dedicated line is
going to be too useful as the primary to have it sit behind something like
that IMO.

I agree we want to be covered for any reasonable contingency, but I don't
think our current size is great enough to justify a fully distributed
system of multiple dedicated lines, and a distributed system that's only
used in emergencies isn't going to be worth the effort for how often it's
going to actually be used, IMO.

> 2) Distributing the load among mirrors.
>
> 3) Allowing widely spread out users to use a mirror which is closer to
> them (and supposedly faster).

Well, what are we talking about mirroring? For codex and download the
above reasons make sense to me, but they're going to stay on ibiblio for
now anyway. You mentioned db replication though, which would be drupal and
bugzilla. For those we don't really need to distribute the load IMO. We'd
only want those mirrored for disaster recovery situations, which has the
issues noted above.

I'm not just trying to be contrary about this... www.mutt.org had a real
problem for years keeping up with this kind of mirroring. We simply didn't
need the mirrors, and keeping the list current in the name of "geographic
closeness" as mirrors showed up or silently went away took most of the time
available to maintain the site. Eventually we dropped all listing of www
mirrors and just pointed to google's caches and sourceforge's ftp mirror
list, and got on with more important stuff.

Attachment: pgpqijKHXrWnh.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page