Cluster
系統擴展的方式：
Scale up：向上擴展；
Scale out：向外擴展
集羣類型：
LB：負載均衡集羣，Load Balancing
HA：高可用集羣，High Availability
HP：高性能集羣，High Performancing
系統：
可擴展性
可用性
容量
性能
系統運維：可用 à 標準化 à 自動化
構建高可用擴展性系統的重要原則：在系統內部儘量避免串行化和交互；
GSLB：Global Service Load Balancing
SLB：Service Load Balancing
總結：
分層
分割
分佈式
分佈式應用
分佈式靜態資源
分佈式數據和存儲
分佈式計算
LB集羣的實現：
硬件：
F5 BIG-IP
Citrix NetScaler
A10 A10
Array
Redware
軟件：
lvs
haproxy
nginx
ats（apache traffic server）
perlbal
基於工作的協議層次劃分：
傳輸層：
lvs，haproxy（mode tcp）
應用層：
haproxy，nginx，ats，perlbal
lvs(1)：
章文嵩：正明；
Lvs：linux virtual server
L4：四層交換，四層路由；
根據請求報文的目錄ip和port將其轉發至後端主機集羣中的某一臺主機（根據挑選算法）；
netfilter：
PREROUTING à INPUT
PREROUTING à FORWARD à POSTROUTING
OUTPUT – POSTROUTING
lvs：
ipvsadm/ipvs
ipvsadm：用戶空間的命令行工具，用於管理集羣服務；
ipvs：工作內核中的netfilter INPUT鉤子上；
支持TCP，UDP ，AH , EST , AH_EST , SCTP等諸多協議；
lvs arch：
調度器：director，dispatcher，balancer
RS：Real Server
Client ip：CIP
Director Virtual ip：VIP
Director IP：DIP
Real Server ip：RIP
lvs type：
lvs-nat
lvs-dr（direct routing）
lvs-tun（ip tunneling）
lvs-fullnat
lvs-nat：
多目標的DNAT（iptables）：它通過修改請求報文的目標ip地址（同時可能會修改目標端口）至挑選出某RS的RIP地址實現轉發；
1) RS應該和DIP應該使用私網地址，且RS的網關要指向DIP；
2) 請求和響應報文都要經由director轉發；極高負載的場景中，director可能會成爲系統瓶頸；
3) 支持端口映射；
4) RS可以使用任意OS；
5) RS的RIP和Director的DIP必須在同一IP網絡；
Note：客戶端主機地址爲cip，調度器Director主機有兩塊網卡，一塊地址爲vip，一塊爲dip，兩臺RS 的主機地址分爲爲RIP1，RIP2；
lvs-dr：direct routing
它通過修改請求報文的目標MAC 地址進行轉發；
Director：VIP , DIP
RSs：RIP , VIP
1) 保證全段路由器將目標ip爲VIP的請求報文送給director；
解決方案：
靜態綁定
arptables
修改RS主機內核的參數
2) RS的RIP可以使用私有地址；但也可以使用公網地址；
3) RS跟Director必須在同一物理網絡中；
4) 請求報文經由Director調度，但響應報文一定不能經由Director；
5) 不支持端口映射；
6) RS可以是大多數的OS；
7) RS的網關不能指向DIP
兩個內核參數
限制響應級別：arp_ignore；
0：默認值，表示可使用本地任意接口上配置的任意地址響應；
1：僅在請求的目標ip配置在本地主機的接收到請求報文接口上時，纔給予迴應；
限制通告級別：arp_announce；
0：默認值，把本機上所有的接口的所有信息向每個接口上的網絡進行通告；
1：儘量避免向非直接連接網絡進行通告；
2：必須避免向非本地直接連接網絡進行通告；
總結：
lvs-nat：請求和響應報文都經由director，且RIP和DIP必須在同一網絡；
lvs-dr：僅請求報文經由director，響應報文是由RS直接響應給client，Director與RS必須在同一物理網絡；
lvs-tun：
不修改請求報文的ip首部，而是通過在原有的ip首部（cip <-->vip）之外，在封裝一個ip首部（dip《--》rip）
1) RIP,DIP,VIP全得是公網地址；
2) RS的網關不能指向DIP；
3) 請求報文必須經由director調度，但響應報文必須不能經由director；
4) 不支持端口映射；
5) RS的OS必須支持隧道功能；
lvs-fullnat：
director通過同時請求報文的目標地址和源地址進行轉發；
1) VIP是公網地址；RIP和DIP是私網地址，二者無須在同一網絡中；
2) RS接收到的請求報文的源地址爲DIP，因此要響應給DIP；
3) 請求報文和響應報文都必須經由director；
4) 支持端口映射機制；
5) RS可以使用任意OS；
http：stateless無狀態
session保持：
session綁定：
source ip hash
cookie
session集羣：
session服務器；
lvs scheduler：
靜態方法：僅根據算法本身進行調度；
RR：round robin，論調
WRR：weighted rr，帶權重的輪調；
SH：source hash，實現session保持的機制；將來自於同一個ip的請求始終調度至同一RS；
DH：destination hash，將對同一個目標的請求始終發往同一個RS；
動態方法：根據算法及各RS的當前負載狀態進行調度；
Overhead=
LC：Least Connection
Overhead=Active*256+Inactive
WLC：Weighted LC
Overhead=（Active*256+Inactive）/weight
SED：Shortest Expection Delay
Overhead=（Active+1）*256/weight
NQ：Never Queue
SED算法的改進；
LBLC：Loality-Based LC，即爲動態的DH算法；
正向代理情形下的cache server調度；
LBLCR：Locality-Based Least-Connection with Replication，帶複製功能的LBLC算法；
ipvs的集羣服務：
tcp, udp , ah , esp , ah_esp , sctp
1) 一個ipvs主機可以同時定義多個cluster service；
tcp ，udp
2) 一個cluster service上至少應該一個real server；
定義時：指明lvs-type，以及lvs scheduler；
ipvsadm的用法：
管理集羣服務
ipvsadm –A|E -t|u|f service-address [-s scheduler]
ipvsadm -D –t|u|f service-address
service-address：
tcp： -t ip：port
udp： -u ip：port
fwn： -f mark
-s scheduler：
默認爲WLC
管理集羣服務中的RS
ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
ipvsadm -d -t|u|f service-address -r server-address
server-address：
ip[:port]
lvs-type：
-g：gateway，dr
-i：ipip，tun
-m：masquerade，nat
清空和查看：
Ipvsadm -C
Ipvsadm -L|l [options]
-n：numeric，基於數字格式顯示地址和端口；
-c：connection，顯示ipvs連接；
--states：統計數據；
--rate：速率；
--exact：精確值；
保存和重載：
Ipvsadm –R
Ipvsadm -S [-n]
置零計數器：
Ipvsadm -Z [-t|u|f service-address]
lvs-nat演示：
實驗環境：
三臺虛擬主機，一臺作Director，另外兩臺作RS，在這裏，Director的兩塊網卡，vip是nat模式，dip是自定義vmnet2模式，兩臺RS的網卡也是vmnet2模式；兩臺RS的網關都指向dip；
1. 打開Director的核心轉發功能；
2. 設置Director的ip地址；
3. 兩臺RS主機的ip地址配置
1) RS1主機的配置：
Note：這裏在配置IP地址時在配置文件中直接指明瞭網關；如果沒有指明用route命令添加路由；
2) RS2主機的ip配置；
4. 提供測試頁面，並開啓web服務；
1) RS1測試頁面及服務開啓；
2) RS2測試頁面及服務開啓；
5. 在Director上添加規則；
6. 訪問測試；
由上可知，此次試驗確實達到了負載均衡集羣的目的。同時我們也可以在添加規則時，還另外的調度算法再進行測試，這裏就不演示了。
Lvs-dr演示：
實驗環境：
準備三臺虛擬主機，一臺作Director，另外兩臺作RS，在Director上配置兩個ip地址，DIP配置在ens33網卡上，vip配置在ens33 的別名上ens33:0，另外RS也同樣配置兩個地址，RIP配置在網卡eth0上，vip配置在lo的別名上lo:0；
同時各RS要修改內核參數，來限制arp響應和通告的級別；
1. 配置Director的物理網卡DIP和物理網卡別名VIP；
2. 寫一個腳本自動配置RS；
1) 編輯執行RS1腳本；
執行腳本後，查看配置：
2) 編輯執行RS2的腳本；
執行腳本後查看配置:
3. 使用ipvsadm定義集羣規則；
4. 開啓RS1和RS2的web服務；
5. 客戶端測試；
此次用的是帶權重的rr算法。所以調用兩次RS2，再調用一次RS1，實現了集羣。
lvs(2)
FWM：FireWall Mark
功用：藉助於防火牆標記來分類報文，而後基於標記定義集羣服務；可將共享一組RS的集羣服務統一進行定義；
通過FWN定義集羣的方式：
1) 在director上的netfilter的mangle表的PREROUTING定義用於“打標”的規則；
iptables –t mangle -A PREROUTING -d $vip -p $protocol --dports $port -j MARK --set-mark #
$vip：VIP地址
$protocol：協議
$port：協議端口
2) 基於FWM定義集羣服務；
Ipvsadm –A -f # -s scheduler
Ipvsadm -a -f # -r RS …
演示：
1. 前兩個步驟與上面的演示一樣；
2. 定義iptables規則；
3. 定義集羣規則；
4. 開啓RS1和RS2的web服務；
5. 測試
1) Web服務測試；
2) ssh服務測試；
由上可以看出，web服務和ssh服務都實現樂集羣負載均衡；
lvs persistence：lvs的持久連接
功能：無論ipvs使用何種調度方法，其都能實現來自於同一個client的請求始終定向至第一次調度時挑選出的RS；
持久連接模板：獨立於算法
Sourceip rs timer
持久連接的實現方式：
每端口持久：PPC，單服務器持久調度
每FWM持久：PFWMC，單FWM持久調度
PORT AFFINITY
每客戶端持久：PCC，單客戶端持久調度
Director會將用戶的任何請求都識別爲集羣服務，並向RS進行調度；
TCP：1-65535
UDP：1-65535
演示：lvs的持久連接；
1. 以上的測試是在做持久連接之前的測試，下面我們將在做持久連接之後，對比測試結果，前兩個步驟跟上面的一樣；
2. 定義集羣規則；
3. 測試；
定義持久連接之前；
定義持久連接之後；
Note：以上是每端口持久，至於每FWM持久定義則先使用iptbales定義標記，在定義標記持久；每客戶端持久，則在定義調度器時，把ip：port，port寫成0，意義爲所有端口；
HA：
SPOF：Single Point of Failure
director：在節點級別進行冗餘：HA集羣解決方案：keepalived
realserver：讓director對其做健康狀態監測，並且根據檢測的結果自動完成添加或移除等管理功能；
1. 基於協議層檢查
Ip：icmp
傳輸層：檢測端口的開放狀態
應用層：請求獲取關鍵性資源；
2. 檢查頻度
3. 狀態判斷
下線：ok --> failure --> failure -->failure
上線：failure --> ok --> ok
4. back server，sorry server
示例腳本：
DR類型director示例：
DR類型RS示例：
實踐任務：
1) 建立一個至少由兩個RS組成的負載均衡集羣：rs用於提供apache+php，mysql由單獨的服務器實現；
2) 部署安裝discuz_x3.1：分別基於rr/lc/sh算法調度，查看兩臺rs是否都接收到了請求；
部署環境說明：架設頁面訪問路徑爲/www/app/discuz，則需要將discuz_3.1部署於/www/app目錄中，而後將/www/app/discuz創建爲符號鏈接，鏈接至帶版本號的目錄上；多臺RS路徑均採用此方式；
3) 基於灰度的方式進行應用程序升級；
4) 嘗試着寫腳本自動進行灰度發步；
待續。