به گفته کارشناس معروف در زمینه علوم کامپیوتر E. Tanenbaum، هیچ تعریف عمومی پذیرفته شده و در عین حال دقیقی از سیستم توزیع شده وجود ندارد. برخی عقلا استدلال می کنند که توزیع شده چنین است سیستم محاسباتی، که در آن خرابی رایانه ای که قبلاً کاربران حتی به وجود آن مشکوک نبودند منجر به پایان کار آنها می شود. متأسفانه بخش قابل توجهی از سیستم های محاسباتی توزیع شده این تعریف را برآورده می کند، اما به طور رسمی فقط به سیستم هایی با یک نقطه آسیب پذیری منحصر به فرد اشاره می کند. تنها نقطه شکست).

اغلب، هنگام تعریف یک سیستم توزیع شده، تمرکز بر تقسیم عملکردهای آن بین چندین کامپیوتر است. با این رویکرد، هر توزیع می شود سیستم محاسباتیکه در آن پردازش داده ها بین دو یا چند کامپیوتر تقسیم می شود. بر اساس تعریف E. Tanenbaum، یک سیستم با توزیع محدودتر را می توان به عنوان مجموعه ای از کامپیوترهای مستقل که توسط کانال های ارتباطی متصل شده اند تعریف کرد، که از دیدگاه کاربر برخی از نرم افزارها، مانند یک کل واحد به نظر می رسند.

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

به عنوان مبنایی برای توصیف تعامل دو موجودیت، مدل کلی تعامل مشتری و سرور را در نظر بگیرید که در آن یکی از طرفین (کلاینت) با ارسال درخواست به طرف دیگر (سرور) مبادله داده را آغاز می کند. سرور درخواست را پردازش می کند و در صورت لزوم پاسخی را برای مشتری ارسال می کند (شکل 1.1).

برنج. 1.1.

تعامل در چارچوب مدل کلاینت-سرور می تواند همزمان باشد، زمانی که کلاینت منتظر است تا سرور درخواست خود را پردازش کند، یا ناهمزمان، که در آن مشتری درخواستی را به سرور ارسال می کند و بدون منتظر ماندن برای سرور به اجرای آن ادامه می دهد. واکنش. مدل مشتری و سرور می تواند به عنوان مبنایی برای توصیف تعاملات مختلف استفاده شود. برای این دوره، تعامل اجزای سازنده نرم افزار که یک سیستم توزیع شده را تشکیل می دهد، مهم است.

برنج. 1.2.

یک کاربرد معمولی خاص را در نظر بگیرید که مطابق با مفاهیم مدرن، می توان آن را به سطوح منطقی زیر تقسیم کرد (شکل 1.2): رابط کاربری(PI)، منطق برنامه (LP) و دسترسی به داده (DD)، کار با پایگاه داده (DB). کاربر سیستم از طریق رابط کاربری با آن تعامل دارد، پایگاه داده داده هایی را که دامنه برنامه را توصیف می کند ذخیره می کند، و لایه منطق برنامه تمام الگوریتم های مربوط به موضوع.

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

برنج. 1.3.

معماری برنامه هایی که بر اساس این اصل ساخته شده اند، کلاینت-سرور یا دو لایه نامیده می شود. در عمل، چنین سیستم هایی اغلب به عنوان توزیع شده طبقه بندی نمی شوند، اما به طور رسمی می توان آنها را ساده ترین نمایندگان سیستم های توزیع شده در نظر گرفت.

توسعه معماری مشتری-سرور یک معماری سه لایه است که در آن رابط کاربری، منطق برنامه و دسترسی به داده ها به اجزای مستقل سیستم که می توانند بر روی رایانه های مستقل کار کنند، جدا می شوند (شکل 1.4).

برنج. 1.4.

درخواست کاربر در چنین سیستم هایی توسط بخش مشتری سیستم، سرور منطق برنامه و سرور پایگاه داده به صورت متوالی پردازش می شود. با این حال، یک سیستم توزیع شده معمولاً به عنوان یک سیستم با معماری پیچیده تر از یک سیستم سه لایه درک می شود.

اصول ایجاد یک سیستم پردازش اطلاعات در سطح سازمانی

تاریخ توسعه فناوری رایانه (و بر این اساس، نرم افزار) با سیستم های جداگانه و مستقل آغاز شد. دانشمندان و مهندسان مشغول ایجاد اولین کامپیوترها بودند و بیشتر در مورد چگونگی کارکرد این دسته از لوله های خلاء متحیر بودند. با این حال ، این وضعیت زیاد دوام نیاورد - ایده ترکیب قدرت محاسباتی کاملاً واضح بود و در هوا بود و با صدای زمزمه کابینت های فلزی اولین ENIAKs و Marks اشباع شده بود. از این گذشته، ایده ترکیب تلاش دو یا چند رایانه برای حل وظایف پیچیده و غیرقابل تحمل برای هر یک از آنها به طور جداگانه در سطح وجود دارد.

برنج. 1. طرح محاسبات توزیع شده

با این حال، اجرای عملی ایده اتصال رایانه‌ها به خوشه‌ها و شبکه‌ها به دلیل نبود راه‌حل‌های فنی و اول از همه، نیاز به ایجاد استانداردها و پروتکل‌های ارتباطی با مشکل مواجه شد. همانطور که می دانید، اولین کامپیوترها در اواخر دهه چهل قرن بیستم ظاهر شدند و اولین شبکه کامپیوتری ARPANet که چندین کامپیوتر را در ایالات متحده به هم متصل کرد، تنها در سال 1966، تقریبا بیست سال بعد، ظاهر شد. البته، چنین ترکیبی از قابلیت‌های محاسباتی یک معماری توزیع‌شده مدرن بسیار مبهم بود، اما با این وجود اولین گام در مسیر درست بود.

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

به تدریج، مین‌فریم‌ها و پایانه‌ها به سمت معماری سرویس گیرنده-سرور تکامل یافتند، که اساساً اولین نسخه یک معماری توزیع‌شده، یعنی یک سیستم توزیع‌شده دو لایه بود. از این گذشته، در برنامه های کاربردی سرویس گیرنده-سرور بود که بخشی از عملیات محاسباتی و منطق تجاری به سمت مشتری منتقل شد، که در واقع به برجسته ترین ویژگی این رویکرد تبدیل شد.

در این دوره بود که مشخص شد مزایای اصلی برنامه های کاربردی توزیع شده عبارتند از:

· مقیاس پذیری خوب - در صورت لزوم، قدرت محاسباتی یک برنامه کاربردی توزیع شده را می توان به راحتی بدون تغییر ساختار آن افزایش داد.

· توانایی مدیریت بار - سطوح متوسط ​​یک برنامه کاربردی توزیع شده، امکان مدیریت جریان درخواست های کاربر و هدایت آنها به سرورهای کمتر بارگذاری شده برای پردازش را فراهم می کند.

· جهانی بودن - یک ساختار توزیع شده به شما امکان می دهد تا توزیع فضایی فرآیندهای تجاری را دنبال کنید و محل کار مشتری را در راحت ترین نقاط ایجاد کنید.

با گذشت زمان، جزایر کوچک شبکه های دانشگاهی، دولتی و شرکتی گسترش یافتند و در سیستم های منطقه ای و ملی ادغام شدند. و سپس پخش کننده اصلی در صحنه ظاهر شد - اینترنت.

مداحی های ستایش آمیز در مورد شبکه جهانی وب از دیرباز محل متداول انتشارات در موضوعات رایانه ای بوده است. در واقع، اینترنت نقشی محوری در توسعه محاسبات توزیع شده ایفا کرده است و این حوزه نسبتاً خاص توسعه نرم افزار را به تمرکز ارتش برنامه نویسان حرفه ای تبدیل کرده است. امروزه به طور قابل توجهی استفاده از برنامه های کاربردی توزیع شده را گسترش می دهد و به کاربران راه دور اجازه می دهد تا متصل شوند و عملکردهای برنامه را در همه جا در دسترس قرار دهند.

این تاریخچه موضوع است. حالا بیایید نگاهی به برنامه های توزیع شده بیندازیم.

پارادایم محاسبات توزیع شده

یک کارخانه نسبتاً بزرگ، شرکت تجاری یا ارائه دهنده خدمات را تصور کنید. همه بخش های آنها قبلاً پایگاه داده و نرم افزار خاص خود را دارند. دفتر مرکزی به نوعی اطلاعات مربوط به فعالیت های جاری این بخش ها را جمع آوری می کند و اطلاعاتی را در اختیار مدیران قرار می دهد که بر اساس آن تصمیمات مدیریتی اتخاذ می کنند.

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

در شرایط توصیف شده، تنها متاسف شدن برای رئیس بخش فناوری اطلاعات باقی می ماند که وی از قبل از ایجاد یک سیستم کلی برای مدیریت جریان های تجاری مراقبت نکرده باشد، زیرا بدون آن، اطمینان از توسعه موثر بسیار دشوار خواهد بود. سازمان. علاوه بر این، نمی توان بدون یک سیستم پردازش اطلاعات در سطح شرکت، طراحی شده با در نظر گرفتن بار فزاینده و همچنین مطابق با جریان های اصلی کسب و کار، انجام داد، زیرا همه بخش ها باید نه تنها وظایف خود را انجام دهند، بلکه در صورت لزوم، درخواست های سایرین را نیز پردازش کنند. بخش ها و حتی (کابوس یک مدیر پروژه!) مشتریان.

بنابراین، ما آماده هستیم تا الزامات اساسی را برای برنامه های کاربردی در مقیاس سازمانی مدرن که توسط سازماندهی فرآیند تولید دیکته شده است، تدوین کنیم.

جداسازی فضایی بخش‌های سازمان در فضا پراکنده هستند و اغلب نرم‌افزار یکپارچه ضعیفی دارند.

انطباق ساختاری نرم افزار باید به اندازه کافی ساختار اطلاعات شرکت را منعکس کند - باید با جریان های اصلی داده مطابقت داشته باشد.

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

تمام الزامات فوق برای نرم افزار در مقیاس سازمانی توسط سیستم های توزیع شده برآورده می شود - طرح توزیع محاسباتی در شکل نشان داده شده است. 1.

البته برنامه های توزیع شده عاری از نقص نیستند. اولاً کار با آنها پرهزینه است و ثانیاً ایجاد چنین برنامه هایی فرآیندی پر زحمت و پیچیده است و هزینه خطا در مرحله طراحی بسیار بالا است. با این وجود، توسعه برنامه های کاربردی توزیع شده به خوبی در حال پیشرفت است - بازی ارزش شمع را دارد، زیرا چنین نرم افزاری به بهبود کارایی سازمان کمک می کند.

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

سیستم های محاسباتی توزیع شده دارای ویژگی های مشترکی مانند:

· مدیریت پذیری - به توانایی سیستم برای کنترل مؤثر اجزای آن اشاره دارد. این امر از طریق استفاده از نرم افزار کنترل به دست می آید.

· عملکرد - به دلیل امکان توزیع مجدد بار روی سرورهای سیستم با استفاده از نرم افزار کنترل ارائه می شود.

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

· توسعه پذیری - اجزای جدید (نرم افزار سرور) با عملکردهای جدید را می توان به برنامه های کاربردی توزیع شده اضافه کرد.

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

برنج. 2. سطوح اصلی معماری یک برنامه کاربردی توزیع شده

ویژگی های ذکر شده سیستم های توزیع شده دلیل کافی برای تحمل پیچیدگی توسعه آنها و هزینه بالای نگهداری است.

معماری کاربردی توزیع شده

معماری یک برنامه کاربردی توزیع شده را در نظر بگیرید که به آن اجازه می دهد تا عملکردهای پیچیده و متنوعی را انجام دهد. منابع مختلف گزینه های مختلفی را برای ساخت برنامه های کاربردی توزیع شده ارائه می دهند. و همه آنها حق وجود دارند، زیرا چنین برنامه‌هایی وسیع‌ترین طیف مشکلات را در بسیاری از زمینه‌های موضوعی حل می‌کنند، و توسعه سرکوب‌ناپذیر ابزارها و فناوری‌های توسعه به بهبود مستمر فشار می‌آورد.

با این وجود، کلی ترین معماری یک برنامه کاربردی توزیع شده وجود دارد که بر اساس آن به چندین لایه منطقی، لایه های پردازش داده، تقسیم می شود. همانطور که می دانید برنامه ها برای پردازش اطلاعات طراحی شده اند و در اینجا می توانیم سه عملکرد اصلی آنها را تشخیص دهیم:

· ارائه داده ها (سطح کاربر). در اینجا کاربران برنامه می توانند داده های لازم را مشاهده کنند، درخواستی برای اجرا ارسال کنند، داده های جدید را وارد سیستم کنند یا آن را ویرایش کنند.

· پردازش داده ها (سطح متوسط، میان افزار). در این سطح، منطق تجاری برنامه متمرکز می شود، جریان داده ها کنترل می شود و تعامل بخش های برنامه سازماندهی می شود. این تمرکز تمام عملکردهای پردازش و کنترل داده در یک سطح است که مزیت اصلی برنامه های کاربردی توزیع شده در نظر گرفته می شود.

· ذخیره سازی داده ها (لایه داده). این ردیف سرور پایگاه داده است. خود سرورها، پایگاه های داده، ابزارهای دسترسی به داده ها و ابزارهای کمکی مختلف در اینجا قرار دارند.

این معماری اغلب به عنوان معماری سه لایه یا سه لایه شناخته می شود. و اغلب بر اساس این "سه نهنگ" ساختار برنامه توسعه یافته ایجاد می شود. همیشه ذکر می شود که هر سطح را می توان به چندین سطح فرعی تقسیم کرد. به عنوان مثال، سطح کاربر را می توان به رابط کاربری واقعی و قوانین اعتبارسنجی و پردازش داده های ورودی تقسیم کرد.

البته، اگر امکان تقسیم به سطوح فرعی را در نظر بگیریم، هر برنامه توزیع شده را می توان در معماری سه لایه گنجاند. اما در اینجا نمی توانیم یکی دیگر از ویژگی های ذاتی برنامه های توزیع شده را نادیده بگیریم - این مدیریت داده است. اهمیت این ویژگی بدیهی است زیرا ایجاد یک برنامه کاربردی توزیع شده در دنیای واقعی (با تمام ایستگاه های مشتری، میان افزارها، سرورهای پایگاه داده و غیره) که درخواست ها و پاسخ های خود را مدیریت نکند بسیار دشوار است. بنابراین، یک برنامه توزیع شده باید یک لایه منطقی دیگر داشته باشد - لایه مدیریت داده.

