Менеджер распределенных блокировок

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

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

Ресурсы

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

База данных
Стол
Записывать
Поле

Затем процесс . может получить блокировки для базы данных в целом, а затем и для отдельных частей базы данных Прежде чем можно будет заблокировать подчиненный ресурс, необходимо получить блокировку родительского ресурса.

Режимы блокировки

Процесс, работающий в VMSCluster, может получить блокировку ресурса. Существует шесть режимов блокировки, которые могут быть предоставлены, и они определяют уровень предоставляемой эксклюзивности. Можно преобразовать блокировку в более высокий или более низкий уровень режима блокировки. Когда все процессы разблокировали ресурс, системная информация о ресурсе уничтожается.

Нуль (Нидерланды). Указывает на интерес к ресурсу, но не препятствует его блокировке другими процессами. Его преимущество заключается в том, что ресурс и его блок значений блокировки сохраняются, даже если никакие процессы его не блокируют.
Параллельное чтение (CR). Указывает на желание прочитать (но не обновить) ресурс. Это позволяет другим процессам читать или обновлять ресурс, но не позволяет другим процессам иметь к нему монопольный доступ. Обычно это применяется к ресурсам высокого уровня, чтобы можно было получить более строгие блокировки для подчиненных ресурсов.
Одновременная запись (CW). Указывает на желание читать и обновлять ресурс. Это также позволяет другим процессам читать или обновлять ресурс, но не позволяет другим процессам иметь к нему монопольный доступ. Это также обычно применяется к ресурсам высокого уровня, чтобы можно было получить более строгие блокировки для подчиненных ресурсов.
Защищенное чтение (PR). Это традиционная блокировка общего ресурса , которая указывает на желание прочитать ресурс, но не позволяет другим его обновлять. Однако другие также могут прочитать этот ресурс.
Защищенная запись (PW). Это традиционная блокировка обновления , которая указывает на желание прочитать и обновить ресурс и не позволяет другим обновлять его. Однако другие пользователи, имеющие доступ к параллельному чтению, могут читать ресурс.
Эксклюзивный (EX). Это традиционная монопольная блокировка , которая разрешает доступ для чтения и обновления к ресурсу и предотвращает доступ к нему других лиц.

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

Режим	Нидерланды	ЧР	CW	пиар	ПВ	БЫВШИЙ
Нидерланды	Да	Да	Да	Да	Да	Да
ЧР	Да	Да	Да	Да	Да	Нет
CW	Да	Да	Да	Нет	Нет	Нет
пиар	Да	Да	Нет	Да	Нет	Нет
ПВ	Да	Да	Нет	Нет	Нет	Нет
БЫВШИЙ	Да	Нет	Нет	Нет	Нет	Нет

Получение блокировки

Процесс может получить блокировку ресурса, в очередь поставив запрос на блокировку . Это похоже на технику QIO , которая используется для выполнения ввода-вывода. Запрос на блокировку постановки в очередь может быть выполнен либо синхронно, и в этом случае процесс ждет, пока блокировка будет предоставлена, либо асинхронно, и в этом случае AST происходит , когда блокировка получена.

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

Блокировать блок значений

Блок значений блокировки связан с каждым ресурсом. Оно может быть прочитано любым процессом, получившим блокировку ресурса (кроме нулевой блокировки), и может быть обновлено процессом, получившим защищенное обновление или исключительную блокировку ресурса.

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

Обнаружение тупиковой ситуации

Когда один или несколько процессов получили блокировки ресурсов, может возникнуть ситуация, когда каждый из них не позволяет другому получить блокировку, и ни один из них не может продолжить работу. Это известно как тупик ( Э. У. Дейкстра первоначально назвал это смертельным объятием ). ^[1]

Простой пример: процесс 1 получил монопольную блокировку ресурса A, а процесс 2 получил эксклюзивную блокировку ресурса B. Если затем процесс 1 попытается заблокировать ресурс B, ему придется дождаться, пока процесс 2 освободит его. Но если Процесс 2 затем попытается заблокировать Ресурс А, оба процесса будут ждать друг друга вечно.

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

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

И Red Hat , и Oracle разработали программное обеспечение для кластеризации для Linux .

OCFS2 , добавлена файловая система Oracle Cluster. ^[2] в официальное ядро Linux версии 2.6.16 в январе 2006 года. Предупреждение об альфа-качестве кода в OCFS2 было удалено в версии 2.6.19.

Кластерное программное обеспечение Red Hat, включая DLM и GFS2, было официально добавлено в ядро Linux. ^[3] с версией 2.6.19, ноябрь 2006 г.

Обе системы используют DLM, созданный по образцу почтенной VMS DLM. ^[4] Oracle DLM имеет более простой API. (основная функция, dlmlock(), имеет восемь параметров, тогда как VMS SYS$ENQ сервис и Red Hat dlm_lock у обоих по 11.)

Другие реализации

Другие реализации DLM включают следующее:

