客户想要 VDI。 我确实研究了 SimpliVity + VDI Citrix 虚拟桌面组合。 适用于所有操作员、城市办公室员工等。 仅第一波迁移就有五千用户，因此他们坚持进行负载测试。 VDI 可能会开始放慢速度，也可能会平静地躺下 - 但由于渠道问题，这种情况并不总是会发生。 我们专门为 VDI 购买了一个非常强大的测试包，并加载基础设施，直到它对磁盘和处理器的负担过重。
因此，我们需要一个塑料瓶和 LoginVSI 软件来进行复杂的 VDI 测试。 我们拥有可供 300 个用户使用的许可证。 然后，我们将 HPE SimpliVity 380 硬件装入适合每台服务器最大用户密度任务的包中，分割具有良好超额订阅的虚拟机，在其上安装 Win10 办公软件并开始测试。
走吧！
系统
两个 HPE SimpliVity 380 Gen10 节点（服务器）。 在各个：
- 2 个英特尔至强铂金 8170 26c 2.1Ghz。
- RAM：768GB、12 个 64GB LRDIMM DDR4 2666MHz。
- 主磁盘控制器：HPE Smart Array P816i-a SR Gen10。
- 硬盘驱动器：9 个 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。
- 多罗 PDF 1.82。
- Java 7 更新 13。
- 微软 Office 专业增强版 2016。
节点之间——同步复制。 集群中的每个数据块都有两个副本。 也就是说，现在每个节点上都有一组完整的数据。 对于三个或更多节点的集群，块的副本位于两个不同的位置。 创建新 VM 时，会在其中一个群集节点上创建一个附加副本。 当一个节点发生故障时，之前在该节点上运行的所有虚拟机都会在具有副本的其他节点上自动重新启动。 如果某个节点长时间失效，则开始逐步恢复冗余，集群恢复到N+1冗余。
数据平衡和存储发生在 SimpliVity 本身的软件存储级别。
虚拟机运行虚拟化集群，该集群也将它们放置在软件存储上。 办公桌本身是根据标准模板进行的：金融家和运营官员的办公桌来进行测试（这是两个不同的模板）。
测试
为了进行测试，使用了 LoginVSI 4.1 软件测试套件。 LoginVSI 综合体由一台控制服务器和 12 台用于测试连接的机器组成，部署在单独的物理主机上。
测试以三种模式进行：
基准模式 - 负载案例 300 名知识工作者和 300 名存储工作者。
标准模式 - 负载情况 300 电力工作人员。
为了使 Power Worker 能够工作并增加负载多样性，LoginVSI 复合体中添加了附加 Power 库文件的库。 为了确保结果的可重复性，所有测试台设置均保留为默认值。
知识和权力工作者测试模拟了在虚拟工作站上工作的用户的真实工作负载。
存储工作人员测试是专门为测试数据存储系统而创建的；它与真实的工作负载相去甚远，并且主要涉及用户处理大量不同大小的文件。
测试期间，用户登录工作站 48 分钟，速度约为每 10 秒一名用户。
结果
LoginVSI 测试的主要结果是 VSImax 指标，该指标是根据用户启动的各种任务的执行时间编制的。 例如：在记事本中打开文件的时间、在 7-Zip 中压缩文件的时间等。
官方文档中提供了指标计算的详细说明 .
换句话说，LoginVSI 重复典型的加载模式，模拟办公套件中的用户操作、阅读 PDF 等，并测量各种延迟。 存在严重的延迟程度（“一切都变慢了，无法工作”），在此之前，认为尚未达到最大用户数量。 如果响应时间比这种“一切都很慢”的状态快1毫秒，则认为系统工作正常，可以添加更多用户。
以下是主要指标：
公制
所采取的行动
详细 描述
加载的组件
N.S.L.D.
文字开放时间
文件重 1 KB
记事本打开并
打开从池中复制的随机 1 KB 文档
资源
CPU 和 I/O
NFO
对话开放时间
记事本中的窗口
打开 VSI-记事本文件 [Ctrl+O]
CPU、RAM 和 I/O
ZHC*
是时候创建高度压缩的 Zip 文件了
局部压缩
随机 5MB .pst 文件复制自
资源池
CPU 和 I/O
零碳*
是时候创建弱压缩的 Zip 文件了
局部压缩
随机 5MB .pst 文件复制自
资源池
I / O
中央处理器
算计大
随机数据数组
创建一个大数组
将在输入/输出定时器（I/O定时器）中使用的随机数据
中央处理器
执行测试时，首先计算基本的 VSIbase 指标，该指标显示系统上无负载时执行作业的速度。 在此基础上，确定 VSImax 阈值，该阈值等于 VSIbase + 1ms。
关于系统性能的结论是基于两个指标得出的：VSIbase（确定系统的速度）和 VSImax 阈值（确定系统在不显着降低性能的情况下可以处理的最大用户数）。
300 名知识工作者基准
知识工作者是经常以各种小峰值加载内存、处理器和 IO 的用户。 该软件模拟了要求严格的办公用户的工作量，就好像他们不断地查看某些东西（PDF、Java、办公套件、照片查看、7-Zip）。 当您将用户从 300 增加到 XNUMX 时，每个用户的延迟会逐渐增加。
VSImax统计数据：
VSIbase = 986ms，未达到 VSI 阈值。
SimpliVity 监控的存储系统负载统计：
对于这种类型的负载，系统可以承受增加的负载，而性能几乎不会下降。 完成用户任务的时间平稳增长，测试过程中系统响应时间没有变化，写入可达3ms，读取可达1ms。
结论： 300个知识用户在当前集群上工作，没有任何问题，并且互不干扰，达到pCPU/vCPU超额认购1到6。随着负载的增加，整体延迟均匀增长，但尚未达到规定的限制。
300 名存储工人基准
这些用户经常进行写入和读取，比例分别为 30 比 70。 这个测试更多是为了实验而进行的。 VSImax统计数据：
VSIbase = 1673，240 个用户达到 VSI 阈值。
SimpliVity 监控的存储系统负载统计：
这种负载本质上是对存储系统的压力测试。 执行时，每个用户都会将许多不同大小的随机文件写入磁盘。 从本例中可以看出，当某些用户超过一定的负载阈值时，完成写文件任务所需的时间会增加。 同时，主机的存储系统、处理器和内存的负载没有明显变化，因此目前无法准确确定导致延迟的原因。
使用此测试得出的有关系统性能的结论只能通过与其他系统的测试结果进行比较来得出，因为此类负载是合成的且不切实际。 不过，总体来说测试进行得很顺利。 一切都很顺利，直到 210 个会话，然后奇怪的响应开始了，除了 Login VSI 之外，没有任何地方跟踪这些响应。
300名电力工人
这些是热爱CPU、内存和高IO的用户。 这些“高级用户”经常运行长时间突发的复杂任务，例如安装新软件和解压大型档案。 VSImax统计数据：
VSIbase = 970，未达到 VSI 阈值。
SimpliVity 监控的存储系统负载统计：
在测试过程中，其中一个系统节点达到了处理器负载阈值，但这并没有对其运行产生重大影响：
在这种情况下，系统可以承受增加的负载而不会显着降低性能。 完成用户任务的时间平稳增长，测试过程中系统响应时间没有变化，写入可达3ms，读取可达1ms。
定期测试对客户来说还不够，我们更进一步：我们增加了虚拟机特性（用于评估超额订阅和磁盘大小增加的 vCPU 数量）并添加了额外负载。
在进行附加测试时，使用了以下支架配置：
在 300vCPU、4GB RAM、4GB HDD 配置中部署了 80 个虚拟桌面。
其中一台测试机的配置：
计算机部署在“专用 - 完整复制”选项中：
300 名知识工作者超额认购基准 12
VSImax统计数据：
VSIbase = 921 ms，未达到 VSI 阈值。
SimpliVity 监控的存储系统负载统计：
获得的结果与测试之前的 VM 配置类似。
300 名 Power 员工，超额认购 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迅速过载，极大地影响了整个系统的运行。
主机CPU负载：
与此同时，存储系统的延迟也自然增加：
计算能力的缺乏在 240 个用户左右变得至关重要：
根据所获得的结果，决定进行 CPU 密集程度较低的测试。
230 名办公室工作人员基准 + 每个用户 22 IOPS
为了减少 CPU 的负载，选择了 Office Workers 负载类型，并且还为每个会话添加了 22 IOPS 的综合负载。
为了不超过最大 CPU 负载，测试限制为 230 个会话。
该测试由用户运行10个小时来检查系统在接近最大负载的情况下长期运行时的稳定性。
VSImax统计数据：
VSIbase = 918 ms，未达到 VSI 阈值。
VSImax详细统计数据：
该图显示在整个测试过程中没有观察到性能下降。
CPU负载统计：
执行此测试时，主机 CPU 上的负载几乎达到最大。
SimpliVity 监控的存储系统负载统计：
在整个测试过程中，存储系统性能保持不变。
测试期间存储系统上的负载约为 6 IOPS，比率为 500/60（40 IOPS 读取，3 IOPS 写入），即每个工作站约为 900 IOPS。
写入响应时间平均为 3 毫秒，读取响应时间最长为 1 毫秒。
总
在模拟 HPE SimpliVity 基础设施上的实际负载时，获得的结果证实了系统能够支持一对 SimpliVity 节点上至少 300 台完整克隆计算机的虚拟桌面。 同时，在整个测试过程中，存储系统的响应时间都保持在最佳水平。
在实施之前进行长时间的测试和解决方案比较的方法给我们留下了深刻的印象。 如果您愿意，我们也可以测试您的工作负载的性能。 包括其他超融合解决方案。 上述客户目前正在并行完成对另一个解决方案的测试。 它当前的基础设施只是一组 PC、每个工作场所的一个域和软件。 当然，在没有测试的情况下迁移到 VDI 是相当困难的。 具体来说，如果不将真实用户迁移到 VDI 场，就很难了解 VDI 场的真实功能。 这些测试可以让您快速评估特定系统的真实功能，而无需普通用户的参与。 这就是这项研究的由来。
第二个重要方法是客户立即承诺适当扩展。 在这里你可以购买额外的服务器并添加农场，例如，对于100个用户，一切都是可以预测的用户价格。 例如，当他们需要再添加 300 个用户时，他们会知道在已定义的配置中需要两台服务器，而不是重新考虑升级整个基础设施。
HPE SimpliVity 联盟的可能性很有趣。 由于业务在地理位置上是分散的，因此在遥远的办公室安装您自己的单独的 VDI 硬件是有意义的。 在 SimpliVity 联邦中，每个虚拟机都按照计划进行复制，能够在地理上遥远的集群之间非常快速地进行复制，并且通道上没有负载 - 这是一个非常好的水平的内置备份。 在站点之间复制虚拟机时，会尽可能少地使用通道，这使得在存在单个控制中心和一堆分散存储站点的情况下构建非常有趣的灾难恢复架构成为可能。
所有这些结合在一起，可以详细评估财务方面，并将 VDI 成本叠加到公司的增长计划上，并了解解决方案的回报速度及其运作方式。 因为任何 VDI 都是一种最终可以节省大量资源的解决方案，但同时，很可能在使用后 5-7 年内没有经济高效的机会对其进行更改。