हमने एवरनोट वास्तुकला में शार्क के विन्यास को कैसे और क्यों बदल दिया

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



इन वर्चुअल मशीनों में से प्रत्येक MySQL डेटाबेस में 300- गीगाबाइट चीता ड्राइव की एक RAID-1 एरे पर MySQL डेटाबेस में ट्रांजेक्शनल "मेटाडेटा" को 15,000 आरपीएम की स्पिंडल स्पीड के साथ स्टोर करती है। 3-टेराबाइट नक्षत्र ड्राइव (7200 आरपीएम) का एक अलग RAID-10 सरणी प्रत्येक उपयोगकर्ता के लिए बड़ी ल्यूसिन पाठ खोज सूचकांक फ़ाइलों को संग्रहीत करने के लिए विभाजित किया गया है। जोड़ी गई आभासी मशीनें इनमें से प्रत्येक विभाजन को वर्तमान प्राथमिक से वर्तमान माध्यमिक मशीन तक सिंक्रोनस डीआरबीडी का उपयोग करके डुप्लिकेट करती हैं।

इन शार्क के पास कम से कम 4 साल के लिए 100,000 पंजीकृत एवरनोट उपयोगकर्ताओं के आरामदायक डेटा प्रसंस्करण के लिए पर्याप्त डिस्क स्थान और I / O समर्थन है, और 4U मामलों में अतिरिक्त ड्राइव बे से भी लैस हैं ताकि बाद में यदि आवश्यक हो तो आप उन्हें अपग्रेड कर सकें। दोहरे L5630 प्रोसेसर और 48 गीगाबाइट रैम को देखते हुए, प्रत्येक ऐसी इकाई की लागत लगभग 374 वाट की ऊर्जा खपत के साथ $ 10,000 तक है। यही है, एक पंजीकृत उपयोगकर्ता हार्डवेयर लागतों में लगभग $ 0.10 और ऊर्जा के 3.7 मिलिवाट के लिए खाता है।

सुधार के अवसर

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

1. MySQL डेटाबेस के लिए 15,000 आरपीएम के साथ डिस्क आमतौर पर 95% समय के लिए बेकार हो जाता है क्योंकि InnoDB ने कैशिंग और I / O को क्रमबद्ध करने के साथ बहुत अच्छा काम किया है। हालाँकि, हमने यादृच्छिक अड़चनों की खोज की जब बड़े खातों वाले उपयोगकर्ता एक नए डिवाइस पर प्राथमिक डेटा सिंक्रनाइज़ेशन शुरू करते हैं। यदि उनकी मेटाडेटा पहले से ही रैम बफर में मौजूद नहीं है, तो बड़े पैमाने पर I / O ऑपरेशन बहुत महंगा हो सकता है।
2. हमारे उपयोगकर्ताओं के लिए ल्यूसिन खोज सूचकांक हमारी अपेक्षा से कहीं अधिक I / O उत्पन्न करते हैं। हम देखते हैं कि Lucene MySQL के रूप में कई बार पढ़ने / लिखने के संचालन के लिए खाता है। यह मोटे तौर पर हमारे उपयोग मॉडल के कारण होता है: हर बार जब हम किसी नोट को बनाते या संपादित करते हैं, तो हमें उसके मालिक के सूचकांक को अपडेट करने और डिस्क में परिवर्तन के बारे में जानकारी भेजने की आवश्यकता होती है ताकि वे तुरंत प्रभावी हों।
3. DRBD एक या दो छोटे विभाजनों की नकल करने के लिए महान है, लेकिन जब यह प्रत्येक सर्वर के लिए बड़ी संख्या में महत्वपूर्ण विभाजन की बात करता है तो यह बहुत असुविधाजनक होता है। प्रत्येक अनुभाग को स्वतंत्र रूप से कॉन्फ़िगर, प्रबंधित और मॉनिटर किया जाना चाहिए। विभिन्न समस्याओं को कभी-कभी सभी संसाधनों के पूर्ण सिंक्रनाइज़ेशन की आवश्यकता हो सकती है, जो कि 1 जीबी / एस के बैंडविड्थ के साथ समर्पित क्रॉसओवर केबल होने पर भी कई घंटे लेने की धमकी देता है।

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

नया विन्यास

हमारा नया कॉन्फ़िगरेशन एक दर्जन 4U सर्वर रैक के साथ रैक की जगह लेता है, जहां एक साथ मेटाडेटा और एक एप्लिकेशन के लिए चौदह 1U शार्क और फ़ाइल भंडारण के लिए चार 4U शार्क हैं।



शार्द 1U सरल आभासी मशीनों की एक जोड़ी का प्रबंधन करता है, जिनमें से प्रत्येक 300 जीबी इंटेल एसएसडी के एक अलग RAID-5 सरणी पर एक विभाजन का उपयोग करता है। इन दो विभाजनों को DRBD का उपयोग करके दोहराया जाता है, और वर्चुअल मशीन छवि केवल एक समय में एक सर्वर पर चलती है। हम ठोस राज्य ड्राइव की क्षमता का 80% तक उपयोग करते हैं, जो इनपुट / आउटपुट संचालन के लिए रिकॉर्डिंग और थ्रूपुट की विश्वसनीयता में काफी वृद्धि करता है। हमने RAID-6 का उपयोग करने के बजाय प्रत्येक ब्लॉक के लिए एक अतिरिक्त SSD को शामिल किया, जो प्रदर्शन में 15% तक की अतिरिक्त हानि से बचा था, क्योंकि पुनर्प्राप्ति समय कम होगा, और DRBD के साथ प्रतिकृति हमें कई डिस्क की काल्पनिक विफलता के मामले में सुरक्षित रहने का अवसर देगी।

फ़ाइल भंडारण को मुख्य सर्वरों पर स्थानीय डिस्क से अलग-अलग WebDAV सर्वरों के पूल में स्थानांतरित किया गया है जो RAID-6 सेकंड पर विशाल फ़ाइल सिस्टम का प्रबंधन करता है।
हर बार जब हम एवरनोट के लिए एक संसाधन फ़ाइल जोड़ते हैं, तो हमारा आवेदन समकालिक रूप से मेटाडेटा लेनदेन पूरा होने से पहले एक ही रैक में दो अलग-अलग फ़ाइल सर्वरों को इस फ़ाइल की एक प्रति लिखता है। अतिरेक के सिद्धांत के दूरस्थ कार्यान्वयन को एक एप्लिकेशन द्वारा भी गारंटी दी जाती है जो पृष्ठभूमि में एसिंक्रोनस डेटा ट्रांसफर के माध्यम से प्रत्येक नई फ़ाइल को दूरस्थ WebDAV सर्वर पर दोहराता है।

परिणाम

इस नए कॉन्फ़िगरेशन में I / O और मेमोरी ऑपरेशंस के लिए कम से कम चार साल के लिए एक ही शार्क पर 200,000 तक उपयोगकर्ताओं को संभालने की पर्याप्त क्षमता है। 14 शार्क और 4 फ़ाइल सर्वर के एक रैक की कीमत लगभग 135 हजार डॉलर है और 3900 वाट की खपत करता है, जो प्रति उपयोगकर्ता लगभग 0.05 डॉलर और 1.4 मिलीवाट है।

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

हम हाई-प्रोफाइल पर्यावरण संबंधी बयान नहीं देना चाहते हैं [और आप एक केडीपीवी के रूप में फिल लिबिन के गले लगाने वाले शराबी कपड़े की एक तस्वीर डाल सकते हैं], लेकिन यह ध्यान दिया जा सकता है कि ऊर्जा की खपत में 50% की कमी आनुपातिक रूप से हमारे उपकरणों से कार्बन उत्सर्जन को कम करती है।

स्पष्ट बचत के अलावा, समाधानों के मूल्यांकन और परीक्षण की प्रक्रिया हमें उन घटकों और प्रौद्योगिकियों को बेहतर ढंग से समझने की अनुमति देती है जिनका हम उपयोग करते हैं। हम SSDs से RAID सरणियों के परीक्षण और अनुकूलन के विवरणों पर कई और पोस्ट लिखने की योजना बनाते हैं, I / O बैंडविड्थ, DRBD प्रबंधन, आदि के संदर्भ में Xen और KVM का तुलनात्मक मूल्यांकन। हम आशा करते हैं कि यह जानकारी हमारे सहयोगियों के लिए उपयोगी होगी जब अत्यधिक भरी हुई सेवाओं का निर्माण।