【编者按】
进入2016年后,来自用户方的VSAN双活需求明显增多。去年VSAN 6.1发布的时候,大家可能都看过如下这张图:

这张图大体没错,但是可能会引起误解的是:以为要实现VSAN双活,两个站点之间必须超过10Gbps的带宽。实际上并不是这样的。可能大家曾在不同的地方,看到对于VSAN Stretched Cluster带宽要求的不同说法。经过编者向VMware总部求证,截止目前,以2015年11月以后发布的相关文章为准,对应的PDF,可以在www.bing.com搜索关键字 Virtual SAN Stretched Cluster bandwidth sizing ,第一个即是。或者加入到文章末尾介绍的QQ群里,也能找到PDF( 2015-11-24 _ vmware-virtual-san-6.1-stretched-cluster-bandwidth-sizing.pdf ) 进行下载。
简而言之,更精准的概述图如下:

小结:
带宽 > Wb(写操作带宽) * md(Data Multiplier) * mr(Resynchronization Multiplier)
按VMware建议值,带宽 > Wb * 1.4 * 1.25,也即 带宽 > Wb * 1.75;
编者邀请了VMware资深顾问 - 魏新宇(曾在2015年vForum介绍过VSAN双活技术),翻译了此文。2016年1月25日,他在其微信公众号 "大卫分享" 发表过,题目为《VMware VSAN双活(延伸集群)站点间带宽设计》。谢谢新宇的分享。下面转载译文,有些修改。
---Begin---
一、总体架构
VSAN延伸集群整体架构如下:一个有三个故障域,两个数据站点分别是一个故障域,仲裁站点是一个故障域。需要注意的是,VSAN延伸的三个故障域都属于是一个VSAN集群,而不是三个。

二.常规建议
两个数据站点之间的带宽很大程度上取决于VSAN承担的负载、总体数据量、可能的故障场景。
通常的建议参考如下:

三.数据站点之间的带宽需求
1.计算公式
在真实的业务场景中,全读或者全写的情况很少。更多的时候,用读写比率来衡量业务I/O特性是常用的办法。以VDI场景的负载举例子。在负载峰值的情况下,读写比率通常是3:7。
例如:业务需要求IOPS的总量是10万,读写比率为3:7。由于VSAN延伸集群本地读(Read Locality)的特性,读操作不需要跨站点,因此考虑数据站点之间带宽只考虑跨站点写即可,也即7万写IOPS。
数据站点带宽计算公式是:
B=Wb*md*mr
B:Bandwidth,数据站点之间的带宽。
Wb:Write Bandwidth,数据站点之间的写带宽。
md: Data Multiplier,数据乘数
mr:Resynchronization multiplier,再同步乘数
其中,数据乘数md由VSAN元数据跨站点写开销等相关的操作组成的(除了数据以外,元数据也需要跨站点写)。VMware建议将md这个数值设置为1.4。
再同步乘数mr指的是数据站点之间同步事件(例如VSAN组件的状态信息)的所需要的总开销。mr这个数值,VMware建议为1.25(也即额外增加25%)。
再同步乘数和数据乘数其实都是跨站点写数据的额外开销。这两个数值使用VSAN推荐值即可。
2.案例分析
案例1.
VSAN运行一个IOPS为1万的全写负载业务。写的block为4KB。这需要消耗40MB/s的数据站点间的带宽(4KB*10000),也就是320Mbps。
按照上一小节的计算公式:
B=320Mbps * 1.4 * 1.25 = 560Mbps ;
因此,在这个负载情况下,VSAN数据站点之间需要的带宽至少应为560Mbps。 【编者按:可以看出这个比10Gbps的带宽需求小得多】
案例2.
VSAN运行负载为3万全写IOPS,4KB block size,这需要120MB/s(960Mbps)跨站点写数据的吞吐量。
按照公式:
B=960Mbps * 1.4 * 1.25 = 1680Mbps ,约等于1.7Gbps;
因此,在这个案例中,数据站点之间的带宽至少应为1.7Gbps。【编者按:记住在VSAN双活里,读能本地进行,即 Read Locality】
四.数据站点与仲裁站点之间的带宽需求
1.计算公式
数据站点并不存放虚拟机的数据,只是用于投票使用,因此数据站点与仲裁站点之间的带宽计算公式与上面的不一样。
VSAN是基于策略驱动的分布式存储。数据是以对象的方式存储在VSAN中的,一个VM在VSAN存储中的数据由一个或者多个组件组成,组件有如下类型:
- VM Folder
- VMware swap file
- VMDK
- 快照
在VSAN中,当一个对象的大小大于255GB的时候,就会被自动划分成多个组件。仲裁站点与数据站点之间的计算公式如下:
1138 B * NumComp / 5seconds ;
其中,1138 B这个数字来源于:当主站点离线,备站点接管所有组件的所有权。我们想象一下,当主站点离线,备站点将成为主站点。仲裁站点将会向新的主站点发送确认信息,确认主站点的角色已经发生了变更。
从本质上讲,1138B是当主站点离线以后,仲裁站点需要从元数据信息中获取主站点上所有组件已经失效,并且随后由备站点接管所有权的状态信息更新开销。当主站点离线以后,仲裁站点与数据站点之间的带宽应足以让集群中所有部件的主站点所有权的变更,在5秒内完成。
2.案例分析
案例1:
虚拟机由如下内容组成:
三个对象:
- VM namespace
- VMKD(小于255GB)
- VM Swap file
- FTT=1
- Stripe width=1
以上配置的虚拟机数量是166个,那么仲裁站点就需要获取到996个组件信息。996=3*2*1*166.
我们用1000进行计算:B=1138B*8*1000/5s=1820800bps=1.82Mbps;
VMware推荐预留10%的额外带宽用于信息双向传输:1.82*1.1=2Mbps。因此,在这个场景下,数据站点与仲裁站点的带宽应为2Mbps。
案例2:
虚拟机由如下内容组成:
三个对象:
- VM namespace
- VMDK(小于255GB)
- VM Swapfile
此外:
- FTT=1
- Stripe width=2
如果具有以上配置的虚拟机数量为1500,那么仲裁站点将会维持18000个组件的状态信息。3*2*2*1*1500=18000
按照案例1中的算法:
B=1138B*8*18000/5s=32.78Mbps
B*1.2=36.05Mbps
因此,在这个场景下,数据站点与仲裁站点之间的带宽需要36.06Bbps。
根据上面的算法,可以提炼一个简单的公式用于在日常的评估,那就是2Mbps带宽可以维系1000个组件的状态信息。因此,在这个场景下,维系18000个组件,所需要的带宽是:18000/1000*2Mbps=36Mbps。
五.2节点VSAN配置下,数据站点与仲裁站点的带宽需求
在VSAN6.1中,支持2节点的VSAN集群。

