আমাদের প্রসেসিংয়ের জন্য আমরা একটি গ্লাস্টারএফএস ক্লাস্টার ব্যবহার করি। আমরা উইন্ডোজটিকে এতে একীভূত করতে চাই, তবে গ্লাস্টারএফএস ভলিউম পরিবেশনকারী সাম্বা সার্ভার যে সিঙ্গল-পয়েন্ট-অফ-ব্যর্থতা এড়াতে হবে তা নির্ধারণ করতে কিছুটা সমস্যা হচ্ছে।
আমাদের ফাইল-প্রবাহ এইভাবে কাজ করে:
- ফাইলগুলি একটি লিনাক্স প্রসেসিং নোড দ্বারা পড়া হয়।
- ফাইলগুলি প্রক্রিয়াজাত হয়।
- ফলাফলগুলি (ছোট হতে পারে, বেশ বড় হতে পারে) গ্লাস্টারএফএস ভলিউমে শেষ হওয়ার সাথে সাথে আবার লেখা হয়।
- পরিবর্তে কোনও ডাটাবেজে ফলাফল লেখা যেতে পারে বা বিভিন্ন আকারের বেশ কয়েকটি ফাইল অন্তর্ভুক্ত থাকতে পারে।
- প্রসেসিং নোডটি সারি এবং GOTO 1 এর বাইরে অন্য একটি কাজ বেছে নেয়।
গ্লাস্টার দুর্দান্ত কারণ এটি বিতরণকৃত ভলিউম এবং তাত্ক্ষণিক প্রতিলিপি সরবরাহ করে। দুর্যোগের স্থিতিস্থাপকতা দুর্দান্ত! আমরা এটা পছন্দ করি.
তবে উইন্ডোজের দেশীয় গ্লাস্টারএফএস ক্লায়েন্ট না থাকায় আমাদের উইন্ডোজ ভিত্তিক প্রসেসিং নোডগুলির জন্য অনুরূপভাবে নমনীয় উপায়ে ফাইল স্টোরের সাথে যোগাযোগের জন্য কিছু উপায় প্রয়োজন। GlusterFS ডকুমেন্টেশন রাজ্যের উপায় উইন্ডোজ অ্যাক্সেস প্রদান করার জন্য একটি উপরে একটি সাম্বা সার্ভার সেট আপ করার জন্য যে GlusterFS ভলিউম মাউন্ট করা। এটি এর ফলে একটি ফাইল প্রবাহকে নিয়ে যাবে:
এটি আমার কাছে একক পয়েন্ট অফ ব্যর্থতার মতো দেখাচ্ছে।
একটি বিকল্প হ'ল সাম্বা ক্লাস্টার করা , তবে এটি এখনই অস্থির কোডের উপর ভিত্তি করে প্রদর্শিত হবে এবং এভাবে চলমান নেই।
সুতরাং আমি অন্য পদ্ধতি খুঁজছি।
আমাদের চারপাশে যে ধরণের ডেটা ফেলা হয় সে সম্পর্কে কয়েকটি মূল বিবরণ:
- আসল ফাইল-আকারগুলি কয়েক কেবি থেকে কয়েক দশক জিবি পর্যন্ত হতে পারে।
- প্রসেস করা ফাইল-আকারগুলি কয়েক কেবি থেকে কোনও জিবি বা দুটি পর্যন্ত যে কোনও জায়গায় হতে পারে।
- কিছু প্রক্রিয়া, যেমন .zip বা .tar এর মতো সংরক্ষণাগার ফাইলটিতে খনন করা ফাইলগুলি ফাইল-স্টোরে আমদানি করা হওয়ায় আরও অনেক বেশি লেখার কারণ হতে পারে।
- ফাইল গণনা 10 মিলিয়নে প্রবেশ করতে পারে।
এই কাজের চাপটি "স্ট্যাটিক ওয়ার্কুনিট সাইজ" হ্যাডোপ সেটআপের সাথে কাজ করে না। একইভাবে, আমরা এস 3-স্টাইলের অবজেক্ট-স্টোরগুলি মূল্যায়ন করেছি তবে সেগুলির অভাব দেখতে পেয়েছি।
আমাদের অ্যাপ্লিকেশনটি রুবিতে লেখা কাস্টম এবং উইন্ডোজ নোডগুলিতে আমাদের একটি সাইগউইন পরিবেশ রয়েছে। এটি আমাদের সাহায্য করতে পারে।
একটি বিকল্প যা আমি বিবেচনা করছি তা হ'ল গ্লাস্টারএফএস ভলিউম মাউন্ট করা সার্ভারগুলির একটি ক্লাস্টারে একটি সাধারণ এইচটিটিপি পরিষেবা। যেহেতু আমরা গ্লাস্টার দিয়ে যা করছি তার সবগুলিই মূলত জিইটি / পুট অপারেশন, এটি কোনও এইচটিটিপি-ভিত্তিক ফাইল স্থানান্তর পদ্ধতিতে সহজেই স্থানান্তরযোগ্য বলে মনে হয়। এগুলি একটি লোডবালেন্সার জোড়ের পিছনে রাখুন এবং উইন্ডোজ নোডগুলি তাদের সামান্য নীল হৃদয়ের সামগ্রীতে HTTP পুট করতে পারে।
আমি যা জানি না তা হ'ল কীভাবে গ্লাস্টারএফএসের সমন্বয় বজায় রাখা হবে । এইচটিটিপি-প্রক্সি স্তরটি প্রসেসিং নোড যখন লেখার সাথে এটি সম্পন্ন করেছে এবং যখন এটি আসলে গ্লাস্টারএফএস ভলিউমে প্রদর্শিত হবে তখন তার মধ্যে পর্যাপ্ত পরিমাণে বিলম্বের পরিচয় দেয় যে পরবর্তী প্রক্রিয়া প্রক্রিয়াটি ফাইলটি বাছাইয়ের চেষ্টা করার বিষয়ে আমি উদ্বিগ্ন won't খুজেন. আমি নিশ্চিত যে direct-io-mode=enableমাউন্ট-অপশনটি ব্যবহার করা সাহায্য করবে তবে আমি যথেষ্ট নই যে এটি যথেষ্ট কিনা । একাত্মতা উন্নত করার জন্য আমার আর কী করা উচিত?
অথবা আমার পুরোপুরি অন্য কোনও পদ্ধতি অনুসরণ করা উচিত?
টম যেমন নীচে নির্দেশ করেছেন, এনএফএস অন্য বিকল্প another তাই আমি একটি পরীক্ষা চালিয়েছি। যেহেতু উল্লিখিত ফাইলগুলির ক্লায়েন্ট-সরবরাহ করা নাম রয়েছে যা আমাদের রাখা দরকার এবং যে কোনও ভাষায় আসতে পারে, তাই আমাদের ফাইল-নাম সংরক্ষণের প্রয়োজন। সুতরাং আমি এই ফাইলগুলি দিয়ে একটি ডিরেক্টরি তৈরি করেছি:
যখন আমি এটিকে এনএফএস ক্লায়েন্ট ইনস্টল করে একটি সার্ভার ২০০৮ আর 2 সিস্টেম থেকে মাউন্ট করব, তখন আমি এর মতো ডিরেক্টরি তালিকা পাই:
স্পষ্টতই, ইউনিকোড সংরক্ষণ করা হচ্ছে না। সুতরাং এনএফএস আমার পক্ষে কাজ করে না।
ctdbস্থিতিশীল এবং উত্পাদন ব্যবহারের জন্য প্রস্তুত বিবেচনা করে এবং আপনার দেওয়া লিঙ্কের প্রথম বাক্যটি দ্বিতীয়টি অবৈধ করে তোলে কারণ যদি কখনও আপডেট হয় না। আমি এটি প্রতিষ্ঠা করার পরিকল্পনা করছিলাম, তবে এটির আগেই আমি প্রায় উইন্ডোজ মুক্ত পরিবেশে চাকরি সরিয়ে নিয়েছি।