بنية الأساس الحرجة للمهمة في منطقة هبوط Azure
يوفر هذا التصميم المرجعي إرشادات لنشر حمل عمل مهم يستخدم خدمات مشتركة مركزية، ويحتاج إلى اتصال محلي، ويتكامل مع أحمال العمل الأخرى للمؤسسة. هذا التوجيه مخصص لمالك حمل العمل الذي يعد جزءا من فريق تطبيق في المؤسسة.
قد تجد نفسك في هذه الحالة عندما تريد مؤسستك نشر حمل العمل في منطقة هبوط تطبيق Azure التي ترث مجموعة إدارة Corp. . من المتوقع أن يتكامل حمل العمل مع الموارد المشتركة المقدمة مسبقا في منطقة هبوط النظام الأساسي Azure التي تديرها فرق مركزية.
هام
ما المقصود بمنطقة Azure المنتقل إليها؟ المنطقة المنتقل إليها للتطبيق هي اشتراك Azure الذي يتم فيه تشغيل حمل العمل. وهو متصل بالموارد المشتركة للمؤسسة. ومن خلال هذا الاتصال، فإنه يتمتع بإمكانية الوصول إلى البنية الأساسية اللازمة لتشغيل حمل العمل، مثل الشبكات، وإدارة الوصول إلى الهوية، والسياسات، والمراقبة. المناطق المنتقل إليها للنظام الأساسي هي مجموعة من الاشتراكات المختلفة، ولكل منها وظيفة محددة. على سبيل المثال، يوفر اشتراك الاتصال ivity دقة DNS مركزية والاتصال المحلي والأجهزة الظاهرية للشبكة (NVAs) المتوفرة للاستخدام من قبل فرق التطبيق.
بصفتك مالك حمل العمل، يمكنك الاستفادة من إلغاء تحميل إدارة الموارد المشتركة إلى الفرق المركزية والتركيز على جهود تطوير حمل العمل. تستفيد المؤسسة من خلال تطبيق إدارة متسقة وتكاليف استهلاكية عبر أحمال عمل متعددة.
نوصي بشدة بفهم مفهوم مناطق هبوط Azure.
في هذا النهج، الحد الأقصى من الموثوقية هو مسؤولية مشتركة بينك وبين فريق النظام الأساسي. وينبغي أن تكون المكونات المدارة مركزيا موثوقة بدرجة كبيرة لكي يعمل عبء العمل الحرج للمهمة كما هو متوقع. يجب أن تكون لديك علاقة موثوق بها مع فريق النظام الأساسي بحيث يتم تخفيف مشكلات عدم التوفر في الخدمات المركزية، والتي تؤثر على حمل العمل، على مستوى النظام الأساسي. ولكن فريقك مسؤول عن متطلبات القيادة مع فريق النظام الأساسي لتحقيق أهدافك.
تعتمد هذه البنية على بنية الأساس الحرجة للمهمة مع عناصر التحكم في الشبكة. من المستحسن أن تصبح على دراية ببنية الأساس قبل المتابعة في هذه المقالة.
إشعار
يتم دعم الإرشادات من خلال تطبيق مثال على مستوى الإنتاج يعرض تطوير التطبيقات ذات المهام الحرجة على Azure. يمكن استخدام هذا التنفيذ كأساس لمزيد من تطوير الحلول كخطوة أولى نحو الإنتاج.
استراتيجيات التصميم الرئيسية
طبق هذه الاستراتيجيات على رأس الأساس الحرج للمهمة:
المسار الهام
لا تحتاج جميع مكونات البنية إلى أن تكون موثوقة على قدم المساواة. يتضمن المسار الهام تلك المكونات التي يجب الحفاظ على عملها بحيث لا يواجه حمل العمل أي وقت تعطل أو أداء منخفض. سيؤدي الحفاظ على هذا المسار إلى تقليل نقاط الفشل.
دورة حياة المكونات
ضع في اعتبارك دورة حياة المكونات الهامة لأنها تؤثر على هدفك المتمثل في تحقيق وقت تعطل يقارب الصفر. ويمكن أن تكون المكونات موارد سريعة الزوال أو قصيرة الأجل يمكن إنشاؤها وتدميرها حسب الحاجة؛ موارد غير سريعة الزوال أو طويلة الأمد تشترك في مدة البقاء مع النظام أو المنطقة.
التبعيات الخارجية
تقليل التبعيات الخارجية على المكونات والعمليات، والتي يمكن أن تقدم نقاط الفشل. تحتوي البنية على موارد مملوكة لفرق مختلفة خارج فريقك. هذه المكونات (إذا كانت هامة) في نطاق هذه البنية.
مخطط الاشتراك
لا تعني مناطق هبوط Azure مخطط اشتراك واحد. خطط لمساحة اشتراكك مسبقا مع فريق النظام الأساسي الخاص بك لاستيعاب متطلبات موثوقية حمل العمل عبر جميع البيئات.
إمكانية المراقبة المستقلة في المسار الحرج
لديك موارد مراقبة مخصصة تمكن الفريق من الاستعلام بسرعة عن جمع البيانات الخاصة بهم (خاصة المسار الحرج) والعمل على المعالجات.
البنية
قم بتنزيل ملف Visio لهذه البنية.
مكونات هذه البنية هي نفس بنية الأساس الحرجة للمهمة مع عناصر التحكم في الشبكة. الأوصاف قصيرة للإيجاز. إذا كنت بحاجة إلى مزيد من المعلومات، فشاهد المقالات المرتبطة. للحصول على وثائق المنتج حول خدمات Azure، راجع الموارد ذات الصلة.
الموارد العمومية
تعيش هذه الموارد في اشتراك (اشتراكات) المنطقة المنتقل إليها للتطبيق. الموارد العالمية غير سريعة الزوال وتشارك مدة بقاء النظام. تظل خدمات Azure وتكوينها هي نفسها الموارد العمومية الأساسية.
موارد الشبكات الإقليمية
تعيش هذه الموارد عبر اشتراكات المنطقة المنتقل إليها للنظام الأساسي واشتراك (اشتراكات) المنطقة المنتقل إليها للتطبيق. توزع البنية الأساسية جميع الموارد المملوكة لك. ومع ذلك، في هذه البنية، يتم توفير موارد الشبكات من خلال اشتراك الاتصال ivity كجزء من المنطقة المنتقل إليها للنظام الأساسي.
في هذه المقالة، راجع قسم الشبكة الظاهرية للمركز الإقليمي.
موارد الطوابع الإقليمية
تعيش هذه الموارد في اشتراك (اشتراكات) المنطقة المنتقل إليها للتطبيق. لا تشترك هذه الموارد في أي شيء مع الموارد الأخرى، باستثناء الموارد العالمية.
تظل معظم خدمات Azure وتكوينها هي نفسها بنية الطوابع الأساسية، باستثناء موارد الشبكات، التي يتم توفيرها مسبقا من قبل فريق النظام الأساسي.
في هذه المقالة، راجع قسم الشبكة الظاهرية الإقليمية المحورية.
الموارد الخارجية
يتفاعل حمل العمل مع الموارد المحلية. بعضها على المسار الهام لحمل العمل، على سبيل المثال قاعدة بيانات محلية. يتم احتساب هذه الموارد والتواصل معها في اتفاقية مستوى الخدمة المركبة الشاملة (SLA) لحمل العمل. يتم جميع الاتصالات من خلال اشتراك الاتصال ivity. هناك موارد خارجية أخرى قد يصل إليها حمل العمل ولكن لا تعتبر حرجة.
موارد البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع
يجب أن تكون البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بالبناء والإصدار لتطبيق المهام الحرجة مؤتمتة بالكامل لضمان طريقة متسقة لنشر طابع تم التحقق من صحته. تظل هذه الموارد هي نفسها مسار توزيع الأساس.
موارد المراقبة الإقليمية
تعيش هذه الموارد في اشتراك (اشتراكات) المنطقة المنتقل إليها للتطبيق. يتم تخزين بيانات المراقبة للموارد العالمية والموارد الإقليمية بشكل مستقل. تظل خدمات Azure وتكوينها هي نفسها موارد المراقبة الأساسية.
في هذه المقالة، راجع قسم اعتبارات المراقبة.
موارد الإدارة
للوصول إلى مجموعة الحوسبة الخاصة والموارد الأخرى، تستخدم هذه البنية عوامل البناء الخاصة ومثيلات الأجهزة الظاهرية لمربع الانتقال. يوفر Azure Bastion وصولا آمنا إلى مربعات الانتقال. تظل الموارد داخل الطوابع هي نفسها موارد إدارة الأساس.
اعتبارات الشبكات
في هذا التصميم، يتم نشر حمل العمل في منطقة هبوط التطبيق ويحتاج إلى الاتصال بالموارد الموحدة في منطقة هبوط النظام الأساسي. يمكن أن يكون الغرض هو الوصول إلى الموارد المحلية، والتحكم في حركة الخروج، وما إلى ذلك.
طبولوجيا الشبكة
يقرر فريق النظام الأساسي مخطط الشبكة للمؤسسة بأكملها. يفترض تخطيط الشبكة المحورية في هذه البنية. يمكن أن يكون البديل Azure Virtual WAN.
الشبكة الظاهرية للمركز الإقليمي
يحتوي اشتراك الاتصال ivity على شبكة ظاهرية مركزية مع موارد، والتي تشاركها المؤسسة بأكملها. هذه الموارد مملوكة ومصانة من قبل فريق النظام الأساسي.
من منظور المهام الحرجة، هذه الشبكة غير سريعة الزوال، وهذه الموارد على المسار الحرج.
مورد Azure | الغرض |
---|---|
Azure ExpressRoute | يوفر اتصالا خاصا من أماكن العمل إلى البنية الأساسية ل Azure. |
Azure Firewall | يعمل ك NVA الذي يفحص حركة الخروج ويقيدها. |
Azure DNS | يوفر تحليل الاسم في أماكن متعددة. |
بوابة VPN | الاتصال فروع المؤسسة البعيدة عبر الإنترنت العام إلى البنية الأساسية ل Azure. يعمل أيضا كبديل لاتصال النسخ الاحتياطي لإضافة المرونة. |
يتم توفير الموارد في كل منطقة ونظيرها إلى الشبكة الظاهرية المحورية (الموضحة بعد ذلك). تأكد من فهم التحديثات التي تم إجراؤها على NVA وقواعد جدار الحماية وقواعد التوجيه وفشل ExpressRoute في بوابة VPN والبنية الأساسية لنظام أسماء نطاقات وما إلى ذلك والموافقة عليها.
إشعار
تتمثل إحدى الفوائد الرئيسية في استخدام المركز الموحد في أن حمل العمل يمكن أن يتكامل مع أحمال العمل الأخرى إما في Azure أو عبر أماكن العمل عن طريق اجتياز مراكز الشبكة التي تديرها المؤسسة. يؤدي هذا التغيير أيضا إلى خفض تكاليف التشغيل الخاصة بك لأن جزءا من المسؤولية يتم نقله إلى فريق النظام الأساسي.
شبكة ظاهرية إقليمية محورية
تحتوي منطقة هبوط التطبيق على شبكتين ظاهريتين من Azure تم توفيرهما مسبقا، لكل منطقة، والتي تشير إليها الطوابع الإقليمية. هذه الشبكات غير سريعة الزوال. واحد يخدم حركة مرور الإنتاج والآخر يستهدف نشر vNext. يمنحك هذا النهج القدرة على تنفيذ ممارسات توزيع موثوقة وآمنة.
الشبكة الظاهرية للعمليات
يتم عزل حركة المرور التشغيلية في شبكة ظاهرية منفصلة. هذه الشبكة الظاهرية غير سريعة الزوال وأنت تملك هذه الشبكة. تحافظ هذه البنية على نفس تصميم البنية الأساسية مع عناصر التحكم في الشبكة.
لا يوجد تناظر بين شبكة العمليات وشبكة النظام المحوري. جميع الاتصالات من خلال الارتباطات الخاصة.
المسؤوليات المشتركة
لديك فهم واضح للفريق الذي يكون مسؤولا عن كل عنصر تصميم في البنية. فيما يلي بعض المجالات الرئيسية.
تخطيط عنوان IP
بعد تقدير الحجم المطلوب لتشغيل حمل العمل الخاص بك، اعمل مع فريق النظام الأساسي حتى يتمكنوا من توفير الشبكة بشكل مناسب.
فريق النظام الأساسي
توفير عناوين مميزة للشبكات الظاهرية التي تشارك في النظراء. يمكن أن تتسبب العناوين المتداخلة، على سبيل المثال الشبكات المحلية وشبكات حمل العمل، في حدوث اضطرابات تؤدي إلى انقطاع التيار الكهربائي.
تخصيص مساحات عناوين IP كبيرة بما يكفي لاحتواء وقت التشغيل وموارد النشر ومعالجة عمليات تجاوز الفشل ودعم قابلية التوسع.
يجب أن تكون الشبكة الظاهرية التي تم توفيرها مسبقا والأقران قادرة على دعم النمو المتوقع لحمل العمل. يجب عليك تقييم هذا النمو مع فريق النظام الأساسي بانتظام. لمزيد من المعلومات، راجع الاتصال ivity إلى Azure.
الشبكة الفرعية للشبكة الفرعية الإقليمية
أنت مسؤول عن تخصيص الشبكات الفرعية في الشبكة الظاهرية الإقليمية. الشبكات الفرعية والموارد فيها سريعة الزوال. يجب أن تكون مساحة العنوان كبيرة بما يكفي لاستيعاب النمو المحتمل.
الشبكة الفرعية لنقاط النهاية الخاصة بعد وصول نسبة استخدام الشبكة إلى الشبكة الظاهرية، يتم تقييد الاتصال بخدمات PaaS داخل الشبكة باستخدام نقاط النهاية الخاصة، تماما مثل بنية الأساس مع عناصر التحكم في الشبكة. يتم وضع نقاط النهاية هذه في شبكة فرعية مخصصة. يتم تعيين عناوين IP الخاصة إلى نقاط النهاية الخاصة من تلك الشبكة الفرعية.
الشبكة الفرعية للمجموعة تؤثر متطلبات قابلية التوسع لحمل العمل على مقدار مساحة العنوان التي يجب تخصيصها للشبكات الفرعية. مع توسيع نطاق عقد AKS والقرون، يتم تعيين عناوين IP من هذه الشبكة الفرعية.
تجزئة الشبكة
الحفاظ على التجزئة المناسبة بحيث لا تتعرض موثوقية حمل العمل للخطر من خلال الوصول غير المصرح به.
تستخدم هذه البنية مجموعات أمان الشبكة (NSGs) لتقييد نسبة استخدام الشبكة عبر الشبكات الفرعية والاشتراك الاتصال. تستخدم مجموعات أمان الشبكة ServiceTags للخدمات المدعومة.
فريق النظام الأساسي
فرض استخدام مجموعات أمان الشبكة من خلال نهج Azure Network Manager.
كن على دراية بتصميم حمل العمل. لا توجد أي حركة مرور مباشرة بين الطوابع. كما لا توجد تدفقات بين المناطق. إذا كانت هذه المسارات مطلوبة، يجب أن تتدفق نسبة استخدام الشبكة عبر اشتراك الاتصال ivity.
منع حركة مرور المركز غير الضرورية التي تنشأ من أحمال العمل الأخرى إلى حمل العمل الحرج للمهمة.
حركة الخروج من الطوابع الإقليمية
يتم توجيه جميع نسبة استخدام الشبكة الصادرة من كل شبكة إقليمية محورية من خلال جدار حماية Azure المركزي في شبكة المركز الإقليمي. وهو بمثابة القفزة التالية التي تفحص ثم تسمح أو ترفض حركة المرور.
فريق النظام الأساسي
إنشاء UDRs لهذا المسار المخصص.
تعيين نهج Azure التي ستمنع فريق التطبيق من إنشاء شبكات فرعية لا تحتوي على جدول التوجيه الجديد.
منح أذونات كافية للتحكم في الوصول استنادا إلى الدور (RBAC) لفريق التطبيق حتى يتمكنوا من توسيع المسارات استنادا إلى متطلبات حمل العمل.
التكرار متعدد المناطق
يجب نشر أحمال العمل ذات المهام الحرجة في مناطق متعددة لتحمل الانقطاعات الإقليمية. تعاون مع فريق النظام الأساسي للتأكد من موثوقية البنية الأساسية.
فريق النظام الأساسي
توزيع موارد الشبكات المركزية لكل منطقة. وتتطلب منهجية التصميم ذات المهام الحرجة عزلا إقليميا.
العمل مع فريق التطبيق للكشف عن التبعيات الإقليمية المخفية بحيث لا يؤثر مورد النظام الأساسي المتدهور في منطقة ما على أحمال العمل في منطقة أخرى.
دقة DNS
يوفر اشتراك الاتصال ivity مناطق DNS خاصة. ومع ذلك، قد لا يكون هذا النهج المركزي عاملا في احتياجات DNS التي قد تكون خاصة بحالة الاستخدام الخاصة بك. توفير مناطق DNS الخاصة بك والارتباط بالطابع الإقليمي. إذا لم يكن فريق التطبيق يمتلك DNS، فإن إدارة الارتباطات الخاصة تصبح صعبة للموارد العالمية، مثل Azure Cosmos DB.
فريق النظام الأساسي
تفويض مناطق Azure Private DNS إلى فريق التطبيق لتغطية حالات الاستخدام الخاصة بهم.
بالنسبة لشبكة المركز الإقليمي، قم بتعيين قيمة خوادم DNS إلى الافتراضي (المقدم من Azure) لدعم مناطق DNS الخاصة التي يديرها فريق التطبيق.
اعتبارات تصميم البيئة
من الممارسات العامة وضع أحمال العمل في بيئات منفصلة للإنتاج وما قبل الإنتاج والتطوير. فيما يلي بعض الاعتبارات الرئيسية.
كيف يتم الحفاظ على العزل؟
يجب عزل بيئة الإنتاج عن البيئات الأخرى. يجب أن تحافظ البيئات المنخفضة أيضا على مستوى من العزلة. تجنب مشاركة الموارد المملوكة للتطبيق بين البيئات.
هناك حاجة إلى بيئة إنتاج واحدة للموارد العالمية والإقليمية والموارد المخصصة المملوكة لفريق التطبيق. هناك حاجة إلى بيئات ما قبل الإنتاج، مثل التقسيم المرحلي والتكامل، للتأكد من اختبار التطبيق في بيئة تحاكي الإنتاج، قدر الإمكان. وينبغي أن تكون بيئة التطوير نسخة متدرجة من الإنتاج.
ما هي دورة الحياة المتوقعة؟
يمكن إتلاف بيئات ما قبل الإنتاج بعد اكتمال اختبارات التحقق من الصحة. يوصى بأن تشترك بيئات التطوير في عمر الميزة ويتم إتلافها عند اكتمال التطوير. هذه الإجراءات التي يتم تنفيذها عن طريق أتمتة التكامل المستمر/النشر المستمر (CI/CD).
ما هي المقايضات؟
ضع في اعتبارك المقايضات بين عزل البيئات وتعقيد الإدارة وتحسين التكلفة.
تلميح
يجب أن تأخذ جميع البيئات تبعيات على مثيلات الإنتاج للموارد الخارجية بما في ذلك موارد النظام الأساسي. على سبيل المثال، مركز إقليمي للإنتاج في اشتراك الاتصال ivity. ستتمكن من تقليل دلتا بين بيئات ما قبل الإنتاج والإنتاج.
مخطط الاشتراك للبنية الأساسية لحمل العمل
يتم تقديم الاشتراكات لك من قبل فريق النظام الأساسي. اعتمادا على عدد البيئات، ستطلب العديد من الاشتراكات لحمل عمل واحد فقط. اعتمادا على نوع البيئة، قد تحتاج بعض البيئات إلى اشتراكات مخصصة بينما قد يتم دمج بيئات أخرى في اشتراك واحد.
بغض النظر عن ذلك، اعمل مع فريق النظام الأساسي لتصميم مخطط يلبي هدف الموثوقية العام لحمل العمل. هناك فائدة لمشاركة الموارد التي يوفرها النظام الأساسي بين البيئات في نفس الاشتراك لأنها ستعكس بيئة الإنتاج.
إشعار
يمكن أن يؤدي استخدام اشتراكات متعددة لاحتواء البيئات إلى تحقيق المستوى المطلوب من العزل. يتم توريث اشتراكات المنطقة المنتقل إليها من نفس مجموعة الإدارة. لذلك، يتم ضمان الاتساق مع الإنتاج للاختبار والتحقق من الصحة.
اشتراك الإنتاج
قد تكون هناك حدود للموارد على الاشتراك الممنوح لك. إذا قمت بحجز كل هذه الموارد في اشتراك واحد، فقد تصل إلى هذه الحدود. استنادا إلى وحدات المقياس والمقياس المتوقع، ضع في اعتبارك نموذجا أكثر توزيعا. على سبيل المثال،
اشتراك واحد يحتوي على كل من عوامل إنشاء Azure DevOps والموارد العمومية.
اشتراك واحد، لكل منطقة. يحتوي على الموارد الإقليمية وموارد الطابع ومربعات الانتقال للطوابع الإقليمية.
فيما يلي مثال على مخطط الاشتراك المستخدم في هذه البنية.
اشتراك ما قبل الإنتاج
مطلوب اشتراك واحد على الأقل. ومع ذلك، فإنه يمكن تشغيل العديد من البيئات المستقلة، مع ذلك، يوصى بوجود بيئات متعددة في اشتراكات مخصصة. قد يخضع هذا الاشتراك أيضا لحدود الموارد مثل اشتراك الإنتاج، الموضح أعلاه.
اشتراك التطوير
مطلوب اشتراك واحد على الأقل. قد يخضع هذا الاشتراك لحدود الموارد إذا كان يشغل جميع البيئات المستقلة. لذلك، يمكنك طلب اشتراكات متعددة. يوصى بوجود بيئات فردية في اشتراكاتهم المخصصة.
حاول مطابقة مخطط الإنتاج قدر الإمكان.
اعتبارات النشر
عمليات النشر الفاشلة أو الإصدارات الخاطئة هي أسباب شائعة لانقطاع التطبيق. اختبر تطبيقك (والميزات الجديدة) بدقة كجزء من دورة حياة التطبيق. عند نشر حمل العمل في منطقة هبوط، ستحتاج إلى دمج تصميمك مع الموارد التي يوفرها النظام الأساسي والحوكمة.
راجع: أحمال العمل المهمة ذات التصميم الجيد: النشر والاختبار.
البنية الأساسية للنشر
غالبا ما تكون موثوقية البنية الأساسية للتوزيع، مثل عوامل البناء وشبكتهم، بنفس أهمية موارد وقت التشغيل لحمل العمل.
تستخدم هذه البنية عوامل البناء الخاصة لمنع الوصول غير المصرح به الذي يمكن أن يؤثر على توفر التطبيق.
يوصى بشدة بالاحتفاظ بالعزلة بين موارد التوزيع. يجب ربط البنية الأساسية للتوزيع باشتراك (اشتراكات) حمل العمل لتلك البيئة. إذا كنت تستخدم بيئات متعددة في اشتراكات ما قبل الإنتاج، فبادر بإنشاء فصل إضافي عن طريق الحد من الوصول إلى تلك البيئات الفردية فقط. يمكن اعتبار موارد النشر لكل منطقة لجعل البنية الأساسية للتوزيع أكثر موثوقية.
توزيع وقت التعطل الصفري
يمكن أن يؤدي التحديثات إلى التطبيق إلى انقطاع التيار الكهربائي. سيؤدي فرض عمليات نشر متسقة إلى تعزيز الموثوقية. يوصى بهذه الأساليب:
- لديك مسارات توزيع مؤتمتة بالكامل.
- نشر التحديثات في بيئات ما قبل الإنتاج على طابع نظيف.
لمزيد من المعلومات، راجع إرشادات النشر والاختبار الحرجة للمهام.
في البنية الأساسية، يتم تنفيذ هذه الاستراتيجيات عن طريق إلغاء التوفير ثم هدم الطابع مع كل تحديث. في هذا التصميم، لا يمكن إلغاء التوفير الكامل لأن فريق النظام الأساسي يمتلك بعض الموارد. لذلك تم تغيير نموذج التوزيع.
نموذج النشر
تستخدم البنية الأساسية نموذج Blue-Green لنشر تحديثات التطبيق. يتم نشر الطوابع الجديدة مع التغييرات جنبا إلى جنب مع الطوابع الموجودة. بعد نقل نسبة استخدام الشبكة إلى الطابع الجديد، يتم إتلاف الطابع الحالي.
في هذه الحالة، تكون الشبكة الظاهرية النظيرة المحددة غير سريعة الزوال. لا يسمح للطابع بإنشاء الشبكة الظاهرية أو التناظر مع المركز الإقليمي. ستحتاج إلى إعادة استخدام هذه الموارد في كل عملية نشر.
يمكن لنموذج الكناري تحقيق نشر آمن مع خيار العودة إلى الحالة السابقة. أولا، يتم نشر طابع جديد مع تغييرات التعليمات البرمجية. يشير مسار التوزيع إلى الشبكة الظاهرية التي تم توفيرها مسبقا ويخصص الشبكات الفرعية ويوزع الموارد ويضيف نقاط النهاية الخاصة. ثم يقوم بتحويل نسبة استخدام الشبكة إلى هذه الشبكات الفرعية في هذه الشبكة الظاهرية المقدمة مسبقا.
عندما لا يكون الطابع الموجود مطلوبا، يتم حذف كافة موارد الطوابع بواسطة المسار، باستثناء الموارد المملوكة للنظام الأساسي. يتم الاحتفاظ بالشبكة الظاهرية وإعدادات التشخيص والتناظر ومساحة عنوان IP وتكوين DNS والتحكم في الوصول المستند إلى الدور (RBAC). في هذه المرحلة، يكون الطابع في حالة نظيفة، وجاهز للتوزيع الجديد التالي.
نهج DINE (deploy-if-not-exists) Azure
قد يكون لمناطق هبوط تطبيق Azure نهج Azure DINE (deploy-if-not-exists). تضمن هذه الفحوصات أن الموارد المنشورة تفي بمعايير الشركة في المناطق المنتقل إليها للتطبيق، حتى عندما تكون مملوكة لفريق التطبيق. قد يكون هناك عدم تطابق بين التوزيع وتكوين المورد النهائي.
فهم تأثير جميع نهج DINE التي سيتم تطبيقها على مواردك. إذا كانت هناك تغييرات على تكوين الموارد، فدمج نية النهج في عمليات النشر التعريفية في وقت مبكر من دورة تطوير حمل العمل. وإلا، قد يكون هناك انحراف يؤدي إلى دلتا بين الحالة المطلوبة والحالة المنشورة.
إدارة الوصول إلى الاشتراك في النشر
تعامل مع حدود الاشتراك على أنها حدود أمان للحد من نصف قطر الانفجار. يمكن أن تؤثر التهديدات على موثوقية حمل العمل.
فريق النظام الأساسي
- امنح فرق التطبيق تخويلا للعمليات مع أذونات محددة النطاق لاشتراك المنطقة المنتقل إليها للتطبيق.
إذا كنت تقوم بتشغيل عمليات نشر متعددة ضمن اشتراك واحد، فسيؤثر الخرق على كل من عمليات التوزيع. يوصى بتشغيل عمليات التوزيع في الاشتراكات المخصصة. إنشاء كيانات الخدمة لكل بيئة للحفاظ على الفصل المنطقي.
يجب أن يوفر كيان الخدمة الاستقلالية على موارد حمل العمل. أيضا، يجب أن يكون لديها قيود في مكانها من شأنها أن تمنع المعالجة المفرطة لموارد النظام الأساسي داخل الاشتراك.
اعتبارات المراقبة
يوفر النظام الأساسي لمنطقة هبوط Azure موارد إمكانية المراقبة المشتركة كجزء من اشتراكات الإدارة. يشجع فريق العمليات المركزية فرق التطبيق على استخدام النموذج الموحد. ولكن بالنسبة لأحمال العمل ذات المهام الحرجة، لا يوصى بمخزن واحد مركزي للمراقبة لأنه قد يكون نقطة فشل واحدة. كما تولد أحمال العمل الحرجة للمهام بيانات تتبع الاستخدام التي قد لا تكون قابلة للتطبيق أو قابلة للتنفيذ لفرق العمليات المركزية.
لذلك، يوصى بشدة باتباع نهج مستقل للرصد. مشغلو حمل العمل مسؤولون في نهاية المطاف عن المراقبة ويجب أن يكون لديهم حق الوصول إلى جميع البيانات التي تمثل الصحة العامة.
تتبع البنية الأساسية هذا النهج وتستمر في هذه البنية المرجعية. يتم توزيع Azure Log Analytics وAzure Application Insights إقليميا وعالميا لمراقبة الموارد في تلك النطاقات. يعد تجميع السجلات وإنشاء لوحات المعلومات والتنبيه في نطاق فريقك. استفد من قدرات تشخيص Azure التي ترسل المقاييس والسجلات إلى متلقيات مختلفة لدعم متطلبات النظام الأساسي لمجموعة السجلات والمقاييس.
نموذج الصحة
تتطلب منهجية التصميم ذات المهام الحرجة نموذجا لصحة النظام. عند تحديد درجة صحية شاملة، قم بتضمين تدفقات المنطقة المنتقل إليها للنظام الأساسي في النطاق التي يعتمد عليها التطبيق. إنشاء استعلامات السجل والصحة والتنبيه لإجراء مراقبة عبر مساحة العمل.
فريق النظام الأساسي
امنح استعلام التحكم في الوصول المستند إلى الدور (RBAC) وقراءة متلقيات السجل لموارد النظام الأساسي ذات الصلة المستخدمة في المسار الحرج للتطبيق الحرج للمهمة.
دعم الهدف التنظيمي المتمثل في الموثوقية تجاه حمل العمل الحرج للمهمة من خلال منح فريق التطبيق الإذن الكافي للقيام بعملياته.
في هذه البنية، يتضمن نموذج الصحة سجلات ومقاييس من الموارد المقدمة في اشتراك الاتصال ivity. إذا قمت بتوسيع هذا التصميم للوصول إلى مورد محلي مثل قاعدة بيانات، يجب أن يتضمن نموذج الحماية اتصال الشبكة بهذا المورد، بما في ذلك حدود الأمان مثل الأجهزة الظاهرية للشبكة في Azure والأماكن المحلية. هذه المعلومات مهمة لتحديد السبب الجذري بسرعة ومعالجة تأثير الموثوقية. على سبيل المثال، هل حدث الفشل عند محاولة التوجيه إلى قاعدة البيانات، أم كانت هناك مشكلة في قاعدة البيانات؟
راجع: أحمال العمل الحرجة للمهام المصممة جيدا: نمذجة الصحة.
التكامل مع النهج والقواعد المقدمة من النظام الأساسي
يرث اشتراك المنطقة المنتقل إليها للتطبيق نهج Azure وقواعد Azure Network Manager وعناصر التحكم الأخرى من مجموعة الإدارة الخاصة به. يوفر فريق النظام الأساسي حواجز الحماية هذه.
بالنسبة إلى عمليات النشر، لا تعتمد على النهج المقدمة من النظام الأساسي حصريا، لأن:
- وهي ليست تصميما لتغطية احتياجات أحمال العمل الفردية.
- قد يتم تحديث النهج والقواعد أو إزالتها خارج فريقك، وبالتالي يمكن أن تؤثر على الموثوقية.
يوصى بشدة بإنشاء نهج Azure وتعيينها ضمن عمليات التوزيع الخاصة بك. قد يؤدي هذا الجهد إلى بعض الازدواجية ولكن هذا مقبول، بالنظر إلى التأثير المحتمل على موثوقية النظام. إذا كانت هناك تغييرات في نهج النظام الأساسي، ستظل نهج حمل العمل سارية محليا.
فريق النظام الأساسي
- إشراك فريق التطبيق في عملية إدارة التغيير للنهج أثناء تطورها.
- كن على دراية بالنهج المستخدمة من قبل فريق التطبيق. تقييم ما إذا كان يجب إضافتها إلى مجموعة الإدارة.
توزيع هذا الهيكل
وتنفذ جوانب الربط الشبكي لهذا الهيكل في التنفيذ الاتصال الحرج للبعثة.
إشعار
ويهدف التنفيذ الاتصال إلى توضيح حمل العمل الحرج للمهام الذي يعتمد على الموارد التنظيمية، ويدمج مع أحمال العمل الأخرى، ويستخدم الخدمات المشتركة. يفترض التنفيذ وجود اشتراك الاتصال ivity بالفعل.
الخطوات التالية
راجع منطقة تصميم الشبكات والاتصال في Azure Well-architected Framework.
الموارد ذات الصلة
بالإضافة إلى خدمات Azure المستخدمة في البنية الأساسية، تعد هذه الخدمات مهمة لهذه البنية.