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

  • مقالة

ينطبق على: NoSQL MongoDB كاساندرا العفريت الجدول

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

تستخدم هذه المقالة المصطلحات التالية:

  • هدف وقت الاسترداد (RTO): الوقت بين بداية الانقطاع الذي يؤثر على Azure Cosmos DB والاسترداد إلى التوفر الكامل.
  • هدف نقطة الاسترداد (RPO): الوقت بين الكتابة الأخيرة التي تمت استعادتها بشكل صحيح ووقت بداية الانقطاع الذي يؤثر على Azure Cosmos DB.

إشعار

تعتمد RPOs وRTOs المتوقعة والقصوى على نوع الانقطاع الذي يواجهه Azure Cosmos DB. على سبيل المثال، انقطاع عقدة واحدة له RTO وRPO متوقع مختلف عن انقطاع المنطقة بأكملها.

توضح هذه المقالة تفاصيل الأحداث التي يمكن أن تؤثر على توفر Azure Cosmos DB وخيارات تكوين Azure Cosmos DB المقابلة.

صيانة النسخ المتماثلة

Azure Cosmos DB هي خدمة متعددة المستأجرين تدير جميع تفاصيل عقد الحوسبة الفردية بشفافية. لا داعي للقلق من أي نوع من التصحيح أو الصيانة المخطط لها. يضمن Azure Cosmos DB اتفاقيات مستوى الخدمة للتوفر وزمن انتقال P99 من خلال جميع عمليات الصيانة التلقائية التي ينفذها النظام.

انقطاعات النسخ المتماثلة

انقطاع النسخ المتماثلة هي انقطاعات العقد الفردية في مجموعة Azure Cosmos DB التي يتم نشرها في منطقة Azure.

يقوم Azure Cosmos DB تلقائيا بتخفيف انقطاع النسخ المتماثلة عن طريق ضمان ثلاث نسخ متماثلة على الأقل من بياناتك في كل منطقة Azure لحسابك ضمن حصة مكونة من أربع نسخ متماثلة. ينتج عن هذا الضمان RTO من 0 وRPO من 0 انقطاع العقدة الفردية، دون الحاجة إلى تغييرات التطبيق أو التكوينات.

في العديد من مناطق Azure، من الممكن توزيع نظام مجموعة Azure Cosmos DB عبر مناطق التوفر. يمكن لمناطق التوفر زيادة اتفاقيات مستوى الخدمة لأنها منفصلة ماديا وتوفر مصدر طاقة وشبكة وتبريد مميزا. عند نشر حساب Azure Cosmos DB باستخدام مناطق التوفر، يوفر Azure Cosmos DB RTO من 0 وRPO من 0، حتى في انقطاع المنطقة.

عند النشر في منطقة Azure واحدة، دون إدخال مستخدم إضافي، يكون Azure Cosmos DB مرنا في مواجهة انقطاع العقدة. يؤدي تمكين التكرار عبر مناطق التوفر إلى جعل Azure Cosmos DB مرنة في مواجهة انقطاعات المنطقة على حساب زيادة الرسوم.

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

بشكل افتراضي، لا يستخدم حساب Azure Cosmos DB مناطق توفر متعددة. يمكنك تمكين النشر عبر مناطق توفر متعددة بالطرق التالية:

إذا تم توزيع حساب Azure Cosmos DB عبر مناطق N Azure، فسيكون هناك N x 4 نسخ من جميع بياناتك. لمزيد من المعلومات حول كيفية نسخ Azure Cosmos DB للبيانات في كل منطقة، راجع التوزيع العالمي باستخدام Azure Cosmos DB. وجود حساب Azure Cosmos DB في أكثر من منطقتين يحسن توفر التطبيق الخاص بك ويوفر زمن انتقال منخفض عبر المناطق المقترنة.

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

انقطاعات المنطقة هي الانقطاعات التي تؤثر على جميع عقد Azure Cosmos DB في منطقة Azure، عبر جميع مناطق التوفر. بالنسبة للحالات النادرة من انقطاع المنطقة، يمكنك تكوين Azure Cosmos DB لدعم النتائج المختلفة للمتانة والتوافر.

المتانة

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

