概述
簡 單的說,集羣(cluster)就是一組計算機,它們作爲一個整體向用戶提供一組網絡資源。這些單個的計算機系統就是集羣的節點(node)。一個理想的 集羣是,用戶從來不會意識到集羣系統底層的節點,在他/她們看來,集羣是一個系統,而非多個計算機系統。並且集羣系統的管理員可以隨意增加和刪改集羣系統 的節點。
集羣並不是一個全新的概念,其實早在七十年代計算機廠商和研究機構就開始了對集羣系統的研究和開發。由於主要用於科學工程計算,所以這些系統並不爲大家所熟知。直到Linux集羣的出現,集羣的概念才得以廣爲傳播。
對 集羣的研究起源於集羣系統的良好的性能可擴展性(scalability)。提高CPU主頻和總線帶寬是最初提供計算機性能的主要手段。但是這一手段對系 統性能的提供是有限的。接着人們通過增加CPU個數和內存容量來提高性能,於是出現了向量機,對稱多處理機(SMP)等。但是當CPU的個數超過某一閾 值,象SMP這些多處理機系統的可擴展性就變的極差。主要瓶頸在於CPU訪問內存的帶寬並不能隨着CPU個數的增加而有效增長。與SMP相反,集羣系統的 性能隨着CPU個數的增加幾乎是線性變化的。圖1顯示了這中情況。
圖1. 幾種計算機系統的可擴展性
集羣系統的優點並不僅在於此。下面列舉了集羣系統的主要優點:
- 高可擴展性:如上所述。
- 高可用性:集羣中的一個節點失效,它的任務可以傳遞給其他節點。可以有效防止單點失效。
- 高性能:負載平衡集羣允許系統同時接入更多的用戶。
- 高性價比:可以採用廉價的符合工業標準的硬件構造高性能的系統。
1.2.1 集羣系統的分類
雖然 根據集羣系統的不同特徵可以有多種分類方法,但是一般我們把集羣系統分爲兩類:
- 高可用(High Availability)集羣,簡稱HA集羣。這類集羣致力於提供高度可靠的服務。
- 高性能計算(High Perfermance Computing)集羣,簡稱HPC集羣。這類集羣致力於提供單個計算機所不能提供的強大的計算能力。
|
計 算機系統的可用性(availability)是通過系統的可靠性(reliability)和可維護性(maintainability)來度量的。工 程上通常用平均無故障時間(MTTF)來度量系統的可靠性,用平均維修時間(MTTR)來度量系統的可維護性。於是可用性被定義爲:
MTTF/(MTTF+MTTR)*100% |
業界根據可用性把計算機系統分爲如下幾類:
可用比例 (Percent Availability) |
年停機時間 (downtime/year) |
可用性分類 |
99.5 | 3.7天 | 常規系統(Conventional) |
99.9 | 8.8小時 | 可用系統(Available) |
99.99 | 52.6分鐘 | 高可用系統(Highly Available) |
99.999 | 5.3分鐘 | Fault Resilient |
99.9999 | 32秒 | Fault Tolerant |
對於關鍵業務,停機通常是災難性的。因爲停機帶來的損失也是巨大的。下面的統計數字列舉了不同類型企業應用系統停機所帶來的損失。
應用系統 | 每分鐘損失(美元) |
呼叫中心(Call Center) | 27000 |
企業資源計劃(ERP)系統 | 13000 |
供應鏈管理(SCM)系統 | 11000 |
電子商務(eCommerce)系統 | 10000 |
客戶服務(Customer Service Center)系統 | 27000 |
隨着企業越來越依賴於信息技術,由於系統停機而帶來的損失也越拉越大。
高可用集羣就是採用集羣技術來實現計算機系統的高可用性。高可用集羣通常有兩種工作方式:
- 容錯系統:通常是主從服務器方式。從服務器檢測主服務器的狀態,當主服務工作正常時,從服務器並不提供服務。但是一旦主服務器失效,從服務器就開始代替主服務器向客戶提供服務。
- 負載均衡系統:集羣中所有的節點都處於活動狀態,它們分攤系統的工作負載。一般Web服務器集羣、數據庫集羣和應用服務器集羣都屬於這種類型。
關於高可用集羣的討論很多,這裏就不進行深入的闡述了。
|
簡單的說,高性能計算(High-Performance Computing)是計算機科學的一個分支,它致力於開發超級計算機,研究並行算法和開發相關軟件。高性能計算主要研究如下兩類問題:
- 大規模科學問題,象天氣預報、地形分析和生物製藥等;
- 存儲和處理海量數據,象數據挖掘、圖象處理和基因測序;
顧名思義,高性能集羣就是採用集羣技術來研究高性能計算。
高性能計算的分類方法很多。這裏從並行任務間的關係角度來對高性能計算分類。
3.2.1 高吞吐計算(High-throughput Computing)
有 一類高性能計算,可以把它分成若干可以並行的子任務,而且各個子任務彼此間沒有什麼關聯。象在家搜尋外星人( SETI@HOME -- Search for Extraterrestrial Intelligence at Home )就是這一類型應用。這一項目是利用Internet上的閒置的計算資源來搜尋外星人。SETI項目的服務器將一組數據和數據模式發給Internet上 參加SETI的計算節點,計算節點在給定的數據上用給定的模式進行搜索,然後將搜索的結果發給服務器。服務器負責將從各個計算節點返回的數據彙集成完整的 數據。因爲這種類型應用的一個共同特徵是在海量數據上搜索某些模式,所以把這類計算稱爲高吞吐計算。所謂的Internet計算都屬於這一類。按照 Flynn的分類,高吞吐計算屬於SIMD(Single Instruction/Multiple Data)的範疇。
3.2.2 分佈計算(Distributed Computing)
另一類計算剛好和高吞吐計算相反,它們雖然可以給分成若干並行的子任務,但是子任務間聯繫很緊密,需要大量的數據交換。按照Flynn的分類,分佈式的高性能計算屬於MIMD(Multiple Instruction/Multiple Data)的範疇。
當 論及Linux高性能集羣時,許多人的第一反映就是Beowulf。起初,Beowulf只是一個著名的科學計算集羣系統。以後的很多集羣都採用 Beowulf類似的架構,所以,實際上,現在Beowulf已經成爲一類廣爲接受的高性能集羣的類型。儘管名稱各異,很多集羣系統都是Beowulf集 羣的衍生物。當然也存在有別於Beowulf的集羣系統,COW和Mosix就是另兩類著名的集羣系統。
3.3.1 Beowulf集羣
簡 單的說,Beowulf是一種能夠將多臺計算機用於並行計算的體系結構。通常Beowulf系統由通過以太網或其他網絡連接的多個計算節點和管理節點構 成。管理節點控制整個集羣系統,同時爲計算節點提供文件服務和對外的網絡連接。它使用的是常見的硬件設備,象普通PC、以太網卡和集線器。它很少使用特別 定製的硬件和特殊的設備。Beowulf集羣的軟件也是隨處可見的,象Linux、PVM和MPI。
本文的以後幾部分將詳細介紹Beowulf集羣系統的硬件、網絡、軟件和應用體系結構。
3.3.2 Beowulf集羣和COW集羣
象Beowulf一樣,COW(Cluster Of Workstation)也是由最常見的硬件設備和軟件系統搭建而成。通常也是由一個控制節點和多個計算節點構成。COW和Beowulf的主要區別在於:
- COW 中的計算節點主要都是閒置的計算資源,如辦公室中的桌面工作站,它們就是普通的PC,採用普通的局域網進行連接。因爲這些計算節點白天會作爲工作站使用, 所以主要的集羣計算髮生在晚上和週末等空閒時間。而Beowulf中的計算節點都是專職於並行計算,並且進行了性能優化。它們採用高速網(Myrinet 或Giganet)上的消息傳遞(PVM或MPI)進行進程間通信(IPC)。
- 因爲COW中的計算節點主要的目的是桌面應用,所以它們都具有顯示器、鍵盤和鼠標等外設。而Beowulf的計算節點通常沒有這些外設,對這些計算節點的訪問通常是在管理節點上通過網絡或串口線實現的。
- 因爲連接COW中計算節點的通常是普通的局域網,所以COW上的高性能應用通常是象SETI@HOME 這樣的SIMD的高吞吐計算。而Beowulf無論從硬件、網絡和軟件上都對需要頻繁交換數據的MIMD應用做了特別的優化。
3.3.3 Mosix集羣
實 際上把Mosix集羣放在高性能集羣這一節是相當牽強的,但是和Beowulf等其他集羣相比, Mosix集羣確實是種非常特別的集羣, 它致力於在Linux系統上實現集羣系統的單一系統映象SSI(Single System Image)。Mosix集羣將網絡上運行Linux的計算機連接成一個集羣系統。系統自動均衡節點間的負載。因爲Mosix是在Linux系統內核中實 現的集羣,所以用戶態的應用程序不需要任何修改就可以在Mosix集羣上運行。通常用戶很少會注意到Linux和Mosix的差別。對於他來 說,Mosix集羣就是運行Linux的一臺PC。儘管現在存在着不少的問題,Mosix始終是引人注目的集羣系統。
- Linux HPC Cluster Installation, IBM Redbooks, http://www.redbooks.ibm.com/
- IBM eServer xSeries Clustering Planning Guide, IBM Redbooks, http://www.redbooks.ibm.com/
- Linux Clustering with CSM & GPFS, IBM Redbooks, http://www.redbooks.ibm.com/
- Cluster Computing White Paper, Mark Baker, University of Portsmouth, UK
- Beowulf HOW-TO, http://www.beowulf-underground.org
- Beowulf Introduction and Overview, http://www.beowulf.org
- The Mosix Howto, http://www.mosix.org
- Linux-HA Heartbeat System Design, http://www.linux-ha.org
- xCAT HOW-TO, http://www.x-CAT.org
- MPICH, http://www.mcs.anl.gov/mpi/mpich.
- PVM, http://www.epm.ornl.gov/pvm/pvm_home.html
- OpenPBS, http://www.openpbs.org/
- Maui, http://www.supercluster.org/
- Condor Manual, Condor Team, University of Wisconsin-Madison
- Intermezzo, http://inter-mezzo.org/
- Coda, http://www.coda.cs.cmu.edu/
Beowulf集羣
Beowulf是現存的最古老的英語史詩:
Famed was this Beowulf: far ew the boast of him, son of Scyld, in the Scandian lands. So becomes it a youth to quit him well with his father's friends, by fee and gift, that to aid him, aged, in after days, come warriors willing, should war draw nigh, liegemen loyal: by lauded deeds shall an earl have honor in every clan.
它歌頌了一個英雄,他擁有強壯的體魄和無人倫比的勇氣。他最終戰勝了魔鬼Grendel. 你可以在http://legends.dm.net/beowulf/index.html找到這首史詩。
我 們所說的Beowulf首先是一個象史詩中英雄一樣強大的集羣系統。在1994年夏季,Thomas Sterling和Don Becker在CESDIS(The Center of Excellence in Space Data and Information Sciences)用16個節點和以太網組成了一個計算機集羣系統,並將這個系統命名爲Beowulf。Beowulf集羣。Beowulf集羣提供了一 種使用COTS(Commodity off the shelf)硬件構造集羣系統以滿足特殊的計算需求的方法。這裏的COTS是指象PC和以太網這種廣爲應用的標準設備,它們通常可以由多家廠商提供,所以 通常有很高的性價比。Beowulf集羣這種方法很快從NASA傳遍了整個科研機構和社團。實際上,Beowulf集羣現在已被人們看作高性能計算中的一 個分支或流派。
因爲幾乎每個Beowulf集羣的設計者都有自己的Beowulf集羣的定義,恐怕很難給Beowulf集 羣下一個確切的定義。一些人認爲只有那些採用和原始的Beowulf集羣系統一樣方法構建的系統才叫Beowulf集羣。而另一些人則認爲凡是能夠在多個 工作站上運行並行代碼的系統都稱爲Beowulf集羣。這裏我們只是列舉多數Beowulf集羣具有的特徵作爲Beowulf集羣的定義:
- Beowulf是一種系統結構,它使得多個計算機組成的系統能夠用於並行計算。
- Beowulf系統通常有一個管理節點和多個計算節點構成。它們通過以太網(或其他網絡)連接。管理節點監控計算節點,通常也是計算節點的網關和控制終端。當然它通常也是集羣系統文件服務器。在大型的集羣系統中,由於特殊的需求,這些管理節點的功能也可能由多個節點分攤。
- Beowulf系統通常由最常見的硬件設備組成,例如,PC、以太網卡和以太網交換機。Beowulf系統很少包含用戶定製的特殊設備。
- Beowulf系統通常採用那些廉價且廣爲傳播的軟件,例如,Linux操作系統、並行虛擬機(PVM)和消息傳遞接口(MPI)。
|
由於一些特殊的目的如系統性能,有些Beowulf集羣系統也採用一些用戶定製的設備(它們通常由一家廠商提供)。爲了區分這些特殊的系統,通常把Beowulf分爲兩大類:
2.1 第一類Beowulf集羣(CLASS I Beowulf)
這一類Beowulf集羣全部由COTS設備組成。第一類Beowulf系統的優點是:
- 硬件設備由多個來源,通常具有廉價和易管理維護的特點。
- 不依賴於單個硬件供應商
- 所有設備驅動都由Linux開發社團提供
- 通常都是標準設備,例如,SCSI、以太網等等
當然第一類Beowulf集羣的缺點也是非常顯然的。由於所採用的硬件都沒有經過性能優化,所以其很難達到很好的性能。比如,由於以太網的高延遲和低帶寬使得集羣系統中消息傳遞很難達到MIMD應用的需求,從而使整個集羣系統的計算能力大打折扣。
2.2 第二類Beowulf集羣(CLASS II Beowulf)
第二類Beowulf集羣是指那些採用了用戶定製設備的Beowulf集羣。這類集羣系統最大優點是具有很好的性能。例如,採用Myrinet作爲集羣系統的IPC網絡可以極大地提供進程間消息傳遞延遲和速度。當然它的缺點就是依賴於單個硬件提供商而且價格高昂。
不能說,哪一類集羣絕對優於另一類集羣。這依賴於你的集羣系統的需求和預算。
如上所述,現實中存在形形色色的Beowulf集羣。雖然它們都是原始Beowulf集羣的衍生物,但是它們的體系結構也存在各種各樣微小的差異。本文以IBM eServer Cluster 1300爲例來闡述Beowulf集羣體系結構和系統組成。
圖1是Cluster 1300上Beowulf集羣的系統視圖
圖 1是Cluster 1300上Beowulf集羣的系統視圖。無論是管理節點(Master Node)和計算節點都是Intel IA32架構的xSeries PC服務器。它們通過網絡(以太網和Myrinet)相連接。所有的節點都運行Linux操作系統。運行在計算節點上的並行應用程序採用MPI進行完成並 行進程間的通信。計算節點通過管理節點和外部LAN相連。整個集羣系統都在一套集羣管理工具監控之下。
圖 2 Cluster1300上Beowlf集羣組件
圖 2 是 Cluster 1300上Beowulf集羣的組件視圖。它揭示了Beowulf集羣的組成部分。通常Beowulf集羣由四個層次構成:
- 硬件:主要是指Intel IA32架構的PC服務器。
- 網絡:指用於節點間通信的局域網(普通的以太網)和並行進程間通信的高速網(Myrinet等高速網)。
- 軟件:主要指Linux操作系統和用於並行通信的並行編程庫(如MPI和PVM)。
- 並行應用
本文的下面三個小節將分別介紹這四個層次。而本系列文章的後面兩片將更詳細的介紹它們。
Beowulf集羣硬件和網絡層次需要解決的問題是如何組織硬件使其達到最高的性價比。爲了達到很好的性價比,Beowulf通常採用廉價的COTS硬件。當然有時爲了提供某些關鍵的性能,也會使用一些特殊的設備。
從硬件組織的角度說,Beowulf集羣中的節點都是非共享內存的計算機,它們通過消息傳遞進行通信。實際上,我們還有其他組織硬件完成並行計算的方式。
簡單地說,有兩種組織硬件完成並行計算的方法:
- 通過消息傳遞通信的本地內存(非共享內存)計算機系統 (Beowulf集羣)
- 通過內存訪問通信的共享內存計算機系統 (SMP計算機)
當 然也存在將多個本地或共享內存計算機相連並創造一個混和的共享內存計算機系統的可能。但在最終用戶看來,這種計算機系統就好像一個大型的共享內存計算機。 這種技術被我們叫做非一致內存訪問NUMA(Non Uniform Memory Access)。但是從底層說,一個NUMA計算機系統必須在節點間傳遞消息。
當然也可以將共享內存計算機作爲一個本地內存的計算機連入一個Beowulf集羣系統。由於Linux系統支持SMP計算機,所以Linux系統本身能夠在SMP中的多個CPU上調度作業。所以Beowulf集羣本身就沒有必要識別集羣的節點是不是共享內存計算機了。
和SMP系統相比,集羣系統有明顯的優點。關於這一點請參閱本系列文章的第一篇。
因 爲Beowulf集羣採用消息傳遞完成並行程序間通信,所以網絡傳輸成了系統的瓶頸。在實際的系統中,通常採用有兩套彼此的獨立的網絡設備。一套是普通的 以太網,用於象系統管理和文件服務等普通的網絡通信。另一套網絡是用於進程間通信的高速網,象Myrinet和Giganet。和100M以太網相比,這 類網絡具有低延遲和高帶寬的特性。
還有三類設備雖然不是必須,但是對於集羣管理卻是非常重要的:
- KVM Swither:KVM是指Keyboard、Video和Mouse。這個設備可以讓系統管理員用一套KVM管理系統中的所有節點。
- 遠程電源管理設備(如ASM):這類設備使得管理員可以在管理節點Power on/off其他節點。
- Terminal Server:這種設備通過串口將節點連接起來。通過這個設備,管理員可以在管理節點上虛擬出其他節點上的控制終端。和KVM相比,這種方法不需要硬件的切換。
Beowulf集羣在軟件層次面臨的問題是如何在硬件層次上獲得最大的性能。通常,Beowulf集羣採用Linux+MPI的方式支持並行計算。MPI是採用消息傳遞的方式實現並行程序間通信。雖然也可以採用其他的通信方法,但是消息傳遞模式是最適合於集羣系統的。 簡單地說,有兩種在並行程序間傳遞併發的方法:
- 使用處理器間的消息傳遞(MPI)
- 使用操作系統的線程(Thread)
其他的方法也存在,但是這兩種方法應用得最廣泛。雖然存在效率和移植的問題,這兩種方法都可以在SMP,NUMA和Cluster上實現。
消 息傳遞需要在CPU間拷貝數據,而線程卻可以在CPU間共享數據。數據拷貝的速度和延遲是影響消息傳遞效率的最關鍵的因素。PVM和MPI是最常用的兩種 消息傳遞API。消息傳遞也可以在線程上實現,並且消息傳遞即可以用於集羣系統,也可以用於SMP系統。和線程相比,在SMP系統上使用消息傳遞的優點在 於可以很方便的把SMP上的應用移植到集羣系統上。
線程的最大特點是,線程間是共享數據。因此它在SMP系統上工作的更好。而且Linux本身也是支持Posix線程的。但是使用線程的最大缺點在於,很難將線程擴展到SMP系統以外。雖然NUMA技術可以高效的做到這一點,但是那非常昂貴而且Linux本身也不支持。
下表概括了線程和消息傳遞在SMP和集羣系統上的比較:
SMP系統性能 | 集羣系統性能 | 擴展性 | |
消息傳遞 | 好 | 很好 | 很好 |
線程 | 很好 | 差* | 差 |
Beowulf集羣的應用層次位於硬件和軟件層次之上。它要解決的問題是如何在實際的集羣系統中並行化(PARALLEL)應用中的併發(CONCURRENT)部分,從而使集羣上的應用達到最好的性能。
在闡述這部分之前,我們需要區分兩個概念: PARALLEL和CONCURRENT。程序的併發(CONCURRENT)部分是指程序中可以獨立計算的部分。程序的並行(PARALLEL)部分是指程序中在同一時間被分別執行的併發(CONCURRENT)部分。
它 們的區別是很重要的。併發是程序本身的屬性,而並行是計算機系統的屬性。並行的目的是獲得很好的性能。限制並行性能的因素是計算節點間通信的速度和延遲。 大部分的Benchmark都有很高的並行性並且通信和延遲不是什麼瓶頸。但是其他應用卻沒有這麼簡單。對於這些應用,有時候使併發部分並行執行反而可能 使應用性能更低。簡單的說,除非附加的通信時間代價小於併發節約的計算時間,否則並行執行反而會降低效率。
程序員的任務就是決定哪些併發的部分需要並行執行,而哪些不應該並行執行。這些決定最終會影響應用程序的執行效率。圖3描述了實際應用中程序併發部分和通信計算時間比的關係。
在 理想的系統中,通信計算時間比應該是恆定的。任何併發部分都應該實現爲並行。不幸的是,實際的系統,包括SMP系統,都是圖3所示的那樣。所以在設計 Beowulf集羣應用時,必須認識到併發帶來的效率依賴於在該系統上通信處理時間比。也正是因爲這個原因,雖然可以把應用移植到另一個併發系統上,但是 並不能保證應用在被移植的系統上仍然是高效的。一般來說,不存在可移植的且高效的應用程序。
同樣的道理,使用更快的CPU也可能使你的應用變慢。
- Linux HPC Cluster Installation, IBM Redbooks, http://www.redbooks.ibm.com/
- IBM eServer xSeries Clustering Planning Guide, IBM Redbooks, http://www.redbooks.ibm.com/
- Linux Clustering with CSM & GPFS, IBM Redbooks, http://www.redbooks.ibm.com/
- Cluster Computing White Paper, Mark Baker, University of Portsmouth, UK
- Beowulf HOW-TO, http://www.beowulf-underground.org
- Beowulf Introduction and Overview, http://www.beowulf.org
- The Mosix Howto, http://www.mosix.org
- Linux-HA Heartbeat System Design, http://www.linux-ha.org
- xCAT HOW-TO, http://www.x-CAT.org
- MPICH, http://www.mcs.anl.gov/mpi/mpich.
- PVM, http://www.epm.ornl.gov/pvm/pvm_home.html
- OpenPBS, http://www.openpbs.org/
- Maui, http://www.supercluster.org/
- Condor Manual, Condor Team, University of Wisconsin-Madison
- Intermezzo, http://inter-mezzo.org/
- Coda, http://www.coda.cs.cmu.edu/
硬件和網絡體系結構
圖 1是Cluster 1300的硬件和網絡體系結構圖
圖 1是Cluster 1300的硬件和網絡體系結構圖。從圖中可以看出,整個系統由5類計算或網絡設備和5類網絡組成。這5類設備是:
- 主控制節點(Control Node)
- 計算節點
- 以太網交換機(Ethernet Switch)
- Myrinet交換機
- Terminal Server
5類網絡是:
- 集羣局域網(Cluster VLAN藍色)
- 管理網絡(Management VLAN 右邊綠色)
- IPC網絡(IPC VLAN 棕色)
- Terminal網絡(灰色)
- Service Processor網絡(左邊綠色)
本文的以下部分將介紹這些設備和網絡的角色,功能和一般的配置。
|
這一節主要介紹Beowulf集羣中的節點,節點的類型和相應的功能。根據功能,我們可以把集羣中的節點劃分爲6種類型:
- 用戶節點(User Node)
- 控制節點(Control Node)
- 管理節點(Management Node)
- 存儲節點(Storage Node)
- 安裝節點(Installation Node)
- 計算節點(Compute Node)
雖然由多種類型的節點,但並不是說一臺計算機只能是一種類型的節點。一臺計算機所扮演的節點類型要由集羣的實際需求和計算機的配置決定。在小型集羣系統中,用戶節點、控制節點、管理節點、存儲節點和安裝節點往往就是同一臺計算機。下面我們分別解釋這些類型節點的作用。
用戶節點是外部世界訪問集羣系統的網關。用戶通常登錄到這個節點上編譯並運行作業。
用 戶節點是外部訪問集羣系統強大計算或存儲能力的唯一入口,是整個系統的關鍵點。爲了保證用戶節點的高可用性,應該採用硬件冗餘的容錯方法,如採用雙機熱備 份。至少應該採用RAID(Redundant Array of Independent Disks)技術保證用戶節點的數據安全性。
控制節點主要承擔兩種任務
- 爲計算節點提供基本的網絡服務,如DHCP、DNS和NFS。
- 調度計算節點上的作業,通常集羣的作業調度程序(如PBS)應該運行在這個節點上。
通常控制節點是計算網絡中的關鍵點,如果它失效,所有的計算節點都會失效。所以控制節點也應該有硬件冗餘保護。
管理節點是集羣系統各種管理措施的控制節點:
- 管理網絡的控制點,監控集羣中各個節點和網絡的運行狀況。通常的集羣的管理軟件也運行在這個節點上。
- ASMA的控制點:ASMA(Advanced System Manager Adapter)允許將計算節點通過菊花鏈連接構成Service Processor網絡用於接受計算節點的警報並收集SNMP Trap.
如果集羣系統的應用運行需要大量的數據,還需要一個存儲節點。顧名思義,存儲節點就是集羣系統的數據存儲器和數據服務器。如果需要存儲TB級的數據,一個存儲節點是不夠的。這時候你需要一個存儲網絡。通常存儲節點需要如下配置:
- ServerRAID保護數據的安全性
- 高速網保證足夠的數據傳輸速度
安裝節點提供安裝集羣系統的各種軟件,包括操作系統、各種運行庫、管理軟件和應用。它還必須開放文件服務,如FTP或NFS。
計算節點是整個集羣系統的計算核心。它的功能就是執行計算。你需要根據你的需要和預算來決定採用什麼樣的配置。理想的說,最好一個計算節點一個CPU。但是如果考慮到預算限制,也可以採用SMP。從性價比角度說,兩個CPU的SMP優於3或4個CPU的SMP機器。
因爲一個計算節點的失效通常不會影響其他節點,所以計算節點不需要冗餘的硬件保護。
雖 然由多種類型的節點,但並不是說一臺計算機只能是一種類型的節點。一臺計算機所扮演的節點類型要由集羣的實際需求和計算機的配置決定。在小型集羣系統中, 用戶節點、控制節點、管理節點、存儲節點和安裝節點往往就是同一臺計算機,這臺計算機通常成爲主節點(Master Node)。在這種情況下,集羣就是由多個計算節點和一個主節點構成。
在大型的集羣系統中如何部署這些節點是個比較複雜的問題,通常要綜合應用需求,拓撲結構和預算等因素決定。
|
因爲計算節點間的通信需求,IPC網絡的性能是Beowulf集羣設計中非常重要的話題。由於應用的需求,通常需要高帶寬、速度和低延遲的網絡。Beowulf集羣的主要瓶頸通常也在於雙工的網絡通信,延遲和全局同步。
有 好幾種網絡技術可以用於IPC網絡。它們是快速以太網、千兆以太網和Myrinet。爲了達到高帶寬,通常需要採用交換機。交換機接受從雙絞線傳來的數據 包,但是它和集線器不一樣。它不向所有連接的節點廣播這個數據包,它會根據目的地址哪個端口是接受者,然後把這個包傳給接受者。
如 上所述,通常Beowulf集羣系統中有5類網絡。其中Service Processor網絡是以太網連接起來的菊花鏈結構,Terminal網絡是計算節點和Terminal Server通過串口線連接起來的星形結構。管理網絡、集羣網絡和IPC網絡則是通過交換機相連的。雖然可以把這三個網絡配置在一個網段,但是通常我們把 它們分化在三個虛擬網中(VLAN)。圖2是Beowulf集羣網絡結構。
3.2.1 管理網絡(Management VLAN)
管理網絡用於訪問IPC網絡交換機、Service Processor網絡和Terminal Server。HTTP、Telnet和SNMP等協議被用來管理這些設備。
3.2.2 集羣網絡(Cluster VLAN)
計算節點和存儲節點用這個網絡進行通常的網絡I/O。
3.2.3 IPC網絡(IPC VLAN)
用於計算節點間的高速通信。通常由特殊的高速網絡設備構成。
3.2.4 Service Processor網絡
以太網連接起來的菊花鏈結構,用於系統管理目的。
3.2.5 Terminal網絡
Terminal網絡是計算節點和Terminal Server通過串口線連接起來的星形結構。Terminal Server是外界訪問這個網絡的接口。管理節點通過Terminal Server虛擬出來的終端可以登錄到其他節點上完成必要的管理工作。
3.2.6 KVM網絡
KVM網絡是KVM Switch和各節點連接的星形網絡。其實把KVM網絡稱爲一個網絡並恰當。KVM是指Keyboard、Video和Mouse。通過KVM Switch的切換,管理員可以在管理各個節點。
|
Qty .P/N Description IBM Products Compute Nodes 4 865431Y xSeries 330 1000 256 256/OPEN 24X 4 37L7202 18.2GB Ultra160 HDD 4 10K3806 866Mhz 133MHz 256K 12 33L3144 256MB 133MHz ECC SDRAM RDIMM MEMORY 1 06P4792 C2T Cable Kit Management Node 1 86564RY xSeries 340,866Mhz,128Mb 1 19k4630 866Mhz 133MHz 256K 4 33L3144 256MB 133MHz ECC SDRAM RDIMM MEMORY 1 37L6091 ServeRAID 4L LVD SCSI Adapter 3 37L7202 18.2GB 7200rpm Ultra160 SCSI Hot-Swap SL H 1 34L1501 Netfinity 10/100 Ethernet PCI Adapter 2 1 34L0301 Netfinity Gigabit Ethernet SX Adapter 1 37L6880 270W Redundant HS Power Supply Shared Resources 1 9306200 Netbay 22 Half Rack 1 3619702 Netbay 22 Rack Extension Kit 1 9411AG1 Monitor (flatpanel) 1 L6888 Flatpanel rack mount kit 1 09N4291 8x2 Console Switch (KVM Switch) 2 94G7447 Console Cable Set 12ft (to KVM switch) 1 28L3644 Spacesaver Keyboard/trackpoint 1 28L4707 Keyboard tray 2 37L6866 Netbay Universal Voltage PDU 1 01K7209 ASMA Adapter (Wiseman card) 1 36L9973 1M Fibre Channel Cable 1 03K9308 Short Wave GBIC (Gigabit module) Equinox Products 1 990209 Equinox ELS-16 1 210059 Micro-Transceiver,AUI (DB-15)to 10BaseT 1 790091 ELS Rackmount kit 4 210062 Equinox Serial Adapters 4 690226 10'Serial Cables Myrinet Networking Products 1 M3-E16 Myrinet2000 3-slot Chassis 1 M3-M Management Module 4 M3S-CB-5M Myricom Myrinet LAN cables 4 M3S-PCI64B-2 Myrinet LAN Card 1 M3SW16-8S Myrinet 8-port Serial modules Miscellaneous Products 8 3'CAT5 Cables 5 1'CAT5 Cables Extreme Networks Products 1 13020 Summit24 -Full Layer 3-X |
- Linux HPC Cluster Installation, IBM Redbooks, http://www.redbooks.ibm.com/
- IBM eServer xSeries Clustering Planning Guide, IBM Redbooks, http://www.redbooks.ibm.com/
- Linux Clustering with CSM & GPFS, IBM Redbooks, http://www.redbooks.ibm.com/
- Cluster Computing White Paper, Mark Baker, University of Portsmouth, UK
- Beowulf HOW-TO, http://www.beowulf-underground.org
- Beowulf Introduction and Overview, http://www.beowulf.org
- The Mosix Howto, http://www.mosix.org
- Linux-HA Heartbeat System Design, http://www.linux-ha.org
- xCAT HOW-TO, http://www.x-CAT.org
- MPICH, http://www.mcs.anl.gov/mpi/mpich.
- PVM, http://www.epm.ornl.gov/pvm/pvm_home.html
- OpenPBS, http://www.openpbs.org/
- Maui, http://www.supercluster.org/
- Condor Manual, Condor Team, University of Wisconsin-Madison
- Intermezzo, http://inter-mezzo.org/
- Coda, http://www.coda.cs.cmu.edu/
軟件體系結構
圖1 是Beowulf集羣的軟件體系機構。一般來說,Beowulf集羣由如下幾個軟件部分組成:
- 操作系統:勿容置疑,操作系統是任何計算機系統的軟件基礎。相對於桌面系統而言,集羣系統對操作系統的任務調度和文件管理方面的要求更高。
- 並行開發庫:只要是指用於集羣中進程通信的軟件庫。消息傳遞和線程是兩種基本的通信方法。但是對於Beowulf集羣而言,消息傳遞更適合一些。Beowulf集羣常用的開發庫是MPI和PVM。
- 作業管理:調度作業並管理集羣系統的資源,是集羣系統的資源得到最大的利用。
- 系統管理:管理和監控整個集羣系統。
- 開發環境:開發和調試高效能應用的開發工具。
- 標準應用:一些標準的高性能應用如CFD。
- 客戶應用:客戶特別定製的應用。
|
並不是每種操作系統都適合高性能集羣系統。理論上說,硬件的體系結構、操作系統的任務調度方式和IPC的方式是決定應用並行化效果的主要因素。根據這三個因素,我們可以歸納出如下5種實施應用並行化的平臺:
- 單任務操作系統:CPU同時只處理任務隊列中的一個任務。MS DOS是這類系統的代表。
- 多任務操作系統:基於分時技術的多任務操作系統。雖然在同一時間段,所有的進程都在運行,但是在某一時間點,CPU只執行一個進程。這類操作系統可分爲搶佔式和非搶佔式。單CPU的Unix和NT屬於這種類型。
- 多CPU多任務操作系統:和單CPU的多任務操作系統不同的是,由於有多個CPU,所以在某個時間點上,可以有多個進程同時運行。多CPU的Unix和NT屬於這種類型。
- 多 CPU多任務操作系統+線程:某些任務當把它分爲若干並行的子任務同時在多個CPU上執行時,它會運行的更快,儘管運行這個任務佔有的總CPU時間變長 了。由於採用多個CPU而使任務結束的時間縮短了。由於應用本身的特性,隨着CPU個數的增加,性能並不會線性增加。Amdal法則說明了這種情況。運行 在同一主板上多個CPU的Unix和NT+線程屬於這一類型。SMP系統合適採用這種方法。
- 多CPU多任務操作系 統+消息傳遞:在SMP系統中,由於採用共享內存,所以CPU通信的時間幾乎可以忽略。但是在象集羣這種系統中,通信時間成爲不得不考慮的因素。這時,使 用線程是一種很奢侈的方法。這種情況下,消息傳遞是一種比較好的方法。(本系列文章的第二部分解釋了這種情況)。同一個主板或多個主板上的多個 CPU+Unix和NT+消息傳遞屬於這種類型。
Beowulf集羣使用第5種類型平臺。它可以由SMP和PC服務器組成,以Linux爲操作系統,以MPI或PVM這種消息傳遞方式作爲通信方法。
|
文件系統是操作系統的重要組成部分,用於存儲程序和數據。如何在各節點間高效、一致和簡捷的實現數據共享是集羣系統對文件系統提出的挑戰。
很明顯,那種僅能管理本地存儲的文件系統(如EXT和FAT)是無法滿足集羣系統對文件共享的要求的。在集羣環境下,最容易想到,也是最容易實現的文件系統就是分佈式文件系統。相當於本地文件系統,分佈式文件系統有如下優點:
- 網絡透明:對遠程和本地的文件訪問可以通過相同的系統調用完成。
- 位置透明:文件的全路徑無需和文件存儲的服務綁定,也就是說服務器的名稱或地址並不是文件路徑的一部分。
- 位置獨立:正是由於服務器的名稱或地址並不是文件路徑的一部分,所以文件存儲的位置的改變並不會導致文件的路徑改變。
分佈式文件系統可以使集羣的節點間簡捷地實現共享。但是爲了提供性能,分佈式文件系統通常需要使用本地的緩存(Cache), 所以它很難保證數據在集羣系統範圍的一致性。而且往往分佈式文件系統中只有一份數據,所以很容易發生單點失效。
建立在共享磁盤(Share-Disk)上的並行文件系統可以克服分佈式文件系統的這些缺點。通過使用在節點共享的存儲設備,並行文件系統具有很多優點:
- 高可用性:克服了分佈式文件系統中那種服務器端的單點失效的缺點,提高了文件系統的可用性。
- 負載均衡:有多個訪問點,彼此可以協調負載。
- 可擴展性:容易擴展容量和訪問的帶寬
下 面通過給出幾個集羣中使用具體的數據共享的方法。其中rsync是建立在本地文件系統之上,NFS和Inteemezzo屬於分佈式文件系統(確切的 說,NFS只是網絡文件系統),GFS屬於並行文件系統,而Backend-database則屬於不同於文件共享的另一種形式的共享。
3.2.1 rsync
rsync是一種簡單的文件共享實現方式。集羣中的每個節點都有一份數據複本,複本間使用rsync進行同步。因爲節點需要的數據就在本地,所以這種方法具有很高的可用性,不會出現單點失效現象。
如果需要的共享的數據量很小,而且很少更新時,可以採用這種方式。靜態網頁和小的FTP站點的可以使用這種共享方式。
3.2.2 NFS
這也是一種容易實現的方式。存儲節點通過NFS將自己本地的文件輸出,其他節點則把存儲節點輸出的文件系統mount到本地文件系統。NFS方式的存在兩個很大的缺點:
- 性能差:因爲所有的文件訪問都必須經過網絡和NFS服務器,所以在訪問流量比較大的情況下,網絡帶寬和NFS服務器都會成爲系統的瓶頸。
- 單點失效:如果NFS服務器的系統失效或者網絡失效都會使得其他節點無法得到數據,從而使整個集羣系統癱瘓。
當然使用多個互爲備份的NFS服務器可以改善性能和避免單點失效,但是這樣又會帶來如何實時保持備份服務器間數據一致性的問題。 NFS方式適合於共享訪問數據量不大的小型集羣系統。
3.2.3 GFS
GFS(Global File System)實現了存儲設備的網絡共享。這些存儲設備可以是共享SCSI(Shared SCSI)和共享通道(Fibre Channel - FC)。GFS包裝這些存儲設備使得它們好像節點本地的文件系統。GFS的主要優點在於:
- 高可用性:如果一個GFS客戶失效,數據還可以通過其他GFS客戶訪問。
- 擴展性:因爲不需要中心服務器,所有很容易擴展存儲容量和訪問帶寬。
GFS可以將物理上分離的存儲設備虛擬爲一個存儲而且能平衡訪問負載。GFS還實現了文件鎖和實時文件系統。
3.2.4 Intermezzo
Intermezzo 實現了一個分佈式的文件系統。它採用客戶/服務器模式。服務器擁有權威的數據,客戶節點僅有本地緩衝的版本。它們通過普通的網絡進行同步。 Intermezzo支持斷開連接下文件操作。在下次恢復連接時,它會集成本地的改動到服務器上。Intermezzo擁有象GFS一樣的可用性和可擴展 性。但是它無法保證數據的實時一致性。
3.2.5 Backend Database
基於後端數據庫的共享是完全不同於文件共享的方式。後端數據庫系統解決了數據的一致性、性能、可用性和可擴展性問題。但是數據庫的訪問方法要比文件訪問複雜的多。
|
並行化應用程序,使其更高效的運行是使用Beowulf集羣系統的最終目的。一般說,並行化應用程序分爲三個步驟:
- 確定應用程序的併發部分
- 估計並行的效率
- 實現應用程序的併發
在並行化應用程序的過程中,需要開發環境、並行開發庫和各種工具的支持。這些軟件都是Beowulf集羣軟件體系結構中重要的組成部分。
從實用的角度說,應用程序有兩種類型的併發:計算和I/O。儘管在多數情況下這兩者是正交的,但是也存在一些應用同時需要這兩種併發性。有一些工具可以用來幫助分析應用程序的併發,而且通常這些工具都是專門爲Fortran設計的。
分 析並行的效率是並行化應用程序中很重要的一個步驟。正確的分析並行的效率可以幫助你在有限的經費下最大化應用的執行效率。往往Beowulf集羣的需要和 應用的需要有些許的差別。比如,CPU消耗型的應用往往需要的是稍微快一點的CPU和高速低延遲的網絡,而I/O消耗型的應用需要的是稍微慢一點的CPU 和快速以太網。
如果沒有分析工具,你只能使用猜測和估計的辦法完成這一步驟。一般來說,如果在應用的一部分中,計算的時間是分鐘級而數據傳輸的時間是秒級,那麼這一部分可以並行執行。但是如果並行後計算時間降到秒級,你就需要實際測量一下再做權衡。
另外,對於I/O消耗型的應用,Eadline-Dedkov法則對你做決定有些幫助:如果兩個並行系統具有相同的CPU指標,慢CPU和相應具有低速CPU間通信網絡的系統反而具有較好的性能。
有兩種方法去實現應用程序的併發:顯式併發和隱式併發。
4.3.1 顯式並行化
顯 式並行化是指由開發者決定程序的並行。開發者通過在程序中增加PVM或MPI消息,或者增加程序執行的線程從而達到程序的並行化。顯式並行化通常難以實現 和調試。爲了簡化顯式並行化,某些開發庫中增加了一些函數用於簡化標準並行方法的實現。另外也有專門用於調試並行程序的工具。 TotoalView(http://www.etnus.com/Products/TotalView/index.html)就是一個源碼級的C、 C++和Fortran調試工具。它擁有方便的圖形化界面,可以用於調試多線程、多進程和集羣應用程序。
4.3.2 隱式並行化
隱式並行化是由編譯器來決定程序的並行性,高性能Fortran就是這類編譯器。隱式並行化中,程序開發者向編譯器提供一些程序並行的特徵,編譯器根據這些特徵做出程序並行化的決定。通常編譯器可以給並行應用提供一定程度的效率和移植性,但是不是最好的。
|
從用戶角度看,集羣系統就好像一臺服務器或者PC。很多用戶可以同時使用這個系統。但是當太多的用戶使用集羣系統時,系統性能會很差。資源管理就是管理用戶提交的作業,合理給各個作業分配資源從而保證集羣系統高效運行。作業管理通常由資源管理器和作業調度策略器組成。
|
從系統組成角度說,集羣系統是由多臺計算機組成的超級計算機。但是從最終用戶看來,集羣系統是一臺計算機,也就是說,集羣系統的構成對用戶是透明的。所以集羣系統的管理的目的就是讓集羣系統象一臺計算機一樣利於管理。歸納起來,集羣系統管理一般完成如下任務:
- 資源管理
- 事件管理
- 配置管理
- 監控和診斷
- 硬件控制
- 系統安裝
- 域管理
本系列文章的第五部分將詳細介紹集羣系統的作業管理和系統管理。
- Linux HPC Cluster Installation, IBM Redbooks, http://www.redbooks.ibm.com/
- IBM eServer xSeries Clustering Planning Guide, IBM Redbooks, http://www.redbooks.ibm.com/
- Linux Clustering with CSM & GPFS, IBM Redbooks, http://www.redbooks.ibm.com/
- Cluster Computing White Paper, Mark Baker, University of Portsmouth, UK
- Beowulf HOW-TO, http://www.beowulf-underground.org
- Beowulf Introduction and Overview, http://www.beowulf.org
- The Mosix Howto, http://www.mosix.org
- Linux-HA Heartbeat System Design, http://www.linux-ha.org
- xCAT HOW-TO, http://www.x-CAT.org
- MPICH, http://www.mcs.anl.gov/mpi/mpich.
- PVM, http://www.epm.ornl.gov/pvm/pvm_home.html
- OpenPBS, http://www.openpbs.org/
- Maui, http://www.supercluster.org/
- Condor Manual, Condor Team, University of Wisconsin-Madison
- Intermezzo, http://inter-mezzo.org/
- Coda, http://www.coda.cs.cmu.edu/
資源管理和系統管理
從 用戶角度看,集羣系統就好像一臺服務器或者PC。很多用戶可以同時使用這個系統。但是當太多的用戶使用集羣系統時,系統性能會變得很差。資源管理就是管理 用戶提交的作業,合理給各個作業分配資源從而確保充分利用集羣系統計算能力並儘可能快的得到運算結果。簡單的說,集羣資源由實現如下幾個部分:
- 資 源管理器:爲了確保分配給作業合適的資源,集羣資源管理需要維護一個數據庫。這個數據庫記錄了集羣系統中各種資源的屬性和狀態、所有用戶提交的請求和正在 運行的作業。策略管理器根據這些數據和指定的調度策略生成優先級列表。資源管理器根據這個優先級列表調度作業。資源管理器還應該具有資源預留能力。這樣不 僅可以保留強大的資源給需要的作業,而且可以預留一定的冗餘資源以應付集羣中的結點失效和突發的計算。
- 作業調度策 略管理器:策略管理器根據資源管理器得到各個結點上的資源狀況和系統的作業信息生成一個優先級列表。這個列表告訴資源管理器何時在哪些結點上運行哪個作 業。策略管理器不僅要提供一個複雜的參數集合去定義計算環境和作業,而且要爲這個定義提供簡捷靈活的表達方式以允許系統管理員實現策略驅動的資源調度。
|
有很多種選擇去管理集羣系統中的資源。其中PBS資源管理器和Maui作業調度器最適合集羣系統。
PBS(Portable Batch System)是由NASA開發的靈活的批處理系統。它被用於集羣系統、超級計算機和大規模並行系統。PBS主要有如下特徵:
- 易用性:爲所有的資源提供統一的接口,易於配置以滿足不同系統的需求,靈活的作業調度器允許不同系統採用自己的調度策略。
- 移植性:符合POSIX 1003.2標準,可以用於shell和批處理等各種環境。
- 適配性:可以適配與各種管理策略,並提供可擴展的認證和安全模型。支持廣域網上的負載的動態分發和建立在多個物理位置不同的實體上的虛擬組織。
- 靈活性:支持交互和批處理作業。
OpenPBS( http://www.OpenPBS.org/)是PBS的Open Source的實現。商業版本的PBS可以參照:http://www.pbspro.com/。
Maui 是一個高級的作業調度器。它採用積極的調度策略優化資源的利用和減少作業的響應時間。Maui的資源和負載管理允許高級的參數配置:作業優先級(Job Priority)、調度和分配(Scheduling and Allocation)、公平性和公平共享(Fairness and Fairshare)和預留策略(Reservation Policy)。Maui的QoS機制允許資源和服務的直接傳遞、策略解除(Policy Exemption)和指定特徵的受限訪問。Maui採用高級的資源預留架構可以保證精確控制資源何時、何地、被誰、怎樣使用。Maui的預留架構完全支 持非入侵式的元調度。
Maui的設計得益於世界最大的高性能計算中心的經驗。Maui本身也提供測試工具和模擬器用於估計和調節系統性能。
Maui需要資源管理器與其配合使用。我們可以把Maui想象爲PBS中的一個插入部件。
更多Maui的信息可以訪問: http://www.supercluster.org
|
從系統組成角度說,集羣系統是由多臺計算機組成的超級計算機。但是從最終用戶看來,集羣系統是一臺計算機,也就是說,集羣系統的構成對用戶是透明的。所以集羣系統的管理的目的就是讓集羣系統象一臺計算機一樣利於管理。歸納起來,集羣系統管理一般完成如下任務:
簡單地說,資源管理就是分配系統的資源和監控系統資源的使用狀態。這裏的資源是個很廣泛的概念,各種硬件設備、數據和程序都可以看成資源:如CPU、存儲、網卡,甚至系統的事件和log。
事 件(Event)就是系統的狀態的一次變化。如"CPU的利用率超過90%"就可以理解爲一次事件。簡單的說,事件服務就是事件通知服務,也就是當一次事 件發生時,通知對這類事件感興趣的個體這個事件發生了。事件服務可以分爲Push(也稱爲Subscribe-Publish)和Pull方式。系統管理 員還應該能夠通過事件服務設置系統對事件的自動響應。
分佈式命令和文件是指讓命令和文件操作同時在整個集羣結點或指定的一組結點上並行執行。
分佈式命令功能通常通過分佈式的Shell來提供。這種Shell一般叫做dsh(distributed shell)或 psh ( parallel shell)。你可以通過rsh或ssh來實現分佈式Shell。
分 布式文件主要用於指集羣中配置文件的同步。集羣系統實際上是由多個結點組成,所以對集羣系統的一個配置需要發佈到每個結點(或一組結點)。比如,需要配置 每個結點上的Apache都支持CGI,就需要把/etc/httpd下的配置文件發佈到每個結點的/etc/httpd中。簡單地說,集羣系統地配置管 理就是把一個或多個配置文件發佈到指定的結點上。有很多開放源碼的工具可以幫助完成集羣系統的分佈式文件功能,如rdist和cfengine。
對 持續運行的集羣系統而言,當系統正常運行時,你需要一些工具監控系統各部分的運行狀態,如系統進程、CPU利用率和內存利用率等。在普通的Unix系統 上,你可以簡單的用ps和top實現這些功能。但是在集羣系統中,你確實需要一些特殊工具,而且最好系統的監控可以支持多種網絡管理協議,如SNMP和 WBEM。當集羣系統工作不正常時,你則需要另外一些工具來協助系統診斷。如當系統某個不服務時,你可能需要用ping診斷是不是網絡出了問題。而當時多 個結點服務時,你則需要併發的ping來診斷是不是網絡錯誤。
PC機上很簡單的管理功能對於集羣系統而言可能會很難做到。比如讓一組結點重啓,就很難手工完成。所以集羣系統需要一些特殊的硬件設備完成這些功能。下面是幾個需要硬件支持特殊管理功能:
- 遠程電源管理:主要是遠程關閉、打開和重啓結點與查詢結點電源狀態。在IBM eServer Cluster 1300中採用ASM。
- 遠 程控制檯:當遠程結點出現問題或出現一些特殊的軟件需要時,需要直接登錄到結點上完成操作。KVM Switch可以滿足這種需求,但是當結點很多時,KVM Switch就會很複雜。而且KVM Switch需要手工切換,不能通過軟件方法使用。Terminal Server克服了KVM Switch的缺點。Terminal Server與結點的串口相連,並把串口虛擬成管理結點上終端設備,當然這需要對結點的操作系統做些相應的配置。
集 羣系統的安裝主要是指在各個結點上安裝操作系統、文件系統、並行程序運行庫、作業管理軟件和系統管理軟件等。它是集羣系統投入應用的前提,所以集羣系統的 安裝是一件非常重要的任務。一般集羣系統由幾十臺,甚至上百上千臺計算機組成,顯然手工安裝系統幾乎是不可能的。一般集羣系統的安裝的機制是:
- 網 絡啓動:設置需要的安裝的結點網絡啓動,然後管理結點遠程重啓需要安裝的結點。網絡啓動的結點啓動後從啓動服務器獲得一個小的操作系統內核。網絡啓動一般 採用Intel的PXE(Pre-Execution Environment)標準。 PXELinux是支持PXE的網絡啓動服務器。它可以在網絡啓動的結點啓動一個小的Linux核心並運行指定的Init程序。由Init程序負責後續的 安裝。
- 網絡安裝:這個操作系統內核負責從安裝服務器(通常是一個文件服務器)上取得安裝軟件包或系統鏡像並在本地 實施系統安裝。有多種Linux工具可以完成基於網絡的系統安裝。這些工具中的典型代表是:KickStart、ALICE (Automatic Linux Installation and Configuration Environment)、SIS(System Install Suite)和PartImage。這些工具可以分爲如下幾類:
- a. 基於Script的安裝:這種安裝方式中,安裝過程由安裝腳本(Script)控制,可以通過修改安裝腳本來配置安裝過程。這種安裝方式中,安裝服務器實 際上是一個文件服務器,它向結點提供要安裝的軟件包。除了軟件包不是來自本地外,這種安裝方法和本地安裝並沒有太大的區別,本地安裝的各個步驟(配置硬 件、安裝軟件包、配置系統等)它都要經過。KickStart屬於這中安裝方法。基於Script的安裝比較靈活,但是它是操作系統依賴型的。象 KickStart只支持Redhat Linux。
- b. 基於Imaging的安裝:和基於Script的安裝不同,基於Imaging的安裝並不需要經過本地安裝的各個步驟。它只需要把存儲在文件服務上的需要 安裝的系統映象(Image)拷貝到本地的硬盤上。這個系統映象來源於一個已經安裝和配置好的樣機。Imaging的安裝方式是獨立於操作系統,但是它依 賴於網絡啓動的操作系統內核支持的文件系統。Imaging的很大缺點是很難提供獨立於操作系統的配置方法。PartImage屬於Imaging安裝方 法。而SIS是Script和Imaging混合型的安裝方式。SIS利用Linux的chroot命令在安裝服務器的一個文件目錄下安裝一個虛擬的操作 系統映象。同時SIS支持用戶提供Shell腳本完成安裝後的配置。
- c. 基於Cloning的安裝:和Imaging安裝方式相同的是,Cloning安裝也採用系統映象。但是Cloning中的系統映象是樣機上硬盤分區的 Clone。因此,Cloning安裝不需要識別系統鏡像中的文件系統類型。所以它是獨立於文件系統的,它只依賴於操作系統內核支持的硬盤設備類型 (IDE或SCSI)。和Imaging一樣,Cloning的很大缺點是很難提供獨立於操作系統的配置方法。而且相對於Imaging而 言,Cloning效率更低。你可以簡單的用dd命令實現Clone。
下表歸納了幾種安裝工具的特點:
安裝工具 | 安裝方法 | 支持的系統 | 支持的網絡協議 |
KickStart | Script | Redhat Linux | NFS、FTP |
SIS | Script和Imaging混合 | Redhat Linux SuSE Linux Turbo Linux … |
rsync |
PartImage | Imaging | EXT2、FAT、NTFS、HPFS… | 私有協議 |
你可以簡單的把集羣系統的域管理理解爲結點管理,它主要包括如下簡單的功能:
- 加入、刪除和列舉集羣系統中的結點
- 對集羣中的結點分組
實際上,我們也把作業管理納入集羣系統管理的任務。但是相對於其他系統管理任務而言,作業管理在集羣系統中具有更重要的作用,而且通常的集羣系統管理軟件也不直接實現作業管理功能。所以我們把作業管理作爲集羣系統一個重要的軟件部分,而不是集羣系統管理的一項任務。
|
集羣系統管理軟件和集羣系統一樣形形色色、多種多樣。下面簡要介紹幾種集羣系統管理軟件並比較它們實現的功能。
IBM CSM(Cluster Systems Management )是IBM eServer Cluster 1300上的系統管理軟件。IBM的Linux集羣戰略的一部分就是把運行在RS/6000 SP平臺上的PSSP軟件移植到基於xSeries的Linux集羣系統上。CSM大部分功能來源於SP平臺,但是它也集成了WebSM 2000、xSeries、開放源碼工具和其他技術。CSM是一款功能很全面的管理工具,而且還在不斷的發展中。
XCAT是用於IBM eServer Cluster 1300上的系統管理軟件。它由Egan Ford開發。它基本上是由shell腳本寫成,相當簡捷。但是它實現了集羣系統管理大部分的內容,是個非常出色的管理軟件。
Mon在Linux平臺上開發,但是也以運行在Solaris上而出名。Mon的服務器和客戶都是基於perl開發的,所以很容易移植到其他UNIX和類UNIX平臺。
下表比較了以上三種集羣系統管理軟件:
項目 | CSM | XCAT | Mon |
支持的集羣系統 | IBM eServer Cluster 1300 | IBM eServer Cluster 1300 | 不特定於某個集羣系統 |
支持的操作系統 | Redhat、SuSE | Redhat,結點可以採用Imaging和Cloning安裝其他操作系統,甚至於Windows | 在Linux上開發,但是以運行在Solaris而著名。很容易移植到其他Unix和非Unix操作系統上 |
資源管理 | 提供統一的、可擴展的,全面的資源管理,但是由於強大而使用起來很複雜。 | 基本沒有 | 基本沒有 |
事件服務 | 提供事件訂閱發佈機制,並預先定義了很多系統事件和對事件的響應 | 將來會於Mon集成以完成事件服務 | 支持 |
配置管理 | 支持 | 無 | 無 |
監控和診斷 | 支持分佈式Shell(dsh)、支持SNMP | 支持併發Shell(psh)、併發ping(pping) | 支持SNMP |
硬件控制 | 遠程電源管理(rpower)遠程控制檯(rconsole) | 遠程電源管理(rpower) 遠程控制檯(rcon、wcon) | 無 |
系統安裝 | 支持KickStart和SIS 支持PXE | 支持KickStart、Imaging和Cloning 支持PXE和etherboot | 無 |
域管理 | 全面 | 基本沒有 | 基本沒有 |
集成性 | 除了必須的開放源碼軟件包,不與任何其他軟件集成。但是底層資源管理和事件服務提供編程接口,集成很方便。上層可以通過命令調用集成。 | 自動安裝PBS、Maui、Myrinet和MPI。將來會支持 SgridEngine Scheduler | 基本沒有,應該可以通過命令行集成 |
易用性 | 提供強大命令行工具和簡單的GUI工具 | 命令行工具,將來會和Ganglia集成提供一定的GUI | 提供命令行和基於Web的工具 |
- Linux HPC Cluster Installation, IBM Redbooks, http://www.redbooks.ibm.com/
- IBM eServer xSeries Clustering Planning Guide, IBM Redbooks, http://www.redbooks.ibm.com/
- Linux Clustering with CSM & GPFS, IBM Redbooks, http://www.redbooks.ibm.com/
- Cluster Computing White Paper, Mark Baker, University of Portsmouth, UK
- Beowulf HOW-TO, http://www.beowulf-underground.org
- Beowulf Introduction and Overview, http://www.beowulf.org
- The Mosix Howto, http://www.mosix.org
- Linux-HA Heartbeat System Design, http://www.linux-ha.org
- xCAT HOW-TO, http://www.x-CAT.org
- MPICH, http://www.mcs.anl.gov/mpi/mpich.
- PVM, http://www.epm.ornl.gov/pvm/pvm_home.html
- OpenPBS, http://www.openpbs.org/
- Maui, http://www.supercluster.org/
- Condor Manual, Condor Team, University of Wisconsin-Madison
- Intermezzo, http://inter-mezzo.org/
- Coda, http://www.coda.cs.cmu.edu/
金戈,IBM軟件工程師,在IBM中國開發中心主持Linux集羣系統開發工作。你可以通過 [email protected]和他聯繫。 |