Распределённый менеджер блокировок

Материал из Википедии — свободной энциклопедии
(перенаправлено с «Distributed lock manager»)
Перейти к навигации Перейти к поиску

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

Различные реализации DLM были использованы в качестве основы для нескольких успешных кластерных файловых систем, в которых машины в кластере можно использовать для хранения файлов друг друга с помощью единой файловой системы, со значительными преимуществами в плане повышения производительности и доступности. Основное преимущество производительности достигается за счёт решения проблемы когерентности дискового кэша между участвующими компьютерами. DLM используется не только для блокировки файлов, но и для координации всех видов дискового доступа. VMS Сluster (ранее именовавшийся VAX Cluster) — первая система кластеризации, получившая широкое распространение, основывается на VAX/VMS (в последующем OpenVMS) DLM именно таким образом.

Реализация VMS[править | править код]

DEC VAX/VMS была первой широкодоступной операционной системой с реализацией DLM. Данный функционал появился в версии 4, хотя пользовательский интерфейс был таким же, как у однопроцессорного менеджера блокировки, который впервые был реализован в версии 3.

Ресурсы[править | править код]

DLM использует обобщённое понятие ресурса как некоего объекта, к которому должен контролироваться общий доступ. Это может быть файл, запись, область общей памяти, или что-нибудь ещё по выбору разработчика приложения. Разработчик сам описывает иерархию ресурсов, так что он может определить необходимое количество уровней блокировки. Например, гипотетическая база данных могла бы описывать иерархию ресурсов следующим образом:

  • База данных
  • Таблица
  • запись
  • поле

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

Режимы блокировки[править | править код]

Процесс, выполняющийся внутри VMS Cluster, может получить блокировку ресурса. DLM реализует шесть режимов блокировки, и каждый из них определяет разные уровни предоставляемой эксклюзивности (совместимости). В процессе использования ресурса можно преобразовать уровень режима блокировки на более высокий или более низкий. Когда все процессы разблокируют ресурс, информация системы о ресурсе уничтожается.

  • Null (NL). Указывает интерес к ресурсу, но не мешает другим процессам захватывать его. Этот режим предоставляет удобный механизм создания ресурса и сохранения его значение блока блокировки. Обычно используется в целях декларации существования объекта на конкретном узле для членов кластера (VMS Cluster members).
  • Параллельное чтение (Concurrent Read, CR). Указывает на намерение читать (но не обновлять) ресурс. Это позволяет другим процессам читать или обновлять ресурс, но не позволяет другим получать эксклюзивный доступ к нему. Этот режим, как правило, используется на ресурсах высокого уровня иерархии, учитывая то, что для подчинённых ему ресурсов могут быть получены более жёсткие блокировки.
  • Одновременная запись (Concurrent Write, CW). Указывает на намерение читать и обновлять ресурс. Этот режим также позволяет другим процессам читать или обновлять ресурс, но не позволяет другим получать эксклюзивный доступ к нему. Этот режим также используется на ресурсах высокого уровня иерархии, учитывая то, что для дочерних ресурсов могут быть получены более жёсткие блокировки.
  • Защищённое чтение (Protected Read, PR). Это традиционный режим общей блокировки, который указывает на желание читать ресурс, но не позволяет другим обновлять его содержимое. Другие процессы, однако, также могут прочитать содержимое ресурса.
  • Защищённая запись (Protected Write, PW). Это традиционный режим блокировки обновления, который указывает на желание читать и обновлять ресурс и не позволяет другим пользователям обновлять его. Другие процессы могут получать режим доступа «Параллельное чтение» и могут прочитать ресурс.
  • Exclusive (EX). Это традиционная эксклюзивная блокировка , которая позволяет читать и обновлять доступ к ресурсу, и не позволяет другим процессам иметь доступ к нему.

Следующая таблица истинности показывает совместимость каждого режима блокировки с другими:

Mode NL CR CW PR PW EX
NL Да Да Да Да Да Да
CR Да Да Да Да Да Нет
CW Да Да Да Нет Нет Нет
PR Да Да Нет Да Нет Нет
PW Да Да Нет Нет Нет Нет
EX Да Нет Нет Нет Нет Нет

Получение блокировки[править | править код]

