-
Cloud Ready Software Load Balancer -
Extensive set of Switching and load balancing options -
Used by eBay to power Test infrastructure
Neutrino
Software Load Balancer
Modular and pluggable
Neutrino’s modular and pluggable architecture allows for easy extensibility for new routing and resolving policies. Customizable Pipeline helps to add new module in Request and Response channel.
Read MoreSwitching Options
Supports L7 Routing based on Canonical names, url context and traffic rules. L4 Routing is achieved by multiple port numbers
Read MoreHorizontally scalable
Any number of SLBs can run in parrallel, can run in Container/VM/Bare Metals
Read MoreHigh Availability and Performance
Neutrino is highly available, and can support very high throughput levels. We have measured upwards of 300+ requests per second on a 2-core VM.
Provides Traffic Metrics and configuration page
Provides Traffic Metrics and configuration APIs for ease of use.
Read MorePluggable pipeline
New components for the pipeline are easy to build. The run-time environment is JVM, and so these components can be built on any language that runs on the JVM.
Why Neutrino
Ebay was looking for options to replace their hardware load balancers which are expensive and unable to keep up with the demand. There were two options, either take an open source product like HAProxy or build an in-house one.
From a high level, SLB has to satisfy following requirements
- L7 Switching using canonical names
- L7 Switching using canonical names and url context
- L7 Switching based on Rules. For eg. Traffic might need to route based on HTTP header, based on authentication header value etc
- Layer 4 Switching
- Should be able to send the traffic logs to API endpoints
- Cluster management is automated using eBay PaaS and Network Topology is stored in a DB and can be accessed through API. SLB should be able to read the topology and reconfigure itself
- Load Balancing should support most common algorithms like Least Connection and Round Robin. The framework should be extensible to add more algorithms in the future.
- Should be able to run on a Bare Metal, VM or a container
- No traffic loss during reconfiguration
HAProxy is the most commonly used SLB across the industry. It is written in C and has a reputation for being fast and efficient (in terms of processor and memory usage). It can do L4 Switching and L7 Switching using canonical names and url context. But L7 Switching based on rules, sending log to API end point or adding new load balancing algorithms cannot be satisfied using HAProxy. Reading the configuration from a DB or a API can be achieved through another application, but not optimal. Extending HAProxy to support these features found to be tough. Adding additional load balancing algorithms is also tough in HAProxy. Those are the reasons forced eBay to think about developing a SLB in-house.
Neutrino was build keeping the above requirements in mind. It is build in Scala language using Netty Server. It can do L7 routing using canonical names, url context and rule based. It has highly extensible pipeline architecture so that, new modules can be hooked into the pipeline without much work. Developers can add new switching rules and load balancing options easily. New modules can be added to send the log to API end point or load the configuration file from a DB or API. It is using JVM runtime environment, so developers can use either Java or Scala to add modules.
When to use Neutrino
Neutrino SLB strengh lies in its programmability and customizable nature. It is very easy to customize and adapt to a existing topology. Neutrino is distributed as a jar file, so that it can run as a standalone or can be wrapped around other applications
Neutrino can be used for the following Load Balancing and Switching requirements
Load Balancing Options
Least Connection
When a load balancer is configured to use the least connection method, it selects the server with the least number of active connections to ensure that the load of the active requests is balanced on the servers.
Round Robin
Round-robin load balancing is one of the simplest methods for distributing client requests across a group of servers. Going down the list of servers in the group, the round-robin load balancer forwards a client request to each server in turn
Switching Options
L7 Switching
L7 Switching is achieved using canonical names. Every HTTP request will have a url address in HOST header and Neutrino can look at the header and route the traffic to the appropriate pool. For eg, we can have two pools with two canonical names cname1.com and cname2.com.
L7 Context Based Switching
L7 Context Based Switching can be achieved using canonical names and url suffix. It is useful if the same canonical names is used for two services, but with different url suffix. For eg: cname1.com/first to point to one pool and cname1.com/second can point to another pool.
L4 Switching
L4 Switching can be achieved using multiple port number. Every service will be identified using a port number and traffic coming to each port number will be send to each pool. For eg: cname1.com:1185 point to one pool and cname1.com:1186 point to second pool.
