【問題】2個乙太網路連線之流量負載平衡

[DuckChang]

各位先進您們好，我最近遇到一個在Linux上網路的問題請教各位先進。
我在Linux上開發一個即時多媒體服務，為了提昇多媒體伺服器服務的效能，
我們希望用超過1條乙太網路連線來輸出多媒體資料。所以我們的伺服器程式
會Bind 2個Ethernet IP，讓伺服器和Client指定IP收送資料。
例如：第一個使用者用192.168.0.1當做伺服器
第二個使用者用192.168.0.2當做伺服器
理論上，多媒體資料會分別從2個乙太網路連線收送資料，理論上頻寬會加倍。
我的不使用 Trunk的方式，是因為Trunk 比較需要消耗CPU，而且效能提昇
約30％而已。我們也不考慮硬體Trunk，因為需要Switch支援。

但是出現一個神奇的事。
首先頻寬沒有加倍，且一樣只有一條乙太網路連線的效能。
再來，觀察Client的訊息，Client確實分別連到2個IP上。
這讓我感到非常的納悶。

經過一段時間的觀察，我發現可能是ARP的問題。
因為我用ARP指令觀察 ARP Cache發現，所有Client的IP都MAP到Eth0，
而不是分別MAP到eth0及eth1。
可能是因為這樣，所以所有的資料都從eth0這條線出去。
實際觀察網路卡的燈號，狀況的確如此。

請教各位，我能否關閉ARP Cache自動學習的功能，
並且指定Client IP所MAP到的乙太網路連線。

謝謝！！
Duck Chang

[wangcm]

兩片網卡接在同一個subnet時只會走routing table上第一個path,除非跑policy routing(有點複雜,依鵝看來不見得比trunk/bounding佔便宜 ),如果只是怕100base跑不動的話何不直接換成GbE的NIC來的省事啊 ....BTW,鵝看過的VOD大部份不是NIC跑不動,而是storage跑不動,而且要怎麼讓storage經得起on demand的摧殘是個大學問就是了 ....

[DuckChang]

謝謝您的回應與意見

首先，我已經用超過1張GbE NIC
第二，Trunk及Route 的方式我都試過，結論是
Hardware Trunk > Route > Software Trunk
第三，Storage存取演算法是我們自己開發。效能很好。

[wangcm]

作者: DuckChang

首先，我已經用超過1張GbE NIC

假設一個session要吃5Mbps,那1port GbE保守估計能service 150個user好了,應該蠻好玩的 ....

作者: DuckChang

第二，Trunk及Route 的方式我都試過，結論是
Hardware Trunk > Route > Software Trunk

那可不可以請問一下server上看到的routing table長成怎樣,client是如何分別連上兩個GbE的(i.e. DNS上一台機器有兩個A record或在client上直接指定IP )....以鵝個人看法,問題應該不是出在client端而是在server端,在不動policy routing為前提下(i.e.您提過的Hardware Trunk > Route > Software Trunk,其中的"Route"應該是指policy routing吧 ),server到同一個subnet就只會走第一個path----假設server有A/B兩個interface/IP好了,當client->A時當然天下太平,可是當client->B時因為server端routing table的關係會從A->client(i.e. client看到封包的source IP/MAC address可能會變成A,或是IP維持B但MAC address變成A),此時client可能直接把封包drop掉(client直接連到IP B的場合)或重新連線到IP A(一台機器有兩個A record的場合),而要是IP維持B但MAC address變成A的場合就會造成原來應該走interface B的traffic塞在interface A了,要讓server有效應用那兩port GbE勢必得動policy routing或跑trunk(不過這麼一來會吃CPU,再說GbE本身也會吃CPU----您確定此時server的CPU和I/O bus沒問題嗎 ),依鵝看來還是換成10GbE比較省事(2port 10GbE NIC只要US$1xx,而且10GbE NIC通常支援TOE可以分攤CPU的loading,不過有10GbE port的switch還是蠻貴的就是了 )....

作者: DuckChang

第三，Storage存取演算法是我們自己開發。效能很好。

傳統的機械式storage在應付數以百計的concurrent session方面恐怕不會太好看,不過鵝差點忘了現在有SSD可玩了,但同樣是鵝的個人看法,SSD用在這類場合的TCO不見得很划算就是了(不論是每GB的單位成本或是server以concurrent session計算的TCO )....

[wangcm]

剛在Virtualbox中試了一下(host跑Win XP,guest是linux kernel v2.6.25),guest用兩個virtual NIC連上host,分別在host端ping guest的兩個IP,用wireshark看到的是host ping A時guest->host的IP/MAC address都是A,而host ping B時guest->host的IP是B,但MAC address是A(同時是走interface A->host的,而不是走interface B->host ),但host->B部份還是走interface B(而且host上看到的arp的確是interface B的MAC address ),so ....