برنج. 3. توزیع منطق تجاری در سطوح یک برنامه کاربردی توزیع شده

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

بنابراین، چهار سطح اصلی معماری توزیع شده وجود دارد (شکل 2 را ببینید):

· ارائه داده ها (سطح کاربر)؛

· قوانین منطق کسب و کار (لایه پردازش داده).

· مدیریت داده ها (لایه مدیریت داده).

· ذخیره سازی داده ها (لایه ذخیره سازی داده ها).

سه سطح از چهار سطح، به استثنای سطح اول، مستقیماً در پردازش داده ها دخالت دارند و لایه ارائه داده به شما امکان تجسم و ویرایش آنها را می دهد. با کمک این لایه، کاربران داده ها را از لایه پردازش داده دریافت می کنند که به نوبه خود، اطلاعات را از مخازن بازیابی می کند و تمام تبدیل داده های لازم را انجام می دهد. پس از وارد کردن اطلاعات جدید یا ویرایش داده های موجود، جریان های داده به عقب هدایت می شوند: از رابط کاربر از طریق لایه قوانین تجاری به مخزن.

لایه دیگری - مدیریت داده - از ستون فقرات داده جدا است، اما عملکرد روان کل سیستم، مدیریت درخواست ها و پاسخ ها و تعامل بخش هایی از برنامه را تضمین می کند.

به طور جداگانه، لازم است گزینه مشاهده داده ها در حالت فقط خواندنی را در نظر بگیرید. در این حالت، لایه پردازش داده در طرح کلی انتقال داده استفاده نمی شود، زیرا نیازی به تغییر نیست. و جریان اطلاعات به خودی خود یک طرفه است - از ذخیره سازی تا سطح ارائه داده ها.

ساختار فیزیکی کاربردهای توزیع شده

حال اجازه دهید به لایه های فیزیکی برنامه های کاربردی توزیع شده بپردازیم. توپولوژی یک سیستم توزیع شده مستلزم تقسیم به چندین سرور پایگاه داده، سرورهای پردازش داده و مجموعه ای از مشتریان محلی و راه دور است. همه آنها می توانند در هر مکانی قرار گیرند: در یک ساختمان یا در قاره ای دیگر. در هر صورت، بخش هایی از یک سیستم توزیع شده باید توسط خطوط ارتباطی مطمئن و مطمئن به هم متصل شوند. در مورد سرعت انتقال داده، تا حد زیادی به اهمیت ارتباط بین دو بخش سیستم از نظر پردازش و انتقال داده و تا حدی به دور بودن آنها بستگی دارد.

توزیع منطق کسب و کار در سطوح برنامه های توزیع شده

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

سرورهای پایگاه داده نه تنها می توانند داده ها را در پایگاه داده ذخیره کنند، بلکه بخشی از منطق تجاری برنامه را در رویه های ذخیره شده، محرک ها و غیره نیز شامل می شوند.

برنامه های کاربردی مشتری همچنین می توانند قوانین پردازش داده ها را پیاده سازی کنند. اگر مجموعه قوانین حداقل باشد و عمدتاً به رویه هایی برای بررسی صحت ورود داده ها مربوط می شود، ما با یک مشتری "نازک" سر و کار داریم. از سوی دیگر، یک کلاینت ضخیم، بخش بزرگی از عملکرد برنامه را شامل می شود.

سطح پردازش داده ها در واقع برای پیاده سازی منطق تجاری برنامه در نظر گرفته شده است و تمام قوانین اساسی برای پردازش داده ها در اینجا متمرکز شده است.

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

و تمرین این نتیجه را تأیید می کند. از این گذشته ، همیشه چند قانون وجود دارد که باید در رویه های ذخیره شده سرور پایگاه داده پیاده سازی شوند ، و معمولاً انتقال برخی از عملیات اولیه با داده ها به سمت مشتری - حداقل برای جلوگیری از پردازش نادرست - راحت است. درخواست ها.

لایه نمایشی

لایه ارائه داده تنها لایه ای است که در دسترس کاربر نهایی است. این لایه ایستگاه های کاری مشتری یک برنامه کاربردی توزیع شده و نرم افزار مربوطه را شبیه سازی می کند. قابلیت های ایستگاه کاری مشتری در درجه اول توسط قابلیت های سیستم عامل تعیین می شود. بسته به نوع رابط کاربری، نرم افزارهای کلاینت به دو گروه تقسیم می شوند: کلاینت هایی که از قابلیت های رابط کاربری گرافیکی (مثلاً ویندوز) استفاده می کنند و کلاینت های وب. اما در هر صورت، برنامه مشتری باید توابع زیر را ارائه دهد:

· در حال دریافت داده ها؛

· ارائه داده ها برای مشاهده توسط کاربر.

· ویرایش داده ها.

· بررسی صحت داده های وارد شده.

· ذخیره تغییرات ایجاد شده.

· رسیدگی به استثناها و نمایش اطلاعات مربوط به خطاها برای کاربر.

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

لایه پردازش داده

لایه پردازش داده اجزایی را که منطق تجاری برنامه را پیاده سازی می کنند ترکیب می کند و واسطه ای بین لایه ارائه داده و لایه ذخیره سازی داده است. تمام داده ها از آن عبور می کنند و به دلیل حل شدن مشکل، در آن تغییراتی ایجاد می شود (شکل 2 را ببینید). وظایف این سطح شامل موارد زیر است:

· پردازش جریان های داده مطابق با قوانین تجاری.

· تعامل با لایه ارائه داده برای دریافت درخواست ها و بازگشت پاسخ ها.

· تعامل با لایه ذخیره سازی داده ها برای ارسال درخواست و دریافت پاسخ.

اغلب، لایه پردازش داده با میان افزار یک برنامه کاربردی توزیع شده برابر می شود. این وضعیت برای یک سیستم "ایده آل" و فقط تا حدی برای کاربردهای واقعی کاملاً صادق است (شکل 3 را ببینید). در مورد دومی، میان‌افزار برای آنها دارای بخش زیادی از قوانین پردازش داده است، اما برخی از آنها در سرورهای SQL به شکل رویه‌های ذخیره شده یا تریگرها پیاده‌سازی می‌شوند و برخی در نرم‌افزار مشتری گنجانده شده‌اند.

این "تاری" منطق تجاری موجه است، زیرا به شما امکان می دهد برخی از مراحل پردازش داده ها را ساده کنید. بیایید یک مثال کلاسیک از بیانیه سفارش را در نظر بگیریم. فقط می تواند نام محصولات موجود در انبار را شامل شود. بنابراین، هنگام افزودن یک کالای خاص به سفارش و تعیین مقدار آن، باید عدد مربوطه را از باقیمانده این کالا در انبار کم کرد. بدیهی است که بهترین راه برای پیاده سازی این منطق از طریق سرور DB است - یا یک رویه ذخیره شده یا یک ماشه.

لایه مدیریت داده

لایه مدیریت داده برای اطمینان از اینکه برنامه منسجم، انعطاف‌پذیر و قابل اعتماد باقی می‌ماند، قابلیت مدرن‌سازی و مقیاس‌بندی را دارد، مورد نیاز است. اجرای وظایف سیستم را تضمین می کند، بدون آن، بخش هایی از برنامه (سرورهای پایگاه داده، سرورهای برنامه، میان افزار، مشتریان) قادر به تعامل با یکدیگر نخواهند بود و اتصالات شکسته شده در طول افزایش بار قابل بازیابی نیستند.

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

به عنوان مثال، یک سرویس تمبر زمان، تمام قسمت های یک برنامه کاربردی را با مهرهای زمانی سیستمی ارائه می دهد که آنها را همگام نگه می دارد. تصور کنید که یک برنامه توزیع شده دارای یک سرور است که وظایف را با یک مهلت مشخص برای مشتریان ارسال می کند. در صورت از دست رفتن مهلت، باید با محاسبه زمان تاخیر، کار ثبت شود. اگر ایستگاه های کاری مشتری در همان ساختمان سرور یا در یک خیابان مجاور واقع شوند، مشکلی نیست، الگوریتم حسابداری ساده است. اما اگر مشتریان در مناطق زمانی مختلف - در کشورهای دیگر یا حتی خارج از کشور - واقع شوند، چه؟ در این حالت، سرور باید بتواند تفاوت را با در نظر گرفتن مناطق زمانی هنگام ارسال کارها و دریافت پاسخ ها محاسبه کند و مشتریان باید اطلاعات سرویس مربوط به زمان محلی و منطقه زمانی را به گزارش ها اضافه کنند. اگر یک سرویس زمانی واحد در یک برنامه توزیع شده گنجانده شود، این مشکل به سادگی وجود ندارد.

علاوه بر سرویس یک بار مصرف، لایه مدیریت داده می تواند شامل خدماتی برای ذخیره اطلاعات عمومی (اطلاعات در مورد برنامه به طور کلی)، تولید گزارش های کلی و غیره باشد.

بنابراین، توابع لایه مدیریت داده عبارتند از:

· مدیریت بخش های یک برنامه کاربردی توزیع شده.

· مدیریت ارتباطات و کانال های ارتباطی بین بخش های برنامه.

· کنترل جریان داده بین مشتریان و سرورها و بین سرورها.

· کنترل بار.

· پیاده سازی خدمات سیستمی اپلیکیشن.

لازم به ذکر است که اغلب لایه مدیریت داده ها بر اساس راه حل های آماده ارائه شده به بازار نرم افزار توسط سازندگان مختلف ایجاد می شود. اگر توسعه دهندگان معماری CORBA را برای برنامه خود انتخاب کرده باشند، آنگاه شامل یک کارگزار درخواست شی (ORB) می شود، اگر پلتفرم ویندوز باشد، ابزارهای مختلفی در خدمت خود دارند: فناوری COM + (توسعه فناوری مایکروسافت تراکنش سرور، MTS)، فناوری پردازش صف‌های پیام MSMQ، فناوری Microsoft BizTalk و غیره.

لایه ذخیره سازی داده ها

لایه ذخیره سازی سرورهای SQL و پایگاه های داده مورد استفاده توسط برنامه را گرد هم می آورد. این راه حل برای وظایف زیر ارائه می دهد:

· ذخیره سازی داده ها در پایگاه داده و نگهداری آنها در حالت کار.

· پردازش درخواست های سطح پردازش داده ها و بازگشت نتایج.

· اجرای بخشی از منطق تجاری یک برنامه کاربردی توزیع شده.

· مدیریت پایگاه های داده توزیع شده با استفاده از ابزارهای مدیریتی سرورهای پایگاه داده.

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

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

اتصال به پایگاه داده های SQL Server در درجه اول با نرم افزار سرویس گیرنده سرور انجام می شود. علاوه بر این، می‌توان از فناوری‌های مختلف دسترسی به داده استفاده کرد، به عنوان مثال ADO (ActiveX Data Objects) یا ADO.NET. اما هنگام طراحی یک سیستم، باید در نظر گرفت که فناوری های دسترسی متوسط ​​به داده ها به سطح ذخیره سازی داده ها تعلق ندارند.

پسوندهای سطح پایه

سطوح فوق از معماری برنامه های توزیع شده پایه هستند. آنها ساختار برنامه ایجاد شده را به عنوان یک کل تشکیل می دهند، اما در عین حال، البته، نمی توانند اجرای هیچ برنامه ای را ارائه دهند - حوزه های موضوعی و وظایف بسیار گسترده و متنوع هستند. برای چنین مواردی، معماری یک برنامه کاربردی توزیع شده را می توان با لایه های اضافی که برای منعکس کردن ویژگی های برنامه در حال ایجاد طراحی شده اند، گسترش داد.

در میان سایر موارد، دو مورد از رایج ترین پسوندهای سطح پایه وجود دارد.

لایه رابط تجاری بین لایه رابط کاربری و لایه پردازش داده قرار دارد. جزئیات ساختار و اجرای قوانین تجاری لایه پردازش داده را از برنامه های مشتری پنهان می کند و انتزاعی از کد برنامه برنامه مشتری را از ویژگی های پیاده سازی منطق برنامه ارائه می دهد.

در نتیجه، توسعه دهندگان برنامه های مشتری از مجموعه خاصی از عملکردهای ضروری استفاده می کنند - آنالوگ یک رابط برنامه نویسی برنامه (API). این امر باعث می شود که نرم افزار مشتری از اجرای لایه پردازش داده مستقل باشد.

البته، هنگام ایجاد تغییرات جدی در سیستم، نمی توانید بدون تغییرات جهانی انجام دهید، اما سطح رابط تجاری به شما اجازه می دهد تا این کار را انجام ندهید مگر اینکه کاملاً ضروری باشد.

لایه دسترسی به داده ها بین لایه ذخیره سازی داده و لایه پردازش داده قرار دارد. این به شما امکان می دهد ساختار برنامه را مستقل از یک فناوری ذخیره سازی داده خاص کنید. در چنین مواردی، اشیاء نرم‌افزار لایه پردازش داده‌ها درخواست‌ها را ارسال می‌کنند و با استفاده از ابزارهای فناوری دسترسی به داده انتخابی، پاسخ‌ها را دریافت می‌کنند.

هنگام پیاده‌سازی برنامه‌ها بر روی پلتفرم ویندوز، بیشتر از همه از فناوری دسترسی به داده‌های ADO استفاده می‌شود، زیرا راهی جهانی برای دسترسی به منابع داده‌ای متنوع - از سرورهای SQL گرفته تا صفحات گسترده، فراهم می‌کند. برای برنامه های کاربردی در پلت فرم دات نت، از فناوری ADO.NET استفاده می شود.

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

معماری سیستم توزیع شده در شکل 13.1 نشان داده شده است. هر کامپیوتر نشان داده شده در شکل، یک واحد مستقل متشکل از یک CPU، حافظه و تجهیزات جانبی است. مدل خراب نمی‌شود حتی اگر رایانه یک سیستم فایل محلی ندارد: باید دستگاه‌های جانبی برای برقراری ارتباط با ماشین‌های دیگر داشته باشد و همه فایل‌های متعلق به آن را می‌توان در رایانه دیگری قرار داد. حافظه فیزیکی موجود برای هر ماشین مستقل از فرآیندهای در حال اجرا در ماشین های دیگر است. از این نظر، سیستم‌های توزیع‌شده با سیستم‌های چندپردازنده‌ای جفت‌شده محکم که در فصل قبل مورد بحث قرار گرفت، تفاوت دارند. بر این اساس، هسته سیستم در هر ماشین مستقل از شرایط عملیاتی خارجی محیط توزیع شده عمل می کند.

شکل 13.1. مدل سیستم معماری توزیع شده

سیستم های توزیع شده، که به خوبی در ادبیات توضیح داده شده اند، به طور سنتی در دسته های زیر قرار می گیرند:

سیستم های جانبی، که گروهی از ماشین ها هستند که اشتراک مشخصی دارند و با یک ماشین (معمولا بزرگتر) مرتبط هستند. پردازنده های جانبی بار خود را با پردازنده مرکزی به اشتراک می گذارند و تمام تماس های سیستم عامل را به آن ارسال می کنند. هدف یک سیستم جانبی افزایش عملکرد کلی شبکه و ارائه توانایی تخصیص یک پردازنده به یک فرآیند واحد در یک محیط عملیاتی یونیکس است. سیستم به عنوان یک ماژول جداگانه راه اندازی می شود. برخلاف سایر مدل‌های سیستم‌های توزیع‌شده، سیستم‌های جانبی استقلال واقعی ندارند، مگر در مواردی که مربوط به توزیع فرآیند و تخصیص حافظه محلی است.

سیستم های توزیع شده مانند "نیوکاسل"، امکان ارتباط از راه دور را با نام فایل های راه دور در کتابخانه (نام از مقاله "اتصال نیوکاسل" گرفته شده است - ببینید). فایل های حذف شده دارای یک BOM (نام متمایز) هستند که در مسیر جستجو، شامل کاراکترهای خاص یا یک جزء نام اختیاری است که قبل از ریشه سیستم فایل قرار دارد. اجرای این روش مستلزم ایجاد تغییراتی در هسته سیستم نیست و بنابراین ساده‌تر از سایر روش‌های مورد بحث در این فصل است، اما انعطاف‌پذیری کمتری دارد.

سیستم‌های توزیع‌شده کاملاً شفاف هستند، که در آن نام‌های متمایز استاندارد برای ارجاع به فایل‌های موجود در ماشین‌های دیگر کافی است. تشخیص این فایل ها به عنوان حذف شده به عهده هسته است. مسیرهای جستجوی فایل مشخص شده در نام ترکیبی آنها از مرزهای ماشین در نقاط اتصال عبور می کنند، مهم نیست که چه تعداد از چنین نقاطی در هنگام نصب سیستم های فایل بر روی دیسک ها تشکیل می شود.

در این فصل به معماری هر مدل می پردازیم. تمام اطلاعات ارائه شده بر اساس نتایج پیشرفت های خاص نیست، بلکه بر اساس اطلاعات منتشر شده در مقالات فنی مختلف است. این فرض می‌کند که ماژول‌های پروتکل و درایورهای دستگاه مسئول آدرس‌دهی، مسیریابی، کنترل جریان، و تشخیص و تصحیح خطا هستند - به عبارت دیگر، هر مدل مستقل از شبکه مورد استفاده است. مثال‌های استفاده از توابع سیستم که در بخش بعدی برای سیستم‌های جانبی نشان داده شده‌اند به روشی مشابه برای سیستم‌هایی مانند نیوکاسل و برای سیستم‌های کاملا شفاف کار می‌کنند که بعداً مورد بحث قرار خواهد گرفت. بنابراین، یک بار آنها را به تفصیل در نظر خواهیم گرفت و در بخش هایی که به انواع دیگر سیستم ها اختصاص داده شده است، عمدتاً بر روی ویژگی هایی تمرکز می کنیم که این مدل ها را از سایرین متمایز می کند.

13.1 پردازنده های جانبی

معماری سیستم جانبی در شکل 13.2 نشان داده شده است. هدف این پیکربندی بهبود عملکرد کلی شبکه با تخصیص مجدد فرآیندهای در حال اجرا بین CPU و پردازنده های جانبی است. هر یک از پردازنده های جانبی هیچ دستگاه جانبی محلی دیگری به جز مواردی که برای ارتباط با واحد پردازش مرکزی نیاز دارد، در اختیار ندارد. فایل سیستم و تمامی دستگاه ها در اختیار پردازنده مرکزی می باشد. فرض کنید که تمام فرآیندهای کاربر بر روی پردازنده محیطی اجرا می شوند و بین پردازنده های جانبی حرکت نمی کنند. پس از انتقال به پردازنده، تا زمان تکمیل روی آن باقی می مانند. پردازنده جانبی شامل یک نسخه سبک از سیستم عامل است که برای رسیدگی به تماس های محلی به سیستم، مدیریت وقفه، تخصیص حافظه، کار با پروتکل های شبکه و با درایور دستگاه برای ارتباط با پردازنده مرکزی طراحی شده است.

هنگامی که سیستم بر روی پردازنده مرکزی راه اندازی می شود، هسته سیستم عامل محلی را از طریق خطوط ارتباطی روی هر یک از پردازنده های جانبی بارگذاری می کند. هر فرآیندی که در حاشیه اجرا می شود با یک فرآیند ماهواره ای متعلق به پردازنده مرکزی مرتبط است (نگاه کنید به). هنگامی که یک فرآیند در حال اجرا بر روی یک پردازنده جانبی، یک تابع سیستم را فراخوانی می کند که فقط به خدمات پردازنده مرکزی نیاز دارد، فرآیند جانبی با ماهواره خود ارتباط برقرار می کند و درخواست برای پردازش به پردازنده مرکزی ارسال می شود. فرآیند ماهواره ای یک عملکرد سیستمی را انجام می دهد و نتایج را به پردازنده محیطی ارسال می کند. رابطه بین یک فرآیند جانبی و ماهواره آن شبیه به رابطه مشتری-سرور است که در فصل 11 به تفصیل در مورد آن بحث کردیم: فرآیند جانبی به عنوان مشتری ماهواره خود عمل می کند که از عملکردهای کار با سیستم فایل پشتیبانی می کند. در این حالت، فرآیند سرور راه دور تنها یک مشتری دارد. در بخش 13.4 ما به فرآیندهای سرور با چندین مشتری نگاه خواهیم کرد.

شکل 13.2. پیکربندی سیستم جانبی

شکل 13.3. فرمت های پیام

هنگامی که یک فرآیند جانبی یک تابع سیستم را که می تواند به صورت محلی پردازش شود فراخوانی می کند، هسته نیازی به ارسال درخواست به فرآیند ماهواره ای ندارد. بنابراین، برای مثال، برای به دست آوردن حافظه اضافی، یک فرآیند می تواند تابع sbrk را برای اجرای محلی فراخوانی کند. با این حال، اگر به خدمات پردازنده مرکزی، به عنوان مثال، برای باز کردن یک فایل نیاز باشد، هسته اطلاعات مربوط به پارامترهای ارسال شده به تابع فراخوانی شده و شرایط اجرای فرآیند را در یک پیام ارسال شده به فرآیند ماهواره ای رمزگذاری می کند (شکل 13.3). این پیام شامل علامتی است که از آن نتیجه می‌شود که عملکرد سیستم توسط فرآیند ماهواره‌ای از طرف مشتری انجام می‌شود، پارامترهای ارسال شده به تابع و داده‌های موجود در محیط اجرای فرآیند (به عنوان مثال، کدهای شناسایی کاربر و گروه)، که عبارتند از: برای عملکردهای مختلف متفاوت است. باقیمانده پیام داده های با طول متغیر است (به عنوان مثال، نام فایل مرکب یا داده هایی که باید با تابع نوشتن نوشته شود).

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

برای توضیح نحوه عملکرد سیستم جانبی، تعدادی عملکرد را در نظر بگیرید: getppid، open، write، fork، exit و signal. تابع getppid بسیار ساده است زیرا با فرم‌های درخواست و پاسخ ساده که بین دستگاه جانبی و CPU رد و بدل می‌شوند، سروکار دارد. هسته روی پردازنده محیطی پیامی تولید می کند که دارای علامت است که از آن نتیجه می شود که تابع درخواستی تابع getppid است و درخواست را به پردازنده مرکزی ارسال می کند. فرآیند ماهواره ای روی پردازنده مرکزی پیام را از پردازنده جانبی می خواند، نوع عملکرد سیستم را رمزگشایی می کند، آن را اجرا می کند و شناسه والد آن را به دست می آورد. سپس یک پاسخ تولید می کند و آن را به یک فرآیند جانبی معلق در انتهای دیگر خط ارتباطی منتقل می کند. هنگامی که پردازنده محیطی پاسخی را دریافت می کند، آن را به فرآیندی که تابع سیستم getppid نامیده می شود، ارسال می کند. اگر فرآیند جانبی داده ها (مانند شناسه پردازش والد) را در حافظه محلی ذخیره کند، به هیچ وجه نیازی به برقراری ارتباط با همراه خود نخواهد داشت.

اگر تابع سیستم باز فراخوانی شود، فرآیند جانبی پیامی را به همراه خود ارسال می کند که شامل نام فایل و سایر پارامترها است. در صورت موفقیت آمیز بودن، فرآیند همراه یک شاخص و نقطه ورودی را به جدول فایل اختصاص می دهد، یک ورودی را در جدول توصیف کننده فایل کاربر در فضای خود اختصاص می دهد و توصیفگر فایل را به فرآیند جانبی برمی گرداند. در تمام این مدت، در انتهای دیگر خط ارتباطی، فرآیند محیطی منتظر پاسخ است. او هیچ ساختاری در اختیار ندارد که اطلاعات مربوط به پرونده باز شده را ذخیره کند. دسته بازگردانده شده توسط open نشانگر ورودی در جدول توصیف کننده فایل کاربر متعلق به فرآیند همراه است. نتایج اجرای تابع در شکل 13.4 نشان داده شده است.

شکل 13.4. فراخوانی تابع باز از یک فرآیند جانبی

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

تنها عملکردی که باید هنگام اجرا بر روی CPU تغییر کند، عملکرد سیستم فورک است. هنگامی که یک فرآیند این عملکرد را بر روی CPU اجرا می کند، هسته یک پردازنده جانبی را برای آن انتخاب می کند و پیامی را به یک فرآیند خاص - سرور می فرستد و به دومی اطلاع می دهد که قرار است فرآیند فعلی را تخلیه کند. با فرض اینکه سرور درخواست را پذیرفته است، هسته از فورک برای ایجاد یک فرآیند محیطی جدید استفاده می کند و یک ورودی جدول پردازش و فضای آدرس را اختصاص می دهد. پردازنده مرکزی یک کپی از فرآیند را که تابع فورک نامیده می شود را به پردازنده محیطی بارگذاری می کند، فضای آدرس جدید اختصاص داده شده را بازنویسی می کند، یک ماهواره محلی برای ارتباط با فرآیند جدید محیطی ایجاد می کند و پیامی به دستگاه جانبی ارسال می کند تا شمارنده برنامه را مقداردهی اولیه کند. برای فرآیند جدید فرآیند ماهواره ای (روی CPU) از نسل فرآیندی است که فورک نامیده می شود. یک فرآیند جانبی از نظر فنی یک نسل از فرآیند سرور است، اما از نظر منطقی این فرآیند از نسل فرآیندی است که تابع فورک نامیده می شود. هنگام تکمیل فورک، فرآیند سرور هیچ ارتباط منطقی با کودک ندارد. تنها وظیفه سرور کمک به تخلیه بار کودک است. به دلیل ارتباط قوی بین اجزای سیستم (پردازنده های جانبی استقلال ندارند)، فرآیند محیطی و فرآیند ماهواره ای دارای کد شناسایی یکسان هستند. رابطه بین فرآیندها در شکل 13.5 نشان داده شده است: خط پیوسته رابطه والد-فرزند را نشان می دهد و خط نقطه چین رابطه بین همسالان را نشان می دهد.

شکل 13.5. اجرای تابع فورک در CPU

هنگامی که یک فرآیند عملکرد فورک را در پردازنده جانبی اجرا می کند، پیامی را به ماهواره خود در CPU ارسال می کند، که سپس کل توالی اقداماتی که در بالا توضیح داده شد را اجرا می کند. ماهواره یک پردازنده محیطی جدید را انتخاب می کند و مقدمات لازم را برای تخلیه تصویر فرآیند قدیمی انجام می دهد: درخواستی را برای خواندن تصویر خود به فرآیند محیطی مادر ارسال می کند که در پاسخ به آن انتقال داده های درخواستی از انتهای دیگر آغاز می شود. از کانال ارتباطی ماهواره تصویر ارسال شده را می خواند و آن را روی نوادگان محیطی بازنویسی می کند. هنگامی که آپلود تصویر کامل شد، ماهواره پردازش را فورک می کند، فرزند خود را روی CPU ایجاد می کند و مقدار شمارنده برنامه را به فرزند جانبی منتقل می کند تا دومی بداند اجرا را از کجا شروع کند. بدیهی است که بهتر است فرزند فرآیند همراه به عنوان والد به فرزند جانبی اختصاص داده شود، اما در مورد ما، فرآیندهای تولید شده قادر به اجرا بر روی سایر پردازنده‌های جانبی هستند، نه فقط پردازنده‌ای که روی آن ایجاد شده‌اند. رابطه بین فرآیندها در انتهای تابع فورک در شکل 13.6 نشان داده شده است. هنگامی که فرآیند جانبی کار خود را به پایان می رساند، یک پیام مربوطه را به فرآیند ماهواره ارسال می کند و آن نیز به پایان می رسد. یک فرآیند همراه نمی تواند خاموش شدن را آغاز کند.

شکل 13.6. اجرای یک تابع فورک در یک پردازنده جانبی

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

هنگامی که یک فرآیند جانبی عملکرد سیستم سیگنال را فراخوانی می کند، اطلاعات فعلی را در جداول محلی ذخیره می کند و پیامی به ماهواره خود ارسال می کند که به آن اطلاع می دهد که آیا سیگنال مشخص شده باید دریافت شود یا نادیده گرفته شود. رهگیری سیگنال یا عملکرد پیش فرض برای فرآیند ماهواره فرقی نمی کند. واکنش یک فرآیند به یک سیگنال به سه عامل بستگی دارد (شکل 13.7): آیا سیگنالی در حین اجرای یک عملکرد سیستمی می رسد، آیا با استفاده از تابع سیگنال نشانه ای برای نادیده گرفتن سیگنال ایجاد می شود یا خیر، آیا سیگنال روی سیگنال رخ می دهد یا خیر. همان پردازنده جانبی یا روی برخی دیگر. بیایید به بررسی احتمالات مختلف بپردازیم.

الگوریتم sighandle / * الگوریتم پردازش سیگنال * /

اگر (فرایند فعلی همراه کسی باشد یا نمونه اولیه داشته باشد)

اگر (سیگنال نادیده گرفته شود)

اگر (سیگنال در حین اجرای یک عملکرد سیستم آمده است)

یک سیگنال در مقابل فرآیند ماهواره قرار دهید.

ارسال یک پیام سیگنال به یک فرآیند جانبی؛

else (/ * فرآیند جانبی * /

/ * آیا سیگنالی در حین اجرای یک عملکرد سیستم دریافت شده است یا خیر * /

ارسال سیگنال به فرآیند ماهواره؛

الگوریتم satellite_end_of_sycall / * خاتمه یک عملکرد سیستم که توسط یک فرآیند جانبی فراخوانی می شود * /

اطلاعات ورودی: وجود ندارد

اطلاعات خروجی: هیچ

اگر (یک وقفه در حین اجرای یک تابع سیستم دریافت شد)

ارسال پیام وقفه، سیگنال به فرآیند جانبی؛

else / * اجرای عملکرد سیستم قطع نشد * /

ارسال یک پاسخ: فعال کردن پرچم نشان دهنده رسیدن یک سیگنال.

شکل 13.7. پردازش سیگنال در سیستم جانبی

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

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

2. اگر فرآیند دستور داده شده که این نوع سیگنال را نادیده بگیرد، ماهواره به دنبال الگوریتم اجرای عملکرد سیستم بدون خروج از حالت تعلیق توسط longjmp ادامه می‌دهد. در پاسخی که به فرآیند جانبی ارسال می شود، هیچ پیام دریافتی سیگنالی وجود نخواهد داشت.

3. اگر با دریافت سیگنال، فرآیند ماهواره در اجرای عملکرد سیستم (با longjmp) وقفه ایجاد کند، این موضوع را به فرآیند پیرامونی اطلاع داده و شماره سیگنال را به آن اطلاع می دهد.

فرآیند محیطی در پاسخ دریافتی اطلاعات مربوط به دریافت سیگنال ها را جستجو می کند و در صورت وجود، سیگنال ها را قبل از خروج از عملکرد سیستم پردازش می کند. بنابراین، رفتار یک فرآیند در یک سیستم چند پردازنده دقیقاً با رفتار آن در یک سیستم تک پردازنده مطابقت دارد: یا بدون خروج از حالت هسته خارج می شود، یا یک تابع پردازش سیگنال سفارشی را فراخوانی می کند، یا سیگنال را نادیده می گیرد و عملکرد سیستم را با موفقیت کامل می کند.

شکل 13.8. وقفه در حین اجرای یک عملکرد سیستم

برای مثال، فرض کنید که یک فرآیند جانبی یک تابع خواندن را از یک پایانه متصل به پردازنده مرکزی فراخوانی می کند و در حالی که فرآیند ماهواره ای عملکرد را انجام می دهد، کار خود را متوقف می کند (شکل 13.8). اگر کاربر کلید break را فشار دهد، هسته CPU سیگنالی را به فرآیند ماهواره ارسال می کند. اگر ماهواره در حالت تعلیق بود و منتظر بخشی از داده ها از ترمینال بود، بلافاصله از این حالت خارج می شود و عملکرد خواندن را خاتمه می دهد. در پاسخ به درخواست یک فرآیند جانبی، ماهواره کد خطا و شماره سیگنال مربوط به وقفه را گزارش می کند. فرآیند محیطی پاسخ را تحلیل می کند و از آنجایی که پیام می گوید وقفه رسیده است، سیگنال را به خود می فرستد. قبل از خروج از تابع خواندن، هسته محیطی سیگنال‌دهی را بررسی می‌کند، سیگنال وقفه را از فرآیند ماهواره تشخیص می‌دهد و آن را طبق معمول پردازش می‌کند. اگر در نتیجه دریافت سیگنال وقفه، فرآیند محیطی با استفاده از عملکرد خروجی کار خود را خاتمه دهد، این عملکرد از نابودی فرآیند ماهواره ای مراقبت می کند. اگر فرآیند محیطی سیگنال‌های وقفه را قطع کند، تابع مدیریت سیگنال تعریف‌شده توسط کاربر را فراخوانی می‌کند و پس از خروج از تابع خواندن، کد خطا را به کاربر برمی‌گرداند. از سوی دیگر، اگر ماهواره عملکرد سیستم آمار را از طرف فرآیند محیطی اجرا کند، هنگام دریافت سیگنال، اجرای آن را قطع نمی کند (عملکرد آمار تضمین می شود که از هر مکثی خارج شود، زیرا زمان انتظار منابع محدودی دارد. ). ماهواره اجرای عملکرد را کامل می کند و شماره سیگنال را به فرآیند محیطی برمی گرداند. فرآیند محیطی سیگنالی را به خود می فرستد و آن را در خروجی از عملکرد سیستم دریافت می کند.

اگر سیگنالی در پردازشگر محیطی در حین اجرای یک عملکرد سیستم رخ دهد، فرآیند محیطی در تاریکی خواهد بود که آیا به زودی به کنترل از فرآیند ماهواره ای باز می گردد یا دومی به حالت تعلیق برای مدت نامحدودی می رود. فرآیند محیطی یک پیام ویژه به ماهواره می فرستد و آن را از وقوع یک سیگنال مطلع می کند. هسته روی CPU پیام را رمزگشایی می کند و سیگنالی را به ماهواره می فرستد که واکنش آن به دریافت سیگنال در پاراگراف های قبلی توضیح داده شده است (خاتمه غیرعادی اجرای عملکرد یا به پایان رساندن آن). فرآیند محیطی نمی تواند مستقیماً به ماهواره پیام ارسال کند زیرا ماهواره مشغول انجام یک عملکرد سیستم است و داده ها را از خط ارتباطی نمی خواند.

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

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

هنگامی که یک فرآیند جانبی سیگنالی را به سایر فرآیندهای جانبی ارسال می کند، یک پیام تماس کشتن را رمزگذاری می کند و آن را به فرآیند ماهواره ای می فرستد، که تابع فراخوانی شده را به صورت محلی اجرا می کند. اگر بخشی از فرآیندهایی که سیگنال برای آنها در نظر گرفته شده است بر روی سایر پردازنده های جانبی قرار داشته باشد، ماهواره های آنها سیگنال را دریافت خواهند کرد (و همانطور که در بالا توضیح داده شد به آن واکنش نشان می دهند).

13.2 ارتباط نیوکاسل

در بخش قبل، ما یک نوع سیستم محکم جفت شده را در نظر گرفتیم که مشخصه آن ارسال تمام تماس‌ها به عملکردهای زیرسیستم مدیریت فایل است که در پردازنده محیطی به یک پردازنده از راه دور (مرکزی) ایجاد می‌شود. اکنون به بررسی سیستم‌هایی با اتصال ضعیف‌تر می‌پردازیم که از ماشین‌هایی تشکیل شده‌اند که با فایل‌های موجود در دستگاه‌های دیگر تماس برقرار می‌کنند. برای مثال، در شبکه‌ای از رایانه‌های شخصی و ایستگاه‌های کاری، کاربران اغلب به فایل‌هایی که روی یک دستگاه بزرگ قرار دارند دسترسی دارند. در دو بخش بعدی به پیکربندی‌های سیستمی می‌پردازیم که در آن کلیه عملکردهای سیستم در زیرسیستم‌های محلی انجام می‌شوند، اما در عین حال امکان دسترسی به فایل‌هایی (از طریق توابع زیرسیستم مدیریت فایل) واقع در سایر ماشین‌ها وجود دارد.

این سیستم ها از یکی از دو مسیر زیر برای شناسایی فایل های پاک شده استفاده می کنند. در برخی از سیستم‌ها، یک کاراکتر خاص به نام فایل ترکیبی اضافه می‌شود: جزء نامی که قبل از این کاراکتر قرار دارد، دستگاه را مشخص می‌کند، بقیه نام فایل روی آن ماشین است. بنابراین، برای مثال، نام متمایز

"sftig! / fs1 / mjb / rje"

فایل "/ fs1 / mjb / rje" را در ماشین "sftig" شناسایی می کند. این طرح شناسایی فایل از قرارداد uucp برای انتقال فایل ها بین سیستم های یونیکس پیروی می کند. در طرحی دیگر، فایل های حذف شده با افزودن یک پیشوند خاص به نام شناسایی می شوند، به عنوان مثال:

/../sftig/fs1/mjb/rje

که در آن "/../" پیشوندی است که نشان می دهد فایل حذف شده است. جزء دوم نام فایل نام دستگاه راه دور است. این طرح از نحو نام آشنای فایل یونیکس استفاده می کند، بنابراین بر خلاف طرح اول، برنامه های کاربر نیازی به تطبیق با استفاده از نام هایی با ساختار غیر معمول ندارند (نگاه کنید به).

شکل 13.9. فرمول بندی درخواست ها به سرور فایل (پردازنده)

ما بقیه این بخش را به مدلی از یک سیستم با استفاده از پیوند نیوکاسل اختصاص خواهیم داد، که در آن هسته مربوط به تشخیص فایل های حذف شده نیست. این تابع به طور کامل به زیربرنامه های کتابخانه استاندارد C اختصاص داده شده است که در این مورد نقش رابط سیستم را بازی می کنند. این زیر روال ها اولین جزء نام فایل را تجزیه و تحلیل می کنند که در هر دو روش شناسایی شرح داده شده حاوی نشانه ای از دور بودن فایل است. این یک انحراف از روال است که در آن روال های کتابخانه نام فایل ها را تجزیه نمی کنند. شکل 13.9 نشان می دهد که چگونه درخواست ها به یک سرور فایل فرموله می شوند. اگر فایل محلی باشد، هسته سیستم محلی درخواست را به طور معمول پردازش می کند. حالت مخالف را در نظر بگیرید:

باز کردن ("/../ sftig / fs1 / mjb / rje / file"، O_RDONLY);

زیر روال باز از کتابخانه C دو جزء اول نام فایل را تجزیه می کند و می داند که فایل را در ماشین راه دور "sftig" جستجو کند. به منظور داشتن اطلاعاتی در مورد اینکه آیا فرآیند قبلاً با یک ماشین خاص ارتباط داشته است یا خیر، زیربرنامه ساختار خاصی را شروع می کند که در آن این واقعیت را به خاطر می آورد و در صورت پاسخ منفی، با فایل سرور در حال اجرا بر روی کنترل از راه دور ارتباط برقرار می کند. دستگاه. هنگامی که فرآیند اولین درخواست خود را برای پردازش از راه دور فرموله می کند، سرور راه دور درخواست را تأیید می کند، در صورت لزوم، در فیلدهای کدهای شناسایی کاربر و گروه ثبت می کند و یک فرآیند ماهواره ای ایجاد می کند که از طرف فرآیند مشتری عمل می کند.

برای برآورده ساختن درخواست های مشتری، ماهواره باید همان مجوزهای فایل را در دستگاه راه دور داشته باشد که مشتری. به عبارت دیگر، کاربر "mjb" باید حقوق دسترسی یکسانی به فایل های راه دور و محلی داشته باشد. متأسفانه، ممکن است کد شناسایی کلاینت "mjb" با کد شناسایی مشتری دیگر در دستگاه راه دور مطابقت داشته باشد. بنابراین، مدیران سیستم در ماشین‌هایی که روی یک شبکه کار می‌کنند باید اطمینان حاصل کنند که به هر کاربر یک کد شناسایی اختصاص داده شده است که برای کل شبکه منحصر به فرد است، یا در زمان فرمول‌بندی درخواست خدمات شبکه، تبدیل کد را انجام دهند. اگر این کار انجام نشود، فرآیند همراه حقوق مشتری دیگری را در دستگاه راه دور خواهد داشت.

موضوع حساس تر، به دست آوردن حقوق ابرکاربر در رابطه با کار با فایل های راه دور است. از یک طرف، مشتری ابرکاربر نباید حقوق یکسانی بر روی سیستم راه دور داشته باشد تا کنترل های امنیتی سیستم راه دور را گمراه نکند. از سوی دیگر، برخی از برنامه ها، اگر حقوق ابرکاربر به آنها اعطا نشود، به سادگی قادر به کار نخواهند بود. نمونه ای از چنین برنامه ای برنامه mkdir است (به فصل 7 مراجعه کنید)، که یک دایرکتوری جدید ایجاد می کند. سیستم راه دور به کلاینت اجازه نمی دهد که دایرکتوری جدیدی ایجاد کند، زیرا امتیازات superuser در هنگام حذف اعمال نمی شود. مشکل ایجاد دایرکتوری های راه دور دلیلی جدی برای بازنگری عملکرد سیستم mkdir در جهت گسترش قابلیت های آن در برقراری خودکار کلیه اتصالات لازم برای کاربر است. با این حال، هنوز یک مشکل رایج است که برنامه‌های setuid (مانند برنامه mkdir) حقوق superuser را بر روی فایل‌های حذف شده به دست می‌آورند. شاید بهترین راه حل برای این مشکل تنظیم ویژگی های اضافی برای فایل هایی باشد که دسترسی به آنها توسط ابرکاربران راه دور را توصیف می کند. متأسفانه، این امر مستلزم تغییراتی در ساختار فهرست دیسک (از نظر افزودن فیلدهای جدید) است و باعث ایجاد آشفتگی بیش از حد در سیستم های موجود می شود.

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

مکانیسم انجام عملیات روی فهرست فعلی پیچیده تر است. هنگامی که فرآیند یک فهرست راه دور را به عنوان فهرست فعلی انتخاب می کند، روال کتابخانه پیامی به ماهواره می فرستد که دایرکتوری فعلی را تغییر می دهد و روال به یاد می آورد که دایرکتوری حذف شده است. در تمام مواردی که نام مسیر جستجو با کاراکتری به غیر از اسلش رو به جلو (/) شروع می‌شود، برنامه فرعی نام را به دستگاه راه دور می‌فرستد، جایی که فرآیند ماهواره آن را از فهرست فعلی هدایت می‌کند. اگر دایرکتوری فعلی محلی باشد، روال به سادگی نام مسیر جستجو را به هسته سیستم محلی منتقل می کند. عملکرد سیستم chroot در دایرکتوری راه دور مشابه است، اما برای هسته محلی مورد توجه قرار نمی گیرد. به طور دقیق، فرآیند می تواند این عملیات را نادیده بگیرد، زیرا فقط کتابخانه اجرای آن را ثبت می کند.

وقتی فرآیندی فورک را فرا می‌خواند، روال کتابخانه مناسب پیام‌هایی را به هر ماهواره ارسال می‌کند. پردازش‌های ماهواره‌ها منشعب می‌شوند و شناسه‌های فرزند خود را برای مشتری والد ارسال می‌کنند. فرآیند مشتری عملکرد سیستم فورک را اجرا می کند، که کنترل را به فرزندی که ایجاد می کند منتقل می کند. کودک محلی با کودک ماهواره ای راه دور که آدرس هایش توسط روال کتابخانه ذخیره می شود در گفتگو است. این تفسیر از عملکرد فورک کنترل فایل های باز و دایرکتوری های فعلی را برای فرآیندهای ماهواره ای آسان تر می کند. هنگامی که فرآیند کار با فایل های راه دور خارج می شود (با فراخوانی تابع خروج)، زیربرنامه پیام هایی را به همه ماهواره های راه دور خود ارسال می کند تا آنها نیز هنگام دریافت پیام، همین کار را انجام دهند. جنبه های خاصی از اجرای عملکردهای سیستم exec و exit در تمرینات مورد بحث قرار می گیرد.

مزیت پیوند نیوکاسل این است که دسترسی یک فرآیند به فایل های راه دور "شفاف" (برای کاربر نامرئی) می شود و هیچ تغییری در هسته سیستم لازم نیست. با این حال، این توسعه دارای معایبی است. اول از همه، در طول اجرای آن، کاهش عملکرد سیستم امکان پذیر است. به دلیل استفاده از کتابخانه توسعه یافته C، اندازه حافظه استفاده شده توسط هر فرآیند افزایش می یابد، حتی اگر فرآیند به فایل های راه دور دسترسی نداشته باشد. کتابخانه توابع کرنل را کپی می کند و به فضای حافظه بیشتری برای خود نیاز دارد. افزایش اندازه فرآیندها دوره راه اندازی را طولانی تر می کند و می تواند کشمکش بیشتری برای منابع حافظه ایجاد کند و شرایطی را برای بارگیری و صفحه بندی مکرر کارها ایجاد کند. درخواست‌های محلی به دلیل افزایش مدت زمان هر تماس با هسته، کندتر اجرا می‌شوند و پردازش درخواست‌های راه دور نیز می‌تواند کند شود، هزینه ارسال آنها از طریق شبکه افزایش می‌یابد. پردازش اضافی درخواست‌های راه دور در سطح کاربر، تعداد سوئیچ‌های زمینه، عملیات تخلیه و تعویض را افزایش می‌دهد. در نهایت، برای دسترسی به فایل های راه دور، برنامه ها باید با استفاده از کتابخانه های جدید دوباره کامپایل شوند. برنامه های قدیمی و ماژول های شی تحویل داده شده بدون آن نمی توانند با فایل های راه دور کار کنند. تمام این معایب در سیستم توضیح داده شده در بخش بعدی وجود ندارد.

13.3 سیستم های فایل توزیع شده "شفاف".

اصطلاح "تخصیص شفاف" به این معنی است که کاربران در یک ماشین می توانند بدون اینکه متوجه شوند در حال عبور از مرزهای ماشین هستند به فایل های روی ماشین دیگر دسترسی پیدا کنند، درست همانطور که در ماشین خود وقتی از یک سیستم فایل به سیستم دیگر می روند و نقاط نصب را طی می کنند، انجام می دهند. نام‌هایی که فرآیندها به فایل‌های موجود در ماشین‌های راه دور اشاره می‌کنند مشابه نام فایل‌های محلی است: هیچ کاراکتر متمایزی در آنها وجود ندارد. در پیکربندی نشان داده شده در شکل 13.10، دایرکتوری "/ usr / src" متعلق به ماشین B در دایرکتوری "/ usr / src" متعلق به ماشین A "نصب" شده است. همان کد منبع سیستم، به طور سنتی در "/ یافت می شود. پوشه usr / src". کاربرانی که روی ماشین A اجرا می‌کنند می‌توانند با استفاده از نحو آشنای نوشتن نام فایل‌ها (به عنوان مثال: "/usr/src/cmd/login.c") به فایل‌های واقع در ماشین B دسترسی پیدا کنند و خود هسته تصمیم می‌گیرد که فایل از راه دور یا محلی باشد. . کاربرانی که روی ماشین B کار می کنند به فایل های محلی خود دسترسی دارند (غافل از اینکه کاربران ماشین A می توانند به همان فایل ها دسترسی داشته باشند)، اما به نوبه خود به فایل های موجود در ماشین A دسترسی ندارند. البته گزینه های دیگری نیز امکان پذیر است. به ویژه، سیستم‌هایی که در آن‌ها همه سیستم‌های راه دور در ریشه سیستم محلی نصب شده‌اند، به طوری که کاربران به همه فایل‌ها در همه سیستم‌ها دسترسی داشته باشند.

شکل 13.10. سیستم های فایل پس از نصب از راه دور

شباهت‌های بین نصب فایل‌سیستم‌های محلی و اجازه دسترسی به فایل‌سیستم‌های راه دور، انطباق تابع mount با فایل‌سیستم‌های راه دور را برانگیخته است. در این مورد، هسته یک جدول نصب با فرمت توسعه یافته در اختیار دارد. با اجرای تابع mount، هسته یک اتصال شبکه را با یک ماشین راه دور سازماندهی می کند و اطلاعات مشخص کننده این اتصال را در جدول mount ذخیره می کند.

یک مشکل جالب مربوط به نام مسیرهایی است که شامل "..." است. اگر فرآیندی دایرکتوری فعلی را از یک سیستم فایل راه دور بسازد، استفاده از کاراکترهای ".." در نام، فرآیند را به جای دسترسی به فایل‌های بالای فهرست فعلی، به سیستم فایل محلی برمی‌گرداند. با بازگشت دوباره به شکل 13.10، توجه داشته باشید که وقتی فرآیند متعلق به ماشین A، قبلاً دایرکتوری فعلی "/ usr / src / cmd" واقع در سیستم فایل راه دور را انتخاب کرده باشد، دستور را اجرا می کند.

دایرکتوری فعلی، دایرکتوری ریشه متعلق به ماشین A خواهد بود، نه ماشین B. الگوریتم namei که در هسته سیستم راه دور اجرا می شود، پس از دریافت دنباله کاراکترهای ".."، بررسی می کند که آیا فرآیند فراخوانی عاملی از فرآیند مشتری، و اگر چنین است، تنظیم می‌کند، آیا کلاینت با دایرکتوری فعلی کار به عنوان ریشه سیستم فایل راه دور رفتار می‌کند.

ارتباط با یک ماشین راه دور به یکی از دو شکل انجام می شود: فراخوانی روش از راه دور یا فراخوانی عملکرد سیستم از راه دور. در شکل اول، هر رویه هسته که با ایندکس ها سروکار دارد، بررسی می کند که آیا ایندکس به یک فایل راه دور اشاره می کند یا خیر، و اگر چنین است، درخواستی را برای انجام عملیات مشخص شده به ماشین راه دور ارسال می کند. این طرح به طور طبیعی در ساختار انتزاعی پشتیبانی از سیستم های فایل با انواع مختلف، که در قسمت پایانی فصل 5 توضیح داده شده است، قرار می گیرد. بنابراین، دسترسی به یک فایل راه دور می تواند انتقال چندین پیام را از طریق شبکه آغاز کند، که تعداد آنها مشخص می شود. با تعداد عملیات ضمنی روی فایل، با افزایش متناظر در زمان پاسخ به درخواست، با در نظر گرفتن زمان انتظار پذیرفته شده در شبکه. هر مجموعه از عملیات از راه دور شامل حداقل اقدامات برای قفل کردن فهرست، شمارش مراجع و غیره است. به منظور بهبود مدل، راه حل های بهینه سازی مختلفی در رابطه با ترکیب چندین عملیات در یک پرس و جو (پیام) و بافر کردن مهم ترین داده ها (cm) پیشنهاد شد. ).

