Управление розподіленими ресурсами

Управление розподіленими ресурсами Базові примітиви передачі повідомлень в розподілених системах.

Единственным по-справжньому важливим відзнакою розподілених систем від централізованих є межпроцессная взаємозв'язок. У централізованих системах зв’язок між процесами, зазвичай, припускає наявність поділюваної пам’яті. Типовий приклад — проблема «поставщик-потребитель », у тому разі один процес пише в поділюваний буфер, а інший — читає потім із нього. Навіть найбільш проста форма синхронізації - семафор — вимагає, хоча б одне слово (змінна самого семафори) було поділюваним. У розподілених системах немає який би не пішли поділюваної пам’яті, в такий спосіб вся природа межпроцессных комунікацій мусить бути продумана наново.

Основой цього взаємодії може служити тільки передача через мережу повідомлень. У найпростішому разі системні кошти забезпечення можуть бути було зведено до двом основним системним викликам (примітивам), один — для посилки повідомлення, інший — щоб одержати повідомлення. Надалі їхній базі може бути побудовано потужніші кошти мережевих комунікацій, такі як розподілена файлова система чи виклик віддалених процедур, які, своєю чергою, також можуть бути підвалинами побудови інших мережевих сервісів.

Несмотря на концептуальну простоту цих системних викликів — ПОСЛАТИ і ОТРИМАТИ — існують різноманітні варіанти реалізації, від правильного вибору яких залежить ефективності роботи мережі. Зокрема, ефективність комунікацій у мережі залежить від способу завдання адреси, від цього, чи є системний виклик блокуючим чи неблокирующим, які вибрано способи буферизации повідомлень і, як надійним є протокол обміну повідомленнями.

Способи адресації

Для здобуття права послати повідомлення, необхідно вказати адресу одержувача. У дуже проста мережі адресу може задаватися як константи, але в складних мережах потрібен і більше витончений спосіб адресації.

Одним з вар’янтів адресації на верхньому рівні є використання фізичних адрес мережевих адаптерів. Якщо який отримує комп’ютері виконується лише одне процес, то ядро знатиме, що робити з котрі вступили повідомленням — передати його цього процесу. Проте, якби машині виконується кілька процесів, то ядру невідомо, якого з них призначено повідомлення, тому використання мережного адреси адаптера як адреси одержувача призводить до вельми серйозного обмеження — з кожної машині повинен виконуватися лише одне процес.

Альтернативная адресна система використовує імена призначення, які з двох частин, що визначають номер машини та номер процесу. Проте адресація типу «машина-процесс «далекою від ідеалу, зокрема, вона гнучка й не прозора, оскільки користувач повинен явно ставити адресу машины-получателя. У цьому випадку, тоді як одного чудового дня машина, де працює сервер, відмовляє, то програма, у якій жорстко використовується адресу серверу, не зможе працювати з іншим сервером, встановленому в інший машині.

Другим варіантом міг стати призначення кожному процесу унікального адреси, що ніяк не пов’язані з адресою машини. Однією з способів досягнення цього є використання централізованого механізму розподілу адрес процесів, який працює просто, як лічильник. З отриманням запиту виділення адреси він повертає поточне значення лічильника, та був нарощує його за одиницю. Недоліком цієї схеми і те, що централізовані компоненти, подібні цій, не забезпечують в достатньо розширюваність систем. Ще одна метод призначення процесам унікальних ідентифікаторів залежить від вирішенні кожному процесу вибору свою власну ідентифікатора з дуже великої адресного простору, такого як простір 64-х бітних цілих чисел. Можливість вибору однієї й тієї ж числа двома процесами є некоректним, а система добре розширюється. Проте тут маємо одну проблема: як процесс-отправитель може дізнатися лише номер машини процесса-получателя. У «тенета, що підтримує широкомовний режим (то є у ній передбачено таку адресу, який приймають все мережні адаптери), відправник може широкомовно передати спеціальний пакет, який містить ідентифікатор процесу призначення. Усі ядра отримають цих повідомлень, перевірять адресу процесу, коли він збігаються з ідентифікатором однієї з процесів цієї машини, пошлють у відповідь повідомлення «Я тут », що містить мережевий адресу машини.

Хотя цю схему і прозора, але широкомовні повідомлення перевантажують систему. Такий перевантаження можна запобігти, виділивши у мережі спеціальну машину для відображення высокоуровневых символьних імен. При застосуванні такої системи процеси адресуються з допомогою символьних рядків, й у програми вставляються ці рядки, а чи не номери машин чи процесів. Щоразу перед перша спроба зв’язатися, процес має послати запит спеціальному отображающему процесу, якого зазвичай називають сервером імен, просячи номер машини, де працює процесс-получатель.

Совершенно інший підхід — це використання спеціальної апаратури. Нехай процеси вибирають свої адреси випадково, а конструкція мережевих адаптерів дозволяє зберігати ці адреси. Тепер адреси процесів не виявляються шляхом широкомовної передачі, а безпосередньо вказуються кадрів, замінюючи там адреси мережевих адаптерів.

Блокуючі і неблокирующие примітиви

Примитивы бувають блокуючими і неблокирующими, вони називаються відповідно синхронними і асинхронними. З використанням блокуючого примітиву, процес, який видав запит з його виконання, припиняється до завершення примітиву. Наприклад, виклик примітиву ОТРИМАТИ призупиняє викликає процес до одержання повідомлення.

