HDFS Router-based Federation

Чтобы решить проблему горизонтального расширения HDFS, сообщество Hadoop реализовало архитектуру Federation на основе ViewF в предыдущей версии, а в последней версии Hadoop сообщество реализовало архитектуру Federation на основе Router, а также реализовало поверх В эту архитектуру добавлен ряд функций, расширяющих возможности управления кластером. Маршрутизатор отделяет таблицу монтирования от клиента и решает проблему несогласованных таблиц монтирования В этой статье будут представлены архитектура и функции федерации на основе маршрутизатора HDFS.

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

Архитектура федерации относится к кластеру федерации, образованному объединением нескольких подкластеров.Обычная практика заключается в том, что эти подкластеры будут совместно использовать узлы данных.Тогда отношение сопоставления между пространством имен федерации и пространством имен подкластера поддерживается таблицей монтирования, которая хранится на стороне клиента.В локальном файле конфигурации он анализируется клиентом для доступа к правильному подкластеру. В реализации сообщества для доступа к пространству имен Federation используется новый протокол viewfs://.

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

• Добавлен уровень инкапсуляции в ViewF сообщества, вместо этого используется исходный протокол hdfs://.

• Таблица монтирования хранится в кластере Zookeeper, и клиент периодически проверяет, обновляется ли таблица монтирования.

• Реализована операция переименования между разными подкластерами в кластере Federation.

Но архитектура Федерации также приносит некоторые проблемы,

• Таблица монтирования реализуется клиентом. При изменении логики кода необходимо учитывать совместимость новых и старых клиентов и распространять новые клиенты.

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

Поэтому сообщество предложило новую архитектуру Федерации:Router-based Federation

Чтобы скрыть детали реализации Federation от пользователей, конфигурация и реализация таблицы монтирования отделены от клиента.Естественная идея состоит в том, чтобы ввести новую прокси-службу.Клиент напрямую запрашивает прокси-службу, а затем анализирует mount table.Запрос перенаправляется в правильный подкластер. Мы называем эту прокси-службу маршрутизатором.

Router Rpc Forwarding

Давайте сначала посмотрим, как прокси маршрутизатора пересылает RPC.

Отношения вызова идентифицируются на рисунке. Маршрутизатор начнет службу RouteRPCServer. Этот класс реализует ClientProtocol, как namenoderpcserver, что означает, что клиент может получить доступ к маршрутизатору в качестве NameNode без изменения реализации. Конечно, маршрутизатор также реализует другие протоколы для администраторов для управления маршрутизатором или кластерным состоянием.
После того, как маршрутизатор получает RPC через RouterRpcServe, он отображает соответствующий подкластер и его путь, анализируя таблицу монтирования, а затем создает RPC-клиент, соответствующий NameNode, через ConnectionManager и использует клиента для пересылки RPC.
ConnectionManager поддерживает набор пулов соединений. Информация о группе пользователей, адрес NameNode и протокол каждого RPC вместе составляют ключ пула соединений. Пул соединений будет создавать определенное количество клиентов RPC при его построении, а затем для каждого входящего RPC. , в пуле соединений Найдите простаивающего RPC-клиента для отправки RPC. Когда простаивающего RPC-клиента недостаточно, поток-создатель в фоновом режиме создает новое соединение асинхронно, а поток Cleaner в фоновом режиме отвечает за очистку пула соединений.

Информация о том, как маршрутизатор проксирует пользователей, описана в следующем разделе «Безопасность маршрутизатора».

В Router каждое сопоставление пространства имен федерации с пространством имен подкластера соответствует MountTable, и все MountTable являются таблицами подключения кластера. В MountTableResolver им управляют элементы типа TreeMap, Key — это путь в пространстве имен Federation, Value — соответствующий MountTable. точка, то есть самое длинное совпадение, отличается от оригинальной реализации сообщества ViewFs.вложенная таблица монтирования.

Сообщество также внедрило Resolver, который поддерживает подвешивание пути к нескольким кластерам, что может решить, какой подкластер сопоставить подкаталог на основе заданных правил, таких как последовательное хэширование.
Таблица монтирования задается администратором с помощью команд, но для того, чтобы все маршрутизаторы могли читать последнюю таблицу монтирования и сбрасывать таблицу монтирования после перезагрузки маршрутизатора, где должна храниться таблица монтирования?

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

StateStoreDriver отвечает за связь с хранилищем состояний, которое определяет некоторые базовые интерфейсы GET/PUT и поддерживается службой StateStoreConnectionMonitorService. StateStoreService — это служба, с помощью которой маршрутизатор управляет хранилищем состояний и отвечает за извлечение данных из хранилища состояний и обновление кэша зарегистрированного хранилища записей. То, что хранится в State Store, называется Record, и в настоящее время существует только реализация сериализации на основе protobuf.
Например, таблица монтирования, о которой мы упоминали выше, является реализацией RecordStore, каждая таблица монтирования является записью, и они сериализуются protobuf и хранятся в хранилище состояний.

В приведенной выше архитектуре маршрутизатор может работать как прокси-уровень без сохранения состояния. Однако клиент больше не взаимодействует напрямую с NameNode, и схема аутентификации безопасности для кластеров, отличных от RBF, становится недействительной, поэтому для уровня маршрутизатора существует схема аутентификации безопасности.

В практике HDFS используются две схемы аутентификации, Kerberos и Delegation Token, которые используются одновременно для разных приложений.
Давайте посмотрим, как реализовать уровень маршрутизатора Kerberos.

Очевидно, что мы можем зарегистрировать маршрутизатор как службу в Kerberos, и маршрутизатор аутентифицирует клиента.В то же время маршрутизатор действует как суперпользователь HDFS для передачи информации о пользователе клиента, что может быть реализовано так же просто, как это в код

UserGroupInformation routerUser = UserGroupInformation.getLoginUser();
connUGI = UserGroupInformation.createProxyUser(    
    ugi.getUserName(), routerUser);

Токен делегирования не так просто реализовать.

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

Other Features

В рамках этой архитектуры сообщество также реализовало множество интересных функций.

• Разрешения могут быть установлены на таблице монтирования

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

• Disabled Namespace.

Community Practice

Карта архитектуры RBF сообщества выглядит следующим образом.

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

• Основываясь на Zookeeper, аутентификация токена делегирования может завершиться неудачей, поэтому нам нужно вызвать интерфейс синхронизации или переключиться на строго согласованное хранилище, такое как etcd.

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

• Перебалансировка. Сообщество не внедрило межподкластерную миграцию, но Xiaomi внедрила внутреннее переименование межподкластерной федерации. Мы можем включить эту функцию в решение перебалансировки сообщества в будущем.

Эта статья была впервые опубликована в публичном аккаунте «Облачные технологии Xiaomi», пожалуйста, укажите источник для перепечатки в качестве публичного аккаунта: Xiaomi Cloud Technology, ID: mi-cloud-tech. Оригинальная ссылка:HDFS Router-based Federation