सर्वर रखरखाव कब कार्यान्वयन अवरोध को प्रभावित करना चाहिए?

Question

यहां मेरी स्थिति है ...

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

1) सभी अच्छे हैं।

सिस्टम एडमिनिस्ट्रेशन या नेटवर्क इंजीनियर नहीं है, मैं एडी इंस्टेंस स्थापित करने के साथ जुड़े सिस्टम प्रशासन की मात्रा से परिचित नहीं था। मुझे पता नहीं था कि प्रत्येक डोमेन के लिए, मुझे एक अलग सर्वर और डोमेन नियंत्रक की आवश्यकता थी। यह पता चला है के रूप में, 9 अलग-अलग डोमेन है कि मेरी टीम विभिन्न वातावरण है कि हम विज्ञापन तक पहुँचना करने जा रहे हैं के सभी के लिए स्थापित किए जाने की आवश्यकता ... की तरह हैं

• env1.dev.mycompany.com
• env1.qa.mycompany.com
• env1.stage.mycompany.com
• env2.dev.mycompany.com
• आदि

... तो अब मैं पर पर रखा गया है खुद कुछ प्रशासनिक सिरदर्द की वजह से मुझे इन सभी मशीनों (या वीएम) को बनाए रखना होगा, जो कुछ ऐसा है जो मुझे जरूरी नहीं है कि मैं करना चाहता हूं।

2) सभी अच्छा नहीं है।

प्रोटोटाइप वास्तव में ठोस है, और एडी समाधान के लिए बहुत अच्छा डेटाबेस बनाता है, लेकिन अब मुझे आश्चर्य है कि मुझे कोड स्क्रैप करना चाहिए और इसके बजाय SQL सर्वर डेटा प्रदाता लिखना चाहिए (मुझे पता है .Net पहले से ही एक प्रदान करता है , लेकिन यह अकेले प्राधिकरण के लिए मेरी व्यावसायिक आवश्यकताओं के अनुरूप नहीं है)।

वैसे भी, इसलिए मैं इस समस्या के माध्यम से उच्च स्तर के परिप्रेक्ष्य से सोचने की कोशिश कर रहा हूं। आम तौर पर, मैं इस तथ्य पर ट्राइपिंग करता रहता हूं कि कुछ सर्वर रखरखाव के कारण मैं वास्तव में एक अच्छा समाधान फेंक रहा हूं? मैं सोच रहा हूं कि अगर किसी ने यहां इस तरह के परिदृश्य का अनुभव किया है और आपने वास्तव में क्या करने का फैसला किया है।

एडी के लिए विशिष्ट नहीं होना चाहिए, केवल एक ऐसी स्थिति जहां आपको एक अच्छे सॉफ़्टवेयर समाधान और सर्वर की रखरखाव बाधाओं के बीच मूल्यांकन करना था।

Answer 1

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

रखरखाव उपयोगिता के एक पहलू के रूप में सोचा जा सकता है। मैं आसानी से रखरखाव योग्य उत्पाद रखने के लिए इसे सर्वोच्च प्राथमिकता दूंगा। लंबे समय तक प्रशासकों से कई घंटों का काम बचाएगा।

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

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

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

Answer 2

यदि विंडोज सिस्टम के लिए सिस्टम पर एक सिंगल साइन सेट करना है तो मैं एडी का उपयोग करना बहुत पसंद करता हूं। एक sys व्यवस्थापक के रूप में। मैं एक एकल स्रोत-डेटा-डेटा नीति का पालन करने का प्रयास करता हूं। एडी पहले से ही मेरे विंडोज उपयोगकर्ता/सुरक्षा डेटा को पकड़ रहा है। मैं दूसरी प्रणाली के बजाय वहां सब कुछ पसंद करना पसंद करूंगा।

dev/test/prod वातावरण स्थापित करते समय मैं यह सुनिश्चित करने का प्रयास करता हूं कि प्रोड एक से निकटता से मेल खाएं, खासतौर पर उस क्षेत्र में जहां विकास कार्य चल रहे हैं, आदि। इसलिए यदि एडी के साथ इंटरफ़ेस विकसित करने के लिए सिस्टम सेट अप करना होगा तो मेरे पास एकाधिक एडी सर्वर होंगे।

व्यवस्थापक कौन सा विकल्प सरल बना सकता है?

क्या आपके पास 1 मास्टर सर्वर है जो आप मानक तरीके से बनाए रखते हैं और सभी या अधिकतर लोगों को बनाए रखने के लिए वीएमवेयर कॉपी प्रक्रिया की तरह कुछ उपयोग करते हैं?9 सर्वरों में कुछ करने के बजाय, अन्य 8 को उस दर्पण की प्रतियों के रूप में मास्टर को dev/test का समर्थन करने के लिए किए गए परिवर्तनों को छोड़कर रखें?

क्या आप 1 एडी सर्वर से एकाधिक देव या टेस्ट डोमेन चला सकते हैं?

क्या आप कार्यवाही कर सकते हैं?

क्या आप पर्यावरण की संख्या को कम कर सकते हैं, खासकर परीक्षण के उच्च अंत में? जैसे एक से अधिक टेस्ट वातावरण में कई देव वातावरण प्रदान करते हैं और रिलीज करते हैं?

Answer 3

परीक्षण करते समय अलग डोमेन के बजाय ओयू का उपयोग क्यों न करें? यही है, एक डोमेन है, लेकिन निर्दिष्ट करें कि विशेष संस्करणों के लिए उपयोगकर्ता उस डोमेन के अंदर एक विशेष ओयू में पाए जाना चाहिए। उपयोगकर्ताओं को देखने के लिए आप अपने खोज कार्यों में क्या करेंगे, आप डोमेन की जड़ के बजाय विशेष ओयू को खोज रूट के रूप में निर्दिष्ट करेंगे। प्रत्येक OU में आप आईडी कि पर्यावरण को शामिल उन्हें अद्वितीय है, उदा रखने के लिए हो सकता था, user_env1_dev, user_env2_dev, user_env1_qa ...

मैं अपने ऐप्स के लिए ई एक बहुत का उपयोग करें और कभी नहीं विकास/परीक्षण के लिए अलग डोमेन की स्थापना की।

Answer 4

प्रदाता पैटर्न का उपयोग करें और अपने डेटासोर्स कॉल को अमूर्त करें।

फिर आप इसे फ्लाई पर एडी या एसक्यूएल का उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं।

public abstract SSODataProvider { 
    public bool AuthenticateUser(string u, string p); 
} 

public ADSSODataProvider : SSODataProvider { 
    public override AutheticateUser(string u, string p) { 
     //do auth here 
    } 
} 

public SQLSSODataProvider : SSODataProvider { 
    public override AuthenticateUser(String u, string p) { 
     //call DB 
    } 
} 

public static SSODataProvider dataProvider; 

if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL") 
    dataProvider = new SQLSSODataProvider(); 
else 
    dataProvider = new ADSSODataProvider(); 

.... 

dataProvider.AuthenticateUser("sss","sss");