Важно: Данный раздел актуален для Платформы данных On-Premise.
RT.DataLake представляет собой масштабируемую платформу с открытым исходным кодом, предназначенную для хранения, обработки и анализа больших объёмов данных.
Платформа спроектирована так, чтобы обеспечить быструю, лёгкую и не затратную загрузку данных различного формата из большого количества источников.
Платформа представляет собой комплекс сервисов, которые обеспечивают не только хранение и обработку данных, но и управление, безопасность и операции.
Платформа включает в себя Hadoop, который состоит из MapReduce, Hadoop Distributed File System (HDFS) и Yet Another Resource Negotiator (YARN), а также другие компоненты экосистемы Apache Hadoop.
Все компоненты интегрированы друг с другом и протестированы на совместимость.
В главе представлен обзор функционала HDFS Federation, а также настройки и управление кластером.
HDFS имеет два основных слоя:
1. Namespace:
2. Block Storage Service:
Предыдущая архитектура HDFS допускает только одно пространство имен для всего кластера и им управляет один Namenode. HDFS Federation устраняет это ограничение, добавляя поддержку нескольких Namenodes/Namespaces в HDFS.
Для горизонтального масштабирования сервиса имён Federation использует несколько независимых Namenodes/Namespaces. Узлы Namenodes федеративные, они независимы и не требуют координации друг с другом. Узлы Datanodes используются в качестве общего хранилища для блоков всех Namenodes, и каждая Datanode регистрируется со всеми Namenodes в кластере. Datanodes посылают периодические heartbeats-сообщения и обрабатывают команды из Namenodes.
Пользователи могут использовать ViewFs для создания персонализированных представлений пространства имён. ViewFs аналогичен mount-таблицам на стороне клиента в некоторых системах Unix/Linux.
Block Pool — это набор блоков, принадлежащих одному пространству имён. Узлы Datanodes хранят блоки для всех пулов в кластере. Каждый пул блоков управляется независимо, что позволяет пространству имён генерировать идентификаторы блоков для новых блоков без необходимости координации с другими пространствами имён. При этом сбой Namenode не препятствует тому, чтобы Datanode обслуживал другие Namenodes в кластере.
Пространство имён и его пул блоков вместе называются Namespace Volume. Это самостоятельная единица управления. Когда Namenode/Namespace удаляется, удаляется и соответствующий ему пул блоков в Datanodes. И каждый Namespace Volume обновляется как единое целое во время обновления кластера.
Идентификатор ClusterID используется для идентификации всех узлов в кластере. При форматировании Namenode этот идентификатор либо предоставляется, либо генерируется автоматически.
Ключевые преимущества:
Конфигурация Federation обратно совместима и позволяет существующим конфигурациям с одним Namenode работать без каких-либо изменений. Новая конфигурация разработана таким образом, что все узлы в кластере имеют одинаковую конфигурацию, не зависящую от типа узла в кластере.
Federation добавляет новую абстракцию NameServiceID. Namenode и соответствующие ему вторичные/резервные/контрольные узлы (secondary/backup/checkpointer) — все принадлежат NameServiceId. Для поддержки одного файла конфигурации к параметрам настроек Namenode и соответствующих ему узлов добавляется суффикс NameServiceID:
Пример конфигурации с двумя Namenodes:
<configuration>
<property>
<name>dfs.nameservices</name>
<value>ns1,ns2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns1</name>
<value>nn-host1:rpc-port</value>
</property>
<property>
<name>dfs.namenode.http-address.ns1</name>
<value>nn-host1:http-port</value>
</property>
<property>
<name>dfs.namenode.secondary.http-address.ns1</name>
<value>snn-host1:http-port</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns2</name>
<value>nn-host2:rpc-port</value>
</property>
<property>
<name>dfs.namenode.http-address.ns2</name>
<value>nn-host2:http-port</value>
</property>
<property>
<name>dfs.namenode.secondary.http-address.ns2</name>
<value>snn-host2:http-port</value>
</property>
.... Other common configuration ...
</configuration>Форматирование Namenodes осуществляется в два шага:
1. Отформатировать Namenode, используя команду:
[hdfs]$ $HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>]Необходимо выбрать уникальный cluster_id, который не будет конфликтовать с другими кластерами в среде. Если параметр не указан, то он генерируется автоматически.
2. Отформатировать дополнительные Namenodes, используя команду:
[hdfs]$ $HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>Важно обратить внимание, что cluster_id на этом шаге должен быть таким же, как в предыдущем. Если они отличаются, дополнительные Namenodes не будут частью кластера Federation.
В процессе обновления с предыдущего релиза и настройки Federation необходимо указать ClusterID следующим образом:
[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon start namenode -upgrade -clusterId <cluster_ID>Если cluster_id не указан, он генерируется автоматически.
Добавление нового Namenode в существующий кластер HDFS осуществляется в результате следующих действий:
[hdfs]$ $HADOOP_HOME/bin/hdfs dfsadmin -refreshNamenodes <datanode_host_name>:<datanode_rpc_port>Команда для запуска кластера:
[hdfs]$ $HADOOP_HOME/sbin/start-dfs.shКоманда для остановки кластера:
[hdfs]$ $HADOOP_HOME/sbin/stop-dfs.shКоманды можно запускать с любого узла, где доступна конфигурация HDFS. Команда использует конфигурацию для определения Namenodes в кластере, а затем запускает процесс Namenode на этих узлах. Datanodes запускаются на узлах, указанных в файле workers. Скрипт можно использовать в качестве ссылки для создания собственных сценариев запуска и остановки кластера.
Для работы с несколькими Namenodes в Balancer:
[hdfs]$ $HADOOP_HOME/bin/hdfs --daemon start balancer [-policy <policy>]Параметр политики может быть любым из следующих:
|
Внимание. Balancer балансирует только данные и не балансирует пространство имён. |
Вывод из эксплуатации следующий — узлы, которые должны быть выведены из эксплуатации, добавляются в файл exclude на всех Namenodes. Каждый Namenode выводит из строя свой Block Pool. Когда все Namenodes завершают вывод из эксплуатации Datanode, узел Datanode считается списанным:
1. Команда для распространения файла exclude на все Namenodes:
[hdfs]$ $HADOOP_HOME/sbin/distribute-exclude.sh <exclude_file>2. Обновление всех Namenodes для получения нового файла exclude:
[hdfs]$ $HADOOP_HOME/sbin/refresh-namenodes.shКоманда использует конфигурацию HDFS для определения настроенных Namenodes в кластере и обновляет их, чтобы получить новый файл exclude.
Подобно веб-странице статуса Namenode, при использовании Federation веб-консоль кластера доступна для мониторинга по адресу http://<any_nn_host:port>/dfsclusterhealth.jsp. Любой Namenode в кластере может быть использован для доступа к этой веб-странице.
Веб-консоль кластера предоставляет следующую информацию:
Репликация всегда дорогостоящая — схема репликации по умолчанию (3x) в HDFS имеет 200% накладных расходов в области хранения и других ресурсах (например, пропускная способность сети). Однако для тёплых и холодных наборов данных с относительно низким уровнем операций ввода-вывода дополнительные реплики блоков редко доступны во время обычных операций, но все равно потребляют тот же объём ресурсов, что и первая реплика.
Поэтому естественным улучшением является использование Erasure Coding (EC) вместо репликации, что обеспечивает тот же уровень отказоустойчивости при гораздо меньшем объёме памяти. В типичных настройках Erasure Coding накладные расходы на хранение не превышают 50%. Коэффициент репликации файла EC не имеет смысла, он всегда равен 1 и не может быть изменен с помощью -setrep команды.
В системах хранения наиболее заметным использованием Erasure Coding является избыточный массив недорогих дисков (RAID). RAID реализует EC посредством чередования, которое делит логически последовательные данные (например, файл) на более мелкие единицы (например, бит, байт или блок) и сохраняет последовательные единицы на разных дисках. Далее данная единица распределения чередования называется чередующейся ячейкой (или просто ячейкой). Для каждой полосы исходных ячеек данных вычисляется и сохраняется определенное количество ячеек четности — процесс, который называется кодированием. Ошибка в любой чередующейся ячейке может быть исправлена путём вычисления декодирования на основе сохранившихся данных и чётности ячеек.
Интеграция Erasure Coding с HDFS может повысить эффективность хранилища, обеспечивая при этом такую же долговечность данных, что и традиционные развертывания HDFS на основе репликации. Например, 3х-реплицированный файл с 6 блоками будет занимать 6 * 3 = 18 блоков дискового пространства. Но при развёртывании EC (6 данных, 3 чётности) он будет занимать только 9 блоков дискового пространства.
В контексте Erasure Coding чередование имеет несколько важных преимуществ. Во-первых, позволяется онлайн запись данных непосредственно в формате EC, избегая фазы преобразования и немедленно экономя место для хранения. Это также повышает производительность последовательного ввода-вывода за счёт параллельного использования нескольких дисков, что особенно желательно в кластерах с высокопроизводительными сетями. Во-вторых, небольшие файлы естественным образом распределяются на несколько узлов данных DataNodes и устраняется необходимость объединения нескольких файлов в одну группу кодирования. Это значительно упрощает операции с файлами, такие как удаление, quota reporting и миграция между объединёнными пространствами имён Namespaces.
В типичных кластерах HDFS небольшие файлы могут занимать более 3/4 общего объёма памяти. Чтобы лучше поддерживать небольшие файлы, на этом первом этапе работы HDFS поддерживает EC с чередованием. В будущем HDFS также будет поддерживать смежную компоновку EC.
1. Расширения NameNode — чередующиеся файлы HDFS, логически состоящие из групп блоков, каждая из которых содержит определённое количество внутренних блоков. Чтобы уменьшить потребление памяти NameNode от этих дополнительных блоков, введён новый иерархический протокол именования блоков. Идентификатор группы блоков может быть выведен из идентификатора любого из её внутренних блоков. Это позволяет управлять на уровне группы блоков, а не на уровне одного блока.
2. Клиентские расширения — клиентские пути чтения и записи улучшены для параллельной работы с несколькими внутренними блоками в группе блоков. На пути вывода/записи DFSStripedOutputStream управляет набором потоков данных, по одному для каждого DataNode, хранящего внутренний блок в текущей группе блоков. Стримеры в основном работают асинхронно. Координатор отвечает за операции над всей группой блоков, включая завершение текущей группы блоков, выделение новой группы блоков и так далее. На пути ввода/чтения DFSStripedInputStream преобразует запрошенный логический байтовый диапазон данных в виде диапазонов во внутренние блоки, хранящиеся в DataNodes. Затем параллельно выдаются запросы на чтение. А при сбоях выдаются дополнительные запросы на чтение для декодирования.
3. Расширения DataNode — DataNode запускает дополнительную задачу ErasureCodingWorker (ECWorker) для фонового восстановления сбойных блоков Erasure Coded. Сбойные блоки EC обнаруживаются NameNode, который затем выбирает DataNode для выполнения работы по восстановлению. Задача восстановления передаётся как ответ на heartbeat-сообщение. Этот процесс аналогичен тому, как реплицированные блоки повторно реплицируются при сбое. Реконструкция выполняет три ключевые задачи:
4. Политики Erasure Coding — файлам и каталогам в кластере HDFS разрешается использование разных политик репликации и кодирования для обеспечения разнородных рабочих нагрузок. Политика Erasure Coding инкапсулирует способ кодирования/декодирования файла. Каждая политика определяется следующей информацией:
Политики называются codec-num data blocks-num parity blocks-cell size. В настоящее время поддерживаются пять встроенных политик: RS-3-2-1024k, RS-6-3-1024k, RS-10-4-1024k, RS-LEGACY-6-3-1024k, XOR-2-1- 1024k.
Схема по умолчанию REPLICATION также поддерживается. Её можно установить только для каталога, чтобы заставить каталог принимать схему репликации 3x, а не наследовать политику erasure coding родительского каталога верхнего уровня. Политика позволяет чередовать каталог схемы репликации 3x с каталогом erasure coding.
Политика REPLICATION всегда включена. Из всех политик EC по умолчанию включена RS(6,3).
Подобно политикам хранения HDFS, политики erasure coding устанавливаются на каталог. При создании файла он наследует политику EC своего ближайшего каталога-родителя.
Политики EC уровня каталога влияют только на новые файлы, созданные в этом каталоге. Как только файл создан, его политику можно запросить, но не изменить. Если erasure coding файл переименовывается в каталог с другой политикой EC, файл принимает политику нового каталога EC. Преобразование файла в другую политику ЕС требует перезаписи его данных; поэтому рекомендуется копировать файл (например, через distcp), а не переименовывать его.
Пользователям позволяется определять свои собственные политики EC с помощью XML-файла, который должен состоять из следующих трёх частей:
Пример XML-файла политики ЕС с именем user_ec_policies.xml.template находится в каталоге Hadoop conf.
5. Intel ISA-L расшифровывается как Intel Intelligent Storage Acceleration Library — это набор оптимизированных низкоуровневых функций с открытым исходным кодом, предназначенных для приложений хранения данных. Библиотека включает в себя быстрые блочные erasure codes типа Reed-Solomon, оптимизированные для наборов команд Intel AVX и AVX2. HDFS erasure coding может использовать ISA-L для ускорения вычислений кодирования и декодирования. ISA-L поддерживает большинство основных операционных систем, включая Linux и Windows. ISA-L не включена по умолчанию.
Erasure coding предъявляет к кластеру дополнительные требования с точки зрения процессора и сети.
Работа по кодированию и декодированию требует дополнительных ресурсов ЦП как для клиентов HDFS, так и для узлов DataNodes.
Для Erasure coding требуется как минимум столько же DataNodes в кластере, сколько сконфигурировано блоков файловой системы EC. Для ЕС политики RS (6,3) это означает минимум 9 узлов DataNodes.
Файлы erasure coding распределяются по стойкам с целью обеспечения её отказоустойчивости. Это означает, что при чтении и записи чередующихся файлов большинство операций выполняется вне стойки. Таким образом, пропускная способность bisection-сети очень важна.
Для отказоустойчивости стойки также важно иметь достаточное количество стоек, чтобы в среднем каждая стойка содержала количество блоков не большее, чем количество блоков чётности EC. Формула для расчёта получается: (блоки данных + блоки чётности) / блоки чётности с округлением в большую сторону. Для политики ЕС RS (6,3) это означает минимум 3 стойки, рассчитанные по формуле (6 + 3) / 3 = 3, но в идеале должно быть 9 или более для обработки запланированных и незапланированных отключений. Для кластеров с меньшим количеством стоек, чем число ячеек чётности, HDFS не может поддерживать отказоустойчивость стойки, но при этом все равно пытается распределить чередующийся файл по нескольким узлам для сохранения отказоустойчивости на уровне узла. По этой причине рекомендуется устанавливать стойки с одинаковым количеством узлов DataNodes.
По умолчанию все встроенные политики erasure coding отключены, за исключением политики, определенной в dfs.namenode.ec.system.default.policy. Администратор кластера может включить набор политик с помощью команды hdfs ec [-enablePolicy -policy <policyName>] в зависимости от размера кластера и требуемых свойств отказоустойчивости. Например, для кластера с 9 стойками такая политика, как RS-10-4-1024k, не сохранит отказоустойчивость на уровне стойки, и RS-6-3-1024k или RS-3-2-1024k могут быть более подходящими. Если администратор заботится об отказоустойчивости только на уровне узла, политика RS-10-4-1024k будет по-прежнему уместной, если в кластере есть по крайней мере 14 DataNodes.
Системная политика ЕС по умолчанию может быть настроена через конфигурацию dfs.namenode.ec.system.default.policy. В этой конфигурации политика EC по умолчанию будет использоваться, когда имя политики не передаётся в качестве аргумента в команде -setPolicy.
По умолчанию dfs.namenode.ec.system.default.policy — RS-6-3-1024k.
Реализация codec для Reed-Solomon и XOR может быть настроена с помощью следующих ключей конфигурации клиента и DataNode: io.erasurecode.codec.rs.rawcoders для RS codec по умолчанию; io.erasurecode.codec.rs-legacy.rawcoders для предыдущих версий RS codec; io.erasurecode.codec.xor.rawcoders для XOR codec.
Пользователь также может настроить самостоятельный кодек с помощью ключа конфигурации, например: io.erasurecode.codec.self-defined-codec.rawcoders. Значения для этого ключа являются списками имён кодеров с резервным механизмом. Эти фабрики кодеков загружаются в заданном значениями конфигурации порядке до тех пор, пока кодек не будет загружен успешно. Конфигурация кодека RS и XOR по умолчанию предпочитает нативную реализацию по сравнению с чистой Java. Реализация нативного кодека RS-LEGACY отсутствует, поэтому по умолчанию используется только реализация Java. Все перечисленные кодеки имеют реализации на чистой Java. Для стандартного кодека RS и кодека XOR существует также собственная реализация, использующая библиотеку Intel ISA-L для повышения производительности кодека. Реализация по умолчанию для RS Legacy — это чистая Java, а реализации по умолчанию для RS и XOR по умолчанию — это собственные реализации, использующие библиотеку Intel ISA-L.
Работы по восстановлению Erasure coding background для узлов DataNodes можно настроить с помощью следующих параметров конфигурации:
Собственная реализация стандартного кодека RS в HDFS использует библиотеку Intel ISA-L в целях улучшения вычислений кодирования и декодирования. Чтобы включить и использовать Intel ISA-L, необходимо выполнить три шага:
Чтобы убедиться, что ISA-L правильно определена в Hadoop, необходимо выполнить команду hadoop checknative.
HDFS предоставляет подкоманду ec для выполнения административных команд, связанных с erasure coding:
hdfs ec [generic options]
[-setPolicy -path <path> [-policy <policyName>] [-replicate]]
[-getPolicy -path <path>]
[-unsetPolicy -path <path>]
[-listPolicies]
[-addPolicies -policyFile <file>]
[-listCodecs]
[-enablePolicy -policy <policyName>]
[-disablePolicy -policy <policyName>]
[-help [cmd ...]]Подробнее о каждой команде:
-replicate и -policy <policyName> опциональные аргументы, и они не могут быть указаны одновременно.
Некоторые операции HDFS, такие как hflush, hsync, concat, setReplication, truncate и append, не поддерживаются файлами erasure coding из-за существенных технических проблем:
Клиент может использовать StreamCapabilities API для запроса, поддерживает ли OutputStream операции hflush() и hsync(). Если клиенту требуется постоянство данных с помощью этих функций, текущим решением является создание таких файлов, как обычные файлы репликации 3x, в каталоге без erasure coding, или использование FSDataOutputStreamBuilder#replicate() API для создания файлов репликации 3x в каталоге erasure coding.
HDFS позволяет администратору устанавливать квоты на количество используемых имён и объём пространства для отдельных каталогов. Квоты имён и квоты пространства работают независимо, но администрирование и реализация этих двух типов квот тесно параллельны.
Квота имён — это жёсткое ограничение на количество имён файлов и каталогов в root-дереве директории со следующими правилами:
Квоты постоянны благодаря fsimage. При запуске, если fsimage нарушает квоту (возможно, при скрытном изменении fsimage), выдаётся предупреждение для каждого из таких нарушений. Установка или удаление квоты создает запись в журнале.
Квота пространств — это жёсткое ограничение на количество байт, используемых файлами в root-дереве директории со следующими правилами:
Квоты постоянны благодаря fsimage. При запуске, если fsimage нарушает квоту (возможно, при скрытном изменении fsimage), выдаётся предупреждение для каждого из таких нарушений. Установка или удаление квоты создает запись в журнале.
Квота типа хранилища — это жёсткое ограничение на использование определенного типа хранилища (SSD, DISK, ARCHIVE) для файлов в root-дереве директории. Во многих аспектах она работает аналогично квоте дискового пространства, но предлагает точный контроль над использованием пространства хранения кластера. Для установки квоты в каталоге должны быть настроены политики хранения, чтобы разрешить хранение файлов в разных типах хранилища в соответствии с политикой.
Квота типа хранилища может быть объединена с квотами пространств и квотами имён для эффективного управления используемого хранилища кластера. Например:
Квоты управляются набором команд, доступных только администратору:
Расширение команды count оболочки HDFS сообщает о значениях квот и текущем количестве используемых имён и байт:
hadoop fs -count -q [-h] [-v] [-t [comma-separated list of storagetypes]] <directory>...<directory>Где:
Снапшот HDFS — это снимок файловой системы на момент времени, доступен только для чтения. Снапшоты могут быть сделаны в поддереве файловой системы или во всей файловой системе. Распространённые случаи использования моментальных снимков — резервное копирование данных, защита от ошибок пользователя и аварийное восстановление.
Реализация снапшотов HDFS очень рациональна:
Снапшоты могут быть сделаны в любом каталоге, как только этот каталог установлен как snapshottable. Каталог snapshottable способен вместить 65 536 одновременных снимков, при этом количество директорий snapshottable не ограничено. Администраторы могут задать для любого каталога значение snapshottable. Данный каталог нельзя ни удалить, ни переименовать, пока в нём находятся снапшоты.
Вложенные каталоги в snapshottable в настоящее время не допускаются. Другими словами, директория не может быть установлена как snapshottable, если хотя бы один её каталог-родитель или каталог-потомок является snapshottable.
Для доступа к снапшотам каталога snapshottable используется компонент пути .snapshot. Например, /foo — каталог snapshottable, тогда /foo/bar является файлом/директорией в нём, где /foo имеет снапшот s0. В результате путь /foo/.snapshot/s0/bar ссылается на копию снимка /foo/bar. Обычный API и CLI могут работать с путями .snapshot. Далее приведены некоторые примеры.
hdfs dfs -ls /foo/.snapshot
hdfs dfs -ls /foo/.snapshot/s0
hdfs dfs -cp -ptopax /foo/.snapshot/s0/bar /tmp
|
Внимание. В примере используется опция preserve для сохранения меток времени, владельца, прав доступа, списков ACL и XAttrs. |
Функция снапшота в HDFS вводит новое зарезервированное имя пути, используемое для взаимодействия со снимками: .snapshot. При обновлении с более старой версии HDFS, которая не поддерживает снапшоты, существующие пути с именем .snapshot необходимо сначала переименовать или удалить, чтобы избежать конфликта с зарезервированным путём в актуальной версии системы.
Описанные далее операции возможны только при наличии привилегий суперпользователя.
1. Разрешение создания снапшотов. При успешном завершении операции каталог становится snapshottable.
Команда:
hdfs dfsadmin -allowSnapshot <path>Аргумент:
2. Запрещение на создание снапшотов в каталоге. Все снапшоты директории должны быть удалены перед введением запрета.
Команда:
hdfs dfsadmin -disallowSnapshot <path>Аргумент:
Далее описываются пользовательские операции над снапшотами. При этом суперпользователь HDFS может выполнять все операции, не удовлетворяя требованиям разрешения для отдельных операций.
1. Создание снапшота в каталоге snapshottable. Операция требует привилегии владельца директории.
Команда:
hdfs dfs -createSnapshot <path> [<snapshotName>]Аргумент:
2. Удаление снапшота из каталога snapshottable. Операция требует привилегии владельца директории.
Команда:
hdfs dfs -deleteSnapshot <path> <snapshotName>Аргумент:
3. Переименование снапшота. Операция требует привилегии владельца каталога snapshottable.
Команда:
hdfs dfs -renameSnapshot <path> <oldName> <newName>Аргумент:
4. Получение списка всех каталогов snapshottable, где у текущего пользователя есть разрешение на создание снапшотов.
Команда:
hdfs lsSnapshottableDir5. Получение различия между двумя снапшотами. Операция требует прав доступа на чтение для всех файлов/каталогов в обоих снапшотах.
Команда:
hdfs snapshotDiff <path> <fromSnapshot> <toSnapshot>Аргумент:
Возможные результаты проведенных операций:
Запись RENAME указывает, что файл/каталог переименован, но все ещё находится в той же директории snapshottable. Файл/каталог считается удалённым, если он переименован за пределами директории snapshottable. Файл/каталог, переименованный из внешней директории snapshottable, считается вновь созданным.
Отчёт о различиях снапшотов не гарантирует одинаковую последовательность вывода результатов операций. Например, если переименовать каталог /foo в /foo2, а затем добавить новые данные в файл /foo2/bar, то отчёт о различиях следующий:
R. /foo -> /foo2
M. /foo/barТо есть об изменениях файлов/каталогов в переименованном каталоге сообщается с использованием исходного пути.
В главе описывается использование списков контроля доступа (ACL) в HDFS. ACL расширяет модель разрешения HDFS для поддержки более детального доступа к файлам на основе произвольных комбинаций пользователей и групп.
По умолчанию ACL отключены и NameNode отклоняет все попытки установить их. Например:
<property>
<name>dfs.namenode.acls.enabled</name>
<value>true</value>
</property>Для включения ACL в HDFS необходимо в файле hdfs-site.xml установить свойству dfs.namenode.acls.enabled значение true.
В FsShell используется две подкоманды: setfacl и getfacl. Они моделируются после одних и тех же команд Linux, но при этом реализуют меньше флагов. Поддержка дополнительных флагов может быть добавлена позже.
Применение:
-setfacl [-bkR] {-m|-x} <acl_spec> <path> -setfacl --set <acl_spec> <path>Функции команды:
Например:
hdfs dfs -setfacl -m user:hadoop:rw- /file
hdfs dfs -setfacl -x user:hadoop /file
hdfs dfs -setfacl -b /file
hdfs dfs -setfacl -k /dir
hdfs dfs -setfacl --set user::rw-,user:hadoop:rw-,group::r--,other::r-- /file
hdfs dfs -setfacl -R -m user:hadoop:r-x /dir
hdfs dfs -setfacl -m default:user:hadoop:r-x /dirКод выхода: при успехе 0 и ненулевое значение при ошибке.
-getfacl [-R] <path>Функции команды:
Например:
hdfs dfs -getfacl /file
hdfs dfs -getfacl -R /dirКод выхода: при успехе 0 и ненулевое значение при ошибке.
Архивные хранилища позволяют хранить данные на физических носителях с высокой плотностью хранения и низкими ресурсами обработки.
Для реализации архивного хранилища необходимо:
Для обновления параметра политики хранения в файле или каталоге необходимо использовать инструмент переноса данных HDFS для перемещения блоков, как указано в новой политике хранения.
Типы хранилищ HDFS могут использоваться для данных, предназначенных различным типам физических носителей. Доступны следующие типы хранилищ:
На дисках типа DISK или ARCHIVE можно хранить данные, используя следующие предварительно настроенные политики хранения:
|
Внимание. В настоящее время политики хранения нельзя редактировать. |
Для настройки архивного хранилища необходимо выполнить следующие действия:
1. Выключить DataNode.
Закрыть DataNode с помощью соответствующих команд.
2. Назначить тип хранения ARCHIVE.
Для назначения типа хранения ARCHIVE для DataNode можно использовать свойство dfs.name.dir в файле /etc/hadoop/conf/hdfs-site.xml.
Свойство dfs.name.dir определяет, где в локальной файловой системе DataNode хранит свои блоки.
Чтобы назначить DataNode как хранилище DISK, необходимо использовать путь к локальной файловой системе. Поскольку DISK является типом памяти по умолчанию, ничего не требуется. Например:
<property>
<name>dfs.data.dir</name>
<value>file:///grid/1/tmp/data_trunk</value>
</property>Чтобы назначить DataNode как хранилище ARCHIVE, необходимо добавить [ARCHIVE] в начало пути локальной файловой системы. Например:
<property>
<name>dfs.data.dir</name>
<value>[ARCHIVE]file:///grid/1/tmp/data_trunk</value>
</property>3. Установка и получение политики хранения.
Необходимо установить политику хранения файла или каталога:
hdfs dfsadmin -setStoragePolicy <path> <policyName>Аргументы:
Пример:
hdfs dfsadmin -setStoragePolicy /cold1 COLDПолучение политики хранения файла или каталога осуществляется по команде:
hdfs dfsadmin -getStoragePolicy <path>Аргументы:
Пример:
hdfs dfsadmin -getStoragePolicy /cold14. Запуск DataNode.
Запустить DataNode с помощью соответствующих команд.
5. Использовать mover для применения политик хранения.
При обновлении параметра политики хранения в файле или каталоге новая политика не применяется автоматически. Необходимо использовать инструмент переноса данных HDFS — mover для фактического перемещения блоков (как указано в новой политике хранения).
Средство миграции данных mover сканирует выбранные файлы в HDFS и проверяет, соответствует ли размещение блоков политике хранения. Копии блоков, нарушающих политику хранения, он перемещает в соответствующий тип хранилища для выполнения требований политики.
Команда:
hdfs mover [-p <files/dirs> | -f <local file name>]Аргументы:
|
Внимание. Если оба параметра -p и -f опущены, путь по умолчанию является корневым каталогом. |
Пример:
hdfs mover /cold1/testfileВ главе приведены инструкции по настройке и использованию централизованного кэша в HDFS, который позволяет указать пути к каталогам или файлам для кэширования в HDFS, тем самым повышая производительность приложений, которые неоднократно обращаются к одним и тем же данным. Процесс осуществляется путем связывания NameNode с DataNodes, которые имеют требуемые доступные блоки на диске, и DataNodes кэшируют эти блоки.
Централизованное управление кэшем в HDFS даёт много существенных преимуществ:
Централизованное управление кэшем полезно:
В архитектуре NameNode отвечает за координацию всех кэш-файлов с неактивными данными в кластере. NameNode периодически получает кэш-отчет от каждого DataNode. Кэш-отчёт описывает все блоки, кэшированные в DataNode. NameNode управляет кэшами DataNode с помощью кэш-копий и мгновенных команд uncache.
NameNode запрашивает набор Cache Directives, чтобы определить, какие контуры следует кэшировать. Cache Directives постоянно сохраняются в fsimage и журналах и могут быть добавлены, удалены и изменены с помощью Java и API-интерфейсов командной строки. В NameNode также хранится набор Cache Pools, являющийся административным объектом, который группирует Cache Directives для управления ресурсами, а также для обеспечения прав доступа.
NameNode периодически повторно сканирует пространство имён и актив Cache Directives, чтобы определить, какие блоки нужно кэшировать, а какие нет, и назначает задачи кэширования DataNodes. Повторное сканирование также может быть вызвано действиями пользователя, такими как добавление или удаление Cache Directives или удаление Cache Pools.
Блоки кэша, находящиеся в стадии разработки, повреждённые или неполные, не кэшируются. Если Cache Directives содержит ссылку, адрес ссылки не кэшируется.
|
Внимание. В настоящее время кэширование может применяться только к каталогам и файлам. |
Cache Directive определяет контур для кэширования. Пути могут указывать либо каталоги, либо файлы. Каталоги кэшируются не рекурсивно, то есть кэшируются только файлы в листинге каталога первого уровня.
Cache Directives также указывают дополнительные параметры, такие как фактор репликации кэша и время окончания. Фактор репликации указывает количество блочных реплик в кэше. Если несколько Cache Directives относятся к одному файлу, применяется максимальный коэффициент репликации кэша.
Время окончания задается в командной строке как жизненный период (time-to-live — TTL), который представляет собой относительное время действия в будущем. После истечения срока действия Cache Directive больше не учитывается NameNode при принятии решений кэширования.
Cache Pool — это административный объект, используемый для управления группами директив кэша. Кэш-пулы имеют UNIX-подобные разрешения, которые ограничивают доступ пользователей и групп к пулу. Разрешения на запись позволяют пользователям добавлять и удалять директивы кэша в пул. Разрешения на чтение позволяют пользователям просматривать директивы кэша в пуле и дополнительные метаданные. Execute-разрешение не используется.
Cache Pools также используются для управления ресурсами. Кэш-пулы могут обеспечить максимальный предел памяти, ограничивающий совокупное количество байтов, которые могут быть кэшированы директивами в пуле. Как правило, сумма лимитов пула приблизительно равна суммарной памяти, зарезервированной для кэширования HDFS в кластере. Кэш-пулы также мониторят ряд статистических данных, чтобы помочь пользователям кластера отслеживать, что в настоящее время кэшируется, и определить, что еще нужно кэшировать.
Cache Pools также могут обеспечить максимальный жизненный период, ограничив максимальное время истечения срока действия директив, добавляемых в пул.
Для выполнения блокировки файлов в памяти DataNode использует собственный код JNI из libhadoop.so.
|
Внимание. При использовании централизованного управления кэшем HDFS обязательно должен быть включён JNI. |
Свойства конфигурации для централизованного кэширования указаны в файле hdfs-site.xml.
В настоящее время требуется только одно свойство:
Пример:
<property>
<name>dfs.datanode.max.locked.memory</name>
<value>268435456</value>
</property>Следующие свойства не являются обязательными, но могут быть заданы в настройках:
Пример:
<property>
<name>dfs.namenode.path.based.cache.refresh.interval.ms</name>
<value>300000</value>
</property>
Пример:
<property>
<name>dfs.time.between.resending.caching.directives.ms</name>
<value>300000</value>
</property>
Пример:
<property>
<name>dfs.datanode.fsdatasetcache.max.threads.per.volume</name>
<value>4</value>
</property>
Пример:
<property>
<name>dfs.cachereport.intervalMsec</name>
<value>10000</value>
</property>
Пример:
<property>
<name>dfs.namenode.path.based.cache.block.map.allocation.percent</name>
<value>0.25</value>
</property>Если выдаётся сообщение об ошибке “Cannot start datanode because the configured max locked memory size… is more than the datanode’s available RLIMIT_MEMLOCK ulimit”, это означает, что операционная система накладывает более низкое ограничение на объём памяти, который можно заблокировать, чем настроено. Чтобы исправить это, необходимо настроить значение ulimit -l, с которым работает DataNode в файле /etc/security/limits.conf (может варьироваться в зависимости от используемой ОС и дистрибутива).
Значение настроено правильно, когда при запуске ulimit-l выдаётся либо более высокое значение, чем настроенное, либо строка “unlimited”, что указывает на отсутствие ограничения.
|
Внимание. Для ulimit -l характерно выводить ограничение блокировки памяти в килобайтах, но при этом dfs.datanode.max.locked.memory должно быть указано в байтах. |
Например, значение dfs.datanode.max.locked.memory установлено в 128000 байт:
<property>
<name>dfs.datanode.max.locked.memory</name>
<value>128000</value>
</property>Лучше установить memlock (максимальное адресное пространство с закрытой памятью) на несколько большее значение. Например, чтобы установить memlock на 130 KB для пользователя hdfs, необходимо добавить следующую строку в /etc/security/limits.conf:
hdfs - memlock 130
|
Внимание. Приведённая информация не применяется к развёртыванию в Windows. Windows не имеет прямого эквивалента ulimit -l. |
Можно использовать интерфейс командной строки (CLI) для создания, изменения и перечисления Cache Pool и Cache Directives с помощью подкоманды hdfs cacheadmin.
Cache Directives идентифицируются уникальным не повторяющимся 64-битным ID. Идентификаторы не используются повторно, даже если Cache Directive удалена.
Cache Pools идентифицируются по уникальному имени строки.
Сначала создаётся Cache Pools, а затем в него добавляется Cache Directives.
Команды Cache Pools:
1. Добавление нового Cache Pool.
Команда:
hdfs cacheadmin -addPool <name> [-owner <owner>] [-group <group>]
[-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]Функции:
2. Изменение метаданных существующего Cache Pool.
Команда:
hdfs cacheadmin -modifyPool <name> [-owner <owner>] [-group <group>]
[-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]Функции:
3. Удаление Cache Pool. Также удаляет пути, связанные с ним.
Команда:
hdfs cacheadmin -removePool <name>Функции:
4. Отображение информации об одном или нескольких Cache Pool, например, имя, владелец, группа, разрешения и прочее.
Команда:
hdfs cacheadmin -listPools [-stats] [<name>]Функции:
5. Отображение подробной информации о команде.
Команда:
hdfs cacheadmin -help <command-name>Функции:
Команды Cache Directives:
1. Добавление нового Cache Directive.
Команда:
hdfs cacheadmin -addDirective -path <path> -pool <pool-name> [-force]
[-replication <replication>] [-ttl <time-to-live>]Функции:
2. Удаление Cache Directive.
Команда:
hdfs cacheadmin -removeDirective <id>Функции:
3. Удаление всех Cache Directives по указанному пути.
Команда:
hdfs cacheadmin -removeDirectives <path>Функции:
4. Возврат списка Cache Directives.
Команда:
hdfs cacheadmin -listDirectives [-stats] [-path <path>] [-pool <pool>]Функции:
В главе описываются правила запуска DataNodes от пользователя без прав root.
Исторически сложилось так, что часть конфигурации безопасности для HDFS задействовала запуск DataNode от пользователя root и привязала привилегированные порты для конечных точек сервера. Это было сделано для решения проблемы безопасности, то есть если задание MapReduce запущено, а DataNode остановился, задачу MapReduce можно привязать к порту DataNode и потенциально сделать что-то вредоносное. Решением подобных случаев стал запуск DataNode от пользователя root и использование привилегированных портов. При этом только пользователь root может получить доступ к привилегированным портам.
Для безопасного запуска DataNodes от пользователя без прав root можно использовать Simple Authentication and Security Layer (SASL), который применяется для обеспечения безопасной связи на уровне протокола.
|
Внимание. Важно выполнить переход от использования root к запуску DataNodes с SASL в конкретной последовательности по всему кластеру. В противном случае может возникнуть риск простоя приложения. |
Для переноса существующего кластера, использующего аутентификацию root, сначала необходимо убедиться, что версия 2.6.0 (или более поздняя) развёрнута для всех узлов кластера, а также для любых внешних приложений, которые необходимо подключить к кластеру. Только версии 2.6.0 + из HDFS-клиента могут подключаться к DataNode, использующему SASL для аутентификации протокола передачи данных, поэтому важно, чтобы все абоненты имели необходимую версию перед переходом.
После развёртывания версии 2.6.0 (или более поздней) необходимо обновить конфигурацию любых внешних приложений, чтобы включить SASL. Если для SASL включён клиент HDFS, он может успешно подключиться к DataNode, работающему с аутентификацией root или аутентификацией SASL. Изменение конфигурации для всех клиентов гарантирует, что последующие изменения конфигурации в DataNodes не нарушат работу приложений. Наконец, каждый отдельный DataNode может быть перенесён путём изменения его конфигурации и перезапуска. Допустимо временно сочетать некоторые DataNodes с аутентификацией root и некоторые DataNodes, работающие с аутентификацией SASL, в течение периода миграции, поскольку клиент HDFS, подключённый для SASL, может подключаться к обоим.
Для настройки DataNode SASL с безопасным запуском DataNode от non-root пользователя необходимо выполнить действия:
Чтобы включить DataNode SASL, необходимо в файле /etc/hadoop/conf/hdfs-site.xml настроить свойство dfs.data.transfer.protection, задав одно из следующих значений:
Также необходимо установить для свойства dfs.http.policy значение HTTPS_ONLY. При этом следует указать порты для DataNode RPC и HTTP-серверов.
Например:
<property>
<name>dfs.data.transfer.protection</name>
<value>integrity</value>
</property>
<property>
<name>dfs.datanode.address</name>
<value>0.0.0.0:10019</value>
</property>
<property>
<name>dfs.datanode.http.address</name>
<value>0.0.0.0:10022</value>
</property>
<property>
<name>dfs.http.policy</name>
<value>HTTPS_ONLY</value>
</property>
|
Внимание. Параметр шифрования dfs.encrypt.data.transfer=true похож на dfs.data.transfer.protection=privacy. Эти два параметра являются взаимоисключающими, поэтому они не должны устанавливаться вместе. В случае если оба параметра установлены, dfs.encrypt.data.transfer не используется. |
3. Обновить настройки экосистемы.
В файле /etc/hadoop/conf/hadoop-env.xml изменить параметр:
#On secure datanodes, user to run the datanode as after dropping
privileges export HADOOP_SECURE_DN_USER=Строка экспорта HADOOP_SECURE_DN_USER=hdfs включает устаревшую конфигурацию безопасности и, чтобы включить SASL, должна быть установлена на пустое значение.
4. Запустить DataNode.
До реализации списков контроля доступа — ACL, модель разрешения HDFS была эквивалентна традиционным UNIX-разрешениям. В этой модели разрешения для каждого файла или каталога управляются набором из трёх пользовательских классов: owner, group и others. Для каждого пользовательского класса существует три разрешения: чтение, запись и выполнение. Когда пользователь пытается получить доступ к объекту файловой системы, HDFS применяет разрешения в соответствии с конкретным классом пользователя. Если пользователь является владельцем, HDFS проверяет разрешения класса owner. Если пользователь не является владельцем, но является членом группы объектов файловой системы, HDFS проверяет разрешения класса group. В противном случае HDFS проверяет разрешения класса others.
Эта модель может в достаточной степени удовлетворять большому количеству требований безопасности. Например, есть отдел продаж с требованием, чтобы один пользователь — Иннокентий, менеджер отдела, — контролировал все изменения данных продаж. Другим сотрудникам отдела продаж необходимо видеть данные, но без возможности их изменения. Все остальные подразделения компании (за пределами отдела продаж) не должны иметь доступа к просмотру данных. Это требование может быть реализовано путем запуска chmod 640 в файле со следующим результатом:
-rw-r-----1 keshasales22K Nov 18 10:55 sales-dataПолучается, только Иннокентий может изменить файл, только члены группы продаж могут прочитать файл, и никто другой не может получить доступ к файлу каким-либо образом.
Предположим, возникает новое требование, которое состоит в том, что Иннокентию, Диане и Эдуарду должно быть разрешено вносить изменения. К сожалению, для реализации этого требования не существует возможности для разрешений, потому что может быть только один владелец и только одна группа. Типичным обходным решением является установка владельца файла на мнимую учётную запись пользователя, например, salesmgr, и разрешение Иннокентию, Диане и Эдуарду использовать учётную запись salesmgr с помощью sudo или аналогичных механизмов. Недостатком обходного пути является то, что он создаёт сложность для конечных пользователей, требуя от них применения разных учётных записей для разных действий.
Предположим далее, что помимо сотрудников по продажам все руководители компании должны иметь возможность читать данные о продажах. Это ещё одно требование, которое не может быть выражено с помощью Permission Bits, поскольку может быть только одна группа, и она уже используется. Типичным обходным решением является установка группы файлов в новую мнимую группу, например, salesandexecs, и добавление всех пользователей sales и execs к этой группе. Недостатком обходного пути является то, что он требует от администраторов создания и управления дополнительными пользователями и группами.
Таким образом, использование Permission Bits для удовлетворения требований к разрешениям, которые могут отличаются от естественной организационной иерархии пользователей и групп, может быть неудобно. А преимущество использования списков ACL заключается в том, что они позволяют более естественным образом решать эти требования, поскольку для любого объекта файловой системы несколько пользователей и несколько групп могут иметь разные наборы разрешений.
В данном примере решается один из вопросов путём установки ACL для предоставления доступа на чтение данных о продажах членам группы execs. Для этого необходимо:
1. Установить ACL.
> hdfs dfs -setfacl -m group:execs:r-- /sales-data2. Запустить getfacl, чтобы проверить результаты.
> hdfs dfs -getfacl /sales-data
# file: /sales-data
# owner: kesha
# group: sales
user::rw-
group::r--
group:execs:r--
mask::r--
other::---3. При помощи команды ls можно увидеть, что перечисленные разрешения добавлены с символом “+” для обозначения наличия ACL. Символ “+” добавляется к разрешениям любого файла или каталога с ACL.
> hdfs dfs -ls /sales-data
Found 1 items
-rw-r-----+ 3 kesha sales 0 2014-03-04 16:31 /sales-dataНовая запись ACL добавляется к существующим разрешениям, определённым в Permission Bits. Как владелец файла, Иннокентий имеет полный контроль. Члены группы sales и execs имеют доступ на чтение. У других пользователей доступа нет.
В дополнение к списку ACL, выполняемому проверки во время разрешений, существует также отдельная концепция — список ACL по умолчанию — default ACL, которая может применяться к каталогу, а не к файлу. Default ACL не имеет прямого влияния на проверку разрешений для существующих дочерних файлов и каталогов, а определяет списки ACL, которые будут получать новые дочерние файлы и каталоги автоматически при их создании.
Например, есть каталог “monthly-sales-data” с отдельными подкаталогами для каждого месяца. Необходимо установить список default ACL, чтобы гарантировать, что члены группы execs автоматически получают доступ к новым подкаталогам по мере их создания:
1. Установить default ACL в родительский каталог.
> hdfs dfs -setfacl -m default:group:execs:r-x /monthly-sales-data2. Создать подкаталоги.
> hdfs dfs -mkdir /monthly-sales-data/JAN
> hdfs dfs -mkdir /monthly-sales-data/FEB3. Убедиться, что HDFS автоматически применил default ACL в подкаталоги.
> hdfs dfs -getfacl -R /monthly-sales-data
# file: /monthly-sales-data
# owner: kesha
# group: sales
user::rwx
group::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---
# file: /monthly-sales-data/FEB
# owner: kesha
# group: sales
user::rwx
group::r-x
group:execs:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---
# file: /monthly-sales-data/JAN
# owner: kesha
# group: sales
user::rwx
group::r-x
group:execs:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---Default ACL копируется из родительского каталога в дочерний файл или каталог при его создании. Последующие изменения default ACL в родительском каталоге не меняют списки ACL существующих дочерних элементов.
Например, необходимо заблокировать доступ ко всему подкаталогу для конкретного пользователя (diana). Применение к данному пользователю списка ACL в корне подкаталога является самым быстрым способом без риска случайного отзыва разрешений у других пользователей. Для этого необходимо:
1. Добавить запись ACL для блокировки всего доступа пользователя diana к “monthly-sales-data”.
> hdfs dfs -setfacl -m user:diana:--- /monthly-sales-data2. Запустить getfacl для проверки результатов.
> hdfs dfs -getfacl /monthly-sales-data
# file: /monthly-sales-data
# owner: kesha
# group: sales
user::rwx
user:diana:---
group::r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:execs:r-x
default:mask::r-x
default:other::---Новая запись ACL добавляется к существующим разрешениям, определенным в Permission Bits. Иннокентий имеет полный контроль как владелец файла. Члены группы sales и execs имеют доступ на чтение. У других пользователей доступа нет.
Важно помнить о порядке оценки записей списка ACL, когда пользователь пытается получить доступ к объекту файловой системы:
В данном примере запись ACL-пользователя достигла установленной цели, поскольку пользователь не является владельцем файла, а именованная пользовательская запись имеет приоритет над всеми другими записями.
HDFS предназначена для хранения и обработки больших наборов данных, но при этом HDFS может быть менее эффективна при хранении большого количества мелких файлов, так как они занимают большую часть пространства имён. В результате место на диске не используется полностью из-за ограничения пространства имён.
Архивы Hadoop (HAR) используются для устранения ограничений пространства имён, связанных с хранением большого количества мелких файлов. Архив Hadoop позволяет упаковывать небольшие файлы в блоки HDFS более эффективно, тем самым сокращая использование памяти NameNode, сохраняя прозрачный доступ к файлам. HAR также совместимы с MapReduce, обеспечивая прозрачный доступ к исходным файлам.
HDFS предназначена для хранения и обработки больших массивов данных (терабайт). Например, большой продуктивный кластер может иметь 14 ПБ дискового пространства и хранить 60 миллионов файлов.
Однако хранение большого количества мелких файлов в HDFS неэффективно. Обычно файл считается «маленьким», когда его размер существенно меньше размера блока HDFS, который в Hadoop по умолчанию равен 256 МБ. Файлы и блоки являются объектами имён в HDFS, что означает, что они занимают пространство имён (место в NameNode). Таким образом, ёмкость пространства имён системы ограничена физической памятью NameNode.
Когда в системе хранится много мелких файлов, они занимают большую часть пространства имён. Как следствие, дисковое пространство не используется полностью из-за ограничения пространства имён. В одном реальном примере кластер имел 57 миллионов файлов размером менее 256 МБ, при этом каждый из этих файлов занимал один блок в NameNode. Эти мелкие файлы использовали 95% пространства имён, но занимали только 30% дискового пространства кластера.
Архивы HAR могут использоваться для устранения ограничений пространства имён, связанных с хранением большого количества мелких файлов. HAR упаковывает несколько мелких файлов в большой, обеспечивая прозрачный доступ к исходным файлам (без расширения файлов). Таким образом HAR увеличивает масштабируемость системы за счёт сокращения использования пространства имён и уменьшения нагрузки на работу в NameNode, оптимизирует память в NameNode и распределяет управление пространством имён по нескольким NameNodes. Кроме того, HAR обеспечивает параллельный доступ к исходным файлам с помощью заданий MapReduce.
Формат модели данных архивов Hadoop имеет вид:
foo.har/_masterindex //stores hashes and offsets
foo.har/_index //stores file statuses
foo.har/part-[1..n] //stores actual file dataФайлы данных хранятся в нескольких файлах, которые индексируются для сохранения первоначального разделения данных. Кроме того, файлы доступны параллельно с помощью MapReduce. В индексах файлов также записываются исходные структуры дерева каталогов и статус файла.
Большинство архивных систем, таких как tar, являются инструментами для архивации и деархивации. Как правило, они не вписываются в фактический уровень файловой системы и, следовательно, не являются прозрачными для разработчика приложения, поскольку пользователь должен предварительно деархивировать (расширять) архив перед использованием.
HAR интегрируется с интерфейсом файловой системы Hadoop. HarFileSystem реализует интерфейс FileSystem и предусматривает доступ через har://. Это обеспечивает прозрачность архивных файлов и структур дерева каталогов для пользователей. Доступ к файлам в HAR можно получить напрямую, без его расширения.
Например, команда для копирования файла HDFS в локальный каталог:
hdfs dfs –get hdfs://namenode/foo/file-1 localdirПредположив, что архив Hadoop bar.har создан из каталога foo, с помощью HAR команда для копирования исходного файла становится следующей:
hdfs dfs –get har://namenode/bar.har/foo/file-1 localdirПользователям следует изменить пути URI. Но при этом пользователи могут создать символическую ссылку (из hdfs://namenode/foo для har://namenode/bar.har/foo в примере выше), и тогда изменять URI не будет надобности. В любом случае, HarFileSystem вызывается автоматически для обеспечения доступа к файлам в HAR. Из-за этого прозрачного слоя HAR совместим с API Hadoop, MapReduce, интерфейсом командной строки оболочки FS и приложениями более высокого уровня, такими как Pig, Zebra, Streaming, Pipes и DistCp.
Архивы Hadoop могут быть созданы с помощью инструмента архивации Hadoop, он использует MapReduce для эффективного параллельного создания HAR. Инструмент вызывается с помощью команды:
hadoop archive -archiveName name -p <parent> <src>* <dest>Список файлов генерируется путём рекурсивного перемещения исходных каталогов, а затем список разбивается на карту входящих задач. Каждая задача создаёт файл (около 2 ГБ, настраивается) из подмножества исходных файлов и выводит метаданные. В итоге, reduce task собирает метаданные и генерирует индексные файлы.
Инструмент архивации вызывается следующей командой:
hadoop archive -archiveName name -p <parent> <src>* <dest>Где -archiveName — имя создающегося архива. В имени архива должно быть указано расширение .har. Аргумент <parent> используется для указания относительного пути к папке, в которой файлы будут архивироваться в HAR. Например:
hadoop archive -archiveName foo.har -p /user/hadoop dir1 dir2 /user/zooВ приведённом примере создаётся архив с использованием /user/hadoop в качестве каталога архива. Каталоги /user/hadoop/dir1 и /user/hadoop/dir2 будут заархивированы в архиве /user/zoo/foo.har.
|
Внимание. Архивирование не удаляет исходные файлы. При необходимости удаления входных файлов после создания архива (в целях сокращения пространства имён), исходные файлы должны удаляться вручную. |
Хотя команда архивации может быть запущена из файловой системы хоста, файл архива создаётся в HDFS из существующих каталогов. Если ссылаться на каталог в файловой системе хоста, а не на HDFS, выдаётся ошибка:
The resolved paths set is empty. Please check whether the
srcPaths exist, where srcPaths = [</directory/path>]Для создания каталогов HDFS, используемых в предыдущем примере, необходимо выполнить команду:
hdfs dfs -mkdir /user/zoo
hdfs dfs -mkdir /user/hadoop
hdfs dfs -mkdir /user/hadoop/dir1
hdfs dfs -mkdir /user/hadoop/dir2Команда hdfs dfs -ls может использоваться для поиска файлов в архивах Hadoop. Используя пример архива /user/zoo/foo.har, созданный в предыдущем разделе, необходимо применить следующую команду для вывода списка файлов в архиве:
hdfs dfs -ls har:///user/zoo/foo.har/Результатом будет:
har:///user/zoo/foo.har/dir1
har:///user/zoo/foo.har/dir2Архивы были созданы с помощью команды:
hadoop archive -archiveName foo.har -p /user/hadoop dir1 dir2 /user/zooЕсли изменить команду на:
hadoop archive -archiveName foo.har -p /user/ hadoop/dir1 hadoop/dir2 /user/zooИ затем выполнить:
hdfs dfs -ls -R har:///user/zoo/foo.harТо результатом будет:
har:///user/zoo/foo.har/hadoop
har:///user/zoo/foo.har/hadoop/dir1
har:///user/zoo/foo.har/hadoop/dir2Следует обратить внимание, что с изменённым родительским аргументом файлы архивируются относительно /user/, а не /user/hadoop.
Для использования HAR с MapReduce необходимо ссылаться на файлы несколько иначе, чем на файловую систему по умолчанию. Если есть архив Hadoop, хранящийся в HDFS в /user/zoo/foo.har, следует указать каталог ввода как har:///user/zoo/foo.har, чтобы использовать его как MapReduce. Поскольку HAR отображаются как файловая система, MapReduce может использовать все логические входные файлы в архивы Hadoop в качестве входных данных.
В главе описывается настройка HDFS Compression на Linux.
Linux поддерживает GzipCodec, DefaultCodec, BZip2Codec, LzoCodec и SnappyCodec. Как правило, для HDFS Compression используется GzipCodec.
Существует два варианта использования GzipCodec:
1. GzipCodec для одноразовых заданий.
hadoop jar hadoop-examples-1.1.0-SNAPSHOT.jar sort sbr"-
Dmapred.compress.map.output=true" sbr"-
Dmapred.map.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec"sbr "-
Dmapred.output.compress=true" sbr"-
Dmapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec"sbr -
outKey org.apache.hadoop.io.Textsbr -outValue org.apache.hadoop.io.Text input output2. GzipCodec в качестве сжатия по умолчанию:
<property>
<name>io.compression.codecs</name>
<value>org.apache.hadoop.io.compress.GzipCodec,
org.apache.hadoop.io.compress.DefaultCodec,com.hadoop.compression.lzo.LzoCodec,org.apache.
hadoop.io.compress.SnappyCodec</value>
<description>A list of the compression codec classes that can
be used for compression/decompression.</description>
</property>
<property>
<name>mapred.compress.map.output</name>
<value>true</value>
</property>
<property>
<name>mapred.map.output.compression.codec</name>
<value>org.apache.hadoop.io.compress.GzipCodec</value>
</property>
<property>
<name>mapred.output.compression.type</name>
<value>BLOCK</value>
</property>
<property>
<name>mapred.output.compress</name>
<value>true</value>
</property>
<property>
<name>mapred.output.compression.codec</name>
<value>org.apache.hadoop.io.compress.GzipCodec</value>
</property>
Для доступа к показателям HDFS можно использовать методы с помощью API-интерфейсов Java Management Extensions (JMX).
Доступ к метрикам JMX можно получить через веб-интерфейс HDFS daemon, что является рекомендуемым методом.
Например, для доступа к NameNode JMX необходимо использовать следующий формат команды:
curl -i http://localhost:50070/jmxДля извлечения только определённого ключа можно использовать параметр qry:
curl -i http://localhost:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeInfoМетод требует, чтобы удалённый агент JMX был включён с опцией JVM при запуске сервисов HDFS.
Например, следующие параметры JVM в hadoop-env.sh используются для включения удалённого агента JMX для NameNode. Он работает на порту 8004 с отключённым SSL. Имя пользователя и пароль сохраняются в файле mxremote.password.
export HADOOP_NAMENODE_OPTS="-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.password.file=$HADOOP_CONF_DIR/jmxremote.password
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=8004 $HADOOP_NAMENODE_OPTS"Подробности о связанных настройках можно найти здесь. Также можно использовать инструмент jmxquery для извлечения информации через JMX.
Hadoop также имеет встроенный инструмент запросов JMX — jmxget. Например:
hdfs jmxget -server localhost -port 8004 -service NameNode
|
Внимание. Инструмент jmxget требует, чтобы аутентификация была отключена, так как она не принимает имя пользователя и пароль. |
Использование JMX может быть сложным для персонала, который не знаком с настройкой JMX, особенно JMX с SSL и firewall tunnelling. Поэтому обычно рекомендуется собирать информацию JXM через веб-интерфейс HDFS daemon, а не напрямую обращаться к удалённому агенту JMX.
Настройка Rack Awareness на кластере Hadoop осуществляется в несколько шагов:
Hadoop использует скрипты топологии для определения местоположения стойки узлов и применяет эту информацию для репликации данных блока в резервные стойки.
#!/bin/bash
# Adjust/Add the property "net.topology.script.file.name"
# to core-site.xml with the "absolute" path the this
# file. ENSURE the file is "executable".
# Supply appropriate rack prefix
RACK_PREFIX=default
# To test, supply a hostname as script input:
if [ $# -gt 0 ]; then
CTL_FILE=${CTL_FILE:-"rack_topology.data"}
HADOOP_CONF=${HADOOP_CONF:-"/etc/hadoop/conf"}
if [ ! -f ${HADOOP_CONF}/${CTL_FILE} ]; then
echo -n "/$RACK_PREFIX/rack "
exit 0
fi
while [ $# -gt 0 ] ; do
nodeArg=$1
exec< ${HADOOP_CONF}/${CTL_FILE}
result=""
while read line ; do
ar=( $line )
if [ "${ar[0]}" = "$nodeArg" ] ; then
result="${ar[1]}"
fi
done
shift
if [ -z "$result" ] ; then
echo -n "/$RACK_PREFIX/rack "
else
echo -n "/$RACK_PREFIX/rack_$result "
fi
done
else
echo -n "/$RACK_PREFIX/rack "
fiПример файла данных топологии. Имя файла: rack_topology.data.
# This file should be:
# - Placed in the /etc/hadoop/conf directory
# - On the Namenode (and backups IE: HA, Failover, etc)
# - On the Job Tracker OR Resource Manager (and any Failover JT's/RM's)
# This file should be placed in the /etc/hadoop/conf directory.
# Add Hostnames to this file. Format <host ip> <rack_location>
192.0.2.0 01
192.0.2.1 02
192.0.2.2 033. Скопировать оба этих файла в каталог /etc/hadoop/conf на всех узлах кластера.
4. Запустить скрипт rack-topology.sh, чтобы убедиться, что он возвращает правильную информацию о стойке для каждого хоста.
Добавление свойства Script Topology в core-site.xml:
<property>
<name>net.topology.script.file.name</name>
<value>/etc/hadoop/conf/rack-topology.sh</value>
</property>По умолчанию скрипт топологии обрабатывает до 100 заявок за запрос. Можно указать другое количество заявок в свойстве net.topology.script.number.args. Например:
<property>
<name>net.topology.script.number.args</name>
<value>75</value>
</property>Перезапустить HDFS и MapReduce.
После запуска сервисов для проверки активации Rack Awareness можно использовать следующие способы:
1. Просмотреть журналы NameNode, расположенные в /var/log/hadoop/hdfs/ (например: hadoop-hdfs-namenode-sandbox.log). Должна быть следующая запись:
:: 014-01-13 15:58:08,495 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /rack01/<ipaddress>2. Команда Hadoop fsck должна возвращать на подобии следующего (в случае двух стоек):
Status: HEALTHY
Total size: 123456789 B
Total dirs: 0
Total files: 1
Total blocks (validated): 1 (avg. block size 123456789 B)
Minimally replicated blocks: 1 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0
Missing replicas: 0 (0.0 %)
Number of data-nodes: 40
Number of racks: 2
FSCK ended at Mon Jan 13 17:10:51 UTC 2014 in 1 milliseconds3. Команда Hadoop dfsadmin -report возвращает отчёт, содержащий имя стойки рядом с каждой машиной. Отчёт должен выглядеть примерно следующим образом (частично):
[bsmith@hadoop01 ~]$ sudo -u hdfs hadoop dfsadmin -report
Configured Capacity: 19010409390080 (17.29 TB)
Present Capacity: 18228294160384 (16.58 TB)
DFS Remaining: 5514620928000 (5.02 TB)
DFS Used: 12713673232384 (11.56 TB) DFS Used%: 69.75%
Under replicated blocks: 181
Blocks with corrupt replicas: 0
Missing blocks: 0
-------------------------------------------------
Datanodes available: 5 (5 total, 0 dead)
Name: 192.0.2.0:50010 (h2d1.phd.local)
Hostname: h2d1.phd.local
Rack: /default/rack_02
Decommission Status : Normal
Configured Capacity: 15696052224 (14.62 GB)
DFS Used: 314380288 (299.82 MB)
Non DFS Used: 3238612992 (3.02 GB)
DFS Remaining: 12143058944 (11.31 GB)
DFS Used%: 2.00%
DFS Remaining%: 77.36%
Configured Cache Capacity: 0 (0 B)
Cache Used: 0 (0 B)
Cache Remaining: 0 (0 B)
Cache Used%: 100.00%
Cache Remaining%: 0.00%
Last contact: Thu Jun 12 11:39:51 EDT 2014В HDFS чтение обычно проходит через DataNode. Таким образом, когда клиент запрашивает DataNode для чтения файла, DataNode считывает этот файл с диска и отправляет данные клиенту через сокет TCP. Так называемое “локальное чтение” читает в обход DataNode, позволяя клиенту непосредственно прочитать файл. Очевидно, что это возможно только в тех случаях, когда клиент находится в одном месте с данными. Локальное чтение обеспечивает значительное повышение производительности для многих приложений.
Для настройки локального чтения данных необходимо включить libhadoop.so.
Также для настройки локального чтения данных на HDFS необходимо в файл hdfs-site.xml добавить свойства, приведённые далее. Локальное чтение данных должно быть настроено как для DataNode, так и для клиента.
XML для вышеуказанных записей:
<configuration>
<property>
<name>dfs.client.read.shortcircuit</name>
<value>true</value>
</property>
<property>
<name>dfs.domain.socket.path</name>
<value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>
<property>
<name>dfs.client.domain.socket.data.traffic</name>
<value>false</value>
</property>
<property>
<name>dfs.client.use.legacy.blockreader.local</name>
<value>false</value>
</property>
<property>
<name>dfs.datanode.hdfs-blocks-metadata.enabled</name>
<value>true</value>
</property>
<property>
<name>dfs.client.file-block-storage-locations.timeout.millis</name>
<value>60000</value>
</property>
<property>
<name>dfs.client.read.shortcircuit.skip.checksum</name>
<value>false</value>
</property>
<property>
<name>dfs.client.read.shortcircuit.streams.cache.size</name>
<value>256</value>
</property>
<property>
<name>dfs.client.read.shortcircuit.streams.cache.expiry.ms</name>
<value>300000</value>
</property>
</configuration>Для настройки WebHDFS необходимо выполнить следующие шаги:
1. Настроить WebHDFS, добавив в файл hdfs-site.xml свойство:
<property>
<name>dfs.webhdfs.enabled</name>
<value>true</value>
</property>2. [Опционально] При запуске защищенного кластера выполнить следующие действия:
kadmin: addprinc -randkey HTTP/$<Fully_Qualified_Domain_Name>@$<Realm_Name>.COMГде:
kadmin: xst -norandkey -k /etc/security/spnego.service.keytab HTTP/$<Fully_Qualified_Domain_Name>
klist –k -t /etc/security/spnego.service.keytab
<property>
<name>dfs.web.authentication.kerberos.principal</name>
<value>HTTP/$<Fully_Qualified_Domain_Name>@$<Realm_Name>.COM</value>
</property>
<property>
<name>dfs.web.authentication.kerberos.keytab</name>
<value>/etc/security/spnego.service.keytab</value>
</property>Где:
3. Перезапустить сервисы NameNode и DataNode.
Списки ACL на HDFS реализуются с помощью модели ACL POSIX, которая работает так же, как и в файловой системе Linux.
HDFS может связывать дополнительный список ACL с любым файлом или каталогом. Все операции HDFS, которые обеспечивают соблюдение разрешений, выраженных с помощью Permission Bits, также должны обеспечить любой ACL, который определён для файла или каталога. Так же как и любая существующая логика, которая обходит Permission Bits, обходит и ACL. Включая супер-пользователя HDFS и установку false в конфигурации dfs.permissions.
HDFS поддерживает операции по настройке и получению ACL, связанного с файлом или каталогом. Эти операции доступны через несколько ориентированных на пользователя конечных точек. Эти конечные точки включают FsShell CLI, программную манипуляцию через классы FileSystem и FileContext, WebHDFS и NFS.
К разрешениям любого файла или каталога с ACL добавляется символ + (вывод команды ls -l).
Реализация ACL обратно совместима с существующими Permission Bits. Изменения, применяемые посредством разрешённых битов (то есть chmod), также отображаются как изменения в ACL. Аналогично, изменения, применяемые к записям ACL для базовых классов пользователей (“Owner”, “Group” и “Other”), отображаются в виде изменений в Permission Bits.
Другими словами, операции Permission Bits и ACL управляют совместно используемой моделью, и операции Permission Bits можно рассматривать как подмножество операций ACL.
Добавление ACL не приводит к негативному влиянию на потребление системных ресурсов при развёртывании. Он включает в себя процессор, память, диск и пропускную способность сети. Но использование списков ACL влияет на производительность NameNode, поэтому рекомендуется использовать Permission Bits, прежде чем ACL.
Количество записей в одном списке ACL ограничено максимум до 32. Попытки добавить записи ACL сверх максимума выполняются с ошибкой, обращенной к пользователю. Это делается по двум причинам: упростить управление и ограничить потребление ресурсов.
Списки ACL с большим количеством записей, как правило, трудно понять и могут указывать на то, что требования лучше устраняются путём определения дополнительных групп или пользователей. Также такие списки требуют большей памяти и хранилища, и для каждой проверки разрешений требуется больше времени.
У символических ссылок нет собственных списков ACL, поэтому они рассматривается как разрешения по умолчанию (777 в Permission Bits). Операции, которые изменяют список символической ссылки, вместо этого изменяют саму символическую ссылку.
При создании снапшота все списки ACL блокируются. Изменения в ACL в момент создания снапшота не фиксируются.
Инструментарий для Permission Bits не подходит для ACL. Списки включаются командой оболочки cp -p и distcp -p.
Когда нескольким пользователям требуется доступ для чтения к файлу и при этом ни один из пользователей не является владельцем файла. Кроме того пользователи не являются членами общей группы, поэтому невозможно использовать групповые разрешения. В таком случае устанавливается ACL-доступ, содержащий несколько именованных пользовательских записей:
ACLs on HDFS supports the following use cases:Когда нескольким группам требуется чтение и запись в файл и при этом нет группы, объединяющей всех необходимых пользователей, поэтому невозможно использовать групповые разрешения. В таком случае устанавливается ACL-доступ, содержащий несколько именованных групповых записей:
group:sales:rw-
group:execs:rw-В случае, когда Hive содержит секционированную таблицу данных и ключ раздела, например, — country. Hive сохраняет секционированные таблицы с помощью отдельного подкаталога для каждого определённого значения ключа, поэтому структура файловой системы выглядит так:
user
`-- hive
`-- warehouse
`-- sales
|-- country=CN
|-- country=GB
`-- country=USГруппа salesadmin — группа для всех файлов. Члены группы имеют доступ на чтение и запись ко всем файлам. Отдельные группы, зависящие от конкретной страны, могут запускать запросы на использование, которые только считывают данные для конкретной страны, например, sales_CN, sales_GB и sales_US. У этих групп нет доступа на запись.
Такой вариант использования можно решить, установив ACL-доступ в каждом подкаталоге, содержащем запись собственной группы и именованной группы:
country=CN
group::rwx
group:sales_CN:r-x
country=GB
group::rwx
group:sales_GB:r-x
country=US
group::rwx
group:sales_US:r-x
|
Внимание. Функциональность записи ACL группы-владельца (запись группы без имени) эквивалентна установленным Permission Bits. |
Авторизация на основе хранилища в Hive в настоящее время не учитывает разрешения ACL в HDFS. Доступ проверяется с использованием традиционной модели разрешений POSIX.
Администратор файловой системы или владелец поддерева может определить политику доступа, применимую ко всему поддереву не только к текущему набору файлов и каталогов, но также к новым файлам и каталогам, которые будут добавляться позже.
Этот вариант использования решается установкой в каталог ACL по умолчанию. При этом список может содержать любую произвольную комбинацию записей. Например:
default:user::rwx
default:user:kesha:rw-
default:user:diana:r--
default:user:edik:rw-
default:group::r--
default:group:sales::rw-
default:group:execs::rw-
default:others::---Важно отметить, что ACL по умолчанию копируется из каталога во вновь созданные дочерние файлы и каталоги во время их создания. Если изменить ACL по умолчанию для каталога, это не повлияет на списки файлов и подкаталогов, которые уже существуют. ACL по умолчанию никогда не учитываются при применении разрешений. Они используются только для определения списка ACL, который новые файлы и подкаталоги будут получать автоматически при их создании.
Списки управления доступом HDFS поддерживают развёртывания, в которых может потребоваться использование только битов разрешений, а не ACL с именованными записями пользователей и групп. Permission Bits эквивалентны минимальному ACL, содержащему только 3 записи. Например:
user::rw-
group::r--
others::---Для примера создано поддерево файловой системы с глубоким вложением, доступное для чтения всем миром, и к которому устанавливается требование заблокировать доступ для определённого пользователя ко всем файлам в этом поддереве.
В таком случае устанавливается ACL в корне поддерева с именованной записью пользователя, которая лишает пользователя доступа.
dir1
`-- dir2
`-- dir3
|-- file1
|-- file2
`-- file3Установка следующего ACL на dir2 блокирует доступ Иннокентия к dir3, file1, file2 и file3:
user:kesha:---Удаление разрешений на dir2 означает, что Иннокентий не может получить к нему доступ и, следовательно, не может видеть ни один из его дочерних элементов. Это также означает, что доступ автоматически блокируется для любых вновь добавленных файлов в dir2. То есть если file4 создается под dir3, Иннокентий не сможет получить к нему доступ.
Когда нескольким именованным пользователям или группам требуется полный доступ к каталогу общего назначения, например, /tmp. Однако разрешения “Write” и “Execute” для каталога также дают пользователям возможность удаления или переименовывания любых файлов в каталоге, включая созданные другими пользователями. Такие разрешения необходимо ограничить, чтобы у пользователей был допуск на удаление или переименование созданных только ими файлов.
Этот случай можно решить, объединив ACL с Sticky bit — это существующая функциональность, которая в настоящее время работает с Permission Bits, и будет продолжать работать как ожидается в сочетании с ACL.
Для работы с HDFS через командную строку необходимо использовать нативный shell-клиент для HDFS.
Для использования shell-команд, с помощью которых можно взаимодействовать с HDFS, необходимо в терминале запустить скрипт bin/hdfs.
При запуске скрипта bin/hdfs без аргументов будет выведен перечень всех возможных команд.
Чтобы запустить конкретную команду, необходимо воспользоваться синтаксисом и перечнем команд, приведёнными ниже.
Общий синтаксис команд:
hadoop [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]Описание параметров и классов команд представлено ниже.
Таблица 16— Параметры и классы
|
COMMAND_OPTIONS |
Описание |
|---|---|
| SHELL_OPTIONS |
Общий набор shell-параметров. |
| GENERIC_OPTIONS |
Общий набор параметров, поддерживаемый несколькими командами. |
| COMMAND COMMAND_OPTIONS |
В следующих пунктах раздела описаны различные пользовательские команды с их параметрами. |
Команды balancer запускают утилиту балансировки кластера.
Администратор может просто нажать Ctrl-C, чтобы остановить процесс перебалансировки.
Обратите внимание, что политика блочного пула более строгая, чем политика узла данных.
Помимо параметров команды, которые представлены ниже, введена функция закрепления, чтобы предотвратить перемещение определённых реплик балансировщиком/движителем. Эта функция закрепления отключена по умолчанию, и её можно включить с помощью свойства конфигурации dfs.datanode.block-pinning.enabled. Когда эта функция включена, она влияет только на блоки, которые записываются в избранные узлы, указанные в вызове create(). Эта функция полезна, когда мы хотим сохранить локальность данных для таких приложений, как HBase regionserver.
Команда policy позволяет произвести балансировку кластера.
Если установлены параметры:
Синтаксис команды:
hadoop balancer [-policy <policy>]Команда threshold устанавливает процент ёмкости диска. Команда перезаписывает порог по умолчанию.
Синтаксис команды:
hadoop balancer [-policy <policy>]Команда exclude исключает указанные DataNode из балансировки балансировщиком.
Синтаксис команды:
hadoop balancer [-exclude [-f <hosts-file> | <comma-separated list of hosts>]]Команда include включает только указанные DataNode для балансировки балансировщиком.
Синтаксис команды:
hadoop balancer [-include [-f <hosts-file> | <comma-separated list of hosts>]]Команда source позволяет выбрать только указанные DataNode в качестве исходных узлов.
Синтаксис команды:
hadoop balancer [-source [-f <hosts-file> | <comma-separated list of hosts>]]Команда blockpools позволяет сформировать список пулов блоков, с которыми будет работать балансировщик.
Синтаксис команды:
hadoop balancer [-blockpools <comma-separated list of blockpool ids>]Команда idleiterations устанавливает максимальное количество итераций простоя перед выходом. Команда перезаписывает количество итераций, установленное по умолчанию (5).
Синтаксис команды:
hadoop balancer [-idleiterations <idleiterations>]Команда runDuringUpgrade разрешает/запрещает запускать балансировщик во время текущего обновления HDFS. Действие является нежелательным, поскольку команда не влияет на используемое пространство на чрезмерно загруженных машинах.
Синтаксис команды:
hadoop balancer [-runDuringUpgrade]Команда help вызывает справку с информацией об использовании инструмента и последующий выход.
Синтаксис команды:
hadoop balancer [--h | --help]Команда cacheadmin позволяет работать с кэшированием, а именно: созданием, изменением и перечислением Cache Pools и Cache Directives.
Cache Directives идентифицируются уникальным не повторяющимся 64-битным ID. Идентификаторы не используются повторно, даже если Cache Directive удалена.
Cache Pools идентифицируются по уникальному имени строки.
Сначала следует создать Cache Pools, а затем добавить в него Cache Directives.
Команды и их параметры COMMAND_OPTIONS представлены в разделах ниже.
Команда addDirective позволяет добавить новый Cache Directive.
Синтаксис команды:
hadoop cacheadmin [-addDirective -path <path> -pool <pool-name>
[-force] [-replication <replication>] [-ttl <time-to-live>]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда modifyDirective позволяет вносить изменения в метаданные существующего Cache Directive.
Синтаксис команды:
hadoop cacheadmin [-modifyDirective -id <id> [-path <path>]
[-force] [-replication <replication>] [-pool <pool-name>] [-ttl <time-to-live>]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда listDirectives позволяет выводить список Cache Directive.
Синтаксис команды:
hadoop cacheadmin [-listDirectives [-stats] [-path <path>] [-pool <pool>] [-id <id>]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда removeDirective позволяет удалить Cache Directive.
Синтаксис команды:
hadoop cacheadmin [-removeDirective <id>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда removeDirectives позволяет удалить все Cache Directive по указанному пути.
Синтаксис команды:
hadoop cacheadmin [-removeDirectives -path <path>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда addPool позволяет добавить новый Cache Directive.
Синтаксис команды:
hadoop cacheadmin [-addPool <name> [-owner <owner>] [-group <group>]
[-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда modifyPool позволяет изменить метаданные существующего Cache Pool.
Синтаксис команды:
hadoop cacheadmin [-modifyPool <name> [-owner <owner>] [-group <group>]
[-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда removePool позволяет удалить Cache Pool. Также удаляет пути, связанные с ним.
Синтаксис команды:
hadoop cacheadmin [-removePool <name>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда listPools позволяет отобразить информацию об одном или нескольких Cache Pool, например, имя, владельца, группу, разрешения и прочее.
Синтаксис команды:
hadoop cacheadmin [-listPools [-stats] [<name>]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда help позволяет отобразить подробную о команде.
Синтаксис команды:
hadoop cacheadmin [-help <command-name>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда crypto позволяет управлять шифрованием.
Команды и их параметры COMMAND_OPTIONS представлены в разделах ниже.
Команда createZone позволяет создать новую зону шифрования.
Синтаксис команды:
hadoop crypto -createZone -keyName <keyName> -path <path>В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда listZones позволяет перечислить все зоны шифрования. Требуются разрешения суперпользователя.
Синтаксис команды:
hadoop crypto -listZonesКоманда provisionTrash позволяет подготовить каталог корзины для зоны шифрования.
Синтаксис команды:
hadoop crypto -provisionTrash -path <path>В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда help позволяет отобразить подробную информацию о команде.
Синтаксис команды:
hadoop crypto -help <command-name>В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда datanode позволяет запустить DataNode.
Синтаксис команды:
hadoop datanode [-regular | -rollback | -rollingupgrade rollback]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команды dfsadmin предназначены для администрирования HDFS.
Ниже в разделах представлены возможные команды для администрирования HDFS.
Команда report позволяет отобразить основную информацию и статистику файловой системы HDFS.
Использование команды dfs может отличаться от использования команды du, поскольку она измеряет необработанное пространство, используемое репликациями, контрольными суммами, снапшотами и т.д. для всех DataNode.
Необязательные параметры команды могут использоваться для фильтрации списка отображаемых узлов данных.
Синтаксис команды:
hadoop dfsadmin [-report [-live] [-dead] [-decommissioning]
[-enteringmaintenance] [-inmaintenance]]Команда safemode предназначена для ручного управления режимом Safemode (безопасным режимом).
Режим Safemode — это состояние узла NameNode, в котором он:
Вход в режим Safemode производится автоматически при запуске NameNode. Выхода из режима производится также автоматически, когда настроенный минимальный процент блоков удовлетворяет минимальному условию репликации. Если NameNode обнаруживает какую-либо аномалию, он будет оставаться в режиме SafeMode до тех пор, пока проблема не будет решена. Если эта аномалия является следствием преднамеренного действия, администратор может использовать команду -safemode forceExit для выхода из режима Safemode.
Случаи, когда может потребоваться использование forceExit:
1. Метаданные NameNode несовместимы.
Если Namenode обнаруживает, что метаданные были изменены вне диапазона и могут вызвать потерю данных, NameNode перейдёт в состояние SafemodeforceExit. В этот момент пользователь может либо перезапустить NameNode с правильными файлами метаданных, либо использовать forceExit (если потеря данных допустима).
2. Откат вызывает замену метаданных и редко может вызвать состояние принудительного выхода из режима Safemode на NameNode.
В этом случае вы можете продолжить, введя -safemode forceExit.
В режим Safemode можно войти вручную, но тогда из него также необходимо будет выйти вручную.
Синтаксис команды:
hadoop dfsadmin [-safemode enter | leave | get | wait | forceExit]Команда saveNamespace позволяет сохранить текущее пространство имён в каталогах хранилища и сбросить журнал изменений.
Для выполнения команды требуется вход в режим Safemode. Если задан параметр beforeShutdown, NameNode выполняет контрольную точку тогда и только тогда, когда ни одна контрольная точка не была выполнена в течение временного окна (настраиваемое количество периодов контрольной точки). Обычно данная команда используется перед завершением работы NameNode, чтобы предотвратить возможное повреждение fsimage или журналов изменений.
Синтаксис команды:
hadoop dfsadmin [-saveNamespace [-beforeShutdown]]Команда rollEdits сворачивает журнал редактирования на активном NameNode.
С течением времени количество файлов журнала редактирования растёт, а также NameNode сохраняет старые версии файла fsimage.
Это будет использовать дисковое пространство на NameNode и может вызвать проблемы с диском в более длительной работе кластера. Кроме того, если вторичная NameNode не настроена или работает некорректно, эти файлы редактирования будут создаваться в большом количестве, каждый файл будет содержать примерно 1 миллион транзакций. Из-за этого время запуска NameNode увеличится, и NameNode может даже не запуститься, если памяти будет недостаточно для выполнения операции создания контрольной точки.
Синтаксис команды:
hadoop dfsadmin [-rollEdits]Команда restoreFailedStorage включает/выключает автоматические попытки восстановления неудачных репликаций хранилища.
Если сбойное хранилище снова станет доступным, система попытается восстановить журнал изменений и/или fsimage во время контрольной точки.
Параметр check вернёт текущую настройку.
Синтаксис команды:
hadoop dfsadmin [-restoreFailedStorage true |false |check]Команда refreshNodes повторно читает хосты и исключает файлы для обновления перечня DataNodes, которым разрешено подключаться к NameNode, и тех, которые должны быть выведены или повторно введены в эксплуатацию.
Синтаксис команды:
hadoop dfsadmin [-refreshNodes]Команда setQuota позволяет установить квоту имени, равной N для каждого каталога.
Наилучший вариант для каждого каталога, с сообщением об ошибках, если N не является положительным длинным целым числом, каталог не существует, или это файл, или каталог немедленно превысит новую квоту.
Синтаксис команды:
hadoop dfsadmin [-setQuota <quota> <dirname>...<dirname>]Команда clrQuota позволяет удалить квоту имён для каждого каталога. Наилучший вариант для каждого каталога с сообщением об ошибках, если каталог не существует или является файлом. Если для каталога нет квоты, это не ошибка.
Синтаксис команды:
hadoop dfsadmin [-clrQuota <dirname>...<dirname>]Команда setSpaceQuota позволяет:
Синтаксис команды:
hadoop dfsadmin [-setSpaceQuota <quota>
[-storageType <storagetype>] <dirname>...<dirname>]Команда clrSpaceQuota позволяет:
Синтаксис команды:
hadoop dfsadmin [-clrSpaceQuota [-storageType <storagetype>]
<dirname>...<dirname>]Команда finalizeUpgrade позволяет завершить обновление HDFS. DataNodes удаляют свою предыдущую резервную копию кластера, которая была сделана во время предыдущего обновления после того, как NameNode произведёт те же действия. После этого считается, что процесс обновления завершён.
Синтаксис команды:
hadoop dfsadmin [-finalizeUpgrade]Команда rollingUpgrade позволяет выполнять действие последовательного обновления.
Синтаксис команды:
hadoop dfsadmin [-rollingUpgrade [<query> |<prepare> |<finalize>]]Команда upgrade позволяет запросить текущий статус обновления, используя параметр query, или завершить текущее обновление HDFS, используя параметр finalize.
Синтаксис команды:
hadoop dfsadmin [-upgrade [query | finalize]Команда refreshServiceAcl позволяет перезагрузить файл политики авторизации на уровне сервиса.
Синтаксис команды:
hadoop dfsadmin [-refreshServiceAcl]Команда refreshUserToGroupsMappings позволяет обновить сопоставления пользователей и групп.
Синтаксис команды:
hadoop dfsadmin [-refreshUserToGroupsMappings]Команда refreshSuperUserGroupsConfiguration позволяет обновить сопоставления proxy-групп суперпользователя.
Синтаксис команды:
hadoop dfsadmin [-refreshSuperUserGroupsConfiguration]Команда refreshCallQueue позволяет перезагрузить очередь вызовов из config.
Синтаксис команды:
hadoop dfsadmin [-refreshCallQueue]Команда refresh запускает обновление во время выполнения ресурса, указанного в <key> на <host:ipc_port>. Все остальные параметры отправляются на хост.
Синтаксис команды:
hadoop dfsadmin [-refresh <host:ipc_port> <key> [arg1..argn]]Команда reconfig запускает реконфигурацию или выводит статус текущей реконфигурации, или выводит список реконфигурируемых свойств. Второй параметр указывает тип узла.
Синтаксис команды:
hadoop dfsadmin [-reconfig <namenode|datanode> <host:ipc_port> <start |status |properties>]Команда printTopology позволяет вывести дерево стоек и их узлов, которые передаются в NameNode.
Синтаксис команды:
hadoop dfsadmin [-printTopology]Команда refreshNamenodes перезагружает файлы конфигурации для данного узла NameNode, прекращает обслуживание удалённых пулов блоков и начинает обслуживание новых пулов блоков.
Синтаксис команды:
hadoop dfsadmin [-refreshNamenodes datanodehost:port]Команда getVolumeReport позволяет получить отчёт об объёме для данного узла NameNode.
Синтаксис команды:
hadoop dfsadmin [-getVolumeReport datanodehost:port]Команда deleteBlockPool при принудительном вводе каталог пула блоков для данного идентификатора пула блоков на указанном DataNode удаляет пул вместе с его содержимым, в противном случае каталог удаляется только в том случае, если он пуст. Команда завершится ошибкой, если DataNode все ещё обслуживает пул блоков. Используйте команду refreshNamenodes, чтобы завершить работу службы пула блоков на DataNode.
Синтаксис команды:
hadoop dfsadmin [-deleteBlockPool datanode-host:port blockpoolId [force]]Команда setBalancerBandwidth изменяет пропускную способность сети, используемую каждым DataNode во время балансировки блоков HDFS. <bandwidth> — это максимальное количество байтов в секунду, которое будет использоваться каждым DataNode. Это значение переопределяет параметр dfs.datanode.balance.bandwidthPerSec. Новое значение не сохраняется в DataNode.
Синтаксис команды:
hadoop dfsadmin [-setBalancerBandwidth <bandwidth in bytes per second>]Команда getBalancerBandwidth позволяет вывести пропускную способность сети (в байтах в секунду) для данного DataNode. Это максимальная пропускная способность сети, используемая DataNode во время балансировки блоков HDFS.
Синтаксис команды:
hadoop dfsadmin [-getBalancerBandwidth <datanode_host:ipc_port>]Команда fetchImage загружает самый последний fsimage из NameNode и сохраняет его в указанном локальном каталоге.
Синтаксис команды:
hadoop dfsadmin [-fetchImage <local directory>]Команда allowSnapshot устанавливает разрешение на создание снапшотов каталога. Если операция завершится успешно, каталог станет снапшотом.
Синтаксис команды:
hadoop dfsadmin [-allowSnapshot <snapshotDir>]Команда disallowSnapshot устанавливает запрет на создание снапшотов каталога. Перед тем, как установить запрет на создание снапшотов, необходимо удалить все снапшоты каталога.
Синтаксис команды:
hadoop dfsadmin [-disallowSnapshot <snapshotDir>]Команда shutdownDatanode позволяет отправить запрос на завершение работы для данного DataNode.
Синтаксис команды:
hadoop dfsadmin [-shutdownDatanode <datanode_host:ipc_port> [upgrade]]Команда evictWriters позволяет заставить DataNode завершить все клиентские соединения, которые записывают блок. Это полезно, если вывод из эксплуатации зависает из-за медленной записи.
Синтаксис команды:
hadoop dfsadmin [-evictWriters <datanode_host:ipc_port>]Команда getDatanodeInfo позволяет получить информацию о данном DataNode.
Синтаксис команды:
hadoop dfsadmin [-getDatanodeInfo <datanode_host:ipc_port>]Команда metasave позволяет сохранить структуры метаданных NameNode в filename в каталоге, указанном свойством hadoop.log.dir. Filename перезаписывается, если он уже имеется. Filename будет содержать по одной строке для каждого из следующих параметров:
Синтаксис команды:
hadoop dfsadmin [-metasave filename]Команда triggerBlockReport запускает отчёт о блоках для данного DataNode. Если не указан параметр <incremental>, то запустится отчёт о полном блоке.
Синтаксис команды:
hadoop dfsadmin [-triggerBlockReport [-incremental] <datanode_host:ipc_port>]
Команда listOpenFiles выводит перечень всех открытых файлов, управляемых в настоящий момент узлом NameNode, а также имя клиента и клиентский компьютер, к которому они обращаются. Список открытых файлов будет отфильтрован по заданному типу и пути. Добавляя параметр <blockingDecommission>, будут перечислены только открытые файлы, которые блокируют вывод DataNode из эксплуатации.
Синтаксис команды:
hadoop dfsadmin [-listOpenFiles [-blockingDecommission] [-path <path>]]Команда help отображает справку для данной команды или всех команд, если ни одна не указана.
Синтаксис команды:
hadoop dfsadmin [-help [cmd]]Команда dfsrouter запускает маршрутизатор.
Синтаксис команды:
hadoop dfsrouterКоманда dfsrouteradmin предназначена для управления маршрутизатором.
Синтаксис команды:
hadoop dfsrouteradmin
[-add <source> <nameservice1, nameservice2, ...> <destination> [-readonly] [-order HASH|LOCAL|RANDOM|HASH_ALL] -owner <owner> -group <group> -mode <mode>]
[-update <source> <nameservice1, nameservice2, ...> <destination> [-readonly] [-order HASH|LOCAL|RANDOM|HASH_ALL] -owner <owner> -group <group> -mode <mode>]
[-rm <source>]
[-ls <path>]
[-setQuota <path> -nsQuota <nsQuota> -ssQuota <quota in bytes or quota size string>]
[-clrQuota <path>]
[-safemode enter | leave | get]
[-nameservice disable | enable <nameservice>]
[-getDisabledNameservices]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда diskbalancer предназначена для управления балансировщиком.
Синтаксис команды:
hadoop diskbalancer
[-plan <datanode> -fs <namenodeURI>]
[-execute <planfile>]
[-query <datanode>]
[-cancel <planfile>]
[-cancel <planID> -node <datanode>]
[-report -node <file://> | [<DataNodeID|IP|Hostname>,...]]
[-report -node -top <topnum>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда ec запускает интерфейс командной строки ErasureCoding.
Синтаксис команды:
hadoop ec [generic options]
[-setPolicy -policy <policyName> -path <path>]
[-getPolicy -path <path>]
[-unsetPolicy -path <path>]
[-listPolicies]
[-addPolicies -policyFile <file>]
[-listCodecs]
[-enablePolicy -policy <policyName>]
[-disablePolicy -policy <policyName>]
[-help [cmd ...]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда haadmin предназначена для управления состояниями NameNode.
Синтаксис команды:
hadoop haadmin -transitionToActive <serviceId> [--forceactive]
hadoop haadmin -transitionToStandby <serviceId>
hadoop haadmin -transitionToObserver <serviceId>
hadoop haadmin -failover [--forcefence] [--forceactive] <serviceId> <serviceId>
hadoop haadmin -getServiceState <serviceId>
hadoop haadmin -getAllServiceState
hadoop haadmin -checkHealth <serviceId>
hadoop haadmin -help <command>В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда journalnode предназначена для запуска узла журналов.
Синтаксис команды:
hadoop journalnodeКоманда mover запускает утилиту переноса данных.
Обратите внимание, что если опущены параметры -p и -f, по умолчанию используется корневой каталог.
Также введена функция закрепления, чтобы предотвратить перемещение определённых реплик балансировщиком/утилитой. Эта функция закрепления отключена по умолчанию, и её можно включить с помощью свойства конфигурации dfs.datanode.block-pinning.enabled. Когда эта функция включена, эта функция влияет только на блоки, которые записываются в избранные узлы, указанные в вызове create (). Эта функция полезна, когда мы хотим сохранить локальность данных для таких приложений, как HBase regionserver.
Синтаксис команды:
hadoop mover [-p <files/dirs> | -f <local file name>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команды namenode позволяют управлять NameNode.
Ниже в разделах представлены возможные команды для администрирования HDFS.
Команда backup запускает backup-узел.
Синтаксис команды:
hadoop namenode [-backup]Команда checkpoint запускает checkpoint-узел, т.е. узел контрольной точки.
Синтаксис команды:
hadoop namenode [-checkpoint]Команда format форматирует указанный NameNode. Он запускает NameNode, форматирует его, а затем закрывает. Выдаёт исключение NameNodeFormatException, если dir уже существует и для кластера отключено переформатирование.
Синтаксис команды:
hadoop namenode [-format [-clusterid cid ] [-force] [-nonInteractive] ]Команда upgrade запускает NameNode с опцией обновления после распространения новой версии Hadoop.
Синтаксис команды:
hadoop namenode [-upgrade [-clusterid cid] [-renameReserved<k-v pairs>] ]Команда upgradeOnly обновляет указанный NameNode, а затем выключает его.
Синтаксис команды:
hadoop namenode [-upgradeOnly [-clusterid cid] [-renameReserved<k-v pairs>] ]Команда rollback откатывает NameNode к предыдущей версии. Команду следует использовать после остановки кластера и разворачивания старой версии Hadoop.
Синтаксис команды:
hadoop namenode [-rollback]Команда rollingUpgrade обновляет и закрывает указанный NameNode.
Синтаксис команды:
hadoop namenode [-rollingUpgrade <rollback |started> ]Команда importCheckpoint загружает изображение из каталога контрольных точек и сохраняет его в текущем. Каталог dir контрольной точки считывается из свойства dfs.namenode.checkpoint.dir.
Синтаксис команды:
hadoop namenode [-importCheckpoint]Команда initializeSharedEdits форматирует новый общий каталог изменений и копирует в достаточное количество сегментов журнала, чтобы можно было запустить резервный NameNode.
Синтаксис команды:
hadoop namenode [-initializeSharedEdits]Команда bootstrapStandby позволяет загрузить резервные каталоги хранилища NameNode путём копирования последнего снимка пространства имён из активного NameNode. Команда используется при первой настройке кластера высокой доступности.
Параметры -force или -nonInteractive имеют то же значение, что и описанный в команде -format. Параметр skipSharedEditsCheck пропускает проверку правок, которая гарантирует, что имеется достаточно правок в общем каталоге для запуска с последней контрольной точки в активном узле имён.
Синтаксис команды:
hadoop namenode [-bootstrapStandby [-force] [-nonInteractive] [-skipSharedEditsCheck] ]Команда recover позволяет восстановить потерянные метаданные в повреждённой файловой системе.
Синтаксис команды:
hadoop namenode [-recover [-force] ]Команда metadataVersion позволяет вывести версии метаданных программного обеспечения и образа (при условии наличия настроенных каталогов).
Синтаксис команды:
hadoop namenode [-metadataVersion ]Команда nfs3 запускает шлюз NFS3.
Синтаксис команды:
hadoop nfs3Команда portmap запускает карту портов RPC.
Синтаксис команды:
hadoop portmapКоманда secondarynamenode запускает SecondaryNameNode.
Синтаксис команды:
hadoop secondarynamenode [-checkpoint [force]] | [-format] | [-geteditsize]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда storagepolicies предназначена для управления политиками хранения.
Синтаксис команды:
hadoop storagepolicies
[-listPolicies]
[-setStoragePolicy -path <path> -policy <policy>]
[-getStoragePolicy -path <path>]
[-unsetStoragePolicy -path <path>]
[-satisfyStoragePolicy -path <path>]
[-isSatisfierRunning]
[-help <command-name>]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Команда zkfc запускает процесс Zookeeper Failover Controller.
Синтаксис команды:
hadoop zkfc [-formatZK [-force] [-nonInteractive]]В команде могут быть использованы следующие параметры команды COMMAND_OPTION:
Tez позволяет создать комплексный ациклический граф задач для обработки данных. В настоящее время он реализован для YARN.
Включает основные возможности:
Tez предоставляет собственный пользовательский интерфейс, который взаимодействует с YARN Application Timeline Server и отражает текущий и исторический вид приложений Tez в веб-приложении Tez UI.
|
Внимание. Для корректной работы веб-приложения Tez UI на хосте, с которого происходит взаимодействие с веб-приложением, необходима сетевая и DNS связность с YARN Application Timeline Server. |
Для корректной работы Hive/Tez, требуется задать соответствующие значения для tez.am.resource.memory.mb, hive.tez.container.size, hive.tez.java.opts.
Нужно учитывать также, если у вас 256 GB и 16 ядер, размер контейнера не должен быть больше 16 GB.
Далее задать tez.runtime.io.sort.mb, tez.runtime.unordered.output.buffer.size-mb, hive.auto.convert.join.noconditionaltask.size.
В главе описывается CapacityScheduler — подключаемый планировщик для Hadoop, позволяющий при мультитенантности безопасно совместно использовать большой кластер таким образом, чтобы для приложений своевременно распределялись ресурсы в условиях ограниченно выделенных мощностей.
CapacityScheduler предназначен для запуска приложений Hadoop в виде общего мультитенантного кластера удобным для оператора способом при максимальной пропускной способности и загрузке кластера.
Традиционно каждая организация имеет свой собственный набор вычислительных ресурсов, которые имеют достаточную производительность для соответствия SLA предприятия в пиковых или около пиковых условиях. Как правило, это приводит к низкой средней загрузке и накладным расходам на управление несколькими независимыми кластерами по одному на каждую организацию. Поэтому совместное использование кластеров между несколькими организациями — это рентабельный способ запуска крупных Hadoop-инсталляций, так как это позволяет пользоваться преимуществами масштаба, не создавая частных кластеров. Однако организации обеспокоены совместным использованием кластера в вопросе использования другими предприятиями ресурсов, критически важных для их собственного SLA.
CapacityScheduler предназначен для совместного использования большого кластера, предоставляя при этом каждой организации гарантии производительности. Основная идея заключается в том, что доступные ресурсы в кластере Hadoop распределяются между несколькими предприятиями. Дополнительным преимуществом является то, что организация может получить доступ к любой избыточной мощности, не используемой другими. Это обеспечивает гибкость экономически эффективным образом.
Совместное использование кластеров требует строгой мультитенантности, поскольку каждому предприятию должна быть обеспечена производительность и безопасность, чтобы гарантировать, что общий кластер защищен от любого постороннего приложения или пользователя. CapacityScheduler предоставляет обязательный набор ограничений, гарантирующих, что отдельное приложение, пользователь или очередь не могут использовать непропорционально большое количество ресурсов в кластере. Кроме того, для обеспечения справедливости и стабильности кластера планировщик предоставляет для инициализированных и ожидающих приложений от одного пользователя очереди и ограничения.
Основной абстракцией, предоставляемой CapacityScheduler, является концепция очередей. Они обычно настраиваются администраторами и отражают экономику общего кластера.
С целью дополнительного контроля и предсказуемости при совместном использовании ресурсов CapacityScheduler также поддерживает иерархические очереди, чтобы обеспечить распределение ресурсов между под-очередями среди приложений внутри одной организации, прежде чем другим очередям будет позволено использовать свободные ресурсы.
CapacityScheduler поддерживает следующие функции:
1. Иерархические очереди (Hierarchical Queues).
Поддерживается иерархия очередей, обеспечивающая совместное использование ресурсов между под-очередями внутри организации, прежде чем другим очередям будет позволено использовать свободные ресурсы, что обеспечивает больший контроль и предсказуемость.
2. Гарантии производительности (Capacity Guarantees).
Очереди распределяются по части пропускной способности сети в том смысле, что в их распоряжении находится определённая производительность ресурсов. Все приложения, отправленные в очередь, имеют доступ к производительности, выделенной для этой конкретной очереди. Для каждой очереди ограничения пропускной способности настраиваются администраторами и могут быть как мягкими, так и жёсткими.
3. Безопасность (Security).
Каждая очередь имеет строгие списки ACL, которые контролируют, какие пользователи могут отправлять приложения в отдельные очереди. Кроме того, существуют средства защиты, гарантирующие, что пользователи не смогут просматривать и/или изменять приложения других пользователей. Также поддерживаются роли для каждой очереди и системного администратора.
4. Эластичность (Elasticity).
Свободные ресурсы могут быть распределены на любые очереди. Когда в будущем от очередей, работающих с пониженной производительностью, возникает потребность в ресурсах, то по мере выполнения запланированных на этих ресурсах задач они назначаются требуемым приложениям (также поддерживается преимущественное право — preemption). Это гарантирует, что ресурсы доступны для очередей предсказуемо и гибко, тем самым предотвращая искусственное разделение ресурсов в кластере и помогая их использованию.
5. Мультитенантность (Multi-tenancy).
Предоставляется набор ограничений для предотвращения монополизации ресурсов очереди или кластера одним приложением, пользователем или очередью, чтобы гарантировать, что кластер не перегружен.
6. Работоспособность (Operability).
7. Планирование на основе ресурсов (Resource-based Scheduling).
Поддержка ресурсоёмких приложений, в которых приложение может опционально определять более высокие требования к ресурсам, чем по умолчанию, тем самым приспосабливая приложения с различными требованиями к ресурсам. В настоящее время память является поддерживаемым требованием к ресурсам.
8. Маппинг очереди на основе пользователя или группы (Queue Mapping based on User or Group).
Функция позволяет пользователям сопоставлять работу с определённой очередью на основе пользователя или группы.
9. Приоритетное планирование (Priority Scheduling).
Функция позволяет направлять приложения и планировать их с разными приоритетами. Более высокое целочисленное значение указывает на более высокий приоритет для приложения. В настоящее время приоритет приложения поддерживается только для политики упорядочения FIFO.
10. Конфигурация абсолютных ресурсов (Absolute Resource Configuration).
Администраторы могут указывать абсолютные ресурсы для очереди вместо предоставления значений в процентах. Это обеспечивает лучший контроль для администраторов в целях настройки необходимого количества ресурсов для конкретной очереди.
11. Динамическое автоматическое создание и управление конечными очередями (Dynamic Auto-Creation and Management of Leaf Queues).
Функция поддерживает автоматическое создание конечных очередей в сочетании с маппингом очередей, которое в настоящее время поддерживает сопоставления очередей на основе групп пользователей для размещения приложений в очереди. Планировщик также поддерживает управление производительностью для этих очередей на основе политики, настроенной в родительской очереди.
Чтобы настроить ResourceManager для использования CapacityScheduler, необходимо установить в файле conf/yarn-site.xml свойство yarn.resourcemanager.scheduler.class со значением org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler.
etc/hadoop/capacity-scheduler.xml — файл конфигурации для CapacityScheduler.
CapacityScheduler имеет предопределённую очередь с именем root, все очереди в системе являются дочерними по отношению к ней. Очереди можно настроить в yarn.scheduler.capacity.root.queues со списком дочерних очередей, разделённых запятыми.
Конфигурация для CapacityScheduler для настройки иерархии очередей использует концепцию, называемую путь к очереди (queuepath). Путь к очереди — это полный путь иерархии очереди, начиная с root, со знаком точки . в качестве разделителя.
Дочерние элементы очереди могут быть определены с помощью настройки yarn.scheduler.capacity.<queue-path>.queues. Дочерние очереди при этом не наследуют свойства напрямую от родителя, если не указано иное.
Пример с тремя дочерними очередями верхнего уровня a, b и c и некоторыми подпоследовательностями для a и b:
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b,c</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.queues</name>
<value>a1,a2</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.queues</name>
<value>b1,b2,b3</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>1) Значение находится в диапазоне от 0 до 100;
2) Администратор должен убедиться, что абсолютная максимальная производительность больше или равна абсолютной производительности для каждой очереди. Кроме того, установка значения в -1 задает максимальную производительность в 100%;
CapacityScheduler поддерживает настройку абсолютных ресурсов вместо предоставления процентной пропускной способности очереди. Как упоминается в конфигурации для yarn.scheduler.capacity.<queue-path>.capacity и yarn.scheduler.capacity.<queue-path>.max-capacity, администратор может указать значение абсолютного ресурса, например, [memory=10240,vcores=12]. Это допустимая конфигурация, указывающая 10 ГБ памяти и 12 VCores.
Для управления запущенными и ожидающими приложениями CapacityScheduler поддерживает следующие параметры:
ACL имеет форму user1,user2 space group1,group2. Особое значение * подразумевает все. Особое значение space подразумевает никто. Значение по умолчанию * для очереди root, если не указано иное.
Пример:
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user1:queue1,g:group1:queue2,u:%user:%user,u:user2:%primary_group</value>
<description>
Here, <user1> is mapped to <queue1>, <group1> is mapped to <queue2>,
maps users to queues with the same name as user, <user2> is mapped
to queue name same as <primary group> respectively. The mappings will be
evaluated from left to right, and the first valid mapping will be used.
</description>
</property>Приоритет приложения работает только совместно с политикой упорядочения по умолчанию FIFO.
Приоритет по умолчанию для приложения может быть на уровне кластера и очереди:
|
Внимание. Приоритет приложения не изменяется при перемещении приложения в другую очередь. |
CapacityScheduler поддерживает возможность преимущественного права (preemption) контейнера от очередей, чьё использование ресурсов превышает их гарантированную производительность. Для этого следующие параметры конфигурации должны быть включены в yarn-site.xml:
Следующие параметры конфигурации могут быть настроены в yarn-site.xml для управления преимущественным правом контейнеров, когда класс ProportionalCapacityPreemptionPolicy задан для yarn.resourcemanager.scheduler.monitor.policies:
CapacityScheduler поддерживает следующие конфигурации в capacity-scheduler.xml для управления преимущественным правом контейнеров приложений, отправляемых в очередь:
CapacityScheduler поддерживает параметры для управления созданием, удалением, обновлением и списком резервирований. Важно обратить внимание, что любой пользователь может обновлять, удалять или перечислять свои собственные резервирования. Если списки ACL-резервирования включены, но не определены, доступ будет иметь каждый. В приведённых далее примерах <queue> — это имя очереди. Например, чтобы настроить ACL для управления резервированиями в очереди по умолчанию, следует использовать свойство yarn.scheduler.capacity.root.default.acl_administer_reservations.
CapacityScheduler поддерживает систему ReservationSystem, которая позволяет пользователям резервировать ресурсы заблаговременно. Таким образом приложение может запросить зарезервированные ресурсы во время выполнения, указав reservationId. Для этого могут быть настроены следующие параметры конфигурации в yarn-site.xml:
ReservationSystem интегрирована с иерархией очереди CapacityScheduler и может быть настроена для любой LeafQueue. Для этого в CapacityScheduler поддерживаются следующие параметры:
CapacityScheduler поддерживает автоматическое создание наследуемых leaf-очередей, настроенных с включенной данной функцией.
1. Настройка при помощи маппинга.
user-group queue mapping(s), перечисленные в yarn.scheduler.capacity.queue-mappings, должны содержать дополнительный параметр очереди, в которую будет осуществляться автосоздание leaf-очередей. Также важно обратить внимание, что в таких родительских очередях необходимо включить автосоздание дочерних очередей, как указано далее.
Пример:
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user1:queue1,g:group1:queue2,u:user2:%primary_group,u:%user:parent1.%user</value>
<description>
Here, u:%user:parent1.%user mapping allows any <user> other than user1,
user2 to be mapped to its own user specific leaf queue which
will be auto-created under <parent1>.
</description>
</property>2. Конфигурация родительской очереди.
Функция Dynamic Queue Auto-Creation and Management интегрирована с иерархией очереди CapacityScheduler и может быть настроена для ParentQueue для автоматического создания leaf-очередей. Такие родительские очереди не поддерживают возможность сосуществования автосозданных очередей вместе с другими предварительно сконфигурированными очередями. Свойства:
3. Настройка при помощи CapacityScheduler.
Родительская очередь для автосоздания leaf-очередей поддерживает настройку параметров их шаблона. Автосозданные очереди поддерживают все параметры конфигурации leaf-очереди, за исключением Queue ACL, Absolute Resource. Списки ACL очереди в настоящее время не настраиваются в шаблоне, но наследуются от родительской очереди. Свойства:
Пример:
<property>
<name>yarn.scheduler.capacity.root.parent1.auto-create-child-queue.enabled</name>
<value>true</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.capacity</name>
<value>5</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.maximum-capacity</name>
<value>100</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.user-limit-factor</name>
<value>3.0</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.ordering-policy</name>
<value>fair</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.GPU.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.accessible-node-labels</name>
<value>GPU,SSD</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels</name>
<value>GPU</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels.GPU.capacity</name>
<value>5</value>
</property>4. Управление конфигурацией Scheduling Edit Policy.
Администраторы должны указать дополнительную политику редактирования org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.QueueManagementDynamicEditPolicy со списком текущих политик в виде строки и разделенные запятыми в конфигурации yarn.resourcemanager.scheduler.monitor.policies.
1. Калькулятор ресурсов.
2. Расположение данных.
Capacity Scheduler использует Delay Scheduling для соблюдения ограничений месторасположения задач. Существует 3 уровня: node-local, rack-local и off-switch. Планировщик учитывает количество упущенных возможностей, когда локальность не может быть удовлетворена, и ждёт, пока это число достигнет порогового значения, прежде чем ослабить ограничение положения до следующего уровня. Порог можно настроить в следующих свойствах:
Важно обратить внимание, что эту функцию следует отключить, если YARN развёртывается отдельно от файловой системы, поскольку локальность в таком случае не имеет смысла. Для этого необходимо установить yarn.scheduler.capacity.node-locality-delay в значение -1, тогда ограничение на местоположение запроса игнорируется.
3. Распределение контейнеров по NodeManager Heartbeat.
Конфигурацию CapacityScheduler можно проверить после завершения установки и настройки путём запуска кластера YARN через веб-интерфейс:
Изменение конфигурации очереди через файл осуществляется путём редактирования conf/capacity-scheduler.xml и запуска yarn rmadmin -refreshQueues:
$ vi $HADOOP_CONF_DIR/capacity-scheduler.xml
$ $HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueuesУдаление очереди через файл реализуется в два шага:
Изменение конфигурации очереди через API осуществляется путём использования резервного хранилища для конфигурации планировщика. Для этого могут быть настроены параметры в yarn-site.xml:
При включении конфигурации планировщика через yarn.scheduler.configuration.store.class, отключается yarn rmadmin -refreshQueues, то есть исключается возможность обновления конфигурации через файл.
|
Внимание. Функция изменения конфигурации очереди через API находится в альфа-фазе и может быть изменена. |
Как только Application Master получает контейнер от Resource Manager, Master может запросить у Manager обновить некоторые атрибуты контейнера. В настоящее время поддерживаются только два типа обновлений контейнера:
Этому способствует Application Master, заполняющий поле updated_containers, представляющее собой список типа UpdateContainerRequestProto в AllocateRequestProto. Master может сделать несколько запросов на обновление контейнера в одном вызове.
Схема UpdateContainerRequestProto выглядит следующим образом:
message UpdateContainerRequestProto {
required int32 container_version = 1;
required ContainerIdProto container_id = 2;
required ContainerUpdateTypeProto update_type = 3;
optional ResourceProto capability = 4;
optional ExecutionTypeProto execution_type = 5;
}ContainerUpdateTypeProto является перечислением:
enum ContainerUpdateTypeProto {
INCREASE_RESOURCE = 0;
DECREASE_RESOURCE = 1;
PROMOTE_EXECUTION_TYPE = 2;
DEMOTE_EXECUTION_TYPE = 3;
}В соответствии с приведённым перечислением планировщик в настоящее время поддерживает изменение типа обновлений контейнера Resource Update либо ExecutionType Update в одном запросе.
Application Master также должен предоставить последнюю версию ContainerProto, полученную от Resource Manager — это контейнер, который Manager запрашивает на обновление.
Если Resource Manager может обновить запрошенный контейнер, то тогда обновленный контейнер возвращается в поле списка updated_containers типа UpdatedContainerProto в возвращаемом значении AllocateResponseProto того же самого вызова или одного из последующих.
Схема UpdatedContainerProto выглядит следующим образом:
message UpdatedContainerProto {
required ContainerUpdateTypeProto update_type = 1;
required ContainerProto container = 2;
}Здесь указывается тип выполненного обновления для контейнера и объект обновлённого контейнера, содержащий обновлённый токен.
Затем токен контейнера может использоваться Application Master для запроса соответствующего NodeManager либо запуска контейнера, если он еще не запущен, либо для обновления контейнера с использованием обновлённого токена.
Обновления контейнера DECREASE_RESOURCE и DEMOTE_EXECUTION_TYPE выполняются автоматически — Application Master не должен явно запрашивать NodeManager, чтобы уменьшить ресурсы контейнера. Другие типы обновлений требуют, чтобы Master явно запрашивал об обновлении.
Если для параметра конфигурации yarn.resourcemanager.auto-update.containers задано значение true (по умолчанию false), Resource Manager обеспечивает автоматическое обновление всех контейнеров.
В главе описывается FairScheduler — подключаемый планировщик для Hadoop, позволяющий YARN-приложениям справедливо распределять ресурсы в больших кластерах.
Справедливое планирование — это метод распределения ресурсов между приложениями таким образом, чтобы все приложения в среднем получали равную долю ресурсов с течением времени. Hadoop NextGen способен планировать несколько типов ресурсов. По умолчанию в FairScheduler планирование решений основывается только на памяти. Но он также может быть сконфигурирован для планирования, основанного на памяти вместе с процессором, используя понятие Dominant Resource Fairness, разработанное Ghodsi et al.
Когда запущено одно приложение, оно использует весь кластер. А при добавлении новых приложений, им назначаются освобождающиеся ресурсы, таким образом каждое приложение в конечном итоге получает примерно одинаковый объём ресурсов. В отличие от стандартного планировщика Hadoop, который формирует очередь приложений, FairScheduler позволяет коротким приложениям завершать работу в разумные сроки, не оставляя ждать при этом долговременные приложения. Это также разумный способ разделить кластер между несколькими пользователями. Наконец, справедливое распределение может также работать с приоритетностью приложений — приоритеты используются в качестве веса для определения доли ресурсов от их совокупности, которую должны получить приложения.
Далее планировщик организует приложения в “очереди” и справедливо распределяет ресурсы между этими очередями. По умолчанию все пользователи имеют общую очередь с именем default. Если приложение специально указывает очередь в запросе ресурса контейнера, запрос отправляется в эту очередь. Также можно назначать очереди на основе имени пользователя, включённого в запрос, через конфигурацию. В каждой очереди имеется политика планирования для совместного использования ресурсов между запущенными приложениями. По умолчанию устанавливается распределение ресурсов на основе памяти, но также могут быть настроены FIFO и мультиресурсность с Dominant Resource Fairness. Очереди могут быть организованы в иерархию для разделения ресурсов и настроены с весами для совместного использования кластера в определенных пропорциях.
Кроме этого, FairScheduler позволяет назначать гарантированные минимальные доли в очереди, что полезно для обеспечения определённых пользователей, групп или рабочих приложений достаточными ресурсами. Когда очередь содержит приложения, она получает по крайней мере свою минимальную долю, но когда очередь не нуждается в полной гарантированной доле, избыток распределяется между другими запущенными приложениями. Это позволяет планировщику гарантировать пропускную способность очередей при эффективном использовании ресурсов, когда эти очереди не содержат приложений.
FairScheduler позволяет запускать все приложения по умолчанию, но также через файл конфигурации можно ограничить количество запущенных приложений на пользователя и на очередь. Это может быть полезно, когда пользователь должен одновременно отправить сотни приложений, или в целом для повышения производительности, если запуск слишком большого количества приложений может привести к созданию слишком большого объёма промежуточных данных или слишком частому переключению контекста. Ограничение приложений не приводит к сбою каких-либо последующих отправленных приложений, а только к ожиданию в очереди планировщика, пока не завершатся более ранние приложения пользователя.
FairScheduler поддерживает иерархию очередей. Все очереди происходят из очереди с именем root. Доступные ресурсы распределяются между дочерними элементами root-очереди типичным способом справедливого планирования. Затем дочерние очереди таким же образом распределяют выделенные им ресурсы по своим дочерним очередям. Приложения могут быть запланированы только в leaf-очередях. Очереди можно указывать как дочерние элементы других очередей, помещая их как подэлементы в файл распределения.
Имя очереди начинается с перечисления имён её родителей с точками в качестве разделителей. Таким образом, очередь с именем queue1 в root-очереди называется “root.queue1”, а очередь с именем queue2 в очереди с именем “parent1” называется “root.parent1.queue2”. При обращении к очередям часть имени root необязательна, поэтому queue1 может называться просто “queue1”, а queue2 — “parent1.queue2”.
Кроме того, FairScheduler позволяет устанавливать различные индивидуальные политики для каждой очереди, чтобы разрешить совместное использование ресурсов любым удобным для пользователя способом. Политика может быть построена путём расширения org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy. FifoPolicy, FairSharePolicy (по умолчанию) и DominantResourceFairnessPolicy являются встроенными и могут быть легко использованы.
Некоторые дополнения ещё не поддерживаются в оригинальном (MR1) Fair Scheduler. Среди них — использование индивидуальных политик, управляющих приоритетом “boosting” над определёнными приложениями.
Планировщик Fair Scheduler позволяет администраторам настраивать политики, которые автоматически помещают отправленные приложения в соответствующие очереди. Размещение может зависеть от пользователя и групп отправителя и запрашиваемой очереди. Политика состоит из набора правил, которые применяются последовательно для классификации входящего приложения. Каждое правило либо помещает приложение в очередь, либо отклоняет его, либо переходит к следующему правилу. Далее в документации приведён формат файла распределения для настройки этих политик.
Для использования Fair Scheduler сначала необходимо назначить соответствующий класс планировщика в yarn-site.xml:
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>Настройка планировщика Fair Scheduler обычно включает в себя изменение двух файлов. Во-первых, можно настроить параметры всего планировщика, добавив свойства конфигурации в файл yarn-site.xml в существующую директорию. Во-вторых, в большинстве случаев пользователи желают создать список файлов распределения, в котором указываются существующие очереди и соответствующий им вес и пропускная способность. Файл распределения перезагружается каждые 10 секунд, позволяя вносить изменения на лету.
Свойства в файле yarn-site.xml:
Файл распределения должен быть в формате XML.
1. Элементы очереди. Элементы очереди могут принимать необязательный атрибут type, который при установке на parent делает очередь родительской. Это полезно в случаях, когда необходимо создать родительскую очередь без настройки каких-либо leaf-очередей. Каждый элемент очереди может содержать следующие свойства:
2. Элементы пользователя. Представляют собой настройки, управляющие поведением отдельных пользователей. Они могут содержать одно свойство:
3. Элемент userMaxAppsDefault. Устанавливает лимит запуска приложения по умолчанию для всех пользователей, у которых не указано иное ограничение.
4. Элемент defaultFairSharePreemptionTimeout. Задаёт тайм-аут преимущественного права preemption для root-очереди. Переопределяется элементом fairSharePreemptionTimeout в root-очереди. По умолчанию значение Long.MAX_VALUE.
5. Элемент defaultMinSharePreemptionTimeout. Устанавливает минимальное время ожидания преимущественного права preemption для root-очереди. Переопределяется элементом minSharePreemptionTimeout в root-очереди. По умолчанию значение Long.MAX_VALUE.
6. Элемент defaultFairSharePreemptionThreshold. Задаёт порог преимущественного права для root-очереди. Переопределяется элементом fairSharePreemptionThreshold в root-очереди. По умолчанию значение 0.5f.
7. Элемент queueMaxAppsDefault. Устанавливает ограничение по умолчанию для запущенного приложения для очередей. Переопределяется элементом maxRunningApps в каждой очереди.
8. Элемент queueMaxResourcesDefault. Задаёт максимальный лимит ресурсов по умолчанию для очереди. Переопределяется элементом maxResources в каждой очереди.
9. Элемент queueMaxAMShareDefault. Устанавливает ограничение ресурса Application Master по умолчанию для очереди. Переопределяется элементом maxAMShare в каждой очереди.
10. Элемент defaultQueueSchedulingPolicy. Устанавливает политику планирования по умолчанию для очередей. Переопределяется элементом schedulingPolicy в каждой очереди, если указан. По умолчанию fair.
11. Элемент reservation-agent. Задаёт имя класса для реализации ReservationAgent, который пытается разместить запрос пользователя на резервирование в Plan. Значением по умолчанию является org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy.
12. Элемент reservation-policy. Задаёт имя класса реализации SharingPolicy, который проверяет, не нарушает ли новое резервирование какие-либо инварианты. Значением по умолчанию является org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.
13. Элемент reservation-planner. Задаёт имя класса для реализации Planner, который вызывается, если пропускная способность Plan падает ниже зарезервированных пользователем ресурсов (из-за планового обслуживания или отказов узла). Значение по умолчанию org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner, что приводит к сканированию Plan и жадному удалению резервирований в обратном порядке (LIFO) до тех пор, пока зарезервированные ресурсы не оказываются в пределах производительности Plan.
14. Элемент queuePlacementPolicy. Содержит список элементов правил, которые сообщают планировщику, как в очередях размещать входящие приложения. Правила применяются в том порядке, в котором они перечислены. Правила могут принимать аргументы. Все правила принимают аргумент create, который указывает, может ли правило создавать новую очередь. Create по умолчанию имеет значение true. Если установлено значение false и правило помещает приложение в очередь, которая не настроена в файле распределения, осуществляется переход к следующему правилу. Последнее правило должно быть заключительным, не вызывающим продолжения. Допустимые правила:
Пример распределённого файла:
<?xml version="1.0"?>
<allocations>
<queue name="sample_queue">
<minResources>10000 mb,0vcores</minResources>
<maxResources>90000 mb,0vcores</maxResources>
<maxRunningApps>50</maxRunningApps>
<maxAMShare>0.1</maxAMShare>
<weight>2.0</weight>
<schedulingPolicy>fair</schedulingPolicy>
<queue name="sample_sub_queue">
<aclSubmitApps>charlie</aclSubmitApps>
<minResources>5000 mb,0vcores</minResources>
</queue>
<queue name="sample_reservable_queue">
<reservation></reservation>
</queue>
</queue>
<queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>
<queueMaxResourcesDefault>40000 mb,0vcores</queueMaxResourcesDefault>
<!-- Queue 'secondary_group_queue' is a parent queue and may have
user queues under it -->
<queue name="secondary_group_queue" type="parent">
<weight>3.0</weight>
<maxChildResources>4096 mb,4vcores</maxChildResources>
</queue>
<user name="sample_user">
<maxRunningApps>30</maxRunningApps>
</user>
<userMaxAppsDefault>5</userMaxAppsDefault>
<queuePlacementPolicy>
<rule name="specified" />
<rule name="primaryGroup" create="false" />
<rule name="nestedUserQueue">
<rule name="secondaryGroupExistingQueue" create="false" />
</rule>
<rule name="default" queue="sample_queue"/>
</queuePlacementPolicy>
</allocations>
|
Внимание. Для обратной совместимости с исходным FairScheduler элементы queue могут быть названы как элементы pool. |
Списки контроля доступа к очереди (Queue Access Control Lists, Queue ACL) позволяют администраторам контролировать, кто может выполнять действия в определенных очередях. Они настраиваются с помощью свойств aclSubmitApps и aclAdministerApps, которые можно установить для каждой очереди. В настоящее время единственным поддерживаемым административным действием является уничтожение приложения. Администратор также может отправлять приложения на уничтожение. Свойства принимают значения в формате “user1,user2 group1,group2” или ” group1,group2” (с учётом пробела). Действия в очереди разрешены, если пользователь/группа является членом Queue ACL самой очереди или любой из её родителей. Таким образом, если queue2 находится в queue1, а user1 находится в ACL queue1, а user2 находится в ACL queue2, тогда оба пользователя могут отправиться в queue2.
|
Внимание. Пробел является разделителем. Для того, чтобы указать только группы ACL, значение должно начинаться с символа пробела. |
|
Внимание. По умолчанию списки ACL для root-очереди имеют значение *, что означает, что по причине того, что списки ACL передаются, любой пользователь может отправлять и уничтожать приложения из любой очереди. Для ограничения доступа необходимо изменить ACL root-очереди на что-то отличное от указанного символа. |
Списки контроля доступа к резервированию (Reservation Access Control Lists, Reservation ACL) позволяют администраторам контролировать, кто может выполнять действия по резервированию в определённых очередях. Они настраиваются с помощью свойств aclAdministerReservations, aclListReservations и aclSubmitReservations, которые можно установить для каждой очереди. В настоящее время поддерживаемые административные действия — это обновление и удаление резервирований. Администратор также может отправлять и перечислять все резервирования в очереди. Свойства принимают значения в формате “user1,user2 group1,group2” или ” group1,group2” (с учётом пробела). Действия в очереди разрешены, если пользователь/группа является членом Reservation ACL. Важно обратить внимание, что любой пользователь может обновлять, удалять или перечислять свои собственные резервирования.
|
Внимание. Если Reservation ACL включены, но не определены, доступ будет иметь каждый пользователь. |
Fair Scheduler поддерживает ReservationSystem, позволяющую пользователям резервировать ресурсы заблаговременно. Таким образом приложение может запросить зарезервированные ресурсы во время выполнения, указав reservationId. Для этого могут быть настроены следующие параметры конфигурации в yarn-site.xml:
ReservationSystem интегрирована с иерархией очереди Fair Scheduler и может быть настроена только для leaf-очередей.
Есть возможность изменения минимальных долей, лимитов, веса, тайм-аута преимущественного права preemtion и политики планирования очередей на лету во время выполнения посредством редактирования файла распределения. Планировщик перезагружает файл через 10-15 секунд после того, как увидит, что он изменён.
Текущие приложения, очереди и общие ресурсы можно просмотреть через веб-интерфейс ResourceManager по адресу http://*ResourceManager URL*/cluster/scheduler. Для каждой очереди в веб-интерфейсе можно просмотреть следующие поля:
Fair Scheduler поддерживает возможность перемещения запущенного приложения в другую очередь. Это может быть полезно для перемещения важного приложения в очередь с более высоким приоритетом или для перемещения неважного приложения в очередь с более низким приоритетом. Приложения можно перемещать, запустив yarn application -movetoqueue appID -queue targetQueueName.
Когда приложение перемещается в очередь, его существующие распределения пересчитываются с распределениями новой очереди для целей определения справедливости. Если добавление ресурсов приложения приводит к нарушению ограничения maxRunningApps или maxResources в новой очереди, то попытка переместить приложение в неё завершается неудачей.
Fair Scheduler может периодически сбрасывать своё состояние. По умолчанию данная функция отключена, но администратор может включить её, установив для уровня org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.statedump значение DEBUG.
Журналы Fair Scheduler по умолчанию отправляются в лог-файл Resource Manager. Но дампы состояния планировщика потенциально могут генерировать большой объём данных, поэтому для того, чтобы вывести состояние в отдельный файл, необходимо раскомментировать раздел Fair scheduler state dump в log4j.properties.
YARN Timeline Service v.2 — это следующая крупная итерация Timeline Server после v.1 и v.1.5. Версия v.2 создана с целью решения двух основных задач v.1:
1. Масштабируемость.
Версия v.1 ограничивается одним экземпляром устройства записи/чтения и хранения и не может масштабироваться далеко за пределы небольших кластеров. Версия v.2 использует более масштабируемую распределённую архитектуру записи и масштабируемое backend-хранилище.
YARN Timeline Service v.2 отделяет сбор (запись) данных от обслуживания (чтения) данных. Он использует распределённые коллекторы, и по существу для каждого приложения YARN выделяется один коллектор. Читатели — это отдельные экземпляры, предназначенные для обслуживания запросов через REST API.
В качестве основного резервного хранилища YARN Timeline Service v.2 выбирает СУБД Apache HBase, поскольку она хорошо масштабируется до большого размера, сохраняя при этом хорошее время отклика для чтения и записи.
2. Улучшения юзабилити.
В большинстве случаев пользователи интересуются информацией на уровне “потоков” (flows) или логических групп приложений YARN. Гораздо более распространённым является запуск набора или серии приложений YARN для завершения логического приложения. Timeline Service v.2 поддерживает понятие потоков в явном виде. Кроме того, он поддерживает агрегирование метрик на flow-уровне.
К тому же, такая информация, как конфигурация и метрики, обрабатывается и поддерживается как объекты первого класса.
YARN Timeline Service v.2 использует набор коллекторов (писателей) для записи данных в backend-хранилище. Коллекторы распределяются и размещаются совместно с Application Masters (AM), которым они предназначены. Все данные, принадлежащие приложению, отправляются timeline-коллекторам уровня приложения, за исключением timeline-коллектора уровня Resource Manager (RM).
Для такого приложения Application Master может записывать данные в совместно расположенные timeline-коллекторы (которые являются вспомогательным сервисом NodeManager в этом выпуске). Кроме того, NodeManagers других узлов с выполняющимися контейнерами для приложения, также записывают данные в timeline-коллектор на узле, на котором выполняется Application Master.
Resource Manager тоже поддерживает свой собственный timeline-коллектор. Он генерирует только события жизненного цикла, характерные для YARN, чтобы поддерживать разумный объём записей.
Timeline-читатели — это отделённые от timeline-коллекторов демоны, предназначенные для обслуживания запросов через REST API.
YARN Timeline Service v.2 в настоящее время находится в альфа-версии (“alpha 2”). Разработка части функционала находится в процессе, и многие вещи могут и будут быстро меняться.
Полный сквозной поток операций записи и чтения является функциональным с Apache HBase в качестве серверной части. При включении сервиса публикуются все общие для YARN события, а также системные метрики YARN, такие как процессор и память. Кроме того, некоторые приложения, в том числе Distributed Shell и MapReduce, могут записывать в YARN Timeline Service v.2 данные для каждой платформы.
Основным способом доступа к данным является REST. Поэтому REST API поставляется с большим количеством полезных и гибких шаблонов запросов (REST API). К тому же в настоящее время отсутствует поддержка доступа к командной строке.
Коллекторы (писатели) в настоящее время встроены в Node Managers в качестве вспомогательных сервисов. Resource Manager также имеет свой специальный внутрипроцессный коллектор. Читатель в настоящее время является единственным экземпляром. Также в текущий период невозможно выполнить запись в Timeline Service вне контекста приложения YARN (то есть вне кластерного клиента).
Начиная с alpha2, Timeline Service v.2 поддерживает простую авторизацию в виде настраиваемого белого списка пользователей и групп, которые могут читать timeline-данные. Администраторам кластера по умолчанию разрешено читать эти данные.
Отключённый YARN Timeline Service v.2 никак не влияет на любую другую существующую функциональность.
Работа, чтобы сделать сервис действительно готовым к production-ready, продолжается. Некоторые ключевые элементы включают в себя:
Конфигурация. Basic:
Новые параметры, введенные в версии v.2:
Конфигурация. Advanced:
Новые параметры, введённые в версии v.2:
Безопасность можно включить, установив для yarn.timeline-service.http-authentication.type значение kerberos, после чего станут доступны следующие параметры конфигурации:
Для включения поддержки совместного использования ресурсов (Cross-origin resource sharing, CORS) в Timeline Service v.2 необходимо установить следующие параметры конфигурации:
Важно обратить внимание, что параметр yarn.timeline-service.http-cross-origin.enabled, установленный на true, переопределяет hadoop.http.cross-origin.enabled.
Подготовка кластера Apache HBase к Timeline Service v.2 заключается в выполнении нескольких шагов:
Первый шаг заключается в настройке или выборе Apache HBase для использования в качестве кластера хранения. Версия Timeline Service v.2 поддерживает Apache HBase 1.2.6. Ранние версии Apache HBase (1.0.x) не работают с Timeline Service v.2, а более поздние не протестированы.
HBase имеет разные режимы развёртывания. При намерении создания простого профиля для кластера Apache HBase со слабой загрузкой данных, но с сохранением их при входе и выходе с узла, подходит режим развёртывания “Standalone HBase over HDFS”.
Это полезный вариант автономной настройки HBase, когда все демоны HBase работают внутри одной JVM, и вместо того, чтобы сохраняться в локальной файловой системе, сохраняются в экземпляре HDFS. Для настройки такого автономного варианта необходимо отредактировать файл hbase-site.xml, указав hbase.rootdir на каталог в экземпляре HDFS, а затем установить для hbase.cluster.distributed значение false. Например:
<configuration>
<property>
<name>hbase.rootdir</name>
<value>hdfs://namenode.example.org:8020/hbase</value>
</property>
<property>
<name>hbase.cluster.distributed</name>
<value>false</value>
</property>
</configuration>В этой версии осуществляется динамическая загрузка сопроцессора (табличный сопроцессор для flowrun-таблицы). Для этого необходимо скопировать jar-файл сервиса timeline в HDFS, откуда HBase сможет его загрузить. Это требуется для создания flowrun-таблицы в schema creator. По умолчанию расположение в HDFS — /hbase/coprocessor. Например:
hadoop fs -mkdir /hbase/coprocessor
hadoop fs -put hadoop-yarn-server-timelineservice-hbase-3.0.0-alpha1-SNAPSHOT.jar
/hbase/coprocessor/hadoop-yarn-server-timelineservice.jarТакже можно воспользоваться параметром yarn-конфигурации — yarn.timeline-service.hbase.coprocessor.jar.hdfs.location. Например:
<property>
<name>yarn.timeline-service.hbase.coprocessor.jar.hdfs.location</name>
<value>/custom/hdfs/path/jarName</value>
</property>Подготовка кластера Apache HBase к Timeline Service v.2 завершается запуском инструмента schema creator для создания необходимых таблиц:
bin/hadoop org.apache.hadoop.yarn.server.timelineservice.storage.TimelineSchemaCreator -createИнструмент TimelineSchemaCreator поддерживает несколько опций, которые могут пригодиться, особенно при тестировании. Например, можно использовать -skipExistingTable (сокращенно -s), чтобы пропустить существующие таблицы и продолжить создание других таблиц, не прерывая создания схемы. Если параметр или -help (сокращенно -h) не задан, отображается command usage и продолжается создание других таблиц без сбоя создания схемы. По умолчанию таблицы имеют префикс схемы prod..
Основные конфигурации для запуска Timeline service v.2:
<property>
<name>yarn.timeline-service.version</name>
<value>2.0f</value>
</property>
<property>
<name>yarn.timeline-service.enabled</name>
<value>true</value>
</property>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle,timeline_collector</value>
</property>
<property>
<name>yarn.nodemanager.aux-services.timeline_collector.class</name>
<value>org.apache.hadoop.yarn.server.timelineservice.collector.PerNodeTimelineCollectorsAuxService</value>
</property>
<property>
<description>The setting that controls whether yarn system metrics is
published on the Timeline service or not by RM And NM.</description>
<name>yarn.system-metrics-publisher.enabled</name>
<value>true</value>
</property>
<property>
<description>The setting that controls whether yarn container events are
published to the timeline service or not by RM. This configuration setting
is for ATS V2.</description>
<name>yarn.rm.system-metrics-publisher.emit-container-events</name>
<value>true</value>
</property>Кроме того, для имени кластера YARN можно установить уникальное значение (удобно при использовании нескольких кластеров для хранения данных в одном и том же хранилище Apache HBase):
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>my_research_test_cluster</value>
</property>Также можно добавить файл hbase-site.xml в конфигурацию кластера Hadoop клиента, чтобы он мог записывать данные в используемый кластер Apache HBase, или установить yarn.timeline-service.hbase.configuration.file в URL файла на hbase-site.xml. Например:
<property>
<description> Optional URL to an hbase-site.xml configuration file to be
used to connect to the timeline-service hbase cluster. If empty or not
specified, then the HBase configuration will be loaded from the classpath.
When specified the values in the specified configuration file will override
those from the ones that are present on the classpath.
</description>
<name>yarn.timeline-service.hbase.configuration.file</name>
<value>file:/etc/hbase/hbase-ats-dc1/hbase-site.xml</value>
</property>Для того, чтобы выбрать новую конфигурацию, необходимо перезапустить Resource Manager, а также Node Managers. Коллекторы запускаются в рамках Resource Manager и Node Managers.
Timeline Service reader — это отдельный демон YARN, который можно запустить, используя следующий синтаксис:
$ yarn-daemon.sh start timelinereaderДля записи данных MapReduce в Timeline Service v.2 необходимо включить следующую конфигурацию в mapred-site.xml:
<property>
<name>mapreduce.job.emit-timeline-data</name>
<value>true</value>
</property>При использовании Timeline Service v.2 версии alpha1 рекомендуется:
Глава предназначена для разработчиков приложений YARN, которые хотят интегрироваться с Timeline Service v.2.
Разработчикам необходимо использовать TimelineV2Client API для публикации данных для каждой платформы в Timeline Service v.2, поскольку API сущности/объекта для v.2 значительно изменилось по отношению к v.1, в части объектной модели. Класс сущности в v.2 — org.apache.hadoop.yarn.api.records.timelineservice.TimelineEntity.
Метод putEntities в Timeline Service v.2 бывает двух видов: putEntities и putEntitiesAsync. Первый — это операция блокировки, используемая для записи наиболее важных данных (например, событий жизненного цикла). Последний является неблокирующей операцией. Важно обратить внимание, что ни один из методов не имеет возвращаемого значения.
Создание TimelineV2Client включает передачу идентификатора приложения статическому методу TimelineV2Client.createTimelineClient.
// Create and start the Timeline client v.2
TimelineV2Client timelineClient =
TimelineV2Client.createTimelineClient(appId);
timelineClient.init(conf);
timelineClient.start();
try {
TimelineEntity myEntity = new TimelineEntity();
myEntity.setType("MY_APPLICATION");
myEntity.setId("MyApp1");
// Compose other entity info
// Blocking write
timelineClient.putEntities(myEntity);
TimelineEntity myEntity2 = new TimelineEntity();
// Compose other info
// Non-blocking write
timelineClient.putEntitiesAsync(myEntity2);
} catch (IOException | YarnException e) {
// Handle the exception
} finally {
// Stop the Timeline client
timelineClient.stop();
}Как показано в примере, следует указать идентификатор приложения YARN, чтобы иметь возможность записи в Timeline Service v.2. Также важно обратить внимание, что при текущей версии необходимо находиться в кластере, чтобы иметь возможность записи в сервис. Например, Application Master или код в контейнере могут выполнять запись в Timeline Service, в то время как отправитель задания (job submitter) MapReduce вне кластера — нет.
После создания клиента timeline v2 пользователь также должен установить информацию timeline-коллектора, содержащую его адрес и токен (только в безопасном режиме) для приложения. Если используется AMRMClient, то достаточно зарегистрировать timeline-клиент, вызвав AMRMClient#registerTimelineV2Client.
amRMClient.registerTimelineV2Client(timelineClient)Ещё один адрес должен быть извлечён из распределённого отклика от Application Master и должен быть явно установлен в timeline-клиенте:
timelineClient.setTimelineCollectorInfo(response.getCollectorInfo());Создавать и публиковать собственные сущности, события и метрики можно также, как и в предыдущих версиях.
Объекты TimelineEntity имеют следующие поля для хранения timeline-данных:
Важно обратить внимание, что при публикации timeline-метрик можно выбрать способ агрегирования каждой метрики с помощью метода TimelineMetric#setRealtimeAggregationOp(). Слово “aggregate” здесь означает применение одной из операций TimelineMetricOperation для набора сущностей. Timeline service v2 обеспечивает встроенную агрегацию на уровне приложения, что означает агрегирование метрик из разных timeline-сущностей в одном YARN-приложении. В настоящее время в TimelineMetricOperation поддерживается два вида операций:
По умолчанию задаётся NOP — в реальном времени никакая операция агрегирования не выполняется.
Платформы приложений по возможности должны устанавливать “flow context”, чтобы воспользоваться преимуществами поддержки потока Timeline Service v.2. Контекст потока состоит из:
Если контекст потока не указан, по умолчанию предоставляется:
Можно предоставить контекст потока через теги YARN-приложения:
ApplicationSubmissionContext appContext = app.getApplicationSubmissionContext();
// set the flow context as YARN application tags
Set<String> tags = new HashSet<>();
tags.add(TimelineUtils.generateFlowNameTag("distributed grep"));
tags.add(Timelineutils.generateFlowVersionTag("3df8b0d6100530080d2e0decf9e528e57c42a90a"));
tags.add(TimelineUtils.generateFlowRunIdTag(System.currentTimeMillis()));
appContext.setApplicationTags(tags);
|
Внимание. Resource Manager преобразует теги приложения YARN в нижний регистр перед их сохранением. Следовательно, необходимо преобразовать имена и версии потоков в нижний регистр, прежде чем использовать их в запросах REST API. |
Запросы Timeline Service v.2 в настоящее время поддерживается только через REST API; в библиотеках YARN не реализован API-клиент.
REST API в версии v.2 осуществляется по пути /ws/v2/timeline/ в веб-сервисе Timeline Service.
Root path:
GET /ws/v2/timeline/Возвращает объект JSON, описывающий экземпляр сервиса и информацию о версии.
{
"About":"Timeline Reader API",
"timeline-service-version":"3.0.0-alpha1-SNAPSHOT",
"timeline-service-build-version":"3.0.0-alpha1-SNAPSHOT from fb0acd08e6f0b030d82eeb7cbfa5404376313e60 by sjlee source checksum be6cba0e42417d53be16459e1685e7",
"timeline-service-version-built-on":"2016-04-11T23:15Z",
"hadoop-version":"3.0.0-alpha1-SNAPSHOT",
"hadoop-build-version":"3.0.0-alpha1-SNAPSHOT from fb0acd08e6f0b030d82eeb7cbfa5404376313e60 by sjlee source checksum ee968fd0aedcc7384230ee3ca216e790",
"hadoop-version-built-on":"2016-04-11T23:14Z"
}Далее описываются поддерживаемые запросы в REST API.
С помощью Query Flows API можно получить список активных потоков, запущенных за последнее время. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если ни один из потоков не соответствует предикатам, возвращается пустой список.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/flows/
or
GET /ws/v2/timeline/flows/Поддерживаемые параметры запроса:
Пример ответа JSON:
[
{
"metrics": [],
"events": [],
"id": "test-cluster/1460419200000/sjlee@ds-date",
"type": "YARN_FLOW_ACTIVITY",
"createdtime": 0,
"flowruns": [
{
"metrics": [],
"events": [],
"id": "sjlee@ds-date/1460420305659",
"type": "YARN_FLOW_RUN",
"createdtime": 0,
"info": {
"SYSTEM_INFO_FLOW_VERSION": "1",
"SYSTEM_INFO_FLOW_RUN_ID": 1460420305659,
"SYSTEM_INFO_FLOW_NAME": "ds-date",
"SYSTEM_INFO_USER": "sjlee"
},
"isrelatedto": {},
"relatesto": {}
},
{
"metrics": [],
"events": [],
"id": "sjlee@ds-date/1460420587974",
"type": "YARN_FLOW_RUN",
"createdtime": 0,
"info": {
"SYSTEM_INFO_FLOW_VERSION": "1",
"SYSTEM_INFO_FLOW_RUN_ID": 1460420587974,
"SYSTEM_INFO_FLOW_NAME": "ds-date",
"SYSTEM_INFO_USER": "sjlee"
},
"isrelatedto": {},
"relatesto": {}
}
],
"info": {
"SYSTEM_INFO_CLUSTER": "test-cluster",
"UID": "test-cluster!sjlee!ds-date",
"FROM_ID": "test-cluster!1460419200000!sjlee!ds-date",
"SYSTEM_INFO_FLOW_NAME": "ds-date",
"SYSTEM_INFO_DATE": 1460419200000,
"SYSTEM_INFO_USER": "sjlee"
},
"isrelatedto": {},
"relatesto": {}
}
]Код ответа:
С помощью Query Flow Runs API можно углубиться в детали и получить запуски (runs) потока (конкретные экземпляры). Если используется конечная точка REST без имени кластера, берется кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если ни один из запусков потока не соответствует предикатам, возвращается пустой список.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/users/{user name}/flows/{flow name}/runs/
or
GET /ws/v2/timeline/users/{user name}/flows/{flow name}/runs/Поддерживаемые параметры запроса:
Пример ответа JSON:
[
{
"metrics": [],
"events": [],
"id": "sjlee@ds-date/1460420587974",
"type": "YARN_FLOW_RUN",
"createdtime": 1460420587974,
"info": {
"UID": "test-cluster!sjlee!ds-date!1460420587974",
"FROM_ID": "test-cluster!sjlee!ds-date!1460420587974",
"SYSTEM_INFO_FLOW_RUN_ID": 1460420587974,
"SYSTEM_INFO_FLOW_NAME": "ds-date",
"SYSTEM_INFO_FLOW_RUN_END_TIME": 1460420595198,
"SYSTEM_INFO_USER": "sjlee"
},
"isrelatedto": {},
"relatesto": {}
},
{
"metrics": [],
"events": [],
"id": "sjlee@ds-date/1460420305659",
"type": "YARN_FLOW_RUN",
"createdtime": 1460420305659,
"info": {
"UID": "test-cluster!sjlee!ds-date!1460420305659",
"FROM_ID": "test-cluster!sjlee!ds-date!1460420305659",
"SYSTEM_INFO_FLOW_RUN_ID": 1460420305659,
"SYSTEM_INFO_FLOW_NAME": "ds-date",
"SYSTEM_INFO_FLOW_RUN_END_TIME": 1460420311966,
"SYSTEM_INFO_USER": "sjlee"
},
"isrelatedto": {},
"relatesto": {}
}
]Код ответа:
С помощью данного API можно запросить определённый flow run, идентифицированный кластером, пользователем, именем потока или run-идентификатором. Так же при этом по умолчанию возвращаются метрики потока. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в configuration yarn.resourcemanager.cluster-id в yarn-site.xml.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/users/{user name}/flows/{flow name}/runs/{run id}
or
GET /ws/v2/timeline/users/{user name}/flows/{flow name}/runs/{run id}Поддерживаемые параметры запроса:
Пример ответа JSON:
{
"metrics": [
{
"type": "SINGLE_VALUE",
"id": "org.apache.hadoop.mapreduce.lib.input.FileInputFormatCounter:BYTES_READ",
"aggregationOp": "NOP",
"values": {
"1465246377261": 118
}
},
{
"type": "SINGLE_VALUE",
"id": "org.apache.hadoop.mapreduce.lib.output.FileOutputFormatCounter:BYTES_WRITTEN",
"aggregationOp": "NOP",
"values": {
"1465246377261": 97
}
}
],
"events": [],
"id": "varun@QuasiMonteCarlo/1465246348599",
"type": "YARN_FLOW_RUN",
"createdtime": 1465246348599,
"isrelatedto": {},
"info": {
"UID":"yarn-cluster!varun!QuasiMonteCarlo!1465246348599",
"FROM_ID":"yarn-cluster!varun!QuasiMonteCarlo!1465246348599",
"SYSTEM_INFO_FLOW_RUN_END_TIME":1465246378051,
"SYSTEM_INFO_FLOW_NAME":"QuasiMonteCarlo",
"SYSTEM_INFO_USER":"varun",
"SYSTEM_INFO_FLOW_RUN_ID":1465246348599
},
"relatesto": {}
}Код ответа:
С помощью данного API можно запрашивать все приложения YARN, которые являются частью определённого потока. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если количество совпадающих приложений превышает установленный лимит, возвращаются последние приложения до достижения предела. Если ни одно из приложений не соответствует предикатам, возвращается пустой список.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/users/{user name}/flows/{flow name}/apps
or
GET /ws/v2/timeline/users/{user name}/flows/{flow name}/appsПоддерживаемые параметры запроса:
(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…) <op>
!(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…)Если выражение имеет тип сущности (взаимосвязь идентификатора(-ов) сущности, указанная в скобках, последующих за знаком !) это означает, что приложения с этими взаимосвязями не возвращаются. Для выражений или подвыражений без знака ! возвращаются все приложения, имеющие указанные отношения в своем поле relatesto. Оператор оp является логическим и может быть AND или OR. Тип сущности может сопровождаться любым числом идентификаторов сущностей. Можно комбинировать любое количество AND и OR для создания сложных выражений. Для объединения выражений можно использовать скобки. Например: (((type1:id1:id2:id3,type3:id9) AND !(type2:id7:id8)) OR (type1:id4)). Важно обратить внимание, что небезопасные символы URL, такие как пробелы, должны быть соответствующим образом закодированы;
Пример ответа JSON:
[
{
"metrics": [ ],
"events": [ ],
"type": "YARN_APPLICATION",
"id": "application_1465246237936_0001",
"createdtime": 1465246348599,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!application_1465246237936_0001"
"FROM_ID": "yarn-cluster!varun!QuasiMonteCarlo!1465246348599!application_1465246237936_0001",
},
"relatesto": { }
},
{
"metrics": [ ],
"events": [ ],
"type": "YARN_APPLICATION",
"id": "application_1464983628730_0005",
"createdtime": 1465033881959,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!application_1464983628730_0005"
"FROM_ID": "yarn-cluster!varun!QuasiMonteCarlo!1465246348599!application_1464983628730_0005",
},
"relatesto": { }
}
]Код ответа:
С помощью данного API можно запрашивать все приложения YARN, которые являются частью определённого flow run. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если количество совпадающих приложений превышает установленный лимит, возвращаются последние приложения до достижения предела. Если ни одно из приложений не соответствует предикатам, возвращается пустой список.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/users/{user name}/flows/{flow name}/runs/{run id}/apps
or
GET /ws/v2/timeline/users/{user name}/flows/{flow name}/runs/{run id}/apps/Поддерживаемые параметры запроса:
(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…) <op>
!(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…)Если выражение имеет тип сущности (взаимосвязь идентификатора(-ов) сущности, указанная в скобках, последующих за знаком !) это означает, что приложения с этими взаимосвязями не возвращаются. Для выражений или подвыражений без знака ! возвращаются все приложения, имеющие указанные отношения в своем поле relatesto. Оператор оp является логическим и может быть AND или OR. Тип сущности может сопровождаться любым числом идентификаторов сущностей. Можно комбинировать любое количество AND и OR для создания сложных выражений. Для объединения выражений можно использовать скобки. Например: (((type1:id1:id2:id3,type3:id9) AND !(type2:id7:id8)) OR (type1:id4)). Важно обратить внимание, что небезопасные символы URL, такие как пробелы, должны быть соответствующим образом закодированы;
Пример ответа JSON:
[
{
"metrics": [],
"events": [],
"id": "application_1460419579913_0002",
"type": "YARN_APPLICATION",
"createdtime": 1460419580171,
"info": {
"UID": "test-cluster!sjlee!ds-date!1460419580171!application_1460419579913_0002"
"FROM_ID": "test-cluster!sjlee!ds-date!1460419580171!application_1460419579913_0002",
},
"configs": {},
"isrelatedto": {},
"relatesto": {}
}
]Код ответа:
С помощью данного API можно запрашивать одно приложение YARN, идентифицированное кластером ID-приложения. Если используется конечная точка REST без имени кластера, берется кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Информация о контексте потока, то есть пользователь, имя потока и run id, не являются обязательными, но если они указаны в параметре запроса, это может исключить необходимость в дополнительной операции для получения информации о контексте потока на основе id кластера и приложения.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/apps/{app id}
or
GET /ws/v2/timeline/apps/{app id}Поддерживаемые параметры запроса:
Пример ответа JSON:
{
"metrics": [],
"events": [],
"id": "application_1460419579913_0002",
"type": "YARN_APPLICATION",
"createdtime": 1460419580171,
"info": {
"UID": "test-cluster!sjlee!ds-date!1460419580171!application_1460419579913_0002"
},
"configs": {},
"isrelatedto": {},
"relatesto": {}
}Код ответа:
С помощью данного API можно запрашивать общие сущности, идентифицируемые по ID-кластера и приложения и типу сущности для каждой платформы. Если используется конечная точка REST без имени кластера, берется кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Информация о контексте потока, то есть пользователь, имя потока и run id, не являются обязательными, но если они указаны в параметре запроса, это может исключить необходимость в дополнительной операции для получения информации о контексте потока на основе id кластера и приложения. Если количество совпадающих сущностей превышает установленный лимит, возвращаются последние сущности до достижения предела.
Эта конечная точка может использоваться для запроса контейнеров, приложения или любой другой общей сущности, которую клиенты помещают в серверную часть. Например, можно запросить контейнеры, указав тип сущности как YARN_CONTAINER и YARN_APPLICATION_ATTEMPT. Если ни одна из сущностей не соответствует предикатам, возвращается пустой список.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/apps/{app id}/entities/{entity type}
or
GET /ws/v2/timeline/apps/{app id}/entities/{entity type}Поддерживаемые параметры запроса:
(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…) <op>
!(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…)Если выражение имеет тип сущности (взаимосвязь идентификатора(-ов) сущности, указанная в скобках, последующих за знаком !) это означает, что приложения с этими взаимосвязями не возвращаются. Для выражений или подвыражений без знака ! возвращаются все приложения, имеющие указанные отношения в своем поле relatesto. Оператор оp является логическим и может быть AND или OR. Тип сущности может сопровождаться любым числом идентификаторов сущностей. Можно комбинировать любое количество AND и OR для создания сложных выражений. Для объединения выражений можно использовать скобки. Например: (((type1:id1:id2:id3,type3:id9) AND !(type2:id7:id8)) OR (type1:id4)). Важно обратить внимание, что небезопасные символы URL, такие как пробелы, должны быть соответствующим образом закодированы;
Пример ответа JSON:
[
{
"metrics": [ ],
"events": [ ],
"type": "YARN_APPLICATION_ATTEMPT",
"id": "appattempt_1465246237936_0001_000001",
"createdtime": 1465246358873,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!application_1465246237936_0001!YARN_APPLICATION_ATTEMPT
!appattempt_1465246237936_0001_000001"
"FROM_ID": "yarn-cluster!sjlee!ds-date!1460419580171!application_1465246237936_0001
!YARN_APPLICATION_ATTEMPT!0!appattempt_1465246237936_0001_000001"
},
"relatesto": { }
},
{
"metrics": [ ],
"events": [ ],
"type": "YARN_APPLICATION_ATTEMPT",
"id": "appattempt_1465246237936_0001_000002",
"createdtime": 1465246359045,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!application_1465246237936_0001!YARN_APPLICATION_ATTEMPT
!appattempt_1465246237936_0001_000002"
"FROM_ID": "yarn-cluster!sjlee!ds-date!1460419580171!application_1465246237936_0001
!YARN_APPLICATION_ATTEMPT!0!appattempt_1465246237936_0001_000002"
},
"relatesto": { }
}
]Код ответа:
С помощью данного API можно запрашивать общие сущности для каждого пользователя, идентифицируемые по ID-кластера, doAsUser и типу сущности. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если количество совпадающих сущностей превышает установленный лимит, возвращаются последние сущности до достижения предела.
Эта конечная точка может использоваться для запроса общей сущности, которую клиенты помещают в серверную часть. Например, можно запросить пользовательские сущности, указав тип сущности как TEZ_DAG_ID. Если ни одна из сущностей не соответствует предикатам, возвращается пустой список. Примечание: на данный момент можно запрашивать только те сущности, которые опубликованы с помощью doAsUser, отличного от владельца приложения.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/users/{userid}/entities/{entitytype}
or
GET /ws/v2/timeline/users/{userid}/entities/{entitytype}Поддерживаемые параметры запроса:
(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…) <op> !
(<entitytype>:<entityid>:<entityid>…,<entitytype>:<entityid>:<entityid>…)Если выражение имеет тип сущности (взаимосвязь идентификатора(-ов) сущности, указанная в скобках, последующих за знаком !) это означает, что приложения с этими взаимосвязями не возвращаются. Для выражений или подвыражений без знака ! возвращаются все приложения, имеющие указанные отношения в своем поле relatesto. Оператор оp является логическим и может быть AND или OR. Тип сущности может сопровождаться любым числом идентификаторов сущностей. Можно комбинировать любое количество AND и OR для создания сложных выражений. Для объединения выражений можно использовать скобки. Например: (((type1:id1:id2:id3,type3:id9) AND !(type2:id7:id8)) OR (type1:id4)). Важно обратить внимание, что небезопасные символы URL, такие как пробелы, должны быть соответствующим образом закодированы;
Пример ответа JSON:
[
{
"metrics": [ ],
"events": [ ],
"type": "TEZ_DAG_ID",
"id": "dag_1465246237936_0001_000001",
"createdtime": 1465246358873,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!sjlee!TEZ_DAG_ID!0!dag_1465246237936_0001_000001"
"FROM_ID": "sjlee!yarn-cluster!TEZ_DAG_ID!0!dag_1465246237936_0001_000001"
},
"relatesto": { }
},
{
"metrics": [ ],
"events": [ ],
"type": "TEZ_DAG_ID",
"id": "dag_1465246237936_0001_000002",
"createdtime": 1465246359045,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!sjlee!TEZ_DAG_ID!0!dag_1465246237936_0001_000002!userX"
"FROM_ID": "sjlee!yarn-cluster!TEZ_DAG_ID!0!dag_1465246237936_0001_000002!userX"
},
"relatesto": { }
}
]Код ответа:
С помощью данного API можно запрашивать определённую общую сущность, идентифицированную по ID кластера и приложения, типу сущности для каждой платформы и ID-сущности. Если используется конечная точка REST без имени кластера, берется кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Информация о контексте потока, то есть пользователь, имя потока и run id, не являются обязательными, но если они указаны в параметре запроса, это может исключить необходимость в дополнительной операции для получения информации о контексте потока на основе id кластера и приложения.
Эта конечная точка может использоваться для запроса отдельного контейнера, приложения или любой другой общей сущности, что клиенты помещают в серверную часть. Например, можно запросить определенный YARN-контейнер, указав тип сущности как YARN_CONTAINER и задав идентификатор сущности как ID контейнера. Аналогично, приложение может быть запрошено путём указания типа сущности как YARN_APPLICATION_ATTEMPT, а application attempt ID в виде идентификатора сущности.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/apps/{app id}/entities/{entity type}/{entity id}
or
GET /ws/v2/timeline/apps/{app id}/entities/{entity type}/{entity id}Поддерживаемые параметры запроса:
Пример ответа JSON:
{
"metrics": [ ],
"events": [ ],
"type": "YARN_APPLICATION_ATTEMPT",
"id": "appattempt_1465246237936_0001_000001",
"createdtime": 1465246358873,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!application_1465246237936_0001!YARN_APPLICATION_ATTEMPT!0!appattempt_1465246237936_0001_000001"
"FROM_ID": "yarn-cluster!sjlee!ds-date!1460419580171!application_1465246237936_0001!YARN_APPLICATION_ATTEMPT!0!appattempt_1465246237936_0001_000001"
},
"relatesto": { }
}Код ответа:
С помощью данного API можно запрашивать общую сущность для каждого пользователя, идентифицируемую по ID-кластера, doAsUser и типу сущности и ее ID. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если количество совпадающих сущностей превышает установленный лимит, возвращаются последние сущности до достижения предела.
Эта конечная точка может использоваться для запроса общей сущности, которую клиенты помещают в серверную часть. Например, можно запросить пользовательские сущности, указав тип сущности как TEZ_DAG_ID. Если ни одна из сущностей не соответствует предикатам, возвращается пустой список. Примечание: на данный момент можно запрашивать только те сущности, которые опубликованы с помощью doAsUser, отличного от владельца приложения.
HTTP:
GET /ws/v2/timeline/clusters/{cluster name}/users/{userid}/entities/{entitytype}/{entityid}
or
GET /ws/v2/timeline/users/{userid}/entities/{entitytype}/{entityid}Поддерживаемые параметры запроса:
Пример ответа JSON:
[
{
"metrics": [ ],
"events": [ ],
"type": "TEZ_DAG_ID",
"id": "dag_1465246237936_0001_000001",
"createdtime": 1465246358873,
"isrelatedto": { },
"configs": { },
"info": {
"UID": "yarn-cluster!sjlee!TEZ_DAG_ID!0!dag_1465246237936_0001_000001!userX"
"FROM_ID": "sjlee!yarn-cluster!TEZ_DAG_ID!0!dag_1465246237936_0001_000001!userX"
},
"relatesto": { }
}
]Код ответа:
С помощью данного API можно запрашивать набор доступных типов сущностей для данного идентификатора приложения. Если используется конечная точка REST без имени кластера, берётся кластер, указанный в конфигурации yarn.resourcemanager.cluster-id в yarn-site.xml. Если идентификатор пользователя, имя потока и идентификатор потока выполнения, которые являются необязательными параметрами запроса, не указаны, они будут запрашиваться на основе идентификатора приложения и идентификатора кластера из информации о контексте потока, хранящейся в базовой реализации хранилища.
HTTP:
GET /ws/v2/timeline/apps/{appid}/entity-types
or
GET /ws/v2/timeline/clusters/{clusterid}/apps/{appid}/entity-typesПоддерживаемые параметры запроса:
Пример ответа JSON:
{
YARN_APPLICATION_ATTEMPT,
YARN_CONTAINER,
MAPREDUCE_JOB,
MAPREDUCE_TASK,
MAPREDUCE_TASK_ATTEMPT
}Код ответа:
Известно, что YARN масштабируется до тысяч узлов. Масштабируемость YARN определяется Resource Manager, и она пропорциональна количеству узлов, активных приложений и контейнеров, а также частоте heartbeat-сообщений (как узлов, так и приложений). Снижение heartbeat-сообщений может обеспечить увеличение масштабируемости, однако это отрицательно сказывается на использовании.
В данной главе описан подход на основе Federation для масштабирования одного кластера YARN до десятков тысяч узлов путём интеграции нескольких подкластеров YARN. Предлагаемый метод заключается в разделении большого кластера (10-100 тысяч узлов) на более мелкие блоки, называемые субкластерами (sub-cluster), каждый из которых имеет свой собственный YARN Resource Manager и вычислительные узлы. Система Federation объединяет эти субкластеры и делает их одним большим кластером YARN для приложений. Приложения при этом видят один массивный кластер YARN и могут планировать задачи на любом его узле, в то время как в рамках системы Federation ведутся переговоры с Resource Manager субкластеров для предоставления ресурсов приложению. Цель состоит в том, чтобы позволить отдельной задаче бесшовно “охватить” субкластеры.
Такая конструкция является структурно масштабируемой, поскольку она связывает количество узлов, за которые отвечает каждый Resource Manager, а соответствующие политики пытаются обеспечить, чтобы большинство приложений находилось в одном субкластере, таким образом, число видимых приложений для каждого Resource Manager также ограничено. Это означает, что масштабирумость может быть почти линейной, просто добавляя субкластеры (поскольку для них требуется очень небольшая координация).
Такая архитектура может обеспечить очень строгое соблюдение инвариантов планирования в каждом субкластере (просто наследуется от YARN), в то время как непрерывная перебалансировка по субкластеру обеспечивает (менее строго) то, что эти свойства также соблюдаются на глобальном уровне (например, если субкластер теряет большое количество узлов, можно переназначить очереди на другие субкластеры, чтобы обеспечить исключение несправедливого воздействия на пользователей, работающих в поврежденном субкластере).
Federation спроектирована как “слой” поверх существующей кодовой базы YARN с ограниченными изменениями в основных механизмах.
Субкластер (sub-cluster) — это кластер YARN размером до нескольких тысяч узлов. Точный размер субкластера определяется с учётом простоты развёртывания/обслуживания, согласования с сетевыми зонами и их доступности, а также общими рекомендациями.
Resource Manager субкластера YARN работает с высоким уровнем доступности (HA) с сохранением работоспособности, то есть необходимо быть в состоянии к сбоям Resource Manager и Node Manager с минимальными нарушениями. Если весь субкластер скомпрометирован, внешние механизмы обеспечивают повторную передачу заданий в отдельный субкластер (в дальнейшем это может быть включено в Federation).
Субкластер также является единицей масштабируемости в среде Federation — её можно расширить, добавив один или несколько субкластеров.
По своей структуре каждый субкластер является полностью функциональным Resource Manager, и его вклад в Federation может быть установлен лишь на долю его общей ёмкости, т.е. субкластер может иметь “частичное” обязательство перед Federation, сохраняя при этом способность выдавать часть своих возможностей локальным способом.
Приложения YARN отправляются на один из маршрутизаторов (Router), который, в свою очередь, применяет политику маршрутизации (полученную из Policy Store), запрашивает в State Store URL-адрес субкластера и перенаправляет запрос на отправку приложения в соответствующий Resource Manager субкластера. Субкластер, в котором запускается задание, называется “домашним субкластером” (home sub-cluster), а “вторичными” (secondary sub-clusters) называются все остальные субкластеры, на которые распространяется задание.
Маршрутизатор предоставляет ApplicationClientProtocol внешнему миру, прозрачно скрывая присутствие нескольких Resource Manager. Для этого маршрутизатор также сохраняет соответствие между приложением и его домашним субкластером в State Store. Это позволяет маршрутизаторам быть в мягком состоянии, недорого поддерживая при этом запросы пользователей, так как любой маршрутизатор может восстановить приложение для маппинга домашнего субкластера и направить запросы к нужному Resource Manager. Целесообразно для кэширования производительности и балансировки нагрузки. Состояние Federation (включая приложения и узлы) отображается через веб-интерфейс.
AMRMProxy является ключевым компонентом, позволяющим приложению масштабироваться и работать в субкластерах. AMRMProxy работает на всех машинах Node Manager и действует как прокси-сервер для YARN Resource Manager для Application Master, реализуя ApplicationMasterProtocol. Приложениям не разрешается напрямую связываться с Resource Manager субкластера. Система принудительно подключает их только к конечной точке AMRMProxy, что обеспечивает прозрачный доступ к нескольким YARN Resource Manager (путём динамической маршрутизации/разделения/маппинга коммуникаций). В любой момент времени задание может охватывать один домашний и несколько вторичных субкластеров, но работающие в AMRMProxy политики пытаются ограничить площадь каждого задания, чтобы минимизировать накладные расходы на инфраструктуру планирования.
Роль AMRMProxy:
Global Policy Generator (GPG) контролирует всю Federation и гарантирует, что система все время настроена должным образом. Ключевым моментом идеи является то, что доступность кластера не зависит от постоянно включённого GPG. При этом GPG работает непрерывно, но вне зоны действия всех операций кластера, и предоставляет уникальную точку обзора, которая позволяет применять глобальные инварианты, влиять на балансировку нагрузки, инициировать дренаж субкластеров, которые будут подвергаться техническому обслуживанию, и т.д. GPG точнее обновляет маппинг распределения пропускной способности пользователя субкластеру и реже меняет политики, выполняющиеся в Routers, AMRMProxy (и возможных Resource Manager).
В случае если GPG недоступен, операции кластера продолжаются с момента последней публикации политик GPG, и хотя долгосрочная недоступность может означать, что некоторые из желательных свойств баланса, оптимального использования кластера и глобальных инвариантов могут исчезнуть, вычисления и доступ к данным не будут скомпрометированы.
В текущей реализации Global Policy Generator представляет собой процесс ручной настройки, представленный через CLI.
Federation State определяет дополнительное состояние, которое необходимо поддерживать для свободного объединения нескольких отдельных субкластеров в один большой кластер Federation. Включает в себя:
1. Sub-cluster Membership.
Члены YARN Resource Manager непрерывно передают heartbeat-сообщения в State Store для keep-alive и публикации своей текущей мощности/загрузке. Эта информация используется GPG для принятия необходимых политических решений. Также эта информация может использоваться маршрутизаторами для выбора лучшего домашнего субкластера. Этот механизм позволяет динамически увеличивать/уменьшать “кластерный парк”, добавляя или удаляя субкластеры, а также позволяет легко обслуживать каждый из них. Это новая функциональность, которую необходимо добавить в YARN Resource Manager, при этом механизмы между собой хорошо понятны, поскольку функциональность аналогична индивидуальной высокой доступности (HA) YARN Resource Manager.
2. Application’s Home Sub-cluster.
Субкластер, в котором выполняется Application Master, называется “домашним субкластером приложения” (home sub-cluster). При этом Application Master не ограничивается ресурсами только домашнего субкластера и может запрашивать ресурсы из других, называемых “вторичными” (secondary sub-clusters). Среда Federation настраивается и периодически налаживается таким образом, чтобы при размещении Application Master в субкластере он мог найти большую часть ресурсов в домашнем субкластере и только в определённых случаях запрашивал ресурсы у других субкластеров.
3. Federation Policy Store.
Federation Policy Store — это логически отдельное хранилище (хотя оно может поддерживаться одним и тем же физическим компонентом), которое содержит информацию о том, как приложения и запросы ресурсов направляются в разные субкластеры. Текущая реализация предоставляет несколько политик — от случайных/ хэширующих/ циклических/ приоритетных до более сложных, которые учитывают нагрузку субкластера и запрашивают потребности в локальности.
При отправке приложения система определяет наиболее подходящий субкластер для его запуска, и он становится домашним. Все коммуникации от Application Master к Resource Manager осуществляются через AMRMProxy, работающий локально на машине Application Master. AMRMProxy предоставляет ту же конечную точку протокола ApplicationMasterService, что и YARN Resource Manager. Application Master может запрашивать контейнеры, используя информацию о местоположении, предоставляемую уровнем хранения.
В идеальном случае приложение размещается в субкластере, где доступны все ему необходимые ресурсы и данные, но если ему нужны контейнеры на узлах в других субкластерах, AMRMProxy прозрачно согласовывает с их Resource Manager и предоставляет ресурсы, что позволяет приложению рассматривать всю среду Federation как один массивный кластер YARN. AMRMProxy, Global Policy Generator и Router работают вместе для бесшовной реализации.
Последовательность для потока выполнения задания:
7. Затем Application Master запрашивает контейнеры, используя информацию о местонахождении, предоставляемую HDFS.
8. На основе политики AMRMProxy может олицетворять Application Master в других субкластерах, отправляя Unmanaged Application Master и перенаправляя heartbeats-сообщения Application Master соответствующим субкластерам.
9. AMRMProxy использует как информацию о местонахождении, так и подключаемую политику, настроенную в State Store, чтобы решить, следует ли перенаправлять полученные от Application Master запросы ресурсов в домашний Resource Manager или во вторичный (один или более). На рисунке отображен случай, когда AMRMProxy решает переслать запрос на вторичный Resource Manager.
10. Вторичный Resource Manager предоставляет AMRMProxy актуальные токены контейнера для запуска нового контейнера на узле в его субкластере. Такой механизм гарантирует, что каждый субкластер использует свои собственные токены безопасности и избегает необходимости общего секрета кластера для создания токенов.
11. AMRMProxy пересылает ответ распределения обратно в Application Master.
12. Application Master запускает контейнер на целевом NodeManager (в субкластере 2), используя стандартные протоколы YARN.
Настройка YARN для использования Federation осуществляется через ряд свойств в файле conf/yarn-site.xml.
Общие для всех:
true
<unique-subcluster-id>В настоящее время поддерживается реализации State Store на основе ZooKeeper и SQL.
Обязательные настройки ZooKeeper для Hadoop:
org.apache.hadoop.yarn.server.federation.store.impl.ZookeeperFederationStateStore
host:portОбязательные параметры SQL:
org.apache.hadoop.yarn.server.federation.store.impl.SQLFederationStateStore
jdbc:mysql://<host>:<port>/FederationStateStore
com.mysql.jdbc.jdbc2.optional.MysqlDataSource
<dbuser>
<dbpass>Для MySQL и Microsoft SQL Server предоставляются скрипты.
Для MySQL необходимо загрузить последнюю версию jar 5.x из MVN Repository и добавить её в CLASSPATH. Затем схема БД создаётся путём выполнения следующих скриптов SQL в базе данных:
В том же каталоге предоставляются скрипты для удаления хранимых процедур, таблиц, пользователя и базы данных.
|
Внимание. FederationStateStoreUser.sql определяет для БД пользователя/пароль по умолчанию, для которого настоятельно рекомендуется установить собственный надёжный пароль. |
Для SQL-сервера процесс аналогичен, но драйвер jdbc уже включён. Скрипты SQL-сервера находятся в каталоге sbin/FederationStateStore/SQLServer/.
Опциональные:
true
<subcluster-id>
org.apache.hadoop.yarn.server.federation.policies.manager.WeightedLocalityPolicyManager
<binary>
org.apache.hadoop.yarn.server.federation.resolver.DefaultSubClusterResolverImpl
<path of machine-list file>Дополнительная конфигурация, которая должна отображаться в файле conf/yarn-site.xml в каждом Resource Manager.
<unique-epoch>Опционально:
60Дополнительные конфигурации, которые должны отображаться в файле conf/yarn-site.xml в каждом Router.
0.0.0.0
org.apache.hadoop.yarn.server.router.clientrm.FederationClientInterceptorОпционально:
0.0.0.0
0.0.0.0:8050
0.0.0.0:8089
0.0.0.0:8052
0.0.0.0:8091
3
10
60
org.apache.hadoop.yarn.server.router.webapp.FederationInterceptorRESTДополнительные конфигурации, которые должны отображаться в файле conf/yarn-site.xml в каждом NodeManager.
true
org.apache.hadoop.yarn.server.nodemanager.amrmproxy.FederationInterceptorОпционально:
true
1
300Для отправки заданий в кластер Federation необходимо создать отдельный набор конфигураций для клиента, из которого будут отправляться задания. В них conf/yarn-site.xml должен иметь следующие дополнительные конфигурации:
<router_host>:8050
localhost:8049Любые задания YARN для кластера могут быть отправлены из описанных выше конфигураций клиента. Чтобы запустить задание через Federation, сначала необходимо запустить все участвующие в ней кластеры. Затем выполнить старт маршрутизатора на компьютере маршрутизатора с помощью команды:
$HADOOP_HOME/bin/yarn --daemon start routerТеперь, когда $HADOOP_CONF_DIR указывает на папку конфигураций клиента, необходимо запустить задание обычным способом. Конфигурации направляют задание на клиентский порт маршрутизатора Resource Manager, где Router должен прослушиваться после запуска. Пример запуска задания Pi на кластере Federation с клиента:
$HADOOP_HOME/bin/yarn jar hadoop-mapreduce-examples-3.0.0.jar pi 16 1000Задание передаётся на маршрутизатор, который использует сгенерированную политику из GPG, чтобы выбрать домашний Resource Manager для задания.
Выходные данные приведённого примера задания должны быть примерно такими:
2017-07-13 16:29:25,055 INFO mapreduce.Job: Job job_1499988226739_0001 running in uber mode : false
2017-07-13 16:29:25,056 INFO mapreduce.Job: map 0% reduce 0%
2017-07-13 16:29:33,131 INFO mapreduce.Job: map 38% reduce 0%
2017-07-13 16:29:39,176 INFO mapreduce.Job: map 75% reduce 0%
2017-07-13 16:29:45,217 INFO mapreduce.Job: map 94% reduce 0%
2017-07-13 16:29:46,228 INFO mapreduce.Job: map 100% reduce 100%
2017-07-13 16:29:46,235 INFO mapreduce.Job: Job job_1499988226739_0001 completed successfully
.
.
.
Job Finished in 30.586 seconds
Estimated value of Pi is 3.14250000......Состояние задания также можно отслеживать в веб-интерфейсе маршрутизатора по адресу routerhost:8089.
Важно обратить внимание, что для использования Federation не потребовалось никаких изменений в коде или перекомпиляции входного jar. Кроме того, выходные данные приведённого задания такие же, как и при запуске без Federation. Чтобы получить все преимущества Federation, рекомендуется использовать большее количество mappers, чем того требует кластер. Для приведённого примера это число составляет 16.