The Hitachi Adaptable Modular Storage models 1000, 500, and 200 deliver the best price/performance, availability and best-in-class scalability in the modular storage market space! Leveraging many high-end features such as cache partitioning and RAID-6, the Adaptable Modular Storage systems are easily managed by Hitachi’s Storage Navigator Modular software. These systems are ideal for any small, midsized or larger businesses that requiring high-availability and high-performance solutions.

Adaptable Modular Storage 1000: With up to 450 disk drives and the ability to virtually connect to a maximum of 1,024 servers, this model delivers enterprise-class performance and capacity at a mid-range price. The 1000 is ideal for larger companies.

Adaptable Modular Storage 500: This model is the solution for mid-sized companies that need tiered storage in a single rack. Mix up to 225 fibre channel and SATA hard drives to store data for both high performance applications and near-line or back up applications.

Adaptable Modular Storage 200: This entry level model is ideal for small business or branch offices. Configurations scale from 4 to 105 hard drives. The 200 is a great choice for companies or departments that are implementing their first storage area network (SAN).
Features

Flexibility
* Upgradeable, data-in-place growth from Adaptable Modular Storage 200 to 500 to 1000 models
* Multi-protocol support for consolidating storage between two types of server interfaces:
o Adaptable Modular Storage 1000 models have dual protocol support for Fibre Channel and iSCSI host connections
o Adaptable Modular Storage 200 and 500 models have dual protocol support for Fibre Channel and iSCSI host connections
* Vertical scaling allows LUNs to span over multiple drive trays
* Scalable design to add capacity, connectivity and/or performance as needed
* Support for all major open systems operating systems as well as host bus adapter and switch models combinations from major vendors

Availability
* No single point-of-failure, all dual-controller models fully redundant
* Major components hot-swappable
* Battery back-up for cache
* Non-disruptive microcode updates
* Host failover with HiCommand Dynamic Link Manager software
* Multipathing support for Windows (MPIO) and Solaris (MPxIO)
* Supports in-system volume backups and snapshots
* Remote site replication (AMS500 and AMS1000)
* Supports RAID-6 dual parity for highest reliability
* RAID-5, RAID-1 and RAID-1+0 and RAID 0 also supported
* Hi-Track® “call home” service/remote maintenance tool

High Performance
* Cache partitioning to optimize application performance
* Allows up to 1024 virtual ports with Host Storage Domains and 4096 LUNs for concurrent support of large heterogeneous open systems environments
* 4Gbit/sec host Fibre Channel connections
* Four fibre channel loops per drive tray to ensure maximum bandwidth

Simplicity
* Includes easy-to-use utilities for configuration and management
* Integrates seamlessly with Hitachi storage systems, managed with a single set of tools using HiCommand Suite software
* Virtually all Hitachi software products run identically on Hitachi modular models and on Hitachi enterprise storage system
* Supports Plug-and-play SAN Kits compatible with Microsoft Simple SAN

Security
* Role based access to Adaptable Modular Storage management systems
* Audit logging keeps track of all system changes

Ideal Applications

* Storage consolidation or storage area network (SAN)
* Primary storage for small or medium sized businesses and branch offices
* Lower tiered storage for large enterprises when used with an Hitachi Universal Storage Platform V™ or Universal Storage Platform VM
* Business Continuity Solutions
* Microsoft environments
* ERP/CRM
* Databases

Benefits

Tiered Storage in a Single Rack
* Intermix Fibre Channel disk drives for high performance with SATA disk drives for lower cost bulk storage in the same system
* Non-disruptively migrate data within the system and without using host resources
o Move data between tiers of storage
o Move data to match drive types with performance requirements
o Move data between RAID groups to balance workloads
* Serves as backend storage for the Hitachi Universal Storage Platform ™ V or Universal Storage Platform VM

Eco-friendly solutions
* Power Savings option that spins down unused or infrequently used RAID groups
* Volume migration to 1000GB, 7200rpm SATA hard drives that provide the lowest energy consumption per GB
* All models are RoHS compliant

HDS: Storage Systems> Adaptable Modular Storage (AMS), AMS1000, AMS500, AMS200.

Bookmark to:
         

Complicating matters somewhat is that we are simultaneously deploying VMWare’s ESX solution for our non PACS servers, which requires hardware as well. Not to mention, our internal/external network needs to be modernized at the same time.

The issue that was most contentious for us was that of which SAN to purchase, and how to spec it out. We ended up going with Hitachi/HDS AMS500, but it was far from our initial choice. A while back, I came across Compellent. To a SAN newbie like myself, they seemed to have a solid, easy to use product. However, it was decided that we wanted to go with a more established vendor. HP’s EVA line was ruled out as not quite robust enough for us. IBM’s DS4700 was a strong contender, although Initially far more expensive than the others. We also looked at EMC’s CX3 line. In the end, the EMC was the most expensive of the bunch, and IBM and HDS were similarly priced. The AMS500 won out due to its support of RAID 6, something that we desired to keep our PACS images as safe as possible.

