बेहतर स्पेसिफिकेशन्स के साथ बड़ी साइट्स एक सर्वर के बजाय मल्टीपल सर्वर का उपयोग क्यों करती हैं?


42

मैंने पढ़ा है कि स्टैक ओवरफ्लो साइट को परोसने के लिए 10 या अधिक सर्वरों का उपयोग करता है। अलग-अलग सर्वर के अलग-अलग कार्य होते हैं जैसे रिवर्स प्रॉक्सी, डेटाबेस सर्वर या एचटीटीपी सर्वर।

मैंने इन विशिष्टताओं के साथ एक शक्तिशाली स्टैंडअलोन एकल सर्वर देखा है:

  • 2 x Xeon E5-2630v2 @ 2.60 GHz, कुल 12 कोर, 24 धागे; 30 एमबी
  • 64 जीबी ईसीसी रजि। 1600 मेगाहर्ट्ज पर 768 जीबी डीडीआर 3 तक
  • 4 x 120 GB Intel 520/530 श्रृंखला (80k यादृच्छिक IOPS, ~ 550 MB / s)
  • HP iLo4 समर्पित ईथरनेट प्रबंधन पोर्ट के साथ उन्नत है।

768 जीबी रैम, 20 टीबी + एचडीडी, 4+ एक्स एक्सॉन जैसे उच्च विनिर्देशों वाले एकल सर्वर का उपयोग क्यों नहीं किया जाता है? किसी एकल उच्च-विनिर्देश सर्वर का उपयोग करने के कई सर्वरों या कमियों का उपयोग करने के क्या लाभ हैं?


4
एसई के पास न केवल 10+ सर्वर हैं, उनके पास फेलओवर के लिए एक और डेटासेटर में एक डुप्लिकेट सेटअप है। और, सर्वर का आविष्कार अभी तक नहीं किया गया है जो फेसबुक या Google के सभी ट्रैफ़िक को संभाल सके।
माइकल हैम्पटन

8
क्या होता है जब आपको उस सुपर सर्वर को रिबूट करने की आवश्यकता होती है?
Liath

अतिरेक ... :)
विलियम एडवर्ड्स


1
@ प्रेस: ​​आप प्रति पोर्ट एक कनेक्शन तक सीमित नहीं हैं। यह सब मायने रखता है कि (src address, src port, dst address, dst port) का संयोजन अद्वितीय है।
डेविड

जवाबों:


58

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

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

अपटाइम और विश्वसनीयता भी खेल में आते हैं। दो या अधिक सर्वरों के साथ, कोई भी अनुरक्षण के लिए असफल हो सकता है या ऑफ-लाइन लिया जा सकता है और साइट ऊपर रह सकती है। आप एक सर्वर के साथ ऐसा नहीं कर सकते।

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

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

किसी एकल सर्वर को अपग्रेड करना लंबवत रूप से स्केलिंग के रूप में जाना जाता है । अधिक सर्वर जोड़ना क्षैतिज रूप से स्केलिंग के रूप में जाना जाता है । इस विषय पर अधिक जानकारी के लिए, यहां कुछ लेख दिए गए हैं जो दोनों की तुलना करते हैं:


9
यदि आपके पास कई सर्वर हैं (कुछ से अधिक), और कुछ सीपीयू मर जाते हैं, तो आपके पास सब कुछ चालू रखने के लिए अन्य सर्वर हैं। यदि आपके पास 1 सर्वर है, और जो टूट गया है, तो आप कर रहे हैं।
मार्टिज़न

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

@closetnoc मुझे लगता है कि इसका वर्णन करने का सबसे अच्छा तरीका यह है कि आप बाधाओं से बचने की कोशिश कर रहे हैं। एक ठीक से संतुलित प्रणाली बिना किसी दुष्परिणाम के 100% क्षमता पर सैद्धांतिक रूप से चल सकती है, लेकिन कुछ भी जो सिस्टम को प्रतीक्षा करना है (CPU समय, I / O, बस स्थानांतरण, आदि ...) प्रदर्शन समस्याओं का कारण होगा। आधी अधिकतम क्षमता पर अपने सिस्टम को चलाकर, आपने एक अच्छा स्थान पाया है जहाँ आप इस तरह की अड़चनों में नहीं पड़ते।
१ .

