توفر عمليات نشر Kubernetes الكثير من المزايا للمؤسسات التي ترغب في تحديث البنية الأساسية الخاصة بها والانتقال إلى بنية سحابية أصلية.
ولكن الكثير من ما الذي يجعل Kubernetes جذابًا؟ كما أن عدم قدرة المطورين ومديري المعلومات على توفير البيانات يخلق أيضًا مشاكل محتملة عندما يتعلق الأمر بالنسخ الاحتياطي واسترداد البيانات بعد الكوارث (DR).
من السهل نسبيًا إجراء نسخ احتياطية للتطبيقات المتجانسة التقليدية وحتى الآلات الافتراضية (VMs) ودمجها في خطة استرداد الكوارث، طالما تم ذلك بعناية. ولكن Kubernetes والحاويات – مع خدماتها المصغرة المترابطة، وتطبيقاتها عديمة الجنسية، والتخزين الدائم – تعمل بطريقة مختلفة. ويتعين على التعافي من الكوارث أن يسمح بذلك.
لماذا نحتاج إلى DR لـ Kubernetes؟
على نحو متزايد، الحاويات و كوبيرنيتس تُستخدم في الإنتاج. ونتيجة لذلك، من المرجح أن يتعامل Kubernetes مع البيانات الحيوية وعمليات الأعمال الرئيسية.
تحتاج المؤسسات إلى حماية البيانات والخدمات المصغرة المختلفة التي تشكل تطبيقًا يعتمد على Kubernetes والتأكد من إمكانية استردادها بدقة وفي الوقت المناسب.
وتحتاج فرق تكنولوجيا المعلومات إلى ضمان تغطية جميع الأجزاء المهمة من النشر المستند إلى Kubernetes بخطة التعافي من الكوارث. لا يتعلق الأمر فقط بحماية التخزين الدائم باستخدام النسخ الاحتياطية القياسية وغير القابلة للتغيير، بل تحتاج المؤسسات إلى حماية المجموعة بأكملها ومكوناتها والبيانات حتى يتمكنوا من استعادتها بسلاسة. كل هذا يحتاج أيضًا إلى الاختبار.
ما هي تحديات الاسترداد بعد الكوارث في Kubernetes؟
تعني DR لمجموعات Kubernetes تحديد وحماية مكونات المجموعة وتكوينها.
وهناك أيضًا أحجام البيانات. فبيانات Kubernetes تخزن بشكل متزايد على وحدات تخزين دائمة، مما يجعل مهمة فريق التعافي من الكوارث أسهل إلى حد ما. ولكن يجب على المتخصصين في التعافي من الكوارث أن يكونوا على دراية بالمكان الذي تخزن فيه التطبيقات المستندة إلى Kubernetes البيانات، حيث يمكن تشغيلها عبر وحدات تخزين محلية وسحابية وهجينة.
والخبر السار، وفقًا لمحلل جارتنر توني إيمز، هو أن تطبيقات الحاويات تتمتع بميزات تساعد على التعافي من الكوارث واستمرارية الأعمال، حتى لو كان النسخ الاحتياطي التفصيلي أكثر صعوبة.
“يقول إن قابلية النقل وعدم قابلية التغيير المتأصلة في الحاويات تجعل من السهل تكرار مجموعة كاملة من التطبيقات بشكل متسق في مواقع متعددة”. “باستخدام التكامل المستمر/النشر المستمر [CI/CD] “من خلال العمليات، يمكن إعادة بناء التطبيقات المحصورة بسهولة وتسليمها حيثما ومتى كانت هناك حاجة إليها، سواء في موقع ثانوي، أو لإعادة بناء موقع أساسي بعد حدوث فشل.”
ما هي المخاطر التي تهدد بيئات Kubernetes والتي تحتاج إلى التخفيف من حدتها من خلال التعافي من الكوارث؟
المخاطر التي تواجه Kubernetes هي نفسها التي تواجهها أي بيئة تشغيلية أخرى لتكنولوجيا المؤسسات: فشل الأجهزة، ومشاكل البرامج – بما في ذلك في نظام التشغيل Linux الأساسي – وانقطاع الطاقة أو الشبكة، والكوارث المادية، وبالطبع الهجمات الإلكترونية بما في ذلك برامج الفدية.
ومع ذلك، فإن مرونة الحاويات وطبيعتها الموزعة يمكن أن تجعل التطبيقات عرضة لنقاط فشل واحدة؛ ويمكن للهندسة المعمارية الموزعة أن تعمل على تكبير تأثير انقطاع الأجهزة.
على سبيل المثال، يمكن للمؤسسة أن تقوم بتكرار آلة افتراضية بالكامل، أو إنشاء لقطة ثابتة، وتكون واثقة إلى حد معقول من أنها التقطت كل ما يلزم لتشغيل تطبيق أو عملية تجارية. مع Kubernetes، هناك المزيد من التبعيات.
يحدد Iams الطريقة التي تتعامل بها التطبيقات المحصورة في حاويات مع التخزين باعتبارها خطرًا محددًا. وعلى عكس التطبيقات التقليدية، التي تستخدم نظام الملفات الخاص بنظام التشغيل المضيف، “تحتفظ الحاويات بالبيانات باستخدام وحدات تخزين تكتب البيانات إلى وحدة تخزين خارج نظام الملفات المحلي الخاص بالحاوية”، كما يقول.
إذا كانت الحاويات موجودة في مجموعات Kubernetes، فيجب على فرق تكنولوجيا المعلومات التأكد من إجراء نسخ احتياطية للبيانات وتكوينات السياسات الأخرى، ومن إمكانية إعادة ربط الحاويات بمخزنها بعد الاستعادة.
ما هي النقاط الرئيسية التي يجب أن تحتويها خطة الاسترداد بعد الكوارث لبيئة Kubernetes؟
عادةً ما تكون عملية الاسترداد الناجح للكوارث لبيئة Kubernetes أكثر تفصيلاً من خطة الاسترداد للتطبيقات التقليدية.
تستطيع الشركات تقليل وقت التوقف عن العمل وفقدان البيانات، بشرط أن تتمكن من استرداد أجزاء معينة من نظام Kubernetes بدلاً من مجموعات كاملة. يمكن أن يكون لكل جزء من بيئة Kubernetes نقطة استرداد خاصة به وأهداف وقت الاسترداد (RPO/RTO).
ومع ذلك، يتطلب هذا من فرق تكنولوجيا المعلومات أن يكون لديها صورة شاملة وحديثة لمكونات Kubernetes الخاصة بها وعمليات الأعمال التي تدعمها.
أما بالنسبة لخطة الاستعادة بعد الكوارث للبيئات التقليدية، فإن أحد الأساليب هو تحديد أولويات الخدمات التي تحتاج إلى الاستعادة أولاً.
من المفيد هنا طرح سؤالين مرتبطين:
- ما هي التطبيقات المستندة إلى Kubernetes الأكثر أهمية لعمليات الأعمال، وبالتالي تحتاج إلى العودة إلى الاتصال بالإنترنت أولاً؟
- ما هي الخدمات والتبعيات (Kubernetes) التي ستعيد هذه الحاويات بشكل أسرع؟
إذا تم ذلك بشكل جيد، فقد يسمح ذلك للمؤسسة بإحضار تطبيقاتها عبر الإنترنت، ربما مع وظائف أقل، بشكل أسرع مما لو اعتمدت على استعادة مجموعة كاملة.
ومن المرجح أن يعتمد النهج الدقيق على نضج المنظمة ونهجها في التعامل مع المخاطر.
ويقول إيامز: “في هذه المرحلة، تختلف وجهات نظر مهندسي البنية التحتية السحابية والتقليدية حول أفضل السبل للتعامل مع المشكلة”.
“يعطي مهندسو السحابة الأولوية لأساليب إعادة النشر عبر سير عمل CI/CD، بينما تعتمد الأساليب التقليدية على أدوات النسخ الاحتياطي والاسترداد لتطبيقات Kubernetes وحماية البيانات.” توصي شركة التحليل باتباع نهج يركز على التطبيقات إذا كانت المؤسسة ناضجة بدرجة كافية.
ما هي متطلبات البنية التحتية لـ DR لـ Kubernetes؟
عندما يتعلق الأمر بالبنية الأساسية المادية، فإن مرونة Kubernetes من شأنها أن تجعل استرداد التطبيق أسهل. يمكن أن يكون ذلك من الأجهزة المحلية إلى السحابة، أو حتى من خلال الانتقال بين موفري السحابة.
يحتاج المتخصصون في DR إلى تأكد من توفر الموارد المطلوبةيتضمن ذلك متطلبات الحوسبة لتشغيل مجموعات Kubernetes ومساحة التخزين لاستعادة وحدات التخزين الدائمة. كما تعد موارد الشبكة المناسبة ضرورية أيضًا.
لاسترداد التطبيقات، إذا استخدمت فرق تكنولوجيا المعلومات نهج GitOps المرتكز على التطبيقات، فيمكنهم استخدام ArgoCD أو Flux CD للاسترداد.
بخلاف ذلك، من المرجح أن يكون النهج الأفضل هو استخدام أداة من بائع متخصص في Kubernetes، مثل Kasten أو Trilio أو CloudCasa أو Cohesity (التي تمتلك الآن أيضًا أعمال حماية البيانات الخاصة بشركة Veritas). كما يدعم البائعون مثل Commvault وRubrik الحاويات والتطبيقات السحابية الأصلية.
هذه هي الأدوات “المتوافقة مع Kubernetes” التي يتم نشرها على مجموعات وتفهم كيف تشكل المجموعات تطبيقًا – وكيفية استعادتها في حالة حدوث انقطاع.
