نگاه عمیق به قابلیت VCHA – بخش 1

قابلیت vCenter High Availability) VCHA) در نسخه vSphere 6.5 در نوامبر 2016 معرفی شد. از آن زمان تیم بازاریابی فنی VMware زمان زیادی را صرف ایجاد محتوا و صحبت در مورد VCHA کرده است. اما با تمام اینها هنوز پرسش های رایج و تصورات غلط در مورد این ویژگی وجود دارد. در این سری از مقالات وبلاگ، ما در مورد تفاوت میان استقرار ساده و پیشرفته ، ملاحظات توسعه ، و جنبه های عملیاتی VCHA بحث خواهیم کرد.

ابتدایی در مقابل پیشرفته

یکی از شایع ترین سوالاتی که ما دریافت می کنیم و تصورات غلطی که من میشنوم این است که به منظور دریافت تمام ویژگی های VCHA ، شما برای راه اندازی باید مراحل پیشرفته را طی کنید. این کاملا نادرست است. در حقیقت VCHA ، بدون توجه به نحوه راه اندازی آن ، کاملا یکسان عمل میکند. ما به شدت توصیه می کنم که از روش Basic برای استفاده از VCHA استفاده کنید. به نظر ما بهتر است گزینه (Basic) را خودکار و (Advanced) را دستی نام گذاری کنیم. در حالت Basic ما این تنظیمات را برای شما انجام می دهیم – اضافه کردن NIC دوم ، Clone کردن، تغییر اندازه VM شاهد و تنظیم DRS anti-affinity rules.

با استفاده از تنظیمات پیشرفته، شما باید تمام کارها را به صورت دستی انجام دهید. علاوه بر این، شما باید تنظیماتی را انجام دهید که نیاز به از بین بردن کلاستر VCHA دارد مانند تغییر گواهینامه، تغییر IP سرور vCenter یا بازگرداندن سرور vCenter. اگر از تنظیمات پیشرفته VCHA استفاده می کنید، پس باید برخی ازکارها را دوباره انجام دهید. اما اگر از Basic استفاده می کنید، می توانید VCHA را با انجام 30 ثانیه تنظیمات در حالت آماده به کار داشته باشید.

شما ممکن است به این فکر کنید که “خوب، پس چه زمانی من باید از پیشرفته استفاده کنم؟” حالت پیشرفته برای زمانی که سرور vCenter شما در یک گروه مدیریتی که در دامنه SSO متفاوتی است استفاده میشود. به عنوان مثال : فرض کنید یک Compute vCenter در Management SSO domain داریم ، اما vCenter در فهرست موجودی Management vCenter  و Management SSO domain باید از راه اندازی پیشرفته استفاده کند. اگر این Compute vCenter Server در Domain SSO همانند Server Management vCenter است که VCHA را فعال کرده اید، می توانید از Basic استفاده کنید. دلیل آخر برای اینکه چرا ممکن است از حالت پیشرفته استفاده کنید، این است که آیا میخواهید نودهای VCHA خود را در سایتهای مختلف تقسیم کنید؟ کمی جلوتر به این موضوع خواهیم پرداخت.

هدف این است که بسیاری از مشتریان قادر باشند از Basic استفاده کنند و مجبور به سروکله زدن با تنظیمات دستی پیشرفته نشوند. به یاد داشته باشید که نتیجه یکسان است. VCHA همان VCHA است ، صرف نظر از نحوه راه اندازی آن ، بنابراین فرض نکنید که نیاز به استفاده از حالت پیشرفته را دارید.

 

حفاظت از سرور vCenter با VCHA

این موضوع احتمالا یکی از مواردی است که بیشتر وقت خود را در هنگام صحبت با مشتریان صرف آن می کنید. این موضوع تا حدودی پیچیده است، بنابراین من سعی خواهم کرد آن را به چند بخش تقسیم کنم. اولا، بیایید سعی کنیم و بدانیم چه نقصی در VCHA هست که به ما کمک کند تا در مقابل آن محافظت کنیم. یک نقص VCHA، نقصی از نود Active به Passive باشد، که قابل بازیابی از نقص های زیر می باشد :

  • hardware or complete host failure
  • network failure or isolation
  • storage failures
  • vCenter Server application or service failure
  • operating system failure

 

با توجه به حالت های شکست فوق و توانایی VCHA برای بازیابی از آنها، VCHA می تواند یک راه حل قوی HA برای vCenter Server باشد. با این حال، یک حالت ثانویه وجود دارد که ممکن است در مورد آن تعجب کنید. اگر مکان های مختلفی دارید و میخواهید از سرور vCenter از یک شکست کامل سایت محافظت کنید چه؟ خوب، در واقع این کار ممکن است اما با برخی از هشدارها. مهمترین نکته در هنگام استفاده از VCHA برای محافظت از سرور vCenter ، این است که VCHA یک راه حل HA است و نه راه حلی برای DR. VCHA، اگر به درستی پیکربندی شده باشد، در واقع دستگاه vCenter Server شما را به یک گره متناوب که در مکان دیگری در حال اجرا است، بازیابی می کند. با این حال، تمام حجم کارها و میزبان ها در مکان شکست خورده بدون   DR Orchestration باقی خواهند ماند. بنابراین، من توصیه می کنم به جای استفاده از VCHA تنها ، از استراتژی کامل DR Orchester برای محافظت از سرور vCenter در برابر شکست سایت استفاده کنید.

