漫談雲端計算網路(二): 雲端計算網路的應用場景
宣告:本文CSDN作者原創投稿文章,未經許可禁止任何形式的轉載。
作者:張欽,雲途騰高階雲解決方案架構師,負責企業級雲端計算網路解決方案的架構設計及客戶培訓。曾就職於金山雲和中國電信,任職售前解決方案架構師及雲資料中心網路架構師,思科CCIE認證工程師。
責編: 錢曙光,關注架構和演算法領域,尋求報導或者投稿請發郵件qianshg@csdn.net,另有「CSDN 高階架構師群」,內有諸多知名網際網路公司的大牛架構師,歡迎架構師加微信qshuguang2008申請入群,備註姓名+公司+職位。
編者按:本文是<<漫談雲端計算網路>>系列的第二篇,本系列文章面向的物件為網路工程師和對網路技術感興趣的童鞋。本系列文章,筆者會從雲端計算網路技術介紹,雲端計算網路的架構模式以及在企業實踐SDN/NFV 解決方案的經驗總結三個維度進行分享。
在漫談雲端計算網路的第一篇裡,筆者總結了在雲端計算中會涉及到的網路技術,目的是讓大家瞭解傳統網路技術和雲端計算中的網路技術有什麼區別和共同點。在第二篇裡,我們會著重分享,這些雲端計算中會用到的網路技術,在實際應用場景中是如何運用和管理的。
隨著以雲平臺為IT基礎搭建的業務場景越來越廣泛的被應用於政企及運營商,區分雲端計算的網路流量型別也變得越來越重要,因為雲端計算會越來越多的以場景的方式落地於各個行業,不同業務的流量是不一樣的,所以首先應該對各種行業應用下雲端計算網路的流量型別進行區分,同時對這些流量進行管理 。
一、雲端計算環境下網路流量的區分
使用者與後臺資源的網路穩定性對於最終體驗是至關重要的,然而對於大部分傳統企業和運營商來說,網路的QOS使用並不能完全滿足網路穩定性的要求,對於大多數傳統企業,資料中心多依靠於運營商的網路,所以多數的流量全部混合到核心網路當中去進行傳輸,那麼對於雲端計算環境下,多業務,多租戶的模式下,網路流量的區分至關重要。
設計雲端計算的網路模型時,我們應該更多、更好地去運用雲端計算所帶來的便捷性,多種業務共存在每個資源池當中,從資源池引入到上層網路,這時我們就應該對於多種流量進行逐一的區分,建立不同的業務模型,找到不同業務對應的底層協議種類,以便在日後整個雲端計算爆發的時候,使得每個邏輯業務網路更加清晰,從龐大的資料流當中提取不同流量。對於雲端計算來說,三種服務模型所產生的流量也是有所不同,巨集觀上可以區分如下:
- SaaS流量模型
包括大量的HTTP與HTTPS流量,主要分佈於80與443埠,通常屬於一種輕量型的資料連線機制,但是在一定程度下,比如上傳或者下載,將會產生多種資料流進行傳遞,使得頻寬佔用的不明朗,與資源管理的複雜性。
- PaaS流量模型
PaaS屬於對外提供定製的軟體執行環境,往往會在系統開發與除錯階段產生不同的資料流量,那麼多與每項的程式呼叫所使用的流量區分,在這個平臺也會逐漸產生。
- IaaS流量模型
IaaS這個層面所產生的流量就比較複雜,兩個維度,一個是屬於面向業務,多租戶,多業務的流量區分,線上儲存的服務,每個儲存通道所產生的流量區分,每個虛擬機器所產生的流量的區分,對於整個網路的流量區分與所需網路的提供將會是一個逐漸演變的過程。
基於以上的流量區分與流量的安全性,我們應該在雲資料中心網路層面上去提前認識與使用,並結合業務實際需求去建設適合使用者的資料中心網路。
二、相同資料中心二層網路互通
隨著雲端計算落地資料中心,虛擬流量逐漸產生,資料中心的概念在逐漸模糊,同地域,不同地域,同資源池,不同資源區分等,本章節主要是講述,相同資料中心之間的網路架構實現,以新老技術為背景,進行實現與架構設計的分享。
1.1VPLS的實現
vpls對於傳統網路來說,這個詞語並不陌生,在之前文章當中已經提及基本知識,本章不再對基本知識進行相關介紹,主要以架構設計與實現進行分享,我們都知道,MPLS-VPN,這個2.5層的網路路由協議可以說是一種比較老舊的技術,但是在當前雲端計算的環境下,對於多業務的區分,多種虛擬流量的整合又重新興起到了現有的雲端計算網路平臺,它們將會發揮它們在於邏輯網路區分的優勢,繼續發揮這個老司機的作用。之所以認為它是屬於相同資料中心的網路通訊協議,其實不難理解,MPLS也好VPLS也好,都是一種依靠LABLE傳遞的路由協議,那麼對於租用運營商鏈路或者跨域其他鏈路資源來說,中間的裝置必須具有LABLE的能力,整體來說,還是屬於一張私有的邏輯網路,那麼整個網路其實可以理解為一個資料中心的整體,並沒有在廣域鏈路上進行完全的隔離與混合,那麼在雲背景下,對於二層網路來說,vpls也即是再適合不過的一個流量區分的一個協議選擇了,其天生的VSI標示,就是對於每一個二層網路進行相互隔離的一個基本機制,利用其VSI我們就可以對不同的流量或者雲端計算當中的每個虛擬網路流量進行區分,本節將會以vpls為主,進行分享。
VPLS在個人業務中的應用
業務描述:
HSI(High Speed Internet)、VoIP(Voice Over IP)、BTV(Broadband TV)這些個人業務通常是通過運營商的都會網路來承載業務流量的。
由於個人業務的業務閘道器(SR/BRAS等)部署在了城域出口,也就意味著使用者的二層報文需要透傳到業務閘道器(因為如果在PE上終結了二層報文,轉為三層路由轉發的話,承載在二層報文中的使用者資訊將會丟失,而無法到達業務閘道器,導致業務閘道器無法對使用者實施控制),需要使用VPLS/VLL等技術透傳二層報文。當都會網路部署主備業務閘道器時,使用者流量需要雙歸屬接入業務閘道器,此時必須使用VPLS技術才能實現。
組網描述:
個人業務(HSI、VoIP、BTV)依次通過都會網路的接入層、匯聚層、核心層到達Internet網路。如圖1是承載個人業務的典型組網。
HSI業務通過該承載網,訪問Internet網路。
VoIP業務經過該承載網,向DHCP(Dynamic Host Configuration Protocol)Server申請IP地址。
BTV業務經過該承載網,向組播源申請組播服務。
部署特性:
VPLS特性通常部署於PE裝置之間,實現流量在PE裝置之間的透明傳輸。根據圖1,以部署LDP方式的VPLS為例:
- 接入層裝置的特性:
部署VLAN特性,用於區分不同型別的使用者。
部署PPPoEoA(PPPoE over AAL5)和PPPoA(PPP over AAL5)特性,實現HSI業務使用者的撥號接入。
部署組播VLAN、IGMP Snooping業務,實現組播業務分發。
- 匯聚層裝置的特性:
PE裝置部署IGP(Interior Gateway Protocol)協議,實現PE裝置間路由互通。
PE裝置部署MPLS基本功能,使得PE裝置之間建立遠端會話。
PE裝置部署MPLS L2VPN功能,同時建立VSI例項。
PE裝置部署VPLS菊花鏈方式的組播業務,實現組播業務分發。
- 核心層裝置的特性:
BRAS(Broadband Remote Access Server)裝置部署認證、計費等特性,用於進行HSI業務的終結。
SR(Service Router)裝置部署IGP協議,實現路由互通。
SR裝置部署MPLS基本功能。
SR裝置部署DHCP Relay功能,實現VoIP使用者通過DHCP Server獲得IP地址。
SR裝置部署三層組播特性,實現與組播源之間業務的互通。
VPLS在企業業務中的應用
業務描述:
目前,很多企業的分佈範圍日益擴大,公司員工的移動性也不斷增加,因此企業中立即訊息、網路會議的應用越來越廣泛。這些應用對端到端的資料通訊技術有了更高的要求。端到端資料通訊功能的實現依賴於一個能夠支援多點業務的網路。同時,企業業務本身對資料保密的固有特點,多點傳輸時不僅要求能保證網路可靠性,還要求提供透明、安全的資料通道。
在運營商建立的都會網路中,企業的多個分支機構分佈在不同區域。此時,需要將企業機構之間的二層業務報文通過都會網路傳輸時通常會使用VPLS技術,實現分佈在不同地區的企業內部之間的互通。
組網描述:
企業業務通過都會網路傳輸。如圖1是承載企業業務的典型組網。某企業擁有多個分支機構,Site1、Site2、Site3是研發部門。通過部署VPLS特性,實現site之間二層網路互通。
部署特性:
VPLS特性通常部署於PE裝置之間,實現流量在PE裝置之間的透明傳輸。從企業使用者看來,公網類似一個二層交換機。根據圖1,以部署LDP方式的VPLS為例:
- 接入層裝置的特性:
部署VLAN特性,用於區分不同型別的企業使用者。
- 匯聚層裝置的特性:
PE裝置部署IGP協議,實現PE裝置間路由互通。
PE裝置部署MPLS基本功能,使得PE裝置之間建立遠端會話。
PE裝置部署MPLS L2VPN功能,同時建立VSI例項。採用VPLS雙歸組網形式,實現對流量的保護。
PE裝置部署MAC地址限制、報文流量抑制功能,實現對資料保護。
1.1.1 HVPLS
HVPLS(Hierarchical Virtual Private LAN Service),即分層VPLS,是一種實現VPLS網路層次化的一種技術。
HVPLS 產生背景
以LDP方式為信令的VPLS,為了避免環路,其基本解決辦法都是在信令上建立所有站點的全連線,LDP建立所有站點之間的LDP會話的全連線。在進行資料轉發時,對於從PW來的報文,根據水平分割轉發的原理,將不會再向其他的PW轉發。如果一個VPLS有N臺PE裝置,該VPLS就有N×(N-1)÷2個連線。當VPLS的PE增多時,VPLS的連線數就成N平方級數增加。假設有100個站點,站點間的LDP會話數目將是4950個。上述VPLS方案不能大規模的應用的真正缺點是提供VC的PE需要複製資料包,對於第一個未知單播報文和廣播、組播報文,每個PE裝置需要向所有的對端裝置廣播報文,這樣就會浪費頻寬。
為解決VPLS的全連線問題,增加網路的可擴充套件性,產生了HVPLS組網方案。在協議draft-ietf-l2vpn_vpls_ldp中引入了HVPLS。HVPLS通過把網路分級,每一級網路形成全連線,分級間的裝置通過PW來連線,分級之間的裝置的資料轉發不遵守水平分割原則,而是可以相互轉發。
HVPLS的基本模型中,可以把PE分為兩種:
UPE:使用者的匯聚裝置,即直接連線CE的裝置稱為下層PE(Underlayer
PE),簡稱UPE。UPE只需要與基本VPLS全連線網路的其中一臺PE建立連線。UPE支援路由和MPLS封裝。如果一個UPE連線多個CE,且具備基本橋接功能,那麼資料幀轉發只需要在UPE進行,這樣減輕了SPE的負擔。SPE:連結UPE並位於基本VPLS全連線網路內部的核心裝置稱為上層PE(Superstratum
PE),簡稱SPE。SPE與基本VPLS全連線網路內部的其他裝置都建立連線。對於SPE來說,與之相連的UPE就像一個CE。從資料轉發的角度看,UPE與SPE之間建立的PW將作為SPE的AC,UPE將CE傳送來的報文封裝兩層MPLS標籤,外層為LSP的標籤,該標籤經過接入網的不同裝置時被交換;內層標籤為VC標籤,用於標識VC。SPE收到的報文包含兩層標籤,外層的公網標籤被直接彈出,SPE根據內層的標籤決定該AC接入哪個VSI並進行內層標籤交換。
HVPLS的接入方式
如圖2所示,UPE1作為匯聚裝置,它只跟SPE1建立一條虛鏈路而接入鏈路PW,跟其他所有的對端都不建立虛鏈路。UPE與SPE之間的PW稱為U-PW,SPE間的PW稱為S-PW。
以CE1傳送報文到CE2為例,資料轉發流程如下:
CE1傳送報文給UPE1,報文的目的MAC地址是CE2;
UPE1負責將CE1傳送的報文發給SPE1,UPE1為該報文打上兩層MPLS標籤,外層標籤標識UPE1與SPE1之間的LSP Tunnel ID,內層標籤標識UPE1與SPE1之間的VC ID;
UPE1與SPE1之間的LSR對使用者報文進行傳遞和標籤交換,最終在倒數第二跳報文的外層標籤被剝離;
SPE1收到報文後,根據MPLS內層標籤判斷報文所屬的VSI,發現該報文屬於VSI1;
SPE1去掉UPE1給使用者報文打上的MPLS內層標籤;
SPE1根據使用者報文的目的MAC,查詢VSI的表項,發現該報文應該被髮往SPE2。SPE1給該報文打上兩層MPLS標籤,外層標籤標識SPE1與SPE2之間的LSP Tunnel ID,內層標籤標識SPE1與SPE2之間的VC ID;
SPE1與SPE2之間的LSR對使用者報文進行傳遞和標籤交換,最終在倒數第二跳報文的外層標籤被剝離;
SPE2從S-PW側收到該報文後,根據內層MPLS標籤判斷報文所屬的VSI,發現該報文屬於VSI1,並去掉SPE1給該報文打上的內層MPLS標籤;
SPE2為該報文打上兩層MPLS標籤,外層標籤標識SPE2與UPE2之間的LSP Tunnel ID,內層標籤標識UPE2與SPE2之間的VC ID,並轉發該報文;
SPE2與UPE2之間的LSR對使用者報文進行傳遞和標籤交換,最終在倒數第二跳報文的外層標籤被剝離;
UPE2收到該報文後,去掉UPE2給使用者報文打上的MPLS內層標籤,根據使用者報文的目的MAC,查詢VSI的表項,發現該報文應該被髮往CE2,並轉發該報文。
CE1與CE4為本地CE之間交換資料,如圖2所示。由於UPE本身具有橋接功能,UPE直接完成兩者間的報文轉發,而無需將報文上送SPE1。不過對於從CE1發來的目的MAC未知的第一個報文或廣播報文,UPE1在廣播到CE4的同時,仍然會通過U-PW轉發給SPE1,由SPE1來完成報文的複製並轉發到各個對端CE。
HVPLS的環路避免
與VPLS的環路避免相比,H-VPLS中環路避免方法需要做如下調整:
只需要在SPE之間建立全連線(PW全連線),UPE和SPE之間不需要全連線。
每個SPE裝置上,從與SPE連線的PW上收到的報文,不再向這個VSI關聯的、與其它SPE連線的PW轉發,但可以向與UPE連線的PW轉發。
每個SPE裝置上,從與UPE連線的PW上收到的報文,可以向這個VSI關聯的所有與其它SPE連線的PW轉發。
1.1.1.1配置LDP方式的HVPLS示例
組網需求:
企業機構,自建骨幹網。分支Site1使用CE1連線UPE裝置接入骨幹網,分支Site2使用CE2連線UPE接入骨幹網,分支Site3使用CE3連線普通PE1接入骨幹網。現在Site1、Site2和Site3的使用者需要進行二層業務的互通,同時要求在穿越骨幹網時保留二層報文中使用者資訊。另外要求骨幹網的UPE和SPE實現分層次的網路結構。
配置思路:
採用如下的思路配置LDP方式的HVPLS基本功能:
為實現Site1、Site2和Site3的二層業務互通,同時在穿越骨幹網時保留二層報文的使用者資訊,故需要使用VPLS技術在骨幹網透傳二層報文;
由於企業需要實現分層次的網路結構,可以選擇LDP方式的HVPLS,形成層次化的網路拓撲並實現各CE裝置二層網路的互通;
為實現PE間資料的公網傳輸,需要在骨幹網上配置IGP路由協議實現互通;
VPLS實現依靠MPLS基本功能,故需要在骨幹網上的裝置配置MPLS基本功能和LDP;
為使PE間傳輸的資料不被公網感知,需要在PE間建立傳輸資料所使用的隧道;
為實現VPLS功能,需要在PE上使能MPLS L2VPN;
為實現LDP方式的VPLS,需要在PE上建立VSI,指定信令為LDP,然後在UPE和PE1上將VSI與AC介面繫結;
為實現層次化的HVPLS功能,需要在SPE上指定UPE為自己的下層PE,PE1為VSI對等體;在UPE和PE1上分別指定SPE為VSI對等體。
1.1.2 Martini VPLS
組網需求:
如圖1,某企業機構,自建骨幹網。分支Site站點較少(舉例中只列出2個站點,其餘省略),分支Site1使用CE1連線PE1裝置接入骨幹網,分支Site2使用CE2連線PE2接入骨幹網。現在Site1和Site2的使用者需要進行二層業務的互通,同時要求在穿越骨幹網時保留二層報文中使用者資訊。
1.1.2.1 配置Marrtini VPLS的示例
採用如下的思路配置Martini方式VPLS的基本功能:
為實現Site1和Site2的二層業務互通,同時在穿越骨幹網時保留二層報文的使用者資訊,故需要使用VPLS技術在骨幹網透傳二層報文;
由於企業網路結構的Site站點較少,可以選擇Martini方式的VPLS,實現各CE裝置二層網路的互通;
為實現PE間資料的公網傳輸,需要在骨幹網上配置IGP路由協議實現互通;
VPLS實現依靠MPLS基本功能,故需要在骨幹網上的裝置配置MPLS基本功能和LDP;
為使PE間傳輸的資料不被公網感知,需要在PE間建立傳輸資料所使用的隧道;
為實現VPLS功能,需要在PE上使能MPLS L2VPN;
為實現Martini方式VPLS,需要在PE上建立VSI,指定信令為LDP,然後將VSI與AC介面繫結。
1.2Fabrica-Path的實現
1) vPC+實現雙活的閘道器路由
如果在FabricPath網路中單純的使用HSRP技術,HSRP虛擬IP地址所對應的虛擬MAC地址,只會對映到活動的閘道器的Switch ID。這樣FabricPath去往外部三層網路的流量只會從活動閘道器轉發。但是如果在HSRP環境下啟用了vPC+技術,如圖8-33所示,HSRP的虛擬MAC地址會對映到vPC+虛擬交換機的Switch ID。並且在FabricPath路由表中會學習到去往虛擬交換機Switch ID的路由通過兩個閘道器進行負載均衡,真正實現了去往外部三層網路的負載均衡。
1.3 Trill的實現
通過TRILL協議構建扁平化二層網路,實現整網無阻塞轉發及虛擬機器的任意遷移。使用TRILL協議部署資料中心網路時,首先在所有裝置上配置TRILL基本功能,繼而根據網路層次,進行如下處理:
- 接入層:
在使用者側配置CE VLAN接入伺服器,配置後使用者流量可以通過TRILL網路傳輸。如果伺服器通過接入裝置雙上行接入到TRILL網路中,建議使用者在連線接入裝置的邊緣RB上配置STP/RSTP/MSTP聯動TRILL功能進行破環。在網路側,可以調整TRILL的路由選路和控制TRILL的網路收斂來保證網路高效轉發。
- 核心層:
在網路側可以調整TRILL的路由選路和控制TRILL的網路收斂來保證網路高效轉發。在出口側,可以通過出口路由器連線企業其他網路,或者在核心層裝置上配置虛擬系統VS(Virtual System),使用其中一個VS作為出口閘道器,連線企業其他網路。
三、 資料中心私有安全通道
VPN屬於目前雲端計算環境當中典型的鏈路加密方式,在整個雲端計算環境體系當中,SSL與IPsec VPN屬於最典型也是最廣泛使用的兩種VPN技術。
資源集中屬於雲端計算的一個天然的本質,統一的資源池化,但是整個雲端計算環境當中面臨的使用者與後臺服務之間在廣域網上的安全通道就面臨了直接的挑戰,每個業務的網路都有可能在整個網際網路上進行傳遞,公有云也好,私有云也好,統一面臨著安全問題,為了在整個網路通道進行安全加密,我們多數人想到的都是VPN,因為VPN天然具備了兩種基本特性-長連線與加密。
長連線在VPN狀態的體現就是每條連線都是有狀態的連線,也就是通常會使用類似“三次握手”的機制保證它的連線性,加密技術使得整個資料包文在專遞過程當中,對於任何人來說都是不可見的狀態,保證了傳輸的安全性。
VPN的選擇有很多,對於多種選擇來說,目前比較廣泛的可靠性加密傳輸為IPsec與SSL兩種VPN技術,本節以SSL VPN與IPsec進行分享。
3.1 SSL VPN
SSL VPN同傳統的加密技術具備如下優勢:
- 部署簡潔:
目前所有瀏覽器都將SSL作為基本功能之一所整合,在使用者訪問時,通常的加密將會自動建立,不再使每一個訪問者進行配置與維護,這種零客戶端的處理機制,都極大地使得安全訪問變得如此簡單。
- 訪問的精細控制
SSL VPN可以對加密的隧道進行區分,使得每個使用者可以區分不同的網路流向,採用不同的加密方式,甚至可以提供使用者級別的鑑權機制,依據安全策略,保證授權的使用者訪問特定的資源限制,這在傳統的VPN當中實現,基本是不可能的一種實現方式。
- FIRWALL的穿越機制
因為SSL VPN工作在傳輸層之上,那麼對於傳統的NAT與防火牆裝置而言,使用者可以在任何地點安全訪問內部資源,而不會被傳統的相關防火牆所阻擋,並且在解決IP地址衝突方面優越於其他VPN方式。
- 安全保護的可靠性
由於SSL VPN閘道器隔離了內網的服務與相關的客戶端,只通過WEB介面進行瀏覽,使得客戶端的大部分木馬無法傳染到所訪問的雲伺服器之上,保證了安全的可靠性機制。
SSL握手協議過程:
客戶機向伺服器發出client hello訊息,在該訊息當中包含了SSL洗衣版本號,隨機數,會話標識,(連線未建立時,此標識為空)、密碼演算法元件配置、壓縮演算法元件配置,以及其他伺服器需要客戶機提供的基本SSL協議訊息。
伺服器端向客戶機傳送 server hello 訊息,在該訊息當中包含了SSL協議版本號,隨機數,會話標識,選擇的密碼演算法,選擇的壓縮演算法,以及其他的SSL協議資訊。若伺服器端要驗證客戶機的證書,將傳送一個客戶證書請求,將這些內容傳送結束後,發出server hello down訊息作為對client hello迴應的結束。
客戶機根據收到的資訊來驗證伺服器的身份,如果伺服器的身份無法被驗證,那麼客戶端就會收到警告資訊,驗證通過進行下一步驗證同步。
客戶機與伺服器使用master secret進行session keys(連線祕鑰)生成,它屬於對稱金鑰,在SSL會話過程中,用來進行資料的加密與解密,同時用於資料的完整性。
客戶機向伺服器傳送一條訊息,宣告後面傳送過來的資料幀將會使用加密祕鑰,接著還會再發出一條單獨的訊息表明建立連線信任時客戶端的工作已經完成,至此SSL的握手協議正式結束,開始進行SSL會話,客戶機與伺服器使用session keys來完成通訊過程中資料的加密解密以及資料的完整性檢查。
SSL記錄協議:
在SSL協議中,所有的傳輸都會被封裝記錄,記錄是由記錄頭和長度不為0的記錄資料組成,所有SSL協議當中(包括握手協議、安全空白記錄和應用資料)都是使用SSL記錄層協議進行記錄,並且其定義了記錄頭和記錄資料的相關格式。
SSL VPN分為多種型別,在基本技術框架的基礎上,可以細分為零客戶端,瘦客戶端和隧道模式三種,其中隧道模式可以用在沒有web瀏覽器的環境當中。
3.2 IPsec VPN
在傳統VPN方式當中,IPsec是目前部署最為廣泛的點對點VPN技術之一,點對多點為MPLS-VPN或者VPLS-VPN,當位於兩地的分支機構希望使用VPN技術進行通訊時,一種情況就是向運營商申請專線資源,但是這種資源方式對於一般企業而言價格高昂,而且安全性問題無法得到確切的保證,IPsec就在這種情況之下孕育而出。IPsec將閘道器裝置發往對端的資料打包加密後,在因特網上進行傳輸,對端閘道器裝置收到資料包,解封裝後再發往目的客戶端,而整個過程對於客戶端來說都屬於無感知狀態,效果跟租用運營商鏈路一樣,但是加密過程使得資料充分保持了安全性。
對於IPsec VPN,無論是哪種資料流,若一方進行了加密,而另一方沒有配,則無法通訊,對於GRE則,路由鄰居都無法建立。另一個概念是隧道模式和傳輸模式。所謂的隧道模式還是傳輸模式,是針對如ESP如何封裝資料包的,前提是ESP在最外面,如果都被Over到了GRE裡,自然談不上什麼隧道模式和傳輸模式(都為隧道模式)。只有當GRE Over IPsec的時候,才可以將模式改為傳輸模式。IPsec不支援組播,即不能傳遞路由協議,而GRE支援。
目前雖然IPsec VPN仍然為主流VPN方式,但是在雲環境下,它也不得不去面臨其管理成本高昂、由於工作在OSI第三層上,而使其協議本身無法附帶高層的安全策略、網路配置的複雜性等問題。
而SSL恰好解決了這些方面的原因,雲端計算的目的是向遠端使用者提供服務,但其實其多租戶的概念並不想讓自己的所有虛擬網路暴露在整個平臺外,但是通過IPsec進行通訊時,很容易使得本地電腦上所附加的病毒、木馬等安全隱患直接帶到雲環境當中的某個雲主機上,SSL正好在遠端接入方面補齊了雲環境下對於IPsec這個弊端所帶來的隱患問題。但是雖說IPsec年歲以大,但是寶刀未老,其安全特性依然還是使用在眾多網路環境當中,其中以下兩點為IPsec使用的兩種最多的場景。
3.2.1 IPsec over GRE
IPsec Over GRE的主意為IPsec加密在裡,GRE在外。先把需要加密的資料包封裝成IPsec包,然後再扔到GRE隧道里。作法是把IPsec的加密作用在隧道介面上,即為Tunnel口上監控資料包文是否有需要加密的資料流,有則先加密封裝為IPsec包,然後封裝成GRE包進入隧道(那麼顯而易見的是,GRE隧道始終存在,GRE整條VPN隧道並沒有被加密),同時,未在控制表內的資料流將以不加密的狀態直接走GRE的隧道,那麼有些資料包文傳遞過程當中,可能並未真正加密,使得資料包文在傳遞過程當中,無法完全保證每條資料流量的安全性,同時,IPsec並不支援組播報文的傳遞,所以此種方式在企業網資料流量導向使用的比較少。
3.2.2 GRE over IPsec
GRE Over IPsec是指,先把資料封裝成GRE包,然後再封裝成IPsec報文。實現方式是在相應介面上進行流量監控,檢測是否有需要加密的GRE流量,若是有相應流量運送過來,那麼所有的這兩個埠的GRE資料流報文將會被加密封裝上IPsec包,然後再進行傳遞,這樣保證的是所有通過GRE隧道的資料包文都會被IPsec加密,包括隧道的建立和路由的建立和傳遞。採用此種方式可以解決IPsec在傳統點對點VPN當中,不支援組播的方式,同時解決了通過隧道傳遞的所有報文都進行了加密處理,完全的保證了每條流量的安全性。
四、 跨資料中心二層網路互通
在整個雲端計算網路環境中,由於業務的批量部署,網路的便捷性,對於2層網路來說的需求正在逐年增加,越來越多的資料中心由單物理節點,向多個不同物理地域所演進,那麼在此過程當中,2層網路必然會隨之增大,甚至到了今天所面臨的跨越資料中心2層網路通訊的挑戰,雲端計算的到來也使得原有的3層主打的網路模型變為了更加靈活方便的2層網路模型,而云計算的多租戶,多業務模型使得每條業務都會擁有自己獨有的流量,又需要跨越資料中心,又需要2層網路,同時需要多租戶,多業務基於流的隔離技術,前文已經介紹了許多關於2層流量的問題,包括VPLS VPN、Fabric-Path、TRILL等協議,都是基於流的區分2層協議,那麼本節主要針對跨越不同物理地獄的2層協議進行說明。
3.1 OTV
Overlay Transport Virtualization (OTV) —-資料中心互聯解決方案
OTV是一個典型的在分散式地域的資料中心站點之間簡化2層擴充套件傳輸技術的工業解決方案. 使用OTV技術可以輕鬆在兩個站點部署Data Center Interconnect (DCI),而不需要改變或者重新配置現有的網路.此外更要的,使用OTV技術可以將不同的地理域的資料中心站點構建統一的虛擬計算資源群集,實現工作主機的移動性,業務彈性以及較高的資源利用性. 主要的OTV特點包括:
- 在多個IP互聯的資料中心站點擴充套件2層LAN網路
- 簡單的配置和選項:與現有的網路無縫的接合,需要極少的配置(最少4條命令)
- 可靠的彈性:保留現有的3層故障邊界,提供自動的多宿主以及內建的防環機制
- 最大可用頻寬:使用等價多路徑以及優化多播複製
除了在二層網路環境下的特殊處理,OTV同時對三層路由也進行了相應的特殊處理,有針對性的優化更改。資料中心區域網通常為了保證高可靠性,高穩定性,通常會設定一個出口路由器作為閘道器,這些路由器上同時啟用了高HA機制保證網路簡潔性,同時對下層裝置提供一個VIP進行虛擬路由,保證3層網路的HA問題,底層裝置會協同處理資料包文傳送到VIP所在的虛擬路由閘道器。
那麼對於資料中心之間,不同地域,之間的通訊,那麼這些保證HA的相關心跳報文就會在不同資料中心之間傳遞,這樣就會發生一個不可避免的問題,那就是不同都會網路或者資料中心的下層裝置,就會認為所有出口路由器都處在相同的地域之中,資料包很可能會從一個SITE跨越距離很長的路段,傳遞到別的資料中心的出口路由器,OTV很好的解決了此類問題,當其將多個資料中心之間的鏈路打通後,OTV就會自動阻止不同區域的HSRP、VRRP、GLBP的信令包,從而使得每個資料中心的下層裝置轉發不會傳遞到其他的區域,而是從本區域的VIP出口路由器向外傳送相關報文,保證業務的高可用同時,使得流量更加易於管理。
在面對跨越資料中心網路通訊的時候,OTV是個非常高效可靠的一款二層路由協議,其是一款專供跨越資料中心的二層互聯技術,對比VPLS有著配置簡化,邏輯清晰,在廣域網上搭建二層通道的能力正好應對了資料中心大二層網路互聯的需求,不過從技術層面上去看,VPLS也有其天生特有的優勢,就是MPLS-VPN的實踐程度與可靠性經過了大規模的驗證,但是VPLS依託於Lable封裝,那麼其無法在普通的IP網路上進行有效的搭建與透傳,而OTV恰恰解決了此問題。
3.2 EVN
EVN(Ethernet virtual Network)是一種基於VXLAN隧道的二層網路互連VPN技術,EVN本身可以通過MP-BGP協議來傳遞二層網路間的MAC地址資訊,通過生成的MAC地址表項進行二層報文封裝的轉發。
隨著資料中心的業務發展,多個資料中心進行二層網路互聯的需求逐漸旺盛,與傳統的vpls虛擬二層網路來進行比較,EVN在跨越資料中心虛擬二層網路互通方面有如下:
與VPLS相比,EVN技術可以解決上述問題:
1) EVN通過擴充套件BGP協議使二層網路間的MAC地址學習和釋出過程從資料平面轉移到控制平面。這樣可以使裝置在管理MAC地址時像管理路由一樣,使目的MAC地址相同但下一跳不同的多條EVN路由實現負載分擔;
2) 在EVN網路中PE裝置之間是通過BGP協議實現相互通訊的。BGP協議支援路由反射器功能,所以可以在運營商骨幹網上部署路由反射器,所有PE裝置與反射器建立鄰居關係,通過路由反射器來反射EVN路由,大大減少了網路部署成本;
3) PE裝置通過ARP協議學習本地和遠端的MAC地址資訊以及其對應的IP地址,並將這些資訊快取至本地。當PE裝置再收到其他ARP請求後,將先查詢本地快取的MAC地址資訊,如果查詢到對應資訊,PE將返回ARP響應報文,避免ARP請求報文向其他PE裝置廣播,減少網路資源消耗;
4) EVN網路中不再使用MPLS隧道,而是使用VXLAN隧道。VXLAN隧道可以在PE間的鄰居關係建立成功後通過EVN路由的傳播自動建立,大大減少了配置工作量。
配置EVN實現資料中心互聯示例
組網需求
如圖1所示,Site1和Site2內為二層資料中心網路,使用者要求實現不同二層資料中心網路間相互通訊,並保證EVN網路的可靠性。當運營商骨幹網中存在大量PE裝置時(舉例中只列出3個PE裝置,其餘省略),可以選擇在運營商骨幹網內配置一臺裝置作為EVN路由反射器,保證PE裝置的全連線。
配置思路
採用如下的思路配置EVN:
1) 骨幹網上配置IGP實現各個PE以及RR裝置之間的互通;
2) 配置隧道模式為VXLAN;
3) 配置PE上的EVN例項;
4) 配置PE與RR間的EVN BGP對等體關係;
5) 配置RR為動態路由反射器;
6) 配置各個PE與CE介面上的ESI;
7) 配置CE側介面;
8) 配置PE1和PE2的冗餘模式,保證EVN網路的可靠性。
3.4 虛實結合與混合雲網路
對於傳統的資料中心來說,都是各個物理伺服器的之間的通訊,那麼在雲端計算環境當中虛擬機器與物理伺服器之間的2層通訊問題逐漸的出現,同時又一種新型的概念混合雲的網路模型逐漸展開,前文介紹了大量的2層網路通訊協議,那麼我們在面對那麼多的網路複雜場景下,雲端計算帶來的網路特殊的部署模式將會變得對於每個網路工程師所必須要知道了解的,本節主要以虛實結合與混合雲網路進行闡述分享。
3.4.1 虛實結合
虛實結合的網路部署模型顧名思義就是雲端計算環境下虛擬機器與物理機相互結合的網路模型,那麼對於傳統網路來說,我們所要知道的就是如何掌控VLAN之間的通訊就可以實現虛擬機器與物理機之間的通訊,那麼在雲端計算新型大二層網路環境下,所要實現VXLAN網路之間的通訊,這時就是我們所必須要了解的一些新型模式。
1.VXLAN網路與非VXLAN網路通訊
在常見的網路模型當中,我們很好解決VLAN的通訊問題,起SVI走路由或者配置成同一個廣播域即可,那麼在此環境當中,這樣的通訊方式如果是基於2層VXLAN通訊就是個問題,我們要引入一個VXLAN L2GATEWAY的這樣一種機制,也就是說使得每個vlan對應的vlan id與VXLAN VNI所對應關聯,使得2層網路環境下,可以使得VXLAN與非VXLAN得轉換,使得傳統2層網路與新型VXLAN2層網路進行通訊。
3.4.2 混合雲網路
混合雲網路當中其實涵蓋了一種網路就是2曾VXLAN與VLAN的概念,但是混合雲網路是一種更為現實複雜的網路模型,其中不僅涵蓋了2層網路,同時也涵蓋了3層網路,那麼對於公有云與私有云是一種混合雲網路,多個異構的私有云也是一種混合雲網路,同時我們也不得不面對原有的雲網路與新興的3層雲網路進行通訊,這些都是一個新的網路模型需要每個網路工程師進行思考的問題,其中一個就是安全性問題,在公有云與私有云當中的安全性問題,通常的情況下,我們會選擇專線接入,那麼對於既保證安全性,又保證高頻寬低延遲的情況下,我們必須保留專線資源,但是還是要保持一定的安全性,同時降低成本,那麼這種情況下,我們就可以選擇最後一公里的VPN接入專線的方式,這樣既保證安全性,又保證專線的高頻寬的本質,同時節省了運營商專線出局的一些資質困擾。
有的時候我們也在考慮公網上跨越運營商的三層路由的通訊方式,那麼網路的最本質的通訊動作還是封裝與解封裝,這時候我們會面臨多個跨越資料中心的異構雲資源池,有的資源池可能會使用的普通3層網路資料包文,那麼有的會採用新型的網路資料中報文,比如VXLAN跨越運營商網路,那麼此時老舊裝置並不知道我重新封裝的VXLAN報文,只知道外面的3層頭部資訊,而且我們在配置出口交換機時都會使用SVI的技術,配置邏輯介面,將每個邏輯介面掛接在一個物理埠上,使得物理埠的損壞時,保證快速鏈路的切換,那麼對於新的VXLAN網路來說,我們怎麼才能在向使用vlan那樣去使用SVI技術呢?這時候我們就需要引入一個新的概念VXLAN L3-GateWay,其實就是VXLAN的3層閘道器,其便可實現VXLAN啟用虛擬3層邏輯介面,並且掛接在物理埠上。
五、 新興網路技術的發展
對於傳統的路由與交換裝置來說,在雲端計算的環境下,原有的網路卡功能的使用將會被各種虛擬化業務所使用,在推動虛擬化發展的高速路程當中,眾多因素使得資源再利用變得尤為重要,大多數客戶都希望在進行虛擬化、私有資料中心雲化之後,都可以使得自身的原有資源可以充分利用,網路卡也不例外,往往通過雲化之後的CPU都會利用率從原有百分之10提升到70進行使用,當越來越多的不同業務的虛擬機器跑在同一個物理伺服器上時,都會擁擠在相同的一個物理I/O通道內,對於高效能運算的環境當中,上層業務往往對於網路的I/O非常敏感,不同業務的虛擬機器往往會要求特殊的埠型別,如果模型匹配不對,效能就會大大折扣,而單一的物理網路卡不可能對於上層每一個業務實現不同的網路介面佇列模型,這就會影響到業務的效能瓶頸,新一代的網路卡與網路技術也就隨之孕育而出。那麼隨著私有云不斷地升溫,原有的虛擬網路方式帶給網路節點的壓力也會逐漸加大,資料中心對於網路的功能與效能變革也進行了時代的變化,從原有的純軟體或者純硬體的方式,逐漸轉變為以軟體定義網路為主,實現軟硬結合的新型網路變化的趨勢,在漫談雲端計算網路最後一篇中,筆者會主要描述雲端計算環境下誕生的一些新的網路技術,以及應用的場景。
相關閱讀:
2016年8月12日-13日,由CSDN重磅打造的網際網路應用架構實戰峰會、運維技術與實戰峰會將在成都舉行,目前18位講師和議題已全部確認。兩場峰會大牛講師來自阿里、騰訊、百度、京東、小米、樂視、聚美優品、YY互娛、華為、360等知名網際網路公司,一線深度的實踐,共同探討高可用/高併發/高效能系統架構設計、電商架構、分散式架構、運維工具研發與實踐、運維自動化系統的構建、DevOps、雲上的運維案例分析、虛擬化技術、應用效能檢測與管理、遊戲行業的運維實踐等,將和與會嘉賓共同探討「構建更安全、更高效能、更穩定的架構和運維體系」等領域的話題與技術。【八折優惠中,點選這裡搶票,欲購從速。】
相關文章
- 雲端計算的5大應用場景
- 邊緣雲端計算典型應用場景
- 雲端計算帶動網際網路革命
- 未來的網際網路是雲端計算還是星計算
- 雲端計算(網際網路)計算的基本機制是病毒機制
- 雲端計算網路,沒那麼簡單
- 雲端計算日常運用場景介紹!
- 網際網路與資訊保安 ——雲端計算及其安全
- 雲端計算學習路線圖素材課件:Docker容器應用場景分析Docker
- 「雲網路」VS「雲端計算」- vecloud伺服器Cloud伺服器
- 網格計算與雲端計算(PPT)
- 基於雲端計算的網路威脅管理分析
- 雲端計算實現物聯網的核心,雲端計算應該怎麼學?
- 什麼叫做雲端計算?雲端計算基礎學習路線
- 青雲QingCloud 在不同場景化中的雲端計算應用GCCloud
- 雲端計算有什麼用?雲端計算的應用領域有多大?
- 雲端計算 - 內容分發網路CDN技術與應用全解
- 趣味漫畫:雲端計算的起源
- 雲端計算學習網站都有哪些?學習雲端計算的方法學習網站
- 計算機網路 -- 應用層計算機網路
- 計算機網路--應用層計算機網路
- 計算機網路 - 應用層計算機網路
- 雲端計算與網格計算的深入比較
- 千鋒雲端計算畢業設計論文:PXE網路裝機流程二
- 開心網與雲端計算
- 從網際網路+角度看雲端計算的現狀與未來
- 雲端計算管理平臺之OpenStack網路服務neutron
- “大資料、雲端計算”決勝企業網路安全大資料
- 美國兩大網際網路巨頭加快發展雲端計算
- 雲端計算,網格計算,分散式計算,叢集計算的區別?分散式
- 雲端計算-從基礎到應用架構系列-雲端計算的演進應用架構
- 雲端計算開源產業聯盟:2019年雲端計算與邊緣計算協同九大應用場景(附下載)產業
- 雲端計算學習路線圖素材課件:雲端計算常用的開源工具開源工具
- 雲端計算演進與應用
- 學習雲端計算有哪些優勢?雲端計算教程學習路線圖
- 雲端計算影片教程:2020年雲端計算學習路線圖
- 零基礎雲端計算學習路線,到底什麼是雲端計算?
- Google CEO施密特:雲端計算將替代網格計算Go