تشغيل الأرانب (RabbitMQ) في وضع "البقاء على قيد الحياة بأي ثمن"

" الشركة " - مشغل الاتصالات PJSC "Megafon"
" Noda " هو خادم RabbitMQ.
" الكتلة " هي مزيج ، في حالتنا الثلاثة ، من عقد RabbitMQ ككل.
" Contour " - مجموعة من مجموعات RabbitMQ ، قواعد العمل التي يتم تحديدها على الموازن أمامهم.
" الموازن " ، " hap " - Haproxy - الموازن الذي يؤدي وظيفة تبديل الحمل على الكتل داخل الحلقة. يتم استخدام زوج من خوادم Haproxy التي تعمل بشكل متواز لكل حلقة.
" النظام الفرعي " - ناشر و / أو مستهلك الرسائل المرسلة عبر الأرنب
" SYSTEM " - مجموعة من الأنظمة الفرعية ، وهي عبارة عن حل برمجي واحد للأجهزة تستخدمه الشركة ، وتتميز بالتوزيع في جميع أنحاء روسيا ، ولكن مع العديد من المراكز حيث تتدفق جميع المعلومات وحيث تجري الحسابات والحسابات الرئيسية.
SYSTEM - نظام موزع جغرافيا - من خاباروفسك وفلاديفوستوك إلى سانت بطرسبرغ وكراسنودار. معماريا ، هذه هي العديد من ملامح المركزية ، مقسوما على ميزات النظم الفرعية المتصلة بها.

ما هي مهمة النقل في واقع الاتصالات؟

باختصار: تتبع استجابة الأنظمة الفرعية لإجراءات كل مشترك ، والتي بدورها تُعلم النظم الفرعية الأخرى عن الأحداث والتغييرات اللاحقة. يتم إنشاء الرسائل من خلال أي إجراءات مع SYSTEM ، ليس فقط من المشتركين ، ولكن أيضًا من جانب موظفي الشركة ومن النظم الفرعية (يتم تنفيذ عدد كبير جدًا من المهام تلقائيًا).

ميزات النقل في الاتصالات: كبيرة ، لا خطأ ، دفق كبير من البيانات المتنوعة المنقولة عبر النقل غير المتزامن.

تعيش بعض الأنظمة الفرعية على مجموعات منفصلة بسبب ثقل تدفقات الرسائل - ببساطة لا توجد موارد متبقية على نظام المجموعة ، على سبيل المثال ، مع تدفق الرسائل من 5-6 ألف رسالة في الثانية ، يمكن أن تصل كمية البيانات المنقولة إلى 170-190 ميغابايت / ثانية. باستخدام ملف تعريف التحميل هذا ، ستؤدي محاولة الهبوط على أي شخص آخر في هذه المجموعة إلى عواقب محزنة: نظرًا لعدم توفر موارد كافية لمعالجة جميع البيانات في نفس الوقت ، سيبدأ الأرنب في دفع الاتصالات الواردة إلى التدفق - ستبدأ عملية نشر بسيطة ، مع كل العواقب المترتبة على جميع الأنظمة الفرعية والنظام في كله.

المتطلبات الأساسية للنقل:

1. يجب أن يكون الوصول إلى المركبات 99.99 ٪. في الممارسة العملية ، يترجم هذا إلى متطلبات تشغيلية على مدار الساعة وطوال أيام الأسبوع والقدرة على الاستجابة تلقائيًا لأي حالات طوارئ.
2. سلامة البيانات: النسبة المئوية للرسائل المفقودة عند النقل يجب أن تميل إلى 0

