OpenStack高可用性指南（1）——介绍

英文文档参考http://docs.openstack.org/high-availability-guide/content/ch-intro.html

目录

无状态对有状态服务

主从方案

双活方案

高可用性系统，从根本上来说，寻求降低两件事情：

1、系统停机时间 - 无法面向用户的服务超出指定的时间上限，
2、数据丢失 - 意外删除或销毁数据。

重要的是要明白，大多数的高可用性系统，只有在面对一个单一的故障事件才可以保证防止这些问题。他们还希望系统能够防止级联故障，当初期的单一故障恶化成了一系列的单一故障。

高可用性的一个重要方面，是消除了单点故障（ SPOFS ）。一个SPOF是一个单独的设备或软件，其故障可能导致系统停机或数据丢失。消除SPOFS的方式通常包括：

• 冗余的网络部件，如交换机和路由器。
• 冗余的应用和自动服务迁移。
• 冗余的存储组件。
• 冗余设施服务，如电力，空调，消防，和其他的冗余。

与此相反，在面对多个独立的（非相互关联的）失败，高可用性成为一种尽力而为的事。在这样的情况下，大多数的高可用性系统倾向于保护数据而非保持可用性。

高可用性系统通常达到或超过99.99％的正常运行时间，这意味着每年累计停机时间低于一个小时。从这一点看，高度可用的系统一般在面对一个故障的恢复时间在1-2分钟，有时会更少。

无状态对有状态服务

如何防止单点故障部分取决于服务是否是无状态，例如，nova-scheduler服务是无状态的，你发送一个请求，它返回一个响应，没有更多需要注意；后续的请求不依赖于第一个结果。所有无状态的Openstack服务包括：nova-api， nova-conductor，glance-api， keystone-api， neutron-api and nova-scheduler。

有状态服务，更难以管理。一个动作通常涉及多个请求，于是简单的提供额外的实例和负载均衡解决不了问题。

一个面向用户的Openstack有状态服务的例子是Horizon，如果UI每次重置自己当用户每次进入新的页面的时候，它将非常不好用。在一个更基本的层面上，OpenStack的数据库和消息队列也有状态的，必须进行相应的管理，提供高可用性。

你如何管理有状态的服务，部分取决于您选择主从或双活配置。

主从方案

在主从配置中，系统将保证在有问题的情况下，有额外的资源可以联机，以取代那些失败的实例来防止可用性问题和数据丢失问题。例如，Openstack在写入主数据库的同时维持一个灾备数据库，可以在主数据库出现故障的时候联机

通常情况下，主动/被动安装看起来像这样：

• 无状态服务的冗余都可用，使用虚拟IP地址和负载均衡器如HAProxy来负载均衡请求。
• 有状态服务将以这样的方式来管理：在系统发生故障时，替换资源才可以联机。一个单独的应用程序（如Pacemaker/ Corosync ）监视这些服务，在需要的时候让备份联机。

双活方案

在双活的配置中，系统同样也设置一个备份，但这个备份不是在系统发生故障时联机，而是同时和主系统一起运行。在这种情况下，如果出现了问题，用户甚至注意不到，因为备份系统已经在线，所以只是承担更多的负载当有问题的系统正在处理的时候。

通常情况下，双活安装看起来像这样：

• 无状态服务的冗余都可用，使用虚拟IP地址和负载均衡器如HAProxy来负载均衡请求。
• 有状态服务将以这样的方式来管理：所有实例具有相同的状态。例如，一个实例的数据库的更新也将更新所有其他实例的数据库。这样对一个实例的请求就是对其他所有实例的请求。负载平衡器管理这些系统的流量，确保工作的系统能够处理请求。

本文档讨论了一些比较常见的方法来实现这些架构，但他们绝不是唯一的办法。重要的是，为确保你的服务是冗余的、可用的，如何实现它取决于你，让我们看看高可用实现的某些选项吧

详细的指南请看后面的翻译，敬请期待