ماشین های اصلی و ثانویه به طور مداوم سیگنال های ضربانی را با یکدیگر تبادل می نمایند. تبادل سیگنال به این جفت ماشین مجازی امکان می دهد که وضعیت یکدیگر را مانیتور کرده و از اجرای دقیق سرویس FT مطمئن شوند. در صورتی که ماشین مجازی اصلی به هر دلیل از کار بیفتد یا از مدار خارج شود یک فرایند رفع اشکال به صورت پنهان از دید بقیه اجزای سیستم و نیز کاربران انجام خواهد شد^[۱۷۰]. به این معنی که به صورت آنی ماشین ثانویه جای ماشین اولیه را گرفته و به جای آن وظایف محوله را انجام و به درخواست ها پاسخ می دهد. همانطور که پیشتر گفته شد، کاربران هیچ تاخیر یا وقفه ای را در دریافت سرویس از ماشین مربوطه حس نخواهند کرد.
همانطور که می توان حدس زد، ماشین مجازی انتخاب شده برای اعمال سرویس FT و نیز کپی ثانویه آن نمی توانند بر روی یک میزبان واحد اجرا شوند. زیرا در صورت بروز اختلال در میزبان مذکور، هر دو عضو این جفت FT از کار خواهند افتاد. به همین دلیل سرویس FT قوانین جلوگیری از اجتماع همبستگان^[۱۷۱] را در مورد جفت های FT اجرا می کند تا از اجرای ماشین های مجازی عضو یک جفت روی میزبانان جداگانه مطمئن شود.

در این میان احتمال بروز یک خطر سرور مذکور را تهدید می کند و آن احتمال بروز پدیده “دو مغزی”^[۱۷۲] در مورد سرور است. با این توضیح که اگر پس از انتقال کنترل اجرا و سرویس دهی از ماشین اصلی به ماشین ثانویه، ماشین اصلی رفع اشکال شده و دوباره به مدار برگردد و شروع به سرویس دهی نماید، در این حالت ما دو کپی از یک ماشین را خواهیم داشت که هر دو در حال پاسخگویی به یک نوع درخواست هستند. برای جلوگیری از این حالت از قفل کردن فایل مربوط به ماشین اصلی بر روی منبع ذخیره سازی مشترک استفاده می شود تا رفع ایراد ماشین را با اجرای ماشین فعلی هماهنگ کرده و تنها اجازه اجرای یک ماشین را به عنوان ماشین اصلی در یک جفت FT بدهد. بنابراین پس از انتقال کنترل اجرا از ماشین اصلی از کار افتاده به ماشین ثانویه در حال کار، این ماشین به عنوان عضو اصلی ثبت شده و یک ماشین مجازی دیگر به عنوان ماشین ثانویه جدید کپی می شود.
موارد کاربرد سرویس Fault Tolerance
استفاده از سرویس FT در چند حالت می تواند برای ایجاد پایداری و دسترس پذیری ماشین های مجازی پر اهمیت و مفید باشد.
با توجه به اینکه سرویس FT سطح بالاتری از از پیوستگی اجرایی^[۱۷۳] را نسبت به سرویس HA در اختیار سیستم قرار می دهد، می تواند برای اطمینان از فعال بودن دائمی سرویس های بسیار ضروری سازمان مورد استفاده قرار گیرد. وقتی که از ماشین ثانویه خواسته می شود که جای ماشین اصلی را بگیرد، این ماشین به سرعت در وضعیت ماشین اصلی قرار گرفته و تمام وظایف وی را انجام می دهد. برنامه های اجرایی و سرویس ها در این لحظه بر روی ماشین ثانویه در حال اجرا هستند و داده های لازم بر روی حافظه کاری این ماشین وجود دارد زیرا در واقع حافظه ماشین ثانویه آینه ای از حافظه ماشین اولیه بوده است.
این شیوه، تفاوت اساسی را در مقایسه با روش سرویس HA در رفع اشکال ماشین ها ایجاد می کند. زیرا در مکانیزم HA نیاز به زمان بیشتری برای راه اندازی دوباره ماشین ها بر روی یک میزبان جدید وجود دارد که بخش زیادی از این زمان نیز به مدت زمان لازم برای بوت شدن سیستم عامل ماشین بستگی دارد. همچنین در صورت ایزوله شدن یک میزبان، باید زمان لازم برای خاموش شدن ماشین های مجازی بر روی میزبان ایزوله شده برای آزاد شدن قفل مربوط به فایل ماشین مذکور را نیز به زمان تاخیر اضافه نمود. این در حالی است که مدت زمان تاخیر برای سرویس FT در صورت بروز خرابی، صفر خواهد بود.
در مقابل باید توجه داشت که این سطح از دسترس پذیری و امنیت اجرایی سرویس ها، مستلزم نگهداری و اجرا کردن دو نسخه از یک ماشن مجازی است که هر یک منابع کافی را برای اجرا طلب می کنند. بنابراین تعریف جفت های FT باید طبق یک برنامه مدون و با توجه به منابع موجود سخت افزاری صورت پذیرد.
سرویس FT در مورد سناریوهای زیر می تواند بسیار سودمند باشد.
برنامه های کاربردی که لازم است همیشه در دسترس باشند. به خصوص آنهایی که اتصالات طولانی مدت با سیستم کاربران برقرار می کنند و اختلال در سرویس می تواند باعث ایجاد قطعی کامل سرویس دهی به کاربر شود.
نرم افزارهای کاربردی که روش دیگری برای ایجاد کلاستر در مورد آنها وجود ندارد.
حالت هایی که امکان high availability باید از طریق شیوه های اختصاصی خود نرم افزار انجام شود و پیکر بندی کردن با این شیوه ها بسیار پیچیده و هزینه بر است.
ارائه سرویس Fault Tolerance بر حسب مورد^[۱۷۴]
یکی دیگر از موارد مورد نیاز در استفاده از سرویس FT مواردی است که یک ماشین مجازی در بازه های زمانی خاصی در حال ارائه سرویس ضروری می باشد ولی در مواقع دیگر سرویس این ماشین چندان حیاتی نیست. در چنین حالاتی احتمالا ماشین مذکور به طور عادی توسط یک کلاستر HA محافظت می شود ولی در این مواقع حساس نیاز به مراقبت و دسترس پذیری بیشتری دارد.
به عنوان مثال وقتی مدیر سیستم تصمیم دارد یک اخبار تلویزیونی را در ساعت پربیننده پخش کند، سرویس ماشین مربوطه باید در طی چند دقیقه پخش اخبار به شدن محافظت شده و از کار نیافتد. اما در ساعات دیگر این سرویس مورد نیاز نیست. به کمک یک امکان در سرویس FT، مدیر می تواند در زمان پخش اخبار ماشین مجازی مربوط به این سرور را با سطح بالاتری از دسترس پذیری حفاظت نماید و پس از پایان برنامه سرویس FT را بر روی این ماشین غیر فعال کرده و آن را به وضعیت عادی مراقبتی بازگرداند.

ارائه مدل فرمال از نحوه کار سرویس Fault Tolerance
در این بخش به ارائه مدلی فرمال برای تحلیل رفتار سرویس Fault Tolerant خواهیم پرداخت.
این مدل شبکه پتری در شکل شماره ۴٫۱۴ دیده می شود.
شکل ۴٫۱۴٫ مدل پتری نحوه کار سرویس Fault Tolerance
در ادامه به شرح گزارها و مراحل تغییر حالت در سیستم فوق می پردازیم.
T0: سرویس vLockstep ورودی ها و وقایع ماشین مجازی اصلی را ثبت می کند
T1: سرویس vLockstep وضعیت ثبت شده را برای سرویس مشابه در ماشین مجازی ثانویه ارسال می کند
T2: ماشین ثانویه بر اساس صورت وضعیت رسیده، فرمان های مشابه را عینا اجرا می کند
T3: بر اساس سیگنال ضربانی تبادل شده، هر دو ماشین اصلی و ثانویه سالم و در حال کار هستند.
T4: ماشین اصلی دچار اختلال شده و سیگنال ضربانی را برای ماشین ثانویه ارسال نمی کند.
T5: ماشین ثانویه جایگزین ماشین اصلی شده و به جای آن شروع به سرویس دهی می نماید
T6: فایل مربوط به ماشین اولیه توسط VMFS قفل می شود تا از پدیده دو مغزی در ماشین مجازی جلوگیری شود.
T7: ماشین ثانویه که در حال سرویس دهی می باشد به عنوان ماشین اصلی معین می شود و یک ماشین ثانویه جدید به صورت کپی از آن ایجاد شده و شروع به کار می کند.
باید توجه داشت که مدل فوق، در واقع نحوه انتقال کنترل در حین اجرای نرمال سرویس FT می باشد. بنابراین پروسه های مربوط به پیکربندی سرویس نیاز به طراحی مدل های جداگانه دارد. بنابراین مدل های دیگری برای ایجاد جفت FT در مرحله شروع کار دیتا سنتر، ایجاد جفت FT جدید در حین کار دیتا سنتر و نیز راه اندازی سرویس FT بر حسب مورد، باید طراحی شود.
همچنین در این مدل، در موقیعت P4 سیستم با انجام همزمان دو مسئولیت به طور موازی رو بروست. این دو وظیفه شامل انتقال کنترل سرویس دهی از ماشین اصلی به ماشین ثانویه و نیز قفل کردن ماشین اولیه برای جلوگیری از سروس دهی مجدد، همزمان با ماشین ثانویه می باشد. برای مدل سازی این همزمانی در اجرای پروسه لازم است وزن لبه ارتباطی از T4 به P4 برابر ۲ باشد به این معنی که T4 پس از fire شدن دو توکن را در P4 قرار دهد تا به این ترتیب هر دو گزار T5 و T6 فعال شده و امکان fire شدن داشته باشند.
همچنین پس از قرار گرفتن سیستم در موقعیت P5 و اجرای دو وظیفه فوق، برای جلوگیری از بروز سرریز در این موقعیت، لازم است با fire شدن گزار T7 هر دو توکن موجود در این موقعیت مصرف شوند. بنابراین وزن لبه ارتباطی بین P5 و T7 برابر ۲ می باشد.

تحلیل و ارزیابی مدل
در این بخش با تحلیل خصوصیات رفتاری مدل، میزان انعطاف پذیری و پایداری آن و در نهایت خوش رفتاری سیستم را بررسی خواهیم کرد. به همین منظور خصوصیات Liveness، Safeness و Reversibility را بر روی آن بررسی می نمائیم.
در بررسی خصوصیات این شبکه باید توجه داشت که شبکه از نوع عادی نمی باشد زیرا در لبه های T4-P4 و نیز P5-T7، وزن لبه ها بیش از ۱ می باشد. بنابراین این شبکه در زیر کلاس های شبکه های پتری، مطرح در فصل ۲، قرار نمی گیرد.
۴٫۴٫۳٫۱٫ Liveness
با توجه به عدم امکان استفاده از قضایای مربوط به زیرکلاس های شبکه های پتری، تنها راه ممکن برای تشخیص سطح liveness این شبکه بررسی سطح liveness تک تک گزارهای سیستم است.
T0، T1، T2: L4-live، برای اجرا شدن هر دنباله ای از وضعیت ها (M₁ تا M_n) این گزارها باید اجرا شوند.
T3، T4: L3-live، در M₃ (S3 در گراف پوشای شکل ۴٫۱۶) یکی از این دو گزار قطعا اجرا می شود. بنابراین این گزارها به دفعات نامحدود می توانند اجرا شوند.
T5، T6: L3-live، در صورت قرارگیری سیستم در M₄، حتما هر دو گزار اجرا خواهند شد. بنابراین آنها می توانند به دفعات دلخواه اجرا شوند. البته زمان اجرای آنها و ترتیب تمام شدن پروسه داخلی آنها لزوما برابر نیست.
T7: L3-live، در صورت اجرا شدن T5 و T6 و قرار گیری سیستم در وضعیت M₆، این گزار قطعا اجرا می شود. اما به دلیل اینکه ممکن است سیستم با اجرای دنباله M₀، M₁، M₂، M₃ و M₀ اصلا به سراغ اجرای گزارهای T4 به بعد نرود، این گزار نیز فقط به دفعات دلخواه (و نه همیشه) می تواند اجرا شود.
وضعیت قرارگیری توکن ها در M₃ و M₄ در شکل ۴٫۱۵ دیده می شوند.