今天來談談不一樣的領域 – 虛擬化的除錯(Troubleshooting)和規劃評估，眼下不可能說只懂網路，其他系統類技術都放生，這樣你一定會被老闆視為不及格。現在一台沒有辦法連網的伺服器已經不存在了，因為沒辦法連上網路的伺服器，代表它無法提供任何服務，沒有產出價值。所以你也不可能只懂系統，網路一概不管…。
虛擬化過後，實虛對應非常重要，網路跟系統跟是無法分家的。不管是ESXi(VMware家族)、XenServer(Citrix家族)、Hyper-V(Microsoft家族)，都沒有辦法說架設一台沒有網路卡的虛擬化平台，所以各家的虛擬化底層都被要求要有支援的網卡，而且最好不只一張。
昨天晚上，我的好友問我，
”我覺得我公司系統上的載台Guest OS回應速度慢，我懷疑有可能是NAT或是網路設備端點有問題，但是內連外很快、外連內很慢，這有可能是甚麼問題？”
首先，這問題很複雜…，而且答案可能是多重解。
第一、 釐清速度慢的原因
User、老闆都沒有你懂，他們很可能只能提供給你情況，而不知道細節…。
User最喜歡說，
”我覺得我網路好慢，你能不能想辦法讓他快點…”
”我時常連不上我要的服務…”
慢可能有很多種原因，從User Client到Server端，可以一步一步來看：
1. 是不是User電腦本身就慢？這點很簡單可以驗證，如果他隔壁鄰居用感覺沒有特別慢或是還算快速，就表示這問題癥結點出在Client PC。代表你有可能要幫他掃毒、清除電腦上垃圾、清出記憶體和CPU資源…。
2. 端點到端點，慢在哪一段？一台組織內設備要連網存取外部網路或內部伺服器，一定穿越不只一台網路設備，如果同一段網路的8-9成使用者都反應網路慢，可以推測可能這一段網路到外部或到伺服器的Farm有問題。可以先嘗試Pathping, Tracert這兩個指令去檢測各端點的Response
Time是否符合預期，如果某端點有嚴重延遲，或是封包遺失率很高，不排除就是該端點造成的問題，後續你就可以檢查那台設備的狀態，例如：燈號、Port、封包交換情況。
3. 連不上，有沒有可能是Session數不夠？這可以在伺服器端作檢視。尤其某一些File System，他連線還沒Timeout前，Session(工作階段)都還會儲存在Server上，你可以寫BAT去定時執行踢人這動作，或者是修改機碼參數等，讓伺服器把Timeout時間縮短，我曾經幫國科會的Share File伺服器做過類似的設定，以避免有大量User跟你反應我連不上檔案伺服器這種鳥事。當然，如果是網路設備的Seesion數不夠，你就有可能要更換或是考慮新增網路設備，但是老闆通常會要求你拿出數據來證實這件事，每一家網路設備看Session數的方式不同，最好先看一下Tool跟指令怎麼下，撈出點數據好跟老闆要錢。
4. 有沒有可能是頻寬不夠？我會建議各位監測主要端口的網路流量，不管你要用軟體來做，還是要用程式固定去跑指令幫你撈報表，這些都可以。不過網路流量監測在重要伺服器跟重點網路設備上很重要，國科會用來監測網路流量的軟體是Whatsup。頻寬不夠，優先考慮使用Teaming來解決(檢查網路跟伺服器是否支援IEEE 802.3ad)，把實體線路頻寬綁一綁讓頻寬變高；如果不支援此項作法，請考慮購入一台有此功能的網路設備或Server。
5. 有沒有可能是虛擬化後的伺服器不夠快？這也是有可能的，虛擬化後，我會建議各位保持定時監看虛擬化後的CPU跟記憶體使用量，如果伺服器顛峰期間的使用量超過七成以上，你就要考慮幫虛擬機配給更多的vCPU或RAM空間。
6. 有沒有可能是Database或Storage的問題？這個問題，很多不是SI界的人會不知道。資料庫不建議做虛擬化，你的SQL Server可以使用虛擬機，但是你的儲存空間一定得是實體機。為什麼？因為虛擬機沒有辦法讓RAID
Card優先處理Database的讀取跟寫入，IOPS(Input/Output Per Second)會被一堆亂七八糟不重要的工作瓜分掉。還有一個方法就是把整櫃的HD換成SSD；或者是額外多買幾顆SSD來當HD Cache，這方法也是可以的，但是如果公司是處理Big Data的，恐怕就不適合。國科會沒有任何一台DB是虛擬機，連測試機DB都是汰換下來的Server或PC來做。
7. 監控DB。我也曾經遇到DB容量已經額滿的問題(硬碟空間剩下5-10%就要處理了，剩下2%就等著服務停止)，所以即時監控DB容量是絕對必要的事情，別讓User反應資料表無法送出讓DBA跳腳，這工作是必要的一環。國科會還有同步監測DB的Deadlock，如果DB產生Deadlock，請儘速通知該DB的DBA來處理。關於這點，由於本人會寫Code，如果你懂SQL，應該要據以力爭別讓Programmer下一些大量運算的SQL語法，搞死DBA同時弄死你的DB，什麼加減乘除四則運算都讓DB算…，你要跟PM和Programmer溝通，運算這件事情應該回到程式內去解決，必要時巴結一下社交手段也是很重要的…。順便提一下，像是中鋼這種DB2規模大小的公司，甚至連Select *這樣開頭的SQL語法都無法被接受，每一筆資料有上百欄位，你下Select *抱歉！資料庫很可能完全不會鳥你。
8. 釐清是哪一種服務慢，如果是所有服務都慢，有可能是整個虛擬機或是實體的問題，但如果只有特定服務慢，你就必須檢查該服務是不是很重視即時回應(Real-time Service)，例如網路電話，這種僅能支持低延遲的服務。如果是這類型的服務，你必須要流量穿越網路設備時給予較高的Priority，甚至是作QoS來保障服務的頻寬跟品質。
第二、檢查你的網路工作排程
不要讓那些會使用到網路顛峰流量的工作在一般上班時間被執行，尤其是網路備份或資料庫搬移之類的工作。還有，同時也要阻止你的User做這些事情，不要讓他們有機會在上班時間傳輸大量的多媒體資料或者是透過網路交換HD
1080P的片子、使用BT下載等，不然網路不慢才有問題。
第三、從架構著手嘗試改善網路速度，降低網路hop數
這會是一個相對浩大的工程，如果你知道瓶頸頻寬卡在某條主幹上，那這個會是你最後的解答。網路線換成光纖，確保光纖通道上的設備有支援光纖連接跟1Gbps的網路連接埠，讓端點到端點的實體速度變快，必要時搭配LCAP(IEEE
802.3ad)來做。國科會就曾經將主幹頻寬擴增一倍，只是這個工程施工必須要公告並且挑離峰時間來做，服務會有中斷。
第四、停止不必要的監控
上述講到很多監控很重要，但是要細分還是排得出重要性，測試機可以不考慮監控，Production或重要的應用服務一定要監控，例如：AD服務跟DNS服務是否存活、DB容量、重要端點網路流量。不管你監控了些甚麼，越接近即時監控的服務就越吃網路的頻寬，監控越多項目就代表你網路效能會有很大一部分被監控給吃掉，而這些監控是沒有產出的；”他們正常是應該，它們不正常是活該…”，老闆認知通常是這樣，所以請拿捏好分寸。同時配合監控的項目還有警告或警報系統，你可以擬定一些規則出來，例如：某些伺服器或服務中止發出手機簡訊或Email、DB容量低於10%通知DBA和MIS…諸如此類工作。
第五、任何的採購或設計優先考慮HA(High Availability)
在導入任何軟硬體之前，先想想沒有他會不會怎樣？很多MIS在購入時，只考慮了”有了他超方便，我很爽”就買進來了，不會考慮如果”沒有他，會不會想要跳江？”
架構跟規劃關係著公司存亡的，更要好好考慮，服務有沒有需要Cluster(叢集)、有沒有Failover(容錯移轉)的機制、有沒有負載平衡(Load Balance)的機制，如果上述都沒有，最糟糕的情況下 Service Recovery要多久時間？這些都要先計算，如果這服務無關存亡也就算了，關係生死存亡的我建議你最好買雙保險甚至是三保險(例如：DNS服務)。DNS有多重要？國科會曾經因為DNS查詢錯誤，導致停擺某些網頁不只三天時間，如果你公司網頁也能接受停擺三天…；就像是馬雲能不能接受淘寶停止服務一小時？先問看看公司接受度，再問看看自己管理上有沒有問題。
不要盲從追求最新的技術，很多東西一出市場，別說HA了，連Reliability(可靠度)都備受質疑，這些東西在評估階段就要否決，不要高層心血來潮，你就捨命陪君子…，最好寫一篇報告告訴他，你為何”現階段”拒絕這樣的東西導入公司。
