2013年4月26日 星期五

Link Aggregation 靜態埠聚集/頻寬聚集 技術



一台電腦、2個網路孔,插上2條線會讓速度變2倍嗎?
http://www.techbang.com/posts/10090-the-dual-network-not-twice-times-faster-speed-the-computer-96-giken-wang-tong#comments-list

可以參考T客邦怎麼說,如果對於細節內容夠感興趣,可以繼續看下去。
事實上T客邦只講了一半,而且沒有技術內容說明,本人在此進行詳細說明。

Q1:今天我有一台電腦同時使用無線上網和有線上網,當我下載東西的時候,能夠使用到的頻寬會是兩者加總嗎?能夠的話,為什麼能夠?不能夠的話,要怎麼做才能讓他能夠?


A1: 不能夠,頻寬不會是兩者的加總,通常有線跟無線網路會是不同的網段(係指會拿到不同的IP位址)PC上每一個應用服務在網路上被識別的方式是Socket(IP+Port)來確定端點服務身份,任何種類的服務不會橫跨在兩個IP之間(負載平衡除外)。再進階一點,如果我有兩張有線網卡同時連線上網,即使同網段,區域網路頻寬也不會是兩者加總,因為還是拿到兩組不同IP

*除了伺服器端有對應技術讓他可以將兩個實體介面綁成一個邏輯介面時(Teaming技術),邏輯頻寬可以加總,只拿單一IP,但是單一個別服務流量上限一樣受限於單一介面的實體速度(由於ARP的關係),這就說來話長了...這是個非常不容易被實現的LAB,某CCIE的著書中有提到過類似案例。

可以依據一個簡單的實驗兩驗證服務不會橫跨兩個介面,拿個BT來測試看看就知道了,並不會在所有可連線介面上都有流量,只會有某一個單一介面有流量(而且這介面是唯一的,OS預設只會使用其中之一)


Q2:如果在Q1的情況下使用下載服務,當其中一種連線失常的時候(有線或無線故障),網路下載服務能否自動切換到另一種網路介面? 所有網路程式服務種類都能切換嗎?

A2: 這問題是可以,但是一定會產生中斷重連,關鍵在於你的應用程式是不是連線導向類型,係指即時連接的服務,HttpsTelnet這類型的協定服務一定會產生中斷需要重連的現象,而像是續傳服務、串流類型服務,則會產生一段時間會沒有下載量,因為作業系統會將應用程式的服務切換到可用的網路連線過程中產生中斷,所以一般PC雙網卡上網,可以達到線路容錯,但是沒有負載平衡。



延伸問題
Q3.那我如何控制服務跑在指定介面上(Windows為例)?如果我有一堆介面都能上網,無線網路、有線網路、藍芽等等亂七八糟介面。

關於Q1議題延伸與Q3問題的答案

連接雙邊網段的架構示意圖:
Internet連接10.0.0.0/24網段連接網卡A
Internet連接192.168.0.0/24網段連接網卡B
兩張網卡都在同一台PC(或Server)上

當拓樸兩邊都能上網,在近端位址部分仍含是可以被正確的使用不會固定從一張網卡出去,理由是因為本機路由表會有直連路由,依照路由表規則沒有問題。
路由三大選定準則為:1. Prefix Match – 最大吻合的網段 2. Min Administrator Distance (Routing Type) – 最小的管理距離/最佳的路由協定 3. Min Metric – 最低的權值,在此不做深入解釋,而在近端最大吻合網段符合即送出。

舉例來說,當你要連10.0.0.1這台主機的時候,肯定會從A網卡出去;當你要連192.168.0.1這台主機的時候,肯定是從B網卡出去。但是當你某網路服務要連外網的時候,肯定會固定從某一介面去,不會偶爾A偶爾B,也絕對不會出現某項固定服務的封包從A網卡出去但是對方從B網卡回應你的情況,這不可能會發生。近端位址關於從哪邊出去會取決於你的本機路由表,但是遠端位址(WAN的位址)OS作業系統只會擇其一介面當作出口,並不會是雙邊都當出口,這點務必切記,因為IP必須具有唯一性。

鳥哥在網路這段給的比喻很貼切,IP就是門牌/大樓,Port代表樓層,ApplicationService代表收件人。要寄給同一個人的貨物不可能寄到不同門牌的地址,所以兩張網卡在不同網段的出口問題的概念就釐清了九成。

根據這篇微軟在問題QA的答覆中,我們很清楚的可以知道網路介面有被使用的優先順序(那個IP在網路上代表這台主機),它可以讓使用者去調整;因此這部分就是Q3的答案。

所以要怎樣才能做到兩個實體介面綁在一起,然後成為一個單一的邏輯介面?

首先,要知道這項技術標準為IEEE802.3ad,所以可以爬到一堆文章關於這項技術和支援的產品,重點是你的網路設備(SwitchRouter)必須支援這項標準,以及你的網卡必須支援這項技術,在Server端我們把這項技術稱為TeamingTrunking,在網路端我們把它稱為Link aggregation

以下名詞都是近義詞或同義詞,在技術上代表網路上兩個端點設備以兩條以上的實體線路連接成一邏輯線路之技術:
Link aggregation [網路設備]
Port Trunking [Server網路埠]
Link Bunding
Ethernet/NIC Bounding [乙太網卡]
NIC Teaming [Server網路卡]

最普遍被使用的Link Aggregation技術為Link Aggregation Control Protocol,被定義在IEEE 802.1ax中,所以這是項標準技術,幾乎所有商用網路設備皆有支援。

*Cisco 將此鏈路合併技術稱為Etherchannel,並自創私有協定,稱為PAgP(Port Aggregation Protocol),但是務必注意,PAgP是思科專利,所以僅限使用在兩端都是Cisco產品且有支援,否則連接會失敗;當然Cisco設備也可以選擇使用LACP,而且近年Cisco新產品線有不支持PAgP傾向,向標準協定LACP靠攏。
*Trunking有兩種截然不同的含意,在伺服端他代表伺服器用兩條以上的實體線路跟其他設備介接;在網路領域他有另一含義為PacketTag(這是一項Ethernet Frame 802.1q tag技術在此處我們先略過說明),但此兩者差異務必釐清。

架構示意圖:(Teaming至少要求一條以上的實體線路)
Server NIC. A -> 納入Teaming -> Logic NIC. C
Server NIC. B -> 納入Teaming -> Logic NIC. C
設定完Teaming後,會形成一個單一邏輯介面,在Windows中就會是一個邏輯的網路連線,並且可以賦予固定的IP位址,當然鏈路的可合併數量不只一條,這必須看網卡與網路設備雙邊支援情況。

依照Cisco標準,Cisco設備間(網路設備與網路設備對接) Etherchannel鏈路合併最大數目是8條,邏輯極限頻寬為實體線路的8倍;而創造出來的邏輯鏈路稱為Port Channel,單一設備最多允許同時存在64條邏輯線路(64Port channel)
*Cisco設備在堆疊(Stack)後,會有例外情況,將設備間Etherchannel最大合併數目調整到16條;但實際運用情況非常少,因為Stack堆疊線的頻寬比Etherchannel有效率上太多,按Cisco釋出的資料來看,目前市售最常見到的C3750產品堆疊線可提供64 Gbps堆疊頻寬及95 Mpps堆疊傳輸效能(前提是要型號相同)

按照伺服器硬體規格(ServerStorage),通常常見的硬體網路卡為2-4Port,大約可插卡也是2PCI-XPCI-E的網路擴充上限,就算兩張卡8個連接埠都做成單一邏輯鏈路也是可行的,但是很少真正會實現這樣的架構,因為實際網路流量不會使用到這麼巨大,且目前新規的Gigabit網卡速度都很足夠,兩條實體線路就足以形成一條2Gbps的邏輯線路,已經足夠提供絕大多數的日常服務。

Server端完成Teaming設定後,會產生出一個Logic的網路介面和連線圖示,可以針對此圖示進行IPv4IPv6相關設定,但是要記得MAC位址並未有任何的改變,依然兩張實體網卡都有各自的MAC位址,都會在主機端留下兩筆ARP位址,從第二層角度來看仍然是兩條線,從第三層的角度來看是一條線,而在第三層形成鏈路容錯,不論底層是壞單一條網路線、主機連接埠或是網路設備連接埠,都不會對現有服務有任何影響,在TeamingARP將會迅速切換,連使用ICMP協定的Ping都不會有封包損失,是可用性非常高的技術;因此所有應用層服務都沒有任何影響,IPPort都不需要任何改動就能以接近不中斷的形式提供網路服務,達到高可用性。

因此,了解技術原理後,就能夠知道為什麼所謂單一服務頻寬仍受限於實體線路頻寬的最大上限。舉個例子,有台Server以兩條1Gbps的實體線路鏈結後產生單一邏輯線路(2Gbps)Switch對接,此台Server同時提供Email服務與FTP服務,可能的情況是Server會以其中一條實體線路(代號A)乘載Email服務,另一條(代號B)乘載FTP服務,並且IP相同。

假設今天FTP流量滿載,B線路頻寬達到使用上限,是否會切換流量到A線路?答案是不會,理由是因為ARPMAC在封包封裝時已經選定走哪一條線跟哪一張網卡,這點並不會在Teaming的功能上被自動切換,也不可能自動切換,了解TCP協定都應該很清楚,因為線路仍然可用,只是滿載而已,所以流量滿載一樣得乖乖排隊,或者是封包被遺棄重送。這個是很多網路工程師的盲點,很多都認為每種服務都能吃到上限2Gbps頻寬是錯誤的認知。因此Teaming並不是負載平衡機制,而是線路容錯機制,負載平衡是指服務與服務之間,而非單一服務項目。以上是依據CCIE著書經驗而來,並非本人做過實驗證實。因此,實體A網卡出去實體B網卡回的情況只會存在於單一實體介面斷線的時候才會發生(不論甚麼原因斷線),但是對於第三層以上的服務是無感的。

