Tape Media

Tape Drives

Ethernet LTO Tape Drives

Tandberg Data RDX QuikStor

Tandberg Data RDX QuikStation

HP RDX Removable Disk

Quantum SuperLoader 3

Quantum Scalar i3 LTO

Qualstar LTO Tape Libraries

Qualstar Q8 Tape Autoloader

Qualstar Q24 Tape Autoloader

Qualstar Q48 Tape Autoloader

Qualstar Q40 Tape Library

Qualstar Q80 Tape Library

Qualstar Tape Libraries

Overland NEO Tape Libraries

Overland NEOs StorageLoader

Overland NEOs T24 Loader

Overland NEOs T48 Library

Overland NEOxl 40 Series

Overland NEOxl 80 Series

Tape Drive Autoloaders

HP StoreEver Tape Libraries

HP StoreEver MSL3040

Archiware P5 Software

XenData LTO Archive

Facilis Technology

SnapServer XSR NAS Series

Nexsan Storage

ATTO SAS / Thunderbolt

Cables & Terminators

Barcode Labels

Turtle Storage Cases

Quantum Scalar i3 Warranty

Removable Disk Storage

Imation RDX

Imation RDX Bundles

Tandberg RDXLock WORM

Quantum RDX

HP RDX+ Bundles


Dell RD1000

Reconditioned Tape Drives

Custom Sequence Barcode Labels for all your Tape Media - DLT, SDLT AIT and LTO FREE LTO BARCODE LABELS

LTO-9 Tape Drives LTO-9 Tape Libraries Now Available

SymplyPro LTO Archiving Solutions LTO-8 and LTO-9

Browse by Manufacturer
Mailing Lists


Key considerations in developing a storage area network design

Storage area networks (SANs) let several servers share storage resources and are often used in situations that require high performance or shared storage with block-level access, like virtualized servers and clustered databases. Although SANs started out as a high-end technology used only in large enterprises, cheaper SANs are now affordable even for small and medium-sized businesses (SMBs). In earlier installments of this Hot Spot Tutorial, we examined what benefits SANs offer over other storage architectural choices, as well as the two main storage networking protocols, Fibre Channel and iSCSI. In this installment, we'll look at the main considerations you should keep in mind when putting together a storage area network design.

Uptime and availability

Because several servers will rely on a SAN for all of their data, it's important to make the system very reliable and eliminate any single points of failure. Most SAN hardware vendors offer redundancy within each unit -- like dual power supplies, internal controllers and emergency batteries -- but you should make sure that redundancy extends all the way to the server.

In a typical storage area network design, each storage device connects to a switch that then connects to the servers that need to access the data. To make sure this path isn't a point of failure, your client should buy two switches for the SAN network. Each storage unit should connect to both switches, as should each server. If either path fails, software can fail over to the other. Some programs will handle that failover automatically, but cheaper software may require you to enable the failover manually. You can also configure the program to use both paths if they're available, for load balancing.

But you should also consider how the drives themselves are configured, Franco said. RAID technology spreads data among several disks -- a technique called striping -- and can add parity checks so that if any one disk fails, its content can be rebuilt from the others. There are several types of RAID, but the most common in SAN designs are levels 5, 6 and 1+0.

RAID 5 stripes data across every disk in the unit except one, which is used to store parity information that can be used to rebuild any drive that needs to be replaced. RAID 6 adds a second disk for redundant parity. This protects your client's data in case a second drive breaks during the first disk's rebuild, which can take up to 24 hours for a terabyte, Franco said. RAID 1+0 stripes data across a series of disks without any parity checks, which is very fast, but mirrors each of those disks to a second set of striped disks for redundancy.

Capacity and scalability

A good storage area network design should not only accommodate your client's current storage needs, but it should also be scalable so that your client can upgrade the SAN as needed throughout the expected lifespan of the system. You should consider how scalable the SAN is in terms of storage capacity, number of devices it supports and speed.

