彈性 SAN 中的可靠性
本文說明 Azure Elastic SAN 中的可靠性支援，並涵蓋可用性區域的區域復原和災害復原和商務持續性。
可用性區域支援
Azure 可用性區域是每個 Azure 區域內至少三個實體獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻系統和網路基礎結構。 在本機區域失敗的案例中，可用性區域的設計在於，當一個區域受影響時，讓其餘兩個區域支援區域服務、容量和高可用性。
這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 透過 Azure 服務的備援和邏輯隔離，實現對失敗的容錯。 如需深入了解 Azure 的可用性區域，請參閱區域和可用性區域。
已啟用 Azure 可用性區域的服務旨在提供正確程度的可靠性和彈性。 您可以透過兩種方式加以設定。 它們可以是區域備援，具有跨區域自動複寫功能，或者是區域性的，將執行個體釘選在特定區域。 兩種方法可以結合使用。 如需區域與區域備援架構的詳細資訊，請參閱使用可用性區域和區域的建議。
Azure Elastic SAN 支援使用本地備援儲存體 (LRS) 的可用性區域部署，並使用區域備援儲存體 (ZRS) 進行區域部署。
必要條件
LRS 和 ZRS 彈性 SAN 目前僅適用於區域子集。 如需區域清單，請參閱調整彈性 SAN 的目標。
使用可用性區域建立資源
若要建立已啟用可用性區域的彈性 SAN，請參閱部署彈性 SAN。
區域關閉體驗
部署彈性 SAN 時，如果您針對 SAN 的備援選項選取 ZRS，平台就會支援區域性故障轉移，而不需要手動介入。 使用 ZRS 的彈性 SAN 本身的設計目的是自我修復和自我重新平衡，以自動利用狀況良好的區域。
如果您已部署 LRS 彈性 SAN，您可能需要使用匯出至受控磁碟的快照集來部署新的 SAN。
低延遲設計
LRS 上的彈性 SAN 與 ZRS 上的彈性 SAN 之間的延遲差異並不特別高。 不過，對於對延遲尖峰敏感的工作負載，請考慮 LRS 上的彈性 SAN，因為它提供最低的延遲。
可用性區域移轉
若要將 LR 上的彈性 SAN 遷移至 ZRS，您必須快照集彈性 SAN 的磁碟區、將它們匯出至受控磁碟快照集、在 ZRS 上部署彈性 SAN，然後使用這些磁碟快照集在 ZRS 上建立 SAN 上的磁碟區。 若要瞭解如何使用快照集 (預覽)，請參閱快照集 Azure 彈性 SAN 磁碟區 (預覽)。
災害復原和商務持續性
災害復原 (DR) 是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前，請參閱設計災害復原策略的建議。
Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時，許多 Azure 服務不會自動複寫資料，或從失敗區域回復為交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務，都有提供支援災害復原的功能和指導，您可以使用特定服務功能復原，制定災害復原方案。
單一和多重區域災害復原
針對 Azure Elastic SAN，您必須負責 DR 體驗。 您可以擷取磁碟區的快照集，並將其匯出至受控磁碟快照集。 然後，您可以將累加快照集複製到新的區域，以儲存您的資料位於彈性 SAN 所位於區域以外的區域。 您應該匯出到與主要區域相距遙遠的區域，以減少因為災害而受到影響的多個區域的可能性。
中斷偵測、通知及管理
您可以在服務健康狀態 - Microsoft Azure 中找到中斷宣告。
容量和主動式災害復原能力
Microsoft 及其客戶會在共同責任模型下運作。 共同責任意即，對於客戶應支援的災害復原（客戶應負責的服務），您都必須為您部署和控制的任何服務，解決災害復原問題。 您應該預先驗證您部署的任何服務，才能與彈性 SAN 搭配運作。 為確保執行主動式復原，您應該每次都要預先部署次要複本，因為未預先配置的人員在受到影響時不一定有容量可用。