SafeKit: برنامج متكامل للتوافر العالي (SANless) وتجميع التطبيقات (Application Clustering)

يقضي SafeKit على الحاجة إلى المتطلبات التالية:

• أجهزة توزيع أحمال الشبكة أو خوادم الوكيل (Proxy) المخصصة.
• الأقراص المشتركة أو وحدات تخزين SAN المنسوخة.
• إصدارات المؤسسات (Enterprise) من أنظمة التشغيل وقواعد البيانات.
• مهارات متخصصة لصيانة الكليستر.

يقوم SafeKit بمعالجة:

• أعطال الأجهزة (20% من المشكلات): بما في ذلك الفشل الكامل لغرفة الكمبيوتر.
• أعطال البرامج (40% من المشكلات): بما في ذلك إعادة تشغيل العمليات الحيوية.
• الأخطاء البشرية (40% من المشكلات): وذلك بفضل سهولة استخدامه.

يمكنك تنفيذ النسخ المتماثل في الوقت الفعلي والانتقال التلقائي عند الفشل (failover) لـ:

• جميع أنواع التطبيقات، أدلة الملفات، والخدمات.
• قواعد البيانات.
• الأجهزة الافتراضية الكاملة (Hyper-V أو KVM).
• تطبيقات Docker وPodman والتطبيقات السحابية.

يوفر SafeKit المميزات التالية لأنظمة Windows وLinux في منتج برمج واحد:

• توزيع الأحمال (Load balancing)
• النسخ المتماثل المتزامن للملفات في الوقت الفعلي
• الانتقال التلقائي للفشل على مستوى التطبيق (Automatic failover)
• العودة التلقائية للحالة الطبيعية (Failback) بعد فشل الخادم

لا. إن SafeKit سهل النشر والاستخدام — ولا يتطلب خبرة تقنية متقدمة.

لا. يعمل SafeKit على خوادمك الحالية، أو الأجهزة الافتراضية، أو في السحاب — ولا يحتاج إلى أقراص مشتركة أو وحدات تخزين SAN.

لا. يعمل SafeKit مع إصدارات Windows وLinux القياسية (Standard) ولا يحتاج إلى تراخيص قواعد بيانات خاصة بإصدارات المؤسسات (Enterprise) المكلفة.

لأتمتة التعافي والقضاء على فترات التوقف، يجب أن يدير المنتج الشامل "الكل في واحد" عدة أجزاء تقنية متحركة في وقت واحد:

• النسخ المتماثل المستند إلى المضيف: نسخ متماثل متزامن وفي الوقت الفعلي لبيانات التطبيقات الحساسة بين الخوادم دون الاعتماد على التخزين المشترك (SAN). وهذا يضمن عدم فقدان أي بيانات (RPO=0) ويقضي على التبعية للأجهزة باهظة الثمن.
• عنوان البروتوكول الافتراضي (Virtual IP Address - VIP): يوفر هذا نقطة دخول واحدة للمستخدمين. عند حدوث فشل، يقوم البرنامج بنقل عنوان الـ VIP من العقدة الفاشلة إلى العقدة السليمة، بحيث لا يضطر المستخدمون إلى تغيير إعداداتهم.
• كواشف أخطاء الأجهزة والبرامج: يجب أن يقوم النظام بإرسال "نبضات قلب" (heartbeat) باستمرار لكل من الخادم الفعلي وعمليات برمجية محددة لتحديد أي تعليق أو تعطل فوري.
• برامج نصية لإعادة التشغيل قابلة للتخصيص: لا تبدأ جميع التطبيقات بنفس الطريقة. تسمح الأداة الشاملة باستخدام برامج نصية مخصصة لضمان بدء الخدمات المعقدة بالترتيب الصحيح.
• الانتقال التلقائي عند الفشل (Automatic Failover): الذكاء اللازم لتنظيم عملية الانتقال بأكملها من خادم إلى آخر دون تدخل بشري.

تتطلب العديد من الشركات المزودة "تجميع" عدة منتجات مختلفة معاً لتحقيق النسخ المتماثل المستند إلى المضيف، والانتقال عند الفشل (failover)، وتوزيع الأحمال. إن هذه البنية المجزأة تعد استراتيجية خطيرة للأنظمة الحساسة:

• تكامل هش: عندما تستخدم المنتج (A) للنسخ المتماثل والمنتج (B) لعمل المجموعات (clustering)، فإنك تبني "بيتاً من ورق". فكل تحديث لنظام التشغيل أو تصحيح أمني يخاطر بكسر رابط التواصل الهش بين هذه المحركات المنفصلة.
• عبء ذهني مرتفع وخطأ بشري: إن إدارة واجهات متعددة تزيد من مخاطر الأخطاء. وأثناء فشل النظام تحت الضغط العالي، يؤدي التنقل بين واجهات رسومية (GUI) مختلفة أو استخدام أوامر (CLI) متباينة لتشخيص مشكلة ما إلى الارتباك وإطالة فترة التوقف.
• تهرب الموردين من المسؤولية: إذا فشلت عملية الانتقال تلقائياً، فقد يلقي مورد برنامج النسخ باللوم على أداة الكليسترينج، مما يتركك عالقاً في المنتصف دون مسار واضح للحل. بينما يوفر الحل "الكل في واحد" نقطة مسؤولية واحدة.
• صيانة معقدة: تتطلب الأنظمة المجزأة مهارات متخصصة لكل مكون على حدة، مما يجعل صيانة الحل أصعب وأكثر تكلفة بكثير بمرور الوقت.

لا. إن نسخ البيانات هو ببساطة عملية نقل البيانات من الخادم (A) إلى الخادم (B). ورغم أهميته القصوى، فإن النسخ المتماثل بحد ذاته لا يوفر التوافر العالي. فبدون المكونات الأخرى لنظام الـ HA، يظل النسخ المتماثل مجرد "نسخة سلبية" تتطلب تدخلاً يدوياً طويلاً ومستهلكاً للوقت لكي تصبح مفيدة:

• إذا تعطل الخادم (A)، فإن برنامج نسخ البيانات لن يوجه المستخدمين تلقائياً إلى الخادم (B).
• لن يكتشف النظام أن التطبيق قد توقف عن العمل.
• لن يقوم النظام بإعادة تشغيل الخدمات تلقائياً.

تؤثر الطريقة التقنية المستخدمة في النسخ المتماثل المستند إلى المضيف بشكل كبير على مدى التغييرات التي يجب عليك إجراؤها في إعدادات تطبيقك الحالي.

• تحدي النسخ المتماثل على مستوى الكتلة (Block-Level): تعتمد معظم الحلول التي لا تستخدم شبكة تخزين (SANless) على النسخ المتماثل على مستوى القرص أو الكتلة. هذا النهج ليس شفافاً بالنسبة للتطبيق، إذ يتطلب منك إعادة تكوين التطبيق بالكامل لنقل بياناته إلى وحدة تخزين "قرص منسوخ" محددة وجديدة. غالباً ما يتضمن ذلك عمليات نقل معقدة وتغييرات محتملة في منطق عمل التطبيق.
• ميزة SafeKit على مستوى الملف (File-Level): يقوم SafeKit بـ النسخ المتماثل المستند إلى المضيف على مستوى الملف، وهو أمر شفاف تماماً بالنسبة للتطبيق. لا تحتاج إلى نقل البيانات إلى قرص خاص؛ بل تقوم ببساطة بتكوين SafeKit لنسخ مجلدات التطبيق الموجودة بالفعل. يمكن لهذه المجلدات أن تظل حتى على قرص النظام، مما يتيح لك حماية التطبيق في مكان تثبيته الأصلي تماماً.

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

1. إعادة مزامنة البيانات في الخلفية من العقدة النشطة إلى العقدة التي تم إصلاحها.
2. الحفاظ على استمرارية الخدمة: يجب أن تتم عملية إعادة المزامنة هذه دون مقاطعة التطبيق الذي يعمل حالياً على العقدة النشطة.
3. استعادة وضع الحماية (Redundancy): بمجرد اكتمال تطابق البيانات (mirroring) مرة أخرى، يعود الكليستر تلقائياً إلى حالة الحماية، ويكون جاهزاً لأي طارئ مستقبلي.

إذا كان مدير الانتقال عند الفشل وبرنامج نسخ البيانات منتجين منفصلين، فقد لا يكونان "متزامنين".

الخطر: إذا حدث انتقال عند الفشل (failover) قبل أن ينتهي النسخ المتماثل من إرسال آخر البيانات، فسيقوم الخادم (B) بتشغيل التطبيق ببيانات قديمة أو تالفة.

يضمن حل التوافر العالي (HA) الشامل وبدون شبكة تخزين (SANless) أن تكون آلية الانتقال عند الفشل على دراية تامة بحالة النسخ المتماثل. فهو لن يسمح للتطبيق بالبدء على العقدة الاحتياطية إلا إذا كانت البيانات مضمونة ومحدثة بالكامل، مما يمنع حدوث تعارض بين العقد النشطة وفقدان البيانات.

• تجاوز الفشل التلقائي لـ عنوان IP الافتراضي (Virtual IP) مع وجود عقدتين في نفس الشبكة الفرعية (Subnet).
• نطاق ترددي (Bandwidth) جيد لإعادة المزامنة (الخطوة 3) وزمن وصول (Latency) جيد لـ النسخ المتماثل المتزامن (عادةً ما يكون وقت الذهاب والإياب أقل من 2 مللي ثانية).

البديل

• استخدم موازن أحمال (Load Balancer) لعنوان IP الافتراضي إذا كانت العقدتان في شبكتين فرعيتين مختلفتين (يدعم SafeKit ذلك، خاصة في السحابة).
• استخدم حلول النسخ الاحتياطي مع النسخ المتماثل غير المتزامن لشبكات زمن الوصول العالي.

• يعمل كل جهاز افتراضي في وحدة مرآة (Mirror Module) مستقلة.
• الحد الأقصى هو 32 وحدة مرآة تعمل على نفس التجمع (Cluster).

البديل

• استخدم وحدة تخزين مشتركة خارجية وحلاً آخر لتجميع الأجهزة الافتراضية (VM clustering).
• أكثر تكلفة وأكثر تعقيداً.

• أداء وقت إعادة المزامنة بعد حدوث فشل (الخطوة 3).
• الوقت المستغرق لفحص كل ملف بين العقدتين (Nodes).

البديل

• ضع الملفات الكثيرة المراد نسخها في قرص صلب افتراضي أو جهاز افتراضي.
• في هذه الحالة، سيتم فقط نسخ وإعادة مزامنة الملفات التي تمثل القرص الصلب الافتراضي أو الجهاز الافتراضي.

وقت إعادة المزامنة بعد حدوث فشل (الخطوة 3)

• شبكة بسرعة 1 جيجابت/ثانية ≈ 3 ساعات لكل 1 تيرابايت.
• شبكة بسرعة 10 جيجابت/ثانية ≈ ساعة واحدة لكل 1 تيرابايت أو أقل، وذلك حسب أداء كتابة القرص.

البديل

• للأحجام الكبيرة من البيانات، استخدم وحدة تخزين مشتركة خارجية.
• تكون أكثر تكلفة وأكثر تعقيداً.

تقدم لوحة تحكم إدارة SafeKit رؤية موحدة للبنية التحتية الخاصة بالإتاحة العالية لديك. وهي تتيح للمسؤولين مراقبة الحالة التشغيلية للعنقودية وتتبع مزامنة البيانات في الوقت الفعلي.

بالنسبة لعنقودية مرآة مكونة من عقدتين (2-node)، تعرض لوحة التحكم بوضوح أدوار كل خادم:

• PRIM (الأساسي): العقدة النشطة التي تقوم حالياً بتشغيل التطبيق وإدارة عنوان IP الافتراضي. وتقوم بعمليات الكتابة على وحدة التخزين المحلية والنسخ المتماثل في الوقت الفعلي إلى العقدة الثانوية.
• SECOND (الثانوي): العقدة الاحتياطية (Standby) التي تستقبل التحديثات المتزامنة على مستوى البايت. وهي مستعدة لتولي المسؤولية فوراً في حال فشل الخادم الأساسي.
• حالة الانفراد (ALONE): تنبيه مرئي يخطرك عندما تعمل العنقودية على عقدة واحدة فقط (على سبيل المثال، أثناء الصيانة أو بعد حدوث فشل)، مما يشير إلى فقدان ميزة التكرار (Redundancy) مؤقتاً.
• تقدم إعادة المزامنة (Resynchronization): عند تعافي العقدة الفاشلة، تتحول حالتها إلى اللون البرتقالي أثناء إعادة دمج البيانات في الخلفية، مما يضمن عدم وجود أي فترة توقف عن العمل (Downtime) خلال مرحلة "العودة إلى الوضع الطبيعي".

إلى جانب أيقونات الحالة البسيطة، توفر الواجهة إمكانية تنظيم النقل عند الفشل بنقرة واحدة (One-click failover)، مما يسمح لك بإعادة تعيين الدور الأساسي يدوياً لإجراء الصيانة المخطط لها مع ضمان استمرارية الإتاحة لأنشطة المستخدمين.

توفر لوحة تحكم ويب SafeKit واجهة سهلة لتنظيم الإتاحة العالية لتطبيقاتك الحساسة والمهمة. في خطوات قليلة فقط، يمكنك تكوين عنقودية مرآة في SafeKit لضمان استمرارية الأعمال:

• النقل عند فشل التطبيق (علامة تبويب Macros): حدد خدمات التطبيق المعينة التي سيتم إعادة تشغيلها تلقائياً في حالة حدوث فشل.
• شبكة (شبكات) نبضات القلب (Heartbeat): مسار (مسارات) اتصال مخصصة تستخدمها عقد العنقودية (Nodes) لمراقبة سلامة وإتاحة بعضها البعض باستمرار، ومزامنة قرارات النقل عند الفشل.
• إدارة عنوان IP الافتراضي (Virtual IP): قم بإعداد عنوان IP الافتراضي (VIP) لضمان إعادة اتصال العملاء بسلاسة وشفافية بعد النقل عند الفشل.
• النسخ المتماثل في الوقت الفعلي: حدد الأدلة (Directories) الحساسة لإجراء نسخ متماثل متزامن على مستوى البايت ومستند إلى المضيف.
• أدوات الفحص (Checkers): راقب سلامة وحالة التطبيق وفعّل الاسترداد التلقائي في حال تم اكتشاف فشل في إحدى العمليات (Processes).

تتضمن عنقودية SafeKit أداة فحص مخصصة لمنع انقسام الدماغ (Split-brain checker) لحل مشكلات عزل الشبكة دون الحاجة إلى جهاز شاهد ثالث (Witness Machine) أو شبكة نبضات قلب إضافية. تعرف على المزيد حول نبضات القلب، والنقل عند الفشل، والنصاب القانوني (Quorum) في العنقودية.

توفر مراقبة المجموعة بأسلوب المزرعة رؤية واضحة لطبيعة البنية التحتية من نوع نشط-نشط (Active-Active)، حيث تساهم جميع العقد في أداء التطبيق (يظهر المثال هنا عقدتين):

• حالة التشغيل UP ‏(50% على عقدتين): في المزرعة السليمة، تكون كلا العقدتين في حالة التشغيل "UP" بنسبة (50%)، مما يعني أنهما تستقبلان طلبات العملاء وتعالجانها بفي آن واحد عبر عنوان IP الافتراضي المشترك.

 

• إعادة توازن تلقائية: في حال فشل إحدى العقد، تعرض لوحة التحكم بصرياً العقدة المتبقية وهي تتحمل 100% من حركة المرور. لا يوجد تأخير في "التبديل عند الفشل" (failover)، نظراً لأن العقدة الناجية تكون نشطة بالفعل (باستثناء وقت الاكتشاف الذي يستغرق بضع ثوانٍ).
• إدراج العقدة: عند إعادة تشغيل عقدة تم إصلاحها، تتحول حالتها من التوقف "STOP" إلى التشغيل "UP" وتبدأ تلقائياً في استقبال حصتها من الحمل دون تدخل من مسؤول النظام.
• لا يوجد مزامنة بيانات: يرجى ملاحظة أنه في المجموعة التي تعمل بأسلوب المزرعة، لا توجد حالة إعادة مزامنة باللون "البرتقالي"، حيث يُفترض أن تكون العقد عديمة الحالة (stateless) أو تشترك في قاعدة بيانات خلفية (والتي يمكن حمايتها بشكل منفصل في مجموعة متطابقة Mirror cluster).

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

تم تصميم مجموعة SafeKit بأسلوب المزرعة لضمان التوافر العالي (High Availability) وقابلية التوسع للخدمات. يركز التكوين على توزيع حركة المرور الواردة عبر كلا العقدتين (Nodes) في آن واحد:

• الخدمات المتوازنة الحمل (تبويب Macros): تحديد خدمات التطبيقات المعينة (مثل Apache أو IIS أو Nginx) المراد إبقاؤها نشطة على جميع العقد.
• شبكة (شبكات) نبضات القلب (Heartbeat network): مسار (مسارات) الاتصال المستخدمة لاكتشاف ما إذا كانت إحدى العقد قد غادرت المزرعة، مما يؤدي إلى إعادة توزيع الحمل على الفور.
• عنوان IP الافتراضي للمزرعة (Farm VIP): على عكس المجموعة المتطابقة (Mirror cluster)، يتم مشاركة عنوان IP الافتراضي للمزرعة بين العقد باستخدام خوارزمية تصفية النواة (Kernel) لتوزيع حركة مرور الشبكة.
• قواعد موازنة الحمل: تحديد سياسة توزيع حركة المرور بناءً على عنوان IP الخاص بالمصدر أو المنفذ.
• أدوات الفحص (Checkers): مراقبة الحالة الصحية للتطبيق وتفعيل إعادة التشغيل التلقائي في حال اكتشاف فشل في إحدى العمليات.