مشاركة عبر

تصميم الخدمات العمومية المتاحة باستخدام قاعدة بيانات Azure SQL

  • مقالة

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

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

ملاحظة

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

السيناريو 1: استخدام منطقتين من مناطق Azure لاستمرارية الأعمال بأقل وقت تعطل

في هذا السيناريو، تتسم التطبيقات بالخصائص التالية:

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

في هذه الحالة، يتم تحسين تخطيط شبكة نشر التطبيق للتعامل مع الكوارث الإقليمية عندما تحتاج جميع مكونات التطبيق إلى الفشل معًا. يظهر المخطط التالي تخطيط الشبكة. بالنسبة إلى التكرار الجغرافي، يتم نشر موارد التطبيق في المنطقة "A" و "B". ومع ذلك، لا يتم استخدام الموارد في المنطقة "B" حتى تفشل المنطقة "A". يتم تكوين مجموعة تجاوز الفشل بين المنطقتين لإدارة اتصال قاعدة البيانات والنسخ المتماثل وتجاوز الفشل. تم تكوين خدمة الويب في كلا المنطقتين للوصول إلى قاعدة البيانات عبر وحدة الاستماع للقراءة والكتابة < failover-group-name > .database.windows.net (1). تم إعداد Azure Traffic Manager لاستخدام طريقة التوجيه ذات الأولوية (2).  

ملاحظة

يتم استخدام Azure Traffic Manager في جميع أنحاء هذه المقالة لأغراض التوضيح فقط. يمكنك استخدام أي حل موازنة التحميل يدعم طريقة التوجيه ذات الأولوية.

يوضح الرسم البياني التالي هذا التكوين قبل الانقطاع:

Scenario 1. Configuration before the outage.

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

ملاحظة

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

Scenario 1. Configuration after failover

إذا حدث انقطاع في المنطقة B، يتم تعليق عملية النسخ المتماثل بين قاعدة البيانات الأساسية والثانوية ولكن الارتباط بين الاثنين يظل سليمًا (1). يكتشف Traffic Manager أن الاتصال بالمنطقة B معطل ويضع علامة على تطبيق الويب الخاص بنقطة النهاية 2 على أنه منخفض (2). لا يتأثر أداء التطبيق في هذه الحالة، ولكن تصبح قاعدة البيانات مكشوفة وبالتالي تكون أكثر عرضة لفقدان البيانات في حالة فشل المنطقة A على التوالي.

ملاحظة

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

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

ملاحظة

بعد تخفيف الانقطاع، سيبدأ مدير حركة المرور في توجيه الاتصالات إلى التطبيق في المنطقة A كنقطة نهاية ذات أولوية أعلى. إذا كنت تنوي الاحتفاظ بالأولوية في المنطقة B لفترة من الوقت، فيجب عليك تغيير جدول الأولوية في ملف تعريف Trafic Manager وفقًا لذلك.

يوضح المخطط التالي انقطاع في المنطقة الثانوية:

Scenario 1. Configuration after an outage in the secondary region.

تتمثل المزايا الرئيسية لنمط التصميم هذا في:

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

تتمثل المقايضة الرئيسية في أن موارد التطبيق في المنطقة B غير مستغلة بشكل كافٍ في معظم الأوقات.

السيناريو 2: مناطق Azure لاستمرارية الأعمال مع أقصى قدر من الاحتفاظ بالبيانات

هذا الخيار هو الأنسب للتطبيقات ذات الخصائص التالية:

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

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

يوضح المخطط التالي هذا التكوين قبل الانقطاع:

Scenario 2. Configuration before the outage.

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

ملاحظة

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

Scenario 2. Disaster recovery stages.

في حالة حدوث انقطاع في المنطقة B، يكتشف Traffic Manager فشل تطبيق الويب 2 الخاص بنقطة النهاية في المنطقة B ويميزه بالتدهور (1). في هذه الأثناء، تعمل مجموعة تجاوز الفشل على تبديل وحدة الإصغاء للقراءة فقط إلى المنطقة A (2). لا يؤثر هذا الانقطاع على تجربة المستخدم النهائي ولكن يتم الكشف عن قاعدة البيانات الأساسية أثناء الانقطاع. يوضح المخطط التالي الانقطاع في المنطقة الثانوية:

Scenario 2. Outage of the secondary region.

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

يتميز نمط التصميم هذا بالعديد من المزايا:

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

المفاضلة هو أن التطبيق يجب أن يكون قادرًا على العمل في وضع القراءة فقط.

السيناريو 3: نقل التطبيق إلى منطقة جغرافية مختلفة دون فقد البيانات وقرب وقت تعطل من الصفر

في هذا السيناريو، تتسم التطبيقات بالخصائص التالية:

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

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

يجب نشر موارد التطبيق في كل جغرافية حيث يكون لديك طلب استخدام كبير. على سبيل المثال، إذا تم استخدام التطبيق الخاص بك بنشاط في الولايات المتحدة والاتحاد الأوروبي وجنوب شرق آسيا، فيجب نشر التطبيق في جميع هذه المناطق الجغرافية. يجب أن يتم تبديل قاعدة البيانات الأساسية ديناميكيًا من منطقة جغرافية إلى أخرى في نهاية ساعات العمل. وتسمى هذه الطريقة "تتبع الشمس". يرتبط حمل عمل OLTP دائمًا بقاعدة البيانات عبر مستمع القراءة والكتابة < failover-group-name > .database.windows.net (1). يرتبط حمل العمل للقراءة فقط بقاعدة البيانات المحلية مباشرةً باستخدام نقطة نهاية خادم قواعد البيانات < server-name > .database.windows.net (2). تم تكوين Traffic Manager باستخدام أسلوب توجيه الأداء. يضمن الجهاز توصيل جهاز المستخدم النهائي بخدمة الويب في المنطقة الأقرب. يجب إعداد Traffic Manager مع تمكين مراقبة نقطة النهاية لكل نقطة نهاية خدمة ويب (3).

ملاحظة

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

Scenario 3. Configuration with primary in East US.

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

  • تبديل الخادم الأساسي في مجموعة تجاوز الفشل إلى شمال أوروبا باستخدام تجاوز الفشل المألوف (1)
  • إزالة مجموعة الفشل بين شرق الولايات المتحدة وشمال أوروبا
  • إنشاء مجموعة تجاوز الفشل جديدة بنفس الاسم ولكن بين شمال أوروبا وشرق آسيا (2).
  • أضف الابتدائي في شمال أوروبا والثانوي في شرق آسيا إلى مجموعة تجاوز الفشل هذه (3).

يوضح المخطط التالي التكوين الجديد بعد تجاوز الفشل المخطط له:

Scenario 3. Transitioning the primary to North Europe.

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

Scenario 3. Outage in North Europe.

ملاحظة

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

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

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

ولكن يوجد بعض المقايضات:

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

تخطيط استمرارية الأعمال: اختر تصميم تطبيق للتعافي من الكوارث السحابية

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

النمط هدف نقطة الاسترداد (RPO) ERT
النشر النشط السلبي للتعافي من الكوارث مع الوصول المشترك إلى قاعدة البيانات الوصول للقراءة والكتابة < 5 ثوانٍ وقت الكشف عن الفشل + DNS TTL
النشر النشط - النشط لموازنة حمل التطبيق الوصول للقراءة والكتابة < 5 ثوانٍ وقت الكشف عن الفشل + DNS TTL
النشر النشط السلبي لحفظ البيانات الوصول للقراءة فقط < 5 ثوانٍ الوصول للقراءة فقط = 0
الوصول للقراءة والكتابة = صفر الوصول للقراءة والكتابة = وقت الكشف عن الفشل + زمن فترة السماح مع فقدان البيانات

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