در توسینسو تدریس کنید

و

با دانش خود درآمد کسب کنید

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

در مقاله قبلی در انجمن تخصصی فناوری اطلاعات ایران در خصوص این صحبت کردیم که ایجاد کردن 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 ها بصورت جداگانه انجام می شود. به قول ITPRO ای خودم به شدت و به شدت توصیه می شود که کارت شبکه ای که برای 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 را منتقل نکند.


نویسنده : محمد نصیری
منبع : جزیره مجازی سازی وب سایت توسینسو
هرگونه نشر و کپی برداری بدون ذکر منبع و نام نویسنده دارای اشکال اخلاقی می باشد
#معرفی_سرویس_fault_tolerance_در_vmware #تفاوت_vmotion_و_storage_vmotion #کاربرد_vlockstep_چیست #vlockstep_چیست #fault_tolerance_در_vmware #datastore_cluster_چیست #ft_logging_nic_چیست #ft_logging_چیست #تکنولوژی_record_و_replay_در_cpu #قابلیت_flash_read_cache_در_vmware
عنوان
1 معرفی قابلیت Fault Tolerance و FT Logging در VSPhere - قسمت 1 رایگان
2 معرفی قابلیت Fault Tolerance و FT Logging در VSPhere - قسمت 2 رایگان
3 معرفی قابلیت Fault Tolerance و FT Logging در VSPhere - قسمت 3 رایگان
4 معرفی قابلیت Fault Tolerance و FT Logging در VSPhere - قسمت 4 رایگان
5 معرفی قابلیت Fault Tolerance و FT Logging در VSPhere - قسمت 5 رایگان
6 معرفی قابلیت Fault Tolerance و FT Logging در VSPhere - قسمت 6 رایگان
زمان و قیمت کل 0″ 0
0 نظر

هیچ نظری ارسال نشده است! اولین نظر برای این مطلب را شما ارسال کنید...

نظر شما
برای ارسال نظر باید وارد شوید.
از سرتاسر توسینسو
تنظیمات حریم خصوصی
تائید صرفنظر
×

تو می تونی بهترین نتیجه رو تضمینی با بهترین های ایران بدست بیاری ، پس مقایسه کن و بعد خرید کن : فقط توی جشنواره تابستانه می تونی امروز ارزونتر از فردا خرید کنی ....