لمساعدتك على الحماية من فقدان البيانات الكامل الذي قد ينتج عن الكوارث الكارثية في منطقة ما، يوفر Azure Cosmos DB وضعين للنسخ الاحتياطي:

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

عند نشر حساب Azure Cosmos DB في مناطق متعددة، تعتمد متانة البيانات على مستوى التناسق الذي تقوم بتكوينه على الحساب. تفاصيل الجدول التالي، لجميع مستويات التناسق، RPO لحساب Azure Cosmos DB الذي تم نشره في منطقتين على الأقل.

مستوى التناسق RPO للانقطاع في المنطقة
جلسة عمل، بادئة متسقة، نهائية أقل من 15 دقيقة
مستمر بلا حدود "Bounded Staleness" K وT
قوي "Strong" 0

K = عدد الإصدارات (أي التحديثات) لعنصر ما.

T = الفاصل الزمني منذ آخر تحديث.

بالنسبة للحسابات متعددة المناطق، فإن الحد الأدنى لقيمة K وT هو 100000 عملية كتابة أو 300 ثانية. تحدد هذه القيمة الحد الأدنى من RPO للبيانات عند استخدام bounded staleness.

لمزيد من المعلومات حول الاختلافات بين مستويات التناسق، راجع مستويات التناسق في Azure Cosmos DB.

التوافر

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

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

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

هام

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

تحذير

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

مناطق كتابة متعددة

يمكنك تكوين Azure Cosmos DB لقبول عمليات الكتابة في مناطق متعددة. هذا التكوين مفيد لتقليل زمن انتقال الكتابة في التطبيقات الموزعة جغرافيا.

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

هام

تحديث معرف المستند نفسه بشكل متكرر (أو إعادة إنشاء معرف المستند نفسه بشكل متكرر بعد TTL أو حذفه) سيكون له تأثير على أداء النسخ المتماثل بسبب زيادة عدد التعارضات التي تم إنشاؤها في النظام.  

منطقة حل النزاعات

عند تكوين حساب Azure Cosmos DB مع عمليات الكتابة متعددة المناطق، ستعمل إحدى المناطق كحكم في تعارضات الكتابة.

أفضل الممارسات للكتابات متعددة المناطق

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

الاحتفاظ بحركة المرور المحلية المحلية

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

من المهم للتطبيق تقليل التعارضات عن طريق تجنب مضادات التناثر التالية:

  • إرسال نفس عملية الكتابة إلى جميع المناطق لزيادة احتمالات الحصول على وقت استجابة سريع

  • تحديد المنطقة المستهدفة بشكل عشوائي لعملية قراءة أو كتابة على أساس كل طلب

  • استخدام نهج الترتيب الدوري لتحديد المنطقة المستهدفة لعملية القراءة أو الكتابة على أساس كل طلب

تجنب التبعية على تأخر النسخ المتماثل

لا يمكنك تكوين حسابات الكتابة متعددة المناطق للاتساق القوي. المنطقة التي تتم كتابتها للاستجابة مباشرة بعد أن يقوم Azure Cosmos DB بنسخ البيانات نسخا متماثلا محليا أثناء نسخ البيانات بشكل غير متزامن عالميا.

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

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

تقييم استخدام تناسق الجلسة لعمليات الكتابة

في تناسق الجلسة، يمكنك استخدام الرمز المميز للجلسة لكل من عمليات القراءة والكتابة.

لعمليات القراءة، يرسل Azure Cosmos DB رمز الجلسة المخزن مؤقتا إلى الخادم مع ضمان تلقي البيانات التي تتوافق مع رمز الجلسة المحدد (أو الأحدث).

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

من الأفضل استخدام الرموز المميزة للجلسة فقط لعمليات القراءة وليس لعمليات الكتابة عند تمرير رموز الجلسة المميزة بين مثيلات العميل.

التخفيف من حدة التحديثات السريعة لنفس المستند

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

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

ما يمكن توقعه خلال انقطاع منطقة

سيعاني عملاء حسابات المنطقة الواحدة من فقدان توفر القراءة والكتابة حتى تتم استعادة الخدمة.

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

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

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

دون تجاوز الفشل المدار بواسطة الخدمة، يواجه العملاء فقدان توفر الكتابة. تتم استعادة توفر الكتابة تلقائيا عند انتهاء الانقطاع.

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

لا تقم بتشغيل تجاوز فشل يدوي أثناء الانقطاع، لأنه لا يمكن أن ينجح.

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

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

معلومات إضافية حول انقطاعات منطقة القراءة

  • المنطقة المتأثرة غير متصلة وتم وضع علامة عليها دون اتصال. تعيد Azure Cosmos DB SDKs توجيه استدعاءات القراءة إلى المنطقة المتوفرة التالية في قائمة المنطقة المفضلة.

  • إذا لم تتوفر أي من المناطق في قائمة المناطق المفضلة، فإن المكالمات تعود تلقائيا إلى منطقة الكتابة الحالية.

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

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

  • حتى في حدث نادر ومؤسف حيث تكون منطقة كتابة Azure غير قابلة للاسترداد بشكل دائم، لا يوجد فقدان للبيانات إذا تم تكوين حساب Azure Cosmos DB متعدد المناطق بتناسق قوي. يحتوي حساب Azure Cosmos DB متعدد المناطق على خصائص المتانة المحددة سابقا في قسم المتانة.

معلومات إضافية حول انقطاعات منطقة القراءة

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

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

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

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

تحذير

في حالة انقطاع منطقة الكتابة، حيث يقوم حساب Azure Cosmos DB بترقية منطقة ثانوية لتكون منطقة الكتابة الأساسية الجديدة عبر تجاوز الفشل المدار بواسطة الخدمة، لن تتم ترقية منطقة الكتابة الأصلية مرة أخرى كمنطقة الكتابة تلقائيا بمجرد استردادها. تقع على عاتقك مسؤولية العودة إلى المنطقة المستردة كمنطقة كتابة باستخدام PowerShell أو Azure CLI أو مدخل Microsoft Azure (بمجرد أن يكون ذلك آمنا، كما هو موضح أعلاه).

اتفاقيات مستوى الخدمة (SLA)

يلخص الجدول التالي قدرات قابلية الوصول العالية لتكوينات الحساب المختلفة.

مؤشر الأداء الأساسي (KPI) عمليات الكتابة أحادية المنطقة دون مناطق توفر عمليات الكتابة أحادية المنطقة مع مناطق التوفر عمليات الكتابة متعددة المناطق والمنطقة الواحدة دون مناطق توفر عمليات الكتابة متعددة المناطق والمنطقة الواحدة مع مناطق التوفر عمليات الكتابة متعددة المناطق، متعددة المناطق مع مناطق التوفر أو بدونها
اتفاقية على مستوى الخدمة لقابلية الوصول إلى عمليات الكتابة 99.99% 99.995% 99.99% 99.995% 99.999%
اتفاقية على مستوى الخدمة لقابلية الوصول إلى عمليات القراءة 99.99% 99.995% 99.999% 99.999% 99.999%
حالات فشل المنطقة: فقدان البيانات فقدان البيانات لا يوجد فقدان للبيانات لا يوجد فقدان للبيانات لا يوجد فقدان للبيانات لا يوجد فقدان للبيانات
حالات فشل المنطقة: التوفر فقدان قابلية الوصول لا يوجد فقدان لقابلية الوصول لا يوجد فقدان لقابلية الوصول لا يوجد فقدان لقابلية الوصول لا يوجد فقدان لقابلية الوصول
الانقطاع الإقليمي: فقدان البيانات فقدان البيانات فقدان البيانات يعتمد ذلك على مستوى التناسق. لمزيد من المعلومات، راجع مقايضات التناسق والتوافر والأداء. يعتمد ذلك على مستوى التناسق. لمزيد من المعلومات، راجع مقايضات التناسق والتوافر والأداء. يعتمد ذلك على مستوى التناسق. لمزيد من المعلومات، راجع مقايضات التناسق والتوافر والأداء.
الانقطاع الإقليمي: التوفر فقدان قابلية الوصول فقدان قابلية الوصول لا يوجد فقدان لقابلية الوصول لعطل في منطقة القراءة، مؤقت لعطل في منطقة الكتابة لا يوجد فقدان لقابلية الوصول لعطل في منطقة القراءة، مؤقت لعطل في منطقة الكتابة لا يوجد فقدان في توفر القراءة، فقدان توفر الكتابة المؤقت في المنطقة المتأثرة
السعر (1) غير قابل للتطبيق وحدة طلب مقدمة/ثانية × معدل 1.25 وحدات الطلب/ثانية المتوفرة x N المناطق وحدات الطلب/ثانية المتوفرة × 1.25 معدل x N المناطق (2) معدل الكتابة متعدد المناطق x N المناطق

1 بالنسبة للحسابات بلا خادم، يتم ضرب وحدات الطلب بعامل 1.25.

2 ينطبق معدل 1.25 فقط على المناطق التي تقوم فيها بتمكين مناطق التوفر.

تلميحات لإنشاء تطبيقات عالية التوفر

  • راجع السلوك المتوقع ل Azure Cosmos DB SDKs أثناء الأحداث والتكوينات التي تؤثر عليه.

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

  • بالنسبة لحسابات Azure Cosmos DB متعددة المناطق التي تم تكوينها مع منطقة كتابة واحدة، قم بتمكين تجاوز الفشل المدار بواسطة الخدمة باستخدام Azure CLI أو مدخل Azure. بعد تمكين تجاوز الفشل المدار بواسطة الخدمة، كلما حدثت كارثة إقليمية، سيفشل Azure Cosmos DB عبر حسابك دون أي إدخال من المستخدم.

  • حتى إذا كان حساب Azure Cosmos DB الخاص بك متوفرا بشكل كبير، فقد لا يكون التطبيق الخاص بك مصمما بشكل صحيح ليظل متوفرا بشكل كبير. لاختبار قابلية الوصول العالية من طرف إلى طرف لتطبيقك كجزء من اختبار التطبيق أو تدريبات التعافي من الكوارث (DR)، قم بتعطيل تجاوز الفشل المدار بواسطة الخدمة للحساب مؤقتا. استدعاء تجاوز الفشل اليدوي باستخدام PowerShell أو Azure CLI أو مدخل Microsoft Azure، ثم مراقبة التطبيق الخاص بك. بعد إكمال الاختبار، يمكنك العودة إلى المنطقة الأساسية واستعادة تجاوز الفشل المدار بواسطة الخدمة للحساب.

    هام

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

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

ما يمكن توقعه أثناء انقطاع منطقة Azure Cosmos DB

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

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

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

يستعيد Azure Cosmos DB توفر الكتابة عند انتهاء الانقطاع.		 أثناء انقطاع التيار الكهربائي، تأكد من وجود عدد كاف من وحدات الطلب المقدمة في المناطق المتبقية لدعم حركة بيانات القراءة.

لا تقم بتشغيل تجاوز فشل يدوي أثناء الانقطاع، لأنه لا يمكن أن ينجح.

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

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

لا تقم بتشغيل تجاوز فشل يدوي أثناء الانقطاع، لأنه لا يمكن أن ينجح.

عند انتهاء الانقطاع، يمكنك نقل منطقة الكتابة مرة أخرى إلى المنطقة الأصلية وإعادة ضبط وحدات الطلب المقدمة حسب الاقتضاء. يمكن للحسابات التي تستخدم واجهة برمجة التطبيقات ل NoSQL أيضا استرداد البيانات غير المبسطة في المنطقة الفاشلة من موجز التعارض الخاص بك.
مناطق كتابة متعددة غير قابل للتطبيق قد لا تتوفر البيانات التي تم تحديثها مؤخرا في المنطقة الفاشلة في المناطق النشطة المتبقية. تضمن مستويات البادئة النهائية والمتناسقة وتناسق الجلسة ثباتا أقل من 15 دقيقة. يضمن Bounded staleness أقل من تحديثات K أو ثواني T ، اعتمادا على التكوين. إذا عانت المنطقة المتأثرة من فقدان دائم للبيانات، فقد تفقد بيانات غير مبسطة. أثناء الانقطاع، تأكد من وجود عدد كاف من وحدات الطلب المتوفرة في المناطق المتبقية لدعم المزيد من حركة المرور.

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

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

بعد ذلك، يمكنك قراءة المقالات التالية: