Share via

已啟用 Azure Arc 的儲存體專業領域SQL 受管理執行個體

  • 發行項

儲存體是已啟用 Azure Arc SQL 受管理執行個體 (已啟用 Arc SQL 受管理執行個體) 部署中的重要元件。 瞭解本檔中所述的儲存體相關概念如何影響 Kubernetes 叢集的運作，是儲存體設計選擇和管理的重要層面。

Kubernetes 不是直接與基礎儲存體互動，而是透過儲存體類別，為各種儲存體技術提供抽象層。 雲端提供者、硬體廠商和其他 Kubernetes 管理的平臺提供不同的 StorageClass 選項，以符合特定環境和實作案例。

已啟用 Arc 的SQL 受管理執行個體不會限制或使用任何儲存體類別強制執行，因此請務必選擇正確的儲存體設計和設定。 已啟用 Arc 的儲存體設計SQL 受管理執行個體就如同您在裸機或虛擬機器上執行時為SQL Server選擇備份存放裝置一樣重要。 這些選擇最終代表 RPO、RTO、容量和效能的相關需求。

對於已啟用 Arc 的SQL 受管理執行個體部署，有效規劃儲存體功能和設定對於成功運作非常重要。 閱讀以瞭解要考慮的儲存體相關因素，後面接著設定已啟用 Arc SQL 受管理執行個體的建議。

架構

下列架構圖顯示已啟用 Azure Arc 的資料服務元件的邏輯設計。 這些元件包括必要的 Azure Arc 資料控制器，以及一或多個已啟用 Arc 的SQL 受管理執行個體 () ，其中包含已布建以供參考的資料庫。 Azure Arc 資料控制器和已啟用 Arc 的SQL 受管理執行個體都提供支援儲存體裝置的選項，這些裝置相依于 Kubernetes 散發和儲存體基礎結構提供者。

顯示已啟用 Azure Arc 的資料服務邏輯架構圖表的螢幕擷取畫面。

設計考量

以下是儲存體設計和設定的考慮。

存放類別

為已啟用 Azure Arc 的資料服務元件選擇正確的 Kubernetes StorageClass 和設定，對於您的資料儲存體效能、復原和容量而言非常重要。

StorageClass、PersistentVolume (PV) 和PersistentVolumeClaim (PVC) 是布建已啟用 Azure Arc 的資料服務元件時，系統會在 Kubernetes 叢集中建立的 Kubernetes 資源物件。

StorageClass 選項會根據您的雲端提供者、硬體廠商提供的專案，以及 Kubernetes 系統管理員已設定的內容而有所不同。 PersistentVolumeClaim 會要求針對 StorageClass 和所要求的大小建立 PersistentVolume。 下圖是這些 Kubernetes 資源與儲存體類別潛在選項之間的關聯性參考。

顯示 Kubernetes 儲存體概念與儲存體類別選項的螢幕擷取畫面。

在分別布建已啟用 Azure Arc 資料控制器和 Arc 的SQL 受管理執行個體時，會設定 PV 和 PV Kubernetes 資源。

有兩種不同的儲存體類型可供選擇：

  • 當地： 掛接在連結至 Pod 執行所在 Kubernetes 節點之本機儲存體裝置上的磁片區。 相較于遠端/共用儲存體，這種類型的儲存體通常會提供較低的延遲，以及每秒較高的輸入/輸出作業， (IOPS) 和輸送量。
  • 遠端/共用儲存體： 通常隨附內建備援的網路連接存放裝置。 常見的儲存體選項為 NAS 和 SAN 裝置。

選擇 StorageClass 時，請考慮下列標準。 您建置的任何資料庫伺服器，這些準則也會保留 true：

  • 性能： 儲存體裝置輸入/輸出 (I/O) 輸送量和 IOPS 應符合您的資料庫需求。
  • 讀取/寫入比率： 瞭解工作負載可協助您選擇支援硬體，以符合適當成本的需求。 大量寫入工作負載可以利用 RAID 0 設定，而不常存取的資料可能最好使用 SAN 裝置儲存體來提供服務。
  • 資料庫隔離和共置：已啟用 Arc 之實例上的所有資料庫SQL 受管理執行個體共用 PV，因此您可以選擇將資料庫移至已啟用 Arc 的個別實例SQL 受管理執行個體，並避免儲存體資源爭用。
  • 能力： 定義的儲存體大小應符合資料控制器和資料庫實例的未來容量，以避免調整 PVC 的大小。 請考慮您選擇的 StorageClass 可能具有的任何儲存體限制。
  • 存取模式： 儲存體類別提供者有不同的存取模式，支援 Pod 如何掛接和讀取或寫入儲存體的不同功能。 SQL 備份磁片區需要 RWX (讀取寫入許多) 。
  • 冗余： 實體儲存層的資料複寫 (RAID) ，以支援硬體磁片失敗時順暢容錯移轉，這與可用性群組 (AG) 所完成的資料庫層級備援不同。

Azure Arc 資料控制器和已啟用 Arc 的 SQL 受管理執行個體 Arc 資料服務都提供細微的選項，以設定資料庫資料的不同儲存體類別。 這些資料服務也提供記錄，可讓您彈性地選擇儲存體類別以符合需求。

資料控制器

Kubernetes 叢集需要單一 Azure Arc 資料控制器，以建立已啟用 Arc 的實例SQL 受管理執行個體的必要條件。 不支援在叢集中執行的多個資料控制器。

Azure Arc 資料控制器會在 Kubernetes 叢集中執行四個不同的具狀態 Pod：控制器 SQL、控制器 API、記錄資料庫和計量資料庫。 每個 Pod 都需要兩個永續性磁片區來取得資料和記錄磁片區。 所有資料控制器元件都需要遠端 StorageClass 以確保資料持久性，因為資料控制器元件本身不會以原生方式提供資料持久性。

請務必考慮 Azure Arc 資料控制器所需的 計算和記憶體資源 。 下圖代表資料控制器儲存體、PV 和 PVC Kubernetes 資源。

顯示 Azure Arc 資料控制器儲存體的螢幕擷取畫面。

資料控制器預設磁片區大小調整是建議的最小值。 您使用的儲存體取決於資料庫數目、使用資料庫的方式，以及產生的記錄數目。 Azure Arc 資料控制器 StorageClass 不區分低延遲。 即使如此，如果您在叢集中有許多已啟用 Arc 的SQL 受管理執行個體部署，則使用者可能會在 Grafana 和 Kibana 介面中看到快速執行儲存體的優點。 Grafana 和 Kibana 是開放原始碼使用資料控制器部署的監視視覺效果工具，並布建儀表板來檢視已啟用 Arc 的計量和記錄SQL 受管理執行個體。

資料控制器布建

當您布建 Azure Arc 資料控制器時，請設定儲存體類別和資料儲存體容量。 針對記錄和資料設定儲存體，然後套用至您為數據控制器 Pod 建立的所有八個 PV。 在布建期間，您可以指定 自訂部署範本 ，以覆寫預設參數，例如容量、記錄保留，以及與 Kubernetes 服務類型等安全性相關的專案。 布建完成後，就會建立 PV 和 PV Kubernetes 物件。

請務必瞭解資料控制器的 StorageClass 一旦布建後就無法變更。 如果您未指定 StorageClass，資料控制器會使用 Kubernetes 預設 StorageClass，視您的 Kubernetes 實例或提供者而有所不同。

當您卸載 Azure Arc 資料控制器時，會刪除與其相關聯的所有永續性磁片區。 封存任何已啟用 Azure Arc 的資料服務控制平面層級記錄，您的組織必須先儲存才能卸載資料控制站。

已啟用 Azure Arc 的 SQL 受控執行個體

已啟用 Arc 的SQL 受管理執行個體會根據商務需求提供兩個不同的層級：常規用途和業務關鍵。 對於這兩層，請務必檢閱已啟用 Arc 的最小和最大SQL 受管理執行個體限制，這些限制是可設定的，並確保已部署的 Kubernetes 叢集具有適當的計算和記憶體容量。

在具有指定資料庫實例上多個資料庫的案例中，所有資料庫都會使用相同的 StorageClass、PVC 和 PV 為已啟用 Arc 的SQL 受管理執行個體指定。 在單一 Kubernetes 叢集中，可以有多個已啟用 Arc 的實例SQL 受管理執行個體。 此設定允許獨立的永續性磁片區，並可藉由將資料庫部署至已啟用 Arc 之不同實例SQL 受管理執行個體，協助將 IO 爭用與不同的資料庫分開。

下表描述每個已啟用 Arc 的 SQL 受管理執行個體 Pod 及其用途所使用的不同永續性磁片區。

永續性磁片區 描述 儲存類別需求
資料 SQL Database資料檔案 (.mdf 檔案) 相依于階層
DataLogs (.ldf 檔案) SQL Database記錄檔 相依于階層
記錄 SQL 代理程式， 錯誤記錄， 追蹤檔案， 健康情況記錄 相依于階層
備份 SQL Server備份檔案，包括完整、差異、交易記錄 Remote、ReadWriteMany 存取模式

一般用途服務層級

已啟用 Arc 的SQL 受管理執行個體常規用途層必須使用資料庫實例的遠端儲存體，如此一來，在 Pod 失敗時，新建立的 Pod 仍可使用資料。 容錯移轉是由 Kubernetes Pod 和節點協調流程所管理。 相較于使用SQL 可用性群組和多個已啟用 Arc 的複本 SQL 受管理執行個體業務關鍵，此設定較不復雜。 常規用途層的單一 Pod 組態表示您可以最小化儲存體數量，因為您不需要複製其他複本的儲存體容量。

顯示已啟用 Arc SQL 受管理執行個體 常規用途儲存體的螢幕擷取畫面。

業務關鍵服務層級

業務關鍵層會使用多個 Pod 模型，其中資料和記錄磁片區可以儲存在本機或遠端儲存類別上。 本機儲存體類別通常會在延遲和輸送量方面表現得更好，因為儲存體裝置會直接連結至節點。 相較于本機儲存體，遠端儲存體通常會提供內建備援，但通常會有較低的延遲和輸送量。 請記住，使用更多業務關鍵資料庫複本需要額外的資料、記錄和資料記錄的永續性磁片區。 所需的儲存體容量總計較高。

下圖顯示具有兩個複本之Arc-Enabled SQL 受管理執行個體業務關鍵儲存體組態。

顯示已啟用 Arc SQL 受管理執行個體 業務關鍵儲存體的螢幕擷取畫面。

業務關鍵可讓您設定兩個或三個次要複本。 容錯移轉是由SQL Always On可用性群組所管理，可提供比常規用途層更少的升級和失敗停機時間。

使用同步認可模式資料複寫來設定多個複本，可確保更能防範失敗，例如失敗的 Pod、節點或儲存體硬體。 它可防止失敗，因為複本上有多個資料複本。 請考慮將次要複本設定為讀取向外延展實例，用戶端在使用次要接聽程式端點時可以連線到這些實例。

Azure Arc SQL 受管理執行個體布建和卸載

布建已啟用 Arc 的SQL 受管理執行個體時，您可以彈性地將不同的儲存類別指派給每個已啟用 Arc 的SQL 受管理執行個體永續性磁片區。 您可能想要 資料與DataLogs的效能較高儲存選項，但 記錄 和 備份 磁片區可能會使用更有成本效益的 StorageClass 選項來節省成本。 在使用本機儲存體的情況下，請確定磁片區能夠登陸不同的節點和實體儲存裝置，以避免磁片 I/O 發生爭用。 將 Data 和 DataLogs 放在相同的實體磁片磁碟機上可能會導致該儲存磁片磁碟機的競爭，因而造成效能不佳。 相反地，請考慮將 Data 和 DataLogs 放在不同的儲存磁片磁碟機上，以平行處理資料庫資料和記錄的 I/O。

當您刪除已啟用 Arc 的SQL 受管理執行個體時，不會移除其相關聯的 PC 和 PVC。 此行為可確保您可以存取資料庫檔案，以防意外刪除。

設計建議

以下是儲存體設計和設定的建議。

生產工作負載的儲存體類別

針對特定公用雲端，下表顯示生產工作負載的建議儲存體類別。

提供者 已驗證和建議的儲存體
Azure Kubernetes Service (AKS) Azure 受控磁碟 (進階層)
Amazon Elastic Kubernetes Service (EKS) EBS CSI 儲存體驅動程式
Google (GKE) GCE 永續性磁片

在內部部署或多重雲端案例中選擇生產儲存體Class 時，請確定其能夠符合您預期的儲存體容量、IOPS、備援和輸送量需求。 下列各節提供這些案例的更多建議。

資料控制器設計

選擇遠端共用的 StorageClass 以確保資料持久性。 在移除 Pod 或節點時，您可以讓 Pod 備份並再次連線到永續性磁片區。 底線 StorageClass 必須提供備援和高可用性。

