مشاركة عبر

اعتبارات النظام الأساسي للتطبيق لأحمال العمل الحرجة للمهام على Azure

  • مقالة

يوفر Azure العديد من خدمات الحوسبة لاستضافة التطبيقات عالية التوفر. تختلف الخدمات في القدرة والتعقيد. نوصي باختيار الخدمات استنادا إلى:

  • المتطلبات غير الوظيفية للموثوقية والتوافر والأداء والأمان.
  • عوامل القرار مثل قابلية التوسع والتكلفة وقابلية التشغيل والتعقيد.

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

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

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

هام

تعد هذه المقالة جزءا من سلسلة حمل العمل الحرجة لمهمة Azure Well-Architected Framework . إذا لم تكن على دراية بهذه السلسلة، نوصي بالبدء بما هو حمل العمل الحرج للمهمة؟.

التوزيع العالمي لموارد النظام الأساسي

يتضمن النمط النموذجي لحمل العمل الحرج للمهام الموارد العالمية والموارد الإقليمية.

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

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

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

رسم تخطيطي يوضح بنية مهمة.

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

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

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

اعتبارات التصميم

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

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

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

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

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

توصيات التصميم

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

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

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

    هام

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

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

  • حدد أهداف نقطة الاسترداد (RPO) وأهداف وقت الاسترداد (RTO) وتحقق من صحتها.

  • ضمن منطقة جغرافية واحدة، حدد أولويات استخدام الأزواج الإقليمية للاستفادة من الإطلاقات المتسلسلة ل SDP للصيانة المخطط لها وتحديد الأولويات الإقليمية للصيانة غير المخطط لها.

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

  • محاذاة توفر الخدمة الحالية مع مخططات المنتجات عند اختيار مناطق التوزيع. قد لا تتوفر بعض الخدمات على الفور في كل منطقة.

الحاويات

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

هام

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

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

اعتبارات التصميم

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

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

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

توصيات التصميم

  • تعبئة جميع مكونات التطبيق في حاويات. استخدم صور الحاوية كنموذج أساسي لحزم توزيع التطبيق.

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

  • اجعل الحاويات غير قابلة للتغيير وقابلة للاستبدال، مع دورات حياة قصيرة.

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

  • تخزين صور الحاوية في Azure Container Registry. استخدم النسخ المتماثل الجغرافي لنسخ صور الحاوية عبر جميع المناطق. تمكين Microsoft Defender لسجلات الحاويات لتوفير فحص الثغرات الأمنية لصور الحاوية. تأكد من إدارة الوصول إلى السجل بواسطة معرف Microsoft Entra.

استضافة الحاوية وتنسيقها

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

هام

يجب أن تكون Azure Kubernetes Service (AKS)وAzure Container Apps من بين اختياراتك الأولى لإدارة الحاويات اعتمادا على متطلباتك. على الرغم من أن Azure App Service ليست منسقا، كمنصة حاوية منخفضة الاحتكاك، إلا أنها لا تزال بديلا ممكنا ل AKS.

اعتبارات التصميم والتوصيات لخدمة Azure Kubernetes

تتيح AKS، وهي خدمة Kubernetes مدارة، توفير نظام المجموعة السريع دون الحاجة إلى أنشطة إدارة نظام المجموعة المعقدة وتقدم مجموعة ميزات تتضمن إمكانات متقدمة للشبكات والهوية. للحصول على مجموعة كاملة من التوصيات، راجع مراجعة Azure Well-Architected Framework - AKS.

هام

هناك بعض قرارات التكوين الأساسية التي لا يمكنك تغييرها دون إعادة توزيع نظام مجموعة AKS. تتضمن الأمثلة الاختيار بين مجموعات AKS العامة والخاصة، وتمكين نهج شبكة Azure، Microsoft Entra التكامل، واستخدام الهويات المدارة ل AKS بدلا من كيانات الخدمة.

الموثوقية

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

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

  • استخدم AKS Uptime SLA لمجموعات الإنتاج لزيادة ضمانات توفر نقطة نهاية Kubernetes API إلى أقصى حد.

قابلية التوسع

خذ بعين الاعتبار حدود مقياس AKS، مثل عدد العقد وتجمعات العقد لكل نظام مجموعة ومجموعات لكل اشتراك.

العزل

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

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

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

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

الأمان

