构建集群的基础理论

    集群分为LB、HA、HP，负载均衡集群只是提高了服务的质量，高可用集群则是重在提供集群服务的稳定性，并行处理集群则在大数据的高度计算能力上又有着很重要的地位，构成集群有这么几层结构，Client、schedule和Server。通过schedule的调度可以将用户的请求发送给server，再由server做出响应，又有着NAT，DR和TUN三种结构，至于每种结构的配置方法，大家自行搜索，很容易找到。

    这里还要提到，既然是集群，分布式处理数据、备份和安全必然是很重要的概念，分布式表现在请求在server上的选择，这里就会涉及到各种各样的调度算法，而对服务器的备份，无形之中会加重系统的负担以及一旦一台server损坏，这样一来，服务器的健康状态的检测也是要在考虑范围之内。为了避免不同的客户端通过同一个server写数据，而造成文件系统的错乱，锁机制的采用也很有必要。在现实生活中，当不同的服务有必要绑定在同一个server上的时候的服务的绑定，也要学会配置。以上这些问题都是后端server的各种问题，此处只是做出列举和总结。

    着重讲解前段的schedule，既然存储有了备份，那么，调度器是不是也该备份的，答案是肯定的，而调度器工作时，也绝非想的那么简单，此处画图示例。（而且，一旦其中一个调度器损坏，对数据的请求失去处理能力，这是你就会看到你的浏览器上，显示不到任何界面，我们此时一旦发现出现这种情况，这台调度器会被STONITH（爆头），而前面的服务器只不过是暂时将数据进行了转移，而且避免不同的server通过同一个schedule写文件，造成文件系统的错乱，在schedule上是集群文件系统，只能应用在DAS和SAN的存储上）

    

    Massage Layer:事物信息层，根据心跳信息，判定schedule是否在线，再做出相应的的反应

    CRM:集群管理层，是一个通用层，是将Massage Layer的信息，传递给RA，有RA来代为管理集群节点，将那些期望提供高可用服务，但不具备高可用服务能力的应用程序实现高可用功能

    RA:资源代理，真正的对server的IP、服务等各项服务做出管理的各类应用程序

    以上各个层次都有着对应的软件来实现管理

Message Layer：

  Heartbeat(v1,v2,v3)

  Corosync

  Cman

  Keepalived

  Ultramokey

CRM:

 haresource,crm (heartbeat v1/v2)

 pacemaker (heartbeat v3/corosync)

 rgmanager(cman) 

RA Classes:

 Legacy heartbeat v1 RA

  LSB(/etc/init.d)

  OCF(Open Cluster Framework)

    pacemaker

    linbit

 STONITH