PDF(304.5 KB) عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
ePub(94.4 KB) العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
Mobi (Kindle)(97.7 KB) عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:٦ أغسطس ٢٠٢٥
معرّف المستند:224027
لغة خالية من التحيز
تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
حول هذه الترجمة
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يوضح هذا المستند كيفية أستكشاف أخطاء الأداء وإصلاحها في موجهات المؤسسات طراز C8000v عبر السحب العامة وسيناريوهات ESXi.
المكونات المستخدمة
أسست المعلومة في هذا وثيقة على هذا جهاز وبرمجية مكون:
C8000v يشغل الإصدار 17.12
ESXi الإصدار 7.0 U3
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
أستكشاف الأخطاء وإصلاحها بشكل عام
على الرغم من إمكانية إستضافة الطابعة طراز C8000v الخاصة بك في بيئات مختلفة، فلا يزال هناك بعض خطوات أستكشاف الأخطاء وإصلاحها التي يمكنك تنفيذها، وهي خطوات متطابقة بغض النظر عن مكان إستضافة الطابعة طراز C8000v. فلنبدأ بالأساسيات. أول شيء يجب عليك التأكد منه هو وصول الجهاز إلى حدود قدرته الاستيعابية أم لا. لذلك يمكنك أن تبدأ بالتحقق من هذين المخرجين:
1. show platform hardware qfp active dataPath util summary - يوفر لك هذا الأمر المعلومات الكاملة الخاصة بالإدخال/الإخراج التي يتلقاها C8000v وينقلها من كل منفذ. يجب أن تركز انتباهك على النسبة المئوية لحمل المعالجة. إذا كنت في سيناريو تصل فيه إلى 100٪ فهذا يعني أنك تصل إلى حد القدرة
------------------ show platform hardware qfp active datapath utilization summary ------------------
CPP 0: 5 secs 1 min 5 min 60 min
Input: Total (pps) 93119 92938 65941 65131
(bps) 997875976 1000204000 708234904 699462016
Output: Total (pps) 93119 92949 65944 65131
(bps) 1052264704 1054733128 746744264 737395744
Processing: Load (pct) 14 14 10 10
2. show platform hardware qfp active dataPath infrastructure sw-cio - فكر في هذا الأمر كإصدار أكثر تعمقا من الأمر أعلاه. يوفر تفاصيل أفضل حول النوى الفردية بما في ذلك مراكز الإدخال/الإخراج والتشفير التي لا تشكل جزءا من رقم إستخدام QFP. وهو مفيد جدا في سيناريو حيث تريد أن ترى ما إذا كان نواة مستوى بيانات معين تتسبب في حدوث إزدحام.
تلميح: تفصيل مهم جدا عند إستخدام هذا الأمر، قم بتشغيله دائما مرتين. وهو يقوم بحساب النسبة المئوية لاستخدام المركز بين وقت تنفيذ الأمر.
الآن، لقد قررت ما إذا كنت تصل إلى حد منصة العمل أم لا. وتتلخص الخطوة التالية في التحقق من حالات السقوط. وترتبط هذه المشاكل بطبيعتها بمشاكل تتعلق بالأداء. هناك ثلاثة أنواع من حالات السقوط التي يمكنك أخذها بعين الإعتبار وفقا لمكان حدوثها.
التجاوز: يقع هذا النوع من إسقاط الحزمة على نهاية Rx. يحدث ذلك بسبب تجاوز سعة معالجة مركز واحد أو أكثر.
حالات إسقاط الميزات: يحدث هذا النوع من إسقاط الحزم في PPE. تتعلق بالميزات في الموجه مثل قائمة التحكم في الوصول (ACL) أو جودة الخدمة.
قطرات ذيلة: يقع هذا النوع من إسقاط الحزمة في نهاية Tx. تحدث بسبب الازدحام في مخازن TX المؤقتة.
لتحديد أي حالات السقوط التي تواجهها، يمكنك إستخدام المخرجات التالية:
إظهار حالة الإسقاط النشط ل QFP لأجهزة النظام الأساسي
show interface
إظهار واجهة خريطة السياسة
يمكنك التحقق من كيفية تحديد أي حالات السقوط التي تواجهها وكيفية التخفيف من حدتها. وعلى الرغم من ذلك، سيكون التركيز الأكبر في هذه المقالة على حالات السقوط المعروفة باسم "نقاط الذيل"، حيث إنها خاصة مخادعة لاستكشاف الأخطاء وإصلاحها في الموجهات الافتراضية.
تجاوز
يحدث إسقاط تجاوز في Cisco IOS XE عندما تتلقى واجهة الشبكة الحزم بشكل أسرع من قدرتها على معالجتها أو تخزينها في المخزن المؤقت الخاص بها. وعلى وجه التحديد، تصبح المخازن المؤقتة الداخلية للواجهات (قائمة انتظار FIFO) ممتلئة لأن معدل البيانات الواردة يتجاوز قدرة الأجهزة على معالجتها. ونتيجة لذلك، لا يمكن تخزين الحزم الواردة الجديدة وإسقاطها، مما يزيد من عداد التجاوز. هذا في الأساس فقدان حزمة بسبب الضغط المؤقت على الواجهة.
يقع هذا النوع من عمليات إسقاط الحزم على نهاية Rx. يحدث ذلك بسبب تجاوز سعة معالجة واحدة أو أكثر من مراكز المعالجات، وتعذر على مؤشر ترابط Rx توزيع الحزم الواردة إلى مؤشر ترابط PP ذي الصلة ومخازن الدخول المؤقتة ممتلئة بالفعل. ولإجراء قياس بسيط، يمكنك التفكير فيه كقائمة انتظار في عداد سحب تمتلئ جدا لأن الحزم تصل بشكل أسرع من قيام أمين الصندوق (أجهزة الواجهة) بخدمتها. عندما تكون قائمة الانتظار ممتلئة، يتوجب على العملاء الجدد المغادرة دون الحاجة إلى الخدمة - فهذه هي حالات السقوط الزائد.
على الرغم من ذكر المكونات المادية في هذا القسم، إلا أن C8000v عبارة عن موجه قائم على البرامج. في هذه الحالة، يمكن أن يحدث التجاوز بسبب:
إستخدام مستوى البيانات المرتفع: إذا كان إستخدام مستوى البيانات مرتفعا، فلا يمكن إستعراض الحزم بسرعة كافية، مما يؤدي إلى تجاوزات. على سبيل المثال، من الممكن أن يؤدي وجود "تدفقات الفيلة" (تدفقات البيانات الكبيرة والمستمرة) إلى تشبع موارد المعالجة والتسبب في التجاوزات على الواجهات.
قالب جهاز غير صحيح: يمكن أن يؤدي إستخدام قالب جهاز غير مناسب إلى إدارة المخزن المؤقت وتجاوزه بشكل غير فعال. يمكن التحقق من هذا الأمر باستخدام الأمر show platform software co alloc ويمكن تغييره باستخدام الأمر platform resource <template>.
يتم تعيين تجمع محدود من الاعتمادات لكل واجهة، وتمنع هذه الآلية الواجهة المشغولة وتحميل موارد النظام بشكل زائد. في كل مرة تصل فيها حزمة جديدة إلى مستوى البيانات، يلزم توفر رصيد. عندما تتم معالجة الحزم، يتم إرجاع الرصيد حتى يمكن لمؤشر ترابط Rx إستخدامه مرة أخرى. في حالة عدم توفر رصيد للواجهة، تحتاج الحزمة إلى الانتظار في حلقة Rx الخاصة بالواجهة. بشكل عام، تتوقع أن تكون حالات السقوط المتعلقة بالحد الأقصى للأداء تجاوز Rx بسبب تجاوز سعة معالجة مركز واحد أو أكثر.
لتحديد التجاوزات، عادة ما تقوم بالتحقق من إحصائيات الواجهة بحثا عن أخطاء الإدخال، وتحديدا عداد التجاوز:
أستخدم الأمر show platform hardware qfp active dataPath infrastructure sw-cio لتحديد الاستخدام الأساسي، وإذا تم تجاوز عدد الاعتمادات الخاصة بواجهة معينة.
أستخدم الأمر show interface <interface-name>وابحث عن عدد التجاوز في الإخراج.
يتم عرض التجاوز كجزء من أخطاء الإدخال، على سبيل المثال:
Gig2 is up, line protocol is up 241302424557 packets input, 168997587698686 bytes, 0 no buffer 20150 input errors, 0 CRC, 0 frame, 20150 overrun, 0 ignored <<<<<<<<<<<
لنفترض حالة حيث يقوم Gig2 بمراقبة مشاكل الأداء الناتجة عن التجاوزات. لتحديد مؤشر ترابط العامل المقترن بهذه الواجهة، يمكنك إستخدام الأمر التالي:
#show platform hardware qfp active datapath infra binding Port Instance Bindings:
ID Port IOS Port WRKR 2 1 rcl0 rcl0 Rx+Tx 2 ipc ipc Rx+Tx 3 vxe_punti vxe_puntif Rx+Tx 4 Gi1 GigabitEthernet1 Rx+Tx 5 Gi2 GigabitEthernet2 Rx+Tx <<< in this case, WRKR2 is the thread responsible for both Rx and Tx
بعد ذلك، أنت يستطيع حللت الإستعمالمن خاص مؤشر الترابط مسؤول عن حركة مرور Rx من هذا قارن وعدد من يخصها.
في سيناريو حيث يراقب Gig2 مشاكل الأداء بسبب التجاوزات، يمكنك أن تتوقع إستخدام PP#2 بشكل كامل باستمرار (خامل = 0٪)، واعتماد منخفض/صفر للواجهة Gig2:
#show platform hardware qfp active datapath infrastructure sw-cio Credits Usage:
Core Utilization over preceding 1.0047 seconds ---------------------------------------------- ID: 0 1 2 % PP: 0.77 0.00 0.00 % RX: 0.00 0.00 0.44 % TM: 0.00 0.00 5.63 % IDLE: 99.23 99.72 93.93 <<< the core ID relevant in this case would be PP#2
عمليات إسقاط الميزات
تتم معالجة الحزم بواسطة أي مؤشر ترابط مستوى بيانات متوفر ويتم توزيعها بشكل صارم استنادا إلى توفر مراكز QFP عبر البرنامج Rx Function (x86) - التوزيع المستند إلى الحمل (LBD). يمكن إسقاط الحزم التي تصل إلى أدوات الحماية الشخصية (PPE) باستخدام سبب إسقاط QFP محدد، والذي يمكن فحصه باستخدام هذا الإخراج:
#show drops
------------------ show platform hardware qfp active statistics drop detail ------------------
Last clearing of QFP drops statistics : never
--------------------------------------------------------------------------------
ID Global Drop Stats Packets Octets
--------------------------------------------------------------------------------
319 BFDoffload 403 31434
139 Disabled 105 7487
61 Icmp 135 5994
94 Ipv4NoAdj 1 193
33 Ipv6NoRoute 2426 135856
215 UnconfiguredIpv4Fia 1937573 353562196
216 UnconfiguredIpv6Fia 8046173 1057866418
------------------ show platform hardware qfp active interface all statistics drop_summary ------------------
----------------------------------------------------------------
Drop Stats Summary:
note: 1) these drop stats are only updated when PAL
reads the interface stats.
2) the interface stats include the subinterface
Interface Rx Pkts Tx Pkts
---------------------------------------------------------------------------
GigabitEthernet1 9980371 0
GigabitEthernet2 4012 0
وأسباب هذا الانخفاض متنوعة وعادة ما تكون ذاتية التفسير. وللمزيد من التحقيق، يمكن إستخدام تتبع الحزمة.
قطرات ذيلية
كما تمت الإشارة إليه سابقا، تحدث عمليات إسقاط الذيل حيث يحاول الجهاز إرسال الحزم، ولكن مخازن الإرسال المؤقتة ممتلئة.
في هذا القسم الفرعي ستنظر في المخرجات التي يمكنك فحصها عند مواجهة هذا النوع من المواقف. ما هي القيم التي يمكنك أن ترى فيها وتعني وما يمكنك القيام به لتخفيف المشكلة.
اولا، يلزم ان تعرفوا كيف تحددون هويتهم. إحدى هذه الطرائق هي مجرد النظر إلى واجهة العرض. تأكد من زيادة أي حالات انخفاض للمخرجات:
GigabitEthernet2 is up, line protocol is up Hardware is vNIC, address is 0050.56ad.c777 (bia 0050.56ad.c777) Description: Connected-To-ASR Cloud Gateway Internet address is 10.6.255.81/29 MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 2/255, rxload 3/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full Duplex, 10000Mbps, link type is force-up, media type is Virtual output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 03:16:21 Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 7982350 <<<<<<<< Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 150449000 bits/sec, 20461 packets/sec 5 minute output rate 89116000 bits/sec, 18976 packets/sec
هذا أمر مفيد خاصة أن يفهم إن أنت تواجه إزدحام أو لا:
show platform hardware qfp active dataPath infrastructure - HQF يمثل "Hierarchical Queueing Framework". هذه ميزة تتيح إدارة جودة الخدمة (QoS) على مستويات مختلفة (مادية ومنطقية وفئة) باستخدام واجهة سطر أوامر جودة الخدمة (MQC) النمطية. وهو يوضح تكاليف RX و TX الحالية. عندما تكون قائمة انتظار TX ممتلئة، كما تظهر المخرجات (كاملة 1959)
يقترح الإخراج أن الجهاز الأساسي لا يتماشى مع إرسال الحزم. لتصحيح أخطاء الواجهة الأساسية، يلزمك النظر من المحتمل خارج C8000v وفي البيئة الأساسية حيث يتم تشغيل C8000v لمعرفة ما إذا كان هناك أي أخطاء إضافية تم الإبلاغ عنها على الواجهات المادية الأساسية.
للتحقق من البيئة، هناك خطوة واحدة يمكنك القيام بها قبل التحقق من الموجه C8000v الذي يعمل ببرنامج hypervisor. هذا أن فحصت الأمر عرض جهاز تحكم إنتاج. ومع ذلك، يمكن ان تجدوا نفسكم ضائعين في ما يعنيه كل عداد أو إلى اين تنظرون.
أولا، هناك تفصيل مهم يجب أن تتذكره عند النظر إلى هذا الإخراج وهو أن المعلومات يتم الحصول عليها غالبا من بطاقات واجهة الشبكة (NICs) نفسها. يحتوي كل برنامج تشغيل لبطاقة واجهة الشبكة (NIC) على مجموعة معينة من العدادات التي يستخدمها، والتي يمكن أن تختلف حسب برنامج التشغيل، بشكل طبيعي. ويؤثر مختلف برامج مراقبة الأجهزة الافتراضية بشكل ما على ما هو معروض أيضا. بعض العدادات، مثل عدادات mbuf، هي حالات من برنامج تشغيل DPDK. يمكن أن يختلف ذلك مع برامج تشغيل DPDK المختلفة. يتم إجراء الجرد الفعلي بشكل عام بواسطة برنامج مراقبة الأجهزة الافتراضية في طبقة المحاكاة الافتراضية.
خذ دقيقة هنا لتعلم كيفية تفسير وقراءة هذه العدادات:
إذا رأيت subx، هو يعني هو قارن فرعي - تقسيم منطقي من القارن رئيسي. يمثل الرقم الفرعي0 بشكل عام الرقم الأساسي/الافتراضي. غالبا ما يتم إستخدام هذه العناصر عندما تكون شبكات VLAN متعددة مشتركة.
ثم، لديك "Rx = تلقي" و "tx = إرسال".
أخيرا، يشير q0 إلى قائمة الانتظار الأولى/الافتراضية المستخدمة من قبل تلك الواجهة
على الرغم من عدم وجود وصف لكل عداد، إلا أن المقالة تصف بعض هذه التفاصيل، والتي قد تكون ذات صلة بعملية أستكشاف المشكلات وحلها لديك:
يظهر "RX_MISSED_ERRORS:" عندما يصبح المخزن المؤقت لبطاقة واجهة الشبكة (Rx FIFO) ممتلئا بشكل زائد. ويؤدي هذا الوضع إلى انخفاض وزيادة في زمن الانتقال. هناك حل محتمل لهذه المشكلة وهو زيادة سعة NIC المؤقتة (وهو أمر مستحيل في حالتنا) أو تغيير برنامج تشغيل NIC.
"tx_q0_drop_total" و"tx_q0_tx_ring_full": ويمكن أن يوضح لك ذلك أن المضيف يقوم بإسقاط الحزم، كما يواجه C8000v حالات سقوط الذيل في C8000v لأن المضيف يضغط على C8000v للخلف
في الإخراج أعلاه، لا نرى أي "rx_missed_errors". ومع ذلك، فإنه أثناء تركيزنا على عمليات الإسقاط التي نراها بالفعل كل من "tx_q0_drop_total" و"tx_q0_tx_ring_full". وبهذا يمكننا أن نستنتج أن هناك بالفعل إزدحاما بسبب الأجهزة الأساسية للمضيف.
وكما ذكرنا سابقا، فإن كل مراقب أجهزة افتراضية له تأثير ما على ما هو معروض. تركز المقالة على هذا الأمر في القسم التالي عند تجاوز الاختلافات بين برامج مراقبة الأجهزة الافتراضية المختلفة التي يمكن فيها إستضافة الطراز C8000v. يمكنك أيضا العثور على التوصيات المختلفة لمحاولة تخفيف هذا النوع من المشاكل في كل واحدة منها.
برامج مراقبة الأجهزة الافتراضية
برنامج hypervisor هو طبقة برامج تسمح لأنظمة تشغيل متعددة (تسمى الأجهزة الافتراضية أو الأجهزة الافتراضية) بالعمل على مضيف أجهزة فعلي واحد من خلال إدارة موارد الأجهزة مثل وحدة المعالجة المركزية (CPU) والذاكرة والتخزين لكل جهاز افتراضي (VM) وتخصيصها. فهي تضمن عمل هذه الأجهزة الافتراضية بشكل مستقل دون التعارض مع بعضها البعض.
في سياق Cisco Catalyst 8000V (C8000v)، يكون برنامج hypervisor هو النظام الأساسي الذي يستضيف الجهاز الظاهري C8000v. كيف يمكنك العثور على أي برنامج Hypervisor يستضيف جهاز C8000v لديك؟ هناك مخرجات مفيدة إلى حد ما تعطينا تلك المعلومات. بالإضافة إلى ذلك، يمكنك أيضا التحقق من نوع الموارد التي يمكن للموجه الظاهري الوصول إليها:
C8000v#show platform software system all Processor Details ================= Number of Processors : 8 Processor : 1 - 8 vendor_id : GenuineIntel cpu MHz : 2593.906 cache size : 36608 KB Crypto Supported : Yes model name : Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
VNIC Details ============ Name Mac Address Driver Name Status Platform MTU GigabitEthernet1 0022.480d.7a05 net_netvsc UP 1500 GigabitEthernet2 6045.bd69.83a0 net_netvsc UP 1500 GigabitEthernet3 6045.bd69.8042 net_netvsc UP 1500
Hypervisor Details =================== Hypervisor: AZURE Manufacturer: Microsoft Corporation Product Name: Virtual Machine Serial Number: 0000-0002-0201-5310-5478-4052-71 UUID: 8b06091c-f1d3-974c-85a5-a78dfb551bf2 Image Variant: None
VMWare ESXi
ESXi هو برنامج مراقبة أجهزة افتراضية من النوع 1 تم تطويره بواسطة VMware وتم تثبيته مباشرة على الخوادم المادية لتمكين المحاكاة الافتراضية. وهو يسمح بتشغيل العديد من الأجهزة الافتراضية (VM) على خادم مادي واحد من خلال إستخلاص موارد الأجهزة وتخصيصها لكل جهاز افتراضي. الموجه C8000v هو واحد من تلك الأجهزة الافتراضية.
يمكنك البدء من خلال الانتقال إلى سيناريو شائع حيث يحدث الازدحام. يمكن تأكيد هذا الإجراء من خلال التحقق من عداد tx_q0_tx_ring_full:
مثال:
------------------ show platform software vnic-if interface-mapping ------------------
------------------------------------------------------------- Interface Name Driver Name Mac Addr ------------------------------------------------------------- GigabitEthernet3 net_vmxnet3 <-- 0050.5606.2239 GigabitEthernet2 net_vmxnet3 0050.5606.2238 GigabitEthernet1 net_vmxnet3 0050.5606.2237 -------------------------------------------------------------
يحدث هذا الازدحام عندما يحاول C8000V إرسال الحزم من خلال واجهة VMXNET3. ومع ذلك، فإن حلقة المخزن المؤقت ممتلئة بالفعل بالحزم، التي ينتهي بها الأمر في حالات تأخير أو إسقاط.
في ظل هذه الظروف، تحدث هذه الانخفاضات على جانب برنامج hypervisor كما ذكرنا سابقا. إذا تم الوفاء بجميع التوصيات، فيوصى بالرجوع إلى دعم VMware لفهم ما يحدث على بطاقة واجهة الشبكة (NIC).
إليك بعض الاقتراحات حول كيفية تحسين الأداء:
أستخدم محول vSwitch مخصص ووصلة للحصول على الأداء الأمثل
من خلال تخصيص الطراز C8000V لمحول vSwitch مخصص مدعوم بارتباطاته المادية الخاصة، يمكننا عزل حركة مرور البيانات الخاصة به عن الدول المجاورة الصاخبة وتجنب المشكلات المشتركة في الموارد.
هناك عدد قليل من الأوامر التي تستحق النظر إليها من جانب ESXi. على سبيل المثال، للتحقق من فقد الحزم من واجهة ESXi، يمكننا القيام بما يلي:
قم بتمكين SSH.
الاتصال ب ESXi باستخدام SSH.
قم بتشغيل esxtop.
اكتب n.
يمكن أن يعرض الأمر esxtop الحزم التي تم إسقاطها في المحول الظاهري إذا نفد برنامج تشغيل شبكة الجهاز الظاهري من ذاكرة Rx المؤقتة. وعلى الرغم من أن esxtop يعرض الحزم كما تم إسقاطها على المحول الظاهري، إلا أنها في الواقع يتم إسقاطها بين المحول الظاهري وبرنامج تشغيل نظام التشغيل الضيف.
البحث عن أي حزم يتم إسقاطها ضمن ٪DRPTX و٪DRPRX:
12:34:43pm up 73 days 16:05, 907 worlds, 9 VMs, 53 vCPUs; CPU load average: 0.42, 0.42, 0.42
esxcli network nic list Name PCI Device Driver Admin Status Link Status Speed Duplex MAC Address MTU Description ------ ------------ ------ ------------ ----------- ----- ------ ----------------- ---- ----------- vmnic0 0000:01:00.0 igbn Up Up 1000 Full fc:99:47:49:c5:0a 1500 Intel(R) I350 Gigabit Network Connection vmnic1 0000:01:00.1 igbn Up Up 1000 Full fc:99:47:49:c5:0b 1500 Intel(R) I350 Gigabit Network Connection vmnic2 0000:03:00.0 ixgben Up Up 1000 Full a0:36:9f:1c:1f:cc 1500 Intel(R) Ethernet Controller 10 Gigabit X540-AT2 vmnic3 0000:03:00.1 ixgben Up Up 1000 Full a0:36:9f:1c:1f:ce 1500 Intel(R) Ethernet Controller 10 Gigabit X540-AT2
هناك أيضا أمر مفيد أن يفحص حالة ال vNIC يعين إلى VM خاص.
بالنظر إلى C8kv-gw-mgmt، وهو C8000v VM، هناك شبكتين مخصصتين:
c8kv-to-9200l
c8kv-to-cisco
يمكنك إستخدام معرف العالم للبحث عن مزيد من المعلومات حول معرف فئة المورد (VM) هذا:
[root@localhost:~] esxcli network vm port list -w 2101719 Port ID: 67108890 vSwitch: vSwitch-to-9200L Portgroup: c8kv-to-9200l DVPort ID: MAC Address: 00:0c:29:31:a6:b6 IP Address: 0.0.0.0 Team Uplink: vmnic1 Uplink Port ID: 2214592519 Active Filters:
Port ID: 100663323 vSwitch: vSwitch-to-Cisco Portgroup: c8kv-to-cisco DVPort ID: MAC Address: 00:0c:29:31:a6:ac IP Address: 0.0.0.0 Team Uplink: vmnic0 <---- Uplink Port ID: 2248146954 Active Filters: [root@localhost:~]
بمجرد حصولك على هذه المعلومات، يمكنك التعرف على الشبكة التي تم تعيين vSwitch لها.
للتحقق من بعض إحصائيات حركة المرور الخاصة ببطاقة واجهة الشبكة (NIC) المادية التي تم تعيينها للمحول vSwitch، يكون لدينا هذا الأمر:
# esxcli network nic stats get -n <vmnic>
يعرض هذا الأمر معلومات مثل الحزم المستلمة ووحدات البايت المستلمة والحزم التي يتم إسقاطها والأخطاء المستلمة. هذا يمكن أن يساعد في تحديد ما إذا كان هناك أي حالات سقوط تحدث في NIC.
هناك بعض التكوينات التي يجب التحقق منها التي يمكنها تحسين أداء Cisco Catalyst 8000V التي تعمل على بيئة ESXi من خلال تعديل الإعدادات على المضيف والجهاز الظاهري:
تعيين الأجهزة الظاهرية: إعداد حجز وحدة المعالجة المركزية إلى الحد الأقصى.
حجز كافة ذاكرة الضيوف في الأجهزة الظاهرية: الذاكرة.
حدد برنامج VMware Paravirical من الأجهزة الافتراضية: وحدة التحكم SCSI.
من الأجهزة الافتراضية: مهايئ الشبكة: خيار نوع المحول، حدد SR-IOV لبطاقات واجهة الشبكة (NICs) المدعومة
قم بتعيين إصدار نظام التشغيل الضيف العام > خيار VM إلى نظام التشغيل 3.x أو نظام التشغيل الأحدث (64-بت).
قم بتعيين خيار خيارات الأجهزة الافتراضية (VM) ضمن "حساسية زمن الوصول المتقدم" إلى "عالي".
تحت VM Options > Advanced Edit Configuration، أضف "numa.nodeAffinity" إلى نفس عقدة NIC الخاصة ب SRIOV
تمكين إعدادات أداء برنامج مراقبة الأجهزة الافتراضية.
يمكنك الحد من التكاليف الإضافية للمحول vSwitch من خلال تمكين SR-IOV على بطاقات واجهة الشبكة (NIC) المادية المدعومة.
قم بتكوين وحدات المعالجة المركزية الافتراضية (vCPUs) للتشغيل على عقدة NUMA نفسها الخاصة ببطاقات واجهة الشبكة (NICs) المادية.
تعيين حساسية زمن وصول VM إلى عالي.
AWS
يدعم الطراز C8000v النشر على AWS من خلال إطلاقه كصورة جهاز Amazon (AMI) داخل شبكة Amazon Virtual Private (VPC)، مما يتيح للمستخدمين توفير قسم معزول منطقيا من سحابة AWS لموارد الشبكة الخاصة بهم.
قوائم انتظار Multi-TX
في C8000v التي تعمل على AWS، هناك ميزة رئيسية وهي إستخدام قوائم انتظار Multi-TX (Multi-TXQs). تساعد قوائم الانتظار هذه على تقليل تكاليف المعالجة الداخلية وتحسين إمكانية التوسع. إن وجود قوائم انتظار متعددة يجعل تعيين الحزم الواردة والصادرة إلى وحدة المعالجة المركزية الظاهرية (vCPU) الصحيحة أسرع وأسهل.
وعلى عكس بعض الأنظمة التي يتم فيها تعيين قوائم انتظار RX/TX لكل وحدة معالجة مركزية (vCPU)، يتم تعيين قوائم الانتظار هذه لكل واجهة في الطراز C8000v. تعمل قوائم انتظار RX (الاستقبال) و TX (الإرسال) كنقاط اتصال بين تطبيق Catalyst 8000V والبنية الأساسية أو جهاز AWS، مما يتيح إدارة كيفية إرسال حركة مرور الشبكة واستقبالها. تتحكم AWS في عدد وسرعة قوائم انتظار RX/TX المتوفرة لكل واجهة، حسب نوع المثيل.
لإنشاء قوائم انتظار TX متعددة، يحتاج Catalyst 8000V أن يكون له واجهات متعددة. عند تمكين قوائم انتظار TX متعددة، يحتفظ الجهاز بترتيب تدفق الحزمة باستخدام طريقة تجزئة استنادا إلى مجموعة 5 من التدفق (مصدر IP ووجهة IP ومنفذ مصدر ومنفذ وجهة وبروتوكول). يحدد هذا التجزئة أي قائمة انتظار TX يتم إستخدامها لكل تدفق.
يمكن للمستخدمين إنشاء واجهات متعددة على المادة حفازة 8000V باستخدام نفس بطاقة واجهة الشبكة المادية (NIC) المرفقة بمثيل AWS. ويتم ذلك من خلال تكوين واجهات الاسترجاع أو إضافة عناوين IP الثانوية.
باستخدام TXQs متعددة، هناك قوائم انتظار إرسال متعددة لمعالجة حركة المرور الصادرة. في المثال، هناك إثنتا عشرة قائمة انتظار TX (مرقمة من 0 إلى 11). يسمح لك هذا الإعداد بمراقبة كل قائمة انتظار على حدة لمعرفة ما إذا كان أي منها قد أصبح ممتلئا.
بالنظر إلى الإخراج، يمكنك أن ترى أن قائمة انتظار TX 8 بها عداد "كامل" مرتفع جدا (56،406،998)، مما يعني أن المخزن المؤقت الخاص بها يتم حشده بشكل متكرر. تظهر قوائم انتظار TX الأخرى صفر للعداد "full"، مما يشير إلى أنها غير مزدحمة.
Router#show platform hardware qfp active datapath infrastructure sw-cio pmd b17a2f00 device Gi2 RX: pkts 9525 bytes 1229599 return 0 badlen 0 Out-of-credits: Hi 0 Lo 0 pkts/burst 1 cycl/pkt 560 ext_cycl/pkt 360 Total ring read 117322273, empty 117312792 TX: pkts 175116324 bytes 246208197526 pri-0: pkts 157 bytes 10238 pkts/send 1 pri-1: pkts 75 bytes 4117 pkts/send 1 pri-2: pkts 91 bytes 6955 pkts/send 1 pri-3: pkts 95 bytes 8021 pkts/send 1 pri-4: pkts 54 bytes 2902 pkts/send 1 pri-5: pkts 75 bytes 4082 pkts/send 1 pri-6: pkts 104 bytes 8571 pkts/send 1 pri-7: pkts 74 bytes 4341 pkts/send 1 pri-8: pkts 175115328 bytes 246208130411 pkts/send 2 pri-9: pkts 85 bytes 7649 pkts/send 1 pri-10: pkts 106 bytes 5784 pkts/send 1 pri-11: pkts 82 bytes 7267 pkts/send 1 Total: pkts/send 2 cycl/pkt 203 send 68548581 sendnow 175024880 forced 1039215617 poll 1155226129 thd_poll 0 blocked 2300918060 retries 68534370 mbuf alloc err 0 TX Queue 0: full 0 current index 0 hiwater 0 TX Queue 1: full 0 current index 0 hiwater 0 TX Queue 2: full 0 current index 0 hiwater 0 TX Queue 3: full 0 current index 0 hiwater 0 TX Queue 4: full 0 current index 0 hiwater 0 TX Queue 5: full 0 current index 0 hiwater 0 TX Queue 6: full 0 current index 0 hiwater 0 TX Queue 7: full 0 current index 0 hiwater 0 TX Queue 8: full 56406998 current index 224 hiwater 224 <<<<<<<<<< TX Queue 9: full 0 current index 0 hiwater 0 TX Queue 10: full 0 current index 0 hiwater 0 TX Queue 11: full 0 current index 0 hiwater 0
تساعد مراقبة العدادات "الكاملة" لقوائم انتظار TX في التعرف على ما إذا كان هناك تحميل زائد لأي قائمة انتظار إرسال. يؤدي وجود عدد "كامل" بشكل مستمر في قائمة انتظار TX معينة إلى تدفق حركة المرور الذي يشدد على الجهاز. قد ينطوي التعامل مع هذه المشكلة على موازنة حركة المرور أو ضبط التكوينات أو زيادة الموارد لتحسين الأداء.
المقاييس المتجاوزة
يعمل AWS على تعيين حدود شبكة معينة على مستوى المثيل لضمان توفر أداء شبكات متناسق وعالي الجودة عبر أحجام مثيل مختلفة. تساعد هذه الحدود في الحفاظ على ثبات الشبكة لجميع المستخدمين.
يمكنك التحقق من هذه الحدود والإحصائيات ذات الصلة باستخدام الأمر show controllers على جهازك. يتضمن الإخراج العديد من العدادات، ولكننا نركز هنا فقط على العدادات الأكثر أهمية لمراقبة أداء الشبكة:
يمكنك الآن الغوص فيها ورؤية ما تشير إليه تلك العدادات بالضبط:
BW_IN_ALLOWANCE_EXCEEDED: عدد الحزم التي تم وضعها في قائمة الانتظار أو إسقاطها بسبب تجاوز النطاق الترددي الوارد حد المثيل.
BW_OUT_ALLOWANCE_EXCEEDED: عدد الحزم التي تم وضعها في قائمة الانتظار أو إسقاطها لأن النطاق الترددي الصادر تجاوز حد المثيل.
PPS_ALLOWANCE_EXCEEDED: عدد الحزم التي تم وضعها في قائمة الانتظار أو إسقاطها لأن إجمالي الحزم في الثانية (PPS) تجاوز حد المثيل.
CONTRACK_ALLOWANCE_EXCEEDED: عدد الاتصالات التي تم تعقبها والتي بلغت الحد الأقصى المسموح به لنوع المثيل.
linkLocal_Allowance_Exceeded: عدد الحزم التي تم إسقاطها بسبب تجاوز حركة المرور إلى خدمات الوكيل المحلي (مثل Amazon DNS وخدمة بيانات تعريف المثيل وخدمة مزامنة الوقت) حد PPS لواجهة الشبكة. لا يؤثر ذلك على تحليلات DNS المخصصة.
ما يعنيه هذا للأداء C8000v:
إذا لاحظت أن هذه العدادات تتزايد وتعاني من مشاكل في الأداء، فهذا لا يعني دائما أن الموجه C8000v هو المشكلة. بدلا من ذلك، غالبا ما يشير إلى أن مثيل AWS الذي تستخدمه قد بلغ حدود السعة. يمكنك التحقق من مواصفات مثيل AWS للتأكد من قدرته على معالجة إحتياجات حركة المرور الخاصة بك.
Microsoft Azure
في هذا القسم، استكشف كيفية تجمع Microsoft Azure والموجه الظاهري Cisco C8000v لتوفير حلول شبكات افتراضية قابلة للتطوير وآمنة وعالية الأداء في الشبكة.
انتقل إلى الطريقة التي يمكن أن تؤثر بها الشبكات (AN) السريعة وتجزئة الحزمة على الأداء. بالإضافة إلى مراجعة أهمية إستخدام نوع مثيل مدعوم ل Microsoft Azure.
شبكات سريعة
في حالات مشاكل الأداء التي يتم فيها إستضافة C8000v في سحابة Microsoft Azure. هناك جانب لا يمكنك تجاهله وهو ما إذا كانت الشبكة المتسارعة ممكنة أم لا. كما يعمل على زيادة أداء الموجه بشكل كبير. باختصار، تعمل الشبكة السريعة على تمكين المحاكاة الافتراضية للإدخال/الإخراج أحادية الجذر (SR-IOV) على الأجهزة الافتراضية (VM) مثل محول Catalyst 8000V VM من Cisco. يتجاوز مسار الشبكة السريع المحول الظاهري، ويزيد من سرعة حركة مرور الشبكة، ويحسن أداء الشبكة، ويقلل من زمن انتقال الشبكة وتشوهها.
هناك طريقة بسيطة جدا للتحقق من تمكين الشبكة المتسارعة. وذلك للتحقق من إخراج show controllers والتحقق من وجود عدادات معينة أو عدم وجودها:
------------------ show controllers ------------------
GigabitEthernet1 - Gi1 is mapped to UIO on VXE
rx_good_packets 6497723453
tx_good_packets 14690462024
rx_good_bytes 2271904425498
tx_good_bytes 6276731371987
rx_q0_good_packets 58576251
rx_q0_good_bytes 44254667162
vf_rx_good_packets 6439147188
vf_tx_good_packets 14690462024
vf_rx_good_bytes 2227649747816
vf_tx_good_bytes 6276731371987
العدادات التي تبحث عنها هي التي تبدأ ب VF مثل vf_rx_good_packet. إذا قمت بالتحقق من وجود هذه العدادات، فيمكنك التأكد تماما من تمكين الشبكة السريعة.
Azure والتجزئة
قد يكون للتجزئة آثار سلبية على الأداء. أحد الأسباب الرئيسية للتأثير على الأداء هو تأثير وحدة المعالجة المركزية (CPU)/الذاكرة لتجزئة الحزم وإعادة تجميعها. عندما يحتاج جهاز الشبكة إلى تجزئة حزمة، فيجب عليه تخصيص موارد وحدة المعالجة المركزية (CPU)/الذاكرة لتنفيذ التجزئة.
يحدث نفس الشيء عندما يتم إعادة تجميع الحزمة. يجب أن يقوم جهاز الشبكة بتخزين جميع الأجزاء حتى يتم استقبالها بحيث يمكن إعادة تجميعها في الحزمة الأصلية.
لا يقوم Azure بمعالجة الحزم المجزأة باستخدام الشبكة السريعة. عندما يستقبل VM حزمة مجزأة، يقوم المسار غير المتسارع بمعالجتها. ونتيجة لذلك، تفوت الحزم المجزأة فوائد الشبكة السريعة، مثل زمن الوصول الأقل والتردد الأقل والحزم الأعلى في الثانية. ولهذا السبب، فإن التوصية هي تفادي التجزؤ إن أمكن.
يقوم Azure، بشكل افتراضي، بإسقاط الحزم المجزأة التي تصل إلى VM خارج الترتيب، مما يعني أن الحزم لا تطابق تسلسل الإرسال من نقطة نهاية المصدر. يمكن أن تحدث هذه المشكلة عندما تنتقل الحزم عبر الإنترنت أو شبكات WAN كبيرة أخرى.
السبب في ذلك هو أن أنواع المثيل في تلك القائمة هي تلك التي تم إختبار C8KV فيها بشكل صحيح. الآن، هناك سؤال صحيح إذا كان C8000v يعمل على نوع مثيل غير مدرج؟ الإجابة هي على الأرجح نعم. ومع ذلك، عندما تقوم باستكشاف شيء ما على نفس القدر من التعقيد مثل مشاكل الأداء، فإنك لا تريد إضافة عامل غير معروف آخر إلى المشكلة. لهذا السبب وحده، توصيك Cisco TAC دائما بالبقاء في نوع مثيل مدعوم.
موارد إضافية
لا يمكن أستكشاف أخطاء الأداء وإصلاحها إلا عند حدوثها في هذه اللحظة. ومع ذلك، قد يكون من الصعب فهم ذلك لأنه قد يحدث في أي لحظة. ولهذا السبب، نقدم هذا النص. يساعد على التقاط مخرجات مهمة في اللحظة التي تبدأ فيها الحزم في السقوط وتظهر فيها مشكلات في الأداء: