Troubleshooting network performance

نظرة عامة

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

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

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

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

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

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

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

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

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

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

• الشبكة الفرعية VNet - تم تعيين NIC لشبكة فرعية معينة، وتأكد من معرفة أيها، والقواعد المرتبطة بهذه الشبكة الفرعية.

• الشبكة الفرعية NSG - تماماً مثل NIC، يمكن تطبيق مجموعات NSG على الشبكة الفرعية أيضاً. تأكد من أن مجموعة قواعد 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 على مكونين Availability Testing وPerformance Testing. هذا المستند معني فقط باختبار الأداء، لذلك دعنا نركز على أمري Link Performance في وحدة 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 وقواعد جدار الحماية اللازمة لبدء iPerf في وضع الخادم بنجاح.

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

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

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

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

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

   

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

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

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

إشعار

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

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

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

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

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

أيضاً، لا تنس إلقاء نظرة على الطبقات الأخرى لنموذج OSI. من السهل التركيز على الشبكة والطبقات من 1 إلى 3 (الطبقات المادية والبيانات والشبكة) ولكن يمكن أيضاً أن تظهر المشكلات في الطبقة 7 في طبقة التطبيق. حافظ على عقل متفتح وتحقق من الافتراضات.

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

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

إشعار

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

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

خطة اختبار

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

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

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

هام

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

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

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

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

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

باستخدام Azure، بمجرد عزل المشكلة بأكبر قدر ممكن من التفاصيل، فقد حان الوقت لمراجعة Azure Network Documentation ثم إذا لزم الأمر، open a support ticket.

المراجع

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

تلميح

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

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

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

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

• دائرة 10Gbps Premium ExpressRoute في الموقع المحدد مع تمكين التناظر الخاص.

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

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

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

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

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

• بيانات عمود "Latency" مأخوذة من اختبار No Load (اختبار زمن انتقال TCP دون تشغيل iPerf).

• بيانات العمود "Max Bandwidth" مأخوذة من اختبار تحميل تدفق TCP 16 بحجم نافذة 1 ميجا بايت.

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

هام

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

ExpressRoute الموقع	Azure المنطقة	مقدر المسافة (كم)	زمن الانتقال	جلسة واحدة النطاق الترددي	الحد الأقصى النطاق الترددي
سياتل	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 مللي ثانية. يبدو أن الاختلاف في زمن الوصول يشير إلى وجود مشكلة في الشبكة في مكان ما. لكن الحقيقة هي أن خط الألياف لا يذهب إلى البرازيل في خط مستقيم. لذلك يجب أن تتوقع 1000 كم إضافي أو نحو ذلك من السفر للوصول إلى البرازيل من سياتل.

إشعار

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

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

• تنزيل مجموعة أدوات اتصال Azure
• اتبع الإرشادات لاختبار أداء الرابط