In my previous posts I’ve discussed how to rack and stack your Isilon and how to get it powered up and running. With the Isilon systems operational it was time to put them into production and start the PACS data migration to Isilon. Which is actually easier than you might think!

The PACS environment

Our PACS environment that is going to push images to the Isilon systems is AGFA IMPAX 6. Data was initially stored on an old EMC CX3 system that needed to be replaced ASAP.

PACS data can be split roughly in two categories: cache storing recently queried/produced images and an archive that makes up the long term storage. New scans are pushed from the scanner into IMPAX and stored on cache for fast retrieval. These new scans are also duplicated to the archive, typically at the end of the work day.

The caches work on a spill and fill principle: oldest data is pushed out, typically after 6-12 months. Once this happens for a particular scan it is no longer stored twice (cache + archive) but only stored in the archive. Next time the medical staff wants to view it, It will have to be retrieved from the archive into cache before it can be used.

During design sessions with the PACS vendor we’ve decided to keep the cache on VNX storage and let Isilon take care of the archive storage. Cache is fixed in size and only ever needs to grow if the “online retention” drops below a usable number. This happens when the radiology department starts to scan more and/or use higher resolution images. The archive will always and continuously grow: no scans are thrown away, EVER. This means we needed archive storage that could scale easily, wouldn’t leave us with a big migration at the end of the depreciation period and would also protect the data.

Two types of PACS data migration

Migrating the cache files was pretty easy. Its a couple of LUNs stored on an EMC CX3 and they are going to an EMC VNX. Enter PowerPath Migration Enabler a couple of hours/days later you’re done!

Migrating the archive was a bit more tricky. We’re coming from a 25TB (Meta)LUN on the CX3 and going to an SMB share for phase 1. Once that’s done AGFA will come in and start phase 2 which is converting all the data to a different (IDC) format and storing it on NFS shares. I can’t use PowerPath Migration Enabler, SAN Copy, MirrorView; I’ll have to use a host based migration tool that works on the file system or individual file level. Here comes trusty old RoboCopy!

I initially created the folder and SMB share on the Isilon system, assigned the appropriate rights and mounted in on the server that now hosted the archive. Next up is starting the actual PACS data migration and copying the archive over. I used RoboCopy with the following syntax:

robocopy.exe <src> <target> /S /E /COPY:DAT /PURGE /NP /R:0 /W:0 /MOT:240 /LOG:<logfile>

In hindsight I could have condensed that down to:

robocopy.exe <src> <target> /MIR /COPY:DAT /NP /R:0 /W:0 /MOT:240 /LOG:<logfile>

• /MIR to mirror the entire directory tree: if you delete something on the source it’s also deleted on the target. This replaces the /E and /PURGE option. The /S was redundant in my command anyway since /E includes /S.
• /COPY:DAT to only copy the data, attributes and timestamps. The data needs to get the new access permissions as configured on the Isilon, so I ommitted the SOU flags.
• /NP so that the logfile isn’t spammed with progress indicators. The 25TB is spanned across an immense amount of files. During the first two days of copying this generated an insane amount of log entries (almost a GB). /NP cleans this up.
• /R:0 /W:0 to disable retries and the wait-time. If it fails I want to know about it.
• /MOT:240 to restart the copy job after 4 hours. I don’t want to lag behind too much; RoboCopy needs to keep the target sort of up to date until we want to do the cutover.
• /LOG:<logfile> to log to file instead of console.

Check your logfile thoroughly for errors and warnings. Initially I tried copying the security info of the original files along onto the Isilon but that didn’t work too well. Changing the copy mode from /COPY:DATSOU to /COPY:DAT solved the problem and didn’t break the target files.

Afterwards it was a matter of shutting down the archive function of IMPAX briefly, reconfiguring it to point to the new share, copying the last couple of files that are still in the old location over to the new location and restarting the archive functionality. Pay special attention to credentials: you may have to reconfigure IMPAX and/or the Isilon to allow secure communications.

Add some post checks to make sure data is sent and retrieved correctly (push some new scans to the archive and retrieve some ancient scans that are no longer stored in cache) and you’re done!