Colossus (या GFS2) Google की एक स्वामित्व वाली
वितरित फ़ाइल प्रणाली है, जिसे 2009 में उत्पादन सर्वर पर लॉन्च किया गया था। कोलोसस जीएफएस का एक विकासवादी विकास है। अपने पूर्ववर्ती, जीएफएस की तरह, कोलोसस
बड़े डेटा सेट , स्केल के साथ पूरी तरह से काम करने के लिए अनुकूलित है, एक अत्यधिक सुलभ और दोष-सहिष्णु प्रणाली है, और आपको डेटा को विश्वसनीय रूप से संग्रहीत करने की भी अनुमति देता है।
उसी समय, कोलोसस कुछ ऐसी समस्याओं का हल करता है जो जीएफएस के साथ सामना नहीं कर सका, और अपने पूर्ववर्ती की कुछ बाधाओं को दूर करता है।
आपको GFS2 की आवश्यकता क्यों थी? जीएफएस की सीमाएं
GFS +
Google MapReduce बंडल की मूलभूत सीमाओं में से एक, साथ ही अनुरूप
HDFS +
Hadoop MapReduce (क्लासिक) बंडल (
YARN से पहले), इसका ध्यान पूरी तरह से
बैच प्रसंस्करण पर था। जबकि अधिक से अधिक Google सेवाओं - सामाजिक सेवाओं, क्लाउड स्टोरेज, मैप सेवाओं - को बैच प्रसंस्करण के उन विशिष्टों की तुलना में काफी कम देरी की आवश्यकता होती है।
इस प्रकार, Google को कुछ प्रकार के अनुरोधों के लिए
निकट-वास्तविक समय प्रतिक्रियाओं का समर्थन करने की आवश्यकता है।
इसके अलावा, जीएफएस में, चंक का आकार 64 एमबी है (हालांकि चंक आकार कॉन्फ़िगर करने योग्य है), जो सामान्य रूप से जीमेल, Google डॉक्स, Google क्लाउड स्टोरेज सेवाओं के लिए उपयुक्त नहीं है - चंक के लिए आवंटित अधिकांश स्थान अति
व्यस्त है ।
चंक के आकार को कम करने से स्वचालित रूप
से मेटाडेटा तालिका में
वृद्धि होगी जिसमें फ़ाइल-टू-चंक मैपिंग संग्रहीत है। और चूंकि:
- पहुंच, प्रासंगिकता समर्थन और मेटाडेटा प्रतिकृति मास्टर सर्वर की जिम्मेदारी है;
- जीएफएस में, एचडीएफएस की तरह, मेटाडेटा पूरी तरह से सर्वर की रैम में लोड होता है,
यह स्पष्ट है कि
जीएफएस क्लस्टर के प्रति एक मास्टर एक वितरित फ़ाइल सिस्टम में बड़ी संख्या में चंक के साथ एक
संभावित अड़चन है।
इसके अलावा, आधुनिक सेवाओं को भौगोलिक रूप से वितरित किया जाता है। भू-वितरण आपको बल के दौरान सेवा के लिए उपलब्ध रहने की अनुमति देता है, और अनुरोध करने वाले उपयोगकर्ता को सामग्री का वितरण समय कम कर देता है। लेकिन जीएफएस वास्तुकला, [1] में वर्णित, एक क्लासिक "मास्टर-स्लेव" वास्तुकला के रूप में, भौगोलिक वितरण (कम से कम महत्वपूर्ण लागतों के बिना) के कार्यान्वयन का अर्थ नहीं है।
आर्किटेक्चर
(अस्वीकरण: मुझे एक भी विश्वसनीय स्रोत नहीं मिला है जो पूरी तरह से कोलोसस वास्तुकला का वर्णन करता है, इसलिए वास्तुकला विवरण में अंतराल और धारणाएं दोनों हैं।)
ऊपर वर्णित जीएफएस समस्याओं को हल करने के लिए कोलोसस को डिजाइन किया गया था। तो
चंक का आकार 1 एमबी तक
कम हो गया (डिफ़ॉल्ट रूप से), हालांकि यह विन्यास योग्य रहा। मेटाडेटा तालिका को बनाए रखने के लिए आवश्यक RAM की मात्रा के लिए मास्टर सर्वरों की बढ़ती आवश्यकताओं को नए
"मल्टी सेल" -ऑर्डिनेटेड कोलोसस
आर्किटेक्चर द्वारा पूरा किया गया था।
तो कोलोसस में तार्किक
सर्वर में विभाजित
मास्टर सर्वर का एक
पूल और चंक सर्वरों का एक
पूल है । चंक सर्वरों की कोशिकाओं के लिए मास्टर सर्वर सेल (सेल में 8 मास्टर सर्वर तक) का अनुपात कई में से एक है, अर्थात, मास्टर सर्वर का एक सेल चंक सर्वरों की एक या अधिक कोशिकाओं की सेवा करता है।
डेटा सेंटर के अंदर, समूह, मास्टर सर्वर सेल और इसके द्वारा नियंत्रित चंक सर्वर सेल, कुछ
स्वायत्त फाइल सिस्टम (इस प्रकार के अन्य समूहों से स्वतंत्र) बनाते हैं (बाद में इसे एससीआई,
स्टैंड-अलोन कॉलोसस इंस्टेंस के रूप में संदर्भित किया जाता है)। ऐसे SCI कई Google डेटा केंद्रों में स्थित हैं और एक विशेष रूप से डिज़ाइन किए गए प्रोटोकॉल के माध्यम से एक-दूसरे के साथ बातचीत करते हैं।
क्योंकि चूंकि खुली पहुंच में Google इंजीनियरों द्वारा वर्णित कोई विस्तृत कोलोसस आंतरिक उपकरण नहीं है, इसलिए यह स्पष्ट नहीं है कि एससीआई और मास्टर सर्वर सेल के अंदर दोनों के बीच
संघर्ष की समस्या को कैसे हल
किया जाए ।
साथियों के बीच संघर्ष को हल करने के पारंपरिक तरीकों में
से एक सर्वरों का
कोरम है । लेकिन अगर कोरम में प्रतिभागियों की संख्या समान है, तो जब कोरम कुछ भी नहीं आता है तो परिस्थितियों को बाहर नहीं किया जाता है - आधा "के लिए", आधा "खिलाफ"। और चूंकि कॉलोसस के बारे में जानकारी बहुत बार लगती है कि मास्टर सर्वर सेल में 8 नोड तक हो सकते हैं, एक कोरम की मदद से संघर्षों के समाधान को प्रश्न में कहा जाता है।
यह भी पूरी तरह से स्पष्ट नहीं है
कि कैसे एक एससीआई जानता है कि एक और एससीआई किस डेटा पर काम करता है । यदि हम मानते हैं कि एससीआई के पास ऐसे शीर्षक नहीं हैं, तो इसका मतलब है कि इस ज्ञान के अधिकारी होने चाहिए:
- या तो ग्राहक (जो भी कम संभावना है);
- या तो (सशर्त रूप से) सुपरमास्टर (जो, फिर से, विफलता का एक बिंदु है);
- या यह जानकारी (अनिवार्य रूप से एक महत्वपूर्ण स्थिति ) सभी एससीआई द्वारा साझा किए गए भंडारण में स्थित होनी चाहिए। यहां, उम्मीद के मुताबिक, ताले, लेनदेन, प्रतिकृति की समस्याएं हैं। बाद में सफलतापूर्वक PaxosDB, या एक रिपॉजिटरी द्वारा नियंत्रित किया जाता है जो Paxos एल्गोरिथ्म (या समान) को लागू करता है।
कुल मिलाकर, कुलुस्स के रूप में जियो-वितरित फ़ाइल सिस्टम बनाने के लिए एक "स्पष्ट वास्तुकला" की तुलना में "ब्लैक बॉक्स" होने की अधिक संभावना है जो डेटा के पेटाबाइट्स पर काम करते हैं।
निष्कर्ष
जैसा कि आप देख सकते हैं, कोलोसस में परिवर्तन पूर्ववर्ती फ़ाइल सिस्टम (जीएफएस) के लगभग सभी तत्वों को प्रभावित करता है - चंक से क्लस्टर रचना तक; उसी समय, GFS में सन्निहित विचारों और अवधारणाओं की निरंतरता संरक्षित है।Colossus के सबसे तारकीय ग्राहकों में से एक कैफीन, Google का नवीनतम खोज इंजन अवसंरचना है।
स्रोतों की सूची *
[१] संजय गेमावत, हॉवर्ड गोबीऑफ, शुन-टेक लेउंग। Google फ़ाइल सिस्टम। ACM SIGOPS ऑपरेटिंग सिस्टम की समीक्षा, 2003।
[१०] एंड्रयू फिकस। भंडारण वास्तुकला और चुनौतियां। Google संकाय शिखर सम्मेलन, 2010।
* चक्र तैयार करने के लिए उपयोग किए जाने वाले
स्रोतों की एक पूरी सूची ।
दिमित्री पेटुखोव,
एमसीपी,
पीएचडी छात्र , आईटी लाश,
लाल रक्त कोशिकाओं के बजाय कैफीन के साथ एक व्यक्ति।