Share via

已啟用 Azure Arc SQL 受管理執行個體 的網路連線能力

  • 發行項

已啟用 Azure Arc 的資料服務支援兩種不同的連線模式。 直接連線和間接連線模式會部署已啟用 Azure Arc 的SQL 受管理執行個體在已啟用 Azure Arc 的 Kubernetes 叢集上使用 Azure Arc 控制平面執行。

已啟用 Arc 的資料服務元件如下：

  • Azure Arc 資料控制器
  • Azure Arc Active Directory 連接器
  • 已啟用 Azure Arc 的 SQL 受控執行個體

這些元件會與 Azure Arc 端點、Active Directory 網域控制站和網域名稱系統 (DNS) 在內部部署和其他雲端環境中執行的伺服器通訊。

本文說明從內部部署或其他雲端基礎結構連線到 Azure 控制平面的網路架構、設計考慮和設計建議。 您將瞭解如何管理和操作已啟用 Arc 的資料服務和已啟用 Arc 的SQL 受管理執行個體在內部部署和其他雲端環境中已啟用 Arc 的 Kubernetes 叢集上執行。

架構

下圖顯示已啟用 Arc 的資料服務網路架構，可支援直接連線和間接連線的網路模式。

顯示已啟用 Azure Arc 的資料服務網路架構的圖表。

下列案例圖顯示各種取用者服務的範例，可安全地存取已啟用 Arc 的SQL 受管理執行個體。

此圖顯示已啟用 Azure Arc 的資料服務安全存取網路架構。

設計考量

  • 檢閱 Azure 登陸區域的 網路拓撲和連線設計區域 ，以配合已啟用 Arc 的資料服務網路連線與貴組織的採用登陸區域設計。

  • 檢閱 已啟用 Azure Arc 的 Kubernetes 網路連線 ，以瞭解網路架構和建議，以針對在已啟用 Arc 的 Kubernetes 叢集上部署及操作已啟用 Arc 的資料服務做出正確的設計決策。 已啟用 Arc 的資料服務會針對服務部署和作業使用已啟用 Azure Arc 的 Kubernetes 網路連線。

  • 檢閱 已啟用 Arc 的資料服務功能可用性，方法是啟用 Azure Arc 的資料服務連線模式和 網路需求 。 決定直接連線模式或間接連線模式是否符合組織內部部署網路或其他雲端提供者的網路安全性原則。

  • 直接連線模式需要直接連線到 Azure，並依此連線本質提供其他優點。 請考慮根據組織安全性和合規性需求啟用此 直接連線 所需的取捨。

  • 視已啟用 Arc 的 Kubernetes 叢集執行位置而定，請考慮使用Kubernetes LoadBalancer或NodePort類型。 這些服務會公開已啟用 Arc 的資料服務，例如資料控制器和SQL 受管理執行個體。 負載平衡器會跨多個實例維護相同的埠號碼，而節點埠會針對每個已啟用 Arc 的SQL 受管理執行個體使用不同的埠號碼。

  • 針對已啟用 Arc 的SQL 受管理執行個體服務，請考慮在內部部署環境中部署軟體負載平衡器類型，例如內部部署環境中的MetalLB，以及在雲端式環境中部署內部負載平衡器。 負載平衡器提供一致的 IP 位址和 SQL 伺服器埠，例如 1433 或自訂埠，並平衡 Kubernetes 叢集中節點的負載。 自動調整叢集中的節點 IP 變更。 當 Pod 從一個 Kubernetes 背景工作節點移至另一個 Kubernetes 背景工作節點時，它們不會提供高可用性。 例如，在 Kubernetes 叢集、資料控制器和已啟用 Arc 的容錯移轉、升級和維護期間，SQL 受管理執行個體。

  • 請考慮使用傳輸層安全性 (TLS) 埠，例如 636 和 3269 與非 TLS 埠 389 和 3268 搭配Active Directory 網域服務。 TLS 埠會在已啟用 Azure Arc 的 SQL 受管理執行個體中使用AD 驗證時，保持連線安全。

  • 當您使用 Azure 金鑰保存庫來保護已啟用 Arc SQL 受管理執行個體 的Kubernetes 秘密以進行 AD 驗證時，請考慮使用Azure 金鑰保存庫私人端點來保持連線私用。 請參閱Azure 金鑰保存庫秘密提供者擴充功能，瞭解如何將秘密擷取至已啟用 Azure Arc 的 Kubernetes 叢集，以及深入瞭解如何搭配已啟用 Arc 的 Kubernetes 叢集使用 Azure 金鑰保存庫。

  • 使用Azure 儲存體帳戶封存 Blob來保留已啟用 Arc 的 SQL 受管理執行個體資料庫備份檔案以供長期保留時，評估公用與私人端點。

