দূরবর্তী সার্ভারগুলির সাথে 1 মিলিয়ন ফাইলকে দক্ষতার সাথে সিঙ্ক্রোনাইজ করার বিকল্পগুলি?


27

যে সংস্থায় আমি কাজ করি সেখানে আমাদের কাছে "প্লেলিস্ট" নামে একটি জিনিস রয়েছে যা প্রতিটি ছোট ফাইল ~ 100-300 বাইট। তাদের মধ্যে প্রায় এক মিলিয়ন রয়েছে। এর মধ্যে প্রায় 100,000 প্রতি ঘন্টা পরিবর্তন হয় get এই প্লেলিস্টগুলি প্রতি ঘন্টা বিভিন্ন মহাদেশে 10 টি অন্যান্য রিমোট সার্ভারে আপলোড করা প্রয়োজন এবং এটি 2 মিনিটের নিচে আদর্শভাবে হওয়া দরকার। এটি অত্যন্ত গুরুত্বপূর্ণ যে মাস্টারে মুছে ফেলা ফাইলগুলি সমস্ত প্রতিরূপেও মুছে ফেলা হয়। আমরা বর্তমানে আমাদের পরিকাঠামোর জন্য লিনাক্স ব্যবহার করি।

আমি সামগ্রীর সাথে তুলনা না করে পুরো ফাইলগুলি অনুলিপি করতে -W বিকল্পের সাথে আরএসসিএনসি চেষ্টা করার কথা ভাবছিলাম। আমি এখনও এটি চেষ্টা করি নি তবে সম্ভবত যাদের সাথে আরএসসিএনসি নিয়ে বেশি অভিজ্ঞতা আছে তারা যদি বলতে পারেন যে এটি একটি কার্যকর বিকল্প কি না?

অন্যান্য বিকল্পগুলি বিবেচনা করার মতো?

আপডেট: আমি উত্তর হিসাবে lsyncd বিকল্পটি বেছে নিয়েছি তবে কেবল এটি সর্বাধিক জনপ্রিয়। অন্যান্য প্রস্তাবিত বিকল্পগুলিও তাদের নিজস্ব উপায়ে বৈধ।


1
কোন ফাইল পরিবর্তন বা মুছে ফেলা হয়েছে তা নির্দেশ করে আপনার কাছে কি কোনও লগ রয়েছে?
অলিভার

3
যদি কেবল প্লেলিস্টগুলি মাইএসকিএল রেকর্ড থাকে। এরপরে আপনি ডাটাবেস প্রতিলিপি ব্যবহার করতে পারেন এবং কী কী পাঠাতে / গ্রহণ করা দরকার তা নিয়ে কাজ করতে মাইএসকিএল পেতে পারেন।
ম্যাট

@ অলিভার আমরা যা করি তবে আপনাকে বিশ্বাস করতে হবে যে লগটির অর্থ কোডটি উত্পন্ন করার অর্থ এটি সঠিক হতে হবে এবং তারপরে সেই লগটি প্রক্রিয়া করার জন্য আপনার কাস্টম কোডের প্রয়োজন যা এটিও সঠিক হওয়া দরকার। সম্প্রদায় দ্বারা ব্যাপকভাবে পরীক্ষা করা হয়েছে এমন কিছু করার জন্য আমি ঘরের বিল্ট কোড এড়াতে চাই।
জিলভিনাস

আপনি কি পরিবর্তনটি প্রতি ঘণ্টায় কেবল প্রয়োগ করতে চান ? বা তাত্ক্ষণিক প্রতিলিপি গ্রহণযোগ্য?
faker

1
এক মিলিয়ন ফাইলে কাজ করতে আরএসসিএন লাগার সময়টিকে অবমূল্যায়ন করবেন না। এটি চেষ্টা করুন এবং আপনি কী করবেন তা দেখতে পাবেন। আপনার যদি লগ থাকে তবে এটি ব্যবহার করুন বা প্রস্তাবিত সমাধানগুলির কোনও অন্য চেষ্টা করুন।
অলিভার

উত্তর:


39

