पसंदीदा इलाके के साथ भौगोलिक रूप से वितरित फ़ाइल सिस्टम


11

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

  1. प्रत्येक साइट एक साझा "नेमस्पेस" में फाइल स्टोर कर सकती है। यही है, सभी फाइलें एक ही फाइल सिस्टम में दिखाई देंगी।
  2. जब तक आवश्यक न हो प्रत्येक साइट WAN पर डेटा नहीं भेजेगी। यानी, WAN के प्रत्येक तरफ स्थानीय भंडारण होगा जो उसी तार्किक फाइल सिस्टम में "मर्ज" किया जाएगा।
  3. लिनक्स और फ्री ($ $ $) एक प्लस है

मूल रूप से, एक केंद्रीय एनएफएस शेयर की तरह कुछ आवश्यकताओं को पूरा करेगा, हालांकि यह स्थानीय रूप से लिखित डेटा को स्थानीय रहने की अनुमति नहीं देगा। WAN के दूरस्थ पक्षों के सभी डेटा को हर समय स्थानीय रूप से कॉपी किया जाएगा।

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


नीचे पूछे गए कुछ सवालों के कुछ जवाब:

  • सर्वर नोड: 2 या 3 शुरू करने के लिए। प्रत्येक सर्वर में एक साथ दर्जनों रीडिंग / राइटिंग क्लाइंट होंगे।
  • WAN टोपोलॉजी पूर्ण जाल और विश्वसनीय है। (बड़े निगम, लागत लाल टेप के रूप में सीमित नहीं है)
  • क्लाइंट फेलओवर: मैंने वास्तव में क्लाइंट फेलओवर होने के बारे में नहीं सोचा था (ज्यादातर इसलिए कि हमारी वर्तमान प्रशंसा केवल एक साइट पर ऐसा नहीं करती है)। मुझे लगता है कि प्रैक्टिकल उत्तर यह है कि प्रत्येक भौगोलिक रूप से वितरित साइट पर सर्वरों को उन ग्राहकों के लिए विफलताओं के एकल बिंदु होने की उम्मीद है जो वे सेवा कर रहे हैं। हालाँकि, अगर आप यहाँ कुछ विशिष्ट के बारे में सोच रहे हैं, तो मुझे लगता है कि यह चर्चा में काफी जर्मन होगा।
  • रोल-माय-ओन: मैंने rsync / unison के बारे में सोचा है, हालाँकि मुझे इस काम का "गतिशील" हिस्सा मूल रूप से बनाने के लिए काफी फैंसी तर्क की आवश्यकता होगी। यानी, फ़ाइल स्थानीय प्रतीत होती है, लेकिन केवल मांग पर पुनर्प्राप्त की जाती है।
  • MS-DFS: यह निश्चित रूप से कुछ ऐसा प्रतीत होता है जिसे मुझे देखना चाहिए। मेरा मुख्य मुद्दा संभवतः विंडोज पर एनएफएस सर्वर कॉन्फ़िगरेशन / विश्वसनीयता / प्रदर्शन के बारे में अनिश्चित होगा, क्योंकि कनेक्ट करने वाले कई क्लाइंट एनएफएस क्लाइंट हैं।

लिनक्स और एक प्लस के लिए नि: शुल्क हार्ड का बदला हुआ हिस्सा।
dpb

जवाबों:


5

लिनक्स आवश्यकता के बारे में शर्म की बात है। यह वही है जो विंडोज डीएफएस करता है। 2003 R2 के बाद से, यह ब्लॉक-स्तर के आधार पर भी करता है।


क्रिस, जवाब के लिए धन्यवाद। मुझे लगता है कि डीएफएस सुंदर है जो मैं देख रहा हूं, हालांकि विंडोज पर। निश्चित रूप से मुझे देखने के लिए कुछ।
dpb

DFS ब्लॉक स्तर के आधार पर काम नहीं करता है। प्रतिकृति सेवा फ़ाइल के आधार पर गैर-लेन-देन है।
eckes

4

कुछ सवाल:

  • कितने "सर्वर" नोड आप इस चीज में भाग लेने के बारे में सोच रहे हैं?

  • WAN कनेक्टिविटी टोपोलॉजी क्या है - हब और स्पोक, फुल मेश? यह कितना विश्वसनीय है?

  • क्या आप अपेक्षा करते हैं कि स्थानीय सर्वर विफल होने की स्थिति में ग्राहकों को भौगोलिक रूप से गैर-स्थानीय सर्वर के विफल होने की उम्मीद है?

विंडोज डीएफएस-आर निश्चित रूप से आप जिस चीज की तलाश कर रहे हैं, वह कुछ संभावित मोटी लाइसेंस लागतों के लिए है।

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


उत्तर इवान के लिए धन्यवाद, मैंने आपके प्रश्न को उस डेटा से अपडेट किया है जो आप पूछ रहे थे। मुझे आपके unison / rsync विचार में दिलचस्पी है, लेकिन यह नहीं देखते कि गतिशील पहलू को कैसे संभाला जाएगा। (मुझे Unison के साथ बहुत अनुभव नहीं है, केवल rsync है)।
dpb

@dpb: मुझे आपके मूल संपादन में उस आवश्यकता का बोध नहीं हो रहा था। Microsoft DFS-R या तो ऐसा नहीं करेगा। ऑन-डिमांड पुनर्प्राप्ति व्यवहार को फ़ाइल स्टब्स के लिए अनुरोधों को पढ़ने के लिए फाइल सिस्टम में कुछ "सक्रिय" की आवश्यकता होती है, जिसमें उनका स्थानीय डेटा कैश नहीं है, डेटा प्राप्त करें, और रीड को पूरा करें। मैं किसी भी भौगोलिक रूप से वितरित filesysstem कि व्यवहार के बारे में पता नहीं कर रहा हूँ-- कि एक HSM की तरह अधिक है।
इवान एंडरसन

उन लोगों के लिए जो मेरे जैसा है: en.wikipedia.org/wiki/Hierarchical_storage_management । धन्यवाद फिर से @ इवान मैं अंतर्निहित स्टोरेज लोकेशन को डायनामिक तरीके से फिर से शुरू करने में दिलचस्पी नहीं रखता क्योंकि इसे शुरू में डायनामिक तरीके से चुनना। मुझे लगता है कि एचएसएम बहुत अच्छा लगता है, लेकिन मैं जो कर रहा हूं, उसके लिए यह बहुत अच्छा हिस्सा है।
dpb

3

क्या आपने AFS पर विचार किया है ?

एंड्रयू फाइल सिस्टम (एएफएस) एक वितरित नेटवर्क फ़ाइल प्रणाली है जो सभी क्लाइंट वर्कस्टेशनों के लिए एक सजातीय, स्थान-पारदर्शी फ़ाइल नाम स्थान पेश करने के लिए विश्वसनीय सर्वरों के एक सेट का उपयोग करता है।

जैसा कि मैं इसे समझता हूं, हाल ही के अधिकांश विकास OpenAFS परियोजना के पीछे रहे हैं ।

मैं यह जानने के लिए परियोजना के साथ पर्याप्त रूप से परिचित होने का नाटक नहीं कर सकता कि क्या "पसंदीदा इलाके" सुविधा उपलब्ध है, लेकिन अन्यथा यह एक अच्छा फिट लगता है।


1
CodaFS को भी देखें: en.wikipedia.org/wiki/Coda_%28file_system%29
blank3

1

क्या आपने चमक में OST पूल को देखा है ?

यह स्वचालित नहीं होगा, लेकिन OST पूल के साथ आप विशिष्ट OST / OSSes के लिए निर्देशिकाओं / फाइलों को निर्दिष्ट कर सकते हैं - मूल रूप से OST के दौरान डिफ़ॉल्ट राउंड-रॉबिन / स्ट्रिपिंग के बजाय नीति आधारित भंडारण आवंटन।

इसलिए आप प्रति साइट पर एक निर्देशिका सेटअप कर सकते हैं और उस निर्देशिका को उस साइट के लिए स्थानीय OSTs को असाइन कर सकते हैं, जो सभी I / O को स्थानीय OST को निर्देशित करेगा। यह अभी भी एक वैश्विक नामस्थान होगा।

WAN कनेक्शन (स्थानीय कैशिंग सर्वर और उस तरह की चीजें) पर चमक को बेहतर बनाने में बहुत काम हो रहा है, लेकिन यह अभी भी भारी विकास AFAIK के तहत है।


धन्यवाद @ जेम्स, यह लगभग वही है जो मैं देख रहा हूँ। मैं शीर्ष स्तर पर मुंगेड नामस्थान पर उत्सुक नहीं हूं (एक OST पूल में विशेष निर्देशिकाएं असाइन करता हूं), लेकिन शायद यह ठीक होगा। यह जानने के लिए कम से कम अच्छा है कि लस्टर में उपयोग का मामला और सीमा क्या है। एक बार फिर धन्यवाद!
dpb

1

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

इसके अलावा, mabye UnionFS देखने लायक है। इसके साथ मुझे लगता है कि प्रत्येक स्थान एक NFS निर्यात होगा, और फिर आप प्रत्येक स्थान पर UnionFS का उपयोग कर सकते हैं और स्थान से अन्य सभी NFS माउंट एक फाइलसिस्टम के रूप में दिखाई देते हैं। हालांकि मुझे इसका अनुभव नहीं है।


धन्यवाद @Kyle, मैं UnionFS के बारे में नहीं जानता था, आक्रामक कैशिंग के साथ, NFS इसके लिए एक अच्छा समाधान हो सकता है। मैं सोच रहा हूं कि स्थानों की संख्या बढ़ने के साथ इसे बनाए रखने के लिए अधिक परेशानी हो सकती है, लेकिन मैं निर्णय लेने से पहले इस पर गौर करने जा रहा हूं।
dpb

0

आप डिस्क को दोहराने के लिए DRBD में देख सकते हैं। http://www.drbd.org/ । यह एक लिनक्स उच्च उपलब्धता समाधान है जो अभी इसे कर्नेल में बनाता है।

हालाँकि, इसकी कुछ सीमाएँ हैं:

  1. केवल दो नोड सेट किए जा सकते हैं
  2. DRBD को मजबूत रखने के लिए WAN बहुत अविश्वसनीय हो सकता है।

दिलचस्प विचार है, हालांकि मुझे नहीं लगता कि यह मेरे आवेदन को अन्य वितरित फाइल सिस्टम पर कुछ भी देगा। (चमक, चमक, आदि)। पोस्ट करने के लिए धन्यवाद ...
dpb

0

यदि आप इसे सरल रखना चाहते हैं, तो एक नज़र एक rsync है, बहुत सारी समस्याओं को हल करता है और इसे स्क्रिप्ट किया जा सकता है।


0

Chironfs पर जाँच करें ।

शायद यह वही कर सकता है जो आप चाहते हैं, फ़ाइल सिस्टम के आधार पर।


0

Btsync एक और समाधान है जिसके साथ मुझे अच्छा अनुभव हुआ है। यह फ़ाइलों को स्थानांतरित करने के लिए बिटटोरेंट प्रोटोकॉल का उपयोग करता है, इसलिए आपके पास जितने अधिक सर्वर होंगे उतनी ही तेजी से नई फ़ाइलों को सिंक्रनाइज़ करना होगा।

Rsync- आधारित समाधान के विपरीत, यह पता लगाता है कि जब आप फ़ाइलों / फ़ोल्डरों का नाम बदलते हैं, और उन्हें हटाएं / कॉपी के बजाय सभी नोड्स पर नाम बदल देते हैं।

Yout btsync क्लाइंट स्थानीय फ़ोल्डर पर फ़ोल्डर साझा कर सकते हैं।

एकमात्र नकारात्मक पहलू जो मुझे मिला (एमएस डीएफएस की तुलना में) यह है कि यह एक स्थानीय फाइल कॉपी का पता नहीं लगाएगा। इसके बजाय यह सभी साथियों के लिए अपलोड की गई एक नई फ़ाइल के रूप में व्याख्या करेगा।

अब तक btsync सबसे अच्छा सिंक्रोनाइज़ेशन समाधान लगता है और इसे विंडोज, लिनक्स, एंड्रॉइड और एआरएम डिवाइस (जैसे नेट) पर इंस्टॉल किया जा सकता है

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