Google разработал Chubby — сервис блокировки для слабосвязанных распределенных систем. ^[5] Он предназначен для грубой блокировки, а также обеспечивает ограниченную, но надежную распределенную файловую систему. Ключевые части инфраструктуры Google, включая Google File System , Bigtable и MapReduce , используют Chubby для синхронизации доступа к общим ресурсам. Хотя Chubby был разработан как служба блокировки, сейчас он активно используется внутри Google в качестве сервера имен , заменяя DNS . ^[5]
Apache ZooKeeper , созданный в Yahoo , представляет собой программное обеспечение с открытым исходным кодом и может использоваться для выполнения распределенных блокировок. ^[6] также.
Etcd — это программное обеспечение с открытым исходным кодом, разработанное в CoreOS по лицензии Apache. ^[7] Его также можно использовать для выполнения распределенных блокировок. ^[8]
Redis — это открытый исходный код, лицензированный Redis Source Available License, расширенный кэш и хранилище «ключ-значение». ^[9] Redis можно использовать для реализации алгоритма Redlock для распределенного управления блокировками. ^[10]
ХашиКорп Консул , ^[11] который был создан HashiCorp , представляет собой программное обеспечение с открытым исходным кодом и также может использоваться для выполнения распределенных блокировок.
Менеджер распределенных блокировок Taooka ^[12] использует методы «try lock», чтобы избежать взаимоблокировок . Он также может указать TTL для каждой блокировки с точностью до наносекунды.
DLM также является ключевым компонентом более амбициозных проектов единого образа системы (SSI), таких как OpenSSI .

Ссылки

^ Гехани, Нараин (1991). Ада: Параллельное программирование . Силиконовый пресс. п. 105. ИСБН 9780929306087 .
^ kernel/git/torvalds/linux.git — дерево исходного кода ядра Linux. ^{[ постоянная мертвая ссылка ]}. Кернел.орг. Проверено 18 сентября 2013 г.
^ kernel/git/torvalds/linux.git — дерево исходного кода ядра Linux . Архивировано 18 июля 2012 г. в archive.today . Git.kernel.org (07.12.2006). Проверено 18 сентября 2013 г.
^ Файловая система OCFS2 . Lwn.net (24 мая 2005 г.). Проверено 18 сентября 2013 г.
^ Перейти обратно: ^а ^б Публикация исследования Google: Служба распределенной блокировки Chubby . Research.google.com. Проверено 18 сентября 2013 г.
^ [1] . Zookeeper.apache.org. Проверено 18 сентября 2013 г.
^ «КореОС» . coreos.com .
^ etcd: Распределенное надежное хранилище значений ключей для наиболее важных данных распределенной системы , CoreOS, 16 января 2018 г. , получено 20 сентября 2016 г.
^ redis.io http://redis.io/ . Проверено 14 апреля 2015 г. {{cite web}}: Отсутствует или пусто |title= ( помощь ) ^{[ название отсутствует ]}
^ «Распределенные блокировки с Redis — Redis» . redis.io . Проверено 14 апреля 2015 г.
^ Обзор консула . Проверено 19 февраля 2015 г.
^ Описание Taooka . Архивировано 3 мая 2017 г. на Wayback Machine. Проверено 4 мая 2017 г.

[1] Гехани, Нараин (1991). Ада: Параллельное программирование . Силиконовый пресс. п. 105. ИСБН 9780929306087 .

[2] rnel/git/torvalds/linux.git — дерево исходного кода ядра Linux. ^{[ постоянная мертвая ссылка ]}. Кернел.орг. Проверено 18 сентября 2013 г.

[3] rnel/git/torvalds/linux.git — дерево исходного кода ядра Linux . Архивировано 18 июля 2012 г. в archive.today . Git.kernel.org (07.12.2006). Проверено 18 сентября 2013 г.

[4] Файловая система OCFS2 . Lwn.net (24 мая 2005 г.). Проверено 18 сентября 2013 г.

[chubby-5] Перейти обратно: ^а ^б Публикация исследования Google: Служба распределенной блокировки Chubby . Research.google.com. Проверено 18 сентября 2013 г.

[zookeeper-6] [1] . Zookeeper.apache.org. Проверено 18 сентября 2013 г.

[CoreOS-7] «КореОС» . coreos.com .

[etcd-8] etcd: Распределенное надежное хранилище значений ключей для наиболее важных данных распределенной системы , CoreOS, 16 января 2018 г. , получено 20 сентября 2016 г.

[redis-9] redis.io http://redis.io/ . Проверено 14 апреля 2015 г. {{cite web}}: Отсутствует или пусто |title= ( помощь ) ^{[ название отсутствует ]}

[redlock-10] «Распределенные блокировки с Redis — Redis» . redis.io . Проверено 14 апреля 2015 г.

[consul-11] Обзор консула . Проверено 19 февраля 2015 г.

[taooka-12] Описание Taooka . Архивировано 3 мая 2017 г. на Wayback Machine. Проверено 4 мая 2017 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]