نکات دیگر که باید به آن توجه داشته باشید ، نیاز به زمان RTT  10ms بین هر سه گره ، همراه با درک اثرات شبکه شبکه VCHA است. اگر Stretched L2 وجود نداشته باشد (از طریق تکنولوژی های معمولی مانند OTV سیسکو یا پوشش مانند VXLAN) در نتیجه آدرس IP سرور vCenter باید در رویدادfailover  تغیر کند. این بخش برای شما اتوماتیک است، اما آنچه که به صورت خودکار انجام نمی شود، DNS است. A رکورد برای vCenter Server توسط هرآنچیزی که DNS سرور در محیط شما استفاده میکرد کنترل می شود و حتی اگر شما بتوانید به روز رسانی این رکورد A را به آدرس IP جدید به صورت خودکار ارتقا دهید ، هنوز احتمال حقیقی آن وجود دارد که با توجه به DNS TTL ، propagation و  caching ، مشکلات گذرا ایجاد شود. ممکن است که این مکانیسم های DNS گذرا ، از راه اندازی درست نود پسیو جلوگیری کند ، که من فکر می کنم راه حل HA در وهله اول این مورد را نفی می کند.

اگر شما شبکه L2 را بین سایت های خود کشیده باشید ، اقدامات شما کمتر میشود زیرا میتوانید از تغیر IP سرور Vcenter و همچنین رکورد DNS در هنگام بروز مشکل پرهیز کنید. همچنین به یاد داشته باشید که برای تقسیم گره ها در سراسر سایت ها، شما باید از جریان پیشرفته استفاده کنید. این بدان معنی است که هر بار که شما ارتقا می دهید، باید گواهینامه را جایگزین کنید، یا لازم است مجددا کلاستر VCHA را re-deploy ، VM ها را به صورت دستی کلون کنید، آنها را به جایی که باید در آن اجرا شوند منتقل کنید، Witness  را تغییر اندازه بدهید، و همه قوانین DRS را مجدد تنظیم کنید که این کار بسیار زیادی است، پس فقط از آنچه در پیش رو دارید، آگاهی داشته باشید.

در ایجا یک سناریو اتفاق می افتد ، جایی که فکر می کنم چینش گره های VCHA در سراسر سایت های مختلف می تواند کار کند. اگر در حال استفاده از stretched cluster یا vMSC هستید ، تنظیمات شما برای VCHA بهتر است . اتصالات L2 بین سایت ها برای stretched clusters و همچنین  stretched storage یک الزام است. این امر فرایند جابجایی نودها به جایی که باید بروند را بسیار آسان تر کرده ، و نیازی به اضافه کردن پیچیدگی های تغییر IP و DNS ندارد. شما می توانید قوانین DRS خود را دوباره تنظیم کنید تا نود ها به گروه های هاست خاصی در هر طرف متصل شوند. اما شما هنوز هم باید از جریان کار پیشرفته در این سناریو استفاده کنید ، زیرا شما نیاز به یک سایت سوم برای VM شاهد دارید و استفاده از جریان پیشرفته تنها راه رسیدن VM شاهد به سایت سوم است. یک استثناء اتفاق می افتد اگر شما یک سایت سوم داشته باشید که stretched L2  را از دو سایت دیگر داشته باشد.

 

جمع بندی

تا این جا خواندید که چندین بار گفتیم که vCenter High Availability یک راهکار high availability است نه یک راهکار disaster recovery . این نشان دهنده این واقعیت است که VCHA تنها از vCenter Server محافظت می کند ، نه حجم کار یا میزبانی که توسط آن مدیریت می شود.  همچنین تعداد قابل توجهی از Task ها برای راه اندازی VCHA به منظور کار در سایت ها و همچنین تلاش های عملیاتی اضافی دیگر برای حفظ از آن وجود دارد ، برای مثال نیاز به استفاده از Advanced Workflow . هنگام استقرار VCHA سعی کنید از جریان کار Basic  استفاده کنید تا در صورت امکان بتوانید راه حل را برای نگهداری و استقرار آسان تر کنید. از سرور vCenter در یک سایت که احتمال بالایی در بروز مشکلات سخت افزار، شبکه یا ذخیره سازی دارید محافظت کنید.

در قسمت دوم این مقاله بیشتر ، درباره برخی از جنبه های عملیاتی ، مانند پشتیبان گیری و بازیابی، پچ کردن و ارتقاء به VCHA cluster صحبت خواهیم کرد.

0 پاسخ

دیدگاه خود را ثبت کنید

Want to join the discussion?
Feel free to contribute!

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *