Link Aggregation by linux

資料來源 http://www.geego.com.tw/tech/tech_word/20060821/index.htm#

Google 搜尋 linux 網路 Link Aggregation 

(一) 前言

Linux 核心能支援的功能真的是不勝沒舉， Ben 哥跟大家說一個最近發生的故事，間接體會 Linux 無遠弗屆的威力。日前 Ben 哥在奇科電腦教授 LPI Level 2 的課程當中，有位在業界從事網路系統管理的學員問了 Ben 哥一個問題 --- 「如果在同一個區域網路，要架設一台比周圍電腦擁有更多網路頻寬的主機，我要花多少錢、買什麼樣的網路設備」。 Ben 哥回答他，你只要花不到 1 千塊的新台幣，買幾塊「螃蟹牌」的網路卡，就可以立即倍增一台 Linux 主機的網路頻寬！

其實「如何在 Linux 系統下結合多張網路卡來增加網路頻寬」，這個議題 Ben 哥以前便常拿來作教學的實作練習！此次藉由本期的技術專欄，跟各位讀者細述說明「在 Linux 下如何結合多張網卡，並配合相對應的頻寬來增加網路的傳輸速率」 ! 同時間還可以讓該台機器提供「連線備援」的機制 !! top!
本期技術文件所需
實驗設備
   

1. Linux 機器乙台， 兩張以上的乙太網路卡
2. Cisco 3550 交換機乙台
所需軟體
及Linux
核心
   

1. Linux 機器：核心 2.4.32 版， bonding 所需的指令：「 ifenslave 」
2. Cisco 3550 交換機的韌體 ：「 c3500xl-c3h2s-mz.120-5.WC15.bin 」
基本知識
   

1. Linux 802.1Q 的設定 ( 詳見 Linux Guide 第十一期 ) 。
2. Cisco 3550 交換機上 Etherchannel 以及 802.1Q 的設定。

(二) Linux 中 Bonding 的意義

Bonding 的中文意義為「結合」，那到底要結合什麼東西呢？其實就是利用軟體的方式 (Linux Bonding 的技術 ) 來結合網路傳輸的頻寬！舉個例子來說，每張網卡傳輸速率為 100Mb ，假使我們 Bonding( 結合 ) 四張網卡，就可以把這四張網卡視同為一張，而這張網卡的傳輸速率則為 400Mb/s 。

(三) 如何讓 Linux 支援 Bonding

要使 Linux 能支援 Bonding 的功能，以及讓使用者能操作 Bonding 的指令，有幾個必備條件：

1.  Linux 核心必須支援 bonding 的功能。

    在核心的選項中，各位可以在主選單下的「 Network Device Support 」裡，選取「 Bonding driver support 」；在這裡要特別提醒各位的是，請選用與 Ben 哥相同的核心版本「 2.4.32 」。因為早期 Linux 核心版本的 bonding 支援能力，並不支援待會我們所需要用到的「 802.3a d 」通訊協定。另外要特別注意的一點是，在 Linux 中的 bonding 設定，其對於「 802.3a d 」的命名為「 PAgP 」，但在 Cisco 所屬的設定名詞中，「 PAgP 」並非指的是「 802.3a d 」，而是「 LACP 」；兩者是完全不相同的。因此，讀者們在使用 Cisco 交換機設備時，務必弄清楚不要搞錯了，不要選到「 PAgP 」。

2. 必須要有 ifenslave 指令。

    ifenslave 為設定 bonding 功能的唯一指令，與核心所使用的版本有相當高的倚賴性，如果各位使用的核心是 2.4.32 版本的話，可以在核心原始碼根目錄中「 Documentation/networking 」的目錄位置下，找到「 ifenslave 」的原始碼—「 ifenslave.c 」，同時間也可在上述同樣的目錄下找到「 bonding.txt 」的檔案，其中簡單的陳述了在此 Linux 版本中，支援了哪些功能。

    因此，我們可以進行編譯適合核心版本 2.4.32 的「 ifenslave 」指令。

    致此為止，我們已確定也必須確定系統的核心支援「 bonding 」功能，再者其核心版本為 2.4.32 ，且有相對應的「 ifenslave 」操作指令存在。

 

(四) Cisco 支援的連接埠整合控制協定介紹

