باید توجه داشت که هنگام تعریف یک کلاستر HA، سیستم با توجه به میزان منابع آزاد سیستم های میزبان اجازه تعریف کلاستر را می دهد. اما ممکن است منابع مورد تقاضای ماشین های مجازی در حین کار بیشتر از تخمین اولیه باشد. بنابراین در هنگام از کار افتادن یک میزبان، بر خلاف انتظار، منابع کافی برای اضافه شده ماشین های در حال انتقال به میزبانان سالم وجود نداشته باشد. همچنین با توجه به قفل شدن فایل های مربوط به ماشین های مجازی در حال کار، همانطور که گفته شد لازم است در ابتدا ماشین های یک میزبان از کار افتاده یا ایزوله شده توسط وی خاموش شوند تا قفل مربوطه توسط VMFS آزاد شود. این کار در مدل ۴٫۷ در گزار T10 انجام می گیرد. اگر در این مرحله به هر دلیل این فرایند خاموش شدن کامل نشود، قفل دیسک آزاد نشده و این ماشین نمی تواند بر روی میزبان دیگری راه اندازی مجدد شود. این اختلال در فرایند خاموش شدن می تواند به اختلال داخلی سیستم عامل ماشین مجازی یا عدم کارکرد صحیح سخت افزارهای مجازی این ماشین مربوط باشد.

در سایر موارد می توان روال منظمی را در انتقال کنترل در این پروسه مشاهده کرد. همچنین لازم به یادآوری است که این مدل تنها روند اجرای سرویس HA در هنگام بروز مشکل را نشان می دهد. بنابراین برای توصیف شیوه افزودن یک میزبان به کلاستر HA و یا تعریف یک کلاستر جدید در حین کار دیتا سنتر، نیاز به طراحی مدل مجزایی می باشد.
در قسمت بعدی از این بخش، به تحلیل و ارزیابی مدل طراحی شده در این قسمت خواهیم پرداخت.

تحلیل و ارزیابی مدل
در این بخش با تحلیل خصوصیات رفتاری مدل میزان انعطاف پذیری و پایداری آن و در نهایت خوش رفتاری سیستم را بررسی خواهیم کرد. به همین منظور خصوصیات Liveness، Safeness و Reversibility را بر روی آن بررسی می نمائیم.
۴٫۳٫۳٫۱٫ Liveness
برای بررسی خصوصیت Liveness، باید به این نکته توجه داشته باشیم که یک شبکه live از درجه k است در صورتی که تمام گزارهای آن شبکه live از درجه k باشند ]۲۳[. به این ترتیب روشن ترین راهی که برای تعیین میزان Liveness شبکه های پتری به نظر می رسد، بررسی تک تک گزارهای آن از نقطه نظر میزان liveness است. اما به دلیل پیچیده و وقت گیر بودن این شیوه، قضایایی برای اثبات کلیت liveness در شبکه ها، در صورتی که آنها از زیرمجموعه های معینی از شبکه های پتری باشند ارائه شده است. این زیر مجموعه ها که در فصل ۲ معرفی و بررسی شدند، ویژگی های خاصی را به طور مشترک دارا می باشند.
به این ترتیب برای بررسی خصوصیت، در ابتدا سعی می کنیم با بررسی ویژگی های ساختاری شبکه مورد نظر، آن را در یکی از این زیر مجموعه ها طبقه بندی کنیم و سپس با بهره گرفتن از قضایای آن زیر مجموعه خصوصیات مذکور از جمله Liveness را راحت تر بر روی آن بررسی نمائیم.
با دقت بیشتر خواهیم فهمید که مدل شکل ۴٫۷ یک state machine است زیرا هریک از گزارها در این شبکه تنها یک ورودی و یک خروجی دارند. عضویت این مدل در دیگر زیرمجموعه های شبکه های پتری در شکل ۴٫۸ آمده است. این طبقه بندی توسط نرم افزار PIPE انجام شده است.
شکل ۴٫۸٫ عضویت شبکه ۴٫۷ در زیرکلاس های شبکه های پتری
پس با تکیه بر قضیه ۴ از فصل ۲، با توجه به اینکه در وضعیت M₀ یک توکن در شبکه وجود دارد، اگر این شبکه متصل قوی باشد بنابراین live نیز هست.
همچنین با مقایسه قضیه ۱ و بسط آن در همان فصل می توان نتیجه گرفت که شرط لازم برای متصل قوی بودن یک شبکه، عدم وجود موقعیت source و sink و نیز گزار source و sink در شبکه است. در چنین شرایطی شبکه ۴٫۷ متصل قوی نمی باشد زیرا P11 در آن یک موقعیت sink محسوب می شود.
در نتیجه بر اساس قضیه ۴، این شبکه خصوصیت Liveness را ندارد. این امر به این دلیل است که در صورت بروز اختلال در دریافت منابع کافی برای راه اندازی سیستم ثانویه، پروسه HA دچار مشکل خواهد شد. با توجه به این مشکل، مدل متناظر، خاصیت Liveness را از دست می دهد.
۴٫۳٫۳٫۲٫ Safeness
در این مرحله با بررسی قضیه ۲ در همان بخش می توانیم خاصیت safeness را در مدل بررسی نمائیم. برای این کار لازم است گراف پوشای مدل را به دست آوریم. با بهره گرفتن از نرم افزار PIPE این گراف به صورت شکل ۴٫۹ خواهد بود.
شکل ۴٫۹٫ گراف پوشای مدل ۴٫۷
با بررسی این گراف در میابیم که برچسب همه گره های آن حاوی مقادیر ۰ و ۱ برای موقعیت های P0 تا P10 هستند. به این معنی که تعداد توکن های موجود در این موقعیت ها، در هیچ وضعیتی بیش از ۱ نبوده است. با این دلیل، مدل همواره ۱-bounded یا به عبارت دیگر safe می باشد.
با مقایسه نتیجه حاصل از این دو قضیه می توان فهمید که مدل به دلیل وجود بن بست، دارای خاصیت liveness نیست. به کمک نرم افزار تحلیلگر PIPE می توان مسیری را که مدل طی آن دچار بن بست می شود مشخص کرد. (شکل ۴٫۱۰)
شکل ۴٫۱۰٫ نتیجه تحلیل فضای حالت بر روی مدل
طبق این تحلیل، با طی دنباله گزارهای T0، T11، T12 و T13 سیستم دچار بن بست خواهد شد.
۴٫۳٫۳٫۳٫ Reversibility
برای بررسی این خصوصیت لازم است به تعریف Reversibility توجه کنیم. با یاد آوری تعریف این مفهوم و نیز خاصیت Reachability از فصل ۲ داریم: شبکه پتری ()، Reversible خوانده می شود اگر برای هر وضعیت M، در دنباله قابل اجرا از (R())، از طریق M، reachable باشد.
با این تعریف، در شبکه های کوچک می توان با بررسی کلیه وضعیت های محتمل در شبکه، reachable بودن را از طریق آنها بررسی نمود. در صورتی که از طریق تک تک این وضعیت ها ( تا ) قابل دسترسی باشد این شبکه Reversible است. با توجه به اینکه این وضعیت ها تماما در گراف پوشای مدل منعکس می شوند می توان با بررسی یک به یک گره های گراف این حالات را بررسی نمود.
به همین منظور و با بررسی گراف شکل ۴٫۹، در می یابیم که کلیه وضعیت ها غیر از S8 می توانند کنترل سیستم را به S0 () بازگردانند. نحوه توزیع توکن در S8 در شکل ۴٫۱۱ آمده است.
شکل ۴٫۱۱٫ نحوه توزیع توکن در وضعیت S8
لازم به ذکر است که مفهوم S (State) در نرم افزار مدل سازی PIPE، متناظر با مفهوم M (Marking) یا همان “وضعیت” است که قبلا درمورد آن توضیح داده شده است.
با این تفسیر، می توان دریافت که دقیقا زمانی که پس از اجرا شدن T13 توکن در موقعیت P11 قرار می گیرد، سیستم دیگر قابل بازگشت به وضعیت اولیه نخواهد بود. به این ترتیب می توان دریافت که مدل ۴٫۷ دارای خاصیت Reversibility نمی باشد.
■
در مرحله آخر با شبیه سازی اجرای سیستم در چند مرحله متفاوت، نحوه توزیع توکن ها در شبکه را در حین اجرای سیستم بررسی می کنیم. برای این کار در هر مرحله، پنج بار مدل را از نقطه آغاز (P0) اجرا می کنیم و حداکثر ۱۰۰ اجرا بر روی گزارهای مدل انجام می دهیم. نتیجه به صورت شکل ۴٫۱۲ خواهد بود.
شکل ۴٫۱۲٫ شبیه سازی شبکه پتری شکل ۴٫۷
همانطور که دیده می شود توزیع توکن ها در موقعیت های شبکه به طور یکنواخت انجام شده است که این امر به دلیل یکسان بودن اولویت اجرای گزارهای سیستم است. با این حال تضمینی برای تکرار شدن این نتیجه در اجراهای بعدی وجود ندارد زیرا ممکن است با قرار گیری سیستم در موقعیت P9، گزار T13 اجرا شده و توکن از شبکه حذف شود. همچنین با اجرا شدن T4 و یا T7، همه گزارهای بعد از آنها (T6، T8 و …) امکان اجرا شدن نخواهند داشت. به همین دلیل بهتر است فرایند شبیه سازی را چندین بار تکرار کنیم تا حالات بیشتری از توزیع توکن ها در شبکه را ببینیم. نتیجه چهار اجرای مختلف از شبیه سازی مدل مذکور در شکل ۴٫۱۳ آمده است.
شکل ۴٫۱۳٫ چندین نمونه از شبیه سازی اجرای شبکه پتری
همانطور که دیده می شود، در اجرای دوم، تنها حلقه T0، T1 اجرا شده اند و در مواقعی نیز با اجرای T11 و T12 سیستم به وضعیت بن بست رسیده است. در اجرای سوم، با اجرا شدن T4 امکان قرارگیری توکن در P4 تا P7 از بین رفته است. و در نهایت در اجرای چهارم از شبیه سازی، با اجرای T11، هیچ توکنی در موقعیت های P2 تا P7 قرار نمی گیرد. البته باید توجه داشت که هر یک از این مرحله ها با اجرای پنج مرتبه این مدل به دست آمده اند.
در صورت تغییر اولویت اجرای گزارها در سیستم می توان میزان حضور توکن را در موقعیت ها تغییر داد. اما این تغییر در اولویت باید بر مبنای یک الگوی قابل تعریف باشد.

بررسی نحوه کار سرویس Fault Tolerance
سرویس Fault Tolerance (FT) به منظور ایجاد اطمینان از همیشه در دسترس بودن ماشین های مجازی حیاتی که بر روی میزبانان در حال کار هستند طراحی شده است. این میزبانان در حال سرویس دادن به ماشین های خود از طریق ESX هستند. سرویس FT سطح بالاتری از دسترس پذیری را نسبت به سرویس HA فراهم می کند به این معنی که مدت زمان خرابی سیستم در هنگام استفاده از این شیوه بسیار کاهش می یابد.
در ادامه این بخش به بررسی ساختار فنی FT و نحوه سرویس دهی آن می پردازیم ]۶۱[.

تشریح ساختار سرویس Fault Tolerance
سرویس FT به کمک ایجاد و نگهداری یک ماشین مجازی ثانویه، امکان دسترسی پذیری دائمی را برای ماشین های مجازی مورد نظر به وجود می آورد. این کپی ثانویه از ماشین مجازی اصلی کاملا همسان با ماشین اولیه بوده و مانند آن همواره در حال اجرا و در دسترس است. ماشین ثانویه همیشه آماده جایگزین شدن به جای ماشین اولیه در صورت بروز هرگونه اختلال برای نمونه اصلی است.
مدیر سیستم می تواند این امکان را برای ماشین های مجازی حساس و حیاتی که همیشه باید در حال سرویس دهی باشند راه اندازی نماید. نسخه کپی شده ماشین اصلی که ماشین ثانویه خوانده می شود توسط سرویس FT روی میزبانی متفاوت با میزبان ماشین اصلی ایجاد شده و به موازات ماشین اصلی کار می کند. سرویس VMware vLockstep تمام ورودی ها و اتفاقات در حال وقوع روی ماشین اصلی را ضبط کرده و برای ماشین ثانویه می فرستد. با این اطلاعات ماشین ثانویه قدم به قدم مطابق ماشین اولیه دستورات را اجرا می کند.