التوافرية العالية: HAProxy وKeepalived وPacemaker وCorosync
خروج

الدرس 1 من 12 · الأساسيات

تقدير التوافرية بالأرقام: SLA وMTTR وRTO وRPO ونقاط الفشل الوحيدة

40 د Debian 12 الإصدارات Debian 12, Rocky 9, Ubuntu 24.04

الهدف

قبل تثبيت HAProxy أو Pacemaker، يجب أن تعرف ما الذي عليك ضمانه: قياس التوافرية الفعلية لخدمة، وفهم ما يُنقصها، وتحديد المكوّنات التي يوقف عطلها كل شيء.

أهم النقاط

  • تُحسب التوافرية (availability) انطلاقًا من الحوادث الحقيقية، وفق قواعد العقد (ما هو مستثنى، وكيف يتم القياس).
  • A = MTBF ÷ (MTBF + MTTR): تربح بـالإصلاح الأسرع (MTTR) بقدر ما تربح بقلّة الأعطال (MTBF).
  • يُترجَم RTO (مدة التوقف المقبولة) وRPO (البيانات المقبول فقدانها) مباشرة إلى تقنيات: تحويل تلقائي أو يدوي، نسخ متماثل متزامن أو غير متزامن، نسخ احتياطي.
  • نقطة الفشل الوحيدة (SPOF) هي كل عنصر موجود بنسخة واحدة على مسار طلب: خادم، ولكن أيضًا مبدّل شبكي (switch)، أو مزوّد طاقة، أو شهادة، أو مسؤول نظام.
  • إضافة التكرار (redundancy) تضيف تعقيدًا: كل آلية تحويل تصبح هي نفسها مصدرًا للأعطال إن لم تُختبر.

الأساسيات (جدول «التسعات»، SLA مزوّد السحابة، قاعدة 3-2-1) موجودة في دورة أساسيات السحابة؛ وSLO وميزانية الأخطاء في دورة المراقبة (Observability). هنا ننتقل إلى الحساب على منصة تديرها بنفسك.

1. قياس التوافرية وفق تعريف العقد

يحدّد عقد مستوى الخدمة (SLA) دائمًا:

البند مثال الأثر على الحساب
فترة القياس شهر ميلادي 30 يومًا = 43200 دقيقة، 31 يومًا = 44640 دقيقة
الاستثناءات صيانة معلنة قبل 48 ساعة، قوة قاهرة هذه الدقائق لا تُحسب
تعريف «غير متاح» الصفحة الرئيسية لا تجيب في أقل من 5 ثوانٍ من مسبارين قد يُحسب البطء عطلًا
الغرامة تخفيض 10% تحت 99.9%، و25% تحت 99% كلفة تجاوز الهدف

الحساب انطلاقًا من سجل الحوادث:

# date;type;minutes;description
awk -F';' '$2=="imprevu" {s += $3} END {printf "%.2f %%\n", 100 * (1 - s/43200)}' incidents.csv

الرقم «التعاقدي» ليس ما عاشه الزبناء: صيانة مبرمجة لمدة ساعة مساء يوم سبت لا تُحسب في SLA، لكن المتجر كان مغلقًا فعلًا. تابِع الرقمين معًا: التوافرية التعاقدية (للغرامات) والتوافرية الفعلية (لاتخاذ قرارات الاستثمار).

2. MTBF وMTTR: الإصلاح السريع مهم بقدر عدم التعطل

  • MTBF (mean time between failures): متوسط الوقت بين عطلين.
  • MTTR (mean time to repair/restore): متوسط الوقت اللازم لاستعادة الخدمة.
A = MTBF / (MTBF + MTTR)

عطل واحد في الشهر (MTBF ≈ 720 h) يُصلَح في 4 h  : 720 / 724   = 99,45 %
نفس العطل يُصلَح في 30 min                       : 720 / 720,5 = 99,93 %

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

3. RTO وRPO: من الحاجة المهنية إلى التقنية

الحاجة المعبَّر عنها RTO RPO الجواب التقني المعتاد
«يمكن للموقع التعريفي أن ينتظر إلى الغد» 24 h 24 h نسخة احتياطية ليلية، استرجاع يدوي
«يجب ألا يُغلق المتجر أكثر من 15 دقيقة» 15 min 5 min خادمان، تحويل يدوي موجَّه، نسخ متماثل غير متزامن
«يجب ألا تضيع أي عملية دفع» 1 min 0 عنقود (cluster) بتحويل تلقائي، نسخ متماثل متزامن، fencing

نقاط يجب تذكّرها:

  • RPO = 0 يتطلّب نسخًا متماثلًا متزامنًا (DRBD بالبروتوكول C، أو synchronous_commit في PostgreSQL): كل عملية كتابة تنتظر الخادم الثاني، فيرتفع زمن الاستجابة.
  • RPO الفعلي لنسخة احتياطية يومية هو 24 ساعة في أسوأ الحالات (عطل قبيل النسخة التالية)، وليس «بضع ساعات».
  • RTO الفعلي يُقاس خلال اختبار تحويل، والساعة في اليد. RTO لم يُختبر قطّ ليس إلا فرضية.

4. جرد نقاط الفشل الوحيدة

تتبَّع مسار طلب من الزبون إلى القرص، وسجّل كل مرحلة:

client ─► DNS ─► lien Internet ─► pare-feu ─► ml-lb-01 ─► ml-web-0[1-3] ─► ml-app-0[1-2] ─► ml-db-0[1-2]
                                                    │
                                              ml-nfs-01 (fichiers clients)

# Un inventaire simple : composant;rôle;exemplaires
awk -F';' 'NR > 1 && $3 == 1 {print "SPOF :", $1, "(" $2 ")"}' architecture.txt

نقاط الفشل الوحيدة الأكثر نسيانًا:

الفئة أمثلة
الشبكة مبدّل مركزي واحد، رابط واحد مع المشغّل، رابطان… لدى المشغّل نفسه
الكهرباء مزوّدا طاقة على نفس المقبس المتعدد، عاكس (UPS) واحد
الخدمات المشتركة DNS الداخلي، NTP، دليل LDAP، خادم NFS، مستودع الصور
العناصر المنطقية شهادة TLS، اسم نطاق ينتهي أجله، مفتاح ترخيص
العنصر البشري شخص واحد فقط يعرف الإجراء أو يملك صلاحيات الوصول

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

5. ثمن التكرار

مضاعفة مكوّن لا تضاعف الموثوقية إذا:

  • كانت النسختان تتقاسمان سببًا مشتركًا (نفس الخزانة، نفس الإصدار البرمجي المعيب، نفس الإعداد الخاطئ المنشور في كل مكان)؛
  • لم تُختبر آلية التحويل أبدًا؛
  • لم ينتبه أحد إلى أن إحدى النسختين معطّلة أصلًا (تكرار «نائم»: تكتشف عطل الثانية يوم تتعطل الأولى).

قاعدة استغلال: كل تكرار يجب أن يُراقَب. موزّع حمل يخدم الحركة بخادم واحد حيّ من أصل ثلاثة يجب أن يطلق تنبيهًا، حتى وإن لم يلاحظ الزبناء شيئًا.

حسب الإصدار

النقطة Debian 12 / Ubuntu 24.04 Rocky 9
حزم التوافرية العالية المستودع الرئيسي (haproxy، keepalived، pacemaker، pcs، drbd-utils) haproxy وkeepalived في AppStream؛ pacemaker وpcs في مستودع HighAvailability الذي يجب تفعيله (dnf config-manager --set-enabled highavailability)
أداة إدارة العنقود pcs أو crmsh pcs
وحدة DRBD حزمة drbd-utils + وحدة النواة (DRBD 9 عبر مستودع المشروع) مستودع ELRepo أو حزم المشروع

أخطاء متكررة

  • احتساب الصيانة المبرمجة في حساب SLA يستثنيها، أو العكس: اقرأ العقد قبل الحساب.
  • الخلط بين RPO وتواتر النسخ الاحتياطي: نسخة كل 24 ساعة تعطي RPO من 24 ساعة، لا 12 ساعة «في المتوسط».
  • نسيان التبعيات: خادما ويب متكرران يركّبان نفس خادم NFS الوحيد يبقيان رهينَين له.
  • الوعد بـ 99.99% (4 دقائق في الشهر) مع إجراء تحويل يدوي يستغرق 20 دقيقة.

التطبيق العملي (Lab)

على آلة Debian 12، يتوفّر لديك سجل حوادث شهر شتنبر لمتجر MasterLinux وجرد لبنيته. ستقوم بما يلي:

  1. حساب التوافرية وفق تعريف العقد؛
  2. تحديد ما إذا تحقّق SLA بنسبة 99.9%؛
  3. حساب MTTR؛
  4. استخراج قائمة نقاط الفشل الوحيدة؛
  5. إعطاء RPO الفعلي لنسخة احتياطية ليلية واحدة.

اختبار قصير

  1. لماذا يمكن لفريقين أن يعلنا توافريتين مختلفتين للشهر نفسه؟
  2. عطل واحد في الشهر يُصلَح في 30 دقيقة بدل 4 ساعات: أيّ مؤشر يتحسّن؟
  3. أيّ نسخ متماثل يلزم لـ RPO يساوي صفرًا، وما كلفته؟
  4. اذكر ثلاث نقاط فشل وحيدة ليست خوادم.
  5. ما هو التكرار «النائم» وكيف نتجنّبه؟
