পোস্টগ্রেস মঙ্গলবার নং 5: “PostgreSQL এবং Kubernetes. সিআই/সিডি। পরীক্ষা অটোমেশন"

গত বছরের শেষে, রাশিয়ান PostgreSQL সম্প্রদায়ের আরেকটি লাইভ সম্প্রচার হয়েছিল #RuPostgres, যে সময়ে এর সহ-প্রতিষ্ঠাতা নিকোলাই সামোখভালভ ফ্লান্টের প্রযুক্তিগত পরিচালক দিমিত্রি স্টোলিয়ারভের সাথে কুবারনেটেসের প্রসঙ্গে এই ডিবিএমএস সম্পর্কে কথা বলেছেন।

আমরা এই আলোচনার মূল অংশের একটি প্রতিলিপি প্রকাশ করছি, এবং এ কমিউনিটি ইউটিউব চ্যানেল সম্পূর্ণ ভিডিও পোস্ট করা হয়েছে:

ডাটাবেস এবং কুবারনেটস

НС: আমরা আজ ভ্যাকুয়াম এবং চেকপয়েন্ট সম্পর্কে কথা বলব না। আমরা Kubernetes সম্পর্কে কথা বলতে চাই. আমি জানি আপনার অনেক বছরের অভিজ্ঞতা আছে। আমি আপনার ভিডিও দেখেছি এবং এমনকি সেগুলির কয়েকটি আবার দেখেছি... আসুন সরাসরি কথায় আসি: কেন পোস্টগ্রেস বা মাইএসকিউএল কে 8 এ আদৌ?

ডি এস: এই প্রশ্নের একটি নির্দিষ্ট উত্তর নেই এবং হতে পারে না। কিন্তু সাধারণভাবে, এটি সরলতা এবং সুবিধা... সম্ভাব্য। প্রত্যেকেই পরিচালিত পরিষেবা চায়।

НС: কিভাবে যদি RDSশুধু বাড়িতে?

ডি এস: হ্যাঁ: আরডিএসের মতো, যে কোনো জায়গায়।

НС: "যেকোন জায়গায়" একটি ভাল পয়েন্ট। বড় কোম্পানিতে, সবকিছু বিভিন্ন জায়গায় অবস্থিত। তাহলে বড় কোম্পানি হলে রেডিমেড সলিউশন নেবেন না কেন? উদাহরণস্বরূপ, নুটানিক্সের নিজস্ব বিকাশ রয়েছে, অন্যান্য সংস্থাগুলির (ভিএমওয়্যার...) একই "আরডিএস, শুধুমাত্র বাড়িতে।"

ডি এস: কিন্তু আমরা একটি পৃথক বাস্তবায়নের কথা বলছি যা শুধুমাত্র কিছু শর্তে কাজ করবে। এবং যদি আমরা কুবারনেটস সম্পর্কে কথা বলি, তবে সেখানে প্রচুর পরিকাঠামো রয়েছে (যা K8 এ হতে পারে)। মূলত এটি ক্লাউডের API-এর জন্য একটি মানক...

НС: এটাও বিনামূল্যে!

ডি এস: এটা তেমন গুরুত্বপূর্ণ নয়। বাজারের একটি খুব বড় অংশের জন্য অবাধতা গুরুত্বপূর্ণ নয়। অন্য কিছু গুরুত্বপূর্ণ... আপনার সম্ভবত প্রতিবেদনটি মনে আছে "ডাটাবেস এবং কুবারনেটস"?

НС: হ্যাঁ.

ডি এস: আমি বুঝতে পেরেছিলাম যে এটি খুব অস্পষ্টভাবে গ্রহণ করা হয়েছিল। কিছু লোক ভেবেছিল যে আমি বলছি: "বন্ধুরা, আসুন কুবারনেটসে সমস্ত ডাটাবেস নিয়ে আসি!", অন্যরা সিদ্ধান্ত নিয়েছে যে এগুলি সমস্ত ভয়ঙ্কর সাইকেল। তবে আমি সম্পূর্ণ আলাদা কিছু বলতে চেয়েছিলাম: “দেখুন কী ঘটছে, কী সমস্যা রয়েছে এবং কীভাবে সেগুলি সমাধান করা যায়। আমাদের কি এখন কুবারনেটেস ডাটাবেস ব্যবহার করা উচিত? উৎপাদন? ঠিক আছে, শুধুমাত্র যদি আপনি পছন্দ করেন... কিছু কিছু করা। কিন্তু একজন দেবের জন্য, আমি বলতে পারি যে আমি এটি সুপারিশ করছি। একজন ডেভের জন্য, পরিবেশ তৈরি/মুছে ফেলার গতিশীলতা খুবই গুরুত্বপূর্ণ।"

NS: দেব দ্বারা, আপনি কি এমন সমস্ত পরিবেশকে বোঝাতে চাচ্ছেন যা প্রোড নয়? মঞ্চায়ন, QA…

ডি এস: আমরা যদি পারফ স্ট্যান্ড সম্পর্কে কথা বলি, তাহলে সম্ভবত না, কারণ সেখানে প্রয়োজনীয়তা নির্দিষ্ট। আমরা যদি বিশেষ ক্ষেত্রে কথা বলি যেখানে স্টেজিংয়ের জন্য একটি খুব বড় ডাটাবেস প্রয়োজন হয়, তাহলে সম্ভবত না... যদি এটি একটি স্থির, দীর্ঘস্থায়ী পরিবেশ হয়, তাহলে K8s-এ ডাটাবেস থাকার সুবিধা কী?

НС: কোনটাই না। কিন্তু কোথায় আমরা স্থির পরিবেশ দেখি? একটি স্থির পরিবেশ আগামীকাল অচল হয়ে যাবে।

ডি এস: স্টেজিং স্থির হতে পারে। আমাদের ক্লায়েন্ট আছে...

НС: হ্যাঁ, আমারও একটা আছে। আপনার যদি 10 টিবি ডাটাবেস এবং 200 জিবি স্টেজিং থাকে তবে এটি একটি বড় সমস্যা...

