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

如果有像主节点或名字节点这样的单点故障节点,那么 NoSQL 系统可以平滑地切换到备用节点而不会造成主要服务中断.如果一个系统可以快速地从一个失效组件的情况下恢复过来,这就是说该系统有自动故障转移(automatic failover)的特性.

自动故障转移是指系统能够监测到服务失效并自动切换到备用组件的特性.故障恢复是指恢复系统中失效组件到正常状态的操作过程.一般情况下,这个过程需要执行数据同步操作.如果系统只配置了一个备用节点,必须综合故障转移失败的概率和故障恢复前系统再次故障的可能性这两项数据来计算可用性.

除了故障指标,还有一些其他指标可用来评估可用性.如果系统有客户端请求响应大于 30s 即超时的配置,那么可以计算客户端请求失败的总占比.在这种情况下,被称为客户端收益(client yield)的量化指标可能是一个更好的参考因素.其中客户端收益是指任意请求在指定时间间隔内返回响应的可能性.

其他指标,比如收获指数(harvest metric),可以在引入部分 API 结果时纳入参考范围,类似联合搜索引擎这样的服务就可能返回部分结果.例如,搜索 10 个远程系统,如果有一个系统在等待结果的 30s 时间窗口内发生了故障,那么这次请求的收获指数就是 90%.收获指数可以通过可用数据除以总的数据源数得到.

要找到最适合应用需求的 NoSQL 服务也许需要比较两个不同系统的架构,而系统的真正架构可能隐藏在网络服务接口之后.在这种情况下,构建一个原型项目并模拟真实负载测试服务也许更有意义.

部署好一个包含压力测试的原型项目后,需要测量的一个关键指标是读写响应时间的频率分布图.这些分布图可为决定是否扩展数据库提供参考.这个分析中的一个关键点是应该关注响应中最缓慢的 5% 部分花了多长时间完成响应,而不是平均响应时间.一般来说,拥有稳定响应时间的服务的可用性比有时出现较高比例缓慢响应的系统要高.让我们来看看这种情况的一个示例.

评估可用性的实践

假如小孙要为一个关心网页响应时间的业务部门评估两个候选 NoSQL 系统.网页由某个 KV 存储中的数据渲染.小孙已经将候选项缩小到了两个 KV 存储,我们将其叫作服务 A 和服务 B.如下图所示,小孙通过 JMeter(一种常用的性能监控工具)生成了两者响应时间的分布图.

平均情况和 95% 的情况下响应时间频率分布的对比图.需要注意的是,两条分布曲线分别对应的是两个 NoSQL KV 数据存储在负载下的表现.服务 A 拥有较低的平均响应时间,但在 95% 的情况下比 B 更慢.服务 B 则是拥有较高的平均响应时间,但 95% 的情况下比 A 更快

当小孙观测数据时,她发现服务 A 拥有较低的平均响应时间.但在 95% 的情况下,服务 A 响应时间比服务 B 高.服务 B 的平均响应时间可能较高,但仍在网页响应时间的期望范围内.在和该业务部门就测试结果讨论完后,该团队选择了服务 B,因为他们感觉在实际负载情况下服务 B 会有更稳定的响应时间.

现在,我们已经讨论过了预测和量化系统可用性的方法.接下来将探讨 NoSQL 集群用来提升系统可用性的策略.

NoSQL 系统的高可用性策略

你最初想要问的几个问题之一可能是：“如果 NoSQL 数据库崩溃了怎么办?”

为了解决这个问题,可以创建一个数据库复制.

使用负载均衡器将流量转向到最空闲的节点

对高可用性有需求的网站会使用一个叫负载均衡器(load balancer)的前端服务.下图展示了一个负载均衡器的示意图.

图中,服务请求从左边进入系统,然后被发送到一个被称为负载均衡池(load balancer pool)的资源池中.接着,被发送给负载均衡器主节点的服务请求会再被转发给某个应用服务器.理想情况下,每个应用服务器有某种负载状况指示来告诉负载均衡器它们的繁忙状况.最空闲的应用服务器将会接收到负载均衡器转发的请求.应用服务器响应请求服务并返回结果.应用服务器也可能向一个或多个 NoSQL 服务器发送数据请求.当查询请求的结果返回后,服务也就最终完结.

负载均衡器适用于有大量可以独立完成服务请求的节点的场景.为了获得性能提升优势,所有的服务请求首先到达负载均衡器,再由其分发给最空闲的节点.每个应用服务器发送的心跳信号构成了一个正在工作的应用服务器列表.一个应用服务器也可能向一个或多个 NoSQL 数据库发送数据请求.

结合高可用分布式文件系统和 NoSQL 数据库

多数 NoSQL 系统的设计目标之一就是能够和像 Hadoop 分布式文件系统(HDFS)这样的高可用文件系统协同工作.如果你正在使用像 Cassandra 这样的 NoSQL 系统,你将了解到它拥有一个和 HDFS 兼容的文件系统.基于某个特定文件系统来构建 NoSQL 系统既有好处也有不足.

将 NoSQL 数据库与分布式文件系统结合有以下优势.

• 重用可靠的组件——从时间和成本上考虑,重用已构建好并完成测试的组件非常有意义.NoSQL 系统不需要重复实现分布式文件系统已实现的功能.另外,组织也许已经有了相应的基础设施和经过培训并知道如何部署配置这些系统的员工.
• 可定制的文件夹级别可用性——多数分布式文件系统可以实现文件夹级别的可用性配置.与使用存在单点故障问题的本地文件系统存储输入输出数据集不同,这些系统可以配置为在多个地方存储数据,一般的默认配置是存储到 3 个不同地方.这就意味着只有当 3 个节点同时崩溃时,客户端请求才会失败.而发生这种情况的概率对于多数服务级别来说已经足够了.
• 机架和站点感知——分布式文件系统软件在设计中已经考虑到了计算机集群在数据中心的位置分布因素.基于位于同一机架上的节点间会有更高带宽的假设,在部署文件系统时,可以指明哪些节点位于同一个机架.机架也可以设置在不同数据中心,这样文件系统就能在某个数据中心宕机后迅速地将数据复制到位于远程数据中心机架的节点上.

将 NoSQL 数据库与分布式文件系统结合还有以下缺点.

• 移植性较低——某些分布式文件系统在 UNIX 或 Linux 系统上的运行效果最好.将这些文件系统移植到像 Windows 这样的其他操作系统上可能并不具可行性.如果确实想在 Windows 上运行,那可能就需要添加一个额外的虚拟机层,而这将造成性能的损失.
• 设计和部署较为耗时——部署一个具有优秀设计的分布式文件系统时,探索出合适的文件夹结构也许就会花费不少时间.文件夹中的所有文件都共享像复制因子这样的属性.如果使用创建日期作为文件夹名字,可能可以根据文件存在的日期(如两年以上)来降低该文件的复制个数.
• 学习曲线较为陡峭——员工需要去学习部署和管理一个分布式文件系统.另外,还需要对这些系统进行监控和备份敏感数据.

案例研究：将 HDFS 作为一个高可用的文件系统存储主数据

（编辑：ASP站长网）