一、回顾
1、Linux Cluster
a、LB/HA/HP
b、分布式系统：存储/计算
2、LB Cluster
a、硬件：F5-BigIP/Netscaler/A10
b、软件：
四层：lvs（真四层），伪四层：nginx（stream）/haproxy（mode tcp）
七层：http：nginx（http）/httpd/haproxy（mode http）/ats/peribal/pound
mysql：ProxySQL，...
3、lvs：Linux Virutal Server
a、vs/rs；cip/vip/dip/rip
b、lvs type：
nat/dr/tun/fullnat
nat类型：多目标IP的DNAT，通过修改请求报文的目标IP和PORT来实现调度
dr类型：通过为请求报文重新封装一个MAC首部进行转发：源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址
二、LVS（2）
1、lvs-tun
a、转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而是在原IP报文之外再封装一个IP首部（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP是CIP）；
b、DIP，VIP，RIP都应该是公网地址
c、RS的网关不能，也不可能指向DIP
d、请求报文要经由Director，但响应不能经由Director
e、不支持端口映射
f、RS的OS得支持隧道功能
g、在nat和DR模式中，我们双绞线的最大传输距离只有一百米，并且DIP所属的网卡与RIP所属的网卡需要在同一个物理网络。这两种方式所能带来的结果就是你的RS和Director都应该在非常近的距离上，一般来讲他是无法跨机房的。那么如果我想做灾备的话要怎么办呢？即假如我们有两个RS，一个在东京机房，一个在北京机房，还有一个在纽约机房，假如我们东京机房翻车了我们北京和纽约机房还能正常工作。如果都托管在东京的话一翻车就全翻车了，如果是这种方案的话前两种模式就都没法工作了，这种的话就需要用到我们的隧道模型。隧道模型指的是互连网上有一个主机当Director，后面的RS可以是互联网上其它地方的主机，这些主机上也都可以配置好VIP地址。和我们DR模型一样他们也应该有VIP，因为对tun模型来讲也是请求报文要有Director而响应报文没有Director，即请求报文要过Director而响应报文是由RS直接响应给客户端的。在我们DR模式中我们说过在RS上不能做ARP广播通告也不能做响应，而我们在做tun模式时各主机因为也要做VIP那么是否也需要不能做ARP广播通告和做响应呢？其实是不用的，因为大家都不在同一网络中，我们广播和通告只是在本地局域网中实现的，所以是不会有任何干扰的。那么我们因为都有VIP那么用户请求直接发给了RS了要怎么办呢？这个其实可以这样来，既然大家相距很远那么所属的网段就不同，在互联网上一个网段，比如12.12.12.0，可不可能在不同区域的RS上分布呢？这是不可能的。因此假如我们对外宣称的VIP地址是互联网上的可达地址并且配置在Director上，所以只有Director这个地址在互联网上路由器路由可达的，因为在Director上这个地址一定所属的网络必须是你的直接地址所应该属于的网络，所以假设我们的Director的地址是12.12.12.1/24，我们其它的RS上是不可能是12.12.12.0网络中。所以我们后端的RS上配置的VIP和自身的RIP肯定是不在同一网段的。
所以基于此互连网上用户的请求报文主要是对这个VIP进行请求，如果我们要VIP可达的话那么这个地址得属于你的Director主机上所配置的网络中的某一地址才行，既然他只能送到VIP这个网络，只要我们各RS没有与Director在同一个网络中那么他们都不可能收到请求的。至少说不可能直接收到请求。所以所有在互联网上的报文请求都应该而且只能路由给Director，也不无需配置其它东西，那么到Director的报文怎么转发到RS呢？
当用户请求到达Director时，源IP为CIP，目标IP为VIP，Director收到请求报文以后一看目标IP是自己，于是交给INPUT，INPUT一检查是集群服务，于是该转发了，他转发后目标IP就发不出去了，这时候要怎么办呢？在请求报文中有我们原来的源CIP，目标地址VIP等IP守护，这些都不会动，相当于Director会在此守护之外重新封装一个IP，这个IP守护中的源IP是DIP，目标IP是某一个RIP，很显然他扔回来给路由器，即给自己网关，然后网关就以RIP来作为目标IP进行路由了，RIP应该是后端的RS中的某一个RS的地址，比如是D网络中的主机，此时我们的B和C网络是不会收到报文请求的。D网络中的主机RS1收到报文后发现目标IP是自己的IP，于是拆除封装，然后一看又有一个IP守护，他就会觉得莫名其妙，因此我们这个RS必须要理解隧道的功能协议才行，知道为什么会有两层IP报文守护，于是拆开外层IP报文守护以后发现内层IP守护居然是VIP，我们的VIP是不是我们RS1自己也有呢，于是继续拆，然后他就会认为这个报文请求的是VIP的某个端口，而VIP肯定是自己啊，端口肯定是本地某一个端口，所以响应报文就交给这个进程，既然请求报文目标地址是VIP于是他封装响应报文时，比如他发回去的时候，源IP就是自己的VIP，目标IP就是CIP，然后就直接扔到互联网上，然后路由以后CIP就收到了。就完成了我们请求和响应报文的传输。
20:06
2、lvs-funllnat
a、通过同时修改请求报文的源IP地址和目标IP地址进行转发；
1）、CIP --> DIP
2）、VIP --> RIP