کنترلر توزیع یافته
تعریف سیستم توزیع شده: هر سیستمی که بر روی مجموعه ای از ماشین ها که دارای حافظه اشتراکی نیستند، اجرا شده و برای کاربران به گونه ای اجرا شود که گویا بر روی یک کامپیوتر می باشند ، یک سیستم توزیع شده است. در یک سیستم توزیع شده : یک نرم افزار یا مجموعه نرم افزاری واحد و متحد الشکل بر روی هر گره اجرا می شود. همه ماشینها یک کرنل مشابه را اجرا می کند. هر کرنل منابع خود را کنترل می کند

مواردی که در طراحی سیستم توزیع شده باید در نظر گرفت: شفافیت انعطاف پذیری قابلیت اطمینان کارایی خوب قابلیت گسترش

قابلیت اطمینان: در دسترس بودن یک فاکتور مهم مرتبط با این سیستم ها است. طراحی نباید به گونه ای باشد که نیاز به اجرای همزمان کامپوننت های اساسی باشد. افزونگی بیشتر داده هاه باعث افزایش در دسترس بودن شده اما ناسازگاری را بیشتر میکند. قدرت تحمل نقص(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

قانون 1: استقلال محلی سایتها باید تا حد امکان(بیشترین حد ممکن) مستقل باشند. داده های محلی باید در محل ذخیره و مدیریت شوند(با توجه به در نظر گرفتن یکپارچگی و امنیت) عملیات محلی باید حتما در خود محل اجرا شوند. تمام عملیات در یک سایت باید توسط همان سایت کنترل شود. این بدین معناست که سایت X نباید برای انجام موفقیت آمیز عملیات خود وابسته به سایت Y باشد. در برخی موارد، از دست دادن مقدار کمی از استقلال، اجتناب ناپذیر است: § مشکل قطعه قطعه شدن(قانون 5) § مشکل Replication(قانون 6) § به روز رسانی رابطه Replicate شده(قانون 6) § مشکل محدودیت یکپارچگی بین چند سایت(قانون 7) § A problem in participation in a 2 phase commit process(قانون 8)

قانون 2: عدم وابسته بودن به سایت مرکزی به هیچ عنوان نباید برای یک سرویس مرکزی به یک سایت وابسته بود. بعنوان مثال نباید دارای یک پردازشگر مرکزی(متمرکز) جستجوها یا مدیریت مرکزی(متمرکز) Transaction بود، چرا که کل سیستم به یک سایت خاصی وابسته می شوند. وابسته بودن به یک سایت خاص، حداقل به دو دلیل زیر غیر مطلوب می باشد: § سایت مرکزی ممکن است یک گلوگاه(Bottleneck) باشد. § سیستم ممکن است آسیب پذیر باشد. در یک سیستم توزیع شده، عملیات زیر (در میان سایر عملیات) حتما باید توزیع شده باشند: § مدیریت دیکشنری § پردازش جستجو § کنترل همزمان § کنترل بازیابی

قانون 3: عملیات پیوسته هیچگاه نباید نیاز به خاموش کردن (از قبل پیش بینی شد)ه کل سیستم برای اعمال تغییرات داشته باشیم. اضافه کردن سایت جدید X به سیستم توزیع شده D، نباید باعث توقف کل سیستم شود. اضافه کردن سایت جدید X به سیستم توزیع شده D، نباید نیازمند تغییری در برنامه های کاربر یا فعالیتهای ترمینال باشد. حذف سایت X از سیستم توزیع شده، نباید ئقفه های غیر ضروری در سرویس ایجاد کند. ایجاد و حذف و تکثیر قطعات به صورت پویا باید در یک سیستم توزیع شده امکان پذیر باشد. باید بتوان بدون نیاز به خاموش کردن کل سیستم، DBMS یک سایت را به روز کرد.

قانون 4: استقلال Location نه تنها کاربران نباید از محلی فیزیکی ذخیره داده ها مطلع باشند، بلکه از لحاظ منطقی باید به تصور کنند که داده ها در سایتهای محلی خودشان قرار دارد. ساده کردن برنامه های کاربر و فعالیتهای ترمینال اجازه تغییر سکو فراهم کردن استقلال Location برای عملیات ساده بازیابی ساده تر از عملیات به روز رسانی می باشد. داشتن طرحی برای نام گذاری داده توزیع شده(Distributed Data Naming Scheme) و ایجاد پشتیبانی مناسب از طریق زیر سیستم دیکشنری مواردی که باید در مورد کاربران پیاده سازی شود: § کاربر U باید شناسه معتبری برای ورود در سایتهای مختلف داشته باشد. § پروفایل هر کاربر برای هر شناسه مجاز باید در دیکشنری باشد. دسترسی های هر کاربر در هر سایت به وی اختصاص داده شود.

قانون 5: استقلال قطعات(Fragmentation) سیستمهای توزیع شده از قطعه قطعه شدن داده ها پشتیبانی می کنند، منوط به اینکه یک رابطه خاص قابلیت تقسیم به قسمتهای مختلف برای ذخیره در محلهای فیزیکی گوناگون را داشته باشد. سیستمی که این قابلیت را داشته باشد، از استقلال قطعات نیز پشتیبانی می کند. کاربران باید از لحاظ منطقی به گونه ای تصور کنند که گویا اصلا داده ها در قسمتهای مختلف ذخیره نشده اند. از دلایل قطعه قطعه شدن داده ها، می توان به افزایش کارآیی اشاره کرد. قطعه قطعه شدن افقی(Select) قطعه قطعه شدن عمودی(Project) قطعه قطعه شدن باید در متن یک پایگاه داده توزیع شده تعریف شود. استقلال قطعات همانند استقلال Location باعث ساده تر شدن برنامه های کاربر و فعالیتهای ترمینال می شود. داده هایی که به کاربران نمایش داده می شود، از ترکیب منطقی قطعات مختلف (به واسطه الحاقها(Joins) و اجتماعات(Unions) مناسب)به دست می آید.
مثالی از قطعه قطعه شدن: داده ها از دید کاربران: شماره کارمندی دپارتمان حقوق E1 DX 450.000 E2 DY 400.000 E3 DZ 500.000 E4 DY 630.000 E5 DZ 400.000
قطعه مشهد قطعه تهران
شماره کارمندی دپارتمان حقوق شماره کارمندی دپارتمان حقوق E2 DY 400.000 E1 DX 450.000 E4 DY 630.000 E3 DZ 500.000

E5 DZ 400.000

محل فیزیکی ذخیره داده ها(مشهد) محل فیزیکی ذخیره داده ها(تهران)

قانون 6: استقلال Replication کاربران باید از لحاظ منطقی به گونه ای تصور کنند که گویا اصلا داده ها تکرار(replicated) نشده اند. سیستم توزیع شده از کپی برداری دادها پشتیبانی می کند، به شرط آن که یک رابطه( یا بطور کلی تر یک قطعه از رابطه) بتواند از لحاظ فیزیکی در کپی های مجزا و در سایتهای مجزا ذخیره شود. کپی برداری داده ها باید همانند قطعه قطعه شدن برای کاربران شفاف(غیر قابل تشخیص) باشد. دلایل عمده کپی برداری داده ها § کارآیی § در دسترس بودن(دسترسی) مشکل انتشار به روز رسانی استقلال Replication همانند استقلال قطعات و استقلال Location باعث ساده تر شدن برنامه های کاربر و فعالیتهای ترمینال می شود. رو نوشت از داده ها (Snapshots)
مثالی از کپی برداری داده ها:

داده ها از دید کاربران: شماره کارمندی دپارتمان حقوق E1 DX 450.000 E2 DY 400.000 E3 DZ 500.000 E4 DY 630.000 E5 DZ 400.000

قطعه مشهد قطعه تهران
شماره کارمندی دپارتمان حقوق شماره کارمندی دپارتمان حقوق E2 DY 400.000 E1 DX 450.000 E4 DY 630.000 E3 DZ 500.000

E5 DZ 400.000


کپی قطعه تهران کپی قطعه مشهد
شماره کارمندی دپارتمان حقوق شماره کارمندی دپارتمان حقوق E1 DX 450.000 E2 DY 400.000 E3 DZ 500.000 E4 DY 630.000 E5 DZ 400.000

محل فیزیکی ذخیره داده ها(مشهد) محل فیزیکی ذخیره داده ها(تهران)

قانون 7: پردازش توزیع شده جستجوها یکی از مهمترین و حیاتی ترین نکات در مرود سیستمهای پایگاه داده توزیع شده، انتخاب استراتژی مناسب برای پردازش توزیع شده جستجو(Query) می باشد. پردازش جستجو در سیستم های توزیع شده شامل موارد زیر می باشد: عملیات محلی ورودی و خروجی(I/O) و CPU در سایتهای مجزا تبادل اطلاعات میان سایتهای فوق الذکر Query Compilation Ahead Of Time Views That Span Multiple Sites integrity constraints that within DDBS that span multiple sites

قانون 8: مدیریت توزیع شده Transaction دو نکته مهم برای مدیریت Transaction، کنترل بازیابی(Recovery Control ) و کنترل سازگاری(Consistency Control) می باشد که نیاز به اعمال و دقت بیشتری در محیط های توزیع شده دارند. در یک سیستم توزیع شده، یک Transaction می تواند باعث اجرای کد در چندین سایت شده که همین امر خود می تواند باعث عملیات به روز رسانی در سایتهای مختلف شود. هر Transaction را می توان شامل چندید Agent در نظر گرفت که هر Agent، فرآیندی است که از طرف Transaction در سایت به خصوصی اجرا می شود.

بن بست عمومی: هیچ سایتی نمی تواند با استفاده از اطلاعات داخلی خود، آن را تشخیص دهد. قانون 9 :استقلال سخت افزاری • صرفه نظر از اینکه چه Platform سخت افزاری استفاده می شود، کاربران باید تصویر واحدی از سیستم داشته باشند. • بهتر است بتوان یک DBMS را بر روی سیستمهای سخت افزاری مختلف اجرا کرد. • بهتر است سیستم های مختلف سخت افزاری سهم یکسانی در یک سیستم توزیع شده داشته باشند. • نمی توان به راحتی فرض کرد که همواره می توان از سیستمهای همگن استفاده کرد، به همین دلیل هنوز باید یک DBMS بر روی سیستمهای مختلف سخت افزاری قابل اجرا باشد.

قانون 10: استقلال سیستم عامل • بهتر است که علاوه بر استقلال سخت افزاری، قادر به راه اندازی DBMS بر روی سیستم عاملهای مختلف (حتی سیستم عاملهای مختلف بر روی یک سخت افزار) باشیم. • حداقل سیستم عاملهای مهمی که باید DBMS پشتیبانی کند(با توجه به معیارهای تجاری)، عبارتند از: MVS/XA؛ MVS/ESA، VM/CMS، VAX/VMS، UNIX(محصولات مختلف)، OS/2، MS/DOS و WINDOWS

قانون 11: استقلال شبکه • مطلوب آن است که بتوانیم شبکه های نامتجانس مختلف را پشتیبانی نماییم. • از دید یک DBMS توزیع شده، شبکه یک سرویس مطمئن انتقال پیغام می باشد. • مفهموم مطمئن در عبارت فوق را می توان بدین صورت توصیف نمود که به طور مثال اگر شبکه پیغامی را از سایت X برای تحویل به سایت Y دریافت کرد، سرانجام آن پیغام را به سایت Y تحویل دهد. • نباید در محتوای پیغامها خللی ایجاد شده و پیغامها باید به ترتیب فرستاده شدن ارسال شده و بیش از یکبار نیز تحویل مقصد نشوند. • شبکه مسئول تایید سایت(Site Authentication) نیز می باشد. • یک سیستم ایده آل باید هم از شبکه های محلی(LAN) و هم از شبکه های گسترده(WAN) پشتیبانی نماید. • سیتمهای توزیع شده باید معماریهای مختلف شبکه را پشتیبانی نمایند.

قانون 12:استقلال DBMS سیستم توزیع شده ایده آل باید استقلال DVBMS را مهیا سازد.
PDF
لینکهای مرتبط