पुस्तक “साइट विश्वसनीयता इंजीनियरिंग। Google में विश्वसनीयता और विश्वसनीयता »

लगभग 20 वर्षों से, Google अकल्पनीय रूप से जटिल और बड़े पैमाने पर सिस्टम प्रदान कर रहा है जो उपयोगकर्ता के अनुरोधों के प्रति संवेदनशील हैं। Google खोज इंजन किसी विभाजन के दूसरे प्रश्न का उत्तर पाता है, उच्चतम सटीकता वाले Google मानचित्र स्थलीय परिदृश्य को दर्शाते हैं, और Google मेल 365/24/7 मोड में उपलब्ध है और, संक्षेप में, पहला सार्वजनिक क्लाउड स्टोरेज बन गया है। क्या ये सिस्टम निर्दोष हैं? नहीं, वे भी विफल हो जाते हैं, टूट जाते हैं और अप्रचलित हो जाते हैं, किसी भी उपकरण की तरह। हम इसे नोटिस नहीं करते हैं। बात यह है कि दस वर्षों से अधिक समय से, Google अद्वितीय साइट विश्वसनीयता इंजीनियरिंग तकनीक विकसित कर रहा है, जो किसी भी जटिलता के सॉफ्टवेयर सिस्टम के निर्बाध संचालन और प्रगतिशील विकास को सुनिश्चित करता है। यह पुस्तक कई वर्षों में Google द्वारा संचित अनुभव का भंडार है, कई उत्कृष्ट विशेषज्ञों का सामूहिक कार्य और किसी भी इंजीनियर के लिए एक अपरिहार्य संसाधन जो उच्चतम गुणवत्ता और सबसे कुशलता के साथ किसी भी उत्पाद को विकसित और बनाए रखना चाहता है।

SRE के संदर्भ में Google का SRE

Google डेटा सेंटर (डेटा सेंटर) पारंपरिक डेटा सेंटर और छोटे सर्वर "फार्म" से काफी अलग हैं। ये अंतर अतिरिक्त समस्याओं और अतिरिक्त अवसरों दोनों का परिचय देते हैं। यह अध्याय Google डेटा केंद्रों के लिए विशिष्ट चुनौतियों और अवसरों पर चर्चा करता है और पूरी पुस्तक में उपयोग की जाने वाली शब्दावली का परिचय देता है।

उपकरण

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

• मशीन (कंप्यूटर) - उपकरणों की एक इकाई (या, संभवतः, एक आभासी मशीन);
• सर्वर - सॉफ्टवेयर की एक इकाई जो एक सेवा को लागू करती है।

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

हम समझते हैं कि "सर्वर" शब्द का ऐसा उपयोग गैर-मानक है। यह एक बार में दो अवधारणाओं को नामित करने के लिए अधिक प्रथागत है: एक प्रोग्राम जो नेटवर्क कनेक्शन प्रदान करता है, और एक ही समय में एक मशीन जो इस तरह के कार्यक्रम चलाता है, लेकिन जब हम Google की कंप्यूटिंग शक्ति के बारे में बात करते हैं, तो दोनों के बीच का अंतर महत्वपूर्ण है। जैसे ही आप शब्द "सर्वर" की हमारी व्याख्या के लिए अभ्यस्त हो जाते हैं, यह आपके लिए स्पष्ट हो जाएगा कि केवल Google पर ही नहीं, बल्कि इस पूरी पुस्तक में ऐसी विशिष्ट शब्दावली का उपयोग करना क्यों महत्वपूर्ण है।

अंजीर में। 2.1 ने Google डेटा सेंटर के कॉन्फ़िगरेशन का प्रदर्शन किया।

• दर्जनों कारों को रैक पर रखा गया है।
• रैक पंक्तियों में खड़े हैं।
• एक या अधिक पंक्तियाँ एक क्लस्टर बनाती हैं।
• आमतौर पर डेटा सेंटर (DPC), या डेटा सेंटर की बिल्डिंग में, कई क्लस्टर स्थित होते हैं।
• कई डेटा सेंटर इमारतें जो एक-दूसरे के करीब हैं कैंपस बनाती हैं।

प्रत्येक डेटा सेंटर के अंदर, सभी मशीनें एक-दूसरे के साथ प्रभावी ढंग से संवाद करने में सक्षम होनी चाहिए, इसलिए हमने हजारों बंदरगाहों के साथ बहुत तेज़ वर्चुअल स्विच (स्विच) बनाया। यह Google द्वारा विकसित किए गए सैकड़ों स्विचों को क्लॉस नेटवर्क [क्लोस, 1953], जो कि बृहस्पति [सिंह एट अल।, 2015] कहा जाता है, के आधार पर कनेक्ट करके संभव था। अपने अधिकतम विन्यास में, बृहस्पति सर्वरों के बीच 1.3 Pb / s थ्रूपुट का समर्थन करता है।

हमारे वैश्विक बी 4 बैकबोन नेटवर्क [जैन एट अल।, 2013] का उपयोग करके डेटा सेंटर एक दूसरे से जुड़े हुए हैं। बी 4 में एक सॉफ्टवेयर-विन्यास नेटवर्क वास्तुकला है और ओपनफ्लो ओपन संचार प्रोटोकॉल का उपयोग करता है। बी 4 सिस्टम की सीमित संख्या के लिए व्यापक बैंडविड्थ प्रदान करता है और अपने औसत मूल्य को अधिकतम करने के लिए लचीला चैनल चौड़ाई नियंत्रण का उपयोग करता है [कुमार एट अल।, 2015]।

सिस्टम सॉफ्टवेयर जो "उपकरण" को व्यवस्थित करता है

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

मशीन प्रबंधन

बोर्ग (चित्र 2.2) एक वितरित क्लस्टर प्रबंधन प्रणाली [वर्मा एट अल।, 2015], अपाचे मेसो के समान है। बोर्ग क्लस्टर स्तर की नौकरियों का प्रबंधन करता है।
बोर्ग उपयोगकर्ता नौकरियों को लॉन्च करने के लिए जिम्मेदार है। ये कार्य या तो लगातार चल रही सेवाएं या बैच प्रक्रियाएं हो सकती हैं, जैसे MapReduce [Dean और Ghemawat, 2004]। वे समान कार्यों (कार्यों) के कई (कभी-कभी हजारों) से मिलकर बना सकते हैं - दोनों विश्वसनीयता कारणों से, और क्योंकि एक नियम के रूप में, सभी क्लस्टर ट्रैफ़िक को संसाधित करने में सक्षम नहीं है। जब बोर्ग कार्य शुरू करता है, तो वह अपने कार्यों को करने के लिए मशीनों को ढूंढता है और सर्वर प्रोग्राम शुरू करने के लिए उन्हें आदेश देता है। बोर्ग इसके बाद इन कार्यों की स्थिति पर नज़र रखता है। यदि कार्य सही ढंग से काम नहीं करता है, तो यह नष्ट हो जाता है और पुनरारंभ होता है, संभवतः किसी अन्य मशीन पर।

चूंकि कार्यों को मशीनों के बीच स्वतंत्र रूप से वितरित किया जाता है, इसलिए हम उन तक पहुंचने के लिए आईपी पते और पोर्ट नंबर का उपयोग नहीं कर सकते हैं। यह समस्या एब्सट्रैक्शन के एक अतिरिक्त स्तर से हल होती है: एक कार्य शुरू करते समय, बोर्ग कार्य के लिए एक नाम और प्रत्येक कार्य के लिए एक संख्या (सूचकांक) आवंटित करता है, जो बोर्ग नामकरण सेवा (बीएनएस) का उपयोग करता है। IP पते और पोर्ट नंबर का उपयोग करने के बजाय, अन्य प्रक्रियाएँ Borg कार्यों को उनके BNS नाम से जोड़ देती हैं, जो बाद में BNS को IP पते और पोर्ट नंबर में परिवर्तित कर देता है। उदाहरण के लिए, BNS पथ एक स्ट्रिंग हो सकता है जैसे / bns / <क्लस्टर> / <user> / <task_name> / <task_number>, जो तब अनुवादित होता है (यह नेटवर्क पर "अनुमति दी" कहने के लिए प्रथागत है) <IP पता>: <port> ।

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

यदि कोई कार्य अनुरोध किए जाने से अधिक संसाधनों को हथियाने की कोशिश करता है, तो बोर्ग इसे नष्ट कर देता है और फिर से पुनरारंभ होता है (क्योंकि आमतौर पर यह कार्य करना बेहतर होता है कि कभी-कभी दुर्घटनाग्रस्त हो जाता है और इससे पुनरारंभ होता है जो बिल्कुल भी पुनरारंभ नहीं होता है)।

कोष

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

स्टोरेज उपयोगकर्ताओं को क्लस्टर में आसानी से और आसानी से उपलब्ध डेटा तक पहुंचने की क्षमता प्रदान करता है। जैसा कि अंजीर में दिखाया गया है। 2.3, रिपॉजिटरी में कई परतें हैं।


1. सबसे निचली परत को डी कहा जाता है (डिस्क से, हालांकि स्तर डी पारंपरिक हार्ड ड्राइव और फ्लैश ड्राइव दोनों का उपयोग करता है)। D एक फ़ाइल सर्वर है जो वस्तुतः सभी क्लस्टर मशीनों पर चलता है। हालांकि, जो उपयोगकर्ता अपने डेटा को एक्सेस करना चाहते हैं, वे यह याद नहीं रखना चाहेंगे कि वे किस मशीन पर संग्रहीत हैं, इसलिए अगली परत यहां से जुड़ी हुई है।