案例1:
2-Node配置中的虚拟机特性如下:虚拟机数量:25;VMDK/VM:1TB;FTT=1;Stripe width=1 ;
上面我们提到过,VSAN中,一个vmdk组件最大为255G,因此每个VMDK由4个组件组成,此外由于FTT=1,在包含副本的情况下,每个vmdk由8个组件组成。加上VM namespace和swap文件(有副本),那么一个虚拟机的组件总数为12=4*2+2*2。25个虚拟机组件总量为300=25*12。
使用通用公式:300/1000*2Mbps=600Kbps。因此,在这种场景下,数据站点与仲裁站点之间的带宽应为600Kbps。
案例2:
在2-Node配置中,每个主机上有100个虚拟机,每个虚拟机有1TB的VMDK,FTT和stripewidth均为1。 那么,组件的总量为:(1000/255+1+1)*2*100(VMs)*2(Hosts)=2400
按照通用公式,2400个组件,需要的带宽为2400/1000*2Mbps=4.8Mbps。因此在这个场景中,仲裁站点到数据站点之间的带宽需要4.8Mbps。
需要注意的是,如果一套VSAN延伸集群承担多个类型的业务负载,那么需要把这些业务负载先单独计算其需要的带宽,然后将其累加在一起。
---End---
欢迎关注如下微信公众号: V记云科技联盟成员

乐生活与爱IT(love_life_and_IT)-软件定义存储和虚拟化叶毓睿 VMware存储架构师亨利笔记(微信号:henglibiji)-容器和云原生应用张海宁,研发中心首席架构师最终用户计算(微信号:CHINAEUC)-桌面与应用虚拟化吴孔辉,VMware架构师疯云时代(微信号:crazycloudtime)-基础架构和应用服务臧铁军,VMware架构师大卫分享(微信号:david-share)-SDDC与IT管理魏新宇,VMware金融行业售前IT那些事儿(IT-Review)尤贵贤,资深技术顾问
其中译者魏新宇的微信公众号 "大卫分享“ 的二维码如下,欢迎扫描关注:

以及VMware官方微信
1、 VMware中国(微信号:vmwarechina)
2、 VMware中国研发中心(微信号:vmwarechinard)
---
欢迎加入软件定义存储讨论 QQ群:122295009,可下载原创的一些文章,及其他有参考价值的文档。
另外,欢迎您扫描微信公众号:“乐生活与爱IT”。

关注后,可以通过点击左下角的“文章目录”,详细了解如何查看历史文章。
也可单击左下角,阅读和VSAN相关的上一篇文章
《VMware SDS之七: 谁在用VSAN ?》
















