दो दूर के लिनक्स सर्वरों के बीच बड़ी फ़ाइल ट्री का द्विदिश वास्तविक-समय सिंक


21

बड़ी फाइल ट्री से मेरा मतलब लगभग 200k फाइल है, और हर समय बढ़ता रहता है। हालाँकि किसी भी समय अपेक्षाकृत कम संख्या में फाइलें बदली जा रही हैं।

द्विदिश से मेरा मतलब है कि परिवर्तन सर्वर पर हो सकते हैं और दूसरे को धकेलने की आवश्यकता है, इसलिए rsync उचित नहीं लगता है।

दूर से मेरा मतलब है कि सर्वर दोनों डेटा सेंटर में हैं, लेकिन भौगोलिक रूप से एक दूसरे से दूरस्थ हैं। वर्तमान में केवल 2 सर्वर हैं, लेकिन समय के साथ इसका विस्तार हो सकता है।

वास्तविक समय तक, सिंक्रनाइज़ेशन के बीच थोड़ा विलंबता होना ठीक है, लेकिन हर 1-2 मिनट में एक क्रोन चलाना सही नहीं लगता है, क्योंकि किसी भी घंटे में फ़ाइलों का एक बहुत छोटा अंश बदल सकता है, अकेले मिनट दें।

संपादित करें : यह VPS पर चल रहा है इसलिए मैं कर्नेल-स्तर के सामान पर सीमित हो सकता हूं जो मैं कर सकता हूं। इसके अलावा, वीपीएस संसाधन-समृद्ध नहीं हैं, इसलिए मैं उन समाधानों से दूर हटूंगा, जिनके लिए बहुत सारे रैम की आवश्यकता होती है (जैसे ग्लस्टर!)।

इसे प्राप्त करने के लिए सबसे अच्छा / सबसे "स्वीकृत" तरीका क्या है? ऐसा लगता है कि यह एक आम ज़रूरत होगी, लेकिन मैं अभी तक आम तौर पर स्वीकृत दृष्टिकोण नहीं पा सका हूं, जो आश्चर्यजनक था। (मैं जनता की सुरक्षा चाह रहा हूँ। :)

मैं फाइलसिस्टम परिवर्तन स्तर पर एक सिंक को ट्रिगर करने के लिए lsyncd के पार आया हूँ । यह सुपर आम नहीं है, हालांकि चालाक लगता है, और मैं विभिन्न lsyncd दृष्टिकोण से थोड़ा उलझन में हूँ। वहाँ बस rsync के साथ lsyncd का उपयोग कर रहा है, लेकिन ऐसा लगता है कि यह द्विदिशता के लिए नाजुक हो सकता है क्योंकि rsync में स्मृति की धारणा नहीं होती है (उदाहरण के लिए, यह जानना कि A पर कोई हटाई गई फ़ाइल B पर हटाई जानी चाहिए या B पर एक नई फ़ाइल है या नहीं कि ए को कॉपी किया जाना चाहिए)। lipsync सिर्फ एक lsyncd + rsync कार्यान्वयन, सही प्रतीत होता है?

फिर csync2 के साथ lsyncd का उपयोग कर रहे हैं , इस तरह: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ मैं इस दृष्टिकोण की ओर झुक रहा हूं, लेकिन csync2 थोड़ा विचित्र है, हालांकि मैंने इसका सफल परीक्षण किया। मैं ज्यादातर इस बात से चिंतित हूँ कि मैं इस पद्धति की बहुत सारी सामुदायिक पुष्टि नहीं कर पाया हूँ।

यहाँ पर लोग Unison को बहुत पसंद करते हैं, लेकिन ऐसा लगता है कि यह अब सक्रिय विकास के अधीन नहीं है और यह स्पष्ट नहीं है कि इसमें lsyncd जैसा स्वचालित ट्रिगर है।

मैंने ग्लस्टर का उल्लेख देखा है , लेकिन शायद मुझे जो चाहिए, उसके लिए ओवरकिल हो?

अद्यतन: fyi- मैंने अपने मूल समाधान के साथ जाना समाप्त कर दिया है: lsyncd + csync2। यह काफी अच्छा काम करता है, और मुझे लगता है कि सर्वरों के वास्तुशिल्प दृष्टिकोण को बहुत ही शिथिल रूप से शामिल किया गया है, ताकि प्रत्येक सर्वर अनिश्चित काल तक अपने बीच लिंक गुणवत्ता की परवाह किए बिना काम कर सके।


आपको किस प्रकार के परिवर्तनों को संभालने की आवश्यकता है? ईजी निर्माण, विलोपन, संशोधन।
sciurus

इसके अलावा, क्या आप संघर्षों की उम्मीद करते हैं? क्या दोनों सर्वरों पर एक ही फाइल को संशोधित किया जा सकता है?
sciurus

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

जवाबों:


5

एक प्रॉक्सी के साथ दोहरे प्राथमिक मोड में DRBD एक विकल्प है।


प्रॉक्सी न तो खुला स्रोत दिखता है और न ही मुक्त, सही? मुझे यकीन नहीं है कि मैं async मोड में एक प्रॉक्सी न होने के परिणाम को समझता हूं: एक विस्तारित डाउनटाइम के दौरान, अगर कोई प्रॉक्सी नहीं है, तो [छोटा?] आउटपुट बफर भर सकता है और हम सिंक खो देंगे? क्या इससे उबरना मुश्किल है?
dlo

मेरा जवाब ऊपर देखिए। मुझे नहीं लगता कि प्रॉक्सी वह चीज है जिसकी आपको जरूरत है। यहां तक ​​कि एक छोटे डाउनटाइम के दौरान ड्रब-मेटा-डिवाइस "गंदे" ब्लॉकों को चिह्नित करेगा और कनेक्शन फिर से होने के बाद उन्हें स्थानांतरित कर देगा। मुझे लगता है कि प्रॉक्सी और async-mode के बीच मुख्य अंतर यह है कि async-mode कुछ एमबी के अधिकतम बफर का उपयोग करता है। उसके बाद यह बफर को फिर से भरने के लिए मधुमक्खी को सिंक करता है। प्रॉक्सी संभवतः एक बड़े बफर के लिए अनुमति देता है (यदि आपके पास बड़ी विलंबता है या दूरस्थ रूप से स्थानीय रूप से बहुत तेज़ी से लिख सकता है)।
नेल्स

2

सिंक्रनाइज़ करने के बजाय, एनएफएस पर एक ही फाइल सिस्टम को साझा क्यों नहीं किया जाता है?


2
एनएफएस भयानक है, बस भयानक है। एनएफएस से कुछ भी बेहतर होगा
अलीगैब्स

2
मल्टी-सर्वर सेटअप के मुख्य बिंदुओं में से एक विफलता / अतिरेक है। तो एक सर्वर को दूसरे के बिना जारी रखने में सक्षम होना चाहिए।
dlo

आपको अपने प्रश्न में इस बात का उल्लेख करना चाहिए कि - पूरी तरह से उचित जवाब देने के लिए वोट देने की आवश्यकता नहीं है!
बार्ट बी

fyi मैंने इसे डाउनवोट नहीं किया - किसी और ने किया। लेकिन हां, मुझे इसका उल्लेख करना चाहिए।
dlo

@ बर्ट: अच्छा - उन्होंने उल्लेख किया कि दो दूर के स्थलों पर समवर्ती पहुंच है। यहां तक ​​कि अगर आप HA-NFS को लगाते हैं जो कि एक बुरा समाधान होगा, क्योंकि एक तरफ NFS-पहुंच के दौरान विलंबता से पीड़ित होगा। और मैं नीचे नहीं था। लेकिन मैं `लंबे समय से एनएफएस व्यवस्थापक रहा हूँ अलीगैब्स का समर्थन करने के लिए। : - /
नील

2

एक वितरित फाइल सिस्टम को लागू करना संभवतः टूल और स्क्रिप्ट के साथ इसे हैक करने से बेहतर है, खासकर अगर सर्वर का क्लस्टर बढ़ेगा। आप एक बेहतर नोड को बेहतर तरीके से संभाल पाएंगे।

मुझे नहीं लगता कि ग्लस्टर (या एएफएस) बिल्कुल ओवरकिल है।


ग्लस्टर के लिए 1 जीबी रैम की आवश्यकता है? gluster.com/community/documentation/index.php/… ... मैं एक VPS पर भी हूं, इसलिए मुझे कर्नेल स्तर के परिवर्तन करने के बारे में निश्चित नहीं है जो AFS की आवश्यकता हो सकती है। लेकिन मैं यह देखना शुरू कर रहा हूं कि एक उचित वितरित एफएस बेहतर मार्ग है।
dlo

हाँ, क्षमा करें, मैंने पहले नहीं पकड़ा था कि आप VPS होस्ट का उपयोग कर रहे थे। सर्वर और क्लाइंट दोनों की मेमोरी मेमोरी के पैरों के निशान छोटे नहीं हैं और वे काफी हद तक बढ़ सकते हैं। DRBD अधिक उपयुक्त लगता है।

AFS जाने का रास्ता है।
एंथनी जियोर्जियो

2

आपके मामले में मैं दोहरे प्राथमिक मोड और gfs या ocfs में DRBD के संयोजन की सिफारिश करूंगा।

दोहरे प्राथमिक में DRBD की खामी यह है कि यह सिंक्रोनस मोड में चल रहा होगा। लेकिन राइट-स्पीड यहां महत्वपूर्ण नहीं लगती है?

DRBD का एक विकल्प कई (2+) iSCSI- लक्ष्य का उपयोग करके एक Soft-Raid1 हो सकता है - लेकिन मैं दो नोड्स के साथ DRBD को प्राथमिकता दूंगा।


1
सिंक्रोनस मोड खराब होगा - मुझे इसकी आवश्यकता नहीं है, और मैं प्रदर्शन को कम नहीं करना चाहूंगा क्योंकि सर्वर महाद्वीपों में एक वान से अधिक जुड़े हुए हैं। लेकिन क्या आप एएसयूएन मोड में दोहरे प्राथमिक नहीं कर सकते हैं?
dlo

मैं वर्तमान में DRBD 8.3.5 का उपयोग कर रहा हूं - वहां आपको डुअल प्राइमरी मोड में आने के लिए सिंक-मोड ("C") में होना चाहिए। मुझे DRBD प्रॉक्सी के साथ कोई व्यक्तिगत अनुभव नहीं है, लेकिन यह वेरिटास वॉल्यूम रेप्लिकेटर के समान प्रतीत होता है - लेकिन यह दोनों पक्षों के लेखन-अभिगम के बाद से संभवत: अनुकूल नहीं है। ब्लॉक-स्तर पर सिंक मोड उतना बुरा नहीं हो सकता है जितना आप सोचते हैं - शायद gfs और / या ocfs लिख सकते हैं।
नेल्स

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

0

जैसा कि ऊपर दिखाया गया है, कई समाधान उपलब्ध हैं, प्रत्येक इसके फायदे और कमियां हैं।

मुझे लगता है कि मैं पूरे पेड़ को संस्करण नियंत्रण ( उदाहरण के लिए तोड़फोड़ ) के तहत रखने और समय-समय पर जाँच / क्रोन नौकरियों में दोनों सर्वरों से अपडेट करने पर विचार करूंगा ।


0

बस एक ही चीज़ के संबंध में कुछ हद तक समाप्त होने के बाद, मैं चमक के साथ जा रहा हूं। हालाँकि, मैंने कोई प्रदर्शन परीक्षण नहीं किया है या नहीं किया है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.