بطريقة أو بأخرى، تاريخيًا، تنقسم صناعة تكنولوجيا المعلومات إلى معسكرين مشروطين لأي سبب من الأسباب: أولئك الذين "يؤيدون" وأولئك الذين "يعارضون". علاوة على ذلك، يمكن أن يكون موضوع النزاعات تعسفيا تماما. أي نظام تشغيل أفضل: وين أم لينكس؟ على هاتف ذكي يعمل بنظام Android أو iOS؟ هل يجب عليك تخزين كل شيء في السحابة أو وضعه على وحدة تخزين RAID باردة ووضع البراغي في خزنة؟ هل يحق لأشخاص PHP أن يطلق عليهم مبرمجين؟ تكون هذه النزاعات، في بعض الأحيان، ذات طبيعة وجودية حصرية وليس لها أي أساس سوى المصلحة الرياضية.
لقد حدث أنه مع ظهور الحاويات وكل هذا المطبخ المحبوب مع عامل الإرساء وk8s المشروط، بدأت المناقشات "المؤيدة" و"المعارضة" لاستخدام القدرات الجديدة في مجالات مختلفة من الواجهة الخلفية. (دعونا نحجز مسبقًا أنه على الرغم من الإشارة إلى Kubernetes في أغلب الأحيان كمنسق في هذه المناقشة، فإن اختيار هذه الأداة بالذات ليس له أهمية أساسية. وبدلاً من ذلك، يمكنك استبدال أي أداة أخرى تبدو أكثر ملاءمة ومألوفة بالنسبة لك .)
ويبدو أن هذا سيكون نزاعًا بسيطًا بين وجهين لعملة واحدة. لا معنى لها ولا رحمة مثل المواجهة الأبدية بين Win vs Linux، حيث يوجد الأشخاص المناسبون في مكان ما في المنتصف. ولكن في حالة النقل بالحاويات، ليس كل شيء بهذه البساطة. عادة في مثل هذه النزاعات لا يوجد جانب صحيح، ولكن في حالة "استخدام" أو "عدم استخدام" حاويات لتخزين قواعد البيانات، كل شيء ينقلب رأسًا على عقب. لأنه بمعنى ما، فإن كلا من مؤيدي ومعارضي هذا النهج على حق.
الجانب المشرق
يمكن وصف حجة Light Side بإيجاز في عبارة واحدة: "مرحبًا، 2k19 خارج النافذة!" يبدو الأمر وكأنه شعبوية بالطبع، ولكن إذا تعمقت في الوضع بالتفصيل، فستجد أن له مزاياه. دعونا فرزها الآن.
لنفترض أن لديك مشروع ويب كبير. كان من الممكن أن يتم بناؤها في البداية على أساس نهج الخدمات الصغيرة، أو أنها وصلت إليها في مرحلة ما من خلال مسار تطوري - وهذا ليس مهمًا جدًا، في الواقع. لقد قمت بتقسيم مشروعنا إلى خدمات صغيرة منفصلة، وقمت بإعداد التنسيق وموازنة التحميل والقياس. والآن، بضمير مرتاح، يمكنك احتساء الموهيتو في الأرجوحة أثناء تأثيرات الهبرة بدلاً من رفع الخوادم المتساقطة. ولكن في جميع الإجراءات يجب أن تكون متسقًا. في كثير من الأحيان، يتم وضع التطبيق نفسه فقط، أي الكود، في حاوية. ماذا لدينا إلى جانب الكود؟
هذا صحيح، البيانات. قلب أي مشروع هو بياناته: يمكن أن يكون هذا إما نظام إدارة قواعد بيانات نموذجي - MySQL، أو Postgre، أو MongoDB، أو وحدة تخزين مستخدمة للبحث (ElasticSearch)، أو وحدة تخزين ذات قيمة أساسية للتخزين المؤقت - على سبيل المثال، redis، وما إلى ذلك. سنتحدث عن خيارات تنفيذ الواجهة الخلفية الملتوية عندما تتعطل قاعدة البيانات بسبب استعلامات مكتوبة بشكل سيئ، وبدلاً من ذلك سنتحدث عن ضمان التسامح مع الخطأ لقاعدة البيانات هذه تحت تحميل العميل. بعد كل شيء، عندما نقوم بوضع تطبيقنا في حاوية ونسمح له بالتوسع بحرية لمعالجة أي عدد من الطلبات الواردة، فإن هذا يؤدي بشكل طبيعي إلى زيادة الحمل على قاعدة البيانات.
في الواقع، أصبحت قناة الوصول إلى قاعدة البيانات والخادم الذي يتم تشغيلها عليه بمثابة عين الإبرة في الواجهة الخلفية الجميلة للحاويات. وفي الوقت نفسه، فإن الدافع الرئيسي للمحاكاة الافتراضية للحاويات هو قابلية الحركة والمرونة للهيكل، مما يسمح لنا بتنظيم توزيع أحمال الذروة عبر البنية التحتية بأكملها المتاحة لنا بأكبر قدر ممكن من الكفاءة. وهذا يعني أننا إذا لم نقم بوضع جميع عناصر النظام الحالية في حاويات ونشرها عبر المجموعة، فإننا نرتكب خطأً فادحًا للغاية.
من المنطقي أكثر بكثير تجميع ليس فقط التطبيق نفسه، ولكن أيضًا الخدمات المسؤولة عن تخزين البيانات. من خلال تجميع ونشر خوادم الويب التي تعمل بشكل مستقل وتوزيع الحمل فيما بينها في k8s، فإننا نحل بالفعل مشكلة مزامنة البيانات - نفس التعليقات على المنشورات، إذا أخذنا بعض الوسائط أو منصة المدونة كمثال. على أية حال، لدينا تمثيل داخل المجموعة، وحتى افتراضي، لقاعدة البيانات كخدمة خارجية. السؤال هو أن قاعدة البيانات نفسها لم يتم تجميعها بعد - فخوادم الويب المنتشرة في المكعب تأخذ معلومات حول التغييرات من قاعدة بياناتنا القتالية الثابتة، والتي تدور بشكل منفصل.
هل تشعر بالصيد؟ نحن نستخدم k8s أو Swarm لتوزيع التحميل وتجنب تعطل خادم الويب الرئيسي، لكننا لا نفعل ذلك لقاعدة البيانات. ولكن إذا تعطلت قاعدة البيانات، فلن يكون للبنية التحتية المجمعة لدينا أي معنى - ما الفائدة من صفحات الويب الفارغة التي تعرض خطأ في الوصول إلى قاعدة البيانات؟
ولهذا السبب من الضروري تجميع ليس فقط خوادم الويب، كما يحدث عادةً، ولكن أيضًا البنية التحتية لقاعدة البيانات. بهذه الطريقة فقط يمكننا ضمان وجود هيكل يعمل بشكل كامل في فريق واحد، ولكن في نفس الوقت مستقل عن بعضنا البعض. علاوة على ذلك، حتى لو "انهار" نصف الواجهة الخلفية لدينا تحت الحمل، فإن الباقي سيبقى على قيد الحياة، وسيساعد نظام مزامنة قواعد البيانات مع بعضها البعض داخل المجموعة والقدرة على توسيع نطاق المجموعات الجديدة ونشرها إلى ما لا نهاية في الوصول بسرعة إلى السعة المطلوبة - لو كانت هناك رفوف فقط في مركز البيانات.
بالإضافة إلى ذلك، يسمح لك نموذج قاعدة البيانات الموزعة في مجموعات بأخذ قاعدة البيانات هذه إلى حيث تكون هناك حاجة إليها؛ إذا كنا نتحدث عن خدمة عالمية، فمن غير المنطقي تمامًا تدوير مجموعة الويب في مكان ما في منطقة سان فرانسيسكو وفي نفس الوقت إرسال الحزم عند الوصول إلى قاعدة البيانات في منطقة موسكو والعودة.
كما تسمح لك حاوية قاعدة البيانات ببناء جميع عناصر النظام على نفس مستوى التجريد. وهذا بدوره يجعل من الممكن إدارة هذا النظام مباشرة من التعليمات البرمجية، من قبل المطورين، دون المشاركة النشطة للمسؤولين. اعتقد المطورون أن هناك حاجة إلى نظام إدارة قواعد بيانات منفصل للمشروع الفرعي الجديد - سهل! كتبت ملف yaml، وقمت بتحميله إلى المجموعة وانتهيت.
وبطبيعة الحال، يتم تبسيط العملية الداخلية إلى حد كبير. أخبرني، كم مرة أغمضت عينيك عندما قام عضو جديد في الفريق بوضع يديه في قاعدة البيانات القتالية للعمل؟ ما هو الشيء الوحيد الذي لديك والذي يدور الآن؟ بالطبع، نحن جميعًا بالغون هنا، وفي مكان ما لدينا نسخة احتياطية جديدة، وحتى بعيدًا - خلف الرف مع خيار الجدة والزلاجات القديمة - نسخة احتياطية أخرى، ربما حتى في مخزن بارد، لأن مكتبك كان مشتعلًا بالفعل مرة واحدة. ولكن على الرغم من ذلك، فإن كل إدخال لعضو جديد في الفريق يتمتع بإمكانية الوصول إلى البنية التحتية القتالية، وبالطبع إلى قاعدة البيانات القتالية، يمثل دلوًا من الصلاحية لكل من حولك. حسنًا، من يعرفه، مبتدئ، ربما هو متقاطع؟ إنه أمر مخيف، سوف توافق.
تساعد الحاويات، وفي الواقع، البنية المادية الموزعة لقاعدة بيانات مشروعك على تجنب لحظات التحقق هذه. لا تثق مبتدئ؟ نعم! دعونا نمنحه مجموعته الخاصة للعمل مع قاعدة البيانات وفصلها عن المجموعات الأخرى - المزامنة فقط عن طريق الدفع اليدوي والتدوير المتزامن لمفتاحين (أحدهما لقائد الفريق والآخر للمسؤول). والجميع سعداء.
والآن حان الوقت للتحول إلى معارضي تجميع قواعد البيانات.
الجانب المظلم
وبمناقشة الأسباب التي تجعل الأمر لا يستحق وضع قاعدة البيانات في حاوية والاستمرار في تشغيلها على خادم مركزي واحد، فإننا لن ننحدر إلى خطاب المعتقدات التقليدية والعبارات مثل "الأجداد كانوا يديرون قواعد البيانات على الأجهزة، وكذلك نحن!" وبدلاً من ذلك، دعونا نحاول التوصل إلى موقف حيث يمكن للنقل بالحاويات أن يحقق أرباحاً ملموسة.
توافق على أن المشاريع التي تحتاج حقًا إلى قاعدة في حاوية لا يمكن حسابها على أصابع يد واحدة من قبل أفضل مشغل لآلة الطحن. بالنسبة للجزء الأكبر، حتى استخدام k8s أو Docker Swarm نفسه يعد زائدًا عن الحاجة - في كثير من الأحيان يتم اللجوء إلى هذه الأدوات بسبب الضجيج العام للتقنيات ومواقف "القدير" في شخص الجنسين لدفع كل شيء إلى الهاوية. الغيوم والحاويات. حسنًا، لأنه الآن أصبح من المألوف والجميع يفعل ذلك.
في نصف الحالات على الأقل، يعد استخدام Kubernetis أو Docker فقط في المشروع أمرًا زائدًا عن الحاجة. المشكلة هي أنه ليس كل الفرق أو شركات الاستعانة بمصادر خارجية التي تم تعيينها للحفاظ على البنية التحتية للعميل على علم بذلك. يكون الأمر أسوأ عندما يتم فرض الحاويات، لأنها تكلف العميل مبلغًا معينًا من العملات المعدنية.
بشكل عام، هناك رأي مفاده أن مافيا عامل الإرساء/المكعب تسحق بغباء العملاء الذين يستعينون بمصادر خارجية لقضايا البنية التحتية هذه. بعد كل شيء، للعمل مع المجموعات، نحتاج إلى مهندسين قادرين على ذلك ويفهمون بشكل عام بنية الحل المطبق. لقد وصفنا حالتنا ذات مرة مع منشور الجمهورية - حيث قمنا بتدريب فريق العميل على العمل في واقع Kubernetis، وكان الجميع راضين. وكان لائقا. في كثير من الأحيان، يأخذ "منفذو" k8s البنية التحتية للعميل كرهينة - لأنهم الآن فقط يفهمون كيف يعمل كل شيء هناك، ولا يوجد متخصصون من جانب العميل.
الآن تخيل أننا بهذه الطريقة نقوم بالاستعانة بمصادر خارجية ليس فقط لجزء خادم الويب، ولكن أيضًا لصيانة قاعدة البيانات. قلنا أن BD هو القلب، وفقدان القلب قاتل لأي كائن حي. باختصار، التوقعات ليست الأفضل. لذلك، بدلاً من الضجيج حول Kubernetis، يجب على العديد من المشاريع ببساطة ألا تهتم بالتعريفة العادية لـ AWS، والتي ستحل جميع مشاكل التحميل على موقعها/مشروعها. لكن AWS لم تعد عصرية، والعروض الاستعراضية تستحق أكثر من المال - لسوء الحظ، في بيئة تكنولوجيا المعلومات أيضًا.
نعم. ربما يحتاج المشروع حقًا إلى التجميع، ولكن إذا كان كل شيء واضحًا مع التطبيقات عديمة الحالة، فكيف يمكننا تنظيم اتصال شبكة لائق لقاعدة بيانات مجمعة؟
إذا كنا نتحدث عن حل هندسي سلس، وهو ما يعني الانتقال إلى k8s، فإن مشكلتنا الرئيسية هي تكرار البيانات في قاعدة بيانات مجمعة. تكون بعض أنظمة إدارة قواعد البيانات مخلصة تمامًا في البداية لتوزيع البيانات بين مثيلاتها الفردية. كثيرون آخرون لا يرحبون بذلك. وفي كثير من الأحيان، لا تكون الحجة الرئيسية في اختيار نظام إدارة قواعد البيانات لمشروعنا هي القدرة على التكرار بأقل تكلفة من الموارد والهندسة. خاصة إذا لم يتم التخطيط للمشروع في البداية كخدمة صغيرة، بل تطور ببساطة في هذا الاتجاه.
نعتقد أنه ليست هناك حاجة للحديث عن سرعة محركات أقراص الشبكة - فهي بطيئة. أولئك. مازلنا لا نملك فرصة حقيقية، إذا حدث شيء ما، لإعادة تشغيل مثيل DBMS في مكان ما حيث يوجد المزيد، على سبيل المثال، طاقة المعالج أو ذاكرة الوصول العشوائي المجانية. سوف نواجه بسرعة كبيرة أداء النظام الفرعي للقرص الافتراضي. وبناءً على ذلك، يجب تثبيت نظام إدارة قواعد البيانات (DBMS) على مجموعة الأجهزة الشخصية الخاصة به والموجودة على مقربة منه. أو من الضروري بطريقة أو بأخرى تهدئة مزامنة البيانات السريعة بما فيه الكفاية للاحتياطيات المفترضة.
مواصلة موضوع أنظمة الملفات الافتراضية: وحدات تخزين Docker، لسوء الحظ، ليست خالية من المشاكل. بشكل عام، فيما يتعلق بتخزين البيانات الموثوق به على المدى الطويل، أود أن أكتفي بالمخططات الأكثر بساطة من الناحية الفنية. كما أن إضافة طبقة تجريد جديدة من FS الخاصة بالحاوية إلى FS الخاص بالمضيف الأصلي يمثل خطرًا في حد ذاته. ولكن عندما يواجه تشغيل نظام دعم الحاويات أيضًا صعوبات في نقل البيانات بين هذه الطبقات، فهذه كارثة حقًا. في الوقت الحالي، يبدو أن معظم المشاكل المعروفة للإنسانية التقدمية قد تم القضاء عليها. لكنك تفهم، كلما كانت الآلية أكثر تعقيدا، كلما كان من الأسهل كسرها.
في ضوء كل هذه "المغامرات"، يكون الاحتفاظ بقاعدة البيانات في مكان واحد أكثر ربحية وأسهل، وحتى إذا كنت بحاجة إلى وضع التطبيق في حاوية، دعه يعمل من تلقاء نفسه ومن خلال بوابة التوزيع يتلقى اتصالاً متزامنًا مع التطبيق قاعدة البيانات، والتي سيتم قراءتها وكتابتها مرة واحدة فقط وفي مكان واحد. يقلل هذا الأسلوب من احتمال حدوث الأخطاء وإلغاء التزامن إلى الحد الأدنى.
ما الذي نؤدي إليه؟ علاوة على ذلك، تعتبر حاويات قاعدة البيانات مناسبة عندما تكون هناك حاجة حقيقية إليها. لا يمكنك حشو قاعدة بيانات كاملة للتطبيق وتدويرها كما لو كان لديك أكثر من عشرين خدمة صغيرة - فهي لا تعمل بهذه الطريقة. ويجب أن نفهم هذا بوضوح.
بدلا من الإخراج
إذا كنت تنتظر نتيجة واضحة "لجعل قاعدة البيانات افتراضية أم لا"، فسنخيب ظنك: لن يكون الأمر هنا. لأنه عند إنشاء أي حل للبنية التحتية، من الضروري عدم الاسترشاد بالموضة والتقدم، ولكن أولا وقبل كل شيء، بالفطرة السليمة.
هناك مشاريع تناسبها تمامًا المبادئ والأدوات التي تأتي مع Kubernetis، وفي مثل هذه المشاريع يسود السلام على الأقل في منطقة الواجهة الخلفية. وهناك مشاريع لا تحتاج إلى حاويات، بل إلى بنية تحتية عادية للخادم، لأنها في الأساس لا يمكنها إعادة القياس إلى نموذج مجموعة الخدمات الصغيرة، لأنها ستسقط.
المصدر: www.habr.com