تحسين سرعة نقل الشبكة للأجهزة الظاهرية لـ Azure

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

مهم

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

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

أنظمة العملاء
أنظمة الخوادم

تطبيق هذه التكوينات على مجموعة فرعية فقط من الآلات الافتراضية يمكن أن يؤدي إلى:

معدل النقل غير المتسق
زيادة إعادة إرسال الحزم
سلوك الاحتراق غير الأمثل

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

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

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

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

تحقق مما إذا كان RSS مفعلا لمحول الشبكة باستخدام أمر Get-NetAdapterRss PowerShell. في المثال التالي، يظهر الناتج Get-NetAdapterRss أن RSS غير مفعل.
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False
```
لتمكين RSS، أدخل الأمر التالي:
```
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
```
هذا الأمر لا يصدر أي مخرجات. يغير إعدادات بطاقة واجهة الشبكة (NIC) ويسبب فقدانا مؤقتا للاتصال لمدة دقيقة تقريبا. يظهر مربع حوار إعادة الاتصال أثناء فقدان الاتصال. عادة ما يُستعاد الاتصال بعد المحاولة الثالثة.
تأكد من تمكين RSS في الجهاز الظاهري عن طريق إدخال الأمر Get-NetAdapterRss مرة أخرى. إذا نجح الأمر، فسيظهر إخراج المثال التالي:
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True
```

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

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

تمكين Azure Accelerated Networking لتحقيق الإنتاجية المثلى

يمكن ل Azure Accelerated Networking تحسين معدل النقل بشكل كبير وتقليل التأخير والتذبذب. اعتمادا على حجم الجهاز الافتراضي وتوليد المنصة، يستخدم Azure واحدة من تقنيتين: Mellanox، المتوفرة على نطاق واسع، وMANA التي طورتها Microsoft.

Azure tuned kernels

بعض التوزيعات، مثل أوبونتو (Canonical) وSUSE، توفر نوى مضبوطة على Azure.

استخدم الأمر التالي للتحقق من أنك تستخدم نواة Azure، والتي عادة ما تكون azure ضمن اسم النواة.

uname -r

# Sample output for an Azure kernel on an Ubuntu Linux VM
6.8.0-1017-azure

توزيعات Linux الأخرى

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

تحقيق سرعات نقل متسقة في أجهزة Linux الظاهرية في Azure

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

للحصول على معدل نقل أكثر اتساقا، طبق الضبط الأساسي التالي ثم اختبر تركيبات الازدحام/القرص السريع لتناسب عبء عملك.

ضبط النظام الأساسي (نسخ/لصق)

طبق إعدادات النظام الأساسية التالية:

sudo tee /etc/sysctl.d/99-azure-network-tuning.conf > /dev/null <<'EOF'
# Buffer and memory tuning
# Overall TCP memory pressure thresholds (min, pressure, max pages)
net.ipv4.tcp_mem = 4096 87380 67108864
# Overall UDP memory pressure thresholds (min, pressure, max pages)
net.ipv4.udp_mem = 4096 87380 33554432
# Per-socket TCP read buffer limits (min, default, max bytes)
net.ipv4.tcp_rmem = 4096 87380 67108864
# Per-socket TCP write buffer limits (min, default, max bytes)
net.ipv4.tcp_wmem = 4096 65536 67108864
# Default socket receive buffer size in bytes
net.core.rmem_default = 33554432
# Default socket send buffer size in bytes
net.core.wmem_default = 33554432
# Minimum UDP send buffer per socket in bytes
net.ipv4.udp_wmem_min = 16384
# Minimum UDP receive buffer per socket in bytes
net.ipv4.udp_rmem_min = 16384
# Maximum socket send buffer size in bytes
net.core.wmem_max = 134217728
# Maximum socket receive buffer size in bytes
net.core.rmem_max = 134217728
# Busy polling time in microseconds for low-latency packet receive
net.core.busy_poll = 50
# Busy read time in microseconds when polling sockets
net.core.busy_read = 50

