Apache ZooKeeper

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:22, 30 января 2019.
Apache ZooKeeper
Apache ZooKeeper
Разработчики: Apache Software Foundation
Постоянный выпуск: 3.4.13 / 15 July 2018 года; 2 years ago (2018-07-15) [Источник 1]
Предыдущий выпуск: 3.5.4-beta / 17 May 2018 года; 2 years ago (2018-05-17)
Состояние разработки: Active
Написана на: Java
Операционная система: Кросс-платформенная[Источник 2][Источник 3]
Тип ПО: СУБД
Лицензия: Apache License2.0, Free software
Веб-сайт zookeeper.apache.org

Apache ZooKeeper - это централизованная служба для поддержки информации о конфигурации, именования, обеспечения распределенной синхронизации и предоставления групповых служб. Все эти виды услуг используются в той или иной форме распределенными приложениями. Управление и координация службы, особенно в распределенной среде, является сложным процессом, ZooKeeper решает эту проблему благодаря своей простой архитектуре и API. Не беспокоясь о распределенной природе приложения, ZooKeeper позволяет разработчикам сосредоточиться на основной логике приложения. Первоначально, для легкого и надежного доступа к приложениям, платформа ZooKeeper была построена в "Yahoo!". Но после этого для организации сервисов, используемых Hadoop, HBase и другими распределенными средами, стал стандартом Apache ZooKeeper. Например, для отслеживания состояния распределенных данных Apache HBase использует ZooKeeper. Кроме того, они также могут легко поддерживать большой кластер Hadoop. Для получения информации каждый клиентский компьютер связывается с одним из серверов. Однако в прошлые времена большая часть работы требовала исправления ошибок во время реализации распределенных приложений. В общем можно сказать, что эти трудности в реализации являются основной причиной создания ZooKeeper, т.к. он следит за синхронизацией, а также за координацией всего кластера.


Описание

Обозначим сначала свойства Zookeeper:

  • пространство ключей образует дерево (иерархию, подобную файловой системе);
  • значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode;
  • между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии;
  • возможно создать временную пару ключ/значение, которая существует, пока клиент, её создавший, подключен к кластеру;
  • все данные должны помещаться в память;
  • устойчивость к смерти некритического количества узлов кластера.

Прежде чем углубляться в работу ZooKeeper, стоит взглянуть на фундаментальные понятия:

- Архитектура.
- Иерархическое пространство имен.
- Сессии.
- Наблюдатели.

Архитектура

Рисунок 1 - Архитектура "Клиент-Сервер"
Рисунок 2 - Компоненты ZooKeeper

Каждый компонент, являющийся частью архитектуры (см. рисунок 1, рисунок 2) ZooKeeper, описывается в таблице:

Компонент Описание
Клиент Клиенты, один из узлов в нашем кластере распределенного приложения, имеют доступ к информации с сервера. Для конкретного интервала времени каждый клиент посылает сообщение серверу, давая последнему понять, что клиент живой. Аналогично, сервер посылает подтверждение, когда клиент подключается. Если от сервера нет ответа, клиент автоматически перенаправляет сообщение другому серверу.
Сервер Сервер, один из узлов ZooKeeper, предоставляет все службы клиенту. Предоставляет подтверждение клиенту о том, что сервер жив.
Ансамбль Группа серверов ZooKeeper. Минимальное количество узлов, которое необходимо для формирования ансамбля - 3.
Лидер Серверный узел, который выполняет автоматическое восстановление, если любой из подключенных узлов отказал. Лидеры выбираются при запуске служб.
Последователь Серверный узел, который следует инструкциям лидера.

Иерархическое пространство имен

Следующая диаграмма показывает древовидную структуру файловой системы ZooKeeper, используемую для представления памяти (см. рисунок 3). Узел ZooKeeper называется znode. Каждый znode идентифицируется по имени и разделяется последовательностью пути (/).

  • На диаграмме первое, что есть, - корень znode, отделенный "/". Под корнем есть два логических пространства имен конфиг и работники.
  • Пространство имен конфиг используется централизованным управлением конфигураций и пространство имен работники используется для наименований.
  • Под конфигом каждый znode может хранить до 1 МБ данных. Это похоже на UNIX-подобную файловую систему за исключением того, что родительский znode также может хранить данные. Главная цель этой структуры - хранение синхронизированных данных и описание метаданных znode. Эта структура называется Моделью Данных ZooKeeper.
Рисунок 3 - Иерархическое пространство имен

Каждый znode в модели данных ZooKeeper содержит структуру stat. Stat просто предоставляет метаданные znode. Состоит из номера версии, список управляющих действий, меток, длины данных.

  • Номер версии - каждый znode имеет номер версии, что означает, что каждый раз, когда данные, связанные с znode, изменяются, его соответствующий номер увеличивается. Использование номера версии важно, когда несколько клиентов ZooKeeper пытаются выполнить операции над одним и тем же znode.
  • Список управляющих действий - по существу механизм аутентификации для доступа к znode. Регулирует все операции чтения и записи.
  • Метка - представляет время, прошедшее с момента создания и изменения. Как правило, представляется в миллисекундах. ZooKeeper идентифицирует каждое изменение в znode с помощью "ID транзакции" (zxid). Zxid является уникальным и поддерживает время для каждой операции, так что можно легко определить время, прошедшее от одного запроса до другого.
  • Длина данных - суммарное число данных, хранимое в znode, и есть длина данных. Максимально возможное значение - 1МБ.

Сессии

Сессии очень важны для операций над ZooKeeper. Запросы в сессию исполняются в порядке очередности FIFO. Как только клиент подключился к серверу, будет создана сессия и id сессии будет присвоен клиенту.

Клиент посылает "сердцебиения" в конкретный временной интервал для валидности сессии. Если ансамбль ZooKeeper не получает "сердцебиения" от клиента более чем за период (таймаут сессии), определенный в начале обслуживания, это означает, что клиент умер.

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

Наблюдатели

Наблюдатели - это простой механизм для клиента для получения уведомлений об изменениях в ансамбле серверов ZooKeeper. Клиенты могут выставлять наблюдателей во время чтения конкретного znode. Наблюдатели посылают уведомления зарегистрированным клиентам при каждом изменении znode (на котором зарегистрирован клиент).

Изменения znode - модификация данных, связанных с znode, или изменения с детьми znode. Наблюдатели запускаются только один раз. Если клиент вновь хочет получить уведомление, это должно быть сделано через следующую операцию чтения. Когда сессия истекла, клиент будет отключен от сервера и все связанные наблюдатели также удалятся.

Для чего же нужен ZooKeeper?

Apache ZooKeeper - сервис, используемый кластером (группой узлов) для согласования друг с другом и поддержания общих данных с надежными методами синхронизации. ZooKeeper сам по себе является распределенным приложением, предоставляющим услуги для написания распределенных приложений. Основные услуги, предоставляемые ZooKeeper:

  • Служба имен - идентификация узлов в кластере по имени. Очень похоже на DNS, но только для узлов.
  • Управление конфигурацией - последняя и актуальная информация о системе новому подключаемому узлу.
  • Управление кластером - добавление/удаление узла в\из кластера и статус узла в реальном времени.
  • Выбор лидера - выбор узла в качестве лидера в целях согласования.
  • Служба блокировки и синхронизации - блокировка данных в момент их изменения. Механизм помогает пользователю в автоматическом восстановлении в случае ошибки при подключении других распределенных приложений, таких как Apache HBase.
  • Высоконадёжная регистрация данных - доступ к данным даже в случае, когда один или несколько узлов упали.

Особенности ZooKeeper

Выгоды использования

Выгоды использования ZooKeeper (см. рисунок 4):

  • Процесс простой распределенной координации.
  • Синхронизация - взаимное исключение и сотрудничество между серверными процессами. Этот процесс помогает в Apache HBase для управления конфигурациями.
  • Упорядоченные сообщения.
  • Сериализация - кодирование данных в соответствии с определенными правилами. Необходимо убедиться, что приложение работает стабильно. Этот подход может быть использован в MapReduce для координации очереди для выполнения запущенных потоков.
  • Надежность.
  • Атомарность - передача данных либо завершается успешно полностью, либо терпит неудачу. Транзакции не осуществляются частично.
  • Последовательная согласованность - обновления применяются в том же порядке, в каком они были отправлены.
  • Единый образ системы - независимо от сервера, к которому он подключается, клиент увидит одно и то же представление службы.
  • Своевременность - в течение определенного периода времени клиент имеет up-to-date представление о системе.
Рисунок 4 - Преимущества Zookeeper

Поддерживаемые операции

Узел дерева ZooKeeper называется znode. В связи с этим ZooKeeper API предоставляет следующие операции:

Операция Описание
exists проверяет существование znode и возвращает его метаданные
create создает znode
delete удаляет znode
getData получает данные, ассоциированные с znode
setData ассоциирует новые данные с znode
getChildren получает детей указанного znode
sync дожидается синхронизации узла кластера, к которому подсоединен клиент, и мастера

Эти операции можно разделить по следующим группам:

callback CAS
exists delete
getData setData
getChildren create
sync
Callback — read-only-операции, к которым можно указать callback'и. Callback сработает, когда запрашиваемая сущность изменит ся. Callback сработает не более одного раза. В случае, когда нужно постоянно отслеживать значение, в обработчике события нужно постоянно переподписываться.
CAS — write-запросы. Проблема конкурентного доступа в ZooKeeper'е решена через compare-and-swap: с каждым znode хранится его версия, при изменении её нужно указывать. Если znode уже был изменен, то версия не совпадает, и клиент получит соответственное исключение. Операции из этой группы требуют указания версии изменяемого объекта.
Create — создает новый znode (пару ключ/значение) и возвращает ключ. Кажется странным, что возвращается ключ, если он указывается как аргумент, но дело в том, что ZooKeeper'у в качестве ключа можно указать префикс и сказать, что znode последовательный, тогда к префиксу добавится выровненное число, и результат будет использоваться в качестве ключа. Гарантируется, что создавая последовательные znode с одним и тем же префиксом, ключи будут образовывать возрастающую (в лексико-графическом смысле) последовательность.

Помимо последовательных znode можно создать эфемерные (недолговечные) znode[Источник 4], которые будут удалены, как только клиент отсоединится (соединение между кластером и клиентом в ZooKeeper долго держится открытым). Эфемерные znode не могут иметь детей. Znode может одновременно быть и эфемерным, и последовательным.

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

Система распределенных блокировок

На основе последовательных эфемерных znode и подписках на их удаление можно создать систему распределенных блокировок. Опишем алгоритм блокировки:

1) Создается эфемерный последовательный znode, используя в качестве префикса "_locknode_/guid-lock-", где _locknode_ — имя ресурса, который блокируют, а guid — свежесгенерированный гуид;
2) Получают список детей _locknode_ без подписки на событие;
3) Если созданный на первом шаге znode в ключе имеет минимальный числовой суффикс, выход из алгоритма — ресурс захвачен;
4) Иначе сортируется список детей по суффиксу и вызывается exists с коллбеком на znode, который в полученном списке находится перед тем, что создан на шаге 1;
5) Если получили false, переход на шаг 2, иначе ждать события и переход на шаг 2.

Так как в случае падения любой операции при работе ZooKeeper пользователь не может узнать, прошла операция или нет, ему нужно выносить эту проверку на уровень приложения. Guid нужен как раз для этого: зная его и запросив детей, пользователь может легко определить, создал ли он новый узел или нет, и операцию стоит повторить. Для вычисления суффикса для последовательного znode используется не уникальная последовательность на префикс, а уникальная последовательность на родителя, в котором будет создан znode.[Источник 5]

Производительность

ZooKeeper создан для высокой производительности. Результаты исследований команды разработчиков ZooKeeper в Yahoo! (см. рисунок 5) показывают, что особенно высокую производительность продукт демонстрирует в приложениях, где число операций чтения превышает количество записей, поскольку записи включают синхронизацию состояния всех серверов. (Количество операций чтения превышает количество записей, как правило, для служб координации.)[1]

Рисунок 5 - Пропускная способность ZooKeeper как коэффициент чтения-записи в зависимости от величины ансамбля

