UNIX to Windows

1. UNIX to Windows

2. Instructor Mikael Taube Director, System Engineering Mikael.Taube@sectra.com

3. Objective • Introduce the UNIX to Windows project • Give a starting point for the project

4. Sectra PACS on Windows • As of R7.1 the Sectra PACS has been available on the Windows platform • Support for various features have been added over the years (HA, operating systems, virtualization) • Same code base for WISE as on UNIX • Our Windows environment have the same uptime and availability as the UNIX environment. • More horsepower at a lower pricepoint • Already partially Windows only

5. Preparing the project • Oracle and SQL have different ideas about case sensitiveness • MRN Sectra123 and SECTRA123 is considered different in Oracle but SQL server consider them to be identical. • Acc No have the same issue • Oracle and SQL have different ideas about dates • SQL server can’t represent dates prior to 1/1/1753 which Oracle have no problem doing Needs to be fixed/managed!

6. Preparing the project • Port number changes: • Privileged ports: 0-1023 (UNIX & Win) • Windows reserved (dynamic) ports • Windows 2003: 1024-5000 • Windows 2008: 49152-65535 • Varies with OS release! You can use netsh to find or change the range • Make sure your port numbers are in the allowable range! Importservers, Q/R, HL7 feeds, MWL etc. • Watch out for posibbly overlapping ports.

7. Preparing the project • Domain accounts • All Sectra related software needs to run as a domain User, typically DOMAIN\PACS_service, DOMAIN\SHDB1_Service_User • Current WEB servers often uses a local account for the healthcare servers • Easiest way is to redeploy the product using the correct account, instead of atempting to change the account manually

8. Preparing the project • New hardware and new operating system allows for changing the layouts and sizes. • Win 2k8 allows for large LUNs, up to 64Tb • No inode limits, possible to collapse basefolders • Time to clean up old, unused importservers, telerad destinations etc • Virtualization • External long term devices needs to be prepared • Mounting /fs volumes will change from NFS to CIFS.

9. The Project Three parts: • Copy local storage (Thumbnails, /s and /fs) • Copy configurations • Transfer databases

10. The project – copy local storage • Initial full copy of all storage • Typically robocopy is being used • Uses standard windows shares to copy • Runs typically for a substantial amount of time • Continous mirroring after initial copy • Typically robocopy is being used • Final run at cutover, during downtime • Note that final run will produce a perfectly consistent mirror filesystem

11. The project – copy configurations • Configurations differ slighly between UNIX and windows, and is also slightly different depending on versions (configurations are being moved into the database rather than being kept in files). • Main items to transfer is: • Import servers • Q/R configuration • Telerad • HL7 (vmd files etc are unchanged)

12. The project – transfer databases • Uses SSIS (the integration studio) during downtime • Three separate projects, WISE, SHdb, SDdb • All three can run concurrently • WISE and SHdb will take a considerable amount of time. Old ha system will be set up so that node 1 runs WISE and node 2 runs SHdb • No real load on the UNIX system generated, and the migrations can therefore be tested on a production system • Main load on the target windows system, mostly memory and disk I/O (typically transaction logs)

13. Testing Sectra will test and verify the migration process as to the best of our ability. This will be completed well ahead of cutover. Once Sectra has done testing, the system will be handed over to the customer for validation. The migration at this point will have some inconsistencies, due to the fact that it is a live system that has been transferred.

14. Common problems There is a huge number of moving parts for this type of a project, something is bound to have been missed. However, those things are typically small and easy to fix. • Telerad (changes in IP scheme) • Archiving (changes in layout) • External connections (new MAC) • General awarness that something major went on • Case sensitiveness • 3rd party integrations, url launches, IDS5web

15. Virtualizing the Sectra PACS

16. Supported platforms Currently only Vmware ESX is supported. • Versions supported: 4.1, 5.0, 5.1 • Licenses supported: Enterprise, Enterprise Plus. • Features supported: All • Sectra supports the abstracted HW layer, as long as it meets the performance requirements.

17. How to go virtual For Sectra, this is considered a HW refresh project where the customer provides the HW. • Sectra will provide a virtual appliance that can be deployed in the virtual environment. • Customer will provide: • OS license • SQL license • Overall infrastructure

18. Alternate approach If you already have a windows based system, and are on a later version of OS (win2008 or later), you can use Vmware converter to convert the physical server to a virtual, aka P2V.

19. How to design the system • Use one virtual server per function • SHdb and WISEdb on different virtual servers • Use Vmware clustering instead of failover clustering • Consider LUN restrictions • Datastore LUNs can only have a size of 2Tb • Pass-Through LUNs can be larger • Consider features to implement • Vmotion • Stretch cluster • Disaster recovery/BCS

21. What not to do • Overprovision the servers • Contention for resources can be very detremental to performance, and very difficult to troubleshoot • Overprovision the virtual servers • Contention for resorces • Use NFS mounted datastores