@ Thebluefish हाँ और नहीं। मैं एक पुराना सिस्टम इंटर्नल आदमी हूँ। अधिकांश प्रणालियों में ओएस और आंतरिक हार्डवेयर के भीतर अड़चनें होती हैं, जिन्हें तेज छापे, मेमोरी, सीपीयू आदि के साथ नहीं बनाया जा सकता है। साथ ही, ओएस के भीतर सीमाएं हैं। विंडोज बहुत अच्छा था क्योंकि यह वीएमएस पर आधारित था, लेकिन अभी भी सीमाएं थीं जो वीएमएस की तरह ट्यून नहीं की जा सकती थीं। लिनक्स स्पष्ट रूप से बेहतर है। कुछ सर्वरों को बहुत कम हार्डवेयर सीमाओं के साथ डिज़ाइन किया जाता है जैसे कि एचपी जो हमने उपयोग किया है। लेकिन फिर भी, इंटरप्ट और सीपीयू स्वैप में वृद्धि के कारण यह 100% क्षमता पर एक संगणना कतार चलाने के लिए एक अच्छा विचार नहीं है।
क्लोसेटनोक

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

32

रियर एडमिरल ग्रेस हॉपर से:

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

स्रोत


1
मैं अपने शुरुआती करियर में कुछ समय ग्रेस हॉपर से मिला और उसके साथ कुछ समय बिताया। वह वास्तव में कुछ था! एक शांत बिल्ली! हम सब उससे प्यार करते थे। वह अपने समय और शोहरत के लिए इतनी दयालु और उदार थी। उसे उद्धृत करने के लिए यश! एक तरह से वोट-बैक के लिए। धन्यवाद!
क्लोसेट्नोक

5
हालांकि यह एक प्रासंगिक उद्धरण है, यह प्रश्न का उत्तर नहीं देता है। एक व्यक्ति की बेबाक राय यहाँ मूल्यवान नहीं होनी चाहिए।
टैंकरस्मैश

7
@NoahSpurrier क्योंकि यह वास्तव में सवाल के किसी भी हिस्से का जवाब नहीं देता है? यह सिर्फ एक उद्धरण है जो एक असम्बद्ध सादृश्य बनाता है और यह नहीं समझाता है कि हमें अधिक सर्वर के लिए क्यों शूट करना चाहिए।
क्रिस हेस

2
मैं कहूंगा कि यह एक उपयोगी उत्तर है, लेकिन इसे स्वीकार नहीं किया जाना चाहिए क्योंकि यह विशिष्ट कारणों का विवरण नहीं देता है। हालांकि, यह स्पष्ट रूप से लोड बंटवारे के मूल के लिए अधिक से अधिक arching कारण बताता है।
इयान टी। स्मॉल

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

10

स्टीफन ने सिस्टम आर्किटेक्चर पर निर्णय लेते समय मुख्य विचार की व्याख्या की: ऊर्ध्वाधर और क्षैतिज स्केलिंग में ट्रेडऑफ। मैं कुछ अन्य विचार जोड़ूंगा:

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

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

दिलचस्प रूप से पेपाल और वीज़ा जैसी कंपनियाँ हजारों क्षैतिज प्रणालियों के क्लस्टर्ड सिस्टम की ओर मेनफ्रेम से दूर जा रही हैं। तेजी से विकसित हो रही डिजिटल दुनिया में भी मेनफ्रेम क्षैतिज स्केलिंग सीलिंग को मार रहे हैं:

“सभी उपलब्धता और प्रदर्शन आवश्यकताओं के साथ, हम मेनफ्रेम पर प्रोसेसिंग भुगतान नहीं रख सकते हैं।

स्रोत: एडम बैंक्स, ComputerWorldUK में


