زمانی که صحبت از Availability و Disaster Recovery در سرویس ها و تجهیزات شبکه میشود ، سخت افزارهایی مثل سرورها ، Switch ها ، Storage ها و HBA ها و ... باید طوری طراحی شوند که در شبکه و ساختار ، Single Point of failure نداشته باشیم و با خرابی و بروز مشکل در یک تجهیز ، شبکه و سرویس دهی آن تجهیز دچار اختلال نشود .
در سطح زیر ساخت vSphere نیز میتوانیم از قابلیت هایی مشابه NIC Teaming و Multipathing و vSphere High Availability و vSphere Fault Tolerance و ... در این راستا استفاده کنیم . در این مقاله به بررسی جزئیات مربوط به vSphere High Availability یا به اختصار vSphere HA خواهیم پرداخت . رایج ترین قابلیت در راه اندازی High Availability پیاده سازی HA در ساختار VMware میباشد . vSphere HA در زمانی که یک هاست دچار مشکل شود و Down شود ، باعث میشود تا ماشین های درون هاست Down شده در یک هاست دیگر درون همان کلاستر restart شوند .
فعال کردن vSphere HA جزئی از تنظیمات کلاستر میباشد . پس باید از قبل باید کلاستری از هاست ها را ایجاد کرده باشیم . برای فعال کردن HA بر روی کلاستر کلیک راست میکنیم و گزینه Setting را انتخاب میکنیم . در ادامه در قسمت Configure و vSphere Availability بر روی EDIT کلیک میکنیم . (مطابق شکل)
در قسمت بعدی چک باکس مربوط به vSphere HA را فعال میکنیم .
در ادامه vSphere HA بر روی هر یک از هاست ها تنظیم میشود و در صورتی که به Recent Task مراجعه کنیم ، میبینیم که بر روی هر یک از هاست ها تنظیماتی اعمال شده است . در کل زمانی که vSphere HA فعال میشود بر روی هر یک از هاست ها یک agent به نام Fault Domain Manager یا به اختصار FDM نصب میشود . حتی یک log فایل که مخصوص agent مربوط به FDM میباشد در هر هاست در مسیر /var/log/fdm.log ایجاد میشود .
پس با فعال شدن این قابلیت از ماشین ها در برابر Down شدن هاست ها ، محافظت میکنیم و در صورتی که هاستی بنا به هر دلیلی خاموش شد یا از دسترس خارج شد (Down شد) ماشین هایش در هاست های دیگر درون کلاستر restart خواهند شد . پس به اندازه یک restart سرور مجازی طول خواهد کشید تا مجددا سرور در شبکه شروع به سرویس دهی کند .
در حالت vSphere HA در داخل هر کلاستر ، یک هاست نقش master و بقیه هاست ها نقش slave خواهند داشت . وظیفه هاست master مدیریت بقیه هاست های slave در راستای عملیات HA میباشد و در واقع اطلاعات مربوط به cluster و وضعیت آن را به vCenter گزارش میدهد . همانطور که مشاهده کردید فعال سازی HA و تنظیمات آن از طریق vCenter صورت میگیرد . پس شاید این سوال مطرح شود که با Down شدن vCenter وضعیت HA به چه صورت خواهد بود ؟ آیا HA غیر فعال میشود و به مشکل خواهیم کرد ؟
جواب این سوال خیر است . یعنی هر زمان vCenter در دسترس نباشد و دچار مشکل شود ، HA همچنان وظیفه خود را به درستی انجام خواهد داد . دلیل این اتفاق این است که وظیفه اصلی کلیه رویدادها در HA بر عهده هاست master یا همان master node میباشد . اما خوب منطقی خواهد بود که با در دسترس نبودن vCenter تغییری در تنظیمات HA نمیتوانیم اعمال کنیم ، چون تغییرات توسط vCenter اعمال میشود .
در راه اندازی HA باید حداقل لایسنس Essential Plus داشته باشیم و نیاز اساسی راه اندازی HA وجود Share datastore میباشد . پس عملا ماشینی امکان استفاده از قابلیت HA را خواهد داشت که در Share datastore ساخته شده باشد تا بقیه هاست های کلاستر نیز به آن دسترسی داشته باشند تا بتوانند در مواقع رخ دادن HA به فایل های ماشین جهت روشن کردن ماشین دسترسی داشته باشند . منطقی به نظر میرسد که پیش نیاز بعدی وجود حداقل دو عدد هاست در کلاستر میباشد تا در زمان وقوع مشکل برای یک هاست ، هاست های دیگری در کلاستر وجود داشته باشند تا بتوانند ماشین های مورد نیاز را در خود روشن کنند . نهایتا ما نیاز به vCenter خواهیم داشت تا تنظیمات مربوط به HA را برای ما انجام دهد . همانطور که اشاره شد تنظیمات و Configuration در خصوص HA بر عهده vCenter سرور است و پس از اعمال تنظیمات در صورت Down بودن vCenter همچنان HA کار خود را انجام خواهد داد .
ساختار VMware جهت تشخیص این مورد که یک هاست Down شده است یا خیر از vSphere HA heartbeats استفاده میکند . پس hearbeat به ما کمک میکند پی ببریم که یک هاست بالاست و به درستی کار میکند . این heartbeat ها در بازه زمانی مشخصی از سمت هاست ها ارسال میشوند و در صورتی که در این بازه های زمانی مشخص ارسال نشوند در نتیجه هاست down شده است و باید عملیات HA رخ دهد و ماشین های هاستی که heartbeat ارسال نمیکنند در هاست دیگری restart شوند . شاید این شوال مطرح شود که این heartbeat ها از چه طریق کار میکنند و با چه مکانیزمی ارسال و دریافت میشوند ؟ جهت تشخیص بالا بودن هاست ها از دو مدل heartbeat استفاده میشود .
همانطور که اشاره شد ESXi از طریق پروتکل ICMP در بازه های زمانی مشخص تک تک slave نودها را پینگ میکند و در واقع این عملیات از طریق management network صورت میگیرد . در این مکانیزم به صورت پیش فرض default gateway به عنوان isolation address شناخته میشود . زمانی که هاست slave هیچگونه heartbaet ای از سمت master دریافت نکند ، تلاش میکند تا با gateway خودش ارتباط برقرار کند و در صورتی که gateway را نیز دسترسی نداشته باشد در نتیجه به عنوان هاست isolated در نظر گرفته میشود و این اتفاق یعنی دسترسی network این هاست محدود خواهد شد و بر اساس تصمیمی که ما خواهیم گرفت مشخص میکنیم چه عملیاتی برای ماشین های داخل این هاست رخ دهد . در تنظیمات مربوط به HA گزینه ای تحت عنوان Response for Host Isolation وجود دارد که در توسط آن میتوانیم در خصوص ماشین های هاستی که ایزوله شده است ، تصمیم گیری کنیم .
میتوانیم isolation address را که به صورت پیش فرض default gateway میباشد ، به هر آیپی آدرسی که در شبکه وجود دارد و از در دسترس بودن آن ها اطمینان داریم ، تغییر دهیم . همچنین میتوانیم تا 10 عدد isolation address مختلف را از طریق پارامتر [0-9] das.isolationaddress تنظیم کنیم . این پارامتر در قسمت Advanced Options تنظیمات HA و در قالب ایجاد پارامتر جدید قابل پیاده سازی خواهد بود . در شکل زیر من وارد تنظیمات HA میشوم و در قسمت Advanced Options دو option جدید ایجاد میکنم که دو عدد isolation address جدید خواهند بود .
چون این روش از پروتکل ICMP استفاده میکند جهت اطمینان خاطر توصیه میشود دو عدد کارت شبکه فیزیکال به ترافیک management اختصاص دهیم و این دو کارت شبکه نیز در محیط فیزیکال به دو عدد سوئیچ فیزیکال مجزا متصل شده باشند . این تنظیمات شبکه ای باعث میشود network availability بالاتری داشته باشیم .
جهت انعطاف پذیری بیشتر علاوه بر network heartbeats میتوانیم از قابلیت storage heartbeats استفاده کرد . به صورت پیش فرض جهت استفاده از storage heartbeat از دو عدد shared datastore استفاده میشود . اگر تعداد datastore ها را از حالت پیش فرض بخواهیم تغییر دهیم میتوانیم از پارامتر das.heartbeatDsPerHost استفاده کنیم و تعداد datastore مورد نظر خودمان را در قسمت value این پارامتر وارد کنیم .نحوه اضافه کردن پارامتر در قسمت بالا اشاره شد .
در قسمت پیش نیازها اشاره شد که جهت فعال سازی HA نیاز به shared storage داریم ، اما تعداد حداقلی برای آن مشخص نکردیم . در صورتی که ما از قابلیت storage heartbeat استفاده کنیم به صورت پیش فرض نیاز به دو عدد shared storage خواهیم داشت . پس در صورتی که تنها یک عدد shared storage داشته باشیم با warning مواجه میشویم . جهت نادیده گرفتن warning میتوانیم از پارامتر das.ignoreInsufficientHbDatastore استفاده کنیم و مقدار آن را true قرار دهیم .
این نکته را نیز باید در نظر داشت که زمانی از storage heartbeat استفاده میشود که network heartbeat درست عمل نکند و failed شده باشد . همانطور که بالاتر هم اشاره شد در مکانیزم storage heartbeat هر هاست یک فایلی در داخل shared storage ایجاد میکند که بقیه هاست ها نیز به آن دسترسی دارند . این فایل به صورت host-xxx-hb ساخته میشود و این فایل خالیست و هیچ حجمی ندارد . برای مثال در شکل زیر در کلاستری که 3 عدد هاست دارد فایل ها به شکل زیر نمایش داده میشوند .
این فایل ها توسط هر ESXi ای که ساخته شده باشند ، توسط همان ESXi نیز قفل شده خواهند بود . پس در حالت عادی این فایل ها قفل شده اند . نود و هاست master نیز از قفل بودن این فایل ها مطلع است . هر زمانی که هاست ارتباطش را با storage از دست بدهد ، هاست امکان این را نخواهد داشت که فایل را قفل شده نگه دارد و در نتیجه این فایل از حالت قفل خارج میشود و نود master متوجه میشود فایل قفل نیست . نود master بلافاصله پس از اینکه میبیند فایل قفل نیست متوجه میشود که ارتباط هاست با storage از بین رفته است و هاست Down شده است . در این هنگام عملیات HA رخ خواهد داد . امیدوارم بخش اول از مکانیزم vSphere HA مورد توجه شما قرار گرفته باشد .