haizdl
作者haizdl2016-12-08 17:01
技术经理, 大连

Vmware虚拟化实施过程中的最佳实践点探讨——— 如何配置虚拟化平台网络

字数 3774阅读 1677评论 0赞 0

1.背景介绍
互联网时代,最热的IT词汇莫过于云计算,所谓共有云、私有云、混合云等等。但是这些东西的奠基石就是虚拟化架构,没有虚拟化技术就没有今天的云计算。所以从另外一个角度来讲,虚拟化架构的健壮性决定了云的持久可用性。虚拟化技术包括很多,有基于Power架构的PowerVM,有基于X86架构的Xen、KVM、Vmware,也有基于容器技术实现的一些虚拟化技术,比如Docker。对于Vmware虚拟化技术来讲,我想大家都不陌生,或多或少都接触过,第一印象都是上手简单。但是真正在生产环境实施Vmware虚拟化基础架构的时候,有多少关键性的因素曾经被我们忽略过,有多少和其他网络设备、安全设备等配合实施的时候需要注意的地方被我们轻易带过,而因此导致生产环境的种种潜伏危机和故障问题。诸如此类问题:

  1. 究竟是用虚拟分布式交换机还是要用标准时交换机?
  2. 网卡绑定的时候究竟使用端口路由模式还是用基于MAC的路由模式?
  3. 具备负载均衡设备环境中,HA、DRS的规则有因该如何去设置?
  4. 每一个物理机器上的虚拟机以及虚拟机的存储空间如何配置才能合理?
  5. 端口组以及网卡的参数信息有好几页,难道一切保持默认配置就可以了么?

2.案例分析及总结
2.1 网卡绑定失误导致的业务中断案例
2.1.1 环境介绍:
宿主机四台,每台配置两块双口万兆网卡;接入交换机两台。
网络分管理网段和业务网段,每一个网卡上的双口分别上联两个不同交换机,交换机对端口设置Trunk模式,允许任何网段通过,不需要做绑定。网卡侧需要按照交叉方式绑定四个端口为两组,分别走业务和管理,交换机不需要绑定。

2.1.2 问题描述:
所有虚拟化环境部署完毕,在结合业务做切换测试的过程中,开发人员报告部分业务系统不可访问。

2.1.3 解决过程:
第一反应,先做客户端到应用系统的Ping测试。DNS解析没有问题,但是网络不可达。
第二反应,网络可能有问题,检查客户端到目标网段的网关可达性。网关全部可达。
第三反应,问题出在接入交换机和宿主机链接上,难道发生了双点故障?于是询问运维人员设备监控情况如何?运维人员说一切正常,没有发现异常。
第四反应,什么情况?监控一点直觉没有么?再问,
问:某某机柜某某交换机有没有问题?某某机柜某某服务器有没有报警?
答:回答说,没有报警,不过....。不过什么?有一个交换机在升级firmware,属于正常停机,不在异常范围之内。
问:就一个?
答:对,就一个。
第五反应,不对啊,任何单点都不可能影响到架构的高可用啊。VC登录上去查具体的机器状态,结果所有机器处于运行状态。再次确认问题出在接入交换机和宿主机之间的链接上。于是让运维人员进入机房再查网卡以及交换机状态。报告说有一台机器的其中一个网卡的两个口全部没有上联信号。
第六反应,网卡帮错了。再查,网卡绑定顺序与其他同类型的机器顺序一样啊。查MAC对应关系,结果发现这台机器的Vmware显示的网卡顺序确实与其他机器识别达到的网卡设备名顺序不一样。当初实施工程师仅仅靠着一个样本机的网卡设备文件名与物理网口的对应关系就按照一个标准实施了。

2.1.4 问题总结:
对于这个案例来讲,其实高可用的设计也好,网卡绑定技术也好都不是问题。问题的关键是工程师想当然认为一种型号的机器对于IO设备文件名的识别顺序是完全一致的。其实不然,不同场合下可能设备文件名的顺序会产生不一致。幸亏这个问题是在测试阶段发生。两个教训:第一、不要想当然,用事实说话。第二、实施后的检验过程非常重要,可以救你一条命。

2.2 防火墙导致的宿主机失联
2.1.1 环境介绍:
多套vmware虚拟化集群组成一个VDC,分别位于不同的安全隔离区内,VC处于一个独立的安全隔离区内,每套虚拟化集群当中有若干宿主机。也就是说宿主机和VC分别属于不同的安全隔离区,分属不同的网段。

2.1.2 问题描述:
虚拟化基础架构部署全部完毕,运行一致良好。突然间有一天发现其中一个安全隔离区内的宿主机有一个掉线了。还没等我来的及区调查原因,这个宿主机又恢复正常了。

2.1.3 解决过程:
第一反应,别的先别说,不可再现的问题,先看日志吧。结果发现其中一个宿主机掉线非常频繁,其他几个宿主机偶尔都会发生掉线现象。而且现象只发生在其中一个安全隔离区内,其他隔离区内没有此现象。
第二反应,问问应用那边,看看有没有察觉到异常。结果没有。
第三反应,那不用多想了,这个离线一定是宿主机跟VC之间的通讯断掉了,没有影响到正常的业务系统。
第四反应,看看日志,第一感觉没啥有价值的线索。为啥其他集群没事儿呢,想想这个区和其他区的区别在哪里?同一个VC,只不过分属不同的安全隔离区而已,只不过这个区属于互联网区,网络层多了几层隔离而已。
第五反应,一方面,收集日志发给厂商。另外一方面,交叉测试,于是乎,
交叉换网卡,还是一个德行。
交换换交换机,好像好一点,但是还会出现类似问题。
第六反应,那剩下的区别就在防火墙上了,防火墙这个区用的是莫某家的,跟其他不一样。不至于吧,虽然国产,但是也经得起推敲啊。于是把网络的运维工程师以及厂商叫过来抓包,抓了好几天,问题没有重现。等吧,Vmware那边终于给回复了,说是VC和宿主机的通讯被周期性阻断了。
第七反应,多半是防火墙上的设置,找吧。对比两家厂商的防火墙设置,终于发现了一个配置“Keep Alive”,问网络厂商是不是可以像别人家的防火墙把这个开关关掉。回答说不能。靠,为什么?回答说,产品默认设置。问曰,你们有没有在别家跟虚拟化产品配合过?回答曰,配合过,没这个问题啊。啥也别说了,升级给网络后线吧。过了几天,回复了,“Keep Alive”在防火墙上可以吧UDP的关掉,TCP的不能关掉。OK,要的就是这句话,把UDP关掉之后,观察了N天,一切OK。

2.1.4 问题总结:
对于这个案例来讲,更多的关注点是在虚拟化架构与其他厂商设备配合过程中的问题。一个很不经意的配置可能会引起很严重的问题。大家多多交流,上下游交流,同游交流,不仅仅知道自己的一亩三分地,也同时知道他人的一幕三分地,对于实施来讲就会带来更大的专家价值。

2.3 操作失误导致的写入失败
2.1.1 问题描述:
有一个DataStore始终写入失败,报错很简单,就是写入失败。

2.1.2 解决过程:
第一反应,先确定是宿主机问题还是存储问题。测试其他DataStore,完全正常。那就把问题缩小到这个DataStore上来。可能是挂载或者格式化的时候出现了问题,重新来呗,结果还是一样。
第二反应,重新挂,从存储上把Lun抽回去然后再分配给主机。还是一个熊样。
第三反应,查看Vmware底层日志,看似有锁信息。
第四反应,谁加的锁呢?为什么不释放呢?
第五反应,仔细询问实施工程师,原来这个DataStore并没有从Vmwware层面进行卸载就通知存储工程师将其重新分配了。他说这么干过很多次了,重来没没有出过问题。
第六反应,不用想了,Vmare对这个Datastore加了scsi锁,这个锁加在了Lun的盘头。在非正常释放Datastore的场合下,及时存储回收了,当它再次给到Vmware的时候,盘头信息并没有消除。锁依然存在,所以无法写入。
第七反应,存储上讲该存储回收再次分配。问题消除。

2.1.3 问题总结:
试想,如果当时工程师按照正常的流程,把磁盘从Vmware层面进行卸载,然后存储再回收,那就不会有这个问题了。对于这个案例来讲,想告诉大家的是不要想当然,999的成功不等于1000一定成功。因为我们面对的外在环境不一定相同或者相似。所以一切操作请按照正确的流程去做。

2.4 环境变迁导致的热迁移失败
2.1.1 问题描述:
这个问题跟Vmware没有任何关系哈,首先澄清。在我们对另外一款虚拟化软件进行测试的过程中,曾经发生过这么一件有趣的事情,供大家参考。Vmotion应该算是所有虚拟化软件必备的功能,它除了要保障虚拟机能正常迁移到其他机器上,另外客户端的访问不能中断。我们在测试的过程中,可能更多的关注的是虚拟机迁移前和后的转台时候有异常,对于客户端的访问似乎多少有些忽略。一次测试过程中,我发现虚拟机正常迁移到其他的宿主机上,但是客户端访问却中断了。

2.1.2 解决过程:
第一反应,虚拟机迁移正常,状态正常。那么问题应该出在网络连接上,于是尝试查看网关的连通性。网关没有问题。
第二反应,回过头来想想迁移前后的变化。内存拷贝过程应该没什么问题,不然机器状态会有问题。接下来就是网络的问题,迁移之后,网卡MAC映射发生变化了。
第三反应,从虚拟机内部往外ping个包试试看,客户端访问马上通了。
第四反应,不用琢磨了,网络上的ARP没有及时更新,导致交换机不知道往哪儿送数据包。
第五反应,这个动作应该由Vmotion的软件主动通知交换机,恰恰这个虚拟化软件缺少了这个功能,或者说不够完善。

2.1.3 问题总结:
其实这个问题跟我们工程师的实施和运维都没有太大关系,只是在提醒更多同业者在选型和测试过程中要关注的更细节。因为对于刚刚创业或者起步的新技术或者新产品来讲,经历的考验更多的是实验室环境下的各种场合。并没有经历过真正的复杂生产环境下的考验。任何简单环境下的测试结果是有一定局限性的,我们在选型的时候要充分考虑到这一点。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广