الشبكات والاتصال لأحمال العمل الحرجة للمهام على Azure

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

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

هام

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

توجيه نسبة استخدام الشبكة العمومية

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

يوفر Azure Front DoorوAzure Traffic ManagerوAzure Standard Load Balancer إمكانات التوجيه المطلوبة لإدارة نسبة استخدام الشبكة العالمية عبر تطبيق متعدد المناطق.

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

يستكشف هذا القسم الاختلافات الرئيسية في خدمات توجيه Azure لتحديد كيفية استخدام كل منها لتحسين السيناريوهات المختلفة.

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

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

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

  • يمكن اعتبار تقنيات التوجيه العالمية المتعددة، مثل Azure Front Door وAzure Traffic Manager، بالتوازي مع التكرار، مع تكوين العملاء للفشل في تقنية بديلة عند استيفاء شروط فشل معينة. يقدم إدخال خدمات توجيه عالمية متعددة تعقيدات كبيرة حول التخزين المؤقت للحافة وقدرات جدار حماية تطبيق الويب وإدارة الشهادات لإلغاء تحميل SSL والتحقق من صحة التطبيق لمسارات الدخول.
  • يمكن أيضا النظر في تقنيات الجهات الخارجية، ما يوفر مرونة توجيه عالمية لجميع مستويات فشل النظام الأساسي ل Azure.

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

• Azure Front Door وAzure Traffic Manager هما خدمات موزعة عالميا مع تكرار وتوافر مضمنين متعدد المناطق.

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

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

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

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

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

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

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

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

Azure Front Door

• يوفر Azure Front Door موازنة تحميل HTTP/S عمومية والاتصال المحسن باستخدام بروتوكول Anycast مع TCP المقسم للاستفادة من شبكة Microsoft الأساسية العالمية.

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

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

• يمكن استخدام Azure Web Application Firewall (WAF) على Azure Front Door، وبما أنه يتم نشره في مواقع حافة شبكة Azure في جميع أنحاء العالم، فإن كل طلب وارد يتم تسليمه بواسطة Front Door يتم فحصه على حافة الشبكة.

• يحمي Azure Front Door نقاط نهاية التطبيق من هجمات DDoS باستخدام حماية Azure DDoS الأساسية. يوفر Azure DDoS Standard إمكانات حماية واكتشاف إضافية وأكثر تقدما ويمكن إضافتها كطبقة إضافية إلى Azure Front Door.

• يوفر Azure Front Door خدمة شهادة مدارة بالكامل. تمكين أمان اتصال TLS لنقاط النهاية دون الحاجة إلى إدارة دورة حياة الشهادة.

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

• يعتمد Azure Front Door على فحوصات السلامة ونقاط نهاية صحة الواجهة الخلفية (عناوين URL) التي يتم استدعاؤها على أساس فاصل زمني لإرجاع رمز حالة HTTP يعكس ما إذا كانت الواجهة الخلفية تعمل بشكل طبيعي، مع استجابة HTTP 200 (OK) تعكس حالة صحية. بمجرد أن تعكس الواجهة الخلفية حالة غير صحية، من منظور عقدة حافة معينة، ستتوقف عقدة الحافة هذه عن إرسال الطلبات هناك. لذلك تتم إزالة الخلفيات غير السليمة بشفافية من تداول نسبة استخدام الشبكة دون أي تأخير.

• يدعم بروتوكولات HTTP/S فقط.

• يوفر Azure Front Door WAF وApplication Gateway WAF مجموعة ميزات مختلفة قليلا، على الرغم من أن كل منهما يدعم القواعد المضمنة والمخصصة ويمكن تعيينه للعمل إما في وضع الكشف أو وضع الوقاية.

• قد تتغير مساحة IP الخلفية ل Front Door، ولكن Microsoft ستضمن التكامل مع نطاقات AZURE IP وعلامات الخدمة. من الممكن الاشتراك في نطاقات IP Azure وعلامات الخدمة لتلقي إعلامات حول أي تغييرات أو تحديثات.

• يدعم Azure Front Door تكوينات توزيع التحميل المختلفة:

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

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

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

Azure Traffic Manager

• Azure Traffic Manager هي خدمة إعادة توجيه DNS.

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

• يتم تخزين استجابة DNS مؤقتا وإعادة استخدامها من قبل العميل لفترة زمنية محددة (TTL)، وستنتقل الطلبات التي تم إجراؤها خلال هذه الفترة مباشرة إلى نقطة النهاية الخلفية دون تفاعل Traffic Manager. يلغي خطوة الاتصال الإضافية التي توفر مزايا التكلفة مقارنة ب Front Door.

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

• على غرار Azure Front Door، يعتمد Azure Traffic Manager أيضا على تحقيقات السلامة لفهم ما إذا كانت الواجهة الخلفية سليمة وتعمل بشكل طبيعي. إذا تم إرجاع قيمة أخرى أو لم يتم إرجاع أي شيء، فإن خدمة التوجيه تتعرف على المشكلات المستمرة وستتوقف عن توجيه الطلبات إلى تلك الخلفية المحددة.

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

Azure Standard Load Balancer

هام

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

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

• استخدم Azure Front Door كخدمة توجيه نسبة استخدام الشبكة العمومية الأساسية لسيناريوهات HTTP/S. يتم الدعوة بشدة إلى Azure Front Door لأحمال عمل HTTP/S لأنها توفر توجيها محسنا لنسبة استخدام الشبكة، وتجاوز الفشل الشفاف، ونقاط النهاية الخلفية الخاصة (مع Premium SKU)، والتخزين المؤقت للحافة والتكامل مع جدار حماية تطبيق الويب (WAF).

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

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

تعرض هذه الصورة تكوين موازن تحميل عمومي متكرر مع تجاوز فشل العميل باستخدام Azure Front Door كموازن تحميل عمومي أساسي.

هام

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

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

• على الرغم من عدم الموصى به، بالنسبة لأحمال عمل HTTP (أحمال العمل) باستخدام Azure Traffic Manager للتكرار العام للتوجيه إلى Azure Front Door، ضع في اعتبارك إلغاء تحميل جدار حماية تطبيق الويب (WAF) إلى بوابة التطبيق لنسبة استخدام الشبكة المقبولة المتدفقة عبر Azure Front Door.
  • سيؤدي ذلك إلى إدخال نقطة فشل إضافية لمسار الدخول القياسي، وهو مكون إضافي للمسار الحرج للإدارة والتحجيم، وسيتكبد أيضا تكاليف إضافية لضمان قابلية الوصول العالية عالميا. ومع ذلك، فإنه سيبسط سيناريو الفشل بشكل كبير من خلال توفير التناسق بين مسارات الدخول المقبولة وغير المقبولة من خلال Azure Front Door وAzure Traffic Manager، سواء من حيث تنفيذ WAF ولكن أيضا نقاط نهاية التطبيق الخاصة.
  • سيؤثر فقدان التخزين المؤقت للحافة في سيناريو الفشل على الأداء العام، ويجب أن يكون هذا متوافقا مع مستوى مقبول من الخدمة أو نهج التصميم المخفف. لضمان مستوى متسق من الخدمة، ضع في اعتبارك إلغاء تحميل التخزين المؤقت للحافة إلى موفر CDN تابع لجهة خارجية لكلا المسارين.

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

Azure Front Door

• استخدم خدمة الشهادات المدارة من Azure Front Door لتمكين اتصالات TLS، وإزالة الحاجة إلى إدارة دورات حياة الشهادة.

• استخدم Azure Front Door Web Application Firewall (WAF) لتوفير الحماية على الحافة من عمليات استغلال الويب الشائعة والثغرات الأمنية، مثل حقن SQL.

• استخدم ذاكرة التخزين المؤقت المضمنة في Azure Front Door لخدمة المحتوى الثابت من عقد الحافة.

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

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

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

• تأكد من تسجيل استجابات فحص السلامة واستيعاب جميع البيانات التشغيلية التي يعرضها Azure Front Door في مساحة عمل Log Analytics العالمية لتسهيل متلقي بيانات موحد وعرض تشغيلي واحد عبر التطبيق بأكمله.

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

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

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

Azure Traffic Manager

• استخدم Traffic Manager لسيناريوهات غير HTTP/S كبديل ل Azure Front Door. ستؤدي اختلافات القدرة إلى اتخاذ قرارات تصميم مختلفة لقدرات ذاكرة التخزين المؤقت وWAF وإدارة شهادات TLS.

• يجب النظر في قدرات WAF داخل كل منطقة لمسار دخول Traffic Manager، باستخدام بوابة تطبيق Azure.

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

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

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

