سیستم های توزیع شده ادامه فصل 1 – جلسه 2

1. سیستم های توزیع شدهادامه فصل 1 – جلسه 2 مرجان نادران طحان استادیار گروه مهندسی کامپیوتر دانشگاه شهید چمران اهواز m.naderan@scu.ac.ir نیمسال دوم 93-92

2. جدول زمانبندی درس

3. سرفصل مطالب • تعریف • اهداف • شفافیت • باز بودن • مقیاس پذیری • انواع سیستم های توزیعی

4. سرفصل مطالب • تعریف • اهداف • شفافیت • باز بودن • مقیاس پذیری • انواع سیستم های توزیعی

5. شفافیت • تعریف شفاف بودن: • سیستم توزیع شده ای که بتواند خود را به کاربران طوری نشان دهد که ظاهراً یک سیستم است. • انواع شفافیت:

6. انواع شفافیت • شفافیت در دسترسی: تفاوت های مربوط به نوع نمایش داده ها و روش دسترسی به منابع را پنهان می کند. مثال: • تفاوت معماری های ماشین های مختلف • تفاوت در سیستم عامل های ماشین های مختلف • تفاوت قواعد نامگذاری فایل ها در سیستم عامل های مختلف • شفافیت مکانی: کاربران متوجه نشوند منبع مورد استفاده آنها در چه مکانی (فیزیکی) قرار دارد. مثال: • نامگذاری (منطقی) یکی از راه های تأمین شفافیت مکانی است. • آیا URL نشان دهنده مکان فیزیکی ست؟ • شفافیت مهاجرتی: جابه جایی منابع بدون اینکه نحوه دسترسی به آنها تفاوت کند. • شفافیت جابجایی: حتی در حین استفاده کاربر از منبع، جابه جایی آن دیده نشود. • قویتر از قبلی است. • مثال: کاربران گوشی های موبایل که در حین جابه جایی، تماس قطع نمی شود.

7. انواع شفافیت (2) • شفافیت در تکرار: کپی های متعدد از یک منبع، از دید کاربر پنهان بماند. • دلیل تکرار منابع در سیستم های توزیعی؟ • لازمه شفافیت در تکرار: • داشتن نام یکسان برای همه کپی ها و یکسان بودن آنها • معمولاٌ باید شفافیت مکانی نیز باشد. • شفافیت در همزمانی: دسترسی های همزمان (رقابتی) کاربران به یک منبع از دید یکدیگر پنهان بماند. مثال: • دو کاربر مستقل داده های خود را روی یک سرور ذخیره کرده باشند. • دو کاربر مستقل همزمان از یک جدول استفاده کنند. • باید سازگاری باشد • بوسیله تعریف قفل یا استفاده از تراکنشها (اتمیک تعریف کردن عملیات) • شفافیت در خرابی: کاربر متوجه خرابی و بازیابی از خرابی سیستم نشود. • یکی از مشکل ترین انواع شفافیت در سیستم های توزیعی (فصل 8) • مشکل اصلی: معمولاً نمی توانیم بین یک منبع خراب و یک منبع خیلی کند تمایز قائل شویم!

8. درجه شفافیت • سیستمی که همه شفافیت های ذکر شده را داشته باشد 100% شفاف است! • ولی • رسیدن به شفافیت کامل اکثر مواقع امکان پذیر نیست. • برخی مواقع نیز شاید لازم نباشد شفافیت کامل داشته باشیم. • برخی مواقع اصلاً بهتر است شفافیت نداشته باشیم! • دلیل دو تای اول: • برقراری مصالحه بین شفافیت و کارایی به گونه ای که کارایی کاهش نیابد. • مثال های اسلایدهای بعدی • مثال سومی: - سیستم های فراگیر: آگاه بودن به زمینه و مکان کاربران مهم است. • تعریف معیار درجه شفافیت • علیرغم این موضوع، تلاش سیستم های توزیعی عمدتاً در جهت افزایش شفافیت است.

9. مثال 1 (کاهش کارایی در تأمین شفافیت) • تضمین سازگاری در کپی های مختلف: • لازمه داشتن نسخه های مختلفی از یک داده، تضمین سازگاری بین کپی هاست. • زمانی صرف یکسان کردن آنها می شود. • تأخیر اعمال می شود. • کارایی کاهش می یابد. • بنابراین گاهی مجبور می شویم سازگاری کامل را کمی قربانی کنیم. • متوجه می شویم که سیستم توزیع شده است.

