案例｜S3、Cassandra、HDFS设计中隐藏的高可用法

《案例｜S3、Cassandra、HDFS设计中隐藏的高可用法》要点：
本文介绍了案例｜S3、Cassandra、HDFS设计中隐藏的高可用法，希望对您有用。如果有疑问，可以联系我们。

Anything that can go wrong will go wrong.

会出错的事总会出错.————墨菲定律

高可用 NoSQL 数据库是指服务无中断地持续运行的系统.许多基于网站的业务要求数据服务能够一直不中断.例如,在线购物的数据库需要保证 7 x 24 的可用性.

为什么需要它们一直运行?假设你的数据库支撑着一个全球化的电子商务网站,那么数分钟的宕机就可能造成一个消费者的购物车被清空,或是系统在德国主要消费时段停止响应.这些类型的故障将会使你的顾客转而选择你的竞争对手并降低你的消费者信任度.

分布式 NoSQL 系统降低了那些需要可扩展性和永久在线特性的系统的每笔交易成本.虽然多数 NoSQL 系统使用非标准的查询语言,但它们的设计和可以部署在低成本的云平台的能力,为那些因初创且需要提供永久在线功能的公司提供了可能的选择.

度量 NoSQL 数据库的可用性

描述系统整体可用性最常用的方法是用“9”来描述可用性,其中的“9”是指在设计上的可用性概率中出现“9”的次数.所以“3 个 9”意味着一个系统被预测可以在 99.9% 的情况下可用,而“5 个 9”意味着那个系统应该有 99.999% 的可能是可用的.

下表展示了一个基于典型可用性目标计算出的每年宕机时间的例子.

可用性目标样例和年宕机时间

量化整体系统可用性并不仅仅是计算出某个数字.为了客观地评估 NoSQL 系统,还需要了解系统可用性中的细化指标.

如果一个业务部门声明他们不能承担一个日历年宕机 8 小时的后果,那么就需要构建一个提供 3 个 9 可用性的基础设施系统.多数固定电话交换机的设计目标是达到 5 个 9 的可用性,或每年不超过 5 分钟的宕机时间.现今,除了某些需要更高可用性的场景,5 个 9 被认为是数据服务的黄金标准.

业界使用服务级别协议(service level agreement,SLA)这个术语来描述任何数据服务期望达到的可用性指标.SLA 是服务提供商和客户之间达成的一种书面协议.它定义了服务商需要提供的服务及其期望的可用性和响应时间,而非服务的提供方式.在起草 SLA 时需要考虑以下因素.

• 按每年在线时长比例计算,服务整体上期望达到的可用性是多少?
• 在普通操作的情况下,服务一般的平均响应时间是多少?服务请求与响应之间的时间通常以毫秒为单位.
• 服务在设计上能处理的最大请求数是多少?这项指标通常按每秒的请求数计算.
• 服务的请求数是否存在周期性变化?例如,在诸如每天某个特定时间、每周或每月中的几天、每年里的节假购物日或体育活动日等特定时间段内,是否存在可预期的请求高峰?
• 如何监控系统和汇报服务可用性?
• 服务请求响应时间的分布曲线的趋势是什么?追踪平均响应时间可能用处不大,大家通常关心的是响应中最慢的 5% 请求.
• 遭遇服务中断的情况下,应该遵循怎样的恢复流程?

NoSQL 系统的可用性配置也许会和上面这些普适规则有出入,但关注点都不应该只是某个单一可用性指标.

案例研究：亚马逊 S3 的 SLA

现在,让我们来看看亚马逊为 S3 存储服务编写的 SLA.亚马逊的 S3 是现今最可靠的基于云端的 KV 存储服务,且即使在遇到大量读写高峰的情况下也能持续良好运行.传闻中,这个系统中存储的数据在 2012 年夏季达到了 1 万亿条,为目前容量最大的云端存储.这些数据平均下来大概能达到全球人均 150 条记录.

亚马逊在网站上声明了如下数个可用性指标.

• 年度数据可靠性设计值——这项指标是指在一年中丢失一条 KV 数据的可能性.亚马逊声称他们的可靠性设计值是 99.999999999%,即 11 个 9.这项数据根据存储在 3 块硬盘上的数据在进行备份前遇到所有硬盘均发生故障的可能性计算得出.这意味着如果在 S3 上存储有 10,000 条数据并以每年 1 千万条的速率增加,那么会有 50% 的可能丢失 1 条数据.这应该不会让你经常担心得夜不能寐.但是需要注意的是,设计值并不能等同于服务保证.
• 年度可用性设计值——这项指标是指在最坏的情况下,每年无法写入新数据或读取旧数据的总时长.亚马逊声称在最坏的情况下,S3 仍有 99.99% 即 4 个 9 的可用性.换句话说,亚马逊认为 KV 数据存储每年可能有 53 分钟的不可用时间.但实际上,用户享受到的是远高于该设计值的服务保障.
• 月 SLA 承诺——S3 的 SLA 声明：如果系统在任意的一个月内不能达到 99.9% 的在线,亚马逊将会返给用户 10% 的服务费用；如果数据在一个月中有 1% 的情况无法访问,用户将得到 25% 的服务费用返还.但实际上,我们从没听说哪个亚马逊用户得到过 SLA 服务返点.

仔细阅读亚马逊的 SLA 对你仍会有帮助.例如,协议定义错误率为 S3 返回了内部错误代码的请求个数,但完全没有提到任何与缓慢的响应时间相关的条目.

在实践中,多数用户将获得的可用性远超过 SLA 中写明的最小值.一个独立的测试服务发现 S3 能够达到 100% 的可用性,即使在长时间高负载的情况下也一样.

预测系统可用性

如果要构建一个 NoSQL 数据库,就要能够预测这个数据库的可靠性.你也需要一些工具帮助你分析数据库服务的响应时间.

可用性的预测方法是通过观测每个被依赖的(单点故障)系统组件的可用性估计值来计算系统总体可用性.如果每个子系统使用一个像 99.9 这样的简单可用性估计值,那么将每个数值相乘就可以得出系统总体可用性的估计值.

例如,如果有 3 个会造成单点故障的情况——网络有 99.9% 可用性、主节点有 99% 可用性、电源有 99.9% 可用性,那么总的系统可用性就是这 3 个数值的乘积：98.8%(99.9×99×99.9).

（编辑：ASP站长网）