قابلیت جدید VMCP جهت تشخیص شرایط APD/PDL

یکی از بهبودهای جدید ارائه شده در High Availability، معرفی قابلیت پیشرفته ای تحت عنوان VMCP در نسخه vSphere 6.0 می باشد. این قابلیت بعنوان مکانیزمی جدید برای شناسایی مشکلات مربوط به عدم دسترسی به هاستها در سطح HA معرفی شده است تا نقاط ضعف HA را پوشش دهد.  این بهبود که شاید بتوان آنرا بزرگترین قابلیت اضافه شده به vSphere HA نامید تحت عنوان VM component protection (VMCP) در نسخه جدید vSphere 6.0 شناخته می شود. VMCP وظیفه محافظت از ماشین های مجازی در مقابل مشکلات و رخدادهای استوریجی و قطعی ارتباط هاست ها با SAN را دارد خصوصا شرایط APD و PDL که در ادامه به آنها خواهم پرداخت.

پیش از شروع، فرآیند برقراری ارتباط یک هاست با ذخیره ساز SAN بدین صورت است که ابتدا دستوراتی با نام SCSI sense code که یک رشته هگزا دسیمال می باشد بین هاست و SAN رد و بدل می شود که در این ارتباط هر دو قادر به فهم و درک دستورات متقابل هستند. در نظر بگیرید وقتی یک LUN جدید به هاستی پرزنت می شود، کدهای SCSI sense رد و بدل می شود تا هاست این تغییر را شناسایی کند. ساختار این کد بصورت رشته هگزادسیمال (H:0x0 D:0x2 P:0x0 and 0x5 0x25 0x) است که در فایل لاگ کرنل ثبت می گردد. از ترکیب رشته فوق می توان بر اساس یک محاسبه گر ساده به پیام خطاهای مختلفی پی برد. در واقع می توان این رشته را آنالیز و به موفق یا ناموفق بودن SCSI command ها پی برد.

(PDL ( Permanent Device Lost: این شرایط زمانی رخ می دهد که دسترسی به یک لان از بین برود. برای مثال یک LUN بر روی ذخیره ساز SAN تان ایجاد و به هاستهای شما پرزنت بوده است. حال به دلایلی LUN یا Device موردنظر دیگر قابل دسترس نخواهد بود. در این حالت آرایه ذخیره ساز کدی را تحت عنوان SCSI sense code صادر می کند و آنرا برای هاست ارسال می کند تا نشان دهد که دستگاه در دسترس نیست و هاست را از تلاش برای بازگرداندن آن LUN منصرف نماید.  یک مثال خوب، LUN است که به هر دلیلی خراب شده یا حتی ادمین سهوا WWN را از پیکربندی زونینگ پاک کرده است. در وضعیت PDL، ذخیره ساز SAN با هاست ارتباط برقرار کرده و کدهای SCSI sense code را برای نشان دادن وضعیت دستگاه به هاست می فرستد. به محض شناسایی وضعیت PDL، هاست عملیات ارسال درخواست های I/O به SAN را متوقف می نماید زیرا دستگاه را بصورت همیشگی غیرقابل دسترس در نظر می گیرد. 

(APD ( All Path Down : این شرایط زمانی رخ می دهد که هاست نمی تواند به دستگاه ذخیره ساز SAN دسترسی پیدا کند و در واقع هیچ SCSI code از سمت SAN به هاست ارسال نمی شود، از این رو هاست همچنان تمام تلاش خود را برای برقراری ارتباط دوباره با SAN ادامه می دهد و این شرایط را به عنوان وضعیت APD برای خود در نظر می گیرد. این وضعیت کمی با حالت PDL متفاوت است، چونکه در این شرایط هاست اطلاعات کافی در مورد از دست رفتن موقت یا دائم SAN را ندارد و در این وضعیت دستگاه SAN ممکن است اطلاعاتی را برگرداند و یا شاید هم خیر! در شرایط APD، هاست همچنان فرآیند ارسال دستورات I/O را برای SAN ادامه می دهد و تا زمان پایان یافتن APD timeout این کار ادامه خواهد یافت. بعد از خاتمه APD timeout، هاست هیچ I/O را برای ذخیره ساز SAN ارسال نمی کند که این مورد مستثنی از I/O داخل ماشین های مجازی می باشد و VM I/O بطور نامحدود برای استوریج ارسال خواهد شد. ضمنا بصورت پیش فرض، مقدار ۱۴۰ ثانیه برای APD timeout درنظر گرفته شده است که می توان مقدار آنرا برای هر هاست از طریق پارامتر Misc.APDTimeout  در تنظیمات Advanced settings ویرایش کنید.

  • فعال سازی VMCP:

با امکان vSphere HA در نسخه ۶ می توان شرایط APD و PDL را شناسایی و بر اساس تنظیمات و پیکربندی انجام شده به مشکلات و رخدادها پاسخ داد. برای اینکار لازم است ابتدا VMCP را در سطح تنظیمات HA Cluster فعال نمایید. این تنظیمات هستند که به سادگی به HA agent اطلاع می دهند که چگونه از ماشین های مجازی در رویدادهای APD/PDL محافظت نماید. بر اساس تصویر زیر می توانید با تنظیمات اولیه آن اشنا شوید.

 

  • در ادامه می توانید روشی که می خواهید تا  HA به رخدادهای APD/PDL پاسخ دهد را تعیین کنید. هر نوع از این رویدادها بصورت کاملا مستقل پیکربندی می شوند.

در زمانی که شرایط PDL صورت می گیرد می توان سه حالت کلی را بعنوان عکس العمل و نحوه پاسخگویی HA تنظیم و پیکربندی کرد. با توجه به اینکه مقدار PDL همیشه صفر یا یک است، لذا می توان این سیاست را به سادگی پیکربندی کنید.

  • Disabled :  در شرایط تشخیص PDL هیچ اتفاقی نیافتد.
  • Issue events : هیچ عکس العمل و واکنشی بر روی ماشین های مجازی متاثر شده صورت نگیرد و صرفا ادمین از بروز این رخداد آگاه شود
  • Power off and restart VMs : در شرایط شناسایی و بروز PDL، ماشین های مجازی متاثر شده بر روی هاست خاموش و توسط HA بر روی سرور دیگری که ارتباطات صحیح با SAN دارد راه اندازی مجدد شود.

به همین صورت می توانیم تنظیمات و پیکربندی لازم برای زمانی که APD صورت می گیرد را مشخص کرد. برای اینکار گزینه های بیشتری برای عکس العمل های HA وجود دارد زیرا وضعیت دستگاه ذخیره ساز شناسایی نشده و و یا حتی ممکن است SAN بصورت موقت غیرقابل دستیابی باشد.

  • Disabled :  در صورت بروز APD هیچ اتفاقی صورت نگیرد.
  • Issue events : هیچ عکس العمل و واکنشی بر روی ماشین های مجازی متاثر شده صورت نگیرد و صرفا ادمین از بروز این رخداد آگاه شود
  • (Power off and restart VMs (conservative : در این مدل ماشین های مجازی مشکل دار و متاثر شده توسط HA ریستارت خواهد شد مگر آنکه HA نتواند هاست سالمی را برای راه اندازی این ماشین مجازی در سطح کلاستر شناسایی و یافت نماید. بهتر است بدانید که هاست متاثر شده از APD هاست مستر (HA master ) ارتباط برقرار می کند تا تعیین کند که آیا فضای لازم برای راه اندازی ماشین های آنرا دارد یا خیر. در صورتیکه جواب مثبت باشد، ماشین های مجازی بر روی هاست خراب خاموش و بر روی هاستهای دیگر در سطح کلاستر راه اندازی مجدد خواهند شد. ضمنا اگر هاستی که APD را تجربه کرده است نتواند با HA master ارتباط برقرار کند، هیچ اتفاقی صورت نخواهد گرفت.
  • (Power off and restart VMs (aggressive :در این حالت هاست بدون در نظر گرفتن شرایط کلاستر و اطمینان از وجود منابع کافی، اقدام به متوقف کردن ماشین های مجازی روی هاست خراب می نماید بدون آنکه تعیین کند آیا سایر هاست ها توان راه اندازی و روشن کردن این VM ها را دارند یا خیر. اگر در شرایط فوق، هاست مستر HA master غیرقابل دستیابی باشد، ماشین های مجازی بر روی سرورهای دیگر روشن می شوند حال آنکه امکان تامین منابع باشد یا خیر. در این حالت در نظر داشته باشید چنانچه منابع کافی وجود نداشته باشد، امکان بازگرداندن تمام ماشین های متاثر شده توسط HA امکانپذیر نخواهد بود. این حالت برای زمانی سودمند خواهد بود که بنا به مشکلات شبکه ای، سناریو partitioning در مجازی سازی رخ می دهد و هاستی قادر به دیدن HA master در سطح کلاستر نباشید.
  • Delay for VM failover for APD: هنگامی که APD timeout که بصورت پیش فرض ۱۴۰ ثانیه می باشد خاتمه یابد، آنگاه VMCP یک زمان اضافه تری را صبر می نماید. هاست متاثر شده از APD می بایست جهت تعیین سیاست برخورد با ماشین های مجازی این زمان را فراتر از ۱۴۰ ثانیه پیش فرض سپری نماید. برای مثال اگر این مقدار را ۳ دقیقه تنظیم نمایید، VMCP مجموعا مدت ۵:۲۰ انتظار کشیده و پس از خاتمه این زمان اقدام لازم بر روی ماشین های مجازی را شروع می نماید. به مجموعه زمان APD timeout و تاخیر بعد از آن VMCP timeout می گویند

Response for APD recovery after APD timeout :  این مقدار برای زمانی مفید خواهد بود که ۱۴۰ ثانیه پیش فرض ADP timeout خاتمه یافته است و شما در زمان تاخیر دوم بوده اید و به هر دلیلی مشکل ذخیره ساز SAN رفع شده و ارتباطات بین هاست با SAN مرتفع شده است. در این حالت می توانید تنظیمات زیر را داشته باشید:

  • Disabled :  هیچ اتفاقی صورت نمی گیرد.
  • Reset VMs : ماشین های مجازی خراب شده روی همین سرور راه اندازی مجدد خواهند شد. این گزینه فعال است چونکه بعضی برنامه ها یا سیستم عاملها ممکن است پس از Fail شدن ارتباطاتشان با استوریج و ذخیره ساز ها برای یک زمان طولانی در وضعیت ناپایدار و idle قرار بگیرد. این گزینه به HA کمک خواهد کرد تا بتواند شرایط آنها را بهتر مدیریت نماید

در تصویر زیر میتوانید روال زمانبندی بازیابی VMCP را مرور نمایید

T=0s: A storage failure is detected. VMCP will start the recovery workflow.
T=0s: For a PDL event, the recovery process immediately starts. VMs will be restarted on healthy hosts in the cluster.
T=0s: For an APD condition, the APD Timeout timer starts.
T=140s: The host declares an APD Timeout and will begin to fast fail non-virtual machine I/O to the unresponsive storage device. By default, this is 140 seconds.
T=320s: The VMCP Timeout.  This is ۳ minutes after the APD Timeout has been reached. vSphere HA will start the APD recovery response.
T=140s-T=320s: The period after an APD Timeout, but before the VMCP Timeout. VMs may become unstable after losing access to storage for an extended period of time. If an APD is cleared in this time period, the option to reset the VMs is available.

منابع ۱ و ۲ و ۳

برچسب خورده : , , , , , , , , , . Bookmark the پیوند یکتا.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *