डेटाबेस और वेब सर्वर को एक ही मशीन पर रखना उचित क्यों नहीं है?


126

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

अगर प्रदर्शन कोई समस्या नहीं है तो यह इतनी बड़ी बात क्यों होगी?

जवाबों:


158
  1. सुरक्षा। आपका वेब सर्वर एक DMZ में रहता है, जो सार्वजनिक इंटरनेट तक पहुंच रखता है और अनाम उपयोगकर्ताओं से अविश्वसनीय इनपुट लेता है। यदि आपके वेब सर्वर से समझौता हो जाता है, और आपने अपने DB से जुड़ने में कम से कम विशेषाधिकार नियमों का पालन किया है, तो अधिकतम एक्सपोजर वही है जो आपका ऐप डेटाबेस API के माध्यम से कर सकता है। यदि आपके बीच में व्यापार स्तरीय है, तो आपके पास अपने हमलावर और आपके डेटा के बीच एक और कदम है। यदि, दूसरी ओर, आपका डेटाबेस एक ही सर्वर पर है, तो हमलावर के पास अब आपके डेटा और सर्वर तक रूट एक्सेस है।
  2. अनुमापकता। अपने वेब सर्वर को स्टेटलेस रखने से आप अपने वेब सर्वरों को क्षैतिज रूप से बहुत सहजता से स्केल कर सकते हैं। यह है बहुत क्षैतिज एक डाटाबेस सर्वर पैमाने पर करने के लिए मुश्किल।
  3. प्रदर्शन। 2 बॉक्स = 2 बार सीपीयू, 2 बार रैम, और 2 बार डिस्क एक्सेस के लिए स्पिंडल।

कहा जा रहा है कि, मैं निश्चित रूप से उचित मामलों को देख सकता हूं कि उन बिंदुओं में से कोई भी वास्तव में मायने नहीं रखता है।


27
लेकिन 2 मशीनों के साथ आपको हार्डवेयर विफलता की संभावना दोगुनी है;)
TWith2Sugars

4
@ TWith2Sugars - किस के विपरीत?
केव

3
संदर्भ। बिंदु 1. यदि वेब टीयर स्वामित्व में है, तो आपको ऐप / डेटाबेस एपीआई इंटरफेस की तुलना में अधिक क्या चाहिए या क्या चाहिए? निश्चित रूप से यह वैसे भी उस बिंदु पर खेल है? डीएमजेड इन्फ्रास्ट्रक्चर का समर्थन करने के लिए आवश्यक सेवाओं के संदर्भ में चीजें बहुत दिलचस्प हैं, जैसे कि कोई भी विज्ञापन या Microsoft सेवाएं?
नॉयली डन

4
@ नोइली - आपके वेब टीयर के पास यह कहने के लिए एक्सेस नहीं होगा कि डेटाबेस को एक फाइल में बैकअप करें और उस फाइल को ftp.hackers.com पर xp_cmdshell का उपयोग करके। या डेटाबेस को छोड़ दें। या कॉन्फ़िगर मूल्यों को संशोधित करें। आदि
मार्क ब्रैकेट

6
@ मिर्गी - चूंकि दो मशीनें समानांतर में हैं और प्रत्येक में विफलता का एक बिंदु है, समग्र विश्वसनीयता कम है; यह तकनीकी रूप से दोहरा नहीं है (यह वास्तव में 1 - (आर 1 * आर 2)) है, लेकिन बड़ी विश्वसनीयता और छोटे नोड्स के लिए पर्याप्त है .... 0.01% मामले में, यह 0.0199% होगा। लेकिन 100 नोड्स के लिए, यह दोहरीकरण कथन द्वारा निहित 100% के बजाय 36.6% होगा।
मार्क ब्रैकेट

45

यह वास्तव में कोई फर्क नहीं पड़ता (आप एक ही मशीन पर वेब / डेटाबेस के साथ अपनी साइट को बहुत खुशी से चला सकते हैं), यह स्केलिंग में सबसे आसान कदम है।

