01. Подготовка к установке кластера Cloudera CDH 6.3.2

Первая часть, где описывается подготовка к установке Cloudera CDH 6.3.2.

Tags:

2021-06-10

1. Введение

Номер последней версии Cloudera CDH, которая умеет работать без лицензии, это 6.3.2. Версия Cloudera Manager (CM), которая умеет работать с CDH 6.3.2, является 6.3.1. В конце 2020 года Cloudera закрыла свободный доступ к любым версиям CDH и CM в своём репозитории. К счастью, на корпоративном Nexus Repository Manager есть hosted-репозитории для Cloudera CM 6.3.1 и Cloudera CDH 6.3.2.

Перед выполнением этой инструкции, предполагается, что:

имеется настроенный FreeIPA-сервер с поднятым доменом;
все узлы будущего Hadoop-кластера введены в домен;
имеется одна командная машина, через bash-оболочку которой, мы имеем доступ на все узлы будущего кластера через ssh.

Сейчас мы подготовим на командной машине отдельный каталог с файлами, где с помощью ansible развернём новый Hadoop-кластер.

2. Преднастройка и подготовка к проверкам

На командной машине в каталоге ~/hadoop подготовим файлы для ансибла с ip-адресами машин будущего кластера:

mkdir hadoop && cd hadoop
printf '[defaults]\nhost_key_checking=false\n' > ansible.cfg

printf '[all:var]\nansible_user=jenkins\n#ansible_password=\n' > cluster.inv
printf 'ansible_python_interpreter=/usr/bin/python2\n\n[cluster]\n' >> cluster.inv
cat << EOF | tee -a cluster.inv > cluster.ips
10.1.4.1
10.1.4.2
10.1.4.3
10.1.4.5
10.1.4.6
10.1.4.7
10.1.4.8
10.1.4.9
10.1.4.10
EOF

cluster.inv — inventory-файл для ансибла;
cluster.ips — простой список ip-адресов узлов будущего кластера.

3. Обновление и перезагрузка машин

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

Выполняем обновление и перезагрузку всех машин:

ansible all -i cluster.inv -m yum -a "name=* state=latest" --become
ansible all -i cluster.inv -m reboot --become

4. Настройка и проверка сетевых настроек

Необходимо проверить и привести к надлежащему виду сетевые настройки в следующих местах:

/etc/sysconfig/network-scripts/ifcfg-ens32
/etc/sysconfig/network
/etc/resolv.conf

4.1. Файл `/etc/sysconfig/network-scripts/ifcfg-ens32`

При наличии строк в этом файле с указанием серверов DNS, они могут заместить рабочие записи в /etc/resolv.conf.

Образец файла `/etc/sysconfig/network-scripts/ifcfg-ens32` после получения машины из ЦОДа...

# Generated by VMWare customization engine.
HWADDR=00:50:56:a2:0e:29
NAME=ens32
DEVICE=ens32
ONBOOT=yes
USERCTL=no
BOOTPROTO=static
NETMASK=255.255.255.128
IPADDR=10.1.4.1
GATEWAY=10.1.4.254
PEERDNS=no

check_link_down() {
 return 1;
}

Строка PEERDNS=no отвечает за отсутствие изменений в /etc/resolv.conf при использовании DHCP.
Функция check_link_down() в конце файла является обходным способом решения vmware-проблемы (https://kb.vmware.com/s/article/977).

Проверку и, если необходимо, удаление лишних строк производим командами:

# Смотрим
ansible all -i cluster.inv -m shell -a "cat /etc/sysconfig/network-scripts/ifcfg-ens32" --become

# Удаляем записи DNS
ansible all -i cluster.inv -m lineinfile -a "path=/etc/sysconfig/network-scripts/ifcfg-ens32 regexp='^DNS=' state=absent" --become
# Удаляем запись DOMAIN
ansible all -i cluster.inv -m lineinfile -a "path=/etc/sysconfig/network-scripts/ifcfg-ens32 regexp='^DOMAIN=' state=absent" --become

4.2. Файл `/etc/sysconfig/network`

Информация из этого файла — /etc/sysconfig/network — используется скриптами при запуске машины, или перезапуске демона network, и частично замещает/добавляет информацию в файле /etc/resolv.conf. Поэтому необходимо сделать этот файл пустым.

# Смотрим
ansible all -i cluster.inv -m shell -a "cat /etc/sysconfig/network" --become

# Очищаем
ansible all -i cluster.inv -m shell -a "> /etc/sysconfig/network" --become

4.3. Автоматически обновляемый файл `/etc/resolv.conf`

Информация в этом файле может добавляться/замещаться данными полученными из двух предыдущих файлов, а так же из DHCP при отсутствии параметра “PEERDNS=no” в файле /etc/sysconfig/network-scripts/ifcfg-ens32.

Образец содержимого файла '/etc/resolv.conf'...

options rotate timeout:1 attempts:1
search example.org
nameserver 10.1.85.5
nameserver 10.1.85.6
nameserver 10.1.85.7

опция rotate заставляет отправлять dns-запросы по очереди к каждому dns-серверу по кругу;
опция timeout:1 уменьшает ожидание ответа dns-сервера с дефолтных трёх секунд до одной секунды;
опция attempts:1 разрешают только один запрос к DNS-серверу;
параметр search включает автоматическое добавление имени домена к коротким именам в отправляемых dns-запросах, например, ping dev-mgm01p преобразуется в ping dev-mgm01p.example.org.

Проверку и, если необходимо, добавление опций производим командами:

# Смотрим
ansible all -i cluster.inv -m shell -a "cat /etc/resolv.conf"

# Обновляем resolv.conf
ansible all -i cluster.inv -m shell -a "echo 'options rotate timeout:1 attempts:1' > /etc/resolv.conf" --become
ansible all -i cluster.inv -m systemd -a "name=network state=restarted" --become

5. Проверка обратного разрешения dns-имён

С пульта управления, при помощи ансибла, пытаемся выполнить обратное разрешение dns-имён:

while read line; \
  do ansible all -i cluster.inv -m shell -a "host $line"; \
  done < cluster.ips

6. Проверка настроек и работы сервиса точного времени

Визуально проверяем наличие синхронизации с серверами точного времени:

ansible all -i cluster.inv -m shell -a "chronyc sources" --become

7. Подготовка файла /etc/hosts

Проверку и, если необходимо, обновление файла производим командами:

# Смотрим
ansible all -i cluster.inv -m shell -a "cat /etc/hosts" --become

# Обновляем /etc/hosts на всех узлах через следующие команды...
# Подготавливаем скрипт
cat << EOF > updatehosts.sh
#!/bin/bash
echo '127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4' > /etc/hosts
while read line; do
    TMPNAME=\$(host \$line | awk '{print \$5}') # prod-01.example.org.
    LONGNAME=\${TMPNAME%.}    # prod-01.example.org
    SHORTNAME=\${TMPNAME%%.*} # prod-01
    echo "\${line} \${LONGNAME} \${SHORTNAME}" >> /etc/hosts
done < /root/tmp/cluster.ips
EOF

# список ip-адресов и подготовленный скрипт забрасываем на все узлы
ansible all -i cluster.inv -m copy -a "src=cluster.ips dest=/root/tmp/" --become
ansible all -i cluster.inv -m copy -a "src=updatehosts.sh dest=/root/tmp/" --become

# запускаем выполнение скрипта на всех узлах
ansible all -i cluster.inv -m shell -a "/bin/bash /root/tmp/updatehosts.sh" --become

8. Создание tmp-каталога для дампов java-машин

По умолчанию, в настройках сервисов указан каталог /tmp, который используется для создания дампов java-машин, в случае их падения при ошибке “OutOfMemoryError”. Cоздадим новый каталог для этих целей на большем разделе, так как корневой раздел обычно слишком мал, чтобы разместить полный дамп java-машины:

ansible all -i cluster.inv -m file -a 'path=/data/tmp state=directory mode=1777' --become

9. Заключительная перезагрузка машин

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

ansible all -i cluster.inv -m reboot --become

Если есть какие-либо подозрения на счёт правильности настроек, то повторяем проверки.