01. Важные замечания
2022-12-01
Список замечаний
Об централизованном использовании Ansible Ad-Hoc команд для подготовки хостов к установке ArenaData-кластера
Для удобства работы с множеством машин будущего кластера, в данной инструкции описано создание отдельного каталога с Ansible-файлами на любой машине, откуда по SSH должны быть доступны все целевые хосты. Инструкция доступна здесь “Подготовка каталога с файлами для развёртывания ADH с помощью Ansible Ad-Hoc”.
О параллельном подключении lvm-тома vg/data
к директориям /data
и /srv
На машинах кластера, lvm-том ‘vg/data’ монтируется не только к каталогу /data
, но и параллельно к /srv
, так как по умолчанию, в ArenaData каталог /srv
используется для размещения меняющихся данных кластера. В то же время, на данный момент только предположительно, некоторые наши скрипты могут использовать каталог /data
?
Если выяснится, что параллельное подключение не востребовано, то отключение лишней директории от lv-тома легко произвести через редактирование файла /etc/fstab
.
Замечу, что на mon-хосте под каталог хранения данных Graphite по умолчанию выделен /opt
. Судя же по инструкции, я изменил в настройках этот параметр на /data
.
Об использовании одного IPA-аккаунта не только для управления сервисными записями при включённой в кластере Kerberos-аутентификации, но и выполнения ansible-задач из ADCM.
Ранее в этих инструкциях описывалось создание отдельной локальной УЗ на всех машинах кластера, которая использовалась в ADCM для подключения к хостам. Для включения Kerberos добавлялся ещё один IPA-аккаунт для создания сервисов и запросов keytab’ов. Теперь этим занимается один IPA-аккаунт.
В результате, для каждой ИС, в которой будет разворачиваться отдельный ArenaData-кластер, во FreeIPA необходимо добавить отдельную учётную запись и отдельную host-группу по инструкции 04. Добавление во FreeIPA отдельной роли, УЗ, и hostgroup, для работы ArenaData-кластера. Новую отдельную IPA-роль создавать не требуется.
О важности экранирования на хостах существующих во FreeIPA специальных УЗ, типа ‘hdfs’, ‘yarn’, ‘hive’, и другие
Так как во FreeIPA имеют быть специальные УЗ с именами, типа ‘hdfs’, ‘yarn’, ‘hive’, и другие, которые используются в продуктовом Hadoop-кластере, то необходимо на всех хостах ArenaData-кластере добавить в /etc/sssd/sssd.conf
следующие строки в раздел ‘[nss]’:
[nss]
filter_groups = root,accumulo,apache,atlas,flume,hadoop,hbase,hdfs,hive,httpfs,hue,impala,kafka,keytrustee,kudu,llama,kms,mapred,mysql,oozie,postgres,sentry,solr,spark,sqoop,sqoop2,yarn,zookeeper
filter_users = root,accumulo,apache,atlas,flume,hbase,hdfs,hive,httpfs,hue,impala,kafka,keytrustee,kudu,llama,kms,mapred,mysql,oozie,postgres,sentry,solr,spark,sqoop,sqoop2,yarn,zookeeper
Важно, чтобы во FreeIPA не попали и любые другие имена использующихся в Hadoop’е учётных записей.
О важности использования по умолчанию Python версии 2.7 на всех хостах с CentOS7 на борту
Важно, чтобы на CentOS7 хостах по умолчанию был выставлен python2.7, из-за использования его ansible-пакетом ‘yum’, который часто применяется во время выполнения различных ansible-задач через ADCM. Напомню, что ADCM использует Ansible для выполнения различных задач на хостах Hadoop-кластера.
Об отключении проверки обычных UNIX-прав на объекты HDFS после подключения Ranger к ADH и отключении параметра ‘xasecure.add-hadoop-authorization’
В нашем кластере применяется следующая конфигурация: установлен Apache Ranger и важный параметр ‘xasecure.add-hadoop-authorization’ установлен в ‘False’, то есть отключен. В этом случае традиционные UNIX-права для доступа к объектам HDFS не учитываются и управление правами доступа выполняется с помощью правил Ranger’а.
Иначе же, если параметр ‘xasecure.add-hadoop-authorization’ оставить в значении по умолчанию ‘True’, то доступ к объектам HDFS регулируется в следующем порядке:
- Если есть политика доступа в Ranger, то и применяется эта политика.
В Ranger-аудите видим применяемый тип Access Enforcer — ranger-acl. - Иначе применяется доступ на основе обычной проверки UNIX разрешений owner/group и mode.
В Ranger-аудите видим применяемый тип Access Enforcer — hadoop-acl.