當您建立已啟用 Arc 的資料服務資料控制器時，建議您使用自訂部署範本。 自訂範本可讓您微調儲存體類別、資料與記錄的儲存體大小、安全性和 Kubernetes 服務類型。 您可以針對您的環境和企業需求自訂它們。 Azure Arc 資料控制器總共需要八個永續性磁片區。 預設的最小組態允許 15Gi 作為資料，而 10Gi 則允許 PV 上的記錄。 設定容量，不僅符合最低建議，也支援在叢集中執行許多已啟用 Arc 的實作SQL 受管理執行個體成長。 此設定可防止未來調整 PVC 的大小。

建議您在叢集有多個資料庫和已啟用 Arc 的部署SQL 受管理執行個體部署時，選擇較低的延遲 StorageClass。 較低的延遲可改善 Grafana 和 Kibana 介面中的使用者體驗。

已啟用 Azure Arc 的SQL 受管理執行個體移轉

建議您針對已啟用 Arc 的移轉和部署SQL 受管理執行個體所涉及的所有新和現有資料庫進行規劃和考慮。 規劃可防止稍後在實例之間移動資料庫。

根據您的 Kubernetes 叢集組織，根據 (非生產、生產) 、區域和其他商務因素的需求，將已啟用 Arc 的SQL 受管理執行個體部署布建至不同的 Kubernetes 叢集。 如需更多建議，請檢閱 資源組織 設計區域。 在叢集上設定多個資料庫實例時，請務必將忙碌的資料庫分成自己的實例，以避免 I/O 爭用。

使用節點標籤來確保資料庫實例放在不同的節點上，以將整體 I/O 流量分散到多個節點，請參閱 Kubernetes 節點標籤 以及 Kubernetes 節點親和性和反親和性標籤 ，以設定標籤。 如果在虛擬化環境中運作，請確定 I/O 會適當地分散在實體主機層級。

規劃已啟用 Arc 的容量SQL 受管理執行個體，以包含資料、記錄、DataLogs和備份的適當儲存體大小。 當您規劃容量以容納目前的需求和預測成長，這些資料庫將會存在於已啟用 Arc 的實例SQL 受管理執行個體上時，它可防止未來調整 PVC 的大小。 為 Data 和 DataLogs 選擇個別的實體磁片磁碟機，以允許平行 I/O 活動發生。 平行 I/O 活動可避免使用共用磁片磁碟機時所造成的可能爭用，以改善效能。

雖然有幾個因素可能會指定部署已啟用 Arc 的業務關鍵或常規用途層SQL 受管理執行個體，但使用本機儲存體業務關鍵可提供最低的延遲和高可用性。 檢閱已啟用 Arc 的SQL 受管理執行個體商務持續性設計區域，以取得有關時間點還原、高可用性和災害復原的建議。 此外，請檢閱已啟用 Arc 的SQL 受管理執行個體成本治理設計區域，以深入瞭解階層之間的成本影響。

下列小節會為每個層提供更具體的建議：

常規用途服務層級建議

建議您為 資料和DataLogs 永續性磁片區選擇低延遲遠端 StorageClass，以獲得最佳效能。 避免使用引進網路分割區的 StorageClass，例如將內部部署叢集設定為使用 備份 和 記錄 持續性磁片區的網際網路提供的 StorageClass。

業務關鍵服務層級建議

建議您檢閱 可用性模式差異，這需要每個所選模式的不同設定。

針對最低可能的延遲需求案例，如果是 Kubernetes 基礎結構的選項，請選擇本機儲存體。 本機儲存磁片區應該落在不同的基礎儲存裝置上，以避免磁片 I/O 發生爭用，並將效能最大化。 儲存裝置不應該有多個功能，例如裝載作業系統磁碟分割。

如需大量讀取工作負載和高可用性，請設定多個複本，並將您的應用程式或用戶端設定為使用次要複本作為讀取Scale-Out實例。 次要複本預設無法讀取;您可以設定設定。

監視

建議您監視已啟用 Arc 的資料服務所建立的所有 PVC，包括 Azure Arc 資料控制器，以及叢集中已啟用 Arc 的所有SQL 受管理執行個體實例。 設定警示，以在PV 接近容量時通知您。 通知可讓您在達到容量之前調整PV 的大小。 針對直接連線的叢集，Azure 監視器和容器深入解析會監視 PVC 和警示。 當您使用間接連線叢集時，請在 Grafana 和 Kibana 中執行監視和警示。 Grafana 安裝包含已啟用 Arc 的儀表板SQL 受管理執行個體計量和 Kubernetes 資源。

如需監視已啟用 Arc SQL 受管理執行個體的詳細資訊，請檢閱已啟用Arc 的SQL 受管理執行個體治理專業領域。

下一步

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