كثير من الناس على دراية بـ PostgreSQL DBMS ، وقد أثبتت نفسها جيدًا في المنشآت الصغيرة. ومع ذلك ، أصبح الاتجاه نحو المصدر المفتوح واضحًا بشكل متزايد ، حتى عندما يتعلق الأمر بمتطلبات الشركات والمؤسسات الكبيرة. في هذه المقالة ، سنصف كيفية دمج Postgres في بيئة الشركة ومشاركة تجربتنا في إنشاء نظام نسخ احتياطي (BMS) لقاعدة البيانات هذه باستخدام نظام النسخ الاحتياطي Commvault كمثال.
لقد أثبتت PostgreSQL قيمتها بالفعل - فهي تعمل بشكل رائع ، وتستخدمها الشركات الرقمية العصرية مثل Alibaba و TripAdvisor ، ونقص الإتاوات يجعلها بديلاً مغريًا للوحوش مثل MS SQL أو Oracle DB. ولكن بمجرد أن نبدأ في التفكير في PostgreSQL في مشهد المؤسسة ، فإننا نواجه على الفور متطلبات صعبة: "ولكن ماذا عن التسامح مع أخطاء التكوين؟ التسامح مع الكوارث؟ أين هي المراقبة الشاملة؟ ماذا عن النسخ الاحتياطية الآلية؟ ماذا عن استخدام مكتبات الأشرطة مباشرة وعلى التخزين الثانوي؟ "
من ناحية أخرى ، لا تحتوي PostgreSQL على أدوات نسخ احتياطي مضمنة ، مثل نظم إدارة قواعد البيانات من نوع RMAN "للبالغين" من Oracle DB أو SAP Database Backup. من ناحية أخرى ، فإن بائعي أنظمة النسخ الاحتياطي للشركات (Veeam و Veritas و Commvault) ، على الرغم من أنهم يدعمون PostgreSQL ، يعملون في الواقع فقط مع تكوين معين (مستقل عادةً) ومع مجموعة من القيود المختلفة.
تحظى أنظمة النسخ الاحتياطي المصممة خصيصًا لـ PostgreSQL ، مثل Barman و Wal-g و pg_probackup ، بشعبية كبيرة في منشآت PostgreSQL الصغيرة أو حيث لا تكون هناك حاجة إلى نسخ احتياطية كبيرة من عناصر أخرى في مجال تكنولوجيا المعلومات. على سبيل المثال ، بالإضافة إلى PostgreSQL ، قد تتضمن البنية التحتية خوادم فعلية وافتراضية ، OpenShift ، Oracle ، MariaDB ، Cassandra ، إلخ. كل هذا مرغوب فيه لعمل نسخة احتياطية باستخدام أداة مشتركة. يُعد وضع حل منفصل خاص بـ PostgreSQL فكرة سيئة: سيتم نسخ البيانات في مكان ما على القرص ، ومن ثم يجب إزالتها إلى شريط. تؤدي مضاعفة النسخ الاحتياطي هذه إلى زيادة وقت النسخ الاحتياطي ، والأهم من ذلك ، زيادة وقت الاسترداد.
في أحد حلول المؤسسات ، يتم إجراء النسخ الاحتياطي للتثبيت مع عدد معين من العقد لمجموعة مخصصة. في الوقت نفسه ، على سبيل المثال ، لا يمكن لـ Commvault العمل إلا مع مجموعة مكونة من عقدين ، حيث يتم تعيين أساسي وثانوي بشكل صارم لعقد معينة. نعم ، ومن المنطقي إجراء نسخ احتياطي باستخدام Primary فقط ، لأن النسخ الاحتياطي باستخدام Secondary له حدوده. نظرًا لخصائص نظام إدارة قواعد البيانات (DBMS) ، لا يتم إنشاء تفريغ على الثانوية ، وبالتالي تبقى فقط إمكانية النسخ الاحتياطي للملف.
لتقليل مخاطر وقت التعطل ، عند إنشاء نظام تجاوز الفشل ، يتم تكوين تكوين مجموعة "مباشر" ، ويمكن ترحيل الأساسي تدريجيًا بين الخوادم المختلفة. على سبيل المثال ، يقوم برنامج Patroni نفسه بتشغيل Primary على عقدة عنقودية يتم اختيارها عشوائيًا. ليس لدى RMS طريقة لتتبع هذا خارج الصندوق ، وإذا تغير التكوين ، تنقطع العمليات. أي أن إدخال التحكم الخارجي يمنع RMS من العمل بفعالية ، لأن خادم التحكم ببساطة لا يفهم أين وما هي البيانات التي يجب نسخها.
مشكلة أخرى هي تنفيذ النسخ الاحتياطي في Postgres. يمكن ذلك عن طريق التفريغ ، ويعمل على قواعد صغيرة. ولكن في قواعد البيانات الكبيرة ، يستغرق الإغراق وقتًا طويلاً ، ويتطلب الكثير من الموارد ، ويمكن أن يؤدي إلى فشل مثيل قاعدة البيانات.
يعمل النسخ الاحتياطي للملف على تصحيح الموقف ، ولكنه يكون بطيئًا في قواعد البيانات الكبيرة لأنه يعمل في الوضع المفرد. بالإضافة إلى ذلك ، فإن البائعين لديهم عدد من القيود الإضافية. إما أنه لا يمكنك استخدام النسخ الاحتياطية للملفات والتفريغ في نفس الوقت ، أو أن إلغاء البيانات المكررة غير مدعوم. هناك العديد من المشاكل ، وغالبًا ما يكون من الأسهل اختيار نظام إدارة قواعد البيانات باهظ الثمن ، ولكنه مثبت بدلاً من Postgres.
لا يوجد مكان للتراجع! خلف مطوري موسكو!
ومع ذلك ، واجه فريقنا مؤخرًا تحديًا صعبًا: في مشروع إنشاء AIS OSAGO 2.0 ، حيث أنشأنا البنية التحتية لتكنولوجيا المعلومات ، اختار المطورون PostgreSQL للنظام الجديد.
من الأسهل بكثير لمطوري البرامج الكبار استخدام حلول مفتوحة المصدر "عصرية". في حالة نفس Facebook ، يوجد عدد كافٍ من المتخصصين الذين يدعمون عمل DBMS. وفي حالة RSA ، وقعت جميع مهام "اليوم الثاني" على عاتقنا. لقد طُلب منا توفير التسامح مع الخطأ ، وبناء مجموعة ، وبالطبع إعداد نسخ احتياطية. كان منطق الأفعال على النحو التالي:
- علم شاروخان عمل نسخة احتياطية من العقدة الأساسية للكتلة. للقيام بذلك ، يجب أن يجدها RMS ، مما يعني أن التكامل مع حل أو آخر لإدارة مجموعة PostgreSQL ضروري. في حالة PCA ، تم استخدام برنامج Patroni لهذا الغرض.
- حدد نوع النسخ الاحتياطي بناءً على كمية البيانات ومتطلبات الاسترداد. على سبيل المثال ، عندما يكون من الضروري استعادة الصفحات بشكل دقيق ، استخدم ملف تفريغ ، وإذا كانت قواعد البيانات كبيرة ولم تكن الاستعادة الدقيقة مطلوبة ، فاعمل على مستوى الملف.
- إرفاق إمكانية النسخ الاحتياطي للكتلة بالحل من أجل إنشاء نسخة احتياطية في الوضع متعدد الخيوط.
في الوقت نفسه ، شرعنا في البداية في إنشاء نظام فعال وبسيط بدون ربط وحشي من مكونات إضافية. كلما قل عدد العكازات ، قل العبء على الموظفين وقل خطر فشل القولون العصبي. استبعدنا على الفور الأساليب التي استخدمت Veeam و RMAN ، لأن مجموعة من حلين تشير بالفعل إلى عدم موثوقية النظام.
القليل من السحر للمؤسسة
لذلك ، احتجنا إلى ضمان نسخ احتياطي موثوق لـ 10 مجموعات من 3 عقد لكل منها ، بينما تنعكس البنية التحتية نفسها في مركز بيانات النسخ الاحتياطي. تعمل مراكز البيانات من حيث PostgreSQL على مبدأ المبني للمجهول. كان الحجم الإجمالي لقواعد البيانات 50 تيرابايت. يمكن لأي RMS على مستوى الشركة التعامل مع هذا بسهولة. لكن الفارق الدقيق هو أنه في البداية في Postgres لا يوجد ربط للتوافق الكامل والعميق مع أنظمة النسخ الاحتياطي. لذلك ، كان علينا البحث عن حل يحتوي في البداية على الحد الأقصى من الوظائف بالتزامن مع PostgreSQL ، وتحسين النظام.
عقدنا 3 "هاكاثونات" داخلية - قمنا بمراجعة أكثر من خمسين تطورًا ، واختبرناها ، وقمنا بإجراء تغييرات تتعلق بفرضياتنا ، وفحصناها مرة أخرى. بعد تحليل الخيارات المتاحة ، اخترنا Commvault. يمكن أن يعمل هذا المنتج "خارج الصندوق" بالفعل مع أبسط تثبيت لمجموعة PostgreSQL ، وقد أدت هندسته المفتوحة إلى ظهور الأمل (وهو ما تحقق) من أجل تحسين وتكامل ناجحين. يمكن لتطبيق Commvault أيضًا إجراء نسخ احتياطي لسجلات PostgreSQL. على سبيل المثال ، يمكن لـ Veritas NetBackup في جزء PostgreSQL إجراء نسخ احتياطية كاملة فقط.
المزيد عن الهندسة المعمارية. تم تركيب وحدات خدمة إدارة Commvault في كل مركز من مركزي البيانات في تكوين CommServ HA. يتم عكس النظام وإدارته من خلال وحدة تحكم واحدة ، ومن وجهة نظر HA يلبي جميع متطلبات المؤسسة.
أطلقنا أيضًا خادمين للوسائط المادية في كل مركز بيانات ، وقمنا بتوصيل مصفوفات الأقراص ومكتبات الأشرطة المخصصة خصيصًا للنسخ الاحتياطية عبر SAN عبر القناة الليفية. ضمنت قواعد بيانات إلغاء البيانات المكررة الموسعة التسامح مع أخطاء خوادم الوسائط ، كما أن اتصال كل خادم بكل خادم CSV يضمن إمكانية التشغيل المستمر في حالة فشل أي مكون. تسمح بنية النظام للنسخ الاحتياطية بالاستمرار حتى في حالة فشل أحد مراكز البيانات.
يحدد Patroni عقدة أساسية لكل مجموعة. يمكن أن تكون أي عقدة مجانية في مركز البيانات - ولكن في الأساس فقط. في النسخ الاحتياطي ، تكون جميع العقد ثانوية.
لكي يفهم Commvault أي عقدة عنقودية أساسية ، قمنا بدمج النظام (بفضل البنية المفتوحة للحل) مع Postgres. للقيام بذلك ، تم إنشاء برنامج نصي يُبلغ عن الموقع الحالي للعقدة الأساسية إلى خادم التحكم في Commvault.
بشكل عام ، تبدو العملية كما يلي:
يقوم Patroni بتحديد Primary → Keepalived يرفع مجموعة IP ويقوم بتشغيل البرنامج النصي → يتلقى وكيل Commvault على العقدة المحددة من الكتلة إشعارًا بأن هذا Primary → Commvault يعيد تكوين النسخة الاحتياطية تلقائيًا داخل العميل الزائف.
تتمثل ميزة هذا النهج في أن الحل لا يؤثر على تناسق السجلات أو صحتها ، أو استعادة مثيل Postgres. كما أنه يتوسع بسهولة ، لأنه لم يعد من الضروري إصلاح عقد Commvault الأساسي والثانوي. يكفي أن يفهم النظام مكان وجود الأساسي ، ويمكن زيادة عدد العقد إلى أي قيمة تقريبًا.
الحل لا يدعي أنه مثالي وله الفروق الدقيقة الخاصة به. يمكن لتطبيق Commvault فقط إجراء نسخ احتياطي لمثيل كامل ، وليس قواعد البيانات الفردية. لذلك ، تم إنشاء مثيل منفصل لكل قاعدة بيانات. يتم تجميع العملاء الحقيقيين في عملاء زائفين افتراضيين. كل عميل زائف Commvault عبارة عن مجموعة UNIX. تتم إضافة عقد المجموعة التي تم تثبيت وكيل Commvault الخاص بـ Postgres إليها. نتيجة لذلك ، يتم نسخ جميع العقد الافتراضية للعميل الزائف احتياطيًا كمثال واحد.
داخل كل عميل زائف ، يشار إلى العقدة النشطة للكتلة. هذا هو بالضبط ما يحدده حل التكامل الخاص بنا لـ Commvault. مبدأ تشغيله بسيط للغاية: إذا ارتفع عنوان IP للكتلة على عقدة ، فإن البرنامج النصي يضبط معلمة "العقدة النشطة" في ثنائي وكيل Commvault - في الواقع ، يضع البرنامج النصي "1" في الجزء الأيمن من الذاكرة. يرسل الوكيل هذه البيانات إلى CommServe ، ويقوم Commvault بعمل نسخة احتياطية من العقدة المطلوبة. بالإضافة إلى ذلك ، يتم التحقق من صحة التكوين على مستوى البرنامج النصي ، مما يساعد على تجنب الأخطاء عند بدء النسخ الاحتياطي.
في الوقت نفسه ، يتم نسخ قواعد البيانات الكبيرة احتياطيًا في عدة تدفقات ، مما يلبي متطلبات RPO ونافذة النسخ الاحتياطي. العبء على النظام ضئيل: النسخ الكاملة لا تحدث كثيرًا ، في الأيام الأخرى يتم جمع السجلات فقط ، وأثناء فترات التحميل المنخفض.
بالمناسبة ، طبقنا سياسات منفصلة لنسخ سجلات PostgreSQL المؤرشفة احتياطيًا - يتم تخزينها وفقًا لقواعد مختلفة ، ونسخها وفقًا لجدول زمني مختلف ، ولم يتم تمكين إلغاء البيانات المكررة لها ، نظرًا لأن هذه السجلات تحمل بيانات فريدة.
لضمان تناسق البنية التحتية لتكنولوجيا المعلومات بالكامل ، يتم تثبيت عملاء ملف Commvault منفصلين على كل عقد من عقد المجموعة. تستبعد ملفات Postgres من النسخ الاحتياطية وهي مخصصة فقط للنسخ الاحتياطية لنظام التشغيل والتطبيقات. يحتوي هذا الجزء من البيانات أيضًا على سياسته الخاصة وفترة التخزين الخاصة به.
حاليًا ، لا يؤثر RMS على الخدمات الإنتاجية ، ولكن إذا تغير الوضع ، فسيكون من الممكن تمكين نظام تحديد الحمل في Commvault.
هل هو بخير؟ جيد!
لذلك ، لم نحصل على نسخة احتياطية قابلة للتطبيق فحسب ، بل حصلنا أيضًا على نسخة احتياطية مؤتمتة بالكامل لتثبيت مجموعة PostgreSQL ، والتي تلبي جميع متطلبات مكالمات المؤسسة.
تتداخل معلمات RPO و RTO في ساعة واحدة وساعتين مع هامش ، مما يعني أن النظام سوف يمتثل لها حتى مع زيادة كبيرة في حجم البيانات المخزنة. على عكس العديد من الشكوك ، اتضح أن PostgreSQL وبيئة المؤسسة متوافقة تمامًا. والآن نعلم من تجربتنا الخاصة أن النسخ الاحتياطي لنظام إدارة قواعد البيانات هذا ممكن في مجموعة متنوعة من التكوينات.
بالطبع ، في هذا المسار ، كان علينا أن نرتدي سبعة أزواج من الأحذية الحديدية ، ونتغلب على عدد من الصعوبات ، ونقفز على بعض المكابس ونصحح عددًا من الأخطاء. ولكن الآن تم اختبار النهج بالفعل ويمكن استخدامه لتنفيذ المصدر المفتوح بدلاً من نظام إدارة قواعد البيانات (DBMS) في البيئة القاسية للمؤسسة.
هل حاولت العمل مع PostgreSQL في بيئة شركة؟
المؤلفون:
أوليج لافرينوف ، مهندس تصميم أنظمة تخزين البيانات ، Jet Infosystems
ديمتري إريكين ، مهندس تصميم أنظمة حوسبة أنظمة المعلومات النفاثة
المصدر: www.habr.com