Cisco 對於交換機連接埠的整合有幾種方式，其一是先前描述過的 LACP ( Link Aggregation Control Protocol) LACP 是 IEEE 標準規格「 802.3ad 」協定中的一部份， 802.3ad 協定規範了：交換機上許多不同的實體連接埠，可以邏輯性的共同結合在一起，進而視為一條實體線；除了 LACP 以外， Cisco 本身也有其他相類似的功能，例如： Etherchannel 以及 PAgP ( Port Aggregation Protocol) 。

(五) 實驗目標

在此次的實驗中， Ben 哥需要讀者們把 Linux 的機器設定成為一個支援 802.3a d 的伺服器，以 802.3a d 的通訊協定方式與 Cisco Catalyst 3550 的交換機連結，最終達成連接埠整合的目的。

以上的網路拓墣為此次實驗的主要連接方式，我們以第二層 (Layer 2) 的連接為本次實驗的主軸，以下為實驗的步驟：



Step1：設定Linux伺服器
1.
首先， Ben 哥已經有一台 Linux 機器，其核心版本為 2.4.32 ，而且也已經有預先編譯好的 ifenslave 指令，該指令存於目錄「 /root 」中， Ben 哥使用一片有四個連接埠的網路卡 ( 附圖一 ) ，每個連接埠都有其獨立的 MAC 定址，因此可以將之視同為四張網卡，其設備代號各為： eth2 、 eth3 、 eth4 、 eth5 。

2.
確定了網路卡可以使用之後，接下來就必須建立一個虛擬的整合連接介面 (bond0) ，以便將 eth2 、 eth3 、 eth4 、 eth5 整合在一起。首先，我們必須安插支援 bonding 的核心模組，在安插模組的時候，同時通知核心待會在 bonding 時所要支援的模式，在這個版本 ( 2.4.32 ) 中，總共支援了 7 種模式，第四種模式就是「 802.3a d 」，因此在安插 bonding 模組的同時，需在其後加上『 mode= 802.3a d 』或是『 mode=4 』的命令參數 ( 兩者擇一使用皆可 ) ；另外，再加上一個用來「監控各個連接埠連接狀況」的參數，這個參數為『 miimon= 數字』 ( 數字表示多少 ms 之意 ) ，讀者們可以從下圖看到 Ben 哥如何確認核心是否支援 bonding 的功能，進而配合相關參數，安插 bonding 模組的整個過程。

3.
在核心支援 bonding 的功能後，在『 ifconfig –a 』指令的標準輸出中，會有一個名為「 bond0 」的介面設備，這個就是用來整合各張網路卡的介面，是以我們先對 bond0 介面設定其 IP 位址並將該介面啟動運作。

4.
啟動完 bond0 後，皆下來當然就是把各個實體網路卡整合到 bond0 中，這時就要使用剛剛 Ben 哥教大家預先編譯好的「 ifenslave 」指令！只要鍵入『 ./ifenslave –v bond0 eth2 eth3 eth4 eth5 』即可。

5.
到現在為止， Linux 伺服器已經設定好了，但是網路線另一端的 3550 交換器還沒有作任何的設定。是以我們先 ping 路由器的 IP 位址「 192.168.10.2 」，看看封包是否能夠到達路由器；結果當然是不行。因為交換器那一端並還沒有將 802.3a d 通訊協定設定進去，所以通訊協定不同，勢必就無法相互傳遞資料。

6.
觀察檔案內容完畢之後，再次鍵入『 ifconfig 』指令來確認是否包含剛剛所設定的各項設備。

7.
到現在為止， Linux 伺服器已經設定好了，但是網路線另一端的 3550 交換器還沒有作任何的設定。是以我們先 ping 路由器的 IP 位址「 192.168.10.2 」，看看封包是否能夠到達路由器；結果當然是不行。因為交換器那一端並還沒有將 802.3a d 通訊協定設定進去，所以通訊協定不同，勢必就無法相互傳遞資料。

觀看第2步驟!!>>


Step2：設定Cisco的交換器

1.
在這個階段的實驗中，我們使用 FastEthernet 連接埠 13 到 16 ，分別對應到 Linux 伺服器上的 eth2 、 eth3 、 eth4 、 eth5 ；在 Cisco 交換機的 IOS 文字使用介面下，可以使用範圍指令 (range) 來同時間對很多連接埠下達相同的指令。如下圖所示，我們利用範圍指令進入連接埠設定模式，設定步驟順序如下：

