लिंक सर्वर जोखिम

Question

मैं एक नई सुविधा लागू कर रहा हूं जिसमें कई सर्वर पर डेटाबेस से डेटा की आवश्यकता होती है। मुझे बस इन सभी सर्वरों से डेटा को यूनियन करने और इसे सॉर्ट करने की आवश्यकता है। दिमाग में आने वाले दो विकल्प हैं:

1. लिंक किए गए सर्वर का उपयोग करें और डेटा को यूनियन और सॉर्ट करने के लिए एक सरल क्वेरी लिखें जो एक सर्वर से चलेगा और दूसरों से डेटा इकट्ठा करेगा।

2. सभी सर्वर से डेटा इकट्ठा करने के लिए एप्लिकेशन का उपयोग करें, और इसे सॉर्ट करने के लिए SQL सर्वर पर वापस भेज दें (आवेदन में सॉर्ट को लागू नहीं करना चाहते हैं)।

हम SQL Server 2008 r2 में सक्रिय / सक्रिय क्लस्टर में अपने सर्वर चलाते हैं। सभी डेटाबेस की एक ही अनुमति है, यदि आपके पास एक डेटाबेस / सर्वर तक पहुंच है, तो आपको उन सभी की अनुमति है। यह एक सार्वजनिक सामना करने वाला एप्लिकेशन है (जिसमें उपयोगकर्ता लॉगिन की आवश्यकता होती है)।

लिंक किए गए सर्वर का उपयोग करने के जोखिम क्या हैं? क्या कोई सुरक्षा खामी है जिससे मुझे चिंतित होना चाहिए? क्या सक्रिय / सक्रिय क्लस्टर में जुड़े सर्वर चलाने में कोई समस्या है? क्या विकल्प की तुलना में कोई महत्वपूर्ण प्रदर्शन मुद्दे होंगे?

लिंक किए गए सर्वरों के बारे में एक सामान्य नकारात्मक "बज़" प्रतीत होता है, लेकिन मुझे कुछ भी ठोस नहीं मिल रहा है जो मुझे विश्वास दिलाता है कि वहां कोई चिंता नहीं है।

Comments

भविष्य के संदर्भ यह सवाल कई बार पोस्ट नहीं करने के लिए सबसे अच्छा है। आपके पास आपके प्रश्न के बारे में पहले से ही एसओ चल रहे हैं, आप केवल ध्यान आकर्षित करने के लिए प्रश्न को ध्वजांकित कर सकते हैं और पूछ सकते हैं कि वे प्रश्न को डीबीएएसई पर भेज देते हैं। stackoverflow.com/questions/16045441/linked-server-risks

Answer 1

लिंक किए गए सर्वर तब तक बहुत अच्छी तरह से काम कर सकते हैं जब तक आपने निहितार्थों के बारे में सोचा हो:

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

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

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

4. लॉकिंग / कॉन्सिरेबिलिटी: ऑफ-सर्वर पर जाने से क्वेरीज़ का रन-टाइम बढ़ जाएगा, जो लॉकिंग के उन मुद्दों को बढ़ा देगा, जिन्हें आप अभी तक नहीं जान पाए हैं और जिससे आपके एप्लिकेशन की कंसिस्टेंसी और स्केलेबिलिटी में गंभीर कमी आई है। नियमित और / या लंबे समय से चल रहे क्रॉस सर्वर क्वेरी का उपयोग करते समय आपको बहुत सावधान रहने की जरूरत है कि आप लॉकिंग मुद्दे पर नज़र रखें और उचित के रूप में योजनाकार संकेत दें।

जब तक आपके पास सुरक्षा और प्रदर्शन के मुद्दों को प्रबंधित करने के लिए पर्याप्त प्रावधान हैं, मुझे लिंक किए गए सर्वर का उपयोग करने में कोई समस्या नहीं दिखाई देगी, हालांकि इसे प्राप्त करने के लिए बेहतर / सुरक्षित / अधिक विश्वसनीय / आसान-से-सुरक्षित तरीके हो सकते हैं। परिणाम।

Answer 2

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

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

Answer 3

लिंक किए गए सर्वर डेवलपर्स के लिए लगभग "जादुई" स्थिति बनाते हैं। लेकिन नेटवर्क को एक क्वेरी के साथ अभिभूत करना बहुत आसान हो सकता है जो एक अनुरोध में 5 सर्वरों से सैकड़ों हजारों रिकॉर्ड वापस कर सकता है, और आप सभी 5 सर्वरों पर भी रिकॉर्ड लॉक कर सकते हैं। जब तक आप 1 या 2 शीर्ष डेवलपर्स को एक क्वेरी के साथ सभी डेटाबेस को लॉक करने के खतरों पर प्रशिक्षित नहीं करते हैं, तब तक मैं किसी को भी, लेकिन अनुभवी डीबीए प्रश्नों को लिखने नहीं दूंगा।

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