مرحله ۳: اجرا شدن سرویس DRS و ایجاد تعادل و توازن در میزان منابع تخصیص یافته به ماشین های مجازی و سرویس های در حال اجرا (P24)
مرحله ۴: واگزار کردن کنترل به ESX در حال اجرا بر روی سیستم های میزبان و نیز سرویس های سطح بالا مانند HA clusterها و FT pairها برای کنترل و مدیریت دینامیک سیستم (P25-P33 و P40-P43).

(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. ))

با این تقسیم بندی، در نگاه اول می توان دریافت که نحوه انتقال کنترل در مراحل ۲ الی ۴ به شدت وابسته به نحوه اجرای کار در مرحله ۱ است. با این توضیح که با توجه به تعداد سیستم های ذخیره سازی و تعداد سیستم های میزبان بوت شده، می توان تعیین کرد که آیا سیستم قابلیت اجرای سرویس های سطح بالا را دارد یا خیر. به عنوان مثال، یک جفت fault tolerance برای اجرای صحیح خود نیاز به حداقل دو سیستم میزبان دارد. همچنین میزان منابع تخصیص یافته به ماشین های مجازی و نیز منابع رزرو شده کاملا وابسته به همین نکته است. در مرحله آخر نیز با توجه به سرویس های اجرا شده و کلاسترها و جفت های به وجود آمده، گردش کار در سیستم رخ می دهد. در انتها مدیر سیستم نیز با توجه به تعداد سیستم های میزبان در دسترس می تواند سرویس هایی مانند مهاجرت ماشین های مجازی توسط VMotion را درخواست نماید. با توجه به اینکه در این سناریوی ساده تنها دو سیستم ذخیره سازی و دو میزبان آورده شده است، می توان دریافت که در یک دیتا سنتر واقعی میزان پیچیدگی فضای حالت بسیار بیش از این خواهد بود.
گزارهای T9 الی T21 و T45 الی T47 حالاتی را که ممکن است در مورد بوت شدن یا مختل شدن سیستم ها رخ دهد نشان می دهد. همانطور که دیده می شود، یک جایگشت بین حالات ممکن رخ داده است و در نهایت، این حالات به پنج گروه کلی تقسیسم شده اند:
اگر تمام چهار عنصر به درستی بوت شوند سیستم در حالت P13 یا بوت کامل^[۱۵۲] قرار می گیرد. این حالت که انتظار مدیر از سیستم است امکان اجرا کردن تمامی سرویس های سطح بالا و حداکثر تعداد ماشین های مجازی که سیستم می تواند داشته باشد را فراهم می کند.
اگر هر دو سیستم ذخیره سازی بوت شود اما تنها یکی از سیستم های میزبان به درستی بوت شود و دیگری مختل گردد، سیستم در وضعیت P14 قرار می گیرد. در این حالت امکان ایجاد و راه اندازی ماشین های مجازی به تناسب منابع پردازشی میزبان بوت شده وجود دارد اما به دلیل ناکافی بودن تعداد سیستم های میزبان، سرویس هایی مانند HA و fault tolerance اجرا نخواهد شد.
در صورتی که هر دو سیستم میزبان و نیز یکی از سیستم های ذخیره سازی به درستی بوت شوند، سیستم در حالت P15 قرار می گیرد. که در این حالت نیز امکان اجرا شدن سرویس ها و نیز ماشین های مجازی وجود خواهد داشت. منتها با توجه به اینکه در این معماری هر ماشین مجازی در واقع یک فایل بر روی دیسک می باشد، امکان ارائه برخی از سرویس ها محدود خواهد شد. در مورد جزئیات این سرویس ها و مدل فرمال آنها در بخش های بعدی به تفصیل صحبت خواهد شد.
اگر تنها یک سیستم ذخیره سازی و یک میزبان به درستی بوت شوند، سیستم در وضعیت P16 قرار می گیرد. این حالت، حداقلی است که سیستم برای ادامه کار خود و ارائه سرویس به آن نیاز دارد. به این معنی که با حداقل یک سیستم ذخیره سازی و یک سیستم میزبان، یک دیتا سنتر می تواند ماشین های مجازی را ایجاد و اجرا نماید. طبیعتا در این حالت امکان ارائه سرویس های سطح بالا نیز وجود نخواهد داشت.
و در نهایت، اگر تنها یکی از چهار مولفه نام برده شده بوت شود و یا هیچ کدام بوت نشوند، سیستم در وضعیت P17 قرار می گیرد. در این حالت گفته می شود سیستم دچار اختلال شده است و امکان ادامه مراحل وجود ندارد. اگر تنها یک سیستم ذخیره سازی بدون هیچ سیستم میزبانی بوت شده باشد، منبع پردازشی برای اجرای ماشین های مجازی وجود ندارد. همچنین اگر تنها یکی از سیستم های میزبان بدون هیچ منبع ذخیره سازی بوت شده باشد، امکان ذخیره سازی و بازیابی فایل های مربوط به ماشین های مجازی و سیستم عامل آنها وجود ندارد پس باز هم سیستم دچار بن بست خواهد شد. در این وضعیت باید تلاش شود تا سیستم طی چند مرحله ایراد یابی و دوباره بوت شود.
در صورت بروز هریک از حالات ۱ تا ۴، سیستم پس از ایجاد و اجرای ماشین های مجازی، بر اساس تعداد و نوع مولفه های بوت شده توانایی اجرای سرویس های سطح بالا را خواهد داشت. در صورت فعال شدن P19، با این معنی که سیستم توانایی ارائه سرویس های سطح بالا را دارد، بر حسب اینکه مدیر سیستم مایل به تعریف کلاستر HA و یا جفت های FT می باشد، سیستم می تواند گام های متناظر را طی نماید. این گام ها برای سرویس اول (HA) گزارهای T28 و T30 و برای سرویس دوم (FT) گزارهای T31 الی T32 خواهد بود. با هر بار اجرا شدن این حلقه ها، یک کلاستر HA یا یک جفت FT تعریف می گردد. بنابراین برای تعریف چندین نمونه از آنها حلقه ها باید چند بار طی شوند. هرگاه که یک کلاستر HA تعریف می شود یا یک ماشین مجازی به یک کلاستر HA اضافه می گردد، سیستم در وضعیت P21 قرار می گیرد. همچنین هرگاه یک جفت FT تعریف می شود سیستم در وضعیت P22 قرار می گیرد. قرار گرفتن در این دو حالت به این معنی است که مدیر می تواند سیستم را به وضعیت های P18 و P19 برای تعریف نمونه جدیدی از سرویس ها برگرداند و یا می تواند به تعریف سرویس ها خاتمه داده و سیستم به مرحله بعدی برود. این بدان معنی است که هر دو وضعیت “آماده برای مرحله بعد” (گزارهای T29 و T33) و نیز “بازگشت برای تعریف نمونه جدیدی از سرویس ها” (گزارهای T30 و T32) در این مرحله فعال^[۱۵۳] هستند اما اجرا شدن^[۱۵۴] گزارها وابسته به تصمیم سیستم خواهد بود.
بعد از مراحل گفته شده، در مرحله سوم که مرحله کوچک اما بسیار حیاتی برای سیستم می باشد، منابع سخت افزاری بر روی سیستم های میزبان زمان بندی و متعادل^[۱۵۵] می شوند. این فرایند به وسیله سرویس هوشمند DRS صورت می پذیرد که در آن بر اساس ماشین های مجازی اجرا شده و نیز سرویس های سطح بالای راه اندازی شده، مقدار متناسبی از منابع پردازشی و حافظه به ماشین ها تخصیص یافته و مقداری نیز به اجرای سرویس ها واگذار می شود. همچنین درصد مناسبی از منابع برای اجرا در مواقع ضروری مانند از کار افتادن یک میزبان و نیاز به انتقال ماشین های مجازی از طریق سرویس هایی مانند HA و VMotion رزرو می شود. بدون اجرا شدن موفقیت آمیز این مرحله، ما اطمینانی از توانایی سیستم در تخصیص منابع لازم به ماشین های مجازی در زمان بروز مشکل در سیستم های میزبان یا سیستم های ذخیره سازی نخواهیم داشت. نحوه کار این سرویس ها در بخش های بعدی تشریح و تحلیل خواهد شد.
در مدل مذکور، اجرای سرویس DRS در گزار T35 نشان داده شده است. همانطور که مشاهده می شود این گزار یک گزار زمان دار^[۱۵۶] است که به معنی اجرای تعداد زیادی از زیرپروسه ها برای اجرای آن می باشد.
آخرین نکته قابل توجه در مرحله سوم این است که اگر بر مبنای خروجی مرحله دوم، امکان ارائه سرویس های سطح بالا به دلیل کمبود منابع سخت افزاری وجود نداشته باشد، سیستم در حالت P23 قرار خواهد گرفت. در این وضعیت مدیر سیستم تنها قادر به راه اندازی ماشین های مجازی بر حسب میزان منابع سیستم خواهد بود و سرویس ها ارائه نخواهند شد. در این شرایط، تنها پس از اجرای موفقیت آمیز ماشین های مجازی، گزار T34 فعال می گردد که با اجرا شدن آن سیستم برای اجرای سرویس DRS آماده خواهد بود.
مرحله چهارم که مرحله نهایی نیز می باشد، مربوط به قرار گرفتن سیستم در وضعیت طبیعی اجرایی و انتقال کنترل هر ماشین میزبان به ESX آن است. در این مرحله که کنترل سیستم را برای همیشه در دست خواهد داشت، هر ESX مسئول سرویس دادن به ماشین های مجازی اجرا شده بر روی خود است. همچنین در هر زمانی به دلیل شرایط محیطی یا به درخواست مدیر سیستم، هر یک از سرویس های سطح بالا می تواند اجرا شود. این سرویس ها به کمک سیگنال های ضربانی^[۱۵۷] یا مکانیزم های مبتنی بر agent از شرایط محیطی که باید در آن فعال شوند مطلع می گردند.
لازم به ذکر است که پروسه های داخلی هر یک از گزارهای T36، T38، T41 و T43 مدل های پیچیده ای برای خود دارند. به عبارت دیگر در یک مدل سلسله مراتبی، ما این پروسه را در یک گزار خلاصه کرده ایم اما در بخش های بعدی با دقیقتر شدن بر روی نحوه کار آنها، مدل هایی برای این بخش ها ارائه خواهیم نمود.

