في نهاية العام الماضي ، تم بث مباشر آخر لمجتمع PostgreSQL الروسي
#RuPostgres ،
تحدث خلاله مؤسسها المشارك نيكولاي ساموكفالوف مع المدير الفني لفلانتا ديمتري ستولياروف حول نظام إدارة قواعد البيانات هذا في سياق Kubernetes.
نحن ننشر نسخة من النص الرئيسي لهذه المناقشة ، وتم نشر فيديو كامل
على قناة المجتمع على YouTube :
قواعد البيانات و Kubernetes
NS : لن نتحدث عن الفراغات ونقاط التفتيش اليوم. نريد أن نتحدث عن Kubernetes. أعلم أن لديك العديد من سنوات الخبرة. شاهدت مقاطع الفيديو الخاصة بك وقمت حتى بمراجعة بعض المقاطع ... دعنا نتفادى الأمر مباشرةً: لماذا Postgres أو MySQL في K8s؟سؤال: لا توجد إجابة واحدة على هذا السؤال ولا يمكن أن تكون كذلك. ولكن بشكل عام ، هو البساطة والراحة ... المحتملة. بعد كل شيء ، الجميع يريد الخدمات المدارة.
NS : أن تحب RDS ، فقط في المنزل؟DS : نعم: أن تحب RDS ، في أي مكان فقط.
NS : "في أي مكان" هو نقطة جيدة. في الشركات الكبيرة ، يوجد كل شيء في أماكن مختلفة. ولماذا ، إذا كانت هذه شركة كبيرة ، لا تأخذ حلاً جاهزًا؟ على سبيل المثال ، لدى Nutanix تطوراتها الخاصة ، في حين أن الشركات الأخرى (VMware ...) لديها نفس "RDS ، فقط في المنزل".DS : لكننا نتحدث عن تطبيق واحد يعمل فقط في ظل ظروف معينة. وإذا كنا نتحدث عن Kubernetes ، فهناك مجموعة كبيرة ومتنوعة من البنية التحتية (التي يمكن أن تكون في K8s). هذا هو الأساس لمعيار API إلى السحابة ...
NS : إنه مجاني أيضًا!DS : هذا ليس مهم جدا. مجاني ليس مهما لقطاع كبير جدا من السوق. شيء آخر مهم ... ربما تتذكر تقرير "
قواعد البيانات و Kubernetes "؟
NS : نعم.دي إس : لقد أدركت أنه كان ينظر إليه بشكل غامض. اعتقد بعض الناس أنني كنت أقول: "شباب ، كل قواعد البيانات ذهبت إلى Kubernetes!" ، بينما قرر آخرون أنهم كانوا جميعهم دراجات فظيعة. وأردت أن أقول شيئًا آخر تمامًا: "انظر إلى ما يحدث ، ما هي المشاكل وكيف يمكن حلها. اذهب الآن قواعد في Kubernetes؟ Production'om؟ حسنا ، فقط إذا كنت تحب ... تفعل أشياء معينة. ولكن لديف ، أستطيع أن أقول إنني أوصي به. بالنسبة إلى dev ، يعد إنشاء / حذف بيئات ديناميكية أمرًا مهمًا للغاية. "
NS: بواسطة ديف ، هل تعني جميع البيئات التي ليست همز؟ التدريج ، ضمان الجودة ...د. س : إذا كنا نتحدث عن المواقف المثالية ، فمن المحتمل ألا يكون ذلك بالفعل ، لأن المتطلبات محددة هناك. إذا كنا نتحدث عن حالات خاصة تحتاج فيها التدريج إلى قاعدة بيانات كبيرة جدًا ، فمن المحتمل ألا تكون كذلك ... إذا كانت هذه بيئة ثابتة وطويلة العمر ، فما الفائدة من وجود القاعدة في K8s؟
NS : لا شيء. لكن أين نرى البيئات الثابتة؟ البيئة الثابتة عفا عليها الزمن غدا.DS : التدريج يمكن أن يكون ثابتا. لدينا عملاء ...
NS : نعم ، لدي أيضًا. المشكلة الكبيرة هي إذا كان لديك قاعدة 10 تيرابايت وتدريجيا - 200 غيغابايت ...DS : لدي حالة رائعة جدا! على التدريج هناك قاعدة prod'ovy التي يتم إجراء التغييرات. ويتم توفير زر: "طرح لإنتاج". تتم إضافة هذه التغييرات - deltas - (على ما يبدو ، يتم مزامنتها فقط من قبل API) في الإنتاج. هذا هو خيار غريب للغاية.
NS : لقد رأيت الشركات الناشئة في الوادي الذين يجلسون في RDS أو حتى في Heroku حتى الآن - هذه قصص من 2-3 سنوات - ويقومون بتنزيلها على جهاز الكمبيوتر المحمول الخاص بهم. لأن القاعدة 80 غيغابايت فقط حتى الآن ، وهناك مكان على الكمبيوتر المحمول. ثم يقومون بشراء الأقراص للجميع ، بحيث يكون لديهم 3 قواعد ، حتى يتمكنوا من تنفيذ تطورات مختلفة. هذا يحدث أيضا. ورأيت أيضًا أنهم لا يخشون نسخ المنتج إلى مراحل - هذا يعتمد إلى حد كبير على الشركة. لكنه رأى أنهم كانوا خائفين للغاية ، وأنه في كثير من الأحيان لم يكن لديهم ما يكفي من الوقت واليدين. لكن قبل أن ننتقل إلى هذا الموضوع ، أريد أن أسمع عن Kubernetes. أنا أفهم بشكل صحيح أنه في prod'e حتى الآن لا أحد؟DS : لدينا قواعد صغيرة في همز. نحن نتحدث عن مجلدات من عشرات الجيجابايت والخدمات غير الضرورية ، والتي كان كسولًا جدًا في إنشاء نسخ متماثلة (وليس هناك حاجة إلى ذلك). وشريطة أن تحت Kubernetes هناك تخزين طبيعي. عملت قاعدة البيانات هذه في جهاز افتراضي - مشروط في VMware ، بالإضافة إلى مساحة التخزين. وضعناها في
PV ، والآن يمكننا نقلها من سيارة إلى أخرى.
NS : يمكن نشر قواعد بهذا الحجم ، تصل إلى 100 جيجابايت ، على أقراص جيدة ومع شبكة جيدة في بضع دقائق ، أليس كذلك؟ سرعة 1 غيغابايت في الثانية لم تعد غريبة.DS : نعم ، بالنسبة لعملية خطية ، هذه ليست مشكلة.
NS : حسنًا ، يجب أن نفكر فقط في همز. وإذا أخذنا في الاعتبار Kubernetes لبيئات غير هجرة - كيف نفعل ذلك؟ أرى أنه في زالاندو يصنعون مشغلًا ، وفي كرنشي يقومون بالنشر ، هناك بعض الخيارات الأخرى. وهناك OnGres - هذا هو صديقنا العزيز Alvaro من إسبانيا: فهم ليسوا مجرد مشغل ، ولكن توزيعًا كاملاً ( StackGres ) ، حيث قرروا أيضًا ، بالإضافة إلى Postgres أنفسهم ، تعبئة النسخ الاحتياطي ، وكيل Envoy ...س : مبعوث من أجل ماذا؟ Postgres موازنة حركة المرور بالضبط؟
NS : نعم. أي أنهم يرون ذلك على النحو التالي: إذا كنت تأخذ توزيع Linux و kernel ، فإن PostgreSQL المعتاد هو kernel ، ويريدون إجراء توزيع سهل السحاب ويعمل على Kubernetes. يرسوون المكونات (النسخ الاحتياطي ، إلخ) وتصحيح بحيث تعمل بشكل جيد.DS : رائع جدا! في جوهرها ، إنه برنامج لجعل Postgres المدارة الخاصة بك.
NS : توزيعات Linux لها مشكلات أبدية: كيفية إنشاء برامج تشغيل بحيث يتم دعم جميع الأجهزة. ولديهم فكرة أنهم سيعملون في Kubernetes. أعلم أنه في مشغل Zalando رأينا مؤخرًا مقل العيون على AWS وهذا ليس جيدًا جدًا. لا ينبغي أن تكون هناك روابط لبنية تحتية محددة - ما هي النقطة إذن؟DS : لا أعرف في أي موقف معين تورط فيه زالاندو ، ولكن في Kubernetes يتم الآن تخزينه بطريقة تجعل من المستحيل إزالة نسخة احتياطية للقرص بطريقة عامة. في الآونة الأخيرة ، جعل المعيار - في أحدث إصدار من
مواصفات CSI - إمكانية الحصول على لقطات ، ولكن أين يتم تطبيقه؟ بصراحة ، لا يزال الأمر صعبًا للغاية ... نحن نحاول استخدام CSI فوق AWS و GCE و Azure و vSphere ، لكننا بدأنا في استخدامه قليلاً ، كما ترون أنها ليست جاهزة بعد.
NS : لذلك ، في بعض الأحيان يكون عليك ربط البنية التحتية. أعتقد أن هذا لا يزال مرحلة مبكرة - مشاكل النمو. سؤال: ما الذي تنصح به للمبتدئين الذين يرغبون في تجربة PgSQL في K8s؟ الذي المشغل ربما؟DS : المشكلة هي أن Postgres بالنسبة لنا هو 3 ٪. لا يزال لدينا قائمة كبيرة جدًا من البرامج المختلفة في Kubernetes ، ولن أدرج كل شيء حتى. على سبيل المثال ، Elasticsearch. هناك الكثير من المشغلين: بعضهم يتطور بنشاط ، والبعض الآخر لا يتطور. لأنفسنا ، قمنا بتوفير المتطلبات التي يجب أن تكون في المشغل ، حتى نأخذه على محمل الجد. المشغل مخصص خصيصًا لـ Kubernetes - وليس "المشغل للقيام بشيء ما بموجب شروط Amazon ..." في الواقع ، نحن نستخدم مشغلًا واحدًا على نطاق واسع (= لكل العملاء تقريبًا) - من أجل Redis (سننشر
مقالًا عنه قريبًا) .
NS : لكن بالنسبة إلى MySQL ، أيضًا؟ أعلم أن Percona ... نظرًا لأنهم متورطون الآن في MySQL و MongoDB و Postgres ، فسيتعين عليهم الحصول على نوع من gash العالمي: لجميع قواعد البيانات ، لجميع مزودي الخدمات السحابية.DS : لم يكن لدينا وقت للنظر في بيانات MySQL. بالنسبة لنا ، ليس هذا هو التركيز الرئيسي الآن. MySQL يعمل بشكل جيد في قائمة بذاتها. لماذا مشغل ، إذا كان يمكنك فقط بدء قاعدة البيانات ... يمكنك بدء تشغيل حاوية Docker مع Postrges ، أو يمكنك بدء تشغيله بطريقة بسيطة.
NS : كان هذا أيضًا سؤال. لا المشغل على الإطلاق؟DS : نعم ، 100 ٪ منا يعمل على تشغيل بوستجرس بدون مشغل. حتى الان نحن نستخدم المشغل بفعالية لـ Prometheus و Redis. لدينا خطط لإيجاد مشغل لـ Elasticsearch - إنها تحترق أكثر لأننا نريد تثبيته في 100 ٪ من الحالات في Kubernetes. كما نريد التأكد من تثبيت MongoDB دائمًا في Kubernetes أيضًا. تظهر قائمة أمنيات معينة هنا - هناك شعور بأنه في هذه الحالات يمكن القيام بشيء ما. وحول بوستجرس لم ننظر حتى. بالطبع ، نحن نعرف عن وجود خيارات مختلفة ، ولكن في الواقع لدينا قائمة بذاتها.
اختبار قاعدة البيانات في Kubernetes
NS : دعنا ننتقل إلى موضوع الاختبار. كيفية طرح التغييرات في قاعدة البيانات - من وجهة نظر منظور DevOps. هناك خدمات micros والعديد من قواعد البيانات ، في كل مكان في مكان ما يتغير شيء. كيفية ضمان CI / CD العادي بحيث يكون كل شيء في وضع جيد من موقف DBMS. ما هو النهج الخاص بك؟DS : لا يمكن أن يكون هناك إجابة واحدة. هناك العديد من الخيارات. الأول هو حجم القاعدة التي نريد طرحها. لقد ذكرت أنت بنفسك أن الشركات لها موقف مختلف في الحصول على نسخة من قاعدة الإنتاج في مرحلة التطوير.
NS : وفيما يتعلق بالناتج المحلي الإجمالي ، أعتقد أنهم أكثر فأكثر ... يمكنني القول أنهم في أوروبا بدأوا بالفعل في الغرامة.DS : ولكن يمكنك غالبًا كتابة برامج تفريغ الإنتاج وتعتيمه. اتضح بيانات prod'ovye (لقطة ، تفريغ ، نسخة ثنائية ...) ، لكنها مجهولة. بدلاً من ذلك ، قد يكون هناك نصوص توليد: يمكن أن تكون تركيبات أو مجرد برنامج نصي ينشئ قاعدة بيانات كبيرة. المشكلة هي: كم من الوقت يستغرق إنشاء الصورة الأساسية؟ وكم من الوقت لنشرها على البيئة المناسبة؟
لقد توصلنا إلى المخطط: إذا كان لدى العميل مجموعة بيانات مثبتة (الحد الأدنى من إصدار قاعدة البيانات) ، فإننا نستخدمها افتراضيًا. إذا كنا نتحدث عن بيئات المراجعة ، عندما أنشأنا فرعًا ، قمنا بنشر مثيل تطبيق - سنقوم بنشر قاعدة بيانات صغيرة هناك. لكن
الخيار قد توقف بشكل جيد ، عندما نزيل التفريغ من الإنتاج مرة واحدة يوميًا (ليلًا) ونجمع على أساسه حاوية Docker مع PostgreSQL و MySQL مع هذه البيانات المحملة. إذا كنت بحاجة إلى نشر القاعدة 50 مرة من هذه الصورة ، يتم ذلك بكل بساطة وسرعة.
NS : نسخ بسيط؟DS : يتم تخزين البيانات مباشرة في صورة Docker. أي لدينا صورة جاهزة ، وإن كانت 100 جيجابايت. بفضل الطبقات في Docker ، يمكننا نشر هذه الصورة بسرعة عدة مرات حسب الحاجة. الطريقة غبية ، لكنها تعمل بشكل جيد.
NS : علاوة على ذلك ، عند الاختبار ، يتغير مباشرة داخل Docker ، أليس كذلك؟ نسخ على الكتابة داخل Docker - قم برميها بعيدًا وتذهب مرة أخرى ، كل شيء على ما يرام. الدرجة! وكنت تستخدم بالفعل مع القوة والرئيسية؟DS : لفترة طويلة.
NS : نحن نفعل أشياء مماثلة جدا. نحن فقط لا نستخدم ميزة دوكر على النسخ والكتابة ،شبيبة : إنه ليس عام. و Docker'ny يعمل في كل مكان.
NS : من الناحية النظرية ، نعم. ولكن لدينا أيضًا وحدات نمطية هناك ، يمكنك إنشاء وحدات نمطية مختلفة والعمل مع أنظمة ملفات مختلفة. يا لها من لحظة. من بوستجرس ، ننظر إلى كل هذا بطريقة مختلفة. نظرت الآن من جانب Docker ورأيت أن كل شيء يعمل من أجلك. ولكن إذا كانت قاعدة البيانات ضخمة ، على سبيل المثال ، 1 تيرابايت ، فإن هذا يكون طويلاً: كلتا العمليتين في الليل وتجعل كل شيء في Docker ... وإذا كانت 5 تيرابايت محشوة في Docker ... أم أن كل شيء طبيعي؟DS : ما الفرق الذي يحدثه: إنه النقط ، البتات فقط والبايتات.
NS : الفرق هو هذا: هل تفعل ذلك من خلال تفريغ واستعادة؟DS : ليس من الضروري على الإطلاق. قد تكون طرق إنشاء هذه الصورة مختلفة.
NS : بالنسبة إلى بعض العملاء ، قمنا بعمل ذلك حتى نقوم باستمرار بتحديثه بدلاً من إنشاء صورة أساسية بشكل منتظم. إنها نسخة متماثلة بشكل أساسي ، لكن البيانات لا يتم استلامها مباشرة من الرئيسي ، ولكن من خلال الأرشيف. الأرشيف الثنائي حيث يتم لف WALs كل يوم ، تتم إزالة النسخ الاحتياطية أيضًا هناك ... ثم تنتقل WALs هذه - مع تأخير بسيط (حرفيًا 1-2 ثانية) - إلى الصورة الأساسية. نحن استنساخها بأي شكل من الأشكال - الآن لدينا ZFS افتراضيا.DS : لكن مع ZFS ، تقتصر على عقدة واحدة.
NS : نعم. لكن لدى ZFS أيضًا إرسال سحري: يمكنك إرسال لقطة معه وحتى (لم PGDATA بالفعل ، ولكن ...) يمكنك إرسال دلتا بين اثنين من PGDATA . في الواقع ، لدينا أداة أخرى لم نأخذها بعين الاعتبار بشكل خاص لمثل هذه المهام. يحتوي PostgreSQL على pg_rewind ، والذي يعمل كرسالة مزامنة "ذكية" ، ويتخطى الكثير من الأشياء التي لا يتعين عليك مشاهدتها ، لأنه لم يتغير شيء هناك بالتأكيد. يمكننا القيام بمزامنة سريعة بين الخادمين والإرجاع بنفس الطريقة تمامًا.لذلك ، نحن نحاول في هذا ، أكثر DBA'noy ، أن يصنع أداة تسمح لك بالقيام بنفس الشيء الذي قلته: لدينا قاعدة واحدة ، لكننا نريد اختبار شيء ما 50 مرة ، في نفس الوقت تقريبًا.DS : 50 مرة يعني أنك تحتاج إلى طلب 50 حالة موضعية.
NS : لا ، نحن نفعل كل شيء على جهاز واحد.س : لكن كيف يمكنك نشر 50 مرة إذا كانت هذه القاعدة الواحدة تيرابايت ، على سبيل المثال. على الأرجح أنها تحتاج مشروطة 256 جيجابايت من ذاكرة الوصول العشوائي؟
NS : نعم ، في بعض الأحيان هناك حاجة إلى الكثير من الذاكرة - هذا طبيعي. لكن هذا مثال من الحياة. آلة الإنتاج لديها 96 النوى و 600 جيجابايت. في الوقت نفسه ، يتم استخدام 32 نواة لقاعدة البيانات (حتى 16 نوى تستخدم في بعض الأحيان الآن) و 100-120 غيغابايت من الذاكرة.DS : و 50 نسخة تحصل هناك؟
NS : إذن لا يوجد سوى نسخة واحدة ، ثم تعمل نسخ (ZFS'ny) على الكاتبة ... سأخبرك المزيد.على سبيل المثال ، لدينا قاعدة من 10 تيرابايت. لقد صنعوا قرصًا لذلك ، ما زال ZFS يضغط حجمه المئوي بنسبة 30-40. نظرًا لأننا لا نقوم بإجراء اختبار الحمل ، فإن وقت الاستجابة الدقيق ليس مهمًا بالنسبة لنا: فليكن أبطأ مرتين - وهذا أمر جيد.نقوم بتمكين المبرمجين و QA و DBA وما إلى ذلك. أداء الاختبار في 1-2 المواضيع. على سبيل المثال ، يمكنهم بدء نوع من الهجرة. لا يتطلب الأمر 10 نوى في وقت واحد - يحتاج إلى 1 بوستجرس الخلفية ، 1 الأساسية. سيبدأ الترحيل - ربما لا يزال الفراغ التلقائي يبدأ ، ثم يتم تنشيط اللب الثاني. لقد خصصنا 16-32 النوى ، لذلك 10 أشخاص يمكن أن تعمل في وقت واحد ، لا توجد مشاكل.نظرًا لأن PGDATA فعليًا ، اتضح أننا نخدع Postgres بالفعل. الحيلة هي: تبدأ ، على سبيل المثال ، 10 Postgres في نفس الوقت. ما المشكلة عادة ما ماذا؟ وضعوا المشتركين ، على سبيل المثال ، بنسبة 25 ٪. وفقا لذلك ، وهذا هو 200 غيغابايت. لن تبدأ أكثر من ثلاثة منهم ، لأن الذاكرة ستنتهي.ولكن في مرحلة ما ، أدركنا أن هذا لم يكن ضروريًا: لقد عدلنا Shared_buffers على 2 غيغابايت. يحتوي PostgreSQL على فعالية_التخزين المؤقت ، وهو في الواقع يؤثر فقط على الخطط . وضعناها عند 0.5 تيرابايت. ولا يهم حتى أنهم ليسوا هناك حقًا: فهو يضع خططًا كما لو كانت كذلك.وفقًا لذلك ، عندما نختبر نوعًا من الترحيل ، يمكننا جمع كل الخطط - سنرى كيف سيحدث ذلك في الإنتاج. ستكون الثواني هناك مختلفة (أبطأ) ، لكن البيانات التي نقرأها بالفعل ، والخطط نفسها (أي نوع من JOINs ، إلخ) يتم الحصول عليها تمامًا كما في الإنتاج. وبالتوازي مع ذلك ، يمكنك تشغيل العديد من عمليات الفحص هذه على جهاز واحد.DS : هل تعتقد أن هناك العديد من المشاكل؟ الأول هو الحل الذي يعمل فقط على بوستجرس. هذا النهج خاص جدا ، إنه ليس عام. الثاني - Kubernetes (وهذا هو المكان الذي تسلكه السحابة الآن) ينطوي على الكثير من العقد ، وهذه العقد سريعة الزوال. وفي قضيتك هي عقدة ثابتة ومستقرة. هذه الأشياء تتناقض معي.
NS : أولاً - أوافق ، هذه قصة بوستجرس بحتة. أعتقد أنه إذا كان لدينا أي IO مباشر وتجمع مؤقت لجميع الذاكرة تقريبًا ، فلن ينجح هذا النهج - ستكون هناك خطط مختلفة. لكننا نعمل فقط مع بوستجرس في الوقت الحالي ، لا نفكر في الآخرين.حول Kubernetes. أنت نفسك تقول دائمًا أن لدينا قاعدة ثابتة. إذا تعطل المثيل ، فإن الشيء الرئيسي هو حفظ القرص. هنا لدينا أيضًا النظام الأساسي بأكمله في Kubernetes ، والمكون مع Postgres منفصل (على الرغم من أنه سيكون هناك يومًا ما). لذلك ، كل شيء على هذا النحو: سقط المثيل ، لكننا حفظناه الكهروضوئية وربطنا فقط بنسخة أخرى (جديدة) ، وكأن شيئا لم يحدث.DS : من وجهة نظري ، نقوم بإنشاء قرون في Kubernetes. K8s - مرن: يتم طلب المكونات من تلقاء نفسها حسب الحاجة. وتتمثل المهمة في إنشاء جراب ببساطة والقول إنه يحتاج إلى موارد X ، ومن ثم ستكتشف K8s ذلك. لكن دعم التخزين في Kubernetes لا يزال غير مستقر: في
1.16 ، في
1.17 (تم إصدار هذا الإصدار قبل
أسابيع ) ، أصبحت هذه الميزات تجريبية فقط.
ستستمر ستة أشهر أو سنة - ستصبح مستقرة إلى حد ما ، أو على الأقل ستعلن على هذا النحو. ثم إمكانية لقطات و resize'a بالفعل يحل مشكلتك تماما. لأن لديك قاعدة. نعم ، قد لا يكون سريعًا جدًا ، لكن السرعة تعتمد على ما هو "تحت الغطاء" ، لأن بعض التطبيقات يمكنها النسخ والنسخ على الكتابة على مستوى النظام الفرعي للقرص.
NS : من الضروري أيضًا أن تتمكن جميع المحركات (Amazon ، Google ...) من بدء تشغيل هذا الإصدار - كما يستغرق الأمر بعض الوقت.دي إس : في حين أننا لا نستخدمها. نحن نستخدم لنا.
التنمية المحلية تحت Kubernetes
NS : هل صادفت قائمة أمنياتك هذه عندما تحتاج إلى رفع جميع القرون على جهاز واحد وإجراء مثل هذا الاختبار الصغير. من أجل الحصول على إثبات للمفهوم بسرعة ، راجع أن التطبيق يعمل في Kubernetes ، دون تخصيص مجموعة من الأجهزة لذلك. هل هناك Minikube ، أليس كذلك؟DS : يبدو لي أن هذه الحالة - التي يتم نشرها على عقدة واحدة - تتعلق حصريًا بالتنمية المحلية. أو بعض مظاهر مثل هذا النمط. هناك
Minikube ، هناك
k3s ،
نوع . نحن نستخدم Kubernetes IN Docker. الآن بدأوا العمل معه للاختبارات.
NS : اعتدت أن أعتقد أن هذه محاولة لالتفاف جميع القرون في صورة واحدة Docker. لكن اتضح أن هذا يتعلق بشيء آخر. على أي حال ، هناك حاويات منفصلة ، حاضن منفصلة - فقط في حوض السفن.دي إس : نعم. وهناك تقليد مضحك إلى حد ما ، ولكن النقطة هي ... لدينا أداة نشر -
werf . نرغب في إنشاء وضع فيه - قم
werf up مشروط: "ارفعني Kubernetes محلي". ثم قم بتشغيل
werf follow . بعد ذلك ، سيتمكّن المطور من التحرير في IDE ، وسيتم إطلاق عملية في النظام يرى التغييرات وتجميع الصور ، ويعيد تشكيلها في K8s المحلية. لذلك نحن نريد أن نحاول حل مشكلة التنمية المحلية.
لقطات واستنساخ قاعدة البيانات في حقائق K8s
NS : إذا عدت إلى النسخ على الكتابة. لقد لاحظت أن السحب لها أيضا لقطات. انهم يعملون بشكل مختلف. على سبيل المثال ، في برنامج "شركاء Google المعتمدون": لديك مثيل متعدد تيرابايت على الساحل الشرقي للولايات المتحدة الأمريكية. كنت تفعل لقطات دورية. يمكنك التقاط نسخة قرص على الساحل الغربي من لقطة - في غضون دقائق قليلة ، كل شيء جاهز ، ويعمل بسرعة كبيرة ، فقط ذاكرة التخزين المؤقت يجب ملؤها في الذاكرة. لكن هذه الحيوانات المستنسخة (لقطات) - من أجل "توفير" وحدة تخزين جديدة. هذا شيء عظيم عندما تحتاج إلى إنشاء العديد من الحالات.لكن بالنسبة للاختبارات ، يبدو لي ، لقطات تتحدث عنها في Docker أو أتحدث عنها في ZFS و btrfs وحتى LVM ... - إنها تتيح لك عدم عمل بيانات جديدة حقًا على نفس الجهاز. في السحابة ، لا يزال يتعين عليك دفع ثمنها في كل مرة وانتظر لا دقائق ، ولكن دقائق (وفي حالة الحمل الكسول ، ربما تكون ساعات).بدلاً من ذلك ، يمكنك الحصول على هذه البيانات في الثانية أو الثانية ، وقيادة الاختبار ورميها بعيداً. هذه اللقطات تحل مشاكل مختلفة. في الحالة الأولى - للقياس والحصول على نسخ متماثلة جديدة ، وفي الحالة الثانية - للاختبارات.DS : أنا لا أوافق. تعد وحدات الاستنساخ عادة مهمة السحابة. لم أشاهد تنفيذها ، لكنني أعرف كيف نفعل ذلك على الأجهزة. لدينا Ceph ، حيث يمكنك إخبار أي وحدة تخزين فعلية (
RBD )
بالاستنساخ والحصول على وحدة تخزين ثانية بنفس الخصائص ،
IOPS ، وما إلى ذلك ، بعشرات المللي ثانية. عليك أن تفهم أن هناك نسخة صعبة في الداخل. لماذا لا تفعل السحابة نفس الشيء؟ أنا متأكد من أنهم يحاولون القيام بذلك بطريقة أو بأخرى.
NS : لكنهم سيستغرقون ثوانٍ ، عشرات الثواني لرفع المثيل ، إحضار Docker هناك ، إلخ.DS : لماذا من الضروري رفع مثيل كامل؟ ولكن لدينا مثيل لـ 32 مركزًا ، و 16 عامًا ، وهو مناسب تمامًا - على سبيل المثال ، أربعة. عندما نطلب الخامس ، فإن المثال سوف يرتفع ، ثم سيتم حذفه.
NS : نعم ، من المثير للاهتمام أن لدى Kubernetes قصة مختلفة. قاعدة بياناتنا ليست في K8s ، ومثال واحد. لكن استنساخ قاعدة بيانات متعددة تيرابايت لا يستغرق أكثر من ثانيتين.DS : هذا رائع. لكن رسالتي الأولية هي أن هذا ليس حلاً عامًا. نعم ، إنه رائع ، لكن Postgres فقط هو المناسب وفقط على عقدة واحدة.
NS : إنه مناسب ليس فقط لـ Postgres: هذه الخطط ، كما وصفتها ، ستعمل بهذه الطريقة فقط. ولكن إذا كنت لا تهتم بالخطط ، لكننا نحتاج فقط إلى جميع البيانات للاختبار الوظيفي ، فهذا مناسب لأي من قواعد البيانات.DS : منذ سنوات عديدة فعلنا هذا على لقطات LVM. هذا كلاسيكي. وقد استخدم هذا النهج بنشاط كبير. العقد الحكيمة هي مجرد ألم. لأنهم لا يحتاجون إلى إسقاط ، تذكر دائمًا عنهم ...
NS : هل ترى أي إمكانية مختلطة هنا؟ دعنا نقول حالة الدولة هي نوع من جراب ، وأنها تعمل لعدة أشخاص (العديد من اختبار). لدينا وحدة تخزين واحدة ، ولكن بفضل نظام الملفات ، تكون النسخ محلية. إذا سقط القرص ، يبقى القرص - يرتفع القرص ، فهو يأخذ في الاعتبار المعلومات حول جميع الحيوانات المستنسخة ، ويعيد كل شيء إلى الوراء ويقول: "ها هي الحيوانات المستنسخة الخاصة بك على هذه المنافذ ، ابدأ العمل معها أكثر".DS : من الناحية الفنية ، هذا يعني أنه داخل Kubernetes ، هذا هو جراب واحد ، وفيه ندير العديد من Postgres.
NS : نعم. لديه حد: افترض ، في الوقت نفسه ، أن أكثر من 10 أشخاص يعملون معه. إذا كنت بحاجة إلى 20 - تشغيل الثانية من هذا القبيل. استنساخه بشكل واقعي تمامًا ، بعد استلام المجلد الكامل الثاني ، سيكون لديه نفس المستنسخة "الرقيقة" العشرة. لا ترى مثل هذه الفرصة؟DS : علينا إضافة مشاكل الأمان هنا. يشير مثل هذا الخيار التنظيمي إلى أن هذا الجهاز يتمتع بقدرات عالية لأنه يمكن أن يؤدي عمليات غير قياسية على نظام الملفات ... ولكني أكرر: أعتقد أنه في المدى المتوسط ، سيتم إصلاح التخزين في Kubernetes ، وسيتم تثبيت القصة الكاملة مع وحدات التخزين في السحب. - كل شيء سيكون "مجرد عمل". سوف يتم تغيير حجمها واستنساخها ... يوجد مجلد - نقول: "أنشئ وحدة جديدة على أساس ذلك" - وبعد ثانية ونصف حصلنا على ما نحتاج إليه.
NS : لا أؤمن بواحدة ونصف ثانية للعديد من تيرابايت. في Ceph ، تقوم بذلك بنفسك ، وتتحدث عن السحب. انتقل إلى السحابة ، على EC2 ، واستنسخ من حجم EBS للعديد من تيرابايت ومعرفة ما سيكون الأداء. لا يستغرق بضع ثوان. أنا مهتم جدًا عندما يصلون إلى هذا المؤشر. أفهم ما الذي تتحدث عنه ، لكن اسمحوا لي أن أختلف.سؤال : حسناً ، لكنني قلت ذلك على المدى المتوسط ، وليس على المدى القصير. لعدة سنوات.
مشغل برو ل PostgreSQL من زالاندو
في منتصف هذا الاجتماع ، انضم إليها أليكسي كليوكين ، المطور السابق من زالاندو ، الذي تحدث عن تاريخ مشغل بوستجرس ،:
من الرائع أن يتم التطرق إلى هذا الموضوع بشكل عام: كلاً من Postgres و Kubernetes. عندما بدأنا القيام بذلك في زالاندو في عام 2017 ، كان موضوعًا يريد الجميع القيام به ، لكن لم يفعله أحد. كان لدى الجميع بالفعل Kubernetes ، لكن عندما سئلوا عن ماذا يفعلون بقواعد البيانات ، حتى بعض الأشخاص مثل Kelsey Hightower الذين بشروا K8s قالوا شيئًا كهذا:
"انتقل إلى الخدمات المدارة واستخدمها ؛ لا تقم بتشغيل قاعدة البيانات في Kubernetes. وإلا ، فستقرر K8s لديك ، على سبيل المثال ، الترقية وإخماد جميع العقد ، وستطير بياناتك بعيدًا. "
قررنا إنشاء مشغل يقوم ، على عكس هذه النصيحة ، بإطلاق قاعدة بيانات Postgres في Kubernetes. وكان لدينا أساس جيد - Patroni . هذا هو الفشل التلقائي ل PostgreSQL ، ويتم بشكل صحيح ، أي باستخدام etcd أو القنصل أو ZooKeeper كمستودع لمعلومات نظام المجموعة. مثل هذا المستودع الذي سيتم تقديمه لكل من يسأل ، على سبيل المثال ، ما نوع القائد الآن ، نفس المعلومات - على الرغم من حقيقة أن لدينا كل شيء موزع - بحيث لا يوجد دماغ منقسم. بالاضافة الى ذلك ، كان لدينا صورة عامل الميناء بالنسبة له.
بشكل عام ، ظهرت الحاجة إلى تجاوز الفشل التلقائي في الشركة بعد الترحيل من مركز بيانات الحديد الداخلي إلى السحابة. اعتمدت السحابة على حل الملكية (PaaS (Platform-as-a-service)). إنه مفتوح المصدر ، ولكن لرفعه ، كان عليك العمل بجد. كان يطلق عليه STUPS .
في البداية ، لم يكن هناك Kubernetes. بتعبير أدق ، عندما تم نشر حلها الخاص ، كانت K8s بالفعل ، لكنها كانت خامًا لدرجة أنها لم تكن مناسبة للإنتاج. كان ، في رأيي ، 2015 أو 2016. بحلول عام 2017 ، أصبحت Kubernetes ناضجة إلى حد ما - كانت هناك حاجة للهجرة إلى هناك.
وكان لدينا بالفعل حاوية عامل ميناء. كان هناك PaaS التي تستخدم عامل الميناء. لماذا لا تجرب K8s؟ لماذا لا تكتب بيانك الخاص؟ بدأ مراد كابلوف ، الذي أتى إلينا من أفيتو ، هذا كمشروع بمبادرة منه - "مسرحية" - والمشروع "انطلق".
ولكن بشكل عام ، أردت أن أتحدث عن AWS. لماذا كان هناك تاريخيا رمز ذات الصلة AWS ...
عندما تقوم بتشغيل شيء ما في Kubernetes ، يجب أن تفهم أن K8s هو مثل هذا العمل قيد التقدم. انها تتطور باستمرار ، وتحسين وبشكل دوري حتى كسر. تحتاج إلى مراقبة جميع التغييرات في Kubernetes بعناية ، ويجب أن تكون مستعدًا لتغمر فيها ، ومعرفة كيفية عملها بالتفصيل - ربما أكثر مما تريد. هذا ، من حيث المبدأ ، أي منصة تقوم بتشغيل قواعد البيانات الخاصة بك ...
لذلك ، عندما قمنا بالبيان ، كان لدينا Postgres ، والتي عملت مع وحدة تخزين خارجية (في هذه الحالة ، EBS ، لأننا عملنا في AWS). قاعدة البيانات كانت تنمو ، في مرحلة ما كان من الضروري تغيير حجمها: على سبيل المثال ، الحجم الأصلي ل EBS هو 100 تيرابايت ، نمت قاعدة البيانات إليها ، والآن نريد أن نجعل EBS في 200 تيرابايت. كيف؟ لنفترض أنه يمكنك تفريغ / استعادة إلى مثيل جديد ، ولكن هذا طويل مع توقف.
لذلك ، أردت تغيير حجم من شأنه أن يوسع قسم EBS ثم أخبر نظام الملفات باستخدام المساحة الجديدة. لقد فعلنا ذلك ، ولكن في ذلك الوقت لم يكن لدى Kubernet أي واجهة برمجة التطبيقات لعملية تغيير الحجم. منذ أن عملنا على AWS ، كتبنا رمزًا لواجهة برمجة التطبيقات.
لا أحد يزعج أن يفعل الشيء نفسه بالنسبة للمنصات الأخرى. لا يوجد أي تعقيد في البيان بأنه يمكن تشغيله فقط على AWS ، ولن يعمل على أي شيء آخر. بشكل عام ، هذا مشروع مفتوح المصدر: إذا أراد أي شخص تسريع ظهور استخدام واجهة برمجة التطبيقات الجديدة ، فنحن نرحب بك. هناك GitHub ، طلبات السحب - فريق Zalando يحاول الاستجابة بسرعة لهم وتعزيز المشغل. على حد علمي ، شارك المشروع في Google Summer of Code وبعض المبادرات المماثلة الأخرى. Zalando نشط جدا في ذلك.
PS مكافأة!
إذا كنت مهتمًا بموضوع PostgreSQL و Kubernetes ، فإننا نلفت الانتباه أيضًا إلى حقيقة أن Postgres الأسبوع الماضي قد حدث ، حيث تحدث
ألكساندر كوكوشكين من زالاندو مع نيكولاي. الفيديو منه متاح
هنا .
PPS
اقرأ أيضًا في مدونتنا: