Kevin, Rusty, et al --
Although VistA on GT.M on Linux on CoLinux on Windows is likely to be a
perfectly good demonstration environment, it is not supported for
production or even safe for situations where you need to ensure data
integrity (like production). Please do not use it in production.
The only officially supported Linux distribution for GT.M is RHEL 3. It
is safe to put GT.M in production on just about any contemporary release
of any major Linux distribution. Anything else is potluck and I must
strongly urge against it. Let me give a medical analogy.
A doctor getting treated by another doctor is officially supported. A
doctor treating himself or his loved ones is not officially supported,
but safe as long as he can keep himself objective. Uncle Fred offering
you his prescription migraine pill when you have a headache that won't
go away is potluck.
For a database to have integrity in the face of a system crash, the
behavior of the underlying IO subsystem needs to be (a) known and (b)
predictable. When GT.M says "commit this data to non-volatile storage,
now" and hears back from the operating system that it is committed, in
the event of a system crash, when recovering, GT.M needs to be sure that
committed data was indeed committed. When layering one operating system
on top of another, this assurance does not exist. This is just one
example of the need to have known and predictable underlying system
behavior.
A demonstration environment needs to be operational for a small period
of time when everything underneath is operating correctly. Worst case,
for a demonstration environment is a failed demonstration and you
recover by starting over. Production environments do not have this
luxury, and must be much more rigorous. [By way of background, I came
to GT.M by way of a career in electronics test and measurement - in
fact, every time you step on a 757 or 767, you are putting your life in
my hands, because I was the software architect of a instrument used to
test and troubleshoot their radio altimeter. I bring a "belt &
suspenders" approach to engineering and I find myself annoyed by things
like operating systems that need frequent rebooting.]
In this context, officially supported means that Fidelity has a server
grade system (as opposed to something you might buy in Staples, Wal-mart
or Best Buy) in house running RHEL 3, and we run the GT.M regression
test suite on it for every production release of GT.M. A contemporary
release of a major distribution (Debian Stable/Testing, SuSE, Mandrake,
Fedora, etc.) on server grade hardware is safe because the core
components that GT.M relies on is very small, and to the best of our
knowledge is both common across contemporary releases of major
distributions, as well as being well tested. Potluck is, well, potluck.
Note that this extends to hardware. Use server grade hardware (it
doesn't have to be a big name brand like IBM, HP or Dell - you can
certainly use reputable off-brands like Penguin Computing). In
production, USB flash drives are not acceptable; even USB or PCMCIA hard
drives are not. Use server-grade IDE or SCSI hard drives from reputable
manufacturers, not consumer grade disk drives in a RAID 5, RAID 0+1 or
RAID 1+0 configuration. If you plan to push performance, disk
controllers that have battery-backed nonvolatile "write back" cache,
with Linux drivers that support this functionality can help; RAID 0+1
and RAID 1+0 will perform better than RAID 5.
NFS or SMB (Samba) mounted file systems, as well as NTFS and FAT file
systems (on Linux) are potluck for production. Use ext3, reiserfs, jfs
or xfs. [Ext3 is officially supported; reiserfs is faster and very safe
- I personally use reiserfs in preference to ext3; jfs and xfs are
believed safe.]
More notes for production:
Get a UPS, and connect it to your computer system so that when
the power fails you can script an automated and orderly
shutdown.
Run a server with the minimum set of packages that you need for
production. Tuxracer is cool, but do you really want that on
your production EHR system? Every unwanted package is one more
potential vulnerability, and one more piece of software that
will be periodically patched and updated.
Go through the procedures for all routine operations (e.g.,
backup) as well as all the forseeable but unscheduled
eventualities (e.g., power failure, forgotten password). Create
a "run-book", and have it handy near the computer console. When
things go bump in the night, your sleep deprived brain is more
likely to be able to correctly follow a documented series of
steps than correctly plan a course of action.
Last but not least, buy support contracts - from your hardware
vendor, for your operating system (you can purchase support for
all major Linux distributions - Crawford Rainwater may want to
comment here), for GT.M, and, if you are not supporting VistA
yourself, then for VistA.
Someone like Jim Self who has run a large production installation may
wish to expand on (or disagree with) this advice.
-- Bhaskar
***************************************************************************
This electronic mail transmission contains confidential and/or privileged
information intended only for the person(s) named.
Any use, distribution, copying or disclosure by another person is strictly
prohibited.
***************************************************************************
NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s)
ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou
dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce
message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner
immediatement a l'expediteur et effacer ce courriel.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