على سبيل المثال ، عند إجراء مكالمة ، تنتقل عدة رسائل مختلفة عبر النقل غير المتزامن. بعض الرسائل مخصصة للأنظمة الفرعية التي تعيش في نفس الدائرة ، والبعض الآخر مخصص للإرسال إلى العقد المركزية. يمكن المطالبة بالرسالة نفسها بواسطة عدة أنظمة فرعية ، وبالتالي ، في مرحلة نشر الرسالة في الأرنب ، يتم نسخها وإرسالها إلى مستهلكين مختلفين. وفي بعض الحالات ، يتم تنفيذ نسخ الرسائل بشكل إجباري على دارة وسيطة - عندما تحتاج إلى تسليم المعلومات من الدائرة في خاباروفسك إلى الدائرة في كراسنودار. يتم الإرسال من خلال أحد الخطوط الكنتورية المركزية ، حيث يتم عمل نسخ من الرسائل ، للمستلمين المركزيين.

بالإضافة إلى الأحداث الناتجة عن تصرفات المشترك ، تمر رسائل الخدمة التي تتبادل الأنظمة الفرعية بالنقل. وبالتالي ، يتم الحصول على عدة آلاف من طرق المراسلة المختلفة ، بعضها متقاطع ، بعضها موجود بمعزل عن غيره. يكفي تسمية عدد من قوائم الانتظار المشاركة في المسارات الموجودة على خطوط كونتور مختلفة لفهم الحجم التقريبي لخريطة النقل: على الدوائر المركزية 600 و 200 و 260 و 15 ... وعلى الدوائر البعيدة 80-100 ...

مع هذه المشاركة في النقل ، لم تعد متطلبات إمكانية الوصول بنسبة 100٪ لجميع عقد النقل مفرطة. نحن ننتقل إلى تنفيذ هذه المتطلبات.

كيف نحل المهام

بالإضافة إلى RabbitMQ نفسها ، يتم استخدام Haproxy لموازنة الحمل وتوفير استجابة تلقائية لحالات الطوارئ.

بعض الكلمات عن بيئة الأجهزة والبرامج التي توجد فيها أرانبنا:

• جميع خوادم الأرنب افتراضية ، مع المعلمات من 8-12 وحدة المعالجة المركزية ، 16 جيجابايت غيغابايت ، 200 غيغابايت الأقراص الصلبة. كما أوضحت التجربة ، حتى استخدام الخوادم غير الافتراضية الزاحفة مع 90 مركزًا ومجموعة من ذاكرة الوصول العشوائي يوفر دفعة أداء صغيرة بتكلفة أعلى بكثير. الإصدارات المستخدمة: 3.6.6 (في الممارسة العملية - الأكثر استقرارًا من 3.6) مع إرلانغ من 18.3 ، 3.7.6 مع إرلانج من 20.1.
• بالنسبة إلى Haproxy ، تكون المتطلبات أقل بكثير: 2 وحدة المعالجة المركزية ، و 4 جيجا بايت Mem ، إصدار haproxy 1.8 مستقر. لا يتجاوز التحميل على الموارد على كافة خوادم haproxy 15٪ ​​CPU / Mem.
• تقع حديقة الحيوان بأكملها في 14 مركز بيانات في 7 مواقع في جميع أنحاء البلاد ، متحدة في شبكة واحدة. يوجد في كل مركز من مراكز البيانات مجموعة من ثلاث نقاط ومحور واحد.
• بالنسبة للدوائر البعيدة ، يتم استخدام مركزين للبيانات ، لكل دائرة من الدوائر المركزية - 4.
• تتفاعل الدوائر المركزية مع بعضها البعض وكذلك مع الدوائر البعيدة ؛ وبدورها ، تعمل الدوائر عن بُعد فقط مع الدوائر المركزية ؛ ولا يوجد لديها اتصال مباشر مع بعضها البعض.
• تكوينات Haps و Clusters داخل نفس الدائرة متطابقة تمامًا. نقطة الدخول لكل دائرة هي اسم مستعار لسجلات A-DNS متعددة. وبالتالي ، لمنع حدوث ذلك ، ستكون هناك نقطة واحدة على الأقل وواحدة على الأقل من المجموعات (عقدة واحدة على الأقل في المجموعة) في كل دائرة. نظرًا لأن حالة فشل حتى 6 خوادم في مركزين للبيانات في الوقت نفسه أمر مستبعد للغاية ، فمن المفترض أن تكون المقبولية قريبة من 100٪.

يبدو مفهوما (وتنفيذها) كل هذا مثل هذا:





الآن بعض التكوينات.


يصف القسم الأول من المقدمة نقطة الدخول - المؤدية إلى المجموعة الرئيسية ، تم تصميم القسم الثاني لموازنة مستوى الاحتياطي. إذا وصفت ببساطة جميع خوادم الأرنب الاحتياطية في قسم الواجهة الخلفية (تعليمات النسخ الاحتياطي) ، فسوف تعمل بنفس الطريقة - إذا كانت المجموعة الرئيسية غير قابلة للوصول تمامًا ، فستذهب الاتصالات إلى النسخة الاحتياطية ، ومع ذلك ، ستذهب جميع الاتصالات إلى خادم النسخ الاحتياطي الأول في القائمة. لضمان موازنة التحميل على جميع عقد النسخ الاحتياطي ، نقدم فقط واجهة واحدة أخرى ، والتي نوفرها فقط مع المضيف المحلي ، ونقوم بتعيين خادم النسخ الاحتياطي عليه.

يصف المثال أعلاه موازنة Loop عن بُعد - والتي تعمل داخل مركزين للبيانات: خادم srv-rmq {01،03،05} - مباشر في مركز البيانات رقم 1 ، srv-rmq {02،04،06} - في مركز البيانات رقم 2. وبالتالي ، لتنفيذ الحل الذي يحتوي على أربعة صودا ، نحتاج فقط إلى إضافة جبهتين محليتين وقسمين خلفيين لخوادم الأرانب المقابلة.

سلوك الموازن مع هذا التكوين كما يلي: على الرغم من وجود خادم رئيسي واحد على الأقل قيد الحياة ، فإننا نستخدمه. إذا كانت الخوادم الرئيسية غير متوفرة ، فإننا نعمل مع احتياطي. في حالة توفر خادم أساسي واحد على الأقل ، يتم قطع اتصال جميع الاتصالات بخوادم النسخ الاحتياطي ، وعندما تتم استعادة الاتصال ، فإنها تقع بالفعل على نظام المجموعة الأساسي.

تُظهر تجربة التشغيل لمثل هذا التكوين توفرًا بنسبة 100٪ تقريبًا لكل دائرة. يتطلب هذا الحل أن تكون النظم الفرعية قانونية وبسيطة تمامًا: لتكون قادرًا على إعادة الاتصال بالأرنب بعد قطع الاتصال.

لذلك ، لقد قدمنا ​​موازنة تحميل لعدد تعسفي من المجموعات والتبديل التلقائي بينهما ، فقد حان الوقت للذهاب مباشرة إلى الأرانب.

يتم إنشاء كل مجموعة من ثلاث نقاط ، كما يظهر من خلال الممارسة - العدد الأمثل للعقد ، والذي يضمن التوازن الأمثل للتيسر / التسامح مع الخطأ / السرعة. نظرًا لأن الأرنب لا يتم قياسه أفقيًا (أداء الكتلة يساوي أداء الخادم الأبطأ) ، فنحن ننشئ كل العقد بنفس المعلمات المثالية لوحدة المعالجة المركزية / Mem / Hdd. نحن نضع الخوادم على مقربة من بعضها البعض قدر الإمكان - في حالتنا ، نقوم بإيداع أجهزة افتراضية داخل المزرعة نفسها.

بالنسبة للشروط المسبقة ، والتي من خلالها ستضمن الأنظمة الفرعية العملية الأكثر استقرارًا والوفاء بمتطلبات حفظ الرسائل المستلمة:

1. العمل مع الأرنب يكون فقط عبر بروتوكول amqp / amqps - من خلال الموازنة. إذن تحت الحسابات المحلية - داخل كل مجموعة (حسنا ، والدائرة بأكملها)
2. ترتبط الأنظمة الفرعية بالأرنب في الوضع السلبي: لا يُسمح بأي معاملات مع كيانات الأرانب (إنشاء قوائم انتظار / eschendzhey / bind) ومحدودة على مستوى حقوق الحساب - نحن ببساطة لا نعطي حقوقًا للتكوين.
3. يتم إنشاء جميع الكيانات اللازمة مركزيا ، وليس عن طريق النظم الفرعية ، ويتم عمل كل مجموعات الكتل بالطريقة نفسها - لضمان التبديل التلقائي إلى الكتلة الاحتياطية والعكس. خلاف ذلك ، يمكننا الحصول على صورة: لقد تحولنا إلى الاحتياطي ، ولكن قائمة الانتظار أو الربط غير موجود ، ويمكننا الحصول على اختيار خطأ في الاتصال أو فقدان الرسائل.

الآن الإعدادات مباشرة على الأرانب:

1. لا يمكن للمضيفين المحليين الوصول إلى واجهة الويب
2. يتم تنظيم الوصول إلى الويب من خلال LDAP - نحن ندمج مع م ونحصل على تسجيل من وأين دخلت كاميرا الويب. على مستوى التكوين ، نقيد حقوق حسابات الإعلانات ، ليس فقط أننا نطلب أن نكون في مجموعة معينة ، ولكننا نعطي حقوقًا فقط "للرؤية". مجموعات الرصد أكثر من كافية. ونعلق حقوق المسؤول على مجموعة أخرى في م ، وبالتالي فإن دائرة التأثير على وسائل النقل محدودة للغاية.
3. لتسهيل الإدارة والتتبع:
   على جميع VHOSTs ، نعلق على الفور سياسة المستوى 0 مع تطبيق على جميع قوائم الانتظار (النمط:. *):
   
   
   • ha-mode: الكل - تخزين جميع البيانات على جميع عقد المجموعة ، وتناقص سرعة معالجة الرسائل ، ولكن يتم ضمان سلامتها وتوافرها.
   • ha-sync-mode: تلقائي - يرشد الزاحف لمزامنة البيانات تلقائيًا على جميع عقد المجموعة: تزداد أيضًا سلامة البيانات وتوافرها.
   • طابور - الوضع: كسول - ربما واحدة من أكثر الخيارات المفيدة التي ظهرت في الأرانب منذ الإصدار 3.6 - تسجيل فوري للرسائل على الأقراص الصلبة. هذا الخيار يقلل بشكل كبير من استهلاك ذاكرة الوصول العشوائي ويزيد من سلامة البيانات أثناء توقف / سقوط العقد أو الكتلة ككل.
   
   
