Linux Cluster (Linux集群)
Cluster: 计算机集合, 为了解决某个特定问题而结合起来;
系统的扩展方式:
Scale Up: 向上扩展; 如: 向原有的机器添加内存, CPU.
Scale Out: 向外扩展; 如: 向原有的web系统, 邮件系统添加一台新机器.
如有兴趣了解世界排名的服务器, 可查询: www.top500.org 其内会定期评价服务器, 评价出向量机.
Linux Cluster类型:
LB: Load Balancing, 负载均衡;
特点: 能解决SPoF(Single Point of Failure), 但Director会成为性能瓶颈;
HA: High Availability, 高可用集群;
MTBF: 平均无故障时间;
MTTR: 平均故障修复时间;
Availability=MTBF/(MTBF+MTTR)
提高可用性主要有两个途径:
1.提高MTBF;
2.降低MTTR----冗余, 自动故障倒换, 监听探测heartbeat;
HP: High Perormance, 高性能集群;
DS: Distributed System, 分布式系统; hadoop, HDFS, Gluster FS, mogilefs, ......
Linux Cluster Director (调度器)
硬件:
F5 BIG-IP(性能好, 价格贵)
Citrix Netscaler (性能适中, 价格适中)
A10 A10 (性能稍差)
软件:
lvs: Linux Virtual Server (国人章文嵩开发)
nginx:
haproxy:
ats: Apache Traffic Server
perlbal:
pound:
基于工作的协议层划分:
传输层: 四层交换(在传输层实现的负载均衡)
lvs
nginx
haproxy
应用层:七层交换(在应用层实现的负载均衡)
httpd
nginx
haproxy
特殊的负载均衡:
fastcgi: httpd, nginx
mysql: mysql-proxy, MHA, Amoeba
lvs: Linux Virtual Server
Real Server
作者: 章文嵩
layer4: 四层交换, 四层路由;
ip:port : 根据请求报文的目标IP地址和协议的目标端口号将数据报文调度转发至后端的某个Real Server上; 在挑选Real Server的时候, 有一系列的调度算法可供选择;
iptables/netfilter: 作用于DNAT: PREROUTING链
ipvsadm/ipvs: 主要作用于INPUT链, 因此必须得清空INPUT链上的规则;
ipvsadm: 用户空间中的命令行工具, 规则管理工具, 用于集群服务及Real Server的管理;
ipvs:工作于内核空间中的netfilter的INPUT钩子之上的框架, 可以接收来自ipvsadm的管理命令;
ipvs可以支持诸如: TCP, UDP, SCTP, AH, ESP, AH_ESP等协议, 可以对此类协议的数据进行调度;
lvs集群中有下述几个常用术语:
vs: virtual server(调度服务器), Director, Dispatche, Balancer
rs: real server(真实服务器), backend server, upstream server
CIP: Client IP, 客户端IP地址, 即: 请求发送方的IP地址;
VIP: Virtual Server IP, 虚拟服务器的虚拟IP地址, 客户端访问的目的地址;
DIP: Director IP, 调度器IP地址, 向后方Real Server转发客户端请求时使用的IP地址;
RIP: Real Server IP, 后方真实服务器的IP地址;
使用lvs的一般通信过程:
CIP --> VIP --> DIP --> RIP
lvs的集群类型: lvs-nat lvs-dr lvs-tunnel lvs-fullnat
lvs-nat:
多目标IP地址的DNAT, 通过将请求报文中的目标地址和目标端口修改为某个利用调度算法挑选出来的后端RS的RIP和PORT的过程实现的转发;
注意下列几个问题:
1.RIP和DIP必须在同一网段, 并且应该是私有IP地址; RS的网关应该指向DIP;
2.请求报文和响应报文都必须经过Director转发, Director易于成为系统性能瓶颈并引发单点故障;
3.可以实现端口重定向; CIP向VIP发送的端口号可以与后端的RIP所提供服务的服务端口不同;
4.VS必须是Linux系统, RS可以是任意操作系统;
lvs-dr: 默认类型
dr: Direct Routing, 直接路由;
通过为请求报文重新封装一个数据链路层首部(MAC地址)进行报文转发; 重新封装之后的报文的源MAC地址是DIP所在网络接口的MAC地址; 目的地址是某个调度算法挑选出来的后端RS的RIP所在接口的MAC地址; 源IP地址和源PORT, 以及目的IP地址和目的PORT, 在整个报文转发过程中保持不变;
注意一下几个问题:
1.确保前端路由器能够将目标IP地址为VIP的报文发往VS(Director);
1) 在路由器上静态绑定IP地址和MAC地址的映射关系;
2) 在RS上使用arptables;
3) 在RS上修改内核参数限制ARP的通告和对ARP请求的应答;
arp_announce
arp_ignore
2.RS的RIP可以是私有地址也可以是共有地址, RIP和DIP应该在同一逻辑网络;
3.请求报文必须要经过Director, 但是所有响应报文不需要经过Director直接通过路由转发给客户端即可;
4.不支持端口重定向;
5.RS必须是Linux操作系统;
6.RS上必须配置RIP和VIP, 并且VIP应该配置在lo接口的lable上;
lvs-tun: tunnel, 隧道;
不修改请求报文的IP首部(源IP为CIP, 目的IP为VIP), 而是在原有的IP报文的封装格式之外再次封装一个IP首部(源IP为DIP, 目的IP为RIP), 将重新封装的报文发往使用调度算法挑选出的后端RS上;
注意以下几个问题:
1.CIP, VIP, DIP, RIP都应该是公有IP地址;
2.RS的网关无法指向DIP, 因此响应报文不会经过Director转发, 而是直接发往CIP;
3.不支持端口重定向;
4.RS必须支持隧道协议;
5.RS上必须配置RIP和VIP;
lvs-fullnat:
非标准类型;
通过同时修改请求报文的源IP地址和目的IP地址实现报文转发;
CIP --> DIP
VIP --> RIP
注意以下几个问题:
1.VIP是公有地址, DIP和RIP是私有地址, 且DIP和RIP可以不再同一网段;
2.RS对收到的请求报文的响应报文的目的地址是DIP, 所以请求报文和响应报文都必须经过Director;
3.支持端口重定向;
4.此类型默认不支持;
ipvs scheduler:
根据lvs在调度时是否考虑各RS当前的负载状态, 可以将调度算法分为两类:
静态算法: 根据算法本身的特点进行调度, 注重起点公平;
RR: RoundRobin, 轮询;
WRR: Weighted RR, 加权轮询;
SH: Source Hashing, 源地址哈希, 将来自于同一个IP地址的请求始终发往后端第一次被挑中的RS, 一般用于正向代理服务器集群;
动态算法: 主要根据每个RS当前的负载状态进度调度, 注重结果公平;
后端RS的负载, 用Overhead表示;
LC: least connections, 最少连接数;
连接有两种: 一种是active connection; 一种是inavtive connection;
Overhead=activeconnections*256+inactiveconnections
注意: 第一次调度时, 按照在ipvsadm中配置的顺序自上而下进行分配;
WLC: Weighted LC, 加权最小连接; (默认算法)
Overhead=(activeconnections*256+inactiveconnections)/weight
注意: 第一次调度时, 按照在ipvsadm中配置的顺序自上而下进行分配; 权重在第一次调度时不发挥作用;
SED: Shortest Expection Delay, 最短期望延迟;
Overhead=(activeconnections+1)*256/weight
注意: SED可以解决起点不公问题, 但是在权重差距比较大时候, 可能会导致不公平;
NQ: Never Queue, 改进版的SED算法, 首次调度时, 根据后端RS的权重依次为每台RS分配一个连接; 然后再按照SED算法调度; 必然会保证后端每台RS至少有一个activeconnection;
LBLC: Locality-Based Least Connections, 基于本地的最少连接, 动态的DH算法;
LBLCR: LBLC with Replication, 带有复制功能的LBLC;
原文地址：http://gt520.blog.51cto.com/12654264/1972661
