April 28, 2008
The impact on the Internet datacenter is equally profound. Gone are the isolated silos of Web servers simply serving up content. Today's Web applications require continual, real-time interactions among multiple client-facing and backend servers. Content must be managed dynamically. Computing is becoming virtualized and distributed, potentially in clusters, grids or clouds. Storage is becoming tiered and consolidated. The entire Internet datacenter must now operate more seamlessly to facilitate Web 2.0 applications. The biggest challenge faced in today's biggest datacenters is making such seamless networking both scalable and affordable.
Scaling the Datacenter -- Past and Present
Datacenters scale today with various combinations of three different networking technologies: Layer 2 Ethernet for edge or access aggregation; Layer 3 IP for distribution switching, core and border routing; and Fibre Channel for storage area networks (SANs). While this approach does indeed scale, it is both complex and costly.
The largest datacenters are now encountering another problem: despite server virtualization and storage consolidation initiatives, they are simply running out of space, power and cooling capacity, owing in large part to the complexity of the myriad interconnects involved.
The diagram below shows how the servers in today's typical datacenter are organized into units, and how these multiple units scale. In this example, Ethernet switching is employed in the Access Layer, with IP routing in the Distribution and Core Layers, as well as at the Border. Each scalable unit is limited to a maximum of 640 servers in 16 racks with up to 40 servers per rack. Each server connects via Gigabit Ethernet (GE) to an Access Layer "top-of-rack" switch with 10 GE connections to the Distribution Layer router. Each 10 GE Distribution Layer router utilizes a total of 28 ports connected as follows: 16 ports for the 16 top-of-rack switches; 4 ports (as a Link Aggregation Group or LAG) connecting with the companion Distribution switch; and 8 ports to the Core. The Core routers also utilize a total of 28 ports each as follows: 12 ports serving 2 connections each from the 6 scalable units; 8 ports (for two 4-port LAGs) connecting with the companion Core switch; and 8 ports to the Border.
Most datacenters today employ a three-layered architecture servers -- Access, Distribution and Core -- to interconnect with the servers organized into scalable units. In this example there are six such scalable units supporting a maximum of 3,840 servers.
In the above example, using a popular switch/router with a maximum non-blocking capacity of 32 10GbE ports, but with a single 4-port card slot being consumed by a redundant supervisor card, the configuration can support a maximum of 3,840 servers. Note that these servers are over-subscribed 4:1 because there is only 20 Gbps of capacity for each rack of 40 servers, and only 8 Core Layer ports going upstream to service the 16 Access Layer ports going downstream.
Something better clearly is needed to support -- preferably more cost-effectively -- the orders of magnitude more servers now being deployed in some of the industry's larger datacenters.
That something better could be something that is also quite familiar: Ethernet. A scalable Layer 2 Ethernet Distribution Layer also overcomes the incumbent Layer 3 approach's two weaknesses with its plug-and-play simplicity and industry-leading affordability. But can Ethernet really meet the demands of today's large and growing datacenters? Can Ethernet really deliver the scalability provided by Layer 3 routing while preserving its renowned simplicity and affordability?
It can, but only by overcoming certain limitations rooted in this veteran technology's legacy Spanning Tree Protocol (STP). STP is what limits Ethernet's scalability to the largest single switch at either the Distribution or Core Layers of the network. STP is required in flat Layer 2 networks to prevent loops that would flood the topology with redundant traffic on alternate paths. Disabling all such alternate paths, however, adversely impacts performance, resiliency and scalability.
Employing Ethernet successfully in the datacenter also requires that the switch deliver lossless throughput with minimal latency. The only way for Ethernet to deliver low latency is to utilize cut-through switching with robust congestion management. But to assure lossless throughput, traditional congestion control mechanisms for Ethernet are all dependent on buffering traffic in store-and-forward switch designs. It's a real dilemma.
One way to overcome these limitations would be to build a massive, cut-through Ethernet switch with thousands of ports. At a theoretical level, this is indeed possible. But such a behemoth would be impractical if not impossible to build, and even if it could be built, it would end up being nothing more than an intolerable single point of (inevitable) failure. A far better approach is the Ethernet fabric.
The Multi-path Ethernet Fabric
The distinguishing characteristic of an Ethernet fabric is its ability to utilize a non-blocking Clos topology across multiple paths on multiple switches. The Clos topology was created by Charles Clos in 1953 specifically to enable the design of circuit-switched networks where the total number of paths exceeded the capacity of the largest crossbar switch. Does this problem sound familiar?
Employing a Clos topology with cut-through Ethernet switching requires the ability to switch any traffic flow to any available alternate path -- on either the same or a separate switch chassis -- within a millisecond. A robust Ethernet fabric would also be able to detect and recover from a complete path failure in less than 10 milliseconds.
Because the Spanning Tree Protocol requires that alternate paths available on a separate switch cannot be in the same tree as the current path, it can take several seconds to recalculate the new tree structure. Even the Rapid Spanning Tree Protocol (RSTP), which superseded STP in 2004, is unable to converge on tree structures rapidly enough to enable use of a multi-switch Clos topology in the datacenter due to the potential for TCP session and application timeouts.
It is this ability to select, almost instantaneously, from any available alternate path and without regard to spanning tree limitations, which gives the Ethernet fabric its virtually unlimited scalability. But achieving the sub-millisecond switchovers required is no trivial task because it requires implementation in silicon to maintain high levels of performance and resiliency without adding latency.
Another challenge with large-scale, cut-through Ethernet fabrics involves detecting congestion almost as immediately as it occurs. One way to do that effectively, while not violating any Ethernet standards, is to use a combination of latency and latency jitter as a proxy for congestion along the path between any pair of edge ports. To be fully effective, these measurements must be made continuously at short intervals for all active and alternate paths between pairs of edge ports.
With this continuous awareness of traffic flows and available capacity for all paths in the Ethernet fabric, the switch is able to rebalance traffic in real time to less congested paths without dropping or re-ordering packets. An example of where such real-time rebalancing of traffic flows is particularly powerful is during brief periods of extraordinarily high activity with an unpredictable traffic pattern. Such a "microburst" of traffic might occur when subscriber billing records are updated at the end of a video event viewed by millions of users, and might last for 50-100 milliseconds or more. The Ethernet fabric, with its dynamic congestion management capabilities, recognizes this situation and rebalances the flows along available paths in under a millisecond, thereby avoiding any problems. By contrast, traditional switches and routers must accommodate these microbursts with very large buffers, which add latency and consume more power.
Even though the Ethernet fabric is capable of eliminating traffic congestion within the fabric itself, congestion can still occur for two reasons. The first reason would be the lack of sufficient alternate paths within the switching fabric; in other words, not implementing a full, non-blocking Clos topology. This situation results from the classic price/performance tradeoff made when intentionally over-subscribing a network. The second reason involves congestion occurring external to the switching fabric, such as during a microburst or in networked storage applications. In both cases, the Ethernet fabric permits a more intelligent use of Ethernet Pause for initiator rate control from the ingress port rather than from egress port. It is important to note that on an ordinary Ethernet switch, the Pause function normally is disabled to prevent the problem of congestion spreading when issued from egress ports.
Finally, by monitoring throughput and latency constantly, and collecting statistics on historical performance, the Ethernet fabric helps datacenter operators spot trends and plan capacity far more accurately and intelligently.
Scaling the Datacenter with Ethernet Fabrics
Ethernet fabric switches available today have the ability to support up to 4,000 10 GbE edge ports, and deliver non-blocking, lossless throughput at 10 Gbps with an edge-to-edge latency of approximately 4 microseconds across multi-switch fabrics. By fronting the Ethernet fabric with GbE aggregation switches, a single fabric can support literally tens of thousands of servers within a datacenter.
This ability to handle inter-server and other datacenter interconnect requirements in a scalable, reliable and affordable way is what gives the Ethernet fabric its remarkable potential. The diagram below shows how an Ethernet fabric at the Distribution Layer is able to support the same configuration as above (3,840 total servers, over-subscribed 4:1) with just two 144-port Ethernet fabric switches. The scalable unit in this case is, in effect, six times larger than the one above, and therefore, requires only one-sixth the number of switches at the Distribution Layer.
An Ethernet fabric at the Distribution Layer is shown here supporting the same 3,840 servers with the same 4:1 over-subscription as in the previous example. What is different is the dramatic reduction in cost, complexity and power consumption.
An Ethernet fabric is capable of scaling well beyond the 3,840 servers in the above scenario. Indeed, a robust Ethernet fabric should be able to scale to at least an order of magnitude more servers -- to 40,000 or even 100,000. In the example below, the network is intentionally over-subscribed; achieving a fully non-blocking configuration would require twice as many switches, with 28 in the spine and 56 in the leaf.
The Ethernet fabric shown here could support as many as 80,000 servers with a total of 42 EFX 1000 Ethernet Fabric Switches: 14 in the spine at the top of the Distribution Layer and 28 switches in the leaf section interfacing to the top-of-rack switches in the Access Layer. Up to 2,016 server racks can be supported with this configuration.
Just as significantly is just how cost-effective the Ethernet fabric is at accommodating such large-scale deployments. Exclusive use of Ethernet also allows operators to take advantage of the Ethernet interfaces built into servers and virtualized servers, eliminating the need to purchase separate host bus adapters or network interface cards for these systems. The economies of scale of Ethernet make it possible to implement large-scale fabrics for less than $2,000 per 10 GbE edge port, which is less than half the cost of comparable configurations.
Of course, an Ethernet fabric can be "green" in another important way: significantly lower power consumption. In the example configuration shown above the entire Ethernet fabric, consisting of both the Distribution Layer switches and the top-of-rack Access Layer switches, consumes only about 8 Watts of power per server. This remarkable result is relatively easy to achieve because Ethernet fabric switches purpose-built in a "lean and mean" fashion for the datacenter are able to consume less than 20 Watts per 10 GbE port. By contrast, "full-featured" Ethernet switches can consume up to 100 Watts per port, but most of those features are either unnecessary for or contrary to satisfying the real needs of the datacenter.
About Dan Maltbie
Dan Maltbie is a 27-year veteran of the networking industry focused on the design and development of new technology and products ranging from storage switches and IP routers to video encoding systems and Ethernet fabric switches. Before co-founding Woven Systems, Maltbie served as vice president of engineering at Sanera Systems, a provider of director-class Fibre Channel switches, which later was acquired by McDATA. Before Sanera, he was vice president of engineering for Caspian Networks where his team developed a telecom-class IP router. Previously, he was vice president of engineering at DiviCom, a video encoding system provider which is now part of Harmonic Lightwave. Earlier, Maltbie held engineering and management roles of increasing importance at Hewlett-Packard, where he represented the company in Ethernet IEEE 802 standards activities. Maltbie studied computer science and astrophysics at Indiana University.
May 16, 2013 |
When it comes to cloud, long distances mean unacceptably high latencies. Researchers from the University of Bonn in Germany examined those latency issues of doing CFD modeling in the cloud by utilizing a common CFD and its utilization in HPC instance types including both CPU and GPU cores of Amazon EC2.
May 10, 2013 |
Australian visual effects company, Animal Logic, is considering a move to the public cloud.
May 10, 2013 |
Program provides cash awards up to $10,000 for the best open-source end-user applications deployed on 100G network.
May 08, 2013 |
For engineers looking to leverage high-performance computing, the accessibility of a cloud-based approach is a powerful draw, but there are costs that may not be readily apparent.
05/10/2013 | Cleversafe, Cray, DDN, NetApp, & Panasas | From Wall Street to Hollywood, drug discovery to homeland security, companies and organizations of all sizes and stripes are coming face to face with the challenges – and opportunities – afforded by Big Data. Before anyone can utilize these extraordinary data repositories, however, they must first harness and manage their data stores, and do so utilizing technologies that underscore affordability, security, and scalability.
04/02/2012 | AMD | Developers today are just beginning to explore the potential of heterogeneous computing, but the potential for this new paradigm is huge. This brief article reviews how the technology might impact a range of application development areas, including client experiences and cloud-based data management. As platforms like OpenCL continue to evolve, the benefits of heterogeneous computing will become even more accessible. Use this quick article to jump-start your own thinking on heterogeneous computing.