Cluster LAMP
假定：perfork 2M 动态10M
200个请求----->1000个请求（800静态+200动态） 800*2+200*10=3.6G Memory
资源瓶颈： Scale On： 向上扩展，加CPU， Memoey， Net ， Storage Scale Out：向外扩展，
Load Balancing : LB RR： 轮询 WRR：加权
集群
1、负载均衡集群：Load Balancing 并发处理能力
rsync + inotify
2、高可用集群：High Availablity 在线时间 / (在线时间 + 故障处理时间)
DAS：Direct Attached Storage block 级别，速度快、脑裂 NAS：Network Attached Storage
Split-Brain 脑裂
STONITH： Shoot The Other Node In The Head Fencing：隔离 。节点级别隔离，资源级别隔离
3、HPC：High Performance compute
向量机
并行处理集群：分布式文件系统、任务切割机制 分布式存储：分布式文件系统 Hadoop
负载均衡： Hareware: F5 ,BIG IP NetScaler A10
Radware
Software: 四层：LVS
七层：nginx haproxy
Nginx和LVS对比的总结：
1、Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所以Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，触碰多了，人为出问题的几率也就会大。 2、Nginx对网络稳定性的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，这是Nginx的一大优势！Nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。
3、Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了；LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的。
5、Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，
apache上就不会堆积过多的请求，这样就减少了相当多的资源占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。
7、Nginx能支持http、https和email（email的功能比较少用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析，如果是比较小的网站（日PV小于1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS。
LVS: Linux Virtual Server lvs 和 iptables 不能共同使用
lvs ipvsadm管理集群服务 / ipvs内核
LVS类型
NAT：地址转换 DR：直接路由 TUN：隧道
NAT:
集群节点跟director必须在同一个IP网络中； RIP通常是私有地址，仅用于各集群节点间的通信；
director位于client和real server之间，并负责处理进出的所有通信； realserver必须将网关指向DIP； 支持端口映射；
real server可以使用任意OS；
较大规模应该场景中，director易成为系统瓶颈；
? ? ?
The cluster nodes need to be on the same network (VLAN or subnet) as the Director. The RIP addresses of the cluster nodes are normally private, non-routable IP addresses
used only for intracluster communication.
The Director intercepts all communication (network packets going in either direction)
between the client computers and the real servers.
? ? ? ?
The cluster nodes use the Director's DIP as their default gateway for reply packets to the
client computers.
The Director can remap network port numbers. That is, a request received on the
Director's VIP on one port can be sent to a RIP inside the cluster on a different port.
Any type of operating system can be used on the nodes inside the cluster. A single Director can become the bottleneck for the cluster.
DR:
集群节点跟director必须在同一个物理网络中；
RIP可以使用公网地址，实现便捷的远程管理和监控；
director仅负责处理入站请求，响应报文则由realserver直接发往客户端； realserver不能将网关指向DIP； 不支持端口映射；
? ? ? ? ? ? ?
The cluster nodes must be on the same network segment as the Director.
The RIP addresses of the cluster nodes do not need to be private IP addresses.
The Director intercepts inbound (but not outbound) communication between the client
and the real servers.
The cluster nodes (normally) do not use the Director as their default gateway for reply
packets to the client computers.
The Director cannot remap network port numbers.
Most operating systems can be used on the real servers inside the cluster. An LVS-DR Director can handle more real servers than an LVS-NAT Director.
Real server 不能解析（屏蔽）client 的arp 请求（client 广播vip询问vip的mac地址） VIP: MAC(DVIP) arptables：
kernel 2.4.26 and 2.6.4 come with 2 new device flags for tuning the ARP stack: arp_announce and arp_ignore.
arp_announce: Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface.
arp_ignore: Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses.
kernel parameter:
arp_ignore - INTEGER
0 - (default): reply for any local target IP address, configured on any interface
1 - reply only if the target IP address is local address configured on the incoming interface
2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved
8 - do not reply for all local addresses arp_announce - INTEGER
0 - (default) Use any local address, configured on any interface.
1 - Try to avoid local addresses that are not in the target's subnet for this interface.
2 - Always use the best local address for this target.
arp_ignore: 定义接收到ARP请求时的响应级别； 0：只要本地配置的有相应地址，就给予响应；
1：仅在请求的目标地址配置请求到达的接口上的时候，才给予响应；
arp_announce：定义将自己地址向外通告时的通告级别； 0：将本地任何接口上的任何地址向外通告；
1：试图仅向目标网络通告与其网络匹配的地址； 2：仅向与本地接口上地址匹配的网络进行通告；