बिलियन फ़ाइल स्पीड सिंक

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

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

कई क्लस्टर प्रौद्योगिकियों और फ़ाइल सिस्टम का परीक्षण करने के बाद, एक वरिष्ठ मित्र की सलाह पर, हमने उसी rsync का उपयोग करने का निर्णय लिया, लेकिन inotify के साथ संयोजन में। इस तरह के रेडी-मेड समाधान के लिए इंटरनेट पर थोड़ी खोज की, ताकि पहिया को सुदृढ़ न करने के लिए, मैं csyncd, inosync और lsyncd के पार आया। हब पर csyncd पर पहले से ही एक लेख था, लेकिन यह यहाँ काम नहीं करेगा, क्योंकि SQLite डेटाबेस में फ़ाइलों की एक सूची संग्रहीत करता है, जो एक लाख रिकॉर्ड के साथ भी काम करने में सक्षम होने की संभावना नहीं है। और ऐसे संस्करणों के साथ एक अतिरिक्त लिंक बेकार है। लेकिन lsyncd ठीक वही निकला जो हमें चाहिए था।

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

Rsync + inotify = lsyncd

Lsyncd एक ऐसा डेमन है जो स्थानीय निर्देशिका में परिवर्तन पर नज़र रखता है, उन्हें एकत्र करता है, और कुछ समय बाद rsync उन्हें सिंक्रनाइज़ करना शुरू करता है।



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

कार्यान्वयन

स्थापना प्रक्रिया Ubuntu 11.10 के लिए वर्णित है। अन्य संस्करणों में अंतर हो सकता है।

1. ssh कॉन्फ़िगर करें ताकि आप बिना प्राधिकरण के किसी भी नोड से दूसरे में लॉग इन कर सकें। सबसे अधिक संभावना है कि हर कोई जानता है कि यह कैसे करना है, लेकिन सिर्फ मामले में मैं वर्णन करूंगा।

ssh-keygen 

पासफ़्रेज़ खाली छोड़ दें।

इसके बाद, ~ / .ssh / प्राधिकृत_के में क्लस्टर में अन्य सभी नोड्स के लिए ~ / .ssh / id_rsa.pub की सामग्री जोड़ें। स्वाभाविक रूप से, हम उस उपयोगकर्ता के लिए $ HOME चुनते हैं, जिसके पास सिंक्रनाइज़ेशन फ़ोल्डर में अनुमतियाँ हैं। सबसे आसान तरीका अगर यह है / जड़, लेकिन सुरक्षा के दृष्टिकोण से यह सबसे अच्छा विकल्प नहीं है।
सभी नोड्स को / etc / मेजबानों में पंजीकृत करना भी उचित है। मैंने उन्हें नोड 01, नोड02, नोड03 कहा।
सभी नोड्स पर दोहराएं।

2. lsyncd स्थापित करें

 apt-get install lsyncd 

3. यद्यपि कॉन्फ़िगर को मैन्युअल रूप से बनाने की आवश्यकता है, यह काफी सरल है। यह लुआ भाषा में लिखा गया है। Lsyncd के लेखक से Lua चुनने के कारणों के बारे में एक टिप्पणी भी दिलचस्प है। मैंने लॉग के लिए एक अलग निर्देशिका भी बनाई।

 mkdir -p /etc/lsyncd mkdir -p /var/log/lsyncd vi /etc/lsyncd/lsyncd.conf.lua 

टिप्पणियों के साथ विन्यास की सामग्री:

 settings = {<br/> logfile = "/var/log/lsyncd/lsyncd.log", <br/> statusFile = "/var/log/lsyncd/lsyncd.status", <br/> nodaemon = true --<==    .  .<br/> } <br/> --[[<br/> sync { <br/> default.rsync, --<==  rsync  . -,    - .<br/> source="/raid", --<==  ,  <br/> target="node01:/raid", --<== dns-    -  <br/> rsyncOps={"-ausS", "--temp-dir=/mnt-is"}, --<== temp-dir    .<br/> delay=10 --<== ,       <br/> } <br/> ]]<br/> sync { <br/> default.rsync, <br/> source="/raid", <br/> target="node02:/raid", <br/> rsyncOps={"-ausS", "--temp-dir=/mnt-is"}, <br/> delay=10 <br/> } <br/> <br/> sync { <br/> default.rsync, <br/> source="/raid", <br/> target="node03:/raid", <br/> rsyncOps={"-ausS", "--temp-dir=/mnt-is"}, <br/> delay=10<br/> } 

