Software Load Balancer
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 More
Supports L7 Routing based on Canonical names, url context and traffic rules. L4 Routing is achieved by multiple port numbersRead More
Any number of SLBs can run in parrallel, can run in Container/VM/Bare MetalsRead More
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 APIs for ease of use.Read More
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.
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
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.
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
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 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
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 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 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.