При використанні неблокирующего примітиву управління повертається зухвалому процесу негайно, ще до його того, як необхідна робота буде виконано. Перевагою цієї схеми є паралельне виконання що викликає процесу процесу передачі повідомлення. Зазвичай, у ОС є одне із два види примітивів і дуже рідко — обидва. Проте виграш в продуктивності під час використання неблокирующих примітивів компенсується серйозним недоліком: відправник неспроможна модифікувати буфер повідомлення, поки повідомлення не відправлено, а дізнатися, відправлено сполучення, відправник не може. Звідси складності у будівництві програм, які передають послідовність повідомлень з допомогою неблокирующих примітивів.

Имеется два можливих виходу. Перше рішення — це змусити ядро копіювати повідомлення своє внутрішнє буфер, та був дозволити процесу продовжити виконання. З погляду процесу цю схему нічим не відрізняється від схеми блокуючого виклику: щойно процес знову отримує управління, може повторно використовувати буфер.

Второе рішення в перериванні процесса-отправителя після відправки повідомлення, аби поінформувати його, що буфер знову доступний. Тут не потрібно копіювання, що заощаджує час, але переривання користувальницького рівня робить програмування заплутаним, складним, можуть призвести до виникненню гонок.

Вопросом, тісно що з блокуючими і неблокирующими викликами, є питання тайм-аутов. У системі з блокуючим викликом ПОСЛАТИ за відсутності відповіді викликає процес може заблокироваться назавжди. Щоб запобігти цій ситуації у деяких системах викликає процес може поставити тимчасової інтервал, протягом якого чекає відповідь. Якщо цей час повідомлення не надходить, виклик ПОСЛАТИ завершується з кодом помилки.

Буферизуемые і небуферизуемые примітиви

Примитивы, описані, є небуферизуемыми примитивами. Це означає, що виклик ОТРИМАТИ повідомляє ядру машини, де його виконується, адресу буфера, у який варто помістити перебуває йому повідомлення.

Эта схема працює чудово за умови, що одержувач виконує виклик ОТРИМАТИ раніше, ніж відправник виконує виклик ПОСЛАТИ. Виклик ОТРИМАТИ повідомляє ядру машини, де виконується, з якого адресою має надійти очікуване повідомлення, й у який область пам’яті потрібна згода її помістити. Проблема виникає тоді, коли виклик ПОСЛАТИ зроблено раніше виклику ОТРИМАТИ. Як зможе дізнатися ядро машиною одержувача, якому процесу адресовано знову яке надійшло повідомлення, якщо їх ще кілька? І як він дізнається, де його скопіювати?

Один з вар’янтів — просто відмовитися від повідомлення, дозволити відправнику взяти тайм-аут і сподіватися, що одержувач все-таки виконає виклик ОТРИМАТИ перед повторної передачею повідомлення. Такий підхід нескладний у реалізації, але, на жаль, відправник (чи, радше ядро його машини) може зробити кілька таких безуспішних спроб. Ще гірша те, що після досить великої числа безуспішних спроб ядро відправника може зробити неправильний висновок про аварію машиною одержувача або про неправильності використаного адреси.

Второй підхід до цієї проблеми у тому, щоб зберігати хоча б якусь годину, вступники сполучення ядрі одержувача той випадок, що незабаром виконано відповідний виклик ОТРИМАТИ. Щоразу, коли надходить таке «несподіване «повідомлення, включається таймер. Якщо поставлене тимчасової інтервал минає раніше, ніж відбувається відповідний виклик ОТРИМАТИ, то повідомлення втрачається.

Хотя його зменшує ймовірність втрати повідомлень, він породжує проблему збереження і управління передчасно які надійшли повідомленнями. Необхідні буферы, які треба десь розміщувати, звільняти, загалом, які потрібно управляти. Концептуально у простий спосіб управління буферами є визначення нової структури даних, званої скринькою.

Процесс, який зацікавлений у отриманні повідомлень, звертається до ядру із запитом з приводу створення йому поштової скриньки і каже адресу, яким йому можуть надходити мережні пакети, після чого все повідомлення з цим адресою будуть перебувають у його поштову скриньку. Такий спосіб часто називають буферизуемым примітивом.

Надійні і ненадійні примітиви

Ранее передбачалося, що коли і відправник посилає повідомлення, адресат його неодмінно отримує. Але реально повідомлення можуть губитися. Припустимо, що використовуються блокуючі примітиви. Коли відправник посилає повідомлення, він призупиняє своєї роботи до того часу, поки повідомлення нічого очікувати послано. Однак жодних ґарантій, що опісля, як і відновить своєї роботи, повідомлення буде доставлено адресата.

Для розв’язання проблеми існує три підходу. Перший у тому, що систему не перебирає ніяких зобов’язань щодо доставки повідомлень. Реалізація надійного взаємодії стає повністю турботою користувача.

Второй підхід у тому, що ядро приймаючої машини посилає квитанцию-подтверждение ядру отправляющей машини кожне повідомлення. Посылающее ядро розблоковує користувальницький процес лише після отримання цього підтвердження. Підтвердження передається від ядра до ядру. Ні відправник, ні одержувач їх бачать.

Третий підхід залежить від використанні відповіді на підтвердження у його системах, у яких запит завжди супроводжується відповіддю. Відправник залишається заблокованим до відповіді. Якщо відповіді занадто довго, то посылающее ядро може переслати запит спеціальної службі запобігання втрати сообщений.