البنية الأساسية لأجهزة Azure الظاهرية

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

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

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

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

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

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

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

بناء الأنظمة

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

للحصول على معلومات حول هذه الموارد، راجع وثائق منتج Azure المدرجة في الموارد ذات الصلة.

المكونات

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

موارد حمل العمل

• تعمل أجهزة Azure الظاهرية كمورد حساب للتطبيق ويتم توزيعها عبر مناطق التوفر. لأغراض توضيحية، يتم استخدام مزيج من كل من Windows وLinux VMs.

  يتم استخدام مجموعات مقياس الجهاز الظاهري Azure في وضع التنسيق المرن لتوفير الأجهزة الظاهرية وإدارتها.

  يمكن تمثيل نموذج التطبيق في مستويين، يتطلب كل منهما حسابه الخاص.

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

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

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

• Azure Application Gateway هي نقطة الدخول المفردة التي توجه الطلبات إلى خوادم الواجهة الأمامية. تتضمن وحدة SKU المحددة Azure Web Application Firewall المتكامل (WAF) للأمان الإضافي.

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

• يوفر Azure Load Balancer Standard SKU الوصول إلى الإنترنت الصادر إلى الأجهزة الظاهرية باستخدام ثلاثة عناوين IP عامة.

• يخزن Azure Key Vault الشهادات المستخدمة لاتصال أمان طبقة النقل من طرف إلى طرف (TLS). كما يمكن استخدامه للبيانات السرية للتطبيق.

موارد دعم حمل العمل

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

• تجمع Application Insights السجلات والمقاييس من التطبيق. نظرا لأن التطبيق ليس محور تركيز هذه البنية، لا يتم توضيح مجموعة السجل في التنفيذ.

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

تدفقات المستخدمين

هناك نوعان من المستخدمين الذين يتفاعلون مع موارد حمل العمل: مستخدم حمل العمل وعامل التشغيل. يتم عرض تدفقات هؤلاء المستخدمين في الرسم التخطيطي للبنية السابقة.

مستخدم حمل العمل

1. يصل المستخدم إلى موقع الويب باستخدام عنوان IP العام المكشوف لبوابة التطبيق.

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

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

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

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

عامل تشغيل

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

1. يقوم عامل التشغيل بتسجيل الدخول إلى مدخل Azure أو Azure CLI.
2. يصل عامل التشغيل إلى خدمة Azure Bastion ويتصل عن بعد بالجهاز الظاهري المطلوب.

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

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

• وحدة المعالجة المركزية والذاكرة وعمليات إدخال/إخراج القرص في الثانية (IOPS).
• بنية المعالجات.
• حجم صورة نظام التشغيل (OS).

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

للحصول على معلومات حول وحدات SKU للجهاز الظاهري المدعومة، راجع أحجام الأجهزة الظاهرية في Azure.

نظام تمهيد تشغيل الكمبيوتر

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

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

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

  • يجمع عامل Azure Monitor (AMA) بيانات المراقبة من نظام التشغيل الضيف ويسلمها إلى Azure Monitor.
  • يقوم Azure Custom Script Extension (Windows, Linux) الإصدار 2 بتنزيل البرامج النصية وتشغيلها على أجهزة Azure الظاهرية (VMs). هذا الملحق مفيد لأتمتة تكوين ما بعد التوزيع أو تثبيت البرامج أو أي مهام تكوين أو إدارة أخرى.
  • يوفر ملحق الجهاز الظاهري ل Azure Key Vault (Windows، Linux) تحديثا تلقائيا للشهادات المخزنة في Key Vault عن طريق الكشف عن التغييرات وتثبيت الشهادات المقابلة.
  • يعد ملحق Application Health مع مجموعات مقياس الجهاز الظاهري مهما عندما تقوم مجموعات مقياس الجهاز الظاهري Azure بالترقيات المتداولة التلقائية. يعتمد Azure على مراقبة السلامة للمثيلات الفردية لإجراء التحديثات. يمكنك أيضا استخدام الملحق لمراقبة صحة التطبيق لكل مثيل في مجموعة المقياس الخاصة بك وإجراء إصلاحات المثيل باستخدام إصلاحات المثيل التلقائي.
  • يتكامل معرف Microsoft Entra وOpenSSH (Windows، Linux) مع مصادقة Microsoft Entra. يمكنك الآن استخدام معرف Microsoft Entra كمنصة مصادقة أساسية ومرجع مصدق إلى SSH في جهاز ظاهري يعمل بنظام Linux باستخدام معرف Microsoft Entra والمصادقة المستندة إلى شهادة OpenSSH. تسمح لك هذه الوظيفة بإدارة الوصول إلى الأجهزة الظاهرية باستخدام التحكم في الوصول استنادا إلى الدور (RBAC) ونهج الوصول المشروط.

• التكوين المستند إلى العامل. يمكن لأجهزة Linux الظاهرية استخدام تكوين الحالة المطلوبة الأصلية الخفيفة المتوفرة من خلال cloud-init على صور الأجهزة الظاهرية المختلفة المتوفرة من Azure. يتم تحديد التكوين وإصداره باستخدام البيانات الاصطناعية IaC. يعد جلب حل إدارة التكوين الخاص بك طريقة أخرى. تتبع معظم الحلول نهجا تعريفيا أولا لتمهيد التشغيل، ولكنها تدعم البرامج النصية المخصصة للمرونة. تتضمن الخيارات الشائعة تكوين الحالة المطلوبة لنظام التشغيل Windows، وتكوين الحالة المطلوبة ل Linux، و Ansible، و Chef، و Puppet، وغيرها. يمكن إقران جميع حلول التكوين هذه مع ملحقات الجهاز الظاهري للحصول على أفضل تجربة من كليهما.

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

راجع إطار عمل جيد التصميم: RE:02 - توصيات لتصميم الأتمتة.

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

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

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

مجموعات مقياس الجهاز الظاهري مع تزامن مرن

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

يسهل وضع التزامن المرن العمليات على نطاق واسع ويساعد في قرارات التحجيم الدقيقة.

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

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

الأقراص

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

يوفر Azure مجموعة من الخيارات من حيث الأداء والتنوع والتكلفة. ابدأ ب Premium SSD لمعظم أحمال عمل الإنتاج. يعتمد اختيارك على VM SKU. تحتوي وحدات SKU التي تدعم Premium SSD على s في اسم المورد، على سبيل المثال Dsv4 ولكن ليس Dv4.

لمزيد من المعلومات حول خيارات القرص مع مقاييس مثل السعة وIOOPS ومعدل النقل، راجع مقارنة نوع القرص.

ضع في اعتبارك خصائص القرص وتوقعات الأداء عند تحديد قرص.

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

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

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

  تعتمد سعة أقراص نظام التشغيل سريعة الزوال على VM SKU المختار. تأكد من أن حجم قرص صورة نظام التشغيل أقل من ذاكرة التخزين المؤقت المتوفرة ل SKU أو القرص المؤقت. يمكنك استخدام المساحة المتبقية للتخزين المؤقت.

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

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

  يمكنك ضبط الأداء عند الطلب عن طريق تغيير مستويات الأداء أو باستخدام ميزات الاندفاع المتوفرة في بعض وحدات SKU للقرص المدارة.

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

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

  لا تتطلب المكونات التي تقوم أساسا بعمليات القراءة تناسق معاملات القرص العالي. يمكن أن تستفيد هذه المكونات من التخزين المؤقت للقراءة فقط. غالبا ما يتم تعطيل التخزين المؤقت للمكونات الثقيلة للكتابة التي تتطلب تناسق معاملات عالي القرص.

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

في هذه البنية:

• أقراص نظام التشغيل لجميع الأجهزة الظاهرية سريعة الزوال وتقع على قرص ذاكرة التخزين المؤقت.

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