4. الإعدادات في ملف التكوين ( rabbitmq-main / conf / rabbitmq.config ):
   
   
   • قسم الأرانب : {vm_memory_high_watermark_paging_ratio ، 0.5} - الحد الأدنى لتنزيل الرسائل على القرص بنسبة 50٪. عند تشغيل الكسل ، يصبح التأمين أكثر عندما نرسم بوليصة ، على سبيل المثال ، المستوى 1 ، ننسى فيه تضمين الكسل .
   • {vm_memory_high_watermark، 0.95} - نقصر الأرنب على 95٪ من إجمالي ذاكرة الوصول العشوائي ، نظرًا لأن الأرانب فقط تعيش على الخوادم ، ليس من المنطقي إدخال قيود أكثر صرامة. 5 ٪ "لفتة واسعة" فليكن - اترك نظام التشغيل والمراقبة وغيرها من الأشياء الصغيرة المفيدة. نظرًا لأن هذه القيمة هي الحد الأعلى ، يوجد ما يكفي للجميع.
   • {cluster_partition_handling، pause_minority} - يصف سلوك الكتلة عند حدوث "قسم الشبكة" ، لثلاث أو أكثر من مجموعات العقدة التي ينصح بها هذه العلامة - إنها تسمح للكتلة باسترداد نفسها.
   • {disk_free_limit ، "500 ميجابايت") - كل شيء بسيط ، عندما يكون هناك مساحة خالية على القرص 500 ميجابايت - سيتم إيقاف نشر الرسائل ، ولن يتوفر الطرح إلا.
   • {auth_backends ، [rabbit_auth_backend_internal، rabbit_auth_backend_ldap]} - ترتيب التفويض للأرانب: أولاً ، يتم فحص وجود الموجات فوق الصوتية في قاعدة البيانات المحلية ، وإذا لم يكن الأمر كذلك ، فانتقل إلى خادم LDAP.
   • قسم rabbitmq_auth_backend_ldap - التكوين للتفاعل مع AD: {servers، ["srv_dc1"، "srv_dc2"]} - قائمة بوحدات التحكم بالمجال التي ستتم المصادقة عليها.
   • المعلمات التي تصف المستخدم مباشرة في م ، ومنفذ LDAP وما إلى ذلك هي فردية بحتة ويتم وصفها بالتفصيل في الوثائق.
   • أهم شيء بالنسبة لنا هو وصف الحقوق والقيود المفروضة على الإدارة والوصول إلى واجهة الويب للأرانب: tag_queries:
     [{admin، {in_group، "cn = rabbitmq-admins، ou = GRP، ou = GRP_MAIN، dc = My_domain، dc = ru"}}،
     {الرصد ،
     {in_group، "cn = rabbitmq-web، ou = GRP، ou = GRP_MAIN، dc = My_domain، dc = ru"}
     }] - يوفر هذا التصميم امتيازات إدارية لجميع مستخدمي مجموعة rabbitmq-admins وحقوق المراقبة (كافية كحد أدنى لعرض الوصول) لمجموعة rabbitmq-web.
     
   • resource_access_query :
     {من أجل ،
     [{إذن ، تكوين ، {in_group ، "cn = rabbitmq-admins ، ou = GRP ، ou = GRP_MAIN ، dc = My_domain ، dc = ru"}} ،
     {إذن ، كتابة ، {in_group ، "cn = rabbitmq-admins ، ou = GRP ، ou = GRP_MAIN ، dc = My_domain، dc = ru"}}،
     {إذن ، قراءة ، {ثابت ، صحيح}}
     ]
     } - نحن نوفر حقوق التكوين والكتابة فقط لمجموعة من المسؤولين ، ولكل شخص آخر قام بتسجيل الدخول بنجاح ، تكون الحقوق للقراءة فقط - يمكنه قراءة الرسائل من خلال واجهة الويب.
     

نحصل على مجموعة (على مستوى ملف التكوين والإعدادات في الأرنب نفسه) التي تزيد من توافر وسلامة البيانات. بهذا ننفذ المتطلب - ضمان توافر وسلامة البيانات ... في معظم الحالات.

هناك العديد من النقاط التي يجب مراعاتها عند تشغيل هذه الأنظمة المحملة للغاية:

1. من الأفضل تنظيم جميع خصائص قوائم الانتظار الإضافية (TTL ، أو انتهاء الصلاحية ، أو الحد الأقصى للطول ، وما إلى ذلك) بواسطة السياسيين ، بدلاً من تعليق المعلمات عند إنشاء قوائم الانتظار. لقد ظهر هيكل قابل للتخصيص بمرونة يمكن تخصيصه سريعًا لتغير الحقائق.
2. باستخدام TTL. أطول قائمة الانتظار ، وارتفاع الحمل على وحدة المعالجة المركزية. لمنع "اختراق السقف" ، من الأفضل تحديد طول قائمة الانتظار عبر الحد الأقصى للطول أيضًا.
3. بالإضافة إلى الأرنب نفسه ، هناك عدد من تطبيقات الأدوات المساعدة تدور على الخادم ، الأمر الذي يتطلب بشكل غير طبيعي موارد وحدة المعالجة المركزية. يأخذ الأرنب الشرابي ، افتراضيًا ، جميع النوى المتاحة ... قد يتحول وضع غير سارة: صراع على الموارد ، يمكن أن يؤدي بسهولة إلى كبح الأرنب. لتجنب حدوث مثل هذا الموقف ، على سبيل المثال ، على النحو التالي: تغيير معلمات إطلاق erlang - أدخل حدًا إلزاميًا على عدد النوى المستخدمة. نقوم بذلك على النحو التالي: ابحث عن ملف rabbitmq-env ، وابحث عن SERVER_ERL_ARGS = المعلمة وأضف + sct L0-Xc0-X + SY: Y إليه. حيث X هو عدد النوى -1 (يبدأ العد من 0) ، Y - عدد النوى -1 (العد من 1). + sct L0-Xc0-X - يغير الربط إلى النواة ، + SY: Y - يغير عدد shedulers التي أطلقتها erlang. لذلك بالنسبة لنظام مكون من 8 نوى ، ستتخذ المعلمات المضافة الشكل: + sct L0-6c0-6 + S 7: 7. وبهذه الطريقة ، لا نقدم للأرنب سوى 7 نوى ونتوقع أن يعمل نظام التشغيل ، عن طريق إطلاق عمليات أخرى ، على النحو الأمثل ويعلقها على نواة غير محملة.

الفروق الدقيقة في تشغيل حديقة الحيوان الناتجة

ما لا يمكن حماية أي إعداد منه هو القاعدة المنهارة - لسوء الحظ ، يحدث ذلك باحتمال غير صفري. هذه النتيجة الكارثية لا تنتج عن الفشل العالمي (على سبيل المثال ، الفشل الكامل لمركز البيانات بأكمله - الحمل سيتحول ببساطة إلى كتلة أخرى) ، ولكن المزيد من الإخفاقات المحلية - داخل نفس قطاع الشبكة.

علاوة على ذلك ، فإن إخفاقات الشبكة المحلية مخيفة لأن لن يؤدي الإغلاق الطارئ لعقد أو عقدتين إلى عواقب وخيمة - ببساطة ستذهب جميع الطلبات إلى عقدة واحدة ، وكما نتذكر ، يعتمد الأداء على أداء العقدة نفسها فقط. تؤدي حالات فشل الشبكة (لا نأخذ في الاعتبار الانقطاعات الصغيرة في الاتصالات - حيث تتم مواجهتها دون ألم) إلى وضع تبدأ فيه العقد في عملية المزامنة مع بعضها البعض ثم ينقطع الاتصال مرارًا وتكرارًا لبضع ثوان.

على سبيل المثال ، وميض متعددة للشبكة ، وبتردد أكثر من 5 ثوان (فقط تم تعيين مهلة كهذه في إعدادات Hapov ، يمكنك بالتأكيد تشغيلها ، ولكن للتحقق من الفعالية ستحتاج إلى تكرار الفشل ، الذي لا يريده أحد).

لا يزال بإمكان المجموعة الصمود أمام واحد أو اثنين من هذه التكرارات ، لكن أكثر من ذلك - فالفرص ضئيلة للغاية. في مثل هذه الحالة ، يمكن حفظ نقطة توقف للعقدة الساقطة ، لكن يكاد يكون من المستحيل القيام بذلك يدويًا. في كثير من الأحيان ، فإن النتيجة ليست مجرد فقدان عقدة من الكتلة مع الرسالة "Network Partition" ، ولكن أيضًا الصورة عندما عاشت البيانات الموجودة على قوائم الانتظار هذه العقدة فقط ولم يكن لديها وقت للمزامنة مع باقيها. بصريا - في بيانات قائمة الانتظار NaN .

