البنية الأساسية لأجهزة Azure الظاهرية في منطقة هبوط Azure

تتوسع البنية في هذه المقالة على البنية الأساسية للجهاز الظاهري (VM) لمعالجة التغييرات والتوقعات عند نشرها في منطقة هبوط Azure.

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

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

تخطيط المقالة

بناء الأنظمة	قرار التصميم	نهج Azure Well-Architected Framework
▪ رسم تخطيطي للبنية ▪ موارد حمل العمل ▪ الموارد الموحدة	▪ إعداد الاشتراك ▪ متطلبات الشبكات ▪ تغييرات تصميم الشبكة من الأساس ▪ رصد ▪ توافق التصحيح ▪ الحوكمة التنظيمية ▪ إدارة التغيير	▪ موثوقيه ▪ الامن ▪ تحسين التكلفة

بناء الأنظمة

قم بتنزيل ملف Visio لهذه البنية.

المكونات

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

الموارد المملوكة لفريق العمل

تظل الموارد التالية في الغالب دون تغيير عن البنية الأساسية.

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

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

• يتم استخدام Azure Application Gateway كوكيل عكسي لتوجيه طلبات المستخدم إلى الأجهزة الظاهرية الأمامية. يتم أيضا استخدام SKU المحدد لاستضافة Azure Web Application Firewall لحماية الأجهزة الظاهرية الأمامية من نسبة استخدام الشبكة الضارة المحتملة.

• يتم استخدام Azure Key Vault لتخزين أسرار التطبيق وشهاداته.

• يتم استخدام Azure Monitor وLog Analytics وApplication Insights لجمع بيانات إمكانية المراقبة وتخزينها وتصورها.

• يتم استخدام نهج Azure لتطبيق النهج الخاصة بحمل العمل.

يحتفظ فريق حمل العمل بالموارد والمسؤوليات التالية ويفي بها.

• الشبكات الفرعية للشبكة الظاهرية المحورية ومجموعات أمان الشبكة (NSGs) التي يتم وضعها على تلك الشبكات الفرعية للحفاظ على التجزئة والتحكم في تدفق نسبة استخدام الشبكة.

• نقاط النهاية الخاصة لتأمين الاتصال بحلول النظام الأساسي كخدمة (PaaS) ومناطق DNS الخاصة المطلوبة لنقاط النهاية هذه.

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

الموارد المملوكة لفريق النظام الأساسي

يمتلك فريق النظام الأساسي هذه الموارد المركزية ويحافظ عليها. تفترض هذه البنية أن هذه الموارد تم توفيرها مسبقا وتعتبرها تبعيات.

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

• يوفر Azure Bastion في شبكة المركز وصولا تشغيليا آمنا إلى أجهزة حمل العمل الظاهرية. في بنية الأساس، يمتلك فريق حمل العمل هذا المكون.

• الشبكة الظاهرية المحورية هي المكان الذي يتم فيه نشر حمل العمل.

• تستخدم المسارات المعرفة من قبل المستخدم (UDRs) لفرض الاتصال النفقي إلى شبكة المركز.

• تعد قيود الحوكمة المستندة إلى نهج Azure ونهج DeployIfNotExists (DINE) جزءا من اشتراك حمل العمل.

إعداد الاشتراك

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

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

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

على سبيل المثال، يتم النظر في مجموعات الإدارة في سيناريوهات التطبيق لبنية الأساس:

• التطبيقات الخاصة، مثل تطبيقات خط الأعمال الداخلية أو الحلول التجارية الجاهزة (COTS)، والتي غالبا ما تقع ضمن مجموعة إدارة Corp لمناطق هبوط Azure.

• التطبيقات العامة، كما هو الحال في التطبيقات التي تواجه الإنترنت، والتي غالبا ما تكون ضمن مجموعة إدارة Corp أو Online.

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

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

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

متطلبات حمل العمل والوفاء به

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

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

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

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

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

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

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

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

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

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

