Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Joerg Jaspert <joerg@debian.org> writes:
>>> Now, should the technician not be able to resurrect ries, our backup
>>> plan extends to have the disks shipped over and replace the ones
>>> currently in rietz.
>> I'm wondering if Debian has the resources (DSA, local admins and
>> hardware) to have a hot-swappable backup machine for ftpmaster, since
>> it does go down occasionally and when it does the downtime is fairly
>> disruptive to Debian.
>
> Well, this would mean:
> a) double ftpmaster. Just as a rough number, the new machine that is
> currently "in progress" has an estimated cost of 20000 Dollar (if you
> take prices from HP Website. This is not what it will cost in the
> end, but it shows what category of stuff we have to get)
> b) Have the double space at our hoster.
> c) Run it with heartbeat, drbd and all that.
>
> Point c) is actually easy enough, even though im not DSA and can't decide
> for them to do it. But technically it would be a working setup, provided
> b) works out, as you really want a *FAST* connection between the
> two. Which means local.
>
> The only trouble this setup has is that you have a pretty huge expensive
> machine always on and running, but not actually doing stuff for
> 99.999999999999% of the time. And usually the support pack we ordered
> provides a service that means getting machine back faster than this, so
> the question in the end is: Do we want the added complexity (and costs),
> or can we just stand a day or three of downtime? Its annoying, but world
> doesnt really die.
Is there any way to build a distributed service instead of relying on
one central machine (or two machines sitting next to each other)?
I don't know exactly what services are involved, but typically and
generally, when I deploy a server infrastructure, I try to setup (at
least) two machines at different geographical places that each can
provide the entire service.
The complexity in getting a heartbeat, drbd, etc solution to work can
easily eat up any downtime savings you plan to get.
/Simon
Reply to: