Navigation:  Installation > Hardware Deployment Scenarios

The Recommended System Requirements section contains specific ImageServer hardware requirements.  This section describes at a higher level serveral different hardware deployment scenarios for scaling the ImageServer software.

The ImageServer software has been designed to scale with a facilities needs. The software will support small-scale deployments where the database, image storage, and services are deployed on a single server. The software will also support deployments with a dedicated database server, multiple servers to run the services and web server, and multiple Network Attached Storage (NAS) devices for storing of online images. The ImageServer can also support SAN devices for image storage, if desired.

The following sections detail three typical deployment scenarios. Note that the ImageServer software is flexible and can support combinations of these examples.

Small Scale Deployment

The major components of the ImageServer are the database, the web server software, the windows services, and the archive services (included in the 1.0 release of the ImageServer). The simplest deployment of the software places all of these components on a single server. Note that this is a good starting point when deploying the ImageServer. It is possible to add additional servers or filesystems after initial deployment of the ImageServer to accommodate increased load.

Medium Scale Deployment

A typical medium scale deployment would add a dedicated database server and NAS to the small scale deployment (with preferably a Gigabit network between the servers). This allows for offloading of the major disk access functions from the main server.

The use of NAS devices with the ImageServer for storage of images adds a great amount of flexibility. Additional NAS devices can be added at any time to increase online storage. The use of NAS devices also simplifies the configuration when using clustered servers as detailed in the next section.

Large Scale Deployment

A large scale deployment will expand upon the medium scale deployment. Multiple filesystem tiers will be added, a cluster of servers to run the Windows services, and a load balancer will be added to distribute the DICOM traffic among the server cluster.

In a large scale deployment it is recommended that a dedicated database server have multiple independent disk volumes to increase performance. At least 3 independent volumes would be suggested. When deploying the database, the ImageServer installer has an option to pick the storage location for various parts of the database. The database log file would be placed on an independent volume, the database indexes on an independent volume, and the database tables are on a third independent volume. A likely hardware configuration would have RAID 1 mirroring for each disk volume on the database server. Note that the installer does allow separating the database queue related tables, static tables, and the remainder of the tables in separate volumes. If a fourth disk volume is available, it would be recommended that the queue related tables be placed on one volume, and the other tables on a different volume. The queue related tables are the most frequently updated tables and thus would benefit from being isolated from the other tables.

The ImageServer supports having multiple tiers of online storage. See the Filesystem Configuration page for a description on filesystem tiers. In a typical large scale deployment, the first tier of storage may be sized to store 3-4 weeks worth of data to ensure that studies are reported on while they are stored on the first tier of storage. The first tier of storage may contain SCSI based disks for faster access, while lower level tiers may have SATA drives for increased storage and lower cost. This allows the flexibility of allowing more disk space to be purchased for older studies, and thus more data online.

The main processing engine of the ImageServer is the WorkQueue. The WorkQueue processing engine can be configured to specify how many simultaneous threads are used when processing queue entries (the default setting is 10). This tells how many simultaneous threads are used to process incoming studies, perform migrations of studies, compress studies, edit studies, etc. The WorkQueue processing mechanism has been built to support running on clustered servers, which can thus increase the number of simultaneous queue entries that are worked on, and increasing overall throughput and responsiveness of the ImageServer software.

When deploying a cluster of servers, two deployment schemes can be used. In both schemes, the ImageServer software appears as a single application to the client application. Since the database is shared among all servers in the cluster, Querying against any server in the cluster would result in the same studies being returned.

Clustering with Divided Modalities

The first method for configuring clustered servers requires assigning specific modalities and/or workstations to specific servers within the cluster. These DICOM applications would always connect to their configured server. The load would be split among the servers in the cluster by how client applications are configured. If there is a desire to add additional processing power for the ImageServer, servers can be added at any time. Note, however, that modality and workstation devices may have to be reconfigured to point to the new server in this configuration in order to split the load among the servers.

Clustering with a Load Balancer

The second method would be to deploy a network load balancer to distribute DICOM and web server requests among the servers. Load balances are typically used in large web server deployments, but can also be used to balance other network services such as DICOM. The load balancer is typically configured to distribute connections to the DICOM port among the servers within the cluster. The modality and workstation DICOM devices would be configured to communicate with the IP address and port configured on the load balancer. The load balancer balances connections among the servers within the cluster in order to evenly distribute the load. One advantage of this configuration is that additional servers can be added to at any time to increase processing capabilities of the ImageServer. The load balancer would just have to be configured to use this new server and client systems will automatically start accessing this new hardware.

Clustering Notes

One note on the use of load balancers when deploying the ImageServer. When a DICOM application performs Query/Retrieve against the ImageServer over time, the load balancer will typically send the requests to different servers within the cluster. All servers within a cluster of ImageServer servers will use the same AE Title. When a DICOM C-MOVE request is issued, this will result in the ImageServer connecting to the DICOM application from different IP Addresses, but using the same AE Title. There are some DICOM applications that require that only one IP address be associated with a DICOM Application Entity title, and may have problems with this configuration.

A second note on the use of load balancers concerns failover scenerios.  The ImageServer software does not contain any specialized software to handle failovers if a hardware failure occurs within the cluster.  It is assumed in this case that the client system connected to the cluster would initiate a new DICOM connection that the load balancer would route to a new server in the cluster.  Note also that when configuring a load balancer, the load balancer must be configured for "sticky" connections, where once a connection is establish to the cluster, subsequent requests over the connection go to the same server in the cluster.

A third note regarding clustering concerns how the path to a filesystem should be configured when clustering servers.  Each server in the cluster must be able to access the filesystems configured by the same path.  This typically means that a UNC path to a shared CIFS folder is configured as the path to the filesystem.  Note that mounted drives typically do not work in this scenario.  Since the ImageServer's ShredHostService runs as a Windows Service, mounted drives are typically not available to a running service.