ارزیابی و تحلیل مدل فرمال
در این بخش با تحلیل مدل ارائه شده در بخش قبل، سعی خواهیم کرد حقایقی را در مورد سیستم استخراج نمائیم. با یادآوری از فصل ۲، در این بخش به بررسی خصوصیات رفتاری سیستم در مدل شبکه پتری ارائه شده می پردازیم تا خصوصیات Liveness، Safeness و Reversibility را بر روی آن تحلیل نمائیم. در نهایت میزان خوش رفتاری سیستم را در فضای حالت مورد بررسی تعیین می نمائیم. در ادامه قضایایی برای تحلیل مدل ارائه شده اند.
۴٫۲٫۱٫۱٫ Liveness
با تکیه به قضیه ۱ از فصل ۲ و توجه به مدل ارائه شده، واضح است که هیچ موقعیت یا گزار source و یا sink در آن وجود ندارد بنابر این با این تعریف اولیه، سیستم دارای خصوصیات Liveness و Safeness می باشد. با این حال با ارائه دلایل بیشتر مدل را بررسی می کنیم.
۴٫۲٫۱٫۲٫ Safeness
بر اساس تعریف درخت پوشا، می توان قضیه ۲ را به گراف پوشا نیز تعمیم داد. در این صورت با بررسی گراف پوشای این مدل می توانیم از safe بودن سیستم مطمئن شویم.
در این تحقیق برای تحلیل مدل های طراحی شده از نرم افزار بررسی مدل شبکه پتری PIPE^[158] نسخه ۳ استفاده شده است. گراف پوشای بدست آمده برای مدل ۴٫۴ به کمک این نرم افزار در شکل ۴٫۵ آمده است. با بررسی این گراف در میابیم که تمام لبه ها دارای برچسب ۰ و ۱ بوده اند. این بدان معنی است که در تمام تغییر حالات از به تعداد توکن های موجود در موقعیت ها هیچ گاه بیشتر از ۱ نبوده است. با این استدلال می توان مطمئن بود که سیستم ۱-bounded و در نتیجه safe می باشد.
شکل ۴٫۵ گراف پوشا برای مدل پتری شکل ۴٫۴
برای اطمینان از درست بودن نتیجه به دست آمده، خصوصیات رفتاری شبکه پتری مذکور را با نرم افزار PIPE بررسی می کنیم. حاصل این بررسی نشان می دهد که مدل دارای خصوصیات Boundedness و Safeness بوده و دارای deadlock نیز نمی باشد به این معنی که سیستم Live است (شکل ۴٫۶).
شکل ۴٫۶٫ نتیجه تحلیل فضای حالت به وسیله نرم افزار PIPE
۴٫۲٫۱٫۳٫ Reversibility
برای بررسی این خصوصیت لازم است به تعریف Reversibility توجه کنیم. با یاد آوری تعریف این مفهوم و نیز خاصیت Reachability از فصل ۲ داریم: شبکه پتری ()، Reversible خواهنده می شود اگر برای هر وضعیت^[۱۵۹] M، در دنباله قابل اجرا از (R())، از طریق M، reachable باشد.
با این تعریف، در شبکه های کوچک می توان با بررسی کلیه وضعیت های محتمل در شبکه، reachable بودن را از طریق آنها بررسی نمود. در صورتی که از طریق تک تک این وضعیت ها ( تا ) قابل دسترسی باشد این شبکه Reversible است. با توجه به اینکه این وضعیت ها تماما در گراف پوشای مدل منعکس می شوند می توان با بررسی گره های گراف این حالات را بررسی نمود.
به این ترتیب در صورت پیدا کردن یک مثال نقض در گراف ۴٫۵، می توان از عدم وجود خاصیت Reversibility در مدل اطمینان یافت. با بررسی گراف می بینیم که با قرار گرفتن توکن در موقعیت P25 و اجرای T40 (وضعیت S94)، سیستم به وضعیت S96 رفته و از این به بعد امکان بازگشت به S0 () وجود ندارد.
در مثال دیگری با اجرا شدن T25 یا T27 سیستم در وضعیت S89 قرار می گیرد. در این حالت در موقعیت های P18 و P19 توکن وجود دارد. با بررسی گراف می بینیم که اینجا نیز امکان بازگشت سیستم به حالت اولیه () وجود ندارد.
به این ترتیب ملاحظه می شود که مدل ۴٫۴ دارای خاصیت Reversibility نمی باشد.
با بررسی سیستم واقعی خواهیم دید که مدل متناظر نباید به طور مطلق Reversible باشد. زیرا پس از بوت اولیه سیستم و ایجاد و راه اندازی ماشین های مجازی و سرویس های سطح بالا، کنترل سیستم به مرحله ۴ منتقل شده و سیستم در وضعیت نرمال اجرای درخواست های ماشین های مجازی توسط ESX و اجرای سرویس های سطح بالا در صورت لزوم باقی می ماند و هیچ گاه به مرحله نخست راه اندازی باز نمی گردد. با این حال می توان گفت که سیستم به طور ضمنی (جزئی) Reversible است زیرا پس از انتقال کنترل به مرحله ۴ (موقعیت های P25، P27، P29 و P32) توکن ها به صورت گردشی در این بخش حرکت کرده و پس از هربار اجرای یک سرویس به موقعیت اولیه خود در این مرحله باز می گردند.
بنابراین با توجه به برآورده نشدن خصوصیت Reversibility به طور مطلق، سیستم به طور خوش رفتار نمی باشد و به آن نیازی نیز ندارد.

