बहुत बड़ी फ़ोल्डर संरचनाओं को सिंक्रनाइज़ करना

Question

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

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

जाहिर है कि चूंकि कुछ फाइलें नियमित रूप से बदलती रहती हैं, इसलिए हम वृद्धिशील प्रति से काफी लाभ उठा सकते हैं। हमने Rsync की कोशिश की है, लेकिन "बिल्डिंग फाइल लिस्ट" को पूरा करने में आठ से बारह घंटे तक का समय लग सकता है । यह स्पष्ट है कि हम तेजी से बढ़ रहे हैं कि rsync क्या सक्षम है (12 घंटे की समय सीमा बहुत लंबी है)।

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

क्या किसी और ने इस तरह के बड़े पैमाने पर सिंक्रनाइज़ेशन प्रोजेक्ट में भाग लिया है? क्या सिंक्रनाइज़ेशन के लिए बड़े पैमाने पर फ़ाइल संरचनाओं को संभालने के लिए कुछ डिज़ाइन किया गया है?

Comments

क्या आपने एक ही समय में rsync के कई उदाहरणों पर कार्य को विभाजित करने का प्रयास किया है? मेरे पास निर्देशिका संरचना की वास्तविक अच्छी तस्वीर नहीं है, लेकिन आप इसे निर्देशिका नाम या फ़ाइल नाम से विभाजित कर सकते हैं।

— क्लच

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

— 21

क्या आपको कभी एक अच्छा समाधान मिला, डेव? मैं 65535 उप-डायर के साथ dir के लिए lsyncd पर विचार कर रहा हूं, जिनमें से प्रत्येक में 65 ^ 16 फाइलें हो सकती हैं।

— माइक डाइने

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

— ताकतवर

Answer 1

यदि आप फाइल-सिस्टम लास्ट-मोडिफाइड टाइमस्टैम्प पर भरोसा कर सकते हैं, तो आप यूनिक्स / लिनक्स 'उपयोगिता' के साथ रुपीस को जोड़कर चीजों को गति दे सकते हैं। 'खोज' उन सभी फाइलों की एक सूची को इकट्ठा कर सकता है, जो पिछले दिन के भीतर अंतिम-संशोधित समय दिखाती हैं, और उसके बाद केवल उस फाइल की छोटी सूची / निर्देशिका को पाइप करें जो Rsync को है। यह रुपये के रिमोट सर्वर के खिलाफ प्रेषक पर हर एक फ़ाइल के मेटाडेटा की तुलना में बहुत तेज़ है।

संक्षेप में, निम्नलिखित आदेश केवल 24 घंटों में बदल गई फ़ाइलों और निर्देशिकाओं की सूची पर रुपये को निष्पादित करेगा: (रुपये किसी भी अन्य फ़ाइलों / निर्देशिकाओं की जांच करने के लिए परेशान नहीं करेगा।)

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

यदि आप 'खोज' कमांड से परिचित नहीं हैं, तो यह एक विशेष निर्देशिका सबट्री के माध्यम से पुन: प्राप्त होता है, जो कि आपके द्वारा निर्दिष्ट मानदंडों को पूरा करने वाली फ़ाइलों और / या निर्देशिकाओं की तलाश करता है। उदाहरण के लिए, यह आदेश:

find . -name '\.svn' -type d -ctime -0 -print

वर्तमान निर्देशिका ("") में शुरू होगा और सभी उप-निर्देशिकाओं के माध्यम से पुन: खोज करेगा, जिसकी तलाश है:

• किसी भी निर्देशिका ("-टाइप डी"),
• ".svn" ("-name '.svn'") नाम दिया,
• मेटाडेटा के साथ पिछले 24 घंटों में संशोधित किया गया ("-ctime -0")।

यह मानक आउटपुट पर उन मानदंडों से मेल खाने वाली किसी भी चीज़ का पूरा पथ नाम ("-प्रिंट") प्रिंट करता है। विकल्प '-name', '-type' और '-ctime' को "परीक्षण" कहा जाता है, और विकल्प '-प्रिंट' को "कार्रवाई" कहा जाता है। 'खोज' के लिए मैन पेज में परीक्षणों और कार्यों की पूरी सूची है।

यदि आप वास्तव में चतुर होना चाहते हैं, तो आप इस प्रक्रिया को अधिक दोष-सहिष्णु और लचीला बनाने के लिए '-ctime' के बजाय 'कमांड' के '-newer' परीक्षण का उपयोग कर सकते हैं। '-newer' परीक्षण करता है कि क्या ट्री में प्रत्येक फ़ाइल / निर्देशिका का मेटाडेटा कुछ संदर्भ फ़ाइल की तुलना में हाल ही में संशोधित हुआ है। प्रत्येक रन की शुरुआत में NEXT रन की संदर्भ फ़ाइल बनाने के लिए 'स्पर्श' का उपयोग करें, 'खोज ... से ठीक पहले | rsync ... 'कमांड निष्पादित करता है। यहां मूल कार्यान्वयन है:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

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

Comments

