經過 dhcp-agent 訪問 Metadata - 天天5分鐘玩轉 OpenStack（168）

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

重啓 dhcp-agent 後，能夠看到控制節點上多了一個 neutron-ns-metadata-proxy 進程。

此進程經過 --network_id 關聯到 test_net，這就是 dhcp-agent 啓動的 neutron-ns-metadata-proxy，用於接收 test_net 網絡上 instance 的 metadata 請求。每個 network 都有一個與之對應的 neutron-ns-metadata-proxy。

重啓 instance c1，查看路由表。

請注意，如今訪問 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。

同時咱們也看到，dhcp-agent 已經將 IP 169.254.169.254 配置到了本身身上。也就是說：c1 訪問 metadata 的請求 http://169.254.169.254 其實是發送到了 dhcp-agent 的 80 端口。而監聽 80 端口的正是 dhcp-agent 啓動的 neutron-ns-metadata-proxy 進程。

後面的數據流向就與 l3-agent 的場景同樣了：neutron-ns-metadata-proxy 將請求經過 unix domain socket 發給 neutron-metadata-agent，後者再經過管理網絡發給 nova-api-metadata。

到這裏，咱們已經分別討論了經過 l3-agent 和 dhcp-agent 訪問 metadata 的實現方法。對於 169.254.169.254：

1. l3-agent 用 iptables 規則來轉發。

2. dhcp-agent 則是將此 IP 配置到本身的 interface 上。

不知道你們有沒有這樣一個疑問：

nova-api-metadata 是怎麼知道應該返回哪一個 instance 的 metadata？c1 只是向 169.254.169.254 發送了一個 http 請求，nova-api-metadata 怎麼就知道應該返回 c1 的 metadata 呢？

下節我們詳細分析這個問題。