যেহেতু তাত্ক্ষণিক আপডেটগুলিও গ্রহণযোগ্য, আপনি lsyncd ব্যবহার করতে পারেন ।
এটি ডিরেক্টরি দেখায় (inotify) এবং দাসগুলিতে rsyncপরিবর্তিত হবে ।
প্রারম্ভকালে এটি একটি পূর্ণ কাজ করবে rsync, যাতে এতে কিছুটা সময় লাগবে, তবে এর পরে কেবল পরিবর্তনগুলিই সঞ্চারিত হয়।
ডিরেক্টরিগুলির পুনরাবৃত্তি পর্যবেক্ষণ সম্ভব, যদি কোনও দাস সার্ভার সিঙ্কটি ডাউন থাকে তবে সিঙ্কটি ফিরে না আসা পর্যন্ত পুনরায় চেষ্টা করা হবে।

যদি এগুলি সবই একক ডিরেক্টরিতে হয় (বা ডিরেক্টরিগুলির একটি স্থির তালিকা) তবে আপনি ইনক্রনও ব্যবহার করতে পারেন ।
ত্রুটিটি হ'ল এটি ফোল্ডারগুলিকে পুনরাবৃত্তভাবে দেখার অনুমতি দেয় না এবং আপনাকে নিজেরাই সিঙ্ক কার্যকারিতা বাস্তবায়ন করতে হবে।


আবার একটি উজ্জ্বল টিপ :)
জিলভিনাস

1
+1 এটি মূলত একটি ক্যাশে সমন্বিত সমস্যা, একটি মনিটর যা পরিবর্তনকে ধাক্কা দেয় তা হ'ল সহজ সমাধান। lsyncdপ্রয়োগ করে ...
ক্রিস এস

1
আমি আপনার নির্দিষ্ট সার্ভার ওএসের জন্য প্রযোজ্য lsyncdএবং inotifyগভীরভাবে তদন্ত করব । উপলব্ধ ইনোটিফাই ওয়াচগুলির সংখ্যার সীমা রয়েছে। আমি বিশ্বাস করি যে আপনার নির্দিষ্ট লিনাক্স সংস্করণের উপর নির্ভর করে ডিফল্টটি প্রায় 1500 বা 8000 এর কাছাকাছি। সর্বাধিক কার্নেলগুলি আপনাকে সীমা বাড়াতে দেয়, তবে 1 মিলিয়ন ফাইলগুলি পর্যবেক্ষণ করা ব্যবহারিকের চেয়ে বেশি হতে পারে। এটি ২০০৮ সালে আমার পক্ষে কাজ করেনি Also এছাড়াও, অযৌক্তিক ইভেন্টের সারিটি আপনার প্রবণতা হারাতে পারে এবং এটি থেকে পুনরুদ্ধার করার জন্য আপনার একটি উপায় থাকা দরকার। আপনার ঘাঁটিগুলি আবরণে একটি সাবধানতার সাথে সুরক্ষিত lsyncdবাস্তবায়ন প্লাস rsync2012 এ এখন কাজ করতে পারে।
ওল্ড প্রো

2
আসলে এটি ডিরেক্টরিতে একটি iontifyকরে পৃথক ফাইল নয়। আপনি কত ডিরেক্টরি দেখতে পারেন? চেক করুন (সাধারণত 8192)। /proc/sys/fs/inotify/max_user_watches
faker

2
~ 50k ডিরেক্টরি সহ inotify সম্ভবত ভাল স্কেল হবে না scale ২০০৯ সালে আমরা যখন 100k ডিরেক্টরি সহ একই ধরণের পদ্ধতির চেষ্টা করেছি, তখন এটি সমস্ত ডিরেক্টরিতে সাবস্ক্রাইব করার জন্য কার্নেলটি দীর্ঘস্থায়ীভাবে নিয়ে গেছে। @ ওল্ডপ্রো হিসাবে এটি আমাদের পক্ষে কার্যকর হয়নি।
নিওভাটার

11

গ্লাস্টারএফএসের মতো বিতরণকৃত ফাইল সিস্টেম ব্যবহার করার বিষয়টি বিবেচনা করুন । প্রতিলিপি নির্মাণ ও মনের মধ্যে উপমা দিয়ে ডিজাইন করা হচ্ছে, GlusterFS 10 সার্ভারে আরো অনেক কিছু সহজে অ্যাড-হক inotify এবং জড়িত সমাধান চেয়ে স্কেল পারে rsync

