Для чего нужен zookeeper

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Apache ZooKeeper

Содержание

Описание

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

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

Архитектура

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

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

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

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

Сессии

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

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

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

Наблюдатели

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

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

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

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

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

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

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

Callback — read-only-операции, к которым можно указать callback’и. Callback сработает, когда запрашиваемая сущность изменит ся. Callback сработает не более одного раза. В случае, когда нужно постоянно отслеживать значение, в обработчике события нужно постоянно переподписываться. CAS — write-запросы. Проблема конкурентного доступа в ZooKeeper’е решена через compare-and-swap: с каждым znode хранится его версия, при изменении её нужно указывать. Если znode уже был изменен, то версия не совпадает, и клиент получит соответственное исключение. Операции из этой группы требуют указания версии изменяемого объекта. Create — создает новый znode (пару ключ/значение) и возвращает ключ. Кажется странным, что возвращается ключ, если он указывается как аргумент, но дело в том, что 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]

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

Надежность

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

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

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

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

Источник

Zookeeper — Краткое руководство

ZooKeeper — это распределенный сервис координации для управления большим количеством хостов. Координация и управление сервисом в распределенной среде — сложный процесс. ZooKeeper решает эту проблему благодаря своей простой архитектуре и API. ZooKeeper позволяет разработчикам сосредоточиться на основной логике приложения, не беспокоясь о распределенной природе приложения.

Фреймворк ZooKeeper изначально был создан в «Yahoo!» для простого и надежного доступа к их приложениям. Позже Apache ZooKeeper стал стандартом для организованного сервиса, используемого Hadoop, HBase и другими распределенными средами. Например, Apache HBase использует ZooKeeper для отслеживания состояния распределенных данных.

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

Распределенное приложение

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

Распределенное приложение состоит из двух частей: серверного и клиентского приложения. Серверные приложения фактически распределены и имеют общий интерфейс, так что клиенты могут подключаться к любому серверу в кластере и получать тот же результат. Клиентские приложения — это инструменты для взаимодействия с распределенным приложением.

Преимущества распределенных приложений

Надежность. Отказ одной или нескольких систем не приводит к отказу всей системы.

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

Прозрачность — скрывает сложность системы и показывает себя как единое целое / приложение.

Надежность. Отказ одной или нескольких систем не приводит к отказу всей системы.

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

Прозрачность — скрывает сложность системы и показывает себя как единое целое / приложение.

Проблемы распределенных приложений

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

Тупик — две или более операций, ожидающих друг друга до бесконечности.

Несоответствие — Частичный сбой данных.

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

Тупик — две или более операций, ожидающих друг друга до бесконечности.

Несоответствие — Частичный сбой данных.

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

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

Общие услуги, предоставляемые ZooKeeper, следующие:

Служба именования — идентификация узлов в кластере по имени. Это похоже на DNS, но для узлов.

Управление конфигурацией — самая свежая и актуальная информация о конфигурации системы для присоединяющегося узла.

Управление кластером — присоединение / выход узла в кластере и статус узла в режиме реального времени.

Выбор лидера — Выбор узла в качестве лидера для целей координации.

Служба блокировки и синхронизации — блокировка данных при их изменении. Этот механизм помогает вам в автоматическом восстановлении после сбоя при подключении других распределенных приложений, таких как Apache HBase.

Высоконадежный реестр данных — доступность данных, даже когда один или несколько узлов не работают.

Служба именования — идентификация узлов в кластере по имени. Это похоже на DNS, но для узлов.

Управление конфигурацией — самая свежая и актуальная информация о конфигурации системы для присоединяющегося узла.

Управление кластером — присоединение / выход узла в кластере и статус узла в режиме реального времени.

Выбор лидера — Выбор узла в качестве лидера для целей координации.

Служба блокировки и синхронизации — блокировка данных при их изменении. Этот механизм помогает вам в автоматическом восстановлении после сбоя при подключении других распределенных приложений, таких как Apache HBase.

Высоконадежный реестр данных — доступность данных, даже когда один или несколько узлов не работают.

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

Вот преимущества использования ZooKeeper —

Простой распределенный процесс координации

Синхронизация — взаимное исключение и взаимодействие между процессами сервера. Этот процесс помогает в Apache HBase для управления конфигурацией.

Сериализация — кодирование данных в соответствии с определенными правилами. Убедитесь, что ваше приложение работает последовательно. Этот подход можно использовать в MapReduce для координации очереди для выполнения запущенных потоков.

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

Простой распределенный процесс координации

Синхронизация — взаимное исключение и взаимодействие между процессами сервера. Этот процесс помогает в Apache HBase для управления конфигурацией.

Сериализация — кодирование данных в соответствии с определенными правилами. Убедитесь, что ваше приложение работает последовательно. Этот подход можно использовать в MapReduce для координации очереди для выполнения запущенных потоков.

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

Zookeeper — Основы

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

Архитектура ZooKeeper

Посмотрите на следующую диаграмму. Он изображает «клиент-серверную архитектуру» ZooKeeper.

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

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

Точно так же сервер отправляет подтверждение, когда клиент соединяется. Если нет ответа от подключенного сервера, клиент автоматически перенаправляет сообщение на другой сервер.

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

Точно так же сервер отправляет подтверждение, когда клиент соединяется. Если нет ответа от подключенного сервера, клиент автоматически перенаправляет сообщение на другой сервер.

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

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

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

Номер версии — у каждого znode есть номер версии, что означает, что каждый раз, когда данные, связанные с znode, изменяются, его соответствующий номер версии также увеличивается. Использование номера версии важно, когда несколько клиентов zookeeper пытаются выполнить операции на одном и том же znode.

Список управления действиями (ACL) — ACL — это механизм аутентификации для доступа к znode. Он управляет всеми операциями чтения и записи znode.

Timestamp — Timestamp представляет время, прошедшее с момента создания и модификации znode. Обычно он представлен в миллисекундах. ZooKeeper идентифицирует каждое изменение в znodes из «ID транзакции» (zxid). Zxid уникален и поддерживает время для каждой транзакции, так что вы можете легко определить время, прошедшее от одного запроса к другому.

Длина данных — общий объем данных, хранящихся в znode, является длиной данных. Вы можете хранить максимум 1 МБ данных.

Номер версии — у каждого znode есть номер версии, что означает, что каждый раз, когда данные, связанные с znode, изменяются, его соответствующий номер версии также увеличивается. Использование номера версии важно, когда несколько клиентов zookeeper пытаются выполнить операции на одном и том же znode.

Список управления действиями (ACL) — ACL — это механизм аутентификации для доступа к znode. Он управляет всеми операциями чтения и записи znode.

Timestamp — Timestamp представляет время, прошедшее с момента создания и модификации znode. Обычно он представлен в миллисекундах. ZooKeeper идентифицирует каждое изменение в znodes из «ID транзакции» (zxid). Zxid уникален и поддерживает время для каждой транзакции, так что вы можете легко определить время, прошедшее от одного запроса к другому.

Длина данных — общий объем данных, хранящихся в znode, является длиной данных. Вы можете хранить максимум 1 МБ данных.

Типы Знодес

Znodes подразделяются на постоянство, последовательность и эфемерность.

Постоянство znode — Постоянство znode живо даже после того, как клиент, который создал этот конкретный znode, был отключен. По умолчанию все узлы являются постоянными, если не указано иное.

Ephemeral znode — эфемерные znode активны, пока клиент не жив. Когда клиент отключается от ансамбля ZooKeeper, тогда эфемерные узлы удаляются автоматически. По этой причине только эфемерные узлы не могут иметь детей дальше. Если эфемерный znode удален, то следующий подходящий узел займет свою позицию. Эфемерные зводы играют важную роль в выборах лидера.

Последовательный узел — Последовательный узел может быть постоянным или эфемерным. Когда новый znode создается как последовательный znode, ZooKeeper устанавливает путь znode, прикрепляя 10-значный порядковый номер к исходному имени. Например, если znode с путем / myapp создается как последовательный znode, ZooKeeper изменит путь на / myapp0000000001 и установит следующий порядковый номер как 0000000002. Если два последовательных znode создаются одновременно, то ZooKeeper никогда не использует один и тот же номер для каждый зноде. Последовательные узлы играют важную роль в блокировке и синхронизации.

Постоянство znode — Постоянство znode живо даже после того, как клиент, который создал этот конкретный znode, был отключен. По умолчанию все узлы являются постоянными, если не указано иное.

Ephemeral znode — эфемерные znode активны, пока клиент не жив. Когда клиент отключается от ансамбля ZooKeeper, тогда эфемерные узлы удаляются автоматически. По этой причине только эфемерные узлы не могут иметь детей дальше. Если эфемерный znode удален, то следующий подходящий узел займет свою позицию. Эфемерные зводы играют важную роль в выборах лидера.

Последовательный узел — Последовательный узел может быть постоянным или эфемерным. Когда новый znode создается как последовательный znode, ZooKeeper устанавливает путь znode, прикрепляя 10-значный порядковый номер к исходному имени. Например, если znode с путем / myapp создается как последовательный znode, ZooKeeper изменит путь на / myapp0000000001 и установит следующий порядковый номер как 0000000002. Если два последовательных znode создаются одновременно, то ZooKeeper никогда не использует один и тот же номер для каждый зноде. Последовательные узлы играют важную роль в блокировке и синхронизации.

сессии

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

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

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

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

Zookeeper — Рабочий процесс

После запуска ансамбля ZooKeeper он будет ожидать подключения клиентов. Клиенты будут подключаться к одному из узлов в ансамбле ZooKeeper. Это может быть лидер или последователь узла. Как только клиент подключен, узел назначает идентификатор сеанса конкретному клиенту и отправляет подтверждение клиенту. Если клиент не получает подтверждение, он просто пытается подключиться к другому узлу в ансамбле ZooKeeper. После подключения к узлу клиент будет регулярно отправлять тактовые импульсы на узел, чтобы убедиться, что соединение не потеряно.

Если клиент хочет прочитать определенный znode, он отправляет запрос на чтение узлу с путем znode, и узел возвращает запрошенный znode, получая его из своей собственной базы данных. По этой причине чтение происходит быстро в ансамбле ZooKeeper.

Если клиент хочет прочитать определенный znode, он отправляет запрос на чтение узлу с путем znode, и узел возвращает запрошенный znode, получая его из своей собственной базы данных. По этой причине чтение происходит быстро в ансамбле ZooKeeper.

Узлы в ансамбле ZooKeeper

Давайте проанализируем эффект наличия разного количества узлов в ансамбле ZooKeeper.

Если у нас есть два узла и один узел выходит из строя, у нас также нет большинства, так как один из двух не является большинством.

Если у нас есть три узла и один узел выходит из строя, у нас есть большинство и так, это минимальное требование. Для ансамбля ZooKeeper обязательно иметь как минимум три узла в рабочей среде.

Если у нас четыре узла и два узла вышли из строя, он снова выходит из строя, и это похоже на наличие трех узлов. Дополнительный узел не служит какой-либо цели, поэтому лучше добавлять узлы в нечетные числа, например, 3, 5, 7.

Если у нас есть два узла и один узел выходит из строя, у нас также нет большинства, так как один из двух не является большинством.

Если у нас есть три узла и один узел выходит из строя, у нас есть большинство и так, это минимальное требование. Для ансамбля ZooKeeper обязательно иметь как минимум три узла в рабочей среде.

Если у нас четыре узла и два узла вышли из строя, он снова выходит из строя, и это похоже на наличие трех узлов. Дополнительный узел не служит какой-либо цели, поэтому лучше добавлять узлы в нечетные числа, например, 3, 5, 7.

Мы знаем, что процесс записи стоит дороже, чем процесс чтения в ансамбле ZooKeeper, поскольку все узлы должны записывать одни и те же данные в свою базу данных. Таким образом, лучше иметь меньшее количество узлов (3, 5 или 7), чем большое количество узлов для сбалансированной среды.

На следующей диаграмме изображен ZooKeeper WorkFlow, а в следующей таблице поясняются его различные компоненты.

Zookeeper — Лидер Выборы

Давайте проанализируем, как лидерный узел может быть выбран в ансамбле ZooKeeper. Учтите, что в кластере N узлов. Процесс выбора лидера выглядит следующим образом —

Ансамбль ZooKeeper добавит к пути 10-значный порядковый номер, а созданный znode будет / app / leader_election / guid_0000000001, / app / leader_election / guid_0000000002 и т. Д.

Для данного экземпляра узел, который создает наименьшее число в znode, становится лидером, а все остальные узлы являются последователями.

Каждый следящий узел наблюдает за узлом, имеющим следующий наименьший номер. Например, узел, который создает znode / app / leader_election / guid_0000000008, будет наблюдать за znode / app / leader_election / guid_0000000007, а узел, который создает znode / app / leader_election / guid_0000000007, будет смотреть znode / app / leader_election / guid_000000000.

Если лидер отключается, то соответствующий ему znode / app / leader_electionN удаляется.

Следующий в очереди следящий узел получит уведомление от наблюдателя об удалении лидера.

Следующий в строке следящий узел проверит, есть ли другие узлы с наименьшим номером. Если нет, то он возьмет на себя роль лидера. В противном случае он находит узел, который создал znode с наименьшим номером в качестве лидера.

Точно так же все другие узлы-последователи выбирают узел, который создал znode с наименьшим числом в качестве лидера.

Ансамбль ZooKeeper добавит к пути 10-значный порядковый номер, а созданный znode будет / app / leader_election / guid_0000000001, / app / leader_election / guid_0000000002 и т. Д.

Для данного экземпляра узел, который создает наименьшее число в znode, становится лидером, а все остальные узлы являются последователями.

Каждый следящий узел наблюдает за узлом, имеющим следующий наименьший номер. Например, узел, который создает znode / app / leader_election / guid_0000000008, будет наблюдать за znode / app / leader_election / guid_0000000007, а узел, который создает znode / app / leader_election / guid_0000000007, будет смотреть znode / app / leader_election / guid_000000000.

Если лидер отключается, то соответствующий ему znode / app / leader_electionN удаляется.

Следующий в очереди следящий узел получит уведомление от наблюдателя об удалении лидера.

Следующий в строке следящий узел проверит, есть ли другие узлы с наименьшим номером. Если нет, то он возьмет на себя роль лидера. В противном случае он находит узел, который создал znode с наименьшим номером в качестве лидера.

Точно так же все другие узлы-последователи выбирают узел, который создал znode с наименьшим числом в качестве лидера.

Выбор лидера — это сложный процесс, когда он делается с нуля. Но сервис ZooKeeper делает это очень просто. Давайте перейдем к установке ZooKeeper для целей разработки в следующей главе.

Zookeeper — Установка

Перед установкой ZooKeeper убедитесь, что ваша система работает в любой из следующих операционных систем:

Любая из ОС Linux — поддерживает разработку и развертывание. Это предпочтительно для демонстрационных приложений.

ОС Windows — поддерживает только разработку.

Mac OS — поддерживает только разработку.

Любая из ОС Linux — поддерживает разработку и развертывание. Это предпочтительно для демонстрационных приложений.

ОС Windows — поддерживает только разработку.

Mac OS — поддерживает только разработку.

Сервер ZooKeeper создан на Java и работает на JVM. Вам нужно использовать JDK 6 или выше.

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

Шаг 1. Проверка установки Java

Мы считаем, что в вашей системе уже установлена ​​среда Java. Просто проверьте это с помощью следующей команды.

Если на вашем компьютере установлена ​​Java, вы можете увидеть версию установленной Java. В противном случае выполните простые шаги, приведенные ниже, чтобы установить последнюю версию Java.

Шаг 1.1: Загрузите JDK

Загрузите последнюю версию JDK, перейдя по следующей ссылке и загрузите последнюю версию. Джава

Источник