Операційні системи використовують менеджери блокувань для організації та серіалізації доступу до ресурсів Розподілений м

Операційні системи використовують менеджери блокувань для організації та серіалізації доступу до ресурсів. Розподілений менеджер блокувань (англ. Distributed lock manager, DLM) працює на кожній машині в кластері, з ідентичною копією бази даних блокувань кластера. Таким чином, DLM є пакетом програмного забезпечення, який дозволяє комп'ютерам в кластері синхронізувати свої доступи до спільно використовуваних ресурсів .

Різні реалізації DLM були використані як основа для декількох успішних кластерних файлових систем, в яких вузли кластера можна використовувати для зберігання файлів один одного за допомогою єдиної файлової системи, зі значними перевагами у плані підвищення продуктивності і доступності . Основна перевага продуктивності досягається за рахунок вирішення проблеми когерентності дискового кешу між комп'ютерами, що беруть участь в кластері. DLM використовується не тільки для блокування файлів , але і для координації всіх видів дискового доступу. VMScluster , перша система кластеризації одержала широке поширення, покладається на OpenVMS DLM саме таким чином.

Реалізація VMS

DEC VMS була першою широко доступною операційною системою, де було реалізовано DLM. Даний функціонал з'явився у версії 4, хоча інтерфейс користувача був таким же, як і у однопроцесорного менеджера блокування, якого вперше було реалізовано у версії 3.

Ресурси

DLM використовує узагальнене поняття ресурсу, як окремого об'єкта, до якого треба контролювати загальний доступ. Це може бути файл, запис, область загальної пам'яті, або щось ще, що вибрав розробник програми. Розробник сам описує ієрархію ресурсів, отже він сам визначає необхідну кількість рівнів блокування. Наприклад, гіпотетична база даних могла б описувати ієрархію ресурсів таким чином:

База даних
Таблиця
запис
поле

Таким чином процес в рамках виконання отримує можливість встановлювати необхідні блокування на базу даних в цілому (батьківський ресурс), а потім і на окремі частини бази даних (підпорядковані ресурси).

Режими блокування

Процес, що виконується в межах VMSCluster може отримати блокування ресурсу. DLM реалізує шість режимів блокування, і кожен з них визначає різні рівні ексклюзивності доступу. У процесі використання ресурсу можна перетворити рівень режиму блокування на більш високий або більш низький. Коли усі процеси розблокують ресурс, інформація про ресурсі знищується.

Null (NL). Вказує інтерес до ресурсу, але не заважає іншим процесам замикаючи його. Цей режим надає зручний механізм створення ресурсу та збереження його значення блоку блокування зберігаються, навіть якщо жоден процес не замикає його.
Паралельне читання (Concurrent Read, CR). Вказує на намір читати (але не оновлювати) ресурс. Це дозволяє іншим процесам читати або оновлювати ресурс, але не дозволяє іншим отримувати ексклюзивний доступ до нього. Цей режим, як правило, використовується на ресурсах високого рівня ієрархії, враховуючи те, що більш жорсткі блокування можуть бути отримані для підлеглих йому ресурсів.
Одночасний запис (Concurrent Write, CW). Вказує на намір читати і оновлювати ресурс. Цей режим також дозволяє іншим процесам читати або оновлювати ресурс, але не дозволяє іншим отримувати ексклюзивний доступ до нього. Цей режим, також використовується на ресурсах високого рівня ієрархії, враховуючи те, що більш жорсткі блокування можуть бути отримані для дочірніх ресурсів.
Захищене читання (Protected Read, PR). Це традиційний режим спільної блокування, який вказує на бажання читати ресурс, але не дозволяє іншим оновлювати його вміст. Інші процеси, однак, також можуть прочитати вміст ресурсу.
Захищена запис (Write Protected, PW). Це традиційний режим блокування оновлення, який вказує на бажання читати і оновлювати ресурс і не дозволяє іншим користувачам оновлювати його. Інші процеси можуть отримувати режим доступу «Паралельне читання» і можуть прочитати ресурс.
Exclusive (EX). Це традиційний режим ексклюзивного блокування, якій дозволяє читати та оновлювати доступ до ресурсу, і не дозволяє іншим процесам мати доступ до нього.

