As always, Bhaskar's advice seems well thought out, knowledgeable, and solid.
I think that we in VMTH are pretty closely in alignment with it. I am no longer directly involved in the setup of our production systems, so I may have missed some details. I think we are still using ext3 file systems and haven't tried reiser yet. It is good to know that we could expect a performance gain with that as we are in the process of upgrading our servers to new hardware. We are also shifting our servers to Debian. Most of our development servers and some of our production servers have been Debian for quite a while. We really like the Debian way of doing upgrades. We haven't tried RHEL. I copied this to our group to see what comments might come back. Bhaskar wrote: >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 > >*************************************************************************** --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- 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_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