(1) 下達指定 VLAN 的 ID → ( 2) 設定連接埠的模式 → (3) 加入 802.3ad 的支援，也就是 LACP 。

2
設定完成後，鍵入『 show running 』指令，觀察一下 FastEthernet 連接埠 13 到 16 的設定狀況。 至此， Cisco 的交換器設定完畢。

觀看第3步驟!!>>


Step3：測試連線狀況

1.
在Linux伺服器以及Cisco交換器這兩台機器上，讀者們都已經完成了802.3ad的設定，接下來就是驗收設定成果的時候了。我們可以從Linux伺服器端ping交換器另一端的路由器，其結果是成功的，由此證明先前兩個設備的設定完全無誤。

 

觀看第4步驟!!>>


Step4：測試連線的備援機制(Redundancy)

1.
連接埠整合的另一個好處就是可以提供連線的備援機制，以本實驗為例，我們使用了四個網路連接埠連接到交換器，理應獲得 400M b/s 的總頻寬；順帶的這種網路連線機制也提供了連線備援的可能。簡單來說，四個網路通路中，如有其中 一兩 個連線有問題，這個連線機制 ( 802.3a d) 會偵測到連線的狀況，讓另外兩條正常工作的連線接替其他工作。 為了讓讀者實地觀察到這個狀況， Ben 哥先從 Linux 的伺服器 ping 路由器，然後在第 4 個 icmp 答應時， Ben 哥把 eth2 以及 eth3 的連線拔掉，各位可以從下圖『 mii-tool 』的指令輸出中，看到 eth2 及 eth3 是沒有連線的，當下，經由 eth2 以及 eth3 的封包就到達不了路由器，但是過了一分多鐘之後，在第 77 個 icmp 的封包之後，連線則自行恢復。

實驗步驟完畢!!

C misc

• 自由軟體鑄造場說明文件
• 用 Open Source 工具開發軟體
• 快快樂樂學 GNU Debugger
• 我所知道的 C 語言

Jserv

http://blog.linux.org.tw/~jserv/
所有有關linux 程設的東西

Raycom

Dilemma:

1. pay自己講太低
sol:
已成定數沒辦法, 但似乎其他公司也不可能開超過,
只是在於自己貪心問題, 多開五萬應該也會上

2. 只找一家
sol:
Ray太早給offer, 也太快要答覆
或許多一個星期也好
但又不想開104, 那種太大海撈針
酬勞都不好談

3. Ray是小公司可能制度與未來不確定
sol:
除了失去大公司的穩定性
但是大公司穩定薪水就會變低
而所謂穩定在台北也是不完全, 因為沒有房子

4. 怕之後會常加班
sol:
有可能, 但因為未知數太高所以只能期望不要


5. 搬家
sol:
如果把ray當成暫時之所
那麼搬家變的有點非必要性
目前缺點: 1. 吃不好 2. 大馬路很吵
優點: 綠地多, 視野寬闊

解惑

//code 1----------------------------------------------// fail

char str1[] = "This is a string";

char *p = str1;
char **pp;

int main()
{
    *pp = p; //fail // pp = &p; //success


    printf("str1 = %s\n" , str1);
printf("p = %s\n" , p);
    return 0;
}

//code 2----------------------------------------------// success

char str1[] = "This is a string";
int main()
{
char *p = str1;
char **pp;

    *pp = p;

    printf("str1 = %s\n" , str1);
printf("p = %s\n" , p);
    printf("*pp = %s\n", *pp);
    return 0;
}


雖然第二個程式不會當機
但是兩個程式都有瑕疵

在於*pp = p;
pp初始時沒有給予數值, 所以存的是一個亂數, 此亂數代表某個位址

所以這個指令*pp = p
表示將p存的(位址)資料存到pp指向的(亂數)位址

該衰毛的位址資料就會被覆寫造成錯誤

軟體產業的知識經濟

軟體產業的知識經濟




近來，「知識經濟」一詞在媒體、會議中出現的頻率很高。連台灣地
區政府都夸夸而談知識經濟在十年後，可們創造多少產值云云，知識
經濟的魅力可見一般。許多人都把知識經濟看做是一種無本生意，不
用原料設備，財源就會滾滾而來。但真相又是如何？


專業知識是一種無形的資產，不容易評估其價值。但是大致上，專業
知識可以分成四個層次，價值由低而高分述如下。


Know-What
受過訓練，通過認證，而精通某領域的基本知識，這類的知識就稱為
know-what，也稱為認知性的知識（cognitive knowledge）。know-what
是一切知識的根基，但是有了 know-what，並不表示有能力可以活用
這些知識。


許多軟體人員在通過專業認證之後，就開始學會獅子大開口了，其實
他們的知識可能還停留在 know-what 的階段，而 know-what 階段的知
識對公司來說是沒有太多生產力的。此階段的軟體人員應該努力地提
昇自己，以進入下一個階段，也就是 know-how。


Know-How
know-how 階段的知識也稱為進階技能（advanced skills），指的是可
以活用書本上學來的知識、理論，以解決實際的問題。know-what
的知識或許可以透過「填鴨」方式生硬地吞下去，但是 know-how
的培養一定要透過實務經驗的累積與體會。


如果有一個好老師或 leader 的引導，know-what 可以很快地提昇成
know-how，靠自我的培養則通常會比較辛苦。不過，當我要引導學生
由 know-what 到 know-how時，往往會有許多「不識貨」的學生嫌我囉唆。


Know-Why
know-why 階段的知識指的是對整個系統的掌握度（system understanding）
，也就是瞭解各種知識背後複雜交錯的因果關係。有了know-why的知識
，軟體人員除了能順利地進行軟體計劃之外，還能進一步解決更大、更
複雜的問題，因為一切的知識都是有條理的。具有know-why的軟體人員
對整個計劃具有強烈的「第六感」，可以直覺地做出正確的判斷，預先
知道可能會遇到的問題。計劃的 leader 必須具備know-why，才能全盤
掌握計劃。


Care-Why
care-why 指的是自發性的創意（self-motivated creativity）。有了源源不絕
的創意，才能保持高度的競爭力。軟體產品相當需要創意和洞燭先機的
能力，在大家一窩蜂搶做某軟體或某服務之前，就已經先完成深度的耕
耘，技術自然比別人來得紮實，也能迅速地迎合市場需求，為公司創造
最大的利益。


時間和努力見證知識經濟
欲創造軟體界的知識經濟，沒有特效藥，而是需要相當時間的努力才
會有成果的，軟體公司應該致力於提昇員工的知識層次，由know-what
進化到 know-how，再由 know-how 進化到 know-why，乃至於 care-why。
而軟體人員也不應該以自己現有的知識為滿足，畢竟知識是無止境的。


我們都該問問自己，自己的知識是在哪個層次呢？




本文作者：蔡學鏞
張貼日期：11/13/00

啥是Design Pattern

來源http://www.oreilly.com.tw/column_sleepless.php?id=j008


Design Pattern 新解


什麼是 Design Pattern？許多人一講到 Design Pattern，就會扯到什麼建築設計，因為他們全都是看四人幫的「Design Patterns」經典本的解釋，沒消化就照單全收。 如果不能用更生活化的方式解釋 Design Pattern，我會懷疑他們是不是真的瞭解 Design Pattern 的真義。

什麼是 Pattern
Pattern 最簡單的定義是：只要是一再重複出現的事物，就是 Pattern。依照此定義，生活中就可以找到一堆 Pattern 的例子：

第四台廣告中的 Pattern：

1. 原價 ...，現在購買只要 ...，還送你一組 ...，請馬上來電 ...，如忙線中請稍後再撥。
2. 利用分割畫面顯示出使用前使用後的差別，來加強說服力。例如：由 C 升級到 E（註：C 和 E 不是指程式語言）。
3. 找人現身說法：「傑瑞！感謝你介紹這套歐萊禮 Java 系列，讓我在短短的三個月內成為公司內首屈一指的 Java 專家，這實在是太神奇了！」

選舉時的 Pattern：

1. 質疑對手 A 錢或搞婚外情
2. 把家人通通拉上台痛哭一場以示選情告急
3. 開口唱「愛拼才會贏」

其它像是金光黨的手法，刮刮樂詐財的技倆 ... 等，也都具有一再重複出現的特性，所以都可算是 Pattern。

電影中的 Pattern
電影中也有大量的 Pattern，請看下面的例子。

