Data Center LAN Migration Guide - Juniper Networks
Data Center LAN Migration Guide - Juniper Networks
Data Center LAN Migration Guide - Juniper Networks
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Data</strong> <strong>Center</strong> <strong>LAN</strong> <strong>Migration</strong> <strong>Guide</strong><br />
Network topologies should mirror<br />
the nature of the tra�c they transport<br />
N<br />
S<br />
UP TO 70%<br />
Figure 3: <strong>Data</strong> center traffic flows<br />
Applications built on SOA architecture and those delivered in the software as a service (SaaS) model require an<br />
increasing number of interactions among servers in the data center. These technologies generate a significant amount of<br />
server-to-server traffic; in fact, up to 70% of data center <strong>LAN</strong> traffic is between servers. Additional server traffic may also<br />
be produced by the increased adoption of virtualization, where shared resources such as a server pool are used at greater<br />
capacity to improve efficiency. Today’s network topologies need to mirror the nature of the traffic being transported.<br />
Existing three-tier architectures were not designed to handle server-to-server traffic without going up and back through<br />
the many layers of tiers. This is inherently inefficient, adding latency at each hop, which in turn impacts performance,<br />
particularly for real-time applications like unified communications, or in industries requiring high performance such as<br />
financial trading.<br />
Scaling Is Too Complex with Current <strong>Data</strong> <strong>Center</strong> Architectures<br />
Simply deploying ever more servers, storage, and devices in a three-tier architecture to meet demand significantly<br />
increases network complexity and cost. In many cases, it isn’t possible to add more devices due to space, power,<br />
cooling, or throughput constraints. And even when it is possible, it is often difficult and time-consuming to manage due<br />
to the size and scope of the network. Or it is inherently inefficient, as it’s been estimated that as much as 50% of all<br />
ports in a typical data center are used for connecting switches to each other as opposed to doing the more important<br />
task of interconnecting storage to servers and applications to users. Additionally, large Layer 2 domains using Spanning<br />
Tree Protocol (STP) are prone to failure and poor performance. This creates barriers to the efficient distribution of<br />
resources in the DC and fundamentally prevents a fast and flexible network scale out. Similarly, commonly deployed<br />
data center technologies like multicast don’t perform at scale across tiers and devices in a consistent fashion.<br />
Legacy security services may not easily scale and are often not efficiently deployed in a data center <strong>LAN</strong> due to the<br />
difficulty of incorporating security into a legacy,multitiered design. Security blades which are bolted into switches at the<br />
aggregation layer consume excessive power and space, impact performance, and don’t protect virtualized resources.<br />
Another challenge of legacy security service appliances is the limited performance scalability, which may be far<br />
below the throughput requirements of most high-performance enterprises consolidating applications or data centers.<br />
The ability to cluster together firewalls as a single logical entity to increase scalability without added management<br />
complexity is another important consideration.<br />
Proprietary systems may also limit further expansion with vendor lock-in to low performance equipment. Different<br />
operating systems at each layer may add to the complexity to operate and scale the network. This complexity is costly,<br />
limits flexibility, increases the time it takes to provision new capacity or services, and restricts the dynamic allocation of<br />
resources for services such as virtualization.<br />
10 Copyright © 2012, <strong>Juniper</strong> <strong>Networks</strong>, Inc.<br />
W<br />
E