सक्रिय निर्देशिका और एक्सचेंज आर्किटेक्चर प्रश्न और मुद्दे

Question

यहाँ हमारी स्थिति पर पृष्ठभूमि है ...

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

कंपनियों और 80 उपयोगकर्ताओं के बीच लगभग 160 मेलबॉक्स हैं (अतिरिक्त मेलबॉक्स या तो आईटी उप-प्रणालियों के लिए हैं, खातों या अन्य उपयोगों को अग्रेषित करते हैं)।

कंपनियां आधिकारिक तौर पर एक साथ विलय कर रही हैं (केवल एक भरोसे के रिश्ते होने के बजाय)। इसलिए हम एक संयुक्त समाधान (एक नए नाम पर आधारित) में देख रहे हैं जहां प्रत्येक कार्यालय एक ही सिस्टम (एक्सचेंज और सक्रिय निर्देशिका) पर होगा और साथ ही साथ हमारे आईटी बुनियादी ढांचे को मजबूत करेगा (इसमें बहुत दोहराव है)।

उन्होंने हमारे आईटी इन्फ्रास्ट्रक्चर में आने और ऑडिट करने के लिए एक बाहरी कंपनी को काम पर रखा। उन्होंने आईटी इन्फ्रास्ट्रक्चर को आउटसोर्स करने के लिए एक आधिकारिक सिफारिश की है (और लगता है कि वे क्या सेवा प्रदान करना चाहते हैं)।

मुझे यह पता लगाने का काम सौंपा गया है कि मुझे क्या करना है। मैंने इसके बारे में बहुत सोचा है, और मैं दो विकल्पों के साथ आया हूँ। मूल अंतर वह है जहां एक्सचेंज होस्ट किया जाता है (आंतरिक रूप से हमारे आउटसोर्स)। चूंकि आउटसोर्स करना थाह लेना आसान है, इसलिए मैं केवल आंतरिक सेटअप का विस्तार करूंगा।

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

site1:

• FSMO सक्रिय निर्देशिका भूमिका
• एक्सचेंज मेलबॉक्स भूमिका - प्राथमिक
• एक्सचेंज क्लाइंट एक्सेस, हब ट्रांसपोर्ट सर्वर रोल्स
• DFS फ़ाइल साझा भूमिका (साझा ड्राइव के लिए)

Site2:

• सक्रिय निर्देशिका भूमिका - साइट 1 से प्रतिकृति
• एक्सचेंज मेलबॉक्स भूमिका - माध्यमिक, सीसीआर प्रतिकृति का उपयोग करके दोहराया गया
• एक्सचेंज क्लाइंट एक्सेस, हब ट्रांसपोर्ट सर्वर रोल्स
• DFS फ़ाइल साझा भूमिका

Site3:

• सक्रिय निर्देशिका भूमिका - साइट 1 से प्रतिकृति
• एक्सचेंज क्लाइंट एक्सेस, हब ट्रांसपोर्ट सर्वर रोल्स
• फ़ाइल शेयर गवाह (विफलता के लिए)
• DFS फ़ाइल साझा भूमिका

तो मूल रूप से क्लस्टर किसी भी अन्य साइटों (या किसी भी सिस्टम) को नीचे लाए बिना एक साइट की विफलता से बचने में सक्षम होना चाहिए। दोहरी साइट की विफलता की स्थिति में, एक्सचेंज पूरी तरह से बंद हो जाएगा।

तो, मेरी चिंता इस प्रकार है:

1. क्या यह एक उचित सेटअप है? या मैं चीजों को उलझा रहा हूं?
2. आवश्यक सर्वरों की संख्या (प्रत्येक साइट पर सीसीआर मेलबॉक्स भूमिकाएँ स्थापित होने के बाद ही होनी चाहिए)।
3. क्या यह समन के रूप में भी काम करेगा (जहां यह स्वचालित रूप से विफल हो जाएगा-उपलब्ध नोड पर साइट या सर्वर को नीचे जाना चाहिए)?
4. चूंकि प्रत्येक कार्यालय अपने उपयोगकर्ताओं के लिए एक स्थानीय क्लाइंट एक्सेस सर्वर निर्दिष्ट करेगा, वह सर्वर सभी स्थानीय अनुरोधों के लिए विफलता का एक बिंदु बन जाता है (लेकिन यह मैन्युअल DNS परिवर्तन द्वारा हल किया जा सकता है)
5. क्या इन सभी सर्वरों को काम करने के लिए समान आईपी सबनेट पर होना चाहिए? या मैं इसके लिए एक hiearchial DNS का उपयोग करके दूर हो सकता हूं (clientaccess.site1.foo.com, आदि)?
6. यह मुझे प्रत्येक कार्यालय को एमएक्स रिकॉर्ड के रूप में सेट करने देगा (चूंकि इंटरनेट से कनेक्ट करने के लिए प्रत्येक कार्यालय में एक हब ट्रांसपोर्ट सर्वर है) इसलिए यदि एक कार्यालय नीचे जाता है तो भी हमें दूसरों में ईमेल प्राप्त करने में सक्षम होना चाहिए, सही?
7. रख-रखाव। मुझे डर है कि लंबे समय तक चलने (कार्यालयों को जोड़ने, कार्यालयों को हटाने, उन्नयन सर्वर (ओएस और हार्डवेयर दोनों), आदि) को बनाए रखने के लिए यह सेटअप बहुत जटिल होगा। क्या यह उचित डर है?

अब, यह भी सवाल है कि क्या सर्वर 2003 या 2008 के साथ जाना है ... यदि हम आंतरिक विनिमय मार्ग पर जाते हैं, तो मुझे लगता है कि मैं शक्तियों को 2008 में अपग्रेड करने के लिए मना सकता हूं (वास्तव में हमें एक्सचेंज 2010 का उपयोग करने के लिए अपग्रेड करने की आवश्यकता होगी) ... लेकिन क्या यह वास्तव में आवश्यक है या यह है कि मेरी सिर्फ एक "चाहत" है जो योजनाओं के प्रति छींटाकशी करती है (बजाय एक न्यायोचित उन्नयन के ...)

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

इस पैमाने की यह पहली परियोजना है जिसे मैं प्रयास कर रहा हूं, इसलिए किसी भी मदद की बहुत सराहना की जाएगी ...

अग्रिम धन्यवाद (और पुस्तक के लिए खेद है) ...

Comments

बहुत अच्छी तरह से लिखित और प्रलेखित प्रश्न के लिए +1। अगर मैं कर सकता तो आप अपने अवतार के लिए +2 देते।

— पोस्का

Answer 1

हम एक समान स्थिति में हैं, इस तथ्य को छोड़कर कि हमारे मामले में हम पहले से ही एक कंपनी हैं। लेकिन हमारे कैंब्रिज, लंदन, स्टॉकहोम, शंघाई और अटलांटा में कार्यालय हैं। सभी वीपीएन के माध्यम से जुड़े हुए हैं। इनमें से तीन में एक्सचेंज सर्वर हैं (2 एक्सचेंज 2010 में, तीसरे को बहुत जल्द अपग्रेड किया जाएगा)। हमारे अधिकांश डोमेन नियंत्रक विंडोज 2003 चलाते हैं, लेकिन हम उन सभी को विंडोज 2008 में अपग्रेड करने के रास्ते पर हैं। हमारे पास लगभग 150 कर्मचारी हैं, जो सभी जगह फैले हुए हैं। तो आपकी स्थिति के समान।

तो यहाँ मेरे दृष्टिकोण से कुछ जवाब हैं:

1. यदि आपके पास एक अच्छी आईटी टीम है, तो मैं कभी आउटसोर्सिंग पर विचार नहीं करूंगा। वास्तव में, भले ही आपकी टीम सभ्य न हो, मैं इसे सभ्य बनाने के लिए कुछ प्रयास करूंगा। आपकी प्रतिक्रिया का समय बहुत बेहतर होगा, आपका सुरक्षा सेटअप सरल है, लेकिन सभी के लिए सबसे महत्वपूर्ण है: आपकी आईटी टीम का प्राथमिक ध्यान आईटी के बुनियादी ढांचे को बेहतर बनाए रखने पर होगा। आउटसोर्सिंग प्रदाता का मुख्य ध्यान आप में से सबसे अधिक पैसा बनाने पर है, सर्वोत्तम सेवा प्रदान नहीं करना।
2. आपका नियोजित सेटअप बहुत अधिक संभव है। आपकी मुख्य चुनौती एक सामान्य डोमेन पर सब कुछ स्थानांतरित करना होगा, लेकिन यह कदम से कदम हो सकता है।
3. आप की जरूरत है कि ज्यादातर के लिए सर्वर एक हाथ और एक पैर खर्च नहीं होगा। यदि आपको अतिरिक्त सर्वर खरीदने की आवश्यकता है, तो उसके लिए पूंजी परिव्यय छोटा होगा।
4. चाहे वह काम करता हो या न किया गया हो या नहीं, यह इस बात पर निर्भर करता है कि आपके पास आपकी सार्वजनिक DNS और आपकी आंतरिक रूटिंग कितनी अच्छी तरह कॉन्फ़िगर की गई है। यह निश्चित रूप से काम करने के लिए बनाया जा सकता है।
5. मैं अत्यधिक प्रत्येक कार्यालय के लिए अलग सबनेट होने की सलाह दूंगा। एक Sysadmin बहुत आसान के रूप में जीवन बनाता है। प्रत्येक कार्यालय के लिए एक सभ्य आकार के सबनेट का उपयोग करें, और फिर साइटों या OSPF के बीच यातायात के लिए स्थैतिक मार्ग का उपयोग करें (सबसे सभ्य वीपीएन राउटर OSPF को बंद की पेशकश करेगा)। अधिकांश कॉरपोरेट ट्रैफ़िक को इंजीनियरिंग ट्रैफ़िक से अलग रखते हुए, वास्तव में हमारे 2 अलग-अलग सबनेट हैं (चूंकि हमारे इंजीनियर डीएनएस, डीएचसीपी, वीडियो स्ट्रीमिंग और क्या नहीं) के साथ बहुत सारे फंकी सामान करते हैं। और यह खूबसूरती से काम करता है। वास्तव में, हमारे पास यह भी है कि किसी भी कार्यालय में इंजीनियर एक स्ट्रीमर से वीडियो स्ट्रीम का उपयोग कहीं और कर सकते हैं, बिना यह जाने कि यह कहां से आता है।
6. एक बड़े सबनेट पर सभी कंप्यूटर रखने का प्रयास न करें । आप अपने बालों को चीर देंगे। वादा।
7. हमारे पास तीन सार्वजनिक मेल गेटवे हैं (उच्चतम इंटरनेट कनेक्शन बैंडविड्थ वाले कार्यालयों में स्थित हैं), जो सभी बिल्कुल उसी तरह से कॉन्फ़िगर किए गए हैं और सभी निकटतम एक्सचेंज सर्वर के लिए हैं, जहां से मेल अंतिम मेलबॉक्स में वितरित किया जाता है। बिल्कुल भी परेशानी नहीं है।
8. एक बार जब आप रूटिंग और इस तरह की एक बुनियादी पकड़ रखते हैं, तो आप पाएंगे कि इसे बनाए रखना मुश्किल नहीं है। मेरे पास इन सभी साइटों पर लगभग 150 सर्वर हैं, लगभग आधा दर्जन वीपीएन राउटर, कई दर्जन प्रबंधित स्विच। हम एक मिश्रित सेटअप (30% विंडोज, 70% लिनक्स, सर्वर और वर्कस्टेशन पर) हैं और मेरे पास 4 लोग हैं। कोईबातनही।

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

