Google开源软负载seesaw

https://github.com/google/seesaw

 ------------------------

在分布式系统中，负载均衡是很是重要的环节，经过负载均衡将请求派发到网络中的一个或多个节点上进行处理。一般来讲，负载均衡分为硬件负载均衡及软件负载均衡。硬件负载均衡，顾名思义，在服务器节点之间安装专门的硬件进行负载均衡的工做，F5便为其中的佼佼者。软件负载均衡则是经过在服务器上安装的特定的负载均衡软件或是自带负载均衡模块完成对请求的分配派发。

通常而言，有如下几种常见的负载均衡策略：

一.轮询。做为很是经典的负载均衡策略，早期该策略应用地很是普遍。其原理很简单，给每一个请求标记一个序号，而后将请求依次派发到服务器节点中，适用于集群中各个节点提供服务能力等同且无状态的场景。其缺点也很是明显，该策略将节点视为等同，与实际中复杂的环境不符。加权轮询为轮询的一个改进策略，每一个节点会有权重属性，可是由于权重的设置难以作到随实际状况变化，仍有必定的不足。

二.随机。与轮询类似，只是不须要对每一个请求进行编号，每次随机取一个。一样地，该策略也将后端的每一个节点是为等同的。另外一样也有改进的加权随机的算法，再也不赘述。

三.最小响应时间。经过记录每次请求所需的时间，得出平均的响应时间，而后根据响应时间选择最小的响应时间。该策略能较好地反应服务器的状态，可是因为是平均响应时间的关系，时间上有些滞后，没法知足快速响应的要求。所以在此基础之上，会有一些改进版本的策略，如只计算最近若干次的平均时间的策略等。

四. 最小并发数。客户端的每一次请求服务在服务器停留的时间可能会有较大的差别,随着工做时间加长,若是采用简单的轮循或随机均衡算法,每一台服务器上的链接进程可能会产生较大的不一样,并无达到真正的负载均衡｡最小并发数的策略则是记录了当前时刻，每一个备选节点正在处理的事务数，而后选择并发数最小的节点。该策略可以快速地反应服务器的当前情况，较为合理地将负责分配均匀，适用于对当前系统负载较为敏感的场景。

五.哈希。在后端节点有状态的状况下，须要使用哈希的方法进行负载均衡，此种状况下状况比较复杂，本文对此不作探讨。

另外还有其余的负载均衡策略再也不一一列举，有兴趣的同窗能够本身去查阅相关资料。

分布式系统面临着远比单机系统更加复杂的环境，包括不一样的网络环境、运行平台、机器配置等等。在如此复杂的环境中，发生错误是不可避免的，而后如何可以作到容错性，将发生错误的代价下降到最低是在分布式系统中必需要考虑的问题。选择不一样的负载均衡策略将会有很是大的不一样。

------------------------

Seesaw v2

Note: This is not an official Google product.

About

Seesaw v2 is a Linux Virtual Server (LVS) based load balancing platform.

It is capable of providing basic load balancing for servers that are on the same network, through to advanced load balancing functionality such as anycast, Direct Server Return (DSR), support for multiple VLANs and centralised configuration.

Above all, it is designed to be reliable and easy to maintain.

Requirements

A Seesaw v2 load balancing cluster requires two Seesaw nodes - these can be physical machines or virtual instances. Each node must have two network interfaces - one for the host itself and the other for the cluster VIP. All four interfaces should be connected to the same layer 2 network.

Building

Seesaw v2 is developed in Go and depends on several Go packages:

• golang.org/x/crypto/ssh
• github.com/dlintw/goconf
• github.com/golang/glog
• github.com/golang/protobuf/proto
• github.com/miekg/dns

Additionally, there is a compile and runtime dependency on libnl and a compile time dependency on the Go protobuf compiler.

On a Debian/Ubuntu style system, you should be able to prepare for building by running:

apt-get install golang
apt-get install libnl-3-dev libnl-genl-3-dev

If your distro has a go version before 1.5, you may need to fetch a newer release from https://golang.org/dl/.

After setting GOPATH to an appropriate location (for example ~/go):

go get -u golang.org/x/crypto/ssh
go get -u github.com/dlintw/goconf
go get -u github.com/golang/glog
go get -u github.com/miekg/dns
go get -u github.com/kylelemons/godebug/pretty

Ensure that ${GOPATH}/bin is in your ${PATH} and in the seesaw directory:

make test
make install

If you wish to regenerate the protobuf code, the protobuf compiler and Go protobuf compiler generator are also needed:

apt-get install protobuf-compiler
go get -u github.com/golang/protobuf/{proto,protoc-gen-go}

The protobuf code can then be regenerated with:

make proto

Installing

After make install has run successfully, there should be a number of binaries in ${GOPATH}/bin with a seesaw_ prefix. Install these to the appropriate locations:

SEESAW_BIN="/usr/local/seesaw"
SEESAW_ETC="/etc/seesaw"
SEESAW_LOG="/var/log/seesaw"

INIT=`ps -p 1 -o comm=`

install -d "${SEESAW_BIN}" "${SEESAW_ETC}" "${SEESAW_LOG}"

install "${GOPATH}/bin/seesaw_cli" /usr/bin/seesaw

for component in {ecu,engine,ha,healthcheck,ncc,watchdog}; do
  install "${GOPATH}/bin/seesaw_${component}" "${SEESAW_BIN}"
done

if [ $INIT = "init" ]; then
  install "etc/init/seesaw_watchdog.conf" "/etc/init"
elif [ $INIT = "systemd" ]; then
  install "etc/systemd/system/seesaw_watchdog.service" "/etc/systemd/system"
  systemctl --system daemon-reload
fi
install "etc/seesaw/watchdog.cfg" "${SEESAW_ETC}"

# Enable CAP_NET_RAW for seesaw binaries that require raw sockets.
/sbin/setcap cap_net_raw+ep "${SEESAW_BIN}/seesaw_ha"
/sbin/setcap cap_net_raw+ep "${SEESAW_BIN}/seesaw_healthcheck"

The setcap binary can be found in the libcap2-bin package on Debian/Ubuntu.

Configuring

Each node needs a /etc/seesaw/seesaw.cfg configuration file, which provides information about the node and who its peer is. Additionally, each load balancing cluster needs a cluster configuration, which is in the form of a text-based protobuf - this is stored in /etc/seesaw/cluster.pb.

An example seesaw.cfg file can be found in etc/seesaw/seesaw.cfg.example - a minimal seesaw.cfg provides the following:

• anycast_enabled - True if anycast should be enabled for this cluster.
• name - The short name of this cluster.
• node_ipv4 - The IPv4 address of this Seesaw node.
• peer_ipv4 - The IPv4 address of our peer Seesaw node.
• vip_ipv4 - The IPv4 address for this cluster VIP.

The VIP floats between the Seesaw nodes and is only active on the current master. This address needs to be allocated within the same netblock as both the node IP address and peer IP address.

An example cluster.pb file can be found in etc/seesaw/cluster.pb.example - a minimal cluster.pb contains a seesaw_vip entry and two node entries. For each service that you want to load balance, a separate vserver entry is needed, with one or more vserver_entry sections (one per port/proto pair), one or more backends and one or more healthchecks. Further information is available in the protobuf definition - see pb/config/config.proto.

On an upstart based system, running restart seesaw_watchdog will start (or restart) the watchdog process, which will in turn start the other components.

Anycast

Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable. For this to work the Quagga BGP daemon needs to be installed and configured, with the BGP peers accepting host-specific routes that are advertised from the Seesaw nodes within the anycast range (currently hardcoded as 192.168.255.0/24).

Command Line

Once initial configuration has been performed and the Seesaw components are running, the state of the Seesaw can be viewed and controlled via the Seesaw command line interface. Running seesaw (assuming /usr/bin is in your path) will give you an interactive prompt - type ? for a list of top level commands. A quick summary:

• config reload - reload the cluster.pb from the current config source.
• failover - failover between the Seesaw nodes.
• show vservers - list all vservers configured on this cluster.
• show vserver <name> - show the current state for the named vserver.

Troubleshooting

A Seesaw should have five components that are running under the watchdog - the process table should show processes for:

• seesaw_ecu
• seesaw_engine
• seesaw_ha
• seesaw_healthcheck
• seesaw_ncc
• seesaw_watchdog

All Seesaw v2 components have their own logs, in addition to the logging provided by the watchdog. If any of the processes are not running, check the corresponding logs in /var/log/seesaw (e.g. seesaw_engine.{log,INFO}).