बिना तीसरे डेटा सेंटर के HP Storageworks P4xxx पर आधारित सिस्टम की फॉल्ट टॉलरेंस

प्रागितिहास

लगभग दो साल पहले, प्रबंधन ने हमारे डेटा सेंटर के वर्चुअलाइजेशन प्रोजेक्ट में निवेश करने का फैसला किया। कार्य काफी सरल था, लगभग 50 सर्वर, ज्यादातर विंडोज, लिनक्स मशीनों के एक जोड़े, कुछ भी गैर-मानक नहीं। डेटा सेंटर, हालांकि छोटा लेकिन बहुत गर्व है, महत्वपूर्ण है, हम एक बड़े संगठन के यूरोपीय मुख्यालय हैं - हम 30 देशों (यूरोप + सीआईएस) के लिए सेवाओं की मेजबानी करते हैं। दो डेटा केंद्र, विश्वसनीय और डुप्लिकेट संचार, कुछ कारणों से, VMWare ESXi (4 तब 5) और HP Lefthand P4000 (पहला किश्त) और P4500 (दूसरा किश्त) का एक गुच्छा चुना। कारण विशुद्ध रूप से व्यक्तिपरक हैं, VMWare और HP रणनीतिक साझेदार हैं, आदि।

क्या हुआ?

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

हमने पता लगाना शुरू किया।

हम जानते थे कि एक स्वचालित फ़ाइलोवर को 3 डेटा सेंटर की आवश्यकता थी - पूर्व बिक्री बैठकों में, एचपी प्रतिनिधियों ने हमें कई बार इस बारे में चेतावनी दी थी। Admins को बैठकों में आमंत्रित नहीं किया गया था, स्पष्ट करने वाले प्रश्न नहीं पूछे गए थे, किसी कारण से प्रबंधन ने निर्णय लिया कि "केवल 3 डेटा केंद्रों के साथ स्वचालित फ़ाइलोवर संभव है" इसका मतलब है कि "यदि मैन्युअल रूप से, तो दो डेटा केंद्र पर्याप्त हैं।" लेकिन नहीं, एक अनुरोध के जवाब में, एचपी सपोर्ट ने जवाब दिया कि तीसरे डेटा सेंटर के बिना न तो मैन्युअल रूप से और न ही स्वचालित रूप से बुखार असंभव है। सिद्धांत यहां वर्णित के समान है (हमारे मामले में, सिस्टम कुछ अलग हैं - लेकिन सामान्य तौर पर, एक ही मामला)। संक्षेप में, सब कुछ फेलओवर मैनेजर (FOM) से जुड़ा हुआ है - मुख्य डिवाइस की विफलता के समय, यह बैकअप डेटा सेंटर द्वारा नेटवर्क से सुलभ होना चाहिए - ताकि समानांतर कामकाज की स्थिति से बचने के लिए - विभाजित मस्तिष्क। FOM में स्वयं कोई डेटा नहीं है, और विफलता के मामले में केवल एक गवाह के रूप में आवश्यक है। एफओएम के कामकाज के लिए, जो मामूली आवश्यकताओं (2Ghz, 1GB RAM, 13Gb HDD) से अधिक के साथ एक नियमित वर्चुअल मशीन है, आपको केवल हमारे iSCSI VLAN तक पहुंच की आवश्यकता है। हमने तुरंत पता लगाया और हमारे iSCSI VLAN में वीपीएन के साथ क्लाउड में विंडोज सर्वर के विकल्प के साथ प्रबंधन प्रस्तुत किया और FOM चलाने के लिए एक मुफ्त VMWare सर्वर ... लेकिन इस परियोजना को टिप्पणियों के साथ अस्वीकार कर दिया गया:

• क) एक स्वचालित फेलोवर की आवश्यकता नहीं है;
• b) स्टोरेज नेटवर्क में क्लाउड-होस्टेड सर्वर का उपयोग IB पॉलिसी के विपरीत है।

नेतृत्व ने कार्य निर्धारित किया: क्लाउड का उपयोग किए बिना समस्या को हल करना और प्राथमिक और बैकअप स्टोरेज डिवाइस के बीच मैन्युअल रूप से स्विच करने की क्षमता प्रदान करना।

और यहां हमने समस्या का समाधान किया है:

• बैकअप डेटा सेंटर में ईएसएक्सआई होस्ट में से एक पर, स्थानीय भंडारण को सक्रिय करें (सैन विफलता के मामले में पहुंच प्रदान करने के लिए)
• मुख्य FOM की पूरी प्रतिलिपि बनाएँ (सब कुछ कॉपी करें, और सबसे महत्वपूर्ण बात यह है कि बैकअप डेटा सेंटर में मेजबान पर iscsi नेटवर्क से जुड़े वर्चुअल नेटवर्क कार्ड का मैक पता)
• स्टैंडबाय मोड में बैकअप डेटा केंद्र में FOM को छोड़ दें

और यह सब, मुख्य प्रणाली में विफलता के मामले में, बैकअप डेटा केंद्र में FOM को स्टैंडबाय मोड से बाहर ले जाया जाता है, और यह पूरी तरह से दुर्गम मुख्य FOM को बदल देता है। जब सामान्य मोड पर लौटते हैं, तो आपको स्टैंडबाय मोड पर वापस लौटने के लिए याद रखने की आवश्यकता होती है।

---

पीएस खेद है कि अंग्रेजी में चित्रों में पाठ, रिपोर्ट से कॉपी किया गया