突发！17000个Citrix云桌面某分支无法登录，PVS云桌面启动后的致命错误背后是...？

原创于 2025-08-05 10:00:00 发布 · 1.2k 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#信息可视化 #云计算 #虚拟化 #Citrix #云桌面 #Xendesktop #思杰

Citrix 专栏收录该内容

18 篇文章

订阅专栏

部署运行你感兴趣的模型镜像

哈喽大家好，欢迎来到虚拟化时代君（XNHCYL），收不到通知请将我点击星标！“ 大家好，我是虚拟化时代君，一位潜心于互联网的技术宅男。这里每天为你分享各种你感兴趣的技术、教程、软件、资源、福利…（每天更新不间断，福利不见不散）

前两天，我和同事Joe、Lim.Zhang汇总集团全球多地数据中心提交的约17000个Citrix云桌面使用的问题，我们发现了多个问题，但是最让我们重点关注的一个特定问题：“重启后作业即重启后有某些任务执行”。

第一章、问题现象

     根据澳大利亚的 IT 部门报告，他们收到了很多有关性能、延迟和登录问题的投诉。用户对环境出现这种问题很头疼，主要总结一些问题。

1、登录时间非常高

2、桌面运行缓慢

3、黑屏

4、连接问题（Storefront错误和未注册的VDA）

第二章、问题探讨

由于我们三个和澳大利亚用户没有直接的联系，也没有日常交集，因此我们根据以下维度进行分析

1、首先将情绪从问题中剥离出来，开始在多个层面进行测量。

当一个问题的持续时间较长时，通常会伴随着很多情绪和一些可能的假设。比如，“是网络的问题！”“我们没有使用最新版本！”“买新硬件吧！”

最终我们决定开始测试：也许需要新硬件，也许是版本问题，我们首先需要验证它。

2、从生活中的例子说起

当你家里的孩子告诉你“我发烧了，我病了”时，我们通常做的第一件事就是拿到温度计，了解发生了什么事情（理想情况下，你每天 24 小时都这样做，这样你就可以观察到变化趋势并收到警报，但孩子们不会每天 24 小时都戴着温度器）。我想说的是，不要轻易假设某个结论是正确的，而是要通过实际数据来验证（一切可能为依据的假设都是不可靠的！）

同样的此方法适用于技术问题的排查。我们需要通过数据来诊断问题，而不是仅凭猜测。

第三章、数据测试与分析

为了全面了解问题，我们需要收集数据并进行分析。以下是我们使用的工具：

SexiGraf
：用于硬件虚拟化的数据可视化。
InfluxDB
：作为附加数据库，用于存储捕获的数据，并可以与 SexiGraf 仪表板集成。

通过编写脚本，我们将数据注入 InfluxDB，并生成可视化图表。从图表中可以看到，WriteCache 的空间使用情况非常不乐观——0% 空闲空间意味着会话崩溃，而图表中多次出现了接近或达到 0% 的情况。这解释了用户会话频繁崩溃、未注册状态和连接错误的原因。

1、发现问题：WriteCache 已满

当我们与测试用户开始新会话时，PVS（Provisioning Services）状态托盘，发现 Citrix WriteCache 已经接近满载。大多数 Citrix 工程师都知道，在会话启动时，WriteCache 的空间会迅速消耗，几乎一半的空间会被占用。如果 WriteCache 空间被完全占满，用户会话就会崩溃。

我们三个探讨了下，如果验证问题必须观察一天是实时状态，于是考虑能否通过绘制图表来全面了解这个问题？一天中的情况如何？多个用户都会遇到这种情况？为此，我们编写了一个脚本，将数据注入 InfluxDB，以便我们得到可视化效果：

从图表中可以看到，问题比我们想象的更严重。0% 空闲空间意味着会话崩溃，而图表中多次出现了接近或达到 0% 的情况。这正好符合用户会话频繁崩溃、未注册状态和连接错误的原因。

2、为什么写缓存会被填满这么多？

Ivanti 自动化：

由于该用户正在使用 Ivanti 套件（包括 Workspace Control 和 Automation），常见的怀疑对象是“重启后作业”——即在非持久性 VDI（虚拟桌面基础设施）机器启动后，添加或删除软件的操作。果然我们发现了一些问题

这些任务的具体内容我们无法获取，但其中有删除并重新安装 Google Chrome 和 Adobe Reader……唉……我们的建议是：与其将这些操作注入 WriteCache，不如直接创建一个新的镜像（或者新版本的 Vdisk）。在我们看来，构建一个新的系统镜像并添加到现有的 Vdisk 中，比将这些操作写入 WriteCache 更好。

不过，您是否知道 Ivanti Workspace Control 也可以触发自动化任务？以下是一个例子：

我们看到登录时安装软件。如图所示，仅这个 MSI 就有近 255 MB…而且还是压缩后的……因此，我们做了一些清理工作，并与用户就任务进行了适当的讨论。优化效果开始明显。我们部署了进一步优化的任务，但这已经是一个良好的开端。

3、优化后反馈情况

根据澳大利亚分部反馈：崩溃的会话/重新连接问题正在减少。图表反映了这一点，但已经显示出积极的进展

在我们开始测试时，注意到了一些异常的峰值。我们在 InfluxDB 中记录了会话数，以便我们可以在 SexiGraf 中绘制该图表并将其与 CPU 就绪和磁盘延迟关联起来。

会话数在 07:00 到 09:00 之间显著增加（这并不意外）。

2/3/4.。CPU 就绪时间和磁盘延迟的异常峰值与 Citrix 中配置的启动计划相关。虽然启动时会有一定的负载，但观察到的峰值明显过高。

猜猜怎么着...当“重启后作业”和 Ivanti Workspace Control 作业清理完毕后...启动计划中的磁盘延迟大幅下降，并且 CPU 按照相同的启动计划显著改善，尤其是在用户登录的高峰期（大约 08:00 左右）。重启和登录后的任务产生了连锁反应...注意延迟的缩放比例...（我们也注意到整体CPU 就绪时间仍然较高）