在集羣系統中，進程的到達時間和新到達進程所需的資源量都是不可預測的，因此進程的放置和遷移是非常重要的問題。由於集羣系統中的不可預測性，進程有時就 會被放置在不合適的機器上，進程遷移就給了系統一個彌補這樣的錯誤的機會。通過較好的算法將新創建的進程放置到合適的節點上執行，並且對某些進程進行遷移 可以縮短任務的平均執行時間，因此從整體上提高了系統的性能。
進程的放置問題是非常複雜的，因爲集羣中的資源是異構的，如：內存、CPU、進程間通訊等等。衡量這些資源耗費的方法也是不同的：內存的單位是字節，CPU的單位是循環、通訊資源的單位是帶寬。
進程的放置策略分爲靜態放置策略和動態放置策略。靜態放置策略通過預先定義的規則對新創建的進程進行分配，它不使用運行時的信息。而動態放置策略則根據系統狀態的變化將進程重新放置到最適宜的節點上。
常見的靜態放置策略由三種：Round Robin（RR）、Best-Fit(BF)、Round Robin Next-Fit (NF)。
Round Robin將新創建的進程以輪轉的形式放置到集羣中的各節點上。這種方法的缺陷在於如果新創建的進程所需的內存量大於將要分配到其上的節點的可用內存大小，則會導致算法的失敗。
一種改進的方法是使用Best-Fit方法，進程將被放置到具有最大可用內存的節點上。
Round Robin Next-fit以Round Robin的方式掃描各節點，並且將進程發送到第一個有足夠大內存的節點上。它的缺點就是可能會導致負載不均衡地分配到各個節點。
三種進程放置策略的性能如圖1-1所示。（進程的平均大小是16MB）
從該圖可以看出，NF算法能夠最充分地利用內存資源。當集羣中的節點數增加時，BF算法和RR的算法的性能也隨之有明顯的下降，之所以產生這種情況是因爲 當節點數增加時，集羣中的內存總量也隨之成比例地增加，而且新增加的節點也會創建新的進程，這也就意味着大進程的數量也會隨之增多，這些大進程對於BF算 法和RR算法而言是很難放置的，因此會導致它們的性能的下降。
一 種動態的進程放置策略叫做MS（Migrate the Smallest process），它以Round Robin的形式掃描所有的節點，並且將新進程放置到下一個節點上。與Round Robin不同的是，如果要放置的節點的內存不足以提供給新來的進程使用，則MS算法將遷移走一個進程。將要被遷移的進程是該節點上所有進程中最小的一個 但是遷移走它剛好能滿足新進程所需內存，而且也有其它的節點能夠容納這個將被遷移的節點，這種方法有較小的網絡開銷，如果不存在這樣的節點，如其它的所有 節點都沒有足夠大的內存空間，則算法失敗。MS算法和NF算法的比較如下圖所示。當進程的平均大小爲1M時，兩種算法都取得了將近100%的內存利用率， 但是如圖1-2所示當進程的平均大小爲16M時，MS 算法比NF 算法高了20多個百分點。
以上各種算法都是集中式的進程放置策略，都需要使用全局信息來決定放置策略，不利於可擴展性，不能有效地在擁有多個節點的集羣上執行。一種基於MS的分佈式進程放置算法(Windowed MS)是這樣實現的：它將遷移的進程放置到從信息窗口中選出的具有最大可用內存的節點上。所謂信息窗口指的是一個緩衝區，裏面保存着其它節點的可用內存的信息。每隔一定的時間就會將其它各節點的內存信息收集到信息窗口中，並對信息窗口進行更新。
 圖1-1
進程放置策略性能比較圖 |
 圖1-2
進程放置策略性能比較圖 |
  |
