हमारा दर्पण कैसे काम करता है

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

हमारी कंपनी का अपना पैकेज दर्पण भी है, जिसमें लोकप्रिय लिनक्स सिस्टम की रिपॉजिटरी की प्रतियां हैं। इस लेख में हम इसके उपकरण के बारे में विस्तार से बात करना चाहेंगे।

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

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

हमने एक ऐसे समाधान की तलाश शुरू की जिसके साथ हम स्थिरता सुनिश्चित कर सकें और आपात स्थिति की संभावना को कम कर सकें। हमारे पास निम्नलिखित विचार थे: नंगेक्स को कई दर्पणों के लिए प्रॉक्सी सर्वर के रूप में उभारने के लिए। यह समाधान हमें काफी उचित और विश्वसनीय लग रहा था: भले ही कोई भी अपलिंक क्रैश हो जाए, हम आसानी से दूसरे से फाइल डाउनलोड कर सकते हैं। हालांकि, हम तुरंत दर्पण की विषम संरचना की समस्या में भाग गए: उदाहरण के लिए, एक अपलिंक पर CentOS रिपॉजिटरी / सेंटोस में, दूसरे में / CentOS में, और सामान्य / www / दर्पण / srv / pub / centos में तीसरे पर हो सकता है।

चूंकि सभी वितरणों के रिपॉजिटरी वाले सार्वभौमिक दर्पण हैं जिनकी हमें ज़रूरत है (CentOS, Debian, Ubuntu, OpenSUSE) को उंगलियों पर गिना जा सकता है, प्रत्येक वितरण के लिए हमें दर्पणों की एक अलग सूची बनानी होगी।

इस विचार को व्यवहार में लाते हुए, हमें और अधिक गंभीर कठिनाइयों का सामना करना पड़ रहा है:

• अपलिंक गति असंगत है: बहुत बार ऐसा होता है कि एक ही मेजबान 5-10 एमबी / एस देता है, और कुछ घंटों के बाद - 5-20 केबी / एस से अधिक नहीं। चूंकि इंस्टॉलर एक-एक करके पैकेजों को डाउनलोड करता है, गति में अंतर के कारण, स्थापना अनिश्चित काल तक विलंबित हो सकती है;
• कुछ अपलिंक को गलत तरीके से कॉन्फ़िगर किया जा सकता है: ऐसा इसलिए हुआ कि एक अनुरोध के जवाब में, RPM पैकेज के बजाय, उन्हें एक HTML पृष्ठ मिला "यह काम करता है!";
• कुछ अपलिंक में कैटलॉग में इंगित पैकेज गायब हो सकते हैं। या पैकेज मौजूद थे, लेकिन गलत चेकसम थे। ऐसा हो सकता है, उदाहरण के लिए, अपस्ट्रीम के साथ गड़बड़ी सिंक्रनाइज़ेशन के कारण: पहला, इंडेक्स फाइल्स, और फिर पैकेज, और प्रोफा नहीं। Rsync के गलत कॉन्फ़िगरेशन के कारण त्रुटियां भी हो सकती हैं, जिसने फाइलों को जगह में दर्ज किया, लेकिन बाद में परमाणु प्रतिस्थापन के साथ एक अस्थायी फ़ाइल में सामग्री को नहीं बचाया।

इन सभी कठिनाइयों के कारण, स्वचालित स्थापना एक से अधिक बार विफल रही। एक बार और सभी के लिए असफलताओं से छुटकारा पाने के लिए, हमने अपना खुद का दर्पण बनाया - mirror.selectel.ru। यह केवल Selectel के आईपी पते से उपलब्ध है (हमारे लिए आउटगोइंग ट्रैफ़िक का भुगतान किया जाता है और हम इसे जनता को प्रदान करने का जोखिम नहीं उठाते हैं, क्योंकि आप आसानी से 10-20 गीगाबिट प्राप्त कर सकते हैं)।

अपना स्वयं का दर्पण बनाने के बाद, हमने ऊपर बताई गई सभी समस्याओं को हल कर दिया। अपने स्वयं के दर्पण के लिए धन्यवाद प्राप्त किए गए लाभों में से, आपको निम्नलिखित नाम भी देना चाहिए:

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

इस दर्पण से, समर्पित सर्वरों पर ऑपरेटिंग सिस्टम स्थापित होते हैं।

रिपॉजिटरी कैसे काम करते हैं?

एक नियम के रूप में, रिपॉजिटरी में दो मुख्य भाग होते हैं: एक निर्देशिका (सूचकांक) और एक पूल (पैकेज भंडारण)।

निर्देशिका उन सभी पैकेजों के बारे में जानकारी संग्रहीत करती है जो भंडार में हैं: नाम, विवरण, वास्तुकला, संस्करण, चेकसम, और कुछ मामलों में निर्भरता और पैकेज सामग्री के बारे में भी जानकारी। निर्देशिका यह भी इंगित करती है कि पूल में वास्तव में प्रत्येक पैकेज के एक या दूसरे संस्करण की फ़ाइल कहाँ है।

पूल में स्वयं पैकेज फाइलें होती हैं। वे किसी भी पदानुक्रम के अनुसार विघटित हो सकते हैं या बस एक निर्देशिका में बदल सकते हैं।

RPM रिपोजिटरी

प्रत्येक RPM रिपॉजिटरी के मूल में डायरेक्टरी फाइलों के साथ एक निर्देशिका है - रिपोडाटा। निर्देशिका के सभी अनुभागों का विवरण repomd.xml फ़ाइल में संग्रहीत किया जाता है। प्रत्येक अनुभाग को निर्देशिका निर्देशिका में एक अलग फ़ाइल द्वारा दर्शाया गया है। विवरण अनुभाग युक्त फ़ाइल के साथ-साथ उसके चेकसम के लिए भी रास्ता दिखाता है।

उदाहरण के लिए, repomd.xml फ़ाइल की सामग्री इस तरह दिख सकती है:

 <? xml संस्करण = "1.0" एन्कोडिंग = "UTF-8"?>
 <repomd xmlns = "http://linux.duke.edu/metadata/repo" xmlns: rpm = "http://linux.duke.edu/metadata/rpm">
 <पुनरीक्षण> 1362531727 </ संशोधन>
 <डेटा प्रकार = "प्राथमिक"> <! - प्राथमिक अनुभाग का विवरण - XML ​​डेटाबेस जिसमें रिपॉजिटरी पैकेज के बारे में जानकारी होती है ->
 <चेकसम प्रकार = "sha256"> 87aa4c4e19f9a3ec93e3d820f1ea6b6ece8810cb45f117a16354465e57a1b50a </ checkum>
 <ओपन-चेकसम प्रकार = "sha256"> 77b5cfcf2c06156858a14a52595e1f69cd8cb58c09699a3ea43913792be943 </ open-checkum>
 <स्थान href = "रिपोडाटा / 87aa4c4e19f9a3ec93e3d820f1ea6b6ece8810cb45f117a16354465e57a1b50d-प्राथमिक.xml.gz" />
 <टाइमस्टैम्प> 1362531876 </ टाइमस्टैम्प>
 <आकार> 2043735 </ आकार>
 <खुले-आकार> 12931923 </ खुले-आकार>
 </ डेटा>
 <data type = "Primary_db"> <! - Primary_db सेक्शन का विवरण केवल sqlite डेटाबेस में प्राइमरी के समान है ->
 <चेकसम प्रकार = "sha256"> 243fdef956d09cb6d022e894e40d145f497bcf3d6d2bed79814e1c88452d9d29 </ checkum>
 <ओपन-चेकसम प्रकार = "sha256"> 533872a158160ac3a83746a676c125b5cf24247272507979502b0d5be4f4d05196806 </ open-checkum>
 <स्थान href = "रिपोडाटा / 243fdef956d09cb6d022e894e40d145f497bcf3d6d2bed79814e1c88452bbdd29- प्राथमिक.sqlite.bz2" />
 <टाइमस्टैम्प> 1362531897.21 </ टाइमस्टैम्प>
 <database_version> 10 </ database_version>
 <आकार> 3605913 </ size>
 <खुले-आकार> 14942208 </ खुले-आकार>
 </ डेटा>
 ...
 </ Repomd>

RPM कैटलॉग में निम्नलिखित भाग होते हैं:

• प्राथमिक - रिपॉजिटरी में संग्रहीत सभी पैकेजों का विवरण होता है, इन पैकेजों की फाइलों के मार्ग और उनके चेकसम;
• फाइलिस्ट्स - प्रत्येक पैकेज में शामिल फाइलों की सूची है;
• समूह - में yum groupinstall का उपयोग करके स्थापित किए गए संकुल के समूहों का वर्णन है;
• अन्य - में अतिरिक्त जानकारी होती है (उदाहरण के लिए, परिवर्तन लॉग - चैंज)।

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

OpenSUSE ने सभी आर्किटेक्चर के लिए पैकेजों को एक ही भंडार में अलग-अलग पूल के साथ i686 / x86_64 आदि में संग्रहीत किया है।

DEB रिपोजिटरी

DEB रिपॉजिटरी में, सभी पैकेज एक आम पूल में रखे जाते हैं। यह विभिन्न रिलीज में शामिल पैकेजों के दोहराव से बचा जाता है। रिपॉजिटरी में प्रत्येक रिलीज़ के लिए एक अलग निर्देशिका बनाई गई है।

निर्देशिका की पार्सिंग फ़ाइल / डिस्ट्स / [वितरण] / रिलीज के साथ शुरू होती है (यहां वितरण का अर्थ है रिलीज का कोडनेम निचोड़ / मट्ठा / जेसी है)। इसमें रिलीज़ घटकों की एक सूची है, साथ ही सभी सूचकांक फ़ाइलों के आकार और चेकसम के बारे में जानकारी है। रिलीज़ फाइल आर्काइव मेंटेनर्स द्वारा साइन की जाती है; हस्ताक्षर को रिलीज़.जीपीजी फ़ाइल में संग्रहीत किया जाता है (कभी-कभी हस्ताक्षर के साथ रिलीज़ की सामग्री इनरेल फ़ाइल में हो सकती है)।