प्रत्येक विशिष्ट सर्वर के लिए अतिरिक्त ब्लॉक की टिप्पणी करते हुए, एक बार कॉन्फ़िगरेशन को बनाना और फिर सभी नोड्स में वितरित करना आसान है। टिप्पणियाँ "- [[" और "]] के बीच हैं।"

प्रयुक्त rsync कॉल विकल्प:
ए - आर्काइविंग मोड; एक्सेस-राइट्स, ग्रुप, ओनर को बनाए रखते हुए, इनक्लिप्टोगो के समतुल्य, जो कि सहानुभूति और विशेष फाइलों के साथ पुन: कॉपी करता है।
एल - कॉपी सीमलिंक;
यू - यदि वे नए हैं तो प्राप्तकर्ता पर फ़ाइलों को अपडेट न करें;
टी, पी, ओ, जी - कॉपी टाइम, एक्सेस राइट्स, ओनर, ग्रुप, क्रमशः।
s - यदि फ़ाइल नाम में कोई स्थान दिखाई देता है।
एस - शून्य से मिलकर डेटा के संचरण का अनुकूलन।
आदमी lsyncd या प्रलेखन में अधिक जानकारी।

4. हम सभी नोटों पर दानव शुरू करते हैं:

 /etc/init.d/lsyncd start 

यदि आपने कॉन्फ़िगरेशन में "nodaemon = true" छोड़ा है, तो आप देख सकते हैं कि क्या हो रहा है।

इसके बाद, उस निर्देशिका में किसी चीज़ को कॉपी / क्रिएट / डिलीट करें जिसे हमने सिंक्रोनाइज़ेशन के लिए निर्दिष्ट किया है (I have / raid), कुछ सेकंड प्रतीक्षा करें और सिंक्रोनाइज़ेशन के परिणाम की जाँच करें।

डेटा ट्रांसफर दर 300 Mbit / s तक पहुँचती है और इसका सर्वर लोड पर बहुत कम प्रभाव पड़ता है (उदाहरण के लिए समान GlusterFS की तुलना में), और इस मामले में देरी चोटियों को सुचारू करती है। बहुत अधिक उपयोग किए गए एफएस पर निर्भर करता है। यहां भी, मुझे संख्याओं और ग्राफ़ के साथ थोड़ा शोध करना पड़ा, क्योंकि स्थिति काफी विशिष्ट है और मौजूदा प्रकाशित परीक्षणों के परिणाम यह नहीं दर्शाते हैं कि कार्य में क्या आवश्यक है।

इस मामले में और क्या विचार किया गया और यह क्यों फिट नहीं हुआ

पूरे अध्ययन का उद्देश्य अमेज़ॅन ईसी 2 के साथ काम करना था, इसकी सीमाओं और विशेषताओं को ध्यान में रखते हुए, इसलिए, निष्कर्ष मुख्य रूप से केवल उसकी चिंता करते हैं।

• DRBD - प्रतिकृति एक ब्लॉक स्तर पर है। एक वाहक के पतन के मामले में, दोनों मारे जाते हैं। 2 नोड्स की सीमा। (अधिक संभव है, लेकिन 3rd और 4th को केवल दास के रूप में जोड़ा जा सकता है।)
• Ocfs2 - इसका उपयोग या तो DRBD (जिसके बारे में हैबर पर एक अच्छा लेख है ) पर किया जाता है, या आपको कई नोड्स से एक विभाजन को माउंट करने में सक्षम होने की आवश्यकता होती है। Ec2 पर असंभव।
• Gfs2 ocfs2 का एक एनालॉग है। मैंने इसकी कोशिश नहीं की है, क्योंकि परीक्षणों के अनुसार, यह एफएस ओफ़्फ़्स 2 की तुलना में धीमा है, अन्यथा यह इसका समकक्ष है।
• GlusterFS - यहाँ यह सब लगभग तुरंत काम किया है और जैसा कि इसे करना चाहिए! प्रशासन करने के लिए सरल और तार्किक। आप मनमाने ढंग से प्रतिकृति मान के साथ 255 नोड्स तक का एक क्लस्टर बना सकते हैं। सर्वर की एक जोड़ी से एक क्लस्टर विभाजन बनाया और उन पर मुहिम शुरू की लेकिन एक अलग निर्देशिका में (यानी, सर्वर भी उसी समय ग्राहक थे)। दुर्भाग्य से, क्लाइंट पर, इस क्लस्टर को FUSE के माध्यम से रखा गया है, और लिखने की गति 3 एमबी / एस से कम हो गई है। और इसलिए, उपयोग के साथ अनुभव बहुत अच्छा है।
• चमक - इस चीज़ को krenel मोड में चलाने के लिए आपको कर्नेल को पैच करना होगा। अजीब तरह से पर्याप्त है, उबंटू भंडार में इन पैच के साथ एक पैकेज है, लेकिन मुझे इसके लिए पैच खुद नहीं मिला, या कम से कम डेबियन के लिए। और समीक्षाओं को देखते हुए, मैंने महसूस किया कि इसे डिबेट-सिस्टम में लाना शर्मनाक है।
• Hadoop w / HDFS, Cloudera - ने कोशिश नहीं की, क्योंकि एक और समाधान मिला था (नीचे देखें)। लेकिन आपकी आंख को पकड़ने वाली पहली चीज जावा में लिखी गई है, इसलिए खाने के लिए बहुत सारे संसाधन होंगे, और पैमाना फेसबुक या याहु की तरह नहीं है, अब तक केवल 4 नोड्स हैं।

UPD: यह समाधान परीक्षणों में उत्कृष्ट साबित हुआ (जिसके बाद लेख लिखा गया था), लेकिन युद्ध की स्थितियों में सब कुछ पूरी तरह से अलग हो गया। न्यूनतम उत्पादन विन्यास 584 हजार नेस्टेड निर्देशिका है। और lsyncd प्रत्येक डायरेक्टरी पर inotify लटकाता है। पूरे पेड़ के लिए अभी यह करना असंभव है। स्मृति, 584 हजार के नोट, लगभग 200 एमबी (उपलब्ध 16 जीबी में से) अपेक्षाकृत कम खपत होती है, लेकिन इस प्रक्रिया में 22 मिनट लगते हैं। सिद्धांत रूप में, यह डरावना नहीं है: बस शुरू हुआ और भूल गया। लेकिन उसके बाद, मानक कॉन्फ़िगरेशन के साथ, lsyncd सभी फ़ाइलों का सिंक्रनाइज़ेशन शुरू करता है, जो हमारी स्थितियों में या तो छोटी गाड़ी थी या दिन लग गए। सामान्य तौर पर - एक विकल्प नहीं है। 100% स्थिरता की आवश्यकता नहीं है और आप बिना शुरुआती सिंक्रनाइज़ेशन के कर सकते हैं। इसे बंद करना ही रह गया। सौभाग्य से, दानव लिखा गया है ताकि आप अपने सभी कार्यों को लगभग सीधे कॉन्फ़िगरेशन से बदल सकें। इसके अलावा, प्रदर्शन को बढ़ाने के लिए, default.rsync को default.rsyncssh द्वारा बदल दिया गया था, और कर्नेल को अयोग्य सीमा के लिए nunyun था। यही है, अधिकांश कार्यों के लिए, ऊपर का विन्यास उपयुक्त है, लेकिन हमारी विशिष्ट स्थिति में, निम्नलिखित कार्य हैं:

 settings = { logfile = "/var/log/lsyncd/lsyncd.log", statusFile = "/var/log/lsyncd/lsyncd.status", statusInterval = 5, --<==         } sync { default.rsyncssh, source = "/raid", host = "node02", targetdir = "/raid", rsyncOps = {"-ausS", "--temp-dir=/tmp"}, --<==   delay = 3, --<==  -,     init = function(event) --<==   .             log("Normal","Skipping startup synchronization...") --<==  ,         end } sync { default.rsyncssh, source = "/raid", host = "node03", targetdir = "/raid", rsyncOps = {"-ausS", "--temp-dir=/tmp"}, delay = 3, init = function(event) log("Normal","Skipping startup synchronization...") end } 

कर्नेल सेटिंग्स

Inotify के तीन पैरामीटर हैं (देखें ls / proc / sys / fs / inotify /))
max_queued_events - कतार में घटनाओं की अधिकतम संख्या; डिफ़ॉल्ट = 16384;
max_user_instances - एक उपयोगकर्ता द्वारा कितने इंस्टीट्यूशन इंस्टाल किए जा सकते हैं; डिफ़ॉल्ट = 128;
max_user_watches - एक उपयोगकर्ता कितनी फ़ाइलों को ट्रैक कर सकता है; डिफ़ॉल्ट = 8192।

कार्य मान:

 echo " fs.inotify.max_user_watches = 16777216 # fs.inotify.max_queued_events = 65536 " >> /etc/sysctl.conf echo 16777216 > /proc/sys/fs/inotify/max_user_watches echo 65536 > /proc/sys/fs/inotify/max_queued_events 

तो सब कुछ पहले से ही उत्पादन में काम किया।

आपका ध्यान के लिए धन्यवाद!