高手教你輕松排除網絡故障

wellhope_365

高手教你輕松排除網絡故障:你的網絡不可能不發生故障。因此, 從現實的角度來講，你的設計應當考慮到故障的問題。然而, 網絡設計總是要面臨商業的利益考慮各種平衡：效率與成本、性能與可維護性等等。雖然說網絡設計要盡量減少故障率，但是這種減少很可能與其它的限制相矛盾。對于這些問題沒有簡單的解決方案。然而，這里有幾條建議對許多類型的網絡都適用。     在組建網絡或者重新組合網絡時，作為網絡規劃者的你就應該采用一些網絡設計原理，有了這些原理，你才可以使你的網絡少出問題，盡可能減少故障所能帶來的影響，或者簡化故障分析的過程。
    在設計網絡時考慮故障問題需要對系統如何產生故障有一個全面的了解。因此，在開始討論設計原理之前，有必要首先回顧一下系統故障類型。這里將以幾種不同的故障類型開始。盡管這種概括可能有些簡單化，但是已經足夠用了。
    簡單故障：
    也許最簡單的故障類型就是單一位置的故障或者一個簡單故障。這種故障，出問題的部分僅僅是你的網絡上的一個組件不工作了。理論上講，哪個設備出了問題是很明顯的，但是通常這并不是問題的關鍵。在許多種情況下，許多個設備同時出現了故障。比如說，如果網絡的唯一一臺DNS服務器出現了電纜連接故障，服務器就會無法訪問，DNS也無法解析，其它服務中的電子郵件也不能運行。實際上，故障只有一個，就是連接器。一旦這個位置進行了修復，所有的問題都立刻消失了。
    互相無關聯的多個故障：有時候你可能會面臨同時出現或者差不多同時出現的多個故障。通常你會有一種多重故障的錯覺，就像上面的例子中所提到的一樣，是電纜出了問題。但是有時候確實是不止一個設備發生了故障。在互相無關聯的故障當中，出現故障的時間幾乎完全是巧合，故障之間并無聯系。不幸的是，無關聯故障可能很難解決，原因有三：第一，你必須意識到確實發生了多重故障；第二，區分幾種故障現象可能會比較困難。最后，總想去尋找根本不存在的關聯是人的天性。這種天性往往會誤導你。
    連續故障：
    一種故障引發的其它故障被稱為連續故障。在這種故障中，每個故障都需要單獨處理。比如說，突然斷電會破壞接口。為了使設備重新工作，你必須修復或更換電源和接口（建議首先更換電源）。區分真正的連續故障和單一故障影響其他設備這兩種情況會比較困難。但是盡管這種區別對于你的用戶來說并無差別，可是在故障診斷時卻很重要。
    系統故障：
    也許最致命的故障就是系統故障了。這是一個經常被濫用和誤用的術語。系統故障源于系統組件之間意外、不明顯的互相影響。這種互相影響可能是獨立故障對于其它設備的作用，或者僅僅來自設備的不兼容。系統故障的發生條件是不熟悉的、未經計劃的，或者沒被發現的或者不能馬上理解的意外的相互影響。多個簡單故障如果沒有相互影響就不算是系統故障。連續故障也不是，因為相互影響可以很容易理解。也許解釋系統故障的最好辦法是舉一個例子。案例分析：
    幾年前，李在擴展自己創建的一個校園網時遇到了一個系統故障。理論上說，這個校園網包括了四個子網：一個是大學管理系統，一個是員工網，一個學生實驗室網絡，還有一個校園互聯網連接的接入網絡，以及撥入服務等等。開始，這些子網都連接到一個用作email服務器、DNS服務器和路由器的主機。每個子網都是由很多通過hub連接的主機構成的。
    一開始這種結構已經足夠了，但是沒多久之后就需要擴展原來的網絡硬件， 這個校園網下一步的發展目標是安裝一個單獨的路由器，并以交換機取代為數眾多的hub。決定關掉電子郵件服務器的路由功能，但是仍然使之保持對四個子網的連接。據稱這樣可以提高效率，因為本地電子郵件可以無須通過路由器，而且可以提供冗余，因為電子郵件系統在路由器關閉時仍然可以正常工作。因為不同網絡的許多用戶互相距離很近，所以選擇了支持虛擬局域網（VLAN）的交換機。
    為了了解這種結構是如何導致系統故障的，有必要首先了解采用的主機和交換機。電子郵件/DNS服務器采用了一個四倍以太網卡適配器，每個網絡接口，或者端口采用的是同樣的以太網或者MAC地址而不是每個端口采用不同的MAC地址。盡管這不是常規的做法，但是銷售商的文件指出IEEE把每個端口使用相同的地址（工作站地址）還是不同的地址（端口地址）這個問題的選擇權留給了開發商。（根據原來的配置，由于每個MAC地址都在不同的網絡上，所以一切運行正常。）
    交換機的一個特征是它們從通過它們的數據中得到MAC地址，然后利用這些信息來控制數據的處理。當一個數據包到達一個端口，它的MAC來源地址就進入了這個端口的地址列表。交換機還搜索每個端口的地址列表來查詢目的地址。 如果發現了相對應的地址，它就會將數據包發送到具有包含MAC地址的地址列表的端口，而且，它不會再把數據包發送到其它的端口了。（如果目標地址不在交換機的任何地址列表當中，這時交換機就會像一個hub一樣從每個端口把數據包發送出去。）由于設備可能會從一個端口移到另一個端口，一般情況下，當交換機把一個MAC地址添加到一個端口的地址列表時，它會刪除其它列表中的這個地址。在具有“傳統”交換機的情況當中，采用了工作站地址方法的郵件服務器不會出任何問題。子網的交換機甚至還不知道其它網絡中到底發生了什么。
    現在考慮一下在這個方案中采用VLAN的含義。VLAN設備的思想是一個物理設備可以被分成幾個虛擬設備。如果你有三位教員，兩位員工以及四位學生同時在同一個布線室，使用傳統的交換機，你需要三個不同的交換機，因為有三種不同類型的用戶，每種類型的用戶需要分成不同的子網。而且，為了把每個交換機都連接到骨干網，我們需要三種不同的電纜布線連接。有了具有VLAN功能的交換機，交換機可以分為三個邏輯交換機。每個邏輯交換機用于處理單獨的網絡數據。因此，我們只需要買一臺交換機。而且，如果我們在骨干網上采用了VLAN技術，我們在骨干網和布線室之間只需要一根電纜（主干線）連接。每一端的交換機都可以都可以分揀數據并把數據發送到相應的邏輯交換機。顯然，VLAN在許多情況下可以顯著節約投入。
    這就引發了一個有趣的問題：在支持VLAN的交換機上是如何管理地址列表的呢？具體地說，當在某個地址列表上添加了一個設備，那應該是在物理交換機上清除所有端口上的地址列表呢，還是僅僅清除同一個邏輯交換機端口上的呢？由于設備可能會從一個網絡移動到另外一個網絡，你可能會推斷地址應該從一個物理交換機上的所有地址列表中清除掉。許多VLAN交換機也正是這樣做的。但是這個決定在用于電子郵件服務器的工作站地址方式時出現了問題。
    問題是這樣的：電子郵件服務器需要同時入住所有的四個網絡。當來自某個服務器的數據包到達交換機的某個端口時，服務器到其他端口的連接就斷掉了。網絡仍然需要向相應的邏輯交換機發送數據包，但是邏輯交換機這時需要將數據包發送到每個端口，因為在任何一個地址列表中都找不到地址。除非有人在與服務器對話，交換機才會快速穩定下來。但是在同時對話中，問題出現了。
    由于服務器之間尋址方案之間的不兼容和VLAN的使用毫無疑問是問題的根源所在，所以原因很簡單。問題出現的頻率很高，所以整個網絡的性能表現非常差，經常發生丟包和掉線的現象。荒謬的是，交換機地址列表卻經常溢出。這似乎是分揀來自干線數據的問題，或者別的什么問題。由于經常發生這樣的問題，在事實發生之后很長時間才可以把片面的解釋歸結到一起。如果這是生產系統的問題，那就不可能回過頭來仔細研究這個問題。一旦掌握了問題發生的原理，就可以做些改變來改正錯誤。Ifconfig被用來把不同的MAC地址分配給服務器上的每個端口。 系統特性和系統故障
    正如前面所提到的，系統故障的特點是兩個或多個部分以一種不明顯的或意外的方式進行的不受歡迎的相互影響。我們可以看出，上面的例子剛好符合系統故障的定義。網絡的每個部分單獨或者在某些環境下面運行都很正常。是不同部分的相互影響導致了故障的產生。服務器的多重連接產生了多重相互影響，而由于這些相互影響不明顯，所以診斷和排除這類故障非常困難。
    那么系統故障在那些情況下容易發生呢？在Charles Perrow的經典著作Normal Accidents一書中，他分析了從核電站到空中交通管制系統的許多不同的系統。簡單地說，他識別出了導致系統故障的幾種因素。首先，系統越簡單，系統就越不容易發生故障。復雜的系統中有更多的容易出錯的東西，更多的相互影響的可能，以及由于在某個部分確實發生了故障的時候有更多的東西需要弄清楚，因此就有更多的出現不明顯或者隱藏的相互影響的可能。復雜系統的信息只能間接地收集到或者推斷出來。
    其次，線性系統與具有很多混合連接的系統相比，出現系統故障的幾率更低。具有許多交叉連接的系統有許多組件間交互作用的方式。在具體的交叉連接當中，那些隱性的交叉連接最可能導致系統故障難以診斷。
    與線性密切相關的是系統各部分之間的結合度。結合度比較松散，線性系統出錯概率就小，結合度緊密，相互影響就發生頻繁而且不容易消除。
    如果你停下來去想，這些特性都是在意料之中的。但是除非當你停下來并去考慮他們，否則非常容易忽視掉。粗略地說，我把大多數網絡歸為復雜但相對線性系統一類。（確切地說大多數網絡都是樹狀結構，但是這里指的是設備之間簡單明顯的線性路徑。）大多數硬件往往是相當緊密地連接在一起的，但是使用硬件的協議可能會提供松散連接。但是如果你不這樣認為，也沒有關系。把系統歸為線性還是非線性，緊密連接還是松散連接，簡單還是復雜主要還是個人判斷。這些都是真正的相關歸類。更重要的是能夠從這個角度比較不同的網絡設計而不是給一種設計歸為那一類。
    故障診斷
    很不幸的是，當你開始故障診斷時，故障類型往往十分模糊。盡管說把所有可能都考慮到會對問題解決有所幫助，但是通常的情況是你沒辦法把故障歸結為哪一類，直到你解決了故障為止。
    人們在深入了解情況之前總是在一開始的時候就認為所有的故障都是簡單故障。首先從故障的表面現象開始，然后再深入下去。在前一個DNS服務器連接故障中，你可能會從電子郵件軟件所報告的DNS故障信息開始，然后開始查找DNS信息。這樣你就會發現DNS服務無法實現，隨之你就會發現無法連通DNS服務器。這樣你就離故障的根源越來越近了。在機械系統中，順藤摸瓜通常是一個很重要的方法。在網絡中，邏輯上的順藤摸瓜取代了它的位置。
    了解不同的故障類型是有幫助的。在診斷一個簡單故障時，通常的做法是采用分段解決的方法。在剛剛的例子中，主動將你的注意力轉移而不是集中到癥狀本身可以少走很多彎路。花費時間在檢查電子郵件配置文件上或查詢DNS會白白浪費大量的時間。在兩個或多個設備幾乎同時出現故障時，故障診斷會更加困難，因為解決了一個問題并不能使系統恢復正常。因此，能夠想到可能會出現多個故障并能想象出多個故障的綜合癥狀對解決問題是很重要的。對于多個故障，當你向解決其中一個問題邁進時，你可能卻在離解決另一個問題更遠。通常是你排除了一個故障，系統的故障現象就變了。這也是發現多個故障的一個基網絡設計
    可能導致故障的網絡特性時會大有幫助。但是這個方法并不是萬能的。在網絡設計中，你的目標自然會首先包括避免故障，并減小故障所產生的影響，簡化故障的排除。不幸的是，這兩個目標是矛盾的。例如，考慮了故障影響的設計必然會使遠程故障信息收集更為困難。
    簡單故障：
    一般的建議適用于避免簡單故障,采用可靠的設備，經常維護和檢測設備,每天更新系統日志，通過使用幾個相同的協議和選擇幾個相同的設備廠商來盡可能簡化所用的東西。不幸的是，僅僅使用幾個協議限制了你的網絡功能；而標準化配置設備意味著你可能會在這些設備上花費更多的錢。并不是所有的情況下采用同一個廠商的產品都是最經濟的方案。而特別的需要會浪費許多錢去購買不必要的設備。這在這些里些建議中是毫無疑問的。
    多重故障和連續故障：
    當然, 盡量減少簡單故障是防止多重故障的基礎，不管是獨立故障，連續故障還是系統故障。下一步是分開以減少網絡組件的互相影響。分開可以通過分開數據連接層或通過采用子網分開網絡級別來實現。盡管有時候被忽視，出于安全的考慮，防火墻不應該受到限制。它們可以作為一種一般性工具來控制子網之間的數據交換。但是由于分開限制了交互，數據收集就變的更加困難了。 如果你確實劃分了網絡，（而且你當然應該考慮劃分到最小網絡單位），內建檢查點是很重要的。
    最簡單的就是每個區內的一些你可以遠程登錄并安裝了數據收集工具的計算機。我Network Troubleshooting Tools一書中介紹了許多有用的工具。你還可以通過配置網絡設備如路由器來收集這方面的信息。如果預算允許，你還可以考據增加RMON類似的設備。當然，你應該會想到，這么做會增加網絡的復雜性。比如，你可能需要重新配置路由器或者防火墻使SNMP數據能夠通過，至少能到達相應的主機。本線索，尤其是在系統故障中。系統故障：
    由于系統故障是最難診斷的故障（而且，其后果也可能是慘重的損失），你可能需要在構建你的網絡時要特別注意避免或減少這類故障。上面所說的都會有幫助。下一步就是考慮哪些系統特性可能會導致系統故障。
    首先, 盡量使你的網絡成為線性布局。樹狀結構的網絡相對來說比較好。總的來說，除了偶爾有冗余連接之外大多數網絡都是線性的（或者說是樹狀的）。具有諷刺意味的是，添加冗余路徑可能反而會有相反的效果。因為潛在的問題，這是網絡需要仔細測試的一個方面。當你添加了額外的路徑，你需要知道有產生問題的潛在可能。盡量選擇能完成任務的最簡單的結構。
    大多數網絡中單個設備都是相對緊密聯合的，盡管使用他們的許多協議和服務可能會連接松散，緩沖和冗余需要在設計時明確考慮到。這可以由某些協議辦到，但不是所有的協議都可以。可能的話，根據情況進行選擇。
    復雜性和效率通常都是和系統緊密相關的。具有諷刺意味的是，最簡單的解決方案反而很少有效率高的。因此，有時候需要某種程度的復雜性來實現所要求的功能。復雜性在許多情況下也提高了可靠性。總的來說，如果能滿足要求，還是簡單些為好，但是前提是它能勝任工作。最后，正如前面所提到的，對于系統故障來說，關鍵因素是相互影響是隱性的而且不可預知。為了避免出現這種問題，你需要盡可能多地知道你的網絡發生了什么事情。不幸的是，這同網絡設計的基本原理直接沖突：透明度。從用戶的角度來看，網絡如何工作的詳細內容跟他們無關。因此，網絡的設計向用戶隱藏了這些細節。如果一個網絡在TCP過程中發生了丟包現象，協議會安排在用戶不知情的情況下重新發送。也許網絡速度會顯得很慢，但是這就是顧客所唯一會注意到的事情。從故障分析者的角度來說，隱藏的信息才是你最終需要的東西。解決問題需要你對網絡運行的原理有透徹的了解和一系列優秀的收集信息的工具。
    結論
    工程似乎總是要涉及到均衡：線性對冗余性，簡單性對效率，透明度對信息收集。這需要在組建網絡時仔細平衡。沒有萬能的解決方案。可靠性的改進或者易診斷性將會始終是需要花費力氣去做的事。但是診斷任何問題的第一步都應該是了解究竟發生了什么事。比較一下你的備選方案的復雜程度并盡量推斷出可能在什么地方發生問題

龍城飛將

講的挺深奧的，也挺有用的，網絡電腦我們都離不開，還的好好學習