بررسی لایه های پایینتر مدل فرمال
در این بخش از تحقیق لازم به ذکر است که این مدل انتزاعی ترین سطح تصور ما از دیتا سنتر طرح شده در بخش گذشته است. با این توضیح که بخش های زیادی از وظایف لازم الاجرا در چنین سیستمی در این مدل از نظر دور مانده و تنها به طرح یک گزار برای نشان داده کلیه وظایف فوق بسنده شده است. این کار به منظور ارائه یک مدل کلی برای بررسی رفتار کلی دیتا سنتر انجام شده است و به معنی حذف بخش های مذکور نمی باشد. در مدل شکل ۴٫۴، کلیه گزارهایی که به شکل توخالی نشان داده شده اند نشان دهنده مجموعه ای از وظایف و مسئولیت های دیتا سنتر هستند که برای ایجاد انتزاع بیشتر خلاصه شده است. به عنوان مثال گزار T28 نشان دهنده کلیه اعمال لازم برای ایجاد یک کلاستر HA یا اضافه کردن یک سیستم میزبان به یک کلاستر موجود است. یا گزار T36 بیانگر پروسه سرویس دهی ESX به ماشین های مجازی خود در صورت صدور درخواست از جانب آنها است.
به این ترتیب و برای بررسی دقیق و جامع تر دیتا سنتر نمونه، لازم است مدلی برای هر یک از زیر مجموعه های این طرح کلی طراحی شده و آنها را نیز ارزیابی و تحلیل نمائیم. به این ترتیب می توان اطمینان بیشتری نسبت به نحوه کار سیستم و مشخصاتی از جمله پایداری، توسعه پذیری و انعطاف پذیری آن داشت.

بررسی نحوه کار سرویس HA
در این بخش ابتدا به شرح نحوه کار سرویس VMware HA می پردازیم و پس از آن مدل شبکه پتری مربوط به این سرویس طراحی و تحلیل خواهد شد.