इसलिए, 4 जनवरी को 7:15 पर, नींद से अपनी आँखें पोंछते हुए, मुझे ज़ैबिक्स सर्वर से टेलीग्राम समूह में एक संदेश का एक पैकेट मिलता है कि वर्चुअलाइजेशन सर्वर में से एक पर सीपीयू लोड बढ़ गया है:
ज़ैबिक्स में इतिहास को देखने के बाद, मैं सर्वर पर चढ़ता हूं और dmesg में देखता हूं, जहां मुझे निम्नलिखित मिलते हैं:
[ 3 20:05:18 2019] qla2xxx [0000:21:00.1]-015b:10: Disabling adapter. [ 3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device [ 3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device [ 3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device [ 3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device [ 3 20:05:28 2019] sd 10:0:0:1: rejecting I/O to offline device
मैं उस स्टोरेज में चढ़ रहा हूँ जहाँ QLogic FC एडाप्टर दिख रहा है, मैं देखता हूँ कि 1 जनवरी को 19:54 पर स्टोरेज में से एक ड्राइव को सर्विस से बाहर कर दिया गया था, स्पेयर ड्राइव को उठाया गया था और 2 जनवरी को 9:11 को समाप्त हो गया था।
मैंने सोचा: शायद रिपॉजिटरी या एफसी स्विच से कुछ आया, जिससे ड्राइवर को QLogic एडॉप्टर से नाराज होना पड़ा।
ट्रैकर में एक कार्य बनाया, सर्वर को फिर से शुरू किया, सब कुछ फिर से उसी तरह काम किया, जैसा कि पहली नज़र में होना चाहिए।
इस पर उन्होंने नए साल की छुट्टियों के अंत तक आगे की कार्रवाई स्थगित कर दी।
9 जनवरी को कामकाजी सप्ताह की शुरुआत के साथ, उन्होंने विफलता के कारण को सुलझाना शुरू कर दिया।
संदेश के बाद से:
[ 3 20:05:18 2019] qla2xxx [0000:21:00.1]-015b:10: Disabling adapter.
बहुत जानकारीपूर्ण नहीं है, चालक स्रोत में चढ़ गए।
ड्राइवर कोड को देखते हुए, पीसीआई (लिनक्स / ड्राइवर / scsi / qla2xxx / qla_os.c (कर्नेल v4.15) पर एक त्रुटि के कारण ड्राइवर को उतारने पर एक संदेश जारी किया जाता है:
qla2x00_disable_board_on_pci_error(struct work_struct *work) { struct qla_hw_data *ha = container_of(work, struct qla_hw_data, board_disable); struct pci_dev *pdev = ha->pdev; scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev); /* * if UNLOAD flag is already set, then continue unload, * where it was set first. */ if (test_bit(UNLOADING, &base_vha->dpc_flags)) return; ql_log(ql_log_warn, base_vha, 0x015b, "Disabling adapter.\n");
मैं आगे खुदाई करने लगा, बीएमसी में मिला, मैं इवेंट लॉग में देखता हूं:
यह पता चला है कि मंच में दो सीपीयू नोड्स में से एक वार्मिंग और थ्रॉटलिंग है, और एफसी एडाप्टर के ड्राइवर को उतारने के बारे में संदेश का समय थ्रॉटलिंग के शुरुआती समय के साथ संबंधित है।
यहां यह टिप्पणी करने योग्य है कि हमारे पास यहां मौजूद सर्वर प्लेटफॉर्म https://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HNC0R.cf है , प्रत्येक नोड पर दो EPYC 7601 के साथ:
मैंने इसे डेटा सेंटर में स्थानांतरित किया, सर्वर से नोड को हटा दिया, थर्मल पेस्ट को बदल दिया, इसे वापस चिपका दिया, लेकिन यह अभी भी गर्म है।
हमने देखा कि सर्वर के एक हिस्से में हवा का प्रवाह दूसरे की तरह मजबूत नहीं है। स्ट्रेस-एनजी के साथ सभी नोड्स को थोड़ा लोड करने के बाद, यह स्पष्ट हो गया कि प्लेटफ़ॉर्म के दाईं ओर नोड प्रोसेसर ठीक से नहीं उड़ते हैं और दो सीपीयू में दो सीपीयू का तापमान बहुत जल्दी महत्वपूर्ण हो जाता है।
बीएमसी में उड़ाने के मापदंडों को बदलने की कोशिश करने के बाद, यह पता चला कि उनका कोई प्रभाव नहीं था:
बीएमसी को फिर से शुरू करने का भी कोई असर नहीं हुआ।
सेंसर रीडिंग में देखने के बाद, मैंने देखा कि 53 सेंसर में से एक नोड पर, केवल 4 का पता लगाया गया है, और दूसरे नंबर पर केवल:
और फिर, मुझे याद आया कि जब एक या दो महीने पहले एक नया BIOS संस्करण और एक नया BMC नोड्स में चमकता था, तो दो नोड्स पर मैंने BMC कॉन्फ़िगरेशन को फ़ैक्टरी मापदंडों (ट्यूनिंग के एक विशेष मामले की जांच के लिए) को रीसेट नहीं किया था।
BMC को फ़ैक्टरी मापदंडों पर रीसेट करने के बाद, सभी 53 सेंसर को फिर से पता चला, पंखे की गति नियंत्रण ने फिर से काम किया, प्रोसेसर ने गर्म होना बंद कर दिया।
तथ्य यह है कि QLogic ड्राइवर को उतारने का कारण प्रोसेसर का अधिक गरम होना सटीक नहीं है, लेकिन मुझे अन्य करीबी सहसंबंध नहीं मिले।
निष्कर्ष:
- बीएमसी फर्मवेयर के बाद, भले ही सब कुछ पहली नज़र में ठीक काम करता हो, फिर भी यह फ़ैक्टरी सेटिंग्स को रीसेट करने लायक है;
- बेशक, तापमान और कर्नेल त्रुटि संदेशों की निगरानी की जानी चाहिए और योजनाओं में यह स्वाभाविक है, लेकिन एक बार में ही नहीं।