ডি এস: আমি খুব শান্ত কেস আছে! মঞ্চায়নে একটি পণ্য ডাটাবেস রয়েছে যেখানে পরিবর্তন করা হয়। এবং একটি বোতাম রয়েছে: "উৎপাদনে রোল আউট"। এই পরিবর্তনগুলি - ডেল্টা - যোগ করা হয়েছে (মনে হচ্ছে এগুলি কেবল API এর মাধ্যমে সিঙ্ক্রোনাইজ করা হয়েছে) উত্পাদনে। এটি একটি খুব বহিরাগত বিকল্প।

НС: আমি উপত্যকায় এমন স্টার্টআপ দেখেছি যেগুলি আরডিএস বা এমনকি হেরোকুতে বসে আছে - এগুলি 2-3 বছর আগের গল্প - এবং তারা তাদের ল্যাপটপে ডাম্প ডাউনলোড করে। কারণ ডাটাবেস এখনও মাত্র 80 জিবি, এবং ল্যাপটপে জায়গা রয়েছে। তারপর তারা প্রত্যেকের জন্য অতিরিক্ত ডিস্ক কেনে যাতে তাদের কাছে বিভিন্ন উন্নয়নের জন্য 3টি ডাটাবেস থাকে। এটাও এভাবেই হয়। আমি আরও দেখেছি যে তারা মঞ্চে প্রোড কপি করতে ভয় পায় না - এটি কোম্পানির উপর নির্ভর করে। কিন্তু আমি এটাও দেখেছি যে তারা খুব ভয় পায়, এবং তাদের প্রায়শই যথেষ্ট সময় এবং হাত থাকে না। কিন্তু আমরা এই বিষয়ে এগিয়ে যাওয়ার আগে, আমি Kubernetes সম্পর্কে শুনতে চাই। আমি কি সঠিকভাবে বুঝতে পারি যে এখনও কেউ পণ্যে নেই?

ডি এস: আমাদের প্রোডে ছোট ডাটাবেস আছে। আমরা দশ হাজার গিগাবাইটের ভলিউম এবং অ-সমালোচনামূলক পরিষেবাগুলির কথা বলছি যার জন্য আমরা প্রতিলিপি তৈরি করতে খুব অলস ছিলাম (এবং এমন কোনও প্রয়োজন নেই)। এবং Kubernetes অধীনে স্বাভাবিক স্টোরেজ আছে যে প্রদান. এই ডাটাবেসটি একটি ভার্চুয়াল মেশিনে কাজ করেছিল - শর্তসাপেক্ষে VMware-এ, স্টোরেজ সিস্টেমের উপরে। আমরা এটা স্থাপন PV এবং এখন আমরা এটি মেশিন থেকে মেশিনে স্থানান্তর করতে পারি।

НС: এই আকারের ডাটাবেস, 100 GB পর্যন্ত, ভালো ডিস্ক এবং একটি ভাল নেটওয়ার্কে কয়েক মিনিটের মধ্যে রোল আউট করা যায়, তাই না? প্রতি সেকেন্ডে 1 জিবি গতি আর বিদেশী নয়।

ডি এস: হ্যাঁ, লিনিয়ার অপারেশনের জন্য এটা কোনো সমস্যা নয়।

НС: ঠিক আছে, আমরা শুধু পণ্য সম্পর্কে চিন্তা করতে হবে. এবং যদি আমরা কুবারনেটসকে নন-প্রোড পরিবেশের জন্য বিবেচনা করি তবে আমাদের কী করা উচিত? আমি Zalando যে দেখতে অপারেটর করবেন, ক্রাঞ্চিতে sawing, কিছু অন্যান্য বিকল্প আছে. এবং আছে অনগ্রেস - এটি স্পেনের আমাদের ভাল বন্ধু আলভারো: তারা যা করে তা মূলত শুধু নয় অপারেটর, এবং সমগ্র বিতরণ (স্ট্যাকগ্রেস), যার মধ্যে, পোস্টগ্রেসের পাশাপাশি, তারা একটি ব্যাকআপ, এনভয় প্রক্সি স্টাফ করার সিদ্ধান্ত নিয়েছে...

ডি এস: কিসের জন্য দূত? পোস্টগ্রেস ট্র্যাফিকের ভারসাম্য বিশেষভাবে?

НС: হ্যাঁ. অর্থাৎ, তারা এটিকে এইভাবে দেখে: আপনি যদি একটি লিনাক্স ডিস্ট্রিবিউশন এবং কার্নেল নেন, তাহলে নিয়মিত PostgreSQL হল কার্নেল, এবং তারা এমন একটি ডিস্ট্রিবিউশন তৈরি করতে চায় যা ক্লাউড-ফ্রেন্ডলি হবে এবং কুবারনেটসে চলবে। তারা উপাদান (ব্যাকআপ, ইত্যাদি) একত্রিত করে এবং তাদের ডিবাগ করে যাতে তারা ভালভাবে কাজ করে।

ডি এস: খুব ঠান্ডা! মূলত এটি আপনার নিজস্ব পরিচালিত পোস্টগ্রেস তৈরি করার সফ্টওয়্যার।

НС: লিনাক্স ডিস্ট্রিবিউশনের চিরন্তন সমস্যা রয়েছে: কীভাবে ড্রাইভার তৈরি করা যায় যাতে সমস্ত হার্ডওয়্যার সমর্থিত হয়। আর কুবেরনেটে কাজ করবে বলে তাদের ধারণা। আমি জানি যে Zalando অপারেটরে আমরা সম্প্রতি AWS-এর সাথে একটি সংযোগ দেখেছি এবং এটি আর খুব ভালো নয়। একটি নির্দিষ্ট পরিকাঠামোর সাথে টাই থাকা উচিত নয় - তাহলে কী লাভ?

ডি এস: আমি ঠিক জানি না জাল্যান্ডো কোন পরিস্থিতিতে পড়েছে, কিন্তু কুবারনেটস স্টোরেজ এখন এমনভাবে তৈরি করা হয়েছে যে জেনেরিক পদ্ধতি ব্যবহার করে একটি ডিস্ক ব্যাকআপ নেওয়া অসম্ভব। সম্প্রতি স্ট্যান্ডার্ডে - সর্বশেষ সংস্করণে CSI স্পেসিফিকেশন — আমরা স্ন্যাপশটগুলি সম্ভব করেছি, কিন্তু এটি কোথায় বাস্তবায়িত হয়? সত্যি বলতে কি, সবকিছু এখনও এত কাঁচা... আমরা AWS, GCE, Azure, vSphere-এর উপরে CSI চেষ্টা করছি, কিন্তু আপনি এটি ব্যবহার শুরু করার সাথে সাথে আপনি দেখতে পাবেন যে এটি এখনও প্রস্তুত নয়।

