When talking to storage companies and to end users, I see an almost religious war going on between those who want...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
to have disk and tape on separate SANs and those who want them together. What are the real arguments?
Let us start off with some simple assumptions:
1) You are implementing SAN-based disk arrays
2) You are implementing SAN-based backup
3) These are for the same end-user
So do we put the disk and the tape on the same fabric?
Let's first clear a few things up:
Disk and tape can live happily on the same fabric with no problems whatsoever and have been able to do so for several years.
A server can talk happily to disk and tape through the same HBA with no problems whatsoever and have been able to do so for several years.
Now let's look at what advice you get from the OEMs. I suspect if you talk to an OEM who primarily sells tape solutions, or primarily sells disk solutions, you will be told to use seperate SANs. On the other hand, if you talk to an OEM that does both, or concentrates on the servers, you are more likely to be told that you can do both together.
Why is this?
Fibre channel is evolving. While you can implement very stable and reliable solutions that drive great business benefits, this does tend to mean that the end-to-end testing -- from the OS and application to the blocks of data on the tape or disk -- is still very important. Do not ignore qualification testing.
Suddenly, it becomes clear that it is easy to find a qualified end-to-end tape SAN solution or disk solution. But mix them and permutations expand greatly, making it easier to stray into unsupported territory.
From an OEM perspective, it can therefore be easier to keep disk and tape SANs separate as it simplifies support.
From an end-user perspective, it can also be easier to keep them separate as you can then go to one OEM for the disk solution and another for the tape solution -- hopefully getting the same SAN switches from both.
It also means each SAN is smaller and simpler. Also, in many cases for the end-user, the disk and tape teams are very separate teams.
So why would I ever want to have a merged disk/tape SAN?
First, what I have just said is actually not so simple. Having separate disk and tape SANs may also mean that the different vendors are placing different requirements on you for which HBA, driver and OS patch you should have on your servers.
Second, if you are running in a campus environment or a multiple data center environment, you may have limited site-to-site connections, and so may want to share these for disk traffic and tape traffic.
Third, it is quite hard to do serverless backup if your disk and tape are on the same fabric!
As any good consultant will tell you, there is no one right, simple answer. My experience is that when talking to a customer, the right solution for that specific customer soon becomes clear.
Usually, certain aspects of the IT strategy of a company, such as support mechanisms and purchasing policy, will drive the solution clearly to merged disk and tape SAN or to separate tape and disk SAN.
The important thing, though, is to have the discussion. That way, the customer understands the pros and cons of each solution (I have not covered them all) and makes a decision based upon their business needs.
About the author:
About the author: Simon Gordon is a senior solution architect for McDATA based in the UK. Simon has been working as a European expert in storage networking technology for more than 5 years. He specializes in distance solutions and business continuity. Simon has been working in the IT industry for more than 20 years in a variety or technologies and business sectors including software development, systems integration, Unix and open systems, Microsoft infrastructure design as well as storage networking. He is also a contributor to and presenter for the SNIA IP-Storage Forum in Europe.