|
早在20世紀80年代，人們就開始了進程遷移的研究。大多數的研究主要着眼於如何用更好的方法在機器之間傳送進程的狀態。同構的進程遷移指的是進程遷移的 原始和目標機器的體系結構相同，而異構的進程遷移指的是不同體系結構的機器之間的進程遷移。同構的進程遷移系統的例子有：V Charllote 、DEMOS/MP、 Sprite、 Condor、 Accent ；異構的進程遷移系統有：Tui、Emerald、HMF(Heterogeneous Migration Facility )等。進程遷移主要用於以下幾種情況下。
- 當失效的機器修復了錯誤，重新進入集羣系統時，需要將某些該機器上原來運行的進程重新遷移回來。
- 在集羣系統中進行負載共享。爲了讓一個進程使用儘可能多的CPU時間，需要將它遷移到能提供大部分指令和I/O操作的機器上執行。但是有時候負載共享也有 缺陷，因爲大部分的進程只需一少部分的CPU時間，考慮到進程遷移的開銷，如果對那些簡單的可以在本地運行的進程進行遷移是得不償失的，但是對於那些需要 大量的處理時間的程序如仿真程序，遷移進程是非常有效的。
- 提高通訊性能。如果一個進程需要與其它進程頻繁地進行通訊，這時將這些進程放置得近一些就會減少通訊的開銷。具體的遷移方法就是將一個進程遷移到其它進程所在的CPU上。
- 可用性。當網絡上的某臺機器失效時，通過進程遷移可以將進程遷移到其它機器上繼續執行，這樣就保證了系統在遇到災難時的可用性。
- 重新配置。當對集羣進行管理時，有時需要將服務從一個節點移到另一個節點，透明的進程遷移可以在不停機的情況下遷移服務。
- 使用集羣中的某些機器的特殊能力。如果某個進程能夠從集羣中的某臺特定機器上受益，它就應該在那臺機器上執行。如進行數值計算的程序能夠通過使用數學協處理器或超級計算機中的多個處理器來大大縮短程序執行時間。
儘管進程遷移已經在實驗環境中成功地實現了，但是它還沒有被廣泛地接受。一個原因是佔主流的平臺如MSDOS、 Microsoft Windows以及許多種類的UNIX操作系統都沒有對進程遷移的支持。另一個原因是因爲進程遷移開銷可能比不遷移進程時的開銷還要大。但是當前，兩種新 的計算領域又促進了進程遷移的發展，一個是移動計算，另一個是廣域計算。移動計算指的是那些便攜式的小型計算機的計算問題。而廣域計算是指廣域網中的機器 的計算問題。
進程遷移將一個正在執行的進程從一個節點遷移到通過網絡連接的另一個節點上（也就是說，不使用本地共享內存機制）。進程所在的原始節點上的操作系統應該將進程的所有狀態都包裝起來，這樣目的機就可以繼續執行此進程。
要完成進程遷移需要遷移進程的狀態，尤其是進程的地址空間，對其它進程的訪問（如套接口、管道等），代碼（可以組成地址空間的一部分）以及執行狀態（寄存 器、堆棧等）。除了這些，還需要將那些對原始的進程所有訪問都重新鏈接到新的進程拷貝上，不然遷移就不是無縫的，就會導致錯誤。整個進程遷移操作必須是原 子操作，這樣才能避免進程的丟失或者是有兩個拷貝。
爲了進行進程遷移需要再進行以下的修改：
- 必須對文件系統進行一定的修改使每個機器看到相同的名字空間。
- 必須傳送足夠的狀態從而確保正常的核心調用能夠在遠端機器上正常執行。
- 一些特殊的核心繫統調用如gettimeofday 、getpgrp應該發回到原始節點執行。
下面通過一個異構進程遷移的例子來說明進程遷移的整個過程。圖1-3說明了進程是如何在Tui進程遷移系統中從一個機器上遷移到另一個機器上的。
- 首先是對一個程序進行編譯，針對Tui支持的四種體系結構，將程序分別編譯四次。
- 程序在原始機上以普通方式執行。（如命令行方式）
- 當選定一個遷移的進程時，migrout程序首先爲進程設置檢查點，然後掛起進程，然後進行內存映像，接着掃描全局變量、堆棧和堆來定位所有的數據。再把所有的這些都轉化爲一種中介的格式傳送給目標機。最後，殺死原始機器上的進程。
- 在目標機上，migrin程序取得中介值並創建新的進程，由於程序已經根據目標機的體系結構進行了編譯，因此正文段的信息和數據報的類型信息都是可用的。然後通過重新創建全局變量、堆和堆棧，程序從檢查點處繼續執行。
經過統計，選擇空閒主機並且開始一個新的進程需要0.1秒的時間，平均遷移時間是330毫秒。通過進程遷移可以將性能提高近5倍。
圖1-3 進程遷移過程示意圖
高可用性
計算機系統的可靠性用平均無故障時間（MTTF）來度量，即計算機系統平均能夠正常運行多長時間，才發生一次故障。系統的可靠性越高，平均無故障時間越 長。可維護性用平均維修時間（MTTR）來度量，即系統發生故障後維修和重新恢復正常運行平均花費的時間。系統的可維護性越好，平均維修時間越短。計算機 系統的可用性定義爲：MTTF/(MTTF+MTTR) * 100%。由此可見，計算機系統的可用性定義爲系統保持正常運行時間的百分比。
計算機產業界通常用如下表所示的"9"的個數來劃分計算機系統可用性的類型。
| 可用性分類 | 可用水平 | 每年停機時間 |
| 容錯可用性 | 99．9999 | < 1 min |
| 極高可用性 | 99．999 | 5 min |
| 具有故障自動恢復能力的可用性 | 99．99 | 53 min |
| 高可用性 | 99．9 | 8.8 h |
| 商品可用性 | 99 | 43.8h |
通過硬件冗餘或軟件的方法都可以從很大程度上提高系統的可用性。硬件冗餘主要是通過在系統中維護多個冗餘部件如硬盤、網線等來保證工作部件失效時可以繼續 使用冗餘部件來提供服務；而軟件的方法是通過軟件對集羣中的多臺機器的運行狀態進行監測，在某臺機器失效時啓動備用機器接管失效機器的工作來繼續提供服 務。
一般來說，需要保證集羣管理器的高可用性和節點的高可用性。Eddie、Linux Virtual Server、Turbolinux、Piranha和Ultramonkey 都採用了類似於圖1的高可用性解決方案。
圖1 高可用性解決方案示意圖
爲了屏蔽集羣管理器的失效，需要爲它建立一個備份機。主管理器和備份管理器上都運行着heartbeat程序，通過傳送諸如"我活着"這樣的信息來監測對 方的運行狀況。當備份機不能在一定的時間內收到這樣的信息時，它就激活fake程序，讓備份管理器接管主管理器繼續提供服務；當備份管理器又從主管理器收 到"我活着"這樣的信息時，它就使fake程序無效，從而釋放IP地址，這樣主管理器就開始再次進行集羣管理的工作了。
|
|
節點的高可用性可以通過不斷監視節點的狀態以及節點上的應用程序的運行狀態來實現，當發現節點已經失效時，可以重新配置系統並且將工作負載交給那些運行正 常的節點來完成。如圖1所示，系統通過在集羣管理器上運行mon精靈程序來監視集羣中的實際服務器上的服務程序的運行狀況。例如使用 fping.monitor 以一定的時間間隔來監視實際服務器是否還在正常運轉；使用http.monitor 來監測http服務，使用ftp.monitor來監測ftp服務等等。如果發現某個實際服務器出了故障，或者是其上的服務已失敗，則在集羣管理器中刪除 有關這個實際服務器的所有規則。反之，如果不久以後發現系統已經重新能夠提供服務，則增加相應的所有規則。通過這種方法，集羣管理器可以自動屏蔽服務器和 其上運行的服務程序的失效，並且當實際服務器正常運轉時能將它們重新加入到集羣系統中。
文件系統
集羣計算的發展需要發展並升級文件系統，此文件系統不僅能夠對多個文件提供並行的訪問，而且能在對同一文件進行訪問的進程間提供cache一致性。大多數 傳統的網絡文件系統如NFS、AFS、Coda對於並行處理而言是遠遠不夠的，因爲它們都依賴中心文件服務器。但是，隨着越來越多的客戶的加入，服務器的 cpu很快就成爲了性能的瓶頸。爲了解決這個問題，處理能力更強的服務器已經被製造了出來，而且文件系統的設計者們也試圖將更多的工作交給客戶來完成，但 是即使是這樣，服務器的速度仍然是文件系統可升級性的瓶頸。新一代的文件系統如Global File System(GFS) 、XFS和 Frangipani 比較適合於集羣系統。因爲這些系統都在集羣系統中的機器上分配存儲器、cache 和控制權，並且提供了並行文件訪問和cache一致性的解決方法。
Coda文件系統(Coda File System)適用於分佈式網絡環境。它是在1987年在卡耐基梅隆大學以AFS2爲原型開發出來的。Linux Virtual Server就採用了Coda文件系統。Coda提供了以下適用於網絡文件系統的特性。
- 爲移動的客戶提供了斷開操作。
- 它是一種自由軟件。
- 通過客戶訪問的持續緩存提供了高可用性。
- 服務器複製功能。
- 提供了認證的安全模型、加密和訪問控制。
- 部分網絡失效後能夠繼續工作。
- 具有網絡帶寬適應性。
- 較好的可擴展性。
- 即使在網絡失效時也爲共享定義了良好的語法。
AFS和Coda文件系統都將所有的文件放於同一個目錄下，如AFS 是/afs，Coda是 /coda，這意味着所有的客戶都可以使用相同的配置，所有的用戶看到的是相同的文件樹。對於大的安裝而言這是非常重要的。對於NFS文件系統而言，客戶需要服務器的最新列表而在Coda中只需要找到根目錄/coda。
當 在客戶端敲入"cat /coda/tmp/foo"這樣的請求時，cat將調用系統調用向核心請求服務，核心首先找到對應的文件索引節點並返回與該文件相關的文件句柄。索引節 點包含文件的一些相關信息，文件句柄用於打開文件。系統調用首先進入核心的虛擬文件系統（VFS），然後它將請求傳送給核心中的Coda文件系統模塊進行 處理。Coda文件系統模塊包含着從VFS來的最近的一些請求，然後它將此請求交給Coda緩衝管理器venus進行處理。Venus通過察看硬盤緩衝 區、向服務器發請求等方式來定位文件的所在地。如果在硬盤緩衝區中沒有找到匹配的文件，則通過遠程系統調用向服務器發請求，並且將取到的文件放在 cache中，這時，這個文件就是一個普通的文件了，因此可以通過本地文件系統對該文件進行讀寫的操作。如果在硬盤緩衝區找到了此文件，則可以直接使用這 個文件。當對此文件進行了一定的修改並且關閉了以後，venus將把新文件傳送給服務器從而來更新服務器上的文件。其它的操作如修改文件系統，創建新目 錄，刪除文件，去除符號鏈接等都可以傳送給服務器。
但是由於網絡有時會出現問題，因此如何保證文件的連續性是一個非常重要的問題。當venus意識到服務器不可用時，它就將客戶端對文件的更新存儲在修改日誌中，當服務器重新可用時，便根據修改日誌對服務器上的相應的文件進行更新。
|
|
Global 文件系統（Global File System, GFS）允許多個Linux機器通過網絡共享存儲設備。每一臺機器都可以將網絡共享磁盤看作是本地磁盤，而且GFS自己也以本地文件系統的形式出現。如果 某臺機器對某個文件執行了些操作，則後來訪問此文件的機器就會讀到寫以後的結果。GFS文件系統的使用示意圖如圖1所示。
圖1 GFS文件系統使用示意圖
|
|
xFS試圖通過將服務器的功能如保持cache的一致性、定位數據和處理磁盤請求分佈在各個客戶上來提供對文件系統數據的低延遲、高帶寬的訪問。
爲了保持cache一致性，xFS採用瞭如下的方法。它將客戶方的所有的內存空間看爲一個大的cache，這樣就減少了客戶方的數據緩存，利用了閒置機器的內存，這種合作型的緩存可以通過減少到達磁盤的請求量來降低讀延遲。
爲了將定位數據的功能分佈到每個客戶端，xFS讓每個客戶都必須對文件的一個子集對應的請求進行處理。文件數據在多個客戶端加以分類從而提供更高的帶寬， 這些分類數據包括一些奇偶信息，通過這些信息可以在機器失效時恢復分類的數據報。這種方法可以保證沒有任何節點會產生單點失效的情況。
|
|
MOSIX集羣使用了自己的文件系統MFS文件系統。MFS將集羣中的所有文件系統和目錄都看作是一個文件系統，而且它提供了對所有節點上的所有文件系統的統一訪問，它還通過只提供一個cache保證了cache的一致性。
MFS包含了許多位於不同節點上的文件子樹，因此它就允許對多個文件進行並行操作和cache一致性。
在MOSIX集羣中進行進程遷移時，如果此進程主要佔用的是CPU資源，則遷移此進程對於提供系統性能是非常有效的，但是如果此進程需要進行大量的I/O操作，則遷移進程非常不利。這是因爲每個I/O操作都需要與該進程原來所處的節點進行通訊。
因 此MFS增加了對DFSA(Direct File System Acess)的支持。DFSA的目的就是讓那些需要進行大量I/O操作的進程遷移到遠端節點上，該遠端節點擁有大多數I/O操作將會涉及到的文件，因此大 多數的I/O操作都能在遠端節點上完成，而且在遠端節點上可以通過本地訪問來訪問數據。如果一個系統調用是節點無關的，此係統調用就會在遠端節點上執行， 否則就在本地執行。MFS比其它網絡文件系統優越的地方就是它允許使用本地文件系統，這樣就減少了進程和文件服務器之間的通訊開銷。