Web Informant #330, 19 May 2003: Sam's SAN Diary


'This week we hear from a long-time colleague of mine Sam Blumenstyk. He is the technology operations manager at Schulte Roth & Zabel, a Manhattan law firm. Blumenstyk is in the midst of a major upgrade to his company's storage infrastructure, and is about to build his first storage-area network (SAN). I asked him to keep a diary of the trials and tribulations, and he has graciously agreed to share this with you.


As a special to my Web Informant readers, I will send out his first entry today. If you want to get subsequent entries and follow his progress through the world of SANs, you'll have to subscribe to a new newsletter that I am editing at VARBbusiness.com called Technology Advisor. You can check it out here, along with our other fine newsletters such as one devoted to government solutions providers:



Once you subscribe to Tech Advisor, you'll hear from Sam each Tuesday about how he assembles his solution, which vendors he favors, how he decides between using VARs or direct-vendor reps at various stages of the project, and the ups and downs of implementing the storage technology. Sam's diary is also a great way to understand the storage marketplace as well as some of the challenges that customers have to overcome to install their first SAN. Take it away, Sam.


I have been with Schulte Roth & Zabel for less than a year, originally tasked with a project to evaluate our disaster-recovery needs. But now I am deep into my first SAN. Even though I have designed numerous server rooms and enterprise networks and have implemented a variety of storage solutions for prior employers and consulting clients, I had no expertise in SANs when I started with the firm. 


I supervise a basic offsite tape rotation operation that covers backups of all of our critical data. I have a staff of plus, plus there's also a tech analyst. My boss, the company's IT director, had begun working on an offsite data-recovery plan before I came on board and had come to the conclusion that a replicated data solution was needed. But a tape-recovery solution would have taken longer for us to get back online. It would be risky as well: What happens if a critical tape isn't readable when it was needed? So began the path down to my first SAN.


We are a Windows-only shop with about 700 desktops and 30 servers, holding about 3 TB of data capacity with half of that already filled. What makes our storage situation somewhat unique is that our clients can bring in a terabyte of data (or more) on one particular case. Law firms these days do a lot of electronic discovery, where a legal team has to sift through millions of electronic documents, and all of that has to be stored someplace on my network. These huge storage needs are happening more and more these days.


IBM and Sungard, as well as smaller, regional firms we had been in contact with, had recommended a host-based replication solution from NSI Software called Double Take. It was relatively mature and worked by installing special drivers to track file input/output changes. So we wrote up a 10-page RFP for our disaster-recovery solution. We included specifics on storage-array controller-based replication solutions, along with a back-to-operation time of between four and 12 hours and specs for data-loss tolerance.


We distributed 20 RFPs -- mainly to solution providers -- and about 15 firms responded, of which 10 actually responded to what we asked for. We followed up with about six of the most promising, asking them to come in to meet with us to better understand their proposed solution and pricing. We were clear that this first set of meetings was to determine a general approach so that we could properly budget to implement the disaster-recovery solution during the next year.


A number of solution providers suggested a SAN as part of the solution, which ranged from hundreds of thousands of dollars to millions of dollars. Those included solution providers that proposed our direct-attached storage could be used with host-based replication to a SAN at their facility. Options were presented based both on purchasing a SAN for the disaster-recovery side and for connecting our servers to a multiclient SAN run by the disaster-recovery vendor. There were also solution providers that thought we should implement a SAN at both ends (meaning our offices and the offsite disaster-recovery location) to allow for SAN-based replication. That were more expensive, but offered a much shorter back-to-operation time. A SAN-based replication investment was relatively common in the financial trading industry prevalent in Manhattan, both for regulatory and business needs.


I don't want to give you the impression that our SAN needs were all based around disaster-recovery planning. I mentioned earlier our needs to support our litigation storage requirements. We also had a growing data challenge with Microsoft's Exchange 2000 servers requiring more storage to support mail-retention applications and specialized archiving products that are designed around the legal industry. We were in the process of rebuilding several of these servers, redistributing the storage of our mail files, and realized that a SAN would save our IT staff a lot of time. 


This was last October, and we realized this was not a project that would be completed quickly. In December, we considered implementing a tactical solution of a low-end SAN to provide some relief on our storage needs and to get our feet wet with a SAN before we rolled out the full disaster-recovery-based solution. We used Manchester Equipment, a local Hauppauge, N.Y.-based VAR, that we have been dealing with for some time, for the project.  


Thanks, Sam. Check out more of his diary entries here on VARBusiness' web site: