Ananta

Abstract

Layer-4 load balancing is fundamental to creating scale-out web services. We designed and implemented Ananta, a scale-out layer-4 load balancer that runs on commodity hardware and meets the performance, reliability and operational requirements of multi-tenant cloud computing environments. Ananta combines existing techniques in routing and distributed systems in a unique way and splits the components of a load balancer into a consensus-based reliable control plane and a decentralized scale-out data plane. A key component of Ananta is an agent in every host that can take over the packet modification function from the load balancer, thereby enabling the load balancer to naturally scale with the size of the data center. Due to its distributed architecture, Ananta provides direct server return (DSR) and network address translation (NAT) capabilities across layer-2 boundaries. Multiple instances of Ananta have been deployed in the Windows Azure public cloud with combined bandwidth capacity exceeding 1Tbps. It is serving traffic needs of a diverse set of tenants, including the blob, table and relational storage services. With its scale-out data plane we can easily achieve more than 100Gbps throughput for a single public IP address. In this paper, we describe the requirements of a cloud-scale load balancer, the design of Ananta and lessons learnt from its implementation and operation in the Windows Azure public cloud.

Measuring control plane latency in SDN-enabled switches

“…This has opened the door to rich network control applications that can adapt to changes in network topology or traffic patterns more flexibly and more quickly than legacy control planes [2,6,7,9,10,13,16]. However, to optimally satisfy network objectives, many important control applications require the ability to reprogram data plane state at very fine time-scales.…”

Coconut

“…Over 20 runs of this experiment, COCONUT applies these updates in respectively 2.4, 1.3, and 0.9 minutes on average. Its 90 th percentile update time is respectively, 2.6, 1.8, and 1.4 minutes, i.e., more than 90% of the time its rate is 76×, 112×, and 144× faster than the peak update rate cited in [47]. Thus, we believe the existing header fields for carrying meta-data are more than sufficient for COCONUT's operations [47].…”

“…A campus network may experience up to 18K updates per month [36], but the rate is significantly larger and more bursty in cloud environments where customers continuously deploy, delete, and migrate services, with an average of 12K updates per day in a typical cluster, peaking at one update per second [47]. To test COCONUT's rate of applying updates, we reserve 12 header bits (the number of bits of the VLAN tag, the header field reserved for the update operations in CU [53]), 19 header bits (the number of bits in one MPLS label), and 4 header bytes (the smallest possible option length in Geneve [22]) for COCONUT and modify the IDS application to send to COCONUT 12K update requests, equivalent to the average number of updates in one day in a cloud environment of [47]. We run this experiment on a fat-tree with 180 switches and measure the time COCONUT consumes to apply all the updates.…”

SwiShmem

“…Because it is essential for subsequent packets in the same TCP connection to be routed to the same server (a property dubbed per-connection consistency), the load balancer must track the connection-to-server mapping. Load balancers like this are in widespread use at major cloud providers [7,34], and handle a significant fraction of a data center's incoming traffic. Implemented on commodity servers, they require large clusters to support their massive workload.…”