应用程序弹性：保持 Windows 应用可用

介绍

Windows 应用程序通常依赖于远比托管它们的服务器更多的东西。数据库、身份服务、存储、网关、网络和用户端点都可能影响应用程序在中断期间是否保持可用。本文解释了 IT 团队如何评估这些依赖关系，围绕现有 Windows 应用程序设计弹性，监控正确的层级，并测试恢复计划是否真正保留用户所依赖的业务功能。

什么是应用程序弹性？

应用程序的弹性是指应用程序及其周围基础设施在发生中断时继续提供重要功能的能力，并在故障后可预测地恢复。

干扰可以是小的或大的，原因可能包括硬件或操作系统故障、应用程序崩溃、更新失败、数据库故障、网络中断、身份验证失败、资源耗尽、不可用的依赖项或安全事件。

一个弹性架构承认故障是不可避免的，而不是旨在防止每一个事件，IT 组织寻求限制每个事件的影响，并建立受控的恢复程序以维持或恢复服务。

应用程序弹性不仅仅是服务器正常运行时间

一个常见的错误是将服务器的可用性作为应用程序可用性的代理，而该应用程序在服务器上运行。

为了使商业应用程序真正可用，多个组件需要同时可用：

基础设施 → 操作系统 → 应用程序 → 依赖关系 → 访问路径 → 用户会话 → 业务流程

链中任何元素的问题都可能导致应用程序实际上无法使用。

例如，一个应用服务器可能是健康的，而其数据库却无法访问。一个已发布的应用程序可能正常工作，但网关故障使远程员工无法访问它。用户甚至可能成功启动应用程序，但由于许可、文件或后端服务不可用而无法完成交易。

应用程序的弹性应根据用户执行必要业务任务的能力来衡量，而不是服务器是否能够响应可用性或健康检查。

为什么Windows应用程序的应用程序弹性不同？

现代弹性实践越来越关注云原生应用、容器、微服务和自动化编排。虽然这些是有价值的方法，但并不总是适用于每个组织。

许多组织拥有在云原生架构普遍之前开发的传统Windows业务应用程序。ERP软件、会计应用程序、制造应用程序、医疗保健应用程序、工程应用程序和内部开发的应用程序可能对组织的运营至关重要。

将这些应用程序重新架构为微服务可能非常昂贵，技术上具有挑战性，或者如果组织不控制源代码，甚至可能完全不可行。

在这种情况下，使应用程序周围的操作更加弹性可能会带来显著的价值，而不是试图使应用程序本身更加弹性。 应用程序发布 可以通过将现有的Windows应用程序保留在集中基础设施上，同时改变用户访问它们的方式来实现这种方法。这可以包括对托管应用程序的基础设施进行更改，例如消除基础设施限制、创建冗余应用程序主机、启用替代访问方法以及为应用程序主机实施更灵活的恢复程序。

在什么情况下 Windows 应用程序的可用性可能会失败？

构建应用程序的弹性始于发现成功将应用程序从其主机交付给用户所需的组件。这个过程突出了可能导致整个应用程序崩溃的潜在故障点。

应用主机

在单个 Windows 服务器上运行的应用程序具有明确的单点故障。

硬件问题、Windows 更新、操作系统损坏、资源耗尽或应用程序故障可能会影响依赖该机器的每个用户。如果可用性需求需要，可以设置多个应用程序主机，以减少对任何一台机器的依赖，并在服务器不可用时提供容量。

数据库、存储和其他依赖项

许多Windows应用程序依赖于应用程序主机外部的服务。这些服务可以包括：

• SQL 数据库
• 文件共享
• 许可服务器
• Active Directory
• 域名系统 (DNS)
• 证书
• 应用程序接口
• 中间件
• 网络存储
• 打印基础设施

引入第二个应用服务器提供的弹性很小，如果它们共享一个不可用的公共数据库或存储依赖关系。显然，依赖关系映射需要超越可见的应用基础设施。

身份验证与身份

用户无法访问健康的应用程序，如果必要的身份验证基础设施不可用。

IT团队需要识别其关键应用程序所依赖的身份服务，并确保在这些资源无法访问时有故障转移计划。Active Directory、云身份平台、多因素身份验证（MFA）服务和身份验证网关都可以依赖，以为应用程序提供可用性链。

网络和远程访问路径

对于集中式Windows应用程序，用户与应用程序环境之间的连接代表另一个可能的故障域。

让我们设想完整的链条：

用户设备 → 互联网或局域网 → 网关 → 应用主机 → 后端服务

在这个链条中的任何故障都可能阻止用户完成他们的工作，即使应用程序运行正常。这对于分布式组织尤其相关，因为应用程序可能在数据中心正常运行，但对其他地点的用户不可访问。

端点

应用程序的弹性并不一定要求用户的正常工作站可用。

为授权用户提供从替代设备或通过浏览器访问集中托管应用程序的手段，可以确保在笔记本电脑不可用、办公室无法访问或员工需要在不同地点工作时仍能访问。

应用交付架构可以是更广泛的业务连续性战略的一个组成部分。

