از دست رفتن تصادفی PATH های ESXi در ارتباط EMC VPLEX

در هفته اخیر در پروژه نگهداری محیط مجازی دیتاسنتر شاهد خطاها و رخدادهایی بودیم که تا حدی عجیب و مرموز بود. این خطاها بصورت مشکوک در قسمت های مختلفی از قبیل محیط استوریج ، قطع ارتباط ISL بین دوسایت و حتی تاثیرات تصادفی در محیط مجازی را بدنبال داشت. بر آن شدم تا با نگاهی فنی تر و دقیق به بررسی برخی پارامترهایی که محتمل به ریشه مساله و بحران پیش آمده است بپردازم. صرفا بررسی این نکات تجربه ای برای اینجانب و علاقه مندان و متخصصین محیط مجازی است و root cause قطعی مشکل پیش آمده نیست.

یکی از خطاهای پیش آمده قطع شدن ارتباط بین دو استوریج در دو سایت جغرافیایی و افتادن لینک WAN بین دو دستگاه VPLEX بود که بالطبع تاثیر در ارتباطات هاست های فیزیکی با دستگاه VPLEX داشت، اما نکته عجیب این بود که هاست های فیزیکی بصورت تصادفی با لان های توزیع شده(مترو) در سطح VPLEX قطع ارتباط می کردند. بعبارت ساده تر، مثلا یک هاست چند لان توزیع شده را با موفقیت مشاهده و به داده های آن دسترسی داشت ولی در ارتباط لان دیگری از همان نوع دچار مشکل بود که وضعیت path های ارتباطی نیز به حالت inactive نمایش داده می شد. جهت بررسی این موضوع در چند مقاله به برخی مطالب مفید و دست یافته های مرتبط خواهم پرداخت:

هنگامی که سرورهای فیزیکی ESXi5 بصورت تصادفی path های خود روی یک محیط EMC VPEX از دست می دهند ، این ارتباط می تواند روی آرایه های HP EVA یا EMC VMAX/VNX که در پشت VPLEX قرار گرفته اند نیز رخ دهد. ریشه خطا برای از دست رفتن path می تواند حجم بار I/O ایجاد شده روی آرایه backend باشد، مخصوصا روی HP EVA. اما راه حل؛ کاهش بار IO و پخش کردن این ترافیک روی بازه زمانی است. اجازه بدهید ببینیم این داستان چگونه آشکار شد:

سرورهای ESXi که در جلوی EMC VPLEX و بعنوان forntend هستند، یک path failure را بعلت دستورات SCSI که زمان شان خاتمه یافته است تجربه می کنند. این دستورات SCSI بواسطه عملیات خواندن/نوشتن ۱۰ بایتی به مکانیزم heartbeat در سطح لان صف ارایی می شوندTEST_UNIT_READY. در این مثال ، ما میتوانیم لان ۱ یا VPEX_HP1 را که برای مدت کمتر از یک ثانیه ناپدید شده است ببینیم. اینجا یک مثال از timeout یک دستور اسکازی است که به path failure خاتمه یافته است. این پیام ها می تواند از فایل var/log/vbod.log بیرون کشیده شود.

 

۲۰۱۲-۰۵-۲۲T07:02:04.680Z: [scsiCorrelator] 1680920122975us: [vob.scsi.scsipath.pathstate.dead] scsiPath vmhba2:C0:T1:L1 changed state from on

۲۰۱۲-۰۵-۲۲T07:02:04.681Z: [scsiCorrelator] 1680923124828us: [esx.problem.storage.redundancy.degraded] Path redundancy to storage device naa.6000144000000010a00f545a97c5704a degraded. Path vmhba2:C0:T1:L1 is down. Affected datastores: “Vplex_HP1”.

۲۰۱۲-۰۵-۲۲T07:02:04.775Z: [scsiCorrelator] 1680920217911us: [vob.scsi.scsipath.pathstate.on] scsiPath vmhba2:C0:T1:L1 changed state from dead

۲۰۱۲-۰۵-۲۲T07:02:04.776Z: [scsiCorrelator] 1680923219503us: [esx.clear.storage.redundancy.restored] Path redundancy to storage device naa.6000144000000010a00f545a97c5704a (Datastores: “Vplex_HP1”) restored. Path vmhba2:C0:T1:L1 is active again.

پیام بالا می تواند شبیه به چیزی باشد که در vCenter مشاهده می شود. این تمام چیزی است که از فایل vmkernel.log می تواند قابل بررسی باشد.

The above messages would be similar to what is observed in vCenter. Here are the entries from the vmkernel log. Note that extended Qlogic driver logging was enabled:

۲۰۱۲-۰۵-۲۲T07:02:04.680Z cpu12:4628)scsi(8:0:1:1): TIMEOUT status detected 0x6-0x0

۲۰۱۲-۰۵-۲۲T07:02:04.680Z cpu7:2200)PowerPath: EmcpEsxLogEvent:1252: Info:emcp:MpxEsxTestAndUpdatePathState: Path “vmhba2:C0:T1:L1” is changing to dead from on.

در اینجا ما یک زمان command timeout داریم TEST_UNIT_READY or SCSI command 0x0

