কিভাবে একটি কঠোর এন্টারপ্রাইজ পরিবেশে "ফ্রি" PostgreSQL ফিট করা যায়

অনেক লোক PostgreSQL DBMS এর সাথে পরিচিত, এবং এটি ছোট ইনস্টলেশনে নিজেকে প্রমাণ করেছে। যাইহোক, ওপেন সোর্সের দিকে প্রবণতা ক্রমশ স্পষ্ট হয়ে উঠেছে, এমনকি যখন এটি বড় কোম্পানি এবং এন্টারপ্রাইজের প্রয়োজনীয়তার ক্ষেত্রে আসে। এই নিবন্ধে আমরা আপনাকে একটি কর্পোরেট পরিবেশে পোস্টগ্রেসকে কীভাবে একীভূত করতে হয় তা বলব এবং উদাহরণ হিসাবে Commvault ব্যাকআপ সিস্টেম ব্যবহার করে এই ডাটাবেসের জন্য একটি ব্যাকআপ সিস্টেম (BSS) তৈরি করার আমাদের অভিজ্ঞতা শেয়ার করব।

PostgreSQL ইতিমধ্যেই এর মূল্য প্রমাণ করেছে - DBMS দুর্দান্ত কাজ করে, এটি আলিবাবা এবং TripAdvisor-এর মতো ফ্যাশনেবল ডিজিটাল ব্যবসার দ্বারা ব্যবহৃত হয় এবং লাইসেন্সিং ফি এর অভাব এটিকে MS SQL বা Oracle DB-এর মতো দানবদের জন্য একটি লোভনীয় বিকল্প করে তোলে। কিন্তু যত তাড়াতাড়ি আমরা এন্টারপ্রাইজ ল্যান্ডস্কেপে PostgreSQL সম্পর্কে চিন্তা করা শুরু করি, আমরা অবিলম্বে কঠোর প্রয়োজনীয়তার মধ্যে চলে যাই: “কনফিগারেশন ফল্ট সহনশীলতা সম্পর্কে কী? দুর্যোগ প্রতিরোধ? ব্যাপক পর্যবেক্ষণ কোথায়? স্বয়ংক্রিয় ব্যাকআপ সম্পর্কে কি? সরাসরি এবং সেকেন্ডারি স্টোরেজ উভয় ক্ষেত্রেই টেপ লাইব্রেরি ব্যবহার করার বিষয়ে কী হবে?"


একদিকে, PostgreSQL-এর বিল্ট-ইন ব্যাকআপ টুল নেই, যেমন "প্রাপ্তবয়স্ক" DBMS যেমন Oracle DB-এ RMAN বা SAP ডেটাবেস ব্যাকআপ। অন্যদিকে, কর্পোরেট ব্যাকআপ সিস্টেমের সরবরাহকারীরা (Veeam, Veritas, Commvault) যদিও তারা PostgreSQL সমর্থন করে, আসলে তারা শুধুমাত্র একটি নির্দিষ্ট (সাধারণত স্বতন্ত্র) কনফিগারেশন এবং বিভিন্ন সীমাবদ্ধতার সেটের সাথে কাজ করে।

PostgreSQL-নির্দিষ্ট ব্যাকআপ সিস্টেম যেমন Barman, Wal-g, এবং pg_probackup ছোট PostgreSQL ইনস্টলেশনে বা যেখানে অন্যান্য IT ল্যান্ডস্কেপ উপাদানের ভারী ব্যাকআপের প্রয়োজন হয় না সেখানে অত্যন্ত জনপ্রিয়। উদাহরণস্বরূপ, PostgreSQL ছাড়াও, অবকাঠামোতে ভৌত এবং ভার্চুয়াল অন্তর্ভুক্ত থাকতে পারে। সার্ভার, OpenShift, Oracle, MariaDB, Cassandra, ইত্যাদি। একটি সাধারণ ব্যাকআপ টুল ব্যবহার করে এই সকলের ব্যাকআপ নেওয়া ভালো। PostgreSQL এর জন্য শুধুমাত্র একটি পৃথক সমাধান স্থাপন করা একটি খারাপ ধারণা: ডেটা কোথাও ডিস্কে অনুলিপি করা হবে, এবং তারপর টেপে স্থানান্তরিত করতে হবে। ব্যাকআপের এই অনুলিপি ব্যাকআপ সময় এবং আরও গুরুত্বপূর্ণভাবে, পুনরুদ্ধারের সময় বৃদ্ধি করে।

