منهجية التصميم لأحمال العمل الحرجة للمهام على Azure

يتطلب بناء تطبيق مهم على أي نظام أساسي سحابي خبرة تقنية كبيرة واستثمار هندسي، خاصة وأن هناك تعقيدا كبيرا مرتبطا بما يلي:

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

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

1 - التصميم لمتطلبات العمل

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

تحديد مستوى موثوقية

الموثوقية هي مفهوم نسبي ويجب أن يعكس أي حمل عمل موثوق به بشكل مناسب متطلبات العمل المحيطة به. على سبيل المثال، يتطلب حمل العمل الحرج للمهمة مع هدف مستوى خدمة التوفر بنسبة 99.999٪ مستوى أعلى بكثير من الموثوقية من حمل عمل آخر أقل أهمية مع SLO بنسبة 99.9٪.

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

مستوى الموثوقية (Availability SLO)	وقت التعطل المسموح به (أسبوع)	وقت التعطل المسموح به (شهر)	وقت التعطل المسموح به (سنة)
99.9%	10 دقائق، 4 ثوان	43 دقيقة و49 ثانية	8 ساعات، 45 دقيقة، 56 ثانية
99.95%	5 دقائق، ثانيتان	21 دقيقة، 54 ثانية	4 ساعات، 22 دقيقة، 58 ثانية
99.99%	1 دقيقة	4 دقائق و22 ثانية	52 دقيقة، 35 ثانية
99.999%	6 ثوانٍ	26 ثانية	5 دقائق، 15 ثانية
99.9999%	<1 ثانية	2 seconds	31 ثانية

هام

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

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

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

طلب

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

2— تقييم مناطق التصميم باستخدام مبادئ التصميم

يكمن جوهر هذه المنهجية في مسار تصميم هام يتكون من:

• مبادئ التصميم التأسيسي
• مجال التصميم الأساسي مع قرارات تصميم مترابطة ومعتمدة بشكل كبير.

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

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

3 — نشر أول تطبيق مهم للمهمة

راجع هذه البنيات المرجعية التي تصف قرارات التصميم بناء على هذه المنهجية.

• البنية الأساسية لتطبيق مواجه للإنترنت

• البنية الأساسية لتطبيق مواجه للإنترنت مع عناصر تحكم الشبكة

تلميح

تدعم البنية بتنفيذ Mission-Critical Online الذي يوضح توصيات التصميم.

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

متجذر في تجارب العالم الحقيقي تسترشد جميع القرارات التقنية بتجارب عملاء Azure والدروس المستفادة من نشر هذه الحلول.

محاذاة مخطط Azure تحتوي البنيات المرجعية الهامة للمهمة على خارطة طريق خاصة بها تتماشى مع مخططات منتجات Azure.

4 - دمج حمل العمل في مناطق هبوط Azure

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

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

الاشتراك عبر الإنترنت

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

تتوافق البنية الأساسية وتنفيذ المهام الحرجة عبر الإنترنت مع النهج عبر الإنترنت.

اشتراك Corp.

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

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

تلميح

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

5 — نشر بيئة تطبيق بيئة الاختبار المعزولة

بالتوازي مع أنشطة التصميم، يوصى بشدة بإنشاء بيئة تطبيق بيئة الاختبار المعزولة باستخدام التطبيقات المرجعية Mission-Critical.

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

6 - تتطور باستمرار مع مخططات Azure

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

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

راجع مبادئ التصميم لسيناريوهات التطبيق ذات المهام الحرجة.

مبادئ التصميم