سیستم عامل/سیستمهای توزیع شده
تعریف سیستم توزیع شده: هر سیستمی که بر روی مجموعه‌ای از ماشینها که دارای حافظه اشتراکی نیستند، اجرا شده و برای کاربران به گونه‌ای اجرا شود که گویا بر روی یک کامپیوتر می‌باشند، یک سیستم توزیع شده است. در یک سیستم توزیع شده: یک نرم‌افزار یا مجموعه نرم‌افزاری واحد و متحد الشکل بر روی هر گره اجرا می‌شود. همه ماشینها یک کرنل مشابه را اجرا می‌کند. هر کرنل منابع خود را کنترل می‌کند
مواردی که در طراحی سیستم توزیع شده باید در نظر گرفت: شفافیت انعطاف‌پذیری قابلیت اطمینان کارایی خوب قابلیت گسترش
قابلیت اطمینان: در دسترس بودن یک فاکتور مهم مرتبط با این سیستم‌ها است. طراحی نباید به گونه‌ای باشد که نیاز به اجرای همزمان کامپوننت‌های اساسی باشد. افزونگی بیشتر داده هاه باعث افزایش در دسترس بودن شده اما ناسازگاری را بیشتر می‌کند. قدرت تحمل نقص(Fault tolerance) باعث پوشاندن خطاهای ایجاد شده توسط کاربر می‌شود.
کارآیی: بدون کارآیی مناسب کلیه موارد استفاده نرم‌افزار بی فایده می‌باشد. اندازه‌گیری کارایی در سیستمهای توزیع شده کار آسانی نیست. برای رسیدن به کارایی باید توازنی خاص در تعداد پیغامها و اندازه کامپوننهای توزیع شده بر قرار باشد.
قابلیت گسترش: قابلیت گسترش یک اصل کلی برای توسعه سیستمهای توزیع شده می‌باشد. برای رسیدن به این قابلیت باید از کامپوننتها، جداول و الگوریتمهای متمرکز دوری کرد. فقط باید از الگوریتمهای غیر متمرکز استفاده شود.
خصوصیات الگوریتمهای غیر متمرکز:
هیچ ماشینی نباید اطلاعات کاملی در مورد وضعیت سیستم داشته باشد. ماشینها باید بر مبنای اطلاعات محلی خود تصمیم بگیرند. خرابی یک ماشین نباید تاثیری در اجرای الگوریتم داشته باشد. نباید تصوری ضمنی از وجود ساعتی عمومی وجود داشته باشد.
گونه‌های مختلف سیستمهای توزیع شده: سرور- ایستگاه کاری Processor pool هیبرید یکپارچه
مدل سرور -ایستگاه کاری
مدل Processor Pool
مدل هیبرید
مدل یکپارچه
سیستمهای توزیع شده متکی بر ارتباطات هستند و به طور کلی از دو سرویس زیر استفاده می‌کنند: انتقال پیام Message Passing فراخوانی از راه دور رویه‌ها Remote Procedure Call
سیستم توزیع شده از دید لایه بندی‌ها
برنامه‌های کاربردی DBMS,TPS, … سیستم عامل توزیع شده سخت‌افزار
بخشهای اصلی سیستم عامل توزیع شده • مدیریت فایل • مدیریت منابع • مدیریت حافظه • مدیریت فرآیندها • Kernel
سیستم عامل توزیع شده باید امکانات Encapsulating منابع را مهیا سازد. کرنل و سرورها هر دو وظیفه مدیریت منابع را بر عهده دارند و چون شامل منابع نیز می‌باشند، باید موارد زیر را مهیا سازند: مجتمع سازی داده‌ها و سرویس‌ها Encapsulating پردازش همزمان محافظت داده‌ها
نحوه دسترسی به منابع کلاینتها با مشخص سازی منابع در آرگومان عملیات (فراخوانی از راه دور رویه‌ها در سرور یا فراخوانی سیستم در کرنل) به آنها دسترسی پیدا می‌کنند.
ارتباط بین قسمتهای مختلف DBMS
قسمتهای اضافه DDBMS
معماری سیستمهای توزیع شده
بر اساس استاندارد ISO در مدل معماری Open Distributed Computing موارد ذیل باید transparent (شفاف) باشند: دسترسی(Access) موقعیت (Location) همزمانی(Concurrency) کپی برداری داده‌ها (Replication) اشکالات (Failure) تبدیل پلتفرم (Migration) کارآیی (Performance) توسعه پذیری (Scaling)
مدل هایی برای تعامل فرآیندها مدل خادم / مخدوم (Client/Server) مدل یکپارچه مدل پایپ فراخوانی رویه از راه دور(RPC)
مدل کلاینت سرور در این حالت نرم‌افزار خاص کلاینت روی هر ماشین اجرا می‌شود و کلاینت با واسطه سرور به منابع دسترسی پیدا می‌کند. سه مشکل عمده مدل کلاینت سرور عبارت است از: کنترل منابع اختصاصی بر روی یک سرور متمرکز می‌شود. هر سرور به طور بالقوه یک گلوگاه (Bottleneck) است. برای بهبود کارآیی، پیاده‌سازی چندگانه برای توابع مشابه باید انجام شود.
مدل کلاینت سرور در سیستم توزیع شده
مدل یکپارچه در این مدل هر نرم‌افزار کامپیوتر بعنوان ابزاری کامل طراحی شده که دارای فایل سیستمی عمومی و مکانیسمی جهت تفسیر اسامی می‌باشد. این بدین معناست که هر کامپیوتر در سیستم توزیع شده از یک نرم‌افزار استفاده می‌کند. توجه داشته باشید که اگر سیستمی بر پایه مدل یکپارچه توسعه یافته باشد، اگر به صورت مناسبی پیکره بندی شده باشد، می‌تواند به راحتی به شکل سیستمی مبتنی بر مدل Client/Server دیده شود.
مدل Pipe مدل پایپ بر اساس مفهوم فرایند پایه ریزی شده است که در این مدل داده از طریق استراتژی FIFO می‌توانند بین فرآیندها منتقل شوند. همچنین این مدل اجازه همگام بودن اجرای فرآیندها را می‌دهد. در این مدل به طور سنتی از فایل سیستم برای ذخیره داده‌ها استفاده شده و از قابلیتهای منحصر بفرد آن امکان ارسال کلی داده توسط فرایند به یک گره می‌باشد.
مدل RPC در سیستمهای مبتنی بر RPC، یک فرایند می‌تواند یک رویه را در یک کامپیوتر راه دور فراخوانی کند. هنگامی که عمل فراخوانی انجام می‌شود، پیغام درخواستی برای کامپیوتر راه دوری که رویه در آن قرار دارد فرستاده می‌شود، سپس فرآیندی ایجاد می‌شود تا رویه اجرا شود، بعد از کامل شدن این فرایند، پیغام پاسخ به فرایند صدازننده فرستاده می‌شود.
دلایل توزیع داده • DBMS متمرکز در مقابل سیستم پایگاه داده توزیع شده • سیستم پایگاه داده توزیع شده مجموعه‌ای از داده‌ها است که از لحاظ منطقی به یک سیستم تعلق دارند ولی از لحاظ فیزیکی در سایتهای مختلف یک شبکه کامپیوتری قرار دارند.
فاکتورهای مختلفی که باعث توسعه سیستم پایگاه داده توزیع شده شده‌اند عبارت است از: طبیعت توزیع شدگی برخی از برنامه‌های دیتا بیس افزایش قابلیت اطمینان و در دسترس بودن امکان به اشتراک گذاشتن داده‌ها افزایش کارآیی
طراحی و پیاده‌سازی سیستم پایگاه داده توزیع شده از پیچیدگیهای بیشتری برخوردار است و نسبت به DBMSهای متمرکز توابع بیشتری را باید پیاده‌سازی کرد از جمله: دسترسی به سایتها و انتقال جستجوها و داده‌ها اطلاع از توزیع داده‌ها و Replication در کاتالوگ DDBMS بکارگیری استراتژیهای مناسب برای اجرای پرس و جوها و ... که دادهایشان در چندین سایت مختلف قرار دارد. تصمیم گیری در مورد استفاده از کدامین داده Replicate شده سازگار نگه داشتن کپی‌های داده‌های Replicate شده قابلیت بازیابی داده‌ها از سایتهایی که دارای مشکل شده‌اند؛ و ...
معماری فیزیکی DDBS
قانونهایی برای سیستمهای توزیع شده
قانون صفر: سیستمهای توزیع شده باید برای کاربر نهایی دقیقا به صورت سیستمهای متمرکز باشند.
استقلال محلی عدم وابسته بودن به سایت مرکزی عملیات پیوسته استقلال Location استقلال قطعات(Fragmentation) استقلال Replication پردازش توزیع شده جستجوها مدیریت توزیع شده Transaction استقلال سخت‌افزاری استقلال سیستم عامل استقلال شبکه استقلال DBMS
قانون ۱: استقلال محلی سایتها باید تا حد امکان (بیشترین حد ممکن) مستقل باشند. داده‌های محلی باید در محل ذخیره و مدیریت شوند (با توجه به در نظر گرفتن یکپارچگی و امنیت) عملیات محلی باید حتما در خود محل اجرا شوند. تمام عملیات در یک سایت باید توسط همان سایت کنترل شود. این بدین معناست که سایت X نباید برای انجام موفقیت آمیز عملیات خود وابسته به سایت Y باشد. در برخی موارد، از دست دادن مقدار کمی از استقلال، اجتناب ناپذیر است: § مشکل قطعه قطعه شدن (قانون ۵) § مشکل Replication(قانون ۶) § به روز رسانی رابطه Replicate شده (قانون ۶) § مشکل محدودیت یکپارچگی بین چند سایت (قانون ۷) § A problem in participation in a 2 phase commit process(قانون ۸)
قانون ۲: عدم وابسته بودن به سایت مرکزی به هیچ عنوان نباید برای یک سرویس مرکزی به یک سایت وابسته بود. بعنوان مثال نباید دارای یک پردازشگر مرکزی (متمرکز) جستجوها یا مدیریت مرکزی (متمرکز) Transaction بود، چرا که کل سیستم به یک سایت خاصی وابسته می‌شوند. وابسته بودن به یک سایت خاص، حداقل به دو دلیل زیر غیر مطلوب می‌باشد: § سایت مرکزی ممکن است یک گلوگاه(Bottleneck) باشد. § سیستم ممکن است آسیب پذیر باشد. در یک سیستم توزیع شده، عملیات زیر (در میان سایر عملیات) حتما باید توزیع شده باشند: § مدیریت دیکشنری § پردازش جستجو § کنترل همزمان § کنترل بازیابی
قانون ۳: عملیات پیوسته هیچگاه نباید نیاز به خاموش کردن (از قبل پیش بینی شد) ه کل سیستم برای اعمال تغییرات داشته باشیم. اضافه کردن سایت جدید X به سیستم توزیع شده D، نباید باعث توقف کل سیستم شود. اضافه کردن سایت جدید X به سیستم توزیع شده D، نباید نیازمند تغییری در برنامه‌های کاربر یا فعالیتهای ترمینال باشد. حذف سایت X از سیستم توزیع شده، نباید ئقفه‌های غیر ضروری در سرویس ایجاد کند. ایجاد و حذف و تکثیر قطعات به صورت پویا باید در یک سیستم توزیع شده امکان‌پذیر باشد. باید بتوان بدون نیاز به خاموش کردن کل سیستم، DBMS یک سایت را به روز کرد.
قانون ۴: استقلال Location نه تنها کاربران نباید از محلی فیزیکی ذخیره داده‌ها مطلع باشند، بلکه از لحاظ منطقی باید به تصور کنند که داده‌ها در سایتهای محلی خودشان قرار دارد. ساده کردن برنامه‌های کاربر و فعالیتهای ترمینال اجازه تغییر سکو فراهم کردن استقلال Location برای عملیات ساده بازیابی ساده‌تر از عملیات به روز رسانی می‌باشد. داشتن طرحی برای نام گذاری داده توزیع شده(Distributed Data Naming Scheme) و ایجاد پشتیبانی مناسب از طریق زیر سیستم دیکشنری مواردی که باید در مورد کاربران پیاده‌سازی شود: § کاربر U باید شناسه معتبری برای ورود در سایتهای مختلف داشته باشد. § پروفایل هر کاربر برای هر شناسه مجاز باید در دیکشنری باشد. دسترسی‌های هر کاربر در هر سایت به وی اختصاص داده شود.
قانون ۵: استقلال قطعات(Fragmentation) سیستمهای توزیع شده از قطعه قطعه شدن داده‌ها پشتیبانی می‌کنند، منوط به اینکه یک رابطه خاص قابلیت تقسیم به قسمتهای مختلف برای ذخیره در محلهای فیزیکی گوناگون را داشته باشد. سیستمی که این قابلیت را داشته باشد، از استقلال قطعات نیز پشتیبانی می‌کند. کاربران باید از لحاظ منطقی به گونه‌ای تصور کنند که گویا اصلا داده‌ها در قسمتهای مختلف ذخیره نشده‌اند. از دلایل قطعه قطعه شدن داده‌ها، می‌توان به افزایش کارآیی اشاره کرد. قطعه قطعه شدن افقی(Select) قطعه قطعه شدن عمودی(Project) قطعه قطعه شدن باید در متن یک پایگاه داده توزیع شده تعریف شود. استقلال قطعات همانند استقلال Location باعث ساده‌تر شدن برنامه‌های کاربر و فعالیتهای ترمینال می‌شود. داده‌هایی که به کاربران نمایش داده می‌شود، از ترکیب منطقی قطعات مختلف (به واسطه الحاقها(Joins) و اجتماعات(Unions) مناسب) به دست می‌آید.
مثالی از قطعه قطعه شدن: داده‌ها از دید کاربران: شماره کارمندی دپارتمان حقوق E1 DX ۴۵۰٫۰۰۰ E2 DY ۴۰۰٫۰۰۰ E3 DZ ۵۰۰٫۰۰۰ E4 DY ۶۳۰٫۰۰۰ E5 DZ ۴۰۰٫۰۰۰
قطعه مشهد قطعه تهران
شماره کارمندی دپارتمان حقوق شماره کارمندی دپارتمان حقوق E2 DY ۴۰۰٫۰۰۰ E1 DX ۴۵۰٫۰۰۰ E4 DY ۶۳۰٫۰۰۰ E3 DZ ۵۰۰٫۰۰۰
E5 DZ ۴۰۰٫۰۰۰
محل فیزیکی ذخیره داده‌ها (مشهد) محل فیزیکی ذخیره داده‌ها (تهران)
قانون ۶: استقلال Replication کاربران باید از لحاظ منطقی به گونه‌ای تصور کنند که گویا اصلا داده‌ها تکرار(replicated) نشده‌اند. سیستم توزیع شده از کپی برداری دادها پشتیبانی می‌کند، به شرط آن که یک رابطه (یا بطور کلی تر یک قطعه از رابطه) بتواند از لحاظ فیزیکی در کپی‌های مجزا و در سایتهای مجزا ذخیره شود. کپی برداری داده‌ها باید همانند قطعه قطعه شدن برای کاربران شفاف (غیرقابل تشخیص) باشد. دلایل عمده کپی برداری داده‌ها § کارآیی § در دسترس بودن (دسترسی) مشکل انتشار به روز رسانی استقلال Replication همانند استقلال قطعات و استقلال Location باعث ساده‌تر شدن برنامه‌های کاربر و فعالیتهای ترمینال می‌شود. رو نوشت از داده‌ها (Snapshots)
مثالی از کپی برداری داده‌ها:
داده‌ها از دید کاربران: شماره کارمندی دپارتمان حقوق E1 DX ۴۵۰٫۰۰۰ E2 DY ۴۰۰٫۰۰۰ E3 DZ ۵۰۰٫۰۰۰ E4 DY ۶۳۰٫۰۰۰ E5 DZ ۴۰۰٫۰۰۰
قطعه مشهد قطعه تهران
شماره کارمندی دپارتمان حقوق شماره کارمندی دپارتمان حقوق E2 DY ۴۰۰٫۰۰۰ E1 DX ۴۵۰٫۰۰۰ E4 DY ۶۳۰٫۰۰۰ E3 DZ ۵۰۰٫۰۰۰
E5 DZ ۴۰۰٫۰۰۰
کپی قطعه تهران کپی قطعه مشهد
شماره کارمندی دپارتمان حقوق شماره کارمندی دپارتمان حقوق E1 DX ۴۵۰٫۰۰۰ E2 DY ۴۰۰٫۰۰۰ E3 DZ ۵۰۰٫۰۰۰ E4 DY ۶۳۰٫۰۰۰ E5 DZ ۴۰۰٫۰۰۰
محل فیزیکی ذخیره داده‌ها (مشهد) محل فیزیکی ذخیره داده‌ها (تهران)
قانون ۷: پردازش توزیع شده جستجوها یکی از مهمترین و حیاتی ترین نکات در مرود سیستمهای پایگاه داده توزیع شده، انتخاب استراتژی مناسب برای پردازش توزیع شده جستجو(Query) می‌باشد. پردازش جستجو در سیستمهای توزیع شده شامل موارد زیر می‌باشد: عملیات محلی ورودی و خروجی(I/O) و CPU در سایتهای مجزا تبادل اطلاعات میان سایتهای فوق‌الذکر Query Compilation Ahead Of Time Views That Span Multiple Sites integrity constraints that within DDBS that span multiple sites
قانون ۸: مدیریت توزیع شده Transaction دو نکته مهم برای مدیریت Transaction، کنترل بازیابی(Recovery Control) و کنترل سازگاری(Consistency Control) می‌باشد که نیاز به اعمال و دقت بیشتری در محیط‌های توزیع شده دارند. در یک سیستم توزیع شده، یک Transaction می‌تواند باعث اجرای کد در چندین سایت شده که همین امر خود می‌تواند باعث عملیات به روز رسانی در سایتهای مختلف شود. هر Transaction را می‌توان شامل چندید Agent در نظر گرفت که هر Agent، فرآیندی است که از طرف Transaction در سایت به خصوصی اجرا می‌شود.
بن‌بست عمومی: هیچ سایتی نمی‌تواند با استفاده از اطلاعات داخلی خود، آن را تشخیص دهد. قانون ۹ :استقلال سخت‌افزاری • صرفه نظر از اینکه چه Platform سخت‌افزاری استفاده می‌شود، کاربران باید تصویر واحدی از سیستم داشته باشند. • بهتر است بتوان یک DBMS را بر روی سیستمهای سخت‌افزاری مختلف اجرا کرد. • بهتر است سیستمهای مختلف سخت‌افزاری سهم یکسانی در یک سیستم توزیع شده داشته باشند. • نمی‌توان به راحتی فرض کرد که همواره می‌توان از سیستمهای همگن استفاده کرد، به همین دلیل هنوز باید یک DBMS بر روی سیستمهای مختلف سخت‌افزاری قابل اجرا باشد.
قانون ۱۰: استقلال سیستم عامل • بهتر است که علاوه بر استقلال سخت‌افزاری، قادر به راه‌اندازی DBMS بر روی سیستم عاملهای مختلف (حتی سیستم عاملهای مختلف بر روی یک سخت‌افزار) باشیم. • حداقل سیستم عاملهای مهمی که باید DBMS پشتیبانی کند (با توجه به معیارهای تجاری)، عبارتند از: MVS/XA؛ MVS/ESA، VM/CMS، VAX/VMS، UNIX(محصولات مختلف)، OS/2، MS/DOS و WINDOWS
قانون ۱۱: استقلال شبکه • مطلوب آن است که بتوانیم شبکه‌های نامتجانس مختلف را پشتیبانی نماییم. • از دید یک DBMS توزیع شده، شبکه یک سرویس مطمئن انتقال پیغام می‌باشد. • مفهموم مطمئن در عبارت فوق را می‌توان بدین صورت توصیف نمود که به طور مثال اگر شبکه پیغامی را از سایت X برای تحویل به سایت Y دریافت کرد، سرانجام آن پیغام را به سایت Y تحویل دهد. • نباید در محتوای پیغامها خللی ایجاد شده و پیغامها باید به ترتیب فرستاده شدن ارسال شده و بیش از یکبار نیز تحویل مقصد نشوند. • شبکه مسئول تایید سایت(Site Authentication) نیز می‌باشد. • یک سیستم ایده آل باید هم از شبکه‌های محلی(LAN) و هم از شبکه‌های گسترده(WAN) پشتیبانی نماید. • سیتمهای توزیع شده باید معماریهای مختلف شبکه را پشتیبانی نمایند.
قانون ۱۲:استقلال DBMS سیستم توزیع شده ایده آل باید استقلال DVBMS را مهیا سازد.