FlexPod上安装vSphere 5.5配置中的排错(4)

delxu原创，首发于delxu的技术博客delxu.blog.51cto.com和本人博客delxu.wordpress.com。转载请标明出处。    

背景：FlexPod的UCS部分的配置已经完成了，ESXi 5.5主机也安装完成了。在第一台ESXi主机配置的时候，我们连接到了NetApp FAS3220A的一个Volume上，建立了一个NFS datastore。我们在这第一台主机上安装了第一个Windows Server 2008R2操作系统，并安装了vCenter Server 5.5。是的，vSphere的安装配置需要vCenter Server的支持，因此这第一台虚拟机必须是也只能是vCenter。    

在还没有vCenter Server之前，第一台ESXi主机是无法配置分布式交换机的，只能配置标准vSwitch。通过标准vSwitch的NFS vmkernel，我们建立了到NAS的万兆链接，这条万兆链路配置在了一个专用的隔离的VLAN中，VLAN ID是63。而ESXi主机的管理端口位于另外一个VLAN 60中。    

vCenter建立起来后，我们就把另外2台主机加入到vCenter中进行集中管理，建立了HA/DRS的Cluster，并做了几次vMotion，都很顺利，速度也很快。我们做了一个简单的磁盘性能测试，发现vCenter Server这台虚拟机的本地磁盘读写速度最高只能达到99MB/s。这个性能似乎太慢了点了。    

进一步检查，发现原来性能慢的根本原因是我们在配置NFS datastore的时候用错了NAS的接口地址，应该用VLAN63上的地址，我们却用了VLAN60的接口地址，NAS在VLAN60上的接口地址是NAS的管理地址，是一个千兆接口，并不是配置在VLAN63中的万兆接口。因此ESXi主机是在用自己的管理端口通过和NAS的管理端口通讯建立了这个NFS mount。这相当于在管理VLAN上跑存储网络数据了，这个错误必须纠正过来。    

我们试图用umount掉当前的datastore再重新mount到正确的接口上的方法来纠正，但是发现这不可行，因为这个datastore上有一台虚拟机在运行！这台虚拟机就是我们的vCenter。    

那好，我们就关掉这台vCenter，再用vSphere Client直连ESXi主机管理的方式，来umount这个datastore，这样总行了吧。还是不行！这是因为我们已经建立了一个HA Cluster，从vSphere 5.0开始，为了避免split brain的情况，HA的Cluster多了一个仲裁的方法，就是datastore HB，HA会选定2个datastore作为仲裁datastore，定期访问，来判定主机是否活着。因此，在有HA配置的情况下，这个datastore就是被占用的，被锁定的，无法umount掉。    
没有vCenter就没法禁用HA，于是又开启vCenter虚拟机，停用HA，并试图将主机移动到Cluster之外，却发现主机要移出cluster，必须先进入维护模式，那么vCenter VM就会vMotion到另外的主机上，当Cluster里面只剩下一台主机的时候，我们就无法将其移动到Cluster之外去了，这时候必须先关掉最后一台主机上所有的虚拟机，才能移动。可是要关掉的是vCenter VM呀，vCenter关掉之后，就没法进行配置了。。。    

写了以上那么多，其实说明了一个问题，当vCenter是一台虚拟机，并且位于其自己管理的主机和群集上的时候，维护工作会处处受限，请一定要小心了。    

那有什么办法解决我们这个错误的datastore的问题呢？难道这个错误就必须将错就错，我们就必须一直忍受最高才100MB/s的较慢性能么？    

办法是有的，聪明的同学可能已经想到了，那就是——Storage vMotion。    

于是我们重新建立了一个NFS的datastore，这次用了正确的VLAN63上的万兆接口。然后。。。。。。storage vmotion。。。问题应该解决了吧？    

更大的问题出现了……    

Storage VMotion不成功，停在14%很久，期间，新mount的datastore变灰，还多了(inaccessible)的字样。神马！？datastore掉线了？这个问题严重了呢。    
我试图browse这个新建datastore，却发现连文件列表都刷新不出来，网络速度异常慢。可是，我们成功mount了这个datastore，说明网络是通的呀。而且在mount之前，我们其实是在主机上ping过NAS的，是能ping通的呀。    

回想起来，vMotion不能、datastore变灰、显示inaccessible，这种情况我上次也遇到过，当时的最终原因是思科交换机上的万兆模块是假模块，替换后问题解决的。这次难道模块又有问题？应该不会呀，不过可以肯定的是这个问题多半还是出在网络上。    

我怀疑是Jumbo Frame设置不正确。    

于是去主机的console上试着ping大包。（ping大包用下面的命令行，记得这是通过vmkernel来ping外部存储的，所以必须用vmkping命令，而不是普通的ping命令）    

# vmkping –d –s 8972 10.86.63.11    

果然不通。    


于是坚定了我的判断。    

Jumbo Frame的配置需要整条链路从一端到另外一端中间每个设备每个接口都支持Jumbo Frame，如果有一处设置不正确，就有可能会有问题。在我们的FlexPod环境下，这包括NAS端口设置、Nexus 5548、FI6248、UCS 网卡、VMware vSwitch这五个部分。再次检查后发现FI6248和Nexus5548上的Jumbo Frame QOS没有正确设置。更改后问题解决。    

vmkping 大包成功。Datastore browse 流畅。    
 

最后，我们的Storage VMotion也成功了，顺利地将vCenter Server VM迁移到了正确的datastore上来。在所有虚拟机（其实就vCenter这一台啦）都移走之后，这个错误的datastore终于可以被umount了。    



那么如何来检查FlexPod这些组件的Jumbo Frame设置呢？下面我会一一的作个简单的介绍：    

一、检查NetApp NAS

检查NAS的方法是查看你配置的端口是否设置了MTU 9000。命令行么就是ifconfig    

NAS> ifconfig vif11-63      
vif11-63: flags=0xb4c863 mtu 9000      
inet 10.86.63.11 netmask 0xffffff00 broadcast 10.86.63.255      
ether 02:a0:98:4e:83:b8 (Enabled interface groups)


二、检查Nexus 5548交换机配置

5548-A# show running-config      
.. .. ..      
policy-map type network-qos jumbo        
 class type network-qos class-fcoe        
   pause no-drop        
   mtu 2158        
 class type network-qos class-default        
   mtu 9000        
   multicast-optimize        
system qos        
 service-policy type network-qos jumbo

找到其中有如上配置，即可。记得2台5548都要检查。如果没有，那就configure terminal进入配置模式，然后把上面这几条命令输入进去。    

三、检查FabricInterconnect 6248
在UCSM的管理界面中，LAN页，在Filter下拉菜单中选择选择LAN Cloud。并找到QoS System Class，然后检查右侧Best Effort的MTU应该设置为9000    
 

四、检查UCS网卡的设置      
在UCSM的管理界面中，选择Servers页，在Filter下拉菜单中选到Service Profiles，然后找到vNICs中配置给存储网络的那几个网卡。    

然后在右侧检查MTU值是否已经是9000了。    


修改需要到该vNIC对应的vNIC Template里面去修改哦。    

五、检查VMware标准vSwitch配置      
在vSphere Client管理界面中，左边选择要查看的ESXi主机，右边选Configuration页，检查Networking配置。    
选ESX_NFS这个VMkernel，点Properties    
 

然后就可以查看vSwitch和用于NFS的这个vmkernel的MTU设置是否是9000。    

delxu原创，首发于delxu的技术博客delxu.blog.51cto.com和本人博客delxu.wordpress.com。转载请标明出处。