ZooKeeper
ZooKeeper — это централизованный координационный сервис, выполняющий следующие функции в кластере Hadoop:
-
Обслуживание конфигурационной информации.
-
Регистрация наименований.
-
Обеспечение распределенной синхронизации.
-
Обеспечение защиты от ошибок вида "состояние гонки" (race condition) и "взаимная блокировка" (deadlock).
-
Предоставление групповых сервисов.
Этот сервис основан на Java с привязкой к Java и C. Его простая архитектура и персонифицированный API помогают избежать возможных ошибок при управлении большими распределенными системами.
Архитектура
Zookeeper использует архитектуру клиент-сервер и содержит следующие компоненты:
-
Ensemble — это группа (ансамбль) серверов ZooKeeper в количестве не менее трех для обеспечения надежности. Когда один сервер становится недоступным, оставшиеся два образуют кворум (quorum), который продолжает работу кластера. Рекомендуется использовать нечетное количество серверов в кластере, то есть: 3, 5, 7 и так далее.
-
Server — один из участников ансамбля Zookeeper. Его назначение состоит в предоставлении всех видов сервиса, необходимых клиентам. Существуют два типа серверов:
-
Server Leader — лидер, обеспечивает автоматическое восстановление работоспособности кластера в случае сбоев на серверах другого типа. Серверы выбирают лидера при начальном запуске ZooKeeper.
-
Server Follower — ведомый сервер, которым является каждый сервер ансамбля, кроме лидера. Он следует указаниям лидера.
-
-
Client — клиент, являющийся потребителем сервисов ZooKeeper.
Компоненты ZooKeeper представлены на следующей схеме.
Модель данных
Znodes
ZooKeeper позволяет распределенным процессам взаимодействовать между собой посредством разделяемого иерархического пространства имен (namespace), организованного подобно обычной файловой системе. Каждая нода в этом пространстве называется znode и идентифицируется с помощью ее пути. В отличие от типичной файловой системы, znode выполняет роль файла и каталога одновременно. Все данные хранятся в оперативной памяти, что позволяет сервису ZooKeeper обеспечивать высокую пропускную способность и малую задержку.
|
ВНИМАНИЕ
Поскольку ZooKeeper разработан для хранения координационных данных (конфигурация, состояния, информация о локации и так далее), предполагается, что объем этих данных не будет слишком большим. Поэтому объем данных в znode не может превышать 1 МБ.
|
На следующей диаграмме дано схематичное изображение модели данных в ZooKeeper. Пример содержит корневую znode, идентифицированную как /, и две дочерние znodes: /z1 и /z2. Эти znodes могут иметь свои дочерние znodes, последние — свои и так далее.
Операции чтения и записи данных в znode атомарные:
-
При чтении клиент получает все данные, хранящиеся в указанной znode.
-
При записи происходит полная замена всего содержимого znode.
Каждая znode содержит метаданные в составе структуры stat. Она включает номера версий, временные метки (timestamps), идентификаторы соответствующих транзакций и другие метаданные. Znodes защищены посредством списков доступа (Access Control Lists, ACLs), содержащих перечень пользователей с их привилегиями.
Возможные типы znodes приведены в следующей таблице.
| Тип | Описание |
|---|---|
Persistent |
Тип znodes, используемый по умолчанию. Znodes такого типа продолжают существовать, даже если создавший их клиент не подключен к серверам кластера |
Ephemeral |
Тип znodes, время существования которых определяется продолжительностью клиентской сессии (в рамках которых они созданы). Ephemeral znodes не могут иметь дочерних znodes |
Sequential |
Когда клиент запрашивает создание znode такого типа, ZooKeeper добавляет к указанному полному пути znode 10-значный последовательный номер, например /top/myspace/mynode0000000001. Sequential znodes играют важную роль в блокировании и синхронизации процессов. Sequential znodes являются одновременно persistent или ephemeral. Это означает, что существует не один тип, а два: persistent-sequential и ephemeral-sequential |
Container |
Тип znodes, созданный для упрощения выполняемой ZooKeeper очистки от неиспользуемых более znodes (znodes, оставшихся без дочерних нод). Container-нода аналогична Persistent-ноде, но c дополнительной функцией постановки в кандидаты на удаление ZooKeeper-сервером, как только удаляется ее последняя дочерняя znode |
Watches
Watches — это специальный механизм, предоставляющий клиентам возможность получать уведомления об изменениях в указанных ими znodes. Объект watch удаляется сразу после его срабатывания, произошедшего в результате изменения наблюдаемой znode.
Watches используется обычно теми операциями, которые следят за состоянием ZooKeeper: проверка наличия znode, чтение данных из znode и получение списка дочерних znodes.
|
ВНИМАНИЕ
Watch основан на использовании одноразового триггера. После того, как он сработал, последующих срабатываний не будет, пока клиент не создаст новый watch.
|
Принципы работы
Сессии
ZooKeeper использует механизм сессий. Сессия (session) — это промежуток времени, в течение которого клиент взаимодействует с сервером для получения требуемых услуг. В каждой сессии сервер исполняет запросы клиента поочередно в порядке поступления (FIFO). При создании сессии клиент получает идентификатор сессии.
Клиент подключается только к одному серверу для обслуживания всех своих запросов. Это может быть лидер или ведомый сервер. Если клиент не получает подтверждения успешного соединения, он пытается подключиться к другому серверу ZooKeeper.
После установления соединения клиент посылает контрольные сигналы (heartbeat) на сервер для поддержания сессии. Если ZooKeeper не получает контрольный сигнал от клиента по истечении заданного периода (timeout), он полагает, что клиент недоступен.
Чтение и запись
Каждый сервер в ансамбле ZooKeeper содержит реплику базы данных. Она хранится в оперативной памяти (in-memory database) и содержит полное дерево znodes. Обновления в дереве серверы записывают в журнал на диске, что позволяет восстановить базу данных при необходимости.
Наличие реплицированной базы данных позволяет серверам выполнять операции чтения без обращения к лидеру. Запросы на запись обрабатываются лидером с использованием специального протокола соглашения (agreement protocol).
Типичная операция чтения состоит из следующих шагов:
Типичная последовательность записи выглядит следующим образом:
-
Клиент запускает сессию на одном из серверов.
-
Клиент посылает серверу запрос на запись. Запрос включает путь к znode, данные которой необходимо перезаписать.
-
Сервер посылает запрос на запись лидеру.
-
Лидер пересылает запрос всем ведомым серверам посредством атомарной широковещательной рассылки (atomic broadcast). Запрос на запись считается обработанным, если большинство ведомых серверов (кворум) подтвердит успешное завершение запроса. В таком случае изменения в базе данных реплицируются на все серверы.
-
Клиент получает ответ о завершении операции.
|
ПРИМЕЧАНИЕ
|