Skip to main content
Enterprise applications
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

虛擬化

貢獻者
PDF

使用 VMware 、 Oracle OLVM 或 KVM 來虛擬化資料庫、對於選擇虛擬化技術的 NetApp 客戶而言、這是越來越常見的選擇、即使是他們最關鍵的關鍵任務資料庫也一樣。

支援能力

對於 Oracle 虛擬化支援政策、尤其是 VMware 產品、存在許多誤解。聽說 Oracle 完全不支援虛擬化並不罕見。這個概念不正確、導致錯失從虛擬化中獲益的機會。Oracle Doc ID 249212.1 討論實際需求、客戶很少會將此視為疑慮。

如果虛擬化伺服器發生問題、而 Oracle Support 先前不知道該問題、可能會要求客戶在實體硬體上重現問題。執行產品尖端版本的 Oracle 客戶可能不想使用虛擬化技術、因為可能會發生支援問題、但這種情況對於虛擬化客戶而言、並不是一個真正的世界、因為他們使用的是 Oracle 產品版本。

儲存簡報

考慮將資料庫虛擬化的客戶應根據其業務需求做出儲存決策。雖然這是所有 IT 決策的一般陳述、但資料庫專案尤其重要、因為需求的大小和範圍差異極大。

儲存簡報有三個基本選項：

  • Hypervisor 資料存放區上的虛擬化 LUN

  • iSCSI LUN 由虛擬機器上的 iSCSI 啟動器管理、而非 Hypervisor

  • 由虛擬機器掛載的 NFS 檔案系統（非從 NFS 型資料存放區）

  • 直接裝置對應。客戶不喜歡 VMware RDM 、但實體裝置通常與 KVM 和 OLVM 虛擬化類似。

效能

將儲存設備呈現給虛擬化來賓作業系統的方法通常不會影響效能。主機作業系統、虛擬化網路驅動程式和 Hypervisor 資料存放區實作均經過高度最佳化、只要遵循基本最佳實務做法、通常都能在 Hypervisor 和儲存系統之間使用所有可用的 FC 或 IP 網路頻寬。在某些情況下、使用一種儲存呈現方法比使用另一種方法來獲得最佳效能可能會稍微容易一些、但最終結果應該是可比較的。

管理能力

決定如何將儲存設備呈現給虛擬化來賓作業系統的關鍵因素是可管理性。沒有正確或錯誤的方法。最佳方法取決於 IT 營運需求、技能和偏好。

考量因素包括：

  • * 透明度。 * VM 管理其檔案系統時、資料庫管理員或系統管理員更容易識別其資料的檔案系統來源。檔案系統和 LUN 的存取方式與實體伺服器的存取方式完全相同。

  • * 一致性。 * VM 擁有其檔案系統時、使用或不使用 Hypervisor 層會影響管理能力。資源配置、監控、資料保護等程序也可在整個資產中使用、包括虛擬化和非虛擬化環境。

    另一方面、在另一個 100% 虛擬化的資料中心中、最好還是在整個佔用空間中使用資料存放區型儲存設備、但前提是上述相同的理由（一致性）、也就是能夠使用相同的程序來進行資源配置、保護、監控和資料保護。

  • * 穩定性與疑難排解。 * VM 擁有其檔案系統時、由於整個儲存堆疊都存在於 VM 上、因此提供良好、穩定的效能與疑難排解問題變得更簡單。Hypervisor 唯一的角色是傳輸 FC 或 IP 框架。當資料存放區包含在組態中時、它會引入另一組逾時、參數、記錄檔和潛在錯誤、使組態複雜化。

  • * 可攜性。 * VM 擁有其檔案系統時、移動 Oracle 環境的程序會變得更簡單。檔案系統可在虛擬化與非虛擬化的來賓作業系統之間輕鬆移動。

  • * 廠商鎖定 * 將資料放入資料存放區後、使用不同的 Hypervisor 或將資料從虛擬化環境中移出、將變得非常困難。

  • * 啟用 Snapshot ： * 虛擬化環境中的傳統備份程序可能會因為頻寬相對有限而成為問題。例如、四埠 10GbE 主幹可能足以支援許多虛擬化資料庫的日常效能需求、但這類主幹可能不足以使用 RMAN 或其他需要串流完整資料複本的備份產品來執行備份。因此、日益整合的虛擬化環境需要透過儲存快照來執行備份。如此可避免僅為了支援備份時間內的頻寬和 CPU 需求而需要過度建置 Hypervisor 組態。

    使用來賓擁有的檔案系統有時會讓您更輕鬆地利用快照型備份和還原、因為需要保護的儲存物件可以更輕鬆地鎖定目標。然而、越來越多的虛擬化資料保護產品能夠與資料存放區和快照完美整合。在決定如何將儲存設備呈現給虛擬化主機之前、應充分考慮備份策略。

半虛擬化驅動程式

為了達到最佳效能、使用半虛擬化網路驅動程式至關重要。使用資料存放區時、需要半虛擬化 SCSI 驅動程式。半虛擬化的裝置驅動程式可讓來賓更深入地整合至 Hypervisor 、而非模擬的驅動程式、在該驅動程式中、 Hypervisor 會花費更多的 CPU 時間來模擬實體硬體的行為。

過度使用 RAM

過度使用 RAM 意味著在不同主機上設定的虛擬化 RAM 多於實體硬體上的虛擬化 RAM 。否則可能會造成非預期的效能問題。虛擬化資料庫時、 Oracle SGA 的基礎區塊不得由 Hypervisor 交換至儲存設備。這樣做會導致效能結果極不穩定。

資料存放區等量分割

在使用資料庫搭配資料存放區時、效能方面有一個關鍵因素需要考量、那就是分段。

VMFS 等資料存放區技術可以跨越多個 LUN 、但它們不是等量磁區的裝置。LUN 會串聯。最終結果可能是 LUN 熱點。例如、典型的 Oracle 資料庫可能有 8-LUN ASM 磁碟群組。所有 8 個虛擬化 LUN 均可在 8-LUN VMFS 資料存放區上進行佈建、但無法保證資料所在的 LUN 。產生的組態可能是全部 8 個虛擬化 LUN 、佔用 VMFS 資料存放區內的單一 LUN 。這會成為效能瓶頸。

通常需要分拆。有些 Hypervisor （包括 KVM ）可以使用 LVM 等量分拆來建置資料存放區、如前所述 "請按這裡"。有了 VMware 、架構看起來有點不同。每個虛擬化 LUN 都必須放置在不同的 VMFS 資料存放區上。

例如：

錯誤：缺少圖形影像

這種方法的主要驅動因素不是 ONTAP 、而是因為單一 VM 或 Hypervisor LUN 可平行處理的作業數量、有固有的限制。單一 ONTAP LUN 通常支援的 IOPS 遠高於主機所能要求的 IOPS 。單一 LUN 效能限制幾乎是主機作業系統的普遍結果。結果是大多數資料庫需要 4 到 8 個 LUN 才能滿足效能需求。

VMware 架構需要仔細規劃其架構、以確保此方法不會遇到資料存放區和 / 或 LUN 路徑最大化問題。此外、每個資料庫都不需要一組唯一的 VMFS 資料存放區。主要需求是確保每個主機都有一組乾淨的 4 到 8 個 IO 路徑、從虛擬化 LUN 到儲存系統本身的後端 LUN 。在極少數情況下、更多的資料存取器可能對真正極致的效能需求有所助益、但 4-8 個 LUN 通常足以滿足 95% 的資料庫需求。單一 ONTAP 磁碟區包含 8 個 LUN 、可透過典型的 OS/ONTAP/ 網路組態、支援多達 250,000 個隨機 Oracle 區塊 IOPS 。