پیاده سازی vCenter Server High Availability

با سلام خدمت دوستان عزیز

در این مقاله  High Availability در  vCenter Server Appliance را بررسی خواهیم کرد . ممکنه برای تک تک شما این اتفاق رخ داده باشه  که ماشین vCenter Server Appliance بنا به هر دلیلی  دچار مشکل بشه  و از دسترس خارج بشه . تو این حالت همه ما سعی می کنیم به هر نحوی شده مشکل رو برطرف کنیم و یه جورایی سرویس vCenter رو راه اندازی کنیم . مشکل از اونجایی بیشتر خودش رو نشون میده که احتمالا سرویس ها و برنامه های متفاوت دیگه ای با وابستگی به vCenter دارن کار میکنن و اگه vCenter بالا نیاد میشه تصور کرد تو چه دردسری افتادیم .
با این اوصاف ، راهی برای بالا بودن حداکثری vCenter تو شرایط مختلف حیاتی هستش و برای همین لازمه تا با vCenter Server High Availability بیشتر آشنا بشیم .
vCenter Server مهمترین و اصلی ترین جزء در محیط VSphere هست و مدیریت و هسته اصلی بسیاری از سرویس ها بر عهده vCenter Server است . بسیاری از برنامه های third-party نیز جهت پیاده سازی نیاز به این جزء خواهند داشت .

پس با توجه به شکل بالا بسیاری از workload هایی که در حال اجرا شدن توسط کاپوننت های دیگه هست ، با وجود vCenter قابل اجراست و در نبود آن این workload ها متوقف یا دچار مشکل خواهند شد .
با توجه به موارد اشاره شده راه اندازی vCenter High Availability  یا به اختصار VCHA برای محیط هایی که وابستگی زیادی به vCenter دارن ، یک امر ضروری محسوب میشه .

راه اندازی VCHA کلاستری به همراه سه نود می باشد ، که هر نود یک نمونه از VCSA می باشد . (َActive node , Passive node , Wittness node)
نود اول به عنوان Active فعالیت میکنه و تحت عنوان نود Protected یا Active از اون یاد میشه . این نود دو عدد کارت شبکه خواهد داشت یکی جهت public network و یکی جهت private network که جهت اتصال به vSphere Web Client ، CLI و عملیات management ای از Public IP استفاده میشه و برای ارتباط با بقیه نودها و شبکه VCHA از Private network استفاده میشه .
از نود اول دو بار Clone گرفته میشه ، یکی جهت نود Passive و دیگری جهت نود Witness ، که به واسطه این سه نود VCHA بر مبنای active-passive پیاده سازی میشه .

نود Passive دقیقا همان نود Active هست ، یعنی به همان میزان CPU ، Memory ، disk خواهد داشت و همونطور که گفته شد بعد از Clone گرفتن از نود Active ایجاد میشه . تنها تفاوت نود پسیو با نود اکیو در Stop بودن همه سرویس ها هست . پس با Down شدن نود Active ، نود Passive نقش Active می گیره و همه سرویس هاش رو استارت میکنه .
Private network که بالاتر اشاره شد جهت Replication مربوط به دیتابیس و فایل های Configuration از نود اکتیو به نود پسیو هست . VCSA کلیه شرایط و وضعیت فعلی خودش رو در قالب vPostgres database و فایل های Configuration درون خودش نگهداری میکنه . پس میشه نتیجه گرفت که با عملیات همسان سازی بین این دو نود ، نود passive ، کلیه این شرایط و وضعیت فعلی رو به صورت آپدیت شده دریافت میکنه .

نود Witness یک نسخه و ورژن سبک تری از VCSA هست که نقش quorum رو ایفا میکنه . همونطور که میدونید quorum یک تکنیک در کلاسترینگ هست و در مبحث VCHA زمانی کاربرد دارد که نودهای Active و Passive هر دو روشن و بالا هستند اما توانایی ارتباط با همدیگه رو ندارن .

قرار گرفتن هر یک از این نودها در هاست های متفاوت باعث میشه در هنگام از دسترس خارج شدن هاستی ، VCSA ما بالا باشه و با مشکلی مواجه نشه و سرویس دهی ادامه پیدا کنه . پس احتمالا حدس زدین که برای پیاده سازی کلاستری حداقل با سه عدد هاست مد نظرمون هست .  پس اگر failure بر روی vCenter Server شناسایی بشه VCHA بلافاصله fails over بر روی نود passive انجام میده و این نود نقش active به خودش میگیره . در این پروسه هیچگونه دیتایی از بین نخواهد رفت یا به اصطلاح گفته میشه که RPO(Recovery Point Objectiv) برابر ۰ هست .

vCenter HA هم حالت embeded و هم حالت external جهت platform service controller (PSC) را پشتیبانی میکنه . همونطور که میدونید حالت embeded PSCبرای مواقعی هست که داخل SSO domain خودمون هیچگونه PSC یا vCenenter دیگه ای نداشته باشیم . از طرف دیگه هم میدونید که external PSC زمانی استفاده میشه که تعدادی vCenter در حالت Enhanced Linked Mode داشته باشیم .یه نکته ای که باید در نظر داشته باشیم این هست که اگه تعدادی PSC داریم و قرار هست vCenter HA راه اندازی کنیم ، از قبل بهتره که  با load balancer عملیات HA در سطح PSC ها فراهم بشه . (اگه کنجکاو هستید که از چه load balancer ای میتونیم استفاده کنیم برای PSC HA در vSphere 6.5 بد نیست بدونید که VMware NSX ، F5 ، BIG-IP ، LTM ، Citrix NetScaler میتونن مورد استفاده قرار بگیرن )

بد نیست کمی بیشتر بررسی کنیم که در چه مواقعی VCHA عملیات failover رو انجام میده . بالاتر اشاره کردم که یکی از موارد حفاظت VCSA توسط VCHA ، زمانی هست که هاست مربوط به VCSA دچار مشکل سخت افزاری بشه و از دسترس خارج بشه . مورد بعدی میتونه مربوط به اشکالاتی در زمینه network ما باشه و بنا به مشکلات network ای ارتباط با VCSA خودمون رو از دست بدیم . گاهی موارد هم storage ای که VCSA درون اون قرار داره دچار مشکل میشه و دسترسی ما به VCSA قطع میشه . ناگفته نمونه گاهی اوقات هم خود VCSA و یا سرویس های اون دچار مشکل میشن .
پس در همه این حالت هایی که اشاره کردم fail شدن برای VCSA اتفاق میوفته و VCHA با failover انجام دادن و تغییر نقش نود passive به active این کار رو برای ما انجام میده .

راه اندازی VCHA تنها در vCenter Server Appliance و از نسخه ۶٫۵ به بعد امکان پذیر هست . پس انتظار نداشته باشید که روی نسخه vCenter Server ویندوزی بشه این عملیات رو پیاده سازی کرد .
برای پیاده سازی VCHA بین هاست هایی که نود های مختلف (active , passive , witness) رو تو دل خودشون جا دادن ، باید یک شبکه مجزا طراحی کنیم . پس یک شبکه private بین سه عدد نودی که قبلا اشاره کردیم باید ایجاد کنیم .ترافیک و ارتباطات مربوط به VCHA درون این شبکه private بین نودها جا به جا میشه . پس ارتباطات این سه نود به واسطه این private network صورت میگیره و نکته ای که باید توجه کنیم مجزا بودن subnet این نتورک از بقیه شبکه هایی هست که VCSA با اونا کار میکنه ، مخصوصا مجزا بودن این شبکه از رنج شبکه management باید مورد توجه قرار بگیره . برای اینکه بتونیم یه شبکه کاملا مجزا برای VCHA طراحی کنیم از هر نود باید یک کارت شبکه(virtual NIC) به صورت مجزا برای این عملیات اختصاص بدیم و latency شبکه بین نودها از نظر استاندارد باید زیر ۱۰ میلی ثانیه باشه .
نکته دیگه قبل از پیاده سازی فعال بودن SSH بر روی VCSA هست و بعد از پیاده سازی می تونیم SSH رو غیر فعال کنیم .

