یکی از قابلیت های منحصر به فرد، فوق العاده و بسیار پراستفاده در مجازی سازی ، قابلیت در دسترس بودن بالا یا همان High Availability است که در زیرساخت VMware vSphere به اختصار به آن HA گفته میشود .این ویژگی از دلایلِ مهم گرایش به سمت زیرساخت های مجازی است.
همانگونه که از نام این قابلیت پیداست، با استفاده از HA میتوان به طرز چشمگیری در دسترس بودنِ ماشین های مجازی و در پیِ آن در دسترس بودنِ سرویسها را بالاتر برد.
در این نوشته به شکل کامل ، بررسی میکنیم که High Availability چیست؟
مقابله با خرابی های ماشین مجازی با High Availability
قابلیت High Availability یا HA میتواند در مقابل انواع خرابی یا Failure ها از ماشین های مجازی تا حدود بسیار زیادی محافظت کند که لیست این خرابی ها به ترتیب زیر است:
- از دست رفتن یک یا چند سرور فیزیکی که در حال حاضر میزبان ماشین های مجازی هستند
- کرش کردن سیستم عامل یک ماشین مجازی
- کرش کردن یا خرابی یک سرویس خاص مربوط به یک اپلیکیشن خاص
- ایجاد اشکالات در سمت ذخیره ساز (Storage)
- خرابی سخت افزاری بخشی از قطعات یک سرور فیزیکی که میزبان ماشین های مجازی است
همانطور که می بینید، استفاده از HA میتواند به طرز چشمگیری، ضامن بالا بودن یا در دسترس بودن سرویس های ما باشد. ما در ادامه به توضیح مختصری در مورد هر یک از موارد فوق خواهیم پرداخت تا ببینیم که HA چگونه به ما در افزایش دسترسی به سرویس ها کمک خواهد نمود.
پیش نیازهای استفاده از قابلیت HA:
- vCenter
- Shared Storage between Hosts for some type of failures
- Minimum of 2 Hosts
- Cluster
- Required license
از دست رفتن یک یا چند سرور فیزیکی که در حال حاضر میزبان ماشین های مجازی هستند
سناریو:
محیطی را در نظر بگیرید که در حال حاضر 3 عدد سرور فیزیکی در حال میزبانیِ تعداد مشخصی ماشین مجازی هستند که این VMها روی همه آنها پخش شده اند.
تمامی سرورها در این سناریو به یک استوریج مرکزی یا shared storage متصل هستند و دیسک ها و بقیه فایل های مربوط به VM روی آنها نگهداری میشوند.
خرابی:
اگر در این محیط یکی از سرورهای فیزیکی به دلیل قطعی برق یا کرش کردن سیستم عامل hypervisor و یا خرابی قطعه ای مانند cpu که منجر به از دست رفتن سرور فیزیکی میشود، دچار خرابی شود، قابلیت HA میتواند با تکیه بر این موضوع که در حال حاضر بقیه هاست ها یا سرورهای فیزیکی موجود به فایل های ماشین مجازی دسترسی دارند، این ماشین ها را پس از یکبار ریستارت کردن، بر روی آن سرورها روشن کند.
کرش کردن سیستم عامل یک ماشین مجازی
با فعال کردن قابلیت VM monitoring در قابلیت High Availability میتوان با کمک ابزار VMware toolsی که در داخل هر سیستم عامل نصب شده است، از اوضاع داخل آن VM اطلاعاتی در زمینه سلامت آن به دست آورد.
اگر سیستم عامل ماشینی به هر دلیلی کرش کرده باشد و در بازه زمانی تعیین شده، vmware tools اطلاعاتی از وضعیت VM در اختیار هایپروایزر قرار ندهد و همچنین در 120 ثانیه گذشته ورود و خروج اطلاعاتی روی دیسک یا کارت شبکه از سمت این ماشین صورت نگرفته باشد، آن ماشین ریستارت خواهد شد. لازم به ذکر است قبل از ریستارت شدن ماشین توسط HA یک اسکرین شات از آن تهیه خواهد شد که در فولدر VM میتوان آنرا یافت و آخرین وضعیت ماشین قبل از ریستارت شدن را مشاهده کرد.
کرش کردن یا خرابی یک سرویس خاص مربوط به یک اپلیکیشن خاص
جالب است بدانیم HA حتی میتواند بر روی سرویس های داخل سیستم عامل هم مونیتورینگ داشته باشد، البته ایجاد این قابلیت نیاز به نصب یک SDK برای آن اپلیکیشن خاص دارد، و باید این قابلیت توسط اپلیکیشن ساپورت شود. با استفاده از این SDK همانند روش قبلی از سمت اپلیکیشن heartbit هایی مبنی بر عملکرد صحیح آن به سمت هایپروایزر ارسال خواهد شد که مجددا اگر این هارت بیت ها ( ضربان) در فواصل معینی دریافت نگردد، آن VM ریستارت خواهد شد.
ایجاد اشکالات در سمت استوریج یا ذخیره ساز
این قابلیت که آنرا با نام VMCP یا VM component protection می شناسیم، یکی از امکانات فوق العاده HA است که میتواند از ماشین های مجازی در مقابل اشکالاتی که برای یک هاست در ارتباط با استوریج پیش می آید محافظت نماید. از جمله این خرابی ها مینوان به پر شدن پهنای باند بین هاست و استوریج و یا unpresent شدن یک لان مشترک از یک هاست خاص که بیشتر به دلیل خطای انسانیست، اشاره کرد.
شکل قبلی را مجددا اینجا استفاده میکنیم:
در این شکل فضای آبی رنگ که نمایانگر یک LUN است برای همه هاست های موجود در دسترس می باشد. به عملیات ارائه این فضا به هاست ها، present کردن یا Mask کردن یک LUN میگویند. فایل های مربوط به هر ماشین بر روی این فضا قرار میگیرند.
در صورتی که این فضا به هر یک از دلایلی که در بالا ذکر شد برای یکی از هاست ها قابل دسترسی نباشد، بقیه هاست ها همچنان به آن دسترسی دارند و High Availability توانایی تشخیص این نوع خرابی یا failure را دارد و میتواند در مواجهه با آن، VM را ریستارت نموده و بر روی هاست های دیگر موجود روشن نماید.
خرابی سخت افزاری بخشی از قطعات یک سرور فیزیکی که میزبان ماشین های مجازی است
این مورد که از آن با عنوان Proactive HA نیز یاد می شود، میتواند با استفاده از نرم افزارهای واسطی که روی هاست ها نصب میشود، اطلاعات کاملی را از سخت افزار آن هاست در اختیار HA قرار دهد. در صورتی که به هر دلیلی برای یکی از قطعات حیاتی آن سرور مشکلی به وجود بیاید که وضعیت آن هاست را degraded بکند، VM های آن هاست، برای پیشگیری از مشکلات احتمالی بعدی به صورت live با استفاده از قابلیت migration یا vmotion به دیگر هاست ها منتقل خواهند شد.
لازم است بدانیم که در وضعیت degraded، هاست به صورت کامل از دست نرفته است، بلکه بخشی از آن دچار مشکل شده است که SPOF یا single point of failure ایجاد کرده است. برای مثال از دست رفتن یک power module از هاستی که تنها دارای دو عدد پاور است، میتواند این وضعیت را ایجاد کند.
مواردی که در بالا ذکر شد، کاربردهای قابلیت HA یا High availability بود که با اینکه برای فعال کردن آن نیاز به vcenter می باشد، اما عملکردهای آن به هیچ وجه وابسته به وی سنتر نیست و کاملا مستقل می باشد.
تنظیمات vSphere HA در vCenter
در ادامه نگاهی خواهیم داشت به تنظیمات مربوط به vSphere HA در داخل vCenter.
همانطور که گفته شد برای فعال کردن vSphere HA نیاز به Host Cluster داریم؛ برای انجام تنظیمات vSphere HA روی Cluster کلیک کرده به بخش Configure -> Service -> vSphere Availability رفته و گزینه Edit را انتخاب کنید.
همچنین در این بخش می توانید خلاصه ای از تنظیمات مربوط به vSphere HA را مشاهده کنید.
همانطور که در تصویر زیر مشاهده می کنید تنظیمات مربوط به vSphere Availability در 4 بخش اصلی تقسیم بندی شده است که عبارتند از:
Failure and Response
Admission Control
Heartbeat Datastore
Advanced Options
پیش از هر چیز لازم است که vSphere HA را فعال کنید. برای این منظور دکمه مربوط به vSphere HA را روشن کنید.
با این کار تنظیمات مربوط به vSphere HA از حالت Gray out خارج شده و می توانید تنظیمات مورد نظر خود را اعمال کنید.
گزینه Enable Host Monitoring به صورت پیش فرض فعال است، و به این معنی است که قابلیت vSphere HA، در حال مانیتور کردن سرورهای فیزیکی است و در صورت خرابی اقدام لازم را انجام خواهد داد. اما گاهی اوقات میخواهیم عامدانه در ساختار شبکه تغییراتی انجام دهیم که این کار ممکن است باعث بروز شرایط Isolation یا Partition شود؛ و میدانیم که تغییرات ما مشکلی برای VMها ایجاد نخواهد کرد و نیازی نیست vSphere HA در این شرایط کاری انجام دهد! برای این منظور موقتا گزینه Enable Host Monitoring را خاموش میکنیم؛ توجه داشته باشید که این کار تاثیری در رفتار HA برای VM Monitoring نخواهد داشت.
همچنین در این قسمت باید مشخص کنید که vSphere HA در هر کدام از شرایط زیر چه عکس العملی داشته باشد:
Host Failure Response
به احتمال بسیار زیاد در زمانی خرابی یک سرور فیزیکی می خواهید بر اساس یک Priority مشخص، ماشین های روی سرور Failed شده، روی سایر سرورهای کلاستر Restart شوند. ممکن است بخواهید vSphere HA در چنین شرایطی عکس العمل خاصی انجام ندهد که در این صورت Disabled را انتخاب خواهید کرد (معادل غیر فعال سازی Host Monitoring).
Response for Host Isolation
وضعیت Host Isolation شرایطی است که یک یا چند سرور Slave نه تنها ارتباط خود با Master را از دست میدهند (Heartbeat دریافت نمیکند)، بلکه نمیتواند Default Gateway خودشان را نیز Ping کند؛ اما هنوز سرور روشن است! در این وضعیت سعی میکنند از طریق Heartbeat Datastore به Master اطلاع دهند که در شرایط Isolate هستند. برای این منظور از فایلی با نام host-<ID>-poweron در Datastore استفاده میکند. در خط اول این فایل 0 یا 1 قرار دارد. 0 یعنی Not Isolated و 1 به معنی Isolated است؛ خط دوم به بعد این فایل شامل لیست ماشین های مجازی روشن روی آن سرور است. فایل host-<ID>-poweron وقتی HA فعال میشود، به وجود میآید و هدف اصلی آن پیگیری وضعیت ماشینهای روشن هر کدام از سرورها ست. یکی از اهداف جانبی این فایل اطلاع رسانی شرایط Network Isolate به Masterاست. این فایلهای در یک شاخه Hidden در مسیر .vSphere-HA/<FDM cluster ID> قرار دارد.
در نهایت وقتی Master متوجه شرایط Isolate شدن سرور شد، باید عکس العمل مناسب را انجام دهد که شامل یکی از موارد زیر خواهد بود:
Disabled
Power off and restart VMs
Shut down and restart VMs
توجه داشته باشید که اگر بخواهیم vSphere HA به بهترین شکل ممکن عمل نموده و هیچ حالت False Positive ای در آن رخ ندهد، لازم است که اصل Redundancy را به درستی رعایت کنیم. Redundancy در سطح Network و در سطح Heartbeat Datastore و…؛ تمام موارد را مد نظر قرار دهیم! در واقع باید Design درستی داشته باشیم.
Virtual machine component protection (vmcp)
از vSphere 6 به بعد بود که بهینه سازی های عمده به vSphere افزوده شد؛ از جمله افزودن Virtual Machine Component Protection (VMCP) به vSphere HA. پیش از اضافه شدن این قابلیت، تمرکز اصلی vSphere HA روی Failed شدن کامل Host و قطع شدن شبکه Management بود. با وجود اینکه قابلیت بسیار کاربردی بود، اما پاسخگوی تمام سناریوهای خرابی نبود.
شرایطی را فرض کنید که یک هاست روشن است و شبکه Management و Heartbeat Datastoreها کاملاً Up هستند؛ اما اتصال هاست به تعدادی از Datastoreها (Storage Devices ها) قطع شده است و تعدادی از VMهای روشن روی آن هاست دچار مشکل شدهاند؛ مثلاً کابل ارتباطی یکی از HABها قطع شده است! تا قبل از قابلیت VMCP، این مشکل قابل تشخیص توسط HA نبود. در واقع VMCP، ماشینهای مجازی را در برابر رخدادهای خرابی مرتبط با Storage محافظت میکند. شرکت VMware این رخدادها را به دو حالت تقسیم بندی کرده است:
Permanent Device Loss (PDL)
PDL یا به عبارتی Permanent Device Loss زمانی اتفاق میافتد که Storage Array یک پیام SCSI برای سرور ارسال کرده و اعلام میکند که یکی از LUNها، دیگر در دسترس نخواهد بود. به عنوان مثال، شرایطی را در نظر بگیرید که Storage Admin با تغییراتی که در سمت Storage و در بخش LUN Masking انجام میدهد، باعث این اتفاق میشود. اما هنوز ارتباط Storage Array با Host برقرار است. در چنین شرایطی هاست ارسال I/O برای آن Device را متوقف خواهد کرد. شرایط و اوضاع در PDL بسیار واضح و مشخص است.
All Paths Down (APD)
اگر به هر دلیلی Host نتواند با Storage Device ارتباط برقرار کند، و از طرفی کد PDL SCSI هم دریافت نکرده باشد، در این شرایط Storage Device در وضعیت APD یا اصطلاحاً All Path Down قرار خواهد گرفت. وضعیت APD از PDL کمی حساس تر است، چرا که هاست اطلاعات کافی از وضعیت Storage Device ندارد؛ ممکن است شرایط خرابی اصلاح شود! به عنوان مثال فرض کنید که کابل اتصال HBA قطع شده است! در این شرایط Host همچنان به ارسال I/O به سمت Device ادامه میدهد تا مدت زمان مشخصی که به آن APD Timeout گفته میشود. به صورت پیش APD Timeout در محیط vSphere برابر 140 ثانیه می باشد، با این حال می توانید از طریق Advanced Option و جستجو عبارت Misc.APDTimeout، این زمان را تغییر دهید.
کافی است تعیین کنیم vSphere HA با دو حالت خرابی PDL و APD چگونه برخورد کند تا از VMها به درستی محافظت شده و پارامتر Availability را افزایش دهد.
در PDL شرایط ساده و واضح است؛ چون میدانیم و آگاه هستیم که چه اتفاقی رخ داده است. سه انتخاب پیش روی ما خواهد بود:
Disabled؛ در این حالت vSphere HA هیچ عکس العملی نخواهد داشت.
Issue events؛ با وجود اینکه کاری برای محافظت انجام نمیدهد؛ اما این مزیت را دارد که Admin را متوجه خرابی میکند.
Power off and restart VMs؛ در این حالت vSphere HA، ماشین یا ماشین هایی که در اثر PDL از دسترس خارج شده و دچار مشکل شده را روی سروری که با Datastore مربوطه در ارتباط است ریست می کند.
در APD به دلیل شرایط خاص و چون وضعیت نا معلوم بوده و امکان دارد خرابی موقتی باشد، توجه و ملاحظات بیشتری مورد نیاز است.
Disabled؛ در این حالت vSphere HA هیچ عکس العملی نخواهد داشت.
Issue events؛ با وجود اینکه کاری برای محافظت انجام نمیدهد؛ اما این مزیت را دارد که Admin را متوجه خرابی میکند.
Power off and restart VMs – Conservative restart policy؛ ماشینهایی که در شرایط APD تحت آسیب قرارگرفته اند را Power off و reset نمیکند مگر اینکه مطمئن شود داخل کلاستر، هاست دیگری وجود دارد که ارتباط آن با Storage Device مربوطه برقرار است. Host ای که دچار وضعیت APD شده با Master ارتباط برقرار میکند و پس از اطمینان از وجود منابع کافی، ماشینهایی که دچار وضعیت APD شدهاند را Terminate کرده تا بتوانند روی هاست های سالم ریست شوند. اگر هم نتواند با Master ارتباط برقرار کند کاری انجام نمیدهد.
Power off and restart VMs – Aggressive restart policy؛ در این شرایط vSphere HA ماشینهای تحت تاثیر قرار گرفته را Terminate خواهد کرد، حتی اگر نتواند تشخیص دهد که هاست دیگری وجود دارد که میتواند VM را روی آن ریست کند. سروری که وضعیت APD برای آن ایجاد شده است تلاش میکند با Master ارتباط برقرار کند تا مطمئن شود منابع کافی وجود دارد، اگر هم نتواند ارتباط برقرار کند باز هم ریست می کند (چون ممکن است مشکل حل شود) و ماشینهای مجازی تحت تاثیر قرار گرفته را Terminate میکند تا بتوانند روی هاست های سالم روشن شوند.
به محض اینکه APD Timeout (140 ثانیه) تمام شود، VMCP مدت زمان دیگری صبر میکند تا بعد Action تعیین شده را روی Affected VMs انجام دهد. این مقدار پیش فرض 3 دقیقه است (Response Delay). در واقع VMCP به مدت 5 دقیقه و 20 ثانیه صبر میکند به امید احیا وضعیت، سپس Action تعیین شده ما را انجام میدهد. این 5 دقیقه و 20 ثانیه را اصطلاحاً VMCP Timeout میگویند.
اما اگر در فاصله زمانی بعد از 140 ثانیه (APD Timeout) و قبل از 5 دقیقه و 20 ثانیه (VMCP Timeout) شرایط Recover شود (مشکل APD حل شود) چه عکس العملی باید انجام دهیم (Recover Response)؟
Disabled؛
Reset VMs: ماشین را روی همان هاست ریست میکنیم. چون احتمال دارد برخی سیستم عاملها یا برنامهها برای احیای شرایط داخلی نیاز به ریست شدن داشته باشد.
توجه داشته باشید که اگر بخواهیم VMCP در پاسخ به مشکلات، عمل ریست را انجام دهد، لازم است که Host Monitoring و Priority هر دو Enable باشند در غیر اینصورت فقط Issue events انجام میشود.
همچنین توجه داشته باشید که در این قسمت تنظیمات پیش فرض Cluster انجام می گیرد که Per VM و همچون سایر تنظیمات در vSphere HA قابل تغییر خواهد بود.
VM Monitoring
همانطور که گفته شد، یکی از وظایف مهم vSphere HA، مقابله و محافظت در برابر خرابی های مربوط به سیستم عامل و یک برنامه و سرویس خاص است؛ این بخش از وظایف vSphere HA اصطلاحاً با نام VM Monitoring شناخته و معرفی شده است که به صورت پیش فرض در تنظیمات غیر فعال است. VM Monitoring و Application Monitoring قابلیتی است که ذاتاً به وسیله VMware Tools فراهم می شوند، البته در Application Monitoring علاوه بر VMware Tools نیازمند نرم افزارهای Third party نیز خواهد بود.
در VM Monitoring یک سری Heartbeatها از طریق VMware Tools فراهم میشود. اما این Heartbeat نمیتواند کافی باشد، صرف اعتماد به VMware Tools ممکن است منجر به تولید نتایج False Positive شود! یعنی نتایج اشتباهی تولید کند؛ ممکن است سرویس VMware Tools بنا به دلایلی Stop شده باشد اما خود VM بالا بوده و مشکلی نداشته باشد. بنابراین VMware علاوه بر شرط VMware Tools Heartbeat دو تا شرط دیگر را هم لازمه تشخیص خرابی در سیستم عامل ماشین مجازی کرده است. این دو شرط عبارتند از Network I/O و Disk I/O. در چنین شرایطی می توان صد در صد مطمئن شد که سیستم عامل ماشین مجازی دچار مشکل شده و باید ریست شود. البته این شرایط باید در یک بازه زمانی خاص مورد بررسی قرار گیرد.
همچنین برای کمک به Troubleshooting، vSphere قبل از ریست کردن ماشین مجازی، یک Screenshot از صفحه میگیرد که احتمالاً شامل Kernel Dump یا Blue Screen ویندوزی است که داخل فولدر اصلی ماشین مجازی ذخیره میشود و کمک میکند که خطاها را دقیقتر بررسی کنیم.
همانطور که گفته شد برای Application Monitoring هم نیاز به نرم افزارهای Third party است که بتوانند با APIهای VMware Tools ترکیب شوند و Applicationها و سرویسها را مانیتور کنند. در مورد Application Monitoring هم در نهایت پس از تشخیص خرابی، این ماشین مجازی است که ریست میشود. اما تجربه در مورد سرویسها و برنامههای Stable نشان میدهد که در اکثر مواقع از کار افتادن یک برنامه یا سرویس، دلائل خارجی دارد و عموماً با ریست شدن VM مشکلی حل نخواهد شد! محصول سیمانتک با نام Symantec Application HA، نمونه ای از این نرم افزارهای Third Party است.
گفتیم که VMware vSphere High Availability برای تشخیص خرابی و Crash کردن سیستم عامل یک سری پارامتر را کنترل می کند که عبارتند از VMware Tools Heartbeat، Disk I/O و Network I/O؛ اما تشخیص خرابی و ریست کردن ماشین نیازمند یک سری پارامتر دیگر نیز هست؛ شرایطی را فرض کنید که سیستم عامل ماشین مجازی شما Crash کرده و با ریست کردن مشکل حل نمی شود و دوباره سیستم عامل Crash می کند؛ در چنین وضعی 100 ها بار ریست کردن ماشین مجازی نه تنها تاثیر مثبتی نخواهد داشت، بلکه Workload اضافی به سیستم تحمیل میکند. یا شرایطی را در نظر بگیرید که بنا به دلائلی نظیر CPU Wait و بار بسیار زیادی که بر سیستم تحمیل شده، برای مدتی Heartbeat ها قطع می شوند. اما این شرایط گذرا است و پس از مدتی سیستم به حالت نرمال باز خواهد گشت؛ در چنین شرایطی ریست کردن ماشین مجازی یک اشتباه مهلک خواهد بود! از همین رو پس از فعال کردن VM Monitoring لازم است که تنظیمات مربوط به Heartbeat Monitoring Sensitivity را نیز با دقت انجام دهید.
این تنظیمات مشخص کننده موارد زیر خواهد بود:
Failure interval: اگر در این بازه زمانی VMware Tools هیچ Heartbeat ای نداشته باشد I/O Disk و Network I/O نیز نداشته باشیم، vSphere HA تشخیص میدهد که سیستم عامل ماشین مجازی Crash کرده و باید ریست شود.
Minimum uptime: بعد از تشخیص اولین خرابی و ریست شدن ماشین، به اندازه Minimum Uptime صبر میکند تا مجدداً مانیتورینگ را شروع کند. برای اینکه مطمئن شویم در این بازه زمانی ماشین کاملاً Boot شده بالا آمده است.
Maximum per-VM resets: جهت جلوگیری از حلقه بی پایان در ریست کردن، باید تعیین کنیم هر ماشین مجازی پس از تشخیص خرابی، حداکثر چند بار می تواند ریست شود.
Maximum reset time window: پارامتر Maximum per-VM resets، پارامتر بسیار مهمی است، اما به تنهایی کافی نیست. باید مشخص کنیم این حداکثر تعداد ریست مربوط به چه بازه زمانی می باشد؛ 1 دقیقه یا 1 ماه! مسلماً انتخاب درست این خواهد بود که در یک بازه زمانی کوچک، تعداد دفعات ریست شدن ماشین مجازی را محدود کنیم.
می توانید از مقادیر از پیش تعریف شده (Preset) استفاده کنید. جدول زیر مقادیر پارامترهای پیش فرض در این حالت را نمایش می دهد.
Setting | Failure Interval (seconds) |
Min. Uptime (seconds) |
Max. Failures
(Per VM Reset) |
Failure Window |
High | 30 | 120 | 3 | 1 hour |
Medium | 60 | 240 | 3 | 24 hours
(1 Day) |
Low | 120 | 480 | 3 | 168 hours
(1 Week) |
در صورتی که این مقادیر را مناسب نمیدانستید، میتوانید از طریق Custom، خودتان پارامترهای مناسب را تنظیم کنید.
توجه داشته باشید که همچون سایر تنظیمات vSphere HA، می توانید از طریق VM Override، برای هر کدام از ماشین ها تنظیمات متفاوتی داشته باشید.
Admission Control
یکی از نکات حائز اهمیت در مورد vSphere HA، کنترل رفتار آن است. به این نکته مهم توجه داشته باشید که بالاخره vSphere HA روی Host Cluster اجرا می شود و ظرفیت محاسباتی Cluster نیز محدود است. اگر قرار باشد ما از تمام یا درصد زیادی از ظرفیت سرورهای عضو کلاستر استفاده کنیم، در نتیجه خراب شدن یک یا چند سرور، دیگه ظرفیتی برای ریست کردن ماشین های محافظت شده توسط vSphere HA وجود نخواهد داشت، و یا اگر هم وجود داشته باشد، فضای بسیار محدودی خواهد بود که نهایتاً منجر به کاهش کارایی ماشین ها خواهد شد. این نکته نشان می دهد که لازم است همواره کنترل دقیقی بر رفتار و ظرفیت Cluster داشته باشیم تا vSphere HA بتواند طبق انتظار ما در آینده رفتار کند. در vSphere HA این کار به وسیله Admission Control انجام میشود. در واقع به وسیله Admission Control و Policyهای آن محدودیتهایی در استفاده از ظرفیت Cluster ایجاد می کنیم.
در حالت Disabled هیچ محدودیتی در استفاده از منابع محاسباتی کلاستر و روشن کردن ماشینها وجود نخواهد داشت؛ البته تا جایی که منابع Cluster اجازه میدهد! در چنین شرایطی احتمال دارد با خراب شدن یک سرور امکان Reset کردن ماشینهای آن روی سایر سرورها وجود نداشته باشد. توجه داشته باشید که در Admission Control آنچه که مهم است و مبنا قرار می گیرد منابع Reserve شده ماشین ها است؛ در واقع هدف اصلی Admission Control Policy ها این است که ماشینهایی با منابع Reserve شده بعد از خرابی به صورت تضمین شده بتوانند به فعالیت خود ادامه دهند.
در صورت انتخاب سایر گزینه ها و فعال بودن Admission Control، اجازه روشن کردن ماشینهای مجازی که محدودیتهای تعریف شده را نقض کند داده نخواهد شد.
یک رویکرد ساده می تواند این باشد که تعیین کنیم کلاستری که قرار است vSphere HA روی آن فعال شود، حداکثر خرابی چند سرور ESXi را می تواند تحمل کند (Host failures cluster tolerates).
واضح است که این عدد می تواند بین حداقل 1 سرور و حداکثر یکی کمتر از تعداد کل سرور های کلاستر باشد. به عنوان مثال اگر 4 سرور در داخل کلاستر داشته باشیم، این کلاستر می تواند به انتخاب ما خرابی بین 1 تا 3 سرور را تحمل کند. واضح است که در صورت انتخاب هر کدام از اعداد 1، 2 و یا 3، لازم است که میزان مشخصی از منابع محاسباتی کلاستر را به صورت رزرو نگه داریم تا در صورت بروز خرابی سرور فیزیکی ESXi بتوانیم از این منابع آزاد استفاده کرده و ماشین های تحت تاثیر قرار گرفته را روی این منابع آزاد ریست کنیم.
پس از اینکه تعیین کردیم کلاستر ما حداکثر خرابی چند سرور را می تواند تحمل کند (Host failures cluster tolerates)، می توان تعیین کرد که چه میزان از منابع باید رزرو شود (Define host failover capacity). برای این منظور سه رویکرد وجود دارد:
1.Cluster Resource Percentage
فرض کنید کلاستری با 4 سرور دارید با فرض اینکه توان محاسباتی تمام سرورها برابر است، اگر Host failures cluster tolerates را برابر 1 تنظیم کرده باشیم، این معنی خواهد بود لازم است 25% از منابع RAM و 25% از CPU را همواره آزاد نگه داریم. با این حال می توانید با انتخاب گزینه Override calculated failover capacity خودتان به صورت دستی این درصد ها تعیین کنید.
به عنوان مثال به سناریو زیر دقت کنید.
در این مثال 3 سرور با منابع پردازشی مختلف داریم که در مجموع 24GHz توان پردازشی و 21 GB حافظه دارند. روی این کلاستر 5 ماشین با منابع رزرو شده همانطور که در شکل مشاهده می کنید روشن هستند. در صورتی که Cluster Resource Percentage برای CPU و RAM روی 25% درصد تنظیم شده باشد، به این معنی است که در این کلاستر فقط تا سقف 75% منابع را می توان استفاده کرد.
CPU: ((24GHz – 7GHz)/24GHz) = 70%
RAM: ((21GB-6GB)/21GB) = 71%
محاسبات فوق نشان می دهد که این کلاستر Policy های vSphere HA را تا اینجا رعایت کرده و حتی می تواند تا سقف 75% باز هم ماشین های دیگری روی این کلاستر ایجاد کرده و یا روشن نمود.
اما لازم است چند نکته مهم را مورد توجه قرار دهید:
- در محاسبات عددی برای حافظه، حافظه رزرو شده به علاوه Memory Overhead مبنا خواهد بود.
- همانطور که گفته شد مبنای محاسبات Admission Control، CPU و RAM ای است که برای ماشین های روشن Reserved شده است، اگر ماشین مجازی روشن، منابع رزرو شده نداشته باشد، به صورت پیش فرض برای حافظه، 0 MB و برای CPU عدد 32 MHz در نظر گرفته خواهد شد.
- با استفاده از Advanced Option، das.vmcpuminmhz می توان این عدد پیش فرض 32 MHz را تغییر داد.
- تنها Host هایی که در وضعیت Connected بوده در محاسبات شرکت خواهند کرد. هاست هایی که در Maintenance Mode بوده و یا در شرایط HA Error هستند مستثنی خواهند بود.
2.Slot Policy
تا قبل نسخه 6.5 این گزینه، گزینه پیش فرض بود. اما وجود پیچیدگی های محاسباتی باعث شد تا شرکت VMware، گزینه ساده تر Cluster Resource Percentage را به عنوان گزینه پیش فرض معرفی کند. این گزینه بر مبنای مخرج مشترک گیری بین منابع CPU و RAM ماشین های مجازی عمل خواهد کرد و دارای دو حالت می باشد؛
- Cover all power-on virtual machines
- Fixed slot size
در Cover all power-on virtual machines، مبنای عملکرد Admission Control در vSphere HA، منابع رزرو شده برای تمام ماشین های مجازی روشن است. در حالی که در حالت Fixed slot size، به صورت دستی Slot Size را مشخص می کنیم.
بعد از مشخص شده Slot Size، vSphere HA تعیین خواهد کرد که هر سرور داخل کلاستر چند Slot است و طوری رفتار خواهد نمود و فرض خواهد کرد که بدترین اتفاق رخ دهد، یا به عبارت دقیق تر، پر ظرفیت ترین سرور کلاستر دچار خرابی شود.
همانطور که گفته شده مبنای Slot Policy، رفتار در شرایط Worst Case است. گام اول محاسبه Slot Size است. برای محاسبات vSphere HA بیشترین میزان RAM و CPU رزرو شده ماشینهای روشن داخل کلاستر را به عنوان Slot Size مبنا قرار میدهد؛ این یعنی همان بدترین حالت! اگر داخل کلاستر، ماشینهای روشن هیچ گونه Reservation ای نداشته باشند، برای CPU عدد 32 MHz و برای RAM، عدد 0 MB + Memory Overhead به عنوان مبنا قرار خواهد گرفت.
به عنوان مثال سناریو زیر را در نظر بگیرید؛
همانطور که گفته شد از آنجا که باید Worst Case در نظر گرفته شود، بالاترین مقدار RAM و CPU بین ماشین های روشن را به عنوان مبنا قرار خواهیم داد، در نتیجه Slot Size برای CPU و RAM به ترتیب برابر خواهد بود با 2 GHZ و 2GB.
گام دوم محاسبه ظرفیت هر کدام از سرورهای داخل کلاستر بر مبنای Slot Size محاسبه شده در مرحله قبل است. میخواهیم بدانیم که وضعیت Slot ها در Cluster ما چگونه است. در ابتدا Slot Size را برای CPU و RAM هر سرور جداگانه محاسبه میکنیم. به این صورت که منابع CPU و RAM هر سرور را جداگانه بر عدد به دست آمده در مرحله قبل تقسیم میکنیم با این کار هر سرور دو Slot Size را به ما میدهد، اما چون میخواهیم بدترین حالت را در نظر بگیریم، اولا اعداد را به سمت پایین رند خواهیم کرد، ثانیاً عدد کوچکتر Slot Size سرور را مشخص خواهد کرد. همانطور که مشاهده می کنید در مثال فوق سرور اول 4 اسلات و سرورهای H2 و H3 هر کدام 3 اسلات خواهند داشت.
گام سوم محاسبه Current Failover Capacityاست. Current Failover Capacity را خودمان باید محاسبه کنیم، از آنجا که اگر در بدترین حالت سرور 1 و سرور 2 از مدار خارج شوند، فقط 3 اسلات باقی میماند که این یعنی فقط 3 تا ماشین مجازی روشن، در حالی که ما 5 ماشین روشن داریم! پس Current Failover Capacity برابر 1 است. یعنی اگر در بدترین حالت سرور 1 از مدار خارج شود همچنان 6 اسلات وجود دارد که برای روشن کردن 5 ماشین (5 اسلات) کافی است.
گام چهارم مقایسه Current Failover Capacity با Configured Failover Capacity که در منو تنظیمات وارد کرده ایم. اگر Current Failover Capacity محاسبه شده کمتر از Configured Failover Capacity بود، اجازه روشن شدن ماشین جدید را نمیدهد، تا مطمئن شود تمام ماشینهای روشن Protected باقی خواهند ماند.
در حالت Fixed slot size هم می توانید به صورت دستی Slot Size ها را مشخص کنید و دیگر نیازی به محاسبات گام اول نخواهد بود و این امکان را خواهد داشت که با استفاده از Calculate و View، نتیجه محاسبات Slot Size را برای کلاستر و ماشین های مجازی داخل آن مشاهده کنید.
به طور کلی استفاده از این گزینه در Admission Control را توصیه نمی کنیم.
سخن پایانی
در این نوشته قابلیت در دسترس بودن بالا یا همان High Availability را به شکل کامل مورد بررسی قرار دادیم . در صورتی که سوالی در این باره دارید حتما از قسمت دیدگاه های سایت با ما در میان بگذارید.