والآن هذه إشارة لا لبس فيها - قم بالتبديل إلى الكتلة الاحتياطية. التبديل سيوفر hap ، تحتاج فقط إلى إيقاف الأرانب على الكتلة الرئيسية - مسألة عدة دقائق. نتيجة لذلك ، نحصل على استعادة القدرة التشغيلية للنقل ويمكننا المضي قدما بأمان في تحليل الحادث والقضاء عليه.

من أجل إزالة كتلة تالفة من تحت الحمل ، من أجل منع المزيد من التدهور ، فإن أبسط شيء هو جعل الأرانب تعمل على موانئ أخرى غير 5672. بما أننا نراقب الأرانب عن طريق المنفذ العادي ، ونزوحه ، على سبيل المثال ، بحلول 5673 في إعدادات الأرنب ، سيسمح لك بتشغيل المجموعة بالكامل دون ألم ومحاولة استعادة قابلية التشغيل والرسائل المتبقية عليه.

نحن نفعل ذلك في بضع خطوات:

1. أوقف جميع عقد المجموعة الفاشلة - يقوم hap بتبديل الحمل إلى نظام مجموعة النسخ الاحتياطي
2. RABBITMQ_NODE_PORT=5673 rabbitmq-env – , Web - 15672.
3. .

. , , – msg_store_persistent , msg_store_transient , queues ( 3.6) msg_stores ( 3.7).

, .

( ): , .

rpm, cpio ( ) . : / root, ( tgz) . ( – , ). RabbitMQ – – .

cpio : rabbitmq-base ( – mnesia) rabbimq-main – .

rabbimq-main/bin – ( ).

rabbimq-main/init.d – rabbitmq-server // ; lib – ; lib64 – erlang ( , , ).

– rabbimq-main/lib rabbimq-main/lib64 bin. – .

– – , , , .

, , — ( ). 99% , kill , .

3.6 3.7 .





لقد أنشأنا حسابًا crontab يعمل بموجبه الأرنب (افتراضيًا rabbitmq) الذي ينفذ هذا البرنامج النصي (اسم البرنامج النصي: check_and_run) كل دقيقة (أولاً ، نطلب من المسؤول منح الحساب الحق في استخدام crontab ، ولكن إذا كان لدينا حقوق الجذر ، فنحن نفعل ذلك بأنفسنا):
* / 1 * * * * ~ / rabbitmq-main / bin / check_and_run

النقطة الثانية في استخدام الأرانب المعاد تجميعها هي دوران السجلات.