設計建議

  • 檢閱已啟用 Azure Arc 的 Kubernetes 網路設計建議，作為已啟用 Arc 的SQL 受管理執行個體部署在現有已啟用 Arc 的 Kubernetes 叢集上。

  • 使用直接連線模式，而不是間接連線模式部署已啟用 Arc 的資料服務和已啟用 Arc 的SQL 受管理執行個體，以取得直接連線模式部署的功能優點。

  • 針對已啟用 Arc 的資料服務，例如資料控制器、儀表板和已啟用 Arc 的 SQL 受管理執行個體，選擇 [Kubernetes LoadBalancer] 服務類型上方的NodePort服務類型。 LoadBalancer 類型可在 Kubernetes 節點失敗、節點重新開機，以及在 Kubernetes 叢集 的升級和維護 期間提供復原能力。

  • 針對已啟用 Arc 的資料服務部署使用公用雲端基礎結構時，請透過外部負載平衡器使用內部負載平衡器。 內部負載平衡器會從虛擬網路指派私人 IP 位址，並將資料庫流量保留在內部網路。

  • 針對內部部署，請使用容器化負載平衡器，例如 MetalLB 來支援 負載平衡器服務類型。 容器化的負載平衡器會使用標準 SQL 埠 1433 來簡化防火牆規則。 使用 NodePort 服務類型的隨機埠比較容易記住。 請務必 配置子網 CIDR 大小 ，以支援在已啟用 Azure Arc 的 Kubernetes 叢集上部署的已啟用 Arc 的 SQL 受控實例數目。

  • 在系統管理或客戶管理的金鑰索引標籤模式中使用已啟用 Arc 的AD 驗證SQL 受管理執行個體時，請務必將已啟用 Arc 的 DNS 註冊自動化SQL 受管理執行個體端點。 自動化可協助您使用內部部署或其他雲端 DNS 伺服器來探索服務。 它也會消除作業額外負荷，並在變更 IP 位址或刪除服務實例時自動更新 IP 位址。

  • 使用防火牆規則來限制已啟用 Arc SQL 受管理執行個體、資料控制站和儀表板端點的網路存取，以防止存取不受信任的來源。 防火牆規則可減少已啟用 Arc SQL 受管理執行個體的攻擊面，並防止資料外泄。

  • 當您將 Azure 私人端點用於Microsoft 成品登錄 (也稱為 Microsoft Container Registry 或 MCR) 、Azure 金鑰保存庫、Azure Log Analytics 和儲存體帳戶時，請將內部部署 DNS 伺服器設定為將 DNS 查詢轉送至 Azure 中的 DNS 轉寄站。 此方法可讓您使用 DNS 名稱自動探索這些私人端點，並不需要在內部部署 DNS 伺服器中使用主項目目或 DNS 專案註冊。

  • 已啟用 Arc 的 AD 驗證SQL 受管理執行個體需要連線至Active Directory 網域服務。 設定主要和災害復原月臺中網域控制站的連線，以取得高可用性。 隨著許多企業跨地理位置部署月臺復原樹系，請使用最接近的月臺來減少網域控制站的網路延遲。 如需更多指引，請檢閱已啟用 Arc 的SQL 受管理執行個體商務持續性和災害復原。

下一步

如需混合式雲端和多重雲端旅程的詳細資訊，請參閱下列文章：