分布式存储系统的雪崩效应

一 分布式存储系统背景 副本是分布式存储系统中的常见概念:将一定大小的数据按照一定的冗余策略存储,以保障系统在局部故障情况下的可用性。 副本间的冗余复制方式有多种,比较常用有两类: Pipeline:像个管道,a->b->c,通过管道的方式进行数据的复制。该方式吞吐较高,但有慢节点问题,某一节点出现拥塞,整个过程都会受影响 分发:client -> a  client ->b client ->c。系统整体吞吐较低,但无慢节点问题 对于冗余副本数目,本文选择常见的三副本方案。 分布式存储系统一般拥有自动恢复副本的功能,在局部存储节点出错时,其他节点(数据副本的主控节点或者client节点,依副本复制协议而定)自动发起副本修复,将该宕机存储节点上的数据副本恢复到其他健康节点上。在少量宕机情况下,集群的副本自动修复策略会正常运行。但依照大规模存储服务运维经验,月百分之X的磁盘故障率和月千分之X的交换机故障率有很大的可能性导致一年当中出现几次机器数目较多的宕机。另外,批量升级过程中若出现了升级bug,集群按照宕机处理需要进行副本修复,导致原本正常时间内可以完成的升级时间延长,也容易出现数目较多的宕机事件。 二 雪崩效应的产生 在一段时间内数目较多的宕机事件有较大可能性诱发系统的大规模副本补全策略。目前的分布式存储系统的两个特点导致这个大规模副本补全策略容易让系统产生雪崩效应: a. 集群整体的free空间较小:通常整体<=30%, 局部机器小于<=20% 甚至10% b. 应用混布:不同的应用部署在同一台物理/虚拟机器上以最大化利用硬件资源 今年火起来的各种网盘、云盘类服务就是a的典型情况。在各大公司拼个人存储容量到1T的背后,其实也在拼运营成本、运维成本。现有的云存储大多只增不减、或者根据数据冷热程度做数据分级(类似Facebook的数据分级项目)。云存储总量大,但增量相对小,为了减少存储资源和带宽资源浪费,新创建的文件若原有的存储数据中已有相同的md5或者sha1签名则当做已有文件做内部链接,不再进行新文件的创建。但即使这样,整体的数据量还是很大。 目前云存储相关业务未有明显的收入来源,每年却有数万每台的服务器成本,为运营成本的考虑,后端分布式存储系统的空闲率很低。而瞬间的批量宕机会带来大量的副本修复,大量的副本修复很有可能继而打满原本就接近存储quota的其他存活机器,继而让该机器处于宕机或者只读状态。如此继续,整个集群可能雪崩,系统残废。 三 预防雪崩 本节主要讨论如何在系统内部的逻辑处理上防止系统整体雪崩的发生。预防的重要性大于事故之后的处理,预测集群状态、提前进行优化也成为预防雪崩的一个方向。 下面选取曾经发生过的几个实际场景与大家分享。 1. 跨机架副本选择算法和机器资源、用户逻辑隔离 现场还原: 某天运维同学发现某集群几十台机器瞬间失联,负责触发修复副本的主控节点开始进行疯狂的副本修复。大量用户开始反馈集群变慢,读写夯住。 现场应对: 优先解决——副本修复量过大造成的集群整体受影响。 a. 处理的工程师当机立断,gdb到进程更改修复副本的条件为副本<2,而非原本的3(replicas_num),让主控节点这个时候仅修复副本数小于2个的文件,即保证未丢失的文件有至少一个冗余副本,防止只有一个副本的数据因可能再次发生的挂机造成文件丢失。 b. 紧急解决这批机器失联问题,发现是交换机问题,a.b.c.d ip网段的c网段机器批量故障。催促网络组尽快修复。 c. 副本修复到>=2之后,Gdb更改检测副本不足周期,将几十秒的检测时间推迟到1天。等待网络组解决交换机问题。 d. 网络恢复,原有的机器重新加入集群。大量2副本文件重新变为3副本,部分3副本全丢失文件找回。 e. 恢复主控节点到正常参数设置状态,系统开始正常修复。 改进措施: 在改进措施前,先分析下这次事件暴露的系统不足: 1) Master参数不支持热修正,Gdb线上进程风险过大。 2) 一定数量但局域性的机器故障影响了整体集群(几十台相对一个大集群仍属于局域性故障)。如上所述,月千分之几的故障率总有机会让你的存储系统经历一次交换机故障带来的集群影响。 案例分析后的改进措施出炉: 1)  Master支持热修正功能排期提前,尽早支持核心参数的热修改。 热修改在上线后的效果可观,后续规避过数次线上问题。 … Continue reading “分布式存储系统的雪崩效应”