News
您的位置：
今年筆（bǐ）者支撐（chēng）的某項目一個部署HBASE的大規模集群中發生了連續的宕機事件，對業務造成嚴重影響。每次宕機後，啟動消耗時間都很長（zhǎng），導致業務出現中斷。其最關鍵的問題是，連續宕機且原因不明，所以大概率存在再次宕機的風險，在根（gēn）因沒有定位出來（lái）的情況下，這個故障就是達（dá）摩克利（lì）斯之劍（jiàn）依然懸在（zài）半空，誰也不知道什麽時候會落下來（lái）。下麵（miàn）的篇幅就依此故障排查分析過程為主線展開。一、故障線索，機（jī）會出現該HBASE集群發生（shēng）的嚴重宕機（jī）事件，具體表現為管理節點HMaster異常退出，並且超過（guò）一（yī）半的RegionServer也出現宕機退出，導致業務生產中斷。運維人員（yuán）根據（jù）常規步驟進行啟動集群操作，之（zhī）後進行故障分析定位（wèi），由於日誌級別設（shè）置為DEBUG級別，日誌（zhì）刷新速（sù）度較快，重啟後沒有及時進行備份轉存，故障的時（shí）間點的日誌沒有辦法獲取，這給（gěi）查找故障原因造成了很大（dà）的麻煩。就在大家麵對缺少關鍵日誌，不知道該（gāi）如何進行故障分析複盤的（de）時候，在（zài）不到24小時（shí）的時間裏麵，集群出現了又一次宕機！現象是（shì）和第一（yī）次是一樣的，也是HMaster異常退出，期間也有大（dà）量（liàng）的RegionServer出現宕機。雖然說連續的（de）故障帶來（lái）客戶的嚴重不滿，但是也給了我們揭開故障根因麵紗的大好機會。二、問題排查，迷霧重重有了前期的教（jiāo）訓，這一次次故障產生後（hòu），立即在第一時間將（jiāng）HBASE的相（xiàng）關日誌都（dōu）轉儲（chǔ）保（bǎo）存（cún）好，然後就馬上著手進行分析和定位。這次故障表象實在有些特殊，HBASE的日誌反應的是Zookeeper連接異常：這個時候所有的思路焦點（diǎn）都聚集到Zookeeper的這個（gè）異常點上麵，為什麽會出現Session expired呢？Zookeeper是不是出現（xiàn）了（le）什麽異常的情況?之前集（jí）群也出現過HBASE的故障，因為Zookeeper連接超時導致，當時進行（háng）過以下舉措解決:
1.Hbase連（lián）接Zookeeper的會話超時調大(120S)。重啟ZK與Hbase；ipa 升級完成（chéng）後再操作（zuò）；
2.ZK連接數監（jiān）控，當前最大連接數600，超（chāo）過80%告警；臨時調整最大連接數—已經調整；
3. JVM 參數（shù）優化。
所以比較肯（kěn）定，故障應該還是出在Zookeeper上（shàng），所以第一時間分析ZK的日誌。但是ZK在整個故障過程中，始（shǐ）終沒有出現異常及宕（dàng）機行為，這個就給（gěi）問題定位帶來很大的不確定性了，因（yīn）為Zookeeper正常，即使是HBASE的（de）日誌顯示連接ZK異（yì）常，但這個時（shí）候依然沒有辦法定位到具體的（de）原因是由哪個參數哪個配置導致的，也（yě）就是說真正有說服力的原因是沒有定位到，這樣肯定是（shì）沒有辦法結案（àn），而（ér）且（qiě）係統隨時可能再次宕機，危機仍在。隻（zhī）能再次分（fèn）析Zookeeper的日誌，查找可能出（chū）現異（yì）常的原因。通過（guò）ZK的日誌，發現到（dào）一個情況，某幾台（tái）主機連接數特別多，一天下來都有上百萬次（cì）連接了，這個根據經驗來看是不正常的，是（shì）不是因為訪問量過大導致異常呢？迅速地，進行了（le）對ZK的各項指標進行全麵的監控，查找可能的連接異常。排（pái）查異常連（lián）接數據的主機是哪些程序發出（chū）的在所內模（mó）擬對（duì）ZK進行高（gāo）負載的連接，測試穩定性（xìng）然而結果並不順利，主機（jī）沒有部署特別的程序，僅（jǐn）是HADOOP集群的計算節點，內測也進行（háng）過百萬次級別的高負載連接壓測，ZK沒（méi）有出現異常（cháng）。三、拔（bá）雲見日，真相大白在經過一（yī）天的艱苦研究後，終於看到了曙光！通過分析（xī）日誌，發現連接Zookeeper的sessionid是（shì）有異常的。HMaster和Zookeeper是通過session維持連（lián）接的，這裏日誌顯示了sessionId 是：0xff8201f4b7b63a73檢測所有的ZK服（fú）務器的日誌，又發現了一（yī）段信息：這（zhè）個sessionid，不是HMaster的主機，是10.26.9.35 發出的，也就是說sessionid出現了衝突的情況。而由（yóu）於sessionid出現了衝突，並且（qiě）修改了原session的元（yuán）數據信息，導致Master連接ZK的長連接出現了過期異常，無法正常續約，HMaster退（tuì）出。那接下來（lái）的事情就明了：查明（míng）白為什麽ZK的sessionid會（huì）出現衝突首先檢測ZK產生sessionid的源代碼：這裏肯定看到是通過時間和ZK的實例ID作為基準進行生成的，現在的問題就是同樣的ID會參數相同（tóng）的開始ID段。通過對這段代碼進行測試，就發現了問題，無論送的是什麽id過來，結果都是一樣的，這樣不同的ZK實例，必定會（huì）產生相同的sessionid，也就是說是一個BUG來了（le）！仔細分析了這段代碼，發現的（de）是帶符（fú）號右（yòu）移，導致溢出了，然後馬上檢查了後續的版本，發現並進行了修複：代碼確實（shí）很少，就是 >>8 變成了（le） >>>8符號移位日常使用比較（jiào）少，確（què）實容易出錯：Java提供了兩種右移運算符（fú）：“>>” 和">>>"。其中，“>>”被稱為有（yǒu）符號右移運算符，“>>>”被稱為無符號右移運算符，它們的功能是將參與運算的對象對應的二進製（zhì）數右移指定的位數。二者的不同點（diǎn）在於“>>”在執行右移操（cāo）作（zuò）時，若參與運算的數字為正數，則在高位補0；若為負數，則在高位補1。而（ér）“>>>”則不同，無論參與運算（suàn）的數（shù）字為正數或（huò）為負數，在執運算時，都會在高位補0。上述的問題在於，左移24位，再右移8位後，當前時間出現了溢出，導（dǎo）致變成負數，真相（xiàng）大白。ZK的更新補丁說明：ZOOKEEPER-1622 session ids will be negative in the year 2022確實（shí）到了2022年後，由於sessionid出現負數，導致所有的ZK實例都會產生相同的sessionid初始值，所以才出現衝突。四、故障（zhàng）解決由於是ZOOKEEPER的BUG導致，所以後續還是（shì）必然還是（shì）會有可能再次出現異常，所以根本原因必須要對ZK打補丁，才能徹（chè）底解決。在沒有進（jìn）行充分驗證的情況下，隻（zhī）能通過避免程序到ZK的頻（pín）繁連接，要求對應用程序進行整改，才能（néng）降低BUG被觸發的風險，並且再更新之前每天進行係統及（jí）業務巡檢。經過一個業務周期（qī）運行觀察，係統穩定（dìng）運（yùn）行。五、經（jīng）驗總結這次的故障定位是一波三折，付（fù）出了很大的（de）努力才最終完成問題的定位。由於是（shì）組件的BUG引起，並且（qiě）在2022年才會觸發，這個在之（zhī）前（qián）多年的運維HADOOP集群還是第一回（huí）出現。故障分析處理過程中分析日誌包括 ：HBASE的MASTER，REGIONSERVER實例日誌，ZOOKEEPER的5台主（zhǔ）機實例日誌（zhì），YARN調度程序運行記錄日誌。通過這次故障分析可以看出，往往造成原因多方麵的，也體現了大數據生態體（tǐ）係複雜性，不同組件的（de）兼容和協同（tóng）能力（lì）是至關重要的，需要研發和（hé）運維團隊有較強的生態和源代碼把控能（néng）力，而不是簡單的把開源組件堆起即可使（shǐ）用。幾（jǐ）點寄語：01故障（zhàng）發生（shēng）後（hòu），現場需要（yào）第一時間保留所有的日誌02需要從故障發生點的異常日誌裏（lǐ）麵，查找有價值（zhí）的信息03需要通過整合所（suǒ）有的日誌文件，進行綜合分析，大（dà）數據集群相對複雜，所有的需要綜合分析所有的組件信息，才能在複雜的環（huán）境中定位出真正的問題
排（pái）查異常連（lián）接數據的主機是哪些程序發出（chū）的
在所內模（mó）擬對（duì）ZK進行高（gāo）負載的連接，測試穩定性（xìng）
国产亚洲熟妇在线视频雲（yún）計算科（kē）技股份有限公司 版權所（suǒ）有 2003-2023
蘇ICP備10224443號-6 蘇公網安備 32011402011374號
蘇公網安備 32011402011374號