استكشاف مشكلات الاتصال الصادر ل Azure Load Balancer وإصلاحها
تعرف على إرشادات استكشاف الأخطاء وإصلاحها للاتصالات الصادرة في Azure Load Balancer. يتضمن ذلك فهم ترجمة عنوان الشبكة المصدر (SNAT) وتأثيرها على الاتصالات، واستخدام عناوين IP العامة الفردية على الأجهزة الظاهرية، وتصميم التطبيقات لكفاءة الاتصال لتجنب استنفاد منفذ SNAT. ترجع معظم المشكلات المتعلقة بالاتصال الصادر الذي يواجهه العملاء إلى استنفاد منفذ SNAT ومهلات الاتصال التي تؤدي إلى الحزم التي تم إسقاطها.
لمعرفة المزيد حول منافذ SNAT، راجع ترجمة عنوان شبكة المصدر للاتصالات الصادرة.
فهم استخدام منفذ SNAT الخاص بك
اتبع تشخيصات موازن التحميل القياسية باستخدام المقاييس والتنبيهات وسلامة الموارد لمراقبة استخدام منفذ SNAT الخاص بموازن التحميل الحالي وتخصيصه. راقب لتأكيد أو تحديد خطر استنفاد SNAT. إذا كنت تواجه مشكلة في فهم سلوك الاتصال الصادر، فاستخدم إحصائيات مكدس IP (netstat) أو اجمع لقطات الحزم. يمكنك تنفيذ عمليات التقاط الحزم هذه في نظام التشغيل الضيف للمثيل الخاص بك أو استخدام مراقب شبكة لالتقاط الحزمة. بالنسبة لمعظم السيناريوهات، يوصي Azure باستخدام بوابة NAT للاتصال الصادر لتقليل خطر استنفاد SNAT. يوصى بشدة باستخدام بوابة NAT إذا كانت خدمتك تقوم ببدء اتصالات TCP أو UDP الصادرة المتكررة إلى نفس الوجهة.
تحسين عمليات توزيع Azure للاتصال الصادر
من المهم تحسين عمليات توزيع Azure للاتصال الصادر. يمكن أن يمنع التحسين المشكلات المتعلقة بالاتصال الصادر أو يخفف منها.
نشر بوابة NAT للاتصال بالإنترنت الصادر
Azure NAT Gateway هي خدمة Azure مرنة للغاية وقابلة للتطوير توفر اتصالا صادرا بالإنترنت من شبكتك الظاهرية. يساعد الأسلوب الفريد لاستهلاك منافذ SNAT لبوابة NAT في حل مشكلات استنفاد SNAT والاتصال الشائعة. لمزيد من المعلومات حول Azure NAT Gateway، راجع ما هي بوابة Azure NAT؟.
كيف تقلل بوابة NAT من خطر استنفاد منفذ SNAT؟
يقوم موازنة التحميل في Azure بتخصيص كميات ثابتة من منافذ SNAT لكل مثيل جهاز ظاهري في تجمع خلفي. يمكن أن يؤدي أسلوب التخصيص هذا إلى استنفاد SNAT، خاصة إذا كانت أنماط نسبة استخدام الشبكة غير المتساوية تؤدي إلى إرسال جهاز ظاهري معين لحجم أكبر من الاتصالات الصادرة. على عكس موازن التحميل، تعمل بوابة NAT على تخصيص منافذ SNAT ديناميكيًا عبر جميع مثيلات الأجهزة الظاهرية داخل شبكة فرعية.
تعمل بوابة NAT على توفير إمكانية الوصول إلى منافذ SNAT إلى كل مثيل في شبكة فرعية. يسمح هذا التخصيص الديناميكي لمثيلات الجهاز الظاهري باستخدام عدد منافذ SNAT التي تحتاجها كل منها من مجموعة المنافذ المتوفرة للاتصالات الجديدة. يقلل التخصيص الديناميكي من خطر استنفاد SNAT.
سلوك تحديد المنفذ وإعادة استخدامه.
تحدد بوابة NAT المنافذ عشوائيًا من مجموعة المنافذ المتوفرة. إذا لم تكن هناك منافذ متوفرة، تتم إعادة استخدام منافذ SNAT طالما لا يوجد اتصال موجود بنفس عنوان IP العام للوجهة والمنفذ. هذا التحديد للمنفذ وسلوك إعادة استخدام بوابة NAT يجعلها أقل عرضة لمواجهة مهلات الاتصال.
لمعرفة المزيد حول كيفية عمل SNAT واستخدام المنفذ لبوابة NAT، راجع أساسيات SNAT. هناك بعض الحالات التي لن تتمكن فيها من استخدام بوابة NAT للاتصالات الصادرة. لمزيد من المعلومات حول قيود بوابة NAT، راجع قيود بوابة NAT.
إذا لم تتمكن من استخدام بوابة NAT للاتصال الصادر، فراجع خيارات الترحيل الأخرى الموضحة في هذه المقالة.
تكوين قواعد موازن التحميل الصادرة لزيادة منافذ SNAT لكل جهاز ظاهري إلى أقصى حد
إذا كنت تستخدم موازن تحميل قياسي عام وواجهت استنفاد SNAT أو فشل الاتصال، فتأكد من أنك تستخدم القواعد الصادرة باستخدام التخصيص اليدوي للمنفذ. وإلا، فمن المحتمل أنك تعتمد على الوصول الصادر الافتراضي لموازنة التحميل. يقوم الوصول الصادر الافتراضي تلقائيًا بتخصيص عدد متحفظ من المنافذ، والذي يستند إلى عدد المثيلات في تجمع الواجهة الخلفية. الوصول الصادر الافتراضي ليس أسلوبًا مستحسنًا لتمكين الاتصالات الصادرة. عندما يتم توسيع نطاق تجمع الواجهة الخلفية، قد تتأثر اتصالاتك إذا كانت هناك حاجة إلى إعادة تخصيص المنافذ.
لمعرفة المزيد حول الوصول الصادر الافتراضي وتخصيص المنفذ الافتراضي، راجع ترجمة عنوان شبكة المصدر للاتصالات الصادرة.
لزيادة عدد منافذ SNAT المتوفرة لكل جهاز ظاهري، بادر بتكوين القواعد الصادرة باستخدام التخصيص اليدوي للمنافذ على موازنة التحميل. على سبيل المثال، إذا كنت تعرف أن لديك 10 أجهزة ظاهرية كحد أقصى في تجمع الواجهة الخلفية، يمكنك تخصيص ما يصل إلى 6400 منفذ SNAT لكل جهاز ظاهري بدلا من 1024 افتراضيا. إذا كنت بحاجة إلى مزيد من منافذ SNAT، يمكنك إضافة عناوين IP متعددة للواجهة الأمامية للاتصالات الصادرة لمضاعفة عدد منافذ SNAT المتوفرة. تأكد من أنك تفهم سبب استنفاد منافذ SNAT قبل إضافة المزيد من عناوين IP للواجهة الأمامية.
للحصول على إرشادات مفصلة، راجع تصميم تطبيقاتك لاستخدام الاتصالات بكفاءة لاحقًا في هذه المقالة. لإضافة المزيد من عناوين IP للاتصالات الصادرة، بادر بإنشاء تكوين IP للواجهة الأمامية لكل عنوان IP جديد. عند تكوين القواعد الصادرة، يمكنك تحديد تكوينات IP متعددة للواجهة الأمامية لتجمع الواجهة الخلفية. يوصى باستخدام عناوين IP مختلفة للاتصال الوارد والصادر. تعزل عناوين IP المختلفة نسبة استخدام الشبكة لتحسين المراقبة واستكشاف الأخطاء وإصلاحها.
تكوين عنوان IP عام فردي على الجهاز الظاهري
بالنسبة لعمليات التوزيع على نطاق أصغر، يمكنك التفكير في تعيين عنوان IP عام إلى جهاز ظاهري. إذا تم تعيين عنوان IP عام إلى جهاز ظاهري، فستتوفر جميع المنافذ التي يوفرها عنوان IP العام للجهاز الظاهري. على عكس موازنة التحميل أو بوابة NAT، لا يمكن الوصول إلى المنافذ إلا من خلال الجهاز الظاهري الفردي المرتبط بعنوان IP.
نوصي بشدة بالنظر في استخدام بوابة NAT بدلاً من ذلك، لأن تعيين عناوين IP عامة فردية ليس حلاً قابلاً للتطوير.
ملاحظة
إذا كنت بحاجة إلى توصيل شبكة Azure الظاهرية بخدمات Azure PaaS مثل Azure Storage أو Azure SQL أو Azure Cosmos DB أو خدمات Azure الأخرى المتوفرة، يمكنك استخدام Azure Private Link لتجنب SNAT بالكامل. يرسل Azure Private Link نسبة استخدام الشبكة من شبكتك الافتراضية إلى خدمات Azure عبر شبكة Azure الأساسية بدلاً من الإنترنت.
Private Link هو الخيار الموصى به عبر نقاط تقديم الخدمة للوصول الخاص إلى خدمات Azure المستضافة. لمزيد من المعلومات حول الفرق بين Private Link ونقاط تقديم الخدمة، راجع مقارنة نقاط النهاية الخاصة ونقاط تقديم الخدمة.
تصميم تطبيقات فعالة في الاتصال
عند تصميم تطبيقاتك، تأكد من أنها تستخدم الاتصالات بكفاءة. يمكن أن تقلل كفاءة الاتصال من استنفاد منفذ SNAT أو تقضي عليه في التطبيقات الموزعة.
تعديل التطبيق لإعادة استخدام الاتصال
بدلاً من إنشاء اتصالات TCP فردية وذرية لكل طلب، نوصي بتكوين التطبيق الخاص بك لإعادة استخدام الاتصالات. ينتج عن إعادة استخدام الاتصال معاملات TCP أفضل من حيث الأداء وترتبط بشكل خاص ببروتوكولات مثل HTTP/1.1,، حيث تكون إعادة الاتصال هي الوضع الافتراضي. تنطبق إعادة الاستخدام هذه على البروتوكولات الأخرى التي تستخدم HTTP كوسيلة نقل مثل REST.
تعديل التطبيق لاستخدام تجمّع الاتصال
استخدم مخطط تجمّع اتصالات في تطبيقك، حيث تُوزع الطلبات داخليًا عبر مجموعة ثابتة من الاتصالات وإعادة استخدامها حيثما أمكن. يُقيد هذا المخطط عدد منافذ SNAT المُستخدمة ويخلق بيئة أكثر قابلية للتنبؤ.
يمكن لهذا المخطط زيادة إنتاجية الطلبات عن طريق السماح بعمليات متزامنة متعددة عند حظر اتصال واحد على الرد على عملية.
قد يكون تجمّع الاتصال موجودًا بالفعل ضمن الإطار الذي تستخدمه لتطوير التطبيق أو إعدادات تكوين تطبيقك. يمكنك دمج تجمّع الاتصال مع إعادة استخدام الاتصال. ثم تستهلك الطلبات المتعددة عددًا ثابتًا يمكن التنبؤ به من المنافذ إلى نفس عنوان IP الوجهة والمنفذ.
كما تستفيد الطلبات من الاستخدام الفعّال لمعاملات TCP، مما يقلل من زمن الانتقال واستخدام الموارد. يمكن أن تستفيد معاملات UDP أيضًا. يمكن أن تؤدي إدارة عدد تدفقات UDP إلى تجنب ظروف الاستنفاد وإدارة استخدام منفذ SNAT.
تعديل التطبيق لاستخدام منطق إعادة المحاولة أقل عدوانية
عندما يتم استنفاد منافذ SNAT أو يحدث فشل في التطبيق، تتم إعادة محاولة تطبيق الفرض القوي دون تدهور ويتسبب منطق التراجع في حدوث الاستنفاد أو استمراره. يمكنك تقليل الطلب على منافذ SNAT باستخدام منطق إعادة محاولة أقل عدوانية.
استنادًا إلى مهلة الخمول التي تم تكوينها، إذا كانت عمليات إعادة المحاولة عدوانية للغاية، فقد لا يكون لدى الاتصالات الوقت الكافي لإغلاق منافذ SNAT وتحريرها لإعادة استخدامها.
استخدام keepalives لإعادة تعيين مهلة الخمول الصادرة
تحتوي قواعد موازنة التحميل الصادرة على مهلة خمول لمدة 4 دقائق بشكل افتراضي وهي قابلة للتعديل حتى 100 دقيقة. يمكنك استخدام TCP النشطة في تحديث تدفق خامل وإعادة تعيين مهلة الخمول عند الضرورة. عند استخدام TCP النشطة، يكفي تمكينها على جانب واحد من الاتصال.
على سبيل المثال، يكفي تمكينها على جانب الخادم فقط لإعادة تعيين مؤقت الخمول للتدفق وليس من الضروري لكلا الجانبين لبدء TCP النشطة. توجد مفاهيم مماثلة لطبقة التطبيق، بما في ذلك تكوينات خادم العميل لقاعدة البيانات. تحقق من جانب الخادم بحثًا عن الخيارات الموجودة لـ keepalives الخاصة بالتطبيق.
الخطوات التالية
لمزيد من المعلومات حول استنفاد منفذ SNAT وخيارات الاتصال الصادرة والوصول الصادر الافتراضي، راجع: