1-5 龚兵-vivo存储系统的数据可靠性探索与实践

vivo存储系统的数据可靠性探索与实践 演讲人：龚兵vivo云存储研发负责人 个人简介 龚兵 vivo存储研发高级经理 2019年加入vivo，参与过存储与数据库多个产品的研发工作，目前担任存储和数据库产品研发团队的负责人 分享目的与目标 自标TARGET 目的OBJECTIVE 可靠性影响因素和量化模型全面剖析让大家对11个9可靠性不再感到陌生 输出倒逼输入 让自己总结可靠性知识沉淀的理由 抛砖引玉引发存储可靠性评估探讨让大家意识可靠性评估重要性 存储可靠性模型实用化、工程化让大家在做存储系统设计有所借鉴 Gdevops全球敏捷运维峰会北京站 目录 CONTENTS 溯源：vivo存储服务介绍 vivo存储产品介绍一-产品矩阵 可靠性：服务质量另一个维度，存储领域指数据不丢不错，指标："11个9” 工具&接入类服务矩阵 存储&数据库产品矩阵 高可靠+低盛本，低成本+高性能）为业务提供一流的高可靠、高性能、低成本的存储和数据库产品 可用性：服务质量的一个维度衡量标准：SLA（服务等级协义）：服务可用时长占全年时长的百分比 Gdevops全球敏捷运维峰会北京站 vivo存储产品介绍--存储框架 vivo存储产品介绍--运营数据 +数据丢失影响因素Software Failure &Data CorruptionHuman Error& MaliciousTheftHardware Failuredbaplus 02. 归因：存储可靠性原因分析 存储可靠性原因分析一影响因素 软件故障存储软件设计缺陷、软件实现有BUG 数据损坏并不仅仅只是bitflip，传输处理存储环节都可能出现数据损坏 恶意窃取公司内部员工窃取外部恶意人员攻击 人为失误运维操作失误、用户误删除、误覆盖 硬盘故障、机架级故障、机房级故障、区域级故障 存储可靠性原因分析一软件故障和数据损坏 数据损坏 软件故障 原因剖析 CPU是不是永还不会说诺？（不一定TCP的checksum机出是否永远正旁？(不一定)B反转是否一定只同限硬件问题？（不一定） 软件设计不规范测试不完善运维发布的操作混炸半径太大 解决方案 解决方案 HTTPS/TLS保护故据在传节过程中的安全和完整件Content-MD5校验携带MD5可以进一步检验传过程的敬据完整性Data-scrubbing利用存技的cRC-checksum进行定期换完整性 设计标准规范化 TLA+，Plusal形式化规范语言亲设计系统 测试白动化 测试用列完善、测试工异完善 版本兼容、版本回滚、读马分离 绝小运维发布轻件的露炸半径，快速回离，升级梁忆进行读写分离 Gdevops全球敏捷运维峰会北京站 存储诸可靠性原因分析一恶意窃取和人为失误 恶意切取 人为失误 原因剖析 运维人员择作失误用户使用数后误操作时除用户使用数导语深作覆盖 内部员工恶宝取和副除故姆外部政击者恶急攻击利除数据 解决方案 Qvivo待建设 解决方案 运维自动化，远雄白屏化，适循POLP 权限控制+生命周期管控 让远维人员的人工强作极少，复杂度越优，操作极限滤细 完各的限控和生命固期控司 对象存储对象轻度的密版本功能特性让用户找回误出数据 可以锁定对盈护度为品读摄式，可配合版本功能全名用 文件存能的回收站功能也支持用户找回不久前误印隐的文件教 提供史加究全的则除数活的机制防止费意除操作 Gdevops全球敏捷运维峰会北京站 存储可靠性原因分析一硬件故障自 挑战：纠划码技术兄余度+成本的衡量，多AZ余+修复带宽压力 硬盘故障：最常见最重要的，驱动器、噬头，度、机祛胃故障主机故障：服务器各部件故障导款务器无法启动机拒故章：由于电源。温度。网络等原因导致整机柜服务器停机机房故障：整个机房由于自然灾售本供电原因范卖Region故障：不同地理区域的一个Region故障A之故障：同一地理区好独立电力和网的机房故障 03. 建模：存储可靠性量化模型 存储可靠性量化模型一11个9的由来 11个9定义：存储一干万个对象预平均每1万年发生一个对象丢失 MTTR：故障平均修复时问，包括故障发现的时间（T2+T3） 所有云存储提供商都像军备竞衰一样说能提供多少多少个9但行业内几乎设有任何一家云厂商能提供权感的量化模型 与MTTR指对应的指标：年平均接更率从 Gdevops全球敏捷运维峰会北京站 存储可靠性量化模型一影响因素 存储可靠性量化模型一MTTDL MTTDL平均系统数据丢失时间：和MTTF区别在于MTTDL描述的是系统的平均丢数据时间 MTTDL-1.0 MTTDL-2.0 缺点： 没考扇区错误 独立扇区错误 考虑数据分布系数5系统量终持久性公式： 结论：MTTDL模型对不同系统设计的可靠性优劳评估作用非常大，MTTDL各种优化版本绝对值有一定借鉴意义 存储可靠性量化模型一EAFDL 侧重频率：MTTDL相同EAFDL最大化低重数量：EAFDL相同MTTDL最大化 回顾 MTTDL定义：平均系统丢失数据的时间。 EAFDL模型 EAFDL计算公式：EAFDL =E(H)MTTDL+U 第二 第 MTTDL越高表示系统有数据丢失的概率低，也就是出现丢数据的频率低。 MTTDL只关注丢失的频，但是没有关注每次丢失的数量， 其中E(1I)为丢失的平均数据量，U为用户总数据量E(H)计算公式：(spreadfactor=N) EAFDL：预期每年数据丢失比例 在MTTDL的基础上进一步关注丢失的数量。也就每年预期丢失的数据比例，11个9定支：平均每年对象的丢失率预计为0.000000000% 真实环境的妥协： 有些云厂商根据实际IDC内部的现网效据真实统计认为控制丢失的频率史重要，因为每个丢失事件都会产生固定虎本，而这些云厂商则可能仍然会关注MTTDL， EAFDL比MTTDL更贴近11个9的计算 +vivo可靠性建模思路·vivo多副本可靠性模型?vivo纠删码可靠性模型●可靠性评估平台化建设dbaplus 实践：存储可靠性评估实践 存诸可靠性评估实践一vivo建模思路 舍 取 原因剖析 硬性的故障率恒定不变有一定误差Markov链无记忆性扇区错误需要专虑，但当前房区相关的错识幸行业内不统一 固定运维或本不低行业设统一标准零散的计算公式有理论支撑 借鉴点 舍弃点 MTTDL频率维度 招数分布 指故分布学术界一直调病 扇区错误 EAFDL是在MTTDL的基出上例工年度效据丢失量维度 错识率不准确，引入型复杂度 单盘敌妇的分布覆盖度对可靠性影前很大 无记忆性 Gdevops全球敏捷运维峰会北京站 存诸可靠性评估实践一多副本模型 MTTDL副本模式可靠性计算公式： 符号解释 N：系统节点数目R：副本数z：单盘业务数据量AFR：年度磁盘故障抵率FIT：单位小时的磁盘故障数5：数据分布系数Tr：故障到灰复的时间（单位小时）B：分片大小W：单节点修复带宽 如果系统的磁盘是随机打散的,集群水位是80%，则数据分布系数如下： 如果磁盘带宽为200MB/S，夜设留给恢克的可用带宽为20%就是40MB/5，则恢克时长Tr计算公式如下 如果磁盘全年集群出现效据丢失的概率：然后又在Tr修复时间内出观荣三块磁盘故障，并且命中数据分布系数5，年内出现第一块磁盘障后T修复时问内出现第二块酸盘英障，才正式确定澈据去失。 年度硬盘故障数虽分布 一年出现第1块磁盘故腹摄率可以由1-P0-P2获得，因P2非常小，我们简化如下： 假设：单位小时内系统故障的盘数的概率服从泊松分布，其中n就是故障的磁盘数。 纠删码模式可靠性计算公式： D+ECLE+) 存储可靠性评估实践一实验数据 EAFDL副本模式模型计算公式 EAFDL模型计算是在原有计算公式上引入E(H)的值计算如下：Z+80%[E,c()RZ+80% MTTDL模型影响因素变化对可靠性影响： 存储可靠性评估实践一平台化建设 评估平台建设原则：1）评估新老方案可靠性的优劣2）近实时评估线上系统可靠性风险 思考：存储可靠性评估思考 存储可靠性评估思考一方向思考 共享数据 统一标准 云存储领域到现在为正并没有可靠性计算的最有代表的标准娜怕是AWS，就节是有因素影响的可靠性很难计算，也可以把基于硬件故障的可靠性评估模型统一为行业提供指引 现在各大提供分布式存储的厂商之所以没公开相关可靠性计算模型很大一个原因足统计样本数据不够，如果全行业能分享各自的一些统计数据，样本量足够大，建设最真实的评估模型才不会是音望 合作共赢 参考：Iliaslliadis论文非常有价值，在CTRQ发表众多关于云存储系统的可靠性模型研究 存诸可靠性评估思考一未来规划 Gdevops 全球敏捷运维峰会 THANK YOU !