يتطلب Vanilla Kubernetes الافتراضي تكوينا كبيرا لضمان وضع أمني مناسب للسيناريوهات الحرجة للمهام. يعالج AKS المخاطر الأمنية المختلفة خارج الصندوق. تتضمن الميزات المجموعات الخاصة والتدقيق وتسجيل الدخول إلى Log Analytics وصور العقدة المتصلبة والهويات المدارة.

  • تطبيق إرشادات التكوين المتوفرة في أساس أمان AKS.

  • استخدم ميزات AKS للتعامل مع هوية نظام المجموعة وإدارة الوصول لتقليل النفقات التشغيلية وتطبيق إدارة وصول متسقة.

  • استخدم الهويات المدارة بدلا من كيانات الخدمة لتجنب إدارة بيانات الاعتماد وتتناوبها. يمكنك إضافة هويات مدارة على مستوى نظام المجموعة. على مستوى الجراب، يمكنك استخدام الهويات المدارة عبر هوية حمل عمل Microsoft Entra.

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

ترقيات

يجب ترقية المجموعات والعقد بانتظام. تدعم AKS إصدارات Kubernetes بالتوافق مع دورة إصدار Kubernetes الأصلية.

  • اشترك في مخطط AKS العام وملاحظات الإصدار على GitHub للبقاء على اطلاع دائم بالتغييرات والتحسينات القادمة، والأهم من ذلك، إصدارات وإصدارات Kubernetes والإهمال.

  • تطبيق الإرشادات المقدمة في قائمة اختيار AKS لضمان التوافق مع أفضل الممارسات.

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

الشبكات

تقييم المكونات الإضافية للشبكة التي تناسب حالة الاستخدام الخاصة بك على أفضل نحو. حدد ما إذا كنت بحاجة إلى التحكم الدقيق في نسبة استخدام الشبكة بين القرون. يدعم Azure kubenet وAzure CNIويجلب CNI الخاص بك لحالات استخدام محددة.

تحديد أولويات استخدام Azure CNI بعد تقييم متطلبات الشبكة وحجم نظام المجموعة. يتيح Azure CNI استخدام نهج شبكة Azure أو Calico للتحكم في نسبة استخدام الشبكة داخل نظام المجموعة.

المراقبة

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

الإدارة

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

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

  • إنشاء موثوقية متسقة وأساس أمان لتكوينات نظام مجموعة AKS والجراب باستخدام نهج Azure.

  • استخدم الوظيفة الإضافية لنهج Azure ل AKS للتحكم في وظائف الجراب، مثل امتيازات الجذر، وعدم السماح بالقرون التي لا تتوافق مع النهج.

ملاحظة

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

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

اعتبارات التصميم والتوصيات لخدمة تطبيقات Azure

بالنسبة لسيناريوهات حمل العمل المستندة إلى الويب وواجهة برمجة التطبيقات، قد تكون App Service بديلا ممكنا ل AKS. يوفر منصة حاوية منخفضة الاحتكاك دون تعقيد Kubernetes. للحصول على مجموعة كاملة من التوصيات، راجع اعتبارات الموثوقية لخدمة التطبيقاتوالتميز التشغيلي لخدمة التطبيقات.

الموثوقية

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

استنفاد منفذ TCP هو سيناريو فشل آخر. يحدث عندما يتجاوز مجموع الاتصالات الصادرة من عامل معين السعة. يعتمد عدد منافذ TCP المتوفرة على حجم العامل. للحصول على توصيات، راجع منافذ TCP وSNAT.

قابلية التوسع

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

  • تمكين التحجيم التلقائي لضمان توفر الموارد الكافية لطلبات الخدمة. تقييم التحجيم لكل تطبيق للاستضافة عالية الكثافة على App Service.

  • يجب أن تدرك أن App Service لديها حد افتراضي مبدئي للمثيلات لكل خطة App Service.

  • تطبيق قواعد التحجيم التلقائي. يتم توسيع نطاق خطة App Service إذا تم استيفاء أي قاعدة داخل ملف التعريف ولكن يتم توسيع نطاقها فقط إذا تم استيفاء جميع القواعد داخل ملف التعريف. استخدم مجموعة قواعد التوسيع والتوسيع للتأكد من أن التحجيم التلقائي يمكنه اتخاذ إجراء لتوسيع النطاق وتوسيع نطاقه. فهم سلوك قواعد تحجيم متعددة في ملف تعريف واحد.

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

المراقبة

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

  • يمكنك استخدام التسجيل التشخيصي لاستيعاب السجلات على مستوى التطبيق وعلى مستوى النظام الأساسي في Log Analytics أو Azure Storage أو أداة تابعة لجهة خارجية عبر Azure Event Hubs.

  • توفر مراقبة أداء التطبيق باستخدام Application Insights رؤى عميقة حول أداء التطبيق.

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

  • تحتاج إلى استخدام الفحوصات الصحية المناسبة لتقييم جميع تبعيات انتقال البيانات من الخادم الهامة، مما يساعد على ضمان الصحة العامة. نوصي بشدة بتمكين Health Check لتحديد العمال غير المستجيبين.

