[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: James Busser
Subject: Re: [Gnumed-devel] Approaches to maintain clinical data uptime
Date: Sun, 30 Apr 2006 23:24:45 -0700

On Apr 29, 2006, at 4:07 AM, Karsten Hilbert wrote:

- primary server... should have 2 hard drives in a hardware RAID 1
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).

One disc for the OS because... db speed would be improved?

Such would protect you against *immediately* losing your
data when one data drive fails... The RAID 1 does not give
you *zero* downtime - not even concerning failure of a
single drive.

By "zero downtime" I just meant no "sudden" downtime in the event that one drive fails. Maybe I am wrong, but I thought that some hardware controllers, despite permitting a RAID 1 array, may not continue to read/write on a single drive if the mirror stops functioning. And therefore as part of a RAID 1 array choosing, when possible, a controller that would continue to run the single drive while issuing alerts as one member of the array is failing (or fails).

The server will have
to be taken down for replacement of the drive unless you
have hot-swap hard drives sitting in drive bays.

Mine aren't in drive bays, so a satisfactory scenario would include a server array (as above) that could function with one drive failed, with a site practice that includes IT support checking of the logs for such alerts, and taking down the server at a time chosen to be the least disruptive.

- 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

Unless the server is located out-of house or is much-accessed from outside of house (say from a second surgery location, or else from an emergency room where one of the GPs often sees patients who had received care in the surgery).

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

Here are you using dedicated firewall hardware, or a PC, as the firewall (or does it matter)? Does "boot CD" mean to upload a config file to the firewall which, in order to work, would depend that the new firewall is interoperable for that config syntax and settings?

[re backup contingency] My approach would be:

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

For someone who knew what they were doing ("IT support"), how long might the above typically take? Is it the type of procedure that could be written down and followed by a GNUmed office administrator in the event that the "IT help" is not quickly enough available?

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

What would be the response of the backup server if it would be selected by the GNUmed client without it having been promoted to master DB via Slony? Would the slave DB refuse to respond?

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

Not clear about the "replication" here. Is it to maintain twin sets of media stored in separate physical locations? Would you invest in some type of "mirroring" media setup, like 2 cd burners each holding a CD for archiving, with a separate cron job backing up to each?

reply via email to

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