Процесс может заблокировать ресурс с помощью постановки в очередь (SYS$ENQ) запроса блокировки. Это похоже на Queue IO — технологию VMS, которая используется для выполнения операций ввода/вывода. Запрос блокировки может выполняться либо полностью синхронно, в этом случае процесс ожидает, пока блокировка не выдаётся, или асинхронно, и в этом случае срабатывает механизм асинхронного системного прерывания (AST), когда будет получена блокировка.

Кроме того, можно установить блокирующий AST (Blocking AST), который срабатывает, когда процесс получил блокировку, предотвращая доступ к ресурсу другим процессом (на жаргоне разработчиков VMS именуется как DoorBell AST). Оригинальный процесс может затем при необходимости принять меры, чтобы позволить другим доступ (например, понизив или сняв блокировку). Blocking AST предоставляет разработчикам приложений удобный способ координации инстанций приложений в тех случаях, когда допускается активность только одной инстанции, а остальные переводятся в режим ожидания. Пример использования в VMS Cluster — Cluster Node Alias, DECNet/LAT/IP адрес, мигрирующий в зависимости от степени загруженности (Load Balancing) узла или его доступности (Failover).

Блок значения блокировки[править | править код]

С каждым ресурсом связан блок значения блокировки размером 32 байта. Он может быть прочитан при получении любого вида блокировки (кроме блокировки NULL) и может быть обновлён ​​с помощью процесса, который получил блокировку ресурса уровня PW или EX.

Он может быть использован для хранения выбранной разработчиком приложений информации о ресурсе. Пример использования: хранение номера версии ресурса. Каждый раз, когда связанный с ним объект (например, запись в базе данных) обновляется, владелец блокировки инкрементирует блок значения блокировки. Когда другой процесс желает прочитать ресурс, он получает соответствующую блокировку и сравнивает текущее значение блокировки с значением, которое было в прошлый раз, когда процесс обращался к заблокированному ресурсу. Если значение такое же, процесс знает, что связанный с ним ресурс не был обновлён с момента последнего времени его чтения, и, следовательно, нет необходимости читать его снова. Следовательно, этот метод может быть использован для реализации различных типов кэш-памяти в базе данных или аналогичных приложениях.

Другой пример использования: межпроцессное взаимодействие (IPC — InterProcess Communication) — в тех случаях, когда требуется высокая реактивность обмена небольшими порциями данных (в пределах 32-х байт) между процессами на различных узлах VMS Cluster при требованиях низкой латентности. Для обмена бóльшими порциями данных (до 1 Mb) — используется технология ICC (IntraCluster Communication service, SYS$ICC[2]).

Определение ситуаций взаимной блокировки[править | править код]

Взаимная блокировка (deadlock) — ситуация при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, занятых самими этими процессами. Э. Дейкстра первоначально назвал такую ситуацию «смертельным объятием»[3].

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

Кластеризация в Linux[править | править код]

В январе 2006 года в ядро Linux версии 2.6.16 был включён код OCFS2 (Oracle Cluster File System)[4], предложенный программистами одноимённой корпорации, в ноябре 2006 в ядро версии 2.6.19 был добавлен код[5] поддержки кластерного ПО от корпорации Red Hat, в частности, поддержку файловой системы GFS2. Обе системы основаны на успешной модели VMS DLM[6]. При этом распределённый менеджер блокировок от Oracle имел упрощённый API — его базовая функция dlmlock() имела всего 8 параметров, когда как аналогичный системный вызов SYS$ENQв VMS, а также функция dlm_lock в DLM от Red Hat имели по 11 параметров.

Chubby, сервис блокировки от Google[править | править код]

Корпорация Google разработала свою реализацию сервиса блокировки для слабосвязанных распределённых систем, которую назвали Chubby[7]. Этот сервис предназначен для обеспечения грубой блокировки (Coarse Grained Lock), а также для поддержки функционально ограниченной, но надёжной распределенной файловой системы. Основные части инфраструктуры Google, включая Google File System, BigTable и MapReduce, используют Chubby для синхронизации доступа к разделяемым ресурсам. Хотя сервис Chubby изначально разработан в качестве службы блокировки, сейчас он широко используется в Google в качестве сервера имён, вытесняя DNS[7].

ZooKeeper[править | править код]

Apache Zookeeper, проект Apache Software Foundation, представляет собой распределенное иерархическое хранилище ключей и значений, которое используется для обеспечения распределенной службы конфигураций, службы синхронизации и реестра имен для больших распределенных систем[8]. Также ZooKeeper может использоваться как распределенный менеджер блокировок[9]. Изначально Zookeeper был суб-проектом в рамках Hadoop, но в настоящем входит в основной список проектов ASF.

Архитектура Zookeeper поддерживает высокую доступность за счет избыточности услуг. Таким образом, клиенты могут инициировать выборы другого лидера Zookeeper, если не отвечает текущий. Узлы Zookeeper хранят свои данные в иерархическом пространстве имён, аналогичном файловой системе или дереву структуры данных[10].

Zookeeper используется многими компаниями, в том числе Rackspace, Yahoo![11], Одноклассники, Reddit[12], Яндекс[13] и eBay, а также платформа полнотекстового поиска с открытым исходным кодом Solr[14].

ETCD[править | править код]

Демон etcd, который позволяет обновлять настройки узлов в рамках инфраструктуры кластера CoreOS, также предоставляет возможности распределенного менеджера блокировок[15].

Алгоритм Redlock в Redis[править | править код]

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

Примечания[править | править код]

  1. ↑ Lawrence Kenah, Ruth Goldenberg. VAX/VMS Internals and Data Structures: Version 5.2. — Bedford, MA: Digital Press, 1987-12-21. — 1427 с. — ISBN 9781555580599.
  2. ↑ Hewlett-Packard Company Palo Alto, California. HPOpenVMSSystemServices ReferenceManual.
  3. ↑ Gehani, Narain. Ada : concurrent programming. — Silicon Press, 1991-01-01. — ISBN 9780929306087.
  4. ↑ kernel/git/torvalds/linux.git - Linux kernel source tree (англ.). git.kernel.org. Дата обращения: 14 февраля 2017.
  5. ↑ kernel/git/torvalds/linux.git - Linux kernel source tree (англ.). git.kernel.org. Дата обращения: 14 февраля 2017.
  6. ↑ The OCFS2 filesystem [LWN.net]. lwn.net. Дата обращения: 14 февраля 2017. Архивировано 24 октября 2016 года.
  7. ↑ 1 2 Google Research Publication: Chubby Distributed Lock Service. research.google.com. Дата обращения: 14 февраля 2017. Архивировано 20 ноября 2016 года.
  8. ↑ Index - Apache ZooKeeper - Apache Software Foundation. cwiki.apache.org. Дата обращения: 14 февраля 2017. Архивировано 25 августа 2018 года.
  9. ↑ ZooKeeper Recipes and Solutions. zookeeper.apache.org. Дата обращения: 14 февраля 2017. Архивировано из оригинала 16 февраля 2017 года.
  10. ↑ ProjectDescription - Apache ZooKeeper - Apache Software Foundation. cwiki.apache.org. Дата обращения: 14 февраля 2017. Архивировано 10 апреля 2014 года.
  11. ↑ ZooKeeper/PoweredBy - Hadoop Wiki. wiki.apache.org. Дата обращения: 14 февраля 2017. Архивировано из оригинала 9 декабря 2013 года.
  12. ↑ Why Reddit was down on Aug 11 • /r/announcements. reddit. Дата обращения: 14 февраля 2017. Архивировано 16 февраля 2017 года.
  13. ↑ ZooKeeper в качестве системы гарантированной доставки для Яндекс.Почты. habr. Дата обращения: 28 июня 2019. Архивировано 27 июня 2019 года.
  14. ↑ SolrCloud - Apache Solr Reference Guide - Apache Software Foundation. cwiki.apache.org. Дата обращения: 14 февраля 2017. Архивировано 13 апреля 2014 года.
  15. ↑ etcd/demo.md at master · coreos/etcd · GitHub (англ.). github.com. Дата обращения: 14 февраля 2017.
  16. ↑ Distributed locks with Redis – Redis. redis.io. Дата обращения: 14 февраля 2017. Архивировано 16 февраля 2017 года.
Источник — https://ru.wikipedia.org/w/index.php?title=Распределённый_менеджер_блокировок&oldid=124394230