• يجب إيلاء الاعتبار لموفري CDN التابعين لجهة خارجية من أجل تحقيق التخزين المؤقت للحافة عند استخدام Azure Traffic Manager كخدمة توجيه عمومية أساسية. حيث يتم تقديم قدرات EDGE WAF أيضا من قبل خدمة الجهات الخارجية، يجب مراعاة تبسيط مسار الدخول وربما إزالة الحاجة إلى بوابة التطبيق.

خدمات توصيل الطلبات

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

يعتمد هذا القسم على توصيات التوجيه العمومية من خلال استكشاف إمكانات تسليم التطبيقات الرئيسية، مع مراعاة الخدمات ذات الصلة مثل Azure Standard Load Balancer وAzure Application Gateway وAzure API Management.

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

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

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

• يوفر Azure WAF حماية خارج الصندوق ضد أهم 10 ثغرات أمنية OWASP باستخدام مجموعات القواعد المدارة.

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

• يمكن أيضا اعتبار تقنيات WAF التابعة لجهة خارجية مثل NVAs ووحدات التحكم المتقدمة في الدخول داخل Kubernetes لتوفير الحماية المطلوبة من الثغرات الأمنية.

• يتطلب تكوين WAF الأمثل عادة ضبطا دقيقا، بغض النظر عن التكنولوجيا المستخدمة.

  Azure Front Door

• يقبل Azure Front Door حركة مرور HTTP وHTTPS فقط، وسيعالج الطلبات فقط بعنوان معروف Host . يساعد حظر البروتوكول هذا على التخفيف من الهجمات الحجمية المنتشرة عبر البروتوكولات والمنافذ، وتضخيم DNS وهجمات تسمم TCP.

• Azure Front Door هو مورد Azure عمومي لذلك يتم نشر التكوين عالميا في جميع مواقع الحافة.

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

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

• تقوم Azure Front Door بتدوير الشهادات "المدارة" تلقائيا قبل 60 يوما على الأقل من انتهاء صلاحية الشهادة للحماية من مخاطر الشهادة منتهية الصلاحية. إذا تم استخدام الشهادات المدارة ذاتيا، يجب نشر الشهادات المحدثة في موعد لا يتجاوز 24 ساعة قبل انتهاء صلاحية الشهادة الموجودة، وإلا فقد يتلقى العملاء أخطاء شهادة منتهية الصلاحية.

• ستؤدي تحديثات الشهادة فقط إلى وقت تعطل إذا تم تبديل Azure Front Door بين "Managed" و"Use Your Own Certificate".

• Azure Front Door محمي بواسطة Azure DDoS Protection Basic، والذي يتم دمجه في Front Door بشكل افتراضي. يوفر هذا مراقبة حركة المرور دائما، والتخفيف في الوقت الحقيقي، ويدافع أيضا ضد الفيضانات الشائعة لاستعلام DNS من الطبقة 7 أو هجمات الطبقة 3/4 الحجمية.

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

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

  Azure Load Balancer

• لا يتم دعم Azure Basic Load Balancer SKU بواسطة اتفاقية مستوى الخدمة ولها العديد من قيود القدرة مقارنة ب SKU القياسية.

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

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

• استخدم الاتصالات المشفرة (مثل HTTPS) من النقطة التي يحدث فيها إلغاء تحميل TLS إلى الواجهات الخلفية للتطبيق الفعلي. لن تكون نقاط نهاية التطبيق مرئية للمستخدمين النهائيين، لذلك يمكن استخدام المجالات المدارة من Azure، مثل azurewebsites.net أو cloudapp.net، مع الشهادات المدارة.

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

• تمكين قدرات WAF في موقع خدمة واحد، إما عالميا باستخدام Azure Front Door أو إقليميا باستخدام Azure Application Gateway، لأن هذا يبسط ضبط التكوين الدقيق ويحسن الأداء والتكلفة.

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

• حدد أولويات استخدام Azure Front Door WAF لأنه يوفر أغنى مجموعة ميزات أصلية في Azure ويطبق الحماية على الحافة العالمية، ما يبسط التصميم العام ويدفع المزيد من الكفاءات.

• استخدم Azure API Management فقط عند تعريض عدد كبير من واجهات برمجة التطبيقات للعملاء الخارجيين أو فرق التطبيقات المختلفة.

