Сегодня рассмотрим компоненты и механизмы обеспечения отказоустойчивости Apache HBase. Что делать, когда региональный сервер выходит из строя и как процедура ServerCrashProcedure перераспределяет регионы данных на другие рабочие сервера в кластере Apache HBase. А также разберем, какие параметры конфигурации следует настроить администратору кластера для наиболее эффективного выполнения процессов записи и восстановления данных.
Регионирование данных в Apache HBase: компоненты и механизмы
Поскольку Apache HBase относится к стеку Big Data, вопрос отказоустойчивости для этой колоночно-ориентированной NoSQL-СУБД, работающей поверх Hadoop HDFS, весьма актуален. Будучи является распределенной СУБД, HBase может работать на десятках и сотнях физических серверов, обеспечивая бесперебойную работу даже при выходе из строя некоторых узлов. Распределение данных по разным физическим машинам кластера обеспечивается механизмом регионирования – автоматической горизонтальной группировки табличных строк. Как распределить данные равномерно, предотвращая появление горячих точек в кластере, читайте в нашей новой статье.
Регион — это диапазон записей, соответствующих определенному диапазону подряд идущих первичных ключей. Каждый регион содержит следующие параметры:
- Persistent Storage — основное хранилище данных, которые физически хранятся на HDFS, в специальном формате HFile, отсортированные по значению первичного ключа (RowKey). Одной паре (регион, column family) соответствует как минимум один HFi
- MemStore— буфер на запись, специально выделенная область памяти для накопления данных перед записью, чтобы не обновлять каждую запись в отсортированном HFile. После заполнения MemStore до некоторого критического значения создается очередной HFile для записи новых данных.
- BlockCache – кэш на чтение, чтобы экономить время на часто читаемые данных.
- Write Ahead Log (WAL) – журнал упреждающей записи, специальный файл для логирования всех операций с данными, чтобы восстановить их в случае сбоя.
Изначально таблица состоит из одного региона, который разбивается на новые по мере роста объема данных, т.е. после превышения заданного порогового размера. Когда таблица становится слишком большой для одного сервера, она разделяется на несколько серверов и обслуживается кластером, на каждом узле которого размещается подмножество регионов этой таблицы. Так механизм регионирования выравнивает распределение нагрузки на таблицу, а общее содержимое распределенной таблицы состоит из множества отсортированных регионов, связанных по сети.
Координатор HBase отслеживает состояние всех региональных серверов, где хранятся участки таблиц (регионы). При этом устанавливаются наблюдатели на узлах в сервисе синхронизации Apache ZooKeeper, которые эфемерно создаются региональными серверами при их запуске. Региональный сервер может быть остановлен по-разному:
- плавная остановка предполагает предварительное перемещение всех регионов с останавливаемого сервера на другие серверы в кластере HBase. Это снижает влияние на доступность на уровне региона.
- вынужденная остановка без предварительного перемещения регионов на другие серверы. Чаще всего это случается, когда сервер останавливается из-за сбоя процесса, оборудования или операционной системы, регионы. В этом случае регионы данных, которые находились на остановленном сервере, должны быть перераспределены между другими серверами кластера Hbase. Эта задача ложится на AssignmentManager координатора, который управляет и выполняет назначение региона, отслеживает ZooKeeper на предмет событий, связанных с переходными регионами и обрабатывает существующие регионы в процессе перехода во время основного аварийного переключения.
Поскольку серверы регионов регистрируются как доступные для обслуживания, помимо прочего, с созданием эфемерного Z-узла, ZooKeeper обрабатывает отслеживание активности всех региональных серверов. Напомним, Zookeeper имитирует виртуальную древовидную файловую систему из взаимосвязанных узлов, которые представляют собой совмещенное понятие файла и директории. Каждый узел этой иерархии (znode, Z-узел) может одновременно хранить данные и иметь подчиненные узлы (потомки). Постоянные узлы (persistent) сохраняют данные на диск и никогда не пропадают, а эфемерные узлы недолговечны – они создаются в рамках конкретной сессии подключения клиента к серверу и существуют только во время ее действия. Такие узлы не имеют потомков, а представляют собой объект, в котором можно временно сохранить какие-то данные.
Эфемерный Z-узел остановленного сервера будет удален после того, как он пропустит отправку мастеру свой периодический heartbeat-сигнал. Координатор регистрирует наблюдателя для получения уведомлений о таких событиях. Когда оно происходит, координатор инициирует процедуру ServerCrashProcedure (SCP) для остановленного сервера. Как это работает, разберем далее.
Как работает ServerCrashProcedure
Если остановленный сервер удерживал какие-либо регионы до того, как был внезапно отключен (вынужденная остановка), ServerCrashProcedure позаботится о перераспределении регионов на другие работающие серверы в кластере следующим образом:
- файл журнала упреждающей записи (WAL, Write Ahead Log) ведется для каждого сервера, но при внесении изменений из WAL во время восстановления они применяются на уровне региона. Для восстановления файл WAL необходимо разделить на файлы по регионам. SCP управляет процессом разделения WAL для остановленного сервера, создавая файлы восстановления (edits) для конкретных регионов. Процесс разделения WAL — это распределенный процесс, в котором задачи разделения WAL назначаются другим действующим региональным серверам.
- Если на остановленном сервере размещался специальный мета-регион, SCP должен открыть его в другом месте, прежде чем переназначать любые другие регионы.
- SCP отвечает за обновление состояния координатора в памяти. Координатор отслеживает состояние всех региональных серверов. Допустимыми являются следующие состояния сервера: ONLINE, CRASHED, SPLITTING_META, SPLITTING_META_DONE, SPLITTING, OFFLINE.
- Если остановленному серверу назначена очередь репликации, SCP должен переназначить его очереди репликации другим рабочим серверам (выпущено в версиях Apache HBase 0.0 и 2.5.0).
- SCP координирует свои действия с процедурой назначения региона TransitRegionStateProcedure (TRSP), чтобы обеспечить плавный переход регионов, которые ранее присутствовали на остановленном сервере.
Процедура SCP реализована как и другие рабочие процессы AssignmentManager, основная обязанность которого в том, чтобы разделить WAL остановленного сервера на файлы для конкретного региона, готовые для воспроизведения при повторном открытии региона. Действия по разделению WAL можно классифицировать на два варианта с отдельными реализациями:
- Координируемое ZooKeeper разбиение WAL, что сегодня считается устаревшей функцией.
- Разбиение WAL на основе процедур, по умолчанию в HBase версии 2.4 и выше.
ServerCrashProcedure выполняется активным координатором для инициирования необходимых действий по восстановлению после остановки или сбоя сервера. Специальная мета-область всегда должна быть доступна. Если остановленный сервер размещал мета-регион, SCP сначала выполняет процесс назначения региона, чтобы убедиться в доступности мета-регион (состояние ONLINE). Это необходимо сделать до разделения WAL.
Затем SCP планирует дочерние процедуры SplitWALProcedure, которые внутренне планируют свою собственную дочернюю процедуру SplitWALRemoteProcedure, чтобы делегировать ответственность за разделение WAL одному из оставшихся активных региональных серверов, выбранному случайным образом. В контексте разделения WAL выбранный региональный сервер называется рабочим (worker). Одна SplitWALProcedure запланирована для каждого файла WAL, и каждая SplitWALProcedure выбирает своих собственных worker’ов. SplitWALManager отслеживает worker’ов для всех SplitWALProcedures и предоставляет служебную логику для их назначения и освобождения по мере необходимости. Процедура SplitWALProcedure назначает worker’а для задачи разделения WAL, делегирует ему задачу и после завершения освобождает, чтобы его можно было получить с помощью другой процедуры.
Рекомендуется ограничить количество задач, которые можно назначить отдельно взятому worker’у, чтобы избежать чрезмерного потребления ресурсов и новых сбоев при восстановлении. Это ограничение настраивается с помощью значения параметра конфигурации hbase.regionserver.wal.max.splitters, по умолчанию равного 2. Таким образом, пиковый уровень параллелизма активности разбиения WAL можно определить как произведение количества онлайн-серверов регионов на максимальное количество настроенных разделителей.
Если все активные серверы уже заняты разделением максимального количества задач, SplitWALProcedure должна ждать и возобновлять работу только после того, как worker станет доступен для выполнения дальнейших задач. Эта стратегия также гарантирует, что задачи разделения WAL будут равномерно распределены между доступными онлайн-серверами. Если несколько региональных серверов обрабатывают задачи медленнее, чем другие, медленные серверы не станут бутылочным горлышком всего кластера Apache HBase.
На региональном сервере WALSplitter отвечает за разделение файлов WAL. HBase позволяет администратору гибко структурировать и управлять низкоуровневыми деталями, специфичными для региона, с помощью модели плагинов. OutputSink предоставляет общий интерфейс для поддержки различных способов разделения файла WAL на файлы воспроизведения для конкретного региона в зависимости от реализации низкоуровневых сведений о регионе. По умолчанию для этой операции используются три потока записи. Количество потоков записи можно настроить с помощью параметра конфигурации hbase.regionserver.hlog.splitlog.writer.threads. Как только все задачи разделения WAL для данной процедуры SplitWALProcedure успешно завершены, SCP очищает WAL остановленного регионального сервера и завершает свою работу, переназначая все регионы, которые там ранее размещались, другим онлайн-серверам в сети. При этом кластер HBase использует обычную процедуру назначения региона TransitRegionStateProcedure (TRSP), о которой мы поговорим в следующий раз.
Файлы для каждого региона (recovery.edits), созданные SCP для восстановления, обрабатываются региональным сервером как часть обычного процесса открытия региона. При записи мутации на уровне региона собираются и сортируются в памяти MemStore. Когда это хранилище памяти достигает настроенного предела, текущий моментальный снимок его содержимого агрегируется и записывается на диск как новый HFile. Если для региона существует файл восстановления (recovery.edits), сервер регионов воспроизводит эти изменения в хранилище памяти перед тем, как пометить регион как доступный (состояние ONLINE). В рамках этого процесса воспроизведения все записи в файле restore.edits добавляются в хранилище памяти региона, а затем инициируется сброс хранилища памяти. Если изменения в файле воспроизведения уже сохранены в существующих HFiles, можно выполнить оптимизацию путем присвоения каждому edit-файлу порядкового номера. Обнаружив какую-либо запись в restore.edits с меньшим порядковым номером, чем есть в метаданных хранилища, эту конкретную запись можно пропустить, поскольку она уже была сохранена в регионе. Метаданные региона также отслеживают максимальный сброшенный порядковый номер и гарантируют, что никакие изменения не будут записаны в хранилище памяти региона, которое уже было ранее обработано и сохранено.
Читайте в нашей новой статье о том, как администраторы и дата-инженеры индийской ecommerce-компании Flipkart обеспечили изоляцию данных и сбалансированное распределение по регионам в мультиарендном кластере Apache HBase.
Освойте администрирование и эксплуатацию Apache HBase и других NoSQL-решений для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