এই নির্দিষ্ট ব্যবহারের ক্ষেত্রে, 10 টির প্রতিরূপের 10-সার্ভার গ্লাস্টারএফএস ভলিউম (যেমন প্রতি সার্ভারে 1 প্রতিলিপি / ইট) তৈরি করতে পারে, যাতে প্রতিটি প্রতিলিপিটি ভলিউমের প্রতিটি প্রতিরূপের নিখুঁত আয়না হতে পারে। গ্লাস্টারএফস স্বয়ংক্রিয়ভাবে সমস্ত প্রতিরূপে ফাইল সিস্টেম আপডেটগুলি প্রচার করে।

প্রতিটি অবস্থানের ক্লায়েন্টরা তাদের স্থানীয় সার্ভারের সাথে যোগাযোগ করবে, সুতরাং ফাইলগুলিতে পঠনের অ্যাক্সেস দ্রুত হবে। মূল প্রশ্নটি হ'ল লেখার বিলম্বটি গ্রহণযোগ্যভাবে কম রাখা যেতে পারে। উত্তর দেওয়ার একমাত্র উপায় এটি চেষ্টা করা।


গ্লাস্টারফসের জন্য +1
টম ও'কনর

8

আমি সন্দেহ করি এর rsyncজন্য স্বাভাবিক পদ্ধতিতে কাজ করবে, কারণ এক মিলিয়ন ফাইল স্ক্যান করা এবং এটি দূরবর্তী সিস্টেমে 10 বার তুলনা করতে দীর্ঘ সময় লাগবে। আমি এমন কিছু দিয়ে একটি সিস্টেম কার্যকর করার চেষ্টা করব যা inotifyপরিবর্তিত ফাইলগুলির একটি তালিকা রাখে এবং এগুলি দূরবর্তী সার্ভারগুলিতে ঠেলা দেয় (যদি এই পরিবর্তনগুলি অন্যভাবে লগ ইন না করে)) তারপরে আপনি এই তালিকাটি স্থানান্তর করার জন্য প্রয়োজনীয় ফাইলগুলি দ্রুত সনাক্ত করতে ব্যবহার করতে পারেন - এমনকি আরএসইএনসি (এমনকি এটির 10 টি সমান্তরাল উদাহরণ) দিয়েও।

সম্পাদনা করুন: কিছুটা কাজ করে আপনি এমনকি পরিবর্তনটি হওয়ার সাথে সাথে ফাইলগুলি অনুলিপি করতে এই ইনোটিফাই / লগ ওয়াচ পদ্ধতির ব্যবহার করতে পারেন।


5

আরও কিছু বিকল্প:

  • যখনই আপনি প্রাথমিক সার্ভারে কোনও ফাইল মুছবেন বা যুক্ত করবেন তখন অবিচ্ছিন্নভাবে সমস্ত রিমোট সার্ভারে একই ফাইলটি মুছে ফেলুন (বা যুক্ত) মুছে ফেলার জন্য রবিট এমকিউ বা গিয়ারম্যানে একটি কাজ Inোকান
  • ফাইলগুলি একটি ডাটাবেসে সংরক্ষণ করুন এবং রিমোট সার্ভারগুলিকে সিঙ্কে রাখার জন্য প্রতিলিপি ব্যবহার করুন।
  • আপনার যদি জেডএফএস থাকে তবে আপনি জেডএফএসের প্রতিলিপি ব্যবহার করতে পারেন
  • কিছু সানদের ফাইলের প্রতিলিপি রয়েছে। এটি ইন্টারনেটে ব্যবহার করা যায় কিনা আমার কোনও ধারণা নেই।

4

এই জন্য আদর্শ storybook ব্যবহারের ক্ষেত্রে মনে করা হয় MongoDB এবং হয়ত GridFS । যেহেতু ফাইলগুলি তুলনামূলকভাবে ছোট, তাই মঙ্গোডিবি একা যথেষ্ট হওয়া উচিত, যদিও গ্রিডেফএস এপিআই ব্যবহার করা সুবিধাজনক হতে পারে।

মঙ্গোডিবি একটি নোসকিএল ডাটাবেস এবং গ্রিডএফএস এর উপরে একটি ফাইল স্টোরেজ বিল্ড। মঙ্গোডিবির প্রতিলিপি এবং শারডিংয়ের জন্য অনেকগুলি বিকল্প রয়েছে , তাই এটি আপনার ব্যবহারের ক্ষেত্রে খুব ভালভাবে স্কেল করা উচিত।

