精彩继续 1.Hyper-V 融合群集网络-低调大师

精彩继续 1.Hyper-V 融合群集网络

2017-11-11 573

一直很想写这篇博客，与大家探讨交流这项技术， Hyper-V Converged Network，中文我将它翻译为融合网络，后来老王又发现这项技术似乎没有群集的话意义不大，所以加上了群集二字，之前很少看到国内有人写过这方面的博客，但是在国外从2012开始已经有不少人对这项新技术进行了尝试，到Windows Server 2016,Converged Network模型更是支援了RDMA，因此决定写这篇博客，希望能够让更多中国的微软ITpro们知道这项技术，为大家抛砖引玉，内容不对之处欢迎探讨指正

在介绍融合网络之前，我想先和大家探讨下Windows上面群集网络的规划，之前几年老王有幸参与过一些项目的实施，发现国内实施微软群集的工程师们似乎都并不太在意群集网络方面的规划，一些小型的场景，甚至就放了一块网卡，承载群集的所有流量，有的有良心一点会放两快卡，一些大型企业实施的时候会把管理，VM，心跳，存储，四种分开，这似乎是国内大中型企业做群集时候的网络标配，土豪一点的会为每种类型的网络配置Teaming或者MPIO，多通道等技术

按照微软的最佳实践来讲，微软建议切割五种群集网络，管理，VM，迁移，心跳，存储，微软将迁移流量也建议单独隔离出来，实际上我是理解微软这种考虑的，我猜想微软总部这样考虑，也许是考虑到大型场景下，可能是一个私有云，或者托管很多虚拟机的虚拟化架构，可能会频繁进行大规模迁移的场景下，同时VM也面临着业务上面的大并发访问，这时候可能一组网络难以支撑，会导致某些场景下的性能下降，但其实根据老王的观察，目前国内使用Hyper-V的企业很少会达到微软这种场景的设想，通常情况下一组LACP teaming 20GB的流量怎么也hold住VM访问+迁移流量了，因此国内很少看到单独独立出迁移网络的群集架构

所以国内用户可能比较常见的就是这种，管理，VM+迁移，心跳，存储的架构，有的公司可能一组LACP teaming 直接把管理，VM，迁移三种放在一起，然后，心跳，存储，一共三个群集网络，这也是一种国内常见的群集网络架构。

这里老王想格外与大家进行探讨的是里面“心跳” 这种群集网络，国内对于这种类型的群集网络通常都叫它心跳网络，似乎这个网络只是用做心跳检测，其实并不是这样，严格来讲，这种类型的网络应该叫做群集通信网络，国外也有人叫它CSV网络。

群集通信网络其实承担着3种功能的流量，在2012之后开始发生了一些变化

1.运行状况检测网络，群集大家都知道，所有节点需要访问同一个共享存储，在群集创建群集角色或群集功能，角色产生的数据会存在共享存储，然后群集之间会做运行状况检测，为什么要做这个检测呢，就是为了知道其它节点现在活不活着，例如群集当前两个节点，他们每隔一秒都会通过3343端口和对方执行一次实际的握手检测，每次发送一个134 byte的包，除了确认对方在线，对方也会确认你在线，双方确认完成一次检测结束，当检测达到一定阈值，例如默认情况下同一子网内每隔一秒全网检测一次，如果一个节点五次检测均没有回应则视为该节点下线，群集其它节点会检查自身群集注册表查看该节点承担角色功能，然后进行迁移出来，跨子网默认也是每隔一秒全网检测一次，五次失效视为该节点下线。如果群集节点启用了Hyper-v角色，默认本地子网每隔一秒全网检测一次，十次失效视为该节点下线，跨子网每隔一秒全网检测一次，二十次次失效视为该节点下线。在2016里面新增了跨站点的检测模式，如果检测到群集设置了站点，则当跨站点，跨子网或不跨子网的情况下，跨站点的检测策略会优于跨子网的检测模式执行。

如上所述，运行状况检测网络是群集里面很重要的内容，通过检测结果来确认一个节点是否存活，因此对于该网络的质量要求极高，可以带宽不高，但一定要确保质量，确保不会被其它流量干扰，确保不会出现丢包，否则如果出现丢包或者流量干扰的情况就会导致群集的运行状况检测失去准确性，本身存活的节点却因为检测不准确而被下线。

因此，老王建议，做群集，至少至少应该分为两种网络，一块承担管理VM迁移存储等流量，一块用于承担群集通信网络的流量，请注意这种运行状况检测是群集内的一个全网检测，每个节点发送检测时会发给所有节点，确保群集每个节点与节点之间都能够知道对方的状态。

2.群集内数据库同步流量

上面讲到当一个节点下线时，群集会触发故障转移操作，其它节点检查自身的群集数据库，查看下线的节点，承载了什么角色，然后上线该角色，并挂载上该角色依赖的群集组，然后客户端重新访问，这是群集最简单的一个故障转移原理，大家可能会注意到里面有一个群集数据库，这个数据库和SQL的数据库，exchange的数据库都没关系，是群集用来存放各个节点的状态，以及各节点hosting角色状态的一个数据库，该数据库主要存在于各群集节点本身的注册表上，如果有磁盘见证的话那么磁盘见证里面也会存放一份，例如节点1当前在线，它上面运行了DHCP角色和文件服务器角色，当前状态是在线，或节点1上面承担了HyperV角色，现在上面跑了十台虚拟机，五台在线，五台离线。

群集数据库主要就是记录这种数据，群集配置，群集成员配置，群集资源的添加，创建，启动，删除，停止，下线等状态变化，然后与其他节点进行同步，带宽使用并不会很大，但一定要准确，每个节点之间的群集数据库一定要一致，这是最重要的要求，因此，群集之间各个节点需要实时的去同步群集数据库，确保每个节点的数据库内容一致，这样当有节点出现下线操作，其它节点才可以准确的承担他的工作，当我们在群集中执行添加角色，删除角色，新增群集资源的时候都会触发数据库的同步操作，因此一定要确保这个同步操作是及时的，准确的到达各个节点，同样，这种类型的流量对网络的质量要求也很高，它并不需要多高的带宽，但一定要保证网络质量。

3.CSV元数据更新

CSV是个好东西，以前2008时代没有CSV，一个hyper-v集群上面要迁移只能把绑定到群集硬盘的虚拟机一起迁移，后来有了CSV就方便多了，CSV不像传统群集磁盘那样，一次挂载在一个节点，故障转移时需要离线，卸载NTFS保留，再上线，挂载，时间长，而且还很不方便。有了CSV之后所有节点上面都可以访问到被创建好的CSV卷，按照CSV编排器的顺序进行访问就可以，当一个节点断电关机，另外节点直接开机VM就可以上线，不需要再执行群集磁盘的卸载上线工作，因为CSV卷始终是挂载着的。所谓元数据更新，即是说，当我们在单个节点上面对CSV卷里面内容进行增删改的时候，后台CSV会把我们增删改的操作进行同步，由东向西，或由北向南，同步的不会是具体的文件内容，只是元数据，同样这种类型的流量对于质量要求很高，并不需要多少带宽，一旦出现延迟，可能导致的情况就是我们在CSV上面更新一个文件执行起来很慢才会进行同步，需要额外注意，2012中CSV严重依赖于SMB，如果您使用CSV功能，请一定不要禁止SMB相关服务。

上述三种流量，其实都包括在我们已知的“心跳网络”中，不看不知道，一看吓一跳，一直被我们忽略的心跳卡竟然也承担着这么多工作，而且还很重要，通过我的介绍相信大家已经有个基本的了解，对于群集网络规划时，一定要把这种类型的群集通信网络单独出来，确保它可以获得最高的质量，防止被其它流量干扰，尤其是要和迁移流量隔离开，即是说至少应该有两种群集网络。

通常情况下这种类型的群集通信网络对于网络带宽要求很低很低，甚至10M 100M也可以满足，但也有一些特别的场景，例如SQL，exchange群集，会经常需要跟踪application的变化，导致群集数据库会很频繁的更新，一些Hyper-V场景下，经常执行CSV创建，迁移操作，会导致CSV元数据流量频繁的进行更新，针对这些场景，老王建议配置单块1GB卡足够了，或者2块1GB卡，做SMB多通道或者Teaming，10GB完全没必要，属于浪费了，有那么大的带宽分给虚拟机迁移和存储多好，哈哈。

2012R2时代也有国外的专家说过，可以把CSV元数据更新的流量从群集通信流量中分割出来，但老王目前还没看到成功的案例，所以目前姑且我们先认为群集通信流量包括运行状况检测，群集数据库更新，CSV元数据更新这三种流量。

