[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Approaches to maintain clinical data uptime

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Approaches to maintain clinical data uptime
Date: Sat, 29 Apr 2006 13:07:41 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Sat, Apr 29, 2006 at 01:29:52AM -0700, Jim Busser wrote:

> Whatever company provides me server (and related) service support  
> will ned to know what I want. They will also make some  
> recommendations which I will be happy to share. But I thought it  
> could be helpful to pool people's ideas, options or favored  
> approaches, I could then stick that up on the wiki.
Please do.

> Beyond maintaining OS (including security) updates
for which Debian is well suited via "apt-get update/upgrade"

> - primary server... should have 2 hard drives in a hardware RAID 1
> array,
I would have one disc for the OS and a RAID 1 mirror (2
discs) for the data (home dirs and clinical data). Putting
the OS on another mirror adds comfort (less downtime).

Such would protect you against *immediately* losing your
data when one data drive fails. (Offsite) backups must be
taken to ensure against loss of the server or entire

The RAID 1 does not give you *zero* downtime - not even
concerning failure of a single drive. The server will have
to be taken down for replacement of the drive unless you
have hot-swap hard drives sitting in drive bays.

> - would people bother to keep a spare drive available to swap out  
> when one fails, and/or to arrange for a local merchant to keep one  
> stocked
Not sure.

> - what about one's router/firewall which could fail...  would people  
> want to know they can quickly get another of the same model
LAN switches are pretty much plugin. Outside connectivity
(eg router) should not be mandatory for a working in-house

Firewall replacement should be: boot firewall boot CD in
another machine with two network cards.

> - backup server... ought this undergo all of the same hardening as  
> the primary server and will it need all of the same system  
> maintenance and monitoring (for breaches etc) as the primary server?
All in all, yes.

> Is there a way to simplify this by making the backup server the  
> equivalent of an extra RAID drive? Or is the best that can be done is  
> to setup and manage the backup machine as a "whole extra" machine,  
> just mirroring the data?
It depends on how much downtime you can afford. If you need
*minimal* downtime I would setup a slave database on a
secondary server identical to the first one. If the primary
one fails the secondary one should have to be manually
activated to replace the primary one.

> Which approach(es) permit --- from within  
> GNUmed --- quickly "switching" to read and write from/to the backup  
> server in the event that the primary fails?
My approach would be:

1) Slony continually replicates GNUmed database from primary
   to slave DB on identical secondary 

2) primary goes down

3) GNUmed clients are shut down

4) primary is taken offline for maintenance

5) secondary is consistency-checked and promoted to be
   master DB via Slony

6) GNUmed clients are brought back up

7) in the login dialog "GNUmed database on backup" server
   is selected

8) a few things may have to be re-entered (we don't support
   keeping that yet)

9) everything is intended to proceed as normal

> Would people run their media archive off their primary
primary, should be replicated, too, if downtime is critical

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]