• كل جهاز ظاهري لديه قرص Premium SSD P1 المدار الخاص به، ما يوفر معدل نقل أساسي مخصص مناسب لحمل العمل.

تخطيط الشبكة

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

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

الشبكة الظاهرية

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

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

في هذه البنية، يتم تعيين مساحة العنوان إلى /21، وهو قرار يستند إلى النمو المتوقع.

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

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

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

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

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

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

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

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

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

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

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

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

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

حساب المنافذ لكل مثيل ك: Number of front-end IPs * 64K / Maximum number of back-end instances.

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

دقة DNS

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

يتم استخدام مناطق DNS الخاصة ل Azure لحل الطلبات إلى نقاط النهاية الخاصة المستخدمة للوصول إلى موارد Private Link المسماة.

مراقبة‬

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

يتم إنشاء المقاييس والسجلات في مصادر بيانات مختلفة، ما يوفر رؤى إمكانية المراقبة على ارتفاعات مختلفة:

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

• يوفر مستوى التطبيق رؤى حول أداء وسلوك التطبيقات التي تعمل على نظامك.

مساحة عمل Log Analytics هي متلقي بيانات المراقبة الموصى به المستخدم لجمع السجلات والمقاييس من موارد Azure وApplication Insights.

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

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

المراقبة على مستوى البنية الأساسية

يرتبط هذا الجدول بالسجلات والمقاييس التي تم جمعها بواسطة Azure Monitor. تساعدك التنبيهات المتوفرة على معالجة المشكلات بشكل استباقي قبل أن تؤثر على المستخدمين.

مورد Azure	المقاييس والسجلات	التنبيهات
Application Gateway	وصف مقاييس وسجلات Application Gateway	تنبيهات بوابة التطبيق
Application Insights	مقاييس Application Insights وتسجيل واجهة برمجة التطبيقات	تنبيهات Application Insights
Azure Bastion	مقاييس Azure Bastion
Key Vault	مقاييس Key Vault ووصف السجلات	تنبيهات Key Vault
Standard Load Balancer	سجلات ومقاييس موازن التحميل	تنبيهات موازن التحميل
عنوان IP العام	مقاييس عنوان IP العام ووصف السجلات	تنبيهات مقاييس عنوان IP العام
شبكة ظاهرية	مقاييس الشبكة الظاهرية ومرجع السجلات	تنبيهات الشبكة الظاهرية
الأجهزة الظاهرية ومجموعات مقياس الجهاز الظاهري	مرجع مقاييس وسجلات الجهاز الظاهري	تنبيهات الجهاز الظاهري والبرامج التعليمية
جدار حماية تطبيق الويب	وصف سجلات ومقاييس جدار حماية تطبيق الويب	تنبيهات جدار حماية تطبيق الويب

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

الأجهزة الظاهرية

يتم تمكين تشخيصات تمهيد Azure لمراقبة حالة الأجهزة الظاهرية أثناء التمهيد عن طريق جمع معلومات السجل التسلسلي ولقطات الشاشة. في هذه البنية، يمكن الوصول إلى هذه البيانات من خلال مدخل Microsoft Azure والأمر Azure CLI vm boot-diagnostics get-boot-log. تتم إدارة البيانات بواسطة Azure وليس لديك أي تحكم أو وصول إلى مورد التخزين الأساسي. ومع ذلك، إذا كانت متطلبات عملك تتطلب المزيد من التحكم، يمكنك توفير حساب التخزين الخاص بك لتخزين تشخيصات التمهيد.

توفر رؤى الجهاز الظاهري طريقة فعالة لمراقبة الأجهزة الظاهرية ومجموعات المقياس. فهو يجمع البيانات من مساحات عمل Log Analytics ويوفر مصنفات محددة مسبقا لبيانات الأداء المتداولة. يمكن عرض هذه البيانات لكل جهاز ظاهري أو تجميعها عبر أجهزة ظاهرية متعددة.

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

الشبكات

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

مقابل الأقراص المُدارة

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

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

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

المراقبة على مستوى التطبيق

