شرح سرویس VMware HA
به طور کلی می توان گفت سرویس HA در حال کار بودن دائمی ماشین های مجازی را تضمین می کند. با این توضیح که این سرویس سیستم های میزبان را که از طرف مدیر سیستم مشخص شده در یک کلاستر قرار می دهد و به طور دائمی آنها را مانیتور می کند. هر گاه مشکلی برای میزبان مربوطه پیش بیاید و به هر دلیل از مدار خارج شود^[۱۶۰]، این سرویس ماشین های مجازی در حال اجرا بر روی سیستم میزبان مختل شده را به سرعت بر روی سیستم های دیگر راه اندازی می کند ]۶۱[.

مفهوم میزبانان اصلی^[۱۶۱] و میزبانان ثانویه^[۱۶۲]
وقتی مدیر سیستم در زمان راه اندازی اولیه دیتا سنتر و یا پس از آن در هنگام کار آن میزبانی را به یک کلاستر HA اضافه می کند، یک agent بر روی میزبان نصب می شود که وظیفه برقراری ارتباط با بقیه میزبانان حاضر در آن کلاستر را بر عهده دارد. به طور قراردادی، پنج میزبان اول در کلاستر به عنوان میزبانان اصلی و بقیه میزبانان افزوده شده به کلاستر به عنوان میزبانان ثانویه معین می شوند. میزبانان اصلی وظیفه اطلاع رسانی در مورد وضعیت کلاستر به همه میزبانان را بر عهده دارند . همچنین در صورت بروز مشکل و اختلال برای یکی از اعضای کلاستر، این میزبانان اصلی هستند که پروسه failover را شروع و سازمان دهی می کنند. اگر یکی از میزبانان اصلی به هر دلیل از مدار خارج شود (مثلا به دلیل بروز اختلال و یا خاموش شدن عمدی با هدف تعمیر و نگهداری) سرویس HA یکی از میزبانان ثانویه را به عنوان میزبان اصلی منسوب می کند.
هر میزبانی که عضو یک کلاستر HA می شود باید لزوما با یکی از میزبانان اصلی ارتباط برقرار کند تا پیکربندی سرویس HA بر روی آن تکمیل گردد. این وضعیت در مورد اولین میزبانی که به یک کلاستر اضافه می شود استثنا است. باید توجه داشت که وجود حداقل یک میزبان اصلی در یک کلاستر برای کارکرد درست آن ضروری است. به این معنی که اگر همه میزبانان اصلی غیر قابل دسترسی شوند و قادر به پاسخگویی نباشند، هیچ میزبان دیگری نمی تواند عضو کلاستر مذکور شود.
یکی از سیستم های میزبان اصلی به عنوان میزبان اصلی فعال^[۱۶۳] معین می شود و وظایف زیر را بر عهده خواهد داشت:
تصمیم گیری در مورد اینکه ماشین های مجازی مربوط به یک میزبان مختل شده در کجا و روی کدام میزبان باید دوباره راه اندازی شوند
به خاطر نگه داشتن وضعیت ماشین های مجازی و میزبانانی که در مرحله راه اندازی مجدد (restart) دچار اختلال شده اند.
تعیین اینکه چه زمانی برای تلاش مجدد برای restart یک ماشین مجازی مناسب است.
اگر یک میزبان اصلی فعال دچار مشکل شده و از مدار خارج شود، یک میزبان اصلی دیگر جای آن را می گیرد.
در این بخش با دقیقتر شدن روی مدل ارائه شده در بخش قبل، به مدل سازی و تحلیل نحوه کار سرویس HA در دیتا سنتر نمونه خواهیم پرداخت. این مدل در واقع شرح نحوه انتقال کنترل در مجموعه وظایف خلاصه شده در گزارهای بین موقعیت های P43 و P44 از مدل شکل ۴٫۴ است. به عبارت دیگر، P0 در این مدل معادل P43 در مدل ۴٫۴ می باشد.
تشخیص خطا و ایزوله شدن میزبان از شبکه
Agent ها با یکدیگر ارتباط برقرار می کنند و به این ترتیب از فعال و سالم بودن میزبانان عضو کلاستر مطمئن می شوند. این فرایند با تبادل سیگنال های ضربانی^[۱۶۴] که به طور پیش فرض هر ۱ ثانیه یک بار انجام می شود صورت می پذیرد. اگر با گذشت یک بازه زمانی ۱۵ ثانیه ای هیچ سیگنالی از طرف یک میزبان دریافت نگردد، و پس از آن میزبان مذکور به درخواست ping جواب ندهد، این میزبان یک کامپیوتر از کار افتاده و از مدار خارج شده محسوب می شود. در صورت از کار افتادن یک میزبان، کلاستر تلاش می کند تا ماشین های مجازی در حال کار روی آن میزبان را رفع ایراد^[۱۶۵] نماید. به این معنی که این ماشین ها را بر روی میزبانان دیگری که منابع آزاد یا رزرو شده دارند restart نماید. همانطور که در فصل قبلی اشاره شد منظور از منابع در اینجا به طور اعم پردازنده و حافظه می باشد.
ایزوله شدن یک میزبان از شبکه هنگامی رخ می دهد که میزبان کاملا سالم و در حال کار است اما نمی تواند با هیچ یک از میزبانان دیگر در کلاستر ارتباط برقرار کند و سیگنال ضربانی را مبادله نماید. به طور پیش فرض اگر میزبانی به مدت ۱۲ ثانیه سیگنالی از هیچ یک از میزبانان حاضر در کلاستر دریافت نکند، تلاش می کند تا آنها را ping نماید. در صورت عدم موفقیت در دریافت جواب ping (ping reply)، خود را به عنوان یک میزبان ایزوله شده از شبکه شناسایی می کند.
در صورتی که میزبان ایزوله شده نتواند ارتباط خود با شبکه و بقیه میزبانان کلاستر را در طول یک بازه زمانی ۱۵ ثانیه ای دوباره برقرار کند، میزبانان دیگر کلاستر آن را به عنوان یک میزبان از کار افتاده تلقی کرده و تلاش خواهند کرد تا ماشین های مجازی روی آن را رفع ایراد کنند. اما با توجه به اینکه میزبان ایزوله شده هنوز فعال است و به منبع ذخیره سازی مشترک دسترسی دارد، این میزبان هنوز کنترل فایل های مربوط به ماشین های مجازی خود را در اختیار دارد و این فایل ها برای میزبان مذکور قفل هستند. لازم به توضیح است که برای جلوگیری از تخریب داده های مربوط به ماشین های مجازی و فایل های آنها، VMFS مکانیزمی برای جلوگیری از دسترسی همزمان چندین میزبان به یک ماشین مجازی دارد که توسط آن، فایل های مربوط به یک ماشین مجازی در حال کار را قفل می کند تا میزبانان دیگر نتوانند عملیات خواندن و نوشتن انجام دهند^[۱۶۶]. بنابراین تلاش برای راه اندازی مجدد ماشین های مجازی در حال کار بر روی یک میزبان ایزوله شده با شکست روبرو خواهد شد. برای رفع این مشکل، میزبان ایزوله شده پس از اطمینان از وضعیت قطعی خود از شبکه، اقدام به خاموش کردن ماشین های مجازی خود می کند. به این ترتیب قفل مربوط به فایل ماشین های مذکور آزاد شده و آنها می توانند بر روی میزبانان در حال کار دیگر در کلاستر راه اندازی شوند.
استفاده همزمان VMware HA و DRS
استفاده همزمان سرویس HA و سرویس زمان بندی تخصیص منابع (DRS) در یک دیتا سنتر، امکان ترکیب رفع اشکال اتوماتیک ماشین های مجازی را به همراه ایجاد تعادل در بار اجرایی بر روی منابع^[۱۶۷] فراهم می نماید. ترکیب درست این دو سرویس به ما امکان متعادل کردن سریع تر بار وارد شده از سوی ماشین های مجازی به میزبانان، بعد از انتقال آنها توسط سرویس HA از یک میزبان به میزبان دیگر را می دهد.
بعد از اینکه سرویس HA فرایند رفع اشکال یک میزبان از کار افتاده را انجام داد و ماشین های مجازی وی را بر روی میزبانان سالم کلاستر راه اندازی نمود، اولین اولویت اجرایی آن، فراهم کردن امکان دسترسی به همه ماشین های مجازی مذکور^[۱۶۸] خواهد بود. پس از اینکه ماشین های مجازی روی میزبانان جدید مجددا راه اندازی شد، میزبانان جدید این ماشین ها ممکن است به شدت تحت فشار کمبود منابع باشند در حالی که میزبانان دیگری در کلاستر بار پردازشی کمی دارند. باید توجه داشت که سرویس HA با توجه به میزان پردازنده و حافظه رزرو شده اقدام به انتقال ماشین ها می کند ولی میزان مصرف واقعی منابع توسط ماشین های مجازی ممکن است با این تخمین متفاوت باشد.
همچنین ذکر این نکته ضروری است که در فرایند انتقال ماشین های مجازی به وسیله سرویس HA و برقراری تعادل در منابع مصرفی میزبانان توسط سرویس DRS، اعمال گفته شده در مورد میزبانانی که در وضعیت نگهداری^[۱۶۹] هستند انجام نخواهد شد. به عبارت دیگر ماشین های مجازی از روی این میزبانان تخلیه نمی شوند. این امر به دلیل حفظ منابع رزرو شده برای مرحله رفع اشکال انجام می شود. در صورت نیاز به انتقال این ماشین های مجازی، مدیر سیستم باید این کار را به صورت دستی و به کمک سرویس VMotion انجام دهد.
در ادامه این بخش به طراحی یک مدل فرمال و تحلیل رفتار های سرویس VMware HA بر روی مدل مربوطه خواهیم پرداخت.

ارائه مدل فرمال از نحوه کار سرویس HA
در این قسمت به ارائه مدلی فرمال از سرویس VMware HA به کمک ابزار شبکه های پتری می پردازیم تا بتوانیم تصویر دقیقتری از نقاط ضعف و نحوه کار آن به دست آوریم.
با توجه به نحوه کار شرح داده شده در قسمت قبل، و با این فرض که در دیتاسنتر مربوطه این سرویس همراه با DRS کار می کند، می توان مدل زیر را برای آن ارائه داد.
شکل ۴٫۷٫ مدل پتری نحوه کار سرویس HA
در ادامه به شرح گزارها و مراحل تغییر حالت در سیستم فوق می پردازیم.
T0: سیگنال ضربانی بر روی سیستم های میزبان عضو کلاستر تولید می شود.
T1: سیگنال تولید شده بین سیستم های عضو یک کلاستر HA تبادل می شود
T2: دریافت سیگنال ضربانی به مدل ۱۲ ثانیه از همه سیستم ها قطع می شود.
T3: سیستم میزبان اقدام به ping کردن سیستم های دیگر می کند.
T4: پیام ping reply از سیستم های دیگر دریافت می شود که به معنی برقراری مجدد ارتباط و از بین رفتن اختلال است.
T5: درخواست ping با شکست روبرو می شود که به معنی باقی بودن اختلال است.
T6: سیستم میزبان به مدت ۱۵ ثانیه برای برقراری مجدد ارتباط و دریافت پیام ping reply تلاش می کند.
T7: سیگنال ضربانی دریافت می شود.
T8: در برقراری مجدد ارتباط با دیگر سیستم های کلاستر دچار مشکل می شود.
T9: در این شرایط، با توجه به قطع شدن ارتباط با همه سیستم های میزبان، سیستم مذکور خود را به عنوان یک سیستم ایزوله شناسایی می کند. به این معنی که می فهمد ارتباط خودش با بقیه قطع شده است.
T10: سیستم میزبان ماشین های مجازی خود را خاموش می کند.
T11: ارتباط سیستم میزبان با یکی از سیستم های عضو کلاستر به مدت ۱۵ ثانیه قطع می شود.
T12: کلاستر تلاش می کند تا سیستم ایزوله شده یا از کار افتاده را ایرادیابی نماید. به این معنی که ماشین های مجازی که روی آن در حال کار بوده اند را بر روی میزبانان دیگر که منابع خالی یا رزرو شده دارند راه اندازی می کند.
T13: فرایند ایرادیابی دچار اختلال شده و عقیم می ماند.
T14: فرایند ایرادیابی تکمیل شده و سیگنال ضربانی دوباره تبادل می شود.
T15: در صورتی که سیستم میزبان ازکار افتاده یک میزبان اصلی بوده باشد، برای جبران کمبود تعداد سیستم های اصلی، یکی از سیستم های میزبان ثانویه به میزبان اصلی تبدیل می شود.
با توجه به اینکه مدل فوق زیر مجموعه ای از مدل ۴٫۴ می باشد، برخی از موقیعت ها و گزارها در این مدل با مدل پدر در تناظر هستند. از آن جمله می توان به P0 (معادل P43 در مدل ۴٫۴) و T13 (معادل T56 در مدل ۴٫۴) اشاره نمود. به این ترتیب اگر مدل ۴٫۴ را یک مدل لایه ۱ در نظر بگیریم، طرح جزئیات نحوه کار سرویس HA یک مدل در لایه ۲ به دست خواهد داد که به کمک آن می توانیم جزئیات بیشتری از رفتار سیستم را بررسی نمائیم.
همانگونه که در این مدل مشخص شده است، هیچ راهکاری برای برخورد با وضعیت T13 در سرویس HA وجود ندارد. به عبارت دیگر، در صورت بروز مشکل در رفع اشکال میزبان از کار افتاده و انتقال ماشین های مجازی آن به دیگر میزبانان درحال کار، پروسه HA دچار مشکل می شود و ماشین های مذکور در دسترس نخواهند بود. این وضعیت ممکن است به دلیل عدم وجود منابع مازاد یا رزرو شده بر روی میزبانان یا خاموش نشدن کامل ماشین های مجازی روی میزبان مختل شده رخ دهد.