پچھلے سال کے آخر میں، روسی PostgreSQL کمیونٹی کی ایک اور لائیو نشریات ہوئی۔ ، جس کے دوران اس کے شریک بانی نکولائی سموخوالوف نے فلانٹ کے تکنیکی ڈائریکٹر دمتری اسٹولیاروف کے ساتھ اس DBMS کے بارے میں Kubernetes کے تناظر میں بات کی۔
ہم اس بحث کے مرکزی حصے کا ایک ٹرانسکرپٹ شائع کر رہے ہیں، اور پر مکمل ویڈیو پوسٹ کی گئی:
ڈیٹا بیس اور کبرنیٹس
НС: ہم آج ویکیوم اور چیک پوائنٹس کے بارے میں بات نہیں کریں گے۔ ہم Kubernetes کے بارے میں بات کرنا چاہتے ہیں۔ میں جانتا ہوں کہ آپ کے پاس کئی سالوں کا تجربہ ہے۔ میں نے آپ کی ویڈیوز دیکھی ہیں اور ان میں سے کچھ کو دوبارہ بھی دیکھا ہے... آئیے سیدھی بات پر آتے ہیں: K8s میں Postgres یا MySQL بالکل کیوں؟
ڈی ایس: اس سوال کا کوئی قطعی جواب نہیں ہے اور نہ ہو سکتا ہے۔ لیکن عام طور پر، یہ سادگی اور سہولت ہے... ممکنہ۔ ہر کوئی منظم خدمات چاہتا ہے۔
НС: کیسے؟ صرف گھر پر؟
ڈی ایس: ہاں: RDS کی طرح، کہیں بھی۔
НС: "کہیں بھی" ایک اچھا نقطہ ہے۔ بڑی کمپنیوں میں، سب کچھ مختلف جگہوں پر واقع ہے. پھر، اگر یہ ایک بڑی کمپنی ہے تو، تیار حل کیوں نہیں لیتے؟ مثال کے طور پر، Nutanix کی اپنی ترقی ہے، دوسری کمپنیوں (VMware...) کے پاس وہی "RDS، صرف گھر پر ہے۔"
ڈی ایس: لیکن ہم ایک الگ نفاذ کے بارے میں بات کر رہے ہیں جو صرف کچھ شرائط کے تحت کام کرے گا۔ اور اگر ہم Kubernetes کے بارے میں بات کر رہے ہیں، تو بنیادی ڈھانچے کی ایک بہت بڑی قسم ہے (جو K8s میں ہوسکتی ہے)۔ بنیادی طور پر یہ کلاؤڈ کے APIs کے لیے ایک معیار ہے...
НС: یہ بھی مفت ہے!
ڈی ایس: یہ اتنا اہم نہیں ہے۔ مارکیٹ کے بہت بڑے طبقے کے لیے آزادی اہم ہے۔ کچھ اور ضروری ہے... آپ کو شاید یہ رپورٹ یاد ہو""؟
НС: جی ہاں.
ڈی ایس: میں نے محسوس کیا کہ یہ بہت مبہم انداز میں موصول ہوا ہے۔ کچھ لوگوں نے سوچا کہ میں کہہ رہا ہوں: "دوستوں، آئیے تمام ڈیٹا بیس کوبرنیٹس میں داخل کریں!"، جبکہ دوسروں نے فیصلہ کیا کہ یہ سب خوفناک سائیکلیں تھیں۔ لیکن میں بالکل مختلف کہنا چاہتا تھا: "دیکھو کیا ہو رہا ہے، کیا مسائل ہیں اور انہیں کیسے حل کیا جا سکتا ہے۔ کیا ہمیں اب Kubernetes ڈیٹا بیس استعمال کرنا چاہیے؟ پیداوار؟ ٹھیک ہے، صرف اس صورت میں جب آپ چاہیں... کچھ چیزیں کرنا۔ لیکن ایک دیو کے لئے، میں کہہ سکتا ہوں کہ میں اس کی سفارش کرتا ہوں۔ ایک دیو کے لیے، ماحول بنانے/ حذف کرنے کی حرکیات بہت اہم ہے۔
NS: بذریعہ دیو، کیا آپ کا مطلب وہ تمام ماحول ہیں جو پروڈ نہیں ہیں؟ سٹیجنگ، QA…
ڈی ایس: اگر ہم پرف اسٹینڈز کے بارے میں بات کر رہے ہیں، تو شاید نہیں، کیونکہ وہاں کے تقاضے مخصوص ہیں۔ اگر ہم خاص کیسز کے بارے میں بات کر رہے ہیں جہاں سٹیجنگ کے لیے بہت بڑے ڈیٹا بیس کی ضرورت ہوتی ہے، تو شاید نہیں... اگر یہ ایک جامد، دیرپا ماحول ہے، تو پھر K8s میں موجود ڈیٹا بیس کا کیا فائدہ؟
НС: کوئی نہیں۔ لیکن ہم جامد ماحول کہاں دیکھتے ہیں؟ ایک جامد ماحول کل متروک ہو جائے گا۔
ڈی ایس: سٹیجنگ جامد ہو سکتا ہے۔ ہمارے پاس کلائنٹ ہیں...
НС: ہاں، میرے پاس بھی ہے۔ اگر آپ کے پاس 10 ٹی بی ڈیٹا بیس اور 200 جی بی سٹیجنگ ہے تو یہ ایک بڑا مسئلہ ہے...
ڈی ایس: میرے پاس ایک بہت اچھا کیس ہے! اسٹیجنگ پر ایک پروڈکٹ ڈیٹا بیس ہوتا ہے جس میں تبدیلیاں کی جاتی ہیں۔ اور ایک بٹن ہے: "رول آؤٹ پروڈکشن"۔ یہ تبدیلیاں - ڈیلٹا - کو پروڈکشن میں شامل کیا جاتا ہے (ایسا لگتا ہے کہ وہ صرف API کے ذریعے مطابقت پذیر ہیں)۔ یہ ایک بہت ہی غیر ملکی آپشن ہے۔
НС: میں نے وادی میں ایسے سٹارٹ اپ دیکھے ہیں جو RDS یا ہیروکو میں بیٹھے ہوئے ہیں - یہ 2-3 سال پہلے کی کہانیاں ہیں - اور وہ اپنے لیپ ٹاپ پر ڈمپ ڈاؤن لوڈ کرتے ہیں۔ کیونکہ ڈیٹا بیس اب بھی صرف 80 جی بی ہے، اور لیپ ٹاپ میں جگہ ہے۔ پھر وہ ہر ایک کے لیے اضافی ڈسک خریدتے ہیں تاکہ ان کے پاس 3 ڈیٹا بیس ہوں تاکہ مختلف پیش رفت کی جا سکے۔ ایسا بھی ہوتا ہے۔ میں نے یہ بھی دیکھا کہ وہ پروڈ کو اسٹیجنگ میں کاپی کرنے سے نہیں ڈرتے ہیں - یہ کمپنی پر بہت زیادہ منحصر ہے۔ لیکن میں نے یہ بھی دیکھا کہ وہ بہت خوفزدہ ہیں، اور یہ کہ ان کے پاس اکثر وقت اور ہاتھ نہیں ہوتے۔ لیکن اس سے پہلے کہ ہم اس موضوع پر جائیں، میں Kubernetes کے بارے میں سننا چاہتا ہوں۔ کیا میں صحیح طور پر سمجھتا ہوں کہ ابھی تک کوئی بھی پروڈکشن میں نہیں ہے؟
ڈی ایس: ہمارے پاس پروڈ میں چھوٹے ڈیٹا بیس ہیں۔ ہم دسیوں گیگا بائٹس کے حجم اور غیر اہم خدمات کے بارے میں بات کر رہے ہیں جن کے لئے ہم نقلیں بنانے میں بہت سست تھے (اور ایسی کوئی ضرورت نہیں ہے)۔ اور بشرطیکہ Kubernetes کے تحت نارمل اسٹوریج موجود ہو۔ یہ ڈیٹا بیس ایک ورچوئل مشین میں کام کرتا تھا - مشروط طور پر VMware میں، اسٹوریج سسٹم کے اوپر۔ ہم نے اسے اندر رکھا اور اب ہم اسے مشین سے مشین میں منتقل کر سکتے ہیں۔
НС: اس سائز کا ڈیٹا بیس، 100 جی بی تک، اچھی ڈسک اور اچھے نیٹ ورک پر چند منٹوں میں رول آؤٹ کیا جا سکتا ہے، ٹھیک ہے؟ 1 GB فی سیکنڈ کی رفتار اب غیر ملکی نہیں ہے۔
ڈی ایس: ہاں، لکیری آپریشن کے لیے یہ کوئی مسئلہ نہیں ہے۔
НС: ٹھیک ہے، ہمیں صرف مصنوعات کے بارے میں سوچنا ہے۔ اور اگر ہم غیر پیداواری ماحول کے لیے Kubernetes پر غور کر رہے ہیں، تو ہمیں کیا کرنا چاہیے؟ میں اسے Zalando میں دیکھ رہا ہوں۔ ، کرنچی میں ، کچھ اور اختیارات ہیں۔ اور ہے - یہ اسپین سے ہمارے اچھے دوست الوارو ہیں: وہ جو کرتے ہیں وہ بنیادی طور پر صرف نہیں ہوتا ہے۔ ، اور پوری تقسیم ()، جس میں، خود پوسٹگریس کے علاوہ، انہوں نے ایک بیک اپ بھرنے کا فیصلہ بھی کیا، ایلچی پراکسی...
ڈی ایس: کس لیے ایلچی؟ پوسٹگریس ٹریفک کو خاص طور پر متوازن کرنا؟
НС: جی ہاں. یعنی، وہ اسے اس طرح دیکھتے ہیں: اگر آپ لینکس کی تقسیم اور کرنل لیتے ہیں، تو باقاعدہ PostgreSQL دانا ہے، اور وہ ایک ایسی تقسیم کرنا چاہتے ہیں جو کلاؤڈ فرینڈلی ہو اور Kubernetes پر چلے۔ وہ اجزاء (بیک اپ وغیرہ) کو ایک ساتھ رکھتے ہیں اور انہیں ڈیبگ کرتے ہیں تاکہ وہ اچھی طرح کام کریں۔
ڈی ایس: بہت ٹھنڈا! بنیادی طور پر یہ آپ کے اپنے زیر انتظام پوسٹگریس بنانے کے لیے سافٹ ویئر ہے۔
НС: لینکس کی تقسیم میں دائمی مسائل ہیں: ڈرائیور کیسے بنائے جائیں تاکہ تمام ہارڈ ویئر کو سپورٹ کیا جائے۔ اور ان کا خیال ہے کہ وہ Kubernetes میں کام کریں گے۔ میں جانتا ہوں کہ Zalando آپریٹر میں ہم نے حال ہی میں AWS سے ایک کنکشن دیکھا ہے اور یہ اب زیادہ اچھا نہیں ہے۔ کسی خاص انفراسٹرکچر سے کوئی تعلق نہیں ہونا چاہیے - پھر کیا فائدہ؟
ڈی ایس: میں بالکل نہیں جانتا کہ Zalando کس صورت حال سے دوچار ہوا، لیکن Kubernetes میں اسٹوریج کو اب اس طرح بنایا گیا ہے کہ عام طریقہ استعمال کرتے ہوئے ڈسک کا بیک اپ لینا ناممکن ہے۔ حال ہی میں معیاری میں - تازہ ترین ورژن میں - ہم نے سنیپ شاٹس کو ممکن بنایا، لیکن اس پر عمل درآمد کہاں ہوتا ہے؟ سچ میں، سب کچھ اب بھی اتنا کچا ہے... ہم AWS, GCE, Azure, vSphere کے اوپر CSI آزما رہے ہیں، لیکن جیسے ہی آپ اسے استعمال کرنا شروع کریں گے، آپ دیکھ سکتے ہیں کہ یہ ابھی تک تیار نہیں ہے۔
НС: اسی لیے ہمیں بعض اوقات انفراسٹرکچر پر انحصار کرنا پڑتا ہے۔ میرے خیال میں یہ اب بھی ابتدائی مرحلہ ہے - بڑھتے ہوئے درد۔ سوال: آپ نئے آنے والوں کو کیا مشورہ دیں گے جو K8s میں PgSQL آزمانا چاہتے ہیں؟ کیا آپریٹر ہو سکتا ہے؟
ڈی ایس: مسئلہ یہ ہے کہ پوسٹگریس ہمارے لیے 3% ہے۔ ہمارے پاس Kubernetes میں مختلف سافٹ ویئر کی ایک بہت بڑی فہرست بھی ہے، میں ہر چیز کی فہرست بھی نہیں دوں گا۔ مثال کے طور پر، Elasticsearch. بہت سارے آپریٹرز ہیں: کچھ فعال طور پر ترقی کر رہے ہیں، دوسرے نہیں ہیں۔ ہم نے اپنے لیے اس بارے میں تقاضے تیار کیے ہیں کہ آپریٹر کے پاس اسے سنجیدگی سے لینے کے لیے کیا ہونا چاہیے۔ ایک آپریٹر میں خاص طور پر Kubernetes کے لیے - "Amazon کے حالات میں کچھ کرنے کے لیے آپریٹر" میں نہیں... درحقیقت، ہم کافی وسیع پیمانے پر (= تقریباً تمام کلائنٹس) ایک ہی آپریٹر استعمال کرتے ہیں - (ہم جلد ہی ان کے بارے میں ایک مضمون شائع کریں گے).
НС: اور MySQL کے لیے بھی نہیں؟ میں جانتا ہوں کہ Percona... چونکہ وہ اب MySQL، MongoDB، اور Postgres پر کام کر رہے ہیں، اس لیے انہیں کسی نہ کسی طرح کا عالمگیر حل بنانا پڑے گا: تمام ڈیٹا بیس کے لیے، تمام کلاؤڈ فراہم کرنے والوں کے لیے۔
ڈی ایس: ہمارے پاس MySQL کے آپریٹرز کو دیکھنے کا وقت نہیں تھا۔ یہ اس وقت ہماری بنیادی توجہ نہیں ہے۔ MySQL اسٹینڈ میں ٹھیک کام کرتا ہے۔ اگر آپ صرف ایک ڈیٹا بیس لانچ کر سکتے ہیں تو آپریٹر کیوں استعمال کریں... آپ Postrges کے ساتھ ایک Docker کنٹینر لانچ کر سکتے ہیں، یا آپ اسے آسان طریقے سے لانچ کر سکتے ہیں۔
НС: اس بارے میں بھی ایک سوال تھا۔ کوئی آپریٹر بالکل نہیں؟
ڈی ایس: ہاں، ہم میں سے 100% پوسٹگری ایس کیو ایل بغیر آپریٹر کے چلا رہے ہیں۔ اب تک تو. ہم Prometheus اور Redis کے لیے آپریٹر کو فعال طور پر استعمال کرتے ہیں۔ ہمارے پاس Elasticsearch کے لیے ایک آپریٹر تلاش کرنے کا منصوبہ ہے - یہ وہ ہے جو سب سے زیادہ "آگ پر" ہے، کیونکہ ہم اسے 100% معاملات میں Kubernetes میں انسٹال کرنا چاہتے ہیں۔ جس طرح ہم اس بات کو یقینی بنانا چاہتے ہیں کہ MongoDB بھی ہمیشہ Kubernetes میں انسٹال ہو۔ یہاں کچھ خواہشات ظاہر ہوتی ہیں - ایک احساس ہے کہ ان معاملات میں کچھ کیا جا سکتا ہے. اور ہم نے پوسٹگریس کو بھی نہیں دیکھا۔ بلاشبہ، ہم جانتے ہیں کہ مختلف اختیارات ہیں، لیکن درحقیقت ہمارے پاس اسٹینڈ اکیلا ہے۔
Kubernetes میں جانچ کے لیے DB
НС: آئیے جانچ کے موضوع کی طرف چلتے ہیں۔ ڈی او اوپس کے نقطہ نظر سے - ڈیٹا بیس میں تبدیلیوں کو کیسے رول آؤٹ کریں۔ مائیکرو سروسز ہیں، بہت سے ڈیٹا بیس، ہر وقت کہیں نہ کہیں کچھ بدلتا رہتا ہے۔ عام CI/CD کو کیسے یقینی بنایا جائے تاکہ DBMS کے نقطہ نظر سے سب کچھ ترتیب میں ہو۔ آپ کا نقطہ نظر کیا ہے؟
ڈی ایس: ایک جواب نہیں ہو سکتا۔ کئی اختیارات ہیں۔ سب سے پہلے بیس کا سائز ہے جسے ہم رول آؤٹ کرنا چاہتے ہیں۔ آپ نے خود ذکر کیا ہے کہ کمپنیاں دیو اور اسٹیج پر پروڈ ڈیٹا بیس کی کاپی رکھنے کے بارے میں مختلف رویہ رکھتی ہیں۔
НС: اور GDPR کی شرائط کے تحت، مجھے لگتا ہے کہ وہ زیادہ سے زیادہ محتاط ہو رہے ہیں... میں کہہ سکتا ہوں کہ یورپ میں انہوں نے پہلے ہی جرمانے عائد کرنا شروع کر دیے ہیں۔
ڈی ایس: لیکن اکثر آپ ایسا سافٹ ویئر لکھ سکتے ہیں جو پروڈکشن سے ڈمپ لیتا ہے اور اسے مبہم کر دیتا ہے۔ پروڈ ڈیٹا حاصل کیا جاتا ہے (اسنیپ شاٹ، ڈمپ، بائنری کاپی...)، لیکن یہ گمنام ہے۔ اس کے بجائے، جنریشن اسکرپٹ ہو سکتے ہیں: یہ فکسچر یا صرف ایک اسکرپٹ ہو سکتا ہے جو ایک بڑا ڈیٹا بیس تیار کرتا ہے۔ مسئلہ یہ ہے کہ: بیس امیج بنانے میں کتنا وقت لگتا ہے؟ اور اسے مطلوبہ ماحول میں تعینات کرنے میں کتنا وقت لگتا ہے؟
ہم ایک اسکیم پر آئے ہیں: اگر کلائنٹ کے پاس ایک مقررہ ڈیٹا سیٹ ہے (ڈیٹا بیس کا کم سے کم ورژن)، تو ہم انہیں بطور ڈیفالٹ استعمال کرتے ہیں۔ اگر ہم جائزہ لینے کے ماحول کے بارے میں بات کر رہے ہیں، جب ہم نے ایک برانچ بنائی، تو ہم نے ایپلیکیشن کی ایک مثال تعینات کی - ہم وہاں ایک چھوٹا ڈیٹا بیس تیار کرتے ہیں۔ لیکن یہ اچھا نکلا۔ ، جب ہم دن میں ایک بار پروڈکشن سے ڈمپ لیتے ہیں (رات کو) اور اس پر مبنی اس بھری ہوئی ڈیٹا کے ساتھ PostgreSQL اور MySQL کے ساتھ ایک Docker کنٹینر بناتے ہیں۔ اگر آپ کو اس تصویر سے ڈیٹا بیس کو 50 بار بڑھانے کی ضرورت ہے، تو یہ بہت آسان اور تیزی سے کیا جاتا ہے۔
НС: سادہ نقل کی طرف سے؟
ڈی ایس: ڈیٹا کو براہ راست ڈاکر امیج میں محفوظ کیا جاتا ہے۔ وہ. ہمارے پاس 100 جی بی کے باوجود ایک ریڈی میڈ امیج ہے۔ ڈوکر میں پرتوں کی بدولت، ہم اس تصویر کو جتنی بار ضرورت ہو تیزی سے تعینات کر سکتے ہیں۔ طریقہ بیوقوف ہے، لیکن یہ اچھی طرح سے کام کرتا ہے.
НС: پھر، جب آپ ٹیسٹ کرتے ہیں، تو یہ ڈوکر کے اندر ہی بدل جاتا ہے، ٹھیک ہے؟ ڈاکر کے اندر کاپی پر لکھیں - اسے پھینک دیں اور دوبارہ جائیں، سب کچھ ٹھیک ہے۔ کلاس! اور کیا آپ پہلے ہی اسے مکمل طور پر استعمال کر رہے ہیں؟
ڈی ایس: ایک طویل وقت کے لئے.
НС: ہم بہت ملتے جلتے کام کرتے ہیں۔ صرف ہم ڈوکر کی کاپی آن رائٹ استعمال نہیں کرتے ہیں، بلکہ کوئی اور استعمال کرتے ہیں۔
ڈی ایس: یہ عام نہیں ہے۔ اور Docker ہر جگہ کام کرتا ہے۔
НС: نظریہ میں، جی ہاں. لیکن ہمارے پاس وہاں ماڈیولز بھی ہیں، آپ مختلف ماڈیول بنا سکتے ہیں اور مختلف فائل سسٹمز کے ساتھ کام کر سکتے ہیں۔ یہاں کیا لمحہ ہے۔ پوسٹگریس کی طرف سے، ہم اس سب کو مختلف انداز میں دیکھتے ہیں۔ اب میں نے ڈوکر کی طرف سے دیکھا اور دیکھا کہ سب کچھ آپ کے لیے کام کرتا ہے۔ لیکن اگر ڈیٹا بیس بہت بڑا ہے، مثال کے طور پر، 1 ٹی بی، تو اس سب میں کافی وقت لگتا ہے: رات کو آپریشن، اور ہر چیز کو ڈوکر میں بھرنا... اور اگر 5 ٹی بی ڈوکر میں بھرے ہوئے ہیں... یا سب کچھ ٹھیک ہے؟
ڈی ایس: کیا فرق ہے: یہ بلاب ہیں، صرف بٹس اور بائٹس۔
НС: فرق یہ ہے: کیا آپ اسے ڈمپ اور بحالی کے ذریعے کرتے ہیں؟
ڈی ایس: بالکل ضروری نہیں۔ اس تصویر کو بنانے کے طریقے مختلف ہو سکتے ہیں۔
НС: کچھ کلائنٹس کے لیے، ہم نے اسے اس لیے بنایا ہے کہ باقاعدگی سے بیس امیج بنانے کے بجائے، ہم اسے مسلسل اپ ٹو ڈیٹ رکھیں۔ یہ بنیادی طور پر ایک نقل ہے، لیکن یہ براہ راست ماسٹر سے نہیں بلکہ آرکائیو کے ذریعے ڈیٹا حاصل کرتا ہے۔ ایک بائنری آرکائیو جہاں WALs کو ہر روز ڈاؤن لوڈ کیا جاتا ہے، جہاں بیک اپ لیا جاتا ہے... یہ WALs پھر تھوڑی تاخیر کے ساتھ بنیادی تصویر تک پہنچ جاتے ہیں (لفظی طور پر 1-2 سیکنڈ)۔ ہم کسی بھی طرح سے اس سے کلون کرتے ہیں - اب ہمارے پاس ڈیفالٹ کے طور پر ZFS ہے۔
ڈی ایس: لیکن ZFS کے ساتھ آپ ایک نوڈ تک محدود ہیں۔
НС: جی ہاں. لیکن ZFS میں بھی ایک جادو ہے۔ : اس کے ساتھ آپ اسنیپ شاٹ بھیج سکتے ہیں اور یہاں تک کہ (میں نے ابھی تک اس کا واقعی تجربہ نہیں کیا ہے، لیکن...) آپ دو کے درمیان ڈیلٹا بھیج سکتے ہیں۔ PGDATA. درحقیقت، ہمارے پاس ایک اور ٹول ہے جس پر ہم نے واقعی ایسے کاموں کے لیے غور نہیں کیا ہے۔ PostgreSQL کے پاس ہے۔ ، جو ایک "سمارٹ" rsync کی طرح کام کرتا ہے، بہت سی چیزوں کو چھوڑ دیتا ہے جو آپ کو نہیں دیکھنا پڑتا ہے، کیونکہ وہاں کچھ بھی نہیں بدلا ہے۔ ہم دونوں سرورز کے درمیان فوری مطابقت پذیری کر سکتے ہیں اور اسی طرح ریوائنڈ کر سکتے ہیں۔
لہذا، اس سے، مزید DBA کی طرف، ہم ایک ایسا ٹول بنانے کی کوشش کر رہے ہیں جو ہمیں وہی کام کرنے کی اجازت دیتا ہے جو آپ نے کہا ہے: ہمارے پاس ایک ڈیٹا بیس ہے، لیکن ہم تقریباً ایک ساتھ 50 بار کسی چیز کی جانچ کرنا چاہتے ہیں۔
ڈی ایس: 50 بار کا مطلب ہے کہ آپ کو 50 اسپاٹ مثالیں آرڈر کرنے کی ضرورت ہے۔
НС: نہیں، ہم سب کچھ ایک مشین پر کرتے ہیں۔
ڈی ایس: لیکن اگر یہ ایک ڈیٹا بیس ہے تو آپ 50 گنا کیسے پھیلائیں گے، کہہ لیں، ٹیرابائٹ۔ زیادہ تر امکان ہے کہ اسے مشروط 256 جی بی ریم کی ضرورت ہے؟
НС: ہاں، کبھی کبھی آپ کو بہت زیادہ یادداشت کی ضرورت ہوتی ہے - یہ عام بات ہے۔ لیکن یہ زندگی سے ایک مثال ہے۔ پروڈکشن مشین میں 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 اسی طرح، یہ پتہ چلتا ہے کہ ہم اصل میں Postgres کو دھوکہ دے رہے ہیں. چال یہ ہے: مثال کے طور پر، 10 پوسٹگریس بیک وقت لانچ کیے جاتے ہیں۔ عام طور پر کیا مسئلہ ہوتا ہے؟ انہوں نے ڈالا۔ ، آئیے کہتے ہیں 25%۔ اس کے مطابق، یہ 200 جی بی ہے۔ آپ ان میں سے تین سے زیادہ لانچ نہیں کر پائیں گے، کیونکہ میموری ختم ہو جائے گی۔
لیکن کسی وقت ہمیں احساس ہوا کہ یہ ضروری نہیں ہے: ہم نے مشترکہ_بفرز کو 2 جی بی پر سیٹ کیا۔ PostgreSQL کے پاس ہے۔ ، اور حقیقت میں یہ صرف وہی ہے جو اثر انداز ہوتا ہے۔ . ہم نے اسے 0,5 TB پر سیٹ کیا۔ اور اس سے بھی کوئی فرق نہیں پڑتا کہ وہ اصل میں موجود نہیں ہیں: وہ ایسے منصوبے بناتا ہے جیسے وہ موجود ہوں۔
اس کے مطابق، جب ہم کسی قسم کی منتقلی کی جانچ کرتے ہیں، تو ہم تمام منصوبوں کو جمع کر سکتے ہیں - ہم دیکھیں گے کہ یہ پیداوار میں کیسے ہو گا۔ وہاں کے سیکنڈ مختلف (سست) ہوں گے، لیکن وہ ڈیٹا جو ہم اصل میں پڑھتے ہیں، اور خود پلانز (وہاں کیا شامل ہوتے ہیں، وغیرہ) بالکل وہی نکلتے ہیں جیسا کہ پروڈکشن میں ہوتا ہے۔ اور آپ ایک مشین پر متوازی طور پر اس طرح کے کئی چیک چلا سکتے ہیں۔
ڈی ایس: کیا آپ کو نہیں لگتا کہ یہاں کچھ مسائل ہیں؟ پہلا ایک حل ہے جو صرف PostgreSQL پر کام کرتا ہے۔ یہ نقطہ نظر بہت نجی ہے، یہ عام نہیں ہے۔ دوسرا یہ کہ Kubernetes (اور ہر وہ چیز جو کلاؤڈ ٹیکنالوجیز اب جا رہی ہیں) میں بہت سے نوڈس شامل ہیں، اور یہ نوڈس عارضی ہیں۔ اور آپ کے معاملے میں یہ ایک ریاستی، مستقل نوڈ ہے۔ یہ چیزیں مجھے متضاد بناتی ہیں۔
НС: سب سے پہلے، میں اتفاق کرتا ہوں، یہ مکمل طور پر پوسٹگریس کی کہانی ہے۔ مجھے لگتا ہے کہ اگر ہمارے پاس تقریبا تمام میموری کے لئے کسی قسم کا براہ راست IO اور بفر پول ہے، تو یہ نقطہ نظر کام نہیں کرے گا - منصوبے مختلف ہوں گے. لیکن ابھی کے لیے ہم صرف پوسٹگریس کے ساتھ کام کرتے ہیں، ہم دوسروں کے بارے میں نہیں سوچتے۔
Kubernetes کے بارے میں۔ آپ خود ہمیں ہر جگہ بتاتے ہیں کہ ہمارے پاس مستقل ڈیٹا بیس ہے۔ اگر مثال ناکام ہوجاتی ہے تو، اہم چیز ڈسک کو محفوظ کرنا ہے۔ یہاں ہمارے پاس Kubernetes میں پورا پلیٹ فارم بھی ہے، اور Postgres کے ساتھ جزو الگ ہے (حالانکہ یہ ایک دن وہاں ہو گا)۔ لہذا، سب کچھ اس طرح ہے: مثال گر گئی، لیکن ہم نے اس کے پی وی کو محفوظ کیا اور اسے کسی اور (نئی) مثال سے جوڑ دیا، جیسے کہ کچھ ہوا ہی نہیں تھا۔
ڈی ایس: میرے نقطہ نظر سے، ہم Kubernetes میں پھلیاں بناتے ہیں۔ K8s - لچکدار: ضرورت کے مطابق گرہیں ترتیب دی جاتی ہیں۔ کام صرف ایک پوڈ بنانا ہے اور یہ کہنا ہے کہ اسے وسائل کی X مقدار کی ضرورت ہے، اور پھر K8s خود ہی اس کا پتہ لگا لے گا۔ لیکن کبرنیٹس میں اسٹوریج سپورٹ اب بھی غیر مستحکم ہے: میں (یہ ریلیز جاری کیا گیا تھا ہفتے کے پہلے) یہ خصوصیات صرف بیٹا بن جاتی ہیں۔
چھ ماہ سے ایک سال گزر جائے گا - یہ کم و بیش مستحکم ہو جائے گا، یا کم از کم اسے ایسے ہی قرار دیا جائے گا۔ پھر سنیپ شاٹس اور سائز تبدیل کرنے کا امکان آپ کے مسئلے کو مکمل طور پر حل کرتا ہے۔ کیونکہ آپ کی بنیاد ہے۔ ہاں، یہ بہت تیز نہیں ہوسکتا ہے، لیکن رفتار اس بات پر منحصر ہے کہ "ہڈ کے نیچے" کیا ہے، کیونکہ کچھ نفاذات ڈسک سب سسٹم کی سطح پر کاپی اور کاپی آن رائٹ کر سکتے ہیں۔
НС: تمام انجنوں (ایمیزون، گوگل...) کے لیے اس ورژن کو سپورٹ کرنا بھی ضروری ہے - اس میں بھی کچھ وقت لگتا ہے۔
ڈی ایس: ہم انہیں ابھی تک استعمال نہیں کرتے ہیں۔ ہم اپنا استعمال کرتے ہیں۔
Kubernetes کے لیے مقامی ترقی
НС: کیا آپ کو ایسی خواہش آئی ہے جب آپ کو تمام پوڈز کو ایک مشین پر انسٹال کرنے اور اتنا چھوٹا ٹیسٹ کرنے کی ضرورت ہے؟ فوری طور پر تصور کا ثبوت حاصل کرنے کے لیے، دیکھیں کہ یہ ایپلیکیشن کبرنیٹس میں چلتی ہے، اس کے لیے مشینوں کا ایک گروپ وقف کیے بغیر۔ وہاں Minikube ہے، ٹھیک ہے؟
ڈی ایس: مجھے ایسا لگتا ہے کہ یہ کیس - ایک نوڈ پر تعینات - خاص طور پر مقامی ترقی کے بارے میں ہے۔ یا اس طرح کے نمونے کے کچھ مظاہر۔ کھاؤ ، وہاں ہے , . ہم Docker میں Kubernetes استعمال کرنے کی طرف بڑھ رہے ہیں۔ اب ہم نے ٹیسٹ کے لیے اس کے ساتھ کام کرنا شروع کر دیا۔
НС: میں سمجھتا تھا کہ یہ تمام پوڈز کو ایک ڈاکر امیج میں لپیٹنے کی کوشش ہے۔ لیکن یہ پتہ چلا کہ یہ بالکل مختلف چیز کے بارے میں ہے۔ ویسے بھی، الگ کنٹینر، الگ پوڈز ہیں - بس ڈوکر میں۔
ڈی ایس: جی ہاں. اور ایک مضحکہ خیز تقلید کی گئی ہے، لیکن معنی یہ ہے... ہمارے پاس تعیناتی کی افادیت ہے - . ہم اسے مشروط موڈ بنانا چاہتے ہیں۔ werf up: "مجھے مقامی Kubernetes حاصل کرو۔" اور پھر وہاں مشروط چلائیں۔ werf follow. پھر ڈویلپر IDE میں ترمیم کرنے کے قابل ہو جائے گا، اور سسٹم میں ایک عمل شروع کیا جائے گا جو تبدیلیوں کو دیکھتا ہے اور تصاویر کو دوبارہ بناتا ہے، انہیں مقامی K8s پر دوبارہ تعینات کرتا ہے۔ اس طرح ہم مقامی ترقی کے مسئلے کو حل کرنے کی کوشش کرنا چاہتے ہیں۔
K8s حقیقت میں سنیپ شاٹس اور ڈیٹا بیس کی کلوننگ
НС: اگر ہم کاپی آن رائٹ پر واپس آتے ہیں۔ میں نے دیکھا کہ بادلوں میں بھی سنیپ شاٹس ہیں۔ وہ مختلف طریقے سے کام کرتے ہیں۔ مثال کے طور پر، GCP میں: آپ کے پاس ریاستہائے متحدہ کے مشرقی ساحل پر ملٹی ٹیرابائٹ مثال ہے۔ آپ وقتا فوقتا اسنیپ شاٹس لیتے ہیں۔ آپ اسنیپ شاٹ سے مغربی ساحل پر ڈسک کی ایک کاپی اٹھا لیتے ہیں - چند منٹوں میں سب کچھ تیار ہو جاتا ہے، یہ بہت تیزی سے کام کرتا ہے، میموری میں صرف کیشے کو بھرنے کی ضرورت ہے۔ لیکن یہ کلون (اسنیپ شاٹس) ایک نیا حجم 'فراہم' کرنے کے لیے ہیں۔ جب آپ کو بہت ساری مثالیں بنانے کی ضرورت ہوتی ہے تو یہ اچھا ہے۔
لیکن ٹیسٹوں کے لیے، مجھے لگتا ہے کہ اسنیپ شاٹس، جن کے بارے میں آپ Docker میں بات کرتے ہیں یا میں ZFS، btrfs اور یہاں تک کہ LVM میں بھی بات کرتا ہوں... - وہ آپ کو ایک مشین پر واقعی نیا ڈیٹا بنانے کی اجازت نہیں دیتے ہیں۔ بادل میں، آپ اب بھی ہر بار ان کے لیے ادائیگی کریں گے اور سیکنڈوں کا نہیں بلکہ منٹوں کا انتظار کریں گے (اور اس معاملے میں ، ممکنہ طور پر ایک گھڑی)۔
اس کے بجائے، آپ یہ ڈیٹا ایک یا دو سیکنڈ میں حاصل کر سکتے ہیں، ٹیسٹ چلائیں اور اسے پھینک دیں۔ یہ سنیپ شاٹس مختلف مسائل کو حل کرتے ہیں۔ پہلی صورت میں - بڑے پیمانے پر اور نئی نقلیں حاصل کرنے کے لیے، اور دوسری میں - ٹیسٹ کے لیے۔
ڈی ایس: میں متفق نہیں ہوں۔ والیوم کلوننگ کے کام کو صحیح طریقے سے بنانا کلاؤڈ کا کام ہے۔ میں نے ان کے نفاذ کو نہیں دیکھا، لیکن میں جانتا ہوں کہ ہم اسے ہارڈ ویئر پر کیسے کرتے ہیں۔ ہمارے پاس Ceph ہے، یہ کسی بھی جسمانی حجم کی اجازت دیتا ہے () کہنا کلون اور دسیوں ملی سیکنڈ میں اسی خصوصیات کے ساتھ دوسری والیوم حاصل کریں، 'امی، وغیرہ آپ کو یہ سمجھنے کی ضرورت ہے کہ اندر ایک مشکل کاپی آن رائٹ ہے۔ بادل کو ایسا کیوں نہیں کرنا چاہئے؟ مجھے یقین ہے کہ وہ کسی نہ کسی طرح ایسا کرنے کی کوشش کر رہے ہیں۔
НС: لیکن پھر بھی ان کو سیکنڈ، دسیوں سیکنڈ لگیں گے ایک مثال اٹھانے، ڈوکر کو وہاں لانے، وغیرہ۔
ڈی ایس: ایک پوری مثال کو اٹھانا کیوں ضروری ہے؟ ہمارے پاس 32 کور، 16... کے ساتھ ایک مثال ہے اور یہ اس میں فٹ ہو سکتا ہے - مثال کے طور پر، چار۔ جب ہم پانچویں کو آرڈر کرتے ہیں، تو مثال پہلے ہی اٹھا دی جائے گی، اور پھر اسے حذف کر دیا جائے گا۔
НС: ہاں، دلچسپ، Kubernetes ایک مختلف کہانی نکلی ہے۔ ہمارا ڈیٹا بیس K8s میں نہیں ہے، اور ہمارے پاس ایک مثال ہے۔ لیکن ملٹی ٹیرا بائٹ ڈیٹا بیس کی کلوننگ میں دو سیکنڈ سے زیادہ وقت نہیں لگتا۔
ڈی ایس: یہ بہت اچھا ہے. لیکن میرا ابتدائی نقطہ یہ ہے کہ یہ عام حل نہیں ہے۔ ہاں، یہ اچھا ہے، لیکن یہ صرف پوسٹگریس کے لیے موزوں ہے اور صرف ایک نوڈ پر۔
НС: یہ نہ صرف پوسٹگریس کے لیے موزوں ہے: یہ منصوبے، جیسا کہ میں نے بیان کیا ہے، صرف اس میں کام کریں گے۔ لیکن اگر ہم منصوبوں کی فکر نہیں کرتے ہیں، اور ہمیں صرف فنکشنل ٹیسٹنگ کے لیے تمام ڈیٹا کی ضرورت ہے، تو یہ کسی بھی DBMS کے لیے موزوں ہے۔
ڈی ایس: بہت سال پہلے ہم نے LVM سنیپ شاٹس پر کچھ ایسا ہی کیا تھا۔ یہ ایک کلاسک ہے۔ یہ نقطہ نظر بہت فعال طور پر استعمال کیا گیا تھا. ریاستی نوڈس صرف ایک درد ہیں۔ کیونکہ آپ کو انہیں نہیں چھوڑنا چاہئے، آپ کو انہیں ہمیشہ یاد رکھنا چاہئے ...
НС: کیا آپ کو یہاں ہائبرڈ کا کوئی امکان نظر آتا ہے؟ آئیے کہتے ہیں کہ اسٹیٹفول ایک قسم کا پوڈ ہے، یہ کئی لوگوں (بہت سے ٹیسٹرز) کے لیے کام کرتا ہے۔ ہمارے پاس ایک حجم ہے، لیکن فائل سسٹم کی بدولت، کلون مقامی ہیں۔ اگر پوڈ گر جاتا ہے، لیکن ڈسک باقی رہتی ہے، پوڈ اوپر آجائے گا، تمام کلون کے بارے میں معلومات گنیں گے، سب کچھ دوبارہ اٹھائیں گے اور کہیں گے: "یہ رہے ان بندرگاہوں پر آپ کے کلون چل رہے ہیں، ان کے ساتھ کام جاری رکھیں۔"
ڈی ایس: تکنیکی طور پر اس کا مطلب ہے کہ Kubernetes کے اندر یہ ایک پوڈ ہے جس کے اندر ہم بہت سے Postgres چلاتے ہیں۔
НС: جی ہاں. اس کی ایک حد ہے: آئیے کہتے ہیں کہ ایک ہی وقت میں 10 سے زیادہ لوگ اس کے ساتھ کام نہیں کرتے ہیں۔ اگر آپ کو 20 کی ضرورت ہے، تو ہم اس طرح کا دوسرا پوڈ لانچ کریں گے۔ ہم اسے مکمل طور پر کلون کریں گے، دوسری مکمل والیوم موصول ہونے کے بعد، اس میں وہی 10 "پتلے" کلون ہوں گے۔ کیا آپ کو یہ موقع نظر نہیں آتا؟
ڈی ایس: ہمیں یہاں سیکورٹی کے مسائل شامل کرنے کی ضرورت ہے۔ اس قسم کی تنظیم کا مطلب یہ ہے کہ اس پوڈ میں اعلی مراعات (صلاحیتیں) ہیں، کیونکہ یہ فائل سسٹم پر غیر معیاری کام انجام دے سکتی ہے... لیکن میں دہراتا ہوں: مجھے یقین ہے کہ درمیانی مدت میں وہ کبرنیٹس میں اسٹوریج کو ٹھیک کر دیں گے، اور بادل وہ جلدوں کے ساتھ پوری کہانی کو ٹھیک کریں گے - سب کچھ "بس کام کرے گا"۔ سائز تبدیل کریں گے، کلوننگ کریں گے... ایک والیوم ہے - ہم کہتے ہیں: "اس کی بنیاد پر ایک نیا بنائیں" اور ڈیڑھ سیکنڈ کے بعد ہمیں اپنی ضرورت کی چیز مل جاتی ہے۔
НС: میں کئی ٹیرا بائٹس کے لیے ڈیڑھ سیکنڈ پر یقین نہیں رکھتا۔ سیف پر آپ یہ خود کرتے ہیں، لیکن آپ بادلوں کی بات کرتے ہیں۔ کلاؤڈ پر جائیں، EC2 پر ملٹی ٹیرابائٹ EBS والیوم کا کلون بنائیں اور دیکھیں کہ کارکردگی کیا ہوگی۔ اس میں چند سیکنڈ نہیں لگیں گے۔ میں اس میں بہت دلچسپی رکھتا ہوں کہ وہ اس سطح پر کب پہنچیں گے۔ میں سمجھتا ہوں کہ آپ کیا کہہ رہے ہیں، لیکن میں اختلاف کرنے کی درخواست کرتا ہوں۔
ڈی ایس: ٹھیک ہے، لیکن میں نے درمیانی مدت میں کہا، مختصر مدت میں نہیں۔ کئی سال کے لئے.
Zalando سے PostgreSQL کے آپریٹر کے بارے میں
اس میٹنگ کے وسط میں، Zalando کے ایک سابق ڈویلپر، Alexey Klyukin نے بھی شمولیت اختیار کی اور PostgreSQL آپریٹر کی تاریخ کے بارے میں بات کی:
یہ بہت اچھا ہے کہ اس موضوع کو عام طور پر چھوا ہے: پوسٹگریس اور کوبرنیٹس دونوں۔ جب ہم نے اسے 2017 میں Zalando میں کرنا شروع کیا تو یہ ایک ایسا موضوع تھا جسے ہر کوئی کرنا چاہتا تھا، لیکن کسی نے ایسا نہیں کیا۔ سب کے پاس پہلے سے ہی Kubernetes موجود تھے، لیکن جب انہوں نے پوچھا کہ ڈیٹا بیس کے ساتھ کیا کرنا ہے، یہاں تک کہ لوگ بھی پسند کرتے ہیں۔ ، جس نے K8s کی تبلیغ کی، کچھ اس طرح کہا:
"منظم خدمات پر جائیں اور انہیں استعمال کریں، کوبرنیٹس میں ڈیٹا بیس نہ چلائیں۔ بصورت دیگر، آپ کے K8s فیصلہ کریں گے، مثال کے طور پر، اپ گریڈ کرنے کے لیے، تمام نوڈس کو بند کر دیں، اور آپ کا ڈیٹا بہت دور تک اڑ جائے گا۔"
ہم نے ایک آپریٹر بنانے کا فیصلہ کیا ہے جو کہ اس مشورے کے برعکس Kubernetes میں Postgres ڈیٹا بیس شروع کرے گا۔ اور ہمارے پاس ایک اچھی وجہ تھی - . یہ PostgreSQL کے لیے ایک خودکار فیل اوور ہے، صحیح طریقے سے کیا گیا، یعنی کلسٹر کے بارے میں معلومات کے ذخیرہ کے طور پر etcd، قونصل یا ZooKeeper کا استعمال۔ ایسا ذخیرہ جو ہر اس شخص کو دے گا جو پوچھے گا، مثال کے طور پر، موجودہ لیڈر کیا ہے، وہی معلومات - اس حقیقت کے باوجود کہ ہمارے پاس سب کچھ تقسیم ہے - تاکہ دماغ تقسیم نہ ہو۔ اس کے علاوہ ہمارے پاس تھا۔ اس کے لیے.
عام طور پر، کمپنی کی آٹو فیل اوور کی ضرورت اندرونی ہارڈویئر ڈیٹا سینٹر سے کلاؤڈ میں منتقل ہونے کے بعد ظاہر ہوئی۔ کلاؤڈ ایک ملکیتی PaaS (Plateform-as-a-Service) حل پر مبنی تھا۔ یہ اوپن سورس ہے، لیکن اسے شروع کرنے اور چلانے میں کافی کام ہوا۔ یہ کہلاتا تھا .
ابتدائی طور پر، کوئی Kubernetes نہیں تھا. مزید واضح طور پر، جب ہمارا اپنا حل تعینات کیا گیا تھا، K8 پہلے سے موجود تھا، لیکن یہ اتنا خام تھا کہ یہ پیداوار کے لیے موزوں نہیں تھا۔ یہ میری رائے میں 2015 یا 2016 تھا۔ 2017 تک، Kubernetes کم و بیش بالغ ہو چکے تھے- وہاں ہجرت کرنے کی ضرورت تھی۔
اور ہمارے پاس پہلے سے ہی ایک ڈوکر کنٹینر تھا۔ ایک PaaS تھا جو Docker استعمال کرتا تھا۔ K8s کیوں نہیں آزماتے؟ اپنا آپریٹر کیوں نہیں لکھتے؟ مرات کابیلوف، جو ایویٹو سے ہمارے پاس آئے تھے، نے اسے اپنی ہی پہل پر ایک پروجیکٹ کے طور پر شروع کیا - "کھیلنے کے لیے" - اور اس پروجیکٹ کو "چلایا گیا۔"
لیکن عام طور پر، میں AWS کے بارے میں بات کرنا چاہتا تھا۔ AWS سے متعلق تاریخی کوڈ کیوں تھا...
جب آپ Kubernetes میں کچھ چلاتے ہیں، تو آپ کو یہ سمجھنا ہوگا کہ K8s ایسا کام جاری ہے۔ یہ مسلسل ترقی کر رہا ہے، بہتر ہو رہا ہے اور وقتاً فوقتاً ٹوٹ رہا ہے۔ آپ کو Kubernetes میں ہونے والی تمام تبدیلیوں پر گہری نظر رکھنے کی ضرورت ہے، اگر کچھ ہوتا ہے تو آپ کو اس میں غوطہ لگانے کے لیے تیار رہنا چاہیے اور یہ جاننا چاہیے کہ یہ کس طرح تفصیل سے کام کرتا ہے - شاید آپ کی مرضی سے زیادہ۔ یہ اصولی طور پر کسی بھی پلیٹ فارم پر لاگو ہوتا ہے جس پر آپ اپنا ڈیٹا بیس چلاتے ہیں...
لہذا، جب ہم نے بیان کیا، تو ہمارے پاس پوسٹگریس ایک بیرونی حجم پر چل رہا تھا (اس معاملے میں EBS، چونکہ ہم AWS پر کام کر رہے تھے)۔ ڈیٹا بیس میں اضافہ ہوا، کسی وقت اس کا سائز تبدیل کرنا ضروری تھا: مثال کے طور پر، EBS کا ابتدائی سائز 100 TB تھا، ڈیٹا بیس اس تک بڑھ گیا، اب ہم EBS کو 200 TB بنانا چاہتے ہیں۔ کیسے؟ ہم کہتے ہیں کہ آپ کسی نئی مثال پر ڈمپ/ریسٹور کر سکتے ہیں، لیکن اس میں کافی وقت لگے گا اور اس میں ڈاؤن ٹائم شامل ہوگا۔
لہذا، میں ایک نیا سائز چاہتا ہوں جو EBS پارٹیشن کو بڑا کرے اور پھر فائل سسٹم کو نئی جگہ استعمال کرنے کے لیے کہے۔ اور ہم نے یہ کیا، لیکن اس وقت کبرنیٹس کے پاس ری سائز آپریشن کے لیے کوئی API نہیں تھا۔ چونکہ ہم نے AWS پر کام کیا، ہم نے اس کے API کے لیے کوڈ لکھا۔
کوئی بھی آپ کو دوسرے پلیٹ فارمز کے لیے ایسا کرنے سے نہیں روک رہا ہے۔ اس بیان میں کوئی اشارہ نہیں ہے کہ اسے صرف AWS پر چلایا جا سکتا ہے، اور یہ ہر چیز پر کام نہیں کرے گا۔ عام طور پر، یہ ایک اوپن سورس پروجیکٹ ہے: اگر کوئی نئے API کے استعمال کو تیز کرنا چاہتا ہے، تو آپ کا استقبال ہے۔ کھاؤ , درخواستیں کھینچیں - Zalando ٹیم ان کا فوری جواب دینے اور آپریٹر کو فروغ دینے کی کوشش کرتی ہے۔ جہاں تک میں جانتا ہوں، پروجیکٹ گوگل سمر آف کوڈ اور کچھ دیگر اسی طرح کے اقدامات پر۔ Zalando اس پر بہت سرگرمی سے کام کر رہا ہے۔
PS بونس!
اگر آپ PostgreSQL اور Kubernetes کے موضوع میں دلچسپی رکھتے ہیں، تو براہ کرم یہ بھی نوٹ کریں کہ اگلا پوسٹگریس منگل گزشتہ ہفتے ہوا تھا، جہاں میں نے نکولائی سے بات کی تھی۔ زیلینڈو سے الیگزینڈر کوکوشکن. اس سے ویڈیو دستیاب ہے۔ .
پی پی ایس
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com