আপনার ক্ষেত্রে আপনি সম্ভবত একটি প্রতিরূপ সেট দিয়ে শুরু করবেন যা আপনার প্রাথমিক ডেটাসেন্টারে অবস্থিত মাস্টার (সম্ভবত দ্বিতীয়টি, যদি আপনি একই স্থানে ফেলও করতে চান) এবং আপনার দশ "দাস" বিশ্বজুড়ে বিতরণ করে থাকে। তারপরে লেখার পারফরম্যান্স যথেষ্ট কিনা তা পরীক্ষা করতে লোড টেস্টগুলি করুন এবং আপনার নোডগুলিতে প্রতিলিপি বার বার পরীক্ষা করুন। আপনার যদি আরও পারফরম্যান্সের প্রয়োজন হয় তবে আপনি সেটআপটিকে একটি ঝাঁকুনিতে পরিণত করতে পারেন (বেশিরভাগ সার্ভারে রাইট লোড বিতরণের জন্য)। মংগোডিবি "সস্তা" হার্ডওয়্যার সহ বিশাল সেটআপগুলি স্কেলিংয়ের সাথে ডিজাইন করা হয়েছে, যাতে আপনি পারফরম্যান্সের উন্নতি করতে সস্তা সার্ভারের একটি ব্যাচ ফেলে দিতে পারেন।


0

আমি একটি এস 3 ব্যাকএন্ড ব্যবহার করব এবং তারপরে আমার যে সমস্ত সার্ভারগুলির প্রয়োজন তা কেবল এটিই মাউন্ট করব - এইভাবে, প্রত্যেকে যে কোনও উপায়ে তাত্ক্ষণিকভাবে সিঙ্ক হয়


স্টোরেজটি সিঙ্ক্রোনাইজ হওয়ার সাথে সাথে আপনাকে অ্যাপ্লিকেশনটি জানাতে হবে, সুতরাং আপনি আবার এক স্কোয়ারে ফিরে আসবেন, বা অ্যাপ্লিকেশনটিকে যখন কেউ এই প্লেলিস্টগুলিতে অ্যাক্সেস করবেন তখনই স্টোরেজটি পোল করতে হবে। পারফরম্যান্স উভয় ক্ষেত্রেই ভয়াবহ হবে।
ক্রিস এস

বাসি ডেটা ছাড়াই অ্যাপ্লিকেশনটি চলছে কিনা তা নিশ্চিত করার জন্য এই অ্যাপ্লিকেশনটিকে প্রতিবার প্লে তালিকায় অ্যাক্সেস করার সময় স্টোরেজটি পোল করার দরকার নেই just এছাড়াও, যদি এস 3 ব্যাকএন্ড হিসাবে ব্যবহৃত হয়, তবে অ্যাপ্লিকেশনটিকে প্রথমে ফাইলগুলি পোল করার প্রয়োজন হবে কেন? তারা সর্বদা আপ টু ডেট থাকবে
মিস্টার আইটি গুরু

0

একটি বিকল্প যা উল্লেখ করা হয়নি বলে মনে হচ্ছে তা হ'ল সমস্ত ফাইলকে একটি সংকুচিত ফাইলে সংরক্ষণাগারভুক্ত করা। এটির মাধ্যমে মোট আকারটি উল্লেখযোগ্যভাবে হ্রাস করা উচিত এবং লক্ষ লক্ষ পৃথক ফাইলের সাথে ডিলিং থেকে প্রাপ্ত সমস্ত ওভারহেড সরিয়ে নেওয়া উচিত। একটি বড় আপডেটে পুরো ফাইলের সেট প্রতিস্থাপন করে আপনি আশ্বাসও দিতে পারেন যে সরানো ফাইলগুলি প্রতিরূপে সরানো হয়েছে।

ডাউনসাইডটি অবশ্যই আপনি অকারণে অনেকগুলি ফাইল স্থানান্তর করছেন। সংকোচনের জন্য কমে যাওয়া আকারের দ্বারা এটি ভারসাম্যপূর্ণ হতে পারে বা নাও হতে পারে। এছাড়াও আমি জানি না যে এটি অনেকগুলি ফাইল সঙ্কুচিত করতে কত সময় লাগবে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.