# Extra TCP and networking settings
# Enable TCP timestamps for RTT measurement and PAWS protection
net.ipv4.tcp_timestamps = 1
# Allow safer TIME-WAIT socket reuse for outbound connections
net.ipv4.tcp_tw_reuse = 1
# Expand available ephemeral source port range
net.ipv4.ip_local_port_range = 1024 65535
# Increase packets processed per NAPI polling cycle
net.core.netdev_budget = 1000
# Increase per-socket ancillary/option memory limit in bytes
net.core.optmem_max = 65535
# Disable F-RTO (typically unnecessary on stable wired paths)
net.ipv4.tcp_frto = 0
# Increase maximum listen backlog for pending connections
net.core.somaxconn = 32768
# Increase ingress packet backlog queue length
net.core.netdev_max_backlog = 32768
# Increase per-CPU packet processing quota per softirq cycle
net.core.dev_weight = 64
EOF

sudo sysctl --system

التحكم في الازدحام واختبارات qdisc (sysctl)

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

BBR + FQ (غالبا ما يكون افتراضيا قويا للنقلات عالية الإنتاجية وطويلة المدى)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
```
BBR + PFIFO_FAST (مفيد لمقارنة سلوك الطابور تحت حركة المرور المتفجرة أو المختلطة)
```
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=pfifo_fast
```

CUBIC + PFIFO_FAST (خط الأساس القديم المشترك للتوافق والمقارنة)

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=pfifo_fast

قس كل خيار بحركة مرور ممثلة، ثم استخدم أفضل تركيبة أداء تناسب بيئتك.

‏‫ملاحظة‬

pfifo_fast يمكن أن يختلف التوفر حسب التوزيعة/النواة. إذا لم يكن متاحا، استخدم أقرب خيار QDIS مدعوم في بيئتك واستمر في الاختبار.

قاعدة UDEV لمخازن حلقة الشبكة (TX/RX)

أنشئ قاعدة udev لتطبيق /etc/udev/rules.d/99-azure-ring-buffer.rules إعدادات مخزن الحلقة على واجهات الشبكة:

الاستخدام rx 4096 tx 4096 لواجهات الشبكات المتسارعة (hv_pci) والاحتفاظ rx 1024 tx 1024 بها للواجهات الاصطناعية hv_netvsc .

إذا كنت تفضل النهج التفاعلي لضبط مخزن الحلقات، يمكنك أيضا استخدام هذه الأداة المساعدة: إعداد شبكة شبكة Azure Linux (bash).

‏‫ملاحظة‬

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

# Setup Accelerated Interface ring buffers (Mellanox / Mana) 
SUBSYSTEM=="net", DRIVERS=="hv_pci", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 4096 tx 4096"

# Setup Synthetic interface ring buffers (hv_netvsc)
SUBSYSTEM=="net", DRIVERS=="hv_netvsc*", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 1024 tx 1024"

قاعدة UDEV لطول قائمة الإرسال في بطاقة الشبكة

أنشئ القاعدة التالية لزيادة /etc/udev/rules.d/99-azure-txqueue-len.rules طول طابور الإرسال:

SUBSYSTEM=="net", ACTION=="add|change", KERNEL=="eth*", ATTR{tx_queue_len}="10000"

SR-IOV سلوك الواجهة المزدوجة والآثار الجانبية

في شبكات لينكس عالية الأداء، يستخدم Azure SR-IOV (على سبيل المثال، مع برامج تشغيل ميلانوكس مثل mlx4 أو mlx5). في هذا النموذج، يمكنك رؤية واجهة تركيبية وواجهة وظيفة افتراضية (VF) لنفس مسار شبكة الآلة الافتراضية. اعرف المزيد.

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

تشمل الآثار الجانبية المحتملة:

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

لتقليل المخاطر:

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

ملاحظات إضافية

يمكن لمسؤولي النظام تنفيذ هذه التوصيات عن طريق تحرير ملفات التكوين مثل /etc/sysctl.d/، /etc/modules-load.d/، و /etc/udev/rules.d/. راجع تحديثات النواة والتعريفات بعناية لتجنب الانحدارات.

لمزيد من المعلومات حول التكوينات المحددة وحل المشكلة، راجع توثيق Azure حول أداء الشبكات.

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

الملاحظات

هل كانت هذه الصفحة مفيدة؟

Last updated on 2026-06-20