適用於:SQL Server 2019 (15.x)
Important
MICROSOFT SQL Server 2019 巨量數據叢集已淘汰。 SQL Server 2019 巨量數據叢集的支援已於 2025 年 2 月 28 日結束。 如需詳細資訊,請參閱 Microsoft SQL Server 平臺上的公告部落格文章和巨量數據選項。
永續性磁碟區 提供 Kubernetes 中儲存的外掛架構。 在此模型中,儲存方式與取用方式是分離的。 因此,您可以將自己的高可用性記憶體插入 SQL Server 巨量資料叢集中。 雖然 Kubernetes 支援 各種記憶體解決方案,包括 Azure 磁碟和檔案、網路檔案系統(NFS)和本機記憶體,但巨量數據叢集僅支持測試的組態。 如需支援組態的詳細資訊,請參閱 SQL Server 2019 巨量數據叢集平臺版本資訊。
Important
如果您要使用其中一個受控 Kubernetes 服務 (AKS 或 ARO) 在 Azure 中部署巨量數據叢集,請記住,視您的應用程式工作負載需求而定,您可能需要容納一些限制。 例如,使用 Azure 受控磁碟的磁碟區目前不是區域備援資源。 磁碟區無法跨區域連結,而且必須與裝載目標 Pod 的指定節點位於相同的區域中。 在此特定案例中,您可能想要使用 SQL Server 巨量數據叢集提供的其他高可用性解決方案。 如需 Azure Kubernetes 服務和可用性區域的詳細資訊,請參閱 這裡 。
配置持久性磁碟區
SQL Server 巨量數據叢集會使用 記憶體類別來取用這些永續性磁碟區。 您可以為不同類型的記憶體建立不同的記憶體類別,並在巨量數據叢集部署時指定它們。 您可以設定儲存類別和永久性磁碟區宣告大小,以便在集區層級用於特定用途。 SQL Server 巨量數據叢集會針對需要永續性磁碟區的每個元件,使用指定的記憶體類別名稱來建立永續性磁碟區 宣告 。 然後,它會在Pod中掛接對應的永續性磁碟區(或磁碟區)。
以下是規劃巨量數據叢集記憶體組態時要考慮的一些重要層面:
若要成功部署巨量數據叢集,請確定您有可用的永續性磁碟區數目。 如果您要在 Azure Kubernetes Service (AKS) 叢集上部署,而且您使用的是內建的記憶體類別 (
default或managed-premium),則此類別支援永續性磁碟區的動態布建。 因此,您不需要預先建立永續性磁碟區,但您必須確定 AKS 叢集中可用的背景工作節點可以連結與部署所需的永續性磁碟區數目一樣多。 根據針對工作節點指定的 VM 大小,每個節點都可以掛載特定數目的磁碟。 針對預設大小叢集(沒有高可用性),至少需要 24 個磁碟。 如果您要啟用高可用性或擴展任何資源池,請確定每一個額外復本至少有兩個持久性磁碟區,不論您要擴展的資源為何。如果您在設定中提供的記憶體類別記憶體布建器不支援動態布建,則必須預先建立保存的磁碟區。 例如,配置器
local-storage不支援啟用動態配置。 如需如何在以 部署的 Kubernetes 叢集中繼續進行的指引,請參閱此kubeadm。當您部署巨量資料叢集時,您可以設定相同的記憶體類別,以供叢集中的所有元件使用。 但作為生產部署的最佳做法,各種元件將需要不同的記憶體設定,以容納各種工作負載的大小或輸送量。 您可以針對每個 SQL Server 主要實例、數據集和存放集區,覆寫控制器中指定的預設記憶體組態。 本文提供如何執行這項作的範例。
計算存放集區大小調整需求時,您必須考慮 HDFS 設定的復寫因素。 在叢集部署組態檔中的部署時間可設定複寫因數。 開發測試配置檔的預設值為
aks-dev-testkubeadm-dev-test2,而針對我們建議用於生產部署的配置檔,kubeadm-prod預設值為 3。 最佳做法是,建議您使用至少 3 個 HDFS 的復寫因數來設定巨量數據叢集的生產部署。 復寫因數的值會影響存放集區中的實例數目:您至少必須部署與複寫因數的值一樣多的存放集區實例。 此外,您必須據以調整儲存空間大小,並考慮 HDFS 中數據的復寫次數,這個次數等於復寫因數的值。 您可以 在這裡找到更多關於 HDFS 中的數據複寫。自 SQL Server 2019 CU1 版本起,BDC 不會啟用更新部署後記憶體組態設定的體驗。 此限制阻止您使用 BDC 作業來修改每個實例的永續性磁碟區宣告大小,或在部署後調整任何集區的規模。 因此,在部署巨量數據叢集之前,規劃記憶體配置非常重要。 不過,您可以直接使用 Kubernetes API 擴充永續性磁碟區大小。 在此情況下,BDC 元數據將不會更新,而且您會在設定叢集元數據中看到磁碟區大小不一致的情況。
藉由將 Kubernetes 部署為容器化應用程式,以及使用具狀態集和永續性記憶體等功能,Kubernetes 可確保 Pod 在發生健康情況問題時重新啟動,並附加至相同的永續性記憶體。 但是,如果節點失敗,而且必須在另一個節點上重新啟動Pod,如果記憶體是失敗節點的本機,就會增加無法使用的風險。 若要降低此風險,您必須設定額外的備援並啟用 高可用性功能 ,或使用遠端備援記憶體。 以下是巨量數據叢集中各種元件的記憶體選項概觀:
| Resources | 數據的儲存類型 | 記錄的記憶體類型 | Notes |
|---|---|---|---|
| SQL Server 主要實例 | 本地(replicas>=3)或遠端冗餘存儲(replica=1) | Local storage | 具狀態集型實作,堅持節點的 Pod 可確保重新啟動,且暫時性失敗不會造成數據遺失。 |
| Compute pool | Local storage | Local storage | 未儲存任何用戶數據。 |
| Data pool | 本機/遠端備援記憶體 | Local storage | 如果無法從其他數據源重建數據集區,請使用遠端備援記憶體。 |
| 存放集區 (HDFS) | 本機/遠端備援記憶體 | Local storage | 已啟用 HDFS 複寫。 |
| Spark 池 | Local storage | Local storage | 未儲存任何用戶數據。 |
| 控制(controldb, metricsdb, logsdb) | 遠端備援記憶體 | Local storage | 對於巨量數據叢集元數據使用記憶體層級備援至關重要。 |
Important
請確定控制相關元件位於遠端備援記憶體裝置上。
controldb-0 Pod 裝載 SQL Server 實例,其中包含儲存與叢集服務狀態、各種設定和其他相關信息相關的所有元數據的資料庫。 如果此實例變得無法使用,將會導致叢集中其他相依服務的健康問題。
設定巨量數據叢集記憶體設定
與其他設定一樣,您可以在部署時於集區的bdc.json組態檔中以及控制服務的control.json檔案中指定叢集儲存設定。 如果集區規格中沒有任何記憶體組態設定,則控制記憶體設定將用於所有其他元件,包括 SQL Server master(master 資源)、HDFS(storage-0 資源)和數據集區元件。 下列程式代碼範例代表您可以包含在規格中的記憶體組態區段:
"storage":
{
"data": {
"className": "default",
"accessMode": "ReadWriteOnce",
"size": "15Gi"
},
"logs": {
"className": "default",
"accessMode": "ReadWriteOnce",
"size": "10Gi"
}
巨量數據叢集的部署會使用永續性記憶體來儲存各種元件的數據、元數據和記錄。 您可以自訂在部署過程中建立的永續性磁碟區宣告的大小。 作為最佳實踐,我們建議您使用具有保留回收原則的儲存類別。
Warning
在沒有持續性記憶體的情況下執行可在測試環境中運作,但可能會導致非功能性叢集。 當 Pod 重新啟動時,叢集元數據和/或用戶數據會永久遺失。 我們不建議您在此設定下執行。
設定 記憶體 一節提供更多範例,說明如何設定 SQL Server 巨量數據叢集部署的記憶體設定。
AKS 記憶體類別
AKS 隨附 兩個內建儲存類別,default 以及 managed-premium,並配有供這些儲存類別使用的動態布建工具。 您可以指定其中一項,或建立自己的記憶體類別,以部署已啟用永續性記憶體的巨量數據叢集。 根據預設,AKS aks-dev-test的內建叢集組態檔隨附持續性記憶體組態,以使用 default 記憶體類別。
Warning
使用內建存儲類別 default 和 managed-premium 所建立的永續性磁碟區,具有「刪除」的回收原則。 因此,當您刪除 SQL Server 巨量數據叢集時,持久性磁碟區宣告和持久性磁碟區都會被刪除。 您可以使用布建 azure-disk 工具搭配 Retain 回收原則來建立自定義記憶體類別,如 概念記憶體中所述。
叢集的 kubeadm 記憶體類別
使用 kubeadm 所部署的 Kubernetes 叢集沒有內建的記憶體類別。 您必須使用本機記憶體或 慣用的記憶體布建器,建立自己的記憶體類別和永續性磁碟區。 在此情況下,您會設定 className 為您所設定的記憶體類別。
Important
在 kubeadm (kubeadm-dev-test 和 kubeadm-prod) 的內建部署組態檔中,沒有針對數據和記錄記憶體指定的記憶體類別名稱。 部署之前,您必須自訂組態檔,並設定 className 的值。 否則,預先部署驗證將會失敗。 部署也有驗證步驟,可檢查記憶體類別是否存在,但不會檢查必要的永續性磁碟區。 請確定您根據叢集的規模建立足夠的磁碟區。 針對預設的最小叢集大小(預設規模,沒有高可用性),您必須建立至少 24 個永續性磁碟區。 如需如何使用本機布建器建立永續性磁碟區的範例,請參閱 使用 Kubeadm 建立 Kubernetes 叢集。
自訂每個集區的記憶體組態
針對所有自定義專案,您必須先建立您想要使用的內建組態檔複本。 例如,下列命令會在名為 aks-dev-test的子目錄中建立部署組態檔的custom複本:
azdata bdc config init --source aks-dev-test --target custom
此過程會建立兩個檔案,bdc.json 和 control.json,您可以手動編輯這些檔案或使用 azdata bdc config 命令來自訂義它們。 您可以使用 jsonpath 和 jsonpatch 連結庫的組合,提供編輯組態檔的方式。
配置儲存類別名稱與/或請求大小
根據預設,為叢集中每個 Pod 配置的持久性磁碟區的大小為 10GB。 您可以更新此值,以容納您在叢集部署之前在自定義組態檔中執行的工作負載。
在下列範例中,control.json中的永續性磁碟區宣告的大小會更新為 32 GB。 如果未在集區層級更改,此設定將會套用至所有集區。
azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.size=100Gi"
下列範例示範如何修改檔案的 control.json 儲存類別:
azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.className=<yourStorageClassName>"
您也可以選擇手動編輯自訂組態檔,或使用變更記憶體集區儲存類別的 .json 修補程式,如下列範例所示:
{
"patch": [
{
"op": "replace",
"path": "$.spec.resources.storage-0.spec",
"value": {
"type":"Storage",
"replicas":2,
"storage":{
"data":{
"size": "100Gi",
"className": "myStorageClass",
"accessMode":"ReadWriteOnce"
},
"logs":{
"size":"32Gi",
"className":"myStorageClass",
"accessMode":"ReadWriteOnce"
}
}
}
}
]
}
套用修補程式檔案。 使用 azdata bdc config patch 命令來套用 .json 修補程式檔案中的變更。 下列範例會將patch.json檔案套用至目標部署組態檔: custom.json
azdata bdc config patch --config-file custom/bdc.json --patch-file ./patch.json
Next steps
如需 Kubernetes 中磁碟區的完整檔,請參閱 有關磁碟區的 Kubernetes 檔。
如需部署 SQL Server 巨量數據叢集的詳細資訊,請參閱 如何在 Kubernetes 上部署 SQL Server 巨量數據叢集。