مشاركة عبر

Troubleshooting network performance

نظرة عامة

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

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

مكونات الشبكة

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

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

على أعلى مستوى، هناك ثلاثة مجالات توجيه شبكة رئيسية:

  • شبكة Azure (السحابة الزرقاء)
  • الإنترنت أو WAN (السحابة الخضراء)
  • شبكة الشركة (سحابة برتقالية)

بالنظر إلى الرسم التخطيطي من اليمين إلى اليسار، دعنا نناقش كل مكون بإيجاز:

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

  • NIC - تأكد من معرفتك لعنوان IP الخاص الذي تم تعيينه إلى NIC المعني.

  • NIC NSG - قد تكون هناك مجموعات NSG محددة مطبقة على مستوى NIC. تأكد من أن مجموعة قواعد NSG مناسبة لنسبة استخدام الشبكة التي تحاول تجاوزها. على سبيل المثال، تأكد من أن المنافذ 5201 لـ iPerf أو 3389 لـ RDP أو 22 لـ SSH مفتوحة للسماح بمرور اختبار المرور.

  • الشبكة الفرعية للشبكة الظاهرية - يتم تعيين NIC إلى شبكة فرعية معينة. تأكد من معرفة أي واحدة والقواعد المقترنة بتلك الشبكة الفرعية.

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

  • Subnet UDR - المسارات المحددة من قِبل المستخدم يمكنها توجيه نسبة استخدام الشبكة إلى قفزة وسيطة (مثل جدار الحماية أو موازن التحميل). تأكّد من معرفة ما إذا كان هناك UDR في مكانه لنسبة استخدام الشبكة الخاصة بك. إذا كان الأمر كذلك، فقد فهمت إلى أين تذهب وماذا ستفعل الخطوة التالية لنسبة استخدام الشبكة الخاصة بك. على سبيل المثال، قد يجتاز جدار الحماية بعض نسبة استخدام الشبكة ويرفض حركة مرور أخرى بين نفس المضيفين.

  • Gateway subnet / NSG / UDR - تماماً مثل الشبكة الفرعية لجهاز VM، يمكن أن تحتوي الشبكة الفرعية للمدخل على مجموعات NSG وUDR. تأكد من أنك تعرف ما إذا كانوا هناك وما هي آثارهم على نسبة استخدام الشبكة الخاصة بك.

  • VNet Gateway (ExpressRoute) - بمجرد تمكين التناظر (ExpressRoute) أو VPN، لا توجد العديد من الإعدادات التي يمكن أن تؤثر على كيفية أو ما إذا كانت مسارات نسبة استخدام الشبكة. إذا كان لديك بوابة شبكة ظاهرية متصلة بدوائر ExpressRoute متعددة أو أنفاق VPN، يجب أن تكون على دراية بإعدادات وزن الاتصال. يؤثر وزن الاتصال على تفضيلات الاتصال ويحدد المسار الذي تسلكه نسبة استخدام الشبكة الخاصة بك.

  • Route Filter (غير معروض) - يعد عامل تصفية المسار ضرورياً عند استخدام Microsoft Peering عبر ExpressRoute. إذا كنت لا تتلقى أي مسارات، فتحقق مما إذا كان عامل تصفية المسار قد تم تكوينه وتطبيقه بشكل صحيح على الدائرة.

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

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

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

الأدوات

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

للمساعدة في استكشاف الأخطاء وإصلاحها، تم تطوير Azure Connectivity Toolkit (AzureCT) لوضع بعض هذه الأدوات في حزمة سهلة. لاختبار الأداء، يمكن لأدوات مثل iPerf وPSPing أن توفر لك معلومات حول شبكتك. iPerf هي أداة شائعة الاستخدام لاختبارات الأداء الأساسية وسهلة الاستخدام إلى حد ما. PSPing هي أداة ping تم تطويرها بواسطة SysInternals. يمكن أن يقوم PSPing بإجراء اختبار اتصال ICMP وTCP للوصول إلى مضيف بعيد. كل من هذه الأدوات خفيفة الوزن ويتم "تثبيتها" ببساطة عن طريق نسخ الملفات إلى دليل على المضيف.

يتم تغليف هذه الأدوات والأساليب في وحدة PowerShell (AzureCT) التي يمكنك تثبيتها واستخدامها.

AzureCT - مجموعة أدوات اتصال Azure

تتضمن الوحدة النمطية AzureCT PowerShell مكونين: اختبار التوفر واختبار الأداء. يركز هذا المستند على اختبار الأداء، وتحديدا الأمرين ربط الأداء في هذه الوحدة النمطية PowerShell.