結論,對於Server的總可用頻寬而言,Teaming確實可以提供較寬裕的頻寬(多種服務),但是單一服務並不會因此有超過一個實體網路介面的可用頻寬,但是提供了兩設備間完善的線路容錯解決方案。

能否完成跨越SwitchTeaming
通常我們將網路設備分成L2設備與L3設備,思科普遍將功能超過L2層級的Switch稱為多層級Switch。最常見的Teaming架構會是像下圖一樣,為Server與單一網路設備互連,將多條實體線路綁在一起,但是當Switch發生故障、斷電、損壞的時候,即意味著伺服器將離線(off line),這樣架構對於某些需要提供7*24的服務來說有欠周詳。


很多企業希望達到所謂的端點容錯,也就是任何一台網路設備或線路出現故障或損毀的時候,影響降到最低,甚至完全不影響現有網路運作,所以跨越SwitchTeaming技術就顯得重要。



在此之前,我們先看一張有趣的圖,這是兩種非常被泛用的網路架構,左手邊的網路架構在大規模的網路下,常被用於底層網路建設,例如:Distributed LayerEdge Layer間的互接;而右手邊的網路架構,通常被用於頂層的網路設備間,例如Core LayerDistributed Layer間的互連。兩個架構都有一個共通之處,那就是具有任一線路、任一孔埠、任一設備壞掉,均不會影響現有網路運作的特點,但是以效能來講,右邊明顯比左邊好得多,因為右邊是兩層式網路,左邊則是多層(至於是幾層則是要看Spanning TreeBlocking Port的位置跟串接設備的多寡,在此略過相關原理),左邊架構的成本較低,右邊明顯高出許多,光是看實體佈線成本就能看得出來。

回歸正題,今天如果是伺服器與網路設備互連,採用的肯定是類似右邊的架構,將底層網路裝置換成了Server,於是就變成了下圖。

這是一個很常見的伺服器與網路設備互連的接法,但是這樣的架構通常會與Teaming同時使用。如果不使用Teaming,兩邊網路就算是同樣網段也會拿到不同IP,在單一線路故障或服務中斷的時候,軟體設定不變更是無法迅速切換的。

如果使用了Teaming,並在兩台Switch間設定Port存取相同的Vlan,可以實現線路的容錯,但是頻寬能否合併使用必須要看Switch之間的連接方式,如果是一般網路線或光纖互相連接兩台Switch則無法進行頻寬合併,無法進行跨機器的Channel Group生成Port Channel,如果兩台Switch是用Stack線互接則是可以實現頻寬合併;如果設備是Nexus則可以用VPC(Virtual Port Channel)互連。
*如果想要加強連接與頻寬,也可以在單側使用兩條以上的實體線路連接。

架構的測試,事實上,依照圖上的方式連接ServerSwitch設定TeamingLCAP的網路可用性相當高,依據實際測試的結果,網路在被拔線的情況下預設Ping不會有任何的封包損失,這表示了高可用性。

DHCP Have Acknowledgement in UDP?


DHCP Service 並不會使用到 TCPPort
根據預設只會使用UDP 6768 Port
67 UDP    Bootstrap Protocol (BOOTP) Server; also used by Dynamic Host Configuration Protocol (DHCP)        Official
68 UDP    Bootstrap Protocol (BOOTP) Client; also used by Dynamic Host Configuration Protocol (DHCP)        Official

[運作方式]
一開始Client沒有ip資料

DHCPDISCOVER
Client發出DHCPDISCOVER廣播封包(UDP port 67),尋找DHCP Server

DHCPOFFER
Client開始監聽UDP port 68(任何)DHCP Server收到DHCPDISCOVER封包後,會發出DHCPOFFER廣播封包(UDP port 68),內含提供的ip資料。使用廣播封包是因為此時Client端還沒有配置ip

DHCPREQUEST
Client收到可能來自多個ServerDHCPOFFER封包後,從其中挑選一筆來回應(通常就直接使用最早收到的一筆)。這時仍是使用廣播方式,向所有Server發出DHCPREQUEST(UDP port 67),內含挑選使用的DHCP Server IP,確定使用提供的資料,並提出其它選項需求(netmask/gateway..etc)。而其它未選用的DHCP Server也可籍此廣播封包瞭解工作已完成。

DHCPACK
Client繼續監聽UDP port 68選定的DHCP Server收到DHCPREQUEST封包後瞭解Client已確認使用,即發出DHCPACK封包(仍為廣播封包,UDP port 68),內含所有Client要求的選項資料。Client接收到此封包後即可依其內容配置IP資訊,完成DHCP請求。

從以上的運作流程來看,client僅會監聽UDP 68 PortServer所發出的DHCPACK封包也一樣屬於廣播封包,切記。