• استخدم Azure Standard Load Balancer SKU لأي سيناريو توزيع نسبة استخدام الشبكة الداخلية داخل أحمال عمل خدمة micros.

  • يوفر اتفاقية مستوى الخدمة بنسبة 99.99٪ عند نشرها عبر مناطق التوفر.
  • يوفر قدرات مهمة مثل التشخيصات أو القواعد الصادرة.

• استخدم Azure DDoS Network Protection للمساعدة في حماية نقاط النهاية العامة المستضافة داخل كل شبكة ظاهرية للتطبيق.

التخزين المؤقت وتسليم المحتوى الثابت

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

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

• لا يتم إنشاء كل المحتوى الذي يتيحه الحل عبر الإنترنت ديناميكيا. تخدم التطبيقات كلا من الأصول الثابتة (الصور وJavaScript وCSS وملفات الترجمة وما إلى ذلك) والمحتوى الديناميكي.
• تستفيد أحمال العمل ذات المحتوى الثابت الذي يتم الوصول إليه بشكل متكرر بشكل كبير من التخزين المؤقت لأنه يقلل من الحمل على خدمات الواجهة الخلفية ويقلل من زمن انتقال الوصول إلى المحتوى للمستخدمين النهائيين.
• يمكن تنفيذ التخزين المؤقت في الأصل داخل Azure باستخدام إما Azure Front Door أو Azure Content Delivery Network (CDN).
  • يوفر Azure Front Door إمكانات التخزين المؤقت للحافة الأصلية من Azure وميزات التوجيه لتقسيم المحتوى الثابت والديناميكي.
    • من خلال إنشاء قواعد التوجيه المناسبة في Azure Front Door، /static/* يمكن إعادة توجيه نسبة استخدام الشبكة بشفافية إلى محتوى ثابت.
  • يمكن تنفيذ سيناريوهات التخزين المؤقت الأكثر تعقيدا باستخدام خدمة Azure CDN لإنشاء شبكة تسليم محتوى كاملة لوحدات تخزين محتوى ثابتة كبيرة.
    • من المحتمل أن تكون خدمة Azure CDN أكثر فعالية من حيث التكلفة، ولكنها لا توفر نفس إمكانات التوجيه المتقدمة وجدار حماية تطبيق الويب (WAF) الموصى بها لمجالات أخرى من تصميم التطبيق. ومع ذلك، فإنه يوفر مزيدا من المرونة للتكامل مع خدمات مماثلة من حلول الجهات الخارجية، مثل Akamai وVerizon.
  • عند مقارنة خدمات Azure Front Door وAzure CDN، يجب استكشاف عوامل القرار التالية:
    • يمكن إنجاز قواعد التخزين المؤقت المطلوبة باستخدام محرك القواعد.
    • حجم المحتوى المخزن والتكلفة المقترنة به.
    • سعر كل شهر لتنفيذ محرك القواعد (يتم تحصيله لكل طلب على Azure Front Door).
    • متطلبات نسبة استخدام الشبكة الصادرة (يختلف السعر حسب الوجهة).

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

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

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

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

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

1. التطبيق العامدون اتصال شبكة الشركة.
2. التطبيق العاممع اتصال شبكة الشركة.
3. تطبيق خاصمع اتصال شبكة الشركة.

تنبيه

عند التوزيع داخل منطقة هبوط Azure، التكوين 1. يجب توزيعها داخل منطقة منتقل إليها عبر الإنترنت، بينما يجب توزيع كل من 2) و3) داخل Corp. Connected Landing Zone لتسهيل التكامل على مستوى الشبكة.

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

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

لا توجد شبكات ظاهرية

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

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

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

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

الشبكات الظاهرية المعزولة

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

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

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

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

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

• Azure Bastion هي خدمة PaaS مدارة بالكامل من قبل النظام الأساسي يمكن نشرها على شبكة ظاهرية وتوفر اتصال RDP/SSH آمنا بالأجهزة الظاهرية ل Azure. عند الاتصال عبر Azure Bastion، لا تحتاج الأجهزة الظاهرية إلى عنوان IP عام.

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

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

الشبكات الظاهرية المتصلة

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

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

• ستنشئ مساحات عناوين IP المتداخلة عبر مناطق Azure أو الشبكات المحلية تنازعا رئيسيا عند النظر في تكامل الشبكة.

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

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

  • يمكن تغيير حجم دائرة ExpressRoute لتوفير نطاقات ترددية تصل إلى 100 جيجابت في الثانية.
  • يمكن تغيير حجم الشبكة الظاهرية الخاصة (VPN) لتوفير نطاق ترددي مجمع يصل إلى 10 جيجابت في الثانية في شبكات المركز والتحدث، وما يصل إلى 20 جيجابت في الثانية في Azure Virtual WAN.

ملاحظة

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

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

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

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

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

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

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

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

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

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

  • ضع في اعتبارك Kubenet للسيناريوهات ذات عناوين IP المتاحة ذات الغضب المحدود لتناسب التطبيق ضمن مساحة عنوان مقيدة.

  • حدد أولويات استخدام المكون الإضافي لشبكة Azure CNI لتكامل شبكة AKS وفكر في Kubenet للسيناريوهات ذات نطاق محدود من عناوين IP المتاحة. راجع نهج شبكة التجزئة الصغيرة وkubernetes لمزيد من التفاصيل.

• بالنسبة للسيناريوهات التي تتطلب تكامل شبكة محلية، حدد أولويات استخدام Express Route لضمان اتصال آمن وقابل للتطوير.

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

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

  ملاحظة

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

• استخدم Azure Bastion أو الاتصالات الخاصة المنقلة للوصول إلى مستوى بيانات موارد Azure أو تنفيذ عمليات الإدارة.

خروج الإنترنت

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

1. تفاعل مستخدم التطبيق المباشر.
2. تكامل التطبيق مع التبعيات الخارجية خارج Azure.
3. الوصول إلى التبعيات الخارجية المطلوبة من قبل خدمات Azure المستخدمة من قبل التطبيق.

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

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

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

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

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

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

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

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

  • يوفر Azure Firewall إمكانات أمان مناسبة لتأمين خروج الشبكة.

  • يمكن استخدام جدار حماية Azure (أو NVA مكافئ) لتأمين متطلبات خروج Kubernetes من خلال توفير تحكم دقيق في تدفقات نسبة استخدام الشبكة الصادرة.

• ستتحمل كميات كبيرة من خروج الإنترنت رسوما على نقل البيانات.

بوابة Azure NAT

• تدعم بوابة Azure NAT 64000 اتصال ل TCP وUDP لكل عنوان IP صادر معين.

  • يمكن تعيين ما يصل إلى 16 عنوان IP إلى بوابة NAT واحدة.
  • مهلة خامدة TCP افتراضية تبلغ 4 دقائق. إذا تم تغيير مهلة الخمول إلى قيمة أعلى، فسيتم الاحتفاظ بالتدفقات لفترة أطول، مما سيزيد من الضغط على مخزون منفذ SNAT.

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

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

• تقليل عدد اتصالات الإنترنت الصادرة لأن هذا سيؤثر على أداء NAT.

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

• استخدم Azure Firewall حيث توجد متطلبات للتحكم في حركة مرور الإنترنت الصادرة وفحصها.

  • تأكد من عدم استخدام Azure Firewall لفحص نسبة استخدام الشبكة بين خدمات Azure.

ملاحظة

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

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

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

الاتصال بين المناطق والمنطقة

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

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

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

• منطقة التوفر (AZ) هي موقع مركز بيانات منفصل فعليا داخل منطقة Azure، ما يوفر عزلا ماديا ومنطقيا للخطأ حتى مستوى مركز بيانات واحد.

  يتم ضمان زمن انتقال ذهابا وإيابا أقل من 2 مللي ثانية للاتصال بين المناطق. سيكون للمناطق تباين زمن انتقال صغير نظرا لمسافات متنوعة ومسارات ألياف بين المناطق.

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

• يتم التعامل مع مناطق التوفر ككيانات منطقية في سياق اشتراك واحد، لذلك قد يكون للاشتراكات المختلفة تعيين نطاقي مختلف لنفس المنطقة. على سبيل المثال، يمكن أن تتوافق المنطقة 1 في الاشتراك أ مع نفس مركز البيانات الفعلي مثل المنطقة 2 في الاشتراك B.

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

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

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

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

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

• بالنسبة للخدمات لخدمة الاتصال يمكن استخدام الارتباط الخاص للاتصال المباشر باستخدام نقاط النهاية الخاصة.

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

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

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

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

• استخدم تناظر الشبكة الظاهرية لتوصيل الشبكات داخل منطقة وعبر مناطق مختلفة. يوصى بشدة بتجنب تثبيت الشعر داخل Express Route.

• استخدم Private Link لإنشاء اتصال مباشرة بين الخدمات في نفس المنطقة أو عبر المناطق (الخدمة في المنطقة أ التي تتواصل مع الخدمة في المنطقة ب.

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

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

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

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

نهج شبكة التجزئة الصغيرة وKubernetes

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

يمكن للتطبيق المهم فرض أمان الشبكة على مستوى التطبيق باستخدام مجموعات أمان الشبكة (NSG) على مستوى الشبكة الفرعية أو واجهة الشبكة وقوائم التحكم في الوصول إلى الخدمة (ACL) ونهج الشبكة عند استخدام خدمة Azure Kubernetes (AKS).

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

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

• يمكن توزيع AKS في نموذجين مختلفين للشبكات:

  • شبكة Kubenet: يتم دمج عقد AKS داخل شبكة ظاهرية موجودة، ولكن توجد وحدات الجراب داخل شبكة تراكب ظاهرية على كل عقدة. يتم توجيه نسبة استخدام الشبكة بين القرون على عقد مختلفة من خلال kube-proxy.
  • شبكة Azure Container Networking Interface (CNI): يتم دمج نظام مجموعة AKS داخل شبكة ظاهرية موجودة والعقد والقرون والخدمات التي تلقت عناوين IP من نفس الشبكة الظاهرية التي يتم إرفاق عقد نظام المجموعة بها. هذا مناسب لسيناريوهات الشبكات المختلفة التي تتطلب اتصالا مباشرا من وإلى pods. يمكن توزيع تجمعات عقد مختلفة في شبكات فرعية مختلفة.

  ملاحظة

  يتطلب Azure CNI مساحة عنوان IP أكبر مقارنة ب Kubenet. مطلوب التخطيط المسبق المناسب وتغيير حجم الشبكة. لمزيد من المعلومات، راجع وثائق Azure CNI.

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

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

  • تدعم AKS اثنين من المكونات الإضافية التي تنفذ نهج الشبكة، Azure و Calico. يستخدم كلا المكونين الإضافيين Linux IPTables لفرض النهج المحددة. راجع الاختلافات بين نهج Azure وCalico وقدراتها لمزيد من التفاصيل.
  • لا تتعارض نهج الشبكة لأنها مضافة.
  • لكي يسمح بتدفق الشبكة بين جرابين، يحتاج كل من نهج الخروج على الجراب المصدر ونهج الدخول على الجراب الوجهة إلى السماح بنسبة استخدام الشبكة.
  • لا يمكن تمكين ميزة نهج الشبكة إلا في وقت إنشاء مثيل نظام المجموعة. لا يمكن تمكين نهج الشبكة على نظام مجموعة AKS موجود.
  • تسليم نهج الشبكة متسق بغض النظر عما إذا كان يتم استخدام Azure أو Calico.
  • يوفر Calico مجموعة ميزات أكثر ثراء، بما في ذلك دعم عقد windows ويدعم Azure CNI بالإضافة إلى Kubenet.

• تدعم AKS إنشاء تجمعات عقد مختلفة لفصل أحمال العمل المختلفة باستخدام العقد ذات خصائص مختلفة للأجهزة والبرامج، مثل العقد ذات إمكانات GPU وبدونها.

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

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

• قم بتكوين NSG على جميع الشبكات الفرعية المعتبرة لتوفير IP ACL لتأمين مسارات الدخول وعزل مكونات التطبيق استنادا إلى نموذج ثقة معدومة.

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

  • يجب تعطيل حركة مرور الإنترنت العامة على منافذ RDP وSSH عبر جميع مجموعات NSG القابلة للتطبيق.

  • حدد أولويات استخدام المكون الإضافي لشبكة Azure CNI وفكر في Kubenet للسيناريوهات ذات نطاق محدود من عناوين IP المتوفرة لتناسب التطبيق ضمن مساحة عنوان مقيدة.

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

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

  • تمكين نهج الشبكة لخدمة Azure Kubernetes في وقت التوزيع.
  • تحديد أولويات استخدام Calico لأنه يوفر مجموعة ميزات أكثر ثراء مع اعتماد ودعم أوسع للمجتمع.

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

راجع اعتبارات القياس الكمي لصحة التطبيق ومراقبتها.

نمذجة الصحة وإمكانية الملاحظة