यह एक अत्यंत चतुर उपाय है! मैं सोच रहा हूँ आप touch $next_ref_fileअंत में मतलब है ? यह हमें हटाए गए रास्तों का सामना करने की क्षमता के बिना छोड़ देता है (भले ही ये स्थिर अभिलेखीय रिपोर्टें अंततः पुरानी हो जाती हैं कि वे संग्रहीत और हटाए गए हैं)। हालांकि यह शो स्टॉपर नहीं हो सकता है।

— ताकतवर

हालांकि मुझे पता है कि find . -ctime 0इस निर्देशिका संरचना पर अभी भी बहुत धीमी है (अभी भी अपने समय की रिपोर्ट करने के लिए इसे पूरा करने के लिए इंतजार कर रहा है)। यह वास्तव में मुझे थोड़ा निराश करता है क्योंकि ऐसा लगता है कि यह एक निम्न स्तर का ऑपरेशन हो सकता है जो शायद सबसे तेज़ बार सेट करता है जो हम इस नौकरी के पूरा होने की उम्मीद कर सकते हैं। यह मामला हो सकता है कि डिस्क I / O यहां सीमित कारक है।

— ताकतवर

उस स्क्रिप्टलेट के रूप में, हां, मैंने एक गलती की। मेरा मतलब था कि 'अगला_ref_file' पर 'टच' ('''_____ '' नहीं 'चलाने से पहले) rsync ... 'कमांड। (मैं अपना जवाब ठीक करूंगा।)

— रियान बी। लिंच

धीमी 'खोज' कमांड के लिए: आप किस तरह के फाइल सिस्टम का उपयोग कर रहे हैं? यदि आप Ext3 का उपयोग कर रहे हैं, तो आप दो FS tweaks पर विचार कर सकते हैं: 1) Run3 की 'dir_index' सुविधा को सक्षम करने के लिए बड़ी फाइल काउंट्स के साथ dirs तक पहुँच को तेज़ करने के लिए 'tune2fs -O dir_index <DEVICE_NODE> चलाएं। 2) एक्सेस टाइम अपडेट को बंद करने के लिए 'माउंट -ओ रीमाउंट, नोमाटाइम, नोडिरटाइम' चलाएं, जो आम तौर पर पढ़ने की गति बढ़ाता है। 'डंप 2 एफए -एच <DEVICE_NODE> | grep dir_index 'आपको बताता है कि' dir_index 'पहले से ही सक्षम है (कुछ डिस्ट्रोस पर, यह डिफ़ॉल्ट है), और' माउंट | grep <DEVICE_NODE> 'आपको एक्सेस टाइम अपडेट के बारे में बताता है।

— रयान बी। लिंच

अफसोस की बात है कि यह NTFS - विंडोज 2003 सर्वर है, जो कमांड आदेश के लिए Cygwin का उपयोग कर रहा है। मुझे उन ट्यूनिंग विकल्पों (उत्कृष्ट सलाह) को ext3 के लिए याद रखना होगा जब हम कभी भी अपने डेबियन क्लस्टर में से किसी एक में मिलते हैं।

— पराक्रमी

Answer 2

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

Comments

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

— माइटी

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

— डेव चेनी

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

— ताकतवर

परिवर्तनों को स्कैन करने के लिए प्रारंभिक कैटलॉग के निर्माण में अभी लगभग 2 घंटे लगते हैं। मुझे बहुत आश्चर्य हुआ कि इसके लिए RAM Unison कितना उपयोग कर रहा है। हमारे फ़ाइल संग्रह के लिए, स्रोत सर्वर 635M का उपयोग कर रहा है, और दूरस्थ क्लाइंट 366M का उपयोग कर रहा है। एक क्लस्टर में कई मशीनों को सिंक्रनाइज़ करने के लिए विशेष रूप से स्रोत सर्वर के लिए एक बहुत बड़ा पदचिह्न होगा!

— पराक्रमी

क्या आप अपने डेटा को इस तरह से संरचना करने में सक्षम हैं जिससे हाल ही में परिवर्तित हुए डेटा की पहचान करना आसान हो जाता है? यानी, इसे वर्ष / माह / दिन / ... प्रारूप में संग्रहीत करना?

— डेव चेनी

Answer 3

http://oss.linbit.com/csync2/ इस तरह की चीज़ के लिए डिज़ाइन किया गया है, मैं कोशिश करूँगा कि।

Answer 4

यदि आप rsync पर -z स्विच का उपयोग कर रहे हैं, तो इसके बिना चलने का प्रयास करें। किसी कारण से मैंने इस गति को फ़ाइलों की प्रारंभिक गणना तक देखा है।

Comments

हमने -z झंडे के साथ और उसके बिना कोशिश की है। यह "बिल्डिंग फ़ाइल सूची" निष्पादन अवधि पर प्रभाव नहीं लगता था।

— ताकतवर

Answer 5

-S को rsync कमांड से बाहर निकालना, जो कि कोई कम्प्रेशन नहीं है, "फाइल लिस्ट प्राप्त करना" इतना तेज हो गया और हमें लगभग 500 GB ट्रांसफर करना पड़ा। इससे पहले कि -z स्विच के साथ एक दिन लगे।