In an effort to resolve an ever-present contributor to data center complexity, much work has been invested in software-defined networks that allow enterprises to define the paths of network traffic using software. However, in the end, physical boxes must still be connected to each other. No matter how much software definition there is, the traffic still has to travel over a switch.
The question becomes whether it is possible to make those switches better to help alleviate network congestion in a virtualized world in which workloads are moving around and application loads are volatile. This is the problem that Gnodal, a load-balancing switch designer, has set out to solve.
Ethernet generates congestion because every endpoint on an Ethernet switch essentially says, “I want to send a packet” and then sends it. If two endpoints want to send a packet at the same time, there is a head-on collision, and they stop. As traffic increases, collisions are more frequent, which results in very slow networks.
Gnodal has developed an ASIC (Application Specific Integrated Circuit), a specially designed chip that forms the core of its switch, to counteract the flaws of Ethernet communication.
Ethernet traffic, as designed, cannot change the course between two points once it is initiated. So, even if load congestion is discovered, nothing can be done until the packet is either delivered or fails.
The Gnodal switch is designed to be aware of any other Gnodal switch in the local area network, at a distance up to 2 km. The switches communicate with each other on Gnodal fabric using a separate, non-Ethernet protocol orchestrated by gNOS (Gnodal Network Operating System), transmitting the load status of each switch and the location of each packet.
If one Gnodal switch becomes aware that another in the path of travel of the Ethernet packet is becoming overloaded, it performs live load balancing and reroutes the packet to a third switch or theoretically an infinite number of ports, taking full advantage of any spare network capacity. This same feedback system also prevents packets from overtaking each other and causing problems (such as dropping packets or blockages).
Single Logical Switch
In essence, the network of Gnodal switches acts as one giant single, logical switch, releasing the data center manager from having to worry about where Ethernet traffic is getting held up. As soon as the first packet of a session runs into trouble, the subsequent packets can receive optimal routing, something Ethernet cannot do by itself.
“The vision really was to take some of the feedback techniques used in high-performance computing and make it look like Ethernet,” says CTO Fred Homewood.
The implications for the data center are tremendous. On one level, it saves enterprises from having to build extra switching capacity and potentially can reduce switch-related power consumption by 50%. On another level, the data center manager spends a lot less time worrying about traffic management, constantly chasing down bottlenecks and installing larger-capacity switches, only to find the bottleneck popping up somewhere else.
“Data center bandwidth requirements are going to go up and up and up and they’re never going to stop,” Homewood says. “We’re really helping to build a high-performance data center. We think we’ve got a fairly broad market, but in particular, people trying to solve numeric problems, and those working with big data are the principal markets.”
Real-time securities traders, who rely on submicrosecond connections between their algorithms, real-time feeds, databases, and the algorithmic engines of their trading partners, are particularly big fans of Gnodal, Homewood adds.
Software Alone Will Not Work
Early on, Gnodal eschewed the idea of a software-only solution because it simply wasn’t fast enough, Homewood says. In the same sense that, in order to prevent a collision, a railroad signal must travel faster than a train entering a given circuit before the train reaches the end of that circuit, with Gnodal, the hardware itself needed to be optimized so that it could transmit feedback about the data in the network faster than the data itself was traveling.
Ordinary network technology couldn’t get the job done either. Gnodal experimented with ASICs from Fujitsu and Fulcrum, but in both cases the feedback loop was simply too long. Diversions caused further network congestion, much in the way traffic jams go on long after the accident that caused them has been cleared.
“Why aren’t the merchants that supply silicon to the other companies doing it?” Homewood asks. “They’re trying to sell as many units as possible. And so they’re looking at other ways of making the chip more applicable to other markets, and they’re not looking specifically at this market. They’re also trying to sell as many single chips as possible. They don’t look at the chip as a component in a bigger system, and that’s really where we’ve won out.”
When the entire switch fabric acts as a single switch, as far as the components of the data center are concerned, all the capacity management and optimization happens within that network, and the data center manager can move on to putting out other fires.
How Gnodal Works
So, how does this all work? There are basically five techniques in play:
- Gnodal Peta: Gnodal’s ASIC, aka Gnodal Peta, supports high speed Ethernet switching of up to 72 links for 10 GbE or 18 for 40 GbE. The chip has a variety of other hardware features to support the advanced capabilities below.
- Multipath connections: All the Gnodal switches connected via a LAN can see each other so that many paths may exist between the same computers.
- Distributed network-wide fair arbitration: The Gnodal fabric allows traffic to be routed in such a way each conversation gets appropriate bandwidth and one overloaded pathway does not starve all other conversations of resources.
- Dynamic load balancing: Paths are rerouted during a conversation between two computers as needed to take advantage of underutilized switches.
- gNOS: Gnodal’s Network Operating System enables the chipset hardware to interoperate, forming the fabric to scale to tens of thousands of ports and delivering flexibility and high performance.
In an era of volatile workloads that migrate from machine to machine, the network will have to have the sort of smarts that Gnodal has implemented to avoid congestion. It will be interesting to see if other approaches can be developed to solve the same problem.