10.0.0.1 node1 10.0.0.2 node2 10.0.0.3 node3 10.0.0.4 node4每一個節點的/etc/hosts.equiv文件應該如下所示:
node1 node2 node3 node4 .< /CODE>一個節點號為2,使用Red Hat Linux的ifcfg-eth0配置文件如下所示:
DEVICE=eth0 IPADDR=10.0.0.2 NETMASK=255.0.0.0 NETWORK=10.0.0.0 BROADCAST=10.255.255.255 ONBOOT=yes此外,我們還經常需要一個DNS,對於那些節點名字和地址經常變化的內部網絡更是如此。DNS可以運行在第一個節點來為內部網絡的節點提供名字/地址的解析。 本地存儲 在加載操作系統的問題上,創建Beowulf集群需要預先做一些存儲方面配置的決定。因為一旦安裝完成後要進行更改就要重新安裝所有的節點,所以一定要進行非常細致的考慮。雖然大部分基於Linux的Beowulf集群運行的是都是Red Hat Linux發行版,但事實上,基本上所有的Linux發行版都支持基本的集群。Red Hat的安裝非常簡單,我們可以使用光盤或者通過集群的第一個節點進行安裝(前提是在節點上已經有一份發行版拷貝)。在實際的使用過程中,很多人發現從主節點通過FTP把操作系統加載到每一個節點要比通過NFS掛載Root分區好。這種方法避免了一些不必要的網絡通信,在應用程序運行時保留帶寬用於信息的傳送。 Red Hat Linux運行環境只需要每一個節點有大約100MB的磁盤空間,不過,在實踐中發現在每一個節點包含一個編譯和一些其它的工具還是非常必要。因此,在配置中,每一個操作系統需要大約175MB的磁盤空間。雖然有一些集群將交換分區配置在了普通的文件系統上,但在本地磁盤上使用一個專門的交換分區才是一個更高效的選擇。一般而言,節點的交換空間的大小應該是內存的2倍,而當內存大於64MB時,交換空間應該等於內存的大小。在實際中,當內存為64MB至 128MB時,我們通常將交換分區設為128MB。因此,如果某一個節點有32MB內存,有2個硬盤,那麼我們就應該將Linux系統加載至主驅動上,而將另外一個硬盤用作交換空間(64MB)和本地運行空間(138MB)。 集群管理 系統管理和維護是一件非常乏味的工作,對於大型的集群更是如此。不過,我們可以從網上找到一些工具和腳本來簡化這些工作。比如,一個節點必須在時間和系統文件(/etc/passwd、/etc/group、/etc/hosts、/etc/hosts.equiv等)上與其它的節點保持同步,那麼一個簡單的可以被cron定時執行的腳本將可以來完成這個同步過程。 一旦所有的節點都加載和配置完成後,我們就可以來開發和設計並行應用程序來充分利用新系統的運算能力。 為集群計算開發並行應用程序 在Linux下,我們可以使用商業編譯器,也可以使用免費的編譯器。GCC、g++和FORTRAN(g77)編譯器被包含在了大部分的Linux發行版中。其中C和C++編譯器已經非常優秀,而FORTRAN編譯器也在不斷的進步之中。商業編譯器則可以從Absoft、 Portland Group、The Numerical Algorithms Group等公司獲取。如果配置適當,一些商業的FORTRAN-90編譯器可以自動實現並行計算。一般來說,開發並行代碼需要在處理器之間使用PVM (並行虛擬機)、MPI(信息傳送接口)或者其它的通信庫來進行清晰的信息傳遞。PVM和MPI都是免費的,並且可以在計算的過程中通過簡單的庫調用來實現節點的之間的信息傳遞。 當然,並不是所有的計算任務都適合用並行計算來實現。一般而言,為了充分利用並行計算的優勢,通常要對針對任務進行一些開發工作。很多科學問題都可以進行細分,也就是可以將其分解為相對獨立的模塊,以使其可以在各個獨立的節點進行處理。比如,圖像處理任務通常可以再細分,讓每一個節點都可以處理某一部分的圖像。當某一圖像可以被獨立處理時(比如處理這部分圖像不需要其它部分的信息),效果更好。 對於並行計算來說,最危險的缺陷就是將一個計算問題變成了一個通信問題(不管是使用現有的並行運算代碼還是自己新開發代碼)。這種問題一般發生在將任務過分細化,從而使得各個節點為了保持同步而傳輸數據的時間超過了CPU進行計算的時間。在這種情況下,使用更少的節點反而可能會獲得更多的運行時間和更充分地利用資源。這就是說,對於不同的並行應用程序而言,要根據本地節點計算的負載和通信來進行調整和優化。 最後要說的是,在開發並行算法時,如果所使用的集群環境的節點各不相同,那麼就要充分考慮到這個問題。事實上,在運行並行應用程序時,各個節點間CPU的速度是非常關鍵的,因此,在一個配置不同的集群中,只簡單地將任務平均分配,那麼速度比較快的CPU就必須要等待速度比較慢的 CPU完成自己的任務,這顯然是不合理的。因此,設計適當的算法可以很好地處理這種情況,當然,不管采用什麼樣的算法,一定要充分考慮到通信過載問題。 並行處理可以以很多種方式來組織,但是master/Slave的組織方式是最易於理解和編寫程序的。在這種模式中,一個節點作為master,而另外一個則作為Slave。Master節點通常決定如何分割任務,以及指揮信息的傳送,而Slave節點則只負責處理分配到的任務,並在任務完成的時候向master報告。 總結 事實上,在開發並行代碼時,並沒有嚴格的規定,而是要根據實際情況來進行。優化硬件配置和算法的前提是要知道所要運行的應用程序的細節。在各個節點配置不同的集群中,在各個節點中進行負載平衡以及各個節點中的通信都取決於硬件的具體情況。在通信速度快的環境裡,可以將任務分得更細,反之則不宜將任務過分細化。 應該說“Beowulf運動”將並行計算大眾化了。在Beowulf系統中使用標准信息傳送庫開發的並行代碼可以不經過任何更改就直接運行在商業級的超級計算機之上。因此,Beowulf集群可以作為一個入門的切入點,在需要時再將其過渡到大型機上。此外,廉價、通用的集群意味著並行計算機環境可以用於特定的任務,而大型的商業超級計算機由於其過於昂貴,故不可能使其專注於某個單一的應用程序。很顯然,隨著並行環境越來越多地被應用到現實工作,將會更進一步促進其在各個領域的應用。