如何构建OpenStack的高可用性上.docxVIP

1、CAP理论　1） CAP 理论给出了3个基本要素：　一致性 (?Consistency) ：任何一个读操作总是能读取到之前完成的写操作结果；?　可用性 (?Availability) ：每一个操作总是能够在确定的时间内返回；?　分区可容忍性 (Tolerance of network?Partition) ：在出现网络分区的情况下，仍然能够满足一致性和可用性；　CAP 理论指出，三者不能同时满足。对这个理论有不少异议，但是它的参考价值依然巨大。　这个理论并不能为不满足这3个基本要求的设计提供借口，只是说明理论上3者不可绝对的满足，而且工程上从来不要求绝对的一致性或者可用性，但是必须寻求一种平衡和最优。　对于分布式数据系统，分区容忍性是基本要求。因此/cpro/ui/uijs.php?rs=1u=http%3A%2F%2Fwww%2Eeducity%2Ecn%2Flinux%2F1440594%2Ehtmlp=baiduc=newsn=10t=tpclicked3_hcqcprk=%C9%E8%BC%C6k0=%C9%E8%BC%C6k1=%D6%F7%BB%FAk2=%B4%E6%B4%A2k3=%CF%B5%CD%B3k4=%CA%FD%BE%DD%BF%E2k5=%C9%E8%BC%C6%B7%BD%B0%B8sid=ce884ac551c7848cch=0tu=u1740074jk=49b15d35606ca1cacf=29fv=14stid=9urlid=0luki=3seller_id=1di=128设计分布式数据系统，很多时候是在一致性和可用性（可靠性）之间寻求一个平衡。更多的系统性能和架构的讨论也是围绕一致性和可用性展开。　2） OpenStack、Swift与CAP的工程实践　对照CAP理论，OpenStack的分布式对象存储系统Swift满足了可用性和分区容忍性，没有保证一致性（可选的），只是实现了最终一致性。Swift如果GET操作没有在请求头中包含’X-Newest’头，那么这次读取有可能读到的不是最新的object，在一致性窗口时间内object没有被更新，那么后续GET操作读取的object将是最新的，保证了最终一致性；反之包含了’X-Newest’头，GET操作始终能读取到最新的obejct，就是一致的。　在OpenStack架构中，对于高可用性需要进行很多工作来保证。因此，下面将对OpenStack结构中的可用性进行讨论：　2、OpenStack的高可用性（OpenStack HA）　要弄清楚怎么实现高可用性，就需要知道哪些服务容易出现不可靠。首先了解一些OpenStack的大致结构。　OpenStack由5大组件组成（计算nova，身份管理keystone，镜像管理glance，前端管理dashboard和对象存储swift）。　nova是计算、控制的核心组件，它又包括nova-compute、nova-scheduler、nova-volume、nova-network和nova-api等服务。借用的以下这幅图了解OpenStack的5大组件和功能：　　下面这幅图描述了各个组件的功能和服务结构：?　同其它大部分分布式系统一样，OpenStack也分为控制节点和计算节点两种不同功能的节点。控制节点提供除nova-compute以外的服务。这些组件和服务都是可以独立安装的，可以选择组合。　nova-compute在每个计算节点运行，暂且假设它是可信任的；或者使用备份机来实现故障转移（不过每个计算节点配置备份的代价相比收益似乎太大）。　控制节点的高可靠性是主要问题，而且对于不同的组件都有自己的高可靠性需求和方案。　（1）由于CotrolNode只有１个，且负责整个系统的管理和控制，因此当Cotrol Node不能提供正常服务时，怎么办？这就是常见的单节点故障（SPoF，single point of failure）问题。　高可用性基本上是没办法通过一台来达到目标的，更多的时候是/cpro/ui/uijs.php?rs=1u=http%3A%2F%2Fwww%2Eeducity%2Ecn%2Flinux%2F1440594%2Ehtmlp=baiduc=newsn=10t=tpclicked3_hcqcprk=%C9%E8%BC%C6%B7%BD%B0%B8k0=%C9%E8%BC%C6%B7%BD%B0%B8k1=%CD%F8%BF%A8k2=masterk3=mysqlk4=gatewayk5=%C9%E8%BC%C6sid=ce884ac551c7848cch=0tu=u1740074jk=49b15d35606ca1cacf=29fv=14stid