WatchStor.com — 领先的中文存储网络媒体 | 51CTO旗下网站

新闻资讯 > 公有云 > 正文
揭秘VDI存储测试:4节点SDS模拟12000虚拟桌面
作者: 高翔(Sean)、唐僧 2017-12-18 17:18 【WatchStor】

3节点超融合660个虚拟桌面;到4节点SDS上万VM模拟测试验证。

本文要点
1、如何将VDI存储I/O特征抽象化?
2Full CloneLink Clone桌面在启动和登录中的不同表现、成因分析
3、为什么说全闪存VDI系统,带宽可能成为瓶颈?
继基础性能、SQL Server I/O模拟和邮件服务器BenchMark之后,本文将向大家介绍微软S2DStorage Spaces Direct)在VDI桌面虚拟化应用中的测试表现。
首先我们将引用一份Dell HCI参考架构文档中的测试结果,然后再来介绍自己的测试内容。
Login VSI测试:每节点220桌面的超融合
下图来自《Dell EMC Storage SpacesDirect (S2D) Ready Nodes for Microsoft Remote Desktop Services (RDS) –Reference Architecture
链接:http://en.community.dell.com/techcenter/extras/m/white_papers/20444551/download
这是一套3节点Windows Server2016 DataCenter超融合集群,存储部分用OS自带的S2D组建SSD+HDD混合存储池。每节点有2SSD用于Cache分层、4HDD作为容量分层,3副本镜像保护。节点间使用10GbRDMA万兆以太网互连。
HCI参考架构中测试的硬件配置
这里的S2D Ready NodeB5”配置使用了Dell PowerEdge R740xd服务器,CPUXeon SP 5120 GoldMellanox ConnectX-4 LxQLogic 41262网卡支持25GbE,不过环境使用的交换机是Dell S4048万兆和S3048千兆,可能因为新一代25G交换机还没有正式上市销售。
由于我们自己测试的网络环境是“不差钱”的100Gb/s RDMA,有读者朋友关心与10/25Gb之间的性能差别。其实大家不难计算出2SATA SSD Cache盘的最大带宽——我认为大多数混合配置下10Gb应该够用了;而若是用NVMe SSDCache或者全闪存的S2D,有条件情况下推荐用25G或以上的网络互连。
当然,大家要注意微软S2DRDMA下的表现会好不少,这方面我在第一篇中列出过对比数字。
这里的每主机桌面密度,与服务器CPU和内存配置直接相关
Login VSI测试验证了3种不同负载的虚拟桌面,平均每节点能够承载的VM数量分别为Task Worker——220个、Knowledge Worker——175个和Power Worker——155个,那么从3节点超融合集群的角度就应该乘以3
按照这个结果,我觉得Hyper-V 2016 + RDS的效率还不错,物理机上的内存消耗都超过了300GB,达到稳态后的每用户平均IOPS3.xx
注:VDI不同的桌面分配方式,完整克隆、链接克隆持久化桌面,以及即时克隆/RDS产生的存储压力和IO模型也不同,这一点后面我们还会重点谈。
显然在超融合架构下S2D分布式存储软件还远未达到瓶颈,即使你换成全SSD,服务器上的CPU和内存仍然限制着承载的桌面数量。
本次测试环境,还是上海戴尔客户解决方案中心(CSC)的微软S2DStorage Spaces Direct)集群,部署在4Dell PowerEdge R630服务器上,每个节点71.6TB SATA SSD,网络互连为100Gb/sRoCE
如果想跑更多虚拟桌面的Login VSI测试,几乎只能增加服务器。比如我看到一份2000桌面的测试报告中就使用了16个服务器节点,以此类推… 本次我们自己的测试(如上图4节点S2D集群)也面临同样问题,能否把VDI测试中的存储I/O负载单独剥离出来呢?直到我看到一份来自NetApp的文档。
VDI启动风暴、登录阶段存储I/O“抽象化”
这一段的内容引用自《NetApp All Flash FASSolution for Persistent Desktops with VMware Horizon View》(tr-4540),可能也是因为跑虚拟机的服务器数量不够多,在该测试报告的结尾处列出了Login VSI测试过程中从Hypervisor层面收集、统计出的存储I/O负载模型
该模型仅针对Full Clone(完整克隆)VDI部署,下文中相同。如果是Link Clone(链接克隆)I/O特征将有所不同。
我们知道,启动风暴(Boot Strom)和虚拟桌面集中登录是VDI应用中最考验存储性能,也是最容易影响用户体验的地方,所以被公认为Login VSI测试中的重点。
如上图,在虚拟桌面OS启动过程中存储读操作的比例相当大,其中最主要的一部分是较大数据块(64KB48KB)顺序读,然后是32KB读和4K随机I/O等。
NetApp获取这个负载模型的目的是验证更多存储系统,既然N厂授人以渔,我们也拿该方法评估下微软S2D集群。当然大家都不会用到那么多的虚拟机,本身这个测试的目的就是要避开服务器的CPU和内存瓶颈。
使用Iometer在这里有一点小限制,就是随机/顺序访问的比率精确不到0.1%,所以我们将对应几项的Random I/O比率提高到1%,实际测得的结果估计会比参考模型略低一点吧。
N厂使用的测试工具为VDBench,由于我们这次是Windows2016 Hyper-V环境,为方便起见选择了Iometer。而经过简单比较,两种压力工具测出的性能基本一致。
当并发启动数千个桌面时存储压力确实很大,不过我看到有同行朋友说Boot Storm可以提前或者分批进行(比如设定在晚上或者周末重启)也是一种办法。另外虚拟机通常不用每天都重启,下班或者不用时可以注销,所以许多时候VDI批量登录(包括Windows或者还有Office等启动)的速度对用户影响更为直接,这大概就是“Login VSI”命名的由来吧:)
所谓周一上午(Monday morning)就是第一次登录,这里面比例最大的一项是4KB随机I/O,读只占36%了。当然16KB32KBI/O也还不少。
前面说过虚拟机通常不需要每天重启,所以在周二(Tuesday)及接下来几天登录时,大部分需要读的数据已经在服务器内存里了,这时4KB随机写操作占据了所有存储I/O的一半。
下面我们来看看N厂的1,500桌面Login VSI基准测试结果。传统存储和SDS有各自的特点及适用场景,我们本意也是以此作为参考而非比较,所以为了避免不必要的争议,以下统一称之为“参考平台”并尽量淡化品牌型号。
Full CloneLink CloneVDI启动和登录中的不同表现
上面这个表信息量有点大,咱们挑重点的说。首先,启动风暴期间峰值IOPS超过11万,平均每个虚机高达78.5Full Clone桌面的测试完成时间约12分钟。根据我看到的另一份4,000桌面Login VSI测试报告,Link Clone在峰值10IOPS下不到7分钟就可以完成启动。
这个背后的原因应该是黄金镜像(Golden Image)的数据更容易被内存缓冲,所以链接克隆在启动风暴中每桌面的IO压力小很多
然后再看周一(首次)和周二(后续)登录测试,按照峰值IOPS推算每个虚机平均20.714.6 IOPS(我们的评估也是以此为基准),每虚机的登录时间都在20秒左右。
而根据我看到的另一份Login VSI报告,全闪存阵列在6,000用户测试中,链接克隆桌面在登录阶段产生的峰值IOPS要比完整克隆高出一倍多。估计是磁盘碎片化导致连续数据的分布被打散,同样数据量的访问需要更多次I/O。所以我觉得两种磁盘分配方式应该区别对待,测试成绩不应混在一起做横向对比。
全闪存VDI系统容易被忽略的带宽瓶颈
下面是我们在微软S2D集群上的测试结果。
首先看IOPS,模拟启动风暴测试读写总和超过21万,大约是上文中参考系统(Full Clone 1,500桌面)峰值的2倍。可以预见的是,如果只考量这套S2D集群的存储性能,换成Link Clone的话能支持的桌面数量远不只3,000个。
模拟第一次登录测试也超过了21IOPS,约为参考系统的7倍;后续登录测试达到16IOPS,而这里列出的还不是我们看到的峰值。
进一步分析带宽,我们发现启动风暴时达到了9GB/s左右,距离第一篇评测中的S2D集群顺序读最大带宽(见下图)已经相距不远。周二登录也是个典型代表,仅写入带宽部分就超过了2.2GB/s,我们的S2D3副本配置。
由此我们认为,对于全闪存系统来说,VDI应用的存储瓶颈有可能出现在SSD及其接口带宽上。如果换NVMe Flash那效果自不必说了:)
注:上表中数字为虚拟机内记录的满负载下延时
这个延时结果(毫秒)要是对比现有的Login VSI报告看似不太漂亮,不过别忘了我们模拟的是峰值性能,也就是说实际VDI测试过程中平均延时会低不少
看看参考系统的平均IOPS和平均延时测试值,我们不难估计出峰值IOPS时对应的延时范围吧?
上图引用自Microsoft Tech Summit 2017大会上分享的一页PPT,对比FC存储和S2D在每月第二周WnidowsUpdate大规模补丁更新时产生的IO压力,从数据中看出S2DIO性能是最好的。其中列出的测试数据是在实际生产环境中获得,供大家参考。
同时我们拿到更进一步的对比数据(都是混合配置):在虚拟机在线实时迁移上,S2D超融合因为具备RDMA网卡,所以VM迁移性能是之前的5倍。更重要的是虚拟机启动风暴的IOPS性能和平均延时对比,S2D也是大比例领先。150个桌面,S2D超融合大约10分钟能全部启动完成;而传统存储大约需要40分钟才能全部启动完成160个桌面。S2D超融合的低延时和高IOPS给用户非常好的使用体验。
为什么看重“周二上午登录”?
我们的测试只进行到周二登录,其实周三到周五也是类似的情况。我理解数据中心的服务器不会随便关机,所以VDI持久桌面用户每周重启一次Windows系统的应该占较大比例。在我们参考的文档中,N厂就是以“周二上午登录”的模拟测试结果,来评估不同存储系统能支持的VDI桌面数量。
如上面图表,测试结果最高的一款全闪存阵列接近参考系统IOPS8倍,所以在这里被判定能够支持到11,000个虚拟桌面。
VDI周二登录模拟测试
上图是我们的S2D集群,在周二登录的模拟测试中,于Windows Server 2016物理机OS的监控截图,可能还不是最高峰值的时候。
如果按照这个176,242 IOPS来计算,已经达到1,500桌面参考系统的8,那么该4节点S2D配置是不是可以支撑12,000虚拟桌面VDI的存储负载呢?
VDI周一(首次)登录模拟测试
由于启动风暴压力可以被规划、分摊在非工作时间,如果是重度VDI用户(每天重启一次的),按照上面这张图中的225,582 IOPS,其首次登录性能应该也能达到10,000以上虚拟桌面的水平吧。
计算存储分离的SDS用于较大规模部署
记得我们在第一篇评测中提到过这种非超融合的“Hyper-V集群和SOFS on S2D集群分离部署,应用主机和存储节点通过SMB3协议网络连接,依然可以使用RDMA。”
虽然理论上SOFS on S2D会比集群内访问会多一层开销,但我们本次模拟测试中Dell R630服务器的CPU还远未成为瓶颈。而这只是4节点总共28SATA SSD的表现(目前S2D最大支持16节点),软件定义存储的魅力大概就是如此吧:)
最后,再次感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持!

标签:存储网络 公有云 

LecVideo
论坛与活动