Specifications

DATA CENTER BEST PRACTICES
SAN Design and Best Practices 51 of 84
•Per-Packet Load Balancing (PPLB) is not supported by Brocade. PPLB is often the cause of chronic and
sometimes severe Out-Of-Order Packets (OOOP). To some degree, OOOP can easily be handled by TCP;
however, PPLB will cause TCP to go into overdrive and put a dramatic strain on the system. PPLB also causes
large latencies in delivering sequences to the upper layer protocols, because TCP is waiting for packets that
are arriving out of order. PPLB may also cause a signicant number of retransmits that will unnecessarily use
up valuable bandwidth. Moreover, there is no redeeming added value that PPLB brings to the network, as there
are other load balancing techniques that do not cause such problems and that equally load the WAN links. It
is for these reasons that Brocade does not support PPLB for FCIP WAN connections.
WORKLOADS
Many different kinds of trafc traverse a SAN fabric. The mix of trafc is typically based on the workload on the
servers and the effect that behavior has on the fabric and the connected storage. Examples of different types of
workload include these:
•I/O-intensive, transaction-based applications: These systems typically do high volumes of short block I/O and
do not consume a lot of network bandwidth. These applications usually have very high-performance service
levels to ensure low response times. Care must be taken to ensure that there are a sufcient number of
paths between the storage and hosts to ensure that other trafc does not interfere with the performance of
the applications. These applications are also very sensitive to latencies.
•I/O-intensive applications: These applications tend to do a lot of long block or sequential I/O and typically
generate much higher trafc levels than transaction-based applications (data mining). Depending on the type
of storage, these applications can consume bandwidth and generate latencies in both storage and hosts that
can negatively impact the performance of other applications sharing their storage.
•Host High Availability (HA) clustering: These clusters often treat storage very differently from standalone
systems. They may, for example, continuously check their connected storage for data integrity reasons and
put a strain on both the fabric and the storage arrays to which they are attached. This can result in frame
congestion in the fabric and can cause performance problems in storage arrays.
•Host-based replication: Host-based replication causes trafc levels to increase signicantly across a fabric
and can put considerable pressure on ISLs. Replicating to poorer-performing storage (such as tier 1-to-
tier 2 storage) can cause application performance issues that are difcult to identify. Latencies in the
slower storage can also cause “back pressure,” which can extend back into the fabric and slow down other
applications that use the same ISLs.
•Array-based replication: Data can be replicated between storage arrays as well.
Workload Virtualization
The past three years have witnessed a huge growth in virtualized workload. Available on IBM mainframes
for decades, workload virtualization was initially popularized on Intel-based platforms by VMware ESX Server
(now vSphere). Windows, UNIX, and Linux server virtualization is now ubiquitous in enterprise infrastructures.
Microsoft now has a viable product with Hyper-V.
Most recently, organizations have started adopting workload virtualization for desktops. This technology is still in
development but is evolving rapidly. (Desktop virtualization storage access is not addressed in this document.)
Intel-Based Virtualization Storage Access
Intel-based VMs typically access storage in two separate ways:
•They use some sort of distributed le system that is typically controlled by the hypervisor (the control program
that manages VMs). This method puts the onus on the hypervisor to manage the integrity of VM data. All VM
I/O passes through an I/O abstraction layer in the hypervisor, which adds extra overhead to every I/O that
a VM issues. The advantage to this approach is that many VMs can share the same LUN (storage), making
storage provisioning and management a relatively easy task. Today the vast majority of VMware deployments
use this approach, deploying a le system called Shared VMFS.