एक सर्वर लॉकअप नेटवर्क से अन्य सर्वरों को क्यों दस्तक देगा?

Question

हमारे पास कुछ दर्जन Proxmox सर्वर (डेबियन पर Proxmox रन) हैं, और महीने में लगभग एक बार, उनमें से एक को कर्नेल घबराहट और लॉक अप होगा। इन लॉक अप के बारे में सबसे बुरी बात यह है कि जब यह एक सर्वर होता है जो क्लस्टर मास्टर की तुलना में अलग स्विच पर होता है, तो उस स्विच पर अन्य सभी Proxmox सर्वर तब तक जवाब देना बंद कर देंगे जब तक कि हम उस सर्वर को नहीं पा सकते जो वास्तव में दुर्घटनाग्रस्त हो गया है और इसे रिबूट करता है।

जब हमने Proxmox फोरम पर इस मुद्दे की सूचना दी, तो हमें Proxmox 3.1 में अपग्रेड करने की सलाह दी गई और हम पिछले कई महीनों से इसे करने की प्रक्रिया में हैं। दुर्भाग्य से, सर्वरों में से एक जिसे हमने Proxmox 3.1 में माइग्रेट किया था, शुक्रवार को कर्नेल घबराहट के साथ बंद हो गया, और फिर से सभी Proxmox सर्वर जो उसी स्विच पर थे नेटवर्क तक पहुंच से बाहर थे जब तक कि हम दुर्घटनाग्रस्त सर्वर का पता नहीं लगा सकते और इसे रिबूट कर सकते थे।

खैर, स्विच पर लगभग सभी Proxmox सर्वर ... मुझे यह दिलचस्प लगा कि उसी स्विच पर Proxmox सर्वर जो अभी भी Proxmox संस्करण 1.9 पर थे अप्रभावित थे।

यहाँ दुर्घटनाग्रस्त सर्वर के कंसोल का स्क्रीन शॉट है:

जब सर्वर लॉक हो गया, तो उसी स्विच के बाकी सर्वर जो कि Proxmox 3.1 भी चल रहे थे, अप्राप्य हो गए और निम्नलिखित को उगल रहे थे:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

लॉक किए गए सर्वर का uname -a आउटपुट:

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pvversion -v आउटपुट (संक्षिप्त):

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: 2.6.32-109

दो सवाल:

1. किसी भी सुराग क्या कर्नेल आतंक का कारण होगा (ऊपर चित्र देखें)?

2. जब तक लॉक किए गए सर्वर को रिबूट नहीं किया जाता है, तब तक प्रॉक्समोक्स के समान स्विच और संस्करण पर अन्य सर्वर नेटवर्क से क्यों खटखटाए जाएंगे? (ध्यान दें: एक ही स्विच पर अन्य सर्वर थे जो प्रोक्समॉक्स के पुराने 1.9 संस्करण को चला रहे थे जो अप्रभावित थे। इसके अलावा, उसी 3.1 क्लस्टर में कोई अन्य प्रोक्समॉक्स सर्वर प्रभावित नहीं हुए थे जो उसी स्विच पर नहीं थे।)

किसी भी सलाह के लिए अग्रिम धन्यवाद।

Comments

क्या आप पूरा क्रैशडंप दे सकते हैं? ऊपर की तस्वीर दिलचस्प हिस्सों को काट देती है। इसके अलावा, क्या आपने दुर्घटना को lkml पर पोस्ट किया है ? हालांकि, इसे फिर से देखते हुए, यह एक बहुत पुराना कर्नेल है, क्या डेबियन को वर्तमान स्थिर रिलीज में अपग्रेड करने की योजना है?

— ckujau

दुर्भाग्य से, हमारे पास क्रैश डंप नहीं है। मैंने इसे सीरियल कंसोल और / या kdump को कॉन्फ़िगर करने के लिए अपनी सूची में जोड़ा है। कर्नेल के पुराने होने के कारण, Proxmox एक OpenVZ कर्नेल का उपयोग करता है जो मुख्यधारा कर्नेल से एक शाखा है। इसलिए, एक बार जब मैं क्रैश डंप काम कर सकता हूं, तो मैं मदद के लिए OpenVZ डेवलपर्स से संपर्क करूंगा। आपकी टिप्पणी के लिए धन्यवाद ... इससे मुझे सही दिशा में संकेत करने में मदद मिली।

— कर्टिस

किस तरह का स्विच?

— ETL

