يصف هذا المستند مشاكل الأداء الشائعة في بيئات FlexPod، ويوفر طريقة لاستكشاف المشكلات وإصلاحها، كما يوفر خطوات تخفيف. تم تصميمه كنقطة بداية للعملاء الذين يسعون إلى أستكشاف الأداء وإصلاحها في بيئة FlexPod. تمت كتابة هذا المستند نتيجة مشاكل شاهدها فريق مركز المساعدة التقنية لحلول مراكز البيانات (TAC) في الأشهر الأخيرة.
يتكون FlexPod من كمبيوتر نظام الحوسبة الموحدة (UCS) متصل عبر محول Nexus إلى وحدات تخزين NetApp وشبكات IP.
ويتكون FlexPod الأكثر شيوعا من هيكل Cisco UCS فئة B المتصل عبر منافذ ربط البنية (FIs) بمحولات Nexus 5500 إلى موجهات NetApp. وهناك حل آخر يدعى FlexPod Express يستخدم هيكل UCS C-Series المتصل بمحولات Nexus 3000. يناقش هذا المستند FlexPod الأكثر شيوعا.
في البيئات المعقدة التي بها أطراف مسؤولة متعددة كما هو موضح عادة في FlexPod، تحتاج إلى إعتبار جوانب متعددة لاستكشاف المشكلة وإصلاحها. تنبع مشاكل الأداء النموذجية في شبكات الطبقة 2 و IP من:
من المهم أن تعرف البيئة التي يقاس الأداء من أجلها. يجب أن يتم طرح الأسئلة حول نوع التخزين والبروتوكول، بالإضافة إلى نظام تشغيل الخادم المتأثر (OS) والموقع، لتقليل المشكلة بشكل صحيح. مخطط مخطط مخطط مخطط يوضح الاتصال هو الحد الأدنى.
تحتاج إلى معرفة ما يتم قياسه وكيف يتم قياسه. توفر بعض التطبيقات، بالإضافة إلى معظم بائعي وحدات التخزين وبرامج مراقبة الأجهزة الافتراضية، قياسات من نوع ما تشير إلى أداء/سلامة النظام. تعد هذه القياسات نقطة جيدة للبدء بها لأنها ليست بديلا لمعظم منهجيات أستكشاف الأخطاء وإصلاحها.
على سبيل المثال، قد يشير قياس زمن وصول تخزين نظام ملفات الشبكة (NFS) في برنامج hypervisor إلى انخفاض الأداء، إلا أنه في حد ذاته لا يتضمن الشبكة. في حالة نظام ملفات الشبكة (NFS)، قد يشير إختبار اتصال بسيط من المضيف إلى شبكة IP الخاصة بتخزين NFS إلى ما إذا كان يجب إلقاء اللوم على الشبكة أم لا.
لا يمكن التأكيد على هذه النقطة بشكل كاف، وخاصة عند فتح حالة مركز المساعدة الفنية. ولبيان أن الأداء غير مرض، يلزم الإشارة إلى المعامل المقاس. وهذا يشمل القيمة المتوقعة والمختبرة. من الناحية المثالية، يجب عرض البيانات السابقة ومنهجية الاختبار المستخدمة للحصول على هذه البيانات.
على سبيل المثال، زمن الوصول الذي يبلغ 10 مللي ثانية والذي تم تحقيقه عند الاختبار، مع كتابة فقط من بادئ واحد إلى رقم وحدة منطقي واحد (LUN)، قد لا يكون مؤشرا على ما يفترض أن يكون زمن الوصول لنظام تم تحميله بالكامل.
بما أن الهدف من هذا المستند هو أن يكون مرجعا لغالبية بيئات FlexPod، فإنه يحدد المشاكل الأكثر شيوعا فقط كما هو موضح من قبل فريق TAC المسؤول عن حلول مركز البيانات.
تتم مناقشة المشاكل الشائعة في وحدات التخزين وشبكات IP/الطبقة 2 في هذا القسم.
يعد فقدان الإطارات والحزم أكثر العوامل شيوعا التي تؤثر على الأداء. وأحد الأماكن المشتركة للبحث عن مؤشرات على وجود مشكلة هو على مستوى الواجهة. من واجهة سطر الأوامر (CLI) الخاصة بنظام التشغيل Nexus 5000 أو UCS Nexus (NX-OS)، أدخل الواجهة show | الثانية "تم" | egrep ^(eth|fc)|discard|drop| أمر CRC. للواجهات الموجودة في الأعلى، يسرد الاسم ويرفض العدادات وحالات السقوط. بالمثل، يتم عرض نظرة عامة رائعة عند إدخال أمر خطأ show interface counters الذي يعرض إحصائيات الأخطاء لجميع الواجهات.
من المهم معرفة أن العدادات في غير الصفر قد لا تشير إلى مشكلة. في بعض السيناريوهات، قد تكون هذه العدادات قد تم رفعها في الإعداد الأولي أو في التغييرات التشغيلية السابقة. يجب مراقبة زيادة في العدادات.
ويمكن أيضا جمع عدادات من مستوى ASIC، وهو ما قد يكون أكثر دلالة. وعلى وجه الخصوص، لخطأ التحقق الدوري من التكرار (CRC) على الواجهات، يكون الأمر المفضل لإدخال TAC هو show hardware internal carmel crc. الكرمل هو اسم ASIC المسؤول عن إعادة التوجيه على مستوى المنفذ.
كما يمكن الحصول على إخراج مماثل من شبكات FiS من السلسلة 6100 أو محولات Nexus 5600 لكل منفذ. بالنسبة ل FI 6100، Gatos ASIC، أدخل هذا الأمر:
show hardware internal gatos port ethernet X/Y | grep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"
ل Nexus 5600، من BigSur ASIC، دخلت هذا أمر:
show hardware internal bigsur port eth x/y | egrep
"OVERSIZE|TOOLONG|DISCARD|UNDERSIZE|FRAGMENT|T_CRC|ERR|JABBER|PAUSE"
توضح الأمر الخاص ب CRC ASIC مكان إستلام حزم CRC والمكان الذي تمت إعادة توجيهها إليه، والأهم من ذلك ما إذا كانت قد تمت غمسها أم لا.
بما أن كلا من عملية Nexus 5000 و UCS NX-OS يتم قصها، فإن إطارات وضع التحويل ذات تسلسل فحص الإطارات غير الصحيح (FCS) يتم غربتها فقط قبل إعادة التوجيه. من المهم أن تعرف من أين تأتي الإطارات التالفة.
bdsol-6248-06-A(nxos)# show hardware internal carmel crc
+----------+------------+------------+------------+------------+------------+------------+------------+
| Port | MM rx CRC | MM Rx Stomp| FI rx CRC | FI Rx Stomp| FI tx CRC | FI tx Stomp| MM tx CRC |
+----------+------------+------------+------------+------------+------------+------------+------------+
(....)
| Eth 1/17 | --- | --- | --- | 908100 | --- | --- | --- |
| Eth 1/18 | --- | --- | --- | 298658 | --- | --- | --- |
(....)
| Eth 1/34 | --- | --- | --- | --- | --- | 1206758 | 1206758 |
يوضح هذا المثال الحزم المجدولة التي تأتي من ETH 1/17 و ETH 1/18، وهي وصلة إلى Nexus 5000. يمكن للمرء أن يفترض أن تلك الإطارات تم إرسالها في وقت لاحق إلى ETH 1/34، مثل ETH 1/17 + ETH 1/18 RX Stomp = ETH 1/34 TX Stomp.
تظهر نظرة مماثلة على Nexus 5000:
bdsol-n5548-05# show hardware internal carmel crc
+----------+------------+------------+------------+------------+------------+------------+------------+
| Port | MM rx CRC | MM Rx Stomp| FI rx CRC | FI Rx Stomp| FI tx CRC | FI tx Stomp| MM tx CRC |
+----------+------------+------------+------------+------------+------------+------------+------------+
(....)
| Eth 1/14 | 13 | --- | --- | 13 | --- | --- | --- |
(.....)
| Eth 1/19 | 7578 | --- | --- | 7463 | --- | --- | --- |
يوضح هذا الإخراج إستلمت CRCs على ارتباطين وتم وضع علامة عليها كأدوات قبل إعادة التوجيه. لمزيد من المعلومات، راجع دليل أستكشاف أخطاء Nexus 5000 وإصلاحها.
توجد طريقة بسيطة للبحث عن عمليات الإسقاط (إخلاء المسؤولية، الخطأ، CRCs، إستهلاك الائتمان B2B) عبر الأمر show interface counters fc.
يوفر هذا الأمر، المتوفر على Nexus 5000 و Fabric Interconnect، مؤشرا جيدا لما يحدث في عالم القنوات الليفية.
على سبيل المثال:
bdsol-n5548-05# show interface counters fc | i fc|disc|error|B2B|rate|put
fc2/16
1 minute input rate 72648 bits/sec, 9081 bytes/sec, 6 frames/sec
1 minute output rate 74624 bits/sec, 9328 bytes/sec, 5 frames/sec
96879643 frames input, 155712103332 bytes
0 discards, 0 errors, 0 CRC
113265534 frames output, 201553309480 bytes
0 discards, 0 errors
0 input OLS, 1 LRR, 0 NOS, 0 loop inits
1 output OLS, 2 LRR, 0 NOS, 0 loop inits
0 transmit B2B credit transitions from zero
0 receive B2B credit transitions from zero
16 receive B2B credit remaining
32 transmit B2B credit remaining
0 low priority transmit B2B credit remaining
(...)
هذه الواجهة ليست مشغولة، ويعرض الإخراج عدم حدوث أخطاء أو أخطاء.
بالإضافة إلى ذلك، تم تمييز عمليات تحويل ائتمان B2B من 0؛ بسبب معرفات أخطاء Cisco CSCue80063 وCSCut08353، لا يمكن الوثوق بهذه العدادات. إنهم يعملون بشكل جيد على Cisco MDS، ولكن ليس على UCS الخاص بمنصات Nexus5k. أيضا أنت يستطيع دققت cisco بق id CSCsz95889.
وبالمثل في عالم الإيثرنت Carmel بالنسبة للقناة الليفية (FC)، يمكن إستخدام مرفق FC-MAC. دخلت كمثال، لميناء fc2/1، العرض جهاز داخلي fc-mac 2 ميناء إحصائيات أمر. العدادات المعروضة بتنسيق سداسي عشر.
bdsol-6248-06-A(nxos)# show interface fc1/32 | i disc
15 discards, 0 errors
0 discards, 0 errors
bdsol-6248-06-A(nxos)# show hardware internal fc-mac 1 port 32 statistics
ADDRESS STAT COUNT
__________ ________ __________________
0x0000003d FCP_CNTR_MAC_RX_BAD_WORDS_FROM_DECODER 0x70
0x00000042 FCP_CNTR_MAC_CREDIT_IG_XG_MUX_SEND_RRDY_REQ 0x1e4f1026
0x00000043 FCP_CNTR_MAC_CREDIT_EG_DEC_RRDY 0x66cafd1
0x00000061 FCP_CNTR_MAC_DATA_RX_CLASS3_FRAMES 0x1e4f1026
0x00000069 FCP_CNTR_MAC_DATA_RX_CLASS3_WORDS 0xe80946c708
0x000d834c FCP_CNTR_PIF_RX_DROP 0xf
0x00000065 FCP_CNTR_MAC_DATA_TX_CLASS3_FRAMES 0x66cafd1
0x0000006d FCP_CNTR_MAC_DATA_TX_CLASS3_WORDS 0x2b0fae9588
0xffffffff FCP_CNTR_OLS_IN 0x1
0xffffffff FCP_CNTR_LRR_IN 0x1
0xffffffff FCP_CNTR_OLS_OUT 0x1
تعرض المخرجات 15 مرتجلا على الإدخال. يمكن تطابق هذا مع FCP_CNTR_PIF_RX_DROP الذي تم حسابه إلى 0xf (15 بوصة عشرية). يمكن ربط هذه المعلومات مرة أخرى بمعلومات FWM (مدير إعادة التوجيه).
bdsol-6248-06-A(nxos)# show platform fwm info pif fc 1/32 verbose | i drop|discard|asic
fc1/32 pd: slot 0 logical port num 31 slot_asic_num 3 global_asic_num 3 fwm_inst 7
fc 0
fc1/32 pd: tx stats: bytes 191196731188 frames 107908990 discard 0 drop 0
fc1/32 pd: rx stats: bytes 998251154572 frames 509332733 discard 0 drop 15
fc1/32 pd fcoe: tx stats: bytes 191196731188 frames 107908990 discard 0 drop 0
fc1/32 pd fcoe: rx stats: bytes 998251154572 frames 509332733 discard 0 drop 15
ومع ذلك، يشير هذا إلى المسؤول عن مقدار حالات السقوط والذي هو رقم ASIC المطابق. يجب الاستعلام عن معلومات الحصول على معلومات حول سبب إسقاط ASIC.
bdsol-6248-06-A(nxos)# show platform fwm info asic-errors 3
Printing non zero Carmel error registers:
DROP_SHOULD_HAVE_INT_MULTICAST: res0 = 25 res1 = 0 [36]
DROP_INGRESS_ACL: res0 = 15 res1 = 0 [46]
في هذه الحالة، تم إسقاط حركة المرور بواسطة قائمة التحكم في الوصول (ACL) إلى المدخل، عادة في FC World - المناطق.
في بيئات FlexPod، من المهم إستيعاب إعداد وحدة الانتقال القصوى (MTU) الشاملة للتطبيقات والبروتوكولات حيثما كانت مطلوبة. في حالة معظم البيئات، تكون هذه هي القنوات الليفية عبر شبكة إيثرنت (FCoE) والإطارات كبيرة الحجم.
وبالإضافة إلى ذلك، في حالة حدوث التجزئة، يتوقع حدوث أداء مخفض. في حالة وجود بروتوكولات مثل نظام ملفات الشبكة (NFS) وواجهة نظام الكمبيوتر الصغير عبر الإنترنت (iSCSI)، فمن المهم إختبار وحدة الإرسال القصوى (MTU) ل IP الشاملة (MTU) والحد الأقصى لحجم مقطع TCP (MSS) وإثباتها.
سواء قمت باستكشاف أخطاء الإطارات كبيرة الحجم أو تقنية القنوات الليفية عبر شبكة إيثرنت (FCoE) وإصلاحها، فمن المهم تذكر أن كلا منهما يحتاج إلى تهيئة متناسقة وعلامات فئة الخدمة (CoS) عبر البيئة من أجل العمل بشكل صحيح.
في حالة UCS و Nexus، يكون الأمر الذي يكون مفيدا للتحقق من صحة كل واجهة، فإن إعداد وحدة الحد الأقصى للنقل (MTU) لكل جودة خدمة مجموعة هو show queuing interface | قائمة الانتظار|مجموعة جودة الخدمة|MTU.
من الجوانب المعروفة لكل من UCS و Nexus عرض وحدات الحد الأقصى للنقل (MTU) على الواجهة. يوضح هذا الإخراج واجهة تم تكوينها لوضع إطارات كبيرة الحجم وقنوات ليفية عبر شبكة إيثرنت (FCoE) في قائمة الانتظار:
bdsol-6248-06-A(nxos)# show queuing interface e1/1 | i MTU
q-size: 360640, HW MTU: 9126 (9126 configured)
q-size: 79360, HW MTU: 2158 (2158 configured)
في نفس الوقت، يعرض أمر show interface 1500 بايت:
bdsol-6248-06-A(nxos)# show int e1/1 | i MTU
MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec
وإذا ما قورنت ASIC بمعلومات Carmel ASIC فإنها تبين قدرة وحدة الحد الأقصى للنقل (MTU) على منفذ معين.
show hardware internal carmel port ethernet 1/1 | egrep -i MTU
mtu : 9260
من المتوقع أن يظهر عدم تطابق وحدة الحد الأقصى للنقل (MTU) هذا على الأنظمة الأساسية المذكورة آنفا، وقد يؤدي إلى تضليل النباتات الجديدة.
والتهيئة المتناسقة الشاملة هي الطريقة الوحيدة لضمان الأداء المناسب. يتم وصف تكوين الإطارات الكبيرة والخطوات الخاصة بجانب Cisco، بالإضافة إلى برنامج ESXi من VMware، في UCS مع مثال تكوين Jumbo MTU الشامل من VMware ESXi.
يوضح مثال تكوين وصلة UCS FCoE تكوين UCS و Nexus 5000. راجع الملحق (أ) في المستند المشار إليه للحصول على مخطط تفصيلي لتكوين Nexus 5000 الأساسي.
إعداد اتصال تقنية القنوات الليفية عبر شبكة إيثرنت (FCoE) لخادم نصلي من Cisco UCS يركز على تكوين UCS ل FCoE. يركز مثال تكوين UCS المرفق بتقنية NPIV للقنوات الليفية عبر شبكة إيثرنت (FCoE) مع تقنية القنوات الليفية عبر شبكة إيثرنت (FCoE) على تكوين Nexus.
توفر معظم أنظمة التشغيل العصرية القدرة على إختبار تكوين إطارات كبيرة الحجم بشكل مناسب باستخدام إختبار بروتوكول رسائل التحكم في الإنترنت (ICMP) البسيط.
9000 بايت - رأس IP بدون خيارات (20 بايت) - رأس ICMP (8 بايت) = 8972 بايت من البيانات
لينكس
ping a.b.c.d -M do -s 8972
مايكروسوفت ويندوز
ping -f -l 8972 a.b.c.d
ESXi
vmkping -d -s 8972 a.b.c.d
تعد التخزين المؤقت والمشاكل الأخرى المتعلقة بزمن الوصول من بين الأسباب الشائعة لتدهور الأداء في بيئة FlexPod. ليست كل المشاكل المبلغ عنها لأن زمن الوصول نابع من مشاكل التخزين المؤقت الفعلية، عدد لا بأس به من القياسات قد يشير إلى زمن الوصول من نهاية إلى نهاية. على سبيل المثال، في حالة نظام ملفات الشبكة (NFS)، قد تكون الفترة الزمنية المبلغ عنها مطلوبة للقراءة/الكتابة بنجاح إلى وحدة التخزين وليس لزمن الوصول الفعلي للشبكة.
الازدحام هو السبب الأكثر شيوعا للتخزين المؤقت. في عالم الطبقة 2، يمكن أن يؤدي الازدحام إلى التخزين المؤقت وحتى عمليات إسقاط إطارات. لتجنب حالات السقوط أثناء فترات الازدحام، تم تقديم إطارات IEEE 802.3x للإيقاف المؤقت والتحكم في تدفق الأولويات (PFC). يعتمد كلاهما على طلب نقطة النهاية لعقد الارسال لفترة قصيرة من الوقت فيما يستمر الازدحام. وقد يحدث هذا بسبب إزدحام الشبكة (حيث يتم التغلب على حجم البيانات التي تم تلقيها) أو بسبب ضرورة تمرير إطار تم ترتيب أولوياته، كما هو الحال بالنسبة لتقنية القنوات الليفية عبر شبكة إيثرنت (FCoE).
للتحقق من الواجهات التي تم تمكين التحكم في التدفق عليها، أدخل الأمر show interface flow control. من المهم اتباع توصية مورد التخزين فيما يتعلق بتمكين التحكم في التدفق.
يوضح الرسم التوضيحي الذي يوضح كيفية عمل التحكم في التدفق 802.3x هنا.
لا يلزم وجود PFC لجميع المجموعات، ولكنه يوصى به لمعظم المجموعات. للتحقق من الواجهات التي تم تمكين PFC لها، يقوم show interface priority-flow-control | يمكن تشغيل i on command على UCS NX-OS و Nexus 5000.
يجب أن تكون الواجهات بين FIs و Nexus 5000 مرئية على تلك القائمة. وإذا لم تكن هناك حاجة إلى التحقق من تكوين جودة الخدمة. يجب أن تكون جودة الخدمة متناسقة ومتكاملة من أجل الاستفادة من PFC. للتحقق من سبب عدم وصول PFC إلى واجهة معينة، أدخل الأمر show system internal dcbx log interface ethernet x/y للحصول على سجل بروتوكول تبادل إمكانات التوصيل بين مراكز البيانات (DCBX).
يظهر رسم توضيحي يوضح كيفية عمل إطارات Pause (الإيقاف المؤقت) مع PFC هنا.
يتيح الأمر show interface priority-flow-control للمسؤول إمكانية مراقبة سلوك الفئة لكل جودة خدمة إطارات Priority Pause (إيقاف مؤقت).
هنا مثال :
bdsol-6120-05-A(nxos)# show queuing interface ethernet 1/1 | i prio
Per-priority-pause status : Rx (Inactive), Tx (Inactive)
Per-priority-pause status : Rx (Inactive), Tx (Active)
توضح هذه المخرجات أن الجهاز، في الفئة الثانية، كان يرسل (TX) إطار PPP فقط.
في هذه الحالة، إثرنيت 1/1 ميناء يواجه IOM وبينما ال عموما ميناء لن يتلقى PFC يمكن، هو أمكن عالجت إطار PPP لميناء FEX.
bdsol-6120-05-A(nxos)# show interface e1/1 priority-flow-control
============================================================
Port Mode Oper(VL bmap) RxPPP TxPPP
============================================================
Ethernet1/1 Auto Off 4885 3709920
وفي هذه الحالة، تكون واجهات FEX مشاركة.
bdsol-6120-05-A(nxos)# show interface priority-flow-control | egrep .*\/.*\/
Ethernet1/1/1 Auto Off 0 0
Ethernet1/1/2 Auto Off 0 0
Ethernet1/1/3 Auto Off 0 0
Ethernet1/1/4 Auto Off 0 0
Ethernet1/1/5 Auto On (8) 8202210 15038419
Ethernet1/1/6 Auto On (8) 0 1073455
Ethernet1/1/7 Auto Off 0 0
Ethernet1/1/8 Auto On (8) 0 3956077
Ethernet1/1/9 Auto Off 0 0
كما يمكن التحقق من منافذ FEX المشاركة عبر تفاصيل show fex x حيث يمثل X رقم الهيكل.
bdsol-6120-05-A(nxos)# show fex 1 detail | section "Fex Port"
Fex Port State Fabric Port
Eth1/1/1 Down Eth1/1
Eth1/1/2 Down Eth1/2
Eth1/1/3 Down None
Eth1/1/4 Down None
Eth1/1/5 Up Eth1/1
Eth1/1/6 Up Eth1/2
Eth1/1/7 Down None
Eth1/1/8 Up Eth1/2
Eth1/1/9 Up Eth1/2
راجع هذه الوثائق للحصول على مزيد من المعلومات حول آليات PAUSE (الإيقاف المؤقت).
يقوم كل من Nexus 5000 و UCS NX-OS بتعقب المداخل المرتجعة بسبب قوائم الانتظار لكل مجموعة جودة الخدمة. على سبيل المثال:
bdsol-6120-05-A(nxos)# show queuing interface
Ethernet1/1 queuing information:
TX Queuing
qos-group sched-type oper-bandwidth
0 WRR 50
1 WRR 50
RX Queuing
qos-group 0
q-size: 243200, HW MTU: 9280 (9216 configured)
drop-type: drop, xon: 0, xoff: 243200
Statistics:
Pkts received over the port : 31051574
Ucast pkts sent to the cross-bar : 30272680
Mcast pkts sent to the cross-bar : 778894
Ucast pkts received from the cross-bar : 27988565
Pkts sent to the port : 34600961
Pkts discarded on ingress : 0
Per-priority-pause status : Rx (Inactive), Tx (Active)
يجب أن يحدث تجاهل المدخل فقط في قوائم الانتظار التي تم تكوينها للسماح بعمليات الإسقاط.
يمكن أن يحدث رفض قوائم انتظار الدخول لهذه الأسباب:
توفر Cisco برنامجي تشغيل ل UCS و ENIC و FNIC. يعد ENIC مسؤولا عن اتصال إيثرنت، كما أن FNIC مسؤول عن اتصال القناة الليفية وتقنية القنوات الليفية عبر شبكة إيثرنت. من المهم جدا أن تكون سواقات ENIC و FNIC كما هي محددة تماما في مصفوفة التوافق UCS. تتراوح المشاكل التي تم إدخالها من قبل برامج التشغيل غير الصحيحة من فقدان الحزم وزمن الوصول الإضافي إلى عملية تمهيد أطول أو النقص الكامل في الاتصال.
يمكن أن يوفر المهايئ الذي توفره Cisco قياسا جيدا لحركة المرور التي يتم تمريرها، وكذلك عمليات السقوط. يوضح هذا المثال كيفية الاتصال بالهيكل X والخادم Y والمهايئ Z.
bdsol-6248-06-A# connect adapter X/Y/Z
adapter X/Y/Z # connect
No entry for terminal type "dumb";
using dumb terminal settings.
من هنا، يمكن للمسؤول تسجيل الدخول إلى مرفق مركز المراقبة للأداء (MCP).
adapter 1/2/1 (top):1# attach-mcp
No entry for terminal type "dumb";
using dumb terminal settings
يسمح لك مرفق MCP بمراقبة إستخدام حركة مرور البيانات لكل واجهة منطقية (LIF).
adapter 1/2/1 (mcp):1# vnic
(...)
---------------------------------------- --------- --------------------------
v n i c l i f v i f
id name type bb:dd.f state lif state uif ucsm idx vlan state
--- -------------- ------- ------- ----- --- ----- --- ----- ----- ---- -----
13 vnic_1 enet 06:00.0 UP 2 UP =>0 834 20 3709 UP
14 vnic_2 fc 07:00.0 UP 3 UP =>0 836 17 970 UP
يحتوي الهيكل 1 والخادم 1 والمهايئ 1 على بطاقتي واجهة شبكة افتراضية (VNICs) مرتبطتين بالواجهات الظاهرية (إيثرنت الافتراضي أو قناة ليفية افتراضية) 834 و 836. هؤلاء لديهم رقمي 2 و 3. يمكن فحص إحصائيات المستويين 2 و 3 كما هو موضح هنا:
adapter 1/2/1 (mcp):3# lifstats 2
DELTA TOTAL DESCRIPTION
4 4 Tx unicast frames without error
53999 53999 Tx multicast frames without error
69489 69489 Tx broadcast frames without error
500 500 Tx unicast bytes without error
8361780 8361780 Tx multicast bytes without error
22309578 22309578 Tx broadcast bytes without error
2 2 Rx unicast frames without error
2791371 2791371 Rx multicast frames without error
4595548 4595548 Rx broadcast frames without error
188 188 Rx unicast bytes without error
260068999 260068999 Rx multicast bytes without error
514082967 514082967 Rx broadcast bytes without error
3668331 3668331 Rx frames len == 64
2485417 2485417 Rx frames 64 < len <= 127
655185 655185 Rx frames 128 <= len <= 255
434424 434424 Rx frames 256 <= len <= 511
143564 143564 Rx frames 512 <= len <= 1023
94.599bps Tx rate
2.631kbps Rx rate
من المهم ملاحظة أن مدير UCS يتم تزويده بالعمود total و delta (بين عمليتي تنفيذ لاحقتين لأحوال الحياة) بالإضافة إلى الحمل الحالي لحركة المرور لكل ليف ومعلومات حول أي أخطاء قد تكون حدثت.
يوضح المثال السابق الواجهات بدون أي أخطاء ذات تحميل صغير جدا. يوضح هذا المثال خادما مختلفا.
adapter 4/4/1 (mcp):2# lifstats 2
DELTA TOTAL DESCRIPTION
127927993 127927993 Tx unicast frames without error
273955 273955 Tx multicast frames without error
122540 122540 Tx broadcast frames without error
50648286058 50648286058 Tx unicast bytes without error
40207322 40207322 Tx multicast bytes without error
13984837 13984837 Tx broadcast bytes without error
28008032 28008032 Tx TSO frames
262357491 262357491 Rx unicast frames without error
55256866 55256866 Rx multicast frames without error
51088959 51088959 Rx broadcast frames without error
286578757623 286578757623 Rx unicast bytes without error
4998435976 4998435976 Rx multicast bytes without error
7657961343 7657961343 Rx broadcast bytes without error
96 96 Rx rq drop pkts (no bufs or rq disabled)
136256 136256 Rx rq drop bytes (no bufs or rq disabled)
5245223 5245223 Rx frames len == 64
136998234 136998234 Rx frames 64 < len <= 127
9787080 9787080 Rx frames 128 <= len <= 255
14176908 14176908 Rx frames 256 <= len <= 511
11318174 11318174 Rx frames 512 <= len <= 1023
61181991 61181991 Rx frames 1024 <= len <= 1518
129995706 129995706 Rx frames len > 1518
136.241kbps Tx rate
784.185kbps Rx rate
توضح وحدتا بت مثيرتان للاهتمام أن المحول أسقط 96 إطارا بسبب نقص المخزن المؤقت أو تعطيل التخزين المؤقت وإضافة إلى ذلك شرائح إلغاء تحميل مقطع TCP (TSO) التي تتم معالجتها.
يوضح المخطط المبين هنا تدفق الحزم المنطقي في بيئة FlexPod.
هذا الرسم التخطيطي يقصد به تصنيف المكونات التي يمر بها الإطار في الطريق عبر بيئة FlexPod. لا تعكس تعقيد أي من الكتل وهي ببساطة طريقة لحفظ المواضع التي يجب فيها تكوين ميزات معينة والتحقق منها.
كما هو موضح في الرسم التخطيطي المنطقي لتدفق الحزم، فإن وحدة الإدخال/الإخراج (IOM) هي مكون في وسط جميع الاتصالات التي تمر عبر UCS. من أجل الاتصال بالمنظمة الدولية للهجرة في الهيكل X، أدخل الأمر connect iom x.
هنا عدة أوامر مفيدة أخرى:
إنها تظهر واجهات شبكة (NIs) التي تؤدي إلى شبكات fi، في هذه الحالة هناك ثمانية منها، مع تشغيل أربعة منها. بالإضافة إلى ذلك، فإنه يعرض واجهات الأجهزة المضيفة (HIs) التي تؤدي، داخل الهيكل، إلى خوادم نصلية معينة.
بسبب طريقة عمل البنية الأساسية الأساسية، يتم عرض العدادات فقط للواجهات التي شهدت أي خسارة بين تنفيذ الأمرين. في هذا المثال، ترى أن واجهة NI2 تلقت 82 إطار إيقاف مؤقت وأن 28 إطار إيقاف مؤقت تم إرسالها إلى الواجهة HI23، والتي تعرف أنها متصلة بالخادم النصلي 3.
يتيح FlexPod تهيئة مرنة وإعداد وحدات التخزين وشبكات البيانات. ومع المرونة تأتي أيضا تحديات اضافية. من الضروري اتباع مستندات أفضل الممارسات وتصميم تم التحقق من صحة Cisco (CVD):
من المشكلات الشائعة التي رآها مهندسو TAC هو الإفراط في إستخدام الارتباطات بسبب تحديد إيثرنت 1 جيجابت بدلا من إيثرنت 10 جيجابت المشار إليه في وثائق أفضل الممارسات. على سبيل المثال، لن يكون أداء التدفق الفردي أفضل عند 10 إرتباطات بسرعة 1 جيجابت مقارنة بارتباط واحد بسرعة 10 جيجابت. في قناة المنفذ، يمكن أن ينتقل تدفق واحد عبر إرتباط واحد.
دخلت in order to اكتشفت أي ميناء موازنة طريقة يكون استعملت على Nexus و/أو NX-OS في FI، العرض ميناء-channel load-balance أمر. كما يمكن أن يكتشف المسؤول أي واجهة في قناة منفذ سيتم إختيارها كواجهة صادرة للحزمة أو الإطار. يوضح مثال بسيط لإطار على VLAN49 بين جهازين مضيفين هنا:
show port-channel load-balance forwarding-path interface port-channel 928 vlan 49
src-mac 70ca.9bce.ee24 dst-mac 8478.ac55.2fc2
Missing params will be substituted by 0's.
Load-balance Algorithm on switch: source-dest-ip
crc8_hash: 2 Outgoing port id: Ethernet1/27
Param(s) used to calculate load-balance:
dst-mac: 8478.ac55.2fc2
src-mac: 70ca.9bce.ee24
تعد المشاكل التي تمت مناقشتها سابقا شائعة في كل من شبكات البيانات ووحدات التخزين. من أجل تحقيق الاكتمال، تتم الإشارة أيضا إلى مشكلات الأداء الخاصة بشبكة منطقة التخزين (SAN). تم تصميم بروتوكولات التخزين بمرونة ولا تزال قابلية الدمج بحاجة إلى زيادة. ومع ظهور تقنيات مثل "تعيين الوحدة المنطقية غير المتماثل (ALUA)" و"الإدخال والإخراج متعدد المسارات" (MPIO)، يتم توفير المزيد من المرونة والخيارات للمسؤولين.
وثمة إعتبار آخر هو وضع التخزين. يتطلب تصميم FlexPod إرفاق وحدة التخزين بمحولات Nexus. لا تتوافق وحدة التخزين المتصلة مباشرة مع CVD. يتم دعم التصميمات المزودة بوحدة تخزين متصلة مباشرة، في حالة اتباع أفضل الممارسات. في نفس الوقت، تلك التصاميم ليست FlexPod فقط.
هذا من الناحية الفنية ليس إصدار Cisco، بما أن معظم هذه الخيارات شفافة لأجهزة Cisco. إنها مشكلة شائعة أن تختار وتلتصق بمسار مثالي. يمكن تقديم وحدة نمطية حديثة للجهاز (DSM) مع مسارات متعددة وتحتاج إلى إختيار وحدة (وحدات) مثالية، استنادا إلى معايير معينة لتوفير المرونة وموازنة الحمل. تعرض لقطة الشاشة هذه أربعة مسارات متوفرة ل NetApp DSM ل Microsoft Windows وخيارات موازنة الأحمال.
يجب انتقاء الإعدادات الموصى بها استنادا إلى مناقشة مع مورد التخزين. قد تؤثر هذه الإعدادات على مشاكل الأداء. الاختبار النموذجي الذي قد يطلب منك TAC إجراءه هو إختبار قراءة/كتابة من خلال البنية A أو البنية B فقط. يتيح لك هذا عادة تضييق مشاكل الأداء إلى الحالات التي تمت مناقشتها في قسم "المشاكل العامة" في هذا المستند.
هذه النقطة محددة لمكون الكمبيوتر، بغض النظر عن المورد. من الطرق السهلة لإعداد شبكة تخزين لبرامج مراقبة الأجهزة الافتراضية من وجهة نظر أجهزة الكمبيوتر هي إنشاء مهايئين لناقل المضيف (HBA)، أحدهما لكل قناة ليفية، وتشغيل كل من حركة مرور وحدة LUN للتمهيد وحركة مرور وحدة التخزين الخاصة بالجهاز الظاهري (VM) عبر هاتين الواجهتين. يوصى دائما بتقسيم حركة مرور بيانات LUN الخاصة بالتمهيد وحركة مرور تخزين الأجهزة الافتراضية (VM). وهذا يسمح بأداء أفضل ويسمح بالإضافة إلى ذلك بتقسيم منطقي بين النوعين من حركة المرور. راجع قسم "المشاكل المعروفة" على سبيل المثال.
وكما هو الحال في أي عملية سريعة لاستكشاف الأخطاء وإصلاحها، فمن المهم للغاية أن يتم تقليل حجم المشكلة وطرح الأسئلة الصحيحة.
في واجهة المستند هذه، تتم مناقشة عدادات قوائم انتظار ASIC. توفر العدادات أيضا طريقة عرض في نقطة ما من الوقت، لذلك من المهم مراقبة زيادة العدادات. يتعذر مسح بعض العدادات حسب التصميم. على سبيل المثال، ذكر سابقا مجمع الكرمل الآسيوي.
ولإعطاء مثال على ذلك، قد لا يكون وجود إتفاقية حقوق الطفل أو المرتجع على واجهة مثاليا، ولكن قد يتوقع أن تكون قيمهما غير صفرية. كان من الممكن أن ترتفع العدادات في وقت ما، ربما أثناء الانتقال أو الإعداد الأولي. لذلك من المهم ملاحظة زيادة العدادات ومتى كانت آخر مرة تم مسح العدادات.
بينما من المفيد مراجعة العدادات، فمن المهم معرفة أن مشاكل مستوى بيانات معينة قد لا تجد انعكاسا سهلا للتحكم في عدادات المستوى والأدوات. وكمثال على ذلك، فإن الإيثاناليزر أداة مفيدة جدا متاحة على كل من UCS و Nexus 5000. ومع ذلك، يمكنها التقاط حركة مرور بيانات مستوى التحكم فقط. التقاط حركة المرور هو ما يطلبه غالبا TAC، خاصة عندما لا يكون واضحا أين يكمن الخطأ.
يمكن لالتقاط حركة مرور موثوقة على الأجهزة المضيفة الطرفية أن يلقي الضوء على مشكلة الأداء ويقلل من أدائها بسرعة كبيرة. يقدم كل من Nexus 5000 و UCS فسحة بين دعامتين حركة مرور. وعلى وجه الخصوص، تكون خيارات UCS الخاصة بنطاق مهايئات الناقل المضيف (HBA) الخاصة وجوانب البنية مفيدة. لمعرفة المزيد حول إمكانيات التقاط حركة المرور عند مراقبة جلسة على UCS، راجع المراجع التالية:
يوفر NetApp مجموعة كاملة من الأدوات المساعدة لاستكشاف أخطاء وحدات التحكم في التخزين وإصلاحها، ومن بينها:
هناك بين الأوامر الأكثر شيوعا:
sysstat -x 2
sysstat -M 2
فيما يلي بعض الأشياء التي يجب البحث عنها في إخراج sysstat -x 2 والتي قد تشير إلى صفيفات أو أقراص NetApp محملة بشكل زائد:
يوضح هذا المقال كيفية تكوين NetApp: أفضل ممارسات تخزين إيثرنت ل NetApp .
يوفر ESXi الوصول إلى بروتوكول Secure Shell (SSH)، والذي يمكنك من خلاله أستكشاف الأخطاء وإصلاحها. من بين أكثر الأدوات المفيدة التي يتم توفيرها للمسؤولين eXxTop و Perfmon.
في العديد من الحالات، سيطلب منك مهندس TAC جمع بعض المعلومات الأساسية قبل أن يمكن بدء التحقيق.
connect nxos A|B
show queuing interface | no-more
show interface priority-flow-control | no-more
show interface flowcontrol | no-more.
dmesg | egrep -i 'enic|fnic'
أستخدم زر الملاحظات لتقديم ملاحظات حول هذا المستند أو تجاربك. سنعمل باستمرار على تحديث هذه الوثيقة عند حدوث التطورات وبعد تلقي الملاحظات.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
20-Feb-2015 |
الإصدار الأولي |