在上期说到，虽然Ceph作为分布式存储系统，应用于生产环境会出现很多问题，但其他开源分布式存储系统更不适用于云计算的生产环境。
我们也提到了，分布式存储如果需要在生产环境中应用，需要满足以下几个条件：
1、提供高可靠的块存储，可分为高性能与低成本等不同种类；
2、块存储的扩容对整个集群的可用性不造成影响；
3、性能可随着扩容线性扩展；
因此，真正用于生产环境的云计算系统，应当采用企业级别的商业分布式存储系统，而不是基于Ceph等开源系统做修改或包装的产品。
让我们来看一个栗子。
某银行打算把核心业务(如资金业务)放到专有云上，涉及的架构大致如下图：
图中，Web、APP和DB都运行在VM上。
VM对系统盘的要求是，IO性能在5000 IOPS以上，尽量在成本合理的范围内；
特别地，数据库对数据盘的要求是，IO性能达25000 IOPS以上；
硬盘的数据持久性达99.9999999%；
业务可用性达99.95%；
用基于Ceph的开源分布式存储实现这个需求，表面上虽然不难，但实际上，随着集群规模的变大，集群分裂的可能性增加，业务可用性达到99.95%的可能性越来越小。
这是由于万恶的CAP理论……
让我们重温一下CAP理论：
在分布式系统中，C(一致性Consistancy)，A(可用性Availability)和P(分区容错性Partition Tolerance)不可兼得。
怎么解决这个问题呢？
工程师们想起了计算机算法中古老的一种方法——Divide and Conquer，将一个大而复杂的问题，分拆为小而简单的问题，进而征服之。
这样的一个集群容易分裂
把集群变小，分散故障域
由于云硬盘的刚性需求为一致性(数据不一致会引发云虚拟机的严重故障)和可用性(SLA承诺)，为了保证一致性和可用性，可以对分区容忍性做出妥协，即，在集群中引入仲裁集群：
如果某个节点被仲裁集群判定为离线，那么，节点上的磁盘全部属于离线状态，磁盘上的副本将被在其他节点上重建，并且不会再有数据落到该磁盘上。
我们知道，在云原生时代，最常见的仲裁节点叫做ZooKeeper。
图中是一个实例，在集群中引入ZooKeeper作为集群的仲裁(为什么是三个？想一想)，并在Zookeeper中保存集群相关的信息，由ZooKeepeer判定某个节点的在线或离线状态。
通过将集群变小并引入Zookeeper仲裁机制的方式，我们才能让分布式存储的可用性达到99.95%以上，应用于关键的生产环境。而数据的持久性，可以通过三副本机制解决——单体磁盘的数据持久性达99.9%，三副本可达9个9。
剖析完这个云计算领域应用Divide & Conquer方法取得成功的实例，方老师想起了这句名言：
He who control the past, command the future. He who command the future, conquer the past.
在分布式系统中，这句话可以改为:
He who control the scalability, command the consistancy. He who command the consistancy conquer the distributed system.
下一期，我们将推开一扇通往新世界的大门……