10. مثال 2 (کاهش کارایی در تأمین شفافیت) • یک فرآیند در کلاینت از طریق شبکه ارتباطی به فرآیند متناظر در سرور وصل می شود. • سرور کند است. • میان افزار درخواست کلاینت را می گیرد و به سرور می دهد و چندین دفعه این کار را انجام می دهد. • میان افزار می فهمد که سرور کُند یا مرده است. • به جای اینکه میان افزار این کار را انجام دهد، خود کلاینت (برنامه کاربردی) درخواست ها را بدهد. • مثلاً پس از سه دفعه درخواست، اگر سرور جواب نداد، کاربر به سرور دیگری مراجعه کند. • کارایی افزایش می یابد. • واضح است که شفافیت را از دست می دهیم. سرور کلاینت

11. سرفصل مطالب • تعریف • اهداف • شفافیت • باز بودن • مقیاس پذیری • انواع سیستم های توزیعی

12. باز بودن • ارائه سرویس ها طبق یک سری قوانین استاندارد • از نظر نحو و معنا • در سیستم های توزیعی: سرویس ها از طریق واسط ها ارائه می شوند. • توصیف واسط ها باید یکسان باشد. • از طریق Interface Definition Language (IDL) • معمولاً IDL برای توصیف نحو است نه معنا • توصیف باید: • کامل باشد. • خنثی باشد. • اکثر تعریف ها این موارد را ادعا می کنند ولی معمولاً این گونه نیستند. • خیلی موارد بر عهده کاربر می افتد و ناسازگاری سیستم ها را نتیجه می دهد. یعنی در تعریف واسط، تمام پارامترها و همه موارد مشخص باشد. در تعریف واسط، از پیاده سازی نگوییم. در واقع تعریف و پیاده سازی باید از هم جدا باشند.

13. From vendor1 From vendor2 باز بودن (2) s1 s2 s4 s3 • کامل و خنثی بودن، مهم هستند برای: • قابلیت همکاری (Interoperability) • دو پیاده سازی از یک سیستم یا مؤلفه هایی از سازندگان مختلف بتوانند با یکدیگر کار کنند. • قابلیت انتقال (Portability) • یعنی یک سرویس طراحی شده برای سیستم توزیعی A بدون تغییر قابل اجرا بر روی سیستم توزیعی B نیز باشد. • سیستم B باید همان واسطهای A را پیاده سازی کرده باشد. • همچنین: • باید بتوان یک سیستم توزیعی را از مؤلفه های مختلف سازندگان مختلف درست کرد. • اضافه کردن مؤلفه جدید و یا جایگزینی مؤلفه ها نیز به همین صورت است. • در مجموع: • یک سیستم توزیعی باز باید قابل توسعه باشد. s6 s5 From vendor1 From vendor2 s1 s2 s1 s2 s4 s4 s3 s3 s6 s6 s5 s5

14. باز بودن (3) • جدا کردن سیاست ها از مکانیزم ها • ارائه تعاریف برای واسط های سطح بالا (کاربرد و کاربر) • ارائه تعریف برای واسط های داخلی سیستم • سیستم های قدیمی یکپارچه (monolithic) هستند. • تغییر یک مؤلفه نیازمند تغییر در کل سیستم است. • سیستم های یکپارچه بسته هستند. • مثال: • کاربران بتوانند سیاست های دلخواه خود را برای تنظیمات کَش مرورگرها، به صورت یک plug-in پیاده سازی کنند.

15. سرفصل مطالب • تعریف • اهداف • شفافیت • باز بودن • مقیاس پذیری • انواع سیستم های توزیعی

16. مقیاس پذیری • ابعاد مقیاس پذیری از سه دیدگاه قابل بررسی است: • اندازه (size) • بتوانیم به راحتی به سیستم کاربر و منبع اضافه کنیم. • حدود جغرافیایی (geographical) • کاربران و منابع در مکانهای نه لزوماً نزدیک یکدیگر باشند. • مدیریتی (administrative) • با وجود سازمان های مدیریتی مستقل از هم، بتوانیم کل سیستم را به راحتی مدیریت کنیم. • مشکلات مقیاس پذیری: • مشکلات مقیاس پذیری از دیدگاه اندازه معمولاً با محدودیت های زیر مواجه هستند. ساده تر سختتر

17. مشکلات مقیاس پذیری • سرویس ها و داده های متمرکز: • همه سرویس ها روی یک ماشین هستند. • همه کلاینت ها باید به یک ماشین رجوع کنند. • واضح است که چنین سیستمی از یک حدی به بعد مقیاس پذیر نیست. • مثال داده های توزیع شده: DNS • الگوریتم های متمرکز: • در الگوریتمهای مسیریابی، بهترین جواب وقتی به دست می آید که دید سراسری از سیستم وجود داشته باشد. • مقیاس پذیری سیستم را پایین می آورد. • بنابراین باید بهینه بودن جواب قربانی مقیاس پذیری شود. • در الگوریتم های مسیریابی غیرمتمرکز: • هیچ ماشینی اطلاعات کامل شبکه را ندارد. • تصمیم گیری ها براساس اطلاعات محلی هستند. • خرابی یک ماشین باعث اختلال در الگوریتم نمی شود. • فرضی در مورد وجود یک ساعت سراسری دقیق نمی شود.

