আমরা সম্প্রতি রেডিস টেকনিক্যাল পার্টনার প্রোগ্রামে অনবোর্ডিং করার একটি ধাপ হিসেবে Helios এবং Redis Enterprise-এর মধ্যে একীকরণ যাচাই করার জন্য Cohesity টিমের সাথে কাজ করার সুযোগ পেয়েছি। কোহেসিটি স্মার্টফাইলস, একটি পরিষেবা যা হেলিওসে চলে, ডেটা যেখানেই থাকুক না কেন, অসংগঠিত ডেটার একক দৃশ্য এবং বিশ্বব্যাপী ব্যবস্থাপনা প্রদান করে। রেডিস এন্টারপ্রাইজের প্রেক্ষাপটে, স্মার্টফাইলস ডাটাবেস স্ন্যাপশটগুলির একক দৃশ্য প্রদান করে৷
কেন আমরা অধ্যবসায় এবং ব্যাকআপ নিয়ে বিরক্ত? এটি সত্য:যদি রেডিস একটি ক্যাশে হিসাবে ব্যবহার করা হয় এবং ন্যূনতম সিস্টেম প্রভাব সহ একটি ব্যাকএন্ড ডাটাবেস থেকে পুনরায় হাইড্রেট করা যায়, তবে এর কোনও প্রয়োজন নেই। অন্যদিকে, ধীরগতির ডেটাতে দ্রুত অ্যাক্সেস দেওয়ার জন্য কখন Redis একটি অপারেশনাল ডাটাবেস হিসাবে ব্যবহার করা হয় তা বিবেচনা করুন (মনে করুন:লেনদেনের ইতিহাস, ইনভেন্টরি গণনা, গ্রাহকের সন্ধান)। Redis ডাটাবেসকে দ্রুত হার্ডওয়্যার সমস্যা থেকে পুনরুদ্ধার করতে হবে বা এমনকি অন্য ডেটাসেন্টারে ফেইলওভার করতে হবে।
অধ্যবসায়
রেডিস ডাটাবেসের সমস্ত ডেটা একচেটিয়াভাবে RAM বা RAM + ফ্ল্যাশ মেমরি (ফ্ল্যাশে রেডিস); এটি একটি প্রক্রিয়া বা সার্ভার ব্যর্থতার কারণে হারিয়ে যাওয়ার ঝুঁকিতে রয়েছে৷ এই ঝুঁকি কমানোর জন্য বেশ কয়েকটি কৌশল অনুসরণ করা যেতে পারে:প্রাথমিক এবং মাধ্যমিক ডেটা শার্ড সহ উচ্চ প্রাপ্যতা (HA) ডেটাবেস, জিও-ডিস্ট্রিবিউটেড সক্রিয়-সক্রিয় ডেটাবেস এবং অবশ্যই ডিস্ক ভিত্তিক অধ্যবসায়। পারফরম্যান্সের দৃষ্টিকোণ থেকে, এটি সর্বদা একটি প্রাথমিক ডাটাবেস শার্ড থেকে একটি সিঙ্ক্রোনাইজড সেকেন্ডারি ডাটাবেস শার্ডে ফেইলওভার করতে পছন্দ করে এবং এইভাবে রেডিস এন্টারপ্রাইজ কাজ করে; শুধুমাত্র প্রাথমিক এবং মাধ্যমিক শার্ডগুলি হারিয়ে গেলেই ডিস্ক থেকে ডাটাবেস পুনরুদ্ধার করা হয়। একইভাবে, একটি ডেটাসেন্টার ব্যর্থতার ক্ষেত্রে, অন্য ডেটা সেন্টারে একটি সিঙ্ক্রোনাইজড সক্রিয়-সক্রিয় ডেটাবেসে ব্যর্থ হওয়া ডিস্ক থেকে পুনরুদ্ধারের চেয়ে দ্রুততর হবে৷
অধ্যবসায়ের প্রশ্নে, রেডিস আরও ভাল স্থায়িত্বের জন্য শুধুমাত্র-সংযোজিত ফাইলগুলি (AOF) সমর্থন করে, যদিও আরও সংস্থান প্রয়োজন, এবং স্ন্যাপশটগুলি (RDB), যা কম টেকসই এবং কম সংস্থানগুলির প্রয়োজন হয়৷ সমস্ত জিনিসের মতো, সেখানে ট্রেডঅফ রয়েছে যা রেডিস এন্টারপ্রাইজ ডকুমেন্টেশনে আরও অনুসন্ধান করা যেতে পারে। এই নিবন্ধটির উদ্দেশ্যে, আমরা ধরে নেব যে আমরা আরও ভালো স্থায়িত্বের জন্য AOF চাই।
ব্যাকআপ
রেডিস এন্টারপ্রাইজ পুনরুদ্ধারের জন্য অধ্যবসায়ের উপর নির্ভর করে যখন প্রাথমিক এবং মাধ্যমিক উভয় ডাটাবেস শার্ড হারিয়ে যায়। যদি সক্রিয়-সক্রিয় ব্যবহার না করা হয় এবং সংযুক্ত স্টোরেজ সহ ডাটাবেসগুলির র্যাকগুলি হারিয়ে যায়, তাহলে আমাদের ব্যাকআপ থেকে পুনরুদ্ধার করা বাকি থাকে। রেডিস এন্টারপ্রাইজের ক্ষেত্রে, একটি ব্যাকআপ সর্বদা একটি স্ন্যাপশট হয়, যা, অধ্যবসায়ের জন্য AOF এর সাথে মিলিত হলে, একটি স্থিতিস্থাপক এবং টেকসই ডেটা প্ল্যাটফর্ম তৈরি করে৷
এখানেই কোহেসিটি স্মার্টফাইলস খেলায় আসে; Redis Enterprise ক্লাউড জুড়ে পরিচালিত ব্যাকআপগুলির জন্য স্মার্টফাইলস দ্বারা সুবিধাজনকভাবে সরবরাহ করা S3 সামঞ্জস্যপূর্ণ এন্ডপয়েন্ট ব্যবহার করে৷ এটি সেট আপ করতে, আমরা নিম্নলিখিত অনুমান সহ Redis Enterprise REST API ব্যবহার করি:
- $USER এবং $PASS যথাক্রমে Redis Enterprise অ্যাডমিন ব্যবহারকারীর নাম এবং পাসওয়ার্ড সেট করা আছে
- $ACCESS_KEY এবং $SECRET_KEY যথাক্রমে S3 অবজেক্ট স্টোর অ্যাক্সেস কী এবং সিক্রেট কী সেট করা হয়েছে
ডেটাবেস অধ্যবসায় সক্ষম করুন৷
৷curl -s -k -u $USER:$PASS -H content-type:application/json -XPUT https://localhost:9443/v1/bdbs/1 -d '{"data_persistence":"aof" }' S3 URL সেট করে S3 অবজেক্ট স্টোর ব্যবহার করার জন্য ক্লাস্টার কনফিগার করুন। মনে রাখবেন বালতির নামটি S3 URL-এ অন্তর্ভুক্ত নয়৷
৷curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT https://localhost:9443/v1/cluster -d '{"s3_url":'\"$ S3_IP\"'}' শুধুমাত্র গোপনীয়তার জন্য ক্লাস্টার S3 ব্যাকআপ কনফিগার করুন।
curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT https://localhost:9443/v1/cluster -d '{"s3_certificate_verification":false}'
ব্যাকআপ অবস্থান যাচাই করুন. লক্ষ্য করুন সাফল্যের একমাত্র প্রতিক্রিয়া হল একটি HTTP 200 ওকে৷
৷ curl -s -k -u $USER:$PASS -H content-type:application/json -X POST https://localhost:9443/v1/bdbs/actions/validate_backup_location -d '{"backup_location":{"type":"s3", "bucket_name":'\"$BUCKET\"', "subdir":"","access_key_id":'\"$ACCESS_KEY\", "secret_access_key":'\"$ SECRET_KEY\"}}'
একটি ব্যাকআপ তৈরি করুন। লক্ষ্য করুন সাফল্যের একমাত্র প্রতিক্রিয়া হল একটি HTTP 200 ওকে৷
৷ curl -s -k -u $USER:$PASS -H content-type:application/json -X POST https://localhost:9443/v1/bdbs/1/actions/export -d '{"export_location ":{"type":"s3", "bucket_name":'\"$BUCKET\"', "subdir":"", "access_key_id":'\"$ACCESS_KEY\"', "secret_access_key":'\ "$SECRET_KEY\"'}}'
প্রতি 30 মিনিটে একটি পুনরাবৃত্ত ব্যাকআপ কনফিগার করুন। লক্ষ্য করুন সাফল্যের একমাত্র প্রতিক্রিয়া হল একটি HTTP 200 ওকে৷
৷ curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT https://localhost:9443/v1/bdbs/1 -d '{"backup":true, "backup_interval":1800, "backup_interval_offset":360, "backup_location":{"type":"s3", "bucket_name":'\"$BUCKET\", "subdir":"", "access_key_id":' \"$ACCESS_KEY\", "secret_access_key":'\"$SECRET_KEY\"'}}' চূড়ান্ত চিন্তা
একটি ঘর্ষণহীন বিশ্বে, HA এবং Active-Active-এর সাথে কনফিগার করা Redis Enterprise আপনাকে অধ্যবসায় এবং ব্যাকআপ নিয়ে উদ্বেগ থেকে বাঁচায়। আমরা একটি ঘর্ষণহীন বিশ্বে বাস করি না এবং যখন রেডিস সিস্টেম ব্যর্থতা থেকে পুনরুদ্ধার করার আশা করা হয় তখন আমাদের অধ্যবসায় এবং ব্যাকআপ (HA সহ) উভয়েরই প্রয়োজন। এটি একটি S3 ব্যাকআপ এন্ডপয়েন্ট দেখা সাধারণ যেটি Dell EMC, NetApp, বা বিশুদ্ধ স্টোরেজের পছন্দের অ্যাপ্লায়েন্স অফার দ্বারা দেখা যায়। সৌভাগ্যবশত, Cohesity SmartFiles-এর সাথে যাচাইকৃত ইন্টিগ্রেশন এই এন্ডপয়েন্টটি ব্যবহার করা এবং অপারেশনাল কৌশলগুলিতে ব্যাকআপ অন্তর্ভুক্ত করা সহজ করে তোলে৷
