محمد نصیری
بنیانگذار توسینسو ، هکر کلاه سفید ، کارشناس امنیت اطلاعات و ارتباطات و عاشق طبیعت

Fault Tolerance در VMware چیست؟ معرفی قابلیت FT Logging

Fault Tolerance در VMware چیست؟ FT Logging چیست؟ برخی اوقات شما در سازمان خودتان سرویس های بسیار حساسی دارید که حتی چند ثانیه خاموش شدن یا حتی Restart شدن این سرور باعث ضررهای سنگینی می شود که بعضا جبران ناپذیر هم هستند. برای مثال من در سازمانی کار می کردم که سرویسی داشت که در هر دقیقه 1000 عدد ثبت عبور و مرور و مجوزهای تردد ترافیکی را بصورت آنلاین صادر می کرد .

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

حال تصور کنید که به دلیل بروز مشکل این سرور به مدد تنها 1 ساعت خاموش باشد یعنی 60000 عدد مجوز عبور و مرور صادر نخواهد شد و این می تواند نارضایتی شدیدی را به همراه داشته باشد. یا حتی از آن هم مهمتر اگر یک سرویس پرداخت الکترونیک بانکی برای چند ساعت دچار اختلال شود ممکن است میلیاردها تومان ضرر به بانک مربوط به برسد. اما چاره کار چیست ؟

قبلا در خصوص استفاده از قابلیت های Network Load Balancing و Failover Clustering در ویندوز سرور 2012 صحبت کرده ایم که می توانند تا حدودی باعث ایجاد Failover و یا تقسیم Load کاری شوند. اما این مبحث در خصوص ویندوز سرور 2012 صادق است و در خصوص سیستم عامل لینوکس باید از روشهای خاص Clustering در لینوکس و ... در سیستم عامل های دیگر استفاده کنیم.

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


تصویر مفاهیم کلاسترینگ در VMware و مایکروسافت

معرفی قابلیت Fault Tolerance در VSPhere

در آموزش هایی که تاکنون در توسینسو مشاهده کردید حتما واژه Additional Domain Controller را به خاطر دارید ، یکی سرور اضافه بر سازمان که در صورت بروز مشکل برای سرور اصلی وارد مدار می شود و به جای سرور اصلی ایفای نقش می کند. هر چیزی که در Domain Controller اصلی وجود داشته باشد در Domain Controller جانبی نیز عینا وجود دارد و در واقع کپی برابر اصل است.

چه خوب می شد که ما چنین قابلیتی را برای Virtual Machine های خودمان نیز داشتیم !! چنین مکانیزمی در محصولات شرکت VMware به نام Fault Tolerance وجود دارد که این امکان را به شما می دهد که دو یا چند Virtual Machine داشته باشید که عینا مثل هم باشند ، از هر جهت کپی برابر اصل و در عین حال هر اطلاعاتی که در سرور اصلی یا همان VM اصلی وجود دارد عینا در سرورهای دیگر نیز وجود دارد ، در صورت بروز مشکل برای سرور اصلی بلافاصله و بدون به وجود آمدن کوچکترین Downtime ای سرور جانبی وارد مدار می شود و همان کار سرور اصلی را انجام می دهد.

Fault Tolerance یا FT در VMware به مفهوم این است که VM های شما حداکثر دسترسی پذیری ممکن در شبکه را داشته باشند و با از بین رفتن یک VM کار و سرویس دهی VM متوقف نشود و به کارش ادامه دهد ، برای پیاده سازی و درک بهتر نحوه عملکرد این مکانیزم امروز در ITPRO می خواهیم در همین خصوص بحث کنیم که چه نیازمندی هایی برای پیاده سازی این سرویس وجود دارد و از طرفی نحوه عملکرد و مفهوم FT Logging را نیز با هم بحث و گفتگو کنیم.


معرفی قابلیت Faul Tolerance در VMware

قابلیت Fault tolerance یا FT در VMware اولین بار به عنوان یکی از امکانات جدید در مجموعه VSPhere برای برطرف کردن یک مشکل در VMware Infrastructure 3 معرفی شد و هدف آن ادامه فعالیت و سرویس دهی یک سرور در صورت بروز مشکل و از بین رفتن یکی از Host ها بود.

در ابتدای کار ما قابلیتی به نام Fault Tolerance نداشتیم و ویژگی که معرفی شده بود به نام High Availability یا HA معرفی شد. HA تا حدودی شبیه به عملکرد FT کار می کرد با این تفاوت که برای اینکه VM دوم وارد مدار شود یک مدت زمان کم برای Restart شدن و در مدار قرار گرفتن VM دوم مورد نیاز بود که همین موضوع یک مدت زمان بسیار کم را به عنوان Downtime به خود اختصاص می داد.

تصویر Availability در سرویس های VMware

با معرفی شدن قابلیت FT تحولی اساسی در خصوص Availability در VM ها پیش آمد به شکلی که با استفاده از مکانیزم VM های Primary و Secondary که عین اطلاعات همدیگر را دارند ، به مجض اینکه یکی از Host ها به مشکل بخورد کپی اصلی که Secondary VM است بدون کوچکترین Downtime ای شروع به کار می کند.

در چنین حالتی هیچوقت VM ای که Secondary بوده است برای روشن شدن و شروع به کار نیازی به Restart شدن ندارد و بلافاصله از Secondary تبدیل به Primary می شود و سرویس دهی را ادامه می دهد. نکته جالب اینجاست که به محض تبدیل شدن Secondary VM به Primary VM یک Secondary دیگر بر روی یک Host دیگر در شبکه ایجاد می شود . البته من فناوری FT را در لابراتوار ایجاد کردم و در محیط عملیاتی هم تست کردم ، تنها Downtime یک Request time out در دستور ping بود و بلافاصله VM جانبی جایگزین و عملیاتی شد.

Primary VM و Secondary VM اطلاعات را با همدیگر یکسان سازی یا Sync ( همگام سازی ) می کنند و به محض اینکه کوچکترین تغییری در Primary VM ایجاد شود این تغییر برای Secondary VM ارسال می شود. تکنولوژی که برای Sync کردن این دو VM بکار می رود به عنوان Record//Replay شناخته می شود و اولین بار در محصول VMware Workstation شرکت VMware معرفی شد.

مکانیزم کاری Record//Replay به این شکل است که کلیه فرآیند های درحال اجرا در Primary VM در داخل یک سری LogFile ذخیره می شود که به این فرآیند Record گفته می شود ، سپس توسط همین LogFile ها اطلاعات ضبط شده به سمت Secondary VM ارسال می شوند که یه این فرآیند Replay گفته می شود و با این روش کلیه اطلاعات موجود بر روی Primary VM بر روی Secondary VM هم عینا وجود خواهد داشت.


Fault Tolerance در VMware چگونه کار می کند

یک نکته را فراموش نکنید ،بیشتر ما شبکه ای ها تا اسمی از Log می شنویم به فکر فایل هایی می افتیم که برای نگهداری اتفاقات و رویدادهایی که بر روی یک سرویس یا موارد مشابه رخ می دهد ، اما فراموش نکنید که در VMware و به ویژه در سرویس FT زمانیکه صحبت از Log می شود ما منظورمان اطلاعات است.

چیزی که شما در VMware و سرویس FT به عنوان LogFile می شناسید در واقع همان چیزی است که در Exchange Server به عنوان Transaction Log و همچنین در SQL سرور به همین اسم Log و فرآیند Log Shipping می شناسیم . در همه این موارد که قبلا در توسینسو در خصوص آنها صحبت کرده ایم در واقع Log File داده ای است که هنوز در پایگاه داده ما ثبت نشده است.در VMware هم در سرویس FT فایل های LogFile تا زمانی وجود دارند که درون دیسک های VM ذخیره نشده باشند. بعد از اینکه محتویات فایل LogFile درون دیسک ذخیره شد ، محتویات آن باید حذف شود.

در قسمت قبلی در توسینسو در خصوص این صحبت کردیم که ایجاد کردن Primary VM و Secondary VM توسط یک تکنولوژی به نام Record//Replay که یک قابلیت جدید در CPU های امروزی است انجام می شود. اما نباید فراموش کنیم که تکنولوژی Record//Replay در همه انواع CPU ها و مدلهای مختلف آن وجود ندارد و فقط برخی از مدل های CPU های شرکت های AMD و Intel از این تکنولوژی بهره مند هستند .

این تکنولوژی در VMware به نام vLockstep شناخته می شود. معرفی کردن تکنولوژی FT باعث شد تولید کنندگان CPU ای مثل AMD و Intel مجبور شوند( البته FT و Record//Replay فقط مختص VMware نیست ) تغییراتی در معماری Performance Counter و تکنیک های مجازی سازی در CPU خود مثل AMD-V و Intel VT بصورت فیزیکی ایجاد کنند تا براحتی بتوانیم از FT و تکنولوژی های مشابه استفاده کنیم.

به همین دلیل تنها CPU های جدید هستند که می توانیم در آنها FT را پیاده سازی کنیم و در اکثر CPU های قدیمی پیاده سازی FT به دلیل وجود محدودیت های CPU قابل پیاده سازی نیست. شرکت AMD در نسل سوم معماری CPU های سرور خود از CPU هایی با نام تجاری Barcelona ، Budapest و Shanghai رونمای کرد و در همین حین شرکت Intel نیز از CPU های Core 2 و Corei7 سری Intel Xeon خود برای سرورها رونمای کرد ، این دو سری از CPU ها براحتی امکان استفاده در سرویس FT در VMware را دارند.


تصویر CPU های Xeon و Barcelona و Budapest

FT چگونه کار می کند ؟

در پیاده سازی کردن FT همیشه حداقل دو عدد سیستم سخت افزاری Host وجود دارد که بر روی یکی از آنها VM اصلی و بر Host دوم VM پشتیبان قرار می گیرد. همانطور که قبلا هم در توسینسو گفتیم FT یک Secondary VM بر روی یک ESX Host در شبکه ایجاد می کند که ساختار دیسک مجازی و تنظیمات آن دقیقا مشابه Primary VM ای است که می خواهیم از آن بکاپ داشته باشیم.

بعد از اینکه FT ایجاد کردن Secondary VM را تمام کرد تمامی ورودی های CPU و نقل و انتقالات داخل Primary VM را در قالب LogFile هایی که قبلا اشاره کردیم ثبت و ضبط یا همان Record می کند ، در اصطلاح فنی ما به Primary VM در اینجا Record و به Secondary VM در اینجا Replay می گوییم.

بعد از برداشته شدن LogFile ها و منتقل شدن و ثبت شدن آنها در Secondary VM که توسط یک کارت شبکه مجزا که به آن FT Logging NIC می گوییم ، VM اصلی با VM دوم بصورت کامل Sync خواهد شد و تمامی اطلاعاتی که در VM اصلی وجود دارد در VM دوم هم عینا کپی می شود ، فارق از اینکه نوع سیستم عامل موجود در VM چیست ، در چنین حالتی VSPhere آماده می شود که در صورت بروز مشکل برای Host اول بلافاصله Host دوم را وارد مدار کند و شروع به سرویس دهی کند.


تصویر Primary VM و Secondary VM به همراه Logfile  ها

توجه کنید که درست است که ورودی هایی که به Primary VM و Secondary VM وارد می شوند هر دو یکسان است اما این فقط Primary VM است که قابلیت نوشتن اطلاعات بر روی دیسک و خروجی اطلاعات را دارد و همچنین ترافیک انتقالی سرویس مورد نظر که روی VM قرار گرفته است صرفا از Primary VM تولید می شود .

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


تصویر Primary VM و Secondary VM به همراه Logfile  ها

این نکته مهم را همیشه در نظر داشته باشید که قرار نیست هر اتفاق و هر چیزی که در Primary VM وجود دارد در Secondary VM هم وجود داشته باشد و در آن کپی شود ، برخی از دستورالعمل ها و اعمال هستند که نیازی نیست در Secondary VM کپی شوند و اگر قرار باشد همه چیز از Primary VM برداشته و Record شود و در Secondary VM نوشته یا Replay شود به قدرت پردازشی بسیار زیاد و در عین حال به فضای دیسک زیادی نیاز خواهد بود.

در عوض فرآیند هایی مثل خواندن دیسک ، ترافیک دریافتی از شبکه ، کلیدهای فشرده شده ، کلیک های موس و ... به همراه برخی فرآیندهای CPU مثل RDTSC و وقفه ها و ... Record می شوند. ورودی های Primary VM به محض اینکه اجرا شدند بلافاصله بعد از Record برای سمت به سمت Secondary VM ارسال می شوند.

این اطلاعات که از طریق Primary VM به سمت Secondary VM ارسال می شوند توسط یک شبکه ویژه این عملیات که ما آن را Logging Network نامگذاری می کنیم ارسال و دریافت می شوند ، تنظیمات مربوط به Logging Network بر روی هر کدام از Host ها بصورت جداگانه انجام می شود.

به قول خودم به شدت و به شدت توصیه می شود که کارت شبکه ای که برای FT Logging استفاده می شود در وهله اول بصورت اختصاصی برای همینکار در نظر گرفته شده باشد و در وهله دوم سرعت حداقل Gigabit یا بیشتر را داشته باشد تا برای انتقال ترافیک FT Logging مشکلی نداشته باشد ، استفاده از کارت شبکه های سرعت پایین به هیچ عنوان در چنین مواردی پیشنهاد نمی شود.

البته شما ممکن است بخواهید در یک شرکت کوچک و یا یک محیط لابراتوار FT را راه اندازی کنید و شاید دو بستر شبکه مجزا نتوانید برای راه اندازی این سرویس در اختیار داشته باشید اما به هر حال شما می توانید FT Logging را روی یک Shared NIC هم راه اندازی کنید که البته معمولا برای لابراتوار استفاده می شود.

اطلاعاتی که در بستر شبکه FT Logging و بین دو Host منتقل می شود می تواند بسیار حجیم باشد که البته بستگی به نوع کاربرد از ماشین های مجازی ما نیز دارد. VMware برای خودش یک فرمول محاسبه دارد که شما می توانید پهنای باند مورد نیاز برای راه اندازی FT Logging را تخمین بزنید :

VMware FT logging bandwidth = (Avg disk reads (MB/s) ×8 + Avg network input (Mbps)) × 1.2 [20% headroom ]

برای اینکه مقادیر بالا را برای محاسبه در فرمول بدست بیاورید کافیست از قسمت Performance Metrics خود VSPhere Client استفاده کنید. در انتهای فرمول سقب 20 درصدی که عنوان شده است برای پردازش ها و رویدادهای CPU ای است که در فرمول محاسبه نشده اند و ممکن است یکباره شروع به کار کنند. به این نکته توجه کنید که خروجی های دیسک و شبکه در این فرمول جایی ندارند و توسط FT استفاده نمی شوند و دلیل آن هم کاملا مشخص است ، مقادیر خروجی از VM هیچ تاثیری در وضعیت VM ما ندارند.

اما همانطور که در فرمول هم مشاهده می کنید تاثیر Disk Read یا خوندن از دیسک در پهنای باند مورد نیاز بسیار زیاد است و مقدار بسیار زیادی پهنای باند را به خودش اختصاص داده است ، اگر شما یک VM دارید که مقدار Disk Read آن بسیار زیاد است

برای اینکه ترافیک آن در شبکه FT Logging کمتر شود می توانید از یک پارامتر در VM به نام replay.logReadData = checksum استفاده کنید که در فایل VMX مربوط به VM ما قرار گرفته است. این پارامتر باعث می شود که Secondary VM داده های خودش را مستقیما از Shared Disk بخواند و دیگر از طریق شبکه FT Logging ترافیک Read Disk را منتقل نکند.

نکته بسیار مهم در خصوص راه اندازی FT این است که اگر فرض کنیم نرم افزار وب سرور توسینسو و سیستم عامل آن بر روی یک VM قرار داشته باشند و ما FT را راه اندازی کنیم و وب سرور و سیستم عامل ITPRO را بصورت Secondary در یک Host دیگر داشته باشیم 

در صورت بروز مشکل برای سیستم عامل Primary VM و مثلا به وجود آمدن یک خطای Blue Screen این اتفاق عینا در Secondary VM مربوط به ITPRO هم رخ خواهد داد و FT در برابر مشکلات مربوط به Application ها و سیستم عامل ها کاری نمی تواند بکند چون دقیقا کپی برابر اصل است و اگر اصل موضوع دچار مشکل شود طبیعتا دومین VM هم دچار مشکل می شود.

البته قابلیتی در FT به نام HA VM Monitor وجود دارد که چنین مشکلاتی را شناسایی می کند و Primary VM را Restart می کند و دوباره یک Secondary VM جدید را Respawn می کند. همچنین دقت کنید که FT از شما در برابر مشکلات مربوط به Storage ها و از بین رفتن Storage محافظت نمی کند 

دلیل این موضوع هم کاملا منطقی است ، هر دو Host از یک Storage و یک Virtual Disk استفاده می کنند و این یعنی یه وجود آمدن Single Point Of Failure ، بنابراین وجود امکانات Redundant تا جای ممکن در پیاده سازی FT پیشنهاد می شود .

برای مثال اگر همین VM های توسینسو را در نظر بگیریم ما می توانیم حداقل دو عدد Shared Storage داشته باشیم تا در صورت بروز مشکل برای یکی از Storage ها بلافاصله بتوانیم بر روی Secondary VM سویچ کنیم. ترجیحا در محیط های Enterprise کلان شما دو یا بیشتر از دو عدد SAN Storage فیزیکی بعضا در مراکز داده مجزا را به هم متصل می کنید و FT را راه اندازی می کنید که حتی در صورت بروز مشکل و انهدام کامل یکی از SAN Storage ها یکی از آنها بتواند به سرویس دهی خود ادامه دهد.


دو عدد SAN Storage در ساختار FT

به دلیل Overhead و همچنین محدودیت هایی که سرویس FT دارد معمولا راه اندازی این سرویس هم مقرون به صرفه نیست و هم کمتر سازمانی مگر در موارد بسیار حساس از آن استفاده می کند. به هر حال پیاده سازی FT نیازمند بسترهای سخت افزاری است که بعضا برای بسیاری از سازمان ها که نیاز به صرفه جویی در همه موارد دارند اصلا قابل قبول نیست.

قبلا در خصوص سرویس Failover Clustering و همچنین NLB Clustering در ویندوز سرور 2012 در توسینسو بصورت کامل صحبت کرده ایم ، بد نیست بدانید که ما می توانیم در برخی موارد از Fault Tolerance شرکت VMware به عنوان جایگزین سرویس Clustering مایکروسافت استفاده کنیم.

اما خیلی مهم است بدانیم که FT چه کاری می تواند برای ما انجام بدهد و چه کاری را نمی تواند انجام بدهد. باید توجه کنید که FT در برابر مشکلات مربوط به نرم افزارهای ما هیچ کاری نمی تواند انجام بدهد و فقط در برابر مشکلات مربوط به Host می تواند مقاومت کند. اگر شما می خواهید محافظت در برابر مشکلات نرم افزاری مد نظر شماست پیاده سازی ساختار Failover Clustering در سیستم عامل ویندوز کارایی بهتری برای شما خواهد داشت.

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

اگر شما بتوانید از قابلیت های HA یا High Availability و FT یا Fault Tolerance در VMware بصورت همزمان استفاده کنید می توانید حداکثر حفاظت ممکن از VM های خود را ایجاد کنید ، اگر در حادترین حالت ممکن ، هم Primary VM و هم Secondary VM به مشکل خوردند و Host های هر دو از بین رفتند قابلیت HA این امکان را به شما می دهد که در یک Host دیگر به غیر از این دو Host بتوانید VM جدید را با یک Restart فعال کنید و یک Secondary VM جدید ایجاد کنید.


پیاده سازی Fault Tolerance در VSPhere

قطعا و بدون شک FT یک سرویس بسیار کاربردی و عالی از نظر یک کارشناس شبکه است اما در عین حال برای پیاده سازی FT در شبکه یک سری نیازمندی ها و در عین حال محدودیت ها وجود دارد که شما به عنوان یک توسینسویی باید با آنها به خوبی آشنا باشید. شاید مهمترین نقطه ضعفی که در پیاد سازی FT وجود دارد این است که این ویژگی فقط قابلیت پشتیبانی از یک vCPU را دارد و شما تنها می توانید بر روی VM هایی FT را راه اندازی کنید که یک vCPU بر روی آن قرار گرفته است.

بسیاری از نرم افزارها و سیستم عامل های مجازی که در محیط های سازمانی بسیار بزرگ استفاده می شوند معمولا بیشتر از یک vCPU دارند و به همین دلیل این محدودیت محرز در خصوص FT است ، در خصوص vCPU و vSMP قبلا در توسینسو صحبت کرده ایم.

البته در عین حالی که این یک محدودیت است چیزی از ارزش های FT کم نمی کند ( دیدی این ورزشکارا میرن خراب می کنن بعد میگیم چیزی از ارزش هاشون کم نشده اینم همون ... والا ) زیرا application های زیادی وجود دارند که به راحتی با همان یک vCPU کار خود را به درستی می توانند انجام دهند ، مخصوصا اینکه امروزه هر چقدر که جلوتر می رویم CPU های سریعتر و پرقدرت تر می شوند و حتی یک vCPU نیز می تواند کار ما را به درستی پشتیبانی کند.


Virtual CPU چیست

شرکت VMware اعلام کرده است که در آینده ای نه چندان دور حتما از قابلیت vSMP نیز پشتیبانی خواهد کرد و وقتی VMware این حرف را می زند مثل قول برخی نیست که فقط حرف است بلکه حتما چنین چیزی اتفاق خواهد افتاد. توجه کنید که پیکربندی استفاده از چندین vCPU در قابلیت LockStep بین چندین Host اصلا و ابدا کار ساده ای نیست و VMware هم برای پیاده سازی این مکانیزم بایستی زمان بیشتری اختصاص بدهد تا بتواند از چندین vCPU پشتیبانی کند.

البته این محدودیت ها در نسخه های 6 به قبل VSphere وجود داشت و با توجه به اینکه اکثر سازمان های ما همچنان از نسخه های 6 به قبل استفاده می کنند این محدودیت ها برای این سازمان ها وجود دارد ، در نسخه 6 از VSPhere دو قابلیت بسیار مهم به FT اضافه شده است که در این نسخه شما می توانید تا 4 عدد vCPU داشته باشد

و در عین حال می توانید از قابلیت Snapshot نیز استفاده کنید . در نسخه های قبلی شما حداکثر یک vCPU می توانستید استفاده کنید و از Snapshot هم نمی توانستید استفاده کنید. در مقاله بعدی از همین سری آموزشی به بررسی نیازمندی های اولیه راه اندازی FT هم در VM ها و هم Host ها خواهیم پرداخت

همانطور که در قسمت قبلی از سری آموزشی Fault Tolerance در VMware به شما قول داده بودیم در ادامه می خواهیم به نیازمندی های پیاده سازی سرویس Fault Tolerance در سیستم Host و همچنین خود Virtual Machine صحبت کنیم. همچنین به بررسی محدودیت های این سرویس نیز اشاره ای خواهیم کرد تا بدانید در کجا می توانید از FT استفاده کنیم و در کجا امکان استفاده از آن را ندارید .

دقت کنید در این سری از مقالات در صورتیکه برخی امکانات در نسخه های بالاتر VSPhere قابل پیاده سازی باشد به آن اشاره خواهد شد اما با توجه به اینکه در اکثر سازمان ها امروزه از ESXi نسخه های 5.0 و 5.1 و 5.5 استفاده می کنند و هنوز به نسخه های بالاتر بعضا بروز رسانی ها انجام نشده است ما نیز محدودیت ها را بر حسب محصولات قدیمی تر عنوان می کنیم ، هر چند اشاره می کنیم که در محصولات جدید چه تغییراتی رخ داده است.


نیازمندی های سیستم Host برای پیاده سازی FT در VMware

فراموش نکنید که برای پیاده سازی کردن FT ما به تکنولوژی vLockstep نیاز داریم که تنها در پردازنده های جدید شرکت Intel و AMD وجود دارند. اکثر CPU های سری Core I7 و Core 2 due از محصولات Xeon شرکت Intel و سری Budapest ، Shanghai و Barcelona از محصولات AMD دارای تکنولوژی vLockstep هستند.

از طرفی هر دو Host ای که قرار است بر روی آنها FT فعال شود بایستی از یک خانواده و نسل CPU بر روی سخت افزار خود استفاده کنند و در واقع سخت افزار CPU آنها FT-Capable باشد. سرعت ساعت یا Clock Speed هر دو CPU ای که بر روی Host ها وجود دارد بایستی ترجیحا یکسان باشد تا فرآیند همگام سازی ورودی ها به درستی بتواند انجام شود.

هر کدام از Host ها باید از یک نسخه مشابه از ESX یا ESXi استفاده کنند و شما نمی توانید از دو نسخه متفاوت از ESXi برای انجام FT استفاده کنید ( البته این الزامی نیست امکان پیاده سازی این روش تست شد جواب گرفتیم ) ، هر دوم سیستم عامل HOST بایستی لایسنس مورد نیاز برای پیاده سازی FT را داشته باشند که البته شما در نسخه های Advanced ، Enterprise و Enterprise Plus محصول VSPhere قابلیت FT را دارید. البته لایسنس در ایران چندان اهمیتی ندارد.


معرفی قابلیت Fault Tolerance و FT Logging در VSPhere  - قسمت چهارم

Host هایی که برای راه اندازی FT استفاده می شوند بایستی برای نگهداری VM محافظت شده در FT به یک Shared Storage مشترک متصل شده باشند ، در واقع برای ایجاد کردن FT Cluster وجود Shared Storage به شکل های مختلف اعم از FC ، iSCSI و یا NAS الزامی است.

همه Host هایی که قرار است FT روی آنها ایجاد شود در قالب یک FT Cluster بایستی قرار بگیرند و یا بهتر بگوییم Host ها باید در یک HA-Enabled Cluster وجود داشته باشند.برای بالا بردن اعتماد به FT پیشنهاد می شود که حتما هم زیرساخت شبکه و هم storage شبکه ای بصورت Redundant در شبکه وجود داشته باشد 

به منظور به حداکثر رساندن اعتماد پذیری یا Reliability در FT می توانید از NIC Teaming و همچنین Storage Multipathing استفاده کنید. هر کدام از Host ها باید یک کارت شبکه اختصاصی با سرعت حداقل یک گیگابیت بر ثانیه برای FT Logging و یک کارت شبکه نیز بصورت اختصاصی برای VMotion داشته باشند. در نهایت قابلیت بررسی Certificate یا Certificate Checking بایستی بر روی سرور VCenter فعال شود ، اینکار براحتی از طریق Settings و SSL Settings در تنظیمات vCenter Server قابل پیکربندی است.


معرفی قابلیت Fault Tolerance و FT Logging در VSPhere  - قسمت چهارم

نیازمندی های Virtual Machine ها برای پیاده سازی FT در VMware

به این موضوع دقت کنید که اگر از نسخه های 6 به پایین از VSPhere استفاده می کنید ، تنها می توانید در VM ای که می خواهید FT بر روی آن فعال شود یک عدد vCPU داشته باشید ، VSPhere های نسخه 6 به پایین از قابلیت vSMPs پشتیبانی نمی کنند و نمی توان بر روی آنها چندین vCPU قرار داد. در نسخه 6 از VSPhere ما می توانیم از حداکثر 4 عدد vCPU در VM های خود استفاده کنیم.

قبلا در توسینسو در خصوص تفاوت Thin Provision و Thick Provision در دیسک های VMware صحبت کرده ایم ، نباید فراموش کنید که تمامی VM هایی که قرار است در FT قرار بگیرند باید در حالت Thick Provision ایجاد شده باشند و چیزی به نام Thin Provision در FT معنی ندارد.

البته به محض اینکه FT را بر روی یک VM فعال کنید بصورت خودکار تبدیل به Thick Provision خواهد شد ، در VSPhere نسخه 6 محدودیت Thick بودن دیسک ها برداشته شده است و شما می توانید از دیسک های Thin هم در FT استفاده کنید . هر دستگاهی که قابلیت Replay شدن ندارد از VM بایستی حذف شود.

برای مثال ابزارهایی مثل USB Flash ها ، پورت های سریال و موازی ، کارت صدا ، CD-ROM فیزیکی ، فلاپی درایو و ... بایستی از روی VM حذف شوند. همانطور که قبلا اشاره کردیم سیستم عامل چندان در FT مهم نیست اما به هر حال اکثر سیستم عامل های Guest در FT پشتیبانی می شوند به غیر از موارد معدودی که ممکن است هرگز هم استفاده نشوند ، برای مثال ویندوز XP نسخه 32 بیتی ، ویندوز 2000 و سیستم عامل Solaris 10 نسخه 32 بیتی از مواردی هستند که در FT پشتیبانی نمی شوند.


محدودیت های استفاده از قابلیت Fault Tolerance در VMware

قبل از اینکه شما بتوانید برای یک VM قابلیت FT را راه اندازی کنید بایستی کلیه Snapshot هایی که از این VM تهیه کرده اید را از آن حذف کنید. در ضمن توجه کنید که فقط در نسخه 6 از VSPhere شما می توانید از VM هایی که در FT وجود دارند Snapshot هم بگیرید و در VSPhere های قدیمی تر نمی توانید از VM ای که در FT هست Snapshot بگیرید. امکان استفاده از قابلین N__Port ID Virtualization یا NPIV در FT وجود ندارد .

برای اینکه بتوانید از یک VM در FT استفاده کنید حتما باید تنظیمات مربوط به NPIV را غیرفعال کنید. FT از Paravirtualized Adapters پشتیبانی نمی کند و همچنین امکان استفاده از Physical RDM در FT وجود ندارد شما می توانید فقط از Virtual RDM ها استفاده کنید.

اگر به VM شما یک فلاپی دیسک یا CD-ROM بصورت فیزیکی متصل شده باشد نمی توانید از آن در FT استفاده کنید ، حتی اگر این اتصال بصورت Remote هم انجام شده باشد باز هم امکان استفاده از FT وجود ندارد و شما بایستی تمامی این دستگاه ها را از VM ای که در آن به FT نیاز دارید حذف کنید.

قابلیت Hot Plug برای VM هایی که در FT قرار می گیرند بصورت خودکار غیر فعال می شود ، این قابلیت به شما این اجازه را می داد که بتوانید در هنگامیکه VM شما روشن است دستگاه های خاصی را به آن اضافه و یا از آن کم کنید ، برای انجام اینکار در FT شما باید بصورت موقتی VM را خاموش کنید و عملیات خود را انجام دهید و مجددا VM را روشن کنید. قابلیت های EPT و RVI بصورت خودکار بر روی VM های FT غیرفعال می شوند.

آدرس IP نسخه 6 هنوز در FT پشتیبانی نمی شود و شما باید از آدرس IP نسخه 4 استفاده کنید. همانطور که گفتیم VM ها اگر بر روی Host ای باشند که از VSPhere نسخه 6 به پایین استفاده می کند تنها یک vCPU را پشتیبانی می کند و در حال حاضر VSPhere نسخه 6 است که می تواند تا 4 عدد vCPU را پشتیبانی کند. شما می توانید در FT از قابلیت VMotion استفاده کنید.

اما شما نمی توانید از VMotion هم در Primary VM و هم در Secondary VM بصورت همزمان استفاده کنید در عین حال قابلیت SVMotion نیز در VM هایی که FT بر روی آنها فعال شده است پشتیبانی نمی شود. در VSPhere 4.0 سرویس FT با DRS بصورت کاملا هماهنگ کار می کرد اما Automation Level برای VM هایی که بر روی آنها FT فعال شده بود غیرفعال می شد. در VSPhere 4.1 شما زمانی می توانید از DRS در FT استفاده کنید همزمان قابلیت EVC را فعال کرده باشید.

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

به قول جناب خان در سریال طنز خندوانه ووووووووو کی میره ای همه راهو وولک ( به لهجه آبودانی ). شما برای بررسی کردن این نیازمندی ها معمولا می توانید از روی یک چک لیست موارد را بررسی کنید اما VMware اینکار را برای شما بسیار ساده کرده است و با معرفی یک ابزار به نام SiteSurvey به شما این امکان را می دهد که تمامی موارد را به سادگی و تنها با یک ابزار ساده بررسی و گزارش گیری کنید. ابزار SiteSurvey هم برای ویندوز و هم برای لینوکس وجود دارد و شما می توانید به سادگی آن را دانلود کنید و اجرا کنید .

بعد از اجرا به سادگی از شما آدرس VCenter Server سئوال می شود و بعد از اتصال به VCenter به شما لیست Cluster های موجود نمایش داده می شود شما کافیست Cluster مورد نظرتان را انتخاب کنید و یک SiteSurvey Report ایجاد کنید ، گزارش خروجی این ابزار به شما می گوید که آیا Host های مورد نظر از FT پشتیبانی می کنند یا خیر و اگر VM ها به پیشنیاز برای راه اندازی FT نیاز داشته باشند به شما این موارد گزارش داده می شود.


تصویر استفاده از نرم افزار SiteSurvey



تصویر استفاده از نرم افزار SiteSurvey



تصویر استفاده از نرم افزار SiteSurvey

بعد از اینکه گزارش خروجی SiteSurvey را مشاهد کردید یک سری لینک به شما نمایش داده می شود که در صورتیکه خطایی یا هشداری به شما نمایش داده شده باشد با کلیک کردن بر روی این لینک بصورت کامل جزئیات اطلاعات مورد نیاز برای پیاده سازی FT در خصوص آن به شما نمایش داده خاهد شد ، حتی لیست CPU های قابل پشتیبانی نیز در این گزارش به شما نمایش داده می شود.

طبیعتا تمامی این لینک ها به وب سایت VMware هدایت خواهند شد و مستندات راهنمای نرم افزار SiteSurvey نیز در آنها به شما ارائه خواهد شد ، به این موضوع دقت کنید که برای باز کردن این لینک ها مستقیما نمی توانید لینک ها را باز کنید زیرا شرکت VMware متاسفانه آدرس های IP ایران را مسدود کرده است.

تصویر استفاده از Compliance Tool

یکی دیگر از راهکارهای بررسی پیشنیازهای راه اندازی FT در VMware استفاده از ابزاری به نام vCenter Server Profile Compliance است.اگر بخواهید با استفاده از این روش بررسی کنید کافیست ابتدا با استفاده از VSPhere Client به VCenter سرور متصل شوید و سپس Cluster مورد نظرتان در کنسول را انتخاب کنید و از سمت راست تب Profile Compliance را انتخاب کنید. حالا بر روی گزینه Check Compliance Now کلیک کنید تا Host شما بصورت کامل بررسی شود که قابلیت های FT هم از این جمله موارد است.

قبل از اینکه بخواهید FT را فعال کنید همانطور که قبلا هم گفتیم ترجیحا Host های شما باید از یک نسخه از ESXi استفاده کنند ، یک محدودیت بسیار مهم در این خصوص وجود دارد ، VMware به هیچ عنوان پیشنهاد نمی کند که در یک Cluster که بصورت ترکیبی هم ESX و هم ESXi وجود دارد سرویس FT را راه اندازی کنید.

این به این خاطر است که قابلیت های FT در نسخه های مختلف ممکن است متفاوت باشد حتی بعضا پیشنهاد نمی شود که بعد از بروز رسانی به نسخه جدید FT را راه اندازی کنید ، بعضا Patch های بروز رسانی ممکن است باعث بروز یک سری مشکلات در FT شوند. ترجیحا سعی کنید بصورت Fresh Install از جدیدترین نسخه VSPhere استفاده کنید. البته این موارد الزامی نیست و پیشنهادی ITPRO است و بهتر است که رعایت کنید.


معرفی قابلیت Fault Tolerance و FT Logging در VSPhere  - قسمت پنجم

پیاده سازی کردن FT در VMware آنقدر که مفاهیم زیاد و پیچیده ای دارد برعکس ساده و تقریبا سریع است ، کافیست شما همه پیشنیازهای راه اندازی FT را بر روی Host های خود داشته باشید. اولین کاری که برای پیاده سازی FT نیاز است ، پیکربندی شبکه مورد نیاز برای راه اندازی FT بر روی سیستم های Host است. شما باید بر روی هر کدام از Host های خودتان دو عدد vSwitch پیکربندی کنید ، در خصوص ساختارهای vSwitch و انواع آنها خانم مهندس قرباوی در مقاله ای با همین عنوان توضیحات کاملی ارائه کرده اند.

یکی از این شبکه ها برای پیاده سازی و استفاده از VMotion و دیگری برای استفاده در FT Logging است. هرکدام از vSwitch ها باید دارای یک زیرساخت و کارت شبکه با حداقل سرعت 1 گیگابیت بر ثانیه باشند اما برای ایجاد کردن Redundancy وجود حداقل دو عدد کارت شبکه گیگابیت توصیه می شود. کارت شبکه های VMotion و FT Logging باید در Subnet های مختلف شبکه وجود داشته باشند و Subnet یکسان برای آنها نباید در نظر گرفته شود.

شما اینکار را می توانید با استفاده از ایجاد کردن VMKernel در هر vSwitch انجام دهید ، شما در تنظیمات VMKernel می توانید با استفاده از گرینه Use this port group for VMotion برای یکی از آنها و Use this port group for fault tolerance logging روی دیگری این پیکربندی را انجام دهید.

اگر می خواهید مطمئن شوید که تنظیمات مربوط به Networking ای که انجام داده اید به درستی انجام شده است کافیست بر روی تب Summary بر روی Host کلیک کنید ، شما باید روبروی قسمت های VMotion Enabled و Fault Tolerance Enabled کلمه Yes را مشاهده کنید. زمانیکه تنظیمات شبکه را به درستی انجام دادید شما می توانید براحتی با راست کلیک کردن بر روی VM مورد نظرتان و کلیک کردن بر روی گزینه Turn On Fault Tolerance قابلیت FT را بر روی آن فعال کنید.


تصویر فعال کردن FT بر وی VM



تصویر تنظیمات شبکه برای VMotion  و FT

زمانیکه شما FT را فعال کردید بلافاصله Secondary VM در Host دیگر شروع به ایجاد شدن می کند و شما یک قسمت جدید در تب Summary به نام Fault Tolerance اضافه می شود و در این قسمت اطلاعاتی در خصوص VM قرار گرفته در FT و وضعیت آن ، محل قرارگیری VM و تنظیمات مروبط به CPU و RAM مورد استفاده در Secondary VM را مشاهده می کنید.

البته اطلاعات جزئی تری اعم از Secondary VM lag time یا همان مدت زمانی که با Primary VM تفاوت دارد ، پهنای باند مورد استفاده در FT Logging و ... را مشاهده می کنید. بعد از فعال کردن FT به سرعت شما می توانید Alarm ها را در خصوص وضعیت FT مشهده کنید و اطلاعات زیادی در خصوص هشدارها و خطاها را ببینید.

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

خوب تا به حال 5 قسمت از سری آموزشی Fault Tolerance در VMware را با هم در توسینسو مرور کردیم ، امیدوارم تا اینجای کار به مفاهیم اصلی این سرویس زیبا پی برده باشید . دوست داریم همیشه در توسینسو بهترین مطالب و با کیفیت ترین آنها بصورت متفاوت از سایر وب سایت ها عنوان شود . این مقاله آخرین مقاله از سری آموزشی FT خواهد بود و به امید خدا در آینده ای نه چندان دور پیاده سازی این سروی را نیز بصورت کاملا کاربردی و عملی به شما آموزش خواهیم داد.

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


ملاحظات مهم در خصوص سرویس FT

VMware برای اینکه بتواند تکنولوژی vLockstep را پیاده سازی کند زمان بسیار زیادی را به پالایش کردن و تجزیه و تحلیل پردازنده های فیزیکی شرکت های AMD و Intel اختصاص داد ، با استفاده از این تکنولوژی کلیه تبادلاتی که هنوز در حافظه سیستم ثبت نشده اند و بصورت کامل پردازش آنها قطعی نشده است به همراه همه دستورالعمل ها بصورت کامل از CPU سیستم اصلی به داخل CPU سیستم جانبی عینا تکرار می شوند.

در واقع هر چیزی که در لحظه در CPU اصلی در حال اجرا شدن است در همان لحظه در CPU دوم که در اختیار VM دوم است نیز تکرار می شود و این دو سیستم با یکدیگر کاملا همگام سازی می شوند به گونه ای که حتی دستوراتی که داخل CPU وجود دارد در CPU دوم نیز تکرار شده و وجود خواهند داشت. تمامی داده ها بین سیستم ها همگام سازی می شوند و تقریبا می توانیم بگوییم Data Loss یا از بین رفتن داده ها بین این دو سیستم صفر است.

در زمانیکه یک مشکل سخت افزاری پیش بیاید در واقع فقط یک IP Packet است که مجددا ارسال می شود و هرگز اختلالی در سرویس دهی ایجاد نمی شود و Data Loss وجود نخواهد داشت ، همانطور که گفتیم حتی آخرین دستوراتی که داخل CPU مربوط به Primary VM وجود داشته است در CPU مربوط به Secondary VM هم وجود خواهد داشت و به عنوان آخرین ورودی بلافاصله بعد از بروز مشکل شروع به فعالیت می کند.


VlockStep چیست

FT از یک ویژگی خاص در CPU ها استفاده نمی کند که بگوییم هر CPU ای که دارای این ویژگی باشد می تواند در FT استفاده شود در عوض فقط از یک خانواده خاص از CPU ها پشتیبانی می کند و تا این خانواده از CPU را در اختیار نداشته باشد نمی تواند کار کند. همانطور که عنوان کردیم vLockstep بیشتر یک راهکار نرم افزاری است که وابسته به وظایف اصلی است که توسط CPU انجام می شود.

لایه نرم افزار تمامی دستورالعمل هایی که داخل CPU وجود دارد را در لایه VM ضبط یا Record می کند و برای انجام اینکار وابسته به پردازنده سیستم است ، انجام شدن این فرآیند Record نیازمند یک قابلیت زمانبندی بسیار دقیق در CPU ها است و VMware هم برای اینکه بتواند این قابلیت را داشته باشد به CPU هایی از شرکت های AMD و Intel نیاز داشت که بتوانند حداکثر صحت و تمامیت از نظر دستورالعمل ها و زمانبندی را ارائه بدهند.

ابزار SiteSurvey به داخل CPU شما توجهی نمی کند که آیا قابلیت vLockstep را دارد یا خیر بلکه فقط به مدل های و خانواده های خاصی از CPU توجه می کند، اگر CPU شما جزو آن دسته از CPU هایی باشد که FT را پشتیبانی می کند به شما گزارش هماهنگی می دهد .

در غیر اینصورت به شما گزارش عدم هماهنگی می دهد. در آینده VMware به احتمال زیاد ابزار SiteSurvey خودش را بروز رسانی می کند که در گزارش خودش بر اساس CPU-ID هم گزارش بدهد که آیا قابلیت پشتیبانی از FT دارد یا خیر ، در حال حاضر فقط یک سری خانواده CPU مشخص را پشتیبانی می کند و امکانسنجی در نرم افزار وجود ندارد.

زمانیکه ارتباط شبکه بین دو Host قطع شود که در اصطلاح فنی به آن Split-Brain گفته می شود ، Secondary VM تلاش می کند که خودش را تبدیل به Primary VM کند چون تصورش این است که Host اصلی دچار مشکل شده است و باید به سرعت سرویس دهی را شروع کند ، در چنین حالتی ممکن است دو عدد Primary VM در لحظه در شبکه ایجاد شود. برای جلوگیری از به وجود آمدن چنین مشکلی از یک قفل یا Lock که درون یک فایل خاص در FT ایجاد می شود استفاده می شود.

زمانیکه یک خرابی تشخیص داده شود هر دو VM تلاش می کنند که این فایل را تغییر نام بدهند ، اگر Secondary VM موفق به تغییر دادن اسم این فایل شود تبدیل به Primary VM می شود و یک Secondary VM جدید هم در Host دیگری در Cluster ایجاد می کند. حال اگر Secondary VM موفق به تغییر اسم فایل نشود و دلیل آن روش بودن Primary VM باشد ، Secondary VM از بین می رود و یک Secondary VM جدید در Host دیگری در Cluster ایجاد می شود.

برای تعداد Host هایی که می توانند درون یک FT-Cluster قرار بگیرند محدودیتی وجود ندارد اما شما نمی توانید از برای VM هایی که FT بر روی آنها فعال شدن است Span Cluster ایجاد کنید. شاید در نسخه های بعدی از VSPhere این قابلیت پشتیبانی شود و شما بتوانید از Spanning Clusters هم استفاده کنید. یک API برای FT وجود دارد که امکان انجام دادن برخی از کارها مثل فعال و غیرفعال کردن FT با استفاده از PowerShell را به شما می دهد و شما برخی کارهای مربوط به FT را می توانید از طریق اسکریپت نویسی انجام دهید.

در حال حاضر شما می توانید بر روی هر کدام از Host های خودتان حداکثر 4 عدد VM داشته باشید که در حالت FT کار کنند ، البته توجه کنید بر روی هر Host نه بر روی هر Cluster ، البته این یک محدودیت عجیب و غریب نیست ، در واقع اگر بیشتر از این تعداد شما VM را در حالت FT بر روی یک Host قرار بدهید کارایی Host و شبکه شما دچار اختلال می شود.

نسخه های فعلی FT به گونه ای طراحی شده اند که فقط می توانند بین Host های یک Datacenter قابلیت FT را ایجاد کنند و هنوز نمی توانند بر روی شبکه های WAN و لینک های سرعت پایین ، بین Datacenter ها کار کنند و این امر هم طبیعی است ، مشکلات مربوط به سرعت و تاخیر ارسال و دریافت و همچنین مشکلات failover شدن بین سایت ها در حال حاضر زیاد است . شاید در نسخه های بعدی امکان ایجاد کردن FT بین Datacenter ها هم با مهندسی بیشتر در این حوزه امکانپذیر شود.


تصویر مروبط به Spanning Clusters یا Stretched Cluster

توجه کنید که در صورتیکه Secondary VM نتواند به اندازه کافی منابع پردازشی از CPU دریافت کند ممکن است باعث کند شدن Primary VM شود. البته شاید این کندی از نظر شما چیزی نباشد و بین 1 یا حداکثر چند ثانیه باشد اما به هر حال در فرآیند های کلان سازمانی همین چند ثانیه هم ممکن است مهم باشد.

برای برطرف کردن این مشکل باید مطمئن باشید که سرعت CPU های Host ها یکسان هستند و از طرفی از طریق اعمال برخی تنظیمات بر روی Primary VM به نام CPU Reservation شما می توانید مطمئن شوید که سرعت CPU مربوط به VM ها هم یکسان است ، اگر در چنین حالتی Primary VM احساس کند که Secondary VM بر روی یکی از Host ها باعث ایجاد کندی برای Primary VM می شود ، بلافاصله Secondary VM مشکل ساز را از مدار خارج و یک Secondary VM جدید بر روی یک Host جدید در Cluster ها ایجاد می کند.

CPU Reservation در VM در FT

بروز رسانی و Patch کردن Host ها در زمانیکه شما از سرویس FT استفاده می کنید کمی ممکن است مشکل ساز شود و نیاز به کمی مهارت در انجام این کار وجود دارد ، توجه کنید که هر دو Host ای که در FT قرار می گیرند باید در یک سطح باشند و تمامی Patch هایی که در یک سمت وجود دارد در سمت دیگر نیز بایستی وجود داشته باشد ، برای انجام اینکار دو روش پیشنهاد می شود.

ساده ترین روش این است که زمانیکه می خواهید Host ها را بروز رسانی کنید سرویس FT را بصورت موقتی غیرفعال کنید و عملیات بروز رسانی خود را انجام دهید و بعد از اتمام فرآیند بروز رسانی و یکسان شدن Host ها مجددا سرویس FT را بر روی VM های مورد نظرتان فعال کنید.

اما در چنین حالتی هم شما Downtime دارید و ممکن است مدت زمان طولانی طول بکشد که Host های شما بروز رسانی شود ، روش بهتر این است که شما اگر دو یا چهار عدد Host بر روی Cluster خودتان دارید ، VM هایی که بر روی آنها FT فعال شده است را بر روی Host های دیگری که وجود دارند VMotion کنید و بعد از بروز رسانی Host های قبلی ، مجددا VM ها را به محل قبلی خودشان VMotion کنید و FT را فعال کنید. با این روش شما Downtime نخواهید داشت. بعد از انجام اینکار شما می توانید سایر Host ها را هم بروز رسانی کنید.

FT براحتی قابل پیاده سازی ، فعال و غیرفعال کردن در هر لحظه است ، بعضا زمانیکه شما می خواهید مواردی از قبیل SVMotion ، Snapshot ، Hot-Add و یا ... را که توسط FT پشتیبانی نمی شود را انجام دهید می توانید بصورت لحظه ای آن را غیرفعال کنید و سپس بعد از انجام کار آن را فعال کنید. برخی اوقات شما نمی خواهید یک VM را بصورت دائمی در FT داشته باشد و صرفا جهت انجام یک فرآیند مقطعی دسترسی پذیری یک VM مهم است و شما می توانید برای مدت زمان خاصی FT را برای آن VM فعال کنید .

برای مثال ممکن است یک فرآیند پردازشی سازمانی داشته باشید که چند روز نیاز به کار داشته باشد و در این میان دسترسی پذیری سرور بسیار مهم است ، شما می توانید در چنین مواردی FT را فعال کنید و پس از اتمام کار آن را غیرفعال کنید. زمانیکه FT فعال می شود هرگونه محدودیت استفاده از حافظه یا Memory Limit از روی Primary VM حذف می شود و Memory Reservation هم دقیقا برابر با RAM ای خواهد شد که به VM اختصاص داده شده است. زمانیکه FT فعال شده باشد شما نمی توانید Memory Limit ، Memory Reservation ، Share ها و .. را از روی Primary VM تغییر بدهید.

خلاصه

بعد از گذشت چند روز که هیچ مطلب و مقاله خاصی در وب سایت قرار ندادم تصمیم گرفتم یکی از محبوب ترین و البته پیشرفته ترین سرویس های موجود در VSPhere به نام Fault Tolerance را برای شما تشریح کنم ، البته قطعا نکات در خصوص پیاده سازی و استفاده از اینگونه قابلیت های VSPhere بسیار زیاد است و ما سعی کردیم تا جای ممکن بهترین کیفیت را در توسینسو به شما ارائه بدهیم .

در نهایت شما باید مستندات مربوط به پیاده سازی این قابلیت را به خوبی مطالعه کنید و از جهتی حتما بصورت عملی FT را پیاده سازی کنید تا تجربه کاری شما هم بالا برود ، شاید باور نکنید که نوشتن این سری مطالب در خصوص FT به یکباره به ذهنم خطور کرد و بعد از پیاده سازی FT در محیط شرکت تصمیم گرفتم که در خصوص این سرویس مطلبی ارائه کنم ، امیدوارم مورد توجه شما قرار گرفته باشد ولی واقعا حلال نمی کنم اگر این مطلب رو کپی کنید و نام نویسنده و منبع را ذکر نکنید. توسینسو باشید


محمد نصیری
محمد نصیری

بنیانگذار توسینسو ، هکر کلاه سفید ، کارشناس امنیت اطلاعات و ارتباطات و عاشق طبیعت

هکر با کلاه ، کارشناس امنیت اطلاعات و ارتباطات و کشف جرائم رایانه ای ، بیش از 12 هزار ساعت سابقه تدریس در بیش از 40 سازمان دولتی ، خصوصی و نظامی ، علاقه مند به یادگیری بیشتر و عاشق محیط زیست ، عضو کوچکی از مجموعه توسینسو

نظرات