यह बिल्कुल वैसा ही है जैसा कि StackOverflow ने किया - IIS / SQL सर्वर पर चलने वाली एकल मशीन से शुरू करना, फिर जब यह भारी लोड होने लगा, तो एक दूसरा सर्वर खरीदा गया और SQL सर्वर को उस पर ले जाया गया।

यदि प्रदर्शन कोई समस्या नहीं है, तो दो सर्वर खरीदने / बनाए रखने के लिए पैसे बर्बाद न करें।


3
मैं सहमत हूं, लोड कम होने पर यह किया जा सकता है ... जैसे-जैसे लोड बढ़ता है, इसकी आसान उन्हें 2 या अधिक मशीनों में अलग करना है।
ईजे ब्रेनन

4
मैं अंदर आया और उसी चीज पर टिप्पणी करने जा रहा था। आपको DB सर्वर को बदलना आपके कनेक्शन स्ट्रिंग (ज्यादातर मामलों में) को बदलने के रूप में आसान है।
सिटीजनबैन

उह, मुझे यह पसंद है। कोई व्यक्ति समाधान सुझाने से पहले संदर्भ के बारे में सोच रहा है!
20

22

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


4
... जब तक समवर्ती उपयोग बढ़ता है, और डीबी सर्वर को बफ़र्स और कैश का प्रभावी उपयोग करने के लिए अधिक मेमोरी की आवश्यकता होती है। एक बार वेब / ऐप और डीबी सर्वरों को एक बॉक्स पर साझा करने की तुलना में अधिक मेमोरी की आवश्यकता होती है, पेजिंग और डिस्क I / O बढ़ता है, और प्रदर्शन टैंक।
कर्माट

@MattK - लेकिन क्या होगा अगर आपके पास भारी मात्रा में मेमोरी है? हमारे पास एक ऐप है जहां प्रत्येक क्लाइंट का अपना डेटाबेस है, इसलिए डेटाबेस और वेब सर्वर दोनों क्षैतिज रूप से बहुत आसानी से स्केल कर सकते हैं। यह देखते हुए कि हमारे पास डिस्क से अधिक मेमोरी उपयोग में है (64 जीबी बनाम ~ 40 जीबी), क्या यह एक ही मशीन पर इसे रखने के लिए प्रदर्शन के लिए बेहतर नहीं होगा?
बीप बीप

1
यदि आपका वर्किंग सेट मेमोरी में फिट बैठता है, तो हो सकता है कि आप मेरे द्वारा बताए गए प्रदर्शन के किसी भी मुद्दे को न देखें। अधिक बार सर्वर में रैम की तुलना में अधिक डिस्क होती है, लेकिन ऐसा लगता है कि आपके मामले में आपके पास डेटाबेस हैं जो पूरी तरह से रैम में फिट होंगे - जब तक कि साझा सर्वर पर एप्लिकेशन इसका बहुत अधिक उपभोग नहीं करते हैं।
कर्मठ

15

मुझे लगता है कि बड़ा कारक प्रदर्शन होगा। दोनों वेब सर्वर / ऐप कोड और SQL सर्वर आमतौर पर मेमोरी में डेटा का अनुरोध करते हैं और आप उन्हें उसी मेमोरी स्पेस में चलाकर आपके कैश प्रदर्शन को मार रहे हैं।


12
यदि आपके पास एक छोटा (ish) डेटाबेस है, लेकिन टन मेमोरी के साथ? प्रत्येक डेटाबेस कॉल के लिए नेटवर्क पर जाने की लागत नहीं होगी, खासकर अगर वहाँ कई हैं, लाभ पल्ला झुकना?
बीप बीप

