通过 dhcp-agent 访问 Metadata - 每天5分钟玩转 OpenStack(168)
2017-03-27 00:00
525 查看
摘要: instance 通过 l3-agent 和 dhcp-agent 都可以获得 metadata,上一节分析了 l3-agent 的场景,今天详细讨论 dhcp-agent。
OpenStack 默认通过 l3-agent 创建和管理 neutron-ns-metadata-proxy,进而与 nova-metadata-api 通信。但不是所有环境都有 l3-agent,比如直接用物理 router 的场景。这时就需要走另一条路:让 dhcp-agent 来创建和管理 neutron-ns-metadata-proxy。
打开 /etc/neutron/dhcp_agent.ini,设置
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530365953053896.jpg)
重启 dhcp-agent 后,可以看到控制节点上多了一个 neutron-ns-metadata-proxy 进程。
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530366263031691.jpg)
此进程通过
重启 instance
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530366754082172.jpg)
请注意,现在访问
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530367185060631.jpg)
同时我们也看到,dhcp-agent 已经将 IP
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530367733083156.jpg)
后面的数据流向就与 l3-agent 的场景一样了:neutron-ns-metadata-proxy 将请求通过 unix domain socket 发给 neutron-metadata-agent,后者再通过管理网络发给 nova-api-metadata。
到这里,我们已经分别讨论了通过 l3-agent 和 dhcp-agent 访问 metadata 的实现方法。对于
l3-agent 用 iptables 规则来转发。
dhcp-agent 则是将此 IP 配置到自己的 interface 上。
不知道大家有没有这样一个疑问:
nova-api-metadata 是怎么知道应该返回哪个 instance 的 metadata?
下节咱们详细分析这个问题。
OpenStack 默认通过 l3-agent 创建和管理 neutron-ns-metadata-proxy,进而与 nova-metadata-api 通信。但不是所有环境都有 l3-agent,比如直接用物理 router 的场景。这时就需要走另一条路:让 dhcp-agent 来创建和管理 neutron-ns-metadata-proxy。
打开 /etc/neutron/dhcp_agent.ini,设置
force_metadata
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530365953053896.jpg)
重启 dhcp-agent 后,可以看到控制节点上多了一个 neutron-ns-metadata-proxy 进程。
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530366263031691.jpg)
此进程通过
--network_id关联到
test_net,这就是 dhcp-agent 启动的 neutron-ns-metadata-proxy,用于接收
test_net网络上 instance 的 metadata 请求。每一个 network 都有一个与之对应的 neutron-ns-metadata-proxy。
重启 instance
c1,查看路由表。
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530366754082172.jpg)
请注意,现在访问
169.254.169.254的路由已由之前的
17.17.17.1变为
17.17.17.2。这里的
17.17.17.2是 dhcp-agent 在
test_net上的 IP。这条路由是由 dhcp-agent 添加进去的。正是因为这条路由的存在,即便 l3-agent 与 dhcp-agent 同时提供 neutron-ns-metadata-proxy 服务,metadata 请求也只会发送给 dhcp-agent。
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530367185060631.jpg)
同时我们也看到,dhcp-agent 已经将 IP
169.254.169.254配置到了自己身上。也就是说:
c1访问 metadata 的请求 http://169.254.169.254 实际上是发送到了 dhcp-agent 的 80 端口。而监听 80 端口的正是 dhcp-agent 启动的 neutron-ns-metadata-proxy 进程。
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530367733083156.jpg)
后面的数据流向就与 l3-agent 的场景一样了:neutron-ns-metadata-proxy 将请求通过 unix domain socket 发给 neutron-metadata-agent,后者再通过管理网络发给 nova-api-metadata。
到这里,我们已经分别讨论了通过 l3-agent 和 dhcp-agent 访问 metadata 的实现方法。对于
169.254.169.254:
l3-agent 用 iptables 规则来转发。
dhcp-agent 则是将此 IP 配置到自己的 interface 上。
不知道大家有没有这样一个疑问:
nova-api-metadata 是怎么知道应该返回哪个 instance 的 metadata?
c1只是向
169.254.169.254发送了一个 http 请求,nova-api-metadata 怎么就知道应该返回
c1的 metadata 呢?
下节咱们详细分析这个问题。
![](http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20170326-1490530368158014407.jpg)
相关文章推荐
- 通过 dhcp-agent 访问 Metadata - 每天5分钟玩转 OpenStack(168)
- 通过 dhcp-agent 访问 Metadata - 每天5分钟玩转 OpenStack(168)
- 通过 dhcp-agent 访问 Metadata - 每天5分钟玩转 OpenStack(168)
- 通过 floating IP 访问 VIP - 每天5分钟玩转 OpenStack(126)
- 通过 floating IP 访问 VIP - 每天5分钟玩转 OpenStack(126)
- 通过 floating IP 访问 VIP - 每天5分钟玩转 OpenStack(126)
- 通过 floating IP 访问 VIP - 每天5分钟玩转 OpenStack(126)
- 通过 floating IP 访问 VIP - 每天5分钟玩转 OpenStack(126)
- 获取 dhcp IP 过程分析 - 每天5分钟玩转 OpenStack(91)
- 访问外网 ML2 的配置 - 每天5分钟玩转 OpenStack(103)
- Service Plugin / Agent - 每天5分钟玩转 OpenStack(73)
- 访问外网 ML2 的配置 - 每天5分钟玩转 OpenStack(103)
- 配置 L3 agent - 每天5分钟玩转 OpenStack(99)
- 外网访问原理分析 - 每天5分钟玩转 OpenStack(105)
- 配置 L3 agent - 每天5分钟玩转 OpenStack(99)
- 配置 DHCP 服务 - 每天5分钟玩转 OpenStack(89)
- 配置 L3 agent - 每天5分钟玩转 OpenStack(99)
- Service Plugin / Agent - 每天5分钟玩转 OpenStack(73)
- 配置 DHCP 服务 - 每天5分钟玩转 OpenStack(89)
- 用 namspace 隔离 DHCP 服务 - 每天5分钟玩转 OpenStack(90)