একটি এন্টারপ্রাইজ সমাধানে, একটি ডেডিকেটেড ক্লাস্টারে নির্দিষ্ট সংখ্যক নোডের সাথে ইনস্টলেশনের ব্যাকআপ নেওয়া হয়। একই সময়ে, উদাহরণস্বরূপ, Commvault শুধুমাত্র একটি দুই-নোড ক্লাস্টারের সাথে কাজ করতে পারে, যেখানে প্রাথমিক এবং মাধ্যমিক নির্দিষ্ট নোডগুলিতে কঠোরভাবে বরাদ্দ করা হয়। এবং এটি শুধুমাত্র প্রাইমারি থেকে ব্যাকআপ নেওয়ার বোধগম্য হয়, কারণ মাধ্যমিক থেকে ব্যাকআপের সীমাবদ্ধতা রয়েছে৷ DBMS-এর বিশেষত্বের কারণে, সেকেন্ডারিতে একটি ডাম্প তৈরি করা হয় না, এবং তাই শুধুমাত্র একটি ফাইল ব্যাকআপের সম্ভাবনা থেকে যায়।

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

আরেকটি সমস্যা পোস্টগ্রেসে ব্যাকআপ বাস্তবায়ন। এটি ডাম্পের মাধ্যমে সম্ভব, এবং এটি ছোট ডাটাবেসে কাজ করে। কিন্তু বড় ডাটাবেসে, ডাম্পের জন্য অনেক সময় লাগে, প্রচুর রিসোর্স লাগে এবং ডাটাবেস ইনস্ট্যান্সের ব্যর্থতার দিকে নিয়ে যেতে পারে।

ফাইল ব্যাকআপ পরিস্থিতি সংশোধন করে, কিন্তু বড় ডাটাবেসে এটি ধীর কারণ এটি একক-থ্রেডেড মোডে কাজ করে। উপরন্তু, বিক্রেতাদের অতিরিক্ত সীমাবদ্ধতা আছে. হয় আপনি একই সময়ে ফাইল এবং ডাম্প ব্যাকআপ ব্যবহার করতে পারবেন না, অথবা ডিডপ্লিকেশন সমর্থিত নয়। অনেক সমস্যা রয়েছে এবং প্রায়শই Postgres এর পরিবর্তে একটি ব্যয়বহুল কিন্তু প্রমাণিত DBMS বেছে নেওয়া সহজ।

পিছু হটার কোথাও নেই! মস্কো ডেভেলপারদের পিছনে!

যাইহোক, সম্প্রতি আমাদের দল একটি কঠিন চ্যালেঞ্জের সম্মুখীন হয়েছে: AIS OSAGO 2.0 তৈরির প্রকল্পে, যেখানে আমরা IT পরিকাঠামো তৈরি করেছি, বিকাশকারীরা নতুন সিস্টেমের জন্য PostgreSQL বেছে নিয়েছে।

বড় সফ্টওয়্যার বিকাশকারীদের জন্য "ট্রেন্ডি" ওপেন সোর্স সমাধানগুলি ব্যবহার করা অনেক সহজ। এই DBMS এর অপারেশনকে সমর্থন করার জন্য ফেসবুকের যথেষ্ট বিশেষজ্ঞ রয়েছে। এবং আরএসএর ক্ষেত্রে, "দ্বিতীয় দিনের" সমস্ত কাজ আমাদের কাঁধে পড়েছিল। আমাদের দোষ সহনশীলতা নিশ্চিত করতে, একটি ক্লাস্টার একত্রিত করতে এবং অবশ্যই ব্যাকআপ সেট আপ করতে হবে। কর্মের যুক্তি নিম্নরূপ ছিল:

• ক্লাস্টারের প্রাথমিক নোড থেকে SRK কে ব্যাকআপ নিতে শেখান৷ এটি করার জন্য, এসআরকে অবশ্যই এটি খুঁজে বের করতে হবে - যার অর্থ এক বা অন্য একটি PostgreSQL ক্লাস্টার ব্যবস্থাপনা সমাধানের সাথে একীকরণ প্রয়োজন। আরএসএর ক্ষেত্রে এর জন্য ব্যবহার করা হয়েছে Patroni সফটওয়্যার।
• ডেটার ভলিউম এবং পুনরুদ্ধারের প্রয়োজনীয়তার উপর ভিত্তি করে ব্যাকআপের ধরণের সিদ্ধান্ত নিন। উদাহরণস্বরূপ, যখন আপনার পৃষ্ঠাগুলিকে দানাদারভাবে পুনরুদ্ধার করতে হবে, একটি ডাম্প ব্যবহার করুন এবং যদি ডেটাবেসগুলি বড় হয় এবং দানাদার পুনরুদ্ধারের প্রয়োজন না হয়, ফাইল স্তরে কাজ করুন৷
• মাল্টি-থ্রেডেড মোডে একটি ব্যাকআপ কপি তৈরি করতে সমাধানটিতে ব্লক ব্যাকআপের সম্ভাবনা সংযুক্ত করুন।

একই সময়ে, আমরা প্রাথমিকভাবে অতিরিক্ত উপাদানগুলির একটি দানবীয় জোতা ছাড়াই একটি কার্যকর এবং সহজ সিস্টেম তৈরি করার জন্য সেট করেছি। কম ক্রাচ, কর্মীদের উপর কম কাজের চাপ এবং IBS ব্যর্থতার ঝুঁকি কম। আমরা অবিলম্বে ভিম এবং আরএমএন ব্যবহার করা পদ্ধতিগুলি বাদ দিয়েছি, কারণ দুটি সমাধানের একটি সেট ইতিমধ্যেই সিস্টেমের অবিশ্বস্ততার দিকে ইঙ্গিত করে।

এন্টারপ্রাইজের জন্য একটি সামান্য জাদু

সুতরাং, ব্যাকআপ ডেটা সেন্টারে একই পরিকাঠামো মিরর সহ 10টি নোডের 3টি ক্লাস্টারের জন্য আমাদের নির্ভরযোগ্য ব্যাকআপের গ্যারান্টি দিতে হবে। পোস্টগ্রেএসকিউএল-এর পরিপ্রেক্ষিতে ডেটা কেন্দ্রগুলি সক্রিয়-প্যাসিভ নীতিতে কাজ করে। মোট ডাটাবেসের আকার ছিল 50 টিবি। যে কোন কর্পোরেট-স্তরের নিয়ন্ত্রণ ব্যবস্থা সহজেই এটি মোকাবেলা করতে পারে। কিন্তু সতর্কতা হল যে প্রাথমিকভাবে পোস্টগ্রেসের ব্যাকআপ সিস্টেমগুলির সাথে সম্পূর্ণ এবং গভীর সামঞ্জস্যের জন্য কোনও সূত্র নেই। অতএব, আমাদের এমন একটি সমাধান সন্ধান করতে হয়েছিল যা প্রাথমিকভাবে PostgreSQL এর সাথে সর্বাধিক কার্যকারিতা ছিল এবং সিস্টেমকে পরিমার্জন করতে হয়েছিল।

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

স্থাপত্য সম্পর্কে আরো. CommVult ম্যানেজমেন্ট সার্ভার দুটি ডেটা সেন্টারের প্রতিটিতে CommServ HA কনফিগারেশনে ইনস্টল করা হয়েছিল। সিস্টেমটি মিরর করা হয়, একটি কনসোলের মাধ্যমে পরিচালিত হয় এবং HA দৃষ্টিকোণ থেকে, এন্টারপ্রাইজের সমস্ত প্রয়োজনীয়তা পূরণ করে।

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

Patroni প্রতিটি ক্লাস্টারের জন্য একটি প্রাথমিক নোড সংজ্ঞায়িত করে। এটি ডেটা সেন্টারে যেকোন ফ্রি নোড হতে পারে - তবে বেশিরভাগই। ব্যাকআপে, সমস্ত নোড সেকেন্ডারি।

Commvault যাতে বুঝতে পারে কোন ক্লাস্টার নোডটি প্রাথমিক, আমরা সিস্টেমটিকে (সমাধানের ওপেন আর্কিটেকচারের জন্য ধন্যবাদ) Postgres-এর সাথে একীভূত করেছি। এই উদ্দেশ্যে, আমরা একটি স্ক্রিপ্ট তৈরি করেছি যা ম্যানেজারকে প্রাথমিক নোডের বর্তমান অবস্থান সম্পর্কে রিপোর্ট করে। সার্ভার কমভল্ট।

সাধারণভাবে, প্রক্রিয়াটি এইরকম দেখায়:

Patroni প্রাথমিক নির্বাচন করে → Keepalived IP ক্লাস্টার তুলে নেয় এবং স্ক্রিপ্ট চালায় → নির্বাচিত ক্লাস্টার নোডে Commvault এজেন্ট একটি বিজ্ঞপ্তি পায় যে এটি প্রাথমিক → Commvault স্বয়ংক্রিয়ভাবে ছদ্ম-ক্লায়েন্টের মধ্যে ব্যাকআপ পুনরায় কনফিগার করে।

এই পদ্ধতির সুবিধা হল সমাধানটি ধারাবাহিকতা, লগের সঠিকতা বা পোস্টগ্রেস উদাহরণের পুনরুদ্ধারকে প্রভাবিত করে না। এটি সহজেই স্কেলযোগ্য, কারণ কমভল্ট প্রাথমিক এবং মাধ্যমিক নোডগুলি ঠিক করার আর প্রয়োজন নেই। এটি যথেষ্ট যে সিস্টেমটি প্রাথমিক কোথায় তা বুঝতে পারে এবং নোডের সংখ্যা প্রায় যে কোনও মান পর্যন্ত বাড়ানো যেতে পারে।

সমাধানটি আদর্শ বলে ভান করে না এবং এর নিজস্ব সূক্ষ্মতা রয়েছে। Commvault শুধুমাত্র সমগ্র উদাহরণ ব্যাকআপ করতে পারে, এবং পৃথক ডাটাবেস নয়। অতএব, প্রতিটি ডাটাবেসের জন্য একটি পৃথক উদাহরণ তৈরি করা হয়েছিল। প্রকৃত ক্লায়েন্টদের ভার্চুয়াল ছদ্ম-ক্লায়েন্টে একত্রিত করা হয়। প্রতিটি Commvault ছদ্ম-ক্লায়েন্ট একটি UNIX ক্লাস্টার। যে ক্লাস্টার নোডগুলিতে Postgres-এর জন্য Commvault এজেন্ট ইনস্টল করা আছে তাতে যোগ করা হয়। ফলস্বরূপ, সিউডো-ক্লায়েন্টের সমস্ত ভার্চুয়াল নোডগুলি একটি উদাহরণ হিসাবে ব্যাক আপ করা হয়।