OK，上面基础打好了，下面我们开始今天的重头戏，融合网络，我先不解释太多，我们先开始进入一个群集环境，我们在环境中慢慢看请它的真面目

今天的融合网络环境架构如下

12DC ：80.0.0.1 承担域控角色

ISCSI 50.0.0.99 60.0.0.100 承担ISCSI服务器角色

HV01

四块网卡，两快卡组成teaming，通过Convered Network技术分出三块卡

Mgmt 80.0.0.2

clus 90.0.0.2

VM 100.0.0.2

另外两块卡做ISCSI MPIO 50.0.0.1 60.0.0.2

HV02

四块网卡，两快卡组成teaming，通过Convered Network技术分出三块卡

Mgmt 80.0.0.3

clus 90.0.0.3

VM 100.0.0.3

另外两块卡做ISCSI MPIO 50.0.0.3 60.0.0.4

关于服务器怎么装，ISCSI，MPIO怎么配置本文不做说明，我们直接进入Convered Network技术配置的场景中

首先，现在的场景下，每台宿主机上面可以看到五个网卡，其中四块是我们上面说好的，一个teaming，交换机独立，地址哈希的，名字我们所有节点上叫vTeam

真实场景下我建议大家都配置为LACP模式的teaming，两张10GB，进出双网卡。

我这里是使用两张1GB，如果生产环境建议至少四张1GB或两张10GB

文章到这里，还和我们传统的群集没什么两样，接下来重头戏来了，一直在说的Convered network到底是怎么回事呢

老王这里先简单介绍一下，简单来讲，Covered Network就是在Hyper-v父分区中，基于单个网卡或teaming，创建出多个虚拟网络适配器，这是2012开始出现的一项新技术，原来我们一直以为一块网卡只能对于出一个虚拟网络适配器，但其实在2012开始已经发生了改变，我们可以基于Convered Network技术在一块网卡或teaming之上建立出多个虚拟网络适配器

同时，可以针对每个创建出的虚拟网络适配器配置IP，QOS，VLAN，是不是很酷，一块物理网卡，创建出一个虚拟交换机，但可以对应出多个可以配置IP的虚拟网络适配器，并且可以配置每个虚拟网络适配器单独的QOS，IP，VLAN，这在以前是硬件厂商们的技术，微软在2012也在自己的虚拟化平台上面进行了实现，话不多说，我们下面就开始实作

#创建基于vTeam组合创建虚拟交换机，最小带宽模式设置为通过权重决定，由于我们会单独创建管理用的虚拟网络适配器，这里我们先设置AllowManagementOS为False，如设置为True会产生虚拟网络适配器

New-VMSwitch -Name vSwitch -NetAdapterName vTeam -MinimumBandwidthMode Weight -AllowManagementOS $False

#设置虚拟交换机默认流最小带宽权重为20，默认情况下虚拟网络适配器发送的任何流量连接到这个虚拟交换机，并且没有分配的最小带宽将被过滤到这个桶中，即默认如果没有匹配上其它最小带宽权重的流量至多使用默认总带宽百分之20权重的带宽

Set-VMSwitch "vSwitch" -DefaultFlowMinimumBandwidthWeight 20

#基于单个虚拟交换机创建出mgmt，clus，vm三个虚拟网络适配器

Add-VMNetworkAdapter -ManagementOS -Name "Mgmt" -SwitchName "vSwitch"

Add-VMNetworkAdapter -ManagementOS -Name "Clus" -SwitchName "vSwitch"

Add-VMNetworkAdapter -ManagementOS -Name "VM" -SwitchName "vSwitch"

#设置每个虚拟网络适配器至多可以使用总带宽的权重，其中VM(VM+Live Migration)最占用流量，我们将流量优先分配权重分配给它，其次权重分配给管理流量，最少的权重分配给群集网络，MinimumBandwidthWeight值以相对权重计算，范围在0-100，建议虚拟网络适配器所有权重+默认流权重一共不超过100，超过100后后台也将重新平衡权重计算，建议设置所有虚拟网络适配器权重共计80或70,90，剩余的用100减去留给默认流。

Set-VMNetworkAdapter -ManagementOS -Name "Mgmt" -MinimumBandwidthWeight 25

Set-VMNetworkAdapter -ManagementOS -Name "Clus" -MinimumBandwidthWeight 10

Set-VMNetworkAdapter -ManagementOS -Name "VM" -MinimumBandwidthWeight 45

#在设置所有虚拟网卡权重的时候后面可以添加 -Access -VlanId 参数，为每个虚拟网络适配器设立单独的Vlan，起到隔离作用

#按照预定义的配置为每个虚拟网络适配器分配IP地址，注意分配mgmt网卡的DNS为80.0.0.1，Clus网卡取消netbios注册

New-NetIPAddress -InterfaceAlias “vEthernet (mgmt)” -IPAddress 80.0.0.2 -PrefixLength “24”

New-NetIPAddress -InterfaceAlias “vEthernet (Clus)” -IPAddress 90.0.0.2 -PrefixLength “24”

New-NetIPAddress -InterfaceAlias “vEthernet (VM)” -IPAddress 100.0.0.2 -PrefixLength “24”

#确保网卡顺序如下，Mgmt作为首要出站网络DNS访问解析

HV02配置同上，不再赘述，配置完成后和HV01一样，可以看到基于两块网卡组成的teaming建立出来的三块虚拟网卡以及两块ISCSI网卡

到这里大家是不是感觉很奇妙，其实最初老王猜想这会是和vmware端口组一样的技术那就酷了，虚拟机接到端口组，每个端口组可以用不同的网卡，还可以做故障转移容错，VLAN ID，QOS的设置，微软这个，除了每块虚拟网络适配器不能做故障转移其它也都差不多嘛，但当做出来后实际看还是有点区别，vmware esxi上面的端口组做完之后，虚拟机直接就可以接入到端口组中，相对来说效果更加直观，便于理解

而微软的这种融合网络创建出来的虚拟网络适配器，在单台机器上几乎看不到什么特别的效果，因为虚拟机还是接到vswitch这个虚拟交换机，但是迁移流量走那块卡，并不知道，单台机器看不出什么，我们只能看到，阿，我们可以基于两块网卡做成teaming，然后做出虚拟交换机，基于这个虚拟交换机我们又做出了多块虚拟网络适配器，每个虚拟网络适配器可以配置单独的QOS,IP,VLAN ，但是具体怎么切割网络流量的，到底用途在哪里，我们到现在为止还看不到显著的效果，网上很多文章都是做到这里就停了，搞得老王也是一头雾水，单台机器上面做这样的架构其实在我看来意义并不大，只是好看而已，做出来了之后实际上做出来了之后单机上面并不会分割流量，除非配合VLAN，host文件等设定。

因此，我们来到群集里面就可以看得清楚了，具体群集怎么搭建的步骤，老王这里不做解释，相信大家都会的，在群集中我们可以看到添加进来的五个网络

经过调整之后如下图所示，这下子五块网卡就各尽启用了，CLU网卡首要用于群集通信，完成运行状况检测，群集数据库更新，CSV元数据更新，一旦CLU网卡不可用，群集会自动路由至其它mgmt或vm卡承担群集通信流量，ISCSI01 ISCSI02两块网卡为MPIO网络，不参与群集通信流量，管理流量，访问流量，设置VM网卡为实时迁移时使用网卡，实际上微软建议我们可以在这里设置多块，例如设置VM和MGMT，VM网络出现故障，还可以使用MGMT完成迁移，或者我们也可以通过powershell，群集会根据度量值和优先值选择排名第二位的网络用于实时迁移，或我们可以添加多个网络，设置两个网络接近的度量值，这样实时迁移就会在两块卡直接负载均衡。

文章进行到这里已经接近尾声了，回想一下我们做了什么呢，我们底层使用了两张卡做成的teaming，然后基于这组teaming建立虚拟交换机，再基于虚拟交换机创建出了三块虚拟网络适配器，并为其指定了单独的QOS策略，确保每个虚拟网络适配器在自己带宽权重内运作，不会干扰到其它网络，同时我们为每个虚拟网络配置了IP地址，并最终加入了群集网络，在群集的网络模式配合下我们实现了真正的流量分割，每块卡实现了各尽启用