توزيع

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

سجل الحاوية

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

اعتبارات التصميم

  • التنسيق. ضع في اعتبارك استخدام سجل حاوية يعتمد على التنسيق والمعايير التي يوفرها Docker لكل من عمليات الدفع والسحب. هذه الحلول متوافقة وقابلة للتبديل في الغالب.

  • نموذج التوزيع. يمكنك نشر سجل الحاوية كخدمة مركزية تستهلكها تطبيقات متعددة داخل مؤسستك. أو يمكنك توزيعه كمكون مخصص لحمل عمل تطبيق معين.

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

توصيات التصميم

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

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

  • تأكد من محاذاة اتفاقية مستوى الخدمة للسجل العام مع أهداف الموثوقية والأمان الخاصة بك. لاحظ بشكل خاص حدود التقييد لحالات الاستخدام التي تعتمد على Docker Hub.

  • تحديد أولويات Azure Container Registry لاستضافة صور الحاوية.

اعتبارات التصميم والتوصيات ل Azure Container Registry

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

الموثوقية

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

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

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

تأمين الصور

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

إذا كنت تريد حماية مثيل سجل الحاوية من الحذف، فاستخدم تأمين الموارد.

الصور ذات العلامات

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

إدارة الهوية والوصول

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

الحوسبة دون الخادم

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

  • Azure Functions. عند استخدام Azure Functions، يتم تنفيذ منطق التطبيق ككتل مميزة من التعليمات البرمجية أو الوظائف التي تعمل استجابة للأحداث، مثل طلب HTTP أو رسالة قائمة الانتظار. تتوسع كل دالة حسب الضرورة لتلبية الطلب.

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

  • إدارة Azure APIM. يمكنك استخدام APIM لنشر واجهات برمجة التطبيقات المحسنة للأمان وتحويلها وصيانتها ومراقبتها باستخدام طبقة الاستهلاك.

  • Power Apps وPower Automate. توفر هذه الأدوات تجربة تطوير منخفضة التعليمات البرمجية أو بدون تعليمات برمجية، مع منطق سير عمل بسيط وتكاملات قابلة للتكوين من خلال الاتصالات في واجهة المستخدم.

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

توفر الأقسام التالية اعتبارات وتوصيات التصميم لاستخدام Azure Functions وLogic Apps كأنظمة أساسية بديلة لسيناريوهات سير العمل غير الحرجة.

اعتبارات التصميم والتوصيات لوظائف Azure

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

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

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

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

تحتاج إلى استخدام أدوات فحص التعليمات البرمجية على التعليمات البرمجية ل Azure Functions ودمج هذه الأدوات مع مسارات CI/CD.

اعتبارات التصميم والتوصيات ل Azure Logic Apps

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

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

عمليات الترحيل المقيدة عبر IaaS

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

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

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

اعتبارات التصميم

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

  • يوفر Azure إمكانات لزيادة توفر الأجهزة الظاهرية:

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

توصيات التصميم

هام

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

  • أحجام وحدة SKU للجهاز الظاهري ذات الحجم الصحيح لضمان الاستخدام الفعال للموارد.

  • نشر ثلاثة أجهزة ظاهرية أو أكثر عبر مناطق التوفر لتحقيق التسامح مع الخطأ على مستوى مركز البيانات.

    • إذا كنت تقوم بنشر برامج تجارية جاهزة، فقم باستشارة مورد البرامج واختبر بشكل كاف قبل نشر البرنامج في الإنتاج.

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

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

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

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

  • للحماية من الانقطاعات الإقليمية، قم بتوزيع الأجهزة الظاهرية للتطبيق عبر مناطق Azure متعددة.

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

  • استخدم الصور القياسية من Azure Marketplace بدلا من الصور المخصصة التي تحتاج إلى صيانة.

  • تنفيذ العمليات التلقائية لتوزيع التغييرات على الأجهزة الظاهرية ونشرها، وتجنب أي تدخل يدوي. لمزيد من المعلومات، راجع اعتبارات IaaS في مجال تصميم الإجراءات التشغيلية .

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

  • مراقبة الأجهزة الظاهرية والتأكد من استيعاب سجلات التشخيص والمقاييس في متلقي بيانات موحد.

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

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

راجع اعتبارات النظام الأساسي للبيانات.

نظام البيانات الأساسي