1
@Tom Ritter हालांकि प्रदर्शन एक चिंता का विषय है (मार्क ब्रैकेट के उत्तर में इस बिंदु के अनुसार, और # 3) मुझे पता है कि कुछ लोग (मुझे शामिल) संभवतः अधिक CPU / RAM में एक अलग DB सर्वर नहीं मिलने से बचाए गए पैसे डालेंगे / आदि। केवल-और-केवल सर्वर ने इसे बदल दिया। इसलिए इस पर ध्यान दिया जाना चाहिए। अलग स्मृति के लिए, संसाधनों पर उनकी प्रतिस्पर्धा के लिए IIS और SQL को कॉन्फ़िगर किया जा सकता है। व्यक्तिगत रूप से, मेरे लिए "किकर" मार्क का # 1 बिंदु था ... सुरक्षा। मुझे लगता है कि एक सीमित वेबसर्वर के सीमित उपयोग के विचार के लिए एक अलग डीबी सर्वर होगा।
डायलन - INNO सॉफ्टवेयर

@ टॉम, आप हमेशा मेमोरी स्पेस को दो अलग-अलग इकाइयों में विभाजित कर सकते हैं। सर्वर के लिए एक आधा और डेटाबेस के लिए एक आधा।
पचेरियर

15

इस पर टॉम सही है। कुछ अन्य कारण हैं कि यह लागत प्रभावी नहीं है और अतिरिक्त सुरक्षा जोखिम हैं।

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

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

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


2
यदि आप कुछ भी चला रहे हैं, लेकिन SPs तो आपके वेबसर्वर के पास आपके डेटाबेस में डेटा की पूरी पहुंच है
जॉर्ज मौअर

यह कुशल लागत क्यों नहीं है? कृपया निर्दिष्ट करें।
रॉबर्ट जीपसेन

रॉबर्ट I ने उस पर विस्तार किया और मापनीयता और रखरखाव पर कुछ टिप्पणियां जोड़ीं।
21:39 पर द साने

9

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

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


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

बेशक आप डेटाबेस का बैकअप लेते हैं, यह निहित है, जहां मेरी पोस्ट में मैंने अन्यथा सुझाव दिया था।
केव

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

@Earwicker - DB सर्वर पर रहने वाले अन्य सभी डेटाबेस के बारे में क्या? आपके द्वारा खो दिया गया सभी एक डेटाबेस है।
केव

8
डैनियल के अलावा, आप एक बड़ा बिंदु याद कर रहे हैं। यह डेटाबेस बैकअप के बारे में नहीं है, यह समझौता किए गए डेटा के बारे में है। क्या आपके ग्राहक ठीक होंगे कि "एक हैकर ने आपके सभी ग्राहक और बिक्री डेटा चुरा लिए, लेकिन चिंता न करें, मुझे एक बैकअप मिला है।" :)
डायलन - INNO सॉफ्टवेयर

9

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


6

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


6

वाह, कोई भी इस तथ्य को नहीं लाता है कि यदि आप वास्तव में 5k रुपये पर SQL सर्वर खरीदते हैं, तो आप इसे अपने वेब एप्लिकेशन से अधिक के लिए उपयोग करना चाह सकते हैं। यदि आपके एक्सप्रेस का उपयोग करते हैं, तो शायद आपको परवाह नहीं है। मैं देख रहा हूँ कि SQL सर्वर 20 से 30 एप्लिकेशन के लिए डेटाबेस चलाते हैं, इसलिए इसे वेबसर्वर पर रखना स्मार्ट नहीं होगा।

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


5

मैं डैनियल इयरविकर से सहमत हूं - सुरक्षा प्रश्न बहुत त्रुटिपूर्ण है।

यदि आपके पास एक वेबसर्वर के साथ एक एकल बॉक्स सेटअप है और उस पर उस वेबसर्वर के लिए केवल डेटाबेस है, अगर उस वेबसर्वर से समझौता किया जाता है तो आप वेबसर्वर और उस विशिष्ट एप्लिकेशन के लिए केवल डेटाबेस खो देते हैं।

यह वैसा ही है जैसा कि यदि आप वेबसर्वर को 2-सर्वर सेटअप पर खो देते हैं तो क्या होता है। आप वेब सर्वर और उस विशिष्ट एप्लिकेशन के लिए केवल डेटाबेस खो देते हैं।

तर्क यह है कि 'डीबी सर्वर की बाकी अखंडता को बनाए रखा जाता है' जहां आपके पास 2-सर्वर सेटअप अप्रासंगिक है, क्योंकि पहली स्थिति में, हर दूसरे एप्लिकेशन से संबंधित प्रत्येक डेटाबेस डेटाबेस (यदि कोई हो) भी अप्रभावित रहें। - जा रहा है, के रूप में वे कर रहे हैं, कहीं और की मेजबानी की।

