एक्सचेंज 2010 के आधार पर बिल्डिंग फेलओवर सिस्टम

आपका दिन शुभ हो!
यह आलेख मेरे अनुभव को एक दोष-सहिष्णु मेल सेवा Microsoft Exchange 2010 SP1 बनाने का वर्णन करता है।
सिद्धांत को समझने के लिए शुरुआती लोगों के लिए यह सबसे अधिक उपयोगी है।
मैं व्यावहारिक पहलुओं में नहीं उतरूंगा, लेकिन एक असफल एक्सचेंज क्लस्टर के निर्माण के लिए आवश्यक सैद्धांतिक आधार को समझाने का प्रयास करूंगा।
बाकी सब कुछ कट के नीचे है। (पाठ के बहुत सारे!)


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

मुझे निम्नलिखित लक्ष्यों को प्राप्त करने की आवश्यकता है:
आंतरिक नेटवर्क पर आउटलुक का उपयोग करने वाले ग्राहकों के लिए दोष सहिष्णुता
• इंटरनेट से HTTPS पर RPC के माध्यम से आउटलुक का उपयोग करने वाले ग्राहकों के लिए आंशिक दोष सहिष्णुता
ActiveSync क्लाइंट के लिए आंशिक दोष सहिष्णुता
• आने वाले (इंटरनेट से) मेल को खोने की संभावना को कम करें

अपने लक्ष्यों के संबंध में, मैंने निम्नलिखित योजना के अनुसार काम करना शुरू कर दिया (एक छोटा स्पष्टीकरण - डेटा सेंटर और कार्यालय के बीच का चैनल 30 एमबी / एस सिंक्रोनस है):


आपको याद दिला दें कि एक्सचेंज 2010 में, न केवल मेलबॉक्स सर्वर एक डीएजी सरणी के तत्व हो सकते हैं, इसलिए यह संस्करण 2007 की तुलना में काम को बहुत सरल करता है।

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

यदि डेटा सेंटर / सर्वर में इंटरनेट गायब हो जाता है, तो कार्यालय में आने वाले सभी मेल सर्वर पर आ जाते हैं। एकमात्र विकल्प जिसमें मेल अभी भी नहीं पहुंच सकता है यदि 30 मिनट से अधिक समय तक इंटरनेट डेटा सेंटर और कार्यालय में (दो चैनलों पर) गायब हो जाता है।

अगला आंतरिक नेटवर्क पर आउटलुक 2010 का उपयोग करने वाले ग्राहकों के लिए दोष सहिष्णुता प्रदान करना है। इसके लिए मेलबॉक्‍स और क्‍लाइंट ऐक्‍सेस भूमिकाओं की शालीनता चाहिए।
मेलबॉक्स की भूमिका वाले 2 एक्सचेंज सर्वरों पर, अलग-अलग साइटों पर 2 डेटाबेस बनाए गए हैं - एक पहली साइट पर सक्रिय है, दूसरा दूसरे पर सक्रिय है।

इसके लिए क्या है:
1) लोड संतुलन, अगर सब कुछ हमेशा की तरह काम करता है।
2) यदि डेटा सेंटर में सर्वर विफल / अनुपलब्ध है, तो कार्यालय में हमारे पास डेटाबेस की एक प्रति है, जो स्वचालित रूप से सक्रिय मोड में बदल जाएगी। उपयोगकर्ता काम करना जारी रख सकते हैं।
3) सक्रिय सर्वर को "गर्म" करने के लिए, सर्वर के सेवा रखरखाव का संचालन करने की क्षमता।

GUI से DAG क्लस्टर बनाते समय, आपको कम से कम एक फ़ाइल गवाह सर्वर निर्दिष्ट करने की आवश्यकता होगी। फ़ाइल गवाह सर्वर (फ़ाइल गवाह), इसे स्पष्ट रूप से रखने के लिए, एक साझा फ़ोल्डर वाला एक सर्वर है जो मेलबॉक्‍स सर्वरों में से एक के विफल होने पर कोरम में आवाज़ों का समर्थन करेगा। यह आवश्यक है कि सर्वरों के बाद, जो कुछ समय के लिए अनुपलब्ध थे, बैक-ऑनलाइन हो गए, वे अन्य क्लस्टर सदस्यों से परिवर्तन (प्रतिकृति दोहरा सकते हैं) और उसी समय "भ्रमित" न हों कि उनके बारे में क्या है और पहले से क्या है। पर्याप्त नहीं है।

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

इस स्तर पर, यह सवाल उठता है: “ लेकिन आउटलुक में सभी के पास एक विशिष्ट क्लाइंट एक्सेस सर्वर पंजीकृत है! और अगर यह ऑफ़लाइन हो जाता है, तो ग्राहक कहां से जुड़ेंगे? "।

यह ऐसी स्थिति को रोकने के लिए है कि नेटवर्क लोड संतुलन सेवाओं का उपयोग किया जाता है। मैंने क्लस्टर सर्वर भूमिका के साथ Windows Server 2008 R2 के साथ उपलब्ध क्षमताओं का उपयोग किया था, लेकिन Microsoft हार्डवेयर NLBs का उपयोग करने की दृढ़ता से अनुशंसा करता है।
NLB सर्वरों के रूप में मैंने संसाधनों को बचाने के लिए फ़ाइल गवाह सर्वर का उपयोग किया।

एनएलबी पर, मैंने क्लाइंट एक्सेस भूमिका के साथ दो एक्सचेंज सर्वरों के बीच लोड संतुलन को कॉन्फ़िगर किया।
हालाँकि, ये सर्वर [लगभग। - क्लाइंट एक्सेस] मेलबॉक्स सर्वर नहीं हैं! मैं दृढ़ता से अनुशंसा करता हूं कि आप इन भूमिकाओं को विभिन्न सर्वरों / वर्चुअल सर्वरों में वितरित करें।

अब आउटलुक क्लाइंट के लिए, सर्वर (जिसे हम खाते सेट करते समय निर्दिष्ट करते हैं) एनएलबी सर्वर है। अधिक से अधिक गलती सहिष्णुता (एनएलबी सर्वरों में से एक की विफलता के मामले में) सुनिश्चित करने के लिए, मैंने टाइप 2 के डोमेन 2 डीएनएस रिकॉर्ड एक ही नाम ( exchange.contoso.com ) उदाहरण के लिए बनाए, जिनमें से प्रत्येक अलग-अलग को संदर्भित करता है एनएलबी सर्वर।
उसी समय, एनएलबी सर्वरों में से 1 की विफलता के मामले में डीएनएस राउंड रॉबिन प्रौद्योगिकी के लिए धन्यवाद, लगभग 50% ग्राहक चालू होंगे। बेशक, DNS कैश भी यहां चलन में आता है, हालाँकि, आप इसके बारे में पढ़ सकते हैं और Microsoft ज्ञानकोष में अलग से रॉबिन राउंड कर सकते हैं।

इसलिए मैंने अपने लक्ष्यों की सूची से पहला आइटम पूरा किया - आंतरिक नेटवर्क पर आउटलुक ग्राहकों के लिए गलती सहिष्णुता ।

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

2 और बिंदु हैं जो स्थानीय नेटवर्क के बाहर ग्राहकों पर लागू होते हैं। यहां सब कुछ बहुत सरल है - अपने डोमेन के लिए सार्वजनिक डीएनएस रिकॉर्ड में मैं फिर से दो (इस बार दो, कार्यालय में बैकअप चैनल पर ट्रैफ़िक को बचाने के लिए) इंगित करता हूं टाइप करें एक रिकॉर्ड जो डेटा सेंटर में और इसके बाद बाहरी फ़ोरफ़्रंट TMG आईपी को संदर्भित करता है। । कार्यालय में आईपी पता। ऑटोडिस्कवर सेवाएं वहां और वहां सक्रिय हैं।
राउंड रॉबिन डीएनएस तकनीक के साथ, HTTPS क्लाइंट्स पर ActiveSync और RPC की आंशिक गलती सहनशीलता सुनिश्चित की जाती है।

PS मुझे आपके प्रश्नों और रचनात्मक आलोचना पर प्रसन्नता होगी।