#IPVS负载均衡（二）LVS集群介绍
以下内容主要摘自zhangwensong博士的博客
介绍LVS之前，需要先说一下LVS的产生需求：
针对LVS需求，我们给出了基于IP层和基于内容请求分发的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的服务器集群，我们称之为Linux虚拟服务器（Linux Virtual Server）。
##LVS集群的通用结构
LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
我们组用的主要是IP负载均衡技术，也就是所介绍的IPVS负载均衡
###负载调度器（load balancer）
它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址上的。它可以是用IP负载均衡技术的负载调度器，也可以是基于内容请求分发的负载调度器，还可以是两者的结合。
个人了解，主要使用的是基于IP负载均衡技术的负载调度器
- 调度器主要采用IP负载均衡技术
- 在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务
- 调度器只根据负载情况从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器
- 由于所有的操作都是在操作系统核心空间中将完成的，它的调度开销很小，所以它具有很高的吞吐率。
个人测试：
测试平台：AWS公有云、EC2
虚拟机类型：c3.xlarge和c3.8xlarge
测试工具：nuttcp(开源)和组内程序，两种测试(其实测试核心程序是我写的。。。。)
测试结果：单LVS，c3.8xlarge可以达到65万pkts每秒，流量大小为单向8Gbps，丢包率低于十万分之一(这个结果在在知乎搜一搜一大堆，性能数据都差不多)
测试结论：
具体结果是公司内部资料，不可泄露；AWS底层流量、路由能力非常强悍，很强悍，具体数据保密，反正完爆阿里云补充：仍有很大优化能力（个人建议要使用FULL-NAT模式）
###服务器池（server pool）
是一组真正执行客户请求的服务器。
- 服务器池的结点数目是可变的
- 当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载
- 对大多数网络服务来说，结点与结点间不存在很强的相关性，所以整个系统的性能可以随着服务器池的结点数目增加而线性增长
第三条说得其实并不正确，因为还有其他很多的限制条件，实际上整个系统在实际应用中并不会线性增加；个人经验是：扩展10~100倍之后就需要拆分业务、架构，否则会有瓶颈；
其他限制条件：譬如达到单个or单组IPVS上限（IPVS负载均衡器实际上肯定是需要多个，进行互相备份的，个人觉得应该是n+2模式这种备份；还需要keepalive对服务器进行实时监控）
###后端存储（backend storage）
它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
- 后端存储通常用容错的分布式文件系统，譬如分布式数据库、memcache、redis
这个其实云服务商基本都提供吧，反正云帮你省了很多I层和P层的事，让你更好的专注于服务和内容！
##总结
IPVS即现在所谓的P层，硬件或者虚拟化硬件、虚拟化虚拟机、容器则是I层，服务器池是S层，后端存储有数据库、分布式数据库、memcache、redis等等，属于P层---还是蛮符合现在硬件、数据、服务分离的思维的