Storage area networks
(SANs) must scale to accommodate the added demands of more users
along with a proliferation of more sophisticated enterprise
applications. In the Fibre Channel world, scaling often means
adding more and faster switch ports to extend the fabric's
bandwidth and connectivity. For example, adding 4 Gb FC ports
supports more interconnected storage devices and servers, while
enhancing their performance and availability. But IP storage
(mainly iSCSI) is a growing area of SAN expansion, using ubiquitous
Ethernet network technology to pass storage data between storage
devices. This requires the use of IP switches and routers, and can
involve the deployment of iSCSI TOE host adapters to offload iSCSI
traffic from the local server's CPU. This Buying Guide is intended
to help clarify the principle considerations involved scaling
storage networks and each chapter offers a set of buying points and
product specifications that can help readers identify prospective
new scaling products. Before we look at specific product
categories, let's start by identifying the core concerns when
scaling any storage network.
@35604 Consider the rate of storage growth. Storage
growth rates will have a profound impact on the technology that is
selected. Slow growth often favors traditional monolithic storage
systems and fixed port switches where there is a single capital
expense and only infrequent upgrades. Rapid growth needs typically
favor modular storage systems or blade-based servers and switches
which can be expanded quickly. Growth also influences bandwidth,
and storage network growth should eventually include upgrades to
switch port speeds. For example, it may be prudent to implement 4
Gb FC switches to scale the storage fabric's bandwidth and avoid
bottlenecks -- even if some servers and storage devices are still
operating at 1 Gb or 2 Gb speeds. Similarly, deploying TCP/IP
Offload Engine (TOE) cards can enhance the performance of an iSCSI
SAN.
Consider the time table of any expansion. Analysts note
that overall storage costs (e.g., disk, port and HBA costs) are
declining over time, and more features are always being added. This
means a massive scaling project implemented in the near term may
actually wind up costing more and offering fewer features than a
systematic upgrade effort that takes place periodically over time.
This can be true even when factoring in potential savings of
upfront bulk purchases. Once you have an accurate knowledge of
growth rates, compare product costs and see what makes more
financial sense for your organization.
Migration should be included in the scaling process. When
storage capacity is scaled with more disks or additional storage
systems, some data may need to be moved in order to take advantage
of faster disks, more capacity, or faster connectivity. Time is
also essential when an older device is being decommissioned because
the longer that migration is delayed, the more your company must
pay to operate and support both systems. Migration is a
mission-critical task, but it's typically overlooked until new
hardware is sitting on the data center floor.
Data classification can help ease the
migration process, especially when using data classification and
migration automation tools to classify and move data according
to your existing policies.
Remember to also scale backup and disaster recovery. Any
time that storage and storage networks are added or expanded, it's
important to consider any adverse side-effects on data protection
policies and practice. Increased storage will demand larger backup
windows. Changes in tiered storage may alter backup or snapshot
policies -- not all data may need to be protected in the same way.
In extreme cases, improved backup technologies may be required. For
example, tape may give way to disk (e.g., virtual tape library or
disk-to-disk storage) and space-saving tactics like data
deduplication. Similarly, backup changes will impact disaster
recovery tasks such as remote replication. If backup software
licensing is priced "per terabyte", increasing storage can
dramatically increase backup costs.
Evaluate changes to management requirements and
processes. Scaling a storage network can also influence
established and documented procedures such as backups or
provisioning. For example, implementing iSCSI in a workgroup or
integrating an iSCSI SAN with an existing FC SAN can cause
substantial procedural changes that should be considered during any
scaling project. Also weigh the management overhead that may
accompany an upgrade. Experts note that additional storage capacity
rarely adds significant management overhead, but adding new
technologies or processes to the storage environment may require
more labor. For example, another 10 terabytes of disk space may be
readily manageable with existing staff, but implementing a new
remote replication scheme for data protection might require
additional attention.
Track performance before and after scaling. It's
important for an enterprise to monitor network, server, and storage
fabric performance before and after any scaling project. For
example, industry experts suggest watching inter-switch local and
long distance links to identify points of congestion and ensure
required service levels. Testing allows IT staff to draw a
performance benchmark prior to an expansion, then measure the
benefits, optimize any new hardware, and spot any unexpected
bottlenecks which can be addressed or tabled for future
upgrades.
Return
to the beginning