客户想要VDI。 我仔细观察了SimpliVity + VDI Citrix虚拟桌面。 对于所有操作员，城市上班族等等。 仅在第一批迁移中就有五千个用户，因此他们坚持进行压力测试。 VDI可能会开始变慢，也可能会从容地躺下-但这并不总是由于通道问题而发生。 我们购买了一个非常强大的测试软件包，专门用于VDI，并加载了基础架构，直到它落在磁盘和处理器上为止。
因此，我们需要一个塑料瓶，LoginVSI软件来进行复杂的VDI测试。 我们拥有300个用户的许可证。 然后，他们将HPE SimpliVity 380硬件包装在适合一台服务器上最大用户密度任务的包装中，以良好的超额订购量削减了虚拟机，将Office软件安装在Win10上并开始测试。
走吧 系统
两个节点（服务器）HPE SimpliVity 380 Gen10。 在每个：
- 2个Intel Xeon Platinum 8170 26c 2.1Ghz。
- 内存：768GB，12个64GB LRDIMM DDR4 2666MHz。
- 主磁盘控制器：HPE Smart Array P816i-a SR Gen10。
- 硬盘驱动器：9 x 1.92 TB SATA 6Gb / s SSD（在RAID6 7 + 2配置中，即从HPE SimpliVity来看这是中型）。
- 网卡：4 x 1Gb Eth（用户数据），2 x 10Gb Eth（SimpliVity和vMotion后端）。
- 每个节点中都有专门集成的FPGA卡，用于重复数据删除/压缩。
节点之间通过10Gb以太网互连直接连接，无需外部交换机，该交换机用作SimpliVity后端，并通过NFS传输虚拟机数据。 群集中的虚拟机数据始终在两个节点之间进行镜像。
节点群集在运行vCenter的Vmware vSphere群集中。
为了进行测试，部署了域控制器和Citrix连接代理。 域控制器，代理和vCenter放置在单独的群集中。
作为测试基础架构，在“专用-完整副本”配置中部署了300个虚拟桌面，也就是说，每个桌面都是虚拟机原始映像的完整副本，并保存用户所做的所有更改。
每个虚拟机都有2vCPU和4GB RAM：
虚拟机上已安装以下测试所需的软件：
- Windows 10（64位）版本1809。
- Adobe Reader XI。
- Citrix虚拟交付代理1811.1。
- Doro PDF 1.82。
- Java 7更新13。
- Microsoft Office Professional Plus 2016。
节点之间-同步复制。 集群中的每个数据块都有两个副本。 也就是说，现在每个节点上都有完整的数据集。 具有三个或更多节点的群集-两个不同位置的块副本。 创建新的VM时，会在一个群集节点上创建一个附加副本。 如果一个节点发生故障，则先前在其上运行的所有VM都会在具有副本的其他节点上自动重新启动。 如果节点长时间出现故障，则将开始逐步进行冗余恢复，并且群集将再次恢复为N + 1冗余。
数据的平衡和存储发生在SimpliVity本身的软件存储级别。
虚拟机运行虚拟化群集；它还将它们托管在软件存储中。 台式机本身是根据标准模板获取的：金融家和操作员的桌子开车去进行测试（这是两个不同的模板）。
测试中
为了进行测试，使用了LoginVSI 4.1软件的测试组合。 作为管理服务器一部分的LoginVSI复合体和用于测试连接的12台计算机部署在单独的物理主机上。
测试以三种模式进行：
基准测试模式-300位知识工人和300位存储工人的负载选项。
标准模式是300 Power Worker负载选项。
为了使Power Worker能够工作并增加负载的多样性，将其他Power Library文件的库添加到LoginVSI复合系统中。 为了确保结果的可重复性，所有测试台设置均保留为默认。
知识和力量工作者测试模拟了在虚拟工作站上工作的用户的实际负载。
Storage Workers测试是专门为测试存储系统而创建的，它远离实际的工作负载，并且在很大程度上在于用户处理大量不同大小文件的工作。
在测试过程中，用户登录工作站需要48分钟，大约每10秒便有一位用户。
结果
LoginVSI测试的主要结果是VSImax指标，该指标是根据用户运行的各种任务的执行时间进行编译的。 例如：记事本中的文件打开时间，7-Zip中的文件压缩时间等。
链接的官方文档中提供了指标计算的详细说明。
换句话说，LoginVSI会重复典型的加载模式，模拟办公套件中的用户操作，读取PDF等，并测量各种延迟。 延迟达到了一个临界水平，“一切都会变慢，无法正常工作”），在此之前，我们认为没有达到最大用户数。 如果响应时间比此“一切都变慢”状态快1000毫秒，则认为系统运行良好，您可以添加更多用户。
以下是基本指标：
公制
| 采取的行动
| 详细 说明
| 可加载组件
|
非甾体抗炎药
| 文字开启时间
重量1,500 kB的文件
| 记事本启动并
打开一个重1500 KB的随机文档，该文档从池中复制
资源
| CPU和I / O
|
Nfo
| 对话框打开时间
记事本窗口
| 打开VSI记事本文件[Ctrl + O]
| CPU，RAM和I / O
|
ZHC *
| 强大的压缩Zip文件创建时间
| 局部压缩
从以下位置复制的5MB随机.pst文件大小
资源池
| CPU和I / O
|
ZLC *
| 低压缩Zip文件创建时间
| 局部压缩
从以下位置复制的5MB随机.pst文件大小
资源池
| 输入/输出
|
中央处理器
| 计算大
随机数据数组
| 创建一个大数组
I / O计时器（I / O计时器）中使用的随机数据
| 中央处理器
|
执行测试时，将首先计算基本VSIbase指标，该指标显示没有系统负载的任务的速度。 基于此，确定VSImax阈值，该阈值等于VSIbase + 1000ms。
关于系统性能的结论基于两个指标：VSIbase（用于确定系统的速度）和VSImax（阈值）阈值（用于确定系统可以承受的最大用户数量，而不会显着降低性能）。
300名知识工作者基准
知识工作者是定期加载内存，处理器和IO各种小峰值的用户。 该软件可以模拟要求苛刻的办公室用户的负担，好像他们一直在戳东西（PDF，Java，办公套件，查看照片，7-Zip）。 随着用户从零增加到300，每个用户的延迟逐渐增加。
VSImax统计数据：
VSIbase = 986ms，未达到VSI阈值。
SimpliVity监视中存储系统上的负载统计信息：
使用这种类型的负载，系统可以承受增加的负载，而性能几乎没有或没有下降。 用户任务的执行时间平稳增长，系统的响应时间在测试过程中没有变化，写入最长为3 ms，读取最长为1 ms。
结论： 300个没有问题的用户知识可以在当前群集上使用，并且不会互相干扰，达到pCPU / vCPU 1到6的超额预订，一般延迟均匀增加，但没有达到条件限制。
300名仓储工人基准
这些用户经常以30到70的比例不断进行写入和读取。 为了实验更多地进行了该测试。 VSImax统计数据：
VSIbase = 1673，VSI阈值达到240个用户。
SimpliVity监视中存储系统上的负载统计信息：
实际上，这种负载是对存储系统的压力测试。 执行该命令时，每个用户都将许多大小不同的随机文件写入磁盘。 在这种情况下，可以看出，当超过某个负载阈值时，某些用户会增加完成文件记录任务所需的时间。 同时，存储系统，处理器和主机存储器上的负载不会显着变化，因此，当前无法确切确定延迟与什么相关。
只能与其他系统的测试结果进行比较，得出有关使用此测试的系统性能的结论，因为这样的负载是综合的，不现实的。 但是，总的来说，测试进行得很好。 直到210个会话，一切都进行顺利，然后开始出现难以理解的响应，除了Login VSI之外，其他任何地方都没有跟踪到。
300名电力工人
这些是喜欢处理器，内存和高IO的用户。 这些“高级用户”定期运行复杂的任务，包括安装新软件和解压缩大型档案等，其工作量很大。 VSImax统计数据：
VSIbase = 970，未达到VSI阈值。
SimpliVity监视中存储系统上的负载统计信息：
在测试期间，在系统节点之一上达到了处理器负载阈值，但这对其操作没有重大影响：
在这种情况下，系统可以承受增加的负载，而不会显着降低性能。 用户任务的执行时间平稳增长，系统的响应时间在测试过程中没有变化，写入最长为3 ms，读取最长为1 ms。
对于客户的常规测试还不够，我们走得更远：增加了VM的特性（vCPU的数量，以评估超额订购和磁盘大小的增加），并增加了额外的负载。
在其他测试期间，使用了以下机架配置：
在4vCPU，4GB RAM，80GB HDD的配置中部署了300个虚拟桌面。
其中一台测试机的配置：
在“专用-完整副本”选项中部署了计算机：
300名知识工作者基准12个超额订阅
VSImax统计数据：
VSIbase = 921 ms，未达到VSI阈值。
SimpliVity监视中存储系统上的负载统计信息：
结果类似于测试先前的VM配置。
300名电力工人超额认购12
VSImax统计数据：
VSIbase = 933，未达到VSI阈值。
SimpliVity监视中存储系统上的负载统计信息：
在此测试中，也达到了处理器负载阈值，但这对性能没有重大影响：
结果类似于测试先前的配置。
如果您开始加载10个小时会怎样？
现在，我们来看是否会有“累积效应”，并连续运行10个小时进行测试。
长时间的测试和对该部分的描述应该针对这样一个事实：我们希望检查长时间加载的服务器场是否存在任何问题。
300名知识工作者基准+ 10小时
此外，对300名知识工作者的负载变化进行了测试，随后用户进行了10个小时的工作。
VSImax统计数据：
VSIbase = 919 ms，未达到VSI阈值。
VSImax详细统计数据：
该图表明，在整个测试过程中，性能没有下降。
SimpliVity监视中存储系统上的负载统计信息：
在整个测试过程中，存储系统性能保持在相同水平。
附加合成负荷的附加测试
客户要求向磁盘添加大量负载。 为此，向用户的每个虚拟机中的存储系统添加了一个任务，以在用户登录到系统时在磁盘上启动综合负载。 负载由fio实用程序提供，该实用程序允许通过IOPS数量限制磁盘上的负载。 在每台机器中，启动了一个任务以开始额外的负载，即22 IOPS 70％/ 30％随机读取/写入。
300位知识工作者基准+每位用户22 IOPS
在初始测试期间，发现fio在虚拟机的处理器上造成了很大的额外负载。 这导致CPU主机快速过载，并极大地影响了整个系统的运行。
主机的CPU负载：
存储系统的延迟自然也增加了：
对于大约240个用户而言，缺乏计算能力已变得至关重要：
根据结果，决定进行CPU占用较少的测试。
230个办公室工作人员基准+每个用户22 IOPS
为了减少CPU上的负载，选择了Office worker负载类型，并向每个会话中添加了22 IOPS的合成负载。
为了不超过CPU的最大负载，该测试被限制为230个会话。
该测试在随后的用户工作中启动了10个小时，以在接近最大负载的情况下长时间运行期间检查系统的稳定性。
VSImax统计数据：
VSIbase = 918 ms，未达到VSI阈值。
VSImax详细统计数据：
该图表明，在整个测试过程中，性能没有下降。
CPU统计信息：
执行此测试时，主机CPU上的负载几乎是最大的。
SimpliVity监视中存储系统上的负载统计信息：
在整个测试过程中，存储系统性能保持在相同水平。
测试期间，存储系统上的负载大约为6,500 IOPS，比率为60/40（读取为3,900 IOPS，写入为2,600 IOPS），每个工作站约为28 IOPS。
写入的平均响应时间为3 ms，读取的平均响应时间为1 ms。
总结
在HPE SimpliVity基础架构上模拟实际负载时，获得的结果证实了系统能够在一对SimpliVity节点上提供至少300台Full Clone计算机的虚拟桌面的能力。 同时，在整个测试过程中，存储系统的响应时间保持在最佳水平。
实施前冗长的测试和解决方案比较的方法给我们留下了深刻的印象。 如果您愿意，我们可以为您的工作负载测试性能。 包括其他超融合解决方案。 提到的客户现在正在并行完成对另一个解决方案的测试。 它当前的基础架构只是每个工作场所的PC机群，域和软件。 当然，在没有测试的情况下迁移到VDI是非常困难的。 具体来说，如果不将实际用户迁移到VDI服务器场，就很难理解其真正功能。 这些测试使您可以快速评估特定系统的实际功能，而无需吸引普通用户。 因此，出现了这样的研究。
第二个重要方法-客户立即放下正确的缩放比例。 在这里，您可以购买服务器并添加服务器场，例如，对于100个用户，一切都是可以以用户的价格进行预测的。 例如，当他们需要添加另外300个用户时，他们将知道他们需要已经定义好的配置中的两台服务器，而不必考虑重新升级整个基础架构的可能性。
HPE SimpliVity Federation的有趣功能。 业务因地理位置而异，因此将您自己的单独VDI铁片放在远处是很有意义的。 在SimpliVity Federation中，每个虚拟机均按计划进行复制，并且能够非常快速地在地理位置较远的群集之间进行操作，并且不会在通道上造成负载-这是一个非常好的内置备份。 在站点之间复制VM时，使用通道的方式应尽可能少，这使得可以通过单个控制中心和大量分散存储站点来构建非常有趣的DR架构。
联合会所有这一切使得可以对财务方面进行详细评估，并将VDI的成本强加到公司的增长计划中，并了解解决方案的回报速度和工作原理。 因为任何VDI都是最终可节省大量资源的解决方案，但同时极有可能在没有成本效益的情况下在5-7年内对其进行更改。
一般而言，如果您有任何其他疑问，请致信mk@croc.ru。