![Openstack 似乎无法正确将内部 IP 映射到本地网络](https://linux22.com/image/619416/Openstack%20%E4%BC%BC%E4%B9%8E%E6%97%A0%E6%B3%95%E6%AD%A3%E7%A1%AE%E5%B0%86%E5%86%85%E9%83%A8%20IP%20%E6%98%A0%E5%B0%84%E5%88%B0%E6%9C%AC%E5%9C%B0%E7%BD%91%E7%BB%9C.png)
我有一个非常令人困惑的问题,似乎无法解决。
我遵循了洛伊克达查里在 Wheezy 上安装 Openstack Folsom,并将其部署在两台主机上:一个集群节点和我的工作站。
在这两台主机上,我运行一个基准测试应用程序,该应用程序以以下方式从一台主机与另一台主机进行通信:
以下是节点主机、工作站和内部虚拟机的路由表:
(笔记:10.0.1.0 条目用于附加网络接口。它最终变得不再需要,并且未在任何虚拟机上启动。因此,它没有影响,因为没有任何东西被路由到目标 10.0.1.x)
现在,我的问题如下:
基准测试应用程序从工作站上的一台虚拟机(例如 10.0.0.2)启动 RMI 调用到节点上的一台虚拟机(例如 172.23.3.100)。
据我了解,应该发生以下情况:
VM 看到目标 172.23.xx 网络路由并通过默认路由 10.0.0.1(工作站计算主机)
nova 网络服务发现 10.0.0.2 已映射到本地网络上的某个 IP(例如 172.23.12.1)。因此它将源 IP 更改为该 IP。
工作站主机看到目的地 172.23.xx 并通过 172.23.1.1 路由到 172.23.3.8。
Nova 网络看到 IP,并且由于映射 172.23.3.100 -> 10.0.0.7 存在,它将目标更改为 10.0.0.7。
内部 IP 为 10.0.0.7 的节点上的 VM 从工作站 VM 获得请求。(@ 172.23.12.1)。
一切正常。实际请求已发送。但是,回复存在问题。
以下是请求发送后我的应用程序运行的日志:
RemoteException was: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
-> java.rmi.ConnectIOException: Exception creating connection to: 10.0.0.7; nested exception is:
-> java.net.NoRouteToHostException: No route to host
因此,节点虚拟机回复的源地址一定是 10.0.0.7。换句话说,nova 网络服务从未将节点虚拟机的源 IP 更改为可路由的 172.23.xx 地址!
这怎么可能?两个虚拟机都可以 ping 自己(节点->工作站,工作站->节点),而且我没有发现路由表有任何问题。
这仅有的我能看到的奇怪因素是以下跟踪路由信息:
工作站虚拟机 -> 节点
root@client-01:~# traceroute 172.23.3.8
traceroute to 172.23.3.8 (172.23.3.8), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.406 ms 0.399 ms 0.390 ms
2 172.23.3.8 (172.23.3.8) 0.381 ms 0.378 ms 0.422 ms
root@client-01:~#
节点虚拟机 -> 工作站
root@idleserver-vm:~# traceroute 172.23.19.176
traceroute to 172.23.19.176 (172.23.19.176), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.741 ms 0.676 ms 0.657 ms
2 172.23.19.176 (172.23.19.176) 0.643 ms 0.638 ms 0.626 ms
root@idleserver-vm:~#
这些工作正常。然而...
节点虚拟机 -> 工作站虚拟机
root@idleserver-vm:~# traceroute client01
traceroute to client01 (172.23.12.1), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.808 ms 0.739 ms 0.721 ms
2 client01 (172.23.12.1) 0.707 ms 0.702 ms 0.688 ms
3 * * *
4 * * *
5 * * *
工作站虚拟机 -> 节点虚拟机
root@client-01:~# traceroute idleserver
traceroute to idleserver (172.23.3.105), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.296 ms 0.239 ms 0.224 ms
2 idleserver (172.23.3.105) 0.213 ms 0.200 ms 0.189 ms
3 * * *
4 * * *
5 * * *
由于同样的原因,这些似乎没有从终端虚拟机获得回复。但是,Ping 工作正常:
root@client-01:~# ping idleserver
PING idleserver (172.23.3.105) 56(84) bytes of data.
64 bytes from idleserver (172.23.3.105): icmp_req=1 ttl=62 time=1.02 ms
64 bytes from idleserver (172.23.3.105): icmp_req=2 ttl=62 time=0.914 ms
root@idleserver-vm:~# ping client01
PING client01 (172.23.12.1) 56(84) bytes of data.
64 bytes from client01 (172.23.12.1): icmp_req=1 ttl=62 time=0.675 ms
64 bytes from client01 (172.23.12.1): icmp_req=2 ttl=62 time=0.875 ms
这到底发生了什么事?
编辑:与网络管理员交谈后,他帮助我稍微排除了故障。似乎 nova-network 未正确让 UDP 数据包通过,因此 traceroute 失败。使用以下命令:
root@idleserver-vm:~# traceroute -T client01
traceroute to client01 (172.23.12.1), 30 hops max, 60 byte packets
1 10.0.0.1 (10.0.0.1) 0.766 ms 0.756 ms 0.748 ms
2 client01 (172.23.12.1) 0.737 ms 0.728 ms 0.720 ms
3 client01 (172.23.12.1) 1.046 ms 1.046 ms 1.034 ms
我做接收虚拟机和请求虚拟机上都打开了 UDP 端口(我也尝试了确信是打开的特定端口),所以我认为这不可能是端口问题。
(PS:我也在 ask.Openstack 上发布了此问题,希望获得更多浏览量并更快地得到解决)