على الرغم من أن التنفيذ المرجعي لا يستخدمه، يتم توفير Application Insights ك Application Performance Management (APM) لأغراض القابلية للتوسعة. تجمع Application Insights البيانات من أحد التطبيقات وترسل تلك البيانات إلى مساحة عمل Log Analytics. كما يمكنه تصور تلك البيانات من تطبيقات حمل العمل.

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

إدارة التحديثات

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

تحديثات البنية الأساسية

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

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

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

ترقيات صورة نظام التشغيل (OS)

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

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

يجب أن تمثل عملية الأتمتة الخاصة بك الإفراط في التزويد بسعة إضافية.

يمكنك استخدام Azure Update Management لإدارة تحديثات نظام التشغيل لأجهزة Windows وLinux الظاهرية في Azure.Azure Update Manager يوفر حل SaaS لإدارة تحديثات البرامج وإدارتها لأجهزة Windows وLinux عبر بيئات Azure والبيئات المحلية ومتعددة السحابات.

تصحيح نظام التشغيل الضيف

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

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

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

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

كن على دراية بالمفاضلة بين التكلفة المرتبطة بالإفراط في التوفير.

يتم تضمين عمليات التحقق من الصحة كجزء من التصحيح التلقائي لضيف الجهاز الظاهري. تتحقق هذه الفحوصات من تطبيق التصحيح الناجح وتكشف عن المشكلات.

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

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

الموثوقيه

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

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

جميع المكونات الأخرى في هذه البنية هي إما:

• المنطقة زائدة عن الحاجة، ما يعني أنه يتم نسخها عبر مناطق متعددة للحصول على قابلية وصول عالية، مثل بوابة التطبيق أو عناوين IP العامة.
• مرونة المنطقة، مما يعني أنه يمكنهم تحمل فشل المنطقة، مثل Key Vault.
• الموارد الإقليمية أو العالمية المتوفرة عبر المناطق أو على مستوى العالم، مثل معرف Microsoft Entra.

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

تستند الاستراتيجيات المستخدمة في التصميم إلى قائمة التحقق من مراجعة تصميم الموثوقية الواردة في Azure Well-Architected Framework. تتم إضافة تعليقات توضيحية إلى الأقسام مع توصيات من قائمة الاختيار هذه.

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

تحديد أولويات ضمانات الموثوقية لكل تدفق مستخدم

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

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

راجع إطار عمل جيد التصميم: RE:02 - توصيات لتحديد تدفقات التقييم وتقييمها.

تحديد نقاط الفشل المحتملة

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

المكون	مخاطر	الاحتمالية	التأثير/التخفيف/الملاحظة	انقطاع
Microsoft Entra ID	خطأ في التكوين	متوسط	يتعذر على مستخدمي العمليات تسجيل الدخول. لا يوجد تأثير انتقال البيانات من الخادم. يبلغ مكتب المساعدة عن مشكلة في التكوين لفريق الهوية.	بلا
Application Gateway	خطأ في التكوين	متوسط	يجب اكتشاف التكوينات الخاطئة أثناء النشر. إذا حدثت هذه الأخطاء أثناء تحديث التكوين، يجب على فريق DevOps التراجع عن التغييرات. تستغرق معظم عمليات النشر التي تستخدم V2 SKU حوالي 6 دقائق لتوفيرها. ومع ذلك يمكن أن تستغرق وقتًا أطول وفقًا لنوع النشر. على سبيل المثال، يمكن أن تستغرق عمليات التوزيع عبر مناطق توفر متعددة مع العديد من المثيلات أكثر من 6 دقائق.	كامل
Application Gateway	هجوم موزع لحجب الخدمة	متوسط	احتمالية التعطيل. تدير Microsoft حماية DDoS (L3 وL4). خطر التأثير المحتمل من هجمات L7.	كامل
مجموعات توسيع الجهاز الظاهري	انقطاع الخدمة	منخفض	انقطاع محتمل لحمل العمل إذا كانت هناك مثيلات جهاز ظاهري غير صحية تؤدي إلى إعادة دفع تلقائي. تعتمد على Microsoft للمعالجة.	الانقطاع المحتمل
مجموعات توسيع الجهاز الظاهري	انقطاع منطقة التوفر	منخفض	لا يوجد تأثير. يتم نشر مجموعات المقياس كمنطقة زائدة عن الحاجة.	بلا