18. مشکلات مقیاس پذیری (2) • مشکل اصلی مقیاس پذیری از دیدگاه جغرافیایی: ارتباطات • در ارتباط سنکرون، کلاینت پس از ارسال درخواست، بلاک می شود تا جواب از سرور دریافت شود. • مزایای ارتباط سنکرون: ابهامی ندارد و برنامه نویسی اش ساده است. • در شبکه های محلی مناسب است. • در شبکه های با وسعت جغرافیایی این گونه نیست. • همچنین ارتباطات از نوع غیرقابل اطمینان و نقطه-به-نقطه است. • مثلاً سِرور زنده است ولی به دلیل دوری فاصله ها، زمان رسیدن جواب طولانی باشد. • بنابراین تشخیص زنده بودن یا نبودن سرور برای ما مشکل می شود. • راه حل: استفاده از ارتباط آسنکرون • ارتباط آسنکرون: برنامه نویسی اش سخت تر می شود. ولی راه حلی برای مشکل مقیاس پذیری جغرافیایی است. request سرور کلاینت reply

19. مشکلات مقیاس پذیری (3) • مقیاس پذیری در سطح مدیریت: • داشتن چندین مجموعه با نظارت مدیریت های مختلف • جمع کردن یکجای این مجموعه ها کار مقیاس پذیری را مشکل می کند. • مثال: تأمین امنیت آنها • سیاست های متضاد در استفاده از منابع و پرداخت ها • مثلاً کاربران یک حوزه به مدیریت حوزه خودشان اعتماد دارند ولی اگر کار به حوزه های دیگر کشیده شود، این گونه نیست. • اگر یک سیستم توزیعی به یک دامنه مدیریتی دیگری گسترده شود: • سیستم توزیع شده باید خودش را در مقابل حمله های دامنه جدید محافظت کند. • دامنه جدید نیز باید خودش را در مقابل حمله های سیستم توزیعی اضافه شده محافظت کند. • ساده ترین راه حل برای حل مشکلات مقیاس پذیری مدیریتی: • چشم پوشی از دامنه های مدیریتی (مثال: شبکه های p2p2)

20. راه حل های مقیاس پذیری • تکنیک های مقیاس پذیری: • پنهان کردن تأخیرهای ارتباطی • توزیع شدگی (distribution) • تکرار (Replication) • پنهان کردن تأخیرهای ارتباطی • اجتناب از انتظار برای پاسخ سرویس های راه دور • ارتباط آسنکرون: مانند کاربردهای پردازش موازی و دسته ای • کاربردهای تعاملی نمی توانند آسنکرون باشند. • راه حل: محول کردن قسمتی از کار به کلاینت: پر کردن فرم ها در اپلت ها یا اسکریپت های جاوا

21. مثال: محول کردن کار به کلاینت در ارتباط آسنکرون

22. توزیع شدگی • تکه تکه کردن اطلاعات و توزیع کردن قطعه ها در قسمت های مختلف سیستم • سیستم DNS • اسامی به ناحیه های (zone) بدون همپوشانی تقسیم می شود. • هر ناحیه (zone) توسط یک سرور نام مدیریت می شود. • مثال دیگر: سیستم مبتنی بر سند اینترنت • صفحات وب روی سرورهای بی شماری در سطح اینترنت توزیع شده اند که از دید کاربران، ظاهراً همه از یک جا می آیند!

23. تکرار • گذاشتن کپی های یکسان از سیستم در جاهای مختلف • متمرکز: دسترس پذیری را افزایش می دهد. • جغرافیایی: کلاینت به نزدیکترین سرور کپی مراجعه می کند. • بار تحمیلی به سرورها متعادل می شود. • مشکل تکرار: • تضمین سازگاری: تغییر دادن یکی، معادل به روز کردن تمام کپی هاست. • آیا می شود سازگاری 100% را همیشه برقرار کرد؟ • از نظر فیزیکی، تغییرات بلافاصله قابل اعمال نیست. از نظر دیگر نگه داشتن همه کپی ها مثل هم سربار زیادی ایجاد می کند. • راه حل مشابه دیگر: کَش کردن • تکرار کردن اطلاعات جدید در مجاورت کلاینتی که اطلاعات را می خواهد. • تفاوت کَش با تکرار: • کَش کردن توسط کلاینت و برحسب تقاضا انجام می شود نه از قبل.