ما المقصود بإجراءات مواجهة الكوارث؟

إن إجراءات مواجهة الكوارث (DR) هي أحد جوانب خطط استمرارية الأعمال الشاملة التي تم وضعها وصيانتها من قبل مختلف خطوط الأعمال داخل المؤسسة. تعمل الخطة الفعالة لإجراءات مواجهة الكوارث على التخفيف من تأثير المراحل غير المخطط لها - أو حتى المخطط لها - للأنظمة الحيوية للمهام والأعمال على قدرة المؤسسة على العمل والاستمرار في كسب الإيرادات.

للقيام بذلك، توفر خطة DR للمؤسسات بنية مرنة تمكنها من العمل بطريقة موحدة وتعاونية لاستعادة أنظمتها وإعادة تطويرها وتنشيطها وإنشاء بنية أساسية أكثر مرونة.

لماذا تعد إجراءات مواجهة الكوارث أمرًا مهمًا؟

كم من الوقت يمكن للشركة مواصلة العمل إذا خسرت نظام كشوف الرواتب الخاص بها قبل حساب الراتب وتمويل الحسابات؟ ما هي العقوبات التي ستفرضها الشركة بسبب تأخر دفع الضرائب الفيدرالية والولاية والمحلية؟ ما العواقب التي قد تواجهها الشركة نتيجة لعدم دفع رواتب الموظفين في الوقت المحدد-ومدة بقاء العمال يعملون؟

للقيام باستعادة البيانات بعد الكوارث أم لا؟ لم يعد هذا هو السؤال. والسؤال الحقيقي هو ما هي التكلفة الحقيقية لفقدان دقائق، أيام، أو أسابيع من البيانات الهامة والثقة بنيت على مر السنين في لحظة؟

لم يعد من الممكن أن يظل التعافي من الكوارث فكرة متأخرة أو شيئًا يتم النظر فيه فقط عندما تكون هناك ميزانية كافية لأن منظمات اليوم من المتوقع أن تستجيب على الفور للأحداث المعطلة وتظل تعمل. بدلاً من أن يتم ردعها بسبب تكلفة تنفيذ خطة المرونة، يجب على المؤسسات أن تتعمق وتقيّم التكلفة الحقيقية لعدم وجود خطة على الإطلاق. على سبيل المثال، فحص اتفاقيات مستوى الخدمة (SLA) التي تعذر استيفاؤها أو العقوبات وخسارة الإيرادات التي قد تنتج عن انقطاع مؤقت. قارن تكلفة تنفيذ إجراءات مواجهة الكوارث بالجزاءات وفقدان الإيرادات وفقدان ثقة العملاء والاختيار واضح.

الصورة بعنوان "الإيرادات والإنتاجية والولاء الضائع." توجد ثلاث إحصائيات رئيسية معروضة في هذه الصورة. تم استخلاص هذه الإحصاءات من دراسة بتكليف من Forrester Consulting نيابة عن IBM في عام 2019. السؤال الذي طرحه المجيبون على الاستطلاع هو "أي من التكاليف التالية التي تواجهها مؤسستك بسبب وقت التوقف المخطط وغير المخطط؟"
على الجانب الأيسر، تظهر الإحصائية المعروضة أن 53% من أولئك الذين شملهم الاستطلاع أجابوا "الإيرادات المفقودة". في الوسط، تظهر الإحصائية أن 47% ردوا على "فقدان الإنتاجية". ومن الجانب الأيمن، تُظهر الإحصائية أن 41% أجابوا على "فقدان قيمة العلامة التجارية أو الثقة".

الانقطاعات المؤقتة غير المخططة

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

وعلى الرغم من أن هذه النتائج تبدو مثيرة، إلا أنها تعكس التجارب الأخيرة للعديد من المؤسسات المعروفة التي فشلت في التعافي في الوقت المناسب وفقدت كميات كبيرة من بيانات المعاملات الهامة ومعلومات العملاء والثقة.

يمكن أن تؤدي مجموعة واسعة من السيناريوهات والأسباب الجذرية إلى تعطيل عمليات الأعمال.

