高可用存储架构双机架构常见的高可用存储架构有主备、主从、主主、集群、分区每一种又可以根据业务的需求进行一些特殊的定制化功能由此衍生出更多的变种。存储高可用方案的本质都是通过将数据复制到多个存储设备通过数据冗余的方式来实现高可用其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。因此对任何一个高可用存储方案要从以下几个方面去进行思考和分析数据如何复制各个节点的职责是什么如何应对复制延迟如何应对复制中断常见的双机高可用架构主备、主从、主备 / 主从切换和主主。主备复制主备复制是最常见也是最简单的一种存储高可用方案几乎所有的存储系统都提供了主备复制的功能例如 MySQL、Redis、MongoDB 等。1. 基本实现其整体架构比较简单主备架构中的“备机”主要还是起到一个备份作用并不承担实际的业务读写操作如果要把备机改为主机需要人工操作。2. 优缺点分析主备复制架构的优点就是简单表现有对于客户端来说不需要感知备机的存在即使灾难恢复后原来的备机被人工修改为主机后对于客户端来说只是认为主机的地址换了而已无须知道是原来的备机升级为主机。对于主机和备机来说双方只需要进行数据复制即可无须进行状态判断和主备切换这类复杂的操作。主备复制架构的缺点主要有备机仅仅只为备份并没有提供读写操作硬件成本上有浪费。故障后需要人工干预无法自动恢复。人工处理的效率是很低的可能打电话找到能够操作的人就耗费了 10 分钟甚至如果是深更半夜出了故障都没人知道。人工在执行恢复操作的过程中也容易出错因为这类操作并不常见可能 1 年就 2、3 次实际操作的时候很可能遇到各种意想不到的问题。综合主备复制架构的优缺点内部的后台管理系统使用主备复制架构的情况会比较多例如学生管理系统、员工管理系统、假期管理系统等因为这类系统的数据变更频率低即使在某些场景下丢失数据也可以通过人工的方式补全。主从复制主从复制和主备复制只有一字之差“从”意思是“随从、仆从”“备”的意思是备份。我们可以理解为仆从是要帮主人干活的这里的干活就是承担“读”的操作。也就是说主机负责读写操作从机只负责读操作不负责写操作。1. 基本实现与主备复制架构比较类似主要的差别点在于从机正常情况下也是要提供读的操作。2. 优缺点分析主从复制与主备复制相比优点有主从复制在主机故障时读操作相关的业务可以继续运行。主从复制架构的从机提供读操作发挥了硬件的性能。缺点有主从复制架构中客户端需要感知主从关系并将不同的操作发给不同的机器进行处理复杂度比主备复制要高。主从复制架构中从机提供读业务如果主从复制延迟比较大业务会因为数据不一致出现问题。故障时需要人工干预。综合主从复制的优缺点一般情况下写少读多的业务使用主从复制的存储架构比较多。例如论坛、BBS、新闻网站这类业务此类业务的读操作数量是写操作数量的 10 倍甚至 100 倍以上。双机切换1. 设计关键主备复制和主从复制方案存在两个共性的问题主机故障后无法进行写操作。如果主机无法恢复需要人工指定新的主机角色。双机切换就是为了解决这两个问题而产生的包括主备切换和主从切换两种方案。简单来说这两个方案就是在原有方案的基础上增加“切换”功能即系统自动决定主机角色并完成角色切换。现一个完善的切换方案必须考虑这几个关键的设计点主备间状态判断 主要包括两方面状态传递的渠道以及状态检测的内容。状态传递的渠道是相互间互相连接还是第三方仲裁状态检测的内容例如机器是否掉电、进程是否存在、响应是否缓慢等。切换决策 主要包括几方面切换时机、切换策略、自动程度。切换时机什么情况下备机应该升级为主机是机器掉电后备机才升级还是主机上的进程不存在就升级还是主机响应时间超过 2 秒就升级还是 3 分钟内主机连续重启 3 次就升级等。切换策略原来的主机故障恢复后要再次切换确保原来的主机继续做主机还是原来的主机故障恢复后自动成为新的备机自动程度切换是完全自动的还是半自动的例如系统判断当前需要切换但需要人工做最终的确认操作(例如单击一下“切换”按钮)。数据冲突解决 当原有故障的主机恢复后新旧主机之间可能存在数据冲突。2. 常见架构根据状态传递渠道的不同常见的主备切换架构有三种形式互连式、中介式和模拟式。互连式故名思议互连式就是指主备机直接建立状态传递的渠道架构图请注意与主备复制架构对比。在主备复制的架构基础上主机和备机多了一个“状态传递”的通道这个通道就是用来传递状态信息的。这个通道的具体实现可以有很多方式可以是网络连接(例如各开一个端口)也可以是非网络连接(用串口线连接)。可以是主机发送状态给备机也可以是备机到主机来获取状态信息。可以和数据复制通道共用也可以独立一条通道。状态传递通道可以是一条也可以是多条还可以是不同类型的通道混合(例如网络 串口)。为了充分利用切换方案能够自动决定主机这个优势客户端这里也会有一些相应的改变常见的方式有为了切换后不影响客户端的访问主机和备机之间共享一个对客户端来说唯一的地址。例如虚拟 IP主机需要绑定这个虚拟的 IP。客户端同时记录主备机的地址哪个能访问就访问哪个备机虽然能收到客户端的操作请求但是会直接拒绝拒绝的原因就是“备机不对外提供服务”。互连式主备切换主要的缺点在于如果状态传递的通道本身有故障(例如网线被人不小心踢掉了)那么备机也会认为主机故障了从而将自己升级为主机而此时主机并没有故障最终就可能出现两个主机。虽然可以通过增加多个通道来增强状态传递的可靠性但这样做只是降低了通道故障概率而已不能从根本上解决这个缺点而且通道越多后续的状态决策会更加复杂因为对备机来说可能从不同的通道收到了不同甚至矛盾的状态信息。中介式中介式指的是在主备两者之外引入第三方中介主备机之间不直接连接而都去连接中介并且通过中介来传递状态信息对比一下互连式切换架构我们可以看到主机和备机不再通过互联通道传递状态信息而是都将状态上报给中介这一角色。单纯从架构上看中介式似乎比互连式更加复杂了首先要引入中介然后要各自上报状态。然而事实上中介式架构在状态传递和决策上却更加简单了连接管理更简单主备机无须再建立和管理多种类型的状态传递连接通道只要连接到中介即可实际上是降低了主备机的连接管理复杂度。状态决策更简单主备机的状态决策简单了无须考虑多种类型的连接通道获取的状态信息如何决策的问题只需要按照下面简单的算法即可完成状态决策。无论是主机还是备机初始状态都是备机并且只要与中介断开连接就将自己降级为备机因此可能出现双备机的情况。主机与中介断连后中介能够立刻告知备机备机将自己升级为主机。如果是网络中断导致主机与中介断连主机自己会降级为备机网络恢复后旧的主机以新的备机身份向中介上报自己的状态。如果是掉电重启或者进程重启旧的主机初始状态为备机与中介恢复连接后发现已经有主机了保持自己备机状态不变。主备机与中介连接都正常的情况下按照实际的状态决定是否进行切换。例如主机响应时间超过 3 秒就进行切换主机降级为备机备机升级为主机即可。虽然中介式架构在状态传递和状态决策上更加简单但并不意味着这种优点是没有代价的其关键代价就在于如何实现中介本身的高可用。如果中介自己宕机了整个系统就进入了双备的状态写操作相关的业务就不可用了。这就陷入了一个递归的陷阱为了实现高可用我们引入中介但中介本身又要求高可用于是又要设计中介的高可用方案……如此递归下去就无穷无尽了。MongoDB 的 Replica Set 采取的就是这种方式其基本架构如下MongoDB(M) 表示主节点MongoDB(S) 表示备节点MongoDB(A) 表示仲裁节点。主备节点存储数据仲裁节点不存储数据。客户端同时连接主节点与备节点不连接仲裁节点。开源方案已经有比较成熟的中介式解决方案例如 ZooKeeper 和 Keepalived。ZooKeeper 本身已经实现了高可用集群架构因此已经帮我们解决了中介本身的可靠性问题在工程实践中推荐基于 ZooKeeper 搭建中介式切换架构。模拟式 模拟式指主备机之间并不传递任何状态数据而是备机模拟成一个客户端向主机发起模拟的读写操作根据读写操作的响应情况来判断主机的状态。其基本架构如下对比一下互连式切换架构我们可以看到主备机之间只有数据复制通道而没有状态传递通道备机通过模拟的读写操作来探测主机的状态然后根据读写操作的响应情况来进行状态决策。模拟式切换与互连式切换相比优点是实现更加简单因为省去了状态传递通道的建立和管理工作。简单既是优点同时也是缺点。因为模拟式读写操作获取的状态信息只有响应信息(例如 HTTP 404超时、响应时间超过 3 秒等)没有互连式那样多样(除了响应信息还可以包含 CPU 负载、I/O 负载、吞吐量、响应时间等)基于有限的状态来做状态决策可能出现偏差。主主复制主主复制指的是两台机器都是主机互相将数据复制给对方客户端可以任意挑选其中一台机器进行读写操作下面是基本架构图。相比主备切换架构主主复制架构具有如下特点两台都是主机不存在切换的概念。客户端无须区分不同角色的主机随便将读写操作发送给哪台主机都可以。从上面的描述来看主主复制架构从总体上来看要简单很多无须状态信息传递也无须状态决策和状态切换。然而事实上主主复制架构也并不简单而是有其独特的复杂性具体表现在如果采取主主复制架构必须保证数据能够双向复制而很多数据是不能双向复制的。因此主主复制架构对数据的设计有严格的要求一般适合于那些临时性、可丢失、可覆盖的数据场景。例如用户登录产生的 session 数据(可以重新登录生成)、用户行为的日志数据(可以丢失)、论坛的草稿数据(可以丢失)等。高可用存储架构集群和分区两种常见的高可用存储架构数据集群和数据分区。数据集群主备、主从、主主架构本质上都有一个隐含的假设主机能够存储所有数据但主机本身的存储和处理能力肯定是有极限的。集群就是多台机器组合在一起形成一个统一的系统这里的“多台”数量上至少是 3 台相比而言主备、主从都是 2 台机器。根据集群中机器承担的不同角色来划分集群可以分为两类数据集中集群、数据分散集群。1.数据集中集群数据集中集群与主备、主从这类架构相似我们也可以称数据集中集群为 1 主多备或者 1 主多从。无论是 1 主 1 从、1 主 1 备还是 1 主多备、1 主多从数据都只能往主机中写而读操作可以参考主备、主从架构进行灵活多变。虽然架构上是类似的但由于集群里面的服务器数量更多导致复杂度整体更高一些具体体现在主机如何将数据复制给备机 主备和主从架构中只有一条复制通道而数据集中集群架构中存在多条复制通道。多条复制通道首先会增大主机复制的压力某些场景下我们需要考虑如何降低主机复制压力或者降低主机复制给正常读写带来的压力。其次多条复制通道可能会导致多个备机之间数据不一致某些场景下我们需要对备机之间的数据一致性进行检查和修正。备机如何检测主机状态 主备和主从架构中只有一台备机需要进行主机状态判断。在数据集中集群架构中多台备机都需要对主机状态进行判断而不同的备机判断的结果可能是不同的如何处理不同备机对主机状态的不同判断是一个复杂的问题。主机故障后如何决定新的主机 主从架构中如果主机故障将备机升级为主机即可而在数据集中集群架构中有多台备机都可以升级为主机但实际上只能允许一台备机升级为主机那么究竟选择哪一台备机作为新的主机备机之间如何协调这也是一个复杂的问题。目前开源的数据集中集群以 ZooKeeper 为典型ZooKeeper 通过 ZAB 算法来解决上述提到的几个问题但 ZAB 算法的复杂度是很高的。2.数据分散集群数据分散集群指多个服务器组成一个集群每台服务器都会负责存储一部分数据同时为了提升硬件利用率每台服务器又会备份一部分数据。数据分散集群的复杂点在于如何将数据分配到不同的服务器上算法需要考虑这些设计点均衡性 算法需要保证服务器上的数据分区基本是均衡的不能存在某台服务器上的分区数量是另外一台服务器的几倍的情况。容错性 当出现部分服务器故障时算法需要将原来分配给故障服务器的数据分区分配给其他服务器。可伸缩性 当集群容量不够扩充新的服务器后算法能够自动将部分数据分区迁移到新服务器并保证扩容后所有服务器的均衡性。数据分散集群和数据集中集群的不同点在于数据分散集群中的每台服务器都可以处理读写请求因此不存在数据集中集群中负责写的主机那样的角色。但在数据分散集群中必须有一个角色来负责执行数据分配算法这个角色可以是独立的一台服务器也可以是集群自己选举出的一台服务器。如果是集群服务器选举出来一台机器承担数据分区分配的职责则这台服务器一般也会叫作主机但我们需要知道这里的“主机”和数据集中集群中的“主机”其职责是有差异的。Hadoop 的实现就是独立的服务器负责数据分区的分配这台服务器叫作 Namenode。 Hadoop 的数据分区管理架构如下Hadoop 官方的解释能够说明集中式数据分区管理的基本方式。HDFS 采用 master/slave 架构。一个 HDFS 集群由一个 Namenode 和一定数目的 Datanodes 组成。 Namenode 是一个中心服务器负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。 集群中的 Datanode 一般是一个节点一个负责管理它所在节点上的存储。HDFS 暴露了文件系统的名字空间用户能够以文件的形式在上面存储数据。从内部看一个文件其实被分成一个或多个数据块这些块存储在一组 Datanode 上。 Namenode 执行文件系统的名字空间操作比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体 Datanode 节点的映射。 Datanode 负责处理文件系统客户端的读写请求。在 Namenode 的统一调度下进行数据块的创建、删除和复制操作。与 Hadoop 不同的是Elasticsearch 集群通过选举一台服务器来做数据分区的分配叫作 master node其数据分区管理架构是其中 master 节点的职责如下数据集中集群架构中客户端只能将数据写到主机数据分散集群架构中客户端可以向任意服务器中读写数据。正是因为这个关键的差异决定了两种集群的应用场景不同。一般来说数据集中集群适合数据量不大集群机器数量不多的场景。数据分区数据分区指将数据按照一定的规则进行分区不同分区分布在不同的地理位置上每个分区存储一部分数据通过这种方式来规避地理级别的故障所造成的巨大影响。采用了数据分区的架构后即使某个地区发生严重的自然灾害或者事故受影响的也只是一部分数据而不是全部数据都不可用当故障恢复后其他地区备份的数据也可以帮助故障地区快速恢复业务。设计一个良好的数据分区架构需要从多方面去考虑。1. 数据量 数据量的大小直接决定了分区的规则复杂度。2. 分区规则 地理位置有近有远因此可以得到不同的分区规则包括洲际分区、国家分区、城市分区。具体采取哪种或者哪几种规则需要综合考虑业务范围、成本等因素。3. 复制规则 数据分区指将数据分散在多个地区在某些异常或者灾难情况下虽然部分数据受影响但整体数据并没有全部被影响本身就相当于一个高可用方案了。但仅仅做到这点还不够因为每个分区本身的数据量虽然只是整体数据的一部分但还是很大这部分数据如果损坏或者丢失损失同样难以接受。因此即使是分区架构同样需要考虑复制方案。常见的分区复制规则有三种集中式、互备式和独立式。集中式集中式备份指存在一个总的备份中心所有的分区都将数据备份到备份中心其基本架构集中式备份架构的优缺点是设计简单各分区之间并无直接联系可以做到互不影响。扩展容易如果要增加第四个分区(例如武汉分区)只需要将武汉分区的数据复制到西安备份中心即可其他分区不受影响。成本较高需要建设一个独立的备份中心。互备式互备式备份指每个分区备份另外一个分区的数据其基本架构互备式备份架构的优缺点是设计比较复杂各个分区除了要承担业务数据存储还需要承担备份功能相互之间互相关联和影响。扩展麻烦如果增加一个武汉分区则需要修改广州分区的复制指向武汉分区然后将武汉分区的复制指向北京分区。而原有北京分区已经备份了的广州分区的数据怎么处理也是个难题不管是做数据迁移还是广州分区历史数据保留在北京分区新数据备份到武汉分区无论哪种方式都很麻烦。成本低直接利用已有的设备。独立式独立式备份指每个分区自己有独立的备份中心其基本架构有一个细节需要特别注意各个分区的备份并不和原来的分区在一个地方。例如北京分区的备份放到了天津上海的放到了杭州广州的放到了汕头这样做的主要目的是规避同城或者相同地理位置同时发生灾难性故障的极端情况。如果北京分区机房在朝阳区而备份机房放在通州区整个北京停电的话两个机房都无法工作。独立式备份架构的优缺点是设计简单各分区互不影响。扩展容易新增加的分区只需要搭建自己的备份中心即可。成本高每个分区需要独立的备份中心备份中心的场地成本是主要成本因此独立式比集中式成本要高很多。如何设计计算高可用架构计算高可用的主要设计目标是当出现部分硬件损坏时计算任务能够继续正常运行。因此计算高可用的本质是通过冗余来规避部分故障的风险单台服务器是无论如何都达不到这个目标的。所以计算高可用的设计思想很简单通过增加更多服务器来达到计算高可用。计算高可用架构的设计复杂度主要体现在任务管理方面即当任务在某台服务器上执行失败后如何将任务重新分配到新的服务器进行执行。因此计算高可用架构设计的关键点有下面两点。1. 哪些服务器可以执行任务第一种方式和计算高性能中的集群类似每个服务器都可以执行任务。例如常见的访问网站的某个页面。第二种方式和存储高可用中的集群类似只有特定服务器(通常叫“主机”)可以执行任务。当执行任务的服务器故障后系统需要挑选新的服务器来执行任务。例如 ZooKeeper 的 Leader 才能处理写操作请求。2. 任务如何重新执行第一种策略是对于已经分配的任务即使执行失败也不做任何处理系统只需要保证新的任务能够分配到其他非故障服务器上执行即可。第二种策略是设计一个任务管理器来管理需要执行的计算任务服务器执行完任务后需要向任务管理器反馈任务执行结果任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行。需要注意的是“任务分配器”是一个逻辑的概念并不一定要求系统存在一个独立的任务分配器模块。常见的计算高可用架构主备、主从和集群。主备主备架构是计算高可用最简单的架构和存储高可用的主备复制架构类似但是要更简单一些因为计算高可用的主备架构无须数据复制其基本的架构示意图主备方案的详细设计主机执行所有计算任务。例如读写数据、执行操作等。当主机故障(例如主机宕机)时任务分配器不会自动将计算任务发送给备机此时系统处于不可用状态。如果主机能够恢复(不管是人工恢复还是自动恢复)任务分配器继续将任务发送给主机。如果主机不能够恢复(例如机器硬盘损坏短时间内无法恢复)则需要人工操作将备机升为主机然后让任务分配器将任务发送给新的主机(即原来的备机)同时为了继续保持主备架构需要人工增加新的机器作为备机。根据备机状态的不同主备架构又可以细分为冷备架构和温备架构。冷备备机上的程序包和配置文件都准备好但备机上的业务系统没有启动(注意备机的服务器是启动的)主机故障后需要人工手工将备机的业务系统启动并将任务分配器的任务请求切换发送给备机。温备备机上的业务系统已经启动只是不对外提供服务主机故障后人工只需要将任务分配器的任务请求切换发送到备机即可。冷备可以节省一定的能源但温备能够大大减少手工操作时间因此一般情况下推荐用温备的方式。主备架构的优点就是简单主备机之间不需要进行交互状态判断和切换操作由人工执行系统实现很简单。而缺点正好也体现在“人工操作”这点上因为人工操作的时间不可控可能系统已经发生问题了但维护人员还没发现等了 1 个小时才发现。发现后人工切换的操作效率也比较低可能需要半个小时才完成切换操作而且手工操作过程中容易出错。例如修改配置文件改错了、启动了错误的程序等。和存储高可用中的主备复制架构类似计算高可用的主备架构也比较适合与内部管理系统、后台管理系统这类使用人数不多、使用频率不高的业务不太适合在线的业务。主从和存储高可用中的主从复制架构类似计算高可用的主从架构中的从机也是要执行任务的。任务分配器需要将任务进行分类确定哪些任务可以发送给主机执行哪些任务可以发送给备机执行其基本的架构示意图主从方案详细设计正常情况下主机执行部分计算任务(如图中的“计算任务 A”)备机执行部分计算任务(如图中的“计算任务 B”)。当主机故障(例如主机宕机)时任务分配器不会自动将原本发送给主机的任务发送给从机而是继续发送给主机不管这些任务执行是否成功。如果主机能够恢复(不管是人工恢复还是自动恢复)任务分配器继续按照原有的设计策略分配任务即计算任务 A 发送给主机计算任务 B 发送给从机。如果主机不能够恢复(例如机器硬盘损坏短时间内无法恢复)则需要人工操作将原来的从机升级为主机(一般只是修改配置即可)增加新的机器作为从机新的从机准备就绪后任务分配器继续按照原有的设计策略分配任务。主从架构与主备架构相比优缺点有优点主从架构的从机也执行任务发挥了从机的硬件性能。缺点主从架构需要将任务分类任务分配器会复杂一些。集群 主备架构和主从架构通过冗余一台服务器来提升可用性且需要人工来切换主备或者主从。这样的架构虽然简单但存在一个主要的问题人工操作效率低、容易出错、不能及时处理故障。因此在可用性要求更加严格的场景中我们需要系统能够自动完成切换操作这就是高可用集群方案。高可用计算的集群方案根据集群中服务器节点角色的不同可以分为两类一类是对称集群即集群中每个服务器的角色都是一样的都可以执行所有任务另一类是非对称集群集群中的服务器分为多个不同的角色不同的角色执行不同的任务例如最常见的 Master-Slave 角色。需要注意的是计算高可用集群包含 2 台服务器的集群这点和存储高可用集群不太一样。存储高可用集群把双机架构和集群架构进行了区分而在计算高可用集群架构中2 台服务器的集群和多台服务器的集群在设计上没有本质区别因此不需要进行区分。对称集群对称集群更通俗的叫法是负载均衡集群因此接下来我使用“负载均衡集群”这个通俗的说法架构示意图负载均衡集群详细设计正常情况下任务分配器采取某种策略(随机、轮询等)将计算任务分配给集群中的不同服务器。当集群中的某台服务器故障后任务分配器不再将任务分配给它而是将任务分配给其他服务器执行。当故障的服务器恢复后任务分配器重新将任务分配给它执行。.负载均衡集群的设计关键点在于两点任务分配器需要选取分配策略。任务分配器需要检测服务器状态。任务分配策略比较简单轮询和随机基本就够了。状态检测稍微复杂一些既要检测服务器的状态例如服务器是否宕机、网络是否正常等同时还要检测任务的执行状态例如任务是否卡死、是否执行时间过长等。常用的做法是任务分配器和服务器之间通过心跳来传递信息包括服务器信息和任务信息然后根据实际情况来确定状态判断条件。非对称集群非对称集群中不同服务器的角色是不同的不同角色的服务器承担不同的职责。以 Master-Slave 为例部分任务是 Master 服务器才能执行部分任务是 Slave 服务器才能执行。非对称集群的基本架构示意图非对称集群架构详细设计集群会通过某种方式来区分不同服务器的角色。例如通过 ZAB 算法选举或者简单地取当前存活服务器中节点 ID 最小的服务器作为 Master 服务器。任务分配器将不同任务发送给不同服务器。例如图中的计算任务 A 发送给 Master 服务器计算任务 B 发送给 Slave 服务器。当指定类型的服务器故障时需要重新分配角色。例如Master 服务器故障后需要将剩余的 Slave 服务器中的一个重新指定为 Master 服务器如果是 Slave 服务器故障则并不需要重新分配角色只需要将故障服务器从集群剔除即可。非对称集群相比负载均衡集群设计复杂度主要体现在两个方面任务分配策略更加复杂需要将任务划分为不同类型并分配给不同角色的集群节点。角色分配策略实现比较复杂例如可能需要使用 ZAB、Raft 这类复杂的算法来实现 Leader 的选举。上一章: FMEA方法排除架构可用性隐患的利器下一章: 异地多活架构归类: 从0开始学架构