इसी तरह, केव द्वारा पूछे गए सवाल 'डीबी सर्वर पर रहने वाले सभी अन्य डेटाबेस के बारे में क्या? तुम सब खो दिया है एक डेटाबेस है। '

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

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


4

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


2

मुझे लगता है कि इसकी दो मशीनों को आमतौर पर अलग-अलग तरीकों से अनुकूलित करने की आवश्यकता होगी। इसके अलावा मेरे पास कोई विचार नहीं है, हम अपने सभी एप्लिकेशन को एक ही मशीन पर सर्वर-डेटाबेस के साथ चलाते हैं - दी गई है कि हम सार्वजनिक सामना नहीं कर रहे हैं - लेकिन हमें कोई समस्या नहीं है।

मैं कल्पना नहीं कर सकता कि बहुत से लोग एक मशीन के बारे में परवाह करते हैं जो दोनों में समझौता किया जा सकता है क्योंकि वेब एप्लिकेशन में आमतौर पर लगभग अप्रतिबंधित पहुंच होती है यदि डेटाबेस के अंदर स्कीमा नहीं तो बहुत कम से कम डेटा।

दूसरे क्या कह सकते हैं में रुचि रखते हैं।


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

2

मैंने उस पॉडकास्ट के बारे में सुना, और यह मनोरंजक था, लेकिन सुरक्षा तर्क से मुझे कोई मतलब नहीं था। यदि आपने सर्वर A से समझौता किया है, और वह सर्वर सर्वर B पर डेटा का उपयोग कर सकता है, तो आप तुरंत सर्वर B के डेटा तक पहुंच बना सकते हैं।


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

2
"बॉक्स ए के पास बॉक्स ए के पास जो भी डेटा या विशेषाधिकार हैं, उन तक आपकी पहुंच है - यही मेरा मतलब है" आपके पास सर्वर बी के डेटा तक तुरंत पहुंच है "। अगर RDBMS बॉक्स A पर था और बॉक्स B नहीं था, तो इससे क्या फर्क पड़ेगा? एनबी। हम मान रहे हैं कि आप बॉक्स ए को पहले ही हैक कर चुके हैं, किसी भी तरह से।
डैनियल इयरविकर

एक दो बॉक्स में, यदि आप कम से कम विशेषाधिकार के सिद्धांत को लागू कर रहे हैं, यदि बॉक्स ए (वेब) से समझौता किया जाता है, तो सबसे बुरा यह होना चाहिए कि आपने बॉक्स बी पर डीबी खो दिया है और नहीं।
केव

1
और एक बॉक्स कॉन्फिगरेशन पर, यदि उस एक बॉक्स से छेड़छाड़ की जाती है, तो आपने उस एक बॉक्स को खो दिया है, जिसमें उस पर DB भी शामिल है। क्या फर्क पड़ता है?
डैनियल इयरविकर

2
अंतर यह है कि एक दो बॉक्स कॉन्फिग पर, यदि वेब सर्वर से छेड़छाड़ की जाती है, तो आपके द्वारा खो दिया गया सभी वेब सर्वर और सबसे खराब DB है। डीबी सर्वर के बाकी अखंडता बनाए रखा है।
केव

2

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

जैसे अगर आपके पास 1 सर्वर है जो वेब और डेटाबेस दोनों में 8 सीपीयू रखता है तो आपको 8 सीपीयू लाइसेंस के लिए भुगतान करना होगा। हालाँकि अगर आपके पास 4 सीपीयू के साथ दो सर्वर हैं और एक सर्वर पर डेटाबेस चलाता है तो आपको केवल 4 सीपीयू लाइसेंस के लिए भुगतान करना होगा


कृपया बताएं कि बचत के लिए यह राशि कैसे है।
जॉन सॉन्डर्स

1
जॉन - वह कह रहा है कि 2 मशीनों के बराबर प्रदर्शन प्राप्त करने के लिए, आपको कोर के # दोगुना करने की आवश्यकता होगी, जो SQL सर्वर लाइसेंसिंग लागत को दोगुना कर देगा। SQL सर्वर के लिए अतिरिक्त $ 10-20k का भुगतान क्यों करें यदि आपको मिलता है तो 2 मशीनों के उपयोग के समान प्रदर्शन है।
बीप बीप

केवल सच है अगर प्रदर्शन / संसाधन उपयोग (जैसे cpu) ऐप सर्वर पर हावी है और db सर्वर द्वारा नहीं। अगर db को 8 cpus की जरूरत है तो यह काम नहीं करेगा।
एंड्रियास डिट्रिच

1

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


-1

तर्क है कि एक वेब सर्वर पर डेटाबेस सर्वर चलाकर एक वास्तविक प्रदर्शन हासिल करना एक त्रुटिपूर्ण तर्क है।

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

सुरक्षा के संबंध में, वेब सर्वर की तुलना में एक अलग बॉक्स पर डेटा सर्वर होने के फायदे हैं। ऐसा सेटअप होना सुरक्षा नहीं है और सभी सुरक्षा को समाप्त करता है, लेकिन यह सही दिशा में एक कदम है।

स्केलेबिलिटी के संबंध में, वेब सर्वर को जोड़ना और उन्हें बढ़ाकर यातायात को संभालने के लिए क्लस्टर में डालना आसान और अपेक्षाकृत सस्ता है। डेटा सर्वर को जोड़ना और उन्हें क्लस्टर करना इतना आसान और सस्ता नहीं है। इसके अलावा, वेब सर्वर और डेटा सर्वर की हार्डवेयर ज़रूरतें अलग-अलग होती हैं, इसलिए कई बॉक्स स्केलेबिलिटी के साथ मदद करते हैं।

यदि आप छोटी शुरुआत कर रहे हैं और केवल एक बॉक्स है, तो एक अच्छा तरीका यह होगा कि आप वर्चुअल मशीनों का उपयोग करें। एक होस्ट पर विभिन्न वीएम में वेब सर्वर और डेटा सर्वर चलाने से आपको एक बड़े बॉक्स की कीमत पर अलग-अलग बॉक्स के सभी लाभ मिलते हैं।


1
मूल सवाल आवेदन सर्वरों के बारे में पूछा गया था, जरूरी नहीं कि सार्वजनिक इंटरनेट का सामना वेब सर्वरों से हो।
जोओ ब्रागनका

-2

ऑपरेटिंग सिस्टम एक और विचार है। जबकि आपके डेटाबेस को बड़े मेमोरी स्पेस की आवश्यकता हो सकती है और इसलिए UNIX, आपका वेब सर्वर - या अधिक विशेष रूप से आपका ऐप सर्वर जब से आप केवल दो स्तरों का उल्लेख करते हैं - एक .Net- आधारित हो सकता है, और इसलिए Windows की आवश्यकता होती है।


मैंने इसे वोट नहीं किया, लेकिन "जबकि आपके डेटाबेस को बड़े मेमोरी स्पेस की आवश्यकता हो सकती है और इसलिए UNIX" - यदि आप 64 बिट विंडो चला रहे हैं और 64 बिट एसक्यूएल के साथ खेलने के लिए बहुत मेमोरी है।
केव

क्षमा करें, मेमोरी को विभाजित ओएस की तैनाती के लिए एक उदाहरण कारण के रूप में माना गया था। अन्य कारणों में शामिल हैं: प्रदर्शन, सुरक्षा, कॉर्पोरेट मानक / लाइसेंसिंग, विक्रेता समर्थन, आदि
क्रिस नू

-6

ठीक! यहाँ बात है, आपके DB सर्वर को किसी अन्य मशीन पर स्थापित करने और वेब सर्वर पर आपके अनुप्रयोग के लिए अधिक सुरक्षित है। फिर आप अपने आवेदन को वेब लिंक के साथ डीबी से जोड़ते हैं। इसका आभार।


3
यह अधिक सुरक्षित क्यों है?
ब्रायन चेन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.