Mercury is an intelligent software loadbalancer which can distribution of traffic across server resources located in multiple geographies. The servers can be on premises in a company’s own data centers, or hosted in a private cloud or the public cloud.
Traditional Loadbalancers such as HA Proxy or Nginx are great for balancing traffic at a single endpoint, to forward or redirect this traffic to the nodes behind this endpoint in the same region. Globabl Loadbalancers such as F5 BigIP or Nginx Plus balance traffic using DNS techniques, which allow you to direct traffic to multiple regions. However these products are expensive and in some cases require specific hardware. With Mercury you have the power of a Global Loadbalancer, and its totally free and opensource!
Besides a Global loadbalancer, you can also user Mercury as normal Loadbalancer within your domain
- Binaries: https://github.com/schubergphilis/mercury/releases
- Documentation: http://mercury-global-loadbalancer.readthedocs.io/en/latest/
- Chef Cookbook: https://github.com/sbp-cookbooks/mercury
- OSX
- Linux (with iproute 3+)
- Global Load balancing across multiple datacenter or Cloud infrastructures using DNS based load balancing
- L4 and L7 Loadbalancing support
- Web GUI for viewing/managing your host state
- Seamless configuration updates without interrupting connected clients (e.g. reload your configuration without your clients noticing)
- Does HealthChecks on local backends, and propagates their availability across other GLB instances
- HTTP health checks (POST or GET)
- TCP Connect checks (connects only)
- TCP Data check (sends and/or expects data)
- ICMP/UDP/TCP ping checks
- None (always online)
- Is a functional DNS server which provides GLB based replies with
- Topology based load balancing, with predefined networks
- Preference based load balancing, for active/passive setup
- Round robin based load balancing for the most balanced setup
- LeastConnected based load balancing for the host with the least connections
- LeastTraffic based load balancing for the host with the least traffic
- Response time based load balancing for the host with the quickest response time
- Random based load balancing for when you can't choose
- Sticky based load balancing for client sticky cookies
- Is a full load balancer using the supported balancing methods
- Supports automated Error / Maintenance pages
- Includes checks for Nagios/Sensu to be used
- Internal DNS server supports most record types
- HTTP/2 support
- Web-socket support
- AD web login integration
For Linux there is a release package available on GitHub release tab here
You can also compile the latest version your self with the following commands:
$ make linux-package
$ rpm -i builds/packages/mercury-${version}.rpm
For other distributions:
$ make linux
OSX has no package, but you can run the following to create the binary:
$ make osx
To configure Mercury please look at the documentation described at ReadTheDocs:Mercury
You will find all possible configuration items documented here, including examples on a few specific use cases.
a Full list of supported TLS cyphers in the golang tls.Config package is here
The recommended cyphers are:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(tls 1.2 + HTTP/2)TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(tls 1.2)TLS_AES_256_GCM_SHA384(tls 1.3)TLS_AES_128_GCM_SHA256(tls 1.3)TLS_CHACHA20_POLY1305_SHA256(tls 1.3)
This combined with the mercury default settings, will make the SSLLabs checks give you an A+ in regards to security on SSL enabled web sites
Required for HTTP/2 is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 see RFC
Note that this has to be the first cipher in the list!
HTTP/2 also requires CurveP256 to be supported
You can browse to the web server within Mercury on the default url http://localhost:9001
In the web interface you can view all the global (cluster wide) and local vips, health checks, status and dns entries served.
Screenshot:
Alternatively you can use curl to read the status
$ curl http://localhost:9001/backend
$ curl http://localhost:9001/glb
Ready to use for monitoring with nagios/sensu.
for json output pass the following option:
$ curl http://localhost:9001/backend -H 'Content-Type: application/json'
There are a few checks which you can execute, and implement them in your monitoring system
Checking all of the Global Load balancing and cluster nodes in a single check
$ mercury -config-file /etc/mercury/mercury.toml -check-glb
OK: All checks are fine!
Checking all of the Backend nodes
$ mercury -config-file /etc/mercury/mercury.toml -check-backend
You can seperate the checks using additional parameters
- Checking a specific pool/backend
$ mercury -config-file /etc/mercury/mercury.toml -check-backend -pool-name example_https_443 -backend-name www_example_com
- Checking the Cluster nodes specificly
$ mercury -config-file /etc/mercury/mercury.toml -check-glb -cluster-only
- Checking a specific glb entry
$ mercury -config-file /etc/mercury/mercury.toml -check-glb -dns-name www.example.com
Exitcodes are nagios/sensu compatible:
- All is fine
- Warning
- Critical
-
Clone this repository from GitHub:
$ git clone git@github.com:schubergphilis/mercury.git -
Create a git branch
$ git checkout -b my_bug_fix -
Install dependencies:
$ make deps -
Make your changes/patches/fixes, committing appropriately
-
Write tests
-
Run tests
$ make test
- Author: Ronald Doorn (<rdoorn@schubergphilis.com>)
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.