راجع إطار عمل جيد التصميم: RE:03 - توصيات لإجراء تحليل وضع الفشل.

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

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

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

تدفق العملية

المكون	SLO
Microsoft Entra ID	99.99%
Azure Bastion	99.95%

SLO المركب: 99.94٪ | وقت التعطل في السنة: 0d 5h 15m 20s

تدفق مستخدم التطبيق

المكون	SLO
Application Gateway	99.95%
موازن تحميل Azure (داخلي)	99.99%
الأجهزة الظاهرية الأمامية باستخدام التخزين المتميز (SLO المركب)	99.70%
الأجهزة الظاهرية الخلفية باستخدام التخزين المتميز (SLO المركب)	99.70%

SLO المركب: 99.34٪ | وقت التعطل في السنة: 2d 9h 42m 18s

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

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

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

راجع إطار عمل جيد التصميم: RE:04 - توصيات لتحديد أهداف الموثوقية.

التكرار

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

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

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

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

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

  جميع عناوين IP العامة المستخدمة في هذه البنية زائدة عن الحاجة في المنطقة.

• يقدم Azure خدمات مرنة للمنطقة للحصول على موثوقية أفضل، مثل Key Vault.

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

راجع إطار عمل جيد التصميم: RE:05 - توصيات لتصميم التكرار.

استراتيجية التحجيم

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

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

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

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

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

راجع إطار عمل جيد التصميم: RE:06 - توصيات لتصميم استراتيجية تحجيم موثوق بها.

الشفاء الذاتي والاسترداد

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

راجع إطار عمل جيد التصميم: توصيات للشفاء الذاتي والحفاظ على الذات.

الأمان

توضح هذه البنية بعض ضمانات الأمان الواردة في قائمة التحقق من مراجعة تصميم الأمان الواردة في Azure Well-Architected Framework. تتم إضافة تعليقات توضيحية إلى الأقسام مع توصيات من قائمة الاختيار هذه.

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

التقسيم

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

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

• تجزئة الهوية. تعيين أدوار مميزة لهويات مختلفة بأذونات كافية للقيام بمهمتها. تستخدم هذه البنية الهويات التي يديرها معرف Microsoft Entra لتقسيم الوصول إلى الموارد.

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

راجع إطار عمل جيد التصميم: SE:04 - توصيات لبناء استراتيجية تجزئة.

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

نوصي بمعرف Microsoft Entra للمصادقة والتخويل لكل من المستخدمين والخدمات.

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

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

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

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

راجع إطار عمل جيد التصميم: SE:05 - توصيات لإدارة الهوية والوصول.

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

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

  يتم توفير المزيد من الأمان من خلال Web Application Firewall المدمج مع Application Gateway. لديها قواعد تفحص نسبة استخدام الشبكة الواردة ويمكنها اتخاذ الإجراء المناسب. يتتبع WAF نقاط الضعف في مشروع أمان تطبيق ويب المفتوح (OWASP) التي تمنع الهجمات المعروفة.

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

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

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

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

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

  في هذه البنية، تتم حماية حركة المرور التشغيلية باستخدام قواعد NSG لتقييد حركة المرور، ويتم تمكين الوصول إلى الجهاز الظاهري في الوقت المناسب (JIT) على الأجهزة الظاهرية. تسمح هذه الميزة من Microsoft Defender for Cloud بالوصول الداخلي المؤقت إلى المنافذ المحددة.

  لتحسين الأمان، استخدم Microsoft Entra إدارة الهويات المتميزة (PIM). PIM هي خدمة في معرف Microsoft Entra تتيح لك إدارة الوصول إلى الموارد المهمة في مؤسستك والتحكم فيه ومراقبته. توفر PIM تنشيطًا للدور المستند إلى الوقت والمستند إلى الموافقة؛ للتخفيف من مخاطر أذونات الوصول المفرطة أو غير الضرورية أو التي تم إساءة استخدامها على الموارد التي تهتم بها.

