در حال بارگزاری...

HA Admission Control بخش اول

پیش تر در مقاله ای مفهوم HA در vSphere را خدمتتان معرفی کردیم. در این مقاله قصد داریم یکی از ویژگی های بسیار کاربردی به نام Admission Control که به نوعی با vSphere HA برای عملکرد بهینه تر در تعامل است را معرفی کنیم.

از میان مباحث و مفاهیم موجود در vSphere، یکی از مباحثی که گاهاً درک درستی از آن وجود ندارد Admission Control است. این مسئله می تواند باعث عدم بهره وری بهینه و درست از ویژگی vSphere HA شود و در برخی موارد کاربران تنها راه چاره را غیر فعال کردن این مکانیزم می دانند.

Admission Control چیست و چرا vSphere HA به آن نیاز دارد؟

توضیح این مکانیزم را با یک مثال شروع می کنیم. در نظر بگیرید که در یک کلاستر دو هاست ESXi وجود دارد که از نظر مقدار منابع RAM و CPU کاملاً یکسان هستند و بر اساس تعداد ماشین های مجازی روشن شده روی هر کدام و استفاده این ماشین ها از منابع، Utilization هر هاست به شکل زیر است:

admission Control 1 FIN compressor

در صورت از دست رفتن Host1. مکانیزم HA تمامی ماشین های مجازی روی آن را در Host2 راه اندازی می کند. چرا که Host2 تنها از 10% منابع خود استفاده کرده و 90% دیگر آن بلا استفاده مانده است. پس طبیعی به نظر می رسد که Host2 ظرفیت کافی برای میزبانی ماشین های مجازی Host1 و راه اندازی مجدد آنها را دارد. حال همین مثال را در شرایطی تصور کنید که Host2 دارای Utilization بالاتری باشد:

admission Control 2 FIN compressor

اگر در این شرایط Host1 از دست برود، آیا Host2 منابع کافی برای میزبانی ماشین های مجازی آن را دارد؟ چگونه می توان از این بابت مطمئن بود که HA می تواند تمام ماشین های روی Host1 را در Host2 مجدداً راه اندازی کند؟

وظیفه Admission Control دقیقاً همین است! اطمینان از وجود منابع کافی در کلاستر.

vCenter Server برای اطمینان از اینکه در هنگام بروز مشکل برای هاست ها، منابع کافی در کلاستر برای ماشین های مجازی باقی بماند از Admission Control استفاده می کند.

در جمله بالا یک توضیح مختصر از ماهیت Admission Control گفته شد اما یک نکته حائز اهمیت است و آن هم کلمه "vCenter" است. بله در واقع بر خلاف چیزی که بسیاری فکر می کنند، این vCenter است که مسئولیت Admission Control  را به عهده دارد. اگر چه در نگاه اول ممکن است این نکته بدیهی به نظر برسد، اما در اصل به این مطلب اشاره دارد که Admission Control منابع کلاستر را بررسی و مقداری از آن را برای Failover رزرو می کند ولی وظیفه راه اندازی مجدد ماشین های مجازی را به عهده ندارد یا از آن جلوگیری نمی کند، به این معنی که راه اندازی های مجدد HA در سطح Host انجام می شود و نه از طریق vCenter .

همانطور که گفته شد Admission Control با رزرو کردن منابع در کلاستر، فضای مورد نیاز برای راه اندازی ماشین مجازی توسطHA  را تضمین می کند. به بیان دیگر این مکانیزم به ما گارانتی می دهد که در صورت از دست رفتن هاست های ESXi، منابع کافی در سطح کلاستر وجود دارد تا بتوان ماشین های مجازی را در هاست های دیگر مجدداً راه اندازی کرد.

Admission Control فضای مورد نیاز برای Failover را بر اساس منابع در دسترس (Available) محاسبه می کند. به عبارت دیگر اگر هاست در حالت Maintenance یا Disconnected قرار بگیرد از معادله خارج می شود. همچنین اگر هاست Failed شود یا پاسخگو نباشد اما از کلاستر حذف نشده باشد، باز هم در معادله شرکت می کند و بر روی محاسبه تاثیر گذار خواهد بود.

منابع در دسترس (Available Resources) پس از محاسبه و کم کردن overhead مجازی سازی از مقدار کل منابع بدست  می آید. به عنوان مثال حافظه مصرف شده توسط VMkernel از کل مقدار حافظه کم می شود تا مقدار حافظه در دسترس برای ماشین های مجازی بدست آید.

قبل از اینکه بیشتر ادامه دهیم مطلبی با اهمیت در مورد Admission Control هست که باید به آن اشاره کرد، زمانی که Admission Control فعال است، HA در هیچ شرایطی از قیود Availability تخطی نمی کند. به این معنی که همیشه از در حال اجرا بودن ماشین های مجازی محافظت شده اطمینان حاصل می کند. به عنوان مثال اگر در کلاستر فقط یک هاست در حال سرویس دهی به ماشین های مجازی باشد و این هاست به عنوان آخرین هاست باقیمانده در کلاستر به هر دلیلی از دست برود، HA پس از سرویس دهی مجدد هاست، به صورت اتوماتیک ماشین های مجازی روی آن را روشن می کند.

اگر شما از مکانیزمی مانند(DRS)  Distributed Resource Scheduler یا Distributed Power Management (DPM) استفاده کنید چه؟ آیا ممکن است DPM تمام هاست ها را در حالت Standby قرار دهد تا میزان برق مصرفی را کاهش دهد؟ نه. DPM به اندازه کافی هوشمند است که هاست ها را از حالت Standby خارج کند و از داشتن منابع کافی برای HA اطمینان حاصل کند.

همچنین هنگام نوشتن Rule در کلاستر تنظیماتی وجود دارد که از طریق آنها کاربر می تواند به DRS و HA بگوید تا به قوانین یکدیگر احترام گذاشته و آنها  را نقض نکنند. به عنوان مثال زمانی که یک Anti-Affinity Rule ساخته می شود تا ماشین های مجازی مورد نظر در هاست های مختلفی باشند، در هنگام از دست رفتن یکی از این هاست ها، HA به صورت پیش فرض این قانون را نادیده می گیرد و برای رسیدن به اهداف Availability ماشین مجازی را در هاست جدید راه اندازی می کند و در این شرایط ممکن است قوانین DRS نقض شده و ماشین های مجازی بر روی یک هاست مشترک اجرا شوند. در قسمت تنظیمات Advance کلاستر می توان این گزینه را تغییر داد تا HA به قانون ساخته شده احترام بگذارد.

اما HA به چه طریق از وجود منابع کافی در هنگام Failover مطمئن می شود؟ در قسمت دوم این مقاله با ما همراه باشید تا سیاست های Admission Control را بررسی کنیم.