云平台中的可用性集 在Azure当中有地缘组的概念(http://maomaostyle.blog.51cto.com/2220531/1585696),之前的博文也提到过，这是一种提高"性能"或者说是尽可能减少系统间延迟的手段，是出于性能保障的，那么从可用性角度而言，就要提到"可用性集(Availability set)"，Availability set是目前云平台上非常流行的一项"基本"功能，主要是提供一种高可用性的保障，在Azure当中对虚拟机提供最高99.95%的SLA承诺，注意是最高，因为如果用户期望获得99.95%的可用性，前提是你的虚拟机实例要放置在可用性集中才可以，那么就来具体瞅瞅何为可用性集。
公有云服务无论是微软的，阿里的或者亚马逊的，都有类似的功能，只不过可能名称不一样，以Azure为例，默认创建虚机时提供可用性集的配置选项，如下图：
同样也可以在创建虚拟机之后再配置可用性集，如下图:
例如我创建了一个叫做AS01的可用性集，在门户中会显示一个提醒，也就是说，当前可用性集中只有一台VM，这并没有任何意义，因为可用性集是要保证至少两台或两台以上数量的VM放置在可用性集中才有效果，为什么呢，因为同一个可用性集中的VM会被部署在不同的RACK上面，这个RACK可以简单理解为一个机架，或者说是一个单故障点，那么假设你有三个VM实例，可能有一台被部署在RACK1，另外两台在RACK2上，因此即便RACK2出问题宕了，但是底层会保证RACK1上仍留存一个在运行的VM实例。
在我的Azure订阅中再创建一台VM放置在之前准备好的AS01可用性集中，如下图:
此时可以看到在AS01中包含了两台虚拟机实例，此时vm01与vm02一定是被部署在不同的"RACK"上面的，稍后会对此做更详尽的解释，如下图:
####################################################################
上面提到的是Azure公有云当中的可用性集，那么在私有云中是否也具备这样的能力呢，答案是肯定的，下图依然是基于微软的私有云解决方案system center，随便找一台云中的虚拟机查看属性，在硬件配置中可以看到可用性集的管理，通过UI界面可以直接创建和分配可用性集，如下图:
分配后通过刷新虚拟机的动作就可以显示出当前所属的可用性集，通过下图可以看出私有云方案中虚拟机可以同属于多个可用性集，也就是说如果一套业务系统中的某一台虚拟机与其他前端或后端可复用，那么就比较适合下图中的场景，例如我有两个web server公用一个SQL服务器，那么web server01与SQL是一个可用性集，web server02与SQL是另外一个可用性集。
上图中是对VMM中的虚拟机进行可用性集管理，同样也可以通过windows cluster进行操作，因为在cluster中的一个属性"antiaffinityclassnames"对应的就是VMM中的availability set，所以通过PowerShell对某一个对象赋值，例如下图：
然后回到VMM进行对该虚拟机进行刷新，依然可以达到同样的效果。
当虚拟机具备了可用性集的属性之后，那么他在迁移的时候底层架构会做判断，例如下图中我有两个节点，分别把一个可用性集中的两台虚拟机部署在了每一个节点上，那么在试图迁移其中一个VM实例时，会有提醒告诉用户当前主机之允许一个可用性集成员，当然这是个warning，并不会强制限制后续操作。
###################################################################
但是从我个人角度来看，winserver+system center私有云当中的可用性集并无法和公有云比拟，可以说完全无可比性，为什么呢，因为首先在多租户场景中可用性集的存在是非常有必要的，但是私有云的方案并无法满足租户粒度的隔离，也就是说，在VMM中创建一个可用性集就是唯一的，但是在真正的云平台上，不同租户一定要在自己的隔离边界中创建可用性集，而不是仅依赖平台级的能力，那么Azure中的可用性集又是如何实现的呢？
首先Azure中的可用性集适用于两个场景，一个就是计划性维护，就是世纪互联会做顶定期的平台维护，好比网游公司的定期维护一样，这种维护窗口内的reboot是用户无法选择的，是一定要接受的。另外一种就是非计划性维护，也就是因为的RACK宕机。
两种维护都依赖于两个关键词，即FD(fault domain)和UD(update domain)，可以称为故障域和更新域，故障域就好比一个单故障点，好似上面提到的"RACK"而更新域则是针对每一台虚拟机实例，例如在计划维护时需要对租户的虚拟机进行reboot，此时如果Azure发现某个租户的虚拟机不在可用性集中，那么直接就reboot了，如果发现在一个可用性集中，就会按照UD顺序来进行重启，而不会一下子全reboot，以此来保障业务连续性。
同理在部署时，可用性集会考虑FD的分布，来尽量打散多个VM实例，以通过在不同的故障域中放置资源来抵消单点故障带来的破坏性影响。
因此在理解了可用性集的工作机制后，对于如何配置和规划资源也需要动动脑筋，从最佳实践上来看，对于一套应用系统，不同层次中的虚拟机应该放置在不同的可用性集中，以避免在一个可用性集中混淆了不同功能的虚拟机实例，例如下图中若是错误的将Web层与Data层的虚机放置在一个可用性集中，那么在例行维护中可能会导致错误的reboot顺序而产生业务中断。
回到刚才的demo中，在AS01中存在两台虚拟机时，可以在云服务中查看到当前的FD与UD信息，比如这里故障域和更新域都是不一样的，下图中分别是0和1。
而在三台实例的时候，更新域是0，1，2，而故障域则是0，1，0，也就是说如果故障域0出现了问题，但至少故障域1上还会有VM02在运行，同理在reboot时候，更新域0，1，2会依照顺序来启动而不会同时发生reboot，对于一个可用性集中的更新域数量，msdn中表示是5个，第六台虚拟机将会按照第一台来做放置计数，第七台按照第二台来识别，以此类推。
虚拟化环境下的CentOS7网络环境存在的问题 为什么要进行一次测试？
在使用CentOS7的过程中发现网络部分有很多与CentOS6所不同的地方。
1.CentOS7默认使用NetworkManager管理系统的网络而不再是network
2.NetworkManager默认使用的是nmtui或nmcli进行管理，不再是sysconfig中的ifcfg配置文件，但这些ifcfg文件依然被支持
3.默认NetworkManager和network同时在系统中工作，但NetworkManager要先于network启动
4.实际使用过程中发现即使在ifcfg配置文件中使用了静态IP地址以及静态DNS，在NetworkManager中依然使用自动获取（DHCP）的方式，自动获取IP地址和DNS服务器地址
5.NetworkManager默认使用ip命令来配置网络而不是ifcfgxxx，ip命令配置的网络重启后失效
测试环境：
测试虚拟化环境：VMware ESXi 5.1.0
操作系统：CentOS7.0（1406-x86_64），采用最小化安装（默认即是NetworkManager管理网络服务）
网络环境：多vlan的网络环境、其中一vlan设有DHCP服务
测试结果：
-
VMware VMXNET3 Ethernet Controller对应的网卡是ens160, VMware E1000 Ethernet Controller对应的网卡名称为ens32，CentOS7默认不支持VMXNET2，如果采用VMXNET3，则网卡编号为ens160、ens192和ens224，如果采用E1000则网卡编号为ens32、ens33、ens34。
-
如果在安装操作系统时在网络连接步骤中设定的是静态IP地址，则在ifcfg的配置文件中将会将IPADDR、PREFIX、GATEWAY的后面加一个0表示，并且将BOOTPROTO的值设为none，如果绑定一个公网IP地址的话将后面的数字将上加。
-
ifcfg文件中默认使用"NAME="而不是"DEVICE="，ifup和ifdown这两个命令都是使用的是"DEVICE="，测试过程中发现并不需要将ifcfg文件中默认使用的"NAME="换成"DEVICE="，network服务照样可以启动，但只有BOOTPROTO的值为none而不是dhcp时，nmcli中ipv4.method的值才是manual。
-
手动修改ifcfg文件不能触发NetworkManager应用这些变更，需要使用nmcli connection reload，或者使用systemctl restart NetworkManager.service，例如ifcfg中将BOOTPROTO从dhcp改为static，需要注意的是nmcli connection reload并不能代替systemctl restart NetworkManager.service，因为nmcli中的任何更改在save persistent之后将对ifcfg文件进行修改，但nmcli中的修改在系统中不会立刻生效，依然需要systemctl restart NetworkManager.service，此时通过ip a命令发现原先修改前的配置和修改后的配置都会留在系统中。
-
如果将NetworkManager禁用掉，那么nmcli、nmtui等命令将不再可用。
-
nmcli中的结果集可能会叠加，例如IP地址或DNS服务器地址可能存在多个，remove只能删除一个配置属性但不能删除整个结果集。
-
偶然遇到NetworkManager中的连接名称不是网卡名称的情况，可以用nmcli手动更改。
测试总结：
NetworkManager不如network使用起来方便和不出错，因此在不明就里之前建议谨慎使用NetworkManager。
tips：
在配置服务器时尽可能按照如下提示进行配置，以免除NetworkManager 所带来的麻烦和困扰
-
在安装操作系统时将网络配置好，打算采用动态IP就使用dhcp，打算采用静态IP地址就手动设置，提前设定好DNS服务器地址，或将DNS地址写进文件并设定好计划任务或者开机自动更新配置
-
尽可能的将DHCP关掉，特别是需要静态IP地址的服务器不要使用DHCP来获取哪些可能没有使用的地址，以免遇到上述测试结果中遇到的nmcli的结果集存在重复的情况
-
将NetworkManager禁用掉使用network，并不需要将ifcfg文件中默认使用的"NAME="换成"DEVICE="，network服务照样可以启动，网络在ifcfg配置文件配置正确的情况下依然可用，由于systemctl与services的不同，systemctl status network时将显示此服务中命令行的运行状态，例如network调用的是/etc/rc.d/init.d/network start，正确情况下此命令会返回代码为0并退出，这并不意味着network服务已经停止，用户只需要关心此状态中是否是绿色的active即可。
本文出自 "通信，我的最爱" 博客，请务必保留此出处http://dgd2010.blog.51cto.com/1539422/1592821
没有评论:
发表评论