服务器 Gind.cn
  1. 服务器 Gind.cn
  3. Openstack似乎没有正确地将内部IP映射到本地networking
Intereting Posts
etckeeper推到github 如何将公共静态IP路由到vmware ESXi主机上的虚拟机？ 两台DHCP服务器在同一个范围内 – 当IP地址用完时会发生什么情况？ 使用nginx将许多域redirect到其他域的不同位置，而不必定义许多服务器块 用cherry.py web服务器运行php？ 问题安装与msxml6相关的sql 2005 计算和计费Internet上的IP多播使用情况 stream量控制：标记数据包进行整形 从客户端到Hyper-V主机/客户端的文件传输速度很慢，但是从Hyper-V主机/客户端到客户端/我的PC很快 禁用LaCie 1TB高速USB 2.0外置驱动器上的蓝色LED NFS共享问题 – RPC：片段太大：xxxxx 使用微软自己的SMTP服务器与第三方服务器有什么优缺点？ 托pipe1000个域的网站引擎上的SSL 如何诊断Tomcat 6突然停止响应？ 在Windows Server上复制文件夹时保留文件权限

Openstack似乎没有正确地将内部IP映射到本地networking

我有一个令人困惑的问题，我似乎无法解决。

我遵循了由Loic Dachary在Wheezy上安装Openstack Folsom的指导，并将其部署在两个主机上：一个集群节点和我的工作站。

在这两个主机上，我正在运行一个基准testing应用程序，以下列方式从一台主机传输到另一台主机：

图片描述

以下是节点主机，工作站和内部VM的路由表：

图片描述

（ 注意 ：10.0.1.0是一个额外的networking接口，最终不需要任何虚拟机，因此没有影响，因为没有任何东西被路由到目的地10.0.1.x）

现在我的问题是：

基准testing应用程序从工作站上的一台虚拟机（比如10.0.0.2）启动一个RMI调用到节点上的一台虚拟机（比如172.23.3.100）。

我的理解是，应该发生以下情况：

  1. 虚拟机看到了预定义的172.23.xxnetworking路由，并经过了默认路由10.0.0.1（工作站计算主机）

  2. novanetworking服务将10.0.0.2映射到本地networking上的某个IP（比如172.23.12.1）。 所以它将源IP更改为

  3. 工作站主机看到目的地172.23.xx，并通过172.23.1.1路由到172.23.3.8。

  4. Novanetworking看到IP，并且由于映射表示，存在172.23.3.100 – > 10.0.0.7，它将目标更改为10.0.0.7。

  5. 具有内部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。 换句话说，novanetworking服务从未将节点VM的源IP更改为其可路由的172.23.xx地址！

这怎么可能？ 这两个虚拟机都可以ping自己（节点 – >工作站，工作站 – >节点），我没有看到任何路由表的错误。

我能看到的唯一的奇怪因素是以下跟踪路由信息：

工作站VM – >节点 

 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:~#

这些工作正常。 不过 …

节点VM – > Workstation 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 * * *

这些似乎没有从最终的虚拟机得到答复，可能是由于相同的原因。 但是，坪工作得很好： 

 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

世界上可能会发生什么？

编辑 ：在与networkingpipe理员交谈之后，他帮我解决了这个问题。 似乎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。我把这张贴出来问.Openstack也希望能得到更多的意见和更快的解决scheme）