• الاتصال الخاص بخدمات النظام الأساسي كخدمة (PaaS). الاتصال بين الأجهزة الظاهرية وKey Vault عبر Private Link. تتطلب هذه الخدمة نقاط نهاية خاصة، والتي يتم وضعها في شبكة فرعية منفصلة.

• حماية DDOS. ضع في اعتبارك تمكين Azure DDoS Protection على عناوين IP العامة التي تعرضها بوابة التطبيق ومضيف Azure Bastion للكشف عن التهديدات. توفر حماية DDoS أيضا التنبيه وبيانات تتبع الاستخدام والتحليلات من خلال Monitor. لمزيد من المعلومات، راجع حماية Azure DDoS: أفضل الممارسات والبنى المرجعية.

راجع إطار عمل جيد التصميم: SE:06 - توصيات للشبكات والاتصال.

التشفير

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

  • app.contoso.com: شهادة خارجية يستخدمها العملاء وبوابة التطبيق لحركة مرور الإنترنت العامة الآمنة.
  • *.workload.contoso.com: شهادة حرف بدل تستخدمها مكونات البنية الأساسية لحركة المرور الداخلية الآمنة.

• البيانات الثابتة. يتم تخزين بيانات السجل في قرص مدار مرفق بالأجهزة الظاهرية. يتم تشفير هذه البيانات تلقائيا باستخدام التشفير المقدم من النظام الأساسي على Azure.

راجع إطار عمل جيد التصميم: SE:07 - توصيات لتشفير البيانات.

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

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

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

تستخدم الأجهزة الظاهرية ملحق Key Vault VM لتحديث الشهادات المراقبة تلقائيا. إذا تم الكشف عن أي تغييرات في مخزن الشهادات المحلي، يقوم الملحق باسترداد الشهادات المقابلة وتثبيتها من Key Vault. يدعم الملحق أنواع محتوى الشهادة PKCS #12 وPEM.

راجع إطار عمل جيد التصميم: SE:09 - توصيات لحماية أسرار التطبيق.

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

يجب استيفاء متطلبات حمل العمل مع مراعاة قيود التكلفة. تستند الاستراتيجيات المستخدمة في البنية إلى قائمة التحقق من مراجعة تصميم Cost Optimization الواردة في Azure Well-Architected Framework. يصف هذا القسم بعض الخيارات لتحسين التكلفة ويتم توضيحه بتوصيات من قائمة الاختيار هذه.

تكلفة المكون

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

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

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

راجع إطار عمل جيد التصميم: CO:07 - توصيات لتحسين تكاليف المكونات.

تكلفة التدفق

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

راجع إطار عمل جيد التصميم: CO:09 - توصيات لتحسين تكاليف التدفق.

تكلفة التحجيم

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

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

راجع إطار عمل جيد التصميم: CO:12 - توصيات لتحسين تكاليف التحجيم.

التكاليف التشغيلية

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

راجع إطار عمل جيد التصميم: CO:13 - توصيات لتحسين وقت الموظفين.

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

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

الموارد ذات الصلة

راجع وثائق المنتج للحصول على تفاصيل حول خدمات Azure المحددة:

• أجهزة Azure الظاهرية
• مجموعات توسعة الأجهزة الظاهرية في Azure
• الشبكة الافتراضية في Azure
• Standard_v2 بوابة تطبيق Azure
• موازن تحميل Azure
• Azure Key Vault
• Azure Bastion
• Application Insights
• تحليلات السجل

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

راجع البنيات المرجعية ل IaaS التي تعرض خيارات طبقة البيانات:

• تطبيق Windows N-tier باستخدام SQL Server على Azure