查网站是不是用shopify做的,贵阳seo网站管理,网站开发技术有哪些,做网站线我们将通过实验详细分析 instance 从 nova-api-metadata 获取信息的完整过程。 环境介绍 1. 一个 all-in-one 环境#xff08;多节点类似#xff09;。 2. 已创建 neutron 网络 test_net#xff0c;DHCP 已启动。在这个 metadata 实验中#xff0c; test_net 的 type 不重… 我们将通过实验详细分析 instance 从 nova-api-metadata 获取信息的完整过程。 环境介绍 1. 一个 all-in-one 环境多节点类似。 2. 已创建 neutron 网络 test_netDHCP 已启动。在这个 metadata 实验中 test_net 的 type 不重要flat、vlan、vxlan 都可以。 3. 暂无 neutron router。 准备就绪开始实验。 启动 instance 通过 cirros 镜像部署一个 instance命名为 c1选择网络 test_net。启动过程中查看 instance 的启动日志。 上面的 log 中我们看到两个信息 ① instance 从 DHCP 拿到了 IP 17.17.17.5这个好理解因为我们在test_net 上开启的 DHCP 服务。 ② instance 会去访问 http://169.254.169.254/2009-04-04/instance-id尝试了 20 次都失败了。 神奇的 169.254.169.254 169.254.169.254 是个什么地址 这是 metadata service 的 IP。 这个地址来源于 AWS当年亚马逊在设计公有云的时候为了让 instance 能够访问 metadata就将 169.254.169.254 这个特殊的 IP 作为 metadata 服务器的地址instance 启动时就会向 169.254.169.254 请求 metadata。OpenStack 之后也沿用了这个设计。 我们现在遇到的问题是 169.254.169.254 没法访问啊cirros 的 cloud-init 显然是没有拿到 metadata 的这点至少可以从 instance 的 hostname 没有被设置为 c1 判断出来。 前面我们在 Metadata Service 架构部分介绍了instance 首先会将 metadata 请求发送给 DHCP agent 或者 L3_agent 管理的 neutron-ns-metadata-proxy。那目前到底是谁在管理 neutron-ns-metadata-proxy 呢我们先在控制节点上查看一下 neutron-ns-metadata-proxy 的进程。 尽然没有 neutron-ns-metadata-proxy 在运行 其原因是默认配置下neutron-ns-metadata-proxy 是由 L3_agent 管理的后面会讨论让 DHCP 来管理由于当前 test_net 并没有挂在 neutron router 上所以没有启动 neutron-ns-metadata-proxy。 添加 router 要解决这个问题很简单创建虚拟路由器 test_router 并连接 test_net。 现在控制节点上已经能够看到 test_router 管理的 neutron-ns-metadata-proxy 了。 重启 instance c1看会发生怎样的变化。 instance 成功访问到 169.254.169.254。从结果看cloud-init 已经获取到 metadata因为 hostname 已经设置为 c1。 下一节我们详细分析 c1 是如何拿到 metadata 的。
