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