构建Windows应用程序的应用程序弹性过程是什么？

没有单一技术可以使应用程序具备弹性。IT团队必须减少可能导致完整功能瘫痪的故障数量，并为仍然存在的故障准备可控的恢复机制。

1. 确定关键应用程序和业务流程

并非所有应用程序都需要相同程度的保护。首先确定哪些应用程序支持主要操作，哪些用户依赖它们以及他们的停机容忍度。

两个恢复目标将业务需求转化为技术规范。 NIST的应急计划指导 定义恢复时间目标（RTO）和恢复点目标（RPO）作为确定恢复需求的关键参数：

• 恢复时间目标 (RTO)：在服务恢复之前可接受的停机持续时间。
• 恢复点目标（RPO）：可接受数据丢失的时间间隔。

一个被密集使用来处理订单的应用程序可能具有几分钟的恢复时间目标，而每周运行一次的财务报告应用程序则可以承受几天的停机时间。

RTO 和 RPO 定义了应用程序所需的保护类型：即时故障转移、快速恢复服务或仅仅是一个记录的恢复程序。

2. 映射整个应用程序依赖链

记录应用程序执行其工作的所有必要内容。

不要仅仅停留在可执行文件或Windows服务器上。不要忘记数据库、存储、身份验证、DNS、网络、证书、许可系统、网关和外部服务。

对于每个，询问：

如果这个消失了，应用程序会发生什么？

此练习将揭示隐藏的单点故障并建立恢复顺序。如果应用程序主机首先恢复，但其数据库、身份服务或存储尚不可用，则帮助不大。

消除关键单点故障

一旦建立了依赖关系树，确定哪些组件需要被冗余，基于业务重要性和恢复目标。

在Windows应用程序交付的情况下，这可能涉及部署多个应用程序服务器，而不是依赖单个主机的能力。通过负载均衡层，正常操作期间会将会话分散到应用程序实例上。在主机故障的情况下，传入连接可以路由到健康的应用程序服务器实例。

冗余规划应基于依赖分析，但多个应用服务器访问单个关键数据库、网络网关或存储层仍然存在单点故障。

高可用性设计因此必须将应用服务视为一个整体实体。对于需要基础设施级冗余的Windows Server环境， 微软的故障转移集群文档 提供有关高可用性和灾难恢复拓扑的进一步指导。

4. 将应用程序与单个终端分开

在每个员工的工作站上直接安装关键应用程序可能会导致另一种弹性问题。如果用户失去对其常规计算机的访问，他们可能也会失去对继续工作的应用程序的访问。

在托管的Windows主机上集中应用程序 并向用户展示应用程序界面消除了这一风险。数据和应用程序状态存储在受管理的Windows主机上，并由授权的终端访问。

通过这样做，我们使应用程序即使在用户更换设备或位置时也可用。虽然集中应用程序并不能消除基础设施问题，但它有助于将其移入一个可以由IT控制的环境中。

提供多种实用的访问方法

通过避免对单一端点类型或连接方式的不必要依赖，也可以实现弹性。

根据应用程序交付架构，用户可以使用不同的 remote access 方法，包括与RDP兼容的客户端、专用应用程序启动器、Web门户或HTML5浏览器会话。

替代连接方法不应与基础设施冗余混淆。如果所有方法都依赖于同一台故障服务器，则应用程序仍然不可用。

他们确实提供访问弹性，当中断影响用户的正常设备、已安装的客户端或位置，而不是应用服务本身时。

6. 监控在降级成为故障之前

应用程序的弹性不仅仅是关于恢复，及时的检测可以避免降级为停机。

在Windows应用程序环境中有用的指标包括CPU利用率、内存压力、磁盘容量和I/O、网络利用率、活动会话、应用程序进程、响应时间、连接失败和依赖服务的可用性。

趋势监控 这是至关重要的，因为一个反复接近其极限的服务器仍然可以在线，而用户体验会逐渐恶化。

阈值警报使管理员能够在用户失去访问权限之前调查事件的前兆。

7. 规划容量峰值和故障转移

一个在硬件级别故障下仍能存活但在需求增加时完全无法运作的应用程序并不是真正对任何类型故障具有韧性的。

容量规划必须考虑不仅是日常使用模式，还要考虑由于季节性需求、变更班次、增长或其他应用程序的托管要求而导致的高峰。

特别是在多服务器托管环境中，必须考虑到单个服务器的损失，确保其他托管节点具有备用容量，以容纳本应在故障节点上执行的任何进程。

否则，故障转移程序可能会将孤立事件简单地转变为广泛的系统性能问题。

8. 保护数据和配置

如果IT无法恢复使应用程序正常工作的组件，替换的Windows服务器就没有什么用。

这可能意味着备份程序需要包括应用程序数据、数据库、配置文件、证书、应用程序设置、用户配置文件、基础设施配置、脚本和许可信息。

该策略将根据应用程序的恢复时间目标（RTO）和恢复点目标（RPO）而有所不同。

首先，确保成功的备份不等于成功的恢复。IT团队应测试是否可以从受保护的数据和配置中恢复整个应用服务。

减少变更的影响范围

并不总是不可预见的灾难导致中断。它们也可能是由实施的改进引起的。因此，Windows 补丁、应用程序和驱动程序升级、安全策略和配置更改也可能对应用程序的可用性产生负面影响。如果可能，建议避免同时对所有生产主机进行类似的更改。

在多服务器设置中，可以分阶段进行改进更改，从而允许管理员确保一切正常工作。能够回滚所做的更改也是至关重要的。

因此，在设计应急程序时，还应考虑回滚选项。该过程应得到适当记录，员工应知道在变更失败时该如何处理，而不是简单地将其留给他们的自由裁量。

10. 优雅降级设计

韧性并不是指始终保持100%的正常功能运转。

在某些情况下，维持关键用户或应用程序的操作可能比确保所有服务对所有用户可用更为重要。IT团队可以在事件发生之前确定优先级。

如果有可用的容量，可以考虑首先将其分配给生产、客户服务、财务或其他职能。

这就是优雅降级：保留运行产生最大商业价值的功能的能力，而不是让不太关键元素的故障导致整个系统崩溃。

IT团队应该如何监控应用程序的弹性？

监控单个服务器可能有用，但弹性监控应反映用户感知的整体应用服务。

一个现实的模型由几个层次组成：

层	监控内容	示例失败
主机	CPU, RAM, 磁盘, 操作系统可用性	服务器过载或离线
应用程序	处理和服务状态	应用程序崩溃
依赖	数据库, DNS, 身份, 存储	应用程序启动但无法操作
访问	网关，门户，网络路径	用户无法连接
会话	活跃用户，故障，延迟	应用程序在线但无法使用
业务功能	成功的工作流程完成	用户无法完成所需的任务

业务功能层是最容易被忽视的层之一。

基础设施仪表板可能会将所有服务器、服务和网络路径显示为健康状态，而真实用户的工作流程却受到影响。因此，关键应用程序从其设计支持的操作角度监控其健康状况是非常重要的。

应用程序弹性应该如何测试？

一个从未经历过控制失败的弹性架构包含未经验证的假设。

使用测试评估系统在关键组件不可用时的响应。测试应包括将应用程序主机下线、停止应用程序服务、模拟网络路由丢失、验证网关或负载均衡行为、从备份恢复以及从替代端点访问应用程序。

测试过程应超越恢复的技术方面。IT团队应审查警报是否发送给正确的管理人员，恢复步骤是否按正确的顺序执行，以及用户在服务恢复后是否能够执行实际的业务任务。

操作程序是弹性系统的重要组成部分。警报升级程序：谁接收警报？谁有权启动故障转移？恢复文档和凭据存储在哪里？哪个依赖项需要首先上线？

技术冗余提供的好处有限，如果恢复访问的过程没有经过测试。

应用程序弹性检查清单可以是什么？

在开始构建一个关键的Windows应用程序的弹性之前，IT团队应该能够回答以下问题：

• 哪些业务流程依赖于该应用程序？
• 它的 RTO 和 RPO 是什么？
• 它需要哪些服务器、数据库和外部服务？
• 它的关键单点故障在哪里？
• 如果一个主机失败，另一个应用程序主机可以接受用户吗？
• 用户如果正常的终端或位置不可用，是否可以连接？
• 是否有足够的备用容量以支持降级操作？
• 基础设施、依赖关系和会话问题是否得到积极监控？
• 管理员在重要阈值变为故障之前会收到警报吗？
• 应用程序数据和配置是否受到保护？
• 恢复功能是否经过实际测试？
• 有问题的更改可以撤回吗？
• 恢复序列是否已记录？
• 用户在恢复后能否完成所需的业务流程？

并非所有答案都需要昂贵的高可用性基础设施。适当的保护级别取决于停机的成本和运营影响。

重要的是，可用性、冗余和恢复决策是经过深思熟虑做出的，而不是假设的。

TSplus 如何帮助保持 Windows 应用程序可用？

对于依赖现有Windows应用程序的组织，我们可以通过将应用程序集中在受管理的Windows服务器上，并通过兼容RDP的客户端、RemoteApp风格的访问或HTML5网页门户将其交付给用户，从而帮助提高可用性。这减少了对单个用户终端的依赖，并为IT团队在用户需要从其他设备或位置连接时提供了更多灵活性。

TSplus 远程访问 还可以支持具有负载均衡和基于网关的访问的多服务器部署。当与弹性数据库、存储、身份服务和网络结合时，这种架构可以减少对单一应用主机的依赖，并在基础设施中断期间帮助维护对关键Windows应用程序的访问。

结论

应用程序的弹性依赖于对基础设施与业务使用之间完整路径的理解。冗余、监控、备份、容量规划和恢复程序在围绕明确定义的应用程序依赖关系和恢复目标设计时最为有效。

对于现有的Windows应用程序，韧性通常来自于加强软件周围的环境，而不是重建应用程序本身。关键测试仍然很简单：当发生中断时，用户能否继续工作，或者IT能否在约定的恢复窗口内恢复所需的业务功能？