منفذ واحد من X520-DA2 يعمل بسرعة 1 جيجابت/ثانية فقط في iperf3 بعد الانتقال من TrueNAS Core إلى SCALE 24.10
انتقل جهاز التخزين من Core 13.0-U6.7 إلى SCALE 24.04 ثم إلى 24.10، ومنذ ذلك الحين أصبح أحد المنفذين بطيئًا جدًا بينما توأمه على نفس البطاقة يعمل بشكل ممتاز. بطاقة 25G تتصرف بنفس الطريقة، وهو ما يجعلني أشك في ما أراه بعيني.
- بطاقة Intel X520-DA2 مع وصلات ضوئية Intel SFP+ متعددة الأنماط، 10G إلى المفتاح
- بطاقة Intel XXV710-DA2 مع وصلات ضوئية Intel SFP28، 25G إلى نفس المفتاح
- TrueNAS SCALE 24.10 على جهاز NAS (كان Core 13.0-U6.7، ثم 24.04)
- iperf3 بين NAS وعميل كمقياس
حالة الرابط على المنفذ البطيء تبدو بالضبط كما ينبغي:
$ ethtool enp1s0f0 | grep -E 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes
$ iperf3 -c 192.168.3.2
# parks itself around 1 Gbit/s for the whole run
# the second port of the same card does line rate against its own clientما تم فعله بالفعل:
- تبديل الوصلات الضوئية بين منفذي البطاقة؛ المنفذ البطيء بقي بطيئًا، والسريع بقي سريعًا
- مقارنة sysctl net.ipv4.tcp_congestion_control على الطرفين، نفس القيمة
- إعادة تركيب الطرفين وتنظيف الفيرول
كل ما يمكن قياسه على طبقة الرابط يقول 10G و25G full duplex، بينما لا تزال البيانات الفعلية عالقة عند حوالي جيجابت واحد تقريبًا. هل الوحدات تتدهور، أم أن بطاقة الشبكة في طريقها للتلف، أم أنني أنظر إلى الطبقة الخاطئة؟
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
لقد استبعدت الوصلات الضوئية بنفسك بالفعل: قمت بتبديلها بين المنفذين وبقي البطء مرتبطًا بالمنفذ. لذا اترك الوحدات جانبًا وافصل حقائق طبقة الرابط عن أرقام الإنتاجية، لأنها تجيب عن أسئلة مختلفة.
هناك أمران يختلفان عادةً بين منفذ سريع وآخر بطيء على نفس البطاقة. انظر إليهما معًا:
إذا كان أحدهما على MTU بقيمة 1500 والآخر على 9014، وكانا في شبكتي VLAN مختلفتين، فإن اختبارك البطيء لا يخرج من بطاقة الشبكة ويعود إليها، بل يمر عبر مسار التوجيه في المضيف. ضع عميلاً في نفس شبكة VLAN والشبكة الفرعية للمنفذ البطيء وشغّل iperf3 -c ضده. لا موجّه في المسار، لا عدم تطابق في MTU، لا شيء للنقاش حوله.
إذا أعطاك اختبار الشبكة الواحدة معدل الخط الكامل، فإن المنفذ والوصلة الضوئية سليمان وما قسته فعليًا هو أداء التوجيه بين شبكات VLAN على المضيف، وهي النقطة التي ينتهي إليها عدد لا بأس به من عمليات الانتقال من Core إلى SCALE: التوجيه بين شبكات VLAN أسوأ بشكل ملحوظ مما كان عليه تحت Core.
هذا تشخيص وليس علاجًا حقيقيًا. تستعيد معظم الأداء بإبقاء التدفقات الثقيلة داخل شبكة VLAN واحدة، أو بتسليم التوجيه إلى المفتاح بدلاً من NAS. على الأقل هذا يمنعك من إرجاع وحدتي SFP+ سليمتين تمامًا.
قبل أن يبدأ أحد بسحب الوصلات الضوئية: ماذا يقول المفتاح عن هذين المنفذين؟ السرعة المتفاوض عليها، الازدواجية، وعدادات الأخطاء على كليهما. وأي طرف يشغّل خادم iperf3 في الاختبار البطيء - هل يبقى السقف كما هو عندما تعكس الاتجاه وتدفع من الطرف الآخر؟
ثم انشر MTU وشبكة VLAN للمنفذ البطيء والسريع جنبًا إلى جنب. منفذ يتفاوض على 10G وينقل جيجابت واحد فقط من البيانات هو في كل الحالات تقريبًا مشكلة توجيه أو مسار، وليست مشكلة ضوئية. إذا لم يكن المنفذان في نفس شبكة VLAN، فإن iperf3 يقيّم موجّهك، وليس رابطك.
عتاد مختلف، نفس الشكل. جهازان متصلان مباشرة على بطاقات X520-DA عبر كابل DAC من نوع SFP+، Hyper-V Server Core 2012 R2 على جانب وجهاز تخزين NAS4Free 9.1 على الجانب الآخر. بشكل مباشر، حقق هذا الزوج 8-9 جيجابت في الثانية قراءةً وكتابةً. بمجرد ربط المنفذ بمحوّل Hyper-V الافتراضي، انخفض إلى شيء يشبه 500 ميجابت في الثانية، وإعادة الاختبار على البطاقات تحت Windows Server 2012 R2 وWindows 8.1 لم يغيّر شيئًا على الإطلاق.
لم يُثبت الأمر أبدًا. الرد الوحيد الذي حصلت عليه سأل عن الأقراص ومستوى RAID خلف كل طرف، وهو سؤال منصف، لأن التخزين قد يكون السقف قبل أن يصل مسار 10G إلى حده بوقت طويل. العادة التي اكتسبتها من هذا: قِس نفس الرابط مع إضافة الطبقة الإضافية وبدونها، وقارن مع قرص RAM إن أمكن ترتيب ذلك. الكابل والبطاقات لم يكونا المشكلة هناك أيضًا.