استخدام لقطات البيانات الاصطناعية لحماية مجموعات Kubernetes من الكوارث

لضمان استمرارية العمل في حالة وقوع كوارث، ستحتاج إلى تنفيذ إستراتيجية استعادة القدرة على العمل بعد الكوارث (DR) للتطبيقات التي تعمل على مجموعة Kubernetes التي توفر حماية البيانات وتمكنك من التبديل بسرعة إلى نظام احتياطي بأقل قدر من فقدان البيانات والإنتاجية. على الرغم من التغيير الهائل الذي ينطوي عليه تبني Kubernetes لبنية نظام تكنولوجيا المعلومات، يقدم نظام Kubernetes نماذج DR مماثلة كتطبيق تقليدي (Oracle Java SE وOracle Java EE وغيرها). يجب الحفاظ على نسخة متسقة ومحدثة قدر الإمكان من النظام الأساسي في موقع ثانوي يمكن من خلاله استئناف أحمال العمل في حالة حدوث كارثة تتسبب في توقف في المنطقة الأساسية.

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

• تجنب استمرار تعدد اللغات. يعد استخدام أنواع مختلفة من المتاجر الدائمة لبيانات وقت التشغيل أمرًا شبه مستحيل لحل المشكلة، وفقًا لنظرية اتساق توفر النسخ الاحتياطي (BAC).
• استخدم متجرًا واحدًا لجميع أنواع البيانات المختلفة والخدمات الصغيرة والتطبيقات ذات التبعيات، قدر الإمكان.
• راجع أفضل ممارسات Oracle MAA لـ Oracle Database من أجل حماية الكوارث لبيانات وقت التشغيل.

بالإضافة إلى ذلك، يجب حماية مستوى التحكم في مجموعة Kubernetes. استخدم لقطات etcd المناسبة لتجنب التلف وحالات الفشل وتوفير ارتداد للمجموعات العاملة. على الرغم من أن Oracle Maximum Availability يوفر أفضل الممارسات للتحكم في حماية المستوى من الكوارث، إلا أنه يقع خارج نطاق هذا المستند لوصف التقنيات المطلوبة في هذا المجال.

قبل البدء

هناك العديد من الموجزات الفنية لـ Oracle Maximum Availability Architecture التي تصف كيفية إعداد نظام استعادة البيانات بعد الكوارث (DR) لأنظمة البرامج الوسيطة التقليدية. تعرض هذه المستندات بالتفصيل متطلبات حماية الكوارث لمكونات البنية الأساسية الخارجية (مثل التخزين وموازنات التحميل وقاعدة البيانات) التي تستخدمها تطبيقات Kubernetes.

لمزيد من التفاصيل، راجع ما يلي:

• Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery
• مجموعة SOA Suite في Oracle Cloud Infrastructure Marketplace لاستعادة القدرة على العمل بعد الكوارث

البنية

تعرض هذه البنية هيكل نظام استعادة القدرة على العمل بعد الكوارث (DR) لمجموعة Kubernetes.

يتم استنساخ جميع معلومات وقت التشغيل والتكوين وبيانات التعريف الموجودة في قاعدة البيانات الأساسية من المنطقة 1 إلى المنطقة 2 مع Oracle Autonomous Data Guard. يتم استنساخ تكوين مجموعة Kubernetes المطلوب (K8s) من خلال لقطات ETCD لحماية مستوى التحكم ولقطات YAML لحماية تكوين التطبيق. يمكنك استخدام لقطات البيانات الاصطناعية أو يمكنك استخدام نسخ etcd أو لقطات البيانات الاصطناعية لحماية التكوين الخاصة بالتطبيق لحماية التكوين الخاصة بالتطبيق. راجع استعادة مجموعات Kubernetes استنادًا إلى لقطات etcd لمزيد من التفاصيل. يتم استضافة الصور التي تستخدمها الحاوية في السجلات، إما المحلية لكل مجموعة أو في المستودعات الخارجية (لا تعتبر الصور تكوين مجموعة Kubernetes بنفسها).

ملاحظة:

إعداد Oracle Autonomous Data Guard لقاعدة بيانات وقت التشغيل خارج مجال هذا المستند.

وصف الشكل التوضيحي kubernetes-multiregion-dr.png