الأجوبة
  1. لأنهما لا يطبّقان القواعد نفسها: الاستثناءات (الصيانة المبرمجة)، وتعريف عدم التوفر، وفترة القياس.
  2. MTTR، وبالتالي التوافرية: A = MTBF ÷ (MTBF + MTTR) تنتقل من نحو 99.45% إلى 99.93%.
  3. نسخ متماثل متزامن (DRBD بالبروتوكول C، أو نسخة PostgreSQL متزامنة)؛ كل كتابة تنتظر تأكيد الخادم الثاني، فيرتفع زمن الاستجابة.
  4. مبدّل شبكي واحد، رابط مشغّل، مزوّد طاقة، شهادة TLS، اسم نطاق، DNS الداخلي، شخص واحد يعرف الإجراء.
  5. نسخة احتياطية معطّلة دون علم أحد؛ نتجنّبه بمراقبة كل عضو على حدة، لا الخدمة الإجمالية فقط.

تمارين تطبيقية

تُنجَز على Debian 12

أنجز هذا التطبيق العملي على جهازك

الطرفية طرفيتك: آلة افتراضية بنظام لينكس (VirtualBox أو VMware أو Hyper-V أو WSL…) أو Docker/Podman. أداة ml تحضّر التمرين وتصحّح عملك، ويُؤكَّد الدرس هنا تلقائيًا.

أنشئ حسابًا مجانيًا للحصول على أمرك الشخصي وتصحيح تطبيقاتك العملية تلقائيًا.

إنشاء حسابي

المهام المطلوبة

  1. عقد الخدمة (SLA) لمتجر MasterLinux يستثني عمليات الصيانة المبرمجة. انطلاقًا من الملف /root/ha/incidents.csv (شهر شتنبر، 30 يومًا)، احسب التوافرية وفق تعريف العقد واكتبها برقمين بعد الفاصلة (مثلًا 99.95) في /root/ha/dispo.txt.
    عرض تلميح30 يومًا = 43200 دقيقة. احسب فقط الأسطر «imprevu» (غير المبرمجة): 38 + 21 + 27.4.
    عرض الحل
    awk -F";" '$2=="imprevu"{s+=$3} END{printf "%.2f\n", 100*(1-s/43200)}' /root/ha/incidents.csv > /root/ha/dispo.txt

    التحقق : grep -Eqx " *99[.,]80 *%? *" /root/ha/dispo.txt

  2. يَعِد العقد بنسبة 99.9%. هل تحقّقت هذا الشهر؟ اكتب oui (نعم) أو non (لا) في /root/ha/sla.txt.
    عرض تلميحقارن نتيجتك بـ 99.90.
    عرض الحل
    echo non > /root/ha/sla.txt

    التحقق : grep -Eqix " *non *" /root/ha/sla.txt

  3. احسب متوسط زمن الاستعادة (MTTR) للحوادث غير المبرمجة بالدقائق، واكتب الرقم في /root/ha/mttr.txt.
    عرض تلميحMTTR = المدة الإجمالية للأعطال غير المبرمجة ÷ عدد هذه الأعطال.
    عرض الحل
    awk -F";" '$2=="imprevu"{s+=$3;n++} END{print s/n}' /root/ha/incidents.csv > /root/ha/mttr.txt

    التحقق : grep -Eqx " *28([.,]8)? *" /root/ha/mttr.txt

  4. في /root/ha/architecture.txt يعطي العمود الثالث عدد نسخ كل مكوّن. اكتب في /root/ha/spof.txt اسم كل نقطة فشل وحيدة، اسمًا في كل سطر.
    عرض تلميحالمكوّن الموجود بنسخة واحدة نقطة فشل وحيدة: awk -F';' '$3==1{print $1}'
    عرض الحل
    awk -F";" '$3==1{print $1}' /root/ha/architecture.txt > /root/ha/spof.txt

    التحقق : test -s /root/ha/spof.txt && test "$(tr -d ' \r' < /root/ha/spof.txt | grep -v '^$' | sort | paste -sd, -)" = "ml-lb,ml-nfs,sw-coeur"

  5. قاعدة البيانات بلا نسخة متماثلة (replica): نسخة احتياطية كاملة واحدة كل ليلة على الساعة 02:00. ما أقصى قدر ممكن من البيانات المفقودة بالساعات (RPO الفعلي)؟ اكتب الرقم في /root/ha/rpo.txt.
    عرض تلميحتخيّل العطل في أسوأ توقيت: قبيل النسخة الاحتياطية التالية مباشرة.
    عرض الحل
    echo 24 > /root/ha/rpo.txt

    التحقق : grep -Eqx " *24 *(h|heures)? *" /root/ha/rpo.txt