عنوان هذه الصورة هو "أهم أسباب وقت التوقف غير المخطط له". تعرض الصورة مخططًا شريطيًا يعرض أسباب الانقطاعات المؤقتة غير المخططة. يتم تقسيم الرسم البياني الشريطي إلى ثلاث فئات: الإخفاقات التشغيلية والكوارث الطبيعية والأحداث التي يتسبب فيها الإنسان. يتم تجميع حالات الفشل التشغيلي في الجزء الأيسر من الرسم البياني الشريطي، والكوارث الطبيعية في الوسط، ويتم تجميع الأحداث التي تسببها الإنسان في الجزء الأيمن من الرسم البياني الشريطي. مصدر هذا المخطط هو Forrester Research، Inc.

الانقطاعات المؤقتة المخططة

توفر إجراءات مواجهة الكوارث كخدمة (DRaaS) في السحابة للمؤسسات خيارات لا مثيل لها لمرونة التشغيل. تستخدم المؤسسات حلول إجراءات مواجهة الكوارث للانقطاعات المخططة بشكل متكرر أكثر من التعافي من الأحداث الكارثية.

نقاط المعاناة المعتادة

• تتطلب النهج التقليدية لإجراءات مواجهة الكوارث استثمارات في الأتمتة.
• يمكن أن تتأثر أنظمة الأعمال في مراكز بيانات الطبقة الأولى بانقطاع التيار الكهربائي، وهو أمر متكرر للغاية. كم مرة يتسبب حادث شائع مثل انقطاع التيار الكهربائي في فقد يوم أو يومين من الإنتاجية؟ ينتهي موظفو تكنولوجيا المعلومات بإنفاق ساعات أو أيام عديدة على المكالمات الجماعية لإنشاء الأنظمة وتشغيلها مرة أخرى باستخدام حلول الإيقاف المؤقت. • تنفق بعض الشركات جزءًا كبيرًا من ميزانيات تكنولوجيا المعلومات الخاصة بها على تطوير الأتمتة الداخلية لإدارة إجراءات مواجهة الكوارث للخوف فقط من استخدامها - أو حتى اختبارها بشكل دوري لضمان استمرارها في العمل كما هو متوقع. • غالبًا ما يستغرق الأمر يومًا (أو أيامًا) للاسترداد من فترة الصيانة المخطط لها. • حتى خطط أو دفاتر DR الموثقة جيدًا قد تتضمن أيامًا من الإنتاجية المفقودة بينما يقوم موظفو عمليات تكنولوجيا المعلومات بأعمال بطولية لإعادة تشغيل الأشياء.

الأهداف الرئيسية لاستعادة القدرة على العمل بعد الكوارث

الهدفان الأساسيان لاستعادة البيانات بعد الكوارث هما إعادة الأنظمة المتأثرة إلى حالة تشغيلية في أسرع وقت ممكن والقيام بذلك بأقل قدر ممكن من فقدان البيانات بعد حدث كارثي أو انقطاع مخطط له. تُعرف مقاييس هذين الهدفين الرئيسيين عالميًا باسم هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO) على التوالي.

سيكون لكل نظام أعمال متطلبات مختلفة لهذين القياسين اعتمادًا على اتفاقية مستوى الخدمة بين عمليات تكنولوجيا المعلومات ومالكي الأعمال.

الصورة بعنوان "مصطلحات حماية البيانات". يتم وصف السماح بفقدان البيانات والتسامح مع وقت التوقف عن العمل على خط مستقيم يمتد في اتجاهات متعاكسة من مركز الصورة. وعلى اليمين، لديك "فقد للبيانات"، وعلى اليمين لديك "وقت التعطل".

هدف وقت الاسترداد

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

هدف نقطة الاسترداد

هدف نقطة الاسترداد هو الحد الأقصى من البيانات التي يمكن فقدانها قبل التسبب في ضرر ضار لأي نظام أعمال معين. عادة ما يتم قياس RPO في الوقت المناسب من دلتا آخر نسخة احتياطية للبيانات أو النسخ المتماثل أو اللقطة.

استرداد البيانات بعد الكوارث مقابل التوفر العالي

عادةً ما يحمي التوافر العالي (HA) من نقاط الفشل المفردة، بينما يحمي الاستعادة من الكوارث من نقاط الفشل المتعددة. في الحوسبة السحابية، يتم تجريد الحماية ضد نقاط الفشل الفردية في طبقة البنية الأساسية المادية، بما في ذلك الطاقة والتبريد والتخزين والشبكات والخوادم المادية، بالكامل في البنية الشاملة من خلال نطاقات التوافر والخطأ.

والتوافر العالي في هذه الحالة قابل للتوسع ومرن للغاية لفقدان البيانات أو فقدان أداء المعالجة. يبني كل موفر خدمة سحابية على مستوى المؤسسات تقريبًا توافرًا كبيرًا في عرضهم.

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

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

DR المحلي هو حل غير مرن ومكلف بسبب التكلفة العالية لنسخ البنية الأساسية لتكنولوجيا المعلومات في موقع مصدر وموقع مركز بيانات هدف ثابت. ولا يمكنها العمل عبر شبكة WAN أو ترحيل الخوادم بين البيئات المختلفة، لذلك فهي تتطلب دائرة مخصصة بين مراكز البيانات المصدر والهدف للعمل كبيئة LAN واحدة مترابطة. لا يمكن لـ DR التقليدي أيضًا ترحيل الخوادم بين البيئات المتباينة غير المتجانسة، مثل بيئة محلية ونظام أساسي سحابي أو بين نظامين أساسيين سحابيين مختلفين.

DRaaS يستخدم مجموعة من حلول النسخ الاحتياطي التي يوفرها البائع وأدوات الترحيل مفتوحة المصدر لإنشاء بيئة يتم التحكم فيها بإحكام ومحددة للغاية. يمكن للمستخدم استعادة أحمال العمل فقط في بيئة الاستضافة التقليدية لموفر DRaaS من بيئته المحلية VMware. قد تكون هذه الحلول التي يوفرها البائع مكلفة ومحدودة في مجموعة أحمال العمل التي يمكنهم حمايتها وبيئات الحوسبة التي يمكنهم دعمها.

عمليات سير عمل وكتيبات تشغيل وخطط DR

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

عمليات DR (التبديل مقابل تجاوز الفشل)

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

تجاوز الفشل

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

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

تبديل

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

استراتيجية نشر السحابة

قد تستفيد المؤسسات الحديثة من نموذج أو أكثر من نماذج نشر السحابة التالية لمجموعة متنوعة من الأسباب، بما في ذلك متطلبات التكلفة والأداء واستمرارية الأعمال. أصبحت إستراتيجية النشر السحابي القوية أكثر انتشارًا مع استمرار الشركات في نقل العمليات إلى السحابة.

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

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

DRaaS يجب أن تكون الحلول قادرة على نقل نظام المؤسسة بأكمله، مثل بوابة الموارد البشرية، أو بوابة الخدمات المالية، أو تطبيق إدارة موارد المؤسسة، إلى منطقة سحابية مختلفة تمامًا. يجب أن يكون DRaaS قادرًا على تحقيق أهداف وقت الاسترداد ونقطة الاسترداد المطلوبة من خلال اتفاقيات مستوى الخدمة لكل تطبيق فردي.

تعمل حلول إجراءات مواجهة الكوارث عبر الإقليمية، مثل Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery على حماية تطبيقات المؤسسة بأكملها من فقدان الوصول الكارثي إلى منطقة سحابية بأكملها، بما في ذلك فقدان جميع نطاقات التوافر في تلك المنطقة.

حلول DR للسحابة المختلطة

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

بالنسبة لعملاء Oracle، السحابة المختلطة هي اتحاد غير محكمة بين OCI والخوادم المادية أو أجهزة Oracle السحابية أو الأنظمة الأخرى في مركز البيانات الفعلي للشركة. تُعد أجهزة Oracle cloud مثل Oracle Private Cloud Appliance X9-2 وOracle Exadata Cloud@Customer أمثلة ممتازة على الأنظمة المحلية التي تتكامل بشكل جيد مع OCI.

يمكن استخدام بعض المنتجات من شركاء Oracle، مثل Rackware، لتحقيق DR بين البنية الأساسية المحلية وOCI. تتوفر Rackware من خلال Oracle Cloud Marketplace.

حلول DR متعددة السحابات

تحمي حلول DR المتعددة السحابات التطبيقات والبيانات من خلال نشر المكونات المختلفة لمجموعة تطبيقات عبر البنى الأساسية للسحابة الخاصة بموفرين أو أكثر من موفري السحابة. تعد شراكة Oracle مع Microsoft Azure مثالًا جيدًا على علاقة متعددة السحابات.

يجب أن تكون إجراءات مواجهة الكوارث كخدمة قادرة على استيعاب إجراءات مواجهة الكوارث عبر الإقليمية وإجراءات مواجهة الكوارث السحابية الهجينة وإجراءات مواجهة الكوارث متعددة السحابات. يمكن لـ OCI حاليًا توفير DRaaS لـ DR الأقاليمي وDR للسحابة الهجينة.

اتساق البيانات لقواعد البيانات

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

يقل اتساق البيانات إلى حد كبير عن مشكلة قواعد بيانات الملفات الموحدة أو بدون خوادم، ولكن استعادة قواعد البيانات الارتباطية المتطورة، مثل Oracle Database أو MySQL، إلى حالة اتساق البيانات بالنسبة إلى نقطة زمنية معينة معقدة للغاية - حتى الآن لا تزال حاسمة.

اعتبارات استعادة القدرة على العمل بعد الكوارث لقواعد بيانات MySQL

عند استخدام خدمة MySQL Database في OCI، يكون نظام قاعدة البيانات MySQL عبارة عن حاوية منطقية لطبعة MySQL واحدة أو أكثر. يوفر واجهة تتيح إدارة المهام مثل التزويد والنسخ الاحتياطية التلقائية والاسترداد في وقت معين.

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

يحتوي نظام قاعدة البيانات الممكن به التوافر العالي على ثلاث طبعات MySQL موضوعة في نطاقات توافر مختلفة أو نطاقات خطأ. يضمن نظام قاعدة البيانات أنه في حالة فشل أحد المثيلات، يتولى مثيل آخر المسؤولية، مع عدم فقدان البيانات والحد الأدنى من وقت التوقف عن العمل. بالنسبة إلى إجراءات مواجهة الكوارث في مناطق مختلفة، يمكن أيضًا إنشاء قنوات استنساخ واردة بين نظامين لقاعدة البيانات.

استخدم الارتباطات التالية لمعرفة المزيد حول إجراءات مواجهة الكوارث لـ MySQL في السحابة.

• نظرة عامة على استمرارية الأعمال لـ MySQL
• نظرة عامة على التوفر العالي لـ MySQL
• نظرة عامة على استنساخ الوارد لـ MySQL

اعتبارات استرداد البيانات بعد الكوارث لقواعد بيانات Oracle

يوفر Oracle Maximum Availability Architecture (MAA) أفضل ممارسات الهندسة المعمارية والتكوين ودورة الحياة لقواعد بيانات Oracle، مما يتيح مستويات خدمة عالية التوافر لقواعد البيانات الموجودة في التكوينات المحلية أو السحابية أو المختلطة.

استخدم الارتباطات التالية لمعرفة المزيد حول Oracle Maximum Availability Architecture لإجراءات مواجهة الكوارث داخل السحابة.

• الصفحة الرئيسية لـ Oracle Maximum Availability Architecture
• البُنى المرجعية لـ Oracle Maximum Availability Architecture
• Oracle Maximum Availability Architecture أفضل الممارسات لـ Oracle Fusion Middleware
• Oracle Maximum Availability Architecture أفضل الممارسات للتطبيقات

بنى النشر المستندة إلى السحابة

تصف بنية النشر كيفية نشر المكونات المختلفة مثل الحوسبة والنظام الأساسي/قاعدة البيانات والتطبيقات بين مناطق السحابة لإنشاء وسيلة مرنة للاسترداد من الفشل الكلي لمركز البيانات. تصف بنية النشر أين يوجد كل شيء أثناء التشغيل العادي لمجموعة التطبيقات وما يجب استرداده في المنطقة الاحتياطية لإعادة تشغيل الأشياء.

تعتقد Oracle أن حلول DRaaS يجب أن تتمتع بالمرونة لتضمين أي مجموعة من بنيات نشر DR لتلبية متطلبات مستوى الخدمة الفردية لكل نظام أعمال فريد. يجب أن يمنح موفرو السحابة عملاءهم الحرية في اختيار "جميع الحلول المذكورة أعلاه" للوفاء باتفاقيات مستوى الخدمة (SLA) لمجموعة واسعة من أنظمة الأعمال التي تدعمها المؤسسات عادةً.

تُستخدم العديد من المصطلحات لوصف إستراتيجيات إجراءات مواجهة الكوارث وبنى النشر. ومع ذلك، فإن مختلف النهج والأنماط لوصف كيفية نشر البنية التحتية والمنصة والتطبيقات لاستعادة القدرة على العمل بعد الكوارث تقع في فئتين استراتيجيتين عريضتين: DR النشطة/النشطة/الجاهزة.

يوضح الجدول التالي المصطلحات الشائعة المستخدمة لوصف بنى النشر المختلفة التي تقع ضمن إستراتيجيتين كبيرتين لإدارة علاقات العملاء (DR).

الاستراتيجية	بنية النشر	طلب شراء خاص	نقط الاسترداد الهدف
نشط/بديل	الاستعداد البارد	الساعات	الساعات
نشط/بديل	الضوء التجريبي	دقائق	الساعات
نشط/بديل	استراتيجية Warm standby (الاستعداد الدافئ)	الثواني	الساعات
نشط/بديل	استراتيجية Hot standby (الاستعداد السريع)	الثواني	دقائق
نشط/نشط	نشط/نشط	قريب من الصفر	قريب من الصفر

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

بنى النشر النشطة/ البديلة

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

تمثل كل من الإضاءة التجريبية والاستعداد البارد والاستعداد الدافئ والسيناريوهات الاستعدادية السريعة شكلاً من أشكال الموضوع نفسه الذي يعمل فيه 100% من مجموعة التطبيقات في المنطقة الأساسية بينما يعمل أقل من 100% من نفس نظام الأعمال بنشاط في المنطقة الاحتياطية.

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

الاستعداد البارد

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

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

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

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

معظم عمليات تكنولوجيا المعلومات تحل هذه المشكلة من خلال إغلاق قاعدة البيانات بشكل دوري، مع تسجيل لقطة من تخزين الكتل، ثم استئناف العمليات العادية. يعرف هذا هدف نقطة الاستعادة حيث يمكنك الاستعادة إلى نقطة اكتمال النسخ الاحتياطي فقط.

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

مثال على عمليات سير عمل DR لبنية التوزيع هذه

يوضح السيناريوان التاليان كيف يمكن أن يتقدم تدفق العملية لعمليات الاسترداد DR لعمليات النشر الاحتياطية الباردة.

في حالة التبديل، يتم تنفيذ المهام التالية في كل من المنطقتين الأساسية والبديلة:

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

في حالة الانتقال عقب الفشل، يتم تنفيذ المهام التالية فقط في منطقة الاستعداد:

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

استراتيجية Warm standby (الاستعداد الدافئ)

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

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

يجب أن تعمل قواعد البيانات في كل من المنطقتين الأساسية والبديلة.

بالنسبة لقواعد بيانات Oracle، نوصي باستخدام Oracle Data Guard لنسخ قاعدة البيانات الأساسية والبديلة. لمزيد من التفاصيل، ارجع إلى البنية المرجعية الذهبية MAA.

بالنسبة لقواعد البيانات من غير Oracle، سيتم استخدام تقنيات النسخ المتماثل الأصلية ذات الصلة للحفاظ على تزامن قواعد البيانات بين المناطق الأساسية والمناطق البديلة.

توجد التطبيقات أيضًا في منطقة السحابة البديلة ولكنها لا تعمل أو يمكن الوصول إليها.

مثال على عمليات سير عمل DR لبنية التوزيع هذه

يوضح السيناريوان التاليان كيفية تقدم تدفق العملية لعمليات الاسترداد DR لعمليات النشر الاحتياطية السريعة.

في حالة التبديل، يتم تنفيذ المهام التالية في كل من المنطقتين الأساسية والبديلة:

• تم إيقاف تشغيل التطبيقات الأساسية.
• يتم تشغيل قواعد البيانات الأساسية ومزامنتها مع المنطقة البديلة.
• يتم إيقاف الأجهزة الافتراضية الأساسية بشكل جيد.
• تمت مزامنة التخزين الأساسي مع المنطقة البديلة.
• يتم إحضار التخزين المتماثل عبر الإنترنت ، ويتم عكس النسخ المتماثل، وهو الآن أساسي في منطقة الاستعداد.
• يتم تشغيل الأجهزة الافتراضية البديلة إن لم تكن قيد التشغيل بالفعل، كما يتم بدء تشغيل أي تطبيقات أو أدوات نظام مطلوبة بواسطة حزمة التطبيقات وتصبح الآن أساسية في المنطقة البديلة.
• يتم تحويل قواعد البيانات البديلة إلى الوصول الكامل للقراءة/الكتابة وهي الآن أساسية في المنطقة البديلة.
• يتم تشغيل التطبيقات البديلة ومراجعتها وهي الآن أساسية في المنطقة الاحتياطية.
• يتم إجراء أي تغييرات على DNS وموازنات التحميل لتمكين الوصول إلى التطبيق عبر الشبكة العامة.

في حالة الانتقال عقب الفشل، يتم تنفيذ المهام التالية فقط في منطقة الاستعداد:

• يتم نقل التخزين المكرر عبر الإنترنت، ويتم عكس عملية النسخ المماثل إن أمكن، ويصبح التخزين الأساسي في منطقة الاستعداد.
• يتم تشغيل الأجهزة الافتراضية البديلة إن لم تكن قيد التشغيل بالفعل، كما يتم بدء تشغيل أي تطبيقات أو أدوات نظام مطلوبة بواسطة حزمة التطبيقات وتصبح الآن أساسية في المنطقة البديلة.
• يتم استرداد قواعد البيانات البديلة باستخدام أحدث سجلات العمليات والإعادة من التخزين المتكرر.
• يتم تحويل قواعد البيانات البديلة إلى الوصول الكامل للقراءة/الكتابة وهي الآن أساسية في المنطقة البديلة.
• يتم تشغيل التطبيقات البديلة ومراجعتها وهي الآن أساسية في المنطقة الاحتياطية.
• يتم إجراء أي تغييرات على DNS وموازنات التحميل لتمكين الوصول إلى التطبيق عبر الشبكة العامة.

استراتيجية Hot standby (الاستعداد السريع)

في هذا السيناريو، توجد أجهزة افتراضية وتعمل في المنطقتين الأساسية والبديلة بأسماء مضيفين فريدين وعناوين IP معينة مسبقًا.

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

يجب أن تعمل قواعد البيانات في كل من المنطقتين الأساسية والبديلة.

بالنسبة لقواعد بيانات Oracle، نوصي باستخدام Oracle Data Guard لنسخ قاعدة البيانات الأساسية والبديلة. لمزيد من التفاصيل، ارجع إلى البنية المرجعية الذهبية MAA.

بالنسبة لقواعد البيانات من غير Oracle، سيتم استخدام تقنيات النسخ المتماثل الأصلية ذات الصلة للحفاظ على تزامن قواعد البيانات بين المناطق الأساسية والمناطق البديلة.

تعمل التطبيقات في منطقة السحابة البديلة، ولكنها لا يمكن الوصول إليها عبر الشبكة العامة.

مثال على عمليات سير عمل DR لبنية التوزيع هذه

يوضح السيناريوان التاليان كيفية تقدم تدفق عملية عمليات الاسترداد DR لعمليات النشر الاحتياطية السريعة.

في حالة التبديل، يتم تنفيذ المهام التالية في كل من المنطقتين الأساسية والبديلة:

• تم إيقاف تشغيل التطبيقات الأساسية.
• يتم تشغيل قواعد البيانات الأساسية ومزامنتها مع المنطقة البديلة.
• يتم إيقاف الأجهزة الافتراضية الأساسية بشكل جيد.
• تمت مزامنة التخزين الأساسي مع المنطقة البديلة.
• يتم إحضار التخزين المتماثل عبر الإنترنت ، ويتم عكس النسخ المتماثل، وهو الآن أساسي في منطقة الاستعداد.
• يتم تشغيل الأجهزة الافتراضية الاحتياطية بالفعل، ويتم بدء تشغيل أي تطبيقات أو أدوات نظام مطلوبة بواسطة مجموعة التطبيقات، وهي الآن أساسية في المنطقة البديلة.
• يتم تحويل قواعد البيانات البديلة إلى الوصول الكامل للقراءة/الكتابة وهي الآن أساسية في المنطقة البديلة.
• يتم تشغيل التطبيقات البديلة ومراجعتها وهي الآن أساسية في المنطقة الاحتياطية.
• يتم إجراء أي تغييرات على DNS وموازنات التحميل لتمكين الوصول إلى التطبيق عبر الشبكة العامة.

في حالة الانتقال عقب الفشل، يتم تنفيذ المهام التالية فقط في منطقة الاستعداد:

• يتم نقل التخزين المكرر عبر الإنترنت، ويتم عكس عملية النسخ المماثل إن أمكن، ويصبح التخزين الأساسي في منطقة الاستعداد.
• يتم تشغيل الأجهزة الافتراضية البديلة إن لم تكن قيد التشغيل بالفعل، كما يتم بدء تشغيل أي تطبيقات أو أدوات نظام مطلوبة بواسطة حزمة التطبيقات وتصبح الآن أساسية في المنطقة البديلة.
• يتم استرداد قواعد البيانات البديلة باستخدام أحدث سجلات العمليات والإعادة من التخزين المتكرر.
• يتم تحويل قواعد البيانات البديلة إلى الوصول الكامل للقراءة/الكتابة وهي الآن أساسية في المنطقة البديلة.
• يتم تشغيل التطبيقات البديلة ومراجعتها وهي الآن أساسية في المنطقة الاحتياطية.
• يتم إجراء أي تغييرات على DNS وموازنات التحميل لتمكين الوصول إلى التطبيق عبر الشبكة العامة.

بنية نشر نشطة/نشطة

في هذا السيناريو، تعمل مجموعة التطبيقات بالكامل وتعالج حمل العمل في كل من المنطقتين الأساسية والاستعدادية.

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

يجب أن تعمل قواعد البيانات في كل من المنطقتين الأساسية والبديلة.

بالنسبة لقواعد بيانات Oracle، نوصي باستخدام Oracle GoldenGate للحصول على تكوين تطبيق نشط/نشط. وبصرف النظر عن ذلك، نوصي بوجود قواعد بيانات بديلة محلية في كل منطقة باستخدام Oracle Data Guard لتحقيق RTO وRPO تقريبًا. لمزيد من التفاصيل، ارجع إلى البنية المرجعية البلاتينية MAA.

بالنسبة لقواعد البيانات من غير Oracle، سيتم استخدام تقنيات الاستنساخ الأصلية والتقنيات النشطة/النشطة للحفاظ على تزامن قاعدة البيانات بين المناطق الأساسية والمناطق البديلة.

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

أتمتة مهام إجراءات مواجهة الكوارث باستخدام DRaaS

تطرّقت فرق Oracle بأطوال كبيرة لتصميم توافر عالٍ في منتجاتها، بما في ذلك الغالبية العظمى من قواعد البيانات والتطبيقات من فئة المؤسسات من Oracle، وغالبًا ما تبتكر أفضل الممارسات وبنى النشر لتحقيق التعافي من الكوارث في الإعدادات المحلية التقليدية وكذلك في السحابة. يضع كل خط إنتاج نهج DR لتطبيقاته الفردية التي تتضمن خطوات مقترنة بشكل فضفاض لاستعادة جميع المكونات اللازمة لدعم تطبيقها.

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

تدير OCI Full Stack Disaster Recovery انتقال البنية الأساسية وقواعد البيانات والتطبيقات بين مناطق OCI من أي مكان في العالم بنقرة واحدة. يمكن للعملاء نشر بيئات استعادة القدرة على العمل بعد الكوارث دون إعادة تصميم أو إعادة نشر البنية الأساسية أو قواعد البيانات أو التطبيقات الحالية مع التخلص من الحاجة إلى خوادم إدارة متخصصة أو تحويل.

• تعرّف على المزيد حول OCI Full Stack Disaster Recovery
• تعرف على المزيد حول استعادة القدرة على العمل بعد الكوارث في OCI