همانطور که در دانلود ها و مطالب آموزشی vSphere 7 متوجه شدید ، شرکت VMware تمرکز ورژن 7 این بستر را بر روی Integration گذاشته است.
در این ورژن Kubernetes در داخل ESXi یکپارچه شده است ، و vCenter بیشترین یکپارچگی را با بستر های Cloud پیدا کرده است.
در راستای همین هدف VMware برنامه ای با نام VCF VMware Cloud Foundation ایجاد کرده است ، که در پست های آینده درمورد این مبحث مفصل صحبت خواهیم کرد.
اما در این مطلب آموزشی قصد داریم مفصل راجع به DRS و تغییرات آن صحبت کنیم .
پس بدون اتلاف وقت میرویم سراغ Distributed Resource Scheduler :
DRS چیست ؟
DRS یکی از قابلیت های کلیدی بستر مجازی سازی VMware می باشد که وظیفه ایجاد توازن بار بین سرور ها را دارد.
علاوه بر این کار وظیفه فراهم کردم منابع برای ماشین های مجازی را نیز دارد.
یعنی اینکه اگر ماشین مجازی A نیاز به مقداری Resource دارد که روی سروری که الان هست موجود نمی باشد ، باید ماشین مجازی را جابجا کند بر روی سرور فیزیکی دیگری که منابع آزاد دارد تا ماشین مجازی بتواند از منابع مورد نیاز خود استفاده کند.
تکنولوژی DRS برای اولین بار در سال 2006 ارائه شد و همانوطور که توضیح دادیم کلا واحد چک شونده و مهم برای DRS هاست ها یا ESXi ها بودند وبه محض مشاهده نابالانسی دست به کار می شد.
اما این مطلب مقداری مشکل دارد. چرا؟
زیرا ممکن است که یک هاست رم استفاده شده اش 90 درصد باشد و ماشینی رو آن باشد که احتیاج به 20 گیگ رم دارد ، و هاست دیگری نیز رم استفاده شده اش 90 درصد باشد ولی ماشینی روی آن باشد که یک 1 گیگ رم احتیاج داشته باشد.
متوجه منظور مثال شدید؟
به همین منظور VMware به دنبال روشی بود که از روی خود ماشین ها و نیازشون به رم و CPU مقدار DRS را محاسبه و اعمال کند.
برای همین منظور فاکتور جدید را با نام VM Score معرفی کرد .
قبل از پرداختن به بقیه تغییرات ایجاد شده باید با Term جدیدی که VMware معرفی کرده آشنا بشیم یعنی VM Score .
VM Score
تعریفی که خود VMware از VM Score دارد میزان راندمان اجرایی یک ماشین مجازی است . ولی آیا واقعا این تعریف قابل فهم است ؟
واقعا خیر. پس سعی می کنیم که از متد خودمان برای آموزش این قابلیت استفاده کنیم.
VMware مقدار DRS Score را به 5 قسمت تقسیم کرده .
- 0 تا 20
- 20 تا 40
- 40 تا 60
- 60 تا 80
- 80 تا 100
بر خلاف چیزی که فکر می کنید اگرDRS Score ماشین در بازه 80 تا 100 باشد بدین معنی نیست که ماشین در وضعیت بدی به سر می برد ، بلکه به این معنی است که ماشین مجازی هر چقدر منابع احتیاج داشته باشد هاست میتواند در اختیار او بگذارد پس یعنی احتمال وجود Contention یا کمبود بسیار بسیار کم است.
از طرف دیگر اگر ماشین مجازی دارای DRS Score ای بین 0 تا 20 باشد، یعنی احتمال اینکه ماشین مجازی در موقع تامین ما بقی منابع به مشکل یا کمبود بر خورد کند خیلی زیاد است.
حال DRS Score چگونه حساب می شود؟
فاکتور های بسیار زیادی در محاسبه DRS Score دخیل هستند که اگر فرصت شد در مطلبی جداگانه کامل به نحوه محاسبه آن می پردازیم.
پس من برای تعریف DRS Score به جای اینکه از کلمات راندمان اجرایی استفاده کنم ، از کلمات درصد آسودگی خاطر استفاده می کنیم.
پس هر چقدر درصد آسودگی خاطر ماشین مجازی نزدیک به 100 باشد ، یعنی ماشین احتیاجی به جابجایی به هاست دیگری ندارد ، هر چقدر درصد آسودگی خاطر ماشین مجازی نزدیک به صفر باشد نیاز آن به DRS و حتی جابجایی به هاست دیگر خیلی بیشتر است.
فقط یک نکته دیگر اینکه ،اگر فکر کنیم ماشینی که بین 80-100 قرار دارد مقدار Performance بهتری نسبت به ماشینی که بین 40-60 است را دارد ، لزوما صحبت درستی نیست ، زیرا فاکتور های زیادی در محاسبه DRS Score وجود دارد .
پس از DRS Score تنها برای DRS استفاده کنید و به دنبال استفاده آن برای سنجش Performance فعلی ماشین نباشید.
پس با توضیحاتی که دادیم در نهایت VMware توانست در محاسبه و اعمال DRS به Workload ماشین ها نگاه کند و دیگر کاری ندارد که هر هاست چقدر از منابعش استفاده شده است.
قبل از اینکه راجع به مورد بعدی صحبت کنیم ما قابلیت دیگری نیز با نام Cluster DRS Score داریم که این فاکتور جمع تمام VM DRS Score ها می باشد و زمانی که این عدد خوب نباشد باید به فکر جابجایی ماشین ها به کلاستر دیگری یا افزایش تعداد هاست های داخل کلاستر باشیم یعنی Scale Out کردن باشیم.
بازه زمانی
دومین تغییری که در DRS این ورژن ایجاد شده است ، تغییر بازه زمانی 5 دقیقه ای به 1 دقیقه می باشد.
این امر باعث میشود که برای سازمانهایی که Workload های بسیار هیجانی دارند ، همیشه به ماشین های مجازی شان منابع در دسترس باشد.
دلیل این تغییر هم مشخص است زیرا که از این به بعد ماشین های مجازی را مانیتور می کنیم نه هاست ، پس تک تک آنها باید در بازه های زمانی کوچک تری مانیتور شوند.
Scalable Share
قابلیت جدیدی که دوباره VMware در این ورژن معرفی کرده است ،قابلیت Scalable Share می باشد.
این قابلیت واقعا نتیجه فکر بسیار زیاد مدیران فنی VMware مثل Duncan Epping و Frank Denneman می باشد.
کل داستان این قابلیت باز میگردد به علاقه VMware به رعایت عدالت در شرایط مختلف ماشین های مجازی.
بهترین روش آموزش این قابلیت مثال زدن می باشد که با هم روی یک مثال تمرکز می کنیم.
فرض کنید که ما دو عدد Resource Pool موجود داریم.
یکی از آنها دارای Share High و دیگری دارای Share Normal هستند درست مثل شکل زیر.
خوب زمانی که یک RP رو بر روی High میگزاریم یعنی 8000 واحد وزن در گرفتن منابع دارد.
زمانی هم که یک RP رو بر روی Normal میگزاریم یعنی 4000 واحد وزن در گرفتن منابع دارد.
اگر در داخل RP A یک ماشین مجازی باشد و در داخل RP B هم یک ماشین مجازی باشد یعنی ماشین مجازی VM10 دو برابره ماشین مجازی VM 20 از توانایی استفاده از منابع را دارد می باشد.
تا اینجا همه چی عالیست ودر واقع یعنی نسبت 2:1 برای ماشین های داخل RP ها فراهم شده.
حال فرض بگیرید در داخل RP A تعداد 10 عدد ماشین مجازی وجود دارد ولی هنوز در داخل RP B همچنان یک عدد ماشین مجازی می باشد .
میتونید محاسبه کنید به هر ماشین موجود در RP A با Share High چند واحد وزن برای دریافت منابع می رسد ؟
8000 / 10 =800
به ماشین مجازی VM20 که در داخل RP B که Share Normal دارد چند واحد وزن برای دریافت منابع می رسد ؟
4000 / 1 = 4000
به نظر شما یه جای داستان مشکل ندارد؟
ما ماشین های مجازی را در داخل RP A قرار دادیم که Resource یا منابعی بیشتری دریافت کنند ولی در این مثال که ازحالت نرمال هم کمتر دریافت می کنند.
پس اگر مشکل رو متوجه شدید بریم سراغ راهکار .
طبق داکیومنت های VMware هر Resource Pool ای به چشم DRS دقیقا کپی یک ماشین مجازی با 4 vCPU و 16 GB RAM دیده می شود.
پس اگر وزن RP High عدد 8000 است یعنی وزن هر CPU برابر با 2000 هستش. ( به تقسیم ساده انجام شد 8000/4 (vCpu))
در نهایت بدین معنی می باشد :
- وزن هر CPU در High = 2000
- وزن هر CPU در Normal = 1000
- وزن هر CPU در Low = 500
حال اگر بخواهیم با استفاده از Scalable Share مقدار Share ماشین های یک RP رو به دست بیاوریم باید از فرمول زیر برم :
Resource Pool Shares = (4 vCPU * Shares of Pool(high/Normal/Low) )* (Total number of shares of all vCPUs in resource pool)
خوب بریم جایگذاری کنیم :
برای RP A با Share High :
Resource Pool Shares = ( 4*2000(High))*(10*1000) = 80.000.000
برای RP B با Share Normal:
Resource Pool Shares = ( 4*1000(Normal))*(1*1000) = 4.000.000
اگر برای شما عزیزان سواله که عدد 1000 از کجا اومد ، این رو باید تو حالت معمولی بدانیم ، وقتی Resource Pool نداشته باشیم یعنی تمام تنظیمات بر روی Normal هستند و Share Normal عدد 1000 می باشد.
از تمام این فرمول ها نتیجه گیری میشود مقدار Share ای که جمعا به دست ماشین های RP A خواهید رسید 20 برابره ماشین هایی است که در RP B هستند. این یعنی Scalable Share.
البته استفاده از این قابلیت کاملا اختیاری می باشد. بعضی از مواقع ما میخواهیم مجموع ماشین ها مقدار مشخصی Resource داشته باشند و با نسبیت ماشین های مجازی اصلا کاری نداریم.
اگر سوالی بود حتما درقسمت کامنت ها بپرسید.
ممنون ار شما بابت ابن مطلب فقط 2 تا سوال :
1- الان یعنی کلا روش قبلی محاسبه در DRS کلا حذف شده و دیگه روی هاستها نگاه نمیکنه که از لحاظ مصرف منابع balance باشند و جابجایی ماشینها در DRS فقط براساس منابعنی که نیاز دارند انجام مبشه ؟
2 – این DRS score که پنج باز هست فقط مثل شکل حالت monitoring داره و میگه کدوم VM ها در کدام دسته قرار گرفتند یا چیزی هست که ما تنظیم میکنیم و میتونیم دستی تغییر بدیم ؟
ممنون
سلام مهندس. خواهش میکنم.
بله الان از روی ماشین های مجازی کار DRS صورت میگیره ولی از همین طریق دوباره بار سرور ها یکسان خواهند بود. (نزدیک به هم). این روش کار های قبل رو دقیق تر کرده.
مقدار DRS score دست ما نیست و خودش محاسبه می کنه. و بر اساس همین Score ها ماشین ها رو جابجا میکنه.
ممنونم، عالی