2. लेयर डी के ऊपर कोलोसस लेयर होती है, जो क्लस्टर में एक फाइल सिस्टम बनाती है जो फाइल सिस्टम के सामान्य शब्दार्थ के साथ-साथ प्रतिकृति और एन्क्रिप्शन की सुविधा प्रदान करती है। Colossus GFS, Google फ़ाइल सिस्टम (Ghemawat et al।, 2003) का उत्तराधिकारी है।

3. इसके बाद, कोलोसस स्तर के ऊपर कई डेटाबेस जैसी सेवाएं निर्मित हैं।

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

नेटवर्क

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

नेटवर्क बैंडविड्थ को ठीक से आवंटित किया जाना चाहिए। के रूप में Borg एक संसाधन का उपयोग कर सकते हैं कंप्यूटिंग संसाधनों को सीमित करता है, इसलिए बैंडविड्थ इनफोर्सेर (BwE) औसत विवाद को अधिकतम करने के लिए उपलब्ध बैंडविड्थ का प्रबंधन करता है। बैंडविड्थ अनुकूलन न केवल लागत से संबंधित है: केंद्रीकृत यातायात प्रबंधन कई समस्याओं को हल करता है जो वितरित रूटिंग और पारंपरिक यातायात प्रबंधन (कुमार, 2015) के संयोजन से हल करना बहुत मुश्किल है।

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

• DNS प्रश्नों के लिए भौगोलिक भार संतुलन (उदाहरण के लिए, www.google.com ), यह अध्याय 19 में वर्णित है;
• उपयोगकर्ता सेवाओं के स्तर पर लोड संतुलन (उदाहरण के लिए, YouTube या Google मानचित्र);
• अध्याय 20 में वर्णित दूरस्थ प्रक्रिया कॉल (RPC) स्तर पर लोड संतुलन।

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

अन्य सिस्टम सॉफ्टवेयर

डेटा सेंटर सॉफ्टवेयर के अन्य महत्वपूर्ण घटक हैं।

ताला सेवा

गलफुला लॉक सेवा [बुरुज़, 2006] ताले की सेवा के लिए फ़ाइल सिस्टम के समान एक एपीआई प्रदान करता है। गलफुला सभी डेटा केंद्रों पर ताले लगाता है। यह Paxos प्रोटोकॉल का उपयोग सर्वसम्मति से सर्वसम्मति से एक्सेस करने के लिए करता है (अध्याय 23 देखें)।

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

निगरानी और चेतावनी

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

• तत्काल समस्याओं के लिए अलर्ट स्थापित करना;
• व्यवहार की तुलना: क्या सॉफ्टवेयर अपडेट ने सर्वर को गति दी;
• समय के साथ संसाधन खपत में परिवर्तन की प्रकृति का आकलन, जो क्षमता नियोजन के लिए आवश्यक है।

हमारे सॉफ्टवेयर बुनियादी ढांचे

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

सभी Google सेवाएं स्टुबी नामक रिमोट प्रक्रिया कॉल (RPC) बुनियादी ढांचे का उपयोग करके "संवाद" करती हैं। इसका एक खुला स्रोत संस्करण है, इसे gRPC ( grpc.io देखें) कहा जाता है। अक्सर, स्थानीय कार्यक्रम में दिनचर्या के लिए भी एक आरपीसी कॉल किया जाता है। इससे आप प्रोग्राम को किसी अन्य सर्वर की कॉल को अधिक से अधिक मॉड्युलैरिटी प्राप्त करने के लिए या मूल सर्वर कोड के बढ़ने की अनुमति दे सकते हैं। जीएसएलबी आरपीसी लोड बैलेंसिंग को उसी तरह से कर सकता है जैसे बाहरी सर्विस इंटरफेस के लिए।

सर्वर फ्रंट छोर से RPC अनुरोध प्राप्त करता है और बैक को RPC भेजता है। पारंपरिक शब्दों का उपयोग करते हुए, दृश्यपटल को क्लाइंट कहा जाता है, और बैकएंड को सर्वर कहा जाता है।
धारावाहिक प्रोटोकॉल का उपयोग करके डेटा को RPC से स्थानांतरित किया जाता है - तथाकथित प्रोटोकॉल बफ़र, या, संक्षेप में, प्रोटोबॉफ़। यह प्रोटोकॉल अपाचे के थ्रिफ्ट के समान है और इसमें संरचित डेटा को क्रमबद्ध करने पर एक्सएमएल के कई फायदे हैं: यह सरल, तीन से दस गुना अधिक कॉम्पैक्ट, 20 से 100 गुना तेज और अधिक अद्वितीय है।

हमारे विकास का वातावरण

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

कुछ समूहों के अपवाद के साथ जिनके उत्पाद खुले स्रोत हैं, और इसलिए वे अपने स्वयं के अलग-अलग रिपॉजिटरी (उदाहरण के लिए, एंड्रॉइड और क्रोम) का उपयोग करते हैं, Google सॉफ़्टवेयर इंजीनियर एक आम रिपॉजिटरी [पोट्विन, लेवेनबर्ग, 2016] में काम करते हैं। इस दृष्टिकोण में कई व्यावहारिक अनुप्रयोग हैं जो हमारी उत्पादन प्रक्रिया के लिए महत्वपूर्ण हैं।

• यदि एक इंजीनियर अपने प्रोजेक्ट के बाहर एक घटक में समस्या का सामना करता है, तो वह समस्या को ठीक कर सकता है, प्रस्तावित परिवर्तनों ("चेंजलॉजिस्ट" - चेंजेलिस्ट, सीएल) को विचार के लिए मालिक को भेज सकता है और फिर कार्यक्रम की मुख्य शाखा में किए गए परिवर्तनों को लागू कर सकता है।
• एक इंजीनियर की खुद की परियोजना में स्रोत कोड में परिवर्तन पर विचार - एक ऑडिट (समीक्षा) आयोजित करने की आवश्यकता है। गोद लेने से पहले सभी सॉफ्टवेयर इस चरण को पार कर जाते हैं।

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

शेक्सपियर: सेवा उदाहरण

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

हम सिस्टम को दो भागों में विभाजित कर सकते हैं।

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

बैच प्रोसेसिंग कंपोनेंट MapReduce सेवा होगी, जिसका काम तीन चरणों में विभाजित है।

1. मैपिंग चरण में, शेक्सपियर के ग्रंथों को अलग-अलग शब्दों में पढ़ा और तोड़ा जाता है। यदि समानांतर में कई कार्य प्रक्रियाएं (कार्य) शुरू की जाती हैं, तो काम का यह हिस्सा तेजी से पूरा हो जाएगा।

2. शफल चरण में, प्रविष्टियों को शब्द द्वारा क्रमबद्ध किया जाता है।

3. कम चरण में, प्रपत्र (शब्द, list_products) के tuples बनाए जाते हैं।

प्रत्येक टुप्ले को बिगटेबल में एक स्ट्रिंग के रूप में लिखा गया है, कुंजी शब्द है।

जीवन चक्र का अनुरोध करें

अंजीर में। 2.4 दिखाता है कि उपयोगकर्ता अनुरोध कैसे परोसा जाता है। सबसे पहले, उपयोगकर्ता ब्राउज़र में shakespeare.google.com लिंक पर क्लिक करता है। उपयुक्त IP पता प्राप्त करने के लिए, उपयोगकर्ता का डिवाइस DNS सर्वर (1) का उपयोग करके पते का अनुवाद ("हल करता है") करता है। DNS क्वेरी अंततः Google DNS सर्वर पर समाप्त होती है, जो GSLB के साथ सहभागिता करती है। क्षेत्र के सभी फ्रंट-एंड सर्वर के ट्रैफ़िक लोड को ट्रैक करते हुए, जीएसएलबी यह चुनता है कि किस सर्वर का आईपी पता उपयोगकर्ता को वापस लौटना है।

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

शेक्सपियर सर्वर HTTP अनुरोध को पार्स करता है और "प्रोटोकॉल बफर" (प्रोटोबुफ़) बनाता है जिसमें पाए जाने वाले शब्द होते हैं। अब, शेक्सपियर फ्रंट-एंड सर्वर को शेक्सपियर बैक-एंड सर्वर से संपर्क करना चाहिए: दूसरे (4) के उपयुक्त और अनलोड उदाहरण के बीएनएस पते को प्राप्त करने के लिए पहले जीएसएलबी से संपर्क करें। इसके बाद, शेक्सपियर बैकेंड सर्वर अनुरोधित डेटा (5) प्राप्त करने के लिए बिगटेबल सर्वर से संपर्क करता है।

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


घटनाओं की यह पूरी श्रृंखला एक आँख की झपकी में चलती है - केवल कुछ सौ मिलीसेकंड में! चूंकि कई घटक शामिल हैं, ऐसे कई स्थान हैं जहां एक संभावित त्रुटि हो सकती है; विशेष रूप से, जीएसएलबी में एक विफलता सभी काम को अव्यवस्थित कर सकती है और पतन की ओर ले जा सकती है। Google, , ( ), , . , www.google.com , .

, - 100 (QPS). , 3470 QPS, 35 . , 37 , N + 2.

• , 36 .
• , - 35 — , .

: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .

- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .

, . , , .

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

Habrozavitel के लिए 20% का कूपन - साइट विश्वसनीयता इंजीनियरिंग