反思一次Exchange服務器運維故障

時間 2020-02-28

標籤反思一次 exchange 服務器故障简体版

原文原文鏈接

本文是對2018年8月9日公司Exchange郵件系統郵件流故障的故障發現、故障處理和故障修復的過程記錄和總結反思。幫助本身總結經驗和吸收教訓，同時也做爲一次反面教材讓其餘運維或管理員吸收教訓。
數據庫

故障發現服務器

昨天下午18點50左右結束團隊內培訓分享會後，收到同事的反饋，說他們幾我的都沒法收到外部郵件（Internet上的郵件），故障現象爲：Exchange服務器內網收發郵件正常，外網發送正常，但沒法收到外部郵件。網絡

由於公司的郵件系統是公司自建的Exchange Server 2010，所以須要運維本身去管理。通過多個外部郵箱的測試發現，的確沒法收到外部郵件，這些外部郵箱包括網易、阿里企業郵箱和微軟Outlook郵箱。
併發

由於郵件服務是企業核心服務之一，加之已經有同事反饋遇到問題，所以此故障應該是重要緊急故障，必須儘快排除以恢復服務。運維

注1：若是問題比較嚴重或者有緊急事件處理流程規定，應該按照流程彙報上級領導和發出通告。ide

注2：如下是我的見解和經驗總結，若有錯誤敬請指出。工具

故障處理學習

面臨故障最重要的就是儘快經過排除法進行故障排除以實現服務的最快恢復。所以首先要作的故障排除。因爲已是下班時間，事故雖然重大，但還還沒有形成重大影響。測試

由於在Windows特別是Exchange的運維上我的經驗比較欠缺，不能憑經驗一會兒發現問題，所以只能先根據以往經驗，結合Google等逐個排查。spa

通過初步測試，內部郵件收發正常，內部向外部發送郵件正常，但接收異常。因而開始如下排查。

在排查以前應該先須要搞清楚最近發生的變動，如軟件配置，致使變動的操做，特別是兩個及以上的管理員共同管理時。所以服務器由一人管理，且最近沒有進行過任何更改，是忽然出現的問題，所以直接開始排查：

檢查域名解析，排查mx記錄等是否存在問題。使用nslookup命令在多個外網服務器上測試MX記錄、以及相關的A記錄和CNAME記錄。
注1：Windows服務器可使用nslookup -q=mx xxx.com直接查詢，Linux命令須要交互式查詢，即先執行nslookup再set q=mx或set type=mx，再查詢
注2：在查詢mx記錄時，只須要查詢郵件服務器fqdn域名的上級域名便可。如mail.qq.com，則只須要查詢qq.com的mx記錄便可。
通過排查，排除域名解析問題。
檢查外部與內部的通訊問題，檢查防火牆攔截狀況和防火牆到服務器中間的網絡鏈路問題。使用telnet mail.xxx.com 25命令檢查25端口的打開狀況，通過測試排除防火牆問題。
注1：25端口是接收外部郵件的約定端口
注2：若是25端口正常且目標爲Exchange郵件服務器，應該提示相似「220 mail.xxx.com Microsoft ESMTP MAIL Service ready at Fri, 10 Aug 2018 10:43:58 +0800」字樣。
爲了確認不是防火牆或網絡設備bug問題，重啓防火牆或網絡設備。一般無軟關閉和重啓功能的防火牆須要斷電或切換電源狀態10s以上。通過檢查不是網絡設備問題。

以上3個步驟排除後，應該肯定問題是出在郵件服務器身上。開始郵件服務器自身的排查：

由於是郵件服務器內部收發正常，所以直接登陸郵件服務器，檢查郵件服務器的其餘可能影響因素
首先檢查服務器負載，包括CPU、內存、磁盤空間、IO和網絡等負載狀況。一般影響Exchange的主要是CPU和內存，其次磁盤空間和IO。通過檢查磁盤空間不足（已經低於5%，但尚有3GB可用空間，因爲經驗不足，沒有判斷出此問題可能形成的影響，加以內網郵件正常，所以沒有優先處理，最後發現是此緣由形成）。
其次應該檢查服務器系統日誌。關於先檢查日誌仍是先檢查負載狀況，只是習慣問題。系統日誌通常會給與管理員足夠的信息。雖然Windows的事件管理器並非特別好用，可是Exchange在日誌方面仍是比較良心，通常大小事件均記錄在內。
除了檢查系統日誌以外，Exchange通常提供了其餘診斷工具。好比「隊列查看器」，由於隊列查看器可用於解決郵件流問題，所以隊列查看器裏面也會有一些關於郵件沒法傳輸的問題的提示。
通過查看系統日誌和隊列查看器後，發現問題是因爲資源不足引發。系統有兩處明顯的提示：
1.隊列查看器提示上一個錯誤爲「452 4.3.1 Insufficient system resources」。通過Google查詢，這一般意味着要麼磁盤空間不足要麼內存空間不足。
2.事件查看器中來源自「MSExchangeTransport」報告稱：
（1）警告：資源壓力已從普通增至中。
（2）錯誤：Microsoft Exchange 傳輸服務拒絕郵件提交，由於可用磁盤空間已降至配置的閾值之下。

故障確認和修復

已經確認爲磁盤空間問題致使的觸發Exchange的「反壓」保護策略。經過釋放磁盤空間解決。解決後通告給上級領導和相關人員。

知識點

關於「反壓」。如下摘錄Microsoft文檔庫--瞭解反壓。

反壓是存在於 Microsoft Exchange Server 2010 集線器傳輸服務器和邊緣傳輸服務器上的 Microsoft Exchange 傳輸服務的一種系統資源監視功能。Exchange 傳輸能夠檢測重要資源（例如可用硬盤空間和內存）什麼時候具備壓力，並採起操做以嘗試阻止服務不可用性。

反壓能夠防止過多地使用系統資源，而且 Exchange 會嘗試傳遞現有郵件。當系統資源使用率恢復到正常級別後，Exchange 服務器就能夠逐漸恢復正常運行。

在 Exchange Server 2007 中，當集線器傳輸服務器或邊緣傳輸服務器具備資源壓力時，它會拒絕傳入鏈接。在 Exchange 2010 中，會接受傳入鏈接，可是會以更慢的速度接受或拒絕經過這些鏈接傳入的郵件。SMTP 主機嘗試鏈接處處於反壓下的集線器傳輸服務器或邊緣傳輸服務器時，鏈接會成功，可是該主機什麼時候發出 MAIL FROM 命令來提交郵件，則取決於具備壓力的資源，Exchange 可能會延遲確認 MAIL FROM 命令或拒絕該命令。

如下摘錄自事件查看器：

Microsoft Exchange 傳輸服務拒絕郵件提交，由於可用磁盤空間已降至配置的閾值之下。

如下資源處於壓力之下: 隊列數據庫日誌記錄路徑(「C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\」) = 95% [中] [正常=93% 中=95% 高=97%]

反壓力致使禁用瞭如下組件: 從集線器傳輸服務器提交入站郵件

從 Internet 提交入站郵件

從分揀目錄提交郵件

從重播目錄提交郵件

從郵箱服務器提交郵件

向遠程域傳遞郵件

正在從隊列數據庫加載電子郵件(若是可用)

如下資源處於正常狀態: 隊列數據庫路徑(「C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que」) = 95% [普通] [正常=95% 中=97% 高=99%]

版本存儲桶 = 0 [普通] [正常=80 中=120 高=200]

專用字節 = 0% [普通] [正常=71% 中=73% 高=75%]

物理內存負載 = 11% [開始郵件凍結的限制爲 94%。]

批處理點 = 0 [普通] [正常=1000 中級=2000 高級=4000]

提交隊列 = 0 [普通] [通常=1000 中=2000 高=4000]

注：其實Linux中也有相似的保護機制，如oom，磁盤保留5%，遇到此類知識應該觸類旁通，舉一反三。

故障反思和總結

遇到故障或問題應該保持頭腦冷靜，切莫慌亂，不能自身亂了陣腳。不少運維或者管理員在遇到問題時首先想到是如何解決，而嘗試各類辦法解決無果後爲了節約時間就想到回滾，這是不正確的。做爲一個合格的運維應該弄清事情的前因後果和問題的根本緣由。在排查問題時首先想到經過日誌去排查問題。在排查時應當儘量全面的排查，不要漏掉任何一個可能致使問題的細節。
部署必須聽從標準，必須規範。從此次事故來看，此Exchange服務器中含有三個數據庫，其中一個數據庫存放在C盤沒有在其餘盤。隨着時間的增加，這個數據庫佔用了大量的磁盤空間，致使磁盤空間不足，從而觸發了「反壓」機制。從標準和規範的作法來看，應該將此數據庫從C盤移動到其餘容量大的磁盤。而且在部署最開始時計算好容量。
重視報警。此服務器是配置了Zabbix監控報警的，並且Zabbix已經監測到故障併發送報警，因爲沒有及時的處理才致使本次故障的發生。
就算是接盤也要痛改前非。由於此郵件服務器是以前運維同事部署的，所以裏面有些問題一直擱置而遲遲沒有解決（也有技術上的緣由），從長遠角度上看，即便須要付出必定的代價也需亡羊補牢。
保持學習。雖然有些時候，某些東西偏離了本身的發展方向，但像郵件服務器這樣的公司的核心IT系統應該去深刻的學習。只有瞭解和懂得才能遇到問題時更快的解決問題。
每次故障後總結經驗和吸收教訓。將知識和經驗記錄下來，沉澱下來。好比這次總結後，在遇到此故障可能一會兒就想到了磁盤空間不足會致使Exchange觸發反壓，從而致使沒法收到外部郵件。