• وصول عامل التشغيل: إذا كانت هناك مجموعات أمان Microsoft Entra ID يستخدمها المشغلون للوصول إلى الأجهزة الظاهرية عبر Azure Bastion، قم بإبلاغ فريق النظام الأساسي. عادة ما يكون Azure Bastion موردا مركزيا. من الضروري التأكد من أن مجموعات الأمان والأجهزة الظاهرية تدعم البروتوكول الآمن.

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

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

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

اختيارات تصميم الجهاز الظاهري

تظل تحديدات VM SKU والقرص هي نفسها بنية الأساس.

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

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

الشبكات

في البنية الأساسية، يتم توفير حمل العمل في شبكة ظاهرية واحدة. يدير فريق حمل العمل الشبكة الظاهرية.

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

قم بتنزيل ملف Visio لهذه البنية.

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

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

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

الشبكات الفرعية للشبكة الظاهرية

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

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

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

استخدام الشبكة الداخل:⁦⁩

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

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

استخدام الشبكة الخارج:⁦⁩

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

هذا التصميم مختلف في هذه البنية. يتم توجيه جميع نسبة استخدام الشبكة التي تترك الشبكة الظاهرية المحورية من خلال شبكة المركز النظيرة عبر جدار حماية الخروج. يتم إرفاق مسار بجميع الشبكات الفرعية المحتملة في الشبكة المحورية التي توجه جميع نسبة استخدام الشبكة لعناوين IP غير الموجودة في الشبكة الظاهرية المحلية (0.0.0.0/0) إلى جدار حماية Azure الخاص بالمركز.

قم بتنزيل ملف Visio لهذه البنية.

يظل اتصال حمل العمل بنقطة النهاية الخاصة للوصول إلى Key Vault هو نفسه بنية الأساس. يتم حذف هذا المسار من الرسم التخطيطي السابق للإيجاز.

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

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

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

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

مناطق DNS الخاصة

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

في هذه البنية، يضمن فريق النظام الأساسي دقة DNS الخاصة الموثوقة لنقاط نهاية الارتباط الخاص. تعاون مع فريق النظام الأساسي لفهم توقعاتهم.

اختبار الاتصال ivity

بالنسبة للبنى المستندة إلى الجهاز الظاهري، هناك العديد من أدوات الاختبار التي يمكن أن تساعد في تحديد مشكلات خط رؤية الشبكة والتوجيه وDNS. يمكنك استخدام أدوات استكشاف الأخطاء وإصلاحها التقليدية، مثل netstatأو nslookupأو .tcping بالإضافة إلى ذلك، يمكنك فحص إعدادات بروتوكول التكوين الديناميكي للمضيف (DHCP) وإعدادات DNS لمحول الشبكة. إذا كانت هناك بطاقات NIC، فلديك المزيد من قدرات استكشاف الأخطاء وإصلاحها التي تمكنك من إجراء عمليات التحقق من الاتصال باستخدام Azure Network Watcher.

وصول عامل التشغيل

مثل البنية الأساسية، يتم دعم الوصول التشغيلي من خلال Azure Bastion في هذه البنية.

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

هوية عامل التشغيل

تستخدم هذه البنية نفس ملحق المصادقة مثل البنية الأساسية.

ابدأ دائما بمبدأ الوصول الأقل امتيازا ونقاوة إلى مهمة بدلا من الوصول طويل الأمد. في سياق منطقة الهبوط، استفد من دعم الوقت المناسب (JIT) الذي يديره فريق النظام الأساسي.

توافق التصحيح وترقيات نظام التشغيل

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

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

مراقبة‬

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

يقوم فريق حمل العمل بتوفير موارد المراقبة، والتي تشمل:

• Application Insights كخدمة لمراقبة أداء التطبيق (APM) لفريق حمل العمل.

• مساحة عمل Log Analytics كمتلقي موحد لجميع السجلات والمقاييس التي يتم جمعها من موارد Azure المملوكة لحمل العمل ورمز التطبيق.

قم بتنزيل ملف Visio لهذه البنية.

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

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

ربط البيانات من متلقيات متعددة

يتم تخزين سجلات ومقاييس حمل العمل ومكونات بنيته الأساسية في مساحة عمل Log Analytics لحمل العمل. ومع ذلك، يتم تخزين السجلات والمقاييس التي تنشئها الخدمات المركزية، مثل Azure Firewall ومعرف Microsoft Entra وAzure Bastion، في مساحة عمل Log Analytics مركزية. يمكن أن يكون ربط البيانات من متلقيات متعددة مهمة معقدة.

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

نهج Azure

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

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

إدارة التغييرات بمرور الوقت

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

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

تغييرات النظام الأساسي التي تؤثر على حمل العمل

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

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

• قواعد جدار الحماية: يمكن أن تؤثر التعديلات على قواعد جدار الحماية على الشبكة الظاهرية لحمل العمل أو القواعد التي تنطبق على نطاق واسع عبر جميع نسب استخدام الشبكة. يمكن أن تؤدي هذه التعديلات إلى حظر حركة المرور وحتى فشل العملية الصامتة، مثل فشل تطبيق تصحيحات نظام التشغيل. تنطبق هذه المشاكل المحتملة على كل من جدار حماية الخروج من Azure وقواعد NSG المطبقة على Azure Virtual Network Manager.

• الموارد المشتركة: يمكن أن تؤثر التغييرات في SKU أو الميزات على الموارد المشتركة على حمل العمل.

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

• مضيف Azure Bastion: يمكن أن تؤثر التغييرات على توفر مضيف Azure Bastion أو تكوينه على عمليات حمل العمل. تأكد من أن تغييرات نمط الوصول إلى مربع الانتقال لها روتين فعال ووصول مخصص وطارىء.

• تغييرات الملكية: قم بتوصيل أي تغييرات في الملكية ونقاط الاتصال إلى فريق حمل العمل لأنها يمكن أن تؤثر على طلبات إدارة ودعم حمل العمل.

تغييرات حمل العمل التي تؤثر على النظام الأساسي

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

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

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

• تصنيف أهمية الأعمال: إذا كانت هناك تغييرات على اتفاقيات مستوى الخدمة لحمل العمل (SLAs)، فقد تحتاج إلى نهج تعاون جديد بين النظام الأساسي وفرق حمل العمل.

• تغييرات الملكية: إبلاغ فريق النظام الأساسي بالتغييرات في الملكية ونقاط الاتصال.

تغييرات متطلبات عمل حمل العمل

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

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

الموثوقيه

تتوافق هذه البنية مع ضمانات الموثوقية في البنية الأساسية.

أهداف الموثوقية

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

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

لمزيد من المعلومات، راجع التوصيات لتحديد أهداف الموثوقية.

التبعيات الهامة

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

بالنسبة إلى هذه البنية، ضع في اعتبارك التبعيات التالية:

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

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

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

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

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

لمزيد من المعلومات، راجع التوصيات لإجراء تحليل وضع الفشل.

الأمان

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

عناصر التحكم في الشبكة

تكوين عناصر التحكم في الشبكة بشكل صحيح للتأكد من أن حمل العمل الخاص بك آمن.

استخدام الشبكة الداخل:⁦⁩

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

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

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

المصدر	الغرض	التحكم في حمل العمل	التحكم في النظام الأساسي
الإنترنت	تدفقات نسبة استخدام الشبكة للمستخدم	قمع جميع الطلبات من خلال NSG وجدار حماية تطبيق الويب وقواعد التوجيه قبل السماح لحركة المرور العامة بالانتقال إلى نسبة استخدام الشبكة الخاصة التي تدخل الأجهزة الظاهرية الأمامية	بلا
Azure Bastion	وصول عامل التشغيل إلى الأجهزة الظاهرية	NSG على الشبكات الفرعية للجهاز الظاهري التي تحظر جميع نسبة استخدام الشبكة إلى منافذ الوصول عن بعد، ما لم يتم الحصول عليها من الشبكة الفرعية Azure Bastion المعينة للنظام الأساسي	بلا
المتحدثون الآخرون	بلا	محظور عبر قواعد NSG	قواعد التوجيه غير الناقل أو Azure Firewall في حالة مركز Azure Virtual WAN الآمن

استخدام الشبكة الخارج:⁦⁩

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

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

يعرض الجدول التالي أمثلة على الخروج في هذه البنية.

نقطة النهاية	الغرض	عنصر تحكم حمل العمل (NSG)	عنصر تحكم النظام الأساسي (المركز)
ntp.ubuntu.com	بروتوكول وقت الشبكة (NTP) لأجهزة Linux الظاهرية	UDP/123 إلى الإنترنت على الشبكة الفرعية للجهاز الظاهري الأمامي (جدار حماية الخروج يضيق هذا الفتح الواسع)	بدل قاعدة شبكة جدار الحماية لنفس عنصر التحكم في حمل العمل
نقاط نهاية Windows Update	وظائف Windows Update من خوادم Microsoft	TCP/443 وTCP /80 إلى الإنترنت على الشبكة الفرعية للجهاز الظاهري الخلفي (جدار حماية الخروج يضيق هذا الفتح الواسع)	قاعدة بدل جدار الحماية مع علامة FQDN ل WindowsUpdate
مراقبة نقاط نهاية العامل	نسبة استخدام الشبكة المطلوبة لملحق Monitor على الأجهزة الظاهرية	TCP/443 إلى الإنترنت على كل من الشبكات الفرعية للجهاز الظاهري (جدار حماية الخروج يضيق هذا الفتح الواسع)	بدلات قاعدة تطبيق جدار الحماية الضرورية لجميع FQDNs المحددة على TCP/443
nginx.org	لتثبيت Nginx (مثال على مكون التطبيق) مباشرة من المورد	TCP/443 إلى الإنترنت على الشبكة الفرعية للجهاز الظاهري الأمامي (جدار حماية الخروج يضيق هذا الفتح الواسع)	بدل قاعدة تطبيق جدار الحماية الضرورية nginx.org على TCP/443
Key Vault	لاستيراد شهادات TLS (أمان طبقة النقل) في بوابة التطبيق والأجهزة الظاهرية	- TCP/443 إلى شبكة فرعية خاصة لنقطة النهاية من كلتا الشبكات الفرعية للجهاز الظاهري إلى شبكة فرعية خاصة لنقطة النهاية - TCP/443 إلى شبكة فرعية خاصة لنقطة النهاية من شبكة فرعية لبوابة التطبيق - TCP/443 من الأجهزة الظاهرية الموسومة بتعيين مجموعة أمان التطبيقات المطلوبة (ASG) والشبكة الفرعية لبوابة التطبيق	بلا

DDOS protection

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

لمزيد من المعلومات، راجع التوصيات للشبكات والاتصال.

إدارة البيانات السرية

لإدارة البيانات السرية، تتبع هذه البنية البنية الأساسية.

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

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

تحسين التكلفة

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

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

يدير فريق النظام الأساسي الموارد التالية في هذه البنية. غالبا ما تستند هذه الموارد إلى الاستهلاك (استرداد التكاليف) أو قد تكون مجانية لفريق حمل العمل.

• Azure Firewall
• إدارة معلومات الأمان والأحداث (SIEM)
• مضيفو Azure Bastion
• الاتصال عبر أماكن العمل، مثل ExpressRoute

استفد من العروض المركزية الأخرى من فريق النظام الأساسي الخاص بك لتوسيع هذه الفوائد إلى حمل العمل الخاص بك دون المساس ب SLO أو هدف وقت الاسترداد (RTO) أو هدف نقطة الاسترداد (RPO).

لمزيد من المعلومات، راجع التوصيات لجمع بيانات التكلفة ومراجعتها.

نشر هذا السيناريو

يتوفر نشر لهذه البنية المرجعية على GitHub.

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

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

بيع الاشتراك