[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
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).
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
LAN.
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?
- Re: [Gnumed-devel] Approaches to maintain clinical data uptime,
James Busser <=