SERVERS AND OPERATING
SYSTEMS
KENNETH M. NESBITT • THOMAS J. SCHULTZ • ROBERTO DASILVA
Sometimes policies and procedures for all areas of system (picture archiv- ing and communication system [PACS]) operations are overlooked, or it is assumed that the PACS vendor will provide them. Although every vendor provides a standard build document, it usually lacks procedures for contin- gencies such as server deployment, maintenance, change management, virus prevention and recovery, and server recovery from hardware and software failures. Therefore, it is important that the institution understand the avail- able technologies and, jointly with the selected PACS provider, develop a PACS server strategy that reflects the goals of the institution. This chapter has 3 sections that discuss technologies and issues to consider during the deployment process: “The PACS Core (Servers),” “Operating System Secu- rity and Policies,” and “Viruses, Trojans, and Worms.”
15
C H A P T E R
T H E PA C S C O R E ( S E R V E R S )
There are numerous server deployment scenarios from which to choose.
Most strategies are based on one or more of the following techniques: single server, multiserver, load balancing, and server clustering.
S I N G L E S E R V E R
The single server model consists of one server handling all PACS functions.
These functions include the importation of exams from DICOM modalities, the processing of the database requests, and the processing of image distri- bution requests from the radiologists’ interpretation workstations. Work- stations can access exams via standard Web protocols (the same Web protocols used to book your vacation on the Internet) or through a propri- etary application program interface (API) built into the PACS vendor’s soft- ware. The single server scenario is often ideal for an imaging center or small community hospital where the size and volume of exams are relatively small. Thus, the need for additional servers to provide the distributed proces- sor power, memory, and hard disk space is not as great as it would be in a larger hospital, where higher volumes and exam sizes necessitate more resources. Figure 15.1 illustrates a single server model for PACS using Web technology as a means of distribution, with a backup server waiting in the wings.
M U LT I S E R V E R
In a multiserver model, a separate server is responsible for each component of the PACS. One server handles DICOM importing, another server main- tains the database, and one handles image distribution requests. This design affords the luxury of having processor power, memory, and hard disk space dedicated to each PACS component on an individual basis rather than having the components competing for the resources of one server. For example, this proves useful in institutions where large exam sizes and the number of studies performed can cause the database to grow to considerable size (200 giga- bytes [GB] or more). Figure 15.2 shows a multiserver model for PACS using Web technology as a means of image distribution. All requests for informa- tion or images are funneled through the Web server. The Web server acts like a traffic cop, directing information requests to the proper servers. Image requests are serviced from the archive(s), and textual requests are serviced through the database.
L O A D B A L A N C I N G
The load-balancing model is based on the theory of distributing tasks evenly so that no one system is overwhelmed; each server assigned to a task shares that task evenly. In PACS this technique works well with DICOM image servers and image distribution servers. For example, if a PACS had two DICOM image servers and two image distribution servers, the request to send images into the PACS would be intelligently routed to the DICOM server with the least amount of activity. Requests by the PACS workstations for images would be satisfied by the distribution server that is the least busy.
The intelligence required to load balance is not provided by the PACS vendors but is provided by third-party technology vendors. Load balancing can be implemented at the hardware level (through content switch, a device that monitors network/server activity and makes decisions on what server should service a given request) or the software level (through Microsoft; the software runs on the servers instead of on a dedicated device). It is worth noting that database servers are costly to load balance (See “Clustered Failover” following this section) because transactions need to be coordinated among all participating servers.
FIGURE 15.1
A single server model for PACS using Web technology as a means of distribution, with a backup server available.
Web Clients DICOM
Database Web
Dark Backup
Server
Figure 15.3 illustrates a typical load-balancing model for PACS, using the Web as a means of image distribution. Following the diagram, both DICOM image servers forward their respective information to the database server, while each Web server makes respective calls to the database server to fulfill the client requests.
DICOM Images
Database
Web
Dark Backup
Server
Web Clients
FIGURE 15.2
A multiserver model for PACS using Web technology for image dis- tribution. All requests for information or images are funneled through the Web server, which directs information requests to the proper servers.
C L U S T E R E D FA I L O V E R
The clustered failover model provides a high level of hardware redundancy protection for PACS servers (this approach is often referred to as active- passive clustering). Clustered failover means that one server controls the task being performed while the second server passively waits for the first one to fail. In this model, the DICOM image servers are clustered together in pairs, as are the image distribution servers, providing simple failover redundancy.
Image and Web Servers each handle one half of the traffic.
Image Servers
Database Server
Dark Backup Servers
Web Server
Web Clients
FIGURE 15.3
A typical load-balancing model for PACS, using the Web as a means of image distribution. Both DICOM image servers forward their information to the database server, while each Web server makes calls to the database server to fulfill the client requests.
The failover between servers is managed through software, either with an enterprise-class operating system such as UNIX/Solaris, Windows 2000 Advanced Server, or Windows Server 03 Enterprise edition, or through commercially available cross-platform products such as Veritas. A caveat of this approach is that if the PACS software caused the failure of the first server, the second server will also fail because it is running the same software as the first.
It is also possible to combine techniques (often called active-active clustering). For example, if the database (IBM DB2, Oracle, or Microsoft SQL Server) were clustered and load balanced, then during normal opera- tions all data requests would be evenly distributed between both physical servers. If one failed, all operations would be funneled to the remaining server. Figure 15.4 shows a clustered failover (load-balanced) model for PACS using Windows 2000 Advanced Server as the operating system. This
Web Clients Web
Servers Database
Server
Backup Database
Server
Dark Backup Servers Image
Servers
Failover Link
Database Copy Failover Link
FIGURE 15.4
A clustered failover (load-balanced) model for PACS; Windows 2000 Advanced Server is the operating system.
approach is usually very costly and offers little advantage over active-passive clustering.
S E R V E R H A R D WA R E A N D O P E R AT I N G S Y S T E M S
There are a number of manufacturers and configurations to choose from when deciding on server hardware. Companies such as Dell (www.dell.com) (Austin, TX), Hewlett-Packard (www.hp.com) (Palo Alto, CA), IBM (www.ibm.com) (Armonk, NY ), and Sun (www.sun. com) (Palo Alto, CA) all offer quality entry level to high-end servers depending on an organization’s needs and the chosen PACS solution. If the PACS solution is Windows based, then DELL, HP, and IBM are all excellent choices at very competi- tive prices. If the PACS vendor offers a UNIX/Solaris-based solution, then Sun is the only choice, as the hardware and operating system are proprietary (Linux may be an option for some implementations in the near future).
Tables 15.1 and 15.2 show a quick comparison of some server product fea- tures and major operating system features. No matter which PACS solution an organization implements, there are powerful, high-quality server hard- ware and operating systems available.
TABLE 15.1 Sample Server Hardware
No.
Internal
Vendor Processor Max RAID Disks Memory Redundant
Model Speed Processors Level (Max Size) (Max) Components
DELL 2850 3.6 GHz 2 0,1,5,10 6–300 GB 12 GB Yes
DELL 6600 3.0 GHz 4 0,1,5 8–300 GB 32 GB Yes
HP DL380 3.6 GHz 2 0,1,5 6–146 GB 8 GB Yes
HP DL580 3.0 GHz 4 0,1,5 4–146 GB 32 GB Yes
IBM X345 2.67 GHz 2 0,1,5 4–146 GB 8 GB Yes
Sun V440 1.28 GHz 4 0,1,5 4–73 GB 16 GB Yes
Note: Usually for PACS, having more than 2 processors in a server yields little gain.
D I S A S T E R R E C O V E RY
Disaster recovery (DR) planning is equally important as choosing the right PACS solution. Without thorough and concise planning, an institution may find itself severely impacted if a major failure occurs on one of the PACS core components. System downtime could be counted in weeks if proper strategies are not developed. This section discusses different aspects of DR, such as uninterruptible power supply (UPS) and emergency power, server operating system (OS) imaging, archiving, and database backups.
U N I N T E R R U P T I B L E P O W E R S U P P LY
Having a UPS and emergency power installed in the room where the PACS servers will be housed is critical to surviving anything from power blips to complete power outages. An enterprise-class UPS consists of several large batteries, built-in power filtering, and system-monitoring capabilities.
The ideal UPS will provide enough battery power to allow servers to shut down gracefully in the event of primary power failure. Companies such as MGE (www.mge.com) (Saint Ismier, France) and APC (www.apc.com) (W. Kingston, RI) offer entry level to enterprise-class UPSs capable of accommodating any PACS scenario.
Most hospitals and trauma centers supply backup emergency power to key areas such as the emergency ward and intensive care units. Upon the installation of PACS, it is advisable to have the PACS servers integrated into the same emergency backup power system. Emergency power can keep PACS
TABLE 15.2
Sample Server Operating Systems
Supported Supported Cluster
OS Processors Memory Capable
Windows 2000 Server 4 8 GB No
Windows 2000 Enterprise 8 32 GB Yes
Windows 2003 Server 4 8 GB No
Windows 2003 Enterprise 8 32 GB Yes
Linux 64 64 GB Yes
Solaris 64 64 GB Yes
servers operational through power failures and enable an organization to con- tinue operating until normal power has been restored. The role of a UPS in this scenario is to provide enough power to bridge the gap between the initial power failure and the institution’s switch over to the backup power system.
O P E R AT I N G S Y S T E M I M A G I N G
Server OS imaging involves using third-party software to take a snapshot (state in time) or image of the OS volume (or any volume) that encompasses all the applications and server patches installed. Images of other volumes, such as the database or log volumes, may also be acquired. By implementing a strat- egy of making OS images of servers before making changes such as installing security patches, tweaking performance, or upgrading applications, extensive downtime can be avoided. If a system change causes issues, it can take less than 20 minutes to reset the affected server back to the last known running state.
(Consider the peace of mind provided by knowing that it will only take 20 minutes to restore a server to a known working state after a virus attack.) This is significantly faster than having to go through the process of reinstalling the OS and other applications, then possibly having to re-create the database from tape backups and database log files. Two vendors of server-imaging software are Acronis (www.acronis.com) (Herndon, VA) and Powerquest (www.powerquest.com) (Orem, UT). Both offer excellent products to help protect your server environment and reduce the time required to recover from a disaster. Both products offer the capability to restore system images from remote network locations (NAS) or from CD or DVD.
R E M O VA B L E M E D I A
Archiving to removable media provides the institution with the option of storing the removed media in a secure offline location. (Storage devices are covered in detail in Chapter 16.) There are many choices for removable media, such as CD, DVD, DLT (digital linear tape, proprietary technology devel- oped by Quantum), Super DLT 1, Super DLT 2, LTO (linear tape open) 1, LTO 2, and the recently released LTO 3. For smaller institutions, a DVD archive would probably suffice. With DVD media capable of writing to both sides, the ability to store 9.4 GB on one disc is appealing, and the new 25 GB DVD release is imminent. One company that offers this solution is DAX Archiving Solutions (www.daxarchiving.com) (The Netherlands). The DLT solution has been around for a while and is still a viable option for most
institutions. It provides up to 80 GB of storage using data compression. Super DLT 1 takes things up a notch with capacities of 160 GB raw and 320 GB com- pressed. Super DLT 2 goes even further, with capacities of 300 GB raw and 600 GB compressed. Linear tape open is an open standards–based technology supported by companies such as Hewlett Packard, IBM, and Seagate (Scotts Valley, CA). Linear tape open 1 tapes can store 100 GB raw and 200 GB compressed. The second-generation LTO 2 drives can store 200 GB raw and 400 GB compressed. Linear tape open 3 became available in the fourth quarter of 2004 and offers capacities of 400 GB raw and 800 GB compressed. Two companies that offer complete DLT and LTO solutions are Storage (www.storagetek.com) (Louisville, CO) and IBM (www.ibm.com).
D ATA B A S E B A C K U P S
Database backups are an essential of everyday life in the world of PACS.
They are a vital piece of the DR puzzle that must be completed to ensure a minimal loss of data (PACS and server configurations) in the event of a sub- stantial failure or environmental disaster. In conjunction with server imaging, the database backup can be used to restore the database to a state that would be less than 24 hours old. It is highly recommended that database backups be performed regularly (every 24 hours). Occasionally restoring a backup to a test system to ensure the integrity of the backup is good idea. Backing up to a high-density tape such as Super DLT or LTO enables retaining many days’ worth of backups, which is useful in the event a single backup copy is bad. It is important to be cognizant of the fact that database corruption or hardware failure can occur at any time, so keep several backups to prevent major headaches.
O P E R AT I N G S Y S T E M S E C U R I T Y A N D P O L I C I E S
To maintain a secure network environment and ensure system functionality, it is crucial that server security policies be clearly developed and outlined.
The following is a general outline of recommended server policies.
O P E R AT I N G S Y S T E M PAT C H E S
Operating systems (defined as the first program that runs when a computer is turned on; this program manages all other programs, including applica-
tions such as e-mail or PACS) all have flaws or bugs. The OS provider con- tinually offers updates (patches) to fix problems that can cause crashes or to seal security flaws to protect the server from hackers. It is very important to routinely and diligently monitor the OS provider’s Web site for available patches. Usually a security hole is discovered and fixed before hackers can take advantage of the flaw. How? Hackers reverse engineer a security patch to learn of the OS flaw and then create malicious programs (viruses) to exploit the flaw. Their intention is to affect systems that are not patched (protected from the flaw).
V I R U S P R O T E C T I O N
Operating system patches are the first line of defense against malicious (virus) software (see “Viruses, Trojans, and Worms” in the next section). The second line of defense is a genre of software (obviously named) antivirus.
Antivirus software runs on each server and workstation and continually mon- itors files and running programs for signature behaviors. The antivirus soft- ware provider continually researches the Web and other sources for virus sightings. Once a new virus is discovered, it is then studied and reverse engi- neered to determine what security flaws it takes advantage of, how it repli- cates itself, and whatever else it tries to do (e.g., steal data, clog the network).
Once the virus is understood, this information is electronically sent to all customers subscribing to the antivirus provider’s service. The updated infor- mation is often called “virus signatures.” Once the antivirus software is updated with the new signatures, it will then scan the server to determine whether it has been compromised. If it has been, the antivirus software will remove the virus, cleansing the system. Sometimes the system is so severely compromised that it cannot be repaired. In this scenario the system will need to be rebuilt from a known clean OS image or by reinstalling the OS and applications. Providers of antivirus software include McAfee (www.mcafee.com) and Norton (www.symantec.com).
PA S S W O R D S
Servers should have individual user accounts and fairly complicated pass- words to prevent a security breach by a hacker. Most hackers will write a simple algorithm looking for easy access through weak passwords or, better yet, no password at all. Examples of weak passwords are “123” or “abc.”
PA S S W O R D C O N S T R U C T I O N G U I D E L I N E S
◗ Include both upper- and lowercase characters (e.g., a–z, A–Z).
◗ Have digits and punctuation characters as well as letters (e.g., 0–9,
!@#$%Ÿ&*()_+|~-=\`{}[]:≤;¢·Ò?,./).
◗ Have at least 8 alphanumeric characters.
L I M I T T H E N U M B E R O F U N N E C E S S A RY A C C O U N T S
Avoid creating duplicate user accounts, test accounts, shared accounts, general department accounts, and the like. Use group policies to assign per- missions as needed, and audit your accounts regularly.
N O U N E N C RY P T E D A U T H E N T I C AT I O N
It is advisable that user authentication (logging in) be encrypted (an encod- ing that makes a password difficult to reverse engineer). For example: “baby”
could be encoded to “%%$FFDFDR” during transmission over the network, but when the server receives the login data it converts it back to
“baby.” This is important to consider because hackers have tools that allow them to monitor network traffic and snatch passwords that are transmitted in clear text (“baby”).
N O U N A U T H O R I Z E D E - M A I L D E L I V E R I E S
All operating systems have the ability to send mail messages to other servers.
Malicious code (viruses) has the ability to leverage this process and cause havoc throughout the institution (spam and other mail-clogging problems).
To help avoid this situation, it is advisable to turn off the SMTP (simple mail transfer protocol) program unless it is absolutely needed.
P H Y S I C A L S E C U R I T Y
All servers and related equipment should be located in a secure room with limited access to only those individuals supporting the system. This is an
obvious security measure to take, but many institutions have had issues with missing/modified equipment due to poor access polices.
S E C U R E B A C K U P M E D I A
All backups and emergency repair disks should be kept in a secure, fireproof location in a building other than the one where the server resides.
S E C U R I T Y G U I D E L I N E S F O R W I N D O W S ( N T, 2 0 0 0 , 2 0 0 3 , A N D X P )
Following are basic guidelines unique to Windows-based systems.
A D M I N I S T R AT O R A C C O U N T S
The administrator account in Windows grants the highest level of access.
Any system change can be performed with this account. Therefore, the administrator account (in domains, the domain administrator) should be restricted to senior members of the information technology (IT) staff.
Each IT staff member requiring administrative privileges should have his or her own account created and placed within the administrator’s group.
This will allow for clear tracking of who is doing what and when. For situ- ations in which IT staff require fewer privileges, such as reading e-mail, a second account should be created with a lower level of access. Following this practice will prevent accidental changes from being made to critical systems.
R E P L A C E T H E “ E V E RY O N E ” G R O U P W I T H
“ A U T H E N T I C AT E D U S E R S ” O N F I L E S H A R E S
“Everyone” in the context of Windows security means that anyone who has access to your server can access the data contained within those shares. The
“Everyone” group is assigned by default when a share is created and thus should be replaced with the “Authenticated Users” group.
PA S S W O R D P R O T E C T T H E S C R E E N S AV E R
A simple method of preventing access to a system in an unsecured location is to password protect the screensaver. This is a basic feature built into all Windows operating systems. For details, visit www.microsoft.com.
U S E N E W T E C H N O L O G Y F I L E S Y S T E M O N A L L PA RT I T I O N S
New technology file system (NTFS) is the only file system type that imple- ments strong security and encryption features. It also contains autocorrec- tion capabilities when corruption occurs. For these and other reasons, it is recommended that this file system be implemented for most applications.
Visit www.microsoft.com for more information.
R U N W I N D O W S U P D AT E
Microsoft provides a mechanism for automatic notification and installation of critical OS patches. It is strongly recommended that you take advantage of this service. On servers it is usually the best practice to set the service to download all patches automatically, but to install them manually. This approach allows for review of how the patch will affect the PACS applica- tions. It is possible that some patches may prevent PACS from running correctly.
D I S A B L E T H E D E FA U LT S H A R E S
Windows NT, Windows 2000, Windows Server 03, and Windows XP open hidden shares on each installation for use by the system account. You can disable the default administrative shares in two ways. One is to stop or disable the server service, which removes the ability to share folders on the server.
The other way is by editing the registry (see www.microsoft.com for details).
Keep in mind that disabling these shares provides an extra measure of secu- rity but may cause problems with applications. Test your changes in a lab before disabling these shares in a production environment.
V I R U S E S , T R O J A N S , A N D W O R M S
More than 30 new viruses appear every day, and the roster of active viruses increases by more than 10,000 per year.
D E F I N I T I O N O F A V I R U S
A virus is defined as a piece of code that replicates by attaching itself to another object, usually without the user’s knowledge or permission. Viruses
can infect program files, documents, or low-level disk and file-system structures such as the boot sector and partition table. Viruses can run when an infected program file runs and can also reside in memory and infect files as the user opens, saves, or creates the files. When a computer virus infects a computer running Windows, it can change values in the registry, replace system files, and take over e-mail programs in its attempt to repli- cate itself.
D E F I N I T I O N O F A W O R M
Worms are a type of virus that replicate by copying themselves from one computer to another, usually over a network. The general goal of a worm is to replicate itself to as many systems as possible. Often the worm acts as a transport mechanism for delivering yet another virus.
D E F I N I T I O N O F A T R O J A N H O R S E
A Trojan horse is a virus that masquerades as a useful program. Sometimes it actually performs a useful purpose, but behind the scenes it releases a virus.
A Trojan horse program can come from an e-mail attachment or a down- load from a Web site, usually disguised as a joke program or a software utility of some sort.
E D U C AT I O N A N D T R A I N I N G
The operations and IT team should work together to develop a sound edu- cation and training program for the PACS users. The more users understand about passwords, viruses, and safe computing, the less likely it is that they will be the ones to allow a compromise of the PACS system.
G L O S S A RY
CORE The central foundation of the PACS, consisting of one or more servers.
SERVER Powerful, robust computers that possess multiple-gigahertz-speed processors, several gigabytes of memory, and several gigabytes of hard-drive space (RAID).
PROCESSOR The component of a server that does most of the data processing.
MEMORY The component of a server that assists the processor with data processing and preserves data for retrieval.
HARD DRIVE The component of a server that holds and spins a magnetic disk and reads/writes information on it. It is also referred to as a hard disk.
GIGABYTE (GB) A unit of computer memory or hard drive capacity equal to 1,024 megabytes.
GIGAHERTZ (GHZ) A unit of frequency used to measure modern processor clock speed. One GHz is equal to 1 billion clock cycles per second.
SYSTEM ARCHITECTURE Deployment scenario/server model: the topology of the CORE systems, workstations, and archive, meaning the number of servers used and their respective roles.
PRIMARY SERVER The server that performs most or all of the PACS func- tions on a regular basis.
BACKUP SERVER A server that is attached to the network and configured to deploy in the event of a failure or virus attack on the primary server.
DARK SERVER A server that is detached from the network to prevent infec- tion from virus attacks. This provides a preconfigured, virus-free server to deploy in the event that the primary server requires downtime for repairs.