पूल की सामग्री का वर्णन दो प्रकार की सूचकांक फाइलों में है: पैकेज (वे बाइनरी पैकेज की सूची) और स्रोत (वे स्रोतों की सूची)।

संकुल फ़ाइल का पथ / dists / [वितरण] / [घटक] / बाइनरी- [वास्तुकला] / संकुल है, और स्रोत फ़ाइल का पथ / dists / [वितरण] / [घटक] / स्रोत / स्रोत है।

नोट: कभी-कभी सूचकांक फाइलें gzip या bzip2 का उपयोग करके संपीड़ित होती हैं - इस मामले में, एक्सटेंशन .gz या .bz2 को फ़ाइल नाम में जोड़ा जाता है। कुछ क्लाइंट LZMA (.lzma), XZ (.xz) और LZIP (.lz) का समर्थन करते हैं।

यहाँ संकुल फ़ाइल से प्रविष्टि का एक उदाहरण दिया गया है:

 पैकेज: ओपनश-सर्वर
 स्त्रोत: ओपेनश
 संस्करण: 1: 6.2p2-6
 स्थापित-आकार: 747
 मेंटेनर: डेबियन ओपनएसएसएच मेंटेनर 
 वास्तुकला: amd64
 स्थान: Opensh-client (<= 2.16), libcomerr2 (> = 1.01), libgssapi-krb5-2 (> = 1.10 + dfsg ~), libkrb5-3 (>> 1.6.dfsg.2), libpam0g (> = 0.99) .7.1), libselinux1 (> = 1.32), libssl1.0.0 (> = 1.0.1), libwrap0 (> = 7.6-4 ~), zlib1g (> = 1: 1.1.4), ओपनश-क्लाइंट (= 1: 6.2p2-6), sysv-rc (> = 2.88dsf-24) |  file-rc (> = 0.8.16), libpam-runtime (> = 0.76-14), libpam-मॉड्यूल (> = 0.72-9), एड्यूसर (> = 3.9), dpkg (> = 1.9.0, lsb) -बेस (> = 4.1 + डेबियन 3), खरीदता है
 अनुशंसा करता है: xauth, ncurses-term
 सुझाव: ssh-askpass, rssh, मौली-गार्ड, ufw, मंकीस्फियर, ओपनश-ब्लैकलिस्ट, ओपनश-ब्लैकलिस्ट-अतिरिक्त
 संघर्ष: rsh-client (<< 0.16.1-1), sftp, ssh (<< 1: 3.8.1p1-9), ssh-krb5 (<< 1: 4.3p2-7), ssh-nonrree (<< 2), ssh-मोजे, ssh2
 विवरण: दूरस्थ मशीनों से सुरक्षित पहुँच के लिए सुरक्षित शेल (SSH) सर्वर
 मल्टी-आर्क: विदेशी
 होमपेज: http://www.openssh.org/
 विवरण- md5: 842cc998cae371b9d8106c1696373919
 टैग: व्यवस्थापक :: लॉगिन, कार्यान्वित-इन :: सी, इंटरफ़ेस :: डेमॉन, नेटवर्क :: सर्वर,
 प्रोटोकॉल :: ssh, भूमिका :: कार्यक्रम, सुरक्षा :: प्रमाणीकरण,
 सुरक्षा :: क्रिप्टोग्राफी, उपयोग :: लॉगिन, उपयोग :: ट्रांसमिशन
 अनुभाग: नेट
 प्राथमिकता: वैकल्पिक
 फ़ाइल नाम: पूल / मेन / ओ / ओपेनश / ओपनश-सर्वर_6.2p2-6_amd64.deb
 आकार: 257438
 MD5sum: 1f18e568c17d81cc2c493ee48c93a03f
 SHA1: 207f131bbd4d709a47bcb69c997520c998ed7593
 SHA256: 242b7f041292dea0702b24e19dc6355f47147796b227f1024665920a493641f2

हमारा दर्पण कैसे काम करता है

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

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

दो हिस्सों के उलट होने के बाद, छाया वाला हिस्सा स्थानीय रूप से कार्यशील प्रतिलिपि से वर्तमान स्थिति में "कैच अप" करता है।

आईना-सिंक

ऊपर वर्णित एल्गोरिथ्म दर्पण-सिंक नामक हमारी स्क्रिप्ट के सेट में लागू किया गया है , जिसे हाल ही में जीएनयू जीपीएल के तहत गीथहब पर प्रकाशित किया गया है । हमें उम्मीद है कि हमारा अनुभव व्यापक दर्शकों के लिए उपयोगी होगा, और हमारे कुछ पाठक हमारे स्वयं के दर्पण बनाने में हमारे अनुभव का उपयोग करेंगे। दर्पण में सुधार के लिए टिप्पणियों और सुझावों वाली सभी टिप्पणियां, हम भविष्य के काम में ध्यान में रखेंगे।

जो लोग हबेरा के पदों पर टिप्पणी नहीं कर सकते, उनके लिए हम अपने ब्लॉग पर आमंत्रित करते हैं।