'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:
http://www.channelweb.com/sections/Resources/Newsletters/
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:
http://www.varbusiness.com/sections/technology/tech.asp?ArticleID=42063