حتی اگر نتوانیم تایید کنیم که دقیقا چه دستوری fail شده است، ولی می توانیم به dead شدن بلافاصله path اشاره کرده و از این وضعیت استنتاج داشته باشیم. اگر هر دستور دیگری fail شود، می توانیم خطاهای NMP را مشاهده و سپس یک TEST_UNITY_READY به بیرون بفرستیم تا اطمینان حاصل کنیم که path هنوز سالم و قابل استفاده است. از انجا که این شرایط نبود، ما باید درنظر بگیریم که این دستور به عنوان مسیر دیسک به بیرون ارسال شده است. کد PathEval که بصورت پیش فرض هر ۳۰۰ ثانیه اجرا می شود. محیط ESXi دیگری که به Backend همان آرایه ذخیره سازی HP متصل شده است، هرچند این هاست ها برای گرفتن لان های HP EVA به VPLEX متصل نشده اند. در طی بازه زمانی یکسان ما شاهد دستورات failure بسیاری هستیم که این بعلت وضعیت QUEUE FULL یک دستگاه اسکازی است، که این به معنای ان است که آرایه ذخیره سازی نمی تواند IO ایجاد شده را تحمل و نگهداری کند.

۰۱۲-۰۵-۲۲T07:02:02.087Z cpu10:2058)ScsiDeviceIO: 2309: Cmd(0x4124403d5ac0) 0x2a, CmdSN 0x800e0011 from world 1829086 to dev “naa.6001438005ded7fb0000500009510000” failed H:0x0 D:0x28 P:0x0 Possible sense data: 0x0 0x0 0x0.

۲۰۱۲-۰۵-۲۲T07:02:02.087Z cpu10:2058)ScsiDeviceIO: 2309: Cmd(0x4124414d9d40) 0x2a, CmdSN 0x800e007a from world 1829086 to dev “naa.6001438005ded7fb0000500009510000” failed H:0x0 D:0x28 P:0x0 Possible sense data: 0x0 0x0 0x0.

۲۰۱۲-۰۵-۲۲T07:02:04.755Z cpu12:2060)ScsiDeviceIO: 2309: Cmd(0x41244120a8c0) 0x2a, CmdSN 0x800e006e from world 1829086 to dev “naa.6001438005ded7fb00005000096c0000” failed H:0x0 D:0x28 P:0x0 Possible sense data: 0x0 0x0 0x0.

شرایط Queue full توسط یک دستگاه با D:0x28 نمایش داده می شود که به یک task_set_full ترجمه می شود. حتی اگر این آرایه ذخیره سازی نتواند لود و حجم بار ایجاد شده را تحمل کند، هیچ path failure روی هاست های ESXi مشاهده نمی شد، و این اساسا بخاطر این است که هاست های فیزیکی از شرایط QFull آگاه هستند و می دانند که این شرایط بصورت زودگذر و موقتی است، بنابراین درک می کند که path ها واقعا dead نیستند. هاست های فیزیکی که در سمت front یک VPLEX هستند، هرگز وضعیت این دستگاه اسکازی را نمی بینند زیرا دستگاه VPLEX این دستورات را به هاست ها برنمی گرداند. در عوض VPLEX تلاش می کند تا ۱۶ ثانیه قبل از اینکه دستور را رها کند فرمان دهد. هاست های ESXi یک زمان ۵ ثانیه ای برای timeout دستورات اسکازی دارند. بنابراین هاستها دستور را رها خواهند کرد و یک فرمان abort برای ان دستگاه ارسال می کنند که این پیش از آن است که VPLEX تلاش برای فرمان دادن را منصرف شود. این علتی است که VPLEX دستورات abort بسیاری از سمت هاست های ESXi ببیند. VPLEX یک شمارنده برای تایید اینکه وضعیت QFull را از آرایه HP دریافت کرده دارد. هنگام بازنگری این شمارنده ما متوجه وضعیت QFULL که از آرایه HP EVA به VPLEX برگشت داده شده است می شویم.

هاست های ESXi در قسمت front VPLEX مسیرها و path ها را بعنوان dead علامتگذاری می کنند و این بخاطر دستورات بسیاری است که timeout شده اند. خصوصا دستورات TEST_UNIT_READY . اگر وضعیت QFULL توسط VPLEX به هاست های فیزیکی برگردانده شده باشد، هیچ مسیری بعنوان dead نشانگذاری نمی شود زیرا دستورات fail شدند و این بخاطر شرایط و وضعیت ناپایدار و گذرا است. در پایان، مقدار لود و حجم بار روی آرایه HP EVA نیاز به توزیع شدن و پخش در بازه زمانی است .بنابراین شرایط QFULL رخ نمی دهد. کدی برای ESXi معرفی شده است که بصورت خودکار عمق صف لانها برای برگرداندن یک وضعیت QFULL را کاهش می دهد.smile icon

4 دیدگاه
  1. mali_Zamani19 says

    like

  2. ketan says

    فوقوالاده بود.سپاس

  3. mrezayi23 says

    با سلام
    نکته : یکی ازدلایلی که در طراحی VPLEX چه بصوتر Local و چه Metro از Power Path بهعنوان Front End Path Management Framework استفاده می شود ایراداتی است که در NMP و یا دیگر نرم افزارهای Path Management که بصورت Builtin و یا 3rd party وجود دارد و در این case study نیز این بوضوح قابل مساهده می باشد . همچنین فقدان یک نرم افزار Monitoring and Reporting مانند Wathc4netنیز در اینجا بسیار مشهود است و شاید بهتر باشد برای پروژه مذکور نیز هر چه سریعتر خداقل Power path تهیه شود

  4. mrezayi23 says

    در همین ارتباط شاید لینک زیر نیز کمک کننده باشد
    http://blogs.vmware.com/kb/2012/05/esx-randomly-losing-paths-in-emc-vplex.html

دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.