SAN: A user's tale

I thought I'd continue with the storage legend theme that I introduced last week, and today examine the myth of "build a storage area network and consolidated storage will come." Although all the characters in the articles are fictionalized the events are drawn from both my own experiences (yes, I made these mistakes too) and the experiences of the many customers I have worked with. Any similarities to actual people are coincidental.

Let's look at the myth that building a SAN infrastructure automatically provides all the benefits that you were sold on, such as high performance, centralized storage management, greater disk utilization, faster backups and higher data availability.

The story begins in a prominent financial institution's data center meeting room. The company has just finalized another merger and IT has been set the task of consolidating infrastructure functions across the enterprise. IT management has called together the responsible personnel to discuss the plan to move forward. The CIO has made the decision to implement a SAN, hoping to ease some of the difficulties prevalent in merged environments.

Off go the troops to implement this new SAN, flushed with excitement for the possibilities this infrastructure promises. Sandy, an experienced system administrator is given the task of configuring a SAN island to support the customer relationship management database application (CRM). Sandy was fortunate because the CRM database could be brought down on the weekends. Many of Sandy's colleagues were not so lucky.

Sandy's company had always used EMC Symmetrix storage for its high-availability applications and the other company used IBM Shark storage. Sandy worked to attach both the storage subsystems to the SAN, create redundant paths for reliability and get the application servers back up and running. The storage was now on the SAN and data was being accessed by the applications.

However, this configuration was logically no different than when the storage was directly attached to the servers. Sandy had created a glorified direct-attach SAN. Yes, there were host bus adapters in the servers with switches and Fibre Channel interconnecting the storage, but there was no sharing of either the data paths or the storage in this first SAN implementation. There were still two CRM applications and two separate storage subsystems to maintain, plus a whole new infrastructure to manage, all with different management interfaces.

Sandy started to ask questions: How can I use the SAN to consolidate the CRM applications and servers as well as data? Again, Sandy was lucky as the CRM applications were the same. Consolidation of the applications, servers and data simply required exporting one CRM database and importing it into the other.

Now Sandy was faced with the next question: Which of these high-ticket subsystems to use? The Symmetrix storage was currently about 40 per cent used and adding the other CRM data would overrun the current Symmetrix storage. It seemed silly to buy more Symmetrix storage when they had this perfectly good Shark sitting there. Could they use both? How would they manage both in a consistent fashion?

Remote mirrors were created using EMC's Symmetrix Remote Data Facility (SRDF) on the Symmetrix, Sandy couldn't use SRDF on the Shark. How was Sandy going to gain the benefits of both these high-ticket storage subsystems as well as consolidate the management of both with a consistent interface?

As you can see, the mere implementation of a SAN does not guarantee a consolidated, shared-storage management environment. Starting with a storage strategy then pulling together prioritized tactical plans to implement the storage strategy is the starting point. As the software technology evolves, the implementation of these types of scenarios will become much easier. In this story, Sandy took the first step in laying the foundation for the future.

Join the newsletter!

Error: Please check your email address.

More about EMC CorporationIBM AustraliaIslandSymmetrix

Show Comments

Market Place