kubernetes-multiregion-dr-oracle.zip

تدعم هذه البنية المكونات التالية:

• Region (المنطقة)

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

• موازن التحميل

  توفر خدمة Oracle Cloud Infrastructure Load Balancing توزيع حركة المرور التلقائي من نقطة إدخال واحدة إلى خوادم متعددة في الواجهة الخلفية.

• بوابة التوجيه الديناميكي (DRG)

  DRG هو جهاز توجيه ظاهري يوفر مسارًا لحركة مرور الشبكة الخاصة بين VCNs في نفس المنطقة، بين VCN وشبكة خارج المنطقة، مثل VCN في منطقة Oracle Cloud Infrastructure أخرى، أو شبكة محلية، أو شبكة في موفر سحابة آخر.

• حماية البيانات

  يوفر Oracle Data Guard مجموعة شاملة من الخدمات التي تنشئ قاعدة بيانات بديلة واحدة أو أكثر وتحتفظ بها وإدارتها وتراقبها لتمكين قواعد بيانات Oracle الإنتاجية من البقاء متاحة دون انقطاع. يحتفظ Oracle Data Guard بقواعد البيانات الاحتياطية هذه كنسخ من قاعدة بيانات الإنتاج. بعد ذلك، إذا أصبحت قاعدة بيانات الإنتاج غير متاحة بسبب انقطاع مؤقت مخطط أو غير مخطط، يمكن لـ Oracle Data Guard تحويل أي قاعدة بيانات بديلة إلى دور الإنتاج، مما يقلل من وقت التوقف عن العمل المرتبط بالانقطاع المؤقت.

• Oracle Real Application Clusters (Oracle RAC).

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

• سجل الحاويات

  Oracle Cloud Infrastructure Registry هو سجل مُدار من Oracle يمكنك من تبسيط سير عمل التطوير إلى الإنتاج. يسهل التسجيل عليك تخزين البيانات الاصطناعية والصور الخاصة بالتطوير ومشاركتها وإدارتها. تضمن بنية Oracle Cloud Infrastructure عالية التوفر والقابلة للتوسع أنه يمكنك نشر تطبيقاتك وإدارتها بشكل موثوق.

• محرك حاوية Kubernetes

  Oracle Cloud Infrastructure Container Engine for Kubernetes هي خدمة مدارة بالكامل وقابلة للتوسع وعالية التوافر يمكنك استخدامها لنشر تطبيقاتك المحفوظة في حاويات على السحابة. يمكنك تحديد موارد الحوسبة التي تتطلبها تطبيقاتك، ويقوم Container Engine for Kubernetes بتوفيرها على Oracle Cloud Infrastructure في عقد إيجار موجود. يستخدم محرك حاوية Kubernetes نظام Kubernetes لأتمتة نشر التطبيقات المحفوظة في حاويات وتوسيعها وإدارتها عبر مجموعات المضيفين.

• مجموعة Kubernetes

  مجموعة Kubernetes هي مجموعة من الأجهزة التي تقوم بتشغيل التطبيقات ذات الحاويات. يوفر نظام Kubernetes نظامًا أساسيًا مفتوح المصدر وقابل للتوسيع وقابل للتنقل لإدارة أحمال العمل والخدمات المحفوظة في حاويات في تلك العُقد. تتكون مجموعة kubernetes من نقاط توصيل العامل ونقاط توصيل مستوى التحكم.

• نقطة توصيل عامل Kubernetes

  نقطة توصيل عامل Kubernetes هي جهاز عامل يقوم بتشغيل التطبيقات الموجودة في حاويات ضمن مجموعة Kubernetes. تحتوي كل مجموعة على عقدة عامل واحدة على الأقل.

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

  • kube-apiserver: تشغيل خادم Kubernetes API.
  • إلخd: مخزن قيمة المفتاح الموزع لكل بيانات المجموعة.
  • kube-sccheder: تحديد وحدات التنفيذ الأساسية الجديدة غير المخصصة لنقطة التوصيل التي سيتم تشغيلها عليها.
  • kube-controller-manager: تشغيل عمليات التحكم.
  • مدير التحكم في السحابة: يربط مجموعتك بواجهة برمجة تطبيقات خاصة بالسحابة.
• مراقب الدخول

  وحدة التحكم في الدخول هي مكون يعمل في مجموعة Kubernetes ويدير موارد Ingress. وهو يستقبل حركة المرور من الشبكة الخارجية، ويوجهها إلى الخدمة الصحيحة، ويقوم بإجراء موازنة التحميل وإنهاء SSL. يعمل جهاز التحكم في الدخول عادةً كوحدة تنفيذ منفصلة في المجموعة ويمكن توسيعه بشكل مستقل عن الخدمات التي يديرها.

• واجهة برمجة تطبيقات نقطة نهاية KUBE

  واجهة برمجة تطبيقات نقطة نهاية KUBE هي مكون KUBE-apiserver لمستوى التحكم Kubernetes. يقوم بتشغيل خادم واجهة برمجة تطبيقات Kubernetes.

• النسخ الاحتياطي لـ ETCD

  ETCD Backup هو نسخة احتياطية من مكون etcd من مستوى التحكم Kubernetes. يحتوي etcd على مخزن قيمة المفتاح الموزع لكل بيانات المجموعة. من المهم إنشاء نسخة احتياطية لـ ETCD لاستعادة مجموعات Kubernetes لاستعادة القدرة على العمل بعد الكوارث.

• لقطات YAML

  لقطة YAML هي نسخة في الوقت المحدد من ملفات (yaml) التي تحتوي على تعريف البيانات الاصطناعية في مجموعة Kubernetes. اللقطة هي ملف tar يمكنك استخدامه لاستعادة تلك البيانات الاصطناعية في نفس مجموعة Kubernetes أو في مجموعة مختلفة.

اعتبارات الحماية من الكوارث في Kubernetes

عند تنفيذ إجراءات الحماية من الكوارث لنظام Kubernetes، ضع في اعتبارك ما يلي:

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

على الرغم من أن هذا الكتيب يقدم مثالاً باستخدام Oracle Cloud Infrastructure، إلا أن التوصيات عامة حول مجموعات Kubernetes المخصصة المثبتة في الأنظمة المحلية. يمكنك استخدام الخطوات والاسكربتات المقدمة بين مجموعة Kubernetes أساسية تعمل في Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) ومجموعة ثانوية تعمل في مجموعة Kubernetes مخصصة أو محلية. يمكنك أيضًا استخدام الخطوات والاسكربتات بين مجموعة Kubernetes أساسية تعمل في OKE ومجموعة ثانوية تعمل أيضًا في OKE، أو بين مجموعتين محليتين أو مخصصتين من Kubernetes.

حول المنتجات والأدوار المطلوبة

يتطلب هذا الحل المنتجات والأدوار التالية:

• مجموعة Kubernetes
• عقدة Bastion قادرة على إدارة نظام kubernetes
• Oracle Cloud Infrastructure (OCI)

  يعتمد هذا الكتيب على استخدام مناطق OCI ومواردها للمناطق الأساسية والثانوية. ومع ذلك، ينطبق هذا الحل أيضًا على مجموعات Kubernetes غير الموجودة في OCI.

هذه هي الأدوار المطلوبة لكل خدمة.

اسم الخدمة: الدور	مطلوب لـ ...
Oracle Cloud Infrastructure: admin	توفير الموارد والخدمات وإعدادها إذا كنت تستخدم منطقة OCI واحدة أو أكثر.
مجموعة Kubernetes (الرئيسية): administrator	تشغيل كل الاسكربتات.
نقاط توصيل Kubernetes (الأساسية): مستخدم نظام التشغيل ذو أذونات التنفيذ وأذونات ssh الثانوية	قم بتشغيل الاسكربتات التالية: maak8-get-all-artifacts.sh maak8DR-apply.sh
Kubernetes Cluster (ثانوي): administrator	تشغيل كل الاسكربتات.
نقاط توصيل Kubernetes (الثانوية): مستخدم نظام التشغيل ذو أذونات التنفيذ	قم بتشغيل الاسكربتات التالية: removeyamlblock.sh apply-artifacts.sh maak8-push-all-artifacts.sh

اطلع على منتجات Oracle وحلولها وخدماتها للحصول على ما تريده.

سجل التغييرات

يسرد هذا السجل التغييرات الهامة:

يوليو 12؜ 2023

تمت مراجعة مخطط البنية. حسّنت المحتوى.