在本章中，我们将重点演示 OpenStack 的一个非常有用的内置特性。这将是能够集中管理可能在不同地理位置运行的多个 OpenStack 区域的能力。OpenStack 中的区域概念并不是一个新的概念，但是问问你自己你是否真的见过它。在许多情况下，我发现自己不清楚完成这项工作需要采取什么步骤。今天你会对这个问题有一个积极的回应。
稳定性和可用性目前是 OpenStack 社区中的热门话题，我认为分享一个可行的用例来实现云高可用性会很好。这只是云操作商设置这一功能的众多方式之一。我们可能已经知道，OpenStack 可以满足众多高可用性需求。我们将简要回顾这些场景，然后过渡到为什么要使用这个功能。与前面的所有章节一样，我们将通过演示如何使用 Ansible 自动设置主动-主动云区域来完成这一章。我们将在本章中讨论以下主题:
- 回顾 OpenStack 高可用性场景
- 为什么要使用主动-主动云区域？
- 设置活动-活动云区域
- 创建和设置管理区域
- 配置活动区域的身份验证
- 编写行动手册和角色
- 回顾行动手册和角色
这个话题恰好是我一直喜欢讨论的话题之一。高可用性 ( HA )和灾难恢复总是成为 IT 人员之间非常情绪化的对话，原因显而易见。可以说，为了确保您组织的系统在发生灾难/故障时保持在线，您正处于危险之中。在旧的本地系统时代，高可用性和冷(未使用的)灾难恢复站点已经足够好了。目前云的敏捷性为系统稳定性提供了新的更好的选择。不要满足于旧的解决方案。你有选择！
如前所述，有多种方法可以通过 OpenStack 实现高可用性。我们将概述三种可能的情况，我发现这些情况是成功的，并且能够满足大多数组织的高可用性要求。此处列出了三种可能的场景，并附有添加附加上下文的图表:
- 多个数据中心:多个 OpenStack 区域横跨多个地理位置不同的数据中心
- 单个数据中心:一个数据中心内有多个 OpenStack 区域
- 可用性区域:在位于一个数据中心内的单个 OpenStack 区域内使用成对的可用性区域
我们将从三个场景中最复杂的开始。该场景包括在多个数据中心部署多组 OpenStack 区域，并让它们作为一个云系统运行的概念。虽然这听起来很复杂，但并不像听起来那么难。当需要将它们完全捆绑在一起时，复杂性就会发挥作用，当然，当您去支持/管理它们时，复杂性也会发挥作用。此模型不仅为您提供跨数据中心(多个主动-主动区域)的高可用性，而且还在每个数据中心内单独提供高可用性(独立的主动-主动区域)。为了让您的云离线，您必须有多层故障。
与前面的场景类似，主要区别在于，它只限于单个数据中心。在这种情况下，您可以部署一组仅限于一个数据中心的开放栈活动-活动区域。这种模式只能在运行区域的数据中心内提供高可用性。如果那个特定的数据中心着火了，你的云将会很倒霉。
如果没有什么选择，这种模式仍然可以将您从完全的云故障中拯救出来。
最后一种情况可能是最简单的选择，但肯定可以提供来宾级高可用性。是的，如果您正在寻求获得一个真正的灾难恢复设计，它确实会有所欠缺。通过利用多个 az，您可以使用反关联性过滤器将实例分布在不同的计算节点上，本质上是提供来宾级高可用性。
现在，让我们专注于前面描述的多数据中心模型的简单成对向下版本。我们将回顾为什么您可能对使用主动-主动区域方法感兴趣。
除了能够主动使用不止一个 OpenStack 区域这一简单的令人敬畏的事情之外，主动-主动云区域方法还提供了对您的整体云投资的最佳利用。再也不会因为第二个站点没有被经常使用而不得不执行灾难恢复测试了。此外，您还可以获得集中管理区域的额外奖励。一个双赢的局面遍地开花。
因此，让我们更深入地了解架构，以便提供一个开放栈活动-活动区域。下图以最简单的形式解释了体系结构:
前述体系结构的组件是:
- 两个独立的 OpenStack 云部署，这又相当于两个区域。在这个例子中，我们有区域 A 和区域 B 。这些区域运行除 Keystone 和 Horizon 之外的核心 OpenStack 服务。每个地区可以有任意数量的免费 az。
- 创建另一个专门托管 Keystone 和 Horizon 服务的 OpenStack 区域。该区域可以被分类为管理区域。
- 然后，区域 A 和区域 B 将利用管理区域，通过集中用户、租户和项目管理/创建，以及提供单个 web 仪表板来管理所有活动区域，来处理身份验证和图形用户界面 web 界面。
实现它的过程相对简单，但它确实需要特别注意细节。事先列出我发现非常有用的步骤，避免遗漏步骤。我也了解到手动执行变更(也就是手工)通常也不会有好的结果。编辑服务配置文件的过程确实打开了错误编辑的大门，这导致服务无法启动。不好！！！甚至没有提到它会使实现过程花费三倍的时间。首先，我们将手动回顾这些步骤，然后在下一节中，我们将学习如何尽可能地自动化设置过程。我能说的就是感谢上帝赐予我的一切！
在本节中，我们将回顾设置主动-主动开放栈云区域的手动步骤。下面简要介绍了这些步骤:
- 清点每个地区的端点，并记下网址。
- 在管理区域创建服务用户帐户。
- 在管理区域创建服务。
- 向管理区域注册每个区域的端点。
- 调整管理区域的身份端点。
- 将每个区域的服务配置为根据管理区域身份服务而不是本地区域的身份服务进行身份验证。
现在，让我们逐步完成这里显示的每个配置步骤，演示工作配置示例。
这一步将是对每个区域的端点的简单查询，您希望将其包括在活动-活动设置中。由于我们正在使用open stack-ansible(OSA)来部署我们的 openstack 云，您需要连接到每个区域的实用程序容器中才能使用 OpenStack CLI。一旦连接并获得 OpenRC 文件，命令将是:
$ openstack endpoint list
该命令的输出应该如下所示:
请记住，我们这里的重点只是注意可用的公共端点。
由于 openstack-ansible 将 openstack 服务安装到 LXC 容器中，因此您需要知道如何连接到每个容器以使用 CLI 并配置/维护服务。列出控制平面服务器上运行的所有容器的 LXC 命令是lxc-ls -fancy，输出类似于以下内容:
接下来的步骤将包括自定义管理区域的安装和配置。这将是您的集中管理区域，仅服务于身份验证请求。管理区域可以与其他区域位于同一个数据中心，也可以与其他区域完全分开。显然，需要数据中心之间的网络连接。为此，请遵循稍后给出的说明。
此时，您应该有一个只运行身份服务(Keystone)和 web 仪表板(Horizon)的正常运行的管理区域。只有这两个服务应该存在并处于活动状态。因为我们希望使用管理区域来管理其他区域，所以您必须让它知道其他区域的服务和端点。此过程从在管理区域创建服务用户帐户开始:
-
For this step, we will create the service user accounts using the CLI with the following command:
$ openstack user create --project <project reserved for services> --password <user password> <user name>该命令的一个工作示例如下所示:
$ openstack user create --project service --password passwd glance -
Now we must assign the new user just created a role with the proper permissions. The CLI command to accomplish this is here:
$ openstack role add --user <user name> --project <project reserved for services> <role>该命令的一个工作示例如下所示:
openstack role add --user glance --project service admin
现在我们已经创建了服务用户帐户，我们可以过渡到下一步，在管理区域注册新服务。
在这一步中，我们只是在管理区域为活动区域上运行的服务创建占位符。请记住，活动区域上运行着其他核心服务，管理区域将为它们处理身份验证。管理区域必须知道这些服务。
将使用以下命令在管理区域注册服务:
$ openstack service create --name <service name>
--description "<service description>" <service type>
该命令的一个工作示例如下所示:
openstack service create --name glance
--description "Glance Image Service" image
下一步是在管理区域注册活动区域端点。这一步需要一定的精确度，因为管理区域将使用端点 URL 进行功能调用。如果网址不正确或输入错误，该服务将被视为每个管理区域关闭。
注册活动区域端点的过程包括使用我们之前开始的端点清单。这里的要点是，您必须使用来自每个地区公共端点的 IP 地址。分配给公共端点的 IP 地址需要是公共 IP 地址(可通过互联网访问)或每个数据中心之间可访问的内部 IP 地址。同样，管理区域将使用此 URL 进行服务调用，因此端点必须是可到达的。
您需要注册两种类型的端点:公共和内部。我在安装过程中发现了这个关键组件。一些 OpenStack 服务仅利用内部端点，而其他服务将使用公共端点。为了避免任何问题，我们将两者都注册。从技术上讲，两者都注册是零风险的，这是一个很好的做法。
注册服务的命令示例如下:
$ openstack endpoint create --region <region name>
<service name> <service type> <endpoint url>
该命令的一组工作示例如下所示:
$ openstack endpoint create --region alpha glance
internal
http://127.0.0.1:9292
$ openstack endpoint create --region alpha glance
public
http://127.0.0.1:9292
对于您希望在管理区域下加入的每个活动区域，都需要重复上述步骤。如前面的例子所示，我们将对区域 A 和区域 B 执行此步骤。
设置管理区域的最后一步是确保活动区域可以成功连接到在那里运行的身份服务。前面分享的关于必须公开服务公共端点的相同原则在这里也适用于 Keystone。每个云设置可能略有不同，因此这一步可能不是所有云都需要。
为了评估是否需要进行此调整，请执行以下命令，并确定公共端点和管理端点是否具有为该 URL 配置的本地 IP 地址:
$ openstack endpoint list --service identity
如果输出类似于此，则必须在使用公共 IP 或数据中心之间可访问的 IP 地址创建新端点后，禁用公共和管理端点。关于如何处理的更多细节将在此分享:
为了创建新的公共端点和管理端点，然后禁用当前端点，您将执行以下命令:
# Add public Keystone endpoint
$ openstack endpoint create --region <region name>
keystone public <endpoint url>
# Add an additional admin Keystone endpoint
$ openstack endpoint create --region <region name>
keystone admin <endpoint url>
# Disable the original public Keystone endpoint
with the local IP address
configured (URL will have a non-routable address)
$ openstack endpoint set --disable <endpoint-id>
# Disable the original admin Keystone endpoint with
the local IP address configured
(URL will have a non-routable address)
$ openstack endpoint set --disable <endpoint-id>
一旦完成，在发出openstack endpoint list --service identity命令时，输出应该类似于这样:
本节将包括设置活动区域的步骤，这些活动区域将成为主动-主动云设计的一部分。这些是运行核心 OpenStack 服务的区域。此时，我们已经设置了管理区域来与这些活动区域进行通信。现在，我们必须将核心服务配置为通过管理区域进行身份验证，而不是使用本地身份服务(Keystone)。
如果不首先设置本地身份服务，就无法部署 OpenStack 云。身份服务必须是安装的第一个服务，因此将存在于活动区域中。要使服务不使用本地身份服务，您必须重新配置每个服务。仅仅禁用本地身份服务是不够的。重新配置每个核心服务的过程包括编辑配置文件。如前所述，编辑服务配置文件为错误编辑敞开了大门，这可能导致服务无法启动。
这是你必须更聪明而不是更努力工作的地方。扪心自问:有没有一种工具可以辅助完成这样的任务？是的，答案又一次是 Ansible！Ansible 可以帮助进行许多服务配置更改，从而最大限度地减少打字错误。在第 2 章、Ansible介绍中，我们简要讨论了 ansi ble 临时命令。即席命令允许直接运行模块命令，而无需将任务包装到行动手册或角色中。
临时命令的一个基本示例如下所示:
$ ansible <host> -m <module> -a <module arguments>
在我们的情况下，我们需要连接到控制平面上运行的特定容器，并对该服务配置文件进行更改。对于在该活动区域上运行的每个核心服务，这需要重复。好消息是，我们可以利用 openstack-ansible 部署的动态清单部分来简化整个过程。让我们用下面的例子作为一个例子来说明它是如何实现的。
在本例中，我们将尝试对 Alpha 区域上的映像服务(扫视)进行所需的更改。所以，我们知道的是:
- 您必须连接到扫视容器
- 使用
sed命令，我们将需要利用外壳 Ansible 模块 - 我们准备了一个
sed命令，它将改变glance-api.conf文件中的auth_url值
命令参数的进一步细分将是:
host = glance_container
module = shell
adhoc command = sed -i 's+^auth_url = <current IP>:35357+auth_url = http://<alpha region IP>:35357+' /etc/glance/glance-api.conf
为了利用 openstack-ansible 安装的动态清单功能，您必须从部署节点(用于部署区域的节点)执行这些命令。同样，您可以在/opt/openstack-ansible/playbooks目录下执行命令。
该命令的一个工作示例如下所示:
$ ansible glance_container -m shell -a "sed -i
's+^auth_url = http://172.30.238.2:35357+auth_url =
http://166.78.18.131:35357+' /etc/glance/glance-api.conf"
您可以使用上述原则对活动区域中的所有服务进行必要的更改。确保在配置文件更改后记得重新启动服务。
$ ansible nova_scheduler_container -m service -a
"name=nova-scheduler state=restarted"
在本节中，我们现在将创建行动手册和角色来设置管理区域。然后，我们还将概述完成设置主动-主动云的其他步骤所需的 Ansible 临时命令。当为这种性质的东西创建 Ansible 自动化代码时，我通常喜欢创建分成不同角色的多个任务。这种格式允许您重用使用其他行动手册创建的角色。我们将以两个行动手册和两个角色结束，以自动化设置管理区域的步骤。最后，我们将回顾一下扮演这些角色的行动手册。
在本节的另一半，我们还将概述完成设置主动-主动云的其他步骤所需的 Ansible 的临时命令。您当然可以收集这些命令来创建行动手册和角色。我觉得这将是几百行不必要的代码，所以我继续起草命令并使用搜索和替换。
我们将创建的第一个角色将包括配置管理区域所需的那些任务。文件的名称将是main.yml，位于名为config-admin-region/tasks的角色目录中。该文件的内容如下所示:
---
- name: Create users
os_user:
cloud: "{{CLOUD_NAME}}"
state: present
name: "{{ item.0 }}"
password: "{{ item.1 }}"
default_project: "{{ servicesproject }}"
domain: default
with_together:
- "{{userid}}"
- "{{passwdss}}"
- name: Assign user to specified role in designated environment
os_user_role:
cloud: "{{CLOUD_NAME}}"
user: "{{ item.0 }}"
role: "{{ urole }}"
project: "{{ servicesproject }}"
with_together:
- "{{userid}}"
- name: Register the new services on the Admin region
shell: openstack --os-cloud="{{ CLOUD_NAME }}"
service create --name "{{ item.0 }}" --description "{{ item.1 }}" "{{ servicetype }}"
with_together:
- "{{userid}}"
- "{{descrip}}"
第一个任务将在管理区域创建服务用户帐户。第二个任务将为刚刚创建的用户分配管理员角色。最后一个任务将为活动区域上托管的服务创建占位符。
要创建的下一个角色将处理在管理区域内注册每个区域端点的任务。与前一个角色一样，该文件将被命名为main.yml，位于名为register-endpoints/tasks的角色目录中。该文件的内容如下所示:
---
- name: Register the region service endpoints on the Admin region
shell: openstack --os-cloud="{{ CLOUD_NAME }}"
service endpoint create --region "{{ item.1 }}" "{{ item.0 }}" "{{ item.2 }}" "{{ item.3 }}"
with_together:
- "{{endpointname}}"
- "{{regionname}}"
- "{{endpointtype}}"
- "{{endpointurl}}"
该角色只有一个任务，那就是使用服务端点create to register的命令行界面命令作为端点。在这种情况下，我们使用with_together参数，这样我们就可以遍历定义为变量的四个参数。这样，您只需调整变量值就可以重新运行剧本。在我们的案例中，我们需要运行本剧本两次，一次用于内部端点，一次用于公共端点。
为了支持这些角色，我们现在需要创建与之配套的变量文件。对于这两个角色，我们将使用角色定义的变量文件来简化一些事情。变量文件将存储在另一个名为vars的目录下的role目录中。该目录中的文件将被命名为main.yml。
名为config-admin-region的角色对应的变量文件内容如下:
---
userid: [ 'glance', 'nova', 'neutron', 'heat' ]
passwdss: [ 'passwd', 'passwd', 'passwd', 'passwd' ]
descrip: [ 'Glance Image Service', 'Nova Compute Service', 'Neutron Network Service', 'Heat Orchestration Service' ]
servicetype: [ 'image', 'compute', 'network', 'orchestration' ]
servicesproject: service
urole: admin
名为register-endpoints的角色对应的第二个变量文件的内容如下:
---
endpointname: [ 'glance', 'nova', 'neutron', 'heat' ]
regionname: alpha
endpointtype: internal
endpointurl: [ 'http://<alpha region IP>:9292', 'http://<alpha region IP>:8774/v2.1/%\(tenant_id\)s', 'http://<alpha region IP>:9696', 'http://<alpha region IP>:8004/v1/%\(tenant_id\)s' ]
请记住，变量文件中定义的值将在每次执行之前进行更改，以便日常使用。
让我们花点时间来分析一下变量及其预期用途。总结如下:
userid # name of the user to create
passwdss # passwords for the users being created
descript # description for the service being registered
servicetype # type of service being registered
servicesproject # name of the project where the services user accounts are associated
urole # name of the role to associate with the user
endpointname # service name of the endpoint being registered
regionname # name of the region
endpointtype # the type of endpoint being registered
endpointurl # the url of the endpoint
变量文件完成后，我们可以继续创建主剧本文件。为了演示，我决定将行动手册文件分成两个独立的文件。这完全是我的选择，可以合并成一个文件，没有问题。我觉得，当您需要注册多组端点时，拥有两个独立的主剧本会使重新运行更容易。此处将描述行动手册文件列表:
config-admin.yml
config-admin-region
register-endpoints.yml
register-endpoints
剧本和角色名可以是你选择的任何东西。这里提供了具体的名称，以便您可以轻松地跟随并引用 GitHub 存储库中的完整代码。唯一的警告是，无论您决定如何命名角色，当从行动手册中引用时，都必须保持一致。
在这里，我们将使用 Ansible 特别命令来完成配置。如前所述，我们将利用 openstack-ansible 部署模型的动态清单功能来实现这一点。这些命令将重新配置 OpenStack 服务，以使用管理区域进行身份验证。以下是您需要执行的命令片段，以重新配置每个区域上的核心服务，使其成为主动-主动区域设置的一部分。命令的完整列表可以在位于root目录下名为configure-region-authentication.txt的文件内的OS-admin-with-ansi ble/OS-admin-with-ansi ble-v2Github 存储库中找到。
## Glance
ansible glance_container -m shell -a "sed -i 's+^auth_url = http://172.30.238.2:35357+auth_url = http://<admin region IP>:35357+' /etc/glance/glance-api.conf"
ansible glance_container -m shell -a "sed -i 's+^auth_url = http://172.30.238.2:35357+auth_url = http://<admin region IP>:35357+' /etc/glance/glance-registry.conf"
ansible glance_container -m shell -a "sed -i 's+^auth_url = http://172.30.238.2:5000/v3+auth_url = http://<admin region IP>:5000/v3+' /etc/glance/glance-cache.conf"
ansible glance_container -m shell -a "sed -i 's+^auth_uri = http://172.30.238.2:5000+auth_uri = http://<admin region IP>:5000+' /etc/glance/glance-api.conf"
ansible glance_container -m shell -a "sed -i 's+^auth_uri = http://172.30.238.2:5000+auth_uri = http://<admin region IP>:5000+' /etc/glance/glance-registry.conf"
ansible glance_container -m shell -a "service glance-api restart"
ansible glance_container -m shell -a "service glance-registry restart"
我发现最有效的方法是搜索<admin region IP>的占位符，并用公共 IP 或与管理区域相关联的内部 IP 替换它。你可以用任何文本编辑器来做，也可以用命令来设置它，以便对任何区域执行。
大家干得好！您刚刚为您的 OpenStack 云配置了多个都处于活动状态的区域。一如既往，为了保持我们的传统，我们将快速回顾一下刚刚创建的剧本和角色，从而结束这一章。
让我们直接进入检查我们创建的角色。
位于config-admin-region/tasks目录中的名为main.yml的已完成角色和文件如下所示:
---
- name: Create users
os_user:
cloud: "{{CLOUD_NAME}}"
state: present
name: "{{ item.0 }}"
password: "{{ item.1 }}"
default_project: "{{ servicesproject }}"
domain: default
with_together:
- "{{userid}}"
- "{{passwdss}}"
- name: Assign user to specified role in designated environment
os_user_role:
cloud: "{{CLOUD_NAME}}"
user: "{{ item.0 }}"
role: "{{ urole }}"
project: "{{ servicesproject }}"
with_together:
- "{{userid}}"
- name: Register the new services on the Admin region
shell: openstack --os-cloud="{{ CLOUD_NAME }}"
service create --name "{{ item.0 }}" --description "{{ item.1 }}" "{{ servicetype }}"
with_together:
- "{{userid}}"
- "{{descrip}}"
位于register-endpoints/tasks目录中的名为main.yml的已完成角色和文件如下所示:
---
- name: Register the region service endpoints on the Admin region
shell: openstack --os-cloud="{{ CLOUD_NAME }}"
service endpoint create --region "{{ item.1 }}" "{{ item.0 }}" "{{ item.2 }}" "{{ item.3 }}"
with_together:
- "{{endpointname}}"
- "{{regionname}}"
- "{{endpointtype}}"
- "{{endpointurl}}"
对应的角色局部变量文件都被命名为main.yml，并被保存到角色的vars目录中:
# variables for config-admin-region
---
userid: [ 'glance', 'nova', 'neutron', 'heat' ]
passwdss: [ 'passwd', 'passwd', 'passwd', 'passwd' ]
descrip: [ 'Glance Image Service', 'Nova Compute Service', 'Neutron Network Service', 'Heat Orchestration Service' ]
servicetype: [ 'image', 'compute', 'network', 'orchestration' ]
servicesproject: service
urole: admin
# variables for register-endpoints
---
endpointname: [ 'glance', 'nova', 'neutron', 'heat' ]
regionname: alpha
endpointtype: internal
endpointurl: [ 'http://<alpha region IP>:9292', 'http://<alpha region IP>:8774/v2.1/%\(tenant_id\)s', 'http://<alpha region IP>:9696', 'http://<alpha region IP>:8004/v1/%\(tenant_id\)s' ]
接下来，我们创建了以下主剧本文件；所有将位于playbook目录的root目录中:
config-admin.yml:
---
# This playbook used to demo OpenStack Juno user, role and project
features.
- hosts: util_container
remote_user: root
become: true
roles:
- config-admin-region
register-endpoints.yml:
---
# This playbook used to demo OpenStack Juno user, role and project
features.
- hosts: util_container
remote_user: root
become: true
roles:
- register-endpoints
最后，我们创建了hosts文件，它也位于playbook目录的root目录中:
[localhost]
localhost ansible_connection=local
[util_container]
172.29.236.224
完整的代码集也可以在 GitHub 存储库中找到https://GitHub . com/OS-admin-with-ansi ble/OS-admin-with-ansi ble-v2。
现在是有趣的部分，是时候测试我们的新剧本和角色了。您还需要执行前面描述的附加特别命令来完全测试这个功能。假设您已经克隆了前面提到的 GitHub 存储库，从部署节点测试剧本的命令如下:
$ ansible-playbook -i hosts config-admin.yml
$ ansible-playbook -i hosts register-endpoints.yml
接下来，您将执行名为configure-region-authentication.txt的文件中的命令，该文件位于playbook目录的root目录中。如果一切顺利，您将能够登录到管理区域的 web 仪表板，并在单击页面顶部标题上的项目名称时看到以下内容:
没错。您只需在主动-主动设计中设置您的开放栈云。您刚刚获得的灵活性和可靠性解决了大多数主流的高可用性需求。在不同的区域之间跳跃，在一两次点击中分离出你的应用资源。在结束本章之前，让我们花点时间回顾一下这一章。我们讨论了 OpenStack 为处理高可用性需求提供的现成优势。然后，我们讨论了您希望使用主动-主动云区域的一些可能原因。接下来，我们介绍了如何设置主动-主动云区域的步骤。最后，我们开发了 Ansible 行动手册和角色来自动设置管理区域。
下一章恰好也是客户对一个相当大的 OpenStack 云的需求。没有哪个云操作商不想知道或拥有其云的完整清单。对我们来说，跟踪资源、审核用户和重新总结网络利用率只是日常/每周例行工作的一部分。假设您可以在一个命令中创建一个完整的报告。有可能吗？我不会说的。你将不得不继续阅读第 9 章、清点你的云，来找出答案。