Показатель пропускной способности ZooKeeper в зависимости от коэффициента чтения-записи рассмотрен для версии 3.2, работающей на серверах с двумя 2 ГГц Xeon и двумя дисками SATA 15K RPM. Один диск использовался в качестве выделенного лог-устройства ZooKeeper. Снимки были записаны на диск ОС. Запросы на запись и на чтение было сделано по 1 тысяче. Примерно 30 других серверов были использованы для моделирования клиентов. Ансамбль ZooKeeper был настроен так, что лидеры не допускают подключения от клиентов. Тесты также показывают, что это тоже надежно. Надежность в присутствии ошибок показывает, как развертывание реагирует на различные сбои. События, отмеченные на рисунке, следующие:

  • Неудача и восстановление последователя
  • Отказ и восстановление другого подписчика
  • Неудача лидера
  • Отказ и восстановление двух последователей
  • Неудача другого лидера

Надежность

Чтобы показать поведение системы с течением времени при возникновении сбоев, был запущен сервис ZooKeeper, состоящий из 7 машин (см. рисунок 6). Выполнялся тот же тест насыщенности, что и раньше, но на этот раз мы сохранили процент записи на постоянном уровне 30%, что является консервативным соотношением наших ожидаемых рабочих нагрузок.

Рисунок 6 - Надежность при наличии ошибок

Вот несколько важных наблюдений из этого графика:

  • Во-первых, если подписчики терпят неудачу и быстро восстанавливаются, то ZooKeeper способен поддерживать высокую пропускную способность, несмотря на сбой.
  • Во-вторых, алгоритм выбора лидера позволяет системе восстанавливаться достаточно быстро, чтобы предотвратить существенное снижение пропускной способности. По нашим наблюдениям, ZooKeeper требуется менее 200 мс, чтобы выбрать нового лидера.
  • В-третьих, по мере восстановления подписчиков ZooKeeper снова может повысить пропускную способность после начала обработки запросов.

[Источник 6]

Преимущества и недостатки

Преимущества:

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

Недостатки:

  • требуется избыточное количество серверов;
  • требуется время на синхронизацию данных во всех узлах очереди.

Порядок установки

  • Обновить данные о репозиториях
$ sudo apt-get update 
$ sudo apt-get upgrade
  • Скачаем официальный дистрибутив с зеркала и распакуем его
$ wget http://apache-mirror.rbc.ru/pub/apache/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
$ tar -zxf zookeeper-3.4.6.tar.gz
  • Создадим папку для хранения данных
$ mkdir -p zookeeper/data
  • Пропишем путь в конфигурационный файл
# nano zookeeper-3.4.6/conf/zoo.cfg
  • в nano:
tickTime = 2000##!y## 
dataDir = /path/to/zookeeper/data##!y##
clientPort = 2181##!y##
initLimit = 5##!y##
syncLimit = 2##!y##
  • Проверим корректность установки
bin/zkServer.sh start
bin/zkCli.sh

Источники

  1. Release Notes // Apache ZooKeeper™ Releases [2010-2018]. Дата обновления: 17.12.2018. URL: http://zookeeper.apache.org/releases.html (дата обращения: 17.12.2018)
  2. Mirror of Apache Hadoop ZooKeeper - readme packaging // GitHub [2008-2018]. Дата обновления: 19.12.2018. URL:https://github.com/apache/zookeeper/blob/master/README_packaging.txt (дата обращения: 19.12.2018)
  3. Installing Apache ZooKeeper on Windows // Medium [1998-2018]. Дата обновления: 19.12.2018. URL:https://medium.com/@shaaslam/installing-apache-zookeeper-on-windows-45eda303e835 (дата обращения: 19.12.2018)
  4. Live-обзор ZooKeeper // Zookeeper - стой под стрелой [2011-2018]. Дата обновления: 17.12.2018. URL: http://tonsky.livejournal.com/277316.html (дата обращения: 17.12.2018)
  5. Система распределенных блокировок // ZooKeeper или пишем сервис распределенных блокировок [2001-2018]. Дата обновления: 17.12.2018. URL: https://habr.com/post/144708/ (дата обращения: 17.12.2018)
  6. Documentation // Zookeeper 3.4 [2010-2018]. Дата обновления: 17.12.2018. URL: http://zookeeper.apache.org/doc/current/zookeeperOver.html (дата обращения: 17.12.2018)

Примечания

  1. Zookeeper 3.4 [Электронный ресурс]: Documentation / Дата обращения: 17.12.2018. Режим доступа: http://zookeeper.apache.org/doc/current/zookeeperOver.html

Ссылки