فيما يلي الخطوات الأساسية الثلاث لاستخدام مجموعة الأدوات هذه لاختبار الأداء:

  1. تثبيت وحدة PowerShell النمطية

    (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression

    يقوم هذا الأمر بتنزيل وتثبيت وحدة PowerShell النمطية محليا.

  2. تثبيت التطبيقات الداعمة

    Install-LinkPerformance

    يقوم أمر AzureCT هذا بتثبيت iPerf وPSPing في دليل C:\ACTTools جديد وفتح منافذ جدار حماية Windows للسماح بحركة مرور ICMP والمنفذ 5201 (iPerf).

  3. تشغيل اختبار الأداء

    أولا، على المضيف البعيد، قم بتثبيت وتشغيل iPerf في وضع الخادم. تأكّد أيضاً من أن المضيف البعيد يستمع إلى 3389 (RDP لنظام التشغيل Windows) أو 22 (SSH لنظام التشغيل Linux) والسماح بنسبة استخدام الشبكة على المنفذ 5201 لـ iPerf. إذا كان المضيف البعيد هو Windows، فقم بتثبيت AzureCT وتشغيل الأمر Install-LinkPerformance لإعداد iPerf وقواعد جدار الحماية الضرورية.

    بمخزون أن تصبح الآلة البعيدة جاهزة، افتح PowerShell على الجهاز المحلي وابدأ الاختبار:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10

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

  4. مراجعة إخراج الاختبار

    يبدو تنسيق إخراج PowerShell مشابهاً لما يلي:

    لقطة شاشة لإخراج PowerShell لاختبار أداء الارتباط.

    يتم حفظ النتائج التفصيلية لجميع اختبارات iPerf وPSPing في ملفات نصية فردية في دليل أدوات AzureCT في C:\ACTTools.

استكشاف الأخطاء وإصلاحها

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

إشعار

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

  1. تحدي افتراضاتك

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

  2. البدء من حافة الشبكة

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

  3. إنشاء رسم تخطيطي

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

  4. القسمة والقهر

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

  5. ضع في اعتبارك جميع طبقات OSI

    في حين أن التركيز على الشبكة والطبقات من 1 إلى 3 (الطبقات المادية والبيانات والشبكة) شائع، تذكر أن المشاكل يمكن أن تحدث أيضا في الطبقة 7 (طبقة التطبيق). ضع عقلا منفتحا وتحقق من جميع الافتراضات.

استكشاف أخطاء ExpressRoute المتقدمة وإصلاحها

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

رسم تخطيطي لشبكات ظاهرية متعددة متصلة بدوائرة ExpressRoute.

إشعار

MSEE غير موجود في سحابة Azure. ExpressRoute على حافة شبكة Microsoft، وليس في الواقع في Azure. بمجرد الاتصال ب ExpressRoute ب MSEE، فأنت متصل بشبكة Microsoft، مما يسمح بالوصول إلى الخدمات السحابية مثل Microsoft 365 (مع Microsoft Peering) أو Azure (مع Private و/أو Microsoft Peering).

إذا كانت شبكتان ظاهريتان متصلتين بنفس دائرة ExpressRoute، يمكنك إجراء اختبارات لعزل المشكلة في Azure.

خطة اختبار

  1. قم بتشغيل اختبار Get-LinkPerformance بين VM1 وVM2. يوفر هذا الاختبار نظرة ثاقبة حول ما إذا كانت المشكلة محلية. إذا كان الاختبار ينتج عنه زمن انتقال مقبول ونتائج عرض النطاق الترددي، يمكنك وضع علامة على الشبكة الظاهرية المحلية على أنها جيدة.

  2. بافتراض أن نسبة استخدام الشبكة الظاهرية المحلية جيدة، قم بتشغيل اختبار Get-LinkPerformance بين VM1 وVM3. يقوم هذا الاختبار بتمرين الاتصال عبر شبكة Microsoft وصولاً إلى MSEE والعودة إلى Azure. إذا كان الاختبار ينتج عنه زمن انتقال مقبول ونتائج عرض النطاق الترددي، يمكنك وضع علامة على شبكة Azure على أنها جيدة.

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

هام

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

المشكلة معزولة، ماذا الآن؟

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

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

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

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

المراجع

الكمون/ توقعات النطاق الترددي

تلميح

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

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

إعداد الاختبار:

  • خادم فعلي يعمل بنظام Windows Server 2016 مع بطاقة NIC بسرعة 10 غيغابت في الثانية، متصلة بدائرة ExpressRoute.

  • دائرة ExpressRoute Premium بسرعة 10 جيجابت في الثانية مع تمكين التناظر الخاص.

  • شبكة Azure الظاهرية مع بوابة UltraPerformance في المنطقة المحددة.

  • جهاز ظاهري DS5v2 يعمل بنظام التشغيل Windows Server 2016 على الشبكة الظاهرية، باستخدام صورة Azure الافتراضية مع تثبيت AzureCT.

  • استخدمت جميع الاختبارات الأمر AzureCT Get-LinkPerformance مع اختبار تحميل مدته 5 دقائق لكل من عمليات تشغيل الاختبار الستة. على سبيل المثال:

    Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300

  • كان تدفق البيانات لكل اختبار من الخادم المحلي (عميل iPerf في سياتل) إلى Azure VM (خادم iPerf في منطقة Azure المدرجة).

  • يعرض العمود "زمن الانتقال" بيانات من اختبار بلا تحميل (اختبار زمن انتقال TCP دون تشغيل iPerf).

  • يعرض العمود "الحد الأقصى للنطاق الترددي" بيانات من اختبار تحميل تدفق TCP 16 بحجم نافذة 1 ميغابايت.

رسم تخطيطي لبيئة الاختبار التي تم تثبيت AzureCT فيها.

نتائج الكمون/ عرض النطاق الترددي

هام

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

موقع ExpressRoute منطقة Azure المسافة المقدرة (كم) زمن الانتقال عرض نطاق ترددي لجلسة عمل 1 الحد الأقصى للنطاق الترددي
سياتل West US 2 191 كم 5 مللي ثانية 262.0 ميغابت/ ثانية 3.74 غيغابت/ ثانية
سياتل غرب الولايات المتحدة 1,094 كم 18 مللي ثانية 82.3 ميغابت/ ثانية 3.70 غيغابت/ ثانية
سياتل Central US 2,357 كم 40 مللي ثانية 38.8 ميغابت/ ثانية 2.55 غيغابت/ ثانية
سياتل South Central US 2,877 كم 51 مللي ثانية 30.6 ميغابت/ ثانية 2.49 غيغابت/ ثانية
سياتل وسط شمال الولايات المتحدة 2,792 كم 55 مللي ثانية 27.7 ميغابت/ ثانية 2.19 غيغابت/ ثانية
سياتل East US 2 3,769 كم 73 مللي ثانية 21.3 ميغابت/ ثانية 1.79 غيغابت/ ثانية
سياتل شرق الولايات المتحدة 3,699 كم 74 مللي ثانية 21.1 ميغابت/ ثانية 1.78 غيغابت/ ثانية
سياتل شرق اليابان 7,705 كم 106 مللي ثانية 14.6 ميغابت/ ثانية 1.22 غيغابت/ ثانية
سياتل جنوب المملكة المتحدة 7,708 كم 146 مللي ثانية 10.6 ميغابت/ ثانية 896 ميغابت/ ثانية
سياتل أوروبا الغربية 7,834 كم 153 مللي ثانية 10.2 ميغابت/ ثانية 761 ميغابت/ ثانية
سياتل شرق أستراليا 12,484 كم 165 مللي ثانية 9.4 ميغابت/ ثانية 794 ميغابت/ ثانية
سياتل جنوب شرق آسيا 12,989 كم 170 مللي ثانية 9.2 ميغابت/ ثانية 756 ميغابت/ ثانية
سياتل جنوب البرازيل* 10,930 كم 189 مللي ثانية 8.2 ميغابت/ ثانية 699 ميغابت/ ثانية
سياتل جنوب الهند 12,918 كم 202 مللي ثانية 7.7 ميغابت/ ثانية 634 ميغابت/ ثانية

* زمن الانتقال إلى البرازيل هو مثال حيث تختلف مسافة تشغيل الألياف اختلافا كبيرا عن مسافة الخط المستقيم. سيكون زمن الانتقال المتوقع حوالي 160 مللي ثانية، ولكنه في الواقع 189 مللي ثانية بسبب مسار الألياف الأطول.

إشعار

تم اختبار هذه الأرقام باستخدام AzureCT استنادا إلى iPerf في Windows عبر PowerShell. لا يحترم iPerf خيارات Windows TCP الافتراضية لعامل التحجيم ويستخدم عدد Shift أقل لحجم نافذة TCP. من خلال ضبط أوامر iPerf مع -w المفتاح وحجم نافذة TCP أكبر، يمكن تحقيق معدل نقل أفضل. يمكن أن يساعد تشغيل iPerf في الوضع متعدد مؤشرات الترابط من أجهزة متعددة أيضا في الوصول إلى أقصى أداء للارتباط. للحصول على أفضل نتائج iPerf على Windows، استخدم "Set-NetTCPSetting -AutoTuningLevelLocal التجريبي". تحقق من النهج التنظيمية قبل إجراء أي تغييرات.

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

  • Last updated on