瞭解混合式案例

已完成

假設您的組織於內部部署和本機資料中心對 SQL Server 基礎結構有大量投資。 在此情況下,請務必注意,使用雲端並不是非此即彼的主張。 有各種方法可以在 Azure 混合式容量中使用現有的內部部署基礎結構,以提升營運韌性及降低成本。

實施混合式基礎結構也是評估雲端運算的絕佳首要步驟,適用於傳統上採用內部部署,且對雲端抱持懷疑態度的組織。 現代的組織通常會於內部部署混合 SQL Server 的實體和虛擬化部署,兩者都可擴充至雲端作為混合式解決方案的一部分。 混合式 SQL Server 平台可同時提供內部部署和雲端服務的優點;取得兩者之間的優勢。 雲端元件通常會使用儲存體或 SQL Server 虛擬機器的 IaaS 服務,如下所示。

描繪混合式解決方案所橋接的內部部署基礎結構和雲端基礎結構的圖表。

除了擴充內部部署解決方案之外,相同的模式也可以套用至現有的替代雲端解決方案,進而啟用雲端對雲端混合式實作。 讓我們查看幾個 SQL Server 最常見的混合式案例。

SQL Server 的混合式案例

讓我們查看幾個部署 SQL Server 混合式解決方案的策略。

災害復原

災害復原是 SQL Server 混合式部署最常見的案例。 災害復原讓組織在重大事件發生時仍能確保業務持續性。 組織可能會將部署分散到多個資料中心,在內部部署方法中方便容錯移轉。 這些資料中心通常位於與組織相同的地理區域內,因此容易受到更重大的區域災害影響。 實體資料中心的部署、監視和維護也會耗費大量成本。 在各種地理區域中啟動 Azure SQL Server 虛擬機器的成本可說是遠小於在另一個地理位置建立新的實體資料中心。

圖表描述從總部到實體資料中心的本機容錯移轉,以及從內部部署網路將混合式容錯移轉至 Azure。

在此混合式方法中,Azure 係用於 DR 容錯移轉 (至一或多個區域) ,一般的日常處理則會繼續使用內部部署伺服器,達到本機高可用性。

SQL Server 備份

SQL Server 備份是另一個常見的混合式案例。 您可以透過 URL 或 Azure 檔案共用 (SMB) 來直接在 Azure 儲存體中完成備份。 當現場備份儲存體失敗時,此案例可防止資料遺失。 此外,這些備份也可以還原至 Azure 的虛擬機器,並在災害復原程序中進行測試。

另一個案例會使用 Azure 儲存體來儲存內部部署的使用者資料庫 SQL Server 資料檔案。 請注意,這些是使用者檔案,而非系統資料庫。 在本機儲存體失敗的情況下,使用者檔案會安全地儲存在雲端,防止資料遺失。 此外,使用 Azure 儲存體具有內建可靠性保證,因此將這些檔案儲存在雲端會更具有復原性。 在此混合式案例中,請務必保持網路通訊安全、評估解決方案的網路延遲,並確保儲存體帳戶已使用 ACL 及 Microsoft Entra ID 鎖定。

已啟用 Azure Arc 的 SQL Server

具有已啟用 Azure Arc 的 SQL 伺服器可將 Azure 管理服務擴充並集中至內部部署、資料中心、邊緣和多雲端環境託管的 SQL Server 執行個體。 在此混合式案例中,Azure Arc 可啟用所有已註冊的 SQL Server 部署,並評估其設定、使用模式和安全性,以根據最佳做法提供動作和建議。 使用已啟用 Azure Arc 的 SQL Server,您就能享有集中式伺服器管理的優勢。 您也可以在內部部署 SQL 伺服器及其主機作業系統上取得 Azure Defender 的即時安全性警示和弱點報告。 此外,Azure Sentinel 還可視需要提供更多安全性威脅檢查。

描述已啟用 Azure Arc 之 SQL Server 架構範例的圖表。

安全性考量

部署混合式 SQL 解決方案時,Active Directory 和 DNS 等所有核心基礎結構都必須存在於內部部署和 Azure 中。 此外,內部部署網路與 Azure 之間必須具備安全的雙向通訊。 此安全通訊的形式可以是站對站 (S2S) VPN 或專門的 ExpressRoute 通道。 評估不同的連線方法時,請務必判斷組織可接受的延遲量。 不論選擇何種解決方案,網路安全性都必須是實作的首要考量。

描述站對站 VPN 閘道至 Azure 的連線圖表。

上圖顯示,S2S VPN 解決方案的優點在於成本通常較低,實作也是網路工程師的常見工作。 然而,若採用此解決方案,所有通訊都會透過公用網際網路進行,且受限於組織的網際網路速度。

描述與 Azure 之 ExpressRoute 連線的連線圖。

如上所示,雖然 ExpressRoute 解決方案通常成本較高,但也能提供最佳的安全性和最低延遲,因為所有通訊都會採用獨立於公用網際網路的直接安全通道。 不過,此解決方案常招致的批評包括整體成本,以及無法在多雲端解決方案中的雲端服務提供者之間套用 ExpressRoute。