提高追殺時緊張程度的 Pattern

1. 壞人追殺好人時，好人躲進車子，卻發現車子發不動，引擎嘎嘎作響，一面努力地繼續發動，一面念念有詞「Come on, Come one」。
2. 壞人追殺好人時，好人衝進電梯，死命地押著 close 按鈕，脫口而出「Come on, Come one」。

許多電影都會使用上述兩個 Pattern，雖然是老掉牙的 Pattern，但每次看到這裡，總是讓我緊張得心臟病差點發作，我不得不承認這兩個 Pattern 實在是挺有效的。

增加主角殺死壞人合理性的 Pattern

電影最後，壞人和好人大對決，最後好人勝利，但是好人如果直接把壞人宰了，那好人在觀眾心中的形象就會受損，所以好人先饒壞人一條生路，但是壞人卻壞到骨子裡了， 偷偷拿出一把槍瞄準好人，說時遲那時快，好人機警地察覺，為了自保於是將壞人一槍斃命。這個 Pattern 可以讓好人有人性，又讓壞人死有餘辜。

床戲的 Pattern

不管和劇情有沒有關係，編劇和導演總愛加上一段激情的床戲。這個 Pattern 相當困擾我和我的家人，因為每次看到這裡，我們保守的一家人往往覺得很尷尬，我們所反應出來的 Pattern 是：藉口倒茶水，上廁所，打電話 ... 而離座避風頭 ... 但眼睛仍不時偷瞄。

恐怖片的 Pattern

無須我舉例，電影驚聲尖叫（Scream）第一集就為我們剖析出恐怖片的一大堆 Pattern。

公式化
好萊塢的電影比較多 Pattern，而歐洲的電影比較少 Pattern。至於昆丁塔倫提諾（Quentin Tarantino）編導的電影，完全是不按排理出牌，很難找到 Pattern。正因為好萊塢的電影很容易就可以找出 Pattern，所以常常會有似曾相似的感覺。許多人批評好萊塢的電影很「公式化」。

基本上，Pattern 就是一種公式化的表現。那麼，究竟公式化是不是好事？

以藝術來說，公式化的結果會造成僵化，所以負面效果居多。電影號稱是「第八藝術」，也是一種藝術創作，所以最好不要出現太多 Pattern，否則肯定被影評人痛批「了無新意」。

以工程來說，公式化是好事。這些公式都是「千錘百鍊」的結果，運用這些公式可以確保工程具備一定的品質，並加快工程的進行。而軟體開發也是一項工程，也需要盡量運用公式。 （軟體另有需要藝術的一面，這不在本文的討論範圍）。

什麼是 Design Pattern
所以，Pattern 就是一種「千錘百鍊」的智慧結晶。有經驗的專家和沒經驗的新手，差別就在於：有經驗的專家知道如何在適當的時機，套用某些公式（Pattern）以解決特定 的問題，這是專家經年累月所培養出來的 Know-How（請參見「軟體產業的知識經濟」一文）。

一般來說，物件導向軟體開發的程序可以粗略分成 OOA（物件導向分析）、OOD（物件導向設計）、OOP（物件導向實作）。在 OOD（Object-Oriented Design）階段所採用的 Pattern 就稱為 Design Pattern。運用良好的 Design Pattern，可以使得系統架構更優良（也更快完成），對於後續的 OOP、測試、維護，都會有很大的 幫助。Design Pattern 會告訴你，什麼情況下用 Delegation 而不要用繼承、什麼情況下用 Interface 而不要用 Class... 諸如此類的知識。這些都是軟體界前輩的智慧結晶。

我要強調 Design Pattern 專指 Design 時期的 Pattern。但是 Coding 時的 Pattern（例如程式碼內縮）最好不要稱為 Pattern，以免混淆。Coding 時期的 Pattern 最好稱為 Coding Style（或 Code Style）。

Design Pattern 這個名詞也可沿用到許多地方。我認為孫子兵法就是一本軍事領域 Design Pattern 的書，它告訴你什麼時候該採什麼樣的軍事動作。至於怎麼去砍人，則是屬於 implementation 的部分，不屬於孫子兵法的範圍。

