虛擬化與高性能計算是天然的矛盾?
這是一個非常有趣的現象--新技術在誕生之初，往往會被人們視作包治百病的良藥。這似乎正應驗了那句老話："錘子在手，看什么都是釘子"。從某些方面看，我認為虛擬化技術已經成了一把錘子，人們正四處為其尋找釘子（或看上去像釘子的東西）。最近便有很多人認為，高性能計算（HPCC）或許是虛擬化錘子的又一顆釘子。
我本人對虛擬化技術并無批駁之意，因為它確實為專注企業級運算的數據中心節約了大量成本，從這個角度看，它完全稱得上是一項革命性新技術。
虛擬化技術之所以能在企業中發揮如此大的作用，原因之一在于目前企業對硬件的利用率不高（多數不超過50%）。而在高性能計算領域，硬件利用率往往會超過90%。
有趣的是，在高性能計算中，即使硬件利用率突破了90%，也經常會發生大量任務列隊等待合適資源的情況，計算需求仍然居高不下。資源管理器一般會以合理的方式安排工作，以便最充分地利用硬件資源，但某些情況下，可能沒有足夠的空閑資源來執行任務，這時管理器會一直保留該項任務，直到獲得執行這項任務的必要資源。最終，硬件利用率似乎無法達到100%（如90%左右），而實際計算需求卻遠遠高于100%。
因此，在高性能計算中利用虛擬化技術來整合未被充分利用的資源，進而提高計算效率的想法并不可行。一個簡單的事實是，幾乎所有高性能計算系統都要處在全負荷或已被過量預訂的狀態（如果您見過未被充分利用的高性能計算系統，請一定和我聯系，我認識一大批渴望計算縮短周期的人J），但這并不意味著虛擬化技術在高性能計算領域就毫無用處。
虛擬化技術在高性能計算領域的潛在應用
我認為，虛擬化技術具備改善高性能計算的潛力，這集中體現在以下三個方面：
首先，我們可以利用計算節點上的虛擬化硬件執行用戶選定的分配任務。聽上去似乎有些不可思議，但實際上，一個典型的集群中往往存在一組幾乎完全相同的計算節點。也就是說，它們在任何方面都不存在差別（包括硬件和軟件環境）。不過有些時候，您運行的應用可能是針對特定操作系統或內核，或是存在某種軟件依賴關系，計算節點上的資源無法滿足其需求。這時您會怎么做？
此時，人們往往會為此類應用創建單獨的集群，以滿足其特定的軟件需求。不過這樣做要付出相當高的代價。如果某家企業共部署了6項軟件需求各不相同的應用，那么他們是不是就得構建六個不同的集群？有沒有其它更好的辦法呢？
虛擬化技術對此的解決之道是利用虛擬機（VM）來運行相應軟件。在此情景中，那些節點會在計算節點上運行主機操作系統（相當于在計算節點上運行管理程序）。當用戶向資源管理器提交任務時，可以自行指定希望在任務中使用的操作系統或內核等組件。在任務執行過程中，資源管理器會通知計算節點運行所需的軟件，并將相應軟件安裝在虛擬機（VM）內。接下來，任務會在虛擬機上運行，處理完畢后，虛擬機被關閉，節點繼續執行下一任務。如果這個設想得以實現，您就能在單個節點上混合運行Linux和Windows應用，或是將其用于需要特定操作系統（不在集群內）的其它應用。但世界上沒有免費的午餐，這種美好的設想也不例外。
問題的關鍵是那些在虛擬機內運行、且需要訪問IO和網絡等硬件的應用。我們不妨假設一下，這些高性能計算應用很可能并行并在多個節點間運行（很可能使用MPI）。如果這些在虛擬機中運行的應用需要通過訪問高速網卡來發送消息，就必須首先向主機操作系統發出請求，然后由其代表虛擬機與網卡進行通信。這種以主機操作系統為中介的通信方式不僅會降低系統性能，還會極大地增加通信延遲。訪問節點內硬盤時也會遇到這種情況。據我所知，因使用高速網卡造成的性能損失應該在50%左右（即，在虛擬機中運行使用高速網卡的代碼時會出現50%的性能損失）。最近情況有所改善，下降幅度已降至30%。同時，很多公司表示，他們可以通過驅動程序來支持虛擬機直接訪問硬件。但截至目前，我還沒有看到此類驅動程序的任何性能指標評測（早在兩年前就有一家公司宣稱擁有了原生的性能驅動程序，但時至今日都沒有發布過任何性能指標評測）。因此，虛擬機訪問硬件方面的困難確實限制了這種設想的實現。
另一個有望改善高性能計算的虛擬化技術設想是，將某個節點中運行的進程"移動"到其它節點。在VMWare領域，這個設想需要靠Vmotion（在Xen和其它虛擬化工具中采用其它名稱）來實現。具體而言，就是將虛擬機從一組物理硬件移動至其它硬件環境，同時保持虛擬機的正常運行。很多人表示，如果發現任務中的某個節點即將出現故障，他們就愿意采用這種辦法。但實際上，我們似乎并不能輕易地在即將出現故障的節點上找到某項任務，并在該節點真正出現故障前將這些任務移走。但移動虛擬機的想法或許能在維護方面發揮一定作用。也就是安排一些專門用于維護的節點，然后在維護窗口打開時將虛擬機移動至這些節點執行維護任務。不過總的來說，在運行高性能計算任務時移動虛擬機的做法還是存在一些問題。
我們再假設，即高性能計算的處理對象多為基于MPI的代碼。其中一個問題是，MPI代碼應當與內核"捆綁"，以期實現最佳性能（人們總是希望得到更高的性能）。但在VMWare環境下，最好不要將進程捆綁到特定內核，因為目標節點與源節點之間可能并不匹配，這會導致進程無法移動。另外還有人指出，固定進程會限制虛擬機的移動。
也許更重要的是，當人們移動虛擬機時，必須中止網絡中所有的消息傳送（收發），并且同時中斷該虛擬機在移動過程中的一切IO流量。只有這樣才能移動虛擬機。此外，人們還必須將來自源節點的消息和IO流量移動到目標節點。這對虛擬機來講的確是個難題。最近的一次測試已成功地將某個執行本地IO操作的單個節點移動至其它節點。整個虛擬機移動過程共耗費了20多分鐘。但假設測試的任務須在多個節點間運行，同時還必須完成消息傳送，另外可能還得進行一些IO操作，在此情況下，移動虛擬機的復雜性可能遠遠超出想象。由此看來，移動虛擬機并非是高性能計算的首選。
最后一個設想是利用虛擬機來充當檢查點或重新啟動應用。長期以來，人們就一直設想在高性能計算中實現獨立于應用本身的檢查點/重新啟動功能。檢查點主要是指代碼進程的快照，用于捕獲節點的計算狀態。人們使用檢查點，是希望在節點出現故障以及應用無法工作時，從最近一個檢查點重新啟動應用。如果沒有檢查點，應用就只能從初始狀態重新啟動。
當應用在虛擬機（虛擬機只是一種軟件）上運行時，您就可以利用虛擬化技術輕松地創建檢查點。您只需少量的準備工作，就能創建出虛擬機狀態檢查點，并將其寫入存儲設備。不然您還是要面對同樣的問題，即在創建檢查點之前使虛擬機保持"安靜"。
最基本的問題是，如何在創建檢查點之前使系統處于"安靜"模式。這要求事先進行很多準備工作，包括停止處理器及其當前任務、終止所有的消息傳送和IO操作、清空所有緩沖區等等，然后將虛擬機狀態以文件形式轉儲至存儲設備。曾有幾家公司嘗試在集群中實施這一設想，但都以失敗告終。目前，又有一家公司開始進行這類嘗試。不過從根本上看，這是一個相當難解決的問題。
總結
從某種程度上講，虛擬化技術能夠有效減少服務器數量并提高剩余服務器的利用率，的確為企業的IT實施帶來了一場革命。 然而，人們錯誤地把它當成了萬靈丹，希望它可以應用于一切可能的IT領域（包括高性能計算在內）。在我看來，虛擬化技術或許可以通過以下三種途徑來影響高性能計算：
利用虛擬化技術選擇操作系統分配和/或其它軟件需求，并指定合適的計算節點來運行相應軟件。
利用虛擬化技術將進程從某個節點（源節點）移動至其它節點（目標節點）。
利用虛擬化技術輕松創建檢查點。
以上三種設想看似簡單，實際上卻很難在高性能計算中實現。第一種設想能夠提供任務所需的操作系統或分配資源，引起了很多人的興趣，但目前這樣做會造成性能損失；第二種設想是在節點間移動虛擬機，這在高性能計算中很難實現，因為許多應用都要大量用到網絡和/或存儲（IO）；而第三種設想，即利用虛擬機快速創建檢查點也存在相同的網絡和/或存儲依賴問題，因此很難應用于高性能計算中。
因此，從目前的情況來看，虛擬化技術尚無法在高性能計算領域占據一席之地。盡管我們并不能由此斷定未來情況不會發生變化，但目前虛擬化技術要進入高性能計算領域尚需時日。我很遺憾地說，高性能計算并不是虛擬化大錘所尋找的那顆釘子。
【編輯推薦】