Comments

वाह! क्या जवाब है! खैर, मुझे आपके द्वारा किए गए कुछ बिंदुओं पर प्रतिक्रिया देना चाहिए। सबसे पहले, मैं सब कुछ एक सबनेट पर नहीं डालूंगा जब तक कि बिल्कुल आवश्यक न हो। जो मैं सोच रहा हूं वह सब कुछ एक वर्ग सी सबनेट पर रखना है, प्रत्येक कार्यालय के लिए विशिष्ट सबनेट के साथ (इसलिए साइट 1 कंप्यूटर के लिए उदाहरण के लिए 172.25.50.0, साइट 1 सर्वर के लिए 172.25.55.0, साइट 2 कंप्यूटर के लिए 172.25.60.0, आदि)। फिर सब कुछ बस मुखौटा निर्दिष्ट करके प्रबंधित किया जा सकता है ... एक नोट, क्या आप कई मेलबॉक्स सर्वर (प्रति साइट एक) का सुझाव देते हैं? या एक एकल अखंड मेलबॉक्स सर्वर अतिरेक के लिए दोहराया गया?

— ircmaxell

या क्या यह वही है जो आप सबनेट के संबंध में चेतावनी दे रहे थे? क्या मैं प्रत्येक कार्यालय को पूरी तरह से अलग सबनेट (उसी \ C का हिस्सा भी नहीं) देना बेहतर होगा?

— ircmaxell

सबनेटिंग: आप जो वर्णन करते हैं, वह वही है जो हम करते हैं और जो मेरे मन में था, मैं उसी तरह से निर्धारित करना चाहता था, क्योंकि परिस्थितियां विस्तार लेआउट को निर्धारित करती हैं।

— वुल्फगैंग्ज़

ईमेल: मैं सुझाव दूंगा कि साइट पर मौजूद सभी उपयोगकर्ताओं के लिए अन्य साइट मेलबॉक्सों के लिए DAG के साथ स्थानीय मेलबॉक्स हों (यह एक एक्सचेंज 2010 अवधारणा और बहुत उपयोगी है)।

— wolfgangsz

पर्याप्त रूप से उचित (मैंने देखा कि 2010 में, और यह वही प्रतीत होता है जो हम चाहते हैं)। मैं व्यापार से एक डेवलपर हूँ। लेकिन जब हमारे sys-admin ने लगभग एक साल पहले छोड़ दिया तो मैंने (अपनी साइट के लिए) जिम्मेदारियां संभाल लीं। मुझे यह पसंद है और बहुत कुछ सीखा है, लेकिन अभी भी बहुत कुछ सीखना बाकी है ... इसलिए इन चीजों पर एक पवित्रता की जांच करना वास्तव में अच्छा और उपयोगी है ... धन्यवाद एक गुच्छा!

— ircmaxell