প্রতিটি সিউডো-ক্লায়েন্টের মধ্যে, ক্লাস্টারের সক্রিয় নোড নির্দেশিত হয়। Commvault-এর জন্য আমাদের ইন্টিগ্রেশন সলিউশন এটিই সংজ্ঞায়িত করে। এর ক্রিয়াকলাপের নীতিটি বেশ সহজ: যদি একটি ক্লাস্টার আইপি একটি নোডে উত্থাপিত হয় তবে স্ক্রিপ্টটি কমভল্ট এজেন্ট বাইনারিতে "সক্রিয় নোড" প্যারামিটার সেট করে - আসলে, স্ক্রিপ্টটি মেমরির প্রয়োজনীয় অংশে "1" সেট করে। . এজেন্ট এই ডেটা CommServe-এ প্রেরণ করে এবং Commvault পছন্দসই নোড থেকে একটি ব্যাকআপ করে। উপরন্তু, স্ক্রিপ্ট স্তরে কনফিগারেশনের সঠিকতা পরীক্ষা করা হয়, ব্যাকআপ শুরু করার সময় ত্রুটিগুলি এড়াতে সহায়তা করে।

একই সময়ে, বড় ডাটাবেসগুলি একাধিক থ্রেড জুড়ে ব্লকগুলিতে ব্যাক আপ করা হয়, আরপিও এবং ব্যাকআপ উইন্ডো প্রয়োজনীয়তা পূরণ করে। সিস্টেমে লোডটি নগণ্য: সম্পূর্ণ কপিগুলি প্রায়শই ঘটে না, অন্যান্য দিনে শুধুমাত্র লগ সংগ্রহ করা হয় এবং কম লোডের সময়কালে।

যাইহোক, আমরা PostgreSQL সংরক্ষণাগার লগগুলির ব্যাক আপ করার জন্য পৃথক নীতি প্রয়োগ করেছি - সেগুলি বিভিন্ন নিয়ম অনুসারে সংরক্ষণ করা হয়, একটি ভিন্ন সময়সূচী অনুসারে অনুলিপি করা হয় এবং তাদের জন্য অনুলিপি সক্ষম করা হয় না, যেহেতু এই লগগুলিতে অনন্য ডেটা রয়েছে৷

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

বর্তমানে, IBS উত্পাদনশীলতা পরিষেবাগুলিকে প্রভাবিত করে না, তবে পরিস্থিতি পরিবর্তন হলে, Commvault লোড সীমিতকরণ সক্ষম করতে পারে।

এটা কি ভালো? ভাল!

সুতরাং, আমরা পোস্টগ্রেএসকিউএল ক্লাস্টার ইনস্টলেশনের জন্য শুধুমাত্র একটি কার্যকরী নয়, একটি সম্পূর্ণ স্বয়ংক্রিয় ব্যাকআপ পেয়েছি এবং এটি এন্টারপ্রাইজ কলের জন্য সমস্ত প্রয়োজনীয়তা পূরণ করে।

1 ঘন্টা এবং 2 ঘন্টার RPO এবং RTO পরামিতিগুলি একটি মার্জিনের সাথে আচ্ছাদিত, যার অর্থ হল সঞ্চিত ডেটার পরিমাণে উল্লেখযোগ্য বৃদ্ধির সাথেও সিস্টেমটি তাদের মেনে চলবে৷ অনেক সন্দেহের বিপরীতে, PostgreSQL এবং এন্টারপ্রাইজ পরিবেশ বেশ সামঞ্জস্যপূর্ণ হয়ে উঠেছে। এবং এখন আমরা আমাদের নিজস্ব অভিজ্ঞতা থেকে জানি যে এই ধরনের DBMS-এর ব্যাকআপ বিভিন্ন ধরনের কনফিগারেশনে সম্ভব।

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

আপনি একটি কর্পোরেট পরিবেশে PostgreSQL এর সাথে কাজ করার চেষ্টা করেছেন?

লেখক:

ওলেগ লাভরেনভ, ডেটা স্টোরেজ সিস্টেমের ডিজাইন ইঞ্জিনিয়ার, জেট ইনফোসিস্টেম

দিমিত্রি এরিকিন, জেট ইনফোসিস্টেমের কম্পিউটার সিস্টেমের ডিজাইন ইঞ্জিনিয়ার

উত্স: www.habr.com