جهت راه اندازی VCHA می تونیم از حالت Basic یا Advanced استفاده کنیم . از نظر کارایی پیاده سازی در حالت basic یا advanced تفاوتی با هم ندارن . در حالت basic ساخته شدن نودهای passive و witness به صورت اتوماتیک در مراحل پیاده سازی صورت میگیره در صورتی که در حالت advanced خود ما به صورت دستی وظیفه clone گرفتن از نود اکتیو رو داریم تا بتونیم نودهای passive و witness رو ایجاد کنیم . پیاده سازی به صورت advanced یا basic کاملا بستگی به شرایط و محیط ما داره ، که در این سناریو ما از حالت basic استفاده خواهیم کرد . همونطور که گفتم حالت advanced قابلیتی فراتر از حالت basic به ما ارائه نمیده و بسته به شرایط در مواقعی میتونیم از حالت advanced استفاده کنیم .

خوب ما قضیه رو سخت نمی کنیم و ستاریو خودمون رو با یک VCSA 6.5 در حالت embeded platform service controller ادامه خواهیم داد .
قبل از شروع راه اندازی VCHA باید پیش نیازهای مربوط به network رو مهیا کنیم . باید درون هر یک از esxi های مورد نظرمون یک port group مجزا برای private networh یا همون VCHA network ایجاد کنیم .

در این سناریو من ۴ عدد هاست در یک کلاستر دارم و با توجه به اینکه از هر هاست یک کارت شبکه آزاد دارم ، پس یک vSwitch جدید با port group مورد نظر ایجاد میکنم و کارت شبکه آزاد خودم رو به vSwitch ایجاد شده اضافه میکنم و مشابه این تنظیمات رو بر روی بقیه هاست های خودم هم ایجادمیکنم . شما میتونید port group درون vSwitch هایی که از قبل دارید ایجاد کنید و حتما نیازی به ایجاد vSwitch جدید نیست .

بعد از ایجاد port group باید یک vitual NIC جدید به VCSA اضافه کنیم . پس VCSA ما دو عدد کارت شبکه خواهد داشت که اولین کارت شبکه جهت management می باشد و آیپی بر روی آن تنظیم شده است که زمان نصب تنظیم کرده ایم و جهت اتصال به vCenter و management مورد استفاده قرار میگیره . کارت شبکه دوم که اضافه میکنیم نیز برای VCHA و شبکه private که ایجاد میشه ، مورد استفاده قرار میگیره .
نکته ای که باید توجه بشه در مورد کارت شبکه management سرور VCSA این هست که گاهی این کارت شبکه و آیپی آن  را در مباحث VCHA تحت عنوان public IP می شناسیم  و کارت شبکه دوم که برای شبکه داخلی VCHA مورد استفاده قرار میگیره تحت عنوان private IP در VCSA می شناسیم .

بعد از اضافه کردن کارت شبکه ، اون رو به port group ای متصل می کنیم که لحظاتی قبل برای شبکه private جهت VCHA ساخته شد .

در ادامه به مسیر زیر می رویم تا تنظیمات مورد نظر جهت پیاده سازی را اعمال کنیم .

در ادامه گزینه Basic را انتخاب و Next را کلیک می کنیم .

در صورتی که مشکلی برای کارت شبکه دوم VCSA نباشد بدون error باید وارد مرحله بعد شویم و در صورت هر مشکلی به ما error خواهد داد و بعد از رفع مشکل باید ادامه عملیات را انجام دهیم .

در این قسمت با error ای مواجه می شویم مبنی بر Down بودن کارت شبکه private network مربوط به VCSA ، که برای برطرف کردن این مشکل از طریق VAMI به vCenter متصل میشم و مورد رو بررسی میکنم . حتما میدونید که اتصال از طریق VAMI یعنی با پورت ۵۴۸۰ به VCSA خودمون متصل بشیم .

خوب همونطور که مشاهده میشه کارت شبکه دومی که اضافه کردیم غیر فعال هست و باید فعال بشه . روی edit کلیک میکنیم تا تنظیمات کارت شبکه باز بشه و برای رفع مشکل گزینه Disable ipv4 Settings رو تغییر می دیم و به صورت استاتیک ، آیپی مورد نظر برای شبکه VCHA رو به نود active اختصاص میدیم .

مجددا در تنظیمات VCHA گزینه Basic رو انتخاب و گزینه Next رو میزنیم . این بار بدون error می تونیم به مرحله بعد وارد بشیم . در این قسمت باید آیپی مربوط به نود های passive و witness رو به صورت استاتیک وارد کنیم  و گزینه Next رو کلیک کنیم .

در مرحله بعدی شرایط کلی و محل قرارگیری نودها نمایش داده میشه که اگه DRS در سطح کلاستر فعال باشه در قسمت Location گزینه و نام cluster رو مشاهده میکنیم ، در غیر این صورت باید به صورت دستی هاست مورد نظری رو به عنوان location انتخاب کنیم . در قسمت network هم port group مربوط به vcha قابل مشاهده هست و نهایتا در قسمت storage محل قرارگیری نودها درون storageها مشخص میشه . بهتر هست که در صورت امکان storage های نودها هم متفاوت باشه تا در برابر fail شدن storage هم مشکلی نداشته باشیم .

warning ای که تو قسمت storage وجود داره هم اشاره میکنه که بهتره نودها توی storage های متفاوت ذخیره بشن .

جهت تغییر در تنظیمات در نودهای passive و witness بر روی edit کلیک می کنیم . البته من در این قسمت تنها تغییر storage مد نظرم هست .

با توجه به شکل بالا روی Next کلیک میکنیم .

در این قسمت نیز computer resource درون کلاستری که DRS بر روی آن فعال است قرار گرفته و قصد تغییر آن را ندارم پس روی گزینه next کلیک می کنم .

در مرحله بعد مطابق شکل بالا Storage رو تغییر می دیم و نود passive در storage ای که نود active قرار دارد نخواهد بود و هدف از این کار جداسازی storage ها هست .
در مرحله بعد هم مطابق شکل زیر management network و شبکه VCHA به درستی به صورت پیش فرض انتخاب شده و نیاز به تغییر نداره .

با کلیک روی Next خلاصه تغییرات و تنظیمات را مشاهده می کنیم و نهایتا روی Finish کلیک می کنیم .

همین عملیات را برای نود witness نیز انجام می دهیم تا storage قرارگیری اون متفاوت از active و passive باشه .

در ادامه پس از اعمال تغییرات مشاهده میشه که warning ها برطرف شده .

بر روی کزینه Next کلیک می کنیم .

در شکل بالا خلاصه ای از تنظیمات VCHA را مشاهده می کنیم و نهایتا بر روی Finish کلیک می کنیم . در ادامه عملیات Deploy شدن vCenter HA کلاستر شروع خواهد شد و در قسمت recent tasks می تونیم عملیات Clone گرفتن که به صورت اتوماتیک انجام میشه رو مشاهده کنیم .

بهد از اینکه از نود active به صورت اتوماتیک clone گرفته بشه ، نود passive اتوماتیک روشن خواهد شد و مجددا clone گیری برای نود witness شروع میشه .

بعد از اتمام cloneگیری جهت نود witness ، این نود نیز ساخته شد و ماشین witness هم روشن میشه .

بعد از ایجاد هر سه نود ، میتونیم مشاهده کنیم که ماشین ها روشن و وضعیت VCHA در حالت فعال هست .

