Распределенный менеджер блокировок - Distributed lock manager

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

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

Внедрение VMS

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

Ресурсы

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

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

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

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

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

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

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

РежимNLCRCWPRPWEX
NLдададададада
CRдададададаНет
CWдададаНетНетНет
PRдадаНетдаНетНет
PWдадаНетНетНетНет
EXдаНетНетНетНетНет

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

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

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

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

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

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

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

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

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

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

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

И то и другое Красная Шапка и Oracle разработали программное обеспечение для кластеризации Linux.

OCFS2, добавлена ​​файловая система Oracle Cluster File System[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 разработал Пухлый, служба блокировки для слабосвязанных распределенных систем.[5] Он разработан для крупномасштабной блокировки, а также предоставляет ограниченную, но надежную распределенную файловую систему. Ключевые части инфраструктуры Google, включая Файловая система Google, Большой стол, и Уменьшение карты используйте Chubby для синхронизации доступа к общим ресурсам. Хотя Chubby был разработан как сервис блокировки, в настоящее время он активно используется в Google как сервер имен, вытесняя DNS.[5]
  • Apache ZooKeeper, который был создан в Yahoo, является программным обеспечением с открытым исходным кодом и может использоваться для выполнения распределенных блокировок[6] также.
  • И т.д. программное обеспечение с открытым исходным кодом, разработанное в CoreOS под лицензией Apache.[7] Его также можно использовать для выполнения распределенных блокировок.[8]
  • Redis - это расширенный кэш-память и хранилище ключей с открытым исходным кодом под лицензией BSD.[9] Redis можно использовать для реализации алгоритма Redlock для управления распределенными блокировками.[10]
  • HashiCorp's Консул,[11] который был создан HashiCorp, является программным обеспечением с открытым исходным кодом и может также использоваться для выполнения распределенных блокировок.
  • Диспетчер распределенных блокировок Taooka[12] использует методы "пробной блокировки", чтобы избежать тупиковые ситуации. Он также может указывать TTL для каждой блокировки с точностью до наносекунды.
  • DLM также является ключевым компонентом более амбициозных единый образ системы (SSI) такие проекты, как OpenSSI.

использованная литература

  1. ^ Гехани, Нараин (1991). Ада: параллельное программирование. п. 105. ISBN  9780929306087.
  2. ^ kernel / git / torvalds / linux.git - дерево исходных текстов ядра Linux[постоянная мертвая ссылка ]. Kernel.org. Проверено 18 сентября 2013.
  3. ^ kernel / git / torvalds / linux.git - дерево исходных текстов ядра Linux В архиве 2012-07-18 в Archive.today. Git.kernel.org (07 декабря 2006 г.). Проверено 18 сентября 2013.
  4. ^ Файловая система OCFS2. Lwn.net (24 мая 2005 г.). Проверено 18 сентября 2013.
  5. ^ а б Публикация Google Research: Chubby Distributed Lock Service. Research.google.com. Проверено 18 сентября 2013.
  6. ^ [1]. Zookeeper.apache.org. Проверено 18 сентября 2013.
  7. ^ «CoreOS». coreos.com.
  8. ^ etcd: распределенное надежное хранилище ключей и значений для наиболее важных данных распределенной системы., CoreOS, 16 января 2018 г., получено 2016-09-20
  9. ^ http://redis.io/ Проверено 14 апреля 2015 г.
  10. ^ «Распределенные блокировки с Redis - Redis». redis.io. Получено 2015-04-14.
  11. ^ Обзор консула. Проверено 19 февраля 2015.
  12. ^ Описание таука Проверено 4 мая 2017.