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

                                     

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

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

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

                                     

1. Реализация VMS

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

                                     

1.1. Реализация VMS Ресурсы

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

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

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

                                     

1.2. Реализация VMS Режимы блокировки

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

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

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



                                     

1.3. Реализация VMS Получение блокировки

Процесс может заблокировать ресурс с помощью постановки в очередь 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.

                                     

1.4. Реализация VMS Блок значения блокировки

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

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

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

                                     

1.5. Реализация VMS Определение ситуаций взаимной блокировки

Взаимная блокировка deadlock - ситуация при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, занятых самими этими процессами. Э. Дейкстра первоначально назвал такую ситуацию "смертельным объятием".

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



                                     

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

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

                                     

3. Chubby, сервис блокировки от Google

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

                                     

4. ZooKeeper

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

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

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



                                     

5. ETCD

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

                                     

6. Алгоритм Redlock в Redis

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

                                     
  • ни один из них не может продолжать свое выполнение. Отладка взаимных блокировок как и других ошибок синхронизации, усложняется тем, что для их возникновения
  • демонов biod обрабатывает асинхронный ввод - вывод блоков файлов NFS. Менеджер блокировок сети NLM - Network Lock Manager и монитор состояния сети NSM
  • нескольких факторов, включая количество уже выполненных блокировок наличие конфликтующих блокировок на запись, и числа запросов на блокировку. Установленная
  • реализуют простейшие типичные функции для обработки информации о измерениях, блокировок регулирования и программного логического управления. Многие из них имеют
  • системы по уровню C2 вплоть до B1 по Orange Book. Реализация распределённого менеджера блокировок DLM Кластеры cluster - объединение нескольких систем