Ansible 调优¶
在本节中，我们将介绍一些用于调整 Ansible 性能和扩展性的选项。
SSH 管道¶
SSH 管道在 Ansible 中默认情况下是禁用的，但通常可以安全地启用，并提供合理的性能提升。
ansible.cfg¶[ssh_connection]
pipelining = True
分叉数¶
默认情况下，Ansible 使用相对保守的 5 个进程分叉来执行任务。 这限制了 Ansible 可以扩展的并行性。 大多数 Ansible 控制主机能够处理比这更多的分叉。 您需要进行实验以找出机器的 CPU、内存和 IO 限制。
例如，要将分叉数增加到 20
ansible.cfg¶[defaults]
forks = 20
事实缓存¶
默认情况下，Ansible 在每个 playbook 的开头为每个主机收集 facts，除非 gather_facts 设置为 false。 对于大量主机，这可能会导致花费大量时间收集 facts。
一种改进方法是利用 Ansible 对 事实缓存 的支持。 为了使这与 Kolla Ansible 协同工作，有必要将 Ansible 的 收集 配置选项更改为 smart。
示例¶
在下面的示例中，我们配置 Kolla Ansible 使用 jsonfile 缓存插件 使用事实缓存。
ansible.cfg¶[defaults]
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible-facts
您还可以通过 [defaults] fact_caching_timeout 设置缓存的过期超时时间。
填充缓存¶
在某些情况下，按需填充事实缓存可能很有帮助。 kolla-ansible gather-facts 命令可用于执行此操作。
一个特别有用之处是在使用 kolla-ansible 带有 --limit 参数运行时，因为在这种情况下，匹配 limit 的主机将为不属于 limit 的主机收集 facts。 在 limit 仅匹配一个主机的极端情况下，它将串行收集所有其他主机的 facts。 为了避免此问题，请在不带 limit 的情况下运行 kolla-ansible gather-facts 以并行填充事实缓存，然后再使用 limit 运行所需的命令。 例如
kolla-ansible gather-facts
kolla-ansible deploy --limit control01
事实变量注入¶
默认情况下，Ansible 为每个 fact 注入一个变量，前缀为 ansible_。 这可能会导致每个主机的大量变量，从而在扩展时产生性能损失。 Ansible 提供了一个 配置选项，可以设置为 False 以防止此 fact 注入。 在这种情况下，应通过 ansible_facts.<fact> 引用 facts。
ansible.cfg¶[defaults]
inject_facts_as_vars = False
事实过滤¶
可以使用 Ansible facts 过滤来加速 Ansible。 网络和计算节点上具有许多网络接口的环境可能会在使用 Kolla Ansible 时遇到非常慢的处理速度。 这是由于对每个任务处理大量的 per-interface facts 所致。 为了避免存储某些 facts，我们可以使用 kolla_ansible_setup_filter 变量，该变量用作 setup 模块的 filter 参数。 例如，要避免收集以 q 或 t 开头的虚拟接口的 facts
kolla_ansible_setup_filter: "ansible_[!qt]*"
这将导致 Ansible 收集但不存储匹配该模式的 facts，其中包括虚拟接口 facts。 目前，我们不在 Kolla Ansible 中引用匹配该模式的其他 facts。 请注意，包含 ansible_ 前缀会导致元 facts module_setup 和 gather_subset 被过滤，但似乎这是获得接口 facts 良好匹配的唯一方法。
确切的改进将有所不同，但据报道，在具有许多虚拟接口的系统上，改进幅度高达 18 倍。
事实收集子集¶
还可以通过 kolla_ansible_setup_gather_subset 配置要收集的事实子集，该子集用作 setup 模块的 gather_subset 参数。 例如，如果一个人想避免通过 facter 收集 facts
kolla_ansible_setup_gather_subset: "all,!facter"
最大失败百分比¶
可以使用 kolla_max_fail_percentage 指定 最大失败百分比。 默认情况下，此值未定义，相当于 100 的值，这意味着 Ansible 将继续执行，直到所有主机都失败或完成。 例如
kolla_max_fail_percentage: 50
可以使用 <service>_max_fail_percentage 为特定服务设置最大失败百分比。 例如
kolla_max_fail_percentage: 50
nova_max_fail_percentage: 25
委托的事实收集¶
当 Kolla Ansible 使用 --limit 参数执行时，操作的范围限制为 limit 中的主机。 例如
kolla-ansible deploy --limit control
由于配置集群软件服务的天性，在某些情况下，我们需要了解有关其他主机的信息。 这通常与它们的主机名或网络地址有关。 为了使之工作，Kolla Ansible 使用 委托的事实收集 收集 limit 之外的主机的事实。
默认情况下，Kolla Ansible 收集所有主机的事实。 由于委托的事实是按批次由活动主机串行收集的，因此当 limit 中的主机不多时，这可能需要很长时间。 如果您知道并非需要所有主机的事实，则可以通过将 kolla_ansible_delegate_facts_hosts 设置为主机列表来减少有资格进行委托的事实收集的主机集。 这可以在 globals.yml 中永久完成，或使用 -e 参数在命令持续时间内临时完成。
确切的要求取决于配置和清单，但以下是一些经验法则
通常需要所有控制器的 facts，无论 limit 中的主机如何。 这是由于对 RabbitMQ 和 Memcache 连接字符串等的引用。
Prometheus 服务器需要其他所有主机的事实才能为节点导出器、cAdvisor 等生成 scrape 配置。 具体来说，它使用 API 接口的 IP 地址。 可以通过在每个主机的清单中硬编码
prometheus_target_address来避免这种情况。在
bootstrap-servers命令期间配置/etc/hosts需要其他所有主机的事实。 具体来说，它使用 API 接口的 IP 地址，以及hostname和nodenamefacts。鉴于上述例外情况，计算节点相对独立。 其他主机不需要知道它们的事实，它们也不需要知道其他主机的事实。
