Azure NetApp Files 的應用程式復原能力常見問題
本文回答關於 Azure NetApp Files 應用程式復原的常見問題（常見問題）。
建議您如何處理因記憶體服務維護事件而可能造成的應用程式中斷？
Azure NetApp Files 可能會偶爾進行計劃性維護（例如平臺更新、服務或軟體升級）。 從檔案通訊協定 （NFS/SMB） 的觀點來看，只要應用程式可以處理可能會在這些事件期間短暫發生的 IO 暫停，維護作業就會不中斷。 I/O 暫停通常很短，範圍從幾秒到 30 秒。 NFS 通訊協議特彆強固，而且用戶端伺服器文件作業會正常繼續。 某些應用程式可能需要微調，才能處理 IO 暫停，只要 30-45 秒。 因此，請確定您知道應用程式的復原設定，以應付記憶體服務維護事件。 對於利用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 上執行 Apache ActiveMQ 與 LevelDB 或 KahaDB。 即使使用 NFS 通訊協定，仍可採取哪些預防措施，以避免因為記憶體服務維護事件而中斷？
如果您正在執行 Apache ActiveMQ，建議您部署具有可插式 儲存體 保險箱的 ActiveMQ 高可用性。
ActiveMQ 高可用性 （HA） 模型可確保訊息代理程序實例一律在在線且能夠處理訊息流量。 兩個最常見的 ActiveMQ HA 模型牽涉到透過網路共用文件系統。 目的是將 LevelDB 或 KahaDB 提供給主動和被動代理程式實例。 這些HA模型要求在LevelDB或KahaDB目錄中的檔案上取得和維護OS層級鎖定，稱為「鎖定」。此 ActiveMQ HA 模型有一些問題。 它們可能會導致「無主圖形」的情況，其中複本不知道該複本可以鎖定檔案。 它們也可以導致「主要主機」設定，導致索引或日誌損毀，最終訊息遺失。 這些問題大多來自 ActiveMQ 控制之外的因素。 例如，優化不佳的 NFS 用戶端可能會導致鎖定數據在負載下變得過時，導致故障轉移期間的「無主機」停機。
由於此 HA 解決方案的大部分問題都源於 OS 層級檔案鎖定不正確，ActiveMQ 社群 在訊息代理程式 5.7 版中引進了可插入式儲存保險箱 的概念。 這種方法可讓使用者利用共享鎖定的不同方式，使用數據列層級 JDBC 資料庫鎖定，而不是作業系統層級文件系統鎖定。 如需 ActiveMQ HA 架構和部署的支援或諮詢，您應該 連絡 Perforce 的 OpenLogic。
我在 Azure NetApp Files 上執行 Apache ActiveMQ 與 LevelDB 或 KahaDB。 即使使用 SMB 通訊協定，仍可採取哪些預防措施來避免因為記憶體服務維護事件而中斷？
一般產業建議是 不要在 CIFS/SMB 上執行 KahaDB 共用記憶體。 如果您在維護精確的鎖定狀態時遇到問題，請查看 JDBC 插入式 儲存體 保險箱，這可以提供更可靠的鎖定機制。 如需 ActiveMQ HA 架構和部署的支援或諮詢，您應該 連絡 Perforce 的 OpenLogic。
我在 Azure NetApp Files 上執行 Boomi。 我可以採取哪些預防措施，以避免因為記憶體服務維護事件而中斷？
如果您正在執行 Boomi，建議您遵循 運行時間高可用性和災害復原的 Boomi 最佳做法。
Boomi 建議使用 Boomi 分子來實作 Boomi Atom 的高可用性。 Boomi 分子系統需求指出可以使用已啟用 NFS 鎖定的 NFS（NLM 支援）或 SMB 檔案共用。 在 Azure NetApp Files 的內容中，NFSv4.1 磁碟區支援 NLM。
Boomi 建議搭配 Windows VM 使用 SMB 檔案共用;針對 NFS，Boomi 建議使用 Linux VM。