集群系統圖

㈠ 求集群管理的相關知識！

集群技術案例介紹和具體操作

集群技術案例介紹和具體操作
中國科學院西安網路中心 中科紅旗linux培訓認證中心
集群技術
1.1 什麼是集群
簡單的說，集群（cluster）就是一組計算機，它們作為一個整體向用戶提
供一組網路資源。這些單個的計算機系統就是集群的節點（node）。一個理想的
集群是，用戶從來不會意識到集群系統底層的節點，在他/她們看來，集群是一
個系統，而非多個計算機系統。並且集群系統的管理員可以隨意增加和刪改集群
系統的節點。
1.2 為什麼需要集群
集群並不是一個全新的概念，其實早在七十年代計算機廠商和研究機構就
開始了對集群系統的研究和開發。由於主要用於科學工程計算，所以這些系統並
不為大家所熟知。直到Linux集群的出現，集群的概念才得以廣為傳播。
對集群的研究起源於集群系統良好的性能可擴展性(scalability)。提高CPU
主頻和匯流排帶寬是最初提供計算機性能的主要手段。但是這一手段對系統性能的
提供是有限的。接著人們通過增加CPU個數和內存容量來提高性能，於是出現了
向量機，對稱多處理機(SMP)等。但是當CPU的個數超過某一閾值，象SMP這些
多處理機系統的可擴展性就變的極差。主要瓶頸在於CPU訪問內存的帶寬並不能
隨著CPU個數的增加而有效增長。與SMP相反，集群系統的性能隨著CPU個數的
增加幾乎是線性變化的。圖1顯示了這中情況。
圖1. 幾種計算機系統的可擴展性
對於關鍵業務，停機通常是災難性的。因為停機帶來的損失也是巨大的。下
面的統計數字列舉了不同類型企業應用系統停機所帶來的損失。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
應用系統每分鍾損失(美元)
呼叫中心(Call Center) 27000
企業資源計劃(ERP)系統13000
供應鏈管理(SCM)系統11000
電子商務(eCommerce)系統10000
客戶服務(Customer Service Center)系統27000
圖2：停機給企業帶來的損失
隨著企業越來越依賴於信息技術，由於系統停機而帶來的損失也越拉越大。
集群系統的優點並不僅在於此。下面列舉了集群系統的主要優點：
高可擴展性：如上所述。
高可用性：集群中的一個節點失效，它的任務可傳遞給其他節點。可以有效防止單點失效。
高性能：負載平衡集群允許系統同時接入更多的用戶。
高性價比：可以採用廉價的符合工業標準的硬體構造高性能的系統。
2.1 集群系統的分類
雖然，根據集群系統的不同特徵可以有多種分類方法，但是一般把集群系統分為兩類：
（1）、高可用(High Availability)集群,簡稱HA集群。
這類集群致力於提供高度可靠的服務。就是利用集群系統的容錯性對外提供7*24小時不間
斷的服務，如高可用的文件伺服器、資料庫服務等關鍵應用。
目前已經有在Linux下的高可用集群，如Linux HA項目。
負載均衡集群：使任務可以在集群中盡可能平均地分攤不同的計算機進行處理，充分利
用集群的處理能力，提高對任務的處理效率。
在實際應用中這幾種集群類型可能會混合使用，以提供更加高效穩定的服務。如在一個使
用的網路流量負載均衡集群中，就會包含高可用的網路文件系統、高可用的網路服務。
（2）、性能計算(High Perfermance Computing)集群，簡稱HPC集群，也稱為科學計算
集群。
在這種集群上運行的是專門開發的並行應用程序，它可以把一個問題的數據分布到多
台的計算機上，利用這些計算機的共同資源來完成計算任務，從而可以解決單機不能勝任
的工作（如問題規模太大，單機計算速度太慢）。
這類集群致力於提供單個計算機所不能提供的強大的計算能力。如天氣預報、石油勘探與油
藏模擬、分子模擬、生物計算等。這些應用通常在並行通訊環境MPI、PVM等中開發，由於MPI
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
是目前的標准，故現在多使用MPI為並行環境。
比較有名的集群Beowulf就是一種科學計算集群項目。
3、集群系統轉發方式和調度演算法
3．1轉發方式
目前LVS主要有三種請求轉發方式和八種調度演算法。根據請求轉發方式的不同，所構
架集群的網路拓撲、安裝方式、性能表現也各不相同。用LVS主要可以架構三種形式的集群，
分別是LVS/NAT、LVS/TUN和LVS/DR，可以根據需要選擇其中一種。
（1）、網路地址轉換（LVS/NAT）
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
（2）、直接路由
（3）、IP隧道
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
三種轉發方式的比較：
3．2、調度演算法
在選定轉發方式的情況下，採用哪種調度演算法將決定整個負載均衡的性能表現，不同
的演算法適用於不同的應用場合，有時可能需要針對特殊場合，自行設計調度演算法。LVS的算
法是逐漸豐富起來的，最初LVS只提供4種調度演算法，後來發展到以下八種：
1.輪叫調度（Round Robin）
調度器通過「輪叫」調度演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均
等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。
2.加權輪叫（Weighted Round Robin）
調度器通過「加權輪叫」調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣
可以保證處理能力強的伺服器能處理更多的訪問流量。調度器可以自動詢問真實伺服器的
負載情況，並動態地調整其權值。
3.最少鏈接（Least Connections）
調度器通過「最少連接」調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器
上。如果集群系統的真實伺服器具有相近的系統性能，採用「最小連接」調度演算法可以較
好地均衡負載。
4.加權最少鏈接（Weighted Least Connections）
在集群系統中的伺服器性能差異較大的情況下，調度器採用「加權最少鏈接」調度演算法優
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自
動詢問真實伺服器的負載情況，並動態地調整其權值。
5.基於局部性的最少鏈接（Locality-Based Least Connections）
「基於局部性的最少鏈接」調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache
集群系統。該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該服務
器是可用的且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且
有伺服器處於一半的工作負載，則用「最少鏈接」的原則選出一個可用的伺服器，將請求
發送到該伺服器。
6. 帶復制的基於局部性最少鏈接（ Locality-Based Least Connections with
Replication）
「帶復制的基於局部性最少鏈接」調度演算法也是針對目標IP地址的負載均衡，目前主要
用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組服務
器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。該演算法根據請求的目
標IP地址找出該目標IP地址對應的伺服器組，按「最小連接」原則從伺服器組中選出一
台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接
」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該服
務器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，
以降低復制的程度。
7.目標地址散列（Destination Hashing）
「目標地址散列」調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分
配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，
否則返回空。
8.源地址散列（Source Hashing）
「源地址散列」調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的
散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則
返回空。
了解這些演算法原理能夠在特定的應用場合選擇最適合的調度演算法，從而盡可能地保持
Real Server的最佳利用性。當然也可以自行開發演算法，不過這已超出本文范圍，請參考有
關演算法原理的資料。
4．1、什麼是高可用性
計算機系統的可用性(availability)是通過系統的可靠性(reliability)和可維護性
(maintainability)來度量的。工程上通常用平均無故障時間(MTTF)來度量系統的可靠性，
用平均維修時間（MTTR）來度量系統的可維護性。於是可用性被定義為：
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
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
為了實現集群系統的高可用性，提高系統的高可性，需要在集群中建立冗餘機制。一個功
能全面的集群機構如下圖所示
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
負載均衡伺服器的高可用性
為了屏蔽負載均衡伺服器的失效，需要建立一個備份機。主伺服器和備份機上都運行
High Availability監控程序，通過傳送諸如「I am alive」這樣的信息來監控對方的運
行狀況。當備份機不能在一定的時間內收到這樣的信息時，它就接管主伺服器的服務IP並
繼續提供服務；當備份管理器又從主管理器收到「I am alive」這樣的信息是，它就釋放
服務IP地址，這樣的主管理器就開開始再次進行集群管理的工作了。為在住伺服器失效的
情況下系統能正常工作，我們在主、備份機之間實現負載集群系統配置信息的同步與備份，
保持二者系統的基本一致。
HA的容錯備援運作過程
自動偵測(Auto-Detect)階段 由主機上的軟體通過冗餘偵測線，經由復雜的監聽程序。邏
輯判斷，來相互偵測對方運行的情況，所檢查的項目有：
主機硬體(CPU和周邊)
主機網路
主機操作系統
資料庫引擎及其它應用程序
主機與磁碟陣列連線
為確保偵測的正確性，而防止錯誤的判斷，可設定安全偵測時間，包括偵測時間間隔，
偵測次數以調整安全系數，並且由主機的冗餘通信連線，將所匯集的訊息記錄下來，以供
維護參考。
自動切換(Auto-Switch)階段 某一主機如果確認對方故障，則正常主機除繼續進行原來的
任務，還將依據各種容錯備援模式接管預先設定的備援作業程序，並進行後續的程序及服
務。
自動恢復(Auto-Recovery)階段 在正常主機代替故障主機工作後，故障主機可離線進行修
復工作。在故障主機修復後，透過冗餘通訊線與原正常主機連線，自動切換回修復完成的
主機上。整個回復過程完成由EDI-HA自動完成，亦可依據預先配置，選擇回復動作為半自
動或不回復。
4．2、HA三種工作方式：
（1）、主從方式 （非對稱方式）
工作原理：主機工作，備機處於監控准備狀況；當主機宕機時，備機接管主機的一切工作，
待主機恢復正常後，按使用者的設定以自動或手動方式將服務切換到主機上運行，數據的
一致性通過共享存儲系統解決。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
（2）、雙機雙工方式（互備互援）
工作原理：兩台主機同時運行各自的服務工作且相互監測情況，當任一台主機宕機時，另
一台主機立即接管它的一切工作，保證工作實時，應用服務系統的關鍵數據存放在共享存
儲系統中。
（3）、集群工作方式（多伺服器互備方式）
工作原理：多台主機一起工作，各自運行一個或幾個服務，各為服務定義一個或多個備用
主機，當某個主機故障時，運行在其上的服務就可以被其它主機接管。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
相關文檔
http://tech.sina.com.cn/it/2004-04-09/1505346805.shtml
http://stonesoup.esd.ornl.gov
LINUX下的集群實列應用
最近有客戶需要一個負載均衡方案，筆者對各種軟硬體的負載均衡方案進行了調查和
比較，從IBM sServer Cluster、Sun Cluster PlatForm 等硬體集群，到中軟、紅旗、
TurboLinux的軟體集群，發現無論採用哪個廠商的負載均衡產品其價格都是該客戶目前所
不能接受的。於是筆者想到了開放源項目Linux Virtual Server(簡稱LVS)。經過對LVS的研
究和實驗，終於在Red Hat 9.0上用LVS成功地構架了一組負載均衡的集群系統。整個實
現過程整理收錄如下，供讀者參考。
選用的LVS實際上是一種Linux操作系統上基於IP層的負載均衡調度技術，它在操
作系統核心層上，將來自IP層的TCP/UDP請求均衡地轉移到不同的伺服器，從而將一組
伺服器構成一個高性能、高可用的虛擬伺服器。使用三台機器就可以用LVS實現最簡單的集
群，如圖1所示。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
圖1 LVS實現集群系統結構簡圖
圖1顯示一台名為Director的機器在集群前端做負載分配工作；後端兩台機器稱之為
Real Server，專門負責處理Director分配來的外界請求。該集群的核心是前端的Director
機器，LVS就是安裝在這台機器上，它必須安裝Linux。Real Server則要根據其選用的負
載分配方式而定，通常Real Server上的設置比較少。接下來介紹Director機器上LVS的
安裝過程。
安裝
LVS的安裝主要是在Director機器上進行，Real Server只需針對不同的轉發方式做簡單
的設定即可。特別是對LVS的NAT方式，Real Server惟一要做的就是設一下預設的網關。
所以構架集群的第一步從安裝Director機器開始。
首先，要在Director機器上安裝一個Linux操作系統。雖然早期的一些Red Hat版本，
如6.2、7.2、8.0等自帶Red Hat自己的集群軟體，或者是在內核中已經支持LVS，但是為
了更清楚地了解LVS的機制，筆者還是選擇自行將LVS編入Linux內核的方式進行安裝，
Linux版本採用Red Hat 9.0。
如果用戶對Red Hat的安裝比較了解，可以選擇定製安裝，並只安裝必要的軟體包。
安裝中請選擇GRUB 做為啟動引導管理軟體。因為GRUB 在系統引導方面的功能遠比
LILO強大，在編譯Linux內核時可以體會它的方便之處。
LVS是在Linux內核中實現的，所以要對原有的Linux內核打上支持LVS的內核補丁，
然後重新編譯內核。支持LVS 的內核補丁可以從LVS 的官方網
http://www.linuxvirtualserver.org 下載，下載時請注意使用的Linux核心版本，必須下載和
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
使用的Linux內核版本相一致的LVS內核補丁才行。對於Red Hat 9.0，其Linux內核版本
是2.4.20，所以對應內核補丁應該是http://www.linuxvirtualserver.org/software/kernel-
2.4/linux-2.4.20-ipvs-1.0.9.patch.gz。筆者經過多次實驗，使用Red Hat 9.0自帶的Linux
源代碼無法成功編譯LVS 的相關模組。由於時間關系筆者沒有仔細研究，而是另外從
kernel.org上下載了一個tar包格式的2.4.20內核來進行安裝，順利完成所有編譯。下面是
整個內核的編譯過程：
1.刪除Red Hat自帶的Linux源代碼
# cd /usr/src
# rm -rf linux*
2.下載2.4.20內核
# cd /usr/src
# wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.bz2
3.解壓到當前目錄/usr/src
# cd /usr/src
# tar -xjpvf linux-2.4.20.tar.bz2
4.建立鏈接文件
# cd /usr/src # ln -s linux-2.4.20 linux-2.4 # ln -s linux-2.4.20 linux
5.打上LVS的內核補丁
# cd /usr/src
#wget http://www.linuxvirtualserver.org/software/kernel-2.4/linux-2.4.20-ipvs-
1.0.9.patch.gz
# gzip -cd linux-2.4.20-ipvs-1.0.9.patch.gz
# cd /usr/src/linux
# patch -p1 < ../linux-2.4.20-ipvs-1.0.9.patch
在打補丁時，注意命令執行後的信息，不能有任何錯誤信息，否則核心或模組很可能
無法成功編譯。
6.打上修正ARP問題的內核補丁
# cd /usr/src
# wget http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff
# cd /usr/src/linux
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
# patch -p1 < ../hidden-2.4.20pre10-1.diff
這一步在Director機器上可以不做，但是在使用LVS/TUN和LVS/DR方式的Real Server
上必須做。
7.為新核心命名
打開/usr/src/linux/Makefile。注意，在開始部分有一個變數EXTRAVERSION可以自行定
義。修改這個變數，比如改成「EXTRAVERSION=-LVS」後，編譯出的核心版本號就會顯
示成2.4.20-LVS。這樣給出有含義的名稱將有助於管理多個Linux核心。
8.檢查源代碼
# make mrproper
這一步是為確保源代碼目錄下沒有不正確的.o文件及文件的互相依賴。因為是新下載的內
核，所以在第一次編譯時，這一步實際可以省略。
9.配置核心選項
# make menuconfig
命令執行後會進入一個圖形化的配置界面，可以通過這個友好的圖形界面對內核進行定製。
此過程中，要注意對硬體驅動的選擇。Linux支持豐富的硬體，但對於伺服器而言，用不到
的硬體驅動都可以刪除。另外，像Multimedia devices、Sound、Bluetooth support、Amateur
Radio support等項也可以刪除。
注意，以下幾項配置對LVS非常重要，請確保作出正確的選擇：
(1)Code maturity level options項
對此項只有以下一個子選項，請選中為*，即編譯到內核中去。
Prompt for development and/or incomplete code/drivers
(2)Networking options項
對此項的選擇可以參考以下的配置，如果不清楚含義可以查看幫助：
<*> Packet socket
[ ] Packet socket: mmapped IO
< > Netlink device emulation
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
Network packet filtering (replaces ipchains)
[ ] Network packet filtering debugging
Socket Filtering
<*> Unix domain sockets
TCP/IP networking
IP: multicasting
IP: advanced router
IP: policy routing
[ ] IP: use netfilter MARK value as routing key
[ ] IP: fast network address translation
<M> IP: tunneling
IP: broadcast GRE over IP
[ ] IP: multicast routing
[ ] IP: ARP daemon support (EXPERIMENTAL)
[ ] IP: TCP Explicit Congestion Notification support
[ ] IP: TCP syncookie support (disabled per default)
IP: Netfilter Configuration --->
IP: Virtual Server Configuration --->
(3)Networking options項中的IP: Virtual Server Configuration項
如果打好了LVS的內核補丁，就會出現此選項。進入Virtual Server Configuration選項，
有以下子選項：
<M> virtual server support (EXPERIMENTAL)
IP virtual server debugging
(12) IPVS connection table size (the Nth power of 2)
--- IPVS scheler
<M> round-robin scheling
<M> weighted round-robin scheling
<M> least-connection scheling scheling
<M> weighted least-connection scheling
<M> locality-based least-connection scheling
<M> locality-based least-connection with replication scheling
<M> destination hashing scheling
<M> source hashing scheling
<M> shortest expected delay scheling
<M> never queue scheling
--- IPVS application helper
<M> FTP protocol helper
以上所有項建議全部選擇。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
(4)Networking options項中的IP: Netfilter Configuration項
對於2.4版本以上的Linux Kernel來說，iptables是取代早期ipfwadm和ipchains的
更好選擇，所以除非有特殊情況需要用到對ipchains和ipfwadm的支持，否則就不要選它。
本文在LVS/NAT方式中，使用的就是iptables，故這里不選擇對ipchains和ipfwadm的
支持：
< > ipchains (2.2-style) support
< > ipfwadm (2.0-style) support
10. 編譯內核
(1)檢查依賴關系
# make dep
確保關鍵文件在正確的路徑上。
(2)清除中間文件
# make clean
確保所有文件都處於最新的版本狀態下。
(3)編譯新核心
# make bzImage
(4)編譯模組
# make moles
編譯選擇的模組。
(5)安裝模組
# make moles_install
# depmod -a
生成模組間的依賴關系，以便modprobe定位。
(6)使用新模組
# cp System.map /boot/System.map-2.4.20-LVS
# rm /boot/System.map
# ln -s /boot/System.map-2.4.20-LVS /boot/System.map
# cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20-LVS
# rm /boot/vmlinuz
# ln -s /boot/vmlinuz-2.4.20-LVS /boot/vmlinuz
# new-kernel-pkg --install --mkinitrd --depmod 2.4.20-LVS
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
(7)修改GRUB，以新的核心啟動
執行完new-kernel-pkg命令後，GRUB的設置文件/etc/grub.conf中已經增加了新核心的
啟動項，這正是開始安裝Linux時推薦使用GRUB做引導程序的原因。
grub.conf中新增內容如下：
title Red Hat Linux (2.4.20-LVS)
root (hd0,0)
kernel /boot/vmlinuz-2.4.20LVS ro root=LABEL=/
initrd /boot/initrd-2.4.20LVS.img
將Kernel項中的root=LABEL=/改成 root=/dev/sda1 (這里的/dev/sda1是筆者Linux的根
分區，讀者可根據自己的情況進行不同設置）。
保存修改後，重新啟動系統:
# reboot
系統啟動後，在GRUB的界面上會出現Red Hat Linux(2.4.20-LVS)項。這就是剛才編譯的
支持LVS的新核心，選擇此項啟動，看看啟動過程是否有錯誤發生。如果正常啟動，ipvs
將作為模塊載入。同時應該注意到，用LVS的內核啟動後在/proc目錄中新增了一些文件，
比如/proc/sys/net/ipv4/vs/*。
11.安裝IP虛擬伺服器軟體ipvsadm
用支持LVS的內核啟動後，即可安裝IP虛擬伺服器軟體ipvsadm了。用戶可以用tar包或
RPM 包安裝，tar 包可以從以下地址http://www.linuxvirtualserver.org/software/kernel-
2.4/ipvsadm-1.21.tar.gz 下載進行安裝。
這里採用源RPM包來進行安裝：
# wget http://www.linuxvirtualserver.org/software/kernel-2.4/ipvsadm-1.21-7.src.rpm
# rpmbuild --rebuild ipvsadm-1.21-7.src.rpm
# rpm -ivh /usr/src/redhat/RPMS/i386/ipvsadm-1.21-7.i386.rpm
注意：高版本的rpm命令去掉了--rebuild這個參數選項，但提供了一個rpmbuild命令來實
現它。這一點和以前在Red Hat 6.2中以rpm—rebuild XXX.src.rpm來安裝源RPM包的習
慣做法有所不同。
安裝完，執行ipvsadm命令，應該有類似如下的信息出現：
# ipvsadm
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
中國科學院西安網路中心 中科紅旗linux培訓認證中心
IP Virtual Server version 1.0.9 (size=4096)
Prot LocalAddress:Port Scheler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
出現類似以上信息，表明支持LVS 的內核和配置工具ipvsadm 已完全安裝，這台
Director機器已經初步安裝完成，已具備構架各種方式的集群的條件。
實例
理解了上述關於請求轉發方式和調度演算法的基本概念後，就可以運用LVS來具體實現
幾種不同方式的負載均衡的集群系統。LVS的配置是通過前面所安裝的IP虛擬伺服器軟體
ipvsadm來實現的。ipvsadm與LVS的關系類似於iptables和NetFilter的關系，前者只是
一個建立和修改規則的工具，這些命令的作用在系統重新啟動後就消失了，所以應該將這
些命令寫到一個腳本里，然後讓它在系統啟動後自動執行。網上有不少配置LVS的工具，
有的甚至可以自動生成腳本。但是自己手工編寫有助於更深入地了解，所以本文的安裝沒
有利用其它第三方提供的腳本，而是純粹使用ipvsadm命令來配置。
下面就介紹一下如何配置LVS/NAT、LVS/TUN、LVS/DR方式的負載均衡集群。
1.設定LVS/NAT方式的負載均衡集群
NAT是指Network Address Translation，它的轉發流程是：Director機器收到外界請求，
改寫數據包的目標地址，按相應的調度演算法將其發送到相應Real Server上，Real Server
處理完該請求後，將結果數據包返回到其默認網關，即Director機器上，Dire

㈡ 資料庫集群的應用

一．基於實時數據同步技術
基於此技術構造的資料庫集群是市場上的新興力量，它又具有兩類，分別是：
a.具有獨立網關
下面以DBTwin為例來說明其技術特點。

DBTwin採用了冗餘設計原理，對於來自客戶端的請求，請求被分成兩類：查詢請求和數據更新請求。對於數據更新請求，集群內部各節點之間保持數據的實時同步一致；對於數據的查詢請求，則可以在集群各節點之間負載均衡執行。它的特點是：
a) 負載均衡的單元是客戶端的每個獨立請求，這點除了Oracle RAC集群，是市場上獨有的。
b) 實時冗餘一致的多份數據，從理論上講實現了數據的零丟失。
c) 由於可以做到數據零丟失，因此在系統發生任意故障條件下，可蔽漏昌以做到系統的對外服務不停止。
d) 此系統使用了專用高速數據同步技術，根據測試，數據同步速度能SQL Server的鏡像相等。
e) 此系統的缺點是數據同步需要花費代價,節點數量受到限制，一般2到4個節點為宜。
f) 此系統從宏觀上提升了整個系統的性能。
b.將調度節點集成於資料庫引擎
下面以Moebius來說明其技術特點。
任何在資料庫和應用程序之間引入的中間件都同時引入了單點故障點，如果中間件（網關）出現了故障，則資料庫集群就會形同虛設。因此Moebius在集群中的每個節點上都存在於嵌入於資料庫引擎的分發代理，當前負責調度的分發代理出現故障時，分發代理會故障轉移到集群中的其他節點，從而避免了使用網關架構所引入的單點故障點，除此之外，該類產品的特點是：
a) 負載均衡是基於每個客戶端的獨立請求，默認規則是將查詢優先分發到集群中負載低的伺服器，也可以自定義規則，將某些特定業務分發到集群中的某一台，比如將報表相關的查詢分發給集群中的特定伺服器。
b) 採用Share-Nothing架構，對數據進行冗餘，從而保證了數據的安全性
c) 資料庫同步機制採用日誌Redo的方式，在日誌同步之前對日誌進行壓縮，保證了同步效率
d) 在集群中任意節點出現故障時，會被自動剝離出節點，由剩餘運行正常的節點繼續提供服務，從而保證了最小停機時間
e) 負載均衡集群從宏觀上提高了吞吐量和性能
f) 該類集群不需要特殊的存儲設備，可以使用廉價的本地存儲，但由於數據冗餘，因此相較於Share-Disk架構而言，需要更多的存儲空間
c.沒有獨立網關
當前市場上也存在下列一種基於數據實時同步的集群，其拓撲結構如下圖所示：

此系統由於沒有獨立的集群網關，因此本質上簡化成了資料庫的實時備份系統，與實際的備份系統不同的是，它是工作在資料庫應用層。此系統的特點：
a) 沒有獨立的集群網關，通過主節點的轉發來實行查詢的負載均衡。在系統壓力大的情況下，集群主機會形成性能瓶頸，無論是CPU、內存還是網路帶寬，也可能是OS等系統內核資源，都容易因到達臨界狀態而形成瓶頸。
b) 各節點數據實時一致，對於數據容錯有利。
c) 對客戶端沒有二進制透明。
d) 負載均衡單元是資料庫連接。也就是說，在客戶端登陸資料庫的時候，靜態地指定連接到某個集群節點，此後此連接上的全部請求一律發送到該資料庫上，因此在特殊情況下，可能會出現這樣的場景：所有客戶端的連接集中在集群主機上，這時候，集群主機不但承擔了客戶端的所宏扒有查詢，還需要實時同步數據到所有的集群從機，即集群主機的CPU為100%，而集群別的節點CPU可能為0%，這樣整個系統的性能會受到嚴重影響。
e) 由於使用的是分布式事務機制(MSDTC)確保數據的實時一致性，搜搭因此數據同步的性能比較慢，根據測試,會比SQL Server鏡像慢好幾倍。
f) 同樣地，此集群的節點數量也受到限制，也是以2到4個節點為宜。

㈢ 什麼叫PDT數字集群系統

PDT標準是具有中國自主知識產權的集群通信標准，著眼未來數字對講技術發展之方向，可滿足多數集群通信行業用戶的需求。

PDT標准充分考慮了中國國情，對國際上的成熟標准技術（如Tetra、P25、DMR、MPT1327等）進行了借鑒及創新設計，遵循高性價比、安全保密、大區制、可擴展和向後兼容的五大原則，有效的解決了多種應急通信網融合通信的問題 。

PDT標准由中國公安部牽頭，海能達作為總體組組長並聯合國內其他廠商共同制定的。PDT標准分為集群標准和常規標准兩部分，並向下兼容DMR標准協議。

PDT聯盟成員有海能達（Hytera）、優能、四川維德、廣州維德、萬格通訊、天立通、NTC以及迅安網路系統等。PDT標准主要定位於公共安全、公共事業、工商業等專業用戶群體。

PDT標准採用TDMA（雙時隙）多址方式， 12.5KHz信道間隔、4FSK調制方式、數據傳輸速率慎脊升為9.6Kb/s。在滿足基本業務的同時，增加了同播、動態頻率資源管理等創新功能。PDT第二階段標准將著眼於提升數據傳輸速率，及寬頻業務功能的應用。

(3)集群系統圖擴展閱讀

網格化巡防是「PDT通訊系統」日常指揮調度的重點領域。指揮人員可以在指揮大廳野差對所有巡防車輛、人員的動態軌跡以及屯警點、4G布控點、高清視頻監控區域進行實時監控。

「PDT通訊系統」還可以深度應用於突發事件的妥善處置，指揮人員可以根據實時監控情況，指揮就近人員趕赴現場處置。 「PDT通訊系統」也讓各類重大活動安保維穩工作如虎添翼，在 「萬步有約」職業人群健走激勵大賽及 「絲綢之路」自行車賽等10餘次大型安保中。

現場各類音頻、圖像均通過「PDT通訊系統」實時傳送至分局指揮大廳，為警情的科學研判、精準決策提供第一手資料，確保了調度更科學，指揮更有力，安保更高效。

「警用無線數字集群（PDT）通訊系統」實現了公安無線數字集群語音通訊，實現了簡訊群發功能，實現了PGIS警員、車輛定位功能及車輛歷史軌跡回放功能，增加了數據加密功能。

並且可與全國公安「PDT通訊系統」互聯互通，寬老公安部指令可直接下達到分局民警個人對講機，真正實現警務的扁平化指揮調度。

㈣ 集群分為哪幾種集群的區別在於哪裡

集群通信系統是一種用於集團調度指揮通信的移動通信系統，主要應用在專業移動通信領域。該系統具有的可用信道可為系統的全體用戶共用，具有自動選擇信道功能，它是共享資源、分擔費用、共用信道設備及服務的多用途、高效能的無線調度通信系統。
數字集群的市場定位分為兩種：一是專業用戶市場，二是公眾用戶市場。專業的數字集群用戶一般估計為移動用戶的10%左右，按照中國3億移動用戶估算，也有3000萬用戶的數字集群市場空間。
和傳統的高性能計算機技術相比，集群技術可以利用各檔次的伺服器作為節點，系統造價低，可以實現很高的運算速度，完成大運算量的計算，具有較高的響應能力，能夠滿足當今日益增長的信息服務的需求。
而集群技術是一種通用的技術，其目的是為了解決單機運算能力的不足、IO能力的不足、提高服務的可靠性、獲得規模可擴展能力，降低整體方案的運維成本（運行、升級、維護成本）。只要在其他技術不能達到以上的目的，或者雖然能夠達到以上的目的，但是成本過高的情況下，就可以考慮採用集群技術。

㈤ Linux集群主要有哪幾類

集李亮正群類型
最常見的三種群集類型包括高性能科學群集、負載均衡群集和高可用性群集。
科學群集
通常，第一種涉及為群集開發並行編程應用程序，以解決復雜的科學問題。這是並行計算的基礎，盡管它不使用專門的並行超級計算機，這種超哪悔級計算機內部由十至上萬個獨立處理器組成。但它卻使用商業系統，如通過高速連接來鏈接的一組單處理器或雙處理器 PC，並且在公共消息傳遞層上進行通信以運行並行應用程序。因此，您會常常聽說又有一種便宜的 Linux 超級計算機問世了。但它實際是一個計算機群集，其處理能力與真的超級計算機相等，通常一套象樣的群集配置開銷要超過 $100,000。這對一般人來說似乎是太貴了，但與價值上百萬美元的專用超級計算機相比還算是便宜的。
負載均衡群集
負載均衡群集為企業需求提供了更實用的系統。如名稱所暗示的，該系統使負載可以在計算機群集中盡可能平均地分攤處理。該負載可能是需要均衡的應用程序處理 負載或網路流量負載。這樣的系統非常適合於運行同一組應用程序的大量用戶。每個節點都可以處理一部分負載，並且可以在節點之間動態分配負載，以實現平衡。 對於網路流量也是如此。通常，網路伺服器應用程序接受了太多入網流量，以致無法迅速處理，這就需要將流量發送給在其它節點上運行的網路伺服器應用。還可以 根據每個節點上不同的可用資源或網路的特殊環境來進行優化。
高可用性群集
高可用性群集的出現是為了使群集的整體服務盡可能可用，以便考慮計算硬體和軟體的鍵散易錯性。如果高可用性群集中的主節點發生了故障，那麼這段時間內將由次節 點代替它。次節點通常是主節點的鏡像，所以當它代替主節點時，它可以完全接管其身份，並且因此使系統環境對於用戶是一致的。
在群集的這三種基本類型之間，經常會發生混合與交雜。於是，可以發現高可用性群集也可以在其節點之間均衡用戶負載，同時仍試圖維持高可用性程度。同樣，可 以從要編入應用程序的群集中找到一個並行群集，它可以在節點之間執行負載均衡。盡管集群系統本身獨立於它在使用的軟體或硬體，但要有效運行系統時，硬體連 接將起關鍵作用。
更多知識請網路《Linux就該這么學》

㈥ ⑩ OpenStack高可用集群部署方案(train版)—OpenStack對接Ceph存儲

參考Ceph官方安裝文檔

Openstack環境中，數據存儲可分為臨時性存儲與永久性存儲。

臨時性存儲：主要由本地文件系統提供，並主要用於nova虛擬機的本地系統與臨時數據盤，以及存儲glance上傳的系統鏡像；

永久性存儲：主要由cinder提供的塊存儲與swift提供的對象存儲構成，以cinder提供的塊存儲應用最為廣泛，塊存儲通常以雲盤的形式掛載到虛擬機中使用。

Openstack中需要進行數據存儲的三大項目主要是nova項目（虛擬機鏡像文件），glance項目（共用模版鏡像）與cinder項目（塊存儲）。

下圖為cinder，glance與nova訪問ceph集群的邏輯圖：

ceph與openstack集成主要用到ceph的rbd服務，ceph底層為rados存儲集群，ceph通過librados庫實現對底層rados的訪問；

openstack各項目客戶端調用librbd，再由librbd調用librados訪問底層rados；
實際使用中，nova需要使用libvirtdriver驅動以通過libvirt與qemu調用librbd；cinder與glance可直接調用librbd；

寫入ceph集群的數據被條帶切分成多個object，object通過hash函數映射到pg（構成pg容器池pool），然後pg通過幾圈crush演算法近似均勻地映射到物理存儲設備osd（osd是基於文件系統的物理存儲設備，如xfs，ext4等）。

CEPH PG數量設置與詳細介紹

在創建池之前要設置一下每個OSD的最大PG 數量

PG PGP官方計算公式計算器

參數解釋：

依據參數使用公式計算新的 PG 的數目:
PG 總數= ((OSD總數*100)/最大副本數)/池數
3x100/3/3=33.33 ;舍入到2的N次幕為32

openstack集群作為ceph的客戶端；下面需要再openstack集群上進行ceph客戶端的環境配置

在openstack所有控制和計算節點安裝ceph Octopus源碼包，centos8有默認安裝，但是版本一定要跟連接的ceph版本一致

glance-api 服務運行在3個控制節點， 因此三台控制節點都必須安裝

cinder-volume 與 nova-compute 服務運行在3個計算（存儲）節點； 因此三台計算節點都必須安裝

將配置文件和密鑰復制到openstack集群各節點

配置文件就是生成的ceph.conf；而密鑰是 ceph.client.admin.keyring ，當使用ceph客戶端連接至ceph集群時需要使用的密默認密鑰，這里我們所有節點都要復制，命令如下

※Glance 作為openstack中鏡像服務，支持多種適配器，支持將鏡像存放到本地文件系統，http伺服器，ceph分布式文件系統，glusterfs和sleepdog等開源的分布式文件系統上。目前glance採用的是本地filesystem的方式存儲，存放在默認的路徑 /var/lib/glance/images 下，當把本地的文件系統修改為分布式的文件系統ceph之後，原本在系統中鏡像將無法使用，所以建議當前的鏡像刪除，部署好ceph之後，再統一上傳至ceph中存儲。

※Nova 負責虛擬機的生命周期管理，包括創建，刪除，重建，開機，關機，重啟，快照等，作為openstack的核心，nova負責IaaS中計算重要的職責，其中nova的存儲格外重要，默認情況下，nova將instance的數據存放在/var/lib/nova/instances/%UUID目錄下，使用本地的存儲空間。使用這種方式帶來的好處是:簡單，易實現，速度快，故障域在一個可控制的范圍內。然而，缺點也非常明顯：compute出故障，上面的虛擬機down機時間長，沒法快速恢復，此外，一些特性如熱遷移live-migration,虛擬機容災nova evacuate等高級特性，將無法使用，對於後期的雲平台建設，有明顯的缺陷。對接 Ceph 主要是希望將實例的系統磁碟文件儲存到 Ceph 集群中。與其說是對接 Nova，更准確來說是對接 QEMU-KVM/libvirt，因為 librbd 早已原生集成到其中。

※Cinder 為 OpenStack 提供卷服務，支持非常廣泛的後端存儲類型。對接 Ceph 後，Cinder 創建的 Volume 本質就是 Ceph RBD 的塊設備，當 Volume 被虛擬機掛載後，Libvirt 會以 rbd 協議的方式使用這些 Disk 設備。除了 cinder-volume 之後，Cinder 的 Backup 服務也可以對接 Ceph，將備份的 Image 以對象或塊設備的形式上傳到 Ceph 集群。

使用ceph的rbd介面，需要通過libvirt，所以需要在客戶端機器上安裝libvirt和qemu，關於ceph和openstack結合的結構如下，同時，在openstack中，需要用到存儲的地方有三個:

為 Glance、Nova、Cinder 創建專用的RBD Pools池

需要配置hosts解析文件，這里最開始已經配置完成，如未添加hosts解析需要進行配置

在cephnode01管理節點上操作 ；命名為：volumes，vms，images

記錄：刪除存儲池的操作

在cephnode01管理節點上操作 ；

針對pool設置許可權，pool名對應創建的pool

nova-compute與cinder-volume都部署在計算節點 ，不必重復操作,如果計算節點與存儲節點分離需要分別推送；

全部計算節點配置；以compute01節點為例；

Glance 為 OpenStack 提供鏡像及其元數據注冊服務，Glance 支持對接多種後端存儲。與 Ceph 完成對接後，Glance 上傳的 Image 會作為塊設備儲存在 Ceph 集群中。新版本的 Glance 也開始支持 enabled_backends 了，可以同時對接多個存儲提供商。

寫時復制技術(-on-write) ：內核只為新生成的子進程創建虛擬空間結構，它們復制於父進程的虛擬空間結構，但是不為這些段分配物理內存，它們共享父進程的物理空間，當父子進程中有更改相應的段的行為發生時，再為子進程相應的段分配物理空間。寫時復制技術大大降低了進程對資源的浪費。

全部控制節點進行配置；以controller01節點為例；
只修改涉及glance集成ceph的相關配置

變更配置文件，重啟服務

ceph官網介紹 QEMU和塊設備

對接 Ceph 之後，通常會以 RAW 格式創建 Glance Image，而不再使用 QCOW2 格式，否則創建虛擬機時需要進行鏡像復制，沒有利用 Ceph RBD COW 的優秀特性。

總結

將openstack集群中的glance鏡像的數據存儲到ceph中是一種非常好的解決方案，既能夠保障鏡像數據的安全性，同時glance和nova在同個存儲池中，能夠基於-on-write(寫時復制)的方式快速創建虛擬機，能夠在秒級為單位實現vm的創建。

全部計算節點進行配置； 以compute01節點為例；只修改glance集成ceph的相關配置

全部計算節點重啟cinder-volume服務；

任意openstack控制節點上查看;

在任意控制節點為cinder的ceph後端存儲創建對應的type，在配置多存儲後端時可區分類型；

為ceph type設置擴展規格，鍵值 volume_backend_name ，value值 ceph

任意控制節點上創建一個1GB的卷 ；最後的數字1代表容量為1G

查看創建好的卷

openstack創建一個空白 Volume，Ceph相當於執行了以下指令

從鏡像創建 Volume 的時候應用了 Ceph RBD COW Clone 功能，這是通過 glance-api.conf [DEFAULT] show_image_direct_url = True 來開啟。這個配置項的作用是持久化 Image 的 location，此時 Glance RBD Driver 才可以通過 Image location 執行 Clone 操作。並且還會根據指定的 Volume Size 來調整 RBD Image 的 Size。

一直存在的cirros_qcow2鏡像為對接ceph之前的鏡像，現在已無法使用，所以將之刪除

在openstack上從鏡像創建一個Volume，Ceph相當於執行了以下指令

任意控制節點操作；

查看快照詳細信息

在openstack上對鏡像的卷創建快照，Ceph相當於執行了以下指令

如果說快照時一個時間機器，那麼備份就是一個異地的時間機器，它具有容災的含義。所以一般來說 Ceph Pool backup 應該與 Pool images、volumes 以及 vms 處於不同的災備隔離域。

https://www.cnblogs.com/luohaixian/p/9344803.html

https://docs.openstack.org/zh_CN/user-guide/backup-db-incremental.html

一般的，備份具有以下類型：

在虛擬磁碟映像的計算節點上使用本地存儲有一些缺點：

Nova 為 OpenStack 提供計算服務，對接 Ceph 主要是希望將實例的系統磁碟文件儲存到 Ceph 集群中。與其說是對接 Nova，更准確來說是對接 QEMU-KVM/libvirt ，因為 librbd 早已原生集成到其中。

如果需要從ceph rbd中啟動虛擬機，必須將ceph配置為nova的臨時後端；
推薦在計算節點的配置文件中啟用rbd cache功能；
為了便於故障排查，配置admin socket參數，這樣每個使用ceph rbd的虛擬機都有1個socket將有利於虛擬機性能分析與故障解決；
相關配置只涉及全部計算節點ceph.conf文件的[client]與[client.cinder]欄位，以compute163節點為例

全部計算節點配置 ceph.conf文件相關的 [client] 與 [client.cinder] 欄位，以compute01節點為例；

在全部計算節點配置nova後端使用ceph集群的vms池，以compute01節點為例；

在全部計算節點操作;

在全部計算節點操作，以compute01節點為例；
以下給出libvirtd.conf文件的修改處所在的行num

㈦ 信息檢索論文/文獻信息檢索論文

信息檢索技術論文 – 基於網格的面向專業內容的Web信息檢索 1 引言 近年來，互聯網得到了迅速的發展，網上信息資源愈來愈龐大，且信息具有量大、分散、異構等特性，因此，傳統的Web信息檢索工具開始暴露出它性能低下的一面，具體體現在現有的信息檢索工具對用戶的要求常常是找出了幾千甚至上萬條記錄，根本無法從中再細找，或者找到的內容和要找的內容不是一個專業領域的，造成信息無效的現象。但隨著人們信息意識的增強，對信息內容及信息服務的需求也在不斷的演變和發展，對獲取信息的專業化、實效性等方面有了新的要求。如何針對專業領域中特定的用戶群為他們提供專業的、度身量造的信息服務，使用戶在盡可能短的態冊時間內有效的找到最需要的信息內容是大家普遍關注的一個問題。本文利用網格計算、集群系統、XML等技術設計了一個基於網格的面向專業內容的Web信息檢索體系結構，它能將地理位置分散的、異構的信息按地區按專業內容從邏輯上進行合理的組織和管理，為用戶快速、有效地獲取自己所需要的信息提供了一種方法。 2 基於網格的面向專業內容的Web信息檢索體系結構的設計 網格計算是近年來國際上興起的一種重要信息技術，其目的是將網上各種資源組織在一個統一的大框架下，為解決大型復雜計算、數據服務和各種網路信息服務提供一個方便用戶使用的虛擬平台，實現互聯網上所有資源的全面連通，實現信息資源的全面共享。 為解決不同領域復雜科學計算與海量信息服務問題，人們以網路互連為基礎構造了不同的網格，他們在體系結構，要解決的問題類型等方面各不相同，但網格計算至少需要具有三種基本功能：資源管理、任務管理、任務調度。本文設計的信息檢索體系結構，圍繞網格計算的基本功能及信息檢索的特點，主要有以下三個層次組成：見圖1 （1） 網格結點：結點是網格計算資源的提供者，本系統主要是由一系列的集群系統組成，它們在地理位置上是分布的，構成了一個分布檢索群體，作為信息共享的基礎結構平台。集群系統負責整個集群范圍內的信息管理，維護和查詢。 （2） 網格計算中間件：中間件是信息資源管理和用戶任務調度、任務管理的工具。它是整個網格信息資源管理的核心部分，它根據用戶的信息請求任務，在整個網格內負責信息資源的匹配、定位，實現用戶任務到集群系統的映射。 （3） 網格用戶層：主要為用喊臘戶應用提供介面，支持用戶對所需要的信息資源進行描述、創建、提交等。 圖1 本系統的主要思想是在邏輯上將地理位置分散的、異構的信息劃分、組建成多個集群系統，集群系統對集群內的資源進行管理和任務調度，再利用網格中間件對各集群系統進行管理，從而形成對整個網格資源的管理，並對用戶的信息需求進行統一的管理和調度。這種管理模型既可以尊重各個集群系統的本地信息管理策略，又可利用中間件在全局意義上對網格信息資源進行管理。 2.1 集群系統的設計 由於Web信息資源數量十分龐大，用戶在利用現有搜索引擎檢索信息時面臨一個海量數據的查詢問題，往往造成在消耗巨大的通信資源後依然存在資源查不準、查不全的問題。目前基於單一系統映射的Web伺服器集群系統能把若干伺服器用區域網連接成一個整體，並使其從客戶端看來就如同一台伺服器在服務，這使得在邏輯上合並、組織地理位置分布的信息資源成為可能。因此本文首先考慮採用分布協作策略，將Web信息資源按地區按專業內容分割，一方面使信息鄭閉滑資源數量相對縮小，便於數據的組織、管理和維護，另一方面按專業內容易於制定一個公用的XML規范，便於集群內各類信息資源的描述，從而可建立一個基於XML的面向專業內容的信息集成系統。集群系統的具體結構見圖2。 集群伺服器主要由介面Agent，基於專業內容的XML信息集成系統、資源服務Agent、資源發布Agent等組成。其中介面Agent根據任務提供的介面參數登記、接收、管理各種信息資源請求任務，並提供安全認證和授權。資源服務Agent根據信息資源請求任務，利用XML信息集成系統提供的數據，為用戶提供實際的資源檢索操作，並將檢索結果信息發送給用戶。資源發布Agent用於向網格中間件提供本地信息資源的邏輯數據及介面參數。 下面主要說明基於專業內容的XML信息集成系統的構造方法： XML（the eXtensible Markup Language）是 W3C於1998年宣布作為Internet上數據表示和數據交換的新標准，它是一種可以對信息進行自我描述的語言，它允許開發人員通過創建格式文件DTD（Document Type Definitions）定製標記來描述自己的數據，DTD規范是一個用來定義XML文件的語法、句法和數據結構的標准。 XML使用普通文本，因此具有跨平台的優點，XML的優點在於（1）簡單、規范性：XML文檔基於文本標簽，有一套嚴謹而簡潔的語法結構，便於計算機、用戶理解；（2）可擴展性：用戶可以自定義具有特定意義的標簽，自定義的標簽可以在任何組織、客戶、應用之間共享；（3）自描述性：自描述性使其非常適用不同應用間的數據交換，而且這種交換是不以預先定義一組數據結構為前提，因此具有很強的開放性；（4）互操作性：XML可以把所有信息都存於文檔中傳輸，而遠程的應用程序又可以從中提取需要的信息。XML數據是不依賴於某個特定的平台的應用，因此它為基於特定專業內容的表達提供了一種極好的手段，可以作為表示專業內容的語言。 目前人們研製Web信息集成系統其基本方法可分成兩類：存入倉庫法（the ware-housing approach）和虛擬法(the virtual approach)，可使用這兩類方法利用XML在數據組織和交換方面的優越性，採用格式文件DTD和XML文檔表示基於專業內容的集成模式和集成模式與資源之間的映射，建立基於XML的Web信息集成系統，其結構與獲取信息的工作過程參見文獻[2]。 圖2 2.2 網格中間件的設計 圖3所示的網格中間件的主要功能是（1）消除不同用戶與集群系統之間數據表達的差異，使信息資源數據對用戶來說是透明的；（2）管理、維護Web上分布的各集群系統，網格中間件以關系資料庫方式記錄所有集群系統及其所包含的專業內容的邏輯信息，對關系資料庫的操作可維護集群系統的分布式邏輯，使本結構在可變性和擴充性上具有柔性；（3）接受用戶的信息請求任務，能快速定位於滿足要求的集群系統，通過對關系資料庫的查詢實現用戶信息請求任務與集群系統的對應關系。 內部主要功能模塊說明如下： （1） 接收Agent模塊：主要用於登記、接收、管理各種信息資源請求任務，並提供安全認證和授權。 （2） 關系資料庫及數據服務Agent：關系資料庫記錄了所有集群系統及其所包含的專業內容的邏輯信息。數據服務Agent提供集群系統對關系資料庫的使用許可權和對數據記錄的增加、刪除、檢索和修改等操作。 （3） 格式轉換Agent模塊：提供用戶信息資源請求文檔與各集群系統中文檔的格式轉換功能。由於XML是自定義的，各用戶對同一數據有不同的表示方法（對信息資源描述存在差異）由於XML文檔中這種格式差異體現在與之相關的DTD/Schema上，因此經過格式轉換，可使信息資源的格式對用戶是透明的。 （4） XML文檔分析Agent模塊：提取格式轉換後的XML文檔中各個標簽，通過查詢網格中間件中的關系資料庫，實現用戶信息請求任務與集群系統的對應關系，並得到滿足條件的集群系統的相關信息，獲取各集群系統的介面參數。 （5） 發送Agent模塊：將轉換過的信息資源請求XML文檔發送到相應的集群系統中。 其中Agent技術是解決分布式智能應用問題的關鍵技術，Agent是指能夠自主地、連續地在一動態變化的、存在於其它系統中運行的、且不斷於環境交互的實體。在系統中引入Agent可使系統具有人的特徵，代表用戶完成用戶的任務，並能動態適應環境的變化更好地滿足用戶的需求，提高信息檢索的能力。

㈧ 怎麼樣做集群服務如題 謝謝了

集群，英文名稱為Cluster，通俗地說，集群是這樣一種技術：它至少將兩個系統連接到一起，使兩台伺服器能夠像一台機器那樣工作或者看起來好像一台機器。採用集群系統通常是為了提高系統的穩定性和網路中心的數據處理能力及服務能力。 舉個例子來說，我們架設了一台WWW伺服器，上面構建了一個電子商務網站，然而隨著時間的推移，名聲越來越大，這時點擊率也就越來越高，WWW伺服器的負載也就越來越高。這種情況下，我們就必須提升WWW伺服器的能力，以滿足以益增長的服務請求。這時，我們就面臨兩種選擇： 1）升級WWW伺服器，採用更快的CPU，增加更多的內存，使其具有更強的性能；但日益增長的服務請求又會使伺服器再次過載，需要再次升級，這樣就陷入了升級的怪圈。還有，升級時還得考慮到服務如何接續，能否中止！ 2）增加WWW伺服器，讓多台伺服器來完成相同的服務。 第二種方法就是伺服器集群，簡而言之，就是一組相互獨立的伺服器在網路中表現為單一的系統，並以單一系統的模式加以管理。此單一系統為客戶工作站提供高可靠性的服務。一個伺服器集群包含多台擁有共享數據存儲空間的伺服器，各伺服器之間通過內部區域網進行相互通信；當其中一台伺服器發生故障時，它所運行的應用程序將由其他的伺服器自動接管；在大多數情況下，集群中所有的計算機都擁有一個共同的名稱，集群系統內任意一台伺服器都可被所有的網路用戶所使用。在集群系統中運行的伺服器並不一定是高檔產品，但伺服器的集群卻可以提供相當高性能的不停機服務；每一台伺服器都可承擔部分計算任務，並且由於群集了多台伺服器的性能，因此，整體系統的計算能力將有所提高；同時，每台伺服器還能承擔一定的容錯任務，當其中某台伺服器出現故障時，系統可以在專用軟體的支持下將這台伺服器與系統隔離，並通過各伺服器之間的負載轉移機制實現新的負載平衡，同時向系統管理員發出報警信號。 目前，有兩種常用的伺服器集群方法，一種是將備份伺服器連接在主伺服器上,當主伺服器發生故障時,備份伺服器才投入運行,把主伺服器上所有任務接管過來。另一種方法是將多台伺服器連接,這些伺服器一起分擔同樣的應用和資料庫計算任務,改善關鍵大型應用的響應時間。同時,每台伺服器還承擔一些容錯任務,一旦某台伺服器出現故障時,系統可以在系統軟體的支持下,將這台伺服器與系統隔離,並通過各伺服器的負載轉嫁機制完成新的負載分配。PC伺服器中較為常見的是兩台伺服器的集群,UNIX系統可支持8台伺服器的集群系統,康柏的專用系統OpenVMS可支持多達96台伺服器的集群系統。 在集群系統中，所有的計算機擁有一個共同的名稱，集群內任一系統上運行的服務可被所有的網路客戶所使用。集群必須可以協調管理各分離組件的錯誤和失敗，並可透明的向集群中加入組件。用戶的公共數據被放置到了共享的磁碟櫃中，應用程序被安裝到了所有的伺服器上，也就是說，在集群上運行的應用需要在所有的伺服器上安裝一便。當集群系統在正常運轉時，應用只在一台伺服器上運行，並且只有這台伺服器才能操縱該應用在共享磁碟櫃上的數據區，其它的伺服器監控這台伺服器，只要這台伺服器上的應用停止運行（無論是硬體損壞、操作系統死機、應用軟體故障，還是人為誤操作造成的應用停止運行），其它的伺服器就會接管這台伺服器所運行的應用，並將共享磁碟櫃上的相應數據區接管過來。其接管過程如下圖所示（以應用A為例）： 1.應用A正常工作時； 2.應用A停止工作後，其它的備用伺服器將該應用接管過來。 具體接管過程分三部執行： a.系統接管 b.載入應用 c.客戶端連接 集群系統的優勢在於以下幾點： 一、集群系統可解決所有的伺服器硬體故障，當某一台伺服器出現任何故障，如：硬碟、內存、CPU、主板、I/O板以及電源故障，運行在這台伺服器上的應用就會切換到其它的伺服器上。 二、集群系統可解決軟體系統問題，我們知道，在計算機系統中，用戶所使用的是應用程序和數據，而應用系統運行在操作系統之上，操作系統又運行在伺服器上。這樣，只要應用系統、操作系統、伺服器三者中的任何一個出現故障，系統實際上就停止了向客戶端提供服務，比如我們常見的軟體死機，就是這種情況之一，盡管伺服器硬體完好，但伺服器仍舊不能向客戶端提供服務。而集群的最大優勢在於對故障伺服器的監控是基於應用的，也就是說，只要伺服器的應用停止運行，其它的相關伺服器就會接管這個應用，而不必理會應用停止運行的原因是什麼。 三、集群系統可以解決人為失誤造成的應用系統停止工作的情況，例如，當管理員對某台伺服器操作不當導致該伺服器停機，因此運行在這台伺服器上的應用系統也就停止了運行。由於集群是對應用進行監控，因此其它的相關伺服器就會接管這個應用。 集群系統的不足之處在於： 我們知道集群中的應用只在一台伺服器上運行，如果這個應用出現故障，其它的某台伺服器會重新啟動這個應用，接管位於共享磁碟櫃上的數據區，進而使應用重新正常運轉。我們知道整個應用的接管過程大體需要三個步驟：偵測並確認故障、後備伺服器重新啟動該應用、接管共享的數據區。因此在切換的過程中需要花費一定的時間，原則上根據應用的大小不同切換的時間也會不同，越大的應用切換的時間越長

㈨ 常見ClickHouse集群部署架構

ClickHouse不同於Elasticsearch、HDFS這類主從架構的分布式系統，它採用多主（無中心）架構，集群中的每個節點角色對等，客戶端訪問任意一個節點都能得到相同的效果。

ClickHouse藉助分片將數據進行橫向切分，而分片依賴集群，每個集群由1到多個分片組成，每個分片對應了CH的1個服務節點；分片數量的上限取決與節點數量（1個分片只能對應1個服務節點）。

但是ClickHouse並不像其他分布式系統那樣，擁有高度自動化的分片功能；CH提供了本地表與分布式表的概念；一張本地表等同於一個數據分片。而分布式表是張邏輯表，本身不存儲任何數據，它是本地表的訪問代理，其作用類似分庫中間件。藉助分布式表，能夠代理訪問多個數據分片，從而實現分布式查詢。當然，也可以在應用層實現數據分發。

ClickHouse同時支持數據副本，其副本概念與Elasticsearch類似，但在CH中分片其實是一種邏輯概念，其物理承載是由副本承擔的。

ClickHouse的數據副本一般通過ReplicatedMergeTree復製表系列引擎實現，副本之間藉助ZooKeeper實現數據的一致性。此外也可通過分布式表負責同時進行分片和副本的數據寫入工作。

以四節點實現多分片和雙副本為例：

（上圖中shard作為主副本）
在每個節點創建一個數據表，作為一個數據分片，使用ReplicatedMergeTree表引擎實現數據副本，而分布表橋陵作為數據寫入和查詢的入口。
這是最常見的集群實現方式。

在每個節點創建一個數據表，作為一個數據分片，分布表同時負責分片和副本的數據寫入工作。
這種實現方案下，不需要使用復製表，但分布表節點需要同時負責分片和副本的數據寫入工閉消鏈作，它很有可能稱為寫入的單點瓶頸。

在每個節點創建一個數據表，作為一個數據分片，同時創建兩個分布表，每個分布表只納管一半的數據。
副本的實現仍需要藉助ReplicatedMergeTree類表引擎。

在每個節點創建兩個數據表，同一數據分片的兩個副本位於不同節點上，每個分布式表納管一般的數據。
這種方案可以在更少的節點上實現數據分布與冗餘，但是部署上略轎孫顯繁瑣。

㈩ 怎麼搭建兩個hadoop集群的測試環境

環境配置：
虛擬機：
vmware workstation 12
系統：
ubuntu 16.04 LTS（推薦使用原版，不要用kylin）
節點： 192.168.159.132 master 192.168.159.134 node1 192.168.159.137 node2
jdk-8u101-Linux-x64.gz (Java)hadoop-2.7.3.tar.gz (Hadoop 包)
安裝步驟：
1、安裝虛擬機系統，並進行准備工作（可安裝一個然後克隆）
2.修改各個虛擬機的hostname和host
3.創建用戶組和用戶
4、配置虛擬機網路，使虛擬機系統之間以及和host主機之間可以通過相互ping通。
5.安裝jdk和配置環境變數，檢查是否配置成功
6、配置ssh，實現節點間的無密碼登錄 ssh node1/2指令驗證時候成功
7、master配置hadoop，並將hadoop文件傳輸到node節點
8、配置環境變數，並啟動hadoop，檢查是否安裝成功，執行wordcount檢查是否成功。

1.安裝虛擬機

在VM上安裝下載好的Ubuntu的系統，具體過程自行網路。可以安裝完一個以後克隆，但是本人安裝過程中遇到很多問題，經常需要刪除虛擬機，重新安裝，而被克隆的虛擬機不能刪除，所以本人就用了很長時候，一個一個安裝。

一共3台虛擬機：分配情況和IP地址如下：

（註：查看ip地址的指令 ifconfig）

安裝虛擬機時可以設置靜態IP，因為過程中常常遇到網路連接問題,ifconfig找不到IPV4地址。當然，也可以不設，默認分配。

192.168.159.132 master 192.168.159.134 node1 192.168.159.137 node2

2.修改虛擬機的hostname和hosts文件

以master上機器為例，打開終端，執行如下的操作，把hostname修改成master，hosts修改成如下所示的樣子：

#修改hostname的指令：sudo gedit /etc/hostname
#修改hosts指令：sudo gedit /etc/hosts
#將以下內容添加到hosts中192.168.159.132 master192.168.159.134 node1192.168.159.137 node2

如下圖所示:

自此，hadoop集群搭建成功！