НС: সেজন্য আমাদের মাঝে মাঝে পরিকাঠামোর ওপর নির্ভর করতে হয়। আমি মনে করি এটি এখনও একটি প্রাথমিক পর্যায় - ক্রমবর্ধমান ব্যথা। প্রশ্ন: K8s-এ PgSQL ব্যবহার করতে চান এমন নতুনদের আপনি কী পরামর্শ দেবেন? কি অপারেটর হতে পারে?

ডি এস: সমস্যা হল পোস্টগ্রেস আমাদের জন্য 3%। আমাদের কাছে কুবারনেটসে বিভিন্ন সফ্টওয়্যারের একটি খুব বড় তালিকা রয়েছে, আমি সবকিছুর তালিকাও করব না। উদাহরণস্বরূপ, ইলাস্টিকসার্চ। অনেক অপারেটর আছে: কিছু সক্রিয়ভাবে বিকাশ করছে, অন্যরা নয়। এটিকে গুরুত্ব সহকারে নেওয়ার জন্য একজন অপারেটরের কী থাকা উচিত সে সম্পর্কে আমরা নিজেদের জন্য প্রয়োজনীয়তা তৈরি করেছি। একটি অপারেটরে বিশেষ করে Kubernetes-এর জন্য - "Amazon এর শর্তে কিছু করার জন্য অপারেটর" নয়... আসলে, আমরা বেশ ব্যাপকভাবে (= প্রায় সব ক্লায়েন্ট) একটি একক অপারেটর ব্যবহার করি - রেডিসের জন্য (আমরা শীঘ্রই তার সম্পর্কে একটি নিবন্ধ প্রকাশ করব).

НС: আর মাইএসকিউএলের জন্যও না? আমি জানি যে Percona... যেহেতু তারা এখন MySQL, MongoDB, এবং Postgres-এ কাজ করছে, তাদের কিছু ধরনের সার্বজনীন সমাধান তৈরি করতে হবে: সমস্ত ডাটাবেসের জন্য, সমস্ত ক্লাউড প্রদানকারীদের জন্য।

ডি এস: MySQL-এর জন্য অপারেটরদের দেখার জন্য আমাদের কাছে সময় নেই। এটা এখন আমাদের প্রধান ফোকাস নয়. মাইএসকিউএল স্বতন্ত্রভাবে কাজ করে। কেন একটি অপারেটর ব্যবহার করুন যদি আপনি শুধুমাত্র একটি ডাটাবেস চালু করতে পারেন... আপনি Postrges সহ একটি ডকার কন্টেইনার চালু করতে পারেন, অথবা আপনি এটি একটি সহজ উপায়ে চালু করতে পারেন।

НС: এটা নিয়েও একটা প্রশ্ন ছিল। কোন অপারেটর এ সব?

ডি এস: হ্যাঁ, আমাদের মধ্যে 100% পোস্টগ্রেএসকিউএল অপারেটর ছাড়াই চলছে। এই পর্যন্ত তাই. আমরা সক্রিয়ভাবে প্রমিথিউস এবং রেডিসের জন্য অপারেটর ব্যবহার করি। ইলাস্টিকসার্চের জন্য আমাদের একটি অপারেটর খুঁজে বের করার পরিকল্পনা রয়েছে - এটিই সবচেয়ে বেশি "আগুনে", কারণ আমরা এটি 100% ক্ষেত্রে কুবারনেটসে ইনস্টল করতে চাই। ঠিক যেমন আমরা নিশ্চিত করতে চাই যে MongoDB সবসময় Kubernetes-এ ইনস্টল করা আছে। এখানে নির্দিষ্ট ইচ্ছা উপস্থিত হয় - এই ক্ষেত্রে কিছু করা যেতে পারে এমন একটি অনুভূতি রয়েছে। এবং আমরা পোস্টগ্রেসের দিকেও তাকাইনি। অবশ্যই, আমরা জানি যে বিভিন্ন বিকল্প আছে, কিন্তু আসলে আমাদের একটি স্বতন্ত্র আছে।

কুবারনেটসে পরীক্ষার জন্য ডিবি

НС: পরীক্ষার বিষয়ে এগিয়ে যাওয়া যাক। একটি DevOps দৃষ্টিকোণ থেকে ডাটাবেসে পরিবর্তনগুলি কীভাবে রোল আউট করা যায়। মাইক্রোসার্ভিস আছে, অনেক ডাটাবেস আছে, কোথাও না কোথাও সব সময় পরিবর্তন হচ্ছে। কিভাবে স্বাভাবিক CI/CD নিশ্চিত করা যায় যাতে DBMS দৃষ্টিকোণ থেকে সবকিছু ঠিক থাকে। আপনার পন্থা কি?

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

НС: এবং জিডিপিআরের শর্তে, আমি মনে করি তারা আরও বেশি সতর্কতা অবলম্বন করছে... আমি বলতে পারি যে ইউরোপে তারা ইতিমধ্যে জরিমানা আরোপ করা শুরু করেছে।

ডি এস: কিন্তু প্রায়ই আপনি এমন সফ্টওয়্যার লিখতে পারেন যা উত্পাদন থেকে একটি ডাম্প নেয় এবং এটিকে অস্পষ্ট করে। প্রোড ডেটা প্রাপ্ত হয় (স্ন্যাপশট, ডাম্প, বাইনারি কপি...), কিন্তু এটি বেনামী। পরিবর্তে, প্রজন্মের স্ক্রিপ্ট থাকতে পারে: এগুলি ফিক্সচার বা শুধুমাত্র একটি স্ক্রিপ্ট হতে পারে যা একটি বড় ডাটাবেস তৈরি করে। সমস্যা হল: একটি বেস ইমেজ তৈরি করতে কতক্ষণ লাগে? এবং কাঙ্ক্ষিত পরিবেশে এটি স্থাপন করতে কতক্ষণ সময় লাগে?