什麼是 Anti-Pattern
並非所有的 Pattern 都是好的，不好的 Pattern 稱為 Anti-Pattern。如果你的系統中出現了 Anti-Pattern，就表示你犯了別人「常犯的典型錯誤」。簡言之，Anti-Pattern 就是錯誤的示範，要盡量避免。

讓 Design Pattern 成為你的不時之需
許多人在設計階段才來喟嘆：「 Pattern 到用時方恨少。」其實你可以避免這樣的情況。現在市面上有許多本 Design Pattern 和 Anti-Pattern 的書。只要好好把這些書讀過，體會每個 Pattern 的真正涵義，你可以在短短的時間內，功力激增一甲子。即使讀過的 Design Pattern，如果比較少用，一陣子之後也可能會忘記。 所以最好能隔一陣子就把 Design Pattern 的書拿出來複習。


本文作者：蔡學鏞
張貼日期：3/09/01

另外連結

http://caterpillar.onlyfun.net/Gossip/DesignPattern/DesignPattern.htm

程式設計是思維具體化的一種方式，是思考如何解決問題的過程，設計模式是在解 決問題的過程中，一些良好思路的經驗集成，最早講設計模式，人們總會提到 Gof  的著作，它最早將經典的 23 種模式集合在一起說明，對後期學習程式設計，尤其是對從事物件導向程式設計的人們起了莫大的影響。後來設計模式一詞被廣泛的應用到各種經驗集成，甚至還有反模式 （AntiPattern），反模式教導您如何避開一些常犯且似是而非的程式設計思維。

這邊的話將整理一些設計模式學習心得，實作的部份是使用 Java 與 Python，在這邊所看到的 UML 圖都是使用 Jude 繪製的。

Gof 模式     以下的設計模式則是我個人從 Gof 學習中的個人體會與實作，並增加幾個導入或衍生的簡單模式。 Creational 模式 如何有效率的產 生、管理 與操作物件，一直都是值得討論的課題， Creational 模式即與物件的建立相關，在這個分類下的模式給出了一些指導原則及設計的方向。 Simple Factory 模式 Abstract Factory 模式 Factory Method 模式 Builder 模式 Prototype 模式 Singleton 模式 Registry of Singleton 模式 Structural 模式 如何設計物件之間 的靜態結構，如何完成物件之間的繼承、實 現與依賴關係，這關乎著系統設計出來是否健壯（robust）：像是易懂、易維護、易修改、耦合度低等等議題。Structural 模式正如其名，其分類下的模式給出了在不同場合下所適用的各種物件關係結構。 Default Adapter 模式 Adapter 模式 - Object Adapter Adapter 模式 - Class Adapter Bridge 模式 Composite 模式 Decorator 模式 Facade 模式 Flyweight 模式 Proxy 模式 Behavioral 模式 物件之間的合作行 為構成了程式最終的行為，物件之間若有設 計良好的行為互動，不僅使得程式執行時更有效率，更可以讓物件的職責更為清晰、整個程式的動態結構（像是物件調度）更有彈性。 Chain of Responsibility 模式 Command 模式 Iterator 模式 Strategy 模式 Template Method 模式 Observer 模式 Mediator 模式 State 模式 Memento 模式 Visitor 模式 Interpreter 模式 多執行緒模式     在很多應用中都會使用多執行緒，尤其是在Web應用中，多執行緒以 Gof 整理的模式為基礎，考量多執行緒環境中，如何組合這些基本模式來完成多執行緒安全要求。 Guarded Suspension 模式 Producer Consumer 模式 Thread-Per-Message 模式 Worker Thread 模式 Thread Pool 模式 Future 模式 Read-Write-Lock 模式 Two-phase Termination 模式 Thread-Specific Storage 模式 參考資料     以下是以Java實作設計模式的介紹網站，從下面的連結開始，當中您可以找到更多設計模式的資源。 Huston Design Pattern The Design Patterns Java Companion 板 橋里人的 Java 設計模式學習心得 Essential JavaScript & jQuery Design Patterns  UML 軟件工程組織

C 語言教學

http://nknucc.nknu.edu.tw/~jwu/c/cpg.htm

Linux Kernel

http://upload.wikimedia.org/wikipedia/commons/2/28/Linux_kernel_diagram.png
簡單版

http://www.makelinux.net/kernel_map/
完整版

FAT32

http://home.educities.edu.tw/wanker742126/list.html

硬碟知識