[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
facility.
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
LAN.
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
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346