আমরা একটি স্কিমে এসেছি: যদি ক্লায়েন্টের একটি নির্দিষ্ট ডেটা সেট থাকে (ডাটাবেসের সর্বনিম্ন সংস্করণ), তবে আমরা সেগুলি ডিফল্টরূপে ব্যবহার করি। যদি আমরা পর্যালোচনা পরিবেশ সম্পর্কে কথা বলি, যখন আমরা একটি শাখা তৈরি করি, আমরা অ্যাপ্লিকেশনটির একটি উদাহরণ স্থাপন করেছি - আমরা সেখানে একটি ছোট ডাটাবেস তৈরি করি। কিন্তু এটা ভাল পরিণত পছন্দ, যখন আমরা দিনে একবার (রাতে) প্রোডাকশন থেকে ডাম্প নিয়ে থাকি এবং এর উপর ভিত্তি করে এই লোড করা ডেটা দিয়ে PostgreSQL এবং MySQL সহ একটি ডকার কন্টেইনার তৈরি করি। আপনি যদি এই চিত্র থেকে ডাটাবেস 50 বার প্রসারিত করতে চান তবে এটি বেশ সহজ এবং দ্রুত করা হয়।

НС: সহজ কপি করে?

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

НС: তারপর, আপনি যখন পরীক্ষা করেন, এটি ঠিক ডকারের ভিতরেই পরিবর্তন হয়, তাই না? ডকারের ভিতরে কপি-অন-রাইট করুন - এটি ফেলে দিন এবং আবার যান, সবকিছু ঠিক আছে। ক্লাসের ! এবং আপনি ইতিমধ্যে এটি সম্পূর্ণরূপে ব্যবহার করছেন?

ডি এস: অনেকক্ষণ ধরে.

НС: আমরা খুব অনুরূপ জিনিস করি। শুধুমাত্র আমরা ডকারের কপি-অন-রাইট ব্যবহার করি না, তবে অন্য কিছু।

ডি এস: এটা জেনেরিক নয়। এবং ডকার সর্বত্র কাজ করে।

НС: তাত্ত্বিকভাবে, হ্যাঁ। কিন্তু আমাদের সেখানে মডিউল রয়েছে, আপনি বিভিন্ন মডিউল তৈরি করতে পারেন এবং বিভিন্ন ফাইল সিস্টেমের সাথে কাজ করতে পারেন। এখানে কি একটি মুহূর্ত. Postgres পাশ থেকে, আমরা এই সব ভিন্নভাবে তাকান. এখন আমি ডকার দিক থেকে দেখেছি এবং দেখেছি যে সবকিছু আপনার জন্য কাজ করে। কিন্তু যদি ডাটাবেস বিশাল হয়, উদাহরণস্বরূপ, 1 টিবি, তবে এই সমস্ত কিছু দীর্ঘ সময় নেয়: রাতে অপারেশন, এবং ডকারে সবকিছু স্টাফ করা... এবং যদি 5 টিবি ডকারে স্টাফ করা হয়... নাকি সবকিছু ঠিক আছে?

ডি এস: পার্থক্য কি: এগুলো হল ব্লব, শুধু বিট এবং বাইট।

НС: পার্থক্য এই: আপনি ডাম্প এবং পুনঃস্থাপন মাধ্যমে এটা করবেন?

ডি এস: মোটেও দরকার নেই। এই ছবি তৈরির পদ্ধতি ভিন্ন হতে পারে।

НС: কিছু ক্লায়েন্টের জন্য, আমরা এটি তৈরি করেছি যাতে নিয়মিতভাবে একটি বেস ইমেজ তৈরি করার পরিবর্তে, আমরা এটি ক্রমাগত আপ টু ডেট রাখি। এটি মূলত একটি প্রতিরূপ, তবে এটি সরাসরি মাস্টারের কাছ থেকে নয়, একটি সংরক্ষণাগারের মাধ্যমে ডেটা গ্রহণ করে। একটি বাইনারি সংরক্ষণাগার যেখানে WALগুলি প্রতিদিন ডাউনলোড করা হয়, যেখানে ব্যাকআপ নেওয়া হয়... এই WALগুলি তখন সামান্য বিলম্বে (আক্ষরিক অর্থে 1-2 সেকেন্ড) বেস ইমেজে পৌঁছায়। আমরা এটি থেকে যেকোনো উপায়ে ক্লোন করি - এখন আমাদের কাছে ডিফল্টরূপে ZFS আছে।

ডি এস: কিন্তু ZFS এর সাথে আপনি একটি নোডে সীমাবদ্ধ।

НС: হ্যাঁ. কিন্তু ZFS এরও একটা জাদু আছে পাঠান: এটি দিয়ে আপনি একটি স্ন্যাপশট পাঠাতে পারেন এবং এমনকি (আমি সত্যিই এটি এখনও পরীক্ষা করিনি, তবে...) আপনি দুটির মধ্যে একটি ডেল্টা পাঠাতে পারেন PGDATA. প্রকৃতপক্ষে, আমাদের আরেকটি টুল আছে যা আমরা সত্যিই এই ধরনের কাজের জন্য বিবেচনা করিনি। PostgreSQL আছে pg_rewind, যা একটি "স্মার্ট" rsync-এর মতো কাজ করে, আপনাকে যা দেখতে হবে না তার অনেকগুলি এড়িয়ে যায়, কারণ সেখানে কিছুই পরিবর্তন হয়নি৷ আমরা দুটি সার্ভারের মধ্যে দ্রুত সিঙ্ক্রোনাইজেশন করতে পারি এবং একইভাবে রিওয়াইন্ড করতে পারি।

সুতরাং, এর থেকে, আরও ডিবিএ দিক থেকে, আমরা একটি টুল তৈরি করার চেষ্টা করছি যা আমাদেরকে আপনি যা বলেছেন একই জিনিস করতে দেয়: আমাদের একটি ডাটাবেস আছে, কিন্তু আমরা প্রায় একই সাথে 50 বার কিছু পরীক্ষা করতে চাই।

ডি এস: 50 বার মানে আপনাকে 50টি স্পট ইনস্ট্যান্স অর্ডার করতে হবে।

НС: না, আমরা এক মেশিনে সবকিছু করি।

ডি এস: কিন্তু আপনি কিভাবে 50 বার প্রসারিত করবেন যদি এই একটি ডাটাবেস হয়, বলুন, টেরাবাইট। সম্ভবত তার একটি শর্তসাপেক্ষ 256 গিগাবাইট RAM প্রয়োজন?

НС: হ্যাঁ, মাঝে মাঝে অনেক স্মৃতির প্রয়োজন হয়- এটাই স্বাভাবিক। তবে এটি জীবন থেকে একটি উদাহরণ। উত্পাদন মেশিনে 96 কোর এবং 600 জিবি রয়েছে। একই সময়ে, ডাটাবেসের জন্য 32 কোর (এমনকি 16 কোরও এখন কখনও কখনও) এবং 100-120 GB মেমরি ব্যবহার করা হয়।

ডি এস: এবং সেখানে 50 কপি মাপসই?

НС: তাই শুধুমাত্র একটি কপি আছে, তারপর কপি-অন-রাইট (ZFS) কাজ করে... আমি আপনাকে আরও বিস্তারিতভাবে বলব।

উদাহরণস্বরূপ, আমাদের একটি 10 ​​টিবি ডাটাবেস আছে। তারা এটির জন্য একটি ডিস্ক তৈরি করেছে, ZFS এর আকার 30-40 শতাংশ দ্বারা সংকুচিত করেছে। যেহেতু আমরা লোড টেস্টিং করি না, তাই সঠিক প্রতিক্রিয়া সময় আমাদের কাছে গুরুত্বপূর্ণ নয়: এটি 2 গুণ ধীর হতে দিন - ঠিক আছে।

আমরা প্রোগ্রামার, QA, DBA ইত্যাদিকে সুযোগ দিই। 1-2 থ্রেড পরীক্ষা সঞ্চালন. উদাহরণস্বরূপ, তারা কোনো ধরনের মাইগ্রেশন চালাতে পারে। এটির একবারে 10টি কোরের প্রয়োজন নেই - এটির জন্য 1টি পোস্টগ্রেস ব্যাকএন্ড, 1টি কোর প্রয়োজন৷ মাইগ্রেশন শুরু হবে- হতে পারে অটোভ্যাকুয়াম এখনও শুরু হবে, তারপর দ্বিতীয় কোর ব্যবহার করা হবে। আমাদের 16-32 কোর বরাদ্দ আছে, তাই 10 জন একই সময়ে কাজ করতে পারে, কোন সমস্যা নেই।

কারণ শারীরিকভাবে PGDATA একই, এটা দেখা যাচ্ছে যে আমরা আসলে পোস্টগ্রেসকে প্রতারণা করছি। কৌশলটি হল: উদাহরণস্বরূপ, 10টি পোস্টগ্রেস একই সাথে চালু করা হয়। সাধারণত কি সমস্যা হয়? তারা স্থাপন করে শেয়ার করা_বাফার, ধরা যাক 25%। তদনুসারে, এটি 200 জিবি। আপনি এর মধ্যে তিনটির বেশি চালু করতে পারবেন না, কারণ মেমরি শেষ হয়ে যাবে।

কিন্তু কিছু সময়ে আমরা বুঝতে পেরেছিলাম যে এটি প্রয়োজনীয় নয়: আমরা শেয়ার্ড_বাফারগুলি 2 জিবিতে সেট করেছি। PostgreSQL আছে কার্যকরী_ক্যাশে_সাইজ, এবং বাস্তবে এটি একমাত্র প্রভাবিত করে পরিকল্পনা সমূহ. আমরা এটি 0,5 টিবিতে সেট করি। এবং এটা কোন ব্যাপার না যে তারা আসলে বিদ্যমান নেই: তিনি পরিকল্পনা করেন যেন তারা বিদ্যমান।

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

ডি এস: এখানে কিছু সমস্যা আছে বলে মনে করেন না? প্রথমটি একটি সমাধান যা শুধুমাত্র PostgreSQL এ কাজ করে। এই পদ্ধতিটি খুব ব্যক্তিগত, এটি সাধারণ নয়। দ্বিতীয়টি হল কুবারনেটস (এবং ক্লাউড প্রযুক্তি যা এখন যাচ্ছে) অনেক নোড জড়িত, এবং এই নোডগুলি ক্ষণস্থায়ী। এবং আপনার ক্ষেত্রে এটি একটি রাষ্ট্রীয়, ক্রমাগত নোড। এই জিনিসগুলি আমাকে দ্বন্দ্ব করে তোলে।

НС: প্রথমত, আমি একমত, এটি একটি সম্পূর্ণ পোস্টগ্রেস গল্প। আমি মনে করি যদি আমাদের প্রায় সমস্ত মেমরির জন্য কিছু ধরণের সরাসরি IO এবং একটি বাফার পুল থাকে তবে এই পদ্ধতিটি কাজ করবে না - পরিকল্পনাগুলি ভিন্ন হবে। কিন্তু আপাতত আমরা শুধুমাত্র Postgres এর সাথে কাজ করি, আমরা অন্যদের কথা ভাবি না।

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

ডি এস: আমার দৃষ্টিকোণ থেকে, আমরা কুবারনেটসে পড তৈরি করি। K8s - ইলাস্টিক: গিঁট প্রয়োজন অনুযায়ী অর্ডার করা হয়। কাজটি হ'ল কেবল একটি পড তৈরি করা এবং বলা যে এটির জন্য X পরিমাণ সংস্থান প্রয়োজন, এবং তারপর K8গুলি নিজেই এটি বের করবে। কিন্তু কুবারনেটসে স্টোরেজ সমর্থন এখনও অস্থির: 1.16, ইন 1.17 (এই রিলিজটি প্রকাশিত হয়েছিল সপ্তাহের আগে) এই বৈশিষ্ট্যগুলি শুধুমাত্র বিটা হয়ে যায়।

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

НС: সমস্ত ইঞ্জিনের (Amazon, Google...) এই সংস্করণটিকে সমর্থন করা শুরু করার জন্যও এটি প্রয়োজনীয় - এতেও কিছু সময় লাগে৷

ডি এস: আমরা এখনও তাদের ব্যবহার করি না। আমরা আমাদের ব্যবহার করি।

Kubernetes জন্য স্থানীয় উন্নয়ন

НС: যখন আপনি একটি মেশিনে সমস্ত পড ইনস্টল করতে হবে এবং এই ধরনের একটি ছোট পরীক্ষা করতে হবে তখন আপনি কি এমন একটি ইচ্ছা জুড়ে এসেছেন? দ্রুত ধারণার প্রমাণ পেতে, দেখুন যে অ্যাপ্লিকেশনটি কুবারনেটসে চলে, এটির জন্য একগুচ্ছ মেশিন উৎসর্গ না করে। মিনিকুব আছে, তাই না?

ডি এস: আমার কাছে মনে হচ্ছে এই কেস - একটি নোডে স্থাপন করা হয়েছে - একচেটিয়াভাবে স্থানীয় উন্নয়ন সম্পর্কে। বা এই ধরনের প্যাটার্নের কিছু প্রকাশ। খাওয়া মিনিক्यूब, আছে K3s, ধরনের. আমরা কুবারনেটস ইন ডকার ব্যবহারের দিকে এগিয়ে যাচ্ছি। এখন আমরা পরীক্ষার জন্য এটির সাথে কাজ শুরু করেছি।

НС: আমি মনে করতাম যে এটি একটি ডকার ইমেজে সমস্ত পড মোড়ানোর একটি প্রচেষ্টা ছিল। কিন্তু দেখা গেল যে এটি সম্পূর্ণ ভিন্ন কিছু সম্পর্কে। যাই হোক, আলাদা কন্টেইনার, আলাদা পড আছে - শুধু ডকারে।

ডি এস: হ্যাঁ. এবং একটি বরং মজার অনুকরণ করা হয়েছে, কিন্তু অর্থ হল এই... আমাদের স্থাপনার জন্য একটি ইউটিলিটি আছে - werf. আমরা এটি একটি শর্তাধীন মোড করতে চাই werf up: "আমাকে স্থানীয় কুবারনেটস পান।" এবং তারপর সেখানে শর্তসাপেক্ষে চালান werf follow. তারপর বিকাশকারী IDE সম্পাদনা করতে সক্ষম হবে এবং সিস্টেমে একটি প্রক্রিয়া চালু করা হবে যা পরিবর্তনগুলি দেখে এবং চিত্রগুলিকে পুনর্নির্মাণ করে, সেগুলিকে স্থানীয় K8s এ পুনরায় স্থাপন করে। এভাবেই স্থানীয় উন্নয়নের সমস্যা সমাধানের চেষ্টা করতে চাই।

K8s বাস্তবতায় স্ন্যাপশট এবং ডাটাবেস ক্লোনিং

НС: আমরা যদি কপি-অন-রাইটে ফিরে যাই। আমি লক্ষ্য করেছি যে মেঘেরও স্ন্যাপশট রয়েছে। তারা ভিন্নভাবে কাজ করে। উদাহরণস্বরূপ, GCP-তে: মার্কিন যুক্তরাষ্ট্রের পূর্ব উপকূলে আপনার একটি মাল্টি-টেরাবাইট উদাহরণ রয়েছে। আপনি পর্যায়ক্রমে স্ন্যাপশট নিতে. আপনি একটি স্ন্যাপশট থেকে পশ্চিম উপকূলে ডিস্কের একটি অনুলিপি বাছাই করুন - কয়েক মিনিটের মধ্যে সবকিছু প্রস্তুত, এটি খুব দ্রুত কাজ করে, শুধুমাত্র ক্যাশে মেমরিতে পূরণ করতে হবে। কিন্তু এই ক্লোনগুলি (স্ন্যাপশট) একটি নতুন ভলিউম 'প্রভিশন' করার জন্য। যখন আপনাকে অনেকগুলি দৃষ্টান্ত তৈরি করতে হবে তখন এটি দুর্দান্ত।

কিন্তু পরীক্ষার জন্য, আমার কাছে মনে হচ্ছে যে স্ন্যাপশটগুলি, যেগুলি সম্পর্কে আপনি ডকারে কথা বলেন বা আমি ZFS, btrfs এবং এমনকি LVM-তেও কথা বলি... - তারা আপনাকে একটি মেশিনে সত্যিই নতুন ডেটা তৈরি করতে দেয় না। ক্লাউডে, আপনি এখনও প্রতিবার তাদের জন্য অর্থ প্রদান করবেন এবং সেকেন্ড নয়, মিনিট অপেক্ষা করবেন (এবং ক্ষেত্রে অলস লোড, সম্ভবত একটি ঘড়ি)।

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

ডি এস: আমি রাজি নই। ভলিউম ক্লোনিংয়ের কাজটি সঠিকভাবে করা ক্লাউডের কাজ। আমি তাদের বাস্তবায়নের দিকে নজর দিইনি, তবে আমি জানি যে আমরা হার্ডওয়্যারে এটি কীভাবে করি। আমাদের কাছে Ceph আছে, এটি যেকোনো শারীরিক ভলিউমকে অনুমতি দেয় (RBD) বলে ক্লোন এবং দশ মিলিসেকেন্ডে একই বৈশিষ্ট্য সহ একটি দ্বিতীয় ভলিউম পান, IOPSআমি, ইত্যাদি আপনাকে বুঝতে হবে যে ভিতরে একটি কৌশলী কপি-অন-রাইট রয়েছে। কেন মেঘ একই কাজ করা উচিত নয়? আমি নিশ্চিত যে তারা এটি একটি উপায় বা অন্যভাবে করার চেষ্টা করছে।

НС: কিন্তু এটি এখনও তাদের সেকেন্ড, কয়েক সেকেন্ড সময় লাগবে একটি উদাহরণ উত্থাপন করতে, ডকারকে সেখানে আনতে, ইত্যাদি।

ডি এস: কেন একটি সম্পূর্ণ উদাহরণ উত্থাপন করা প্রয়োজন? আমাদের কাছে 32 কোর, 16... সহ একটি উদাহরণ রয়েছে এবং এটি এতে ফিট হতে পারে - উদাহরণস্বরূপ, চারটি। যখন আমরা পঞ্চমটি অর্ডার করি, দৃষ্টান্তটি ইতিমধ্যে উত্থাপিত হবে এবং তারপরে এটি মুছে ফেলা হবে।

НС: হ্যাঁ, মজার, কুবারনেটস একটি ভিন্ন গল্প হতে চলেছে। আমাদের ডাটাবেস K8 এ নেই, এবং আমাদের একটি উদাহরণ আছে। কিন্তু একটি মাল্টি-টেরাবাইট ডাটাবেস ক্লোন করতে দুই সেকেন্ডের বেশি সময় লাগে না।

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

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

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

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

ডি এস: টেকনিক্যালি এর মানে হল Kubernetes-এর মধ্যে এটি একটি পড যার মধ্যে আমরা অনেক Postgres চালাই।

НС: হ্যাঁ. তার একটি সীমা আছে: ধরা যাক একই সময়ে 10 জনের বেশি লোক তার সাথে কাজ করবে না। আপনার যদি 20 এর প্রয়োজন হয়, আমরা এরকম একটি দ্বিতীয় পড চালু করব। আমরা এটিকে সম্পূর্ণরূপে ক্লোন করব, দ্বিতীয় পূর্ণ ভলিউমটি পেয়ে, এটিতে একই 10টি "পাতলা" ক্লোন থাকবে। আপনি কি এই সুযোগ দেখতে পাচ্ছেন না?

ডি এস: আমাদের এখানে নিরাপত্তা সংক্রান্ত সমস্যা যোগ করতে হবে। এই ধরণের সংস্থার ইঙ্গিত দেয় যে এই পডের উচ্চ বিশেষাধিকার (ক্ষমতা) রয়েছে, কারণ এটি ফাইল সিস্টেমে অ-মানক ক্রিয়াকলাপ সম্পাদন করতে পারে... তবে আমি আবার বলছি: আমি বিশ্বাস করি যে মাঝারি মেয়াদে তারা কুবারনেটসে স্টোরেজ ঠিক করবে, এবং মেঘ তারা ভলিউম দিয়ে পুরো গল্প ঠিক করবে - সবকিছু "শুধু কাজ করবে"। সেখানে আকার পরিবর্তন করা হবে, ক্লোনিং হবে... একটি ভলিউম আছে - আমরা বলি: "তার উপর ভিত্তি করে একটি নতুন তৈরি করুন" এবং দেড় সেকেন্ড পরে আমরা যা প্রয়োজন তা পাই।

НС: আমি অনেক টেরাবাইটের জন্য দেড় সেকেন্ডে বিশ্বাস করি না। সেফ-এ আপনি নিজেই এটি করেন, কিন্তু আপনি মেঘের কথা বলেন। ক্লাউডে যান, EC2 এ মাল্টি-টেরাবাইট ইবিএস ভলিউমের একটি ক্লোন তৈরি করুন এবং দেখুন কার্যক্ষমতা কী হবে। কয়েক সেকেন্ড লাগবে না। তারা কখন এই স্তরে পৌঁছাবে তা নিয়ে আমি খুব আগ্রহী। আমি বুঝতে পারছি আপনি কি বলছেন, কিন্তু আমি ভিন্ন অনুরোধ করছি.

ডি এস: ঠিক আছে, তবে আমি মধ্য মেয়াদে বলেছি, স্বল্প মেয়াদে নয়। কয়েক বছরের জন্য.

Zalando থেকে PostgreSQL জন্য অপারেটর সম্পর্কে

এই বৈঠকের মাঝখানে, জাল্যান্ডোর একজন প্রাক্তন বিকাশকারী আলেক্সি ক্লিউকিনও যোগ দিয়েছিলেন এবং PostgreSQL অপারেটরের ইতিহাস সম্পর্কে কথা বলেছেন:

এটি দুর্দান্ত যে এই বিষয়টিকে সাধারণভাবে স্পর্শ করা হয়েছে: পোস্টগ্রেস এবং কুবারনেটস উভয়ই। 2017 সালে যখন আমরা Zalando-এ এটি করা শুরু করি, তখন এটি এমন একটি বিষয় ছিল যা সবাই করতে চেয়েছিল, কিন্তু কেউ করেনি। প্রত্যেকেরই ইতিমধ্যে কুবারনেটস ছিল, কিন্তু যখন তারা জিজ্ঞাসা করেছিল যে ডেটাবেসগুলির সাথে কী করতে হবে, এমনকি লোকেরাও পছন্দ করে কেলসি হাইটাওয়ার, যিনি K8s প্রচার করেছিলেন, এইরকম কিছু বলেছিলেন:

"পরিচালিত পরিষেবাগুলিতে যান এবং সেগুলি ব্যবহার করুন, Kubernetes-এ ডাটাবেস চালাবেন না৷ অন্যথায়, আপনার K8 গুলি সিদ্ধান্ত নেবে, উদাহরণস্বরূপ, একটি আপগ্রেড করার জন্য, সমস্ত নোড বন্ধ করুন এবং আপনার ডেটা অনেক দূরে উড়ে যাবে।"

আমরা একটি অপারেটর তৈরি করার সিদ্ধান্ত নিয়েছি যে, এই পরামর্শের বিপরীতে, Kubernetes-এ একটি Postgres ডাটাবেস চালু করবে। এবং আমাদের একটি ভাল কারণ ছিল - পৃষ্ঠপোষক. এটি PostgreSQL এর জন্য একটি স্বয়ংক্রিয় ব্যর্থতা, সঠিকভাবে করা হয়েছে, যেমন ক্লাস্টার সম্পর্কে তথ্যের স্টোরেজ হিসাবে etcd, কনসাল বা ZooKeeper ব্যবহার করে। এমন একটি ভাণ্ডার যা প্রত্যেককে জিজ্ঞাসা করবে, উদাহরণস্বরূপ, বর্তমান নেতা কী, একই তথ্য - আমাদের সবকিছু বিতরণ করা সত্ত্বেও - যাতে কোনও বিভক্ত মস্তিষ্ক নেই। প্লাস আমরা ছিল ডকার ইমেজ তার জন্য

সাধারণভাবে, একটি অভ্যন্তরীণ হার্ডওয়্যার ডেটা সেন্টার থেকে ক্লাউডে স্থানান্তরিত হওয়ার পরে অটো ফেইলওভারের জন্য কোম্পানির প্রয়োজনীয়তা দেখা দেয়। ক্লাউডটি একটি মালিকানাধীন PaaS (প্ল্যাটফর্ম-এ-সার্ভিস) সমাধানের উপর ভিত্তি করে ছিল। এটি ওপেন সোর্স, কিন্তু এটি চালু এবং চালানোর জন্য এটি অনেক কাজ নিয়েছে। এটা বলা হয়েছিল STUPS.

প্রাথমিকভাবে, কোন কুবারনেটস ছিল না। আরও স্পষ্টভাবে, যখন আমাদের নিজস্ব সমাধান স্থাপন করা হয়েছিল, তখন K8 গুলি ইতিমধ্যেই বিদ্যমান ছিল, কিন্তু এটি এতটাই কাঁচা ছিল যে এটি উত্পাদনের জন্য উপযুক্ত ছিল না। এটা ছিল, আমার মতে, 2015 বা 2016। 2017 সাল নাগাদ, কুবারনেটস কমবেশি পরিপক্ক হয়ে উঠেছিল—সেখানে স্থানান্তর করার প্রয়োজন ছিল।

এবং আমরা ইতিমধ্যে একটি ডকার ধারক ছিল. একটি PaaS ছিল যে Docker ব্যবহার করত। কেন K8s চেষ্টা করবেন না? কেন আপনার নিজের অপারেটর লিখুন না? মুরাত কাবিলভ, যিনি আভিটো থেকে আমাদের কাছে এসেছিলেন, তিনি এটিকে তার নিজের উদ্যোগে একটি প্রকল্প হিসাবে শুরু করেছিলেন - "খেলতে" - এবং প্রকল্পটি "চলে গেছে।"

কিন্তু সাধারণভাবে, আমি AWS সম্পর্কে কথা বলতে চেয়েছিলাম। কেন ঐতিহাসিক AWS সম্পর্কিত কোড ছিল...

আপনি যখন Kubernetes-এ কিছু চালান, তখন আপনাকে বুঝতে হবে যে K8s এমন একটি কাজ চলছে। এটি ক্রমাগত উন্নয়নশীল, উন্নতি এবং এমনকি সময়ে সময়ে ভেঙে যাচ্ছে। আপনাকে কুবারনেটসের সমস্ত পরিবর্তনের উপর ঘনিষ্ঠ নজর রাখতে হবে, কিছু ঘটলে এটিতে ডুব দেওয়ার জন্য আপনাকে প্রস্তুত থাকতে হবে এবং এটি কীভাবে কাজ করে তা বিস্তারিতভাবে শিখতে হবে - সম্ভবত আপনি যা চান তার চেয়ে বেশি। এটি, নীতিগতভাবে, যে কোনও প্ল্যাটফর্মে প্রযোজ্য যেখানে আপনি আপনার ডাটাবেসগুলি চালান...

সুতরাং, যখন আমরা বিবৃতিটি করেছি, তখন আমাদের কাছে পোস্টগ্রেস একটি বাহ্যিক ভলিউমে চলমান ছিল (এই ক্ষেত্রে EBS, যেহেতু আমরা AWS-এ কাজ করছিলাম)। ডাটাবেস বৃদ্ধি পেয়েছে, কিছু সময়ে এটির আকার পরিবর্তন করা প্রয়োজন ছিল: উদাহরণস্বরূপ, EBS এর প্রাথমিক আকার ছিল 100 TB, ডাটাবেস এটিতে বেড়েছে, এখন আমরা EBS 200 TB করতে চাই। কিভাবে? ধরা যাক আপনি একটি নতুন উদাহরণে একটি ডাম্প/পুনরুদ্ধার করতে পারেন, তবে এটি একটি দীর্ঘ সময় নেবে এবং ডাউনটাইমকে জড়িত করবে।

অতএব, আমি একটি রিসাইজ চেয়েছিলাম যা EBS পার্টিশনকে বড় করবে এবং তারপর ফাইল সিস্টেমকে নতুন স্থান ব্যবহার করতে বলবে। এবং আমরা এটি করেছি, কিন্তু সেই সময়ে কুবারনেটসের কাছে রিসাইজ অপারেশনের জন্য কোনো API ছিল না। যেহেতু আমরা AWS এ কাজ করেছি, আমরা এর API এর জন্য কোড লিখেছি।

অন্য প্ল্যাটফর্মের জন্য একই কাজ থেকে কেউ আপনাকে বাধা দিচ্ছে না। বিবৃতিতে কোন ইঙ্গিত নেই যে এটি শুধুমাত্র AWS এ চালানো যেতে পারে, এবং এটি অন্য সব কিছুতে কাজ করবে না। সাধারণভাবে, এটি একটি ওপেন সোর্স প্রজেক্ট: যদি কেউ নতুন API-এর ব্যবহারকে ত্বরান্বিত করতে চান, তাহলে আপনাকে স্বাগতম। খাওয়া GitHub, অনুরোধ টানুন - Zalando টিম তাদের খুব দ্রুত সাড়া দেওয়ার এবং অপারেটরকে প্রচার করার চেষ্টা করে। আমি যতদূর জানি, প্রকল্প অংশগ্রহণ করেছে Google সামার অফ কোড এবং অন্যান্য অনুরূপ উদ্যোগে। Zalando এটা খুব সক্রিয়ভাবে কাজ করছে.

PS বোনাস!

আপনি যদি PostgreSQL এবং Kubernetes বিষয়ে আগ্রহী হন, তাহলে অনুগ্রহ করে এটাও মনে রাখবেন যে পরবর্তী Postgres মঙ্গলবার গত সপ্তাহে হয়েছিল, যেখানে আমি নিকোলাইয়ের সাথে কথা বলেছিলাম জাল্যান্ডো থেকে আলেকজান্ডার কুকুশকিন. এটি থেকে ভিডিও পাওয়া যায় এখানে.

PPS

আমাদের ব্লগেও পড়ুন:

• «ডাটাবেস এবং কুবারনেটস (ওভারভিউ এবং ভিডিও রিপোর্ট)";
• «কুবারনেটসে ক্যাসান্দ্রা স্থানান্তর: বৈশিষ্ট্য এবং সমাধান";
• «বিরামহীন MongoDB থেকে Kubernetes মাইগ্রেশন";
• «বিরামহীন RabbitMQ থেকে Kubernetes মাইগ্রেশন».

উত্স: www.habr.com