عملیات پیاده سازی VCHA با موفقیت انجام شد . در صورت بروز هر گونه مشکلاتی که بالاتر اشاره شد ، نود passive به صورت اتوماتیک نقش active به خود می گیره . البته در صورتی که بخواهیم به صورت manual نود passive را active کنیم ، از initiate Failover میشه استفاده کرد . پس برای اینکه به صورت دستی این عملیات رو انجام بدم ، روی گزینه Initiate Failover کلیک می کنم .

در پنجره باز شده بر روی yes کلیک می کنیم تا به صورت manual نود passive نقش active به خود بگیرد . در ضمن میشه توی این قسمت مشخص کنیم تا بدون در نظر گرفتن synchronization بین نود active و passive این تغییر در زمان هر چه کمتر صورت بگیره .

پس از تغییر manual ، مدت زمانی طول میکشه تا بتونیم مجددا به vCenter متصل بشیم . با اندکی صبر و اتصال مجدد به vCenetr مشاهده میشه که نود ۱۷۲٫۱۹٫۲۲۰٫۱۰ که قبلا نقش Active داشت به Passive تغییر وضعیت داده و نود ۱۷۲٫۱۹٫۲۲۰٫۲۰ که قبلا نقش Passive داشت به Active تغییر وضعیت داده و دقیقا انتظاری که داشتیم همین بود .

خوب تغییر دستی نقش نودها رو با هم بررسی کردیم .
پس از راه اندازی ، به صورت اتوماتیک یک anti-affinity Rule ساخته شده و مشخص می کنه که ماشین مربوط به نودها در یک هاست و کنار هم قرار نگیرن  . anti-affinity Rule ها بیشتر برای سرویس هایی که در اون ها از کلاسترینگ در سطح سرویسی اعمال میشه استفاده می کنیم جهت high available بودن اون سرویس مثل کلاسترینگ در سطح SQL یا Exchange و …
مشخصه که اگه application یا سرویسی رو کلاستر کنیم از تعدادی نود یا سرور مجزا تشکیل میشه دقیقا مشابه کاری که ما تو این سناریو انجام دادیم . پس بهتر هست که این نودها جداگانه در
و در واقع هر نود در یک هاست مستقل باشه که در شکل زیر این موضوع مشخصه .

شاید براتون سوال پیش بیاد که اگر روزی قرار به خاموشی نودها باشه بنا به هر دلیلی ، ترتیب خاموش شدن باید به چه صورتی باشه و اگر قرار باشه که نودها رو روشن کنیم ترتیب به چه صورتی هست . برای خاموش کردن نودها و جهت اینکه جلوگیری بشه از اینکه نود Passive نقش Active بگیره ، باید ابتدا نود Passive ، سپس نود Active و نهایتا Witness را خاموش کنیم . خوب مشخصه که در صورتی که نود Active رو خاموش کنیم درون کلاستر چون نود Active روشنی نخواهیم داشت ، پس نود Passive بلافاصله تصمیم به تغییر وضعیت به Active خواهد کرد . پس باید همیشه در پروسه های خاموشی به ترتیبی که بیان شد عمل کرد . در مورد روشن شدن نودها باید این نکته رو بگم که هیچ تفاوتی در ترتیب روشن شدن وجود نداره و به هر ترتیب دلخواهی می تونیم نودها رو روشن کنیم .

در نهایت برای مانیتور کردن vCenter Srver High Availability میتونیم از قسمت مانیتورینگ vCenter وضعیت نودها رو ببینیم .

خوب ، امیدوارم این مقاله برای شما مفید واقع شده باشه . البته موارد جزئی بشتری  رو در مورد vCenter Server High Availability می شه بررسی کرد که توی این مقاله سعی شده به صورت ساده موارد بیان بشه . اگر سوالی در زمینه این مقاله وجود داره در قسمت نظرات بیان کنید تا بتونیم از این راه دانش خودمون رو بالاتر ببریم .
با مقالاتی دیگر در زمینه مجازی سازی در کنار شما خواهم بود .

نویسنده : محمدرضا ملک احمد