運維必學:一文看懂全域性負載均衡與 CDN 內容分發
CDN簡介
CDN的全稱是Content Delivery Network,即內容分發網路。CDN是構建在現有網路基礎之上的智慧虛擬網路,依靠部署在各地的邊緣伺服器,透過中心平臺的負載均衡、內容分發、排程等功能模組,使使用者就近獲取所需內容,降低網路擁塞,提高使用者訪問響應速度和命中率。CDN的關鍵技術主要有內容儲存和分發技術。
簡而言之,就是將資料部署在各地的伺服器中,透過負載均衡技術,讓使用者就近獲取伺服器中的資料。
CDN原理
CDN的基本原理是廣泛採用各種快取伺服器,將這些快取伺服器分佈到使用者訪問相對集中的地區或網路中,在使用者訪問網站時,利用全域性負載技術將使用者的訪問指向距離最近的工作正常的快取伺服器上,由快取伺服器直接響應使用者請求。
全域性負載均衡主要用於在多個區域擁有自己伺服器的站點,為了使全球使用者只以一個IP地址或域名就能訪問到離自己最近的伺服器,從而獲得最快的訪問速度。
CDN 基本思路是儘可能避開網際網路上有可能影響資料傳輸速度和穩定性的瓶頸和環節,使內容傳輸的更快、更穩定。透過在網路各處放置節點伺服器所構成的在現有的網際網路基礎之上的一層智慧虛擬網路,CDN 系統能夠實時地根據網路流量和各節點的連線、負載狀況以及到使用者的距離和響應時間等綜合資訊將使用者的請求重新導向離使用者最近的服務節點上。
其目的是使使用者可就近取得所需內容,解決 Internet 網路擁擠的狀況,提高使用者訪問網站的響應速度。
CDN功能
歸納起來,CDN具有以下主要功能:
節省骨幹網頻寬,減少頻寬需求量;
提供伺服器端加速,解決由於使用者訪問量大造成的伺服器過載問題;
服務商能使用Web Cache技術在本地快取使用者訪問過的Web頁面和物件,實現相同物件的訪問無須佔用主幹的出口頻寬,並提高使用者訪問因特網頁面的相應時間的需求;
能克服網站分佈不均的問題,並且能降低網站自身建設和維護成本;
降低“通訊風暴”的影響,提高網路訪問的穩定性。
CDN服務模式
簡單地說,內容分發網路(CDN)是一個經策略性部署的整體系統,包括分散式儲存、負載均衡、網路請求的重定向和內容管理4個要件,而內容管理和全域性的網路流量管理(Traffic Management)是CDN的核心所在。透過使用者就近性和伺服器負載的判斷,CDN確保內容以一種極為高效的方式為使用者的請求提供服務。總的來說,內容服務基於快取伺服器,也稱作代理快取(Surrogate),它位於網路的邊緣,距使用者僅有”一跳”(Single Hop)之遙。
同時,代理快取是內容提供商源伺服器(通常位於CDN服務提供商的資料中心)的一個透明映象。這樣的架構使得CDN服務提供商能夠代表他們客戶,即內容供應商,向終端使用者提供儘可能好的體驗,而這些使用者是不能容忍請求響應時間有任何延遲的。
全域性負載均衡
全域性負載均衡(Global Server Load Balance, GSLB),全域性負載均衡是指對分別放置在不同的地理位置的伺服器群間作負載均衡。伺服器負載均衡是指對本地的伺服器群做負載均衡。主要用於在多個區域擁有自己伺服器的站點,為了使全球使用者只以一個IP地址或域名就能訪問到離自己最近的伺服器,從而獲得最快的訪問速度。
伺服器群選擇
對於全域性負載均衡而言,其核心就是伺服器群的選擇。對於某個特定的客戶,應該將其定向到哪一個服務群?應該使用什麼標準來進行這種選擇?一般情況下,主要考慮兩個因素:臨近程度和負載大小。
臨近機制主要考察伺服器群與使用者之間的物理距離。選擇地理位置最接近使用者的伺服器叢集,可以減少服務響應到達使用者所經過的中轉次數,從而降低中轉節點對服務質量的影響。常見的有兩種方式,一種是靜態配置,例如根據靜態的IP地址配置表進行IP地址到伺服器群的對映。另一種方式是動態的檢測,例如實時地探測到目標IP的距離(可以採用到達目標IP經過的跳數作為度量單位),然後比較探測結果進行選擇。
負載機制比較各個伺服器群的負載,確定由哪一個伺服器群來響應請求。在全域性負載均衡中,考察的是伺服器群的負載,而不是單個伺服器的負載,因此,需要更多地考慮普遍的問題,比如,需要考慮站點的最大連線數、站點的平均響應時間、服務質量等。
常見的GSLB實現方式有三種:DNS輪詢、HTTP重定向、IP欺騙(又稱三角傳輸)。這三種實現方式都是在使用者透過域名來訪問目標伺服器時,由GSLB裝置進行智慧決策,將使用者引導到一個最佳的服務IP。
基於DNS的GSLB
使用者訪問某個網站時,需要首先透過域名解析服務(DNS)獲得網站的IP。域名解析通常不是一次性完成的,常常需要查詢若干不同的域名伺服器才能找到對應的IP。如下圖所示,使用者首先在本地配置一個本地DNS伺服器地址,本地DNS伺服器收到DNS請求後若不能解析,會將請求轉發給更高一級的DNS伺服器直到找到域名對應的IP或確定域名不存在。
對於加入了GSLB的情況,一個GSLB裝置(可能是一個4層交換機)會最終代替DNS伺服器完成域名解析。下圖展示兩種流程的不同。
基於DNS的GSLB優缺點
優點
實現簡單、實施容易、成本低。
缺點
當GSLB裝置採用“使用者就近訪問”的原則作為選擇最優伺服器的策略時,會存在判斷不準的現象。原因是在這種策略下,GSLB裝置是根據使用者IP地址和內容伺服器IP地址比較來判斷其就近性的,但由於DNS響應是透過本地DNS伺服器到達使用者的,GSLB裝置實際上只能得到使用者的本地DNS伺服器地址,若使用者指定的DNS伺服器IP不能正確代表使用者的實際位置,就會出現判斷不準的現象。
基於HTTP重定向的GSLB
為了解決基於DNS實現方式判斷不準的問題,又出現了基於HTTP重定向的GSLB。這種方案中GSLB使用HTTP重定向技術,將使用者訪問重定向到最合適的伺服器上。
使用基於HTTP重定向方案,首先在DNS中將GSLB裝置的IP地址登記為域名的A記錄(既域名對應的IP)。如上圖所示,使用者首先透過DNS得到GSLB裝置的IP地址,此時使用者以為這就是站點伺服器的IP,並向其傳送HTTP請求。GSLB裝置收到HTTP請求後使用一定策略選擇一個最合適的伺服器,然後GSLB裝置向使用者傳送一個HTTP重定向指令(HTTP302),並附上選出的伺服器的IP地址。最後,使用者根據重定向IP訪問站點的伺服器。
基於HTTP重定向的GSLB優缺點
優點
由於直接向使用者傳送HTTP重定向指令,可以得到使用者的真實IP,從而解決了判斷不準確的問題。
缺點
只能為HTTP訪問重定向。
基於IP欺騙的GSLB
HTTP重定向方案解決了判斷不準確的問題,但只能針對HTTP協議應用使用。對於HTTP協議以外的訪問,就需要使用基於IP欺騙(又稱三角傳輸)的GSLB。
基於IP欺騙的方案同樣需要首先將GSLB裝置的IP地址在DNS中登記為域名的A記錄,這樣使用者對該域名的請求包都會先傳送到GSLB裝置。如上圖所示,GSLB裝置首次收到服務請求包後,會選擇一個最合適的伺服器,並將服務請求包傳送到該伺服器。伺服器在向使用者傳送響應包時,將其源IP地址欄位改為GSLB裝置的IP,傳送給使用者。
這樣,整個過程對使用者來說,感覺到的只是GSLB裝置在為其提供服務,並不知道其中經歷這樣一個三角傳輸的過程。而且這種方案可以對所有型別的訪問如HTTP、FTP等進行重定向,但其速度和效率相對比前兩種方案要差一點,因為使用者所有的訪問請求都透過三個點才能響應,經歷了更多的路徑和處理,所以其主要作為HTTP重定向方案的補充方案在同一GSLB裝置中實現。
伺服器群選擇策略
上文中介紹的三種方案,解決了如何將使用者引導到指定伺服器群的問題,而在此之前首先需要使用某種方式選出最適合使用者的伺服器群,也就是GSLB在選擇伺服器群時所採用的策略。接下來介紹一些常用的GSLB策略。
地理區域或使用者自定義區域:將若干條IP地址字首劃分一個區域為。根據使用者本地DNS的IP地址,將特定IP範圍的使用者優先分配到某個透過健康檢查的站點。
IP地址權重:可以為DNS應答中的每個IP地址分配權重,權重決定與其他候選IP相比分配到該IP的流量比例。
往返時間(Round Trip Time, RTT):RTT策略是基於區域之外最常用的策略。有兩種模式的RTT測量:Active RTT測量與Passive RTT測量。在實際部署中,由於網路限制和效能原因,Active RTT往往無法使用,Passive RTT更實用一些。
a) Active RTT 測量:
當GSLB Controller收到來自LDNS的DNS請求時,GSLB Controller會通知所有站點負載均衡裝置對該LDNS進行RTT測量。根據採集到的RTT值,GSLB Controller會選擇RTT值最小的站點的VIP返回給LDNS。
由於Active RTT採用DNS Query或ICMP進行RTT測量,在有些網路中可能會被安全策略所過濾而無法工作。
Active RTT測量會產生額外的DNS Query或ICMP流量,在有些網路中使用者不希望有太多類似的非使用者流量。
b) Passive RTT測量:
Passive RTT測量指從內容站點收到一個使用者發出連線請求(傳送TCN SYN)到接收到使用者的確認(收到TCP ACK)所經歷的時間。而不是簡單的PING的響應時間,可以更精確的衡量訪問最快的站點。
Passive RTT測量不會主動去進行測量,也不會產生額外的資料流量,而是在使用者向返回的VIP建立連線時進行採集。
Passive RTT的測量值真正反映了使用者的上網感受,在運營商網路中也不會產生額外流量。也不會受到其他運營商或網路的安全策略的影響。
來自 “ https://www.cnblogs.com/Courage129/p/14363627.html ”, 原文作者:等不到的口琴;原文連結:https://www.cnblogs.com/Courage129/p/14363627.html,如有侵權,請聯絡管理員刪除。
相關文章
- 全域性負載均衡與CDN內容分發負載
- 全域性負載均衡方案負載
- 一文了解CDN(內容分發網路)
- 運維講堂:LVS負載均衡模式與F5負載均衡盤點運維負載模式
- Nginx通過geo模式實現限速白名單和全域性負載均衡 - 運維筆記Nginx模式負載運維筆記
- 負載均衡-構建CDN服務負載
- CDN-內容分發網路
- CDN和負載均衡的基本瞭解負載
- AutoScaling彈性伸縮附加與分離負載均衡例項負載
- 《前端運維》二、Nginx--4代理、負載均衡與其他前端運維Nginx負載
- Dubbo學習筆記(四)叢集容錯與負載均衡筆記負載
- 一文讀懂“負載均衡”負載
- kubernetes叢集內排程與負載均衡負載
- 內容分發網路(Content Delivery Network,CDN)
- 容性負載運用場所有何不同?負載
- 雲原生應用負載均衡系列 (2): 入口流量分發、容錯與高可用排程負載
- 負載均衡有哪些知識點需要掌握?Linux運維負載Linux運維
- 負載均衡和動態負載均衡分別是什麼?-VeCloud負載Cloud
- dubbo容錯機制和負載均衡負載
- Nginx 動靜分離與負載均衡的實現Nginx負載
- Java Chassis 3:介面維度負載均衡Java負載
- gRPC負載均衡(自定義負載均衡策略)RPC負載
- gRPC負載均衡(客戶端負載均衡)RPC負載客戶端
- 負載均衡簡介與搭建負載
- Kubernetes:服務與負載均衡負載
- 四. SpringCloud負載均衡與呼叫SpringGCCloud負載
- 負載均衡負載
- nginx學習之負載均衡Nginx負載
- 服務發現與負載均衡機制-Service負載
- openGauss JDBC客戶端負載均衡與讀寫分離JDBC客戶端負載
- 資料庫的讀寫分離與負載均衡策略資料庫負載
- 彈性負載均衡(Elastic Load Balance,ELB)負載AST
- 雲端計算 - 內容分發網路CDN技術與應用全解
- 秒懂負載均衡與反向代理負載
- 如何最佳化負載均衡?一文講懂負載
- Nginx使用篇:實現負載均衡、限流與動靜分離Nginx負載
- MySQL Route負載均衡與讀寫分離Docker環境使用MySql負載Docker
- Azure CDN 為靜態網站建立內容分發網路網站