समस्या 3 अलग-अलग स्विच (एक डलिंक और 2 सिस्को) के साथ हुई है। मेरे पास दो पिछले स्विच पर मॉडल नंबर नहीं हैं, लेकिन नवीनतम सिस्को SG102-24 है। चूँकि यह केवल उसी कर्नेल को चलाने वाले स्विच पर सर्वरों को प्रभावित करता है, और क्योंकि मैं अपने तीसरे स्विच पर हूँ इसलिए ऐसा नहीं लगता कि स्विच को दोष देना है (हालाँकि यह मेरा मूल विचार भी था)।

— कर्टिस

मुझे एक ईमेल सूचना मिली कि किसी ने निम्नलिखित टिप्पणी यहां पोस्ट की है ... "मेरे पास एक समान मुद्दा है, सिवाय इसके कि मैं हार्ड कोर कर रहे एक युगल कंटेनर के साथ मेरा क्रैश कर सकता हूं ..." दुर्भाग्य से, यह वहां काट दिया गया था और जब मैं आया था यहाँ, लेखक ने अपनी टिप्पणी को हटा दिया था, इसलिए मुझे नहीं पता कि यह बाकी क्या था। लेकिन, मैं यह जोड़ूंगा कि मैंने नोट किया है कि भारी नेटवर्क ट्रैफ़िक होने पर समस्या सबसे अधिक बार होती है (जैसे कि जब बैकअप चल रहा हो)। शायद वह टिप्पणी "कट्टर नेटवर्क स्थानांतरण" थी?

— कर्टिस

Answer 1

मैं लगभग निश्चित हूं कि आपकी समस्या सिर्फ एक कारक के कारण नहीं है, बल्कि कारकों के संयोजन के कारण है। जो व्यक्तिगत कारक हैं वे निश्चित नहीं हैं, लेकिन सबसे अधिक संभावना है कि एक कारक या तो नेटवर्क इंटरफ़ेस या ड्राइवर है और दूसरा कारक स्विच पर ही पाया जाता है। इसलिए यह काफी संभावना है कि समस्या केवल इस विशेष ब्रांड के नेटवर्क इंटरफ़ेस के साथ संयुक्त स्विच के इस ब्रांड के साथ पुन: पेश की जा सकती है।

आपको लगता है कि समस्या के लिए ट्रिगर एक व्यक्ति सर्वर पर कुछ हो रहा है, जिसके बाद कर्नेल घबराहट होती है जिसका प्रभाव होता है जो किसी भी तरह से स्विच को फैलाने का प्रबंधन करता है। यह संभव लगता है, लेकिन मैं कहूंगा कि यह संभावना के बारे में है, कि ट्रिगर कहीं और है।

यह हो सकता है कि स्विच या नेटवर्क इंटरफ़ेस पर कुछ हो रहा है, जो एक साथ स्विच पर कर्नेल घबराहट और लिंक समस्याओं का कारण बनता है। दूसरे शब्दों में, भले ही कर्नेल में कर्नेल घबराहट न हो, ट्रिगर बहुत अच्छी तरह से स्विच पर कनेक्टिविटी को नीचे ला सकता है।

एक को पूछना होगा, व्यक्तिगत सर्वर पर संभवतः क्या हो सकता है, जो अन्य सर्वरों पर इसका प्रभाव हो सकता है। यह संभव नहीं होना चाहिए, इसलिए स्पष्टीकरण में प्रणाली में कहीं न कहीं एक दोष शामिल है।

यदि यह दुर्घटनाग्रस्त सर्वर और स्विच के बीच की कड़ी थी, जो नीचे चला गया या अस्थिर हो गया, तो इससे लिंक सर्वर पर अन्य सर्वर पर कोई प्रभाव नहीं होना चाहिए। यदि ऐसा होता है, तो यह स्विच में दोष के रूप में गिना जाएगा। और ट्रैफिकवाइज, दुर्घटनाग्रस्त सर्वर के कनेक्टिविटी से एक बार खो जाने के बाद दूसरे सर्वर को थोड़ा कम ट्रैफ़िक देखना चाहिए, जो यह नहीं बता सकता कि वे समस्या को क्यों देखते हैं।

यह मुझे लगता है कि स्विच पर एक डिजाइन दोष होने की संभावना है।

हालाँकि, एक लिंक समस्या पहली व्याख्या नहीं है, जब कोई यह बताने की कोशिश करेगा कि एक सर्वर पर कोई समस्या स्विच पर अन्य सर्वरों के लिए समस्या कैसे पैदा कर सकती है। एक प्रसारण तूफान एक अधिक स्पष्ट स्पष्टीकरण होगा। लेकिन क्या कर्नेल पैनिक और ब्रॉडकास्ट स्टॉर्म वाले सर्वर के बीच कोई लिंक हो सकता है?