Given we are going with 10K/300GB drives, there was some fear that if one drive fails, during the lengthy rebuild process, we would be susceptible to complete failure if a second drive failed. RAID 6, with its second parity drive, alleviates those concerns.

Now that the bulk of the hardware seems to be taken care of, pending Intelerad approval, we can focus on the software integration piece of the puzzle.

Bookmark to:
         

Bookmark to:
         

After much investigation, we chose to use 5U AIC server chassis as a basis for a Windows based storage system, with the ability to hold 48 hard drives. We looked at NAS units and fibre channel storage systems, but both got prohibitively expensive once we moved beyond the 5TB storage mark. Actually, NAS got expensive as we stored more, fibre channel was just expensive period. The AIC units (we got two, for redundancy) will allow us to add space via inexpensive SATA drives, up to 22.5TB as currently configured with 500GB drives. We do not need that much space quite yet, but when we do, it is available to us. Also, we reasoned that the money we saved going with these units now, compared to a fibre channel solution, could perhaps pay for a fair chunk of a FC solution in a few years if we require the speed and versatility it would provide.

With the hardware in place, I had to devise a way of duplicating the data from each of our 8 clinics onto these storage boxes. If all we were after was a long term backup of the DICOM files themselves, it would have been one thing, but we also wanted to use this backup as a means of consolidating our files, and allowing lookups against them. After all, each local clinic would be purging data, and still wanted quick access to those purged patients.

I looked at Conquest’s data mirroring feature (MIRRORDevices), but it was not really what we were after. It was more of a data redundancy feature, not geared towards long term storage, our local drive system would still be a limiting factor. Conquest also had the NightlyMoveTarget feature, but again, this only partly met our requirements. This would allow us to grow beyond the local storage system limitations, but would still require redundancy, and would not allow the consolidation of online data that we wanted.

It was decided to simply set up a Conquest server on the AIC box, and have each clinic forward images to it. For sake of ease of management, this was altered somewhat, and we ran multiple Conquest server instances, one for each clinic. This way I could keep data separate, which aids in some troubleshooting. Also, it allowed me to compare image counts directly, so if the numbers matched on both the original and backup server, everything was duplicated. Had we gone with a single server, there would be no easy way to do a count and know that ClinicA was fully duplicated on the backup server.

The game plan was that once studies were purged at each clinic, they would be able to click on the backup server in eFilm to request needed studies. But as we had created multiple backup servers, this would be a pain for users. Plus, it would require them to know which clinic a study was performed at. At about this time, a new version of Conquest was released, with the VirtualServerFor feature. With this, we set up one additional server instance on the backup server, which was a virtual server for the other 7 servers. This way, a user only had to select this one server, and they would get all images from any clinic with no time limitation. From a user perspective, this has been a success. They love this ability, even if it is slower then pulling images from the local server (we are still stuck with slow WAN VPN links).

At first, this method seemed fine. However, I found myself spending an increasing amount of time at the end of each month verifying that images from each clinic server were on the corresponding backup Conquest instance. And if they were not, then identifying which were missing and copying them over manually. My process I was following was:
– On each clinic server, and each backup server instance, from the Query / Move tab of Conquest, I would do a IMAGE query level search for the month that was ending (200610* for example). I would then wait for it to do the count.
– When a backup server and clinic server did not match, I would then run the FIND LOCAL MISSING PATIENTS command for the month, from the backup server instance of a clinic, with the DICOM SYSTEM being the appropriate clinic. After some time, this would return a result. Then I would have to tell it to copy those images over, which again took time.
– Repeat!

Considering that I had 7 clinics to worry about, this was just too time intensive. I had to do it on each clinic server (7), then on the main backup server (7 more times), and finally on the backup backup server (yet another 7 times). Repeating the step a minimum of 21 times was just too much. There had to be a better way.

Not being familiar with SQL, I decided now might be the time to dabble in it. After getting up to speed, and with much trial and error, I devised a solution I am quite proud of. What I was after was a quicker way of doing this, one that was as automated as possible. This is what I came up with:

– A batch file process that would, using a SQL script, do an image count for a specified period, and log it to a file.

– A SQL script that would take input from the batch file (server, date range) and run the count, logging to a file.

– A second batch file process that would, using the DGATE.exe -g command line option, grab any missing images automatically.

Once I had the framework in place, I utilized our systems monitoring software, Hostmonitor to run the script to do the image counts. It is also used to compare the resulting log files, and if needed, starts the process to copy missing images over. As an aside, I highly recommend Hostmonitor. It is not the most graphical of tools, but it is extremely flexible and adaptable. The longer I use it, the more I realize I can be done with it. Best of all, it is very affordable. Perhaps I will discuss it more in a future post.

The result should be a nearly hands off solution. I just got done the final tweaking this past weekend, so it is still early, but the first couple of days with it show promise. If there is interest, I can certainly share the batch files, where most of the magic happens. Some of the features of the batch files include:
– Parsing the date into variables.
– Doing math to determine end of month automatically.
– Parsing the SQL output file to strip out excess data and read the numeric result as a variable to be manipulated.

Bookmark to:
         

Bookmark to: