使用 coLinux 和 openMosix 構建異構集群

您可以通過以下三種方法的任意一種來創建一個集群：完全遷移到一個單一的平臺，部分遷移，或者是以混合的方式創建。在本文中，將學習如何通過集群代理實現最后一種方法，并了解如何將 coLinux 和 openMosix結合起來為異構環境提供高性能集群中間件。在這個異構的環境中，Linux™ 將提供穩定性和性能，而且 Windows®用戶可以繼續使用他們的應用程序，根本不用關心其中的區別。

您可以通過以下三種方法的任意一種來創建一個集群：完全遷移到一個單一的平臺，部分遷移，或者是以混合的方式創建。在本文中，將學習如何通過集群代理實現最后一種方法，并了解如何將 coLinux 和 openMosix結合起來為異構環境提供高性能集群中間件。在這個異構的環境中，Linux™ 將提供穩定性和性能，而且 Windows®用戶可以繼續使用他們的應用程序，根本不用關心其中的區別。

從九十年代早期起，集群計算已經取得了長足的發展。隨著對 GNU/Linux 使用的日益增加，以可接受的預算使用 PC集群來獲得超級計算速度正日趨主流。容易獲得的廉價硬件（處理器、內存、硬盤、以太網卡等），再加上開放源代碼軟件，這些都促使人們采用基于Linux 的 Beowulf 集群。（“Beowulf”指的是基于 PC 的集群領域中最早的研究者 Dr. Donald Becker 和Dr. Thomas Sterling 為他們最初的集群所起的名字；很多人使用這個名字來代表一種類似的技術，即基于 PC 的集群。）

術語的這一模糊性帶來了這樣的問題：“希望構建集群的人是否必須使用 Linux？”（或許，那個問題的中心，也是更為實際的一點，是“我們有很多使用 Windows 的空閑 PC。僅僅為了借用 CPU 周期，我們是否需要將它們全部遷移到 Linux？”）

正是這些問題促使我們去試驗如何構建混合式集群（hybrid cluster），即由異構操作系統構成的集群。本文使用的是 Windows 和 Linux，為了簡化起見，沒有考慮其他操作系統。

為什么創建混合式集群？
當前，局域網和校園網都是由使用不同操作系統的PC 所構成。有的使用 Windows，有的使用 Linux，還有的使用 BSD，等等。一個局域網中 PC 的平均數目在 100 到 300之間，這表明其中有巨大的潛在計算能力，特別是如果您正在規劃一個主要目的是獲得最高速度的高性能計算集群（HPC）。

這種類型的集群所面臨的挑戰是：在大部分情況下，我們不能讓每臺 PC百分之百地致力于集群的工作。傳統的集群在全天候的運行期間內都完全致力于運行需要大量運算的程序，與之相比，這種混合式的集群主要適用于擴展現有Linux 集群的節點。實現這一目標有兩種策略：

• 在每一臺 Windows PC 上安裝集群代理（cluster agent）。您可以認為這個代理是在系統中運行的一個小應用程序，或者是一個 Windows 服務。它以自動的方式工作，其操作由主節點（使用 Linux）完全控制。
• 使用雙引導安裝，或者使用 Linux LiveCD。LTSP（Linux Thin Server Project）也可以歸類于此策略。其基本思想是將節點臨時轉換為 Linux 系統，然后作為集群的成員連接到主節點。

我們并沒有將從 Windows 到 Linux的部分或完全遷移作為解決方案來研究，因為我們希望在本文中集中關注第三種方法。我們沒有研究向 Linux的完全或者部分遷移，而是希望研究那些不需要關注完全遷移就可以將 Window 和 Linux加入集群的機制和好處。不過，這并不表示完全遷移是錯誤的解決方案。

我們選擇集群代理方法作為解決方案，因為它具有以下優勢：

• Windows 用戶能夠繼續在熟悉的環境中工作，使用辦公套件、繪圖或者執行其他任務。用戶可以讓集群代理以低優先級運行，或者在啟動屏幕保護程序時運行。Seti@home 項目使用了此類策略，非常有效。
• 由于避免了雙引導，不需要進行重新分區（為了安裝 Linux）。您可以在 Windows 文件系統之上安裝 Linux （比如 ZipSlack），但這樣會要求您必須退出 Windows。

使用集群代理的方法，您只需要在 FAT32 或者 NTFS 文件系統中留出一些空間來存放 Linux 代理二進制程序。

混合式集群的先決條件
在創建集群的過程中，需要在三類集群中作出選擇：高可用集群（HA）、高性能計算集群（HPC）和高吞吐率集群（HTC）。我們選擇的是 HPC，這是最常用的集群，它會帶來以下后果：

• 忽略在節點上可能發生的故障。這些故障包括電源故障、網線損壞以及其他種類的硬件相關問題，比如磁盤損壞、CPU 由于過熱而被鎖，以及內存損壞。
• 各個節點在執行主節點所提交的作業時，需要重新引導的機率較小。在這種情況下，應用程序本身或者管理員必須在特定時間內重新啟動必要的應用程序或者檢查點。

讓我們退而考慮這個問題：“為什么我們需要植入一個集群代理？難道將基于 Linux 的應用程序移植到 Windows 不能獲得更好的性能嗎？”當然，隨著 MinGW 或 Cygwin 等跨平臺編譯器的可用，這可能會很容易。

對這個問題的回答是，我們出于以下原因而更希望使用集群代理：

• 將軟件移植到另一個平臺不會像預期的那樣順利。對系統調用、時間、直接硬件訪問等問題的處理會延緩實現。
• 混合式集群往往用作各種新應用程序的實驗臺，或者用作對已有集群的擴展。投入很多精力來進行移植，對計劃會經常變化的環境而言不會有太多好處。
• 實際上，很多人使用商業或者私有軟件。這種軟件出售或發布時并沒有附帶源代碼。結果是不可能進行移植。

我們提出的解決方案并不是要獲得如同將其移植為本地 Windows 應用程序那樣快的執行速度。不過請記住，在這個試驗中，我們將嘗試達到以下幾個關鍵目標：

• 靈活性。當代理以較低的優先級運行，或者只有在 CPU 的空閑周期中運行時，Windows 用戶才可能如往常一樣工作。
• 性能。當運行集群代理時，執行速度應該幾乎 與本地移植一樣快。
• 效率。我們只需要像安裝普通 Windows 程序一樣安裝集群代理的二進制程序，并讓它們自動運行。
• 易管理。借助大規模部署軟件（比如 LanDesk 套件，或者微軟軟件管理服務器（Microsoft Software Management Server）），我們可以快速安裝和刪除代理軟件包。如果需要，還有 VNC 等遠程 X 客戶機擴展可以簡化遠程管理。

選擇軟件
首先，我們需要選擇兩個軟件：

• 模擬器或者虛擬機
• 集群中間件

關于模擬器/虛擬機
該軟件將成為一個橋梁，讓 Linux 內核可以在 Windows 上運行；這是它的主要功能。

由于難以將單一系統映像（Single System Image，SSI）中間件移植到 Windows內核體系結構中，所以我們選擇使用模擬器或者虛擬機。SSI解決方案會修改內核的幾乎所有部分：進程管理、文件系統、內存管理、調度器，等等。通過不加修改地運行內核進程，模擬器簡化了部署工作。

關于集群中間件
使用中間件，我們可以選擇作為 Linux 內核擴展的解決方案，這樣就可以構建 SSI 集群。還有其他一些選擇（比如批調度器或者完全的遠程執行包裝器），但是我們選擇 SSI 模型，因為它具有以下優勢：

• SSI 中間件隱藏了訪問分散在節點間的資源（文件、內存、CPU）的復雜性。我們只是需要運行應用程序，中間件將透明地完成資源的管理。
• SSI 中間件具有負載均衡和透明進程（transparent process）特性。利用這些特性，除了極其需要進行調整情形，或者中間件無法實現公平，管理員不需要手工調整負載。進程遷移也方便了執行，因為我們不需要進行顯式的遠程執行。

選擇集群中間件
這相對簡單。我們所選擇的 SSI 中間件是什么？有三個開放源代碼而且遵循 GPL 許可的解決方案（排序不分先后）：

• openMosix。
• openSSI。
• Kerrighed。

關于各個解決方案的詳細資料超出了本文的范圍，不過可以在參考資料中找到。

我們將選擇 openMosix，原因有二：

• 與其他解決方案相比，openMosix 擁有最為簡單的配置。這將降低集群部署的復雜度。
• openMosix 以其最簡單的方式為我們提供了負載均衡和透明進程遷移功能。所謂“最簡單”，指的是內核補丁的大小相對較小，而且沒有引入很多特性。這適用于我們的試驗，不過如果愿意的話，您可以使用其他 SSI 中間件來擴展此試驗。

選擇模擬器/虛擬機
這一選擇略為復雜。有兩種可能，使用 VMWare等商業版本的，或者使用 coLinux等開放源代碼的（猜猜我們將選擇哪一個!）。同樣，我們選擇的是基于開放源代碼的解決方案。不過，我們首先來討論各個解決方案的優勢與不足，您將了解到在分析我們的選擇時思考的過程。

對于商業產品，我們以 VMWare 為例。您可能會熟悉此產品；VMWare 已經在 VM 舞臺活躍了很長時間。這里是我們對 VMWare 的初步分析。

優勢 所在：

• VMWare是一個完全的系統模擬器（在本文中，術語“模擬器（emulator）”和“仿真器（virtualizer）”可以自由互換，都是指“完成對某個系統的模擬的軟件”）。所以，它可以模擬一個完整的系統（內存、存儲器、CPU、以太網卡、聲卡，等等）。運行于模擬器中的系統（稱為客戶系統（guest system））不需要任何修改（或者，最多需要一些保證 OS 平穩工作的補?。?。
• 模擬器在與其他宿主應用程序隔離開來的內存地址空間中運行，與用戶空間應用程序具有相同的特權，所以客戶系統的任何破壞都不會影響宿主。

不足 之處：

• 由于 VMWare 是一個商業產品，所以它不是免費的。網絡中所有 Windows 機器的許可費用，可能很容易超出一個新的專用集群的費用，后者可以以更少的費用獲得更高的性能。
• 模擬器會消耗宿主系統的大量資源。模擬器不得不為 guest-kernel-to-application 通信攔截大部分指令，也不得不模擬一組完整的虛擬硬件設備。這樣的模擬意味著使用多個層會影響網絡延遲的正常下限，而這個下限是無法再下調的。
• VMWare 本身（不包括客戶系統）需要大量的內存。所以，分配給它的內存數量將會非常大。

現在來分析 coLinux。coLinux 是一個新的開放源代碼解決方案，讓您可以在 Windows 內核之上運行 Linux 內核。

優勢：

• coLinux 讓 Linux 內核可以在本地運行（作為 Windows內核驅動器）。由于在這宿主內核和客戶內核之間沒有任何“橋梁”，所以 Linux 客戶可以以接近本地的速度運行。在很多不同的 Linux子系統中，模擬層是作為代碼直接插入的，因此它們可以轉換為對 Windows系統的直接請求。兩個內核之間在內部執行上下文切換，但這可以非?？焖俚赝瓿?。
• 宿主系統只需要分配完全只是客戶系統（及其派生的進程）所需要的內存。

不足：

• coLinux 本身還在發展之中，所以在運行它時您可能會遇到一些小問題。盡管所有的開發人員都在盡力使 coLinux 變得更好，但他們也可能不能捕獲某些缺陷。Windows 2000 和 Windows XP 是得到支持的 Windows 版本。
• 要運行 coLinux，需要進行一些手工配置。當前還沒有幫助創建完整 coLinux 系統的自動工具，所以您必須能夠構建或調整 coLinux 配置。

那么，與 VMWare 相比，coLinux 的性能如何呢？我們運行了一個粗略的基準。作為測試，我們選擇了來自 Povray 的 Web站點的 POV-Ray 3.6.1 預編譯二進制程序。（POV-Ray 是逼真 3D圖形創建軟件的始祖之一，它完全由那些進行大量數字處理的任務構成，非常適合我們的測試。）使用 benchmark.ini（包含于 povray軟件包之中）中的默認選項執行那個二進制程序： # povray benchmark.ini。

POV-Ray 在用于 Linux 內核 2.4.26 的 coLinux 上運行。根文件系統使用的是 Gentoo發行版本。我們使用相同的發行版本在 VMWare 版本 4.5.2 上測試相同的 POV-Ray二進制程序。下面的表格說明了測試機器使用必要的選項（在 benchmark.ini 給出）完成預定義的場景所需要的時間。

表 1. POV-Ray 運行時間結果

平臺（POV-Ray 在哪里執行）	時間（單位為 分鐘：秒）
本地 Linux	39:23
coLinux	39:26
VMWare	40:53

研究數據表單，您會發現 coLinux 與本地 OS 的速度相差甚少。正如所預期的那樣，VMWare 比 coLinux慢，相差一分鐘左右。通過實時地將虛擬機（VM）的指令流翻譯給宿主機器， VMWare 可以獲得接近本地的速度，但是由于 VMWare本身在用戶空間運行，這可能會引發問題。比如，當 VM 以內核模式執行代碼時；為了正確地仿真 VM 的虛擬 CPU，VMWare必須謹慎地轉換內存映射和權限。

現在，我們來看所選擇的模擬器 coLinux 和所選擇的中間件 openMosix 如何一起工作。

coLinux 與 openMosix 的聯合
圖 1 向我們展示了 openMosix 的工作方式。

圖 1. openMosix 的工作方式
javascript:window.open(this.src);" style="CURSOR: pointer" onload="return imgzoom(this,550)">

openMosix 在 Linux 內核內部運行。它有若干個可以通過 /proc接口進行控制的參數。為了簡化實際的操作，創建了一些用戶空間應用程序。openMosix以分散的（decentralized）方式工作，所以在此拓撲中沒有主節點或從節點。這一分散式策略被應用于負載信息交換，并且應用于進程遷移期間。

如果負載均衡算法認為另一個節點的工作負載較小，而且適于遷移進程，那么 openMosix會透明地將進程遷移到目標節點。進程不能或者不應該遷移的原因是多種多樣的（使用pthreads、進行大量磁盤操作、運行期非常短）。從用戶空間的角度來看，不需要修改應用程序代碼。所有工作都在內核空間透明地完成。

現在，讓我們來研究 coLinux 如何工作（下面的圖引用自 coLinux.org）。

圖 2. coLinux 內部結構的總體描述（獲得了Dan Aloni 的授權，他是 coLinux 首席開發人員和文檔編寫者）

Dan Aloni 將 coLinux 描述為一個協作的（cooperative） 且半虛擬的（paravirtualized）Linux 虛擬機。協作指的是它將控制權自主地交還給宿主 OS。半虛擬指的是：除了 CPU 和內存以外， coLinux內核不需接觸任何實際的硬件。這與 VMWare 不同，后者截取訪問硬件設備的 I/O 并模擬它。coLinux 感覺像是一個獨立的 Linux機器 —— 客戶內核的內部結構與宿主內核的內部結構是分開的。

注意，coLinux 由兩部分構成：

• 在宿主內核空間運行的 coLinux 內核驅動程序。
• 若干個用戶空間后臺進程。

coLinux 內核驅動程序的主要工作是：

• 在啟動時加載 Linux 客戶內核。您可以認為這個功能類似于引導加載器（比如 LILO 或 GRUB）。
• 根據 colinux-daemon 進程的要求執行 ioctl() 請求。這個 ioctl() 調用負責進行客戶 OS 與宿主 OS 之間的上下文切換。
• 為來自某些虛擬驅動器（cobd（塊設備）、conet（網絡）、cocon（控制臺））的中斷和請求進行代理轉發。

在用戶空間中，最重要的是部分是 colinux-daemon-process。除了負責觸發上下文切換之外，它還要作為colinux-console-nt 和 colinux-net-daemon 等一些其他后臺進程的“管理者”。例如，通過colinux-console，用戶可以查看 Linux 客戶的活動控制臺的當前顯示。當用戶在此 colinux-console 的shell 中輸入或者執行命令時，colinux-daemon 將會 “包裝”它并將其轉發給 colinux-driver。要完全理解coLinux 的內部機制，請訪問 coLinux.org。

openMosix 與 coLinux 融合時，沒有顯著的變化。由于 openMosix 完全位于內核空間，而 coLinux只是與通常一樣引導客戶內核映像，并如前所述那樣工作。當 openMosix 必須與其他節點通信時，客戶內核會去調用一些系統調用。coLinux截取這些調用，并將數據傳遞到 coLinux-net-daemon，由它來通過 Windows API 最終將數據發送出去。

下面是對 coLinux 網絡層次和網絡傳輸數據流的描述：

1. 源應用程序（Source Application）
2. Linux 內核
3. coLinux 內核驅動程序
4. coLinux 網絡驅動程序
5. Windows NIC 驅動程序

現在我們來看如何讓 coLinux 和 openMosix 進行結合。

融合 coLinux 和 openMosix
對本文而言，我們組合使用了coLinux 和用于 2.4.26 Linux 內核的 openMosix 補丁。之所以選擇2.4.26，是因為它是進行試驗時最新的穩定內核版本，也是同時支持 openMosix 和 coLinux 的 2.4.x內核中序列號最高的版本。（這里提及的描述只是一個概述。要獲得完整的說明，請參閱參考資料中的 step-by-step 指南。）

下面是制做您的第一個 coLinux/openMosix 內核的步驟：

1. 您需要 2.4.26 Linux vanilla 內核，用于此內核的 openMosix，以及 coLinux 版本 0.6.1。下載所需要的存檔文件，并將它們解壓到合適的工作目錄。
2. 為內核源代碼打上 coLinux 內核補丁，并將配置文件（conf/linux-config，這是 coLinux 所附帶的）復制到內核源代碼樹。當然，應該將其命名為“.config”。
3. 現在打 openMosix 補丁。有一個文件會失敗，不過這沒關系，因為它只是補丁認為有問題的一個 Makefile 文件。
4. 最后，您可以執行下面的命令來構建內核：
   
   # make oldconfig
# make dep
# make vmlinux

這將生成 vmlinux 文件和新的內核。我們建議您在構建 coLinux 的所有過程中（內核映像和用戶空間工具）都使用 gclearcase/" target="_blank" >cc3.3.x，因為已經證明它能夠生成最穩定的二進制程序。編譯內核映像和用戶空間工具時不要使用不同的gcc，因為這可能會造成系統的鎖定。為了將完成的內核用作虛擬機，還需要有用戶空間工具、基文件系統的映像以及 TAP-32 win32網絡驅動程序。為了縮短整個測試周期，您可以下載同時包含有用戶空間工具和內核映像的立即可用的程序包。（在參考資料一節中可以找到所有這些下載。）

剩下的惟一一件事情就是創建您自己的文件系統映像，或者從 coLinux.org 下載它們。為了使用 openMosix 的功能，需要將openMosix 用戶空間工具放入文件系統映像中。請參閱 openmosix.org Web 站點上關于如何編譯用戶空間工具的說明。

在 step-by-step 指南中，可以找到將所有內容（Linux 內核映像、用戶空間工具、根文件系統等）整合為一個可用系統的步驟。

運行時間基準
這里是闡明我們所提出的方法的易用性與性能的一個基本的、初步的基準。我們的實驗臺上只有兩臺機器：Amun 是一臺本地 Linux 的機器，運行的是 Debian linux。Ipc256 運行的是 Windows 2000 Professional。

各個節點的硬件規格如下：

Ipc256 的規格

處理器：	P4 1.70 GHz
RAM：	256 MB
操作系統：	Windows 2000 Professional
硬盤：	40 GB IDE
網卡：	Realtek Semiconductor Co. Ltd. RTL-8139 Fast Ethernet

Amun 的規格

處理器：	P4 2.40 GHz Hyper Threading
RAM：	2048 MB
操作系統：	Debian Woody
硬盤：	2x approx. 40 GB IDE, several NFS mounts
網卡 1：	Syskonnect (Schneider & Koch) SK-98xx V2.0 Gigabit Ethernet
網卡 2：	Realtek Semiconductor Co., Ltd. RTL-8139 Fast Ethernet

我們選擇了一個多進程（之所以使用術語“進程”，是因為它使用了 fork()）應用程序作為基準，它不做任何事情，只是連續不斷地使用不同的種子數值計算 Fibonacci 數字。它的目的并不是做有意義的計算，而是為我們的解決方案提供一個易于理解的說明。在下載一節中有壓縮文件，下載這些文件可以查看其源代碼。

程序分為兩部分。第一部分派生 2^5 = 32 個子進程。為此它使用了系統調用 fork()。這樣就使得 openMosix 可以將那些進程分布到參與集群的所有節點中去。在第二部分執行實際的計算。

我們將此程序運行了四次，取其平均值。下面的表給出了結果。

表 2. 多進程程序運行時間結果

宿主	執行時間（單位為秒）	注釋
Amun	ta = 436.25	本地運行
Ipc256	ti = 778.75	本地運行
Both	tb = 285.25	先在 Amun 上運行，然后遷移到 Ipc256

查看這些結果，您會觀察到單臺 PC 完成那個工作需要多長時間。Amun 比 Ipc256 稍快一些，但是同時使用兩臺 PC 獲得的效率絕對是最高的。如果不僅是一臺而是很多 Windows PC 加入到集群，這個效率可能還會更高。