अज्ञात मैक पते के लिए नियत मल्टीकास्ट और पैकेट को प्रसारण के समान ही कम या ज्यादा माना जाता है, इसलिए ऐसे पैकेटों की एक तूफान भी गिनती होगी। क्या पैक्ड सर्वर स्विच द्वारा पहचाने नहीं गए मैक पते पर नेटवर्क पर क्रैशडम्प भेजने की कोशिश कर रहा है?

यदि वह ट्रिगर है, तो अन्य सर्वरों पर कुछ गलत हो रहा है। क्योंकि पैकेट तूफान नेटवर्क इंटरफ़ेस पर इस तरह की त्रुटि का कारण नहीं होना चाहिए। Reset adapter unexpectedlyएक पैकेट तूफान की तरह आवाज नहीं करता है (जो प्रदर्शन में गिरावट का कारण होना चाहिए, लेकिन इसमें कोई त्रुटि नहीं है), और यह एक लिंक समस्या की तरह नहीं है (जिसके परिणामस्वरूप संदेश नीचे जाने वाले लिंक के बारे में संदेश होना चाहिए, लेकिन आप त्रुटि नहीं हैं देख के)।

तो यह संभावना है कि नेटवर्क इंटरफ़ेस हार्डवेयर या ड्राइवर में कुछ दोष है, जो स्विच द्वारा ट्रिगर किया गया है।

कुछ सुझाव जो अतिरिक्त सुराग दे सकते हैं:

1. क्या आप स्विच करने के लिए कुछ अन्य उपकरणों को हुक कर सकते हैं और समस्या को दिखाने पर आप स्विच पर क्या ट्रैफ़िक देख सकते हैं (मुझे लगता है कि यह या तो शांत हो जाता है या आपको बाढ़ दिखता है)।
2. क्या यह संभव है कि परिणाम को अलग-अलग तरीके से देखने के लिए किसी भिन्न ड्राइवर का उपयोग करके किसी अलग ब्रांड के सर्वर पर नेटवर्क इंटरफ़ेस को प्रतिस्थापित किया जाए?
3. क्या एक स्विच को एक अलग ब्रांड के साथ बदलना संभव है? मुझे उम्मीद है कि स्विच को बदलने से समस्या यह सुनिश्चित होगी कि अब कई सर्वर प्रभावित नहीं होंगे। यह जानना और भी दिलचस्प है कि क्या यह कर्नेल पैनिक्स को होने से रोकता है।

Comments

आपके विचारपूर्ण उत्तर के लिए धन्यवाद। आपके 3 सुझावों के संदर्भ में: 1) उपकरण / सॉफ्टवेयर किस प्रकार का काम करेगा? 2) काश मैं कर सकता था, लेकिन इसमें बहुत सारे सर्वर शामिल हैं और मुझे नहीं पता कि समस्या आगे कहां होने वाली है। 3) मैंने पहले ही 3 अलग-अलग स्विच की कोशिश की है (3 अलग-अलग मॉडल, 2 अलग-अलग ब्रांड)। यह भी दिलचस्प है कि Proxmox के एक ही संस्करण पर केवल सर्वर प्रभावित होते हैं। Proxmox में क्लस्टर सिंकिंग मैकेनिज्म होता है, इसलिए मुझे संदेह है कि इसके साथ कुछ करना है। सौभाग्य से, यह एक दो महीने हो गया है क्योंकि यह मुद्दा अब हुआ है।

— कर्टिस

स्विच पर ट्रैफ़िक देखने के लिए मैं tcpdump और / या वायरशार्क के साथ एक साधारण पीसी को हुक करने के बारे में सोच रहा था। जाहिर है आप उस पीसी पर स्थापित सॉफ़्टवेयर को प्रभावित होने से बचाना चाहेंगे। लेकिन ऐसा लगता है कि वास्तव में कोड में एक बग होना चाहिए जो कि प्रोक्समॉक्स कर्नेल में स्थापित होता है। यदि ऐसा बहुत कम होता है, तो आप इसे प्रति माह केवल एक बार और केवल एक बार एक स्विच पर देखते हैं, तो इसे ट्रैक करने में लंबा समय लग सकता है। मैं इसके बारे में थोड़ा सोचता हूं और टिप्पणी करता हूं, अगर अधिक विचार आते हैं।

— कास्परड

Answer 2

यह ईथरनेट चालक या हार्डवेयर / फर्मवेयर में एक बग की तरह मुझे लगता है, यह एक लाल झंडा है:

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly

मैंने इन्हें पहले देखा है और यह सर्वर को ऑफ़लाइन दस्तक दे सकता है। मुझे ठीक से याद नहीं है कि यह इंटेल ईथरनेट कार्ड पर था लेकिन मुझे ऐसा लगता है। यहां तक ​​कि यह स्वयं ईथरनेट कार्ड में एक बग से संबंधित हो सकता है। मुझे याद है कि ऐसे मुद्दों वाले विशेष इंटेल ईथरनेट कार्ड के बारे में कुछ पढ़ना। लेकिन मैं लेख का लिंक खो दिया।

मुझे लगता है कि इसके लिए ट्रिगर आंशिक रूप से उपयोग किए जा रहे ड्राइवर (संस्करण) पर निर्भर करता है, तथ्य यह है कि सॉफ्टवेयर का एक पुराना संस्करण ठीक काम करता है जो इसकी पुष्टि करता है। आप कहते हैं कि विक्रेता अपने स्वयं के कस्टम कर्नेल का उपयोग करता है, ईथरनेट ड्राइवर मॉड्यूल को अपडेट करने का प्रयास करें जो आपके विशेष ईथरनेट हार्डवेयर के लिए उपयोग किया जा रहा है। या तो आपके विक्रेता से एक या आधिकारिक कर्नेल स्रोत पेड़ से एक।

अपने ईथरनेट हार्डवेयर को भी देखें, आम तौर पर एक सर्वर में दो ईथरनेट पोर्ट, ऑनबोर्ड और / या कार्ड (ओं) को जोड़ा जाता है। इस तरह यदि एक ईथरनेट कार्ड में यह समस्या है तो दूसरा उठाएगा। मैं "कार्ड" शब्द का उपयोग करता हूं लेकिन यह किसी भी ईथरनेट हार्डवेयर पर लागू होता है।

इसके अलावा ईथरनेट हार्डवेयर की जगह इसे ठीक कर सकते हैं। या तो एक नया (इंटेल) ईथरनेट कार्ड बदलें या जोड़ें और इसके बजाय इसका उपयोग करें। संभावना है कि अगर मुद्दा हार्डवेयर / फर्मवेयर में है तो एक नए कार्ड में एक फिक्स (या पुराना?) है।

Comments

सभी मशीनों में दोहरी ईथरनेट पोर्ट होते हैं, हालांकि, यह त्रुटि एक ही समय में कई सर्वरों पर होती है जो उसी क्षण स्विच पर होते हैं कि मशीनों में से एक लॉक हो जाता है। जिस समय एक लॉक किया गया सर्वर पावर साइकल होता है, सभी प्रभावित सर्वर तुरंत फिर से एक्सेस हो जाते हैं। यह इंगित करता है कि बंद सर्वर पूरी तरह से बंद नहीं है, लेकिन किसी भी तरह एक ही स्विच पर मशीनों के रीसेट को भर रहा है। यह देखना दिलचस्प होगा कि क्या कोई ड्राइवर अपडेट मदद कर सकता है, लेकिन मुझे नहीं लगता कि सबूत के आधार पर अन्य ईथरनेट कार्ड को सक्रिय करने में मदद मिल सकती है।

— कर्टिस

पुराना धागा, लेकिन यहां तक ​​कि इंटेल e1000e एनआईसी मॉडल 82574L के साथ और 5.0-23 / af4267bf के नए ProxMox संस्करणों में से एक नेटवर्क समस्या अभी भी बनी हुई है। मैं अपने विंडोज़ लैपटॉप (नींद से जागना या बस लॉगिन से) को एक ही स्विच से कनेक्ट कर सकता हूं और ProxMox सर्वर मूल रूप से हर बार रिबूट करता है। मैंने यह भी देखा है जब स्विच से कनेक्ट नहीं होने पर यह केवल छिटपुट रूप से रिबूट होता है। और यह रिबूट होगा जब मैं पहली बार इसे स्विच से जोड़ता हूं। वर्तमान ड्राइवर ३.३.५.३ है और ३.३.५.१०, ३.३.६ और ३.४.०.२ है इसलिए मैं उन लोगों के निर्माण और उपयोग की कोशिश करूँगा। मेरा .02 सी।

— JGlass