Hyper-V
ONTAP QoS 的 Oracle 資料庫效能管理
建議變更
PDF
安全有效地管理多個 Oracle 資料庫、需要有效的 QoS 策略。原因在於現代儲存系統的效能功能不斷提升。
具體而言、由於採用 All Flash 儲存設備的情況增加、因此能夠整合工作負載。依賴旋轉媒體的儲存陣列往往只支援有限數量的 I/O 密集工作負載、因為舊版旋轉式磁碟機技術的 IOPS 功能有限。一或兩個高作用中的資料庫會在儲存控制器達到限制之前、使基礎磁碟機飽和。這種情況已經改變。即使是功能最強大的儲存控制器、相對少數 SSD 磁碟機的效能也能達到飽和。這意味著控制器的完整功能可以充分發揮、而不會因為旋轉媒體延遲尖峰而突然降低效能。
舉例來說、簡單的雙節點 HA AFF A800 系統能夠在延遲超過 1 毫秒之前、提供高達 100 萬次的隨機 IOPS 服務。只有很少單一工作負載會達到這類層級。充分利用此 AFF A800 系統陣列、將需要託管多個工作負載、同時確保可預測性、這需要 QoS 控制。
ONTAP 中有兩種服務品質（ QoS ）： IOPS 和頻寬。QoS 控制可套用至 SVM 、磁碟區、 LUN 和檔案。
IOPS QoS
IOPS QoS 控制顯然是以指定資源的 IOPS 總計為基礎、但 IOPS QoS 的許多層面可能並不符合直覺。剛開始有幾位客戶對於達到 IOPS 臨界值時、延遲明顯增加感到困惑。延遲增加是限制 IOPS 的自然結果。從邏輯上講、它的運作方式與權杖系統類似。例如、如果包含資料檔案的特定磁碟區有 10K IOPS 限制、則每個到達的 I/O 都必須先接收權杖才能繼續處理。只要在指定的秒數內使用的權杖不超過 10K 、就不會有延遲。如果 IO 作業必須等待接收其權杖、則此等待會顯示為額外延遲。工作負載相對於 QoS 限制的推動越大、每個 IO 在佇列中等待處理的時間就越長、使用者認為延遲越高。
|
將 QoS 控制套用至資料庫交易 / 重做記錄資料時、請務必謹慎。雖然重做記錄的效能需求通常比資料檔案低很多、但重做記錄活動卻很繁瑣。IO 會以簡短的脈衝形式發生、而顯示適合平均重做 IO 層級的 QoS 限制、對於實際需求而言可能太低。結果可能會造成嚴重的效能限制、因為每次重做記錄突增時、 QoS 都會啟動。一般而言、重作和歸檔記錄不應受到 QoS 的限制。 |
頻寬 QoS
並非所有 I/O 大小都相同。例如、資料庫可能會執行大量的小區塊讀取、導致達到 IOPS 臨界值、 但資料庫也可能執行完整的資料表掃描作業、這項作業會由極少數的大量區塊讀取所組成、佔用大量頻寬、但 IOPS 相對較少。
同樣地、 VMware 環境在開機期間可能會產生極高的隨機 IOPS 、但在外部備份期間執行的 IO 會較少、但會較大。
有時有效管理效能需要 IOPS 或頻寬 QoS 限制、甚至兩者都需要。
最低 / 保證的 QoS
許多客戶尋求的解決方案都包含保證的 QoS 、這比看起來更難達成、而且可能相當浪費。例如、如果要放置 10 個具有 10K IOPS 保證的資料庫、就必須針對所有 10 個資料庫同時以 10K IOPS 執行的情況來調整系統規模、總共需要 10 萬個。
最適合用於最低 QoS 控制的是保護關鍵工作負載。例如、假設 ONTAP 控制器的 IOPS 最高可達 50 萬、同時混合了生產與開發工作負載。您應該將 QoS 原則上限套用至開發工作負載、以防止任何指定的資料庫壟斷控制器。然後、您可以將最低 QoS 原則套用至正式作業工作負載、以確保它們在需要時隨時都能使用所需的 IOPS 。
調適性QoS
調適性 QoS 是指 ONTAP 功能、其中 QoS 限制是根據儲存物件的容量而定。它很少用於資料庫、因為資料庫的大小與其效能需求之間通常沒有任何連結。大型資料庫可能幾乎無法運作、而較小的資料庫則可能是 IOPS 最密集的資料庫。
Adaptive QoS 對於虛擬化資料存放區非常有用、因為這類資料集的 IOPS 需求往往與資料庫的總大小相關。較新的資料存放區包含 1TB 的 VMDK 檔案、可能需要的效能約為 2TB 資料存放區的一半。Adaptive QoS 可讓您在資料存放區填入資料時、自動增加 QoS 限制。