دانلود فایل های آموزشی

دانلود نمونه سوال فایل های آموزشی و پژوهشی نقد و بررسی مظالب دانشگاهی پروژه های دانشجویی تحقیق و مقاله

برای دانلود متن کامل پایان نامه ها اینجا کلیک کنید

پایان نامه های کارشناسی ارشد-— (298)- دانلود نمونه پژوهش علمی


در این زبان می توان از سودوکدهای ساده استفاده نمود بنابراین نحو زبان برای اکثر افراد قابل درک است. بر خلاف بسیاری از ابزار، می توان مدل طرح شده به ASM را مستقیما اجرا نمود تا نتیجه رفتار سیستم مشخص گردد. همچنین از این ابزار می توان برای مدل کردن طیف وسیعی از سیستم ها …


دانلود فایل- — (298)- دانلود فایل

در این زبان می توان از سودوکدهای ساده استفاده نمود بنابراین نحو زبان برای اکثر افراد قابل درک است. بر خلاف بسیاری از ابزار، می توان مدل طرح شده به ASM را مستقیما اجرا نمود تا نتیجه رفتار سیستم مشخص گردد. همچنین از این ابزار می توان برای مدل کردن طیف وسیعی از سیستم ها استفاده کرد. از جمله می توان به سیستم های تسلسلی، موازی، توزیع شده، real time، سیستم های متناهی و نامتناهی و غیره اشاره نمود که نشان دهنده انعطاف پذیری ابزار می باشد. در ادامه نمونه ای از نحو زبان ASM آورده شده است. این بخش چگونگی انتقال پیام مابین Agent ها را نشان می دهد. ]14[. class COMMUNICATOR Program() = let availableMsgs = {m | m in me.mailbox where ReadyToDeliver(m)} let selectedMsgs = chooseSubset(availableMsgs) forall msg in selectedMsgs me.mailbox(msg) := false //delete the message let resolvedMsgs = ResolveMessage(msg) //resolve the message forall m in resolvedMsgs let a = Recipient(m) if a <> undef then // if recipient found InsertMessage(a,m) // forward the message else skip // else ignore message برای مطالعه بیشتر به ]29[ الی ]32[ مراجعه کنید. LOTOS LOTOS توسط سازمان ISO برای بیان فرمال استاندارد های مربوط به OSI ساخته شد. این زبان به عنوان به عنوان یک FDT تحت استاندارد ISO/IEC 8807 در سال 1989 ارائه گردید. LOTOS یک زبان توصیف فرمال مبتنی بر روابط جبری است که برای توصیف سیستم های موازی و توزیع شده مناسب می باشد ]15[. در واقع دو بخش اصلی تشکیل دهنده LOTOS عبارتست از ADT و جبر پروسه ها. به دلیل پشتیبانی از گونه های داده ای انتزاعی، این زبان می تواند تبادل اطلاعات و در نتیجه رابطه بین اجرا را به خوبی توصیف نماید. همچنین به دلیل جبری بودن، خواص عملکردی سیستم را توصیف می نماید. به علاوه، پشتیبانی از عملگرهای --poral باعث می شود که این زبان توانایی توصیف خواص رفتاری و جنبه های زمانی سیستم ها را نیز داشته باشد. مقدمه ای بر جبر پروسه ها ]16[ در این جبر، اجزای سیستم به صورت پروسه های انتزاعی نمایش داده می شوند که با یکدیگر ارتباط دارند. پروسه ها به صورت جعبه سیاه دیده می شوند که تنها رفتار خارجی آنها مورد بررسی قرار می گیرد. همچنین پروسه ها به کمک مکانیزم interaction point با یکدیگر رابطه برقرار می کنند. در LOTOS به این نقاط event gate یا به اختصار gate گفته می شود (شکل 2.3). شکل 2.3. نقطه gate در جبر پروسه ها ]4[ Event نشان دهنده یک همگامی بین دو یا چند پروسه است. به طور کلی سه نوع event تعریف شده اند: Pure synchronization: هیچ مقداری بین پروسه ها تبادل نمی شود. Value establishment: مقادیر ارائه شده توسط یک یا چند پروسه از سوی بقیه مورد پذیرش نیست. Value negotiation: مقادیر از سوی یک یا چند پروسه مورد قبول است. همچنین یک عبارت رفتاری انتخابی از بین مجموعه ای از event ها است که برای یک محیط مطرح می گردد. در شرایطی که امکان همگام سازی بین eventهای پیشنهاد شده در یک محیط وجود نداشته باشد یک بن بست رخ داده است. همچنین اگر هیچ پیشنهادی در محیط مطرح نشده باشد یک livelock رخ می دهد (مانند یک حلقه بینهایت). همچنین LOTOS مفهوم ترتیب زمانی eventها را نیز به قواعد جبری موجود اضافه نموده است. این زبان از عملگرهای --poral برای ترکیب عبارات رفتاری و به دست آوردن عبارات رفتاری پیچیده تر استفاده می کند. در عین حال این عملگرها از قواعد خوش تعریف پیروی می نمایند که تفسیر صریح و یکسانی را برای افراد ممکن می سازد. به عنوان خلاصه ای از خصوصیات LOTOS، می توان آنرا تعریف فرمالی از ترکیب داده و کنترل، بر مبنای جبر پروسه ها دانست که همزمانی یکی خصوصیات ذاتی آن است. همچنین قواعد LOTOS به دلیل عملیاتی بودن قابل تفسیر و اجرا می باشد و ماژولار است ]17[. در ادامه مثالی از مدلسازی مساله تولید کننده- مصرف کننده با این زبان آورده شده است. در این مساله سه ماژول تولید کننده، مصرف کننده و کانال که وظیفه هماهنگ سازی این دو را به عهده دارد حضور دارند. لازم به ذکر است که تغییراتی در صورت مساله به وجود آمده تا خصوصیات LOTOS بهتر نشان داده شود. ازآن جمله، تولید کننده می تواند دو خروجی را به صورت همزمان یا غیر همزمان تولید نماید و سپس متوقف شود. همچنین مصرف کننده پس از مصرف ترتیبی یا همزمان آنها متوقف می گردد (شکل 2.4). شکل 2.4. مدل تولید کننده- مصرف کننده به کمک LOTOS ]17[ برای کنترل پیچیدگی مساله، در ابتدا عمل تجزیه را روی این سه بخش انجام داده و هر یک را به عنوان یک پروسه مستقل تشریح می کنیم. سپس آنرا را با هم ترکیب می نمائیم. با توجه به تعاریف pc1 و pc2 به عنوان کانال های تولید کننده و cc1 و cc2 به عنوان کانال های مصرف کننده و همچنین عملگرهای انتخاب ([]) و فعال سازی (>>) می توان پروسه های فوق را به صورت زیر تعریف نمود: پروسه تولید کننده: process Producer [pc1, pc2] : exit := pc1; pc2; exit endproc پروسه کانال: process Channel [ pc1, pc2, cc1, cc2] : exit := pc1; ( pc2; cc1; exit [] cc1; pc2; exit ) >> cc2; exit endproc پروسه مصرف کننده: process Consumer [cc1, cc2] : exit := cc1; cc2; exit endproc در این بین می توان جزئیات اجرایی بیشتر مانند عملکرد داخلی هریک از پروسه ها را با عملگرهای بیشتری مدل نمود به عنوان مثال مساله گم شدن یکی از ورودی ها به کانال به شکل زیر قابل توصیف است: process Channel [pc1, pc2, cc1, cc2] : exit := pc1; ( pc2 ; cc1; exit [] cc1; pc2; exit [] i; pc2; exit ) >> ( cc2; exit [] i; exit) Endproc در نهایت با تعریف عملگر میانه گزاری (|||) برای شبیه سازی توازی بین پروسه ها می توان ترکیب سه پروسه یاد شده را به شکل زیر نوشت: specification Producer_Consumer [ pc1, pc2, cc1 cc2 ] : exit behavior ( Producer [ pc1, pc2 ] ||| Consumer [ cc1, cc2 ] ) || Channel [pc1, pc2, cc1, cc2] where process Producer [ out1, out2 ] : exit := . . . (*As defined previously*) process Consumer [ in1, in2 ] : exit := . . . (*As defined previously *) process Channel [ le1, le2, , re1, re2 ] : exit := . . . (*As defined previously *) endspec برای جزئیات بیشتر در مورد مثال فوق و عملگرهای زبان LOTOS به ]17[ و برای مطالعه بیشتر در مورد زبان LOTOS به ]33[ الی ]34[ مراجعه کنید. VDM-SL VDM-SL ابزاری برای توصیف مسائل نرم افزاری است که به صورت مجرد و مستقل از جزییات ماشین ابداع شده است. با توجه به اینکه VDM یک زبان بوده و دارای semantic فرمال می‌باشد، ابزای برای ارزیابی آن نیز ارایه شده است که می‌توان الگوریتم های مدل شده در این زبان را ارزیابی نمود. همچنین ابزاری برای اجرای سیستم مدل شده و مشاهده نتیجه تست برای آن پیش‌بینی شده تا کسانی که با VDM آشنایی ندارند بتوانند سیستم مورد نظر خود را بررسی کنند. با این حال این زبان قابلیت مدل سازی سیستم‌های موازی را ندارد. با توجه یه اینکه VDM یک زبان model-based است به طور کلی تفاوت بین این گروه از ابزار فرمال و متدهای جبری را می توان اینگونه توضیح داد که در گروه اول، ما عملیات در یک سیستم را بر اساس اینکه چه تأثیری بر مقادیر می گزارند توصیف می کنیم. در مقابل در ابزار جبری، خصوصیات عملیات را به صورت مجرد شرح می دهیم ]18[. با توجه به اینکه بیشترین توان VDM در مدل سازی سیستم های خطی است، به نظر می رسد این زبان بیشتر به توصیف خصوصیات کارکردی سیستم می پردازد. بنابراین بخش بزرگی از توصیف به بیان انواع داده‌ای ساده و مجرد و نیز ADT ها مربوط است. در چنین حالتی بسیاری از ساختار های عبارات جبری قابل نگاشت به این زبان هستند. در ادامه مدل ساده‌ای از VDM برای مدل سازی حساب بانکی آورده شده است ]18[: در این مثال مشتری با CustNum و حساب با AccNum مدل می شود. AccNum = token; CustNum = token; Balance = int; Overdraft = nat; AccData :: owner : CustNum balance : Balance state Bank of accountMap : map AccNum to AccData overdraftMap : map CustNum to Overdraft inv mk_Bank(accountMap,overdraftMap) == for all a in set rng accountMap & a.owner in set dom overdraftMap and a.balance >= -overdraftMap(a.owner) برای مطالعه بیشتر به ]35[ الی ]36[ مراجعه کنید. شبکه های پتری شبکه های پتری یکی از قدیمیترین زبان های فرمال برای توصیف و ارزیابی سیستم ها است. از بارزترین خصوصیات این زبان می توان به توانایی آن برای توصیف سیستم های موازی اشاره نمود. همچنین به دلیل پختگی، این زبان مکانیزم هایی برای بیان جنبه های کارکردی و رفتاری سیستم ارائه می نماید. همچنین علاوه بر توانایی توصیف سیستم ها، می تواند شیوه هایی برای تحلیل و ارزیابی و نیز در نهایت اثبات فرمال آنها ارائه نماید ]19[ الی ]22[. بر اساس تعریف، یک شبکه پتری به صورت زیر به شکل فرمال تعریف می شود ]23[: P={p1, p2, …, pm}مجموعه متناهی از موقعیت ها T={t1, t2, …, tn}مجموعه متناهی از گزارها F⊆P×T∪T×Pمجموعه ای از لبه های گراف (روابط بین pها و tها) W: → {1, 2, 3, …} تابع وزن گذاری روابط M0:P →{0, 1, 2, …}وضعیت اولیه سیستم. همچنین ضروری است : P∩T=∅ and P∪T≠∅به عنوان مثال مدل ساده ای از یک پروتکل ارتباطی در شکل 2.5 نشان داده شده است. شکل 2.5. مثالی از مدل سازی یک پروتکل به کمک شبکه های پتری ]23[ در شکل بالا، وضعیت شروع M0= (1,0,0,1,0,0,0,0) می باشد که به معنی فعال بودن موقعیت های p1 و p4 است. بنابراین گزارهای t1 و t5 به ترتیب فعال هستند. باید توجه داشت که فعال بودن یک گزار لزوما به معنی اجرا شدن آن نیست بلکه اجرا شدن به رخ دادن اتفاق در سیستم واقعی بر می گردد. همچنین اجرا شدن t1 و t5 به ترتیب توکن های p1 و p4 را حذف کرده و توکن هایی به p2 و p5 اضافه می کند. خصوصیات رفتاری با تعریف وضعیت شروع به عنوان وضعیت اولیه سیستم ، خصوصیات رفتاری در واقع جنبه هایی از سیستم هستند که به این وضعیت شروع وابسته هستند و در موقعیت های اجرایی سیستم تغییر می کنند. در شبکه (N, M0) (شبکه پتری N با وضعیت شروع M0)، مجموعه تمام دنباله های گزارهای قابل اجرا که از وضعیت M0 شروع می شوند را با L(N, M0) و یا به شکل ساده تر با L(M0) نشان می دهند. به کمک پارامترهای زیر می توان جنبه های رفتاری سیستم توصیف نمود ]23[ و ]24[: Reachability طبق تعریف، وضعیت سیستم در Mn ، از وضعیت M0 ، reachable خواهد بود اگر دنباله ای از اجرای گزارها وجود داشته باشد که M0 را به Mn ببرد. مجموعه وضعیت های قابل دسترسی از طریق M0 را با مجموعه R M0 نشان میدهیم. Boundedness شبکه پتری (N, M0)، k-bounded یا به اختصار bounded خواهد بود اگر تعداد توکن های موجود در هر place، برای همه وضعیت های قابل دستیابی از وضعیت شروع، از تعداد محدود k تجاوز نکند. به عبارت دیگر M p≤k. همچنین یک شبکه پتری 1-bounded، شبکه پتری ایمن نامیده می شود. Liveness این مفهوم در ارتباط نزدیک با مفهوم عدم وجود بن بست در سیستم عامل ها می باشد. شبکه پتری (N, M0)، live خوانده می شود (به عبارت دیگر وضعیت M0 یک وضعیت live برای N شمرده می شود) اگر، بدون توجه به اینکه چه وضعیتی از M0 پیش می آید، در نهایت اجرای تمام گزارهای شبکه با دنبال کردن دنباله ای از گزارها ممکن باشد. این بدان معنی است که یک شبکه پتری live عملیات بدون بن بست را تضمین می کند بدون اینکه ترتیب اجرای گزارها مهم باشد. به عنوان نمونه، شبکه شکل 2.6 دارای خصوصیت Liveness نمی باشد زیرا در صورتی که گزار t1 در ابتدا اجرا شود، دیگر هیچ یک از گزارها امکان اجرا شدن نخواهند داشت. شکل 2.6. نمونه ای از شبکه پتری non-Live ]23[ Liveness خصوصیتی ایده آل برای بسیاری از سیستم ها است. با این حال اثبات و فراهم کردن کامل این خصوصیت دشوار برای بسیاری از سیستم های پیچیده غیر ممکن و هزینه بر است. سیستم عامل کامپیوترهای بزرگ نمونه ای از چنین سیستم هایی است. بنابراین در عمل این خصوصیت نادیده گرفته شده و چندین سطح از Liveness برای شبکه ها در نظر گرفته می شود. بر این اساس سطح Liveness گزار t در شبکه پتری (N, M0) یکی از موارد زیر خواهد بود: Dead (L0-live) اگر t هیچ گاه و در هیچ یک از دنباله های اجرای L(M0) اجرا نشود. L1-live (probably fireable) اگر t حداقل یک بار و در یکی از دنباله های اجرای L(M0) بتواند اجرا شود. L2-live اگر با در نظر گرفتن عدد مثبت k، گزار t بتواند حداقل k بار در دنباله های اجرای مختلف L(M0) اجرا شود. L3-live اگر t به دفعات نامحدودی در تعدادی از دنباله های اجرای L(M0) ظاهر شود. L4-live (Live) اگر t در هر وضعیت M در R(M0) در مرتبه L1-live باشد. ■ گفته می شود شبکه پتری (N, M0)، Lk-live است اگر همه گزارهای موجود در شبکه حداقل از مرتبه Lk-live باشند و k=0,1,2,3,4. همچنین L4-liveness قویترین سطح live بودن سیستم و و معادل مفهومی است که در ابتدای بخش توضیح داده شد. به سادگی می توان دریافت که یک گزار یا شبکه که در سطح k، live است، لزوما در سطح k-1 نیز live خواهد بود. به عبارت دیگر رابطه دلالت بین آنها به این شکل برقرار است: L4-liveness => L3-liveness => L2-liveness => L1-liveness گفته می شود گه یک گزار دقیقا Lk-live است اگر این گزار Lk-live باشد ولی L(k+1)-live نباشد، K=1,2,3. Reversibility شبکه (N, M0)، reversible است اگر برای هر وضعیت M، M0 از طریق M قابل دستیابی (reachable) باشد. Coverability در شبکه (N, M0) گفته می شود وضعیت M قابل پوشش است اگر وضعیت M' در RM0 وجود داشته باشد به طوری که M'p≥Mp. Home state وضعیت M' در شبکه (N, M0)، Home state نامیده می شود اگر برای هر وضعیت M در RM0، M' از M قابل دسترسی باشد. زیر مجموعه های شبکه های پتری تعریف: یک شبکه پتری، شبکه اولیه نامیده می شود در صورتی که وزن تمام لبه های آن 1 باشد. با این تعریف در این بخش شبکه های اولیه ای را معرفی می کنیم که دارای خواص مشترکی هستند. البته باید توجه داشت که شبکه های اولیه و غیر اولیه هر دو دارای قدرت مدلسازی یکسانی هستند و تفاوت آنها در راحتی و سرعت استخراج و اثبات خصوصیات است. در این بخش از نشانه گذاری زیر به عنوان مقدمه استفاده می کنیم. در اینجا F مجموعه همه لبه های شبکه پتری است: •t= {p| (p,t) ∈F} مجموعه موقعیت های ورودی به t  
 نکته مهم : هنگام انتقال متون از فایل ورد به داخل سایت بعضی از فرمول ها و اشکال (تصاویر) درج نمی شود یا به هم ریخته می شود یا به صورت کد نشان داده می شود ولی در سایت اصلی می توانید فایل اصلی را با فرمت ورد به صورت کاملا خوانا خریداری کنید: سایت مرجع پایان نامه ها (خرید و دانلود با امکان دانلود رایگان نمونه ها) : jahandoc.com   t•= {p| (t,p) ∈F} مجموعه موقعیت های خروجی از t •p= {t| (t,p) ∈F} مجموعه گزارهای ورودی به p p•= {t| (p,t) ∈F} مجموعه گزارهای خروجی از p مثال هایی از نشانه های گفته شده در شکل 2.7 نشان داده شده است. با این تعریف می توانیم زیر مجموعه های شبکه های پتری را با اعمال قوانینی در ساختار آنها مشخص کنیم. در این تحقیق فرض شده است که در هیچ یک از شبکه های مورد بحث، موقعیت یا گزار ایزوله وجود ندارد یعنی گزار یا موقعیتی با شرایط •p= p•= Ø یا •t= t•= Ø وجود ندارد. شکل 2.7. نشانه گزاری برای: a) مجموعه موقعیت های ورودی و خروجی برای t و b) مجموعه گزارهای ورودی و خروجی برای p ]23[ با مقدمه گفته شده، کلاس های زیر را برای شبکه های پتری داریم: State Machine (SM) یک شبکه پتری اولیه با این شرط که هر گزار t دقیقا یک موقعیت ورودی و یک موقعیت خروجی داشته باشد. یعنی: |•t| = |t•| = 1for all t T. Marked Graph (MG) یک شبکه پتری اولیه با این شرط که هر موقعیت p دقیقا یک گزار ورودی و یک گزار خروجی داشته باشد. یعنی: |•p| = |p•| = 1for all p P. Free-choice net (FC) یک شبکه پتری اولیه است که در آن هر لبه متصل به یک موقعیت، یا یک لبه خروجی یکتا از یک گزار و یا یک لبه ورودی یکتا به یک گزار است. یعنی: For all p∈P, |p•| ≤1 or •(p•) = {p} که معادل است با: For all p1, p2 ϵP, p1•∩p2•≠∅=>|p1•|=|p2•|=1Extended Free-choice net (EFC) یک شبکه پتری اولیه است که: p1•∩p2•≠∅=> p1•=p2• for all p1, p2∈PAsymmetric choice net (AC) این کلاس که به عنوان شبکه ساده هم شناخته می شود، یک شبکه پتری اولیه است که : p1•∩p2•≠∅=> p1•⊆p2•or p2•⊆p1• for all p1, p2∈P. مثال هایی از کلاس های تشریح شده که تفاوت های کلیدی این زیر مجموعه های شبکه پتری را نشان می دهد در شکل 2.8 آمده است. شکل 2.8. مثال هایی از زیر مجموعه های شبکه های پتری ]23[ قضایا و فرضیات ]23[ با یادآوری این نکته که شبکه اولیه به شبکه ای گفته می شود که وزن همه لبه های آن 1 باشد، قضیه های زیر را داریم: قضیه 1: اگر شبکه پتری عادی (N, M0)، Live و Safe باشد، نباید در آن موقعیت source یا sink و نیز گزار source یا sink وجود داشته باشد یعنی: x∈P∪T, •x≠Ø≠x•. □ با بسط دادن این قضیه می توان گفت اگر شبکه پتری متصل (N, M0)، live و safe باشد، آنگاه شبکه N یک شبکه متصل قوی است. قضیه 2: اگر درخت پوشای شبکه پتری (N, M0) را به عنوان T در نظر بگیریم، شبکه (N,M0)، Safe خواهد بود اگر و تنها اگر فقط مقادیر 0 و 1 در برچسب لبه های T وجود داشته باشد. □ قضیه 3: اگر درخت پوشای شبکه پتری (N, M0) را به عنوان T در نظر بگیریم، گزار t یک بن بست است اگر و تنها اگر t به عنوان برچسب یک لبه در T ظاهر نشود. □ قضیه 4: یک state machine، (N, M0)، live است اگر و تنها اگر این شبکه متصل قوی بوده و M0 حداقل یک توکن داشته باشد. □ قضیه 5: یک state machine، (N,M0)، safe است اگر و تنها اگر M0 حداکثر یک توکن داشته باشد. همچنین شرط لازم و کافی برای اینکه یک live state machine، (N, M0)، safe نیز باشد این است که M0 دقیقا یک توکن داشته باشد. □ در شبکه های marked graph، هر موقعیت دقیقا یک لبه ورودی و یک لبه خروجی با وزن واحد دارد. بنابراین گراف نشانه دار (N,M0) را می توان با گراف نشانه دار جهت دار (G, M0) نشان داد که در آن لبه ها معادل موقعیت ها و گره ها معادل گزارها هستند. شکل 2.9 مثالی از مدل پتری یک پروتکل ارتباطی در شبکه های کامپیوتری (الف) و گراف نشانه دار متناظر با آن (ب) را نشان می دهد. شکل 2.9. یک شبکه پتری و گراف نشانه دار مربوط به آن ]23[ اجرای یک گره (گزار) در یک marked graph شامل حذف شدن یک توکن از از لبه های ورودی (موقعیت های ورودی) و اضافه شدن یک توکن به لبه های خروجی (موقعیت های خروجی) می باشد. اگر یک گره بر روی یک مدار جهت دار یا حلقه قرار داشته باشد، آنگاه دقیقا یکی از لبه های ورودی و یکی از لبه های خروجی آن متعلق به حلقه مذکور خواهد بود. متقابلا، اگر گره ای بر روی یک حلقه قرار نداشته باشد، هیچ یک از لبه های متصل به آن متعلق به مدار جهت دار مذکور نخواهد بود. با توجه به مقدمه گفته شده، قضایای زیر را در مورد خصوصیات نامتغیر توکن ها در marked graph داریم: قضیه 6: در یک marked graph، تعداد توکن ها در یک مدار جهت دار تحت اجرای هر گزاری، نا متغیر است؛ یعنی برای هر مدار جهت دار C و هر وضعیت M در R(M0) داریم: M(C) = M0(C) که در اینجا M(C) نشان دهنده مجموع تعداد توکن ها در C است. □ بر اساس قضیه 6، اگر در وضعیت اولیه شبکه، توکنی در یک مدار جهت دار وجود نداشته باشد، این حلقه بدون توکن باقی خواهد ماند. بنابراین هیچ یک از گره ها (گزار) در آن امکان اجرا شدن نخواهند داشت. از سوی دیگر اگر یک گره هیچ گاه طی هیچ وضعیتی امکان اجرا شدن نداشته باشد (L0-live transition)، می توان با بررسی معکوس دنباله گزارها، مدار مستقیم بدون توکن را پیدا کرد. بر این اساس قضیه 7 را داریم: قضیه 7: گراف نشانه دار (G, M0)، live است اگر و تنها اگر در وضعیت M0، حداقل یک توکن در هریک از مدارهای جهت دار G وجود داشته باشد. □ قضیه 8: گراف نشانه دار live (G, M0)، safe خواهد بود اگر و تنها اگر هر لبه ای (موقعیت) در این گراف متعلق به مدار جهت دار C باشد به طوری که M0(C) = 1 . □ لم 1: با استفاده از گراف پوشای مدل پتری (N,M0) تعدادی از خصوصیات آن را می توان بررسی نمود. از آن جمله می توان به موارد زیر اشاره کرد: شبکه (N,M0) ، bounded و در نتیجه R(M0) متناهی است اگر و تنها اگر مقدار ω (تعداد بی نهایت توکن در یک موقعیت) در هیچ یک از برچسب های گره های گراف وجود نداشته باشد. شبکه (N,M0)، safe است اگر و تنها اگر فقط مقادیر 0 و 1 در برچسب گره های گراف دیده شود. گزار t در شبکه (N,M0) ، dead خواهد بود اگر و تنها اگر این گزار به صورت برچسب یک لبه در گراف پوشا ظاهر نشود. اگر وضعیت M از طریق M0 قابل دسترسی (reachable) باشد. آنگاه در گراف گره ای با برچسب M' وجود دارد به طوری که M≤M' □ برای مطالعه بیشتر قضایا و فرضیات به ]25[ الی ]28[ مراجعه کنید. جمع بندی در فصل دو، با تکیه بر مطالعات انجام شده در زمینه ابزار توصیف فرمال سیستم ها، چهار ابزار مختلف را انتخاب و بررسی نمودیم. هر یک از این چهار ابزار، خواه مبنی بر ابزار ریاضی مانند گراف باشند و یا مبتنی بر روابط جبری، به طراح در به دست آوردن تصویری قابل درک از سیستم واقعی کمک می کنند. این تصویر می تواند با متد های قابل دفاع مورد بررسی و تحلیل قرار گرفته و ظرفیت ها و مشکلات سیستم را از جنبه های زیادی به طراح نشان دهد. با توجه به تنوع سیستم های دنیای واقعی و خصوصیات بی شمار آنها، به طبع، ابزار فرمال متنوعی نیز برای بررسی آنها ابداع شده است. به عنوان نمونه بسیاری از ابزار مدلسازی فرمال قادر به نشان دادن دقیق خصوصیات سیستم های غیر موازی هستند. در مقابل بسیاری می توانند خصوصیات سیستم های موازی را که بسیار پیچیده ترند نشان دهند. همچنین خصوصیات ساختاری و رفتاری سیستم ها و نحوه برخورد آنها با زمان مسائل پیچیده ای است که باید در مدل سازی سیستم با ابزار فرمال مد نظر داشت. با توجه به توضیحات ارائه شده در بخش های گذشته، می توان جدول مقایسه ای برای چهار ابزار توصیف فرمال مذکور به صورت جدول 2.1 ارائه داد. جدول 2.1. خلاصه مقایسه ابزار توصیف فرمال ردیف خصوصیت ابزار توصیف فرمال ASM LOTOS VDM-SL Petri nets 1 پارادایم مبتنی بر جبر مبتنی بر جبر مبتنی بر مدل مبتنی بر مدل 2 سطح فرمالیتی فرمال فرمال فرمال فرمال 3 ابزار گرافیکی برای نمایش ندارد ندارد ندارد دارد 4 قابلیت توصیف سیستمهای موازی ندارد دارد ندارد دارد 5 قابلیت بیان ضعیف ضعیف ضعیف قوی 6 قابلیت انتزاع پذیری متوسط متوسط متوسط قوی 7 پشتیبانی از شئی گرایی ندارد دارد ندارد دارد 8 قابلیت تبدیل به کد اجرایی دارد دارد دارد دارد 9 استفاده از متغیرها بله بله بله بله 10 قابلیت توصیف سیستم های غیر تعینی ندارد دارد ندارد دارد 11 قابلیت اثبات پذیری دارد دارد دارد دارد 12 امکان بررسی مدل ندارد ندارد دارد دارد با توجه به نتایج به دست آمده از مقایسه ابزار مذکور و ماهیت سیستم مورد بررسی، در این تحقیق از زبان شبکه های پتری برای مدل سازی فرمال سیستم استفاده خواهد شد. به همین دلیل در این فصل در مورد این ابزار تمرکز و بررسی بیشتری به کار رفته است. همچنین در پایان کلیه قضایا و فرضیاتی که در طول تحقیق از آنها بهره گرفته می شود آمده است. در فصل بعد به تشریح تکنولوژی مجازی سازی خواهیم پرداخت. این تکنولوژی برای ساخت لایه نرم افزاری دیتا سنتر به کار خواهد رفت. در نهایت در فصل چهار، مدل های فرمالی در چند لایه از دیتا سنتری که به کمک این تکنولوژی ساخته شده طراحی خواهیم کرد. فصل سوم: بررسی معماری دیتا سنترها در این بخش لازم است معماری زیر ساخت نرم افزاری دیتا سنترها را بررسی و تحلیل نمائیم. این تحلیل پیش نیاز ما در طراحی مدل فرمال این زیر ساخت خواهد بود. به این منظور، در ابتدا معماری نرم افزارهای مدیریت ماشین های مجازی تحت عنوان نرم افزارهای Hypervisor را بررسی و تشریح می نمائیم ]37[ و ]38[. در حال حاضر سه نرم افزار مطرح در این زمینه، بیشترین سهم بازار سیستم های مجازی سازی را در اختیار دارند. این سه محصول عبارتند از: Microsoft Hyper-V Xen VMware ESXi از دیدگاه های مختلفی می توان hypervisor ها را با یکدیگر مقایسه نمود. از آن جمله می توان به پیاده سازی سرویس مجازی سازی کامل در مقابل مجازی سازی ضمنی اشاره کرد. در حالت اول، سخت افزار به طور کامل شبیه سازی می گردد و انتزاع کاملی از آن برای ماشین های مجازی ایجاد می گردد. به این ترتیب سیستم های عامل میهمان نیازی به اصلاح برای کار بر روی این ماشین مجازی نخواهند داشت. همچنین آنها و نرم افزارهای در حال اجرا بر روی آنها هیچ اطلاعی از وجود ماشین مجازی نخواهند داشت. در نتیجه پیاده سازی به شکل کامل امکان مهاجرت نرم افزارها و سیستم های عامل میهمان بین ماشین های فیزیکی را میسر می سازد. همچنین با ایزوله کردن نرم افزارها و سیستم عامل ها، امنیت هر یک از آنها در حد بالایی تامین خواهد شد. در عین حال این شکل از مجازی سازی مشکلات کاهش کارایی را نیز به دنبال دارد. زیرا hypervisor مجبور است تصویر کاملی از هر ماشین مجازی و سیستم عامل میهمان نصب شده بر روی آن را نگه دارد. به عنوان مثال حتی BIOS شبیه سازی می گردد. بنابراین منابع بیشتری صرف مدیریت و اجرای hypervisor خواهد شد. در مقابل، پیازی سازی مجازی سازی به شکل ضمنی اجازه دسترسی سیستم های عامل میهمان را به بخش هایی از منابع بدون شبیه سازی آنها فراهم می کند. در این حالت لازم است روی سیستم های عامل میهمان اصلاحاتی صورت گیرد تا امکان برقراری ارتباط با hypervisor را داشته باشند. در نتیجه آنها از وجود ماشین مجازی مطلع خواهند بود. این روش در کنار برخی از مشکلات امنیتی، عموما از سیستم های عامل closed-source پشتیبانی نمی کند زیرا امکان انجام اصلاحات لازم برای کار در ماشین مجازی در مورد آنها وجود ندارد ]39[. نرم افزارهای Hyper-V و Xen به صورت مجازی سازی ضمنی و ESX به صورت مجازی سازی مطلق پیاده سازی شده اند. در ادامه به بررسی معماری هر یک از این سه محصول می پردازم و در نهایت برای مدل سازی روابط بر روی VMware ESX متمرکز خواهیم شد. Microsoft Hyper-V توضیحات زیر از سایت رسمی اسناد فنی شرکت میکروسافت (MSDN) برداشت شده است ]40[. Hyper-V یک تکنولوژی مجازی سازی مبتنی بر Hypervisor است که برای Windows server 2008 نسخه 64 بیتی ساخته شده است. اولین مفهوم مطرح در این تکنولوژی نوعی از جدا سازی به نام پارتیشن است. در واقع Hyper-V از این بخش های جدا شده برای نگهداری اطلاعات و اجرای سیستم عامل های مختلف استفاده می کند. وجود حداقل یک پارتیشن ضروری است که پارتیشن ریشه یا والد نامیده می شود. در این پارتیشن یک سیستم عامل Windows server 2008 نصب و اجرا می گردد که وظیفه مدیریت دیگر سیستم عامل های مهمان و برقراری ارتباط آنها با سخت افزارهای فیزیکی را بر عهده دارد. پارتیشن ریشه تنها پارتیشنی است که دسترسی مستقیم به سخت افزار فیزیکی را دارد و از طریق رابط برنامه نویسی hypercall سیستم عامل های میهمان را ایجاد می کند. سیستم عامل های میهمان با تصویری از پردازنده و وقفه ها و در فضای محدودی از حافظه کار می کنند. در واقع hypervisor وقفه ها را برای سیستم عامل ترجمه کرده و به پارتیشن متناظر ارسال می کند. همچنین سیستم عامل ها (میهمان) به کمک ماژول VDev با تصویری از سخت افزارهای جانبی کار می کنند که توسط hypervisor اجرا می شود. درخواست سیستم عامل از سخت افزار مجازی توسط VMBus که یک کانال ارتباطی منطقی بین پارتیشن ها است به hypervisor و یا پارتیشن ریشه منتقل می شود و از آنجا به سخت افزار واقعی انتقال می یابد. به عبارت دقیقتر، ماژول VSC بر روی سیستم عامل میهمان درخواست خود را از طریق VMBus برای ماژول VSP بر روی سیستم عامل میزبان در پارتیشن ریشه ارسال می نماید. همچنین می توان از امکان Enlightened I/O برای افزایش سرعت و کارایی دستیابی به سخت افزارهای جانبی مانند دیسک، رابط شبکه و غیره استفاده نمود. در واقع این تکنولوژی، پیاده سازی پروتکل های سطح بالا (مانند SCSI) است که برای استفاده در محیط مجازی آماده پیاده سازی پروتکل های سطح بالا (مانند SCSI) است که برای استفاده در محیط مجازی آماده شده اند. این پروتکل ها با استفاده مستقیم از VMBus، لایه های میانی شبیه سازی سخت افزارها و نیاز به راه اندازها را از بین می برند. اما استفاده از این امکان به راه اندازی سرویس های مجتمع سازی نیاز دارد که برای چند سیستم عامل مشخص موجود است. لیست سیستم های عاملی که توسط Hyper-V پشتیبانی می شوند در جدول 3.1 آورده شده است. جدول 3.1. سیستم های عامل قابل پشتیبانی توسط Hyper-V R2 ]42[ Guest OS Virtual processors Edition(s) Windows 71,2 or 4 Both x86-32 and x86-64, all editions except home editions Windows Server 2008 R21,2 or 4 Web, Standard, Enterprise, Datacenter Windows Server 20081,2 or 4 Both x86 and x64, Web, HPC, Standard, Enterprise, Datacenter, with or without Hyper-V Linux (only including SUSE Linux Enterprise Server 10 with SP3 or version 11 and Red Hat Linux versions 5.2-5.5) 1,2 or 4 Both x86 and x64 Windows Server 20031 or 2 Both x86 and x64, Standard, Enterprise, Datacenter, SP2 required Windows Server 2003 R21 or 2 Web, Standard, Enterprise, Datacenter, both x86 and x64 except for Web whose 64-bit version is not supported Windows Vista1 or 2 Both x86 and x64, all editions except home editionsOthers 1 N/A شمایی از معماری Hyper-V در شکل 3.1 آورده شده است. شکل 3.1. معماری سطح بالای Hyper-V ]40[ بررسی اجزاء معماری Hyper-V در ادامه به توضیح مختصری درباره بخش ها و اصطلاحات این معماری می پردازیم. APIC ماژولی که امکان اولویت بندی وقفه ها را فراهم می سازد. Child Partition پارتیشنی که حاوی یک سیستم عامل میهمان است. تمام دسترسی های لازم به منابع فیزیکی سیستم مانند حافظه و وسایل جانبی توسط VMBus و hypervisor برای این پارتیشن فراهم می گردد. Hypercall رابطی برای ارتباط با hypervisor است که از طریق آن سیستم های عامل میهمان می توانند به ابزار بهینه hypervisot دست یابند. Hypervisor یک لایه نرم افزاری که مابین سخت افزار و یک یا چند سیستم عامل قرار می گیرد و وظیفه اصلی آن فراهم آوردن فضای مجزایی به نام پارتیشن برای اجرای هر یک از سیستم های عامل است. Hypervisor دسترسی به سخت افزار را کنترل و مدیریت می کند. IC ماژولی است که امکان ارتباط سیستم های عامل میهمان را با یکدیگر و با hypervisor فراهم می آورد. I/O stack همان پشته ورودی و خروجی است. Root Partition پارتیشنی است که سیستم عامل آن وظایف مدیریتی در سطح ماشین را انجام می دهد که عبارتند از راه انداز سخت افزارهای جانبی، مدیریت انرژی مصرفی و اضافه و حذف کردن دستگاه های در حال کار. این پارتیشن تنها پارتیشنی است که دسترسی مستقیمی منابع فیزیکی سیستم دارد. VID عملیاتی مانند سرویس های مدیریت پارتیشن ها، سرویس مدیریت پردازنده های مجازی، و سرویس مدیریت حافظه برای پارتیشن ها را ارائه می دهد. VMBus یک مکانیزم ارتباطی مبتنی بر کانال برای ارتباط پارتیشن ها و دستگاه ها فراهم می آورد. VMMS مدیریت وضعیت همه ماشین های مجازی در پارتیشن های فرزند را بر عهده دارد. VMWP یک بخش user mode در پشته مجازی سازی است. با این تعریف که پروسه ایجاد کننده یک سرویس مدیریت ماشین ها مجازی در پارتیشن ریشه (windows server 2008) ایجاد می کند که به کمک آن می توان سیستم های عامل میهمان را مدیریت نمود، سرویس VMWP یک پروسه ایجاد کننده مجزا برای هر یک از پارتیشن های فرزند ایجاد می کند. VSC یک ماژول ترکیبی که که در پارتیشن فرزند قرار می گیرد و نحوه استفاده از منابع سخت افزاری را که توسط سرویس دهنده مجازی (VSP) ارائه شده بهینه می نماید. VSC با VSP متناظر خود در پارتیشن ریشه از طریق VMBus ارتباط برقرار می کند تا به درخواست های I/O پارتیشن فرزند سرویس دهد. VSP سرویسی که در پارتیشن ریشه قرار می گیرد و از درخواست های پارتیشن های فرزند که از طریق VMBus مطرح می شود پاسخ می دهد. WinHv این ماژول پلی بین راه اندازهای سیستمهای عامل موجود در پارتیشن ها و hypervisor است که به راه اندازها امکان می هد تا از طریق رابط فراخوانی استاندارد ویندوز، hypervisor را صدا بزنند. WMI ابزار مدیریت ویندوز مجموعه ای از API ها هستند که سرویس مدیریت ماشین های مجازی برای مدیریت و کنترل ماشین ها ارائه می دهد. نقاط ضعف در مجموع می توان گفت که Hyper-V زیر ساخت نسبتا سبکی برای پیاده سازی ساختار مجازی سازی است. در عین حال به دلیل نیاز به وجود بخشی از معمای در سیستم های عامل میهمان، اجرای آنها کاملا مستقل از hypervisor نخواهد بود. در عمل نیز می بینیم که Hyper-V از تعداد محدودی از سیستم های عامل به عنوان میهمان پشتیبانی می کند تعدادی از آنها در جدول 3.1 آمده است. همچنین نیاز به وجود یک سیستم عامل میزبان هنوز هم وجود دارد. به این معنی که یک Windows server 2008 باید در پارتیشن ریشه نصب گردد تا بتواند درخواست های سیستم های عامل میهمان از سخت افزارهای مجازی را به سخت افزارهای فیزیکی منتقل نماید ]43[. برای مطالعه بیشتر در مورد Microsoft Hyper-V به ]44[ الی ]48[ مراجعه کنید. Xen در این بخش به تشریح کلیات معماری نرم افزار مجازی سازی Xen خواهیم پرداخت ]49[ و ]50[. این hypervisor معروفترین نرم افزار مجازی سازی با متن باز است که شرکت ها و سازمان های متعددی با بومی سازی از آن برای پیاده سازی زیر ساخت مجازی خود استفاده کرده اند. Xen به صورت یک مجازی ساز ضمنی پیاده سازی شده است بنابراین برای سیستم های عامل میهمان برای کار با آن نیاز به یک سری تغییراتی دارند. لیست سیستم های عاملی که توسط Xen 3.0 پشتیبانی می شوند در جدول 3.2 آورده شده است. جدول 3.2. سیستم های عامل قابل پشتیبانی توسط Xen نسخه 3 Operating Sys-- Runs as Dom0 (host os) Runs as DomU (guest os) Linux 2.6 Yes Yes NetBSD 3.1 No Yes NetBSD 4.0_BETA2 and -CURRENT Yes Yes FreeBSD 5.3 No currently broken? Actively being worked on FreeBSD 7-CURRENT no can be patched; works. Plan 9 No currently broken? ReactOS No planned, development stalled Solaris 10 Unknown Yes Un-Modified OS No Initial support for unmodified guests when using Intel VTX hardware, e.g. Windows این hypervisor از بخش های مختلفی تشکیل شده که در ادامه به تشریح آنها می پردازیم. همچنین شمایی کلی از آن در شکل 3.2 آمده است. شکل 3.2. شمایی از معماری Xen ]51[ بررسی اجزاء معماری Xen در این بخش اجزاء تشکیل دهنده معماری Xen که به طور شماتیک در شکل 3.2 آمده است را بیشتر بررسی می کنیم. Xen Hypervisor این بخش اولین لایه مجرد نرم افزار مجازی سازی است که مستقیما بر روی سخت افزار و زیر همه سیستم های عامل قرار گرفته است. Xen Hypervisor مسئول زمان بندی پردازنده و مدیریت حافظه برای ماشین های مجازی است که روی آن در حال اجرا هستند. همچنین این بخش هیچ گونه درکی از پروتکل های شبکه، دستگاه های ذخیره سازی خارجی، ویدئو و دیگر ورودی/ خروجی های استاندارد ماشین ندارد. Domain 0 در مقابل پارتیشن های موجود در Hyper-V که هریک مسئول نگهداری یک سیستم عامل بودند، در اینجا چندین دامنه وجود دارد. دامنه صفر که در واقع یک هسته تغییر یافته لینوکس است، تنها ماشین مجازی در حال اجرا بر روی Xen است که دسترسی مخصوصی برای کار با ورودی/ خروجی های استاندارد و نیز ارتباط با دیگر ماشین های مجازی دارد. بر روی هر مجازی ساز Xen قبل از اجرای هر سیستم عامل دیگری لازم است دامنه صفر اجرا گردد. در دامنه صفر دو راه انداز برای پشتیبانی درخواست های سیستم های عامل میهمان وجود دارد. یکی راه انداز شبکه، برای ارتباط مستقیم با سخت افزار شبکه و دیگری راه انداز دیسک، برای برای کار با دیسک محلی و ذخیره و بازیابی اطلاعات بر حسب نیاز سیستم های عامل ]51[. Domain U به هر ماشین مجازی در Xen یک دامنه U گفته می شود. همچنین تمام ماشین های مجازی که به صورت ضمنی مجازی سازی شده اند، به عنوان Domain U PV Guests و ماشین هایی که به صورت کامل مجازی سازی شده اند به عنوان Domain U HVM Guests شناخته می شوند. لازم به ذکر است که راه اندازی ماشین های HVM بر روی Xen در صورتی امکان پذیر است که پردازنده از تکنولوژی مجازی سازی سخت افزاری پشتیبانی نماید. این امکان در پردازنده هایی مانند اینتل سری VT-x و پردازنده های AMD سری AMD-V وجود دارد ]52[. هر یک از ماشین های PV شامل دو راه انداز برای شبکه و دیسک هستند در حالی که ماشین های HVM این راه انداز های را ندارند و در عوض برای هر یک از آنها یک دیمون در دامنه صفر به نام Qemu-dm مسئول برقراری ارتباط سیستم عامل میهمان (دامنه U) با کارت شبکه و دیسک فیزیکی است. در حالت دوم، لازم است نرم افزاری به نام Xen virtual firmware بر روی سیستم عامل میهمان اجرا شود تا بتواند BIOS را برای راه اندازی سیستم عامل شبیه سازی نماید (شکل 3.3). شکل 3.3. نحوه سرویس دهی به ماشین میزبان توسط Qemu-DM ]51[ Xenstored این دیمون مسئول نگهداری یک رجیستری از اطلاعات حافظه و وضعیت کانال های ارتباطی بین دامنه صفر و دامنه های U می باشد. ماشین مجازی مستقر در دامنه صفر با کنترل این رجیستری، ارتباط دیگر ماشین های مجازی را با منابع سخت افزاری مدیریت می کند. ارتباطات مابین دامنه صفر و دامنه های U همانطور که قبلا گفته شد، Xen Hypervisor قادر به ارائه سرویس شبکه و دیسک به سیستم های عامل میهمان نمی باشد بنابراین این سیستم های عامل باید از طریق hypervisor با سیستم عامل موجود در دامنه صفر ارتباط برقرار کنند تا سرویس مورد نظر خود را از وی بگیرد. برای مطالعه بیشتر در مورد Xen به ]53[ الی ]58[ مراجعه کنید. VMware ESXi این نرم افزار مجازی سازی که یکی از معروفترین hypervisor های موجود بوده و بیشترین سهم بازار مجازی سازی را نیز در اختیار دارد، امکان پیاده سازی مجازی سازی کامل را به کاربر داده و بنابراین سیستم های عامل میهمان کاملا مستقل از hypervisor و بی اطلاع از آن کار می کنند. همچنین این hypervisor بر خلاف دو نمونه قبلی نیازی به اجرای سیستم عامل میزبان ندارد و مستقیما بر روی سخت افزار نصب می گردد. در ادامه به تشریح کلیات معماری آن خواهیم پرداخت ]3[ و ]59[. این نرم افزار نیز مانند نمونه های قبلی از یک ساختار لایه ای پیروی می کند. در پائین ترین بخش، یک هسته تغییر یافته لینوکس به نام VMkernel قرار دارد که به طور مستقیم بر روی سخت افزار قرار گرفته است. وظیفه این هسته مدیریت همه پروسه ها از جمله برنامه های مدیریتی، agentها و نیز ماشین های مجازی است. همچنین این بخش مدیریت سخت افزارها و منابع ماشین فیزیکی را بر عهده دارد. در واقع این هسته تمام وظایف یک سیستم عامل از جمله ایجاد پروسه ها، کنترل و سیگنال، مدیریت فایل سیستم و threadها را برای ماشین انجام می دهد. همچنین به طور اخص، VMkernel برای پشتیبانی از اجرای چندین ماشین مجازی طراحی شده است. از اصلی ترین پروسه هایی که بر روی VMkernel اجرا می شوند میتوان به موارد زیر اشاره کرد: رابط مستقیم کاربر (DCUI) که یک رابط سطح پایین برای مدیریت و پیکر بندی hypervisor است و یک ارتباط کنسولی برای پیکر بندی اولیه در اختیار می گزارد. VMM پروسه ای است که محیطی اجرایی برای ماشین مجازی ایجاد می کند. هر ماشین مجازی، VMM و پروسه کمکی VMX مخصوص به خود را دارد. Agent هایی که وظیفه ارائه سرویس های سطح بالا مانند HA را بر عهده دارند. CIM رابطی است که به کمک API های استاندارد، امکان مدیریت و نگهداری سخت افزار را به صورت راه دور فراهم می کند. شکل 3.4 نمایی کلی از معماری گفته شده را نشان می دهد. شکل 3.4. شمایی از معماری VMware ESXi ]3[ بررسی اجزاء معماری VMware ESX در این بخش به بررسی دقیقتر اجزاء سازنده VMware ESX خواهیم پرداخت. VMkernel این هسته در واقع یک سیستم عامل از خانواده POSIX است که توسط شرکت VMware طراحی شده و همه وظایف یک سیستم عامل مانند ایجاد و مدیریت پروسه ها، سیگنال ها و فایل سیستم و مدیریت I/O را انجام می دهد. همچنین این هسته به طور اختصاصی برای مدیریت چندین ماشین مجازی طراحی شده است و وظایف زیر را برای آنها انجام می دهد: زمانبندی منابع مدیریت پشته های I/O مدیریت راه انداز سخت افزارها File Sys-- VMkernel از فایل سیستم ساده ای برای نگهداری فایل های پیکربندی ESX، فایل های Log و بسته های اجرایی استفاده می کند. به عنوان مثال، همانند لینوکس، فایل های پیکر بندی در مسیر /etc/vmware و فایل های log در مسیر /var/log/vmware ذخیره می شود. این فایل سیستم مستقل از فایل سیستم VMFS است که برای نگهداری ماشین های مجازی به کار می رود. منابع ذخیره سازی VMFS ممکن است بر روی دیسک محلی سرور یا یک دستگاه ذخیره سازی مشترک قرار داشته باشد. اگر منابع ذخیره سازی VMFS در خارج از سرور باشد، نیازی به وجود دیسک محلی نخواهد بود زیرا خود ESX نیز بدون نیاز به دیسک و به صورت embedded از روی یک حافظه flash قابل بارگزاری است. CIM این مدل در واقع یک استاندارد باز است که چگونگی ارائه و مدیریت منابع پردازشی را در یک ESX تعریف می کند. به عبارت دیگر CIM چارچوبی را برای مانیتورینگ استاندارد و بدون نیاز به مهفوم agent بر روی سخت افزار ارائه می دهد. و شامل مدیر شئی CIM و ارائه کننده CIM است. ارائه کننده های CIM مکانیزم های رابط برای مدیریت و دسترسی hypervisor به راه انداز دستگاه ها و دیگر سخت افزارهای سیستمی هستند. تولید کنندگان سخت افزار می توانند با تولید این ارائه کننده ها، امکان استفاده ESX از راه انداز سخت افزار خود را فراهم سازند و به این ترتیب ESX توانایی پشتیبانی و کار با هر نوع سخت افزار جدیدی را نیز دارد. همچنین ESX از این مکانیزم ها برای مانیتوینگ سخت افزار سرور، زیر ساخت ذخیره سازی ESX و منابع مخصوص مجازی سازی استفاده می کند. همچنین باید توجه داشت که این ماژول ها به دلیل توکار بودن در ESX، بسیار سبک و کاربردی هستند. از سوی دیگر، مدیر شئی CIM، رابطی است که توسعه دهندگان می توانند ماژول های جدید ارائه کننده CIM را نوشته و به ESX اضافه کنند. البته باید توجه داشت که این بسته ها نمی توانند در حال اجرا به ESX اضافه شوند و باید با آن packaged شوند. رابط CIM اطلاعات را از همه ارائه کننده های CIM جمع آوری کرده و از طریق APIهای استاندارد مانند WS-WAM به محیط مدیریتی منتقل می کند. شکل 3.5 ساختار مدیریت CIM را نشان می دهد. شکل 3.5. ساختار شماتیک مدیریت CIM ]3[ طراحی یک معماری برای دیتا سنتر پس از بررسی نرم افزارهای hypervisor مطرح در بازار و مقایسه آنها، در این بخش با انتخاب یکی از آنها به طراحی یک معماری برای ساخت دیتا سنتر می پردازیم. این معماری پایه طراحی مدل فرمال در فصل بعد خواهد بود. لازم به یادآوری است که hypervisor های معرفی شده در بخش قبل، با نصب بر روی یک ماشین فیزیکی، به مدیر سیستم اجازه اجرای چندین سیستم عامل را به طور همزمان می داد که هر یک از آنها در یک فضای مجزای حافظه به عنوان یک ماشین مجازی اجرا می شدند. دراین مرحله با فرض اینکه به جای یک ماشین فیزیکی، چندین ماشین فیزیکی مشابه وجود دارد، لازم است طرحی برای مجازی سازی یکپارچه این ماشین ها ارائه گردد. به طوری که بر روی این ماشین های مجازی اهدافی از جمله HA، انتقال ماشین ها و سرویس های در حال کار، مدیریت یکپارچه ماشین های مجازی، مدیریت یکپارچه منابع ذخیره سازی مشترک، مدیریت ساختار شبکه و مدیریت یکپارچه منابع پردازشی حاصل گردد. در مقایسه hypervisor های معرفی شده با یکدیگر، با توجه به مشخصه های هریک، در این تحقیق از معماری VMware ESX استفاده خواهد شد. برخی از دلایل این انتخاب عبارت است از: Vmware ESX نیاز به نصب سیستم عامل میزبان و نیز پارتیشن ریشه یا دامنه صفر برای نگهداری یک رابط سیستم عاملی ندارد. بنابر این به نظر می رسد کاراتر و کم هزینه تر است. در معماری Vmware ESX ماشین های مجازی برای استفاده از منابع سخت افزاری به طور مستقیم با VMkernel ارتباط برقرار می کنند و رابط سیستم عاملی در این بین وجود ندارد. بنابراین سیستم های عامل میهمان کاملا مستقل و بدون اطلاع از محیط مجازی کار خواهند کرد. این امر خطاپذیری ماشین های مجازی را کم کرده و نیز به مدیر اجازه می دهد هر نوع سیستم عاملی را بر روی این پلتفورم نصب و راه اندازی نماید. در این میان فقط محدودیت های سخت افزاری مانند معماری ماشین فیزیکی مطرح می باشد. با توجه به منحصر بودن حوزه تخصصی شرکت Vmware به تکنولوژی های مجازی سازی و تجاری بودن محصولات آن، می توان راه کارهای ساخت یافته و پخته ای را برای طراحی معماری های گسترده تر مجازی مانند ترکیب چندین دیتا سنتر، ساخت دیتا سنترهای مجازی و در نهایت طراحی معماری های پردازش ابری که مبتنی بر این محصولات باشند یافت. بنابر این راه برای توسعه معماری های مبتنی بر Vmware همیشه باز خواهد بود. ■ با توجه به توضیحات ارائه شده، در ادامه بحث به معرفی یک معماری عمومی برای دیتا سنترها بر اساس پلتفورم VMware می پردازیم ]60[. همچنین لازم به یاد آوری است که فرض این تحقیق بر وجود تعدادی ماشین های فیزیکی همگون، مانند سرورهای HP Blade در یک محل فیزیکی است که قرار است بر روی آن به کمک ساختار مناسب، تعداد دلخواهی از ماشین های مجازی قرار گیرد و سرویس های مورد نیاز در یک دیتا سنتر با اندازه کوچک ارائه گردد. معماری دیتا سنترهای مجازی و پردازش ابری خارج از موضوع این بحث می باشد. مختصری درباره vSphere vSphere به عنوان سیستم عامل پردازش ابری شناخته می شود و در واقع مجموعه ای از سرویس ها است که به کمک ESX معماری یک دیتا سنتر را پیاده سازی می نماید. لازم به توضیح است که مفاهیم میزبان، کلاستر و مخزن منابع، شیوه ای پویا و انعطاف پذیر برای سامان دهی منابع پردازشی و ارتباط آنها با زیر ساخت منابع فیزیکی ارائه می دهد. یک میزبان به مجموع منابع پردازشی و حافظه یک سرور فیزیکی با معماری x86 اشاره می کند. برای مثال اگر یک سرور فیزیکی دارای چهار پردازنده دو هسته ای 4GHz و 8GB حافظه باشد، این سیستم دارای 32GHz قدرت پردازش و 32GB حافظه می باشد که برای اجرای ماشین های مجازی آماده است. یک کلاستر مانند یک موجودیت واحد کار می کند و مدیریت می شود. این موجودیت منابع پردازشی و حافظه یک گروه از سرور های فیزیکی x86 را که از منابع مشترک شبکه و دیسک استفاده می کنند یکپارچه می نماید. به عنوان مثال، اگر یک گروه هشت تایی از سرورها با چهار پردازنده دو هسته ای و 32B حافظه بر روی هر یک در اختیار باشد، کلاستر منبع یکپارچه ای شامل 256GHz قدرت پردازنده و 256GB حافظه برای اجرای ماشین های مجازی در اختیار کاربران قرار می دهد. مخزن منابع بخشی از منابع پردازشی و حافظه یک میزبان و یا یک کلاستر است. این مخازن می توانند سلسله مراتبی و تودرتو باشند. مدیر سیستم می تواند یک مخزن را به مخازن کوچکتری تقسیم نماید. در شکل 3.6 نمونه ای از مفاهیم گفته شده آمده است. سه سرور x86 که هر یک 4GHz توان پردازشی و 16GB حافظه دارند در نظر گرفته شده است. پس در مجموع یک کلاستر با توان پردازشی 12GHz و حافظه 48GB در اختیار داریم. مخزن پردازشی دپارتمان مالی، به میزان 8GHz از توان پردازشی و 32GB از حافظه این کلاستر را رزرو کرده است. همچنین 4GHz پردازنده و 16GB از حافظه برای ماشین های مجازی دیگر کنار گذاشته شده است. در کلاستر دپارتمان مالی، یک مخزن منابع کوچکتر شامل 4GHz از منابع پردازشی و 16GB حافظه برای ماشین های مجازی دپارتمان حسابداری ایجاد شده است. همچنین منابعی شامل 4GHz منبع پردازشی و 16GB حافظه به ماشین مجازی با عنوان payroll اختصاص یافته است. شکل 3.6. مثالی از مفاهیم میزبان، کلاستر و مخزن منابع ]60[ مدیر سیستم می تواند به صورت پویا سیاست تخصیص منابع را عوض نماید. به عنوان مثال با زیاد شدن بار پردازشی یکی از ماشین های مجازی، می توان با قرض گرفتن منابع دیگر مخازن، منابع موجود در مخزن پردازشی مربوط به آن را افزایش داد و برای این کار نیازی به خاموش شدن هیچ یک از ماشین های مجازی وجود ندارد. در ادامه به شرح سرویس هایی که معماری vSphere را می سازند می پردازیم]60[ و ]61[. سرویس های زیر ساختی vSphere VMware vCompute VMware vStorage VMware vNetwork سرویس های کاربردی vSphere سرویس هایی که خصوصیاتی از سیستم مانند دسترس پذیری، امنیت، توسعه پذیری و غیره را در سیستم فراهم می کنند. نمونه هایی از آن HA و تحمل خطا در سیستم می باشد. سرور VMware vCenter سروری که یک نقطه دسترسی واحد برای مدیریت و کنترل کلیه منابع و امکانات دیتا سنتر فراهم می کند. سرویس هایی مانند کنترل دسترسی، مشاهده وضعیت کارکرد سیستم و پیکر بندی سیستم نمونه هایی از سرویس های این سرور هستند. Client ها کاربران می توانند به کمک رابط های کاربری به منابع vSphere دسترسی داشته باشند. این ابزار شامل vSphere Client و رابط های تحت وب هستند. ESX همانطور که قبلا توضیح داده شد، یک نرم افزار مجازی ساز از کلاس hypervisor است که منابع سیستم را برای استفاده ماشین های مجازی مدیریت می کند. vCenter Server سروری برای مدیریت جامع منابع دیتا سنتر و پیکر بندی و مانیتورینگ سیستم می باشد. VMFS یک فایل سیستم کارآمد برای مدیریت منابع ذخیره سازی کلاستر می باشد. SMP ماژولی که به یک ماشین مجازی امکان استفاده از چندین پردازنده فیزیکی را به طور همزمان می دهد. VCMS یک نقطه دسترسی مرکزی برای پیکربندی، تخصیص و مدیریت منابع زیر ساخت مجازی است. VI Client رابطی که امکان دسترسی از راه دور به VCMS و یا هر یک از ESX های نصب شده بر روی ماشین ها را برای کاربران و مدیر سیستم فراهم می نماید. VMware VMotion ماژولی که امکان انتقال بلادرنگ ماشین های مجازی از یک ماشین فیزیکی به ماشین فیزیکی دیگر را فراهم می کند. این انتقال بدون قطع سرویس و از کار افتادگی خواهد بود. برای انتقال یک ماشین مجازی، VMotion یک کپی از ماشین مجازی مذکور را بر روی یک سرور دیگر روشن می کند و وضعیت جاری پروسه ها را به آن انتقال می دهد. این عمل باعث انتقال بلادرنگ ماشین و عدم قطعی در سرویس های آن خواهد شد. Storage VMotion این سرویس امکان انتقال فایل های یک ماشین مجازی را از روی یک سرور فیزیکی به سرور فیزیکی دیگر فراهم می کند. این سرویس می تواند دیسک های مجازی و فایل های پیکربندی یک ماشین در حال کار را به یک datastore جدید منتقل کند. همچنین این عمل را بدون قطعی و تاخیر در ماشین مجازی انجام می دهد. به کمک دو سرویس بالا مدیر سیستم می تواند ماشین مجازی و دیسک های آن را در یک محل قرار دهد و یا در سرور های مختلف توزیع نماید. VMware HA ماژولی که امکان HA را با هزینه کم و به شکل ساده برای نرم افزارهای در حال اجرا بر روی ماشین های مجازی فراهم می کند. در صورت بروز یک اختلال، ماشین مجازی متاثر، به صورت خودکار بر روی سرور دیگری که دارای منابع اضافی است راه اندازی می گردد. این سرویس تمام میزبانان روی هر کلاستر HA را مانیتور کرده و خرابی ها را شناسایی می کند. یک agent بر روی هر میزبان فیزیکی مسئول تولید یک سیگنال ضربانی است. این ضربان با ضربان دیگر میزبانان حاضر بر روی مخزن منابع همگام است. در صورت قطع شدن این ضربان بر روی هر یک از میزبانان، سرویس HA پروسه راه اندازی ماشین های مجازی موجود بر روی میزبان فیزیکی قطع شده را بر روی میزبانان دیگر اجرا می کند. البته این سرویس همواره اطمینان حاصل می کند که منابع پردازشی کافی بر روی مخزن منابع برای راه اندازی مجدد ماشین های مجازی در صورت بروز خطا وجود دارد. شکل 3.7 طرز کار سرویس HA را نشان می دهد. شکل 3.7. طرز کار سرویس HA ]61[ با توجه به وظیفه ماژول HA، این سرویس ابزاری برای مانیتورینگ وضعیت ماشین های مجازی در کلاستر نیز ارائه می نماید.این امکان می تواند در صورت بروز خرابی بر روی یک میزبان، مراتب را گزارش نموده و نسبت به پروسه راه اندازی ماشین های مجازی متاثر شده اقدام کند. DRS این ماژول به صورت هوشمند و پویا منابع سخت افزاری سیستم را به ماشین های مجازی تخصیص داده و بالانس می کند. در واقع این سرویس یک کلاستر از سرورهای فیزیکی را به صورت منابع یک کامپیوتر واحد مدیریت می کند. وقتی مدیر یک ماشین مجازی را به یک کلاستر نسبت می دهد، DRS یک سرور فیزیکی مناسب را برای اجرای آن پیدا می کند. همچنین DRS ماشین های مجازی را به شکلی بر روی سرور های فیزیکی توزیع می کند که بالانس بودن بار پردازشی و اعمال سیاست گزاری تخصیص منابع از جمله رزور منابع، اولویت بندی و محدودیت ها اطمینان حاصل نماید. وقتی یک ماشین مجازی روشن می شود، DRS یک بررسی اولیه برای جاگزاری آن بر روی یک سرور فیزیکی انجام می دهد. اگر شرایط یک کلاستر مانند بار پردازشی و منابع در دسترس تغییر کند، DRS به کمک سرویس های VMotion ماشین های مجازی را به سرور فیزیکی جدیدی منتقل می کند. همچنین اگر یک سرور فیزیکی به مجموعه اضافه شود، DRS به ماشین های مجازی امکان استفاده از منابع پردازشی و حافظه سرور جدید را می دهد. DRS شامل سرویس DPM است که امکان صرفه جویی محسوسی را در مصرف انرژی توسط دیتا سنتر فراهم می کند. در صورت فعال بودن DPM، سیستم، ظرفیت منابع را در سطح کلاستر و میزبان، با میزان منابع مورد نیاز ماشین های مجازی مقایسه می کند. اگر این نیاز ماشین ها با تعداد کمتری از سرور های فیزیکی قابل سرویس دهی باشد، DPM ماشین های مجازی را به این تعداد سرور منتقل و بقیه سرورها را خاموش می کند. وقتی تقاضا برای منابع دوباره افزایش یافت DPM سرور های مذکور را دوباره روشن کرده و ماشین های مجازی را به محل اولیه بر می گرداند. با این مکانیزم تخصیص منابع به کلاسترها فقط به اندازه نیاز آنها، میزان مصرف انرژی توسط سرور های فیزیکی به شکل قابل ملاحظه ای کاهش می یابد. Consolidated Backup ابزاری راحت و متمرکز برای گرفتن backup از ماشین های مجازی است که بدون نیاز به agentها پیاده سازی شده است. این ماژول مدیریت backup را ساده تر کرده و بار پردازشی بر روی ESX را کم می کند. vSphere SDK رابطی استاندارد برای نوشتن ماژول های جانبی نرم افزاری و بر روی vSphere می باشد. Fault Tolerance اگر این امکان برای یک ماشین مجازی فعال باشد، یک کپی از ماشین اولیه تحت عنوان ماشین ثانویه ایجاد می گردد. همچنین تمام اعمالی که بر روی ماشین مجازی اصلی انجام می گیرد بر روی کپی آن نیز اعمال می شود. در صورت بروز خطا و غیر قابل استفاده شدن ماشین مجازی، کپی آن فعال خواهد شد و کار ماشین را ادامه می دهد. سرویس های توزیع شده در vSphare از بین سرویس های توصیف شده در بالا، تعدادی از آنها به صورت توزیع شده بر روی معماری انجام وظیفه می کنند. این سرویس ها امکان مدیریت و تخصیص منابع را به صورت کار آمد و خودکار فراهم می کنند و شامل سرویس های زیر هستند: VMware VMotion VMware Storage VMotion VMware DRS VMware HA Fault Tolerance معماری شبکه Hypervisor با شبیه سازی مکانیزم های فیزیکی دسترسی به شبکه در محیط مجازی، همه امکانات این ابزار و نیز امکانات دیگری که در محیط واقعی قابل دسترسی نیست را برای ماشین های مجازی فراهم می کند. شکل 3.8. شمایی از معماری شبکه در محیط مجازی ]60[ همانطور که در شکل 3.8 دیده می شود، hypervisor با استفاده از کارت شبکه های مجازی، سوئیچ های مجازی و port groupها امکان ایجاد vNIC به تعداد دلخواه، برقراری ارتباط vNIC با کارت شبکه فیزیکی، پشتیبانی از پروتکل های سوئیچینگ لایه 2 و قرار دادن تعداد دلخواهی از vNICها در یک شبکه مجزا را فراهم می کند. در این معماری، vSwitch شبیه یک سوئیچ فیزیکی لایه 2 عمل می کند و هر ماشین فیزیکی vSwitch مربوط به خود را دارد. این سوئیچ از یک طرف با port group متصل به ماشین های مجازی مرتبط بوده و از طرف دیگر یک uplink با کارت شبکه های فیزیکی ماشین دارد. همچنین این سوئیچ می تواند به بیش از یک کارت شبکه فیزیکی متصل شود امکاناتی از جمله NIC teaming را فراهم کند ]62[. همچنین port group مفهومی منحصر به محیط مجازی است که به کمک آن می توان مفهوم VLANing را بر روی vNICها پیاده سازی نمود. به این معنی که با قرار دادن چندین vNIC در یک port group، می توان آنها را به صورت یک شبکه مجزا برای محیط مجازی معرفی کرد و قوانین و سیاست های مشترکی را بر روی آنها اعمال نمود. معماری محل ذخیره سازی داده ها این معماری شامل لایه هایی برای ایجاد انتزاع کافی و پوشاندن و مدیریت پیچیدگی ابزار ذخیره سازی متنوع است که می تواند یک عنصر ذخیره سازی ساده و یکسان را در اختیار ماشین های مجازی قرار دهد. بنابراین همه نرم افزارها و سیستم های عامل در حال اجرا، یک دیسک ساده SCSI که به Bus logic مجازی متصل است را مشاهده و با آن کار می کنند ]61[. شکل 3.9. شمایی از معماری ذخیره سازی ]60[ دیسک های مجازی توسط ماژول Datastore به ماشین های مجازی ارائه می شوند. در واقع، datastore یک نرم افزار ذخیره سازی است که که سرویس ذخیره سازی را برای ماشین های مجازی فراهم می کند همانطور که در شکل 3.9 دیده می شود، خود ماشین مجازی نیز به عنوان یک فایل در پوشه مربوط به خود ذخیره می شود (vm1.vmx) که این فایل بعدا به صورت یک فایل بر روی دیسک فیزیکی نگهداری می گردد (vm1.vmdx). بنابراین سیستم عامل و دیسک متعلق به آن به راحتی به عنوان یک فایل قابل جابه جایی، کپی برداری، backup و غیره است. در اینجا نیز دیسک های مجازی مانند کارت های شبکه مجازی قابل افزودن به یک ماشین مجازی در حال کار هستند ]63[. بنابراین در این مدل، نرم افزارها بدون اطلاع از پیچیدگی تکنولوژی ذخیره سازی می توانند از آن استفاده کنند و در عین حال معماری می تواند از انواع تکنولوژی ها مانند Fiber Channel SAN، iSCSI SAN، Direct Attached Storage و NAS استفاده نمایند. از نظر فیزیکی، هر datastore، یک پارتیشن از فایل سیستم VMFS و یا یک پوشه است که بر روی دیسک ذخیره شده است. هر datastore می تواند شامل چندین منبع ذخیره سازی فیزیکی باشد. هر پارتیشن VMFS شامل یک یا چند LUN است که مستقیما بر روی دیسک های فیزیکی مانند iSCSI یا ... قرار گرفته اند. LUNهای اضافه شده، به طور اتوماتیک شناسایی و به منابع سیستم اضافه می شوند. برای اضافه کردن این LUNها به datestore های موجود، نیازی به خاموش کردن هیچ یک از بخش های سیستم نیست. همچنین اگر یکی از LUNها دچار خرابی شود فقط ماشین های مجازی که به آن وابسته هستند از مدار خارج می شوند و بقیه ماشین ها به صورت عادی به کار خود ادامه می دهند. VMFS یک فایل سیستم کلاستر برای مدیریت دیسک های مشترک و فراهم آوردن امکان دسترسی چندین سرور فیزیکی به این منابع است. همچنین VMFS با مکانیزم فقل توزیع شده دیسک برای هرماشین مجازی، تضمین می کند که هر ماشین در یک زمان تنها بر روی یک سرور فیزیکی قابل اجرا است. در صورت خراب شدن یک سرور فیزیکی این فقل آزاد شده و ماشین های مجازی روی آن می توانند بر روی سرور دیگری شروع به کار نمایند. VMFS همچنین مکانیزم هایی را در سطح کلان برای پیشگیری و برخورد با خرابی منابع ذخیره سازی و بازیابی اطلاعات ارائه می نماید که از آن جمله می توان به ژورنالینگ توزیع شده، مکانیزم IO path برای جلوگیری از خرابی و ذخیره تصاویر لحظه ای از سیستم اشاره کرد. سیستم به کمک این ابزار می تواند مدت از کار افتادگی سرور های فیزیکی و منابع ذخیره سازی خود را به حداقل برساند. از دیگر سرویس های VMFS می توان به نگاشت مستقیم دیسک یا RDM اشاره نمود. RDM مکانیزمی برای دسترسی مستقیم ماشین های مجازی به LUNهای مستقر بر روی دیسک فراهم می کند. این راهکار در مواقعی از جمله موارد زیر بسیار مفید است: دریافت تصاویر لحظه ای از SAN و دیگر نرم افزارهای چند لایه که بر روی ماشین های مجازی تصب شده اند. که در این حالت RDM به کمک خصوصیات ذاتی SAN کارایی ذخیره سازی را بالا می برد. استفاده از سرویس کلاستر سازی میکروسافت که بر روی چندین سرور فیزیکی قرار گرفته و امکان کلاستر سازی ماشین های مجازی با مجازی و نیز ماشین های فیزیکی با مجازی را بر عهده دارد. شکل 3.10. طرز کار RDM ]60[ مطابق شکل 3.10 یک RDM را می توان به عنوان یک اشاره گر در نظر گرفت که به یک LUN اشاره می کند. این نگاشت LUN را به صورت یک فایل در پارتیشن VMFS نمایش می دهد. وقتی LUN برای دسترسی خواندن یا نوشتن باز می شود، VMFS فایل RDM را برای تشخیص محل فیزیکی ذخیره سازی مورد نظر بررسی می کند. پس از فقل کردن LUN مورد نظر، دسترسی مناسب را برای انجام عملیات در اختیار نرم افزار قرار می دهد. معماری سرور مدیریت VirtualCenter این سرور ابزاری برای مدیریت متمرکز منابع فیزیکی که ممکن است بر روی چندین ESX پراکنده باشد ایجاد می کند و به صورت پنلی انعطاف پذیر و یکپارچه برای مدیریت منابع فیزیکی و مجازی در اختیار مدیر سیستم قرار می دهد ]64[. شکل 3.11. شمایی از ساختار سرور مدیریت VirtualCenter ]60[ در شکل 3.11 اجزای اصلی سرور نشان داده شده است. User Access Control این ماژول امکان تعریف کاربرانی با سطوح دسترسی مختلف را برای سیستم فراهم می کند. به عنوان مثال کاربری که توانایی مدیریت سرور های فیزیکی را داشته باشد و یا کاربری که توانایی مدیریت تنها تعداد مشخصی از ماشین های مجازی را داشته باشد. Core Service سرویس پایه برای مدیریت دیتا سنتر مجازی است که سرویس هایی مانند Logging and Statistics، VM provisioning و Host and VM Configuration را ارائه می هد. برای مطالعه بیشتر در مورد VMware به ]65[ الی ]69[ و ]72[ مراجعه کنید. جمع بندی در این فصل به تعریف نرم افزارهای Hypervisor و معرفی سه نمونه پیشرو در بازار پرداخته شد. این سه Hypervisor که در حال حاضر بخش بزرگی از بازار را در اختیار دارند عبارتند از Microsoft Hyper-V، Xen و VMware ESX. در مرحله بعد به تشریح معماری هر یک پرداختیم تا نقاط ضعف و قوت شان را با یکدیگر مقایسه کنیم. در پایان و با توجه به اینکه در این تحقیق از محصول شرکت VMware برای طراحی لایه نرم افزاری دیتا سنتر استفاده خواهد شد، بر روی این تکنولوژی تمرکز بیشتری داشتیم. به این ترتیب که علاوه بر معماری ESX، به تشریح سرویس های سطح بالا که معماری VMware vSphere و یا سیستم های پردازش ابری را بر مبنای تکنولوژی VMware می سازند پرداختیم. این سرویس ها عبارت اند از VMotion، HA، Fault Tolerance، DRS و دیگر سرویس هایی که در ترکیب با بقیه کار می کنند. در فصل بعد پس از طراحی یک نمونه دیتا سنتر کوچک، از بخش های مختلف آن مدل های فرمال تهیه می کنیم. برای تهیه مدل فرمال از زبان شبکه های پتری، تشریح شده در فصل 2، کمک خواهیم گرفت. فصل چهارم: ارائه مدل فرمال برای دیتا سنتر و تحلیل آن در این فصل ابتدا یک دیتا سنتر نمونه تشریح می گردد و سپس این دیتا سنتر در لایه های مختلف توسط شبکه های پتری مدل خواهد شد. برای بررسی دقیقتر، سعی شده است که نمونه معرفی شده برای دیتا سنتر تا حد امکان ساده و در عین حال شامل تمام بخش های لازم برای یک دیتا سنتر واقعی باشد. همچنین لازم به ذکر است که این تحلیل ساختار و مدل سازی تا سطح سرویس انجام شده است. به این معنی که از بررسی مکانیزم های داخلی ماشین های مجازی از جمله سیستم عامل میهمان و سرویس های آن و نیز ساختار منابع سخت افزاری از جمله پردازنده، حافظه و غیره چشم پوشی شده است. بنابراین به تشریح ساختار کلی لایه مجازی سازی، سرویس های سطح بالا از جمله HA، Fault Tolerance و vMotion و نیز شیوه کار معماری های شبکه و سیستم ذخیره سازی پرداخته شده است. به عبارت دیگر از دیدگاه سطح دانه پذیری سیستم، می توان گفت مدل ها با حداکثر انتزاع ممکن و در سطح اجزاء اصلی دیتا سنتر انجام شده است. تشریح دیتا سنتر نمونه در این فصل با تکیه بر ابزار و تکنولوژی های معرفی شده، تلاش می شود یک الگوی نمونه برای دیتا سنترهای نوین معرفی گردد. در این معماری، منابع پردازشی هر ماشین فیزیکی بخشی از مخزن منابع کل سیستم هستند. بنابراین مدیر سیستم می تواند این منابع را به هر شکل مورد نیاز تخصیص دهد. همچنین وی می تواند به سرعت بین ماشین ها سوئیچ کند، از آنها نسخه پشتیبان تهیه نماید، آنها را کپی کند و به صورت متمرکز آنها را مدیریت نماید. زیر ساخت VMWare همه منابع پردازشی از جمله سرورها، منابع ذخیره سازی و شبکه را مجازی سازی می کند. این زیر ساخت با گردآوری همه منابع و نمایش مجموعه ای ساده شده و یکپارچه از آنها، مدیر را در درک بهتر ساختار موجود دیتا سنتر و مدیریت و تغییر آن یاری می رساند. به کمک این ساختار می توان منابع توزیع شده در یک دیتا سنتر را به صورت مجموعه ای از ابزار مشترک مدیریت نمود. همچنین می توان از دیتا سنتر در مصارف گوناگونی استفاده کرد بدون اینکه نگران گوناگونی سخت افزار و نوع مصرف آن باشیم. شکل 4.1 نحوه پیکربندی و معماری یک طرح نمونه VMware را نشان می دهد. شکل 4.1. زیر ساخت دیتا سنتر مجازی ]63[ پیش از آنکه ساختار دیتا سنترها را دقیقتر بررسی نمائیم، لازم است برخی از اصطلاحات و مفاهیم را تشریح کنیم. این مفاهیم در بخش های مختلف لایه نرم افزاری در سیستم مذکور به کار می روند ]60[ و ]63[. میزبان یک میزبان نمود مجازی سازی شده منابع پردازشی و حافظه یک ماشین فیزیکی است که در حال اجرا کردن VMware ESX می باشد. در واقع بدنه اصلی فیزیکی دیتا سنتر از مجموعه ای از ماشین های میزبان تشکیل شده که درحال اجرا کردن زیر ساخت سیستم عاملی Hypervisor هستند. کلاستر وقتی چند ماشین فیزیکی با یکدیگر همگروه می شوند و به صورت یک واحد یکپارچه مدیریت می گردند، منابع پردازشی و حافظه آنها که با یکدیگر جمع شده است یک کلاستر تشکیل می دهند. چنین گروهی ازمنابع پردازشی به منظور راه اندازی سرویس های سطح بالا مانند HA، Fault Tolerance و غیره مورد استفاده قرار می گیرند. می توان ماشین های فیزیکی جدیدی را به یک کلاستر اضافه یا از آن حذف نمود. مخزن منابع مجموعه منابع پردازشی و حافظه ماشین هایی که در یک کلاستر قرار دارند، تشکیل مخزنی از منابع را می دهند که به همین نام شهرت یافته است. مدیر سیستم می تواند این منابع را به صورت سلسله مراتبی و یا گروه بندی شده به ماشین های مجازی تخصیص دهد و همچنین بخشی از آن را به صورت دستی و یا خودکار برای سرویس های سطح بالا که در یک دیتا سنتر ضروری است رزرو نماید. در یک دیتا سنتر نمونه مانند شکل 4.2، چندین ماشین فیزیکی با معماری x86 در یک شبکه محلی به یکدیگر متصل شده اند. این شبکه ترجیها از قویترین و سریعترین انواع شبکه های در دسترس است زیرا در انتهای طراحی، نقاط اتصال سرورهای فیزیکی، گلوگاه ارتباطات دیتا سنتر خواهد بود. همچنین تعدادی منبع ذخیره سازی نیز در این شبکه وجود دارند. بر حسب تکنولوژی موجود در بازار، این ابزار ذخیره سازی می تواند از دیسک های SCSI درون هر یک از سیستم های میزبان تا دیسک های SCSI مبتنی بر شبکه اترنت متنوع باشند. وجود تجهیزات تخصصی دیگر مانند سوئیچ های SAN برای برقراری ارتباط میان سرورهای فیزیکی و ابزار ذخیره سازی و نیز تجهیزات پشتیبان گیری نیز در دیتا سنتر عادی است. شکل 4.2. یک الگوی نمونه برای زیر ساخت دیتا فیزیکی سنتر ]60[ در این تحقیق برای طراحی و تحلیل مدل فرمال از یک دیتا سنتر، نمونه کوچکی از یک دیتا سنتر واقعی در نظر گرفته شده است که شامل دو سیستم میزبان و دو منبع ذخیره سازی می باشد. سیستم های میزبان به یک شبکه داخلی متصل هستند و به وسیله سوئیچ های SAN به دیسک های Fiber SCSI مرتبط شده اند. افزونگی در سیستم به منظور به حداقل رساندن قطعی و خرابی در شبکه زیر ساخت دیتا سنتر رعایت شده است. شمای کلی این ساختار را می توان در شکل 4.3 دید. شکل 4.3. ساختار شماتیک دیتا سنتر نمونه بعد از پیاده سازی سخت افزاری اجزا و نصب ESX بر روی سیستم های میزبان و نیز پس از پیکر بندی سیستم های میزبان و ذخیره سازی داده، سیستم می تواند شروع به کار نماید. در این مرحله انتظار می رود که همه چهار بخش اصلی سیستم یعنی دو سیستم میزبان و دو سیستم ذخیره سازی اطلاعات بدون مشکل بوت شده و آماده بارگذاری شوند. با این حال بروز اختلال در یکی یا بیشتر و آماده به کار نبودن بعضی از آنها در پایان مرحله بوت دور از انتظار نیست. در گام بعد، با توجه به بخش های آماده به کار، ماشین های مجازی و سرویس های سطح بالا می توانند اجرا و پیکر بندی شوند. با توجه به ساختار سرویس های سطح بالا و نحوه کارکرد آنها، واضح است که برای اجرای درست سرویس هایی مانند HA و FT حضور حداقل دو میزبان فیزیکی ضروری است ]61[. پس از بارگزاری ماشین های مجازی و سرویس های لازم، ESX شروع به دریافت درخواست های ماشین های مجازی و ارائه سرویس به آنها می کند. در کنار این روال دائمی، در صورت بروز مشکل در یکی از ماشین های میزبان یا منابع ذخیره سازی و یا درخواست مدیر برای انتقال یک ماشین مجازی و غیره، سرویس متناظر می تواند فعال شده و وظیفه خود را انجام دهد. به عبارت دیگر می توان گفت که از این مرحله به بعد سیستم در یک وضعیت تعادل اجرایی مابین نحوه کار ESX و سرویس ها قرار می گیرد. در چنین تعادلی، مدیر می تواند ماشین های مجازی جدیدی ایجاد کند، ماشین های مجازی را از یک میزبان به میزبان دیگر منتقل نماید و نحوه تخصیص منابع به ماشین های مجازی و کلاسترها را تغییر دهد. ارائه مدلی از رفتار کلی دیتا سنتر

ارسال نظر آزاد است، اما اگر قبلا در بیان ثبت نام کرده اید می توانید ابتدا وارد شوید.
شما میتوانید از این تگهای html استفاده کنید:
<b> یا <strong>، <em> یا <i>، <u>، <strike> یا <s>، <sup>، <sub>، <blockquote>، <code>، <pre>، <hr>، <br>، <p>، <a href="" title="">، <span style="">، <div align="">
تجدید کد امنیتی
Designed By Erfan Powered by Bayan