8
  • आकार की सीमा। हम दिखावा करना पसंद करते हैं कि कई प्रोसेसर, मेमोरी चिप्स और डिस्क के साथ एक एकल बॉक्स एक समान है। यह पूरी तरह से सच नहीं है, लेकिन अगर आपके नंबर बहुत बड़े नहीं हैं, तो यह काफी सही है। गर्मी, ऊर्जा, निकटता आदि पर तकनीकी सीमाएँ हैं, जिसका अर्थ है कि एक सर्वर कितना बड़ा हो सकता है, इस पर हमेशा व्यावहारिक सीमा रहेगी।

  • स्केलेबिलिटी - आईपीसी के लिए साझा मेमोरी और एक मल्टी सर्वर सिस्टम जो नेटवर्किंग या क्लस्टरिंग का उपयोग करता है, के बीच एक एकल सर्वर प्रणाली के बीच एक बड़ा अंतर है। हालाँकि, दो सर्वरों और 200 के बीच का अंतर काफी छोटा है - यदि आपने एक ऐसी प्रणाली बनाई है, जो आपको मापती है, तो आप समस्या होने से पहले उसे बड़े पैमाने पर माप सकते हैं ... और यदि आपके पास है, तो वास्तव में एक विशाल एकल सर्वर की कोई आवश्यकता नहीं है पहली जगह में।

  • लचीलापन - एक सर्वर एक जगह है जो एक व्यवस्थापक 'उफ़' हो सकता है। या फिर एक शारीरिक समस्या है जिसका मतलब है कि टिन का पूरा टुकड़ा सेवा बाधित है। (डाटाकेंटर पानी का रिसाव, किसी को एक रैक में दुर्घटनाग्रस्त होना और उसे खटखटाना, उस तरह की बात)। एकाधिक सर्वरों को डेटासेंटर के भीतर वितरित किया जा सकता है, या बेहतर भौगोलिक रूप से वितरित किया जा सकता है। और यदि आप पहले से ही अपने ऐप को वितरित कर रहे हैं, तो 'मध्यम' आकार की मशीनों पर स्केलिंग लगभग हमेशा बड़ी संख्या में सीपीयू / मेमोरी / आईओ की तुलना में सस्ती होती है।

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


7

आइए समस्या को छोटे स्तर पर लें। एक सर्वर, मेल, ActiveDirectory, फ़ाइल साझा और कंपनी के लिए वेब साइट पर चलने वाला एक छोटा सा कार्यालय।

हैकर्स ने इसे मारा और आपको रिबूट करना पड़ा क्योंकि IIS गड़बड़ है। या एक्सचेंज को अपडेट और रिबूट की जरूरत है। या सक्रिय निर्देशिका दूषित हो गई।

इनमें से कोई भी अलग-थलग "एक सेवा नीचे है" समस्याएं पूरे सर्वर को प्रभावित करती हैं, इसलिए उस सर्वर पर कुछ भी साझा करने से रिबूट या कुछ और होने के कारण उन्हें प्रभावित किया जा सकता है।

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

यह "एक टोकरी में अपने सभी अंडे न डालें" की पुरानी कहावत है

अब वह दर्शन वेब सर्वर पर लागू होता है। यदि मेरे पास केवल एक ही वेब सर्वर है और मैं अपना वेब ऐप (नया MyFaceLink.com) प्रकाशित करता हूं और यह वास्तव में लोकप्रिय हो जाता है, तो मुझे नई मुसीबतें मिल गई हैं। मैं साइट को रखरखाव करने के लिए नीचे नहीं ले जा सकता, जबकि उपयोगकर्ता उस पर हैं। और अगर यह दुर्घटनाग्रस्त हो जाता है या मुझे बहुत सारे उपयोगकर्ता मिलते हैं, तो मैं चंगा हूँ। यहां तक ​​कि दुनिया का सबसे बड़ा एकल सर्वर 1 अरब FB धर्मान्तरित होने से अभिभूत हो जाएगा।

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

सरलतम में, यह मेगा-सर्वर की कीमत के बारे में नहीं है या क्या यह वास्तव में लोड को संभाल सकता है (हालांकि यह हो सकता है)। यह विफलता के एकल बिंदु के बारे में है। एक बार व्यापार काफी व्यस्त हो जाता है, और 8-5 काम करने वाले 5 उपयोगकर्ताओं के बजाय 24x7 हो रहा है, डाउनटाइम स्वीकार्य नहीं है। शेड्यूल किए गए आउटेज शेड्यूल करने के लिए कठिन हैं। तो, आप लोड फैलाते हैं।


विफलता की समस्या के एकल बिंदु के नामकरण के लिए +1 ।
डेविड कैरी

1

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

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

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