|
General Concepts |
  
|
|
General Concepts |
|
Server Partitions
The ImageServer supports configuring virtual partitions. These partitions can best be described as "virtual servers" within the ImageServer software. A partition is associated with a specific DICOM Application Entity (AE) Title and TCP/IP listen port. Any incoming DICOM SOP Instances sent to a specific partition can only be seen when querying against that partition's AE title and port. The partitions all share the same filesystems, services, and database. The installer automatically adds a partition during setup time.
See the Server Partitions section for further details on partitions.
Filesystems
The ImageServer allows configuration of multiple filesystems for storage of image data. The filesystems can be locally mounted drives, NAS devices accessed through a UNC path, or a Storage Area Network (SAN). The ImageServer allows assigning configured filesystems to a specific Tier of storage. The ImageServer will store incoming studies to the available filesystems configured for Tier 1 with preference given to the filesystem with the most free space available.
The ImageServer software can function with a single tier of storage configured, or with multiple tiers of storage. Studies will be migrated to lower level tiers automatically when watermarks are reached. Note that with some storage systems, the lowest tier of storage is typically an archive. With the ImageServer software, however, the lowest tier is still a standard filesystem. Archiving with the ImageServer software is treated separately from online storage of studies.
The filesystems are shared among the Server Partitions configured. The ImageServer automatically creates a folder in the filesystem to store each partition's data to keep its data separated from other partitions.
See the Server Filesystems section for more details on filesystems.
WorkQueue
The WorkQueue is the core processing engine of the ImageServer. Almost all processing done by the ImageServer is done through the WorkQueue. The WorkQueue is extensible, and uses the ClearCanvas Framework plugin mechanism for adding new processors. The WorkQueue mechanism has been developed to run across multiple servers within a cluster.
The ImageServer has a scheduling mechanism for WorkQueue items that favors the initial processing of studies over other WorkQueue items. The WorkQueue also monitors the current memory available on the system and attempts to keep a minimum amount of memory available.
See the Work Queue section for more details on the WorkQueue.
Study Integrity Queue
The Study Integrity Queue is a Quality Assurance (QA) related function of the ImageServer to ensure consistency of data within a study. Currently, two types of entries are contained in the study integrity queue, which are dependent on the configuration on the system. First, a Partition can be configured to to validate that several DICOM tags within a study are consistent across all the images within a study. When inconsistencies are found, the study is placed in the Study Integrity Queue. The second type of entry is for duplicate images received. When configured, the ImageServer will compare the contents of duplicate images received, and place entries in the study integrity queue for the study if the images are different.
For both types of Study Integrity Queue entries, the user is allowed several choices to reconcile the study. The incorrect images can simply be discarded, the study can be overwritten, or the study can be updated to reflect the chosen demographics.
See the Study Integrity Queue section for further details.
Service Scheduling
The ImageServer has a number of services that periodically run. The Service Scheduling configuration page allows for enabling and configuration of these services. The current Service Scheduling entries are linked to specific filesystems on the system. Some entries are enabled by default and periodically run. These are typically for performing disk management and for controlling when studies are compressed.
There are also Service Scheduling entries for services that run one time and disable themselves. These are related to reinventorying a filesystem, reapplying the rules engine to studies, and rebuilding the Study XML file created for each study.
Finally, there are also services that are typically associated with a single filesystem. These are used for archiving of the application log, archiving alerts messages, and configuring an import folder where images can be dragged to and automatically added to the ImageServer.
See the Service Scheduling section for further details.
Server Rules
The ImageServer makes extensive usage of a sophisticated rules engine. The rules engine allows testing of logical conditions against DICOM tags encoded within the header of a DICOM file. Each rule has a specific type associated with it and a time when it is applied. The rules are typically applied when a study is initially processed by the server, when individual images are processed by the server, after studies have been archived, or when they have been restored back to an online state from an archive.
See the Rules Engine section for further details.
Archiving
The ImageServer has an extensible interface for handling archiving of studies for long term storage. The only currently supported archiving mechanism is a hierarchical storage management (HSM) style archive. An HSM archive abstracts away archival media devices such as tape jukeboxes into a filesystem where files can be copied to and from. Common HSM archive software packages are the Sun StorageTek Storage Archive Manager and the EMC DiskXtender. Because the HSM archive expects to be working with HSM style archives, it was not designed to handle the case where the filesystem configured for the archive fills up.
ImageServer archives are associated with each partition configured on the ImageServer. Archiving of studies works in conjunction with disk management. Studies that are not scheduled for deletion are archived. Because archiving is associated with server partitions, it is possible to create different configurations for each server partition.
See the Archive Support section for further details.
Archiving vs Temporary Cache
By default, the ImageServer is configured to be a temporary cache. A rule is setup to delete all studies on the system by default, and no archives are configured. By removing the default rule for deletion, and configuring an archive, the ImageServer will function in archive mode.
The ImageServer can also function in a mixed mode where some studies are archived, and others deleted. This can be accomplished through the rules engine. The default rule for deletion can be removed, and replaced by a rule to delete only the configured studies.
Clustering
The ImageServer software has been designed to support clustering of servers. The ShredHostService and web server can be installed on multiple servers within a cluster to spread the processing load of the ImageServer.