在大規模網際網路應用中,負載均衡裝置是必不可少的乙個節點,源於網際網路應用的高併發和大流量的衝擊壓力,我們通常會在服務端部署多個無狀態的應用伺服器和若干有狀態的儲存伺服器(資料庫、快取等等)。
在大規模網際網路應用中,負載均衡裝置是必不可少的乙個節點,源於網際網路應用的高併發和大流量的衝擊壓力,我們通常會在服務端部署多個無狀態的應用伺服器
和若干有狀態的儲存伺服器
(資料庫
、快取等等)。
一、負載均衡的作用
負載均衡裝置的任務就是作為應用伺服器流量的入口,挑選最合適的一台伺服器,將客戶端的請求**給它處理,實現客戶端到真實服務端的透明**。最近幾年很火的「雲計算」以及分布式架構,本質上也是將後端伺服器作為計算資源、儲存資源,由某台管理伺服器封裝成乙個服務對外提供,客戶端不需要關心真正提供服務的是哪台機器,在它看來,就好像它面對的是一台擁有近乎無限能力的伺服器,而本質上,真正提供服務的,是後端的集群。
乙個典型的網際網路應用的拓撲結構是這樣的:
二、負載均衡的型別
負載均衡可以採用硬體裝置,也可以採用軟體負載。
商用硬體負載裝置成本通常較高(一台幾十萬上百萬很正常),所以在條件允許的情況下我們會採用軟負載,軟負載解決的兩個核心問題是:選誰、**,其中最著名的是lvs(linux
virtual server)。
三、軟負載——lvs
lvs是四層負載均衡
,也就是說建立在osi模型的第四層——傳輸層之上,傳輸層上有我們熟悉的tcp/udp,lvs支援tcp/udp的負載均衡。
lvs的**主要通過修改ip位址(nat模式,分為源位址修改snat和目標位址修改dnat)、修改目標mac(dr模式)來實現。
那麼為什麼lvs是在第四層做負載均衡?
首先lvs不像haproxy等七層軟負載面向的是http包,所以七層負載可以做的url解析等工作,lvs無法完成。其次,某次使用者訪問是與服務端建立連線後交換資料報實現的,如果在第三層網路層做負載均衡,那麼將失去「連線」的語義。軟負載面向的物件應該是乙個已經建立連線的使用者,而不是乙個孤零零的ip包。後面會看到,實際上lvs的機器代替真實的伺服器與使用者通過tcp三次握手建立了連線,所以lvs是需要關心「連線」級別的狀態的。
lvs的工作模式主要有4種:
drnat
tunnel
full-nat
這裡挑選常用的dr、nat、full-nat來簡單介紹一下。
請求由lvs接受,由真實提供服務的伺服器(realserver, rs)直接返回給使用者,返回的時候不經過lvs。
dr模式下需要lvs和繫結同乙個vip(rs通過將vip繫結在loopback實現)。
乙個請求過來時,lvs只需要將網路幀的mac位址修改為某一台rs的mac,該包就會被**到相應的rs處理,注意此時的源ip和目標ip都沒變,lvs只是做了一下移花接木。
rs收到lvs**來的包,鏈路層發現mac是自己的,到上面的網路層,發現ip也是自己的,於是這個包被合法地接受,rs感知不到前面有lvs的存在。
而當rs返回響應時,只要直接向源ip(即使用者的ip)返回即可,不再經過lvs。
dr模式是效能
最好的一種模式。
nat(network address translation)是一種外網和內網位址對映的技術。
nat模式下,網路報的進出都要經過lvs的處理。lvs需要作為rs的閘道器。
當包到達lvs時,lvs做目標位址轉換(dnat),將目標ip改為rs的ip。rs接收到包以後,彷彿是客戶端直接發給它的一樣。
rs處理完,返回響應時,源ip是rs ip,目標ip是客戶端的ip。
這時rs的包通過閘道器(lvs)中轉,lvs會做源位址轉換(snat),將包的源位址改為vip,這樣,這個包對客戶端看起來就彷彿是lvs直接返回給它的。客戶端無法感知到後端rs的存在。
3、full-nat
無論是dr還是nat模式,不可避免的都有乙個問題:lvs和rs必須在同乙個vlan下,否則lvs無法作為rs的閘道器。
這引發的兩個問題是:
1、同乙個vlan的限制導致運維不方便,跨vlan的rs無法接入。
2、lvs的水平擴充套件受到制約。當rs水平擴容時,總有一天其上的單點lvs會成為瓶頸。
full-nat由此而生,解決的是lvs和rs跨vlan的問題,而跨vlan問題解決後,lvs和rs不再存在vlan上的從屬關係,可以做到多個lvs對應多個rs,解決水平擴容的問題。
full-nat相比nat的主要改進是,在snat/dnat的基礎上,加上另一種轉換,轉換過程如下:
在包從lvs轉到rs的過程中,源位址從客戶端ip被替換成了lvs的內網ip。
內網ip之間可以通過多個交換機跨vlan通訊。
當rs處理完接受到的包,返回時,會將這個包返回給lvs的內網ip,這一步也不受限於vlan。
lvs收到包後,在nat模式修改源位址的基礎上,再把rs發來的包中的目標位址從lvs內網ip改為客戶端的ip。
full-nat主要的思想是把閘道器和其下機器的通訊,改為了普通的網路通訊,從而解決了跨vlan的問題。採用這種方式,lvs和rs的部署在vlan上將不再有任何限制,大大提高了運維部署的便利性。
4、session
客戶端與服務端的通訊,一次請求可能包含多個tcp包,lvs必須保證同一連線的tcp包,必須被**到同一臺rs,否則就亂套了。為了確保這一點,lvs內部維護著乙個session的hash表,通過客戶端的某些資訊可以找到應該**到哪一台rs上。
5、lvs集群化
採用full-nat模式後,可以搭建lvs的集群,拓撲結構如下圖:
6、容災
容災分為rs的容災和lvs的容災。
rs的容災可以通過lvs定期健康檢測實現,如果某台rs失去心跳,則認為其已經下線,不會在**到該rs上。
lvs的容災可以通過主備+心跳的方式實現。主lvs失去心跳後,備lvs可以作為熱備立即替換。
容災主要是靠keepalived來做的。
原文出自:
從乙個笑話看軟體開發管理
關於軟體開發的笑話有很多,下面這個是我剛在qq群裡的看到的 1.程式設計師寫出自認為沒有bug的 2.軟體測試,發現了20個bug。3.程式設計師修改了10個bug,並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作,同時又發現了15個新bug。5.重複3次步驟3和步驟4。6....
從乙個笑話看軟體開發管理
關於軟體開發的笑話有很多,下面這個是我剛在qq群裡的看到的 1.程式設計師寫出自認為沒有bug的 2.軟體測試,發現了20個bug。3.程式設計師修改了10個bug,並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作,同時又發現了15個新bug。5.重複3次步驟3和步驟4。6....
從乙個笑話看軟體開發管理
關於軟體開發的笑話有很多,下面這個是我剛在qq群裡的看到的 1.程式設計師寫出自認為沒有bug的 2.軟體測試,發現了20個bug。3.程式設計師修改了10個bug,並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作,同時又發現了15個新bug。5.重複3次步驟3和步驟4。6....