資料庫集群原理
Ⅰ 資料庫中的集群和F5
分布式資料庫系統分布式資料庫系統有兩種：一種是物理上分布的，但邏輯上卻是集中的。這種分布式資料庫只適宜用途比較單一的、不大的單位或部門。另一種分布式資料庫系統在物理上和邏輯上都是分布的，也就是所謂聯邦式分布資料庫系統。由於組成聯邦的各個子資料庫系統是相對「自治」的，這種系統可以容納多種不同用途的、差異較大的資料庫，比較適宜於大范圍內資料庫的集成。
----- ----
分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)。在分布式資料庫系統中，一個應用程序可以對資料庫進行透明操作，資料庫中的數據分別在不同的局部資料庫中存儲、由不同的 DBMS進行管理、在不同的機器上運行、由不同的操作系統支持、被不同的通信網路連接在一起。
一個分布式資料庫在邏輯上是一個統一的整體，在物理上則是分別存儲在不同的物理節點上。一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫。它的分布性表現在資料庫中的數據不是存儲在同一場地。 更確切地講，不存儲在同一計算機的存儲設備上。 這就是與集中式資料庫的區別。從用戶的角度看，一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣，用戶可以在任何一個場地執行全局應用。就好那些數據是存儲在同一台計算機上，有單個資料庫管理系統(DBMS)管理一樣，用戶並沒有什麼感覺不一樣。
分布式資料庫系統是在集中式資料庫系統的基礎上發展起來的，是計算機技術和網路技術結合的產物。分布式資料庫系統適合於單位分散的部門，允許各個部門將其常用的數據存儲在本地，實施就地存放本地使用，從而提高響應速度，降低通信費用。分布式資料庫系統與集中式資料庫系統相比具有可擴展性，通過增加適當的數據冗餘，提高系統的可靠性。在集中式資料庫中，盡量減少冗餘度是系統目標之一．其原因是，冗餘數據浪費存儲空間，而且容易造成各副本之間的不一致性．而為了保證數據的一致性，系統要付出一定的維護代價．減少冗餘度的目標是用數據共享來達到的。而在分布式資料庫中卻希望增加冗餘數據，在不同的場地存儲同一數據的多個副本,其原因是：①．提高系統的可靠性、可用性當某一場地出現故障時，系統可以對另一場地上的相同副本進行操作，不會因一處故障而造成整個系統的癱瘓。②．提高系統性能系統可以根據距離選擇離用戶最近的數據副本進行操作，減少通信代價，改善整個系統的性能。
分布式資料庫具有以下幾個特點：
(1)、數據獨立性與位置透明性。數據獨立性是資料庫方法追求的主要目標之一，分布透明性指用戶不必關心數據的邏輯分區，不必關心數據物理位置分布的細節，也不必關心重復副本（冗餘數據）的一致性問題，同時也不必關心局部場地上資料庫支持哪種數據模型．分布透明性的優點是很明顯的．有了分布透明性，用戶的應用程序書寫起來就如同數據沒有分布一樣．當數據從一個場地移到另一個場地時不必改寫應用程序．當增加某些數據的重復副本時也不必改寫應用程序．數據分布的信息由系統存儲在數據字典中．用戶對非本地數據的訪問請求由系統根據數據字典予以解釋、轉換、傳送．
(2)、集中和節點自治相結合。資料庫是用戶共享的資源．在集中式資料庫中，為了保證資料庫的安全性和完整性，對共享資料庫的控制是集中的，並設有DBA負責監督和維護系統的正常運行．在分布式資料庫中，數據的共享有兩個層次：一是局部共享，即在局部資料庫中存儲局部場地上各用戶的共享數據．這些數據是本場地用戶常用的．二是全局共享，即在分布式資料庫的各個場地也存儲可供網中其它場地的用戶共享的數據，支持系統中的全局應用．因此，相應的控制結構也具有兩個層次：集中和自治．分布式資料庫系統常常採用集中和自治相結合的控制結構,各局部的DBMS可以獨立地管理局部資料庫，具有自治的功能．同時，系統又設有集中控制機制，協調各局部DBMS的工作，執行全局應用。當然,不同的系統集中和自治的程度不盡相同．有些系統高度自治，連全局應用事務的協調也由局部DBMS、局部DBA共同承擔而不要集中控制，不設全局DBA,有些系統則集中控製程度較高，場地自治功能較弱。
(3)、支持全局資料庫的一致性和和可恢復性。分布式資料庫中各局部資料庫應滿足集中式資料庫的一致性、可串列性和可恢復性。除此以外還應保證資料庫的全局一致性、並行操作的可串列性和系統的全局可恢復性。這是因為全局應用要涉及兩個以上結點的數據．因此在分布式資料庫系統中一個業務可能由不同場地上的 多個操作組成．例如, 銀行轉帳業務包括兩個結點上的更新操作。這樣，當其中某一個結點出現故障操作失敗後如何使全局業務滾回呢？如何使另一個結點撤銷已執行的操作(若操作已完成或完成一部分）或者不必再執行業務的其它操作(若操作尚沒執行)？這些技術要比集中式資料庫復雜和困難得多，分布式資料庫系統必須解決這些問題．
(4)、復制透明性。用戶不用關心資料庫在網路中各個節點的復制情況，被復制的數據的更新都由系統自動完成。在分布式資料庫系統中，可以把一個場地的數據復制到其他場地存放，應用程序可以使用復制到本地的數據在本地完成分布式操作，避免通過網路傳輸數據，提高了系統的運行和查詢效率。但是對於復制數據的更新操作，就要涉及到對所有復制數據的更新。
(5)、易於擴展性。在大多數網路環境中，單個資料庫伺服器最終會不滿足使用。如果伺服器軟體支持透明的水平擴展，那麼就可以增加多個伺服器來進一步分布數據和分擔處理任務。
分布式資料庫的優點：
(1)具有靈活的體系結構 。
(2)適應分布式的管理和控制機構。
(3)經濟性能優越 。
(4)系統的可靠性高、可用性好 。
(5)局部應用的響應速度快。
(6)可擴展性好，易於集成現有系統。
分布式資料庫的缺點：
(1)系統開銷大，主要花在通信部分。
(2)復雜的存取結構，原來在集中式系統中有效存取數據的技術，在分成式系統中都不再適用。
(3)數據的安全生和保密性較難處理。
分布式資料庫系統的目標
分布式資料庫系統的目標，也就是研製分布式資料庫系統的目的、動機，主要包括技術和組織兩方面的目標．
1．適應部門分布的組織結構，降低費用。
使用資料庫的單位在組織上常常是分布的（如分為部門、科室、車間等等），在地理上也是分布的．分布式資料庫系統的結構符合部門分布的組織結構，允許各個部門對自己常用的數據存儲在本地，在本地錄入、查詢、維護，實行局部控制．由於計算機資源靠近用戶，因而可以降低通信代價，提高響應速度，使這些部門使用資料庫更方便更經濟。
2．提高系統的可靠性和可用性。
改善系統的可靠性和可用性是分布式資料庫的主要目標．將數據分布於多個場地，並增加適當的冗餘度可以提供更好的可靠性．一些可靠性要求較高的系統，這一點尤其重要．因為一個地出了故障不會引起整個系統崩潰．因為故障場地的用戶可以通過其它場地進入系統．而其它場地的用戶可以由系統自動選擇存取路徑，避開故障場地，利用其它數據副本執行操作，不影響業務的正常運行．
3．充分利用資料庫資源，提高現有集中式資料庫的利用率
當在一個大企業或大部門中已建成了若干個資料庫之後，為了利用相互的資源，為了開發全局應用，就要研製分布式資料庫系統．這種情況可稱為自底向上的建立分布式系統．這種方法雖然也要對各現存的局部資料庫系統做某些改動、重構，但比起把這些資料庫集中起來重建一個集中式資料庫，則無論從經濟上還是從組織上考慮，分布式資料庫均是較好的選擇．
4．逐步擴展處理能力和系統規模
當一個單位規模擴大要增加新的部門(如銀行系統增加新的分行，工廠增加新的科室、車間)時，分布式資料庫系統的結構為擴展系統的處理能力提供了較好的途徑：在分布式資料庫系統中增加一個新的結點．這樣做比在集中式系統中擴大系統規模要方便、靈活、經濟得多。
在集中式系統中為了擴大規模常用的方法有兩種：一種是在開始設計時留有較大的餘地．這容易造成浪費，而且由於預測困難，設計結果仍可能不適應情況的變化．另一種方法是系統升級，這會影響現有應用的正常運行．並且當升級涉及不兼容的硬體或系統軟體有了重大修改而要相應地修改已開發的應用軟體時，升級的代價就十分昂貴而常常使得升級的方法不可行．分布式資料庫系統能方便地把一個新的結點納入系統，不影響現有系統的結構和系統的正常運行，提供了逐漸擴展系統能力的較好途徑，有時甚至是唯一的途徑。
①資料庫系統與應用 趙致格編著 清華大學出版社p. 260
②資料庫原理及應用 張晉連 編著 電子工業出版社P.13
Ⅱ 資料庫集群的應用
一．基於實時數據同步技術
基於此技術構造的資料庫集群是市場上的新興力量，它又具有兩類，分別是：
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個節點為宜。
Ⅲ 什麼是MySQL集群帶你全面掌握MySQL集群原理
如果Master收橋瞎到所有 Slave的OK消息，它就會向所有Slave發送提交消息，告訴Slave提交該事務；
如果Slave收到提交請求，它們就會提交事務，並向Master發送事務已提交 的確認；
如果Slave收到取消請求,它們就會撤銷所有改變並釋放所佔有的資源，從而中止事務，然後向Masterv送敏吵空事務已中止的確認。
隨著計算機和信息技術的迅猛發展和普及，行業應用系統的規模迅速擴大，行業應用所產生的數據量量呈爆炸式增長，類似於MySQL集群這樣的技術得到了廣泛的運用，MySQL集群原理的運用就顯得尤其重要。
動力節點的MySQL集群教程 ，對於MySQL集群技術的應用場景有著詳細的介紹，能夠有效幫助我們學以致用， 教程主要從MySQL集群架構解析到架構部署再到集群架構測試，一步步帶你部署企業級的MySQL資料庫集群項目，熟悉各個環節技術點，提升資料庫架構設計能力。
https://www.bilibili.com/video/BV1Rg4y1i7VR
http://www.bjpowernode.com/?toutiao
•001.MySQL集群視頻教程：主從復制介紹
•002.MySQL集群視頻教程：主從復制結構
•003.MySQL集群視頻教程：主從復制流程原碰敗理
•004.MySQL集群視頻教程：多實例安裝
•005.MySQL集群視頻教程：多實例鏈接
•006.MySQL集群視頻教程：一主多從-配置
•007.MySQL集群視頻教程：-一主多從測試
•008.MySQL集群視頻教程：雙主雙從配置
•009.MySQL集群視頻教程：雙主雙從測試
•010.MySQL集群視頻教程：多數據源-環境搭建
•011.MySQL集群視頻教程：多算數據源實現
•012.MySQL集群視頻教程：修復MySLQ主從復制
•013.MySQL集群視頻教程：多數據源的問題
•014.MySQL集群視頻教程：動態數據源
•015.MySQL集群視頻教程：動態數據源執行流程
•016.MySQL集群視頻教程：SpringBoot集成多數據源
•017.MySQL集群視頻教程：SpringBoot集成多數據源問題
•018.MySQL集群視頻教程：SpringBoot集成動態數據源
Ⅳ 如何保證資料庫集群中id的唯一性，假設每秒鍾並發20萬次
用雪花演算法的工具類,1秒內可以生成26萬不重復的值,資料庫的主鍵不要自增,手動設置
java">packageentity;
importjava.lang.management.ManagementFactory;
importjava.net.InetAddress;
importjava.net.NetworkInterface;
/**
*<p>名稱：IdWorker.java</p>
*<p>描述：分布式自增長ID</p>
*<pre>
*Twitter的SnowflakeJAVA實現方案
*</pre>
*核心代碼為其IdWorker這個類實現，其原理結構如下，我分別用一個0表示一位，用—分割開部分的作用：
*1||0------00000---00000---000000000000
*在上面的字元串中，第一位為未使用（實際上也可作為long的符號位），接下來的41位為毫秒級時間，
*然後5位datacenter標識位，5位機器ID（並不算標識符，實際是為線程標識），
*然後12位該毫秒內的當前毫秒內的計數，加起來剛好64位，為一個Long型。
*這樣的好處是，整體上按照時間自增排序，並且整個分布式系統內不會產生ID碰撞（由datacenter和機器ID作區分），
*並且效率較高，經測試，snowflake每秒能夠產生26萬ID左右，完全滿足需要。
*<p>
*64位ID(42(毫秒)+5(機器ID)+5(業務編碼)+12(重復累加))
*
*@authorPolim
*/
publicclassIdWorker{
//時間起始標記點，作為基準，一般取系統的最近時間（一旦確定不能變動）
privatefinalstaticlongtwepoch=1288834974657L;
//機器標識位數
=5L;
//數據中心標識位數
=5L;
//機器ID最大值
=-1L^(-1L<<workerIdBits);
//數據中心ID最大值
=-1L^(-1L<<datacenterIdBits);
//毫秒內自增位
=12L;
//機器ID偏左移12位
=sequenceBits;
//數據中心ID左移17位
=sequenceBits+workerIdBits;
//時間毫秒左移22位
=sequenceBits+workerIdBits+datacenterIdBits;
=-1L^(-1L<<sequenceBits);
/*上次生產id時間戳*/
=-1L;
//0，並發控制
privatelongsequence=0L;
privatefinallongworkerId;
//數據標識id部分
privatefinallongdatacenterId;
publicIdWorker(){
this.datacenterId=getDatacenterId(maxDatacenterId);
this.workerId=getMaxWorkerId(datacenterId,maxWorkerId);
}
/**
*@paramworkerId
*工作機器ID
*@paramdatacenterId
*序列號
*/
publicIdWorker(longworkerId,longdatacenterId){
if(workerId>maxWorkerId||workerId<0){
(String.format("workerIdcan'tbegreaterthan%dorlessthan0",maxWorkerId));
}
if(datacenterId>maxDatacenterId||datacenterId<0){
(String.format("datacenterIdcan'tbegreaterthan%dorlessthan0",maxDatacenterId));
}
this.workerId=workerId;
this.datacenterId=datacenterId;
}
/**
*獲取下一個ID
*
*@return
*/
publicsynchronizedlongnextId(){
longtimestamp=timeGen();
if(timestamp<lastTimestamp){
thrownewRuntimeException(String.format("Clockmovedbackwards.Refusingtogenerateidfor%dmilliseconds",lastTimestamp-timestamp));
}
if(lastTimestamp==timestamp){
//當前毫秒內，則+1
sequence=(sequence+1)&sequenceMask;
if(sequence==0){
//當前毫秒內計數滿了，則等待下一秒
timestamp=tilNextMillis(lastTimestamp);
}
}else{
sequence=0L;
}
lastTimestamp=timestamp;
//ID偏移組合生成最終的ID，並返回ID
longnextId=((timestamp-twepoch)<<timestampLeftShift)
|(datacenterId<<datacenterIdShift)
|(workerId<<workerIdShift)|sequence;
returnnextId;
}
privatelongtilNextMillis(finallonglastTimestamp){
longtimestamp=this.timeGen();
while(timestamp<=lastTimestamp){
timestamp=this.timeGen();
}
returntimestamp;
}
privatelongtimeGen(){
returnSystem.currentTimeMillis();
}
/**
*<p>
*獲取maxWorkerId
*</p>
*/
(longdatacenterId,longmaxWorkerId){
StringBuffermpid=newStringBuffer();
mpid.append(datacenterId);
Stringname=ManagementFactory.getRuntimeMXBean().getName();
if(!name.isEmpty()){
/*
*GETjvmPid
*/
mpid.append(name.split("@")[0]);
}
/*
*MAC+PID的hashcode獲取16個低位
*/
return(mpid.toString().hashCode()&0xffff)%(maxWorkerId+1);
}
/**
*<p>
*數據標識id部分
*</p>
*/
(longmaxDatacenterId){
longid=0L;
try{
InetAddressip=InetAddress.getLocalHost();
NetworkInterfacenetwork=NetworkInterface.getByInetAddress(ip);
if(network==null){
id=1L;
}else{
byte[]mac=network.getHardwareAddress();
id=((0x000000FF&(long)mac[mac.length-1])
|(0x0000FF00&(((long)mac[mac.length-2])<<8)))>>6;
id=id%(maxDatacenterId+1);
}
}catch(Exceptione){
System.out.println("getDatacenterId:"+e.getMessage());
}
returnid;
}
publicstaticvoidmain(String[]args){
//推特26萬個不重復的ID
IdWorkeridWorker=newIdWorker(0,0);
for(inti=0;i<2600;i++){
System.out.println(idWorker.nextId());
}
}
}
Ⅳ 簡述Oracle資料庫RAC真實應用集群的工作原理
Oracle集群
Oracle集群，最早稱作OPS(Oracle Parallel Server)出現在Oracle 7版本中，從Oracle 9i開始正式改稱為Oracle RAC，RAC即Real Application Clusters的簡寫，譯為「真正應用集群」；RAC 是Oracle新版資料庫中採用的一項新技術，也是Oracle資料庫支持網格計算環境的核心技術。 10g以前的OPS或者RAC都依賴於第三方集群軟體(Vendor Clusterware)方能正常工作，在10g版本中Oracle推出了Oracle Clusterware集群軟體以及ASM自動存儲管理技術，換而言之10g以後版本的RAC不再依賴於第三方的集群軟體(譬如IBM的HACMP,Veritas的VCS等)，但必須安裝Oracle自己的Clusterware集群軟體。 Oracle RAC主要支持Oracle9i、10g、11g版本，可以可以支持24 x 7 有效的資料庫應用 系統，在低成本伺服器上構建高可用性資料庫系統，並且自由部署應用，無需修改代碼。 在Oracle RAC環境下，Oracle集成提供了集群軟體和存儲管理軟體，為用戶降低了應用成本。當應用規模需要擴充時，用戶可以按需擴展系統，以保證系統的性能。 參考編輯本段Oracle集群參考文檔
Oracle RAC一般也可構建於大型SMP主機，IBM的AIX系列伺服器往往是其中高端平台，Intel linux往往作為其低端平台。當AIX UNIX用來運行Oracle RAC作為大型資料庫系統平台時，其集群系統構建、實施、運維、高可用設置，有其平台特點。可以參照《Oracle大型資料庫系統在AIX/UNIX上的實戰詳解》，該書以AIX UNIX平台為主線，以其他UNIX系統為參照，描述了資料庫系統Oracle 10g、Oracle 11g的RAC的構架方法和過程。在Linux平台，則《大話OracleRAC集群、高可用性、備份與恢復》有著很好的論述。
Ⅵ 為什麼說資料庫在電子商務中佔有重要的地位
電子商務需要數據的支持來完成，在復雜的數據中當然需要資料庫來存儲、查詢、歸類等操作了。
Ⅶ 如何理解分布式與集群，二者區別是什麼
分布式是指不同的業務分布在不同的地方，集群指的是將幾台伺服器集中在一起，實現同一業務。白話理解的話，比如公司項目上線初期（舉例電子商務網站）
初期：用戶訪問量低，只弄了一台伺服器，一個tomcat項目運行一個web工程。
中期：用戶訪問量提高，伺服器崩了，為了解決這個問題，購買伺服器，增加伺服器數量，然後每個伺服器中個各放了一份，使用nginx代理轉發。（這就是運用集群原理）
後期：用戶訪問量不斷增加，響應速度變慢，伺服器又崩了，在不考慮增加伺服器帶寬、內存和CPU的情況下如何解決這個問題？先解決響應速度變慢，用戶頻繁調用資料庫，在客戶端與資料庫之間，使用redis緩存。解決之後，又發現問題：由於每台伺服器運行一個tomcat，放著一個web工程，用戶有可能在商品詳情存在大幅度調用資料庫，而訂單列表調用幅度小，此時就存在著模塊之間耦合度高，一個功能升級其他也需要升級，擴展性差，不能靈活部署。是該考慮項目重構，把項目按照模塊分為不同的系統（使用zookeeper進行模塊之間通信），例如：訂單系統，會員系統、搜索系統、商品信息系統。把每個模塊進行拆分，用戶在哪個系統訪問頻繁，就針對哪個系統進行對症下葯，增加緩存還是使用其他技術。（這樣我們就可以單獨對這個模塊進行服務性能的提升，不用全部都一起提升。也降低了代碼的耦合度，模塊之間互不影響，即使後期增加開發人員，也可按照敏捷開發思想只對其負責模塊進行開發，效率大大提升）。這樣一個web工程就拆分成多個web工程（多個tomcat部署）。那這個項目就可以在一台伺服器部署多個工程（不同埠進行通信）或者多台伺服器運行單個項目。（這就是分布式原理）
總而言之，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
Ⅷ 分布式資料庫CAP原理
C: Consistency 強一致性
A：Availability 可用性
P：Pattition tolerance 分區容錯性
一個分布式系統不可能同時滿足CAP，只能滿足兩個
CAP只能三選二
CP:單賀者點集群洞拍肢，滿足一致性，可用性的系統，通常再可擴納世展性上不太強大 RABMS (mysql)
CP：滿足一致性，分區容忍的系統，通常性能不是特別高 redis
AP：滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些
在分布式系統中，P肯定是要滿足的；所以只會有CP AP
AP:高可用，大部分系統架構的選擇
CP：強一致性 redis MongoDb
Ⅸ 詳解kubernetes備份恢復利器 Velero - 深入了解Carina系列第三期
傳統的數據備份方案主要有兩種， 一種是利用存儲數據的服務端實現基於快照的備份，另一種是在每台目標伺服器上部署專有備份 agent 並指定備份數據目錄，定期把數據復制到外部存儲上。這兩種方式的備份機制相對固化，在雲原生時代無法適應容器化後的彈性、池化等部署場景。
以雲原生存儲插件 Carina 為例，資料庫等數據敏感場景中每個資料庫集群包括多個計算實例，實例可能在集群內任意漂移並實現自動故障恢復。傳統數據備份方式在資料庫集群快速擴縮容、跨節點漂移等場景下無法自動跟隨計算實例遷移從而導致數據備份失效，因此一款貼合 k8s 容器場景的備份工具就十分重要。
Velero 是一款雲原生時代的災難恢復和遷移工具，採用 Go 語言編寫，並在 github 上進行了開源，開源地址為：https://github.com/vmware-tanzu/velero。Velero 源於西班牙語，意思為帆船，非常符合 Kubernetes 社區的命名風格。
利用 velero 用戶可以安全的備份、恢復和遷移 Kubernetes 集群資源和持久卷。它的基本原理就是將集群的數據，例如集群資源和持久化數據卷備份到對象存儲中，在恢復的時候將數據從對象存儲中拉取下來。除了災備之外它還能做資源移轉，支持把容器應用從一個集群遷移到另一個集群，這也是 velero 一個非常成功的使用場景。
Velero 主要包括連個核心組件，分別為服務端和客戶端。服務端運行在具體的 Kubernetes 集群中，客戶端是運行在本地的命令行工具，只要配置好 kubectl 及 kubeconfig 即可使用，非常簡單。
Velero 基於其實現的 kubernetes 資源備份能力，可以輕松實現 Kubernetes 集群的數據備份和恢復、復制 kubernetes 集群資源到其他 kubernetes 集群或者快速復制生產環境到測試環境等功能。
在資源備份方面，velero 支持將數據備份到眾多的雲存儲中，例如AWS S3或S3兼容的存儲系統、Azure Blob、Google Cloud存儲、Aliyun OSS等。與備份整個 kubernetes 的數據存儲引擎 etcd 相比，velero 的控制更加細化，可以對 Kubernetes 集群內對象級別進行備份，還可以通過對 Type、Namespace、Label 等對象進行分類備份或者恢復。
以核心的數據備份為例，當執行 velero backup create my-backup 時：
關於備份存儲位置和卷快照，Velero 有兩個自定義資源 BackupStorageLocation 和 VolumeSnapshotLocation，用於配置 Velero 備份及其關聯的持久卷快照的存儲位置。
Minio安裝Yaml文件如下：
安裝Mini，並檢查資源創建情況。
待服務都已經啟動完畢，可以登錄 minio 查看 velero/velero 的 bucket 是否創建成功。
其中，幾個重要的參數及其說明如下：
安裝命令執行完成後，等待 Velero 和 restic 工作負載就緒後，查看配置的存儲位置是否可用。
至此 velero 就已經全部部署完成。
velero 支持備份所有對象，也可以按類型，名稱空間和/或標簽過濾對象
其中：
--include-namespaces:備份該命名空間下的所有資源，不包括集群資源
--include-resources:要備份的資源類型
--include-cluster-resources:是否備份集群資源 此選項可以具有三個可能的值： true：包括所有集群范圍的資源； false：不包括集群范圍內的資源； nil （「自動」或不提供）
--selector:通過標簽選擇匹配的資源備份
--exclude-namespaces:備份時該命名空間下的資源不進行備份
--exclude-resources:備份時該類型的資源不進行備份
http://--velero.io/exclude-from-backup=true:當標簽選擇器匹配到該資源時，若該資源帶有此標簽，也不進行備份
同時，也可以通過使用 –ordered-resources 參數，按特定順序備份特定種類的資源，需要指定資源名稱和該資源的對象名稱列表，資源對象名稱以逗號分隔，其名稱格式為「命名空間/資源名稱」，對於集群范圍資源，只需使用資源名稱。映射中的鍵值對以分號分隔，資源類型是復數形式。
當備份任務狀態是 「Completed」 ，且錯誤數為 0 ，說明備份任務完成且沒發生任何錯誤，可以通過以下命令查詢：
通過先臨時將備份存儲位置更新為只讀模式，可以防止在還原過程中在備份存儲位置中創建或刪除備份對象。
還原完成後，不要忘記把備份存儲位置恢復為讀寫模式，以便下次備份任務使用：
Velero 支持還原 hooks，可以在還原任務執行前或還原過程之後執行的自定義操作。有以下兩種定義形式：
如進行備份之前，請使用以下命令將注釋添加到Pod：
如進行備份之前，請使用以下命令將注釋添加到Pod
是的，可以使用--namespace-mappings參數來指定：
Velero 有一個參數，可讓用戶決定保留原來的 nodePorts。
velero restore create 子命令具有 --preserve-nodeports標志保護服務nodePorts。此標志用於從備份中保留原始的nodePorts，可用作--preserve-nodeports或--preserve-nodeports=true 如果給定此標志，則Velero在還原Service時不會刪除nodePorts，而是嘗試使用備份時寫入的nodePorts。
如果是基於velero實現資料庫的一致性，需要用velero的hook，在備份前對資料庫進行quiesce操作，備份完unquiesce。對於備份本身，可以使用restic來數據（但不用快照），或者使用快照的方式。
Ⅹ 求集群管理的相關知識！
集群技術案例介紹和具體操作
集群技術案例介紹和具體操作
中國科學院西安網路中心 中科紅旗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