مشاركة عبر

استراتيجيات الاسترداد بعد الكوارث للتطبيقات التي تستخدم تجمعات مرنة لقاعدة بيانات Azure SQL

  • مقالة

ينطبق على: قاعدة بيانات Azure SQL

توفر قاعدة بيانات Azure SQL العديد من القدرات لتوفير استمرارية العمل لتطبيقك عند حدوث حوادث كارثية. تدعم التجمعات المرنة وقواعد البيانات المفردة نفس النوع من قدرات الاسترداد بعد الكوارث (DR). توضح هذه المقالة العديد من استراتيجيات الاسترداد بعد الكوارث للتجمعات المرنة التي تستفيد من هذه الميزات لاستمرار الأعمال بقاعدة بيانات Azure SQL.

يستخدم هذا المقال نمط تطبيق SaaS ISV الأساسي التالي:

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

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

ملاحظة

إذا كنت تستخدم قواعد بيانات Premium أو Business Critical والتجمعات المرنة، يمكنك جعلها مرنة أمام انقطاعات إقليمية بتحويلها إلى تكوين نشر المنطقة المكررة. راجع قواعد بيانات المنطقة المكررة.

السيناريو 1. بدء التشغيل الحساس للتكلفة

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

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

Figure 1

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

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

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

Figure 2

إذا كان الانقطاع مؤقتًا، فمن الممكن أن يتم استرداد المنطقة الأساسية بواسطة Azure قبل اكتمال كافة عمليات استعادة قاعدة البيانات في منطقة الاسترداد. وفي هذه الحالة، قم بتنسيق نقل التطبيق مرة أخرى إلى المنطقة الأساسية. تأخذ العملية الخطوات الموضحة في الرسم التخطيطي التالي.

  • إلغاء كافة طلبات الاستعادة الجغرافية المعلقة.
  • تجاوز فشل قواعد بيانات الإدارة إلى المنطقة الأساسية (5). وبعد تعافي المنطقة، أصبحت الأساسيات القديمة ثانويات تلقائيًا. والآن يقومون بتبديل الأدوار مرة أخرى.
  • قم بتغيير سلسلة اتصال التطبيق للإشارة إلى المنطقة الأساسية. والآن تم إنشاء كافة الحسابات الجديدة وقواعد بيانات المستأجر في المنطقة الأساسية. يرى العملاء الحاليون بياناتهم غير متوفرة مؤقتًا.
  • قم بتعيين كافة قواعد البيانات في تجمع الاسترداد بعد الكوارث للقراءة فقط، للتأكد من أنها لا يمكن تعديلها في منطقة الاسترداد بعد الكوارث (6).
  • ولكل قاعدة بيانات في تجمع الاسترداد بعد الكوارث تم تغييرها منذ الاسترداد، قم بإعادة تسمية قواعد البيانات المقابلة أو حذفها في التجمع الأساسي (7).
  • انسخ قواعد البيانات المحدثة من تجمع الاسترداد بعد الكوارث إلى التجمع الأساسي (8).
  • احذف تجمع الاسترداد بعد الكوارث (9)

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

Figure 3

الميزة

تتمثل الفائدة الرئيسة لهذه الاستراتيجية في انخفاض التكلفة الجارية لتكرار مستوى البيانات. تقوم قاعدة بيانات Azure SQL تلقائيًا بالنسخ الخلفي لقواعد البيانات مع عدم حدوث إي إعادة كتابة للتطبيق دون أي تكلفة إضافية. ولا تتكبد التكلفة إلا عندما تتم استعادة قواعد البيانات المرنة.

المفاضلة

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

السيناريو 2. تطبيق مكتمل بخدمة متدرجة

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

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

Diagram shows a primary region and a D R region which employ geo-replication between the management database and paid customers primary pool and secondary pool with no replication for the trial customers pool.

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

قواعد بيانات المستأجرين للعملاء الذين يدفعون لديها قواعد بيانات نشطة في التجمع "المدفوع" الموجود في المنطقة الأساسية. قم بتوفير تجمع ثانوي بنفس الاسم في منطقة الاسترداد. يتم نسخ كل مستأجر جغرافيًا إلى التجمع الثانوي (2). وهذا يتيح الاسترداد السريع لكافة قواعد بيانات المستأجر باستخدام تجاوز الفشل.

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

Diagram shows an outage for the primary region, with failover to the management database, paid customer secondary pool, and creation and restore for trial customers.

  • قم بتجاوز الفشل مباشرة عبر قواعد بيانات الإدارة إلى منطقة الاسترداد (3).
  • قم بتغيير سلسلة اتصال التطبيق للإشارة إلى منطقة الاسترداد. والآن تم إنشاء كافة الحسابات الجديدة وقواعد بيانات المستأجر في منطقة الاسترداد. يرى العملاء التجريبيون الحاليون بياناتهم غير متوفرة مؤقتًا.
  • قم بتجاوز الفشل لقواعد بيانات المستأجر المدفوعة إلى التجمع في منطقة الاسترداد لاسترداد توفرها على الفور (4). ونظرًا لأن تجاوز الفشل هو تغيير سريع في مستوى بيانات التعريف، فكر في تحسين يتم فيه تشغيل عمليات تجاوز الفشل الفردية عندما تطلبها اتصالات المستخدم النهائي.
  • إذا كان حجم eDTU التجمع الثانوي أو قيمة vCore أقل من الأساسي؛ لأن قواعد البيانات الثانوية تتطلب فقط القدرة على معالجة سجلات التغيير عندما تكون ثانويات، قم على الفور بزيادة سعة التجمع لاستيعاب عبء العمل الكامل لجميع المستأجرين (5).
  • قم بإنشاء تجمع مرن جديد بنفس الاسم والتكوين في منطقة الاسترداد لقواعد بيانات العملاء التجريبيين (6).
  • وبمجرد إنشاء تجمع العملاء التجريبيين، استخدم الاستعادة الجغرافية لاستعادة قواعد بيانات المستأجر للأفراد التجريبيين في التجمع الجديد (7). يمكنك التفكير في تشغيل الاستعادة الفردية بواسطة اتصالات المستخدم النهائي أو استخدام نظام أولوية خاص بالتطبيق.

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

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

Diagram shows failback steps to implement after restoring the primary region.

  • إلغاء كافة طلبات الاستعادة الجغرافية المعلقة.
  • تجاوز الفشل عبر قواعد بيانات الإدارة (8). وبعد تعافي المنطقة، أصبحت الأساسيات القديمة ثانويات تلقائيًا. والآن أصبحت أساسيات مرة أخرى.
  • تجاوز الفشل عبر قواعد بيانات المستأجر المدفوعة (9). وبالمثل، بعد استرداد المنطقة، أصبحت الأساسيات القديمة ثانويات تلقائيًا. والآن أصبحت أساسيات مرة أخرى.
  • قم بتعيين قواعد البيانات التجريبية المستعادة التي تم تغييرها في منطقة الاسترداد للقراءة فقط (10).
  • ولكل قاعدة بيانات في تجمع الاسترداد للعملاء التجريبيين قد تغيرت منذ الاسترداد، قم بإعادة تسمية قاعدة البيانات المقابلة في تجمع العملاء التجريبي الأساسي أو حذفها (11).
  • انسخ قواعد البيانات المحدثة من تجمع الاسترداد بعد الكوارث إلى التجمع الأساسي (12).
  • احذف تجمع الاسترداد بعد الكوارث (13).

ملاحظة

عملية تجاوز الفشل غير متزامنة. لتقليل وقت الاسترداد، من المهم تنفيذ أمر تجاوز الفشل لقواعد بيانات المستأجر في دفعات تتكون من 20 قاعدة بيانات على الأقل.

الميزة

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

المفاضلة

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

السيناريو 3. تطبيق موزع جغرافيًا مع خدمة متدرجة

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

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

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

Diagram shows a primary region called Region A and secondary region called Region B which employ geo-replication between the management database and paid customers primary pool and secondary pool with no replication for the trial customers pool.

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

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

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

Diagram shows an outage for the primary region, with failover to the management database, paid customer secondary pool, and creation and restore for trial customers to region B.

  • قم بتجاوز الفشل مباشرة عبر قواعد بيانات الإدارة إلى منطقة الاسترداد (3).
  • قم بتغيير سلسلة اتصال التطبيق للإشارة إلى قواعد بيانات الإدارة في المنطقة (ب). وقم بتعديل قواعد بيانات الإدارة للتأكد من إنشاء الحسابات الجديدة وقواعد بيانات المستأجر في المنطقة (ب)، وتواجد قواعد بيانات المستأجر الموجودة هناك أيضًا. يرى العملاء التجريبيون الحاليون بياناتهم غير متوفرة مؤقتًا.
  • قم بتجاوز الفشل لقواعد بيانات المستأجر المدفوعة إلى التجمع (2) في المنطقة (ب) لاسترداد توفرها على الفور (4). ونظرًا لأن تجاوز الفشل هو تغيير سريع في مستوى بيانات التعريف، فكر في تحسين يتم فيه تشغيل عمليات تجاوز الفشل الفردية عندما تطلبها اتصالات المستخدم النهائي.
  • ونظرًا لأن التجمع (2) الآن يحتوي على قواعد البيانات الأساسية فقط، يزداد إجمالي عبء العمل في التجمع، وقد يؤدي إلى الزيادة الفورية في حجم eDTU (5) أو عدد vCores.
  • قم بإنشاء تجمع مرن جديد بنفس الاسم والتكوين في المنطقة (ب) لقواعد بيانات العملاء التجريبيين (6).
  • وبمجرد إنشاء التجمع، استخدام الاستعادة الجغرافية لاستعادة قاعدة بيانات المستأجر التجريبي الفردية في التجمع (7). يمكنك التفكير في تشغيل الاستعادة الفردية بواسطة اتصالات المستخدم النهائي أو استخدام نظام أولوية خاص بالتطبيق.

ملاحظة

عملية تجاوز الفشل غير متزامنة. لتقليل وقت الاسترداد، من المهم تنفيذ أمر تجاوز الفشل لقواعد بيانات المستأجر في دفعات تتكون من 20 قاعدة بيانات على الأقل.

وعند هذه النقطة، يعود تطبيقك متصلًا بالإنترنت في المنطقة (ب). ويمكن لجميع العملاء الذين يدفعون الوصول إلى بياناتهم، بينما يواجه العملاء التجريبيون تأخيرًا عند الوصول إلى بياناتهم.

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

Diagram shows failback steps to implement after restoring Region A.

  • قم بإلغاء كافة طلبات الاستعادة الجغرافية المعلقة بتجمع الاسترداد التجريبي.
  • تجاوز الفشل عبر قواعد بيانات الإدارة (8). وبعد تعافي المنطقة، أصبحت الأساسيات القديمة ثانويات تلقائيًا. والآن أصبحت أساسيات مرة أخرى.
  • حدد أي من قواعد بيانات المستأجر المدفوعة عليها العودة مرة أخرى في التجمع (1)، وابدأ تجاوز الفشل إلى الثانويات الخاصة بها (9). بعد استرداد المنطقة، أصبحت كافة قواعد البيانات في التجمع (1) ثانويات تلقائيًا. والآن 50% منهم أصبحت أساسيات مرة أخرى.
  • قم بخفض حجم التجمع (2) إلى eDTU (10) أو عدد vCores الأصليين.
  • قم بتعيين كافة قواعد البيانات التجريبية المستعادة في المنطقة (ب) للقراءة فقط (11).
  • ولكل قاعدة بيانات في تجمع الاسترداد التجريبي تم تغييرها منذ الاسترداد، قم بإعادة تسمية قواعد البيانات المقابلة أو حذفها في التجمع الأساسي (12).
  • انسخ قواعد البيانات المحدثة من تجمع الاسترداد بعد الكوارث إلى التجمع الأساسي (13).
  • احذف تجمع الاسترداد بعد الكوارث (14).

الميزة

الفوائد الرئيسية لهذه الاستراتيجية هي:

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

المفاضلات

المفاضلات الرئيسة هي:

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

الملخص

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

الخطوات التالية