في نهاية العام الماضي، حدث بث مباشر آخر لمجتمع PostgreSQL الروسي ، حيث تحدث المؤسس المشارك نيكولاي ساموخفالوف مع المدير الفني لشركة فلانت ديمتري ستولياروف حول نظام إدارة قواعد البيانات هذا في سياق Kubernetes.
نحن ننشر نسخة من الجزء الرئيسي من هذه المناقشة، وفي تم نشر الفيديو كاملا:
قواعد البيانات و Kubernetes
NA: لن نتحدث اليوم عن الفراغ ونقاط التفتيش. نريد أن نتحدث عن Kubernetes. أعلم أن لديك سنوات عديدة من الخبرة. لقد شاهدت مقاطع الفيديو الخاصة بك وأعدت مشاهدة بعضها... دعنا ننتقل مباشرة إلى النقطة: لماذا Postgres أو MySQL في K8s على الإطلاق؟
س: لا يوجد ولا يمكن أن يكون هناك إجابة محددة لهذا السؤال. ولكن بشكل عام، هذه هي البساطة والراحة... الإمكانات. الجميع يريد الخدمات المدارة.
NA: كيفية ، فقط في المنزل؟
س: نعم: مثل RDS، في أي مكان.
NA: "في أي مكان" هي نقطة جيدة. في الشركات الكبيرة، كل شيء يقع في أماكن مختلفة. لماذا إذن، إذا كانت شركة كبيرة، لا تأخذ حلاً جاهزًا؟ على سبيل المثال، لدى Nutanix تطوراتها الخاصة، والشركات الأخرى (VMware...) لديها نفس "RDS، فقط في المنزل".
س: لكننا نتحدث عن تطبيق منفصل لن يعمل إلا في ظل ظروف معينة. وإذا كنا نتحدث عن Kubernetes، فهناك مجموعة كبيرة ومتنوعة من البنية التحتية (والتي يمكن أن تكون في K8s). يعد هذا في الأساس معيارًا لواجهات برمجة التطبيقات (APIs) في السحابة...
NA: إنه مجاني أيضًا!
س: ليس من المهم جدا. الحرية مهمة بالنسبة لشريحة كبيرة جدًا من السوق. هناك شيء آخر مهم... ربما تتذكر التقرير ""؟
NA: نعم.
س: أدركت أنه تم استلامه بشكل غامض للغاية. اعتقد بعض الناس أنني كنت أقول: "يا رفاق، دعونا نضع جميع قواعد البيانات في Kubernetes!"، بينما قرر آخرون أن هذه كلها كانت دراجات فظيعة. لكنني أردت أن أقول شيئًا مختلفًا تمامًا: "انظروا إلى ما يحدث، وما هي المشاكل الموجودة وكيف يمكن حلها. هل يجب أن نستخدم قواعد بيانات Kubernetes الآن؟ إنتاج؟ حسنًا، فقط إذا كنت ترغب في القيام بأشياء معينة. ولكن بالنسبة للمطورين، أستطيع أن أقول أنني أوصي به. بالنسبة للمطورين، تعد ديناميكية إنشاء/حذف البيئات أمرًا مهمًا للغاية.
NS: هل تقصد بكلمة dev جميع البيئات التي لا يتم إنتاجها؟ التدريج، ضمان الجودة…
س: إذا كنا نتحدث عن منصات الأداء، فربما لا، لأن المتطلبات هناك محددة. إذا كنا نتحدث عن حالات خاصة حيث تكون هناك حاجة إلى قاعدة بيانات كبيرة جدًا للتدريج، فربما لا... إذا كانت هذه بيئة ثابتة وطويلة العمر، فما فائدة وجود قاعدة البيانات في K8s؟
NA: لا أحد. ولكن أين نرى البيئات الثابتة؟ سوف تصبح البيئة الثابتة عفا عليها الزمن غدا.
س: التدريج يمكن أن يكون ثابتا. لدينا عملاء...
NA: نعم، لدي واحدة أيضا. إنها مشكلة كبيرة إذا كان لديك قاعدة بيانات بسعة 10 تيرابايت و200 جيجابايت للتدريج...
س: لدي حالة رائعة جدا! عند التدريج، توجد قاعدة بيانات للمنتج يتم إجراء التغييرات عليها. وهناك زر: "الطرح للإنتاج". تتم إضافة هذه التغييرات - الدلتا - (يبدو أنها تتم مزامنتها ببساطة عبر واجهة برمجة التطبيقات) في الإنتاج. هذا خيار غريب للغاية.
NA: لقد رأيت شركات ناشئة في Valley موجودة في RDS أو حتى في Heroku - هذه قصص منذ 2-3 سنوات مضت - ويقومون بتنزيل ملف التفريغ على أجهزة الكمبيوتر المحمول الخاصة بهم. لأن قاعدة البيانات لا تزال 80 جيجابايت فقط، وهناك مساحة على الكمبيوتر المحمول. ثم يقومون بشراء أقراص إضافية للجميع بحيث يكون لديهم 3 قواعد بيانات لتنفيذ التطويرات المختلفة. هذه هي الطريقة التي يحدث بها الأمر أيضًا. ورأيت أيضًا أنهم لا يخشون نسخ الحث على العرض المسرحي - فالأمر يعتمد كثيرًا على الشركة. لكنني رأيت أيضًا أنهم خائفون جدًا، وأنهم في كثير من الأحيان ليس لديهم ما يكفي من الوقت والأيدي. ولكن قبل أن ننتقل إلى هذا الموضوع، أريد أن أسمع عن Kubernetes. هل أفهم بشكل صحيح أنه لا يوجد أحد في الإنتاج حتى الآن؟
س: لدينا قواعد بيانات صغيرة في همز. نحن نتحدث عن أحجام تصل إلى عشرات الجيجابايت وخدمات غير مهمة كنا كسالى جدًا بحيث لا يمكننا عمل نسخ متماثلة لها (وليس هناك مثل هذه الحاجة). وبشرط أن يكون هناك تخزين عادي ضمن Kubernetes. عملت قاعدة البيانات هذه في جهاز افتراضي - بشكل مشروط في برنامج VMware، أعلى نظام التخزين. لقد وضعناها فيه والآن يمكننا نقله من آلة إلى أخرى.
NA: قواعد بيانات بهذا الحجم، تصل إلى 100 جيجابايت، يمكن نشرها في بضع دقائق على أقراص جيدة وشبكة جيدة، أليس كذلك؟ لم تعد سرعة 1 جيجابايت في الثانية غريبة.
س: نعم، بالنسبة للتشغيل الخطي، فهذه ليست مشكلة.
NA: حسنا، علينا فقط أن نفكر في همز. وإذا كنا نفكر في استخدام Kubernetes في بيئات غير إنتاجية، فماذا علينا أن نفعل؟ أرى ذلك في زالاندو ، في كرانشي ، هناك بعض الخيارات الأخرى. وهناك - هذا هو صديقنا العزيز ألفارو من إسبانيا: ما يفعلونه ليس عادلاً في الأساس والتوزيع كله ()، والتي، بالإضافة إلى Postgres نفسها، قرروا أيضًا حشو نسخة احتياطية، وكيل المبعوث...
س: مبعوث ماذا؟ موازنة حركة مرور Postgres على وجه التحديد؟
NA: نعم. أي أنهم يرون الأمر على النحو التالي: إذا كنت تستخدم توزيعة Linux ونواة، فإن PostgreSQL العادي هو النواة، ويريدون إنشاء توزيعة تكون صديقة للسحابة وتعمل على Kubernetes. يقومون بتجميع المكونات (النسخ الاحتياطية، وما إلى ذلك) وتصحيحها بحيث تعمل بشكل جيد.
س: رائع جدا! هذا هو في الأساس برنامج لإنشاء Postgres المُدار الخاص بك.
NA: تعاني توزيعات Linux من مشاكل أبدية: كيفية إنشاء برامج تشغيل بحيث يتم دعم جميع الأجهزة. ولديهم فكرة أنهم سيعملون في Kubernetes. أعلم أننا رأينا مؤخرًا اتصالاً بـ AWS في مشغل Zalando ولم يعد هذا جيدًا جدًا. لا ينبغي أن يكون هناك ارتباط ببنية تحتية محددة، فما الفائدة إذن؟
س: لا أعرف بالضبط ما هو الموقف الذي وصل إليه زالاندو، ولكن في Kubernetes يتم إنشاء التخزين الآن بطريقة تجعل من المستحيل أخذ نسخة احتياطية على القرص باستخدام طريقة عامة. مؤخرًا بشكل قياسي - في أحدث إصدار - لقد جعلنا اللقطات ممكنة، ولكن أين يتم تنفيذها؟ بصراحة، كل شيء لا يزال خامًا للغاية... نحن نحاول استخدام CSI بالإضافة إلى AWS وGCE وAzure وvSphere، ولكن بمجرد البدء في استخدامه، يمكنك أن ترى أنه ليس جاهزًا بعد.
NA: لهذا السبب يتعين علينا أحيانًا الاعتماد على البنية التحتية. أعتقد أن هذه لا تزال مرحلة مبكرة - آلام النمو. سؤال: ما النصيحة التي تقدمها للمبتدئين الذين يرغبون في تجربة PgSQL في K8s؟ ما المشغل ربما؟
س: المشكلة هي أن Postgres يمثل 3% بالنسبة لنا. لدينا أيضًا قائمة كبيرة جدًا من البرامج المختلفة في Kubernetes، ولن أذكر كل شيء حتى. على سبيل المثال، Elasticsearch. هناك الكثير من المشغلين: بعضهم يتطور بنشاط، والبعض الآخر ليس كذلك. لقد وضعنا لأنفسنا متطلبات حول ما يجب أن يكون لدى المشغل حتى نتمكن من أخذ الأمر على محمل الجد. في مشغل مخصص لـ Kubernetes - وليس في "مشغل للقيام بشيء ما في ظروف Amazon"... في الواقع، نحن على نطاق واسع جدًا (= جميع العملاء تقريبًا) نستخدم مشغلًا واحدًا - (سننشر عنه مقالا قريبا).
NA: وليس لـ MySQL أيضًا؟ أعلم أن بيركونا... بما أنهم يعملون الآن على MySQL وMongoDB وPostgres، سيتعين عليهم إنشاء نوع من الحلول الشاملة: لجميع قواعد البيانات، ولجميع موفري الخدمات السحابية.
س: لم يكن لدينا الوقت لإلقاء نظرة على مشغلي MySQL. هذا ليس تركيزنا الرئيسي في الوقت الحالي. يعمل MySQL بشكل جيد بشكل مستقل. لماذا تستخدم عامل تشغيل إذا كان بإمكانك فقط تشغيل قاعدة بيانات... يمكنك تشغيل حاوية Docker باستخدام Postrges، أو يمكنك تشغيلها بطريقة بسيطة.
NA: كان هناك سؤال حول هذا أيضا. لا يوجد مشغل على الإطلاق؟
س: نعم، 100% منا لديه PostgreSQL يعمل بدون مشغل. الى حد بعيد. نحن نستخدم بشكل نشط عامل التشغيل لـ Prometheus وRedis. لدينا خطط للعثور على مشغل Elasticsearch - وهو المشغل الأكثر "اشتعالًا"، لأننا نريد تثبيته في Kubernetes في 100% من الحالات. تمامًا كما نريد التأكد من تثبيت MongoDB دائمًا في Kubernetes. هنا تظهر بعض الرغبات - هناك شعور بأنه في هذه الحالات يمكن فعل شيء ما. ولم ننظر حتى إلى Postgres. بالطبع، نحن نعلم أن هناك خيارات مختلفة، ولكن في الواقع لدينا قائمة بذاتها.
قاعدة بيانات للاختبار في Kubernetes
NA: دعنا ننتقل إلى موضوع الاختبار. كيفية طرح التغييرات على قاعدة البيانات - من منظور DevOps. هناك خدمات صغيرة، والعديد من قواعد البيانات، هناك شيء يتغير في مكان ما طوال الوقت. كيفية التأكد من أن CI/CD طبيعي بحيث يكون كل شيء على ما يرام من منظور نظام إدارة قواعد البيانات (DBMS). ما هو النهج الخاص بك؟
س: لا يمكن أن يكون هناك إجابة واحدة. هناك عدة خيارات. الأول هو حجم القاعدة التي نريد طرحها. لقد ذكرت بنفسك أن الشركات لديها مواقف مختلفة تجاه الحصول على نسخة من قاعدة بيانات المنتج على مستوى التطوير والمسرح.
NA: وفي ظل شروط اللائحة العامة لحماية البيانات، أعتقد أنهم أصبحوا أكثر حذرًا... أستطيع أن أقول إنهم في أوروبا بدأوا بالفعل في فرض الغرامات.
س: لكن في كثير من الأحيان يمكنك كتابة برنامج يتخلص من الإنتاج ويحجبه. يتم الحصول على بيانات الإنتاج (لقطة، تفريغ، نسخة ثنائية...)، ولكنها تكون مجهولة المصدر. بدلاً من ذلك، يمكن أن يكون هناك برامج نصية للإنشاء: يمكن أن تكون هذه برامج نصية ثابتة أو مجرد برنامج نصي يقوم بإنشاء قاعدة بيانات كبيرة. المشكلة هي: كم من الوقت يستغرق إنشاء الصورة الأساسية؟ وكم من الوقت يستغرق نشره في البيئة المطلوبة؟
لقد توصلنا إلى مخطط: إذا كان لدى العميل مجموعة بيانات ثابتة (الحد الأدنى من إصدار قاعدة البيانات)، فإننا نستخدمها افتراضيًا. إذا كنا نتحدث عن بيئات المراجعة، فعندما أنشأنا فرعًا، قمنا بنشر مثيل التطبيق - وقمنا بنشر قاعدة بيانات صغيرة هناك. ولكن اتضح جيدا ، عندما نأخذ تفريغًا من الإنتاج مرة واحدة يوميًا (ليلاً) ونبني حاوية Docker باستخدام PostgreSQL وMySQL مع هذه البيانات المحملة بناءً عليها. إذا كنت بحاجة إلى توسيع قاعدة البيانات 50 مرة من هذه الصورة، فسيتم ذلك بكل بساطة وبسرعة.
NA: عن طريق النسخ البسيط؟
س: يتم تخزين البيانات مباشرة في صورة Docker. أولئك. لدينا صورة جاهزة، وإن كانت 100 جيجابايت. بفضل الطبقات الموجودة في Docker، يمكننا نشر هذه الصورة بسرعة بقدر ما نحتاج. الطريقة غبية لكنها تعمل بشكل جيد.
NA: بعد ذلك، عند الاختبار، يتغير مباشرة داخل Docker، أليس كذلك؟ النسخ عند الكتابة داخل Docker - تخلص منه وانطلق مرة أخرى، كل شيء على ما يرام. فصل! وهل تستخدمه بالفعل على أكمل وجه؟
س: لفترة طويلة.
NA: نحن نفعل أشياء مماثلة جدا. نحن فقط لا نستخدم نسخة Docker عند الكتابة، بل نستخدم طريقة أخرى.
س: انها ليست عامة. ويعمل Docker في كل مكان.
NA: من الناحية النظرية، نعم. ولكن لدينا أيضًا وحدات هناك، حيث يمكنك إنشاء وحدات مختلفة والعمل مع أنظمة ملفات مختلفة. يا لها من لحظة هنا. من جانب Postgres، نحن ننظر إلى كل هذا بشكل مختلف. لقد نظرت الآن من جانب Docker ورأيت أن كل شيء يناسبك. ولكن إذا كانت قاعدة البيانات ضخمة، على سبيل المثال، 1 تيرابايت، فكل هذا يستغرق وقتًا طويلاً: العمليات في الليل، وملء كل شيء في Docker... وإذا تم حشو 5 تيرابايت في Docker... أم أن كل شيء على ما يرام؟
س: ما الفرق: هذه النقط، مجرد بت وبايت.
NA: الفرق هو هذا: هل تفعل ذلك من خلال التفريغ والاستعادة؟
س: ليس ضروريا على الإطلاق. يمكن أن تكون طرق إنشاء هذه الصورة مختلفة.
NA: بالنسبة لبعض العملاء، قمنا بذلك بحيث نقوم بتحديثها باستمرار بدلاً من إنشاء صورة أساسية بشكل منتظم. إنها في الأساس نسخة طبق الأصل، ولكنها تتلقى البيانات ليس من السيد مباشرة، ولكن من خلال الأرشيف. أرشيف ثنائي حيث يتم تنزيل شبكات WAL كل يوم، حيث يتم أخذ النسخ الاحتياطية... تصل شبكات WAL هذه بعد ذلك إلى الصورة الأساسية مع تأخير بسيط (حرفيًا 1-2 ثانية). نحن نستنسخه بأي شكل من الأشكال - الآن لدينا ZFS افتراضيًا.
س: ولكن مع ZFS فأنت مقيد بعقدة واحدة.
NA: نعم. ولكن لدى ZFS أيضًا سحرًا : بواسطتها يمكنك إرسال لقطة وحتى (لم أختبر هذا بالفعل بعد، ولكن...) يمكنك إرسال دلتا بين اثنين PGDATA. في الواقع، لدينا أداة أخرى لم نفكر فيها حقًا لمثل هذه المهام. يحتوي PostgreSQL على ، الذي يعمل مثل rsync "الذكي"، ويتخطى الكثير مما لا يتعين عليك مشاهدته، لأنه لم يتغير شيء هناك. يمكننا إجراء مزامنة سريعة بين الخادمين والترجيع بنفس الطريقة.
لذلك، من هذا الجانب المتعلق بإدارة قواعد البيانات، نحاول إنشاء أداة تتيح لنا القيام بنفس الشيء الذي قلته: لدينا قاعدة بيانات واحدة، ولكننا نريد اختبار شيء ما 50 مرة، في وقت واحد تقريبًا.
س: 50 مرة يعني أنك بحاجة إلى طلب 50 مثيلًا لـ Spot.
NA: لا، نحن نفعل كل شيء على جهاز واحد.
س: ولكن كيف يمكنك التوسع 50 مرة إذا كانت قاعدة البيانات هذه، على سبيل المثال، تيرابايت. على الأرجح أنها تحتاج إلى 256 جيجابايت من ذاكرة الوصول العشوائي المشروطة؟
NA: نعم، في بعض الأحيان تحتاج إلى الكثير من الذاكرة - وهذا طبيعي. لكن هذا مثال من الحياة. تحتوي آلة الإنتاج على 96 نواة و 600 جيجابايت. في الوقت نفسه، يتم استخدام 32 مركزًا (حتى 16 مركزًا في بعض الأحيان) و100-120 جيجابايت من الذاكرة لقاعدة البيانات.
س: و50 نسخة تناسب هناك؟
NA: إذن هناك نسخة واحدة فقط، ثم تعمل خاصية النسخ عند الكتابة (ZFS)... سأخبرك بمزيد من التفاصيل.
على سبيل المثال، لدينا قاعدة بيانات بسعة 10 تيرابايت. لقد صنعوا قرصًا له، كما قامت ZFS أيضًا بضغط حجمه بنسبة 30-40 بالمائة. نظرًا لأننا لا نجري اختبار التحميل، فإن وقت الاستجابة الدقيق ليس مهمًا بالنسبة لنا: فليكن أبطأ بما يصل إلى مرتين - فلا بأس.
نحن نعطي الفرصة للمبرمجين، ضمان الجودة، ديسيبل، الخ. إجراء الاختبار في 1-2 المواضيع. على سبيل المثال، قد يقومون بإجراء نوع من الهجرة. لا يتطلب 10 مراكز في وقت واحد - فهو يحتاج إلى واجهة Postgres خلفية واحدة ونواة واحدة. ستبدأ الهجرة - ربما سيظل يبدأ، ثم سيتم استخدام النواة الثانية. لدينا 16-32 مركزًا مخصصًا، لذلك يمكن لـ 10 أشخاص العمل في نفس الوقت، دون أي مشكلة.
لأنه جسديا PGDATA نفس الشيء، اتضح أننا في الواقع نخدع Postgres. الحيلة هي كما يلي: على سبيل المثال، يتم إطلاق 10 Postgres في وقت واحد. ما هي المشكلة عادة؟ وضعوا ، دعنا نقول 25٪. وفقا لذلك، هذا هو 200 جيجابايت. لن تتمكن من تشغيل أكثر من ثلاثة منها، لأن الذاكرة ستنفد.
ولكن في مرحلة ما أدركنا أن هذا لم يكن ضروريًا: لقد قمنا بتعيين Shared_buffers على 2 جيجابايت. يحتوي PostgreSQL على ، وفي الحقيقة هو الوحيد الذي يؤثر . قمنا بتعيينه على 0,5 تيرابايت. ولا يهم حتى أنها غير موجودة بالفعل: فهو يضع الخطط كما لو كانت موجودة.
وفقا لذلك، عندما نختبر نوعا ما من الترحيل، يمكننا جمع كل الخطط - سنرى كيف سيحدث ذلك في الإنتاج. ستكون الثواني هناك مختلفة (أبطأ)، ولكن البيانات التي نقرأها بالفعل، والخطط نفسها (ما هي الروابط الموجودة هناك، وما إلى ذلك) ستكون هي نفسها تمامًا كما في الإنتاج. ويمكنك إجراء العديد من هذه الفحوصات بالتوازي على جهاز واحد.
س: ألا تعتقد أن هناك بعض المشاكل هنا؟ الأول هو الحل الذي يعمل فقط على PostgreSQL. هذا النهج خاص جدًا، وليس عامًا. والثاني هو أن Kubernetes (وكل ما ستفعله التقنيات السحابية الآن) يتضمن العديد من العقد، وهذه العقد سريعة الزوال. وفي حالتك فهي عقدة ثابتة ومستمرة. هذه الأشياء تجعلني متضاربة.
NA: أولاً، أوافق على أن هذه قصة بوستجرس بحتة. أعتقد أنه إذا كان لدينا نوع من عمليات الإدخال والإخراج المباشرة وتجمع مؤقت لكل الذاكرة تقريبًا، فلن ينجح هذا النهج - ستكون الخطط مختلفة. لكن في الوقت الحالي نحن نعمل فقط مع Postgres، ولا نفكر في الآخرين.
حول كوبرنيتيس. أنت بنفسك تخبرنا في كل مكان أن لدينا قاعدة بيانات ثابتة. إذا فشل المثيل، فإن الشيء الرئيسي هو حفظ القرص. لدينا هنا أيضًا النظام الأساسي بأكمله في Kubernetes، والمكون مع Postgres منفصل (على الرغم من أنه سيكون موجودًا يومًا ما). لذلك، كل شيء على هذا النحو: سقطت النسخة، لكننا حفظنا PV الخاص بها وقمنا ببساطة بتوصيلها بمثيل آخر (جديد)، وكأن شيئًا لم يحدث.
س: من وجهة نظري، نقوم بإنشاء البودات في Kubernetes. K8s - مرن: يتم ترتيب العقد حسب الحاجة. تتمثل المهمة ببساطة في إنشاء حجرة والقول إنها تحتاج إلى كمية X من الموارد، وبعد ذلك ستكتشف K8s ذلك من تلقاء نفسها. لكن دعم التخزين في Kubernetes لا يزال غير مستقر: في (تم إصدار هذا الإصدار الأسبوع مضت) أصبحت هذه الميزات تجريبية فقط.
سوف تمر ستة أشهر إلى سنة - سوف تصبح أكثر أو أقل استقرارا، أو على الأقل سيتم الإعلان عنها على هذا النحو. إذن فإن إمكانية التقاط اللقطات وتغيير حجمها تحل مشكلتك تماما. لأن لديك قاعدة. نعم، قد لا يكون سريعًا جدًا، لكن السرعة تعتمد على ما هو "تحت الغطاء"، لأن بعض التطبيقات يمكنها النسخ والنسخ عند الكتابة على مستوى النظام الفرعي للقرص.
NA: من الضروري أيضًا أن تبدأ جميع المحركات (Amazon، Google...) في دعم هذا الإصدار - وهذا يستغرق أيضًا بعض الوقت.
س: نحن لا نستخدمها بعد. نحن نستخدم لنا.
التنمية المحلية لKubernetes
NA: هل واجهت مثل هذه الرغبة عندما تحتاج إلى تثبيت جميع القرون على جهاز واحد وإجراء مثل هذا الاختبار الصغير. للحصول على إثبات سريع للمفهوم، تأكد من أن التطبيق يعمل في Kubernetes، دون تخصيص مجموعة من الأجهزة له. هناك Minikube، أليس كذلك؟
س: يبدو لي أن هذه الحالة - المنتشرة على عقدة واحدة - تتعلق حصريًا بالتنمية المحلية. أو بعض مظاهر مثل هذا النمط. يأكل هناك , . نحن نتجه نحو استخدام Kubernetes IN Docker. الآن بدأنا العمل معه لإجراء الاختبارات.
NA: كنت أعتقد أن هذه كانت محاولة لتجميع جميع القرون في صورة Docker واحدة. لكن اتضح أن الأمر يتعلق بشيء مختلف تمامًا. على أي حال، هناك حاويات منفصلة وكبسولات منفصلة - فقط في Docker.
س: نعم. وهناك تقليد مضحك إلى حد ما، ولكن المعنى هو هذا... لدينا أداة للنشر - . نريد أن نجعله وضعًا مشروطًا werf up: "احصل لي على Kubernetes المحلية." ثم قم بتشغيل الشرطية هناك werf follow. بعد ذلك، سيتمكن المطور من تحرير IDE، وسيتم إطلاق عملية في النظام ترى التغييرات وتعيد بناء الصور، وإعادة نشرها إلى K8s المحلية. هذه هي الطريقة التي نريد أن نحاول بها حل مشكلة التنمية المحلية.
اللقطات واستنساخ قاعدة البيانات في واقع K8s
NA: إذا عدنا إلى النسخ عند الكتابة. لقد لاحظت أن السحب تحتوي أيضًا على لقطات. إنهم يعملون بشكل مختلف. على سبيل المثال، في Google Cloud Platform: لديك مثيل متعدد التيرابايت على الساحل الشرقي للولايات المتحدة. يمكنك التقاط لقطات بشكل دوري. يمكنك التقاط نسخة من القرص على الساحل الغربي من لقطة - في بضع دقائق، كل شيء جاهز، ويعمل بسرعة كبيرة، فقط ذاكرة التخزين المؤقت تحتاج إلى ملء الذاكرة. لكن هذه النسخ (اللقطات) تهدف إلى "توفير" مجلد جديد. يعد هذا أمرًا رائعًا عندما تحتاج إلى إنشاء الكثير من الحالات.
لكن بالنسبة للاختبارات، يبدو لي أن اللقطات التي تتحدث عنها في Docker أو التي أتحدث عنها في ZFS وbtrfs وحتى LVM... - تسمح لك بعدم إنشاء بيانات جديدة حقًا على جهاز واحد. في السحابة، ستظل تدفع ثمنها في كل مرة ولا تنتظر ثواني، بل دقائق (وفي هذه الحالة وربما ساعة).
وبدلاً من ذلك، يمكنك الحصول على هذه البيانات في ثانية أو ثانيتين، وإجراء الاختبار والتخلص منها. هذه اللقطات تحل مشاكل مختلفة. في الحالة الأولى - للارتقاء والحصول على نسخ متماثلة جديدة، وفي الثانية - للاختبارات.
س: أنا لا أوافق. إن جعل استنساخ الحجم يعمل بشكل صحيح هو مهمة السحابة. لم ألقي نظرة على تنفيذها، لكني أعرف كيف نفعل ذلك على الأجهزة. لدينا Ceph، فهو يسمح بأي حجم مادي () يقول استنساخ واحصل على مجلد ثانٍ بنفس الخصائص في عشرات المللي ثانية، 'عمي، الخ. عليك أن تفهم أن هناك نسخة صعبة للكتابة بالداخل. لماذا لا تفعل السحابة نفس الشيء؟ أنا متأكد من أنهم يحاولون القيام بذلك بطريقة أو بأخرى.
NA: ولكن سيستغرق الأمر ثوانٍ، أو عشرات الثواني لرفع مثيل، وإحضار Docker إلى هناك، وما إلى ذلك.
س: لماذا هو ضروري لرفع مثيل كامل؟ لدينا مثيل يحتوي على 32 نواة، 16... ويمكن أن يتناسب معه - على سبيل المثال، أربعة. عندما نطلب الخامس، سيتم رفع المثيل بالفعل، ثم سيتم حذفه.
NA: نعم، من المثير للاهتمام، أن Kubernetes قصة مختلفة. قاعدة بياناتنا ليست في K8s، ولدينا مثيل واحد. لكن استنساخ قاعدة بيانات متعددة التيرابايت لا يستغرق أكثر من ثانيتين.
س: هذا عظيم. لكن نقطتي الأولية هي أن هذا ليس حلاً عامًا. نعم، إنه رائع، لكنه مناسب فقط لـ Postgres وعلى عقدة واحدة فقط.
NA: إنها مناسبة ليس فقط لـ Postgres: هذه الخطط كما وصفتها لن تعمل إلا فيها. ولكن إذا لم نهتم بالخطط، ونحتاج فقط إلى جميع البيانات للاختبار الوظيفي، فهذا مناسب لأي نظام إدارة قواعد بيانات.
س: منذ عدة سنوات فعلنا شيئًا مشابهًا في لقطات LVM. هذا كلاسيكي. تم استخدام هذا النهج بنشاط كبير. العقد ذات الحالة هي مجرد ألم. لأنه لا يجب أن تسقطهم، يجب أن تتذكرهم دائمًا...
NA: هل ترى أي إمكانية لوجود هجين هنا؟ لنفترض أن الحالة هي نوع من الكبسولة، وهي تعمل مع العديد من الأشخاص (العديد من المختبرين). لدينا مجلد واحد، ولكن بفضل نظام الملفات، تكون النسخ محلية. إذا سقطت الكبسولة، ولكن بقي القرص، فسوف ترتفع الكبسولة، وتحسب المعلومات حول جميع النسخ، وتلتقط كل شيء مرة أخرى وتقول: "ها هي نسخك تعمل على هذه المنافذ، استمر في العمل معهم."
س: من الناحية الفنية، هذا يعني أنه داخل Kubernetes هناك حجرة واحدة نقوم من خلالها بتشغيل العديد من Postgres.
NA: نعم. لديه حد: لنفترض أنه لا يعمل معه أكثر من 10 أشخاص في نفس الوقت. إذا كنت بحاجة إلى 20، فسنطلق حجرة ثانية من هذا القبيل. سوف نقوم باستنساخه بالكامل، بعد أن حصلنا على المجلد الكامل الثاني، سيكون له نفس النسخ العشرة "الرفيعة". ألا ترى هذه الفرصة؟
س: نحن بحاجة إلى إضافة قضايا أمنية هنا. يشير هذا النوع من التنظيم إلى أن هذه الكبسولة تتمتع بامتيازات (قدرات) عالية، لأنها يمكنها إجراء عمليات غير قياسية على نظام الملفات... لكنني أكرر: أعتقد أنهم سيصلحون التخزين في Kubernetes على المدى المتوسط، وفي الغيوم سوف يقومون بإصلاح القصة بأكملها بالمجلدات - كل شيء "سيعمل فقط". سيكون هناك تغيير الحجم، والاستنساخ... هناك مجلد - نقول: "إنشاء مجلد جديد على أساس ذلك"، وبعد ثانية ونصف نحصل على ما نحتاجه.
NA: لا أؤمن بالثانية والنصف مقابل العديد من التيرابايت. على Ceph تفعل ذلك بنفسك، لكنك تتحدث عن السحب. انتقل إلى السحابة، وقم بإجراء نسخة من وحدة تخزين EBS متعددة تيرابايت على EC2 وشاهد الأداء. لن يستغرق الأمر بضع ثوان. أنا مهتم جدًا بموعد وصولهم إلى هذا المستوى. أنا أفهم ما تقوله، ولكن أرجو أن أختلف.
س: طيب، ولكن قلت على المدى المتوسط، وليس على المدى القصير. لعدة سنوات.
حول مشغل PostgreSQL من Zalando
في منتصف هذا الاجتماع، انضم أيضًا Alexey Klyukin، المطور السابق من Zalando، وتحدث عن تاريخ مشغل PostgreSQL:
من الرائع أن يتم التطرق إلى هذا الموضوع بشكل عام: كل من Postgres وKubernetes. عندما بدأنا القيام بذلك في زالاندو في عام 2017، كان هذا موضوعًا أراد الجميع القيام به، لكن لم يفعل أحد ذلك. كان لدى الجميع بالفعل Kubernetes، ولكن عندما سألوا عما يجب فعله بقواعد البيانات، حتى الناس يحبون ذلك ، الذي بشر K8s، قال شيئًا كهذا:
"انتقل إلى الخدمات المُدارة واستخدمها، ولا تقم بتشغيل قاعدة البيانات في Kubernetes. بخلاف ذلك، ستقرر أجهزة K8 الخاصة بك، على سبيل المثال، إجراء ترقية، وإيقاف تشغيل جميع العقد، وسوف تطير بياناتك بعيدًا جدًا.
قررنا إنشاء مشغل، خلافًا لهذه النصيحة، سيطلق قاعدة بيانات Postgres في Kubernetes. وكان لدينا سبب وجيه - . يعد هذا بمثابة تجاوز فشل تلقائي لـ PostgreSQL، ويتم إجراؤه بشكل صحيح، أي. باستخدام etcd أو consul أو ZooKeeper كمخزن للمعلومات حول المجموعة. مثل هذا المستودع الذي سيعطي كل من يسأل، على سبيل المثال، ما هو القائد الحالي، نفس المعلومات - على الرغم من حقيقة أن كل شيء لدينا موزع - بحيث لا يكون هناك انقسام في الدماغ. بالإضافة إلى أنه كان لدينا له.
بشكل عام، ظهرت حاجة الشركة إلى تجاوز الفشل التلقائي بعد الترحيل من مركز بيانات الأجهزة الداخلية إلى السحابة. اعتمدت السحابة على حل PaaS (النظام الأساسي كخدمة) الخاص. إنه مفتوح المصدر، لكن الأمر استغرق الكثير من العمل لإعداده وتشغيله. كان يدعى .
في البداية، لم يكن هناك Kubernetes. وبشكل أكثر دقة، عندما تم نشر الحل الخاص بنا، كانت طائرات K8 موجودة بالفعل، ولكنها كانت بدائية للغاية لدرجة أنها لم تكن مناسبة للإنتاج. كان ذلك في رأيي عام 2015 أو 2016. بحلول عام 2017، أصبح نظام Kubernetes أكثر أو أقل نضجًا، وكانت هناك حاجة للانتقال إليه.
وكان لدينا بالفعل حاوية Docker. كان هناك PaaS يستخدم Docker. لماذا لا تجرب K8s؟ لماذا لا تكتب المشغل الخاص بك؟ مراد كابيلوف، الذي جاء إلينا من أفيتو، بدأ هذا كمشروع بمبادرة منه - "لللعب" - و"انطلق" المشروع.
ولكن بشكل عام، أردت أن أتحدث عن AWS. لماذا كان هناك رمز تاريخي متعلق بـ AWS...
عندما تقوم بتشغيل شيء ما في Kubernetes، عليك أن تفهم أن K8s هو عمل قيد التقدم. إنها تتطور باستمرار وتتحسن وحتى تنهار من وقت لآخر. يجب عليك مراقبة جميع التغييرات في Kubernetes عن كثب، ويجب أن تكون مستعدًا للتعمق فيها إذا حدث شيء ما ومعرفة كيفية عمله بالتفصيل - ربما أكثر مما تريد. وينطبق هذا، من حيث المبدأ، على أي منصة تقوم بتشغيل قواعد البيانات الخاصة بك عليها...
لذا، عندما قمنا بالبيان، كان لدينا Postgres يعمل على وحدة تخزين خارجية (EBS في هذه الحالة، نظرًا لأننا كنا نعمل على AWS). نمت قاعدة البيانات، في مرحلة ما كان من الضروري تغيير حجمها: على سبيل المثال، كان الحجم الأولي لـ EBS 100 تيرابايت، ونمت قاعدة البيانات إليه، والآن نريد أن نجعل EBS 200 تيرابايت. كيف؟ لنفترض أنه يمكنك إجراء تفريغ/استعادة لمثيل جديد، ولكن هذا سيستغرق وقتًا طويلاً وسيتضمن فترة توقف عن العمل.
لذلك، أردت تغيير الحجم الذي من شأنه تكبير قسم EBS ومن ثم إخبار نظام الملفات باستخدام المساحة الجديدة. وقد فعلنا ذلك، ولكن في ذلك الوقت لم يكن لدى Kubernetes أي واجهة برمجة تطبيقات لعملية تغيير الحجم. منذ أن عملنا على AWS، قمنا بكتابة التعليمات البرمجية لواجهة برمجة التطبيقات (API) الخاصة بها.
لا أحد يمنعك من فعل الشيء نفسه بالنسبة للمنصات الأخرى. لا يوجد ما يشير في البيان إلى أنه لا يمكن تشغيله إلا على AWS، ولن يعمل على أي شيء آخر. بشكل عام، هذا مشروع مفتوح المصدر: إذا أراد أي شخص تسريع ظهور استخدام واجهة برمجة التطبيقات الجديدة، فنحن نرحب به. يأكل ، سحب الطلبات - يحاول فريق Zalando الرد عليها بسرعة كبيرة وترقية المشغل. بقدر ما أعرف، المشروع في Google Summer of Code وبعض المبادرات المماثلة الأخرى. يعمل زالاندو بنشاط كبير على ذلك.
مكافأة ملاحظة!
إذا كنت مهتمًا بموضوع PostgreSQL وKubernetes، فيرجى أيضًا ملاحظة أن يوم الثلاثاء القادم من Postgres قد أقيم الأسبوع الماضي، حيث تحدثت مع نيكولاي ألكسندر كوكوشكين من زالاندو. الفيديو منه متاح .
ذكر المكتب الصحفى
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com