The following information is per each server. Customers will need to create two (2) identical systems based on the following specifications for redundancy, one for the Primary and another for the Stand-by Secondary server.
Virtual Machines - The requirements are identical. Please be prepared to provide equivalent number of cores allocated and block storage for OS and SQL partitions. You are welcome to start with smaller configuration and tune up to higher performance as the need grows, however please be mindful that Imorgon is a "bursting" application therefore it requires peak performance when images are requested, queried from the database and image compression or decompression operations are performed. Therefore it is not wise to place Imorgon on an over-subscribed hosting nodes.
(1) Imorgon servers will only operate on 64-bit architecture using Microsoft Windows 2008 Standard Edition and Microsoft SQL Server 2008 starting 2010. Enterprise and Datacenter Editions are also acceptable but in general that's an "over-kill" for this purpose only.
(2) Servers are in 64-bit architecture is in place, Imorgon may require more memory for improved performance.
(3) If you have an external iSCSI or SAN configuration, R:, S:, and T: drives may be served up by those since the SQL Server requires BLOCK I/O device. Block storage is normally abstracted by a file system or database management system (DBMS) for use by applications and end users. The physical or logical volumes accessed via block I/O may be devices internal to a server, directly attached via SCSI or Fibre Channel, or distant devices accessed via a storage area network (SAN) using a protocol such as iSCSI, or AoE. DBMSes often use their own block I/O for improved performance and recoverability as compared to layering the DBMS on top of a file system.
(4) Backup space can be SAN, Removable USB2 Drive, or Windows Share from a Network Storage Device/File Server. However, for this to work, all systems must be on a domain and all of the Imorgon services should run on a service account within the domain.
(5) 400 GB is the size of commonly available LTO or DLT drive, therefore by partitioning each drive this way, the entire partition can fit in one tape if you are using tapes. Customer may partition these in any size. It may be served up by the SAN or Windows Share. Instead of drive letters, they can be mounted as Windows "Mount Points"
(6) Imorgon will install and configure the SQL Database as well as partition the drives. Please have the install media ready on the day of installation. Our system will be utilizing SQL Server 2012 in mid 2012. Until then we will purchase the 2012 licenses and then opt to downgrade to 2008 R2.
(7) Customers are expected to purchase Device Specific CAL per Imorgon Workstation from Microsoft. This is a legal document between Microsoft and the customer and it is a responsibility of the customer to be compliant. For more information about this, please look at this URL: http://blogs.msdn.com/sqlblog/archive/2006/11/10/tracking-license-information-in-sql-2005.aspx
(8) We have experience using Virtual Machines from VMware and Microsoft Hyper-V, however due to the CPU power and Disk Space requirements the Imorgon Servers will require you to prepare a hefty and undersubscribed machines to implement this.
Inadequate and incorrectly implemented VMs will almost certainly cause a severe performance and reliability issue when inexpensive dedicated CPUs could have prevented these issues. If you currently do not have an in-house expertise in VMs, we suggest you do not implement the VM based solution at this time because performance issues are very difficult to diagnose.
Almost all modern (deployed or updated in since 2008 or so) storages and SANs are totally acceptable for use in Imorgon.
For SQL Data and Logs partitions we recommend that high quality SAS based RAID implementation sustaining more than 6 Gb/sec , a minimum of 80 IOPs rating the RAID Controller and the Host Bus Adaptor is recommended. Or a local set of RAID combined with a mid-grade or better RAID controller.
For Image Data storage, we can tolerate a less performance RAID implementation, for example disks consisting of 7200 RPM SATA drives are really fine especially if the bandwidth is aggregated in a minimum of a RAID-5 set with a minimum of 80 IOPs and > 6 Gb/s performance can be achieved easily with RAID-5 or better configuration.
Windows compatible Network Attached Storage in Image Storage can also be utilized, however, this will cause more performance degradation. If such arrangements must be made then we highly recommend that NASs to be hosted on a second Gigabit Ethernet network separate from the imaging network to reduce network contentions.
The RAID configuration afford us to be able to lose a disk or even two at the same time.
If none of this makes sense to you, please think of it this way. If you have a BBQ party with a number of people and you know given the number of guests, you know that normally up to a party consisting of up to 10 guests, someone is very likely drop 1 jar of mayonaise, and if you have 12 guests, you have had an experience that there were several times that you've lost 2 jars of mayonaise.
So, likewise, we recommend that up to 10 guests we reserve 1 jar of mayonaise as a "just in case spare" and if we have any more than that, for every 12 guests we buy 12 jars but reserve 2 jars. In this case, at the worst case, you know you have enough in your pantry to go through the night.
Please also note that in this analogy, any bottle you purchased can be dropped. In other words, it can be the bottle close to the edge of a table, the one in the middle or one next to it. Likewise, any one of the disks can fail and the party can go on, a sophisticated electronics will know which one of the jar was dropped and will take care of it automatically.
All your servers must bear an official name on your Domain Name Server so that servers can be configured using the network name rather than raw IP addresses. This is more important when you are mirroing servers using the SQL, as the SQL Mirroring technology requires a Fully Qualified Domain Name for example, IMORGON1.PACS.STELSEHS.ORG as a the name. Most customers have some host naming convention. Please free free to use your own convention, however an underscore (_) is not permitted as an official Internet DNS name therefore do not use the underscore. The DNS standard does permit a use of a dash (-).
Your Imorgon Server computers must be joined to your Windows Active Directory (AD) domain in order for the SQL Server Mirroring to work. There are also suggested accounts tied to your domain. Your domain can be sub-domained for the purpose of providing security for Imorgon servers. AD is sometimes called LDAP by some IT administrators, however in our situation the full standard Active Directory support must be provided by the LDAP system of your choice.
Imorgon does not require domain user accounts for technical support purposes, but it is also recommended.
(C) Imorgon Medical, LLC. 2013. For the sole use by Imorgon customers. Reviewed 9 August 2013