Azure NetApp Files 的應用程式復原能力常見問題
本文回答關於 Azure NetApp Files 應用程式復原能力的常見問題集 (FAQ)。
您建議如何處理由於儲存體服務維護事件而可能造成的應用程式中斷？
Azure NetApp Files 可能偶爾遇到計劃性維護 (例如平台更新、服務或軟體升級)。 從檔案通訊協定 (NFS/SMB) 的觀點來看，只要應用程式可以處理這些事件期間可能短暫發生的 IO 暫停，維護作業就不會造成干擾。 I/O 暫停通常很短，從幾秒鐘到 30 秒。 NFS 通訊協定特別強固，用戶端-伺服器檔案作業會正常繼續。 某些應用程式可能需要微調，才能處理長達 30-45 秒的 IO 暫停。 因此，請確定您了解應用程式的復原設定，以應付儲存體服務維護事件。 對於利用 SMB 通訊協定的人類互動式應用程式，標準通訊協定設定通常就已足夠。
重要
為了確保有復原性的架構，請務必辨識雲端在共同責任模型中運作。 此模型包含 Azure 雲端平台、其基礎結構服務、OS 層和應用程式廠商。 每一個元件在正常處理儲存體服務維護事件期間可能發生的應用程式中斷時，都扮演著重要角色。
我需要針對 SMB 型應用程式採取特殊的預防措施嗎？
是，某些 SMB 型應用程式需要 SMB 透明容錯移轉。 SMB 透明容錯移轉支援在 Azure NetApp Files 服務上進行維護作業，而不會造成在 SMB 磁碟區上儲存和存取資料的伺服器應用程式中斷連線。 為了對特定應用程式支援 SMB 透明容錯移轉，Azure NetApp Files 現在支援 SMB 持續可用性共用選項。 以下各項的工作負載不支援使用 SMB 持續可用性：
- Citrix 應用程式分層
- FSLogix 使用者設定檔容器
- FSLogix ODFC 容器
- Microsoft SQL Server (非 Linux SQL Server)
- MSIX 應用程式連結
警告
SMB 持續可用性不支援自訂應用程式，且無法與已啟用 SMB 持續可用性的磁碟區搭配使用。
我在 Azure NetApp Files 上執行 IBM MQ。 儘管使用 NFS 通訊協定，我可以採取哪些預防措施，以避免因為儲存體服務維護事件而中斷？
如果您在共用檔案設定下執行 IBM MQ 應用程式，其中 IBM MQ 資料和記錄儲存在 Azure NetApp Files 磁碟區，建議考慮下列作法，以改善儲存體服務維護事件期間的復原能力：
- 您必須只使用 NFS v4.1 通訊協定。
- 為了確保高可用性，您應該採用使用共用 NFS v4.1 磁碟區的 IBM MQ 多重執行個體設定。
- 您應該驗證使用共用 NFS v4.1 磁碟區的 IBM 多重執行個體設定的功能。
- 您應該實作向外延展 IBM MQ 架構，而不是使用一個很大的多重執行個體 IBM MQ 設定。 由於將訊息處理負載分散到多個 IBM MQ 多重執行個體配對，因為每個 MQ 多重執行個體配對處理的訊息變少，服務中斷的機會就可能降低。
注意
每個 MQ 多重執行個體配對應該處理的訊息數目很大程度取決於您的特定環境。 您必須決定需要多少個 MQ 多重執行個體配對，或會有什麼擴大或縮小規則。
向外延展架構由部署在 Azure Load Balancer 後方的多個 IBM MQ 多重執行個體配對所組成。 然後，設定為與 IBM MQ 通訊的應用程式會設定為透過 Azure Load Balancer 來與 IBM MQ 執行個體進行通訊。 如需與共用 NFS 磁碟區上的 IBM MQ 相關的支援，您應該在 IBM 尋求廠商支援。
我在 Azure NetApp Files 上以 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 Files 上以 LevelDB 或 KahaDB 執行 Apache ActiveMQ。 儘管使用 SMB 通訊協定，我可以採取哪些預防措施，以避免因為儲存體服務維護事件而中斷？
一般產業建議是不要在 CIFS [通用網際網路檔案系統]/SMB 上執行 KahaDB 共用儲存體。 如果您在維護準確的鎖定狀態時遇到問題，請試一試 JDBC 插入式儲物櫃，這提供更可靠的鎖定機制。 如需 ActiveMQ HA 架構和部署方面的支援或諮詢，您應該連絡 OpenLogic by Perforce。
我在 Azure NetApp Files 上執行 Boomi。 我可以採取哪些預防措施，以避免因為儲存體服務維護事件而中斷？
如果您執行 Boomi，建議您遵循 Boomi 的執行階段高可用性和災害復原最佳做法。
Boomi 建議使用 Boomi Molecule 來實作 Boomi Atom 的高可用性。 Boomi Molecule 系統需求指出可以使用已啟用 NFS 鎖定 (NLM 支援) 的 NFS 或 SMB 檔案共用。 就 Azure NetApp Files 而言，NFSv4.1 磁碟區具有 NLM 支援。
Boomi 建議對 Windows VM 使用 SMB 檔案共用；若為 NFS，Boomi 建議用在 Linux VM。
注意
Boomi 不支援 Azure NetApp Files 持續可用性共用。