في الآونة الأخيرة ، تبحث الشركات الروسية الكبيرة بشكل متزايد عن حلول تخزين ميسورة التكلفة. تصبح أنظمة قواعد البيانات (DBMS) مفتوحة المصدر منافسين لـ Oracle و SAP HANA و Sybase و Informix: PostgreSQL و MySQL و MariaDB وما إلى ذلك. عمالقة الغرب - Alibaba و Instagram و Skype - يستخدمونهم لفترة طويلة في مناطق تكنولوجيا المعلومات الخاصة بهم.
في مشروع الاتحاد الروسي لشركات التأمين على السيارات (RSA) ، حيث كانت Jet Infosystems تبني البنية التحتية لتكنولوجيا المعلومات لـ AIS OSAGO الجديد ، استخدم المطورون PostgreSQL DBMS. وفكرنا في كيفية ضمان توفر أقصى قدر من قاعدة البيانات والحد الأدنى من فقدان البيانات في حالة تعطل الأجهزة. وهذا الوصف "على الورق" للحل يبدو بسيطًا مثل 2 + 2 ، في الواقع ، كان على فريقنا العمل بجد لتحقيق التسامح مع الخطأ.
هناك العديد من أدوات تجاوز الفشل للمجموعات لـ PostgreSQL. هؤلاء هم Stolon و Patroni و Repmgr و Pacemaker + Corosync ، إلخ.
لقد اخترنا Patroni لأن هذا المشروع يتطور بنشاط ، على عكس المشاريع المماثلة ، لديه وثائق واضحة وأصبح اختيارًا متزايدًا لمسؤولي قواعد البيانات.
تكوين "مجموعة الحساء"
Patroni عبارة عن مجموعة من نصوص Python لأتمتة تبديل الدور الرائد لخادم قاعدة بيانات PostgreSQL إلى النسخة المتماثلة. يمكنه أيضًا تخزين وتعديل وتطبيق معلمات PostgreSQL DBMS نفسها. اتضح أنه ليست هناك حاجة لتحديث ملفات تهيئة PostgreSQL على كل خادم على حدة.
PostgreSQL هي قاعدة بيانات علائقية مفتوحة المصدر. لقد أثبتت نفسها في التعامل مع العمليات التحليلية الكبيرة والمعقدة.
Keepalived - في تكوين متعدد العقد ، يتم استخدامه لتمكين عنوان IP مخصص على عقدة المجموعة نفسها حيث يتم استخدام دور عقدة PostgreSQL الأساسية حاليًا. يعمل عنوان IP كنقطة دخول للتطبيقات والمستخدمين.
DCS هو تخزين تكوين موزع. يستخدمه Patroni لتخزين المعلومات حول تكوين الكتلة ، وأدوار خوادم المجموعة ، بالإضافة إلى تخزين معلمات تكوين PostgreSQL الخاصة به. هذه المقالة سوف تركز على الخ.
تجارب مع الفروق الدقيقة
بحثًا عن الحل الأمثل للتسامح مع الخطأ ومن أجل اختبار فرضياتنا حول تشغيل الخيارات المختلفة ، أنشأنا العديد من مقاعد الاختبار. في البداية ، نظرنا في الحلول التي كانت مختلفة عن البنية المستهدفة: على سبيل المثال ، استخدمنا Haproxy كعقدة أساسية لـ PostgreSQL أو DCS كانت موجودة على نفس الخوادم مثل PostgreSQL. نظمنا هاكاثونات داخلية ، ودرسنا كيف سيتصرف Patroni في حالة فشل مكون الخادم ، وعدم توفر الشبكة ، وتجاوز نظام الملفات ، وما إلى ذلك. أي أنهم وضعوا سيناريوهات فشل مختلفة. نتيجة لهذه "الدراسات العلمية" ، تم تشكيل الهيكل النهائي للحل المتسامح مع الخطأ.
طبق جورميه لتكنولوجيا المعلومات
هناك أدوار للخادم في PostgreSQL: أساسي - مثيل له القدرة على كتابة / قراءة البيانات ؛ نسخة متماثلة - مثيل للقراءة فقط ، تتم مزامنته باستمرار مع الأساسي. تكون هذه الأدوار ثابتة عند تشغيل PostgreSQL ، وإذا فشل خادم بالدور الأساسي ، يجب على مسؤول قاعدة البيانات رفع دور النسخة المتماثلة يدويًا إلى دور أساسي.
يقوم Patroni بإنشاء مجموعات تجاوز الفشل ، أي أنه يجمع الخوادم مع الأدوار الأساسية والنسخة المتماثلة. يوجد انعكاس تلقائي للدور بينهما في حالة حدوث أي فشل.
يوضح الرسم التوضيحي أعلاه كيفية اتصال خوادم التطبيق بأحد الخوادم في مجموعة Patroni. يستخدم هذا التكوين عقدة أساسية واحدة ونسختين متماثلتين ، أحدهما متزامن. مع النسخ المتزامن ، تعمل PostgreSQL بطريقة تنتظر الأساسي دائمًا كتابة التغييرات على النسخة المتماثلة. إذا كانت النسخة المتماثلة المتزامنة غير متوفرة ، فلن تكتب النسخة الأساسية التغييرات إلى نفسها ، وستكون للقراءة فقط. هذه هي بنية PostgreSQL. من أجل "تغيير طبيعتها" ، يتم استخدام النسخة المتماثلة الثانية - غير متزامنة (إذا لم يكن النسخ المتماثل المتزامن مطلوبًا ، فيمكنك قصر نفسك على نسخة متماثلة واحدة).
عند استخدام نسختين متماثلتين أو أكثر وتمكين النسخ المتزامن ، يقوم Patroni دائمًا بعمل نسخة متماثلة متزامنة واحدة فقط. إذا فشلت العقدة الأساسية ، يقوم Patroni برفع مستوى النسخة المتماثلة المتزامنة.
يوضح الرسم التوضيحي التالي وظائف Patroni الإضافية التي تعتبر حيوية في حلول المؤسسات الصناعية - نسخ البيانات إلى موقع نسخ احتياطي.
يستدعي Patroni هذه الوظيفة standby_cluster. يسمح باستخدام مجموعة Ratroni في موقع بعيد كنسخة متماثلة غير متزامنة. في حالة فقد الموقع الرئيسي ، ستبدأ مجموعة النسخ الاحتياطية Patroni في العمل كما لو كانت الموقع الرئيسي.
تسمى إحدى عقد مجموعة موقع النسخ الاحتياطي Standby Leader. إنها نسخة متماثلة غير متزامنة من العقدة الأساسية للموقع الرئيسي. تستقبل العقدتان المتبقيتان من كتلة موقع النسخ الاحتياطي البيانات من Standby Leader. هذه هي الطريقة التي يتم بها تنفيذ النسخ المتماثل المتتالي ، مما يقلل من حجم حركة المرور بين المواقع التكنولوجية.
تكوين تطبيقات مجموعة Patroni
بمجرد بدء التشغيل ، يقوم Patroni بإنشاء منفذ TCP منفصل. بعد إجراء طلب HTTP لهذا المنفذ ، يمكنك فهم عقدة الكتلة الأساسية وأيها نسخة متماثلة.
في Keepalived ، حددنا برنامج نصي صغير مصنوع ذاتيًا ككائن مراقبة يقوم باستقصاء منفذ Patroni TCP. يتوقع البرنامج النصي استجابة HTTP GET 200. عقدة الكتلة المستجيبة هي العقدة الأساسية ، حيث يبدأ Keepalived عنوان IP المخصص للاتصال بالمجموعة.
إذا قمت بتكوين المثيل الثاني لـ keepalived لانتظار استجابة HTTP GET 200 من نسخة متماثلة متزامنة ، فحينئذٍ ستطلق خاصية الاحتفاظ بها على نفس عقدة المجموعة عنوان IP مخصصًا آخر. يمكن أن يستخدم التطبيق هذا العنوان لقراءة البيانات من قاعدة البيانات. هذا الخيار مفيد ، على سبيل المثال ، لإعداد التقارير.
نظرًا لأن Patroni عبارة عن مجموعة من البرامج النصية ، فإن مثيلاتها في كل عقدة لا "تتصل" مباشرة مع بعضها البعض ، ولكنها تستخدم مخزن التكوين لهذا الغرض. نحن نستخدم etcd كما هو ، وهو النصاب القانوني لـ Patroni نفسه - تقوم العقدة الأساسية الحالية باستمرار بتحديث المفتاح في مستودع etcd ، مما يشير إلى أنه المفتاح الرئيسي. تقرأ بقية العقد العنقودية هذا المفتاح باستمرار و "تفهم" أنها نسخ متماثلة. توجد خدمة إلخ على خوادم مخصصة بمبلغ 3 أو 5. يتم تنفيذ مزامنة البيانات في التخزين وما إلى ذلك بين هذه الخوادم عن طريق خدمة etcd نفسها.
في سياق تجاربنا ، اكتشفنا أن الخدمة وغيرها تحتاج إلى النقل إلى خوادم منفصلة. أولاً ، يعتبر etcd شديد الحساسية لاستجابة الشبكة واستجابة النظام الفرعي للقرص ، ولن يتم تحميل الخوادم المخصصة. ثانيًا ، مع احتمال فصل الشبكة لعقد مجموعة Patroni ، قد يحدث "انقسام دماغي" - ستظهر عقدتان أساسيتان لن تعرف كل منهما شيئًا عن بعضهما البعض ، لأن المجموعة etcd سوف "تتفكك" أيضًا.
التحقق من الممارسة
على نطاق مشروع لبناء بنية تحتية لتكنولوجيا المعلومات لـ AIS OSAGO ، فإن تحقيق التسامح مع أخطاء PostgreSQL هو إحدى مهام "غرس" نظام DBMS مفتوح في مشهد تكنولوجيا المعلومات للشركات. بجانبه توجد قضايا ذات صلة تتعلق بدمج كتلة PostgreSQL مع أنظمة النسخ الاحتياطي ، وأدوات مراقبة البنية التحتية وأمن المعلومات ، وأمان البيانات الموثوق به في موقع النسخ الاحتياطي. كل من هذه الاتجاهات له مآزقه وطرقه لتجاوزها. لقد كتبنا بالفعل عن أحدها - تحدثنا عن النسخ الاحتياطي لـ PostgreSQL باستخدام حلول المؤسسات .
لقد أثبتت بنية PostgreSQL المتسامحة مع الأخطاء ، والتي تم التفكير فيها واختبارها في منصاتنا ، فعاليتها في الممارسة العملية. الحل جاهز "لترحيل" مختلف الأنظمة والفشل المنطقي. الآن يتم تشغيله على 10 مجموعات Patroni محملة بشكل كبير ويتحمل معالجة PostgreSQL لأحمال مئات الجيجابايت من البيانات في الساعة.
المؤلف: ديمتري إريكين ، ومهندس مصمم لأنظمة الحوسبة في أنظمة المعلومات النفاثة