---
title: "التوافر العالي Kubernetes K3s: النسخ المتماثل المتزامن والتحويل التلقائي في حالة الفشل لعقدتين"
canonical: "https://safekit.eviden.com/ar/solutions/kubernetes-k3s-the-simplest-high-availability-cluster-with-synchronous-replication-and-failover-between-two-redundant-servers/"
description: "حقق التوافر العالي لـ K3s على عقدتين دون الحاجة إلى تخزين خارجي أو نصاب etcd. تعرف على كيفية توفير SafeKit للنسخ المتماثل بدون فقدان للبيانات وتجاوز الأعطال التلقائي."
category: "solutions"
lang: "ar"
topics: "تبسيط التوافر العالي (HA) في K3s: لماذا تختار SafeKit بدلاً من MetalLB و Longhorn؟, جدول المحتويات, كيف يقوم برنامج SafeKit بتطبيق مجموعة Kubernetes K3s عالية التوافر ببساطة؟, كيف تعمل مجموعة mirror SafeKit مع Kubernetes K3S؟, قيود التوافر العالي SafeKit, مقارنة: SafeKit مقابل حزمة K3s القياسية (MetalLB و Longhorn), دليل الفيديو: تهيئة مجموعة mirror SafeKit HA"
translation: "translate_md 2026-11-08.3 | glossaire 2026-11-08.8 | Translation LLM | 26 expressions"
---
# التوافر العالي Kubernetes K3s: النسخ المتماثل المتزامن والتحويل التلقائي في حالة الفشل لعقدتين {#kubernetes-k3s-high-availability-2-node-synchronous-replication--failover}
## تبسيط التوافر العالي (HA) في K3s: لماذا تختار SafeKit بدلاً من MetalLB و Longhorn؟ {#safekit-k3s-ha-introduction}
في حين أن حزمة المصادر المفتوحة القياسية (MetalLB + Longhorn) الخاصة بـ K3s قوية لمراكز البيانات الكبيرة، إلا أنها تزيد من التعقيد بشكل مفرط للمواقع المحلية ذات العقدتين. يعمل **SafeKit** على تبسيط بيئة K3s عن طريق استبدال أدوات الشبكات والتخزين المستقلة بمحرك واحد موحد عالي التوافر.
### لماذا نستخدم SafeKit لتحقيق التوافر العالي (HA) لعقدتين من K3s؟ {#why-use-safekit-for-2-node-k3s-high-availability-ha}
* **التوافر العالي الحقيقي بعقدتين:** يوفر SafeKit التكرار الكامل **بعقدتين** فقط، مما يلغي الحاجة إلى ثلاث عقد لتحقيق النصاب القانوني لـ *etcd*.
* **انعدام فقدان البيانات (RPO = 0):** يستبدل التخزين الكتلي ذي التكلفة العالية **بالنسخ المتماثل المتزامن على مستوى البايتات** للحصول على أداء محركات الأقراص ذات الحالة الصلبة المحلية.
* **حماية مرنة على مستوى الملفات:** يقوم SafeKit بإجراء النسخ المتماثل المستند إلى المضيف على مستوى الملفات، وهو أمر شفاف تمامًا للتطبيق. فهو لا يحمي قواعد البيانات فحسب، بل يحمي جميع المجلدات والبيانات المرتبطة بها. يمكنك نسخ المجلدات الموجودة تمامًا في مكان تثبيتها، حتى على **قرص النظام**.
* **بروتوكول الإنترنت الظاهري (VIP) المتكامل:** يدير بروتوكول الإنترنت الخاص بالمجموعة على مستوى النواة، مما يلغي الحاجة إلى تكوينات **MetalLB** منفصلة.
* **التحويل التلقائي عند الفشل والعودة بعد الفشل:** يُفعّل انتقالًا فوريًا إلى العقدة الثانوية عند حدوث عطل؛ وبمجرد أن تصبح العقدة الأساسية سليمة، يُنفّذ SafeKit **إعادة مزامنة البيانات تلقائيًا** دون تدخل يدوي.
* **تكاليف تشغيل منخفضة للغاية:** يعمل SafeKit دون تكاليف الإدارة الباهظة لوحدات التخزين (CSI/Longhorn) ووحدات الشبكات (CNI/MetalLB) التي تتطلبها المكدسات القياسية، مما يوفر ذاكرة وصول عشوائي (RAM) ووحدة معالجة مركزية (CPU) حاسمة لتطبيقاتك.
* **سهل الاستخدام لمتخصصي تكنولوجيا المعلومات:** يستبدل **ملفات YAML المعقدة الخاصة بالبنية التحتية** للشبكات والتخزين بواجهة **مستخدم رسومية بسيطة عبر الويب** ونصوص برمجية للنشر التلقائي، مما يتيح لك التركيز فقط على تطبيقاتك.
**التوافر العالي (HA) بدون مشاركة موارد لمجموعات K3s المكونة من عقدتين**
⚡ دليل سريع لتثبيت مجموعة Kubernetes عالية التوفر (HA) >
## جدول المحتويات {#toc}
* [كيف يقوم برنامج SafeKit بتطبيق مجموعة Kubernetes K3s عالية التوافر ببساطة؟](#safekit-mirror-k3s-cluster)
* [كيف تعمل مجموعة mirror SafeKit مع Kubernetes K3S؟](#safekit-mirror-cluster)
* [قيود التوافر العالي SafeKit](#safekit-ha-limitations)
* [مقارنة: SafeKit مقابل حزمة K3s القياسية (MetalLB و Longhorn)](#safekit-k3s-ha-comparison)
* [دليل الفيديو: تهيئة مجموعة mirror SafeKit HA](#videoguide-safekit-mirror-cluster)
* [🔍 استكشف SafeKit](#hub)
## كيف يقوم برنامج SafeKit بتطبيق مجموعة Kubernetes K3s عالية التوافر ببساطة؟ {#safekit-mirror-k3s-cluster}
### كيف يمكنني تطبيق التوافر العالي لمجموعة Kubernetes K3s المكونة من عقدتين؟ {#how-do-i-implement-high-availability-for-a-2-node-kubernetes-k3s-cluster}
يمكنك تطبيق التوافر العالي (HA) لمجموعة Kubernetes K3s المكونة من عقدتين باستخدام **وحدة SafeKit k3s.safe mirror**. يتيح لك هذا الحل نشر بيئة زائدة عن الحاجة دون الحاجة إلى تخزين NFS خارجي، أو قاعدة بيانات تكوين خارجية مخصصة، أو خبرة متخصصة Kubernetes.
### لماذا نستخدم K3s للحوسبة الطرفية وإنترنت الأشياء؟ {#why-use-k3s-for-edge-and-iot-computing}
يُعد [K3s]() محرك Kubernetes المفضل **لإنترنت الأشياء والحوسبة الطرفية** لأنه توزيع خفيف الوزن ومعتمد ومصمم للبيئات ذات الموارد المحدودة. إنه يبسط العبء التشغيلي لـ Kubernetes القياسي مع الحفاظ على التوافق الكامل.
### ما هي الميزات الرئيسية لوحدة k3s.safe mirror؟ {#what-are-the-key-features-of-the-k3ssafe-mirror-module}
توفر وحدة k3s.safe حزمة توافر عالية شاملة لـ K3s من خلال تنفيذ ما يلي:
* **العُقد النشطة المزدوجة:** تشغيل عقدتين رئيسيتين/عميلتين K3s نشطتين في وقت واحد لاستضافة الحاويات.
* **نسخ قاعدة البيانات:** نسخ قاعدة بيانات تكوين MariaDB في الوقت الفعلي بين العُقد.
* **التخزين الدائم:** تكرار وحدات التخزين الدائمة عبر مُزوِّد ديناميكي متكامل لعميل NFS (nfs-client).
* **استمرارية الشبكة:** تتضمن عنوان IP ظاهريًا لتمكين وصول العميل بسلاسة.
* **الاسترداد التلقائي:** دعم كامل لعمليات تجاوز الفشل والعودة إليها تلقائيًا.
### بالإضافة إلى K3s، ما هي التطبيقات والبيئات التي يمكن لـ SafeKit حمايتها؟ {#beyond-k3s-which-applications-and-environments-can-safekit-protect}
يُعد SafeKit حلاً متعدد الاستخدامات وعالي التوافر **لكل من Windows و Linux،** ويمتد إلى ما هو أبعد من مجموعة mirror. فهو يتيح **النسخ المتماثل المتزامن في الوقت الفعلي** وتجاوز الأعطال التلقائي لمجموعة واسعة من أعباء العمل الحرجة، بما في ذلك:
* **البيئات الافتراضية والمادية:** أجهزة افتراضية كاملة من نوع Hyper-V أو KVM.
* **تنسيق الحاويات:** بيئات Docker و Podman.
* **البيانات والخدمات:** أدلة الملفات الفردية والخدمات وقواعد البيانات المتنوعة.
* **البنية التحتية السحابية:** توفر عالٍ للتطبيقات السحابية.
يوفر SafeKit أيضًا **مجموعات farm** مع **موازنة تحميل الشبكة الأصلية (Network Load Balancing) وتجاوز الفشل (Failover)** للتطبيقات عديمة الحالة مثل **خوادم الويب**.
💡 [استكشف القائمة الكاملة لحلول التوافر العالي المدعومة هنا.]()
### كيف يحقق SafeKit التوافر العالي لـ K3s؟ {#safekit-k3s-architecture-table}
**البنية ومنطق التكرار لمجموعة K3s ثنائية العقدة باستخدام SafeKit**
مجموعة K3s ثنائية العقدة | SafeKit PRIM (العقدة الأساسية) | SafeKit SECOND (العقدة الثانوية)
---|---|---
تنفيذ عبء العمل | خدمات K3s الرئيسية والوكيلة نشطة، وتدير تنسيق المجموعة وتشغل الحاويات. | تظل خدمات العميل والتحكم في K3s نشطة، مما يوفر معالجة متوازية وتوافرًا عاليًا.
تخزين NFS ووحدات التخزين الدائمة | • يستضيف عنوان IP ظاهري ومنفذ NFS
• إدارة مشاركات NFS المصدرة النشطة
• يخزن وحدات التخزين الدائمة (PVs) الخاصة بـ K3s | النسخ المتطابق المتزامن: ينسخ SafeKit جميع وحدات التخزين الدائمة في الوقت الفعلي لضمان عدم فقدان أي بيانات.
قاعدة بيانات التكوين | • يستضيف عنوان IP ظاهريًا ومنفذ MariaDB
• إدارة قاعدة بيانات تكوين K3s النشطة | نسخ قاعدة البيانات: يتم نسخ قاعدة بيانات MariaDB بشكل متزامن، مما يحافظ على حالة المجموعة للتحويل التلقائي عند الفشل.
**آلية تجاوز الفشل التلقائي:** في حالة فشل العقدة الأساسية، يقوم SafeKit تلقائيًا بترحيل عناوين IP الظاهرية وخدمات التخزين إلى العقدة الثانوية، مما يضمن استمرارية الخدمة لمجموعة K3s.
## كيف تعمل مجموعة mirror SafeKit مع Kubernetes K3S؟ {#safekit-mirror-cluster}
### الخطوة 1: نسخ الملفات على مستوى البايت في مجموعة mirror {#step-1-byte-level-file-replication-in-a-mirror-cluster}
توضح هذه المرحلة البنية التوافر العالي بين **الخادم 1 (PRIM)** والخادم **2 (SECOND)**. يشغل كلا الخادمين مكونات K3s الرئيسية والوكيلة كما هو محدد في [جدول البنية](#safekit-k3s-architecture-table).
حاليًا، عنوان **IP الظاهري (VIP)** **وتخزين NFS الدائم** و **MariaDB** نشطة على الخادم 1 (PRIM) فقط. تتزامن مكونات K3s الرئيسية على كلا العقدتين مع بعضها البعض عن طريق الوصول إلى حالة المجموعة عبر عنوان IP الظاهري ومنفذ MariaDB. تُنفذ SafeKit [النسخ المتماثل المتزامن]() لـ MariaDB وملفات NFS الدائمة، مما يضمن **عدم فقدان البيانات (RPO = 0)** في حالة حدوث عطل.
توزع أجهزة K3s الرئيسية عبء العمل عبر كلتا العقدتين (أو أكثر) عن طريق التواصل مباشرة مع وكلاء K3s. تتصل العملاءات الخارجية بـ
[عنوان IP الظاهري للمجموعة]() على عقدة PRIM. باستخدام آليات Kubernetes القياسية، يقوم خادم K3s الرئيسي بإعادة توجيه حركة المرور إلى الحاويات الموزعة عبر العقد. وبالمثل، تصل الحاويات إلى **وحدات التخزين الدائمة (PVs)** الخاصة بها على خادم PRIM عبر عنوان IP الظاهري ومنفذ NFS.
### الخطوة 2: تجاوز الفشل التلقائي واستمرارية الخدمة {#step-2-automatic-failover-and-service-continuity}
عندما يتعطل **الخادم 1 (PRIM)**، يتولى **الخادم 2 (SECOND)** تلقائيًا عمليات المجموعة لضمان الاستمرارية.
يكتشف SafeKit العطل وينقل **عنوان IP الظاهري** للمجموعة على الفور إلى الخادم 2. ثم يقوم بترقية **خدمات** **MariaDB** وNFS المحلية إلى حالة نشطة. وبسبب النسخ المتماثل المتزامن الذي تم إجراؤه في الخطوة 1، فإن جميع قواعد بيانات MariaDB وملفات وحدة التخزين الدائمة (PV) الخاصة بـ NFS محدثة بالفعل على الخادم 2، مما يضمن عدم فقدان أي بيانات.
مع الحفاظ على حالة المجموعة، يستمر برنامج **K3s Master** على الخادم 2 في التنفيذ. يكتشف فقدان وكيل الخادم 1 ويعيد جدولة الحاويات المتأثرة تلقائيًا على وكلاء K3s النشطين المتبقين. إجمالي وقت تجاوز الفشل (RTO) هو مجموع فترة اكتشاف الخطأ (الافتراضي: 30 ثانية) والوقت المطلوب لمكونات K3s للتهيئة على العقدة الثانوية.
بينما يكون الخادم 1 غير متصل بالإنترنت، تستمر خدمات MariaDB وNFS في العمل على الخادم 2، مع كتابة التغييرات محليًا فقط.
### الخطوة 3: استعادة الفشل وإعادة التكامل التلقائي {#step-3-failback-and-automatic-reintegration}
يحدث **الفشل الارتدادي** عند إعادة تشغيل الخادم 1 بعد حل المشكلة الأولية. يقوم SafeKit تلقائيًا بإعادة مزامنة ملفات MariaDB وNFS، وتحديث البيانات المعدلة فقط على الخادم 2 أثناء فترة التوقف. عملية إعادة التكامل هذه **غير معطلة** ؛ حيث تستمر مكونات K3s الرئيسية والوكيلة في العمل على الخادم 2 دون انقطاع.
تعمل SafeKit على تحسين وقت الاسترداد بناءً على كيفية إيقاف تشغيل الخادم:
* **الإغلاق النظيف:** إذا تم إيقاف SafeKit عن عمد على الخادم 1، فستتم إعادة مزامنة المناطق المعدلة المحددة فقط داخل الملفات باستخدام **خرائط البتات لتتبع التعديلات**. وهذا يضمن إعادة دمج سريعة للغاية.
* **تعطل النظام (مثل انقطاع التيار الكهربائي):** إذا تعرض الخادم 1 لإيقاف تشغيل غير نظيف، يتم تجاوز خرائط البتات المعدلة لأغراض السلامة. بدلاً من ذلك، يقوم SafeKit بإعادة مزامنة جميع الملفات التي تحمل طابعًا زمنيًا للتعديل أحدث من آخر نقطة مزامنة محددة، مما يضمن **سلامة البيانات بالكامل**.
### الخطوة 4: استعادة التوافر العالي وتوزيع الحمولة {#step-4-restoring-high-availability-and-load-distribution}
بعد إعادة الدمج، تعود المجموعة إلى **وضع mirror الكامل**، مما يعكس الحالة الموضحة في الخطوة 1. يصبح النظام مرة أخرى في حالة توفر عالية: تظل **خدمات** **MariaDB** وNFS نشطة على الخادم 2، بينما يقوم SafeKit بإجراء نسخ متماثل في الوقت الفعلي لجميع تحديثات الملفات مرة أخرى إلى الخادم 1.
تتم إعادة تشغيل كل من **K3s Master** و **K3s Agent** تلقائيًا على الخادم 1. يتعرف مُجدوِل Kubernetes الآن على الخادم 1 كعقدة سليمة ويمكنه البدء في إعادة جدولة الحاويات لتوزيع عبء العمل عبر كلا الخادمين.
إذا كان المسؤول يفضل تشغيل خدمات MariaDB وNFS على الخادم 1 (استعادة دور PRIM الأصلي)، فيمكن تشغيل **عملية التبديل** يدويًا عبر وحدة التحكم بالويب في وقت مناسب أو تلقائيًا من خلال إعدادات التكوين.
### كيفية تهيئة مجموعة mirror SafeKit؟ {#safekit-mirror-cluster-configure}
توفر **وحدة التحكم الويب SafeKit** واجهة سهلة الاستخدام لتنسيق التوافر العالي لتطبيقاتك الهامة. في بضع خطوات فقط، يمكنك تكوين **مجموعة mirror SafeKit** لضمان استمرارية الأعمال:
* **تجاوز الفشل في التطبيق (علامة تبويب الماكرو):** حدد خدمات التطبيق المحددة التي سيتم إعادة تشغيلها تلقائيًا في حالة حدوث عطل.
* **شبكة (شبكات) مراقبة النبض:** مسار (مسارات) اتصال مخصص (مخصصة) تستخدمه عقد المجموعة لمراقبة صحة وتوافر بعضها البعض باستمرار ومزامنة قرارات تجاوز الفشل.
* **إدارة عنوان IP الظاهري:** قم بإعداد عنوان IP الظاهري (VIP) لإعادة اتصال العميل بشفافية بعد تجاوز الفشل.
* **النسخ المتماثل في الوقت الفعلي:** حدد الدلائل الهامة للنسخ المتماثل المتزامن على مستوى البايت والمستند إلى المضيف.
* **أداة التحقق:** راقب سلامة التطبيق وقم بتشغيل الاسترداد التلقائي إذا تم اكتشاف فشل في إحدى العمليات.
تتضمن مجموعة SafeKit أداة مخصصة للتحقق من انقسام الدماغ لحل مشكلات عزل الشبكة دون الحاجة إلى جهاز شاهد ثالث أو شبكة نبضات إضافية. تعرّف على المزيد حول [النبضات، وتجاوز الأعطال، والنصاب في المجموعة]().
### كيفية مراقبة مجموعة mirror SafeKit؟ {#safekit-mirror-cluster-monitoring}
توفر **وحدة تحكم إدارة SafeKit** عرضًا موحدًا للبنية التحتية عالية الإتاحة. وتسمح للمسؤولين بمراقبة **الحالة التشغيلية** للمجموعة وتتبع مزامنة البيانات في الوقت الفعلي.
بالنسبة مجموعة mirror المكونة من عقدتين، تعرض وحدة التحكم بوضوح أدوار كل خادم:
* **PRIM (Primary):** العقدة النشطة التي تشغل التطبيق حاليًا وتدير عنوان IP الظاهري. وهي تؤدي عمليات الكتابة إلى وحدة التخزين المحلية والنسخ المتماثل في الوقت الفعلي إلى العقدة الثانوية.
* **SECOND :** العقدة الاحتياطية التي تتلقى تحديثات متزامنة على مستوى البايت. وهي جاهزة لتولي المهام على الفور في حال فشل العقدة الأساسية.
* **الحالة ALONE :** تنبهك بصريًا عندما تعمل المجموعة على عقدة واحدة (على سبيل المثال، أثناء الصيانة أو بعد حدوث عطل)، مما يشير إلى فقدان التكرار مؤقتًا.
* **تقدم إعادة المزامنة:** عندما يتعافى العقدة الفاشلة، يتحول لونها إلى البرتقالي أثناء إعادة دمج البيانات في الخلفية، مما يضمن عدم وجود وقت تعطل أثناء مرحلة "العودة إلى الوضع الطبيعي".
بالإضافة إلى أيقونات الحالة البسيطة، توفر الواجهة **تنسيقًا للتحويل التلقائي عند الفشل بنقرة واحدة**، مما يتيح لك إعادة تعيين الدور الأساسي يدويًا للصيانة المخطط لها مع ضمان التوافر المستمر لنشاط المستخدم.
## قيود التوافر العالي SafeKit {#safekit-ha-limitations}
الحد / المتطلب | السبب والتأثير | البديل الموصى به
---|---|---
حجم النسخ المتماثل: بضعة تيرابايت | وقت إعادة المزامنة بعد الفشل ([الخطوة 3](https://safekit.eviden.com/ar/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)):
• شبكة بسرعة 1 جيجابت/ثانية ≈ 3 ساعات/تيرابايت
• شبكة بسرعة 10 جيجابت/ثانية ≈ ساعة واحدة/تيرابايت (حسب أداء الكتابة على القرص) | • استخدام [وحدة تخزين خارجية مشتركة](https://safekit.eviden.com/ar/best-practises/san-vs-nas-shared-storage-for-a-failover-cluster/) (أكثر تكلفة وأكثر تعقيدًا).
عدد الملفات: أقل من 1,000,000 ملف | • أداء وقت إعادة المزامنة بعد حدوث عطل ([الخطوة 3](https://safekit.eviden.com/ar/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• الوقت اللازم لمقارنة كل ملف بين العقدتين. | • ضع الملفات العديدة المراد نسخها في قرص صلب افتراضي/جهاز افتراضي.
• في هذه الحالة، سيتم تكرار الملفات التي تمثل القرص الصلب الافتراضي/الجهاز الافتراضي وإعادة مزامنتها فقط.
سعة تجاوز الفشل: ≤ 32 جهازًا افتراضيًا | • تعمل كل آلة افتراضية في وحدة mirror مستقلة.
• بحد أقصى 32 وحدة mirror تعمل على نفس المجموعة. | • استخدام وحدة تخزين مشتركة خارجية وحل آخر لتجميع الأجهزة الافتراضية (أكثر تكلفة وأكثر تعقيدًا).
البنية الشبكية: شبكة LAN/VLAN بين المواقع البعيدة | • تجاوز الفشل التلقائي [لعنوان IP الظاهري](https://safekit.eviden.com/ar/best-practises/how-a-virtual-ip-address-works/) مع عقدتين في نفس الشبكة الفرعية.
• عرض نطاق ترددي جيد لإعادة المزامنة ([الخطوة 3](https://safekit.eviden.com/ar/architectures/file-replication-byte-level-with-failover-mirror-cluster/#safekit-mirror-cluster)).
• زمن انتقال منخفض [للنسخ المتماثل المتزامن](https://safekit.eviden.com/ar/best-practises/synchronous-replication-vs-asynchronous-replication/): عادةً ما يكون أقل من 5 مللي ثانية من زمن ذهاب وعودة (RTT)؛ يجب التحقق من صحة القيم الأعلى مقابل معدل الكتابة للتطبيق. | • إذا كانت العقدتان في شبكات فرعية مختلفة (وهو أمر شائع في السحابة)، فاستخدم [خيارات إعادة التوجيه الأخرى](https://safekit.eviden.com/ar/best-practises/how-a-virtual-ip-address-works/#safekit-virtual-ip-implementation): موازن تحميل، أو واجهات سطر الأوامر لمزود السحابة، أو بروتوكول BGP، أو إعادة توجيه نظام أسماء النطاقات (DNS).
• استخدم حلول النسخ الاحتياطي مع النسخ المتماثل غير المتزامن للشبكات ذات زمن الانتقال العالي.
## مقارنة: SafeKit مقابل حزمة K3s القياسية (MetalLB و Longhorn) {#safekit-k3s-ha-comparison}
**مقارنة: SafeKit مقابل المصادر المفتوحة القياسية (MetalLB + Longhorn)**
القدرة | SafeKit (K3s.safe) | MetalLB + Longhorn (معيار K8s)
---|---|---
البنية | الكل في واحد: شبكات متكاملة، ونسخ متماثل، وتجاوز للأعطال في حزمة واحدة. | مكدس "افعلها بنفسك" (DIY): يتطلب حزمًا مستقلة متعددة (CNI، CSI، LoadBalancer).
كفاءة الأجهزة | التوافر العالي (HA) بعقدتين فقط: تكرار كامل بدون عقدة "شاهد" أو محكِّم ثالثة. | الحد الأدنى 3 عُقد: يتطلب عادةً أعدادًا فردية لضمان اكتمال نصاب Etcd وسلامة التخزين.
التواصل (VIP) | الأصلي: عنوان IP ظاهري تتم إدارته على مستوى نظام التشغيل؛ شفاف بالنسبة لـ K3s. | معقد: يتطلب تثبيت MetalLB مع تكوين L2 أو BGP باستخدام وحدات speaker مخصصة تستهلك وحدة المعالجة المركزية/ذاكرة الوصول العشوائي (CPU/RAM) على كل عقدة.
متطلبات التخزين | المزامنة على مستوى البايت: نسخ الملفات في الوقت الفعلي للأدلة الموجودة؛ يعمل على أقراص النظام القياسية؛ نسخ الملفات على مستوى البايت مع الحد الأدنى من استهلاك وحدة المعالجة المركزية/الشبكة. | على مستوى الكتلة: تخزين الكتل الموزع (Longhorn) باستخدام وحدات تخزين مخصصة؛ استهلاك أعلى للموارد.
الذكاء في تجاوز الفشل | الاستقرار المستقل: يعمل SafeKit خارج بيئة تشغيل الحاويات. يراقب نظام التشغيل والأجهزة مباشرة، مما يضمن تجاوز الفشل حتى إذا توقفت واجهة تحكم Kubernetes أو محرك الحاويات. | الاعتمادية الدائرية: يتم استضافة منطق تجاوز الفشل *داخل* الحاويات التي يُفترض أن تحميها. إذا توقف نظام التشغيل المضيف أو محرك K3s، فإن حاويات الإدارة (MetalLB/Longhorn) تتجمد أيضًا، مما يتطلب غالبًا فرزًا يدويًا لكسر "القفل"
الإدارة | بشكل مبسط: يمكن إدارتها عبر لوحة تحكم ويب واحدة؛ لا يلزم وجود خبير Kubernetes. | متخصص: يتطلب معرفة عميقة بـ YAML وHelm ووحدات التحكم الداخلية لـ K8s.
**باختصار**، في حين أن حزمة "افعلها بنفسك" القياسية (MetalLB + Longhorn) توفر قابلية التوسع لخبراء Kubernetes، فإنها تخلق **تبعية دائرية** حيث تكون أدوات التخزين والشبكات عرضة لنفس حالات فشل العقدة التي صُممت لإدارتها. يكسر **SafeKit** هذه الحلقة من خلال العمل كطبقة بنية تحتية مستقلة؛ فهو يوفر حلاً أكثر قوة ومستقلًا عن الأجهزة للتوافر العالي (HA) بعقدتين، والذي يظل قيد التشغيل حتى إذا توقف محرك Kubernetes أو نظام التشغيل المضيف. وهذا يضمن الاسترداد التلقائي وسلامة البيانات دون الحاجة إلى موارد كبيرة، أو نصاب إلزامي من ثلاث عقد، أو تعقيد التكوين الذي تتطلبه حلول التخزين الموزع التقليدية وطبقات الشبكات.
## دليل الفيديو: تهيئة مجموعة mirror SafeKit HA {#videoguide-safekit-mirror-cluster}
### فيديو SafeKit: تجميع على مستوى التطبيق (8:47) {#demo-mirror-ha-cluster}
في حين أن هذا الفيديو يوضح مدى التوافر العالي لبرنامج SafeKit Microsoft SQL Server، فإنه يقدم نظرة عامة ممتازة حول كيفية تأمين الحل لبيئات K3s. يعمل SafeKit بشكل متطابق مع أي قاعدة بيانات أخرى أو تطبيق حيوي للأعمال.
### أبرز لقطات الفيديو {#video-highlights}
1. 🎬 [عقدتان مع SQL Server]() (0:32)
2. 🎬 [إعداد المجموعة ووحدة mirror.safe]() (3:58)
3. 🎬 [بدء واختبار النسخ المتماثل لـ SQL، والترحيل، وتجاوز الفشل عند التعطل]() (4:17)
<br />