炼数成金 门户 图书 查看内容

OpenStack 的网络(十八)

2015-7-2 11:28| 发布者: 博文视点| 查看: 1716| 评论: 0|原作者: 李俊武|来自: 云计算网络珠玑

摘要: 6 Neutron 网络高级话题讨论 Neutron 的使用和部署已经有很多的案例,比如Unitedstack 的公有云和托管云的底层网络Core Plugin,使用的就是Neutron 中Open vSwitch 的方案,但是在云计算中Neutron 网络的研究和部署 ...

网络 测试 服务器 案例 云计算 Openstack

6 Neutron 网络高级话题讨论

Neutron 的使用和部署已经有很多的案例,比如Unitedstack 的公有云和托管云的底层网络Core Plugin,使用的就是Neutron Open vSwitch 的方案,但是在云计算中Neutron 网络的研究和部署中确实都遇到了很多问题,确实还有很多云计算公司倾向于采用简单稳定的Nova-network 技术,毕竟对于生产环境的产品,稳定性压倒一切;即使功能再丰富,系统不定期的故障导致客户数据丢失或业务的间歇性服务故障的现象,必然结果是没有客户再信任该云计算方案或平台的提供商;所以就像网络历史中任何新技术的出现一样,必然会有一个产生、发展和成熟的时间历程。Neutron 现在经历了若干个版本的迭代,已经修复了大量BUG,并且提供的网络功能在大量测试后不断完善,随着云计算厂商研发人员深入的研究和改进,及使用Neutron 相关的云计算平台的不断增多,会有越来越多的部署案例使用Neutron 技术,并且在J 版中Nova-network 已经被标注。在OpenStack的技术交流qq 群里(群号:347195472)也有非常多新入门或不熟悉网络的初学者咨询各种网络问题。本节对常见的问题及通用的解决方法进行下汇总。

6.1 常见Neutron 网络问题

搭建完OpenStack 的实验环境后,需要对网络进行做些修改配置才能使得OpenStack 的虚拟网络为VM 提供正常服务。由于OpenStack 的安装者或网络配置者不熟悉网络原理、其他原因操作不当或配置不完整等原因导致的网络问题时有发生。这里对常见的Ping 不通外网Ping 不同VMVM 无法获取DHCP 地址等常见问题进行汇总,剖析导致问题发生或出现异常的可能原因,为解决这些问题提供参考的思路和定位问题的手段。下面讨论的情形大部分是针对用Open vSwitch Plugin 且使用VLAN 隔离环境下VM 采取DHCP 的方式获取IP 地址的场景。

通常情况下VM 启动时,会和相应网段的DHCP 功能的进程Dnsmasq 进行交互,基本就是DHCP 的交互流程,并获取DNS 的配置信息。当OpenStack 安装完毕建立VM 后,如果VM 能够启动但是无法获取IP 地址时,即VM 在内部用Linux系统的ifconfig 命令或Windows 系统用IPconfig 等查看网卡信息,可以看到相应的网卡下没有IP 地址或没有有正确的IP 地址,这种情况的发生必然是因为DHCP的交互过程不完整导致的,具体问题原因定位可以分这么几步来进行:

1)首先需要到网络节点看下相应网段的Dnsmasq 进程是否启动正常,如果没有启动需要分析下没有自动启动的原因,排除错误让Dnsmasq 能正常启动后后再尝试VM 获取DHCP 的流程,以保证Dnsmasq 可以正常为该网段的VM 提供DHCP 服务;

2)如果Dnsmasq 的进程正常,VM 仍然还是无法通过DHCP 的流程获取IP 地址,则需要根据VM 的启动日志判断分析DHCP 的交互过程是卡在了哪一歩,大部分都是Discover 这个报文发出后没有得到Offer 报文,可以初步判断是因为底层网络通路配置不正确导致的;底层网络不通的原因有很多,可能是VM所在物理服务器的网卡网线松动(用ethtool eth0 格式的命令查看网卡是否active即可);如果是在采用VLAN 技术的隔离环境里,更重要的原因有可能是因为VLAN 在交换机上配置的范围和OpenStack 的不匹配,因为OpenStack 安装时会指定物理交换机的VLAN 范围,那么在Open vSwitch 会配置VLAN Translation的功能,并且物理交换机上要配置添加OpenStack 指定的VLAN 范围内的所有VLAN ID,连接服务器的交换机端口还要配置成Trunk 模式。

3)如果Dnsmasq 进程没有问题且VLAN 物理交换机和OpenStack 的虚拟网络配置都匹配,VM 仍然无法通过DHCP 获取IP 地址的话,这个时候基本上是交换机的ACL 或者服务器的IPtables 规则将DHCP 的交互报文丢弃导致的,就需要根据DHCP 交互报文的特征去查看交换机的ACL 规则和IPtables 规则,来确认是否有规则匹配到报文且把相应的报文丢弃了,采用VXLAN 的方式隔离时就需要对IPtables 做配置以放行VXLAN 格式封装的报文(主要是匹配VTEP的地址和UDP 的目的端口4789)。通过以上三步,基本可以定位出VM 无法通过DHCP 获取IP 地址的确切原因。

VM 建立后,后续的工作就是想让其能访问公共网络或OpenStack 所指定的public 网络,测试方式往往是Ping www.baidu.com Ping 114.114.114.114,如果遇到Ping 不通外网设备的情况就需要按照如下步骤对问题进行定位:

1)如果Ping 114.114.114.114 能够通信,仅是Ping www.baidu.com 不通,基本可以断定是该网段的DNS VM DNS 配置有问题,修改下相应的DNS配置信息即可;

2)如果Ping 114.114.114.114 Ping www.baidu.com 都不通,那么应该是确切的VM 无法访问外网,这时候先看VM 是否有正确的IP 地址,如果没有正确的IP 地址可以参考前文所述的VM如何获取正确获取IP 地址的步骤进行定位;

3)如果VM 有正确的IP 地址但仍然无法访问外网,先判断VM 所连内网对应的虚拟路由器是否设置了public 网为外网网关,并且public 网是可以与互联网通信的;很多时候该步骤的原因是租户或管理员将外网直接在虚拟路由器中进行加入接口操作,而不是将其设置为默认网关;


本文摘自《云计算网络珠玑》



鲜花

握手

雷人

路过

鸡蛋

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

热门文章

     

    GMT+8, 2017-12-19 00:46 , Processed in 0.180833 second(s), 24 queries .