نظرًا لأننا لسنا مرتبطين بنظام logrotate ، فإننا نستخدم الوظائف التي يوفرها المطور: البرنامج النصي rabbitmq-server من init.d (للإصدار 3.6)
بإجراء تغييرات صغيرة على rotate_logs_rabbitmq ()
أضف:

  find ${RABBITMQ_LOG_BASE}/http_api/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.log.*.back -maxdepth 0 -type f | xargs -i gzip {} find ${RABBITMQ_LOG_BASE}/*.gz -type f -mtime +30 -delete find ${RABBITMQ_LOG_BASE}/http_api/*.gz -type f -mtime +30 -delete 

نتيجة تشغيل البرنامج النصي rabbitmq-server باستخدام سجلات تدوير المفتاح: يتم ضغط السجلات بواسطة gzip ، ويتم تخزينها فقط لمدة 30 يومًا الماضية. http_api - المسار الذي يضع فيه الأرنب السجلات http - المكوّنة في ملف التكوين: {rabbitmq_management ، [{rates_mode ، مفصلة} ، {http_log_dir ، path_to_logs / http_api "}]}

في الوقت نفسه ، أُولي اهتمامًا لـ {rates_mode ، مفصلة } - الخيار يزيد الحمل بشكل طفيف ، لكنه يسمح لك بمشاهدة المعلومات حول من الذي ينشر الرسائل في EXCHENGE على واجهة WEB (وبالتالي يمكنك الوصول إلى واجهة برمجة التطبيقات). المعلومات ضرورية للغاية ، لأن جميع الاتصالات تذهب من خلال الموازن - سنرى فقط IP للموازنات أنفسهم. وإذا كنت تتغلب على جميع الأنظمة الفرعية التي تعمل مع الأرانب حتى تملأ معلمات خصائص العميل في خصائص اتصالاتهم بالأرانب ، فسيكون من الممكن الحصول على معلومات مفصلة على مستوى الاتصال من بالضبط ، وأين وبكثافة ما تنشر الرسائل.

مع إصدار الإصدارات الجديدة 3.7 ، كان هناك رفض كامل للبرنامج النصي rabbimq-server في init.d. من أجل تسهيل التشغيل (توحيد أوامر التحكم بغض النظر عن إصدار الأرنب) وانتقال أكثر سلاسة بين الإصدارات ، في الأرانب المعاد تجميعها ، نواصل استخدام هذا البرنامج النصي. الحقيقة مرة أخرى: سنعمل على تغيير rotate_logs_rabbitmq () قليلاً ، نظرًا لأن آلية تسمية السجلات بعد التدوير قد تغيرت في 3.7:

  mv ${RABBITMQ_LOG_BASE}/$NODENAME.log.0 ${RABBITMQ_LOG_BASE}/$NODENAME.log.$(date +%Y%m%d-%H%M%S).back mv ${RABBITMQ_LOG_BASE}/$(echo $NODENAME)_upgrade.log.0 ${RABBITMQ_LOG_BASE}/$(echo $NODENAME)_upgrade.log.$(date +%Y%m%d-%H%M%S).back find ${RABBITMQ_LOG_BASE}/http_api/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.log.* -maxdepth 0 -type f ! -name "*.gz" | xargs -i gzip --force {} find ${RABBITMQ_LOG_BASE}/*.gz -type f -mtime +30 -delete find ${RABBITMQ_LOG_BASE}/http_api/*.gz -type f -mtime +30 -delete 

الآن يبقى فقط إضافة مهمة تدوير السجل إلى crontab - على سبيل المثال ، كل يوم في 23-00:
00 23 * * * ~ / rabbitmq-main / init.d / rabbitmq-server تدوير سجلات

دعنا ننتقل إلى المهام التي تحتاج إلى حل في إطار تشغيل "مزرعة الأرانب":

1. التلاعب مع الكيانات الأرانب - إنشاء / حذف الكيانات الأرانب: ekschendzhey ، قوائم الانتظار ، يربط ، معاول ، المستخدمين ، والسياسات. وللقيام بذلك ، يكون الأمر متطابقًا تمامًا في جميع المجموعات العنقودية.
2. بعد التبديل إلى / من الكتلة الاحتياطية ، يلزم نقل الرسائل التي بقيت عليها إلى الكتلة الحالية.
3. إنشاء نسخ احتياطية من تكوينات جميع المجموعات من جميع الدوائر
4. تزامن كامل لتكوينات الكتل داخل الكنتور
5. وقف / بدء الأرانب
6. لتحليل تدفقات البيانات الحالية: نفذ كل الرسائل وإذا كانت تذهب ، فأين يجب أن تذهب أو ...
7. البحث عن الرسائل التي تم اجتيازها بأي معايير

من الممكن تشغيل حديقة الحيوان الخاصة بنا وحل المهام التي يتم التعبير عنها عن طريق المكوّن الإضافي المنتظم لـ rabbitmq_management ، ولكنه غير مريح للغاية ، ولهذا السبب تم تطوير وتنفيذ قذيفة للسيطرة على مجموعة كاملة من الأرانب .