شکل 13.11. باز کردن یک فایل راه دور

فرآیندی را در نظر بگیرید که یک فایل راه دور "/usr/src/cmd/login.c" را باز می کند، جایی که "src" نقطه اتصال است. با تجزیه نام فایل (با استفاده از طرح namei-iget)، هسته تشخیص می دهد که فایل حذف شده است و درخواستی را برای دریافت ایندکس قفل شده به ماشین میزبان ارسال می کند. پس از دریافت پاسخ مورد نظر، هسته محلی یک کپی از ایندکس در حافظه مربوط به فایل راه دور ایجاد می کند. سپس کرنل با ارسال پیام دیگری به دستگاه راه دور، حقوق دسترسی لازم به فایل (مثلاً برای خواندن) را بررسی می کند. الگوریتم باز همانطور که در فصل 5 برنامه ریزی شده ادامه می یابد و در صورت نیاز پیام هایی را به دستگاه راه دور ارسال می کند تا زمانی که الگوریتم کامل شود و فهرست آزاد شود. رابطه بین ساختارهای داده هسته پس از تکمیل الگوریتم باز در شکل 13.11 نشان داده شده است.

اگر کلاینت تابع سیستم خواندن را فراخوانی کند، هسته مشتری نمایه محلی را قفل می کند، یک قفل در فهرست راه دور صادر می کند، یک درخواست خواندن، داده ها را در حافظه محلی کپی می کند، یک درخواست برای آزاد کردن فهرست راه دور صادر می کند، و فهرست محلی را آزاد می کند. . این طرح با معنایی هسته تک پردازنده موجود سازگار است، اما فرکانس استفاده از شبکه (تعداد فراخوانی به هر عملکرد سیستم) عملکرد کل سیستم را کاهش می دهد. با این حال، برای کاهش جریان پیام ها در شبکه، چندین عملیات را می توان در یک درخواست ترکیب کرد. در مثال با تابع خواندن، کلاینت می‌تواند یک درخواست کلی «خواندن» به سرور ارسال کند و خود سرور تصمیم می‌گیرد که ایندکس را هنگام اجرا بگیرد و آزاد کند. کاهش ترافیک شبکه را می توان با استفاده از بافرهای راه دور نیز به دست آورد (همانطور که در بالا توضیح دادیم)، اما باید مراقب بود که عملکرد فایل سیستم با استفاده از این بافرها به درستی اجرا شود.

در شکل دوم ارتباط با یک ماشین راه دور (تماس با یک تابع سیستم از راه دور)، هسته محلی تشخیص می دهد که عملکرد سیستم به یک فایل راه دور مرتبط است و پارامترهای مشخص شده در فراخوانی خود را به سیستم راه دور ارسال می کند، که آن را اجرا می کند. تابع و نتایج را به مشتری برمی گرداند. ماشین کلاینت نتایج اجرای تابع را دریافت کرده و از حالت فراخوانی خارج می شود. اکثر توابع سیستم را می توان تنها با استفاده از یک درخواست شبکه و دریافت پاسخ پس از یک زمان معقول انجام داد، اما همه عملکردها در این مدل قرار نمی گیرند. بنابراین، به عنوان مثال، با دریافت سیگنال های خاص، هسته یک فایل برای فرآیند به نام "core" ایجاد می کند (فصل 7). ایجاد این فایل با عملکرد سیستم خاصی مرتبط نیست، اما در نهایت به انجام چندین عملیات مانند ایجاد یک فایل، بررسی مجوزها و انجام یک سری از نوشتن ها می رسد.

در مورد تابع سیستم باز، درخواست برای اجرای تابع ارسال شده به دستگاه راه دور شامل بخشی از نام فایل باقی مانده پس از حذف اجزای نام مسیر جستجو که فایل راه دور را متمایز می کند و همچنین پرچم های مختلف است. در مثال قبلی باز کردن فایل "/usr/src/cmd/login.c"، هسته نام "cmd / login.c" را به دستگاه راه دور ارسال می کند. این پیام همچنین شامل اعتبارنامه هایی مانند کدهای شناسایی کاربر و گروه است که برای تأیید مجوزهای فایل در دستگاه راه دور مورد نیاز است. اگر پاسخی از ماشین راه دور دریافت شود که نشان دهنده عملکرد باز موفقیت آمیز است، هسته محلی یک فهرست رایگان در حافظه ماشین محلی واکشی می کند و آن را به عنوان فهرست فایل راه دور علامت گذاری می کند، اطلاعات مربوط به ماشین راه دور و فهرست راه دور را ذخیره می کند و به طور معمول تخصیص می دهد. یک ورودی جدید در جدول فایل در مقایسه با شاخص واقعی در ماشین راه دور، ایندکس متعلق به ماشین محلی رسمی است و پیکربندی مدل را نقض نمی کند، که به طور کلی با پیکربندی استفاده شده هنگام فراخوانی روش راه دور یکسان است (شکل 13.11). اگر یک تابع فراخوانی شده توسط یک فرآیند توسط توصیفگر خود به یک فایل راه دور دسترسی پیدا کند، هسته محلی از ایندکس (محلی) می داند که فایل از راه دور است، درخواستی را فرموله می کند که شامل تابع فراخوانده شده است و آن را به ماشین راه دور ارسال می کند. این درخواست حاوی یک اشاره گر به نمایه راه دور است که توسط آن فرآیند ماهواره می تواند خود فایل راه دور را شناسایی کند.

پس از دریافت نتیجه اجرای هر عملکرد سیستم، هسته می‌تواند برای پردازش آن به خدمات یک برنامه خاص متوسل شود (پس از اتمام آن هسته کار با تابع را به پایان می‌رساند)، زیرا پردازش محلی نتایج در یک سیستم تک‌پردازنده استفاده می‌شود. همیشه برای سیستمی با چندین پردازنده مناسب نیست. در نتیجه، تغییراتی در معنایی الگوریتم های سیستم با هدف ارائه پشتیبانی از اجرای توابع سیستم از راه دور امکان پذیر است. با این حال، در همان زمان، حداقل جریان پیام ها در شبکه در گردش است که حداقل زمان پاسخگویی سیستم به درخواست های دریافتی را تضمین می کند.

13.4 مدل توزیع شده بدون فرآیندهای انتقال

استفاده از فرآیندهای انتقال (فرآیندهای ماهواره ای) در یک سیستم توزیع شده شفاف، ردیابی فایل های حذف شده را آسان تر می کند، اما جدول فرآیند سیستم از راه دور با فرآیندهای ماهواره ای که اغلب اوقات بیکار هستند، بارگذاری می شود. در طرح‌های دیگر، از فرآیندهای سرور ویژه برای پردازش درخواست‌های راه دور استفاده می‌شود (و را ببینید). سیستم راه دور دارای مجموعه ای (پول) از فرآیندهای سرور است که هر از گاهی برای پردازش درخواست های راه دور دریافتی اختصاص می دهد. پس از پردازش درخواست، پردازش سرور به pool باز می گردد و وارد حالت آماده برای پردازش سایر درخواست ها می شود. سرور زمینه کاربر را بین دو تماس حفظ نمی‌کند، زیرا می‌تواند درخواست‌های چندین فرآیند را همزمان پردازش کند. بنابراین، هر پیامی که از فرآیند مشتری می‌آید باید شامل اطلاعاتی در مورد محیط اجرای آن باشد، یعنی: کدهای شناسایی کاربر، دایرکتوری فعلی، سیگنال‌ها و غیره توابع.

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

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

پردازش سیگنال‌هایی که اجرای یک عملکرد سیستم را مختل می‌کنند، هنگام استفاده از سرورها نیز پیچیده است، زیرا دستگاه راه دور باید سرور مناسبی را جستجو کند که اجرای عملکرد را ارائه می‌کند. حتی ممکن است به دلیل شلوغی همه سرورها، درخواست یک تابع سیستم در حالت انتظار برای پردازش باشد. شرایط برای وقوع رقابت نیز زمانی ایجاد می شود که سرور نتیجه عملکرد سیستم را به فرآیند فراخوانی برمی گرداند و پاسخ سرور شامل ارسال پیام سیگنالینگ مربوطه از طریق شبکه است. هر پیام باید علامت گذاری شود تا سیستم راه دور بتواند آن را تشخیص دهد و در صورت لزوم، فرآیندهای سرور را خاتمه دهد. هنگام استفاده از ماهواره، فرآیندی که به انجام درخواست مشتری رسیدگی می کند، به طور خودکار شناسایی می شود و در صورت رسیدن سیگنال، بررسی اینکه آیا درخواست پردازش شده است یا خیر، دشوار نیست.

در نهایت، اگر یک تابع سیستمی که توسط کلاینت فراخوانی می‌شود، باعث توقف موقت سرور شود (مثلاً هنگام خواندن داده‌ها از یک پایانه راه دور)، سرور نمی‌تواند درخواست‌های دیگر را برای آزاد کردن مخزن سرور پردازش کند. اگر چندین فرآیند به طور همزمان به دستگاه های راه دور دسترسی داشته باشند و اگر تعداد سرورها از بالا محدود شود، یک گلوگاه کاملاً محسوس وجود دارد. این در مورد ماهواره ها اتفاق نمی افتد، زیرا یک ماهواره به هر فرآیند مشتری اختصاص داده می شود. یکی دیگر از مشکلات استفاده از سرورها برای دستگاه های راه دور در تمرین 13.14 پوشش داده خواهد شد.

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

شکل 13.12. نمودار مفهومی تعامل با فایل های راه دور در سطح هسته

13.5 نتیجه گیری

در این فصل، ما سه طرح برای کار با فایل‌های واقع در ماشین‌های راه دور در نظر گرفته‌ایم که سیستم‌های فایل راه دور را به عنوان پسوند محلی در نظر می‌گیرند. تفاوت های معماری بین این چیدمان ها در شکل 13.12 نشان داده شده است. همه آنها به نوبه خود با سیستم های چند پردازنده ای که در فصل قبل توضیح داده شد تفاوت دارند زیرا پردازنده های اینجا حافظه فیزیکی مشترک ندارند. یک سیستم پردازشگر جانبی شامل مجموعه ای از پردازنده های متصل به هم است که منابع فایل پردازنده مرکزی را به اشتراک می گذارند. یک اتصال از نوع نیوکاسل دسترسی پنهان ("شفاف") به فایل های راه دور را فراهم می کند، اما نه از طریق هسته سیستم عامل، بلکه از طریق استفاده از یک کتابخانه ویژه C. به همین دلیل تمامی برنامه هایی که قصد استفاده از این نوع لینک را دارند باید مجددا کامپایل شوند که به طور کلی ایراد جدی این طرح است. دور بودن یک فایل با استفاده از یک توالی خاص از کاراکترها نشان داده می شود که ماشینی را که فایل در آن قرار دارد را توصیف می کند، و این عامل دیگری است که قابلیت حمل برنامه ها را محدود می کند.

در سیستم‌های توزیع‌شده شفاف، برای دسترسی به فایل‌های راه دور از تغییر عملکرد سیستم mount استفاده می‌شود. نمایه‌های سیستم محلی به عنوان فایل‌های راه دور علامت‌گذاری می‌شوند و هسته محلی پیامی را به سیستم راه دور ارسال می‌کند که عملکرد سیستم درخواستی، پارامترهای آن و فهرست راه دور را توصیف می‌کند. ارتباط در یک سیستم توزیع شده "شفاف" به دو شکل پشتیبانی می شود: به صورت تماس با روش راه دور (پیامی به دستگاه راه دور ارسال می شود که حاوی لیستی از عملیات مرتبط با شاخص است) و در قالب یک تماس. به یک عملکرد سیستم از راه دور (پیام عملکرد درخواستی را توصیف می کند). بخش پایانی فصل مسائل مربوط به پردازش درخواست های راه دور با استفاده از فرآیندها و سرورهای ماهواره ای را مورد بحث قرار می دهد.

13.6 تمرین

*1. پیاده سازی عملکرد سیستم خروج را در یک سیستم با پردازنده های جانبی شرح دهید. چه تفاوتی بین این مورد و زمانی که فرآیند با دریافت یک سیگنال کشف نشده خارج می شود چیست؟ هسته چگونه باید محتویات حافظه را تخلیه کند؟

2. فرآیندها نمی توانند سیگنال های SIGKILL را نادیده بگیرند. توضیح دهید که وقتی فرآیند چنین سیگنالی را دریافت می کند در سیستم جانبی چه اتفاقی می افتد.

* 3. پیاده سازی عملکرد سیستم exec را در سیستمی با پردازنده های جانبی توصیف کنید.

*4. پردازنده مرکزی چگونه باید فرآیندها را بین پردازنده های جانبی توزیع کند تا بار کلی را متعادل کند؟

*5. چه اتفاقی می افتد اگر پردازنده جانبی حافظه کافی برای تطبیق تمام فرآیندهای بارگذاری شده روی آن نداشته باشد؟ تخلیه و تعویض فرآیندها در شبکه چگونه باید انجام شود؟

6. سیستمی را در نظر بگیرید که در صورت یافتن پیشوند خاصی در نام فایل، درخواست ها به یک سرور فایل راه دور ارسال می شود. اجازه دهید فرآیند execl را فراخوانی کند ("/../ sftig / bin / sh، "sh"، 0); فایل اجرایی روی یک ماشین راه دور است، اما باید در سیستم محلی اجرا شود. نحوه انتقال ماژول راه دور به سیستم محلی را توضیح دهید.

7. اگر مدیر نیاز به اضافه کردن ماشین های جدید به یک سیستم موجود با اتصالی مانند نیوکاسل داشته باشد، بهترین راه برای اطلاع رسانی به ماژول های کتابخانه C در این مورد چیست؟

*هشت در طول اجرای تابع exec، هسته فضای آدرس فرآیند را بازنویسی می‌کند، از جمله جداول کتابخانه‌ای که پیوند نیوکاسل برای ردیابی پیوندها به فایل‌های راه دور استفاده می‌کند. پس از اجرای تابع، فرآیند باید توانایی دسترسی به این فایل ها را توسط توصیفگرهای قدیمی خود حفظ کند. اجرای این نکته را شرح دهید.

*نه. همانطور که در بخش 13.2 نشان داده شده است، فراخوانی عملکرد سیستم خروج در سیستم‌هایی با اتصال نیوکاسل منجر به ارسال پیامی به فرآیند همراه می‌شود که دومی را مجبور به خاتمه می‌کند. این کار در سطح روتین های کتابخانه انجام می شود. وقتی یک پردازش محلی سیگنالی دریافت می کند که به آن می گوید در حالت هسته خارج شود چه اتفاقی می افتد؟

*ده در سیستمی با پیوند نیوکاسل، که در آن فایل‌های راه دور با پیشوند نام با یک پیشوند خاص شناسایی می‌شوند، چگونه یک کاربر با تعیین «..» (دایرکتوری والد) به عنوان مؤلفه نام فایل، می‌تواند از نقطه اتصال راه دور عبور کند؟

11. ما از فصل 7 می دانیم که سیگنال های مختلف باعث می شوند که فرآیند محتویات حافظه را به فهرست فعلی تخلیه کند. اگر دایرکتوری فعلی از سیستم فایل راه دور باشد چه اتفاقی باید بیفتد؟ اگر سیستم از رابطه ای مانند نیوکاسل استفاده کند چه پاسخی خواهید داد؟

*12. اگر تمام فرآیندهای ماهواره یا سرور از سیستم حذف شوند، چه پیامدهایی برای فرآیندهای محلی خواهد داشت؟

*13. نحوه پیاده سازی الگوریتم پیوند در یک سیستم توزیع شده شفاف را در نظر بگیرید که پارامترهای آن می تواند دو نام فایل راه دور و همچنین الگوریتم exec باشد که با انجام چندین عملیات خواندن داخلی مرتبط است. دو شکل ارتباط را در نظر بگیرید: فراخوانی رویه از راه دور و فراخوانی عملکرد سیستم از راه دور.

*چهارده. هنگام دسترسی به دستگاه، فرآیند سرور می تواند وارد حالت تعلیق شود که توسط درایور دستگاه از آن خارج می شود. طبیعتاً اگر تعداد سرورها محدود باشد، سیستم دیگر نمی تواند درخواست های ماشین محلی را برآورده کند. یک طرح قابل اعتماد ارائه کنید که به موجب آن همه فرآیندهای سرور در حالی که منتظر تکمیل I/O مربوط به دستگاه هستند، به حالت تعلیق در نمی آیند. عملکرد سیستم زمانی که همه سرورها مشغول هستند خاتمه نمی یابد.

شکل 13.13. پیکربندی سرور ترمینال

*15. هنگامی که کاربر وارد سیستم می شود، رشته خط ترمینال اطلاعاتی را ذخیره می کند که ترمینال یک پایانه اپراتور است که گروهی از فرآیندها را هدایت می کند. به همین دلیل، هنگامی که کاربر کلید "شکست" را روی صفحه کلید ترمینال فشار می دهد، تمام پردازش های گروه سیگنال وقفه را دریافت می کنند. پیکربندی سیستمی را در نظر بگیرید که در آن تمام پایانه ها به صورت فیزیکی به یک ماشین متصل هستند، اما ثبت نام کاربر به طور منطقی روی ماشین های دیگر پیاده سازی می شود (شکل 13.13). در هر مورد، سیستم یک فرآیند getty برای ترمینال راه دور ایجاد می کند. اگر درخواست‌های یک سیستم راه دور توسط مجموعه‌ای از فرآیندهای سرور پردازش می‌شوند، توجه داشته باشید که وقتی روال باز اجرا می‌شود، سرور منتظر اتصال متوقف می‌شود. هنگامی که عملکرد باز کامل شد، سرور به استخر سرور باز می گردد و اتصال خود را به ترمینال قطع می کند. سیگنال وقفه چگونه با فشردن کلید "break" به آدرس های فرآیندهای موجود در همان گروه ارسال می شود؟

*16. اشتراک گذاری حافظه یک ویژگی ذاتی در ماشین های محلی است. از نقطه نظر منطقی، تخصیص یک منطقه مشترک از حافظه فیزیکی (محلی یا راه دور) می تواند برای فرآیندهای متعلق به ماشین های مختلف انجام شود. اجرای این نکته را شرح دهید.

* 17. الگوریتم‌های صفحه‌بندی و صفحه‌بندی فرآیند که در فصل 9 مورد بحث قرار گرفتند، استفاده از یک پیجر محلی را فرض می‌کنند. چه تغییراتی باید در این الگوریتم ها اعمال شود تا بتوان از دستگاه های تخلیه از راه دور پشتیبانی کرد؟

*هجده. فرض کنید یک تصادف مرگبار در ماشین راه دور (یا در شبکه) رخ می دهد و پروتکل لایه شبکه محلی این واقعیت را ثبت می کند. یک طرح بازیابی برای یک سیستم محلی ایجاد کنید که درخواست هایی را به یک سرور راه دور ارسال می کند. علاوه بر این، یک طرح بازیابی برای سیستم سروری که ارتباط خود را با مشتریان از دست داده است، ایجاد کنید.

*19. هنگامی که یک فرآیند به یک فایل راه دور دسترسی پیدا می کند، این امکان وجود دارد که فرآیند چندین ماشین را در جستجوی فایل طی کند. نام "/ usr / src / uts / 3b2 / os" را به عنوان مثال در نظر بگیرید، جایی که "/ usr" دایرکتوری متعلق به ماشین A است، "/ usr / src" نقطه اتصال ریشه ماشین B است، " / usr / src / uts / 3b2 "نقطه سوار شدن ریشه ماشین C است. راه رفتن از طریق چندین ماشین به مقصد نهایی "multihop" نامیده می شود. با این حال، اگر یک اتصال شبکه مستقیم بین ماشین‌های A و C وجود داشته باشد، ارسال داده از طریق ماشین B ناکارآمد خواهد بود. ویژگی های اجرای «چند خرید» را در یک سیستم با اتصال نیوکاسل و در یک سیستم توزیع شده «شفاف» توضیح دهید.

بر اساس محیط محاسباتی چند خط لوله قابل تنظیم مجدد L-Net

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

این راه‌حل‌ها استفاده کارآمد از منابع پایه‌های اضافی، فنی و نرم‌افزاری را فراهم نمی‌کنند، که بر تحمل خطا و مقیاس‌پذیری چنین راه‌حل‌هایی تأثیر منفی می‌گذارد. اگر معماری شبکه نقض شود، امکان پیکربندی مجدد پویا هر دو فرآیند پردازش اطلاعات و انتقال جریان های داده (هم کنترل و هم اطلاعات) وجود ندارد. استفاده از میکروکنترلرهای خاص، استفاده از DCS / SCADA توسعه و پشتیبانی سیستم ها، گسترش عملکرد آنها را پیچیده می کند.

معماری سیستم کنترل توزیع شده

معماری معمولی تعمیم یافته یک سیستم کنترل توزیع شده (DCS) شامل سه سطح مرتبط سلسله مراتبی است: سطح اپراتور، سطح کنترل و سطح I/O (به شکل 1 مراجعه کنید).

وظیفه اصلی سطح اپراتور ارائه یک رابط انسان و ماشین (HMI) برای اطمینان از پیکربندی و کنترل عملکرد کل سیستم است. سطح کنترل مسئول دریافت و پردازش داده ها از حسگرها، انتقال داده ها به سطح اپراتور و توسعه اقدامات کنترلی بر روی محرک ها است. سطح I/O نشان دهنده حسگرها و محرک هایی است که مستقیماً به جسم کنترل شده متصل هستند.

وظیفه نرم افزار، در چارچوب معماری تعمیم یافته DCS، اطمینان از عملکرد سطح اپراتور و ارتباط آن با سطح کنترل سیستم است. در نتیجه، سطح اساسی در طراحی نرم افزار و حل مسائل مربوط به تعامل آن با سخت افزار، سطح اپراتور است. نرم افزار باید از منابع سخت افزاری موجود سیستم حداکثر استفاده را ببرد در حالی که تا حد امکان مستقل از معماری داخلی سخت افزار باشد.

سخت افزار منابع محاسباتی، حافظه و رسانه های ارتباطی را بین گره های یک سیستم فراهم می کند. هنگام طراحی معماری کلی سیستم، گره های خاص سطح I/O که در یک پیاده سازی خاص به آن متصل خواهند شد در نظر گرفته نمی شوند، بنابراین در معماری تعمیم یافته، سطح اپراتور و سطح کنترل در نظر گرفته می شود. سخت افزار باید گسترده باشد، با استانداردهای مدرن مطابقت داشته باشد و تمام ویژگی ها و قابلیت های لازم برای اجرای معماری را داشته باشد.

الزامات DCS

الزامات DCS نه تنها برای سیستم به عنوان یک کل اعمال می شود، بلکه برای اجزای سخت افزاری و نرم افزاری آن نیز به طور جداگانه اعمال می شود، زیرا رویکردهای خاص برای برآوردن این الزامات برای این اجزا می تواند اساساً متفاوت باشد. DCS باید قبل از هر چیز قابل تحمل خطا باشد. ساده‌ترین روش افزایش تحمل خطا، افزونگی (تکثیر) واحدهای عملکردی یا مجموع آنها است. دومین ویژگی مهم مقیاس پذیری است. مقیاس پذیری مبتنی بر پیاده سازی الگوریتم های خاص در نرم افزار و توانایی سخت افزاری برای جایگزینی و افزودن گره های جدید یا اجزای آنهاست. در عین حال، سیستم باید برای عملکرد خود، توسعه گره ها یا ماژول های جدید و اصلاح معماری آن ساده بماند.

نمای کلی معماری DCS

برای بررسی معماری‌های DCS، Siemens SIMATIC PCS 7 DCS را به عنوان یکی از پرتقاضاترین در بازار و RTS S3 را به عنوان DCS پیاده‌سازی شده بر اساس QNX RTOS انتخاب کردیم.

زیمنس SIMATIC PCS 7

معماری سیستم تمام خصوصیات معماری DCS عمومی را دارد. ایستگاه های اپراتور رایانه هایی بر اساس معماری پردازنده x86 با سیستم عامل ویندوز و بسته WinCC زیمنس هستند که HMI را ارائه می دهد. سرورهایی با پایگاه داده وجود دارد. ایستگاه های اپراتور، ایستگاه های مهندسی و سرورها توسط یک شبکه محلی مبتنی بر اترنت به هم متصل می شوند. سطح اپراتور به صفحه کنترل شبکه اترنت صنعتی اضافی متصل است. در سطح کنترل، کنترل کننده های منطقی قابل برنامه ریزی (PLC) با امکان افزونگی به دلیل عملکردهای تکراری وجود دارد. امکان اتصال به سیستم ها و شبکه های خارجی و سازماندهی دسترسی از راه دور به سیستم وجود دارد.

RTS S3

این معماری به طور مشابه از لایه های ساختار تعمیم یافته DCS تشکیل شده است. ایستگاه های اپراتور بر اساس همان پلت فرم سخت افزاری SIMATIC DCS هستند، اما می توانند تحت هر دو سیستم عامل ویندوز و لینوکس کار کنند. ایستگاه های مهندسی با ایستگاه های اپراتور ترکیب می شوند. این سیستم یک محیط توسعه برنامه یکپارچه را فراهم می کند. اترنت با استفاده از پشته پروتکل TCP/IP، گره‌ها را در لایه حامل و خود اپراتور را با صفحه کنترلی متصل می‌کند. در سطح کنترل، کامپیوترهای صنعتی در حال اجرا سیستم عامل QNX با پایگاه داده خود و امکان افزونگی با کپی کردن عملکرد گره وجود دارد.

معایب سیستم های توصیف شده

سیستم های شرح داده شده در بالا از یک پلت فرم سخت افزاری / نرم افزاری متفاوت برای سطح اپراتور و صفحه کنترل استفاده می کنند. در سطح اپراتور، تنها یک معماری پردازنده قابل استفاده است و یک ایستگاه مهندسی ویژه برای پیکربندی و توسعه سطح کنترل مورد نیاز است. این DCSها تنها افزونگی سخت‌افزاری را با تکرار عملکرد گره اضافی به عنوان راهی برای افزایش تحمل خطا ارائه می‌دهند، که استفاده غیرمنطقی از سخت‌افزار اضافی است.

ویژگی ها و ویژگی های عملکردی سیستم L-Net

هنگام توسعه سیستم L-Net، وظیفه ایجاد یک سیستم کنترلی بود که دارای ویژگی های زیر باشد:

• پیکربندی مجدد پویا با بازیابی کامل با حداقل ضرر در صورت خرابی میزبان یا اختلال در توپولوژی شبکه.
• توزیع کارآمد وظایف بین گره های شبکه کارآمد موجود.
• تکرار کانال های ارتباطی بین گره ها با پیکربندی مجدد پویا جریان های انتقال داده.
• سهولت استفاده و مقیاس پذیری سیستم.
• قابلیت حمل و عملکرد سیستم بر روی هر پلت فرم سخت افزاری که برای سیستم های کنترل ساختمان و سیستم های تعبیه شده طراحی شده است.

برای ساختن یک سیستم با مشخصات فوق، یک سیستم عامل مورد نیاز است که در درجه اول برای ایجاد سیستم های کنترل و سیستم های تعبیه شده در نظر گرفته شده است. تجزیه و تحلیل سیستم عامل های موجود نشان داد که مناسب ترین سیستم عامل QNX 6 (نوترینو) است که تخصیص منابع و قابلیت های شبکه بسیار کارآمدی دارد. قابلیت های شبکه گسترده ای توسط پروتکل شبکه Qnet ارائه شده است. این مشکل قابلیت اطمینان و تعادل بار دینامیکی کانال های ارتباطی را حل می کند، اما مشکل تحمل خطای سیستم را به طور کلی حل نمی کند. در نتیجه، یک سیستم کنترل نوآورانه بر اساس یک محیط محاسباتی چند خط لوله قابل تنظیم مجدد توزیع شده توسعه یافت. سیستم توسعه‌یافته دارای یک معماری همتا به همتا است که شامل سه بلوک منطقی است: یک بلوک ورودی-خروجی، یک بلوک سوئیچ همه‌منظوره، و یک بلوک محیط محاسباتی قابل تنظیم مجدد (RCS) (به شکل 2 مراجعه کنید).

مزایای اصلی این معماری عبارتند از:

• نوع همتا به همتا
• عدم تمرکز
• مقیاس پذیری
• توزیع فضایی

ویژگی های کاربردی این معماری:

• پردازش داده های خط لوله
• افزونگی سخت افزاری
• توزیع بار
• پیکربندی مجدد در حین پرواز

در سطح اول معماری یک واحد ورودی-خروجی (I/O) وجود دارد که شامل: گره های ورودی-خروجی، سوئیچ گره های ورودی-خروجی، رابط ورودی-خروجی، سنسورها و محرک ها می باشد. این واحد مسئول مکانیسم های اساسی برای ایجاد اقدامات کنترلی بر اساس داده های حسگرهای محلی و داده های دریافتی از سطوح دیگر سیستم کنترل است. وظایف محول شده بین گره های I/O سالم بر اساس عملکرد نسبی فعلی آنها یا به صورت دستی توسط اپراتور توزیع می شود. حسگرها و محرک ها از طریق یک گذرگاه به تمام گره های ورودی/خروجی در بلوک متصل می شوند، که به هر گره اجازه می دهد هر سنسوری را بازجویی کند یا اثری را روی هر محرک ایجاد کند. سوئیچ گره I/O ارتباط بین تمام گره های I/O را برای تبادل داده بین آنها و سایر سطوح معماری سیستم برای به دست آوردن اطلاعات کنترل و اطلاعات فراهم می کند. با قابلیت های سخت افزاری مناسب، گره ها به طور مستقیم با یکدیگر و با گره ها و سوئیچ ها در سطوح دیگر سیستم ارتباط برقرار می کنند که باعث کاهش زمان پاسخگویی در شبکه می شود. ارتباط مستقیم بین گره ها و بار مشخصی از گره ها در حالت فعلی عملکرد بلوک I / O امکان سازماندهی محاسبات خط لوله را در بلوک لازم برای عملکرد این بلوک بدون استفاده از قدرت محاسباتی خارجی سیستم کنترل (DCS) فراهم می کند. که استفاده موثر از منابع رایگان ارائه شده برای گره های افزونگی واحد I/O را در زمان خرابی ممکن می سازد.

بلوک سوئیچ های همه منظوره، واقع در سطح دوم معماری، خطوط ارتباطی بین بلوک های ورودی-خروجی و DCS و سیستم های خارجی را سازماندهی می کند. هر سوئیچ می تواند پیوندها و سوئیچ های مختلف را در کل سیستم کنترل به هم متصل کند. تعداد خطوط ارتباطی با قابلیت های سخت افزاری گره ها و سوئیچ های موجود در بلوک ها تعیین می شود. از آنجایی که شبکه Qnet به شما امکان توزیع پویا جریان های داده را می دهد، مقیاس بندی این بلوک به سادگی با اتصال دستگاه های جدید انجام می شود و نیازی به پیکربندی ندارد و در صورت خرابی یکی از سوئیچ ها، انتقال داده بین گره ها قطع نمی شود. سوییچ دیگر ارتباط مشابهی بین گره ها ایجاد می کند یا به طور مستقیم با هم مرتبط هستند. در عین حال، لازم است از پهنای باند کافی شبکه مورد نیاز برای پشتیبان گیری از یک سوئیچ ناموفق مراقبت شود.

بلوک شبکه کامپیوتری قابل تنظیم مجدد (RCN) که در سطح سوم معماری قرار دارد، سیستم مدیریت توان محاسباتی بالایی را برای حل مشکلات پیچیده پردازش اطلاعات، تصمیم گیری، تشخیص و غیره فراهم می کند. بلوک مسئول اولیه سازی کل سیستم کنترل است: بررسی عملکرد سوئیچ ها و گره ها، یکپارچگی شبکه، ساخت نمودارهای شبکه کل سیستم، تنظیم پارامترهای شروع برای عملکرد بلوک های ورودی-خروجی. گره های این بلوک هم داده های خود و هم داده های بلوک های I/O را بایگانی می کنند. هر گره از این بلوک می تواند نقش یک ماشین اپراتور را ایفا کند که برای نظارت بر عملکرد سیستم طراحی شده است و برنامه های کاری این گره و تمام گره های سیستم را تنظیم می کند و پیکربندی مجدد را در صورت تقاضا انجام می دهد.

توزیع بار

یکی از وظایف اصلی سیستم L-Net توزیع بار محاسباتی بر روی گره های شبکه است. راه حل این مشکل بر اساس ساخت خطوط لوله محاسباتی است. برای ایجاد یک خط لوله محاسباتی، یک نمودار وظیفه از ابتدا ساخته می شود - طرحی برای تبادل جریان های داده از یک منبع به یک گیرنده. حسگرها به عنوان منبع و محرک ها به عنوان گیرنده عمل می کنند. خط لوله محاسباتی خود نقشه‌برداری از نمودار وظیفه (نگاه کنید به شکل 3) بر روی نمودار شبکه کامپیوتری (نگاه کنید به شکل 4) است، با در نظر گرفتن الزامات کار به منابع محاسباتی سیستم و وضعیت فعلی آن.

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

تحمل خطا

مشکل اصلی عملکرد چنین سیستمی، اختلال کامل در خطوط لوله محاسباتی در صورت خرابی هر گره این نوار نقاله یا نقض انتقال داده بین آنها است. ابزار اصلی پروتکل Qnet به بازیابی اتصالات بین گره ها در صورت نقض جزئی آنها به دلیل خطوط پشتیبان ارائه شده توسط معماری، دست می یابد. سیستم L-Net مشکل بازیابی عملکرد را در صورت خرابی کامل میزبان سیستم محاسباتی با پیکربندی مجدد پویا خط لوله محاسباتی حل می کند. استفاده از منابع کاری برای جایگزینی بلوک بد این سیستم سه سناریو بازیابی (پیکربندی مجدد) را ارائه می دهد که از نظر زمان پاسخ به واقعیت شکست، زمان بازیابی و منابع سخت افزاری استفاده شده متفاوت است: در صورت شکست، با آمادگی غیرفعال، با آمادگی فعال.

• پیکربندی مجدد در صورت شکست- پس از تشخیص خرابی، جستجوی سخت افزار موجود و درج آن در نمودار وظیفه انجام می شود.
• پیکربندی مجدد با آمادگی غیرفعال- سخت افزار اضافی از قبل تعیین می شود، فرآیندی شروع می شود که اجرای بالای نمودار وظیفه را بر روی یک گره تضمین می کند، اتصالات برقرار می شود، اما این فرآیند داده ها را پردازش نمی کند مگر اینکه گره اصلی با شکست مواجه شود.
• پیکربندی مجدد با آمادگی فعال- بالای نمودار وظیفه بر روی چندین گره پیاده سازی شده است که پردازش داده ها را به صورت موازی انجام می دهند و نتیجه را منتقل می کنند.

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

نتیجه

سیستم توسعه‌یافته L-Net، بر خلاف آنالوگ‌های موجود، استفاده از طیف گسترده‌ای از ویژگی‌های سخت‌افزاری گره‌های DCS را با سازگاری کامل نرم‌افزاری آنها پیش‌فرض می‌گیرد. هنگامی که گره ها تحت کنترل یک سیستم عامل (QNX Neutrino) کار می کنند، می توان آنها را بر روی معماری های مختلف پردازنده (x86، ARM، MIPS و غیره) با مجموعه های مختلف رابط ها و تجهیزات جانبی ساخت. پیاده سازی گره ها در قالب رایانه های شخصی رومیزی، صنعتی، رایانه های شخصی پوشیدنی و رایانه های تک برد امکان پذیر است. تمام اجزای مجموعه نرم افزاری DCS توسعه یافته را می توان روی هر یک از گره های آن با سیستم عامل QNX راه اندازی کرد، در حالی که امکان استفاده از گره ها با سیستم عامل متفاوت وجود دارد. این رویکرد به هر گره اجازه می دهد تا برای حل وظایف در سطح اپراتور و سطح کنترل استفاده شود. در نتیجه، یک سیستم انعطاف پذیر از تعامل بین همتایان بدون سلسله مراتب سفت و سخت از سطوح ذاتی در معماری تعمیم یافته DCS و سیستم هایی که از این معماری به عنوان پایه استفاده می کنند وجود دارد. شبکه همتا به همتا فرآیندهای استقرار، عملیات، مقیاس‌بندی و اشکال‌زدایی یک سیستم را ساده می‌کند.

برای تحقق پتانسیل محاسباتی سخت افزار اضافی در سیستم توسعه یافته، الگوریتم هایی برای پیکربندی پویا و پیکربندی مجدد بر اساس پروتکل شبکه Qnet و نرم افزار شبکه L-Net پیشنهاد شده است. الگوریتم پیکربندی پویا مبتنی بر توزیع بار محاسباتی در تمام گره‌ها با خط لوله کردن و موازی کردن وظایف و متعادل کردن پویا بار در کانال‌های انتقال داده بین گره‌ها است. الگوریتم پیکربندی مجدد سیستم، بسته به سخت افزار موجود، اولویت ها و وظایف محول شده به سیستم، وجود سه سناریو برای بازیابی عملکرد در صورت خرابی را فرض می کند: در صورت شکست، با آمادگی غیرفعال (تخصیص منابع) و با آمادگی فعال (استفاده از منابع). . پیکربندی پویا و الگوریتم های پیکربندی مجدد عملکرد و قابلیت اطمینان را با استفاده از ذخایر سخت افزاری موجود در سیستم بهبود می بخشد.

مزیت مهم سیستم حداکثر شفافیت فناوری های سخت افزاری و نرم افزاری به کار رفته در آن است که امکان ساده سازی جدی پشتیبانی فنی سیستم و توسعه ماژول های جدید را برای آن فراهم می کند.

خروجی

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

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Zyl S. QNX Momentics: Application Basics. - SPb: BHV-Petersburg، 2005.
5. Krten R. مقدمه ای بر نوترینو QNX. راهنمای توسعه برنامه های کاربردی بلادرنگ. - SPb: BHV-Petersburg، 2011.

کلید واژه ها:سیستم کنترل توزیع شده، پشتیبانی اطلاعات برای سیستم های کنترل، سیستم های قابل تنظیم مجدد توزیع شده.

معماری یک سیستم کنترل توزیع شده بر اساس محیط محاسباتی چند خط لوله قابل تنظیم مجدد L-Net

سرگئی یو. پوتومسکی، استادیار دانشگاه تحقیقات ملی "مدرسه عالی اقتصاد".

نیکیتا A. Poloyko، دانشجوی سال پنجم دانشگاه ملی تحقیقات "مدرسه عالی اقتصاد". دستیار تحصیلی. برنامه نویس. زمینه آموزشی: "کنترل و انفورماتیک در سیستم های فنی".

خلاصه.این مقاله به یک سیستم کنترل توزیع شده بر اساس محیط محاسباتی چند خط لوله قابل تنظیم مجدد اختصاص دارد. معماری سیستم داده شده است. همچنین، ویژگی های اساسی و ویژگی های عملکردی سیستم نیز آورده شده است. در این مقاله دلیلی برای انتخاب سیستم عامل ارائه شده است. مزایای اساسی سیستم در مقایسه با پیشرفت های مشابه موجود در مقاله نشان داده شده است.

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

در تماس با

(مواد سایت http://se.math.spbu.ru)

معرفی.

امروزه تقریباً تمام سیستم های نرم افزاری بزرگ توزیع شده اند. سیستم توزیع شده- سیستمی که در آن پردازش اطلاعات بر روی یک کامپیوتر متمرکز نیست، بلکه بین چندین کامپیوتر توزیع می شود. هنگام طراحی سیستم های توزیع شده، که اشتراکات زیادی با طراحی نرم افزار به طور کلی دارد، هنوز باید برخی از ویژگی ها را در نظر گرفت.

شش ویژگی اصلی سیستم های توزیع شده وجود دارد.

1. به اشتراک گذاری منابع سیستم های توزیع شده امکان اشتراک گذاری منابع سخت افزاری (هارد دیسک، چاپگرها) و نرم افزاری (فایل ها، کامپایلرها) را فراهم می کنند.
2. باز بودن.این توانایی گسترش سیستم با افزودن منابع جدید است.
3. موازی سازی.در سیستم های توزیع شده، چندین فرآیند می توانند به طور همزمان بر روی کامپیوترهای مختلف در شبکه اجرا شوند. این فرآیندها می توانند در حین اجرا با هم تعامل داشته باشند.
4. مقیاس پذیری . زیر مقیاس پذیریامکان افزودن خواص و روش های جدید درک می شود.
5. تحمل خطا. وجود رایانه های متعدد امکان تکرار اطلاعات و مقاومت در برابر برخی از خطاهای سخت افزاری و نرم افزاری را فراهم می کند. سیستم های توزیع شده می توانند در صورت بروز خطا از عملکرد جزئی پشتیبانی کنند. خرابی کامل سیستم فقط با خطاهای شبکه رخ می دهد.
6. شفافیت.دسترسی کامل به منابع موجود در سیستم برای کاربران فراهم می شود، در عین حال اطلاعات مربوط به توزیع منابع در سراسر سیستم از آنها پنهان می شود.

سیستم های توزیع شده نیز دارای معایبی هستند.

1. پیچیدگی... درک و ارزیابی خصوصیات سیستم های توزیع شده به طور کلی بسیار دشوارتر است و طراحی، آزمایش و نگهداری آنها دشوارتر است. همچنین، عملکرد سیستم به سرعت شبکه بستگی دارد، نه به تک تک پردازنده ها. تخصیص مجدد منابع می تواند به طور قابل توجهی سرعت سیستم را تغییر دهد.
2. امنیت... به طور معمول، سیستم از چندین ماشین مختلف قابل دسترسی است، پیام های موجود در شبکه را می توان مشاهده و رهگیری کرد. بنابراین، در یک سیستم توزیع شده، حفظ امنیت بسیار دشوارتر است.
3. قابلیت کنترل... این سیستم می تواند از انواع مختلفی از کامپیوترها تشکیل شده باشد که نسخه های مختلف سیستم عامل را می توان روی آنها نصب کرد. خطاهای یک ماشین می تواند به روشی غیرقابل پیش بینی به ماشین های دیگر منتشر شود.
4. غیر قابل پیش بینی بودن ... واکنش سیستم های توزیع شده به برخی رویدادها غیرقابل پیش بینی است و به بار کامل سیستم، سازماندهی آن و بار شبکه بستگی دارد. از آنجایی که این پارامترها می توانند دائما تغییر کنند، بنابراین، زمان پاسخ به درخواست ممکن است به طور قابل توجهی با زمان متفاوت باشد.

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

1. شناسایی منابع ... منابع در سیستم های توزیع شده بر روی رایانه های مختلف قرار دارند، بنابراین باید سیستم نامگذاری منابع را در نظر گرفت تا کاربران بتوانند به راحتی به منابع مورد نیاز خود دسترسی داشته باشند و به آنها مراجعه کنند. یک مثال سیستم URL (Uniform Resource Locator) است که نام صفحات وب را تعریف می کند.
2. ارتباط... عملکرد جهانی اینترنت و اجرای کارآمد پروتکل های TCP / IP در اینترنت برای اکثر سیستم های توزیع شده نمونه هایی از مؤثرترین راه سازماندهی ارتباط بین رایانه ها است. با این حال، در برخی موارد که عملکرد یا قابلیت اطمینان خاصی مورد نیاز است، می توان از ابزارهای تخصصی استفاده کرد.
3. کیفیت خدمات سیستم ... این پارامتر عملکرد، سلامت و قابلیت اطمینان را منعکس می کند. تعدادی از عوامل بر کیفیت خدمات تأثیر می گذارد: توزیع فرآیندها، منابع، سخت افزار و سازگاری سیستم.
4. معماری نرم افزار ... معماری نرم افزار توزیع توابع سیستم را در بین اجزای سیستم و همچنین توزیع این اجزا در بین پردازنده ها را توصیف می کند. اگر نیاز به حفظ یک سرویس سیستم با کیفیت بالا دارید، انتخاب معماری مناسب بسیار مهم است.

چالش طراحان سیستم های توزیع شده طراحی نرم افزار و سخت افزار برای ارائه تمام ویژگی های مورد نیاز یک سیستم توزیع شده است. این امر مستلزم دانستن مزایا و معایب معماری های مختلف سیستم توزیع شده است. سه نوع معماری سیستم توزیع شده وجود دارد.

1. معماری کلاینت/سرور ... در این مدل، سیستم را می توان مجموعه ای از خدمات ارائه شده توسط سرورها به مشتریان در نظر گرفت. در چنین سیستم هایی، سرورها و کلاینت ها به طور قابل توجهی با یکدیگر تفاوت دارند.
2. معماری سه لایه ... در این مدل، سرور به طور مستقیم به مشتریان خدمات ارائه نمی کند، بلکه از طریق سرور منطق تجاری خدمات ارائه می دهد.

در مورد دو مدل اول قبلاً بیش از یک بار گفته شده است ، بیایید در مورد سوم با جزئیات بیشتری صحبت کنیم.

1. معماری اشیاء توزیع شده ... در این حالت هیچ تفاوتی بین سرورها و کلاینت ها وجود ندارد و سیستم را می توان مجموعه ای از اشیاء تعاملی در نظر گرفت که مکان آنها واقعاً مهم نیست. هیچ تفاوتی بین ارائه دهنده خدمات و کاربران آنها وجود ندارد.

این معماری امروزه بسیار مورد استفاده قرار می گیرد و همچنین نامیده می شود معماری خدمات وبوب سرویس برنامه ای است که از طریق اینترنت قابل دسترسی است و خدماتی را ارائه می دهد که شکل آنها مستقل از فروشنده است (از آنجایی که از قالب داده جهانی - XML ​​استفاده می شود) و پلت فرم عملیات. در حال حاضر، سه فناوری مختلف وجود دارد که از مفهوم سیستم های شی توزیع شده پشتیبانی می کنند. اینها فناوری های EJB، CORBA و DCOM هستند.

ابتدا چند کلمه در مورد اینکه XML به طور کلی چیست. XML یک قالب داده عمومی است که برای ارائه خدمات وب استفاده می شود. خدمات وب بر اساس استانداردها و پروتکل های باز است: SOAP، UDDI و WSDL.

1. صابون ( پروتکل دسترسی به اشیاء ساده که توسط W3C توسعه یافته است، قالبی را برای درخواست ها به سرویس های وب تعریف می کند. پیام‌های بین یک وب سرویس و کاربر آن در پاکت‌های به اصطلاح SOAP (گاهی اوقات پاکت‌های XML نیز نامیده می‌شوند) بسته‌بندی می‌شوند. خود پیام می تواند شامل درخواستی برای انجام یک عمل یا پاسخ باشد - نتیجه این عمل.
2. WSDL (زبان شرح خدمات وب).رابط وب سرویس در اسناد WSDL توضیح داده شده است (و WSDL زیرمجموعه ای از XML است). قبل از استقرار یک سرویس، توسعه‌دهنده توضیحات آن را به زبان WSDL می‌نویسد، آدرس سرویس وب، پروتکل‌های پشتیبانی‌شده، فهرستی از عملیات مجاز، و فرمت‌های درخواست و پاسخ را مشخص می‌کند.
3. UDDI (توصیف جهانی، کشف و ادغام) -پروتکل جستجوی خدمات وب اینترنت ( http://www.uddi.org/). این یک دفتر ثبت کسب و کار است که در آن ارائه دهندگان خدمات وب خدمات را ثبت می کنند و توسعه دهندگان خدماتی را که باید در برنامه های خود قرار دهند پیدا می کنند.

از صحبت‌ها، ممکن است به نظر برسد که وب سرویس‌ها بهترین راه‌حل و بی‌رقیب هستند و تنها سؤال، انتخاب ابزارهای توسعه است. با این حال، اینطور نیست. جایگزینی برای خدمات وب وجود دارد، وب معنایی، که تیم برنرز لی، خالق WWW، پنج سال پیش در مورد آن صحبت کرد.

اگر هدف خدمات وب تسهیل ارتباط بین برنامه‌ها باشد، وب معنایی برای حل یک مشکل بسیار پیچیده‌تر طراحی شده است - با استفاده از مکانیسم‌های ابرداده برای افزایش کارایی ارزش اطلاعاتی که می‌توان در وب یافت. این را می توان با کنار گذاشتن رویکرد سند گرا به نفع رویکرد شی گرا انجام داد.

کتابشناسی - فهرست کتب

1. سامرویلI. مهندسی نرم افزار.
2. Dranitsa A. Java vs. NET. - "کامپیوتررا"، شماره 516.
3. منابع اینترنتی