Наступна таблиця істинності показує сумісність кожного режиму блокування з іншими:

Mode	NL	CR	CW	PR	PW	EX
NL	Так	Так	Так	Так	Так	Так
CR	Так	Так	Так	Так	Так	Ні
CW	Так	Так	Так	Ні	Ні	Ні
PR	Так	Так	Ні	Так	Ні	Ні
PW	Так	Так	Ні	Ні	Ні	Ні
EX	Так	Ні	Ні	Ні	Ні	Ні

Отримання блокування

Процес може заблокувати ресурс з допомогою постановки в чергу запиту блокування. Цей механізм схожий на ^[en] — технологію VMS, яка використовується для виконання операцій введення/виводу. Запит блокування може виконуватися або повністю синхронно, в цьому випадку процес чекає, поки блокування не видається, або асинхронно, і в цьому випадку спрацьовує механізм ^[en] (англ. AST) , коли буде отримана блокування.

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

Блок значення блокування

Блок значення блокування пов'язаний з кожним ресурсом. Він може бути прочитаний при отриманні будь-якого виду блокування (крім блокування NULL) і його може бути поновлено за допомогою процесу, який отримав блокування ресурсу рівня PW або EX.

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

Визначення ситуацій взаємного блокування

Взаємне блокування (deadlock) — ситуація, при якій декілька процесів знаходяться в стані нескінченного очікування ресурсів, зайнятих самими цими процесами. Е. Дейкстра спочатку назвав таку ситуацію «смертельними обіймами».

OpenVMS DLM періодично перевіряє процеси на ситуації взаємного блокування. У разі, коли перший процес блокує ресурс 1, очікуючи звільнення ресурсу 2, блокованою другим процесом, який, в свою чергу, очікує звільнення ресурсу 1, то другий процес викликає статус взаємного блокування. У цьому випадку вживаються заходи по виходу із стану взаємної блокування, звільняючи від блокування ресурс, якого було заблоковано першим.

Кластеризація в Linux

