Data Center手册(3): Load Balancer
Load Balancer的类型
DNS Round-Robin
这是一种很常见的分流的方式，具体配置如下：
- name server有一个zone文件，对于同一个domain，有多个IP
www.example.com IN A 192.0.2.80
www.example.com IN A 192.0.2.50
- 当有客户端请求www.example.com的时候，返回所有的IP，但是顺序则需要配置
- name server可以配置成rrset-order，所有的IP轮流在最前面
- 每个客户端得到的IP顺序都不一样，可能会选择不同的服务器去连接。
DNS Round-Robin有很多缺点：
- 对于流量的分配不是很均衡
- 不能确认服务器是否健康
- 不能确认服务器的负载
Server Load Balancer
它可以解决上面的问题，它可以监控服务器的状态和负载，尽量均匀的分配流量。
当然也有特殊情况，比如对于电子商务系统，需要确保TCP connection从80端口来的，相同的用户始终指向同样的服务器，443端口的连接，来自同一用户的，也需要指向同一服务器，因为可能用户正在进行transaction的操作。
Load Balancer使用virtual server和virtual IP，将真正的服务器隐藏起来，用户认为连接的是同一个服务器。
Cache Load Balancer
Cache LB也是将流量分散给多个cache server，但是还有另外的需求，就是需要增加命中率，如果不能命中，则还需要到缓存后面的真正存储拿数据，则降低了性能。
所以传统的round-robin是不能用的，可以想象一个请求发送到了第一个cache server，刚把数据cache起来，第二个请求发送给了第二个cache server，压根没有起到缓存的作用。
常用的如一致性哈希等方法。
VPN/IPSec Load balance
为了增加VPN/IPsec tunnel的数量，可以在VPN aggregation point有一个load balancer和多个VPN concentrator
下面的图是EC2 VPC的VPN的配置
单一VPN 连接
多VPN 连接
为您的 VPN 连接配置两条 VPN 隧道
使用冗余 VPN 连接以提供故障转移
Firewall Load Balancer
多个firewall被夹在两层Load Balancer之间，Load Balancer需要处理firewall处理的所有协议，从而对inbound和outbound选择适当的firewall
Load Balance 过程
- Client发出DNS请求，请求www.example.com的IP
- DNS返回一个VIP 10.10.10.100
- Client通过VIP连接到Load Balancer上
- Load Balancer收到连接请求，解析收到的信息IP, protocal, port等
- 如果这是一个新的连接，则load balancer查看一些policy，如L4/L5，选择一个server
- 在发送package之前，load balancer计算checksum，甚至改写包头，最终将包发送给server
- 当和server之间的连接建立之后，load balancer汇总connection table中加一项来维护这个连接
- 当server有返回的时候，load balancer会改写包，更新connection table，返回给client
Load balancer功能
L4 load balancing
基于L4的信息进行负载均衡，如protocal, source/dest IP, port等
L5/application layer load balancing
使用L5信息，如果HTTP, SMTP, FTP等信息进行LB
Connection Tracking
LB维护连接的状态信息，主要用于：
首先，方便进行package的查看和改写，因为记录了inbound和outbound的接口，source/dest的IP, protocal, port
其次，将连接信息复制到另外一个server，如果主LB失败了，可以从备LB重建连接。
Connection Persistence
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair.
LB需要能够保持TCP connection是打开的，同时对于每一个http request，可以选择不同的backend server
Session Persistence
一个client的transaction可能包含多个connection
Session Persistence又称sticky connections，意思是将多个connection组成一组，成为一个session
在电子商务中，这个很重要，如图
当一个用户登录www.example.com的时候，建立一个http连接，当用户选择一个物品，放入购物车的时候，又打开一个http连接，这两个连接应该到一个server上，最终用户付款，要建立https连接，由于购物信息都在server 3上，因而这个https的连接也应该到server 3上。
那么如何保证session persistence呢
一种方法是通过source IP，但是如果client是通过proxy访问的，source IP很可能会变
另一种方法是用cookie，cookie的值可以标识一个用户，但是如果是https，则LB不可能知道cookie的内容。
在https中，是否可以用SSL ID呢，也不靠谱，SSL ID在v2中也是加密的，在V3中不加密，你无法确定客户的SSL版本。即便确定了SSL ID，这个值可以再rehandshake中改变。
也可以这样，https连接时连到LB，从LB到后端不加密，则在LB上就可以直接解密，得到cookies
另外一种方法是http redirection，client会连接LB的VIP，当连接建立后，当发现用户开始购物的时候，LB根据TCP connection中URL的内容，匹配某个content policies，返回一个http redirection，将结果redirect到另一个VIP，srv3.example.com，这个VIP仅仅对应一个server，则后续的数据都发送到这个server上。
Server Health
两种方式，一个是in-band，并不主动监听，而是通过已建立的连接被动监听。对应用程序是否正常工作不能保证。
另一种是out-of-band，主动监听：
- server availability: ICMP是否有回应
- Application availability: 是否能建立连接，是否监听端口
- application consistency：返回的数据是否正确，比如本地保存index.html，过一段时间拿一次，比较是否相同。
HA of LB
Active-Passive
Active-Active
