你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure NetApp 文件的应用程序复原能力常见问题解答
本文解答了有关 Azure NetApp 文件应用程序复原能力的常见问题 (FAQ)。
若要处理因存储服务维护事件引起的潜在应用程序中断问题，你建议执行哪些操作？
Azure NetApp 文件可能会不定期进行计划内维护（例如，平台更新、服务或软件升级）。 从文件协议 (NFS/SMB) 角度来看，只要应用程序可以处理在执行维护操作的过程中可能会短暂发生的 IO 暂停，那么这些操作就是非中断性的。 I/O 暂停通常只持续较短时间，从几秒到 30 秒不等。 NFS 协议特别可靠，客户端-服务器文件操作会正常持续。 某些应用程序可能需要进行优化才能处理长达 30-45 秒的 IO 暂停。 因此，请确保知悉应用程序的复原设置以应对存储服务维护事件。 对于利用 SMB 协议的人机交互应用程序，通常标准协议设置就已足够。
重要
为了确保可复原的体系结构，必须认识到云是在“共担责任”模型下运行的。 此模型包括 Azure 云平台、它的基础结构服务、OS 层和应用程序供应商。 其中每个组件都在正常处理存储服务维护事件期间可能出现的应用程序中断方面发挥着重要作用。
对于基于 SMB 的应用程序，是否需要采取特殊的预防措施？
是的，某些基于 SMB 的应用程序需要 SMB 透明故障转移。 SMB 透明故障转移可在 Azure NetApp 文件服务上实现维护操作，并且依然保持连接到存储和访问 SMB 卷上的数据的服务器应用程序。 为支持针对特殊应用程序的 SMB 透明故障转移，Azure NetApp 文件现在支持 SMB 连续可用性共享选项。 只有以下资源上的工作负载支持使用 SMB 持续可用性：
- Citrix App Layering
- FSLogix 用户配置文件容器
- FSLogix ODFC 容器
- Microsoft SQL Server（而非 Linux SQL Server）
- MSIX 应用附加
注意
自定义应用程序不支持 SMB 持续可用性，也不能用于启用了 SMB 持续可用性的卷。
我正在 Azure NetApp 文件上运行 IBM MQ。 可以采取哪些预防措施，来避免即使使用 NFS 协议也会出现的中断（因存储服务维护事件而造成）？
如果你运行的是使用共享文件配置的 IBM MQ 应用程序（在该配置中，IBM MQ 数据和日志存储在 Azure NetApp 文件卷上），则建议考虑以下注意事项以提高存储服务维护期间的复原能力：
- 须仅使用 NFS v4.1 协议。
- 为实现高可用性，应使用利用共享 NFS v4.1 卷的 IBM MQ 多实例配置。
- 应对利用共享 NFS v4.1 卷的 IBM 多实例配置的功能进行验证。
- 应实现横向扩展 IBM MQ 体系结构，而非使用一个大型多实例 IBM MQ 配置。 通过在多个 IBM MQ 多实例对之间分布消息处理负载，可能有助于降低服务中断的几率，因为如此一来，每个 MQ 多实例对都将处理更少的消息。
注意
每个 MQ 多实例对应处理的消息数高度依赖于特定环境。 须确定所需的 MQ 多实例对数量，或纵向扩展或纵向缩减的规则。
横向扩展体系结构由在 Azure 负载均衡器后部署的多个 IBM MQ 多实例对组成。 然后，为与 IBM MQ 通信而配置的应用程序将被配置为通过 Azure 负载均衡器与 IBM MQ 实例通信。 对于共享 NFS 卷上的 IBM MQ 相关支持，应在 IBM 获取供应商支持。
我正在 Azure NetApp 文件上运行带有 LevelDB 或 KahaDB 的 Apache ActiveMQ。 可以采取哪些预防措施，来避免即使使用 NFS 协议也会出现的中断（因存储服务维护事件而造成）？
如果运行的是 Apache ActiveMQ，建议使用可插拔存储保险箱部署 ActiveMQ 高可用性模型。
ActiveMQ 高可用性 (HA) 模型确保中转站实例始终处于联机状态，并能够处理消息流量。 最常见的两个 ActiveMQ HA 模型包含通过网络共享文件系统。 目的是向主动和被动中转站实例提供 LevelDB 或 KahaDB。 这些 HA 模型要求在 LevelDB 或 KahaDB 目录中的文件上获取和维护 OS 级锁（称为“锁”）。此 ActiveMQ HA 模型存在一些问题。 它们可能会导致“无主”的情况，在这种情况下，副本并不知道它可以锁定文件。 还可能导致“双主”配置，使索引或日志出现损坏，最终造成消息丢失。 其中的大多数问题都源于 ActiveMQ 无法控制的因素。 例如，优化不佳的 NFS 客户端可能会导致锁定数据在负载下变得过时，从而导致故障转移期间发生“无主”停机。
由于此 HA 解决方案的大多数问题都源于不准确的 OS 级文件锁定，ActiveMQ 社区在 5.7 版中转站中引入了可插拔存储保险箱的概念。 这种方法让用户可以使用其他方式的共享锁定，即行级 JDBC 数据库锁定而不是 OS 级文件系统锁定。 有关 ActiveMQ HA 体系结构和部署的支持或咨询，应联系 OpenLogic by Perforce。
我正在 Azure NetApp 文件上运行带有 LevelDB 或 KahaDB 的 Apache ActiveMQ。 可以采取哪些预防措施，来避免即使使用 SMB 协议也会出现的中断（因存储服务维护事件而造成）？
一般的行业建议是不要在 CIFS [通用 Internet 文件系统]/SMB 上运行 KahaDB 共享存储。 如果在维护准确的锁定状态时遇到问题，请检查 JDBC 可插拔存储保险箱，它可提供更可靠的锁定机制。 有关 ActiveMQ HA 体系结构和部署的支持或咨询，应联系 OpenLogic by Perforce。
我正在 Azure NetApp 文件上运行 Boomi。 可以采取哪些预防措施来避免因存储服务维护事件而造成的中断？
如果运行的是 Boomi，建议遵循关于运行时高可用性和灾难恢复的 Boomi 最佳做法。
Boomi 建议使用 Boomi 分子实现 Boomi 原子的高可用性。 Boomi 分子系统要求规定，可以使用启用了 NFS 锁定的 NFS（NLM 支持）或 SMB 文件共享。 在 Azure NetApp 文件上下文中，NFSv4.1 卷具有 NLM 支持。
Boomi 建议 Windows 虚拟机使用 SMB 文件共享；对于 NFS, Boomi 建议使用 Linux 虚拟机。
注意
Boomi 不支持 Azure NetApp 文件连续可用性共享。