cluster集群種類：
1，LB（Load Balance）負載均衡集群：
弱點：當橫向擴展到一定機器后，發現在怎么橫向加機器也沒有效果的時候，瓶頸就卡在分發的服務器上了，也就是LB機器上了，如何解決呢？功能拆分嗎，一個功能一個LB集群。
2，HA（High Availability）高可用集群：有多個LB，一旦主LB掛斷，副LB馬上取而代之。副LB怎么知道主LB是否還或者呢，主LB每間隔一段時間（1秒或者半秒）向副LB集群發送還活着的信息，副LB接到了主LB還或者的信息，就知道了它還或者。如果多次副LB沒有接收到主LB的活着的信息，則取而代之。那么副LB怎么取代主LB呢，把主LB的IP設置成自己機器的IP，並啟動和主LB同樣的服務。
3，HP（High performance）集群
- 向量機：通過在一台機器上增加硬（比如加100個CPU）件的方式提高性能。
- 並行處理集群：橫向擴展
- 需要一個分布式文件系統
- 將大任務切割為小任務，分別進行處理的機制
上面3種集群的各自用途：
-
LB用於高並發
-
HA用於高穩定
-
HP用於海量數據分析（大數據分析，比如分析中國15億人），復雜的科學計算，模擬核彈爆炸，天氣預報
集群節點間的文件同步：
rsync：遠程文件拷貝命令
inotify ：內核監控文件發生變化后，會發信號給用戶進程。
所以使用rsync+inotify ，可以實現，各個服務器機器見的靜態文件的同步。
health check：
試想一下，如果LB下的某個機器壞掉了，會發生什么情況？LB分發到這台機器上的請求，這台機器不能處理了。所以LB需要知道地下的機器哪些掛掉了，哪些又從掛掉的狀態恢復成正常狀態了，這就是health check。如果發現它掛掉了，則不往它這里分發請求了。如果它又恢復了，則繼續往它這里分發請求。
DAS和NAS
DAS:direct attached storage
以塊為單位請求文件
NAS:network attached storage
以整個文件為單位請求文件
DAS的傳輸速度根據設備類型的不同，最少也能320Mbps，最高的能6Gbps；
而百兆以太網的速度為12.5Mbps，千兆125Mbps。
所以DAS的性能更好。如果多台主機同時使用DAS設備，是通過線連接到DAS設備上的，DAS設備相當於一塊硬盤，里面沒有操作系統，所以主機1寫DAS上的文件A，主機B也寫DAS上的文件A，文件A就會錯亂。主機1的進程1寫DAS上的文件A，主機1的進程2寫DAS上的文件A，主機1的操作系統會提供鎖機制。
主副切換時，會產生split-brain：腦裂
主服務器由於太忙了，沒來得及給副服務器發送心跳信息，這時副服務器取代了主服務器，
但是在主服務器還有一些數據沒有寫到DAS設備上，數據就丟失了。
如何解決呢，防止主服務器是假死，所以補上一刀，直接拔掉主服務器的電源。
只要主服務器和副服務器都插在一個電源管理器上的話，副服務器發送關閉主服務器的命令給電源管理器械就行了。
stonith：shoot the other node in the head爆頭。
隔離機制：fencing
1，節點級別：stonith
2，資源級別：切斷某個主機能夠訪問DAS的接口
如果只有主服務器和一個副服務器，它們2個就會來回強着當主服務器，為了避免split-brain，我們就需要至少3台服務器或者奇數個服務器作為一個集群。
- 其中一台接受不到另外2台的心跳了，自動把自己下線
- 其中2台都接受不到另外一條的心跳了，殺死它。
LB集群
-
Hardware
- F5（最好？），BIG IP
- Citrix,Netscaler
- A10（最便宜）
-
Software
-
四層
- LVS（Linux Virtual Server）國人發明的
-
七層
-
nginx
http ，smtp，pop3，imap
-
haproxy
http，tcp（mysql，smtp）
-
-
四層和七層的區別：4層是在IP和端口上做負載均衡，7層是在特定的應用層協議上做負載均衡。
-
四層的LVS說明
LVS不能和iptables一起使用，LVS是工作在內核區域的。
iptables/netfilter
LVS
- ipvsadm：用戶區。管理集群服務的命令行工具
- ipvs:在內核區
IP地址的名詞解釋：
- CIP：客戶端的IP
- VIP：負載均衡機器（director）的公網IP，也就是客戶端發送請求里的目標IP。
- DIP：轉發請求時，使用的IP
- RIP：集群節點機器的IP
LVS種類：
1，NAT
- 集群主機必須和負載均衡主機在同一個內網了，而且DIP必須是RIP們的網關
- RIP是私有IP
- DIP位於CIP和RIP之間，即負責CIP過來接收請求，然后把目標IP從VIP修改為RIP，然后RIP機器處理完成后，把相應再發回DIP機器（director），然后DIP再把目標IP從RIP修改回VIP。所以director的負載很重
- 支持端口映射，RIP的服務的端口可以是任意的
- real server可以是任意操作系統，但是director必須是Linux系統
- 確定director是最容易形成性能瓶頸的。最多掛10 real server
，DR：直接路由。被使用最多
-
集群節點必須和director在同一個物理網絡中（同一個物理網絡是什么意思？？？）
-
director只負責接收請求，而不負責響應；相應報文直接發給CIP
-
實際過來的是，請求端IP為CIP，目標端IP為VIP。
-
每台RIP機器配2個IP，一個是VIP但必須是隱藏的，負責IP就會沖突了；另一個是RIP
-
當CIP的請求發送到了VIP，然后director不修改目標IP，所以目標IP還是VIP，它修改MAC地址，把目標IP攜帶的MAC地址修改為RIP的，real server處理完后，把相應報文用隱藏的VIP發送給CIP，這樣一來就不用經過director了。
VIP是配置到網卡別名上，並且是隱藏的，不用於接受請求，只用於發送相應。
-
RIP可以使用公網IP，實現便捷的遠程管理。也可以是私有IP
-
集群節點一定不能將網關指向DIP
-
director不支持端口映射
-
RIP機器上可以使用大多數操作系統，前提是支持IP隱藏功能。
-
DR模式可以帶動更多的real server，至少100以上。
理由：只負責接收請求，而不負責響應；請求報文很小，響應報文很大，director不處理響應報文了，所以性能提高很大。
3，TUN模式
解決real server 分布在不同的國家，不同的城市
- director通過隧道協議把原CIP和目標VIP作為報文發給realserver，發的時候，使用DIR-》RIP
- RIP要有公網IP，realserver的OS必須支持隧道協議
- 其余的和DR模式一樣
調度算法：靜態調度，動態調度
（active）活動連接數：正在傳輸數據
（inactive）非活動連接數：傳輸數據完成了，但是連接還沒有斷開。
靜態調度（固定調度）：調度器不管realserver的活動連接數和非活動連接數，按照事先指定好的算法調度。所以就有可能把某個realserver累死了，有的閑死了。
-
rr：輪詢（平均呼叫）
-
wrr：weight 加權輪詢（性能好的realserver多叫，不好的少叫）
-
sh（source hash 原地址hash）：只要是同一個CIP來的請求，都給固定的realserver。
感覺很奇怪，這不就破壞了負載均衡的機制了嗎，為什么會有這樣的算法？
http協議是無狀態的短鏈接，所以server處理完會給瀏覽器發送一個身份信息，來標識這個client，
瀏覽器會把這個信息保存在本地的cookie中。早期cookie里有太多的敏感信息，會泄露用戶的信息，
所以瀏覽器保存了最少量的信息，變成了輕cookie，原來的信息放到了server端，存到了server的內存中，叫session。就是為了找到原來的session，才需要把同一個CIP導向到原來的real server。
如果各個節點的real server可以同步session的話，sh調度算法就沒有使用的必要了。
-
dh（destination hash 目標地址hash）：和sh算法類似。用於緩存服務器集群。保證緩存命中率的提高。
動態調度：調度器要考慮realserver的活動連接數和非活動連接數
- lc（最少連接）：計算:active × 256 + inactive，結果最小的realserver，作為這次的目標realserver
- wlc：加權lc。計算：（active × 256 + inactive）/weight，結果最小的realserver，作為這次的目標realserver。wlc被使用最多
- sed（最短期望延遲）計算：（active+1） × 256/weight，結果最小的realserver，作為這次的目標realserver
- np（never queue 永不排隊）：只要有個realsever沒有被分到，就分給它一個再說。
- lblc（基於本地的最少連接）：相當於動態的dh，不考慮active數
- lblcr（基於本地的帶復制功能的最少連接）：考慮active數
c/c++ 學習互助QQ群：877684253
