Welcome!

Eclipse Authors: Jayaram Krishnaswamy, Yeshim Deniz, Liz McMillan, Shelly Palmer, Si Chen

Blog Feed Post

What networking can learn from CPUs

The rapid growth in compute demand is well understood. To keep up with accelerating requirements, CPUs have gone through a massive transformation over the years. Starting with relatively low-capacity CPUs, the expansion of capability to what is available today has certainly been remarkable – enough to satisfy even Gordon Moore. But keeping up with demand was not a matter of simply making bigger and faster chips. To get more capacity, we actually went smaller.

As it turns out, there are practical limitations to just scaling things larger. To get more capacity out of individual CPUs, we went from large single cores to multi-core processors. This obviously required a change in applications to take advantage of multiple cores. The result is a distributed architecture and the proliferation of “scale out” as a buzzword in our industry.

From an application perspective, the trend continues. Applications that require performance continue to move to multi-tiered applications that are distributed across a number of VMs. This is true for massive web-scale applications like Facebook, but also for other applications like MapReduce.

To get bigger, we get smaller

The technology trend is clear: to get more output, move to smaller blocks of capacity, and coordinate workloads across that capacity.

If this is true, then the future will be lots of small pools of resources that rely on the network for interconnectivity. As applications become more distributed, then performance between these pools becomes even more critical. Even small amounts of pool-to-pool latency can aggregate up into significant impacts, either because of interesting failure conditions with asynchronous operations or because of the cumulative performance impact.

As interconnectivity takes a larger role, we should expect the discussion of commoditization of network resources to expand. Today, there is a strong argument around commoditizing the switch hardware (largely via merchant silicon) and the switch operating system (through players like Cumulus, Big Switch, and Pica8). But massive distribution will require both a commoditized interconnect and a commoditized orchestration platform.

On the latter, it would seem that OpenDaylight is poised to lead the charge. With an industry-backed open source solution, it will be difficult to justify premium control products, which should be sufficient in driving that aspect of the solution towards commodity. But that still leaves the interconnect piece unaccounted for.

Getting to a cheaper interconnect

There is probably a case to be made for leaf-spine architectures here, but if the number of servers continues to expand, there are some ugly economics at play. Scaling out in a leaf-spine architecture requires scaling up at the same time. As the interconnect demands increase, the number of spine switches increases. You eventually get into spines of spines, which starts to look an awful like like traditional three-tier architectures.

The sheer number of devices and cables drive the cost unfavorably. And when you consider the long-term operational costs tied to power, cooling, space, and management, it’s unclear where the budgetary breaking point is. Beyond just the costs, the other issue here is that every time a new layer is added, you add a couple of more fabric switch hops. If application performance is based on both capacity and latency, then every time you add switch hops, you incur a potentially heavy performance penalty.

At some point, you need to move away from multi-hop connectivity through the fabric.

Moving away from multi-hop fabrics

Instinctively, we already know this. There is already a tendency to rack gear up in close proximity to other gear to which it is tied. You might, for example, balance Hadoop loads across a number of servers that are in the same rack. Essentially, what we are doing in these cases is acknowledging that proximity matters, and we are statically designing for it.

But what happens when things aren’t static?

In a datacenter where applications are portable across servers, the network capacity cannot be statically planned. And as application requirements change (often dynamically as load changes), then the network capacity demands will also change. This requires an interconnect that is both high in capacity and dynamic.

This problem is slightly different than the compute problem. On the compute side, it was enough to free up resources (or create additional ones) and then move the application to the resource. In this case, the application is fixed, which means the capacity has to move to the application. When capacity is statically allocated, this poses a problem.

The bottom line

The only solutions here are to either over provision everything, or move towards a dynamic interconnect. The first is counter to the trends we learn from compute – make things smaller and more distributed. In this case you get out of the problem by paying for it. The question is whether this flies in the face of all the commoditization trends. What good is commoditizing something if the end solution requires buying a ton more? You would have to see cost declines match capacity increases, but this seems unlikely as there is no upper limit for capacity whereas cost will asymptotically approach some profit threshold.

If the trends in compute and storage hold true for networking, then the current trajectory of some networking solutions will need to change. Learning from the past is a great way to shape the future.

[Today’s fun fact: Lobster was one of the main entrees at the first Thanksgiving dinner. They also had Cheddar Bay Biscuits I think.]

The post What networking can learn from CPUs appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."