元数据服务缓存

OpenStack Networking 服务代理虚拟机发送到 Compute 服务以获取其元数据的请求。此功能由 neutron-metadata-agent 或 neutron-ovn-metadata-agent 提供，具体取决于部署中使用的 ML2 后端。为了从 Compute 服务获取元数据，需要将实例 ID 发送到 nova-metadata-api。这两个元数据代理提供相同的功能，但方式略有不同，区别在于元数据代理如何确定请求元数据的实例的 ID

• neutron-metadata-agent 使用 RPC 向 neutron-server 进程请求有关连接到给定网络或路由器的特定固定 IP 地址的端口的详细信息（为每个 Neutron 路由器或 Neutron 网络生成代理服务），

• neutron-ovn-metadata-agent 检查 OVN Southband DB 中端口详细信息中的实例 ID。

对于使用 neutron-metadata-agent 的大规模部署，这可能会给 RPC 总线和 neutron-server 带来显著的负载，因为默认情况下，对于每次对元数据服务 (169.254.169.254) 的请求，代理都需要发送一个 RPC 查询来检索端口详细信息，并且 cloud-init 在 VM 启动过程中会向此服务发送许多请求。为了避免 RPC 总线上的高负载，neutron-metadata-agent 允许使用端口详细信息的缓存机制。Neutron 使用 oslo cache 用于此目的，并通过 metadata_agent.ini 文件中的 cache 部分中的以下参数进行配置

• enabled：启用缓存机制。

• backend：要用于缓存的后端模块。

• expiration_time：缓存项的 TTL，以秒为单位。对于 neutron-metadata-agent 而言，建议在此使用一些较小的值，例如 10 秒。通常，cloud-init 会在 VM 启动过程中在短时间内向元数据服务发送许多请求，因此仅缓存几秒钟的端口详细信息就足以避免许多 RPC 请求。另一方面，使用过大的值可能会导致缓存端口的详细信息，而该端口已被删除，因为固定 IP 地址可以快速重新关联到 Neutron 中的新端口。

oslo.cache 模块提供了许多其他配置选项，可用于调整此缓存机制。所有这些都在 oslo.cache 文档 中描述。