甲骨文松口 支持在VMware上運(yùn)行RAC
甲骨文在其支持策略上不再明確地排除Real Application Cluster（RAC）產(chǎn)品能用于VMware服務(wù)器虛擬化。
這是邁向正確方向的一大步，IT人士表示。但是，將RAC帶入甲骨文現(xiàn)有的用于甲骨文數(shù)據(jù)庫的VMware支持策略時，就停滯不前了，意味著甲骨文仍然不能預(yù)知用戶選擇何種服務(wù)器虛擬化平臺。該支持策略包括：
甲骨文的任何產(chǎn)品都不在VMware虛擬化環(huán)境中進(jìn)行驗(yàn)證。甲骨文支持團(tuán)隊(duì)將幫助客戶以下面方式在VMware上運(yùn)行甲骨文產(chǎn)品：甲骨文只對在自身操作系統(tǒng)已知的或發(fā)生的問題，或者能證明不是由于運(yùn)行VMware才出現(xiàn)問題的時候，才進(jìn)行支持。
RAC不再是個特別的例外，這個事實(shí)至少表明甲骨文不再那么敵視VMware。但支持策略不是用戶決定是否虛擬和如何虛擬甲骨文的首要因素。
甲骨文虛擬化的障礙
不管甲骨文對待VMware的方式如何，用戶在獨(dú)立的Oracle VM平臺或者VMware運(yùn)行甲骨文應(yīng)用有著自己的想法。而且，在評估是否虛擬化甲骨文應(yīng)用和數(shù)據(jù)庫時，hypervisor平臺的選擇只是用戶必須考慮的因素之一。
一些用戶已經(jīng)證實(shí)VMware的產(chǎn)品存在局限，所以他們避免虛擬化Oracle的RAC，而不是因?yàn)榧坠俏牡闹С植呗浴?/p>
VMware對于附屬在Raw Device Mapping（RDM）模式里的RAC集群共享SCSI總線的虛擬機(jī)不提供vMotion支持。因此，如果一臺物理RAC服務(wù)器是處于維護(hù)模式，用戶只能關(guān)掉Oracle虛擬機(jī)，才能將它們移動到另一臺RAC集群節(jié)點(diǎn)，這在業(yè)務(wù)關(guān)鍵環(huán)境中違反了生產(chǎn)服務(wù)器級別協(xié)議。
另一些人指出，這也存在一些許可條例，在vSphere上運(yùn)行Oracle之前需要考慮到，不管是支持還是技術(shù)問題。
例如Oracle Enterprise Edition版本仍然有個預(yù)配置處理器許可機(jī)制，盡管通常的策略是軟件廠商實(shí)行的是預(yù)插槽或者預(yù)虛擬CPU許可策略來適應(yīng)虛擬化。
不過，對于來自Sun或Oracle VM的硬分區(qū)有個例外，但是VMware不是硬分區(qū)，所以你得將與虛擬機(jī)相關(guān)的所有組件都進(jìn)行許可。你可以限制虛擬機(jī)宿主的地點(diǎn)，但某些情況下這會讓虛擬化失去意義。
然而，RAC支持策略的更改是“邁向正確方向的一大步，”Reiter說，“支持協(xié)議的更改將改變我們的計(jì)劃，現(xiàn)在，如果一個客戶來找我們，并想在我們的云環(huán)境中運(yùn)行RAC，我們就能如他們所愿了。”他說，“雖然最終我比較希望看到一個許可模式能夠與虛擬化技術(shù)協(xié)調(diào)工作。”
#p#
削減甲骨文成本
一些用戶在避免復(fù)雜性，對虛擬化第一層應(yīng)用（如數(shù)據(jù)庫）作出了很大努力，而不理會虛擬化平臺。同時，他們開始審查甲骨文環(huán)境中的其他可虛擬化組件。
Chris Rima就是這樣的一位用戶，在基于Sun SPARC的硬件上運(yùn)行Oracle應(yīng)用，這意味著他可能會使用甲骨文的全套產(chǎn)品，缺失的組件是Oracle VM。
Rima說他的虛擬化旅程進(jìn)行得小心翼翼，尤其是在明年虛擬化甲骨文的中間件和管理軟件層時，但是可能會使用vSphere來進(jìn)行嘗試，他組織中的其他一些應(yīng)用已經(jīng)在使用vSphere。
對于Rima來說，通過在Sun的專有SPARC處理器上只運(yùn)行該軟件最關(guān)鍵的分區(qū)，并將其他分區(qū)盡量移到一般的x86硬件上去，使用vSphere虛擬甲骨文應(yīng)用的決定意味著削減硬件和運(yùn)營成本。
“我們關(guān)于甲骨文數(shù)據(jù)庫的核心經(jīng)驗(yàn)在SPARC上，”Rima說，“對于一些沒有數(shù)據(jù)庫重要的非關(guān)鍵應(yīng)用，我們就使用x86硬件來節(jié)約成本……并且我們內(nèi)部也沒有專門的工程師來支持兩種hypervisor環(huán)境。”
【編輯推薦】
