عندما تتحول البيانات إلى كارثة

نحن نعيش في عالم رقمي حيث تعد البيانات عنصرا حاسما في الأعمال التجارية. لكن في بعض الأحيان تؤثر الكوارث على البيانات الجيدة.

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

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

التخطيط للتعافي من الكوارث

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

الجواب القصير – نعم، هناك! التعافي من الكوارث هو مجموعة فرعية من التخطيط لاستمرارية الأعمال.

• يعمل التعافي من الكوارث (DR) على إحياء عمليات الشركة وعملياتها بمجرد وقوع الكارثة. يتعلق الأمر بإعادة الأشياء (مثل التطبيقات) – هذه هي الطريقة التي تستجيب بها لحدث مزعج.
• تركز استمرارية الأعمال (BC) على الخدمات ذات المهام الحرجة التي يحتاجها عملك حتى يعمل بشكل صحيح. يتعلق الأمر بالخدمات وإعادة المستخدمين إلى العمل.

افترض أنك تستخدم Gmail لإرسال واستقبال رسائل البريد الإلكتروني داخل مؤسستك وخارجها. حدثت كارثة لأي سبب كان، وجميع السيرفرات غير متوفرة. لإعطاء المزيد من الأمثلة التوضيحية لـ DR وBC، قم بإلقاء نظرة على ما يلي:

يعد التعافي من الكوارث جزءًا من التخطيط لاستمرارية الأعمال، ويتم استخدام كلا التعبيرين كـ BCDR في الصناعة. كلاهما يجيب على “ماذا لو حدثت كارثة؟” السؤال ونحدد معًا الخطوات التي يتعين عليك اتخاذها لضمان استمرارية العمل.

المقاييس الرئيسية لاستمرارية الأعمال – RTO وRPO

يعد هدف وقت الاسترداد وهدف نقطة الاسترداد معلمتين أساسيتين يجب أخذهما في الاعتبار عند التخطيط لـ BC:

• هدف وقت الاسترداد (RTO) – الحد الأقصى للطول المقبول الذي يمكن أن يكون فيه تطبيقك غير متصل بالإنترنت منذ الإعلان عن الكارثة. يتم تحديد هذه القيمة عادةً
  كجزء من اتفاقية مستوى الخدمة الأكبر.
• هدف نقطة الاسترداد (RPO) – الحد الأقصى للطول المقبول الذي قد يتم خلاله فقدان البيانات نتيجة لحدث كارثي. لاحظ أن هذا المقياس يصف طول الوقت فقط: فهو لا يتناول كمية أو جودة البيانات المفقودة.

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

تنمو تكلفة حلول التعافي من الكوارث بشكل كبير مع اقتراب متطلبات RPO وRTO من الصفر. عادةً ما يتم تجميع قيم RTO وRPO في مقياس آخر: هدف مستوى الخدمة. يعد SLO عنصرًا رئيسيًا قابلاً للقياس في SLA، على الرغم من أن SLAs وSLO غالبًا ما يتم الخلط بينهما:

• SLA هي الاتفاقية الكاملة التي تحدد الخدمة التي سيتم تقديمها، وكيفية دعمها، والأوقات، والمواقع، والتكاليف، والأداء، والعقوبات، ومسؤوليات الأطراف المعنية.
• SLOs هي خصائص محددة وقابلة للقياس لاتفاقية مستوى الخدمة، مثل التوفر أو الإنتاجية أو التردد أو وقت الاستجابة أو الجودة.

يمكن أن تحتوي اتفاقية SLA على العديد من SLOs. تعتبر RTOs وRPOs قابلة للقياس ويجب اعتبارها SLOs.

لماذا جوجل كلاود؟

يمكن تقليل التكلفة المرتبطة باستيفاء متطلبات RTO وRPO عند تنفيذ DR بشكل كبير على Google Cloud مقارنة بالتكلفة التقليدية داخل المؤسسة، كما أنها أسهل في التنفيذ.

هناك العديد من العناصر التي يجب أخذها في الاعتبار عند التخطيط لـ DR التقليدي داخل المؤسسة، بما في ذلك:

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

تشمل عيوب DR التقليدية داخل الشركة ما يلي:

• التعقيد — يمكن أن يكون موقع استرداد مركز البيانات المحلي معقدًا في إدارته وصيانته.
• التكاليف — قد يستغرق إنشاء موقع محلي وصيانته وقتًا طويلاً ومكلفًا للغاية.
• قابلية التوسع — يتطلب توسيع الموارد اتباع دورة شراء تقليدية، وهي ليست سريعة وتكلف الكثير من الوقت والمال.

يساعد Google Cloud Platform في التغلب على معظم هذه التحديات والعيوب إن لم يكن كلها. بالإضافة إلى ذلك، يقدم Google Cloud Platform العديد من الأدوات والإمكانيات التي تسمح للمؤسسات بالتخطيط بكفاءة للتعافي من الكوارث. مما لا شك فيه أن هناك فوائد معينة لـ DR في Google Cloud Platform، مثل:

• تكلفة معقولة — تتبع خدمات Google Cloud Platform نموذج تسعير الدفع حسب الاستخدام.
• إمكانية الوصول — ستكون قادرًا على الوصول إلى نظامك من أي مكان.

أنماط DR الشائعة

يوضح الرسم البياني أدناه أنماط DR التي يتم أخذها في الاعتبار في Google Cloud. تشير RTO وRPOs المختلفة إلى مدى سهولة استرداد النظام عند حدوث خطأ ما.

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

HA المنتشر هو HA بين المناطق ذات تجاوز الفشل الشفاف وموازنة التحميل. يجوز للعملاء استخدام مصطلحات مختلفة، على سبيل المثال، Geo HA، وActive/Active، وDisaster Prevention، وBusiness Contingency Group.

بنية أنماط DR

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

دكتور بارد

فيما يلي مثال على بنية أنماط DR الباردة، ونقل مثيل VM في منطقة جديدة (النسخ الاحتياطي والاستعادة).

تم اختيار أبسط نهج للمرونة باستخدام موارد المنطقة والاسترداد من خلال اللقطات مع مجموعات من الكتل البرمجية الإنشائية لتنفيذ منطقة DR باستخدام الأقراص واللقطات المنطقية:

• مجموعات المثيلات المدارة حسب المنطقة
• الأقراص المستمرة الإقليمية
• لقطات من القرص الثابت المتصل بـ VM1
• يتم استخدام النسخ المتماثل المتزامن بين إعداد المنطقة المزدوجة (الاستعداد النشط) لتحقيق منطقة DR.

تتم عمليات الاسترداد عن طريق:

• إنشاء أقراص ثابتة وVM2 من اللقطات في المنطقة الثانية
• تشغيل VM2 والإضافة إلى مجموعة LB الداخلية

يتم استخدام النسخ المتماثل المتزامن بين إعداد المنطقة المزدوجة (الاستعداد النشط) لتحقيق منطقة DR.

الدكتور الدافئ

لتحسين RPO، يمكن الاستفادة من الموارد الإقليمية لتجنب عمليات الاستعادة المستندة إلى اللقطة. قد يتطلب ذلك:

• استخدام الخدمات المُدارة مثل Cloud SQL مع ميزات النسخ المتماثل الأصلية
• الأقراص الثابتة الإقليمية مع النسخ المتماثل المتزامن

اعتمادًا على إعداد هذا النمط، يتم تنفيذ عمليات الاسترداد عن طريق:

• تفعيل المثيل الاحتياطي في المنطقة الثانوية
• إعادة تنشيط مثيل ثانوي في المنطقة الأساسية عندما يصبح متاحًا

حار د

يتم استخدام النسخ المتماثل المتزامن بين إعداد المنطقة المزدوجة (النشيطة النشطة) لتحقيق المنطقة DR.

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

• استخدام الخدمات المُدارة مثل Cloud SQL مع ميزات النسخ المتماثل الأصلية
• الأقراص الثابتة الإقليمية مع النسخ المتماثل المتزامن

اعتمادًا على إعداد هذا النمط، يتم تنفيذ عمليات الاسترداد عن طريق:

• تعزيز النسخة المتماثلة للقراءة في المنطقة الثانوية
• إعادة تنشيط مثيل ثانوي في المنطقة الأساسية عندما يصبح متاحًا

لتحقيق مرونة المنطقة المزدوجة مع النسخ المتزامن وغير المتزامن، قد يتطلب ذلك ما يلي:

• آليات النسخ المتطابق لقاعدة البيانات في المنطقة الأساسية مع مثيلات احتياطية في منطقة DR
• مثيل قاعدة بيانات مخصص للقطات قاعدة البيانات

تتم عمليات الاسترداد عن طريق:

• تجاوز فشل قاعدة البيانات (الثانوية إلى الأساسية أو المستندة إلى اللقطة)
• موازن الحمل الداخلي

HA المنتشرة

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

• مجموعات MIG الإقليمية والواجهات الأمامية النشطة عبر المناطق
• يعتمد على DNS أو موازنة التحميل العالمية لتوزيع حركة مرور المستخدم

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

• خدمات الواجهة الأمامية والخلفية النشطة النشطة
• خدمات مُدارة متعددة المناطق (على سبيل المثال، Cloud Spanner أو Cloud Storage)
• القياس التلقائي لزيادة القدرة في المنطقة الثانوية في حالة الفشل

الكلمات الأخيرة

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