مرجان نادران طحان استادیار گروه مهندسی کامپیوتر دانشگاه شهید چمران اهواز m.naderan@scu.ac.ir

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

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

3. سرفصل مطالب • نخ ها (threads) • مجازی سازی (virtualization) • کلاینت ها و سرورها • مهاجرت کد (code migration)

4. سرفصل مطالب • نخ ها (threads) • مجازی سازی (virtualization) • کلاینت ها و سرورها • مهاجرت کد (code migration)

5. کلاینت ها • واسط کاربری شبکه ای (Networked User Interface) • یکی از مهمترین وظایف کلاینت ها، ایجاد واسط برای ارتباط با سرورها است. • روش اول: • به ازای هر سرویس راه دور، کلاینت یک همتا برای برقراری سرویس در سمت سرور دارد.

6. کلاینت ها (2) • روش دوم: • برای دسترسی به تمامی سرویس ها فقط از یک واسط کاربری متداول استفاده شود. • کلاینت فقط یک ترمینال است که نیازی به حافظه محلی ندارد و مستقل از پروتکل است. • کلاینت ضعیف • اخیراً باز محبوب شده به خاطر وسایل کوچک ارتباطی امروزی

7. سیستم X Window • سیستم X: • قسمتی از کتابخانه سیستم عامل که ترمینال را از طریق ماوس، صفحه کلید و مانیتور کنترل می کند. • جد همه سیستم عامل های مبتنی بر پنجره • قسمت اصلی: X kernel که وابسته به سخت افزار نیز هست. • کتابخانه آن تحت عنوان Xlib است. • X kernel و X applications می توانند روی ماشین های مختلف باشند. • ارتباط از طریق X protocol است. • برنامه اصلی به نام ”مدیر پنجره“ مشخصات پنجره ها، دکمه ها، ... را مدیریت می کند. • X kernel مانند سرور عمل می کند و برنامه های کاربردی که درخواست به آن می فرستند همان کلاینت ها هستند.

8. سیستم X Window (2)

9. کلاینت های ضعیف (Thin client) • وقتی شبکه ارتباطی گسترده باشد، X Window کارایی خود را از دست می دهد. • برای فائق آمدن بر مشکلات X Window • تغییر پیاده سازی X protocol که منجر به پروتکل NXشد، شامل: • فشرده کردن پیغام های X • استفاده از کَشینگ در هر دو طرف فرستنده و گیرنده • محول کردن نحوه نمایش در سطح پیکسل به سمت کلاینت

10. نرم افزارهای سمت کلاینت برای تأمین شفافیت • بررسی نقش کلاینت ها در تأمین شفافیت • کلاینت ها معمولاً بیش از واسط کاربری هستند (پردازش، ذخیره سازی، ...) • بنام ”نرم افزار نهفته در کلاینت“ • مانند ATM ها، دستگاه های بارکد، تلویزیون ها ست-تاپ باکس، ... • در مقابل سرورها معمولاً به دلایلی مانند کارایی، نقش زیادی در تأمین شفافیت ندارند. • اِستاب (Stub): • نقاط واسطی در سمت کلاینت و سرور • در واقع، میان افزار هستند و شفافیت را ایجاد می کنند. • تفاوت های پروتکل های ارتباطی و ماشین ها را می پوشانند. • ارتباط برنامه های کاربردی از طریق استاب ها هستند. • شفافیت دسترسی از طریق استاب انجام می شود.

11. نرم افزارهای سمت کلاینت برای تأمین شفافیت (2) • توضیحات تکمیلی در مورد استاب: • از طریق IDL تولید می شوند. • واسط را تعریف می کنیم که شامل چه متغیرهایی است، ... • واسط کامپایل شده و استاب تولید می شود. • استاب سمت کلاینت قسمتی از وظایف شفافیت را انجام می دهد و سمت سرور بخش دیگری. • شفافیت های استاب سمت کلاینت: • دسترسی • مکانی • مهاجرتی، جابجایی • تکرار • خرابی

12. نرم افزارهای سمت کلاینت برای تأمین شفافیت (3) • مثال: شفافیت تکرار • شفافیت هایی که توسط سرورها تأمین می شوند: • همزمانی • ماندگاری (Persistent): تعریف در نسخه قدیمی کتاب • پنهان کردن اینکه منبع (نرم افزار) در حافظه اصلی وجود دارد یا روی دیسک از دید کاربر

13. سرفصل مطالب • نخ ها (threads) • مجازی سازی (virtualization) • کلاینت ها و سرورها • مهاجرت کد (code migration)

14. ملاحظات عمومی در طراحی سرورها • فرآیند سرور • فرآیندی که سرویس خاصی را برای مجموعه ای از کلاینت ها فراهم می کند. • منتظر درخواست می ماند و با دریافت درخواست، آن را پردازش می کند. • روش های سازماندهی سرورها: • Iterative: سرور خودش درخواست را بررسی کرده و جواب را به کلاینت برمی گرداند. • Concurrent: سرور درخواست را به یک نخ دیگر می دهد و خودش منتظر درخواست بعدی می ماند. • مثال: سرورهای چندنخی • فرآیند سرور با دریافت درخواست جدید fork شود.

15. ملاحظات عمومی در طراحی سرورها (2) • مسأله دوم: محل ارتباط کلاینت و سرور کجا باشد؟ • کلاینت درخواست خود را به یک نقطه انتهایی (end point) یا پورت در ماشین سرور می فرستد. • Port = machine address + process address • به این ترتیب محل ارتباط برای هر فرآیندی مشخص است. • مسأله سوم: کلاینت چگونه شماره پورت را می داند؟ • انتساب شماره ها به پورت ها به صورت سراسری برای سرویس های شناخته شده. • مثال: سرورهای ftp به پورت TCP شماره 21 گوش می دهند. • سرورهای http به پورت TCP شماره 80 گوش می دهند. • به این ترتیب کلاینت باید فقط آدرس IP ماشین سرور را پیدا کند. • استفاده از شماره های دینامیک که توسط سیستم عامل منتسب می شوند.

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

17. ملاحظات عمومی در طراحی سرورها (4) • سوپرسرور: • به جای اینکه سرورهای مختلف برای سرویس های مختلف داشته باشیم، یک سرور وجود داشته باشد که به شماره پورت های سرویس های مختلف گوش می دهد. • مثال: دیمون inetd در یونیکس که با آمدن درخواست جدید fork می شود.

18. ملاحظات عمومی در طراحی سرورها (5) • مسأله چهارم: چگونه یک درخواست ارسال شده به یک سرور را ملغی کنیم؟ • کلاینت برنامه خود را ببندد و دوباره باز کند و وانمود کند که درخواستی مطرح نشده است. • راه دیگر: طراحی کلاینت و سرور به گونه ای که کانالی برای ارسال اطلاعات کنترلی (out-of-band) نیز وجود داشته باشد. • این داده های کنترلی با اولویت بالا توسط سرور پردازش می شوند. • شماره پورت مشخصی برای ارسال اطلاعات کنترلی مشخص شود تا سرور با اولویت بالا به آن گوش دهد.

19. ملاحظات عمومی در طراحی سرورها (6) • مسأله آخر: سرور بدون حالت (stateless) یا با حالت (stateful) • سرور بدون حالت: • اطلاعاتی راجع به حالت کلاینت های خود نگهداری نمی کند. • حالت خود را می تواند تغییر داده و به کلاینت خبر ندهد. • مثال: وب سروری که به درخواست های http پاسخ می دهد. • ممکن است در مواردی اطلاعاتی راجع به کلاینت هایش نیز نگهداری کند ولی با از بین رفتن این اطلاعات کار سرور مختل نمی شود. • مثال: نگه داشتن کوکی ها سمت کلاینت از طرف سرور • فرم دیگری از طراحی بدون حالت: • سروری که ”حالت نرم“ را نگهداری می کند. • اطلاعاتی از کلاینت ها را ذخیره می کند ولی برای مدت معینی. • پس از سپری شدن زمان مشخص، انگار که هیچ اطلاعی از کلاینت ندارد. • مثال: سروری که کلاینت را راجع به به روز رسانی ها باخبر می کند.

20. ملاحظات عمومی در طراحی سرورها (7) • سرور باحالت • اطلاعات ماندگار راجع به کلاینت هایش نگهداری می کند. • مثال: فایل سروری که به کلاینتش اجازه می دهد یک کپی محلی از فایل داشته باشد. • این سرور جدولی شامل اطلاعات دوتایی های (client, file) نگهداری می کند. • نکته: کارایی سرورهای باحالت نسبت به بدون حالت ها بیشتر است. • مشکل: با خراب شدن سرور تمامی اطلاعات راجع به کلاینت ها از بین می رود و یا سرور باید اطلاعات را بازیابی کند.

21. ملاحظات عمومی در طراحی سرورها (8) • تفاوت حالت نشست و حالت دائمی • حالت نشست: اطلاعات مربوط به عملیاتی که توسط یک کاربر خاص درخواست می شود و برای مدت معینی نگهداری می شود. • در معماری های کلاینت-سروری 3-لایه ای استفاده می شود. • اگر از بین برود اتفاق خاصی نمی افتد. • اطلاعاتی که وب سرورها از کلاینت ها نگهداری می کنند در دسترسی به صفحات وب (کوکی ها) در این دسته هستند. • حالت دائمی: اطلاعاتی که در پایگاه داده ها راجع به کلاینتها نگهداری می شود.

22. سرور کلاسترها • مجموعه ای از سرورها که توسط شبکه ای به یکدیگر وصلند. • شبکه، اغلب محلی، پرسرعت و با تأخیر کم است. • از طرف دنیای بیرون فقط یک سرور دیده می شود با یک نقطه دسترسی.

23. سرور کلاسترها (2) • ساختار 3-لایه ای دارد: • سوئیچی که درخواست های کلاینت ها را هدایت می کند. • مثال: سوئیچ لایه انتقال که درخواست های TCP را هدایت می کند. • سرورها یا ماشین های محاسباتی قدرتمندی که نیازمند دسترسی به ابزارهای ذخیره سازی هستند. • هر ماشین می تواند سرویس کاربردی متفاوتی ارائه بدهد. • مدیریت راحت تر • ابزارهای ذخیره سازی با حجم و سرعت دسترسی بالا • اگر هر ماشین سروری به ابزار ذخیره سازی خودش دسترسی داشته باشد، ساختار 2-لایه ای می شود. • سوئیچ ها باید از محتوای درخواست ها آگاه باشند و بتوانند سرویس های متمایز را تشخیص دهند. • اگر ساختار 2-لایه ای باشد نیازی به تمایز سرویس ها نیست.

24. سرور کلاسترها (3)

25. سرور کلاسترها (4) • اگر از سرویس سروری استفاده نشود بیکار می شود. • اگر سرورهای دیگری زیر بار کاری باشند، می توان با استفاده از مفهوم ماشین مجازی، یک وظیفه را مهاجرت داد. • بالانس کردن بار کاری روی سرورها

26. سرور کلاسترها (5) • مجموعه سرورها باید از دید کاربران یک سرور دیده شوند • شفافیت دسترسی • باید یک پورت دسترسی فراهم باشد (توسط یک ماشین خاص). • سوئیچ باید یک آدرس شبکه داشته باشد. • می توان یک سرور کلاستر را با چندین پورت دسترسی نیز تعریف کرد. • افزایش قابلیت مقیاس پذیری و دسترس پذیری • سوئیچ های لایه انتقال، درخواست های برقراری اتصال TCP را پذیرفته و آن را به یک سرور پاس می دهند.

27. سرور کلاسترها (6) • پاس کاری TCP (TCP handoff) • سوئیچ با دریافت یک درخواست اتصال TCP، بهترین سروری که می تواند درخواست را انجام دهد شناسایی کرده و درخواست را به آن می فرستد. • سرور تأییدیه به کلاینت برمی گرداند ولی آدرس سوئیچ را به عنوان فرستنده در آن قرار می دهد. • زیرا کلاینت سوئیچ را می شناسد نه تک تک سرورها را! • تغییرات در سطح سیستم عامل لازم است. • استراتژی سوئیچ برای انتخاب سرور • ساده ترین حالت: چرخشی (round robin) • اگر سرویس های سرورها متمایز باشند، سوئیچ باید بتواند درخواست ها را تشخیص دهد و یا محتوای آنها را بررسی کند (content-aware request distribution).

28. سرور کلاسترها (5) • نحوه پاس کاری TCP

29. سرور کلاسترها (6) • مشکل سرور کلاسترها: • تنظیم آنها استاتیک است. • یک ماشین باید آمار همه سرورها را داشته باشد. • آدرس ها مشخصند و اگر سوئیچ تغییر کند ممکن است آدرس آن نیز تغییر کند. • سوئیچ یک نقطه خرابی است. • می توان با گذاشتن چندین نقطه دسترسی مشکل را حل کرد. • ولی کلاینت ها باید چندین بار تلاش کنند. • انتظارات دیگر از سرور کلاسترها: • پایدار بودن سیستم (stability) • منعطف بودن در تنظیمات (flexibility) • راه حل: سرورهای توزیع شده • مجموعه ای دینامیک از ماشین ها با نقاط دسترسی قابل تغییر که از دید بیرون یک ماشین دیده می شود.