In this interview, SearchStorage.co.UK bureau chief Antony Adshead speaks with Steve Pinder, principal consultant at GlassHouse Technologies (UK), about completing the first SAN implementation in your data storage infrastructure. Pinder discusses SAN fabric topologies, the key planning stages of a SAN deployment and common pitfalls to watch out for to ensure a successful implementation.
You can read the interview below or download the MP3 file.
You must have Adobe Flash Player 7 or above to view this content.See http://www.adobe.com/products/flashplayer to download now.
Download for later:
SAN technology: A guide to SAN installation
• Internet Explorer: Right Click > Save Target As
• Firefox: Right Click > Save Link As
Pinder: Firstly, it's critical to understand the business drivers behind the implementation of the SAN. Is the reason organic growth or has there been a recent merger or acquisition? You must also take into account whether some or all of the current server estate is due to be refreshed, or whether it will be migrated to the new SAN.
In most cases, the business drivers will cause the decision to implement a SAN, after which the following stages should take place. Understand what the SAN will contain. Will it be for mission-critical hosts only or will there be a variety of hosts aligned to performance and capacity?
This decision will help to size the SAN correctly, minimising waste and future issues. If a large SAN is implemented and a small number of hosts are attached, this could be a waste of money. Whereas if a smaller SAN than required is implemented it could run out of capacity quickly and cause a costly reconfiguration expense.
It's also necessary to decide if redundant fabrics are needed, how data on the SAN will be backed up and what classes of storage are needed. Each of these points needs to be dealt with so the correct hardware and software budgets can be signed off.
The next stage of the process is to decide whether you want to implement the solution yourself or invite third parties to carry out some or all of the work for you. A small-scale SAN with one or two switches is not immensely complex, but once you increase the number of ports beyond a certain level it's wise to get external advice.
What also needs to be understood is the amount of time your IT department can devote to the project. If the implementation is complex, it may require large chunks of IT time and this could be to the detriment of other key projects.
Once roles have been decided, a tender process would normally take place. This involves inviting vendors to propose a solution to fulfill the requirements provided and give appropriate costs for the implementation. Responses can then be analysed and the most appropriate taken forward. Allocation of work between the customer and vendor will then take place and the installation will commence.
The first phase will probably be a pilot followed by a full-scale rollout. During the SAN installation, new hosts and services will be built and commissioned. For hosts and services that need transferring to the new SAN, the migration schedule will need to be created and the necessary downtime needs to be negotiated for the services they provide. Further hosts will be implemented according to the project plan until its completion and sign-off.
SearchStorage.co.UK: What are the main pitfalls in a SAN installation to watch out for and how can you ensure the process goes as smoothly as possible?
Pinder: Unless your implementation is very small or you are an experienced SAN professional, it's highly recommended to get some professional advice to help with your SAN rollout. This can range from a simple assessment to a full implementation service, and will almost always prove to be good value for money and help prevent any pitfalls from becoming a reality.
My advice would be to ensure you have answers to the following five items:
Is my SAN sized correctly? Director-class switches are much more expensive than edge switches but can enable a SAN implementation of 1,000 or more ports. They can also be purchased with a limited number of ports initially, which can be increased at a later date. Edge switches are cheaper but are not expandable, and an increased port requirement in the future could lead to contention and delays along inter-switch links and badly aligned storage.
Secondly, you should assign service levels to hosts. Not all hosts need the same service levels, and it's a waste of money to assign low priority hosts to enterprise-class storage. All hosts connecting to a SAN should be allocated to a class of service and should be attached to the infrastructure that provides that service level. For example, it's pointless wasting an extra host bus adapter and SAN port dual-pathing a host when no one will notice if it's down for a week.
Thirdly, do the storage arrays have the required performance levels? All arrays have maximum capacity service levels and it's important to aggregate hosts across these arrays so that one limit isn't reached far before the other. If an array has reached its performance limit, yet has many terabytes of free storage, this is obviously a waste of money.
Fourthly, ensure a backup plan is in place. When there's no SAN present, all backup traffic will traverse the LAN, and as the amount of backup traffic increases, this can lead to contention between backup traffic and network data. Implementing technologies that allow backup traffic to traverse the storage network instead of the LAN can remove this potential bottleneck and increase performance of the LAN.
Lastly, create standards and stick to them. Once a SAN grows beyond a certain point its administration can become difficult. It is therefore imperative to agree on naming conventions during the design phase and to ensure they are adhered to. Zone names on the fabric, host aliases on the switches and host groups on arrays should all remain consistent. If standards are not implemented administration becomes difficult and it's only a matter of time before an outage is caused.
This was first published in April 2010