Because a SAN's switch connects storage devices on one side and servers on the other, its number of ports can affect both storage capacity and speed, Schulz said. By allowing enough ports to support multiple, simultaneous connections to each server, switches can multiply the bandwidth to servers. On the storage device side, you should make sure you have enough ports for redundant connections to existing storage units, as well as units your client may want to add later.

One feature of storage area network design that you should consider is thin provisioning of storage. Thin provisioning tricks servers into thinking a given volume within a SAN, known as a logical unit number (LUN), has more space than it physically does. For instance, an operating system (OS) that connects to a given LUN may think the LUN is 2 TB, even though you have only allocated 250 GB of physical storage for it.

Thin provisioning allows you to plan for future growth without your client having to buy all of its expected storage hardware up front. In a typical "fat provisioning" model, each LUN's capacity corresponds to physical storage. That means that your client will have to buy as much space as it anticipates needing for the next few years. While it's possible to allocate a smaller amount of space for now and transfer its data to a larger provision as needed, that process is slow and could result in downtime for your client.

Thin provisioning allows you to essentially overbook a SAN's storage, promising a total capacity to the LUNs that is greater than the SAN physically has. As those LUNs fill up and start to reach the system's physical capacity, you can add more units to the SAN -- often in a hot-swappable way. But because this approach to storage area network design requires more maintenance down the road, it's best for stable environments where a client can fairly accurately predict how each LUN's storage needs will grow.


With several servers able to share the same physical hardware, it should be no surprise that security plays an important role in a storage area network design. Your client will want to know that servers can only access data if they're specifically allowed to. If your client is using iSCSI, which runs on a standard Ethernet network, it's also crucial to make sure outside parties won't be able to hack into the network and have raw access to the SAN.

Most of this security work is done at the SAN's switch level. Zoning allows you to give only specific servers access to certain LUNs, much as a firewall allows communication on specific ports for a given IP address. If any outward-facing application needs to access the SAN, like a website, you should configure the switch so that only that server's IP address can access it.

If your client is using virtual servers, the storage area network design will also need to make sure that each virtual machine (VM) has access only to its LUNs. Virtualization complicates SAN security because you cannot limit access to LUNs by physical controllers anymore -- a given controller on a physical server may now be working for several VMs, each with its own permissions. To restrict each server to only its LUNs, set up a virtual adapter for each virtual server. This will let your physical adapter present itself as a different adapter for each VM, with access to only those LUNs that the virtualized server should see.

Replication and disaster recovery

With so much data stored on a SAN, your client will likely want you to build disaster recovery into the system. SANs can be set up to automatically mirror data to another site, which could be a failsafe SAN a few meters away or a disaster recovery (DR) site hundreds or thousands of miles away.

If your client wants to build mirroring into the storage area network design, one of the first considerations is whether to replicate synchronously or asynchronously. Synchronous mirroring means that as data is written to the primary SAN, each change is sent to the secondary and must be acknowledged before the next write can happen.

While this ensures that both SANs are true mirrors, synchronization introduces a bottleneck. If the secondary site has a latency as high as even 100 to 200 milliseconds (msec), your system will slow down as the primary SAN has to wait for each confirmation. Although there are other factors, latency is often related to distance; synchronous replication is generally possible up to about 6 miles.

The alternative is to asynchronously mirror changes to the secondary site. You can configure this replication to happen as quickly as every second, or every few minutes or hours. While this means that your client could permanently lose some data, if the primary SAN goes down before it has a chance to copy its data to the secondary, your client should make calculations based on its recovery point objective (RPO) to determine how often it needs to mirror.

Shopping Cart
Your cart is empty.

Tandberg Data RDX Quikstor Removable Disk Cartridges

RDX 10 Pack Promotion - celebrating 10 Years of RDX Technology

SnapSever XSR120 and XSR40 Available

Quantum Scalar i3 LTO-9 Now Available and Shipping

Free Shipping UPS Ground - $500 min. order

Repair Services - 6 Month Warranty Fast Turnaround

Outlet Center - Refurbished Tape Drives - 6 Month Warranty