使用下面的公式計算開銷：

Overhead = tb/ta + tb/ti - 1

在該例中，我們的試驗所產生的開銷是 2.01%，接近理論最優值。

通過這一基準，我們可以得出這樣的結論：要最大限度地受益于此類集群，最好的方法就是劃分作業或者應用程序。使用參數化調用（parameterized invocation） 是更常見的一個策略，使用不同的參數派生同一個程序的多個實例。

POV-Ray 的渲染工廠（renderfarm）是參數化調用的一個示例。渲染程序的每一個實例都取得一部分場景并構建出一個完成的幀。重復此過程，直到所有場景都被取完。

展望
對于預算充足的用戶而言，采用 VMWare等商業化的仿真器或許是使用開放源代碼的基于 Linux 的 SSI 來實現混合式 Windows-Linux集群的安全方法，但是，對那些尋求可接受的解決方案的用戶而言，他們希望每一分投入都能獲得最大的價值，而 coLinux 是理想的選擇。

這一解決方案的優勢很明顯。不需要進行大規模的從 Windows 到 Linux 的遷移 —— 只需繼續使用您所熟知的 Linux環境。這樣將會縮短部署的時間，而且還能讓基于 Windows 的用戶如往常一樣工作。Windows PC 的空閑能力可以用來幫助 Linux機器運行非常消耗 CPU 的程序。

基于目前基礎的改進
今后能夠得到改進的方面有很多，包括

• 編寫宿主內核和客戶內核之間的內核到內核的網絡數據包注入（injection）。當前，這些數據包必須從宿主驅動程序開始，經過 TAP32 驅動程序、colinux-net 后臺進程、coLinux 后臺進程，最后到達colinux 內核驅動程序。繞開這些步驟并將其替換為直接的內核驅動程序/colinux驅動程序連接，這樣就可以減少通信延遲，從而提高集群的性能。
• 創建更先進的集群代理軟件包。有一些讓我們可以立即部署的特殊的 coLinux 發行版本（下一節中提到的 CosMos 就是一個例子）。創建這樣的軟件包需要大家的共同幫助，最好讓它擁有一個易用的配置管理器，使得用戶或者管理員只需要點擊幾次鼠標就可以進行定制配置。
• 將 coLinux 移植到 2.6 版本的 Linux 內核。我們撰寫本文時，已經有用于 2.6 內核的 coLinux 內核補丁的開發發布版（development release）。2.6 版本的 Linux 內核具備很多可以在內核方面提高集群性能的特性，比如 O(1) 調度器和 I/O 調度器。
• 增強 coLinux 內核驅動程序與 Windos 2000 和 XP 的兼容性。 勿需多言，coLinux 和 Windows 內核之間還存在一些兼容性問題。（注意：coLinux 不支持 Windows 95/98/ME，這也是一個問題。）
• 令 coLinux 使用宿主機器的 IP。到目前為止，coLinux 實例使用的是它自己的 IP地址。這樣，在大規模的集群中會浪費大量 IP 地址。IPSec 隧道會有所幫助，它能夠將全部客戶網絡數據封裝到一個單獨的 IPSec流中（同樣，如 CosMos 的用法），不過 IPSec 本身增加了大量的延遲。另一個解決方案應該是 IP-over-IP隧道，這樣可以避免加密的時間消耗，但是其實現需要付出更多努力。

相關項目
CosMos 是 Ian Latter所開發的一個項目，它的目標是提供一個具有緊湊文件系統的直接可用的 coLinux/openMosix 二進制程序。CosMos的一個非常好的特性是，它使用 IPSec 隧道來在集群節點間創建安全的端到端通信。（您可以通過 Ian.Latter@mq.edu.au 與Ian 聯系。）

另一個項目（主要由 Christian Kauhaus 開發）的目標并不是 HPC，而是類似于著名的 Condor 項目，設計用于高吞吐率計算集群。與 CosMos 的共通之處是，其目標也是創建一個立即可用的程序包，不過在其他方面有所不同，比如：

• 網絡通信；出于性能原因，它沒有使用 IPSec 隧道。
• 配置服務器（Configuration Server）；它的任務是管理配置，以及集群中非專用節點的加入與離開。

此項目仍處于早期 alpha 階段 —— 觀察它的發展應該會非常有趣。

原文轉自：http://www.kjueaiud.com