老王认为这在群集网络规划时是一种新的思维，假设服务器只有两个或四个口，或者交换机端口有限，不允许我们六块卡八块卡的占用，那么我们完全就可以考虑通过这种融合网络的架构设计来节约端口的成本，又能够通过QOS技术对虚拟出来的网络适配器进行合理的管控，同时我们底层是teaming，也可以获得teaming的容错性，对于上层的虚拟网络适配器，它只知道对应的是虚拟交换机，虚拟交换机只知道对应的是teaming，即是说只要teaming没坏，整套架构就可以正常运作，一旦teaming里面单块网卡出现故障，并不会导致整个架构的瘫痪，只需要再增加网卡进来即可，这对于上层的架构都不会有很大的感知。

在关于融合网络的架构中老王有一个地方一直没有提到，为什么ISCSI你要单独出来两快卡，为什么不干脆都通过一组teaming虚拟出来，其实老王完全可以都放在一组teaming里面，但是我想给大家展示出最理想的的架构，经过翻阅国外的资料老王得知，ISCSI这种存储技术是不支持NIC teaming的，如果要想获得ISCSI的MPIO能力，只有单独出来两块网卡，或者，两个ISCSI网卡，分别对应两个虚拟交换机，这样物理层可以使用MPIO技术，群集虚拟机也可以得到。

另外，NIC teaming技术在2012时代也不支援RDMA技术，如果你的融合群集底层是SOFS架构，那么你用了两块网卡做成teaming，也将失去RDMA的能力，如果是SMB架构，在2012时代老王建议单独出来两块10GB卡，不做teaming，充分利用SMB多通道和SMB RDMA技术。

当然微软最终也听从了广大群众的呼声，在2016里面，提供了新的技术Switch Embedded Teaming，创建出来的虚拟交换机，将支援融合网络中使用RDMA VRSS等技术

2016融合网络新命令示例：

#创建支持RDMA与VRSS功能的Switch Embedded Teaming交换机

New-VMSwitch -Name CNSwitch -AllowManagementOS $True -NetAdapterName NIC01,NIC02 -EnableEmbeddedTeaming $Tru

#针对存储网络及迁移虚拟网络适配器启用RDMA

Get-NetAdapterRDMA -Name *Storage* | Enable-NetAdapterRDMA

Get-NetAdapterRDMA -Name *Live-Migration* | Enable-NetAdapterRDMA

#在vNIC和物理NIC之间设置关联

Set-VMNetworkAdapterTeamMapping –VMNetworkAdapterName Storage1 –ManagementOS –PhysicalNetAdapterName NIC1

Set-VMNetworkAdapterTeamMapping –VMNetworkAdapterName Storage2 –ManagementOS –PhysicalNetAdapterName NIC2

----------------------------------------------------------------------------

如何构建Piel.io的微服务交付第一篇：搭建Rancher Server

几个月前，我们开始尝试在我们的网站Piel.io上使用Rancher来构建我们的第一个微服务，在此期间，Rancher发布了1.0版。所以我觉得这是一个很好的时间点，我将通过三篇blog跟大家分享一下我们是如何通过Rancher来构建Piel.io的微服务交付的。本文希望可以帮助到那些刚刚接触Rancher的用户，对Rancher已经十分熟悉的技术大拿们可以跳过。第一篇，我将介绍下如何搭建自己的Rancher Server。第二篇，我将介绍下如何构建、配置以及整合自己的Docker Registry。第三篇，我们将讨论下如何通过Stack向企业提供一个可用的平台，可用于描述、部署和管理多种的业务应用。首先，准备一台虚拟机。我是从vutlr.com上购买了一个Ubuntu 14.04 LTS. 前提：安装Docker 安装完成后，用docker –v命令进行验证：成功，可以继续。接下来下载最新的Rancher，我们可以不指定Tag。所有可以使用的Tag可从此获得：https://hub.docker.com/r/rancher/server/tags/ 成功！容器环境下，可以通...

2017-11-12

646

##puppet 后期整理题纲有道云笔记, puppet 自动化管理 1.1 架构实际流程图: 1.2 puppet feature 多环境 puppet running environment http://docs.puppetlabs.com/guides/environment.html 分阶段 2,install & config 2.1 install ##install a third party source rpm -ivhhttp://mirrors.yun-idc.com/epel/6/i386/epel-release-6-8.noarch.rpm #master yum install puppet-server -y #agent yum install puppet -y ##agent 申请证书 puppet agent --server master.puppet.com --test /etc/init.d/puppet start ##mastet 签署证书 puppet cert sign client.puppet.com...

2017-11-12

738

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。