凡是企业关键应用都对可用性有严格的要求，因为短时间的业务中断就可能给客户造成不可估量的损失。
举例来说，如果某宝或者某东的网站有几分钟不能访问，相信损失不下百万，并且一定能成为新闻热点。
图1 系统高可用基本示意图由此可以看出，对于大型企业的关键应用，可用性是最为重要的指标。
常规的高可用架构如图1所示，本文以2台服务器为例进行介绍，通常为1主1备，通过集群管理软件进行管理。
正常情况下主服务器通过虚拟IP对外提供服务，当主服务器出现故障（故障包括业务软件崩溃、网卡故障、访问数据库异常和访问后端存储异常等等）时，集群管理软件将业务切换到备服务器。
由图1可以看出，由于服务端通常是要有数据的，而为了保证切换后服务的完整性，显然数据必须一致，因此高可用架构的服务器通常要有一个共享存储（后面介绍没有共享存储的方案）。
企业应用的高可用设计除了业务软件必须考虑容错外，还需要依赖很多外部软件，比如存储数据的数据库等。
这些被依赖的软件也要考虑容错。
对于数据库来说，其中Oracle RAC就是数据库高可用的解决方案。
如果钱不是问题自然可以考虑商用软件，但商用软件毕竟价格不菲。
因此，本文将介绍一些在实际生产环境中经常用到的开源、免费的高可用软件。
集群管理软件首先介绍一下什么是集群，集群就是通过软件将一组服务器作为一个整体向客户提供资源的服务器集合。
而单个的服务器就是集群的节点。
集群的一个显著特点是其通过多个节点提高业务的可用性和负载能力，当对外提供资源的节点故障后，集群中其余的节点能够将资源接管起来，继续对客户提供资源。
集群管理软件，顾名思义就是对集群进行管理的软件。
由于在一个集群中运行这各种软件，而且又依赖各种资源，因此需要用一个软件进行管理，并且能够应对各种故障。
比如在网络链路出现故障时如何处理、磁盘故障是如何处理、进程崩溃时如何处理等等。
关于集群管理软件，商业的很多，诸如VCS和BCP等，本文介绍几款比较著名的开源集群管理软件。
目前在生产中用的比较多的是Linux-HA（又叫Heartbeat）和keepalived。
HeartbeatHeartbeat是一个比较老牌的集群管理软件，最新版本是V3.0， 也称为Heartbeat 3。
目前该项目被拆分为多个子项目，包括Heartbeat、Pacemaker和Cluster Glue等。
通过Heartbeat，可以实现对服务器资源（ip以及程序服务等资源）的监控和管理，并在出现故障的情况下，将资源集合从一台已经故障的计算机快速转移到另一台正常运转的机器上继续提供服务。
图2 Heartbeat整体架构KeepalivedKeepalived也是一款高可用集群管理软件，其基本功能与Heartbeat非常类似，它的功能主要包括两方面：1）通过IP漂移，实现服务的高可用：服务器集群共享一个虚拟IP，同一时间只有一个服务器占有虚拟IP并对外提供服务，若该服务器不可用，则虚拟IP漂移至另一台服务器并对外提供服务；2）对LVS应用服务层的应用服务器集群进行状态监控：若应用服务器不可用，则keepalived将其从集群中摘除，若应用服务器恢复，则keepalived将其重新加入集群中。
Keepalived可以单独使用，即通过IP漂移实现服务的高可用，也可以结合LVS使用，即一方面通过IP漂移实现LVS负载均衡层的高可用，另一方面实现LVS应用服务层的状态监控，如图所示：图3 Keepalived架构示意图Keepalived原理Keepalived的实现基于VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议），而VRRP是为了解决静态路由的高可用。
VRRP的基本架构如图所示：图4 Keepalived基本原理虚拟路由器由多个VRRP路由器组成，每个VRRP路由器都有各自的IP和共同的VRID(0-255)，其中一个VRRP路由器通过竞选成为MASTER，占有VIP，对外提供路由服务，其他成为BACKUP，MASTER以IP组播（组播地址：224.0.0.18）形式发送VRRP协议包，与BACKUP保持心跳连接，若MASTER不可用（或BACKUP接收不到VRRP协议包），则BACKUP通过竞选产生新的MASTER并继续对外提供路由服务，从而实现高可用。
数据库商用数据库中Oracle在可用性上基本上做到了极致，Oracle RAC加上DG基本可以应付所有的场景，极大的保证应用的可用性。
而开源领域，MySQL恐怕最流行的开源数据库吧，应该没有之一。
MySQL在可用性方面目前有多种解决方案，但目前官方都是主备方案，无法达到真正的双活。
目前在网上普遍的所谓双主方案中也只是从服务器可以同时提供查询的功能，并不能多主同时更新数据。
图5 MySQL主备请求流程图如图5是MySQL主备流程示意图。
对于写数据，请求发送到主节点，节点先写到本地binlog，然后发送到从节点的replay log，成功后给客户端返回成功。
由于两个动作分布在2个节点，而整个流程无法保证事务性，因此会有主从不一致的情况。
虽然如此，但对于免费产品，已经非常不错了。
据说某云对MySQL进行了加强，可以实现真正意义多活的部署，但本人并没有实际用过。
文件系统在图1的方案中如果使用的是普通的文件系统，通常业务通常只能做到主备，而无法做到双活。
这是由本地文件系统的特性决定的。
我们以常规Web服务为例进行说明，假设后端存储存储的是静态图片等数据。
如果两个服务器都可以同时访问同一个磁盘，那么就存在文件系统同时对磁盘的数据进行更改的情况，这就出现服务器1进行了修改，而服务器2不知道，又进行充分修改的情况。
如果修改的是普通数据，将导致数据混乱，而如果修改了元数据，将可能破坏整个文件系统，从而导致数据的丢失。
为了解决这个问题，可以使用集群文件系统例如Oracle的ocfs2文件系统，这个是开源，免费的集群文件系统。
集群文件系统的最大特点是将多个服务器组成一个集群，而且每个服务器都可以访问这个集群。
ocfs2文件系统之所以可以实现对同一个磁盘的并发多活访问，其原因是实现了一个分布式锁。
也就是该文件系统在进行数据修改的时候会进行全局加锁，保证只有一个服务器对数据进行修改，而不会出现普通文件系统所出现的数据冲突的问题。
本文仅仅是做科普介绍，更详细的内容请看本文的历史文章。
图6 集群文件系统架构磁盘容灾大家可能发现了，前面的高可用方案中都用到了共享存储。
共享存储毕竟是比较昂贵的设备，如果没有共享存储怎么办？本节将介绍一个没有共享存储的方案，就是通过一个名为DRBD的开源软件。
目前该软件已经集成到Linux内核当中。
图6 DRBD整体架构图该软件实现了一个基于网络的RAID1功能，也就是说该软件可以将两台服务器上的磁盘组建成为一个RAID1。
这样，当向服务器1的磁盘写数据的时候，数据会通过网络同时写到服务器2的磁盘上面。
通过这个软件，可以保证两台服务器上的磁盘数据的实时一致性，其效果与共享磁盘完全一致。
有了DRBD之后，我们可以在这个基础之上安装集群管理软件或者集群文件系统实现多活的业务高可用部署。
KubernetesKubernetes是一个开源的，简称K8S，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。
图7 K8S整体架构其实可以简单的理解K8S就是一个基于容器的集群管理软件。
但其数据存储仍然需要依赖后端的存储系统。
Kubernetes主要由以下几个核心组件组成：etcd保存了整个集群的状态；apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；好了，今天先介绍到这，后面再详细介绍每部分的内容。