layout: post
title: "大规模云计算平台的技术挑战"
category: Reading Notes
tags: ["读文章", “云计算”]
{% include JB/setup %}
飞天大规模分布式计算平台是一个由多个组件所构成的复杂的分布式系统，其中的核心组件是以下两个子系统：
- 计算资源调度系统：管理和调度集群计算资源；在多个云服务间动态分配计算资源；自动检测服务器故障并迁移故障服务器上的服务。
- 分布式文件系统：管理集群的所有硬盘；合理地安排数据存放位置以兼顾性能和数据安全性；自动检测磁盘故障并复制数据以保证安全。
实现云计算平台的过程中所面临的技术挑战：
- 在不可靠硬件基础上提供高可靠的计算能力和存储能力；
- 提供高可用服务；
- 低成本运维海量硬件；
- 在线应用与离线应用共存；
- 克服节点间宽带的限制；
- 最大化利用计算资源，等等
一、不可靠的硬件是最基本的挑战：
集群规模达到上千台后，单机上的小规模事件变成了必然的、频繁发声的事件。我们称之为“硬”故障。还有一类称之为“软”故障，例如，硬盘可访问但速度只有正常的1/10、服务器没有宕机但程序运行缓慢、网络时好时坏等。
硬、软故障发声都会对系统的可靠性甚至可用性造成不良影响，因此如何及时有效地进行故障检测和恢复就变得比较关键。
检测“软”故障有两种思路。
一种是针对每种具体故障设计检测方法。
一种是从宏观现象来检测。
例子1：检测作业在某个服务器上执行特别缓慢的情况。
统计每个作业在每台服务器上的执行事件。因为输入数据被均匀地切片，每台服务器上的执行时间应该大致相同。如果某台服务器上的执行时间超过了平均时间的三倍，它就被标记为“缓慢”。如果各种不同作业在某台服务器上都“缓慢”，那么我们有充分的理由怀疑这台服务器有问题。调度系统会自动把这台服务器**加入黑名单**，不再用它执行作业。之后再自动或人工检查这些可疑服务器的具体故障原因。
例子2：检测磁盘读写慢的情况。
我们在分布式文件系统里也会统计每次磁盘访问的时间。如果某块磁盘有大比率的访问时间远远超过系统平均值，那么很有可能是这块磁盘快要发声故障了。文件系统此时会做三件事：
* 停止写新数据到这块磁盘，防止更多数据处于危险中；
* 开始为这块磁盘上的数据增加更多副本；
* 当这块磁盘上的所有数据都有额外的副本，就可以将它下线，待运维处理。
二、故障自动恢复的策略：
Amazon EC2大规模停机事件
事故起因是Amazon对集群网络做日常维护升级时操作错误，网络流量被全部切换到备用网络，导致备用网络过载。自动故障恢复机制检测到网络不同，以为服务器大量宕机，马上开始数据复制以替换‘宕机’的服务器上的数据副本，引发了‘镜像风暴’（大量服务器同时尝试创建数据镜像）。而由此增加的数据流量更加剧了网络过载，从而使故障在集群中蔓延，进入恶性循环。最终采取了包括暂时关闭自动故障恢复系统和增加硬件在内的多个措施。
我们的策略是限制故障自动恢复机制的作用范围：
- 正常情况下，任何时候集群中都有且仅有很小比例的服务器发生故障，此时自动恢复有效，即使无效也不会造成灾难（上限是1%的硬盘）；
- 如果发生大规模故障，明智的策略是尽量降低系统负载，暂时禁止掉前面提到的自动恢复逻辑。
三、数据可靠性和实时性能优化：
为了保证数据安全性，文件系统对所有的数据均采用了多份拷贝。在创建文件时，用户可以指定文件数据的拷贝数目，文件系统会保证数据分布在不同节点和不同的机架上，使得单个硬件故障不会造成数据无法访问。
多副本技术被广泛采用但是会导致数据写入的延迟增大，因为只有当所有副本都写成功后才能结束一个写操作。
可以通过文件日志文件来解决此问题。把日志文件写入磁盘，只要数据文件进入指定数量服务器的内存即可认为是写成功；后天线程随后会把内存中的数据批量写入磁盘。
REFERENCE
刘缙，朱家稷，张海勇，“大规模云平台的技术挑战”，淘宝，2012