Share via

وثائق موثوقية Azure

  • مقالة

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

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

توفر وثائق موثوقية Azure إرشادات الموثوقية لخدمات Azure. تتضمن هذه الإرشادات معلومات حول دعم منطقة التوفر، وإرشادات التعافي من الكوارث، وتوافر الخدمات.

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

للحصول على معلومات حول مبادئ الموثوقية والموثوقية والهندسة المعمارية في خدمات Microsoft Azure، راجع Microsoft Azure Well-Architected Framework: الموثوقية.

متطلبات الموثوقية

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

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

Diagram showing the shared responsibility model for Azure business continuity.

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

لمزيد من المعلومات حول مبادئ الموثوقية، راجع وثائق موثوقية إطار العمل المصممة جيدا.  

موثوقية البناء

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

تغطي قائمة الاختيار التالية نطاق تخطيط الموثوقية.

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

RTO وRPO

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

  • هدف وقت الاسترداد (RTO) هو الحد الأقصى للوقت المقبول الذي يمكن أن يكون فيه التطبيق غير متوفر بعد وقوع حادث.

  • هدف نقطة الاسترداد (RPO) هو الحد الأقصى لمدة فقدان البيانات المقبولة أثناء وقوع كارثة.

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

المناطق ومناطق التوفر

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

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

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

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

تبعيات خدمة Azure

تتوفر خدمات Microsoft Azure عالميا لدفع عمليات السحابة الخاصة بك إلى المستوى الأمثل.

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

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

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

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