从3节点超融合660个虚拟桌面；到4节点SDS上万VM模拟测试验证。
本文要点
1、如何将VDI存储I/O特征抽象化？
2、Full Clone和Link Clone桌面在启动和登录中的不同表现、成因分析
3、为什么说全闪存VDI系统，带宽可能成为瓶颈？
接上篇：《4节点近160万IOPS：SDS/超融合测试不能只看数字》
《12万邮箱ESRP测试：Exchange超融合存储设计漫谈》
继基础性能、SQL Server I/O模拟和邮件服务器BenchMark之后，本文将向大家介绍微软S2D（Storage 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混合存储池。每节点有2个SSD用于Cache分层、4个HDD作为容量分层，3副本镜像保护。节点间使用10GbRDMA万兆以太网互连。
HCI参考架构中测试的硬件配置
这里的S2D Ready Node“B5”配置使用了Dell PowerEdge R740xd服务器，CPU为Xeon SP 5120 Gold。Mellanox ConnectX-4 Lx或QLogic 41262网卡支持25GbE，不过环境使用的交换机是Dell S4048万兆和S3048千兆，可能因为新一代25G交换机还没有正式上市销售。
由于我们自己测试的网络环境是“不差钱”的100Gb/s RDMA，有读者朋友关心与10/25Gb之间的性能差别。其实大家不难计算出2个SATA SSD Cache盘的最大带宽——我认为大多数混合配置下10Gb应该够用了；而若是用NVMe SSD做Cache或者全闪存的S2D，有条件情况下推荐用25G或以上的网络互连。
当然，大家要注意微软S2D在RDMA下的表现会好不少，这方面我在第一篇中列出过对比数字。
这里的每主机桌面密度，与服务器CPU和内存配置直接相关
Login VSI测试验证了3种不同负载的虚拟桌面，平均每节点能够承载的VM数量分别为Task Worker——220个、Knowledge Worker——175个和Power Worker——155个，那么从3节点超融合集群的角度就应该乘以3。
按照这个结果，我觉得Hyper-V 2016 + RDS的效率还不错，物理机上的内存消耗都超过了300GB，达到稳态后的每用户平均IOPS在3.xx。
注：VDI不同的桌面分配方式，完整克隆、链接克隆持久化桌面，以及即时克隆/RDS产生的存储压力和IO模型也不同，这一点后面我们还会重点谈。
显然在超融合架构下S2D分布式存储软件还远未达到瓶颈，即使你换成全SSD，服务器上的CPU和内存仍然限制着承载的桌面数量。
本次测试环境，还是上海戴尔客户解决方案中心（CSC）的微软S2D（Storage Spaces Direct）集群，部署在4台Dell PowerEdge R630服务器上，每个节点7块1.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启动过程中存储读操作的比例相当大，其中最主要的一部分是较大数据块（64KB、48KB）顺序读，然后是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%了。当然16KB和32KB读I/O也还不少。
前面说过虚拟机通常不需要每天重启，所以在周二（Tuesday）及接下来几天登录时，大部分需要读的数据已经在服务器内存里了，这时4KB随机写操作占据了所有存储I/O的一半。
下面我们来看看N厂的1,500桌面Login VSI基准测试结果。传统存储和SDS有各自的特点及适用场景，我们本意也是以此作为参考而非比较，所以为了避免不必要的争议，以下统一称之为“参考平台”并尽量淡化品牌型号。
Full Clone和Link Clone在VDI启动和登录中的不同表现
上面这个表信息量有点大，咱们挑重点的说。首先，启动风暴期间峰值IOPS超过11万，平均每个虚机高达78.5，Full Clone桌面的测试完成时间约12分钟。根据我看到的另一份4,000桌面Login VSI测试报告，Link Clone在峰值10万IOPS下不到7分钟就可以完成启动。
这个背后的原因应该是黄金镜像（Golden Image）的数据更容易被内存缓冲，所以链接克隆在启动风暴中每桌面的IO压力小很多。
然后再看周一（首次）和周二（后续）登录测试，按照峰值IOPS推算每个虚机平均20.7和14.6 IOPS（我们的评估也是以此为基准），每虚机的登录时间都在20秒左右。
而根据我看到的另一份Login VSI报告，全闪存阵列在6,000用户测试中，链接克隆桌面在登录阶段产生的峰值IOPS要比完整克隆高出一倍多。估计是磁盘碎片化导致连续数据的分布被打散，同样数据量的访问需要更多次I/O。所以我觉得两种磁盘分配方式应该区别对待，测试成绩不应混在一起做横向对比。
全闪存VDI系统容易被忽略的带宽瓶颈
下面是我们在微软S2D集群上的测试结果。
首先看IOPS，模拟启动风暴测试读写总和超过21万，大约是上文中参考系统（Full Clone 1,500桌面）峰值的2倍。可以预见的是，如果只考量这套S2D集群的存储性能，换成Link Clone的话能支持的桌面数量远不只3,000个。
模拟第一次登录测试也超过了21万IOPS，约为参考系统的7倍；后续登录测试达到16万IOPS，而这里列出的还不是我们看到的峰值。
进一步分析带宽，我们发现启动风暴时达到了9GB/s左右，距离第一篇评测中的S2D集群顺序读最大带宽（见下图）已经相距不远。周二登录也是个典型代表，仅写入带宽部分就超过了2.2GB/s，我们的S2D是3副本配置。
由此我们认为，对于全闪存系统来说，VDI应用的存储瓶颈有可能出现在SSD及其接口带宽上。如果换NVMe Flash那效果自不必说了：）
注：上表中数字为虚拟机内记录的满负载下延时
这个延时结果（毫秒）要是对比现有的Login VSI报告看似不太漂亮，不过别忘了我们模拟的是峰值性能，也就是说实际VDI测试过程中平均延时会低不少。
看看参考系统的平均IOPS和平均延时测试值，我们不难估计出峰值IOPS时对应的延时范围吧？
上图引用自Microsoft Tech Summit 2017大会上分享的一页PPT，对比FC存储和S2D在每月第二周WnidowsUpdate大规模补丁更新时产生的IO压力，从数据中看出S2D的IO性能是最好的。其中列出的测试数据是在实际生产环境中获得，供大家参考。
同时我们拿到更进一步的对比数据（都是SSD+HDD混合配置）：在虚拟机在线实时迁移上，S2D超融合因为具备RDMA网卡，所以VM迁移性能是之前的5倍。更重要的是虚拟机启动风暴的IOPS性能和平均延时对比，S2D也是大比例领先。150个桌面，S2D超融合大约10分钟能全部启动完成；而传统存储大约需要40分钟才能全部启动完成160个桌面。S2D超融合的低延时和高IOPS给用户非常好的使用体验。
为什么看重“周二上午登录”？
我们的测试只进行到周二登录，其实周三到周五也是类似的情况。我理解数据中心的服务器不会随便关机，所以VDI持久桌面用户每周重启一次Windows系统的应该占较大比例。在我们参考的文档中，N厂就是以“周二上午登录”的模拟测试结果，来评估不同存储系统能支持的VDI桌面数量。
如上面图表，测试结果最高的一款全闪存阵列接近参考系统IOPS的8倍，所以在这里被判定能够支持到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节点总共28个SATA SSD的表现（目前S2D最大支持16节点），软件定义存储的魅力大概就是如此吧：）
最后，再次感谢上海戴尔客户解决方案中心Tony Wang对本次测试的大力支持！