У січні 2006 року до ядра Linux версії 2.6.16 було включено код OCFS2 (Oracle Cluster File System), який запропонували програмісти однойменної корпорації; в листопаді 2006 до ядра версії 2.6.19 було додано код підтримки кластерного ПЗ від компанії Red Hat, зокрема підтримку файлової системи {{ safesubst:p{{ safesubst:#ifGFS2:{{{2}}}|1|2}}|{{{3}}}|}}. Обидві системи базуються на успішної моделі VMS DLM. При цьому розподілений менеджер блокувань від Oracle має спрощений API — базова функція dlmlock() мала всього 8 параметрів. Аналогічне логічне ім'я SYS$ENQв VMS, а також функція dlm_lock в DLM від Red Hat мають по 11 параметрів.

Chubby, сервіс блокування від Google

Корпорація Google розробила свою реалізацію сервісу блокування для слабозв'язанних розподілених систем, яку назвали Chubby. Цей сервіс призначений для забезпечення грубого блокування (Coarse Grained Lock), а також для підтримки функціонально-обмеженої, але надійної розподіленої файлової системи. Основні частини інфраструктури Google, включаючи Google File System, BigTable та MapReduce, використовують Chubby для синхронізації доступу до ресурсів, що розділяються. Хоча сервіс Chubby спочатку було розроблено як службу блокування, зараз Google його широко використовує як сервер імен, витісняючи DNS.

ZooKeeper

Apache Zookeeper, проект Apache Software Foundation — це розподілене ієрархічне сховище ключів і значень, яке використовується для забезпечення розподіленої служби конфігурацій, служби синхронізації та реєстру імен для великих розподілених систем. Також ZooKeeper може використовуватися як розподілений менеджер блокувань. Спочатку Zookeeper було започатковано як суб-проект в рамках Hadoop, але зараз він входить до списку основних проектів ASF.

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

Zookeeper використовується багатьма компаніями, в тому числі Rackspace, Yahoo!, Однокласники, Reddit і eBay , а також платформа повнотекстового пошуку з відкритим кодом Solr.

ETCD

Демон etcd, що дозволяє оновлювати налаштування вузлів в рамках інфраструктури кластера CoreOS, також надає можливості розподіленого менеджера блокувань.

Алгоритм Redlock в Redis

Нереляційна високопродуктивна СУБД Redis, що представляє собою мережевий журналируемое сховище даних типу «ключ — значення» з відкритим вихідним кодом, може бути використана для реалізації алгоритму розподіленого управління блокуваннями Redlock.

Зноски

Gehani, Narain. {{{Заголовок}}}. — .
kernel/git/torvalds/linux.git - Linux kernel source tree. git.kernel.org. Процитовано 14 лютого 2017.
kernel/git/torvalds/linux.git - Linux kernel source tree. git.kernel.org. Процитовано 14 лютого 2017.
. lwn.net. Архів оригіналу за 24 жовтня 2016. Процитовано 14 лютого 2017.
. research.google.com. Архів оригіналу за 20 листопада 2016. Процитовано 14 лютого 2017.
. cwiki.apache.org. Архів оригіналу за 25 серпня 2018. Процитовано 14 лютого 2017.
. zookeeper.apache.org. Архів оригіналу за 16 лютого 2017. Процитовано 14 лютого 2017.
. cwiki.apache.org. Архів оригіналу за 10 квітня 2014. Процитовано 14 лютого 2017.
. wiki.apache.org. Архів оригіналу за 9 грудня 2013. Процитовано 14 лютого 2017.
. reddit. Архів оригіналу за 16 лютого 2017. Процитовано 14 лютого 2017.
. cwiki.apache.org. Архів оригіналу за 13 квітня 2014. Процитовано 14 лютого 2017.
etcd/demo.md at master · coreos/etcd · GitHub. github.com. Процитовано 14 лютого 2017.
. redis.io. Архів оригіналу за 16 лютого 2017. Процитовано 14 лютого 2017.

[1] Gehani, Narain. {{{Заголовок}}}. — .

[2] rnel/git/torvalds/linux.git - Linux kernel source tree. git.kernel.org. Процитовано 14 лютого 2017.

[3] rnel/git/torvalds/linux.git - Linux kernel source tree. git.kernel.org. Процитовано 14 лютого 2017.

[4] . lwn.net. Архів оригіналу за 24 жовтня 2016. Процитовано 14 лютого 2017.

[:0-5] . research.google.com. Архів оригіналу за 20 листопада 2016. Процитовано 14 лютого 2017.

[6] . cwiki.apache.org. Архів оригіналу за 25 серпня 2018. Процитовано 14 лютого 2017.

[7] . zookeeper.apache.org. Архів оригіналу за 16 лютого 2017. Процитовано 14 лютого 2017.

[8] . cwiki.apache.org. Архів оригіналу за 10 квітня 2014. Процитовано 14 лютого 2017.

[9] . wiki.apache.org. Архів оригіналу за 9 грудня 2013. Процитовано 14 лютого 2017.

[10] . reddit. Архів оригіналу за 16 лютого 2017. Процитовано 14 лютого 2017.

[11] . cwiki.apache.org. Архів оригіналу за 13 квітня 2014. Процитовано 14 лютого 2017.

[12] tcd/demo.md at master · coreos/etcd · GitHub. github.com. Процитовано 14 лютого 2017.

[13] . redis.io. Архів оригіналу за 16 лютого 2017. Процитовано 14 лютого 2017.