Высокая доступность: бэкенд Chef

[править на GitHub]

В данном разделе рассматриваются основные концепции архитектуры кластера высокодоступного сервера Chef Infra. Затем описывается процесс настройки и установки кластера высокодоступного сервера Chef Infra, состоящего из пяти узлов (два front-end и три back-end).

Обзор

Сервер Chef Infra может работать в конфигурации высокой доступности, которая обеспечивает автоматическое распределение нагрузки и отключение работоспособных компонентов в архитектуре системы. Этот тип конфигурации обычно разделяет серверы на два сегмента: кластер back-end и группу front-end.

• Группа front-end, состоящая из одного (или нескольких) узлов, на которых работает сервер Chef Infra. Узлы в группе front-end обрабатывают запросы к API сервера Chef Infra и доступ к консоли управления Chef. Узлы группы front-end должны быть сбалансированы по нагрузке и могут быть масштабированы горизонтально путём увеличения количества узлов, доступных для обработки запросов.

• Кластер back-end, состоящий из трёх узлов, работающих совместно, обеспечивает высокую доступность и сохранение данных для группы front-end.

  Примечание

  В настоящее время кластеры back-end могут содержать только три узла.

Ключевые различия от автономного сервера Chef Infra

Новое в Chef Infra Server 14 Начиная с Chef Infra Server 14, автономные экземпляры используют Elasticsearch для внутренней поисковой системы. Elasticsearch предоставляет более гибкие варианты кластеризации, сохраняя при этом совместимость API поиска с Apache Solr.

Рекомендуемая топология кластера

Узлы

• Для установки back-end HA требуется три узла кластера. Chef не тестировал и не поддерживает установки с другим количеством узлов кластера back-end.
• Один или несколько узлов группы front-end

Требования к оборудованию

Ниже приведён список общих требований к оборудованию для серверов front-end и back-end. Важное руководство, которому следует следовать: серверы front-end имеют тенденцию быть более ресурсоёмкими по ЦП, а серверы back-end – более ресурсоёмкими по диску и памяти. Кроме того, объём дискового пространства для серверов back-end должен увеличиваться с количеством узлов, за которыми серверы следят. Хорошее правило – выделять 2 МБ на каждый узел. Перечисленные ниже значения для диска являются хорошим значением по умолчанию, которое вы захотите изменить позже, если/когда количество узлов увеличится.

• Архитектура 64 бит

Требования к front-end

• 4 ядра (физические или виртуальные)
• 4 ГБ ОЗУ
• 20 ГБ свободного дискового пространства (SSD, если на локальном сервере, Premium Storage в Microsoft Azure, EBS-Optimized GP2 в AWS)

Требования к back-end

• 2 ядра (физические или виртуальные)
• 8 ГБ ОЗУ
• 50 ГБ/сервер back-end (SSD, если на локальном сервере, Premium Storage в Microsoft Azure, EBS-Optimized GP2 в AWS)

Сетевые службы

• Сбалансированная по нагрузке связь между остальной сетью и группой front-end (не предоставляется). Поскольку данные сеансов консоли управления хранятся на каждом узле группы front-end индивидуально, сбалансированную по нагрузке связь необходимо настроить с сохранением сеансов.

Требования к сетевым портам

Входящие соединения от балансировщика нагрузки к группе front-end

• TCP 80 (HTTP)
• TCP 443 (HTTPS)

Входящие соединения от группы front-end к кластеру back-end

• TCP 2379 (etcd)
• TCP 5432 (PostgreSQL)
• TCP 7331 (leaderl)
• TCP 9200-9300 (Elasticsearch)

Взаимодействие узлов, кластер back-end

• 2379 (etcd)
• 2380 (etcd)
• 5432 (PostgreSQL)
• 9200-9400 (Elasticsearch)

Установка

Эти инструкции предполагают, что вы используете минимальные версии:

• Chef Server : 12.5.0
• Chef Backend : 0.8.0

Загрузите Chef Infra Server и Chef Backend (chef-backend), если у вас их ещё нет.

Прежде чем создавать кластер back-end HA и создавать как минимум один сервер Chef Infra для группы front-end, проверьте:

• Пользователь, который будет устанавливать и создавать кластер back-end HA и группу front-end, имеет права root на всех узлах.
• Количество узлов back-end и front-end, которые требуются. Требуется три узла back-end, но количество узлов front-end может варьироваться от одного узла до сбалансированной по нагрузке конфигурации.
• Доступ SSH ко всем машинам, которые войдут в кластер back-end HA, с узла, который будет начальным начальным узлом.
• Существует политика синхронизации времени, такая как Network Time Protocol (NTP). Разница должна быть менее 1,5 секунд на всех узлах в кластере back-end HA.

Шаг 1: Создание кластера

Первый узел должен быть запущен для инициализации кластера. Узел, используемый для запуска кластера, будет лидером кластера, когда кластер станет доступен. После завершения запуска этот узел не отличается от любого другого узла back-end.

1. Установите пакет Chef Backend на первом узле back-end как root.

   • Загрузите Chef Backend (chef-backend)
   • В Red Hat/CentOS: yum install PATH_TO_RPM
   • В Debian/Ubuntu: dpkg -i PATH_TO_DEB

2. Обновите /etc/chef-backend/chef-backend.rb следующими данными:

   publish_address 'external_IP_address_of_this_box' # External ip address of this backend box
   

3. Если какие-либо back-end или front-end находятся в разных сетях друг от друга, добавьте строку postgresql.md5_auth_cidr_addresses в /etc/chef-backend/chef-backend.rb с следующими данными, где , "<NET-1_IN_CIDR>", ..., "<NET-N_IN_CIDR>" – это список всех сетей, в которых находятся ваши back-end и front-end. См. раздел Настройка членов front-end и back-end в разных сетях для получения дополнительной информации:

   publish_address 'external_IP_address_of_this_box' # External ip address of this backend box
   postgresql.md5_auth_cidr_addresses = ["samehost", "samenet", "<NET-1_IN_CIDR>", ..., "<NET-N_IN_CIDR>"]
   

4. Запустите chef-backend-ctl create-cluster.

Шаг 2: Общие учётные данные

Файл учётных данных /etc/chef-backend/chef-backend-secrets.json , созданный при запуске, должен быть доступен другим узлам. Вы можете скопировать их напрямую или сделать их доступными через общее подключение.

Например, для копирования с помощью ssh:

scp /etc/chef-backend/chef-backend-secrets.json <USER>@<IP_BE2>:/home/<USER>
scp /etc/chef-backend/chef-backend-secrets.json <USER>@<IP_BE3>:/home/<USER>

Удалите этот файл из пункта назначения после того, как будет выполнен шаг 4 для каждого узла back-end, подключаемого к кластеру.

Шаг 3: Установка и настройка остальных узлов back-end

Для каждого дополнительного узла выполните следующие действия последовательно (если вы попытаетесь подключить узлы параллельно, кластер может не стать доступным):

1. Установите пакет Chef Backend на узел.

   • Загрузите Chef Backend (chef-backend)
   • В Red Hat/CentOS: yum install PATH_TO_RPM
   • В Debian/Ubuntu: dpkg -i PATH_TO_DEB

2. Если вы добавили строку postgresql.md5_auth_cidr_addresses к /etc/chef-backend/chef-backend.rb лидера в разделе Шаг 1: Создание кластера, обновите /etc/chef-backend/chef-backend.rb этого узла следующими данными, где postgresql.md5_auth_cidr_addresses имеет то же значение, что и в chef-backend.rb лидера. Если все кластеры back-end и front-end находятся в одной сети, то вам не нужно изменять /etc/chef-backend/chef-backend.rb этого узла.

   publish_address 'external_IP_address_of_this_box' # External ip address of this backend box
   postgresql.md5_auth_cidr_addresses = ["samehost", "samenet", "<NET-1_IN_CIDR>", ..., "<NET-N_IN_CIDR>"]
   

3. Как root или с помощью sudo:

   chef-backend-ctl join-cluster <IP_BE1> -s /home/<USER>/chef-backend-secrets.json
   

4. Ответьте на запросы, касающиеся использования общедоступного IP-адреса. В качестве альтернативы вы можете указать их в команде chef-backend join-cluster . См. chef-backend-ctl join-cluster --help для получения дополнительной информации. Если вы вручную добавили строку publish_address в /etc/chef-backend/chef-backend.rb, вам не будет предложено указать общедоступный IP-адрес, и вы не должны использовать опцию --publish-address для указания общедоступного IP-адреса в команде chef-backend join-cluster.

5. Если вы скопировали общий файл учётных данных chef-backend-secrets.json в домашний каталог пользователя на этом узле, удалите его.

6. Повторите эти шаги для каждого узла-последователя, после чего кластер будет доступен. На любом узле в кластере back-end HA запустите следующую команду:

   chef-backend-ctl status
   

   должно вернуть что-то вроде:

   Service        Local Status        Time in State  Distributed Node Status
   elasticsearch  running (pid 6661)  1d 5h 59m 41s  state: green; nodes online: 3/3
   etcd           running (pid 6742)  1d 5h 59m 39s  health: green; healthy nodes: 3/3
   leaderl        running (pid 6788)  1d 5h 59m 35s  leader: 1; waiting: 0; follower: 2; total: 3
   postgresql     running (pid 6640)  1d 5h 59m 43s  leader: 1; offline: 0; syncing: 0; synced: 2
   

Шаг 4: Генерация конфигурации сервера Chef Infra

Войдите на узел из шага 1 и сгенерируйте конфигурацию узла front-end сервера chef-server:

chef-backend-ctl gen-server-config <FE1-FQDN> -f chef-server.rb.FE1
scp chef-server.rb.FE1 USER@<IP_FE1>:/home/<USER>

Шаг 5: Установка и настройка первого front-end

На первом узле front-end, предполагая, что сгенерированная конфигурация была скопирована, как указано в шаге 4:

1. Установите пакет chef-server-core

2. Скопируйте файл в /etc/opscode с помощью:

   `cp /home/<USER>/chef-server.rb.<FE1> /etc/opscode/chef-server.rb`
   

3. Как root, запустите

   chef-server-ctl reconfigure
   

Шаг 6: Добавление дополнительных узлов front-end

Для каждого дополнительного узла front-end, который вы хотите добавить в кластер:

1. Установите текущий пакет chef-server-core.

2. Сгенерируйте новый /etc/opscode/chef-server.rb с любого из узлов бэкенда, используя

   chef-backend-ctl gen-server-config <FE_NAME-FQDN> > chef-server.rb.<FE_NAME>
   

3. Скопируйте его в /etc/opscode на новом узле фронтенда.

4. С первого настроенного узла фронтенда в шаге 5 скопируйте следующие файлы с первого узла фронтенда в /etc/opscode на новом узле фронтенда:

   • /etc/opscode/private-chef-secrets.json

   Примечание

   Для версий Chef Server до 12.14, вам также потребуется скопировать файлы ключей:

   • /etc/opscode/webui_priv.pem
   • /etc/opscode/webui_pub.pem
   • /etc/opscode/pivotal.pem

5. На новом узле фронтенда выполните:

   mkdir -p /var/opt/opscode/upgrades/
   

6. С первого узла фронтенда скопируйте /var/opt/opscode/upgrades/migration-level в то же место на новом узле.

7. На новом узле фронтенда выполните:

   touch /var/opt/opscode/bootstrapped`
   

8. На новом узле фронтенда, как root, выполните:

   chef-server-ctl reconfigure
   

Шаг 7: Настройка сервера

1. Выполните следующую команду для создания администратора:

   sudo chef-server-ctl user-create USER_NAME FIRST_NAME LAST_NAME EMAIL 'PASSWORD' --filename FILE_NAME
   

   Автоматически генерируется закрытый ключ RSA. Это закрытый ключ пользователя и его следует сохранить в надёжном месте. Опция --filename сохранит закрытый ключ RSA в указанном абсолютном пути.

   Например:

   sudo chef-server-ctl user-create janedoe Jane Doe janed@example.com 'abc123' --filename /path/to/janedoe.pem
   

2. Выполните следующую команду для создания организации:

   sudo chef-server-ctl org-create short_name 'full_organization_name' --association_user user_name --filename ORGANIZATION-validator.pem
   

   Например:

   sudo chef-server-ctl org-create 4thcafe 'Fourth Cafe, Inc.' --association_user janedoe --filename /path/to/4thcafe-validator.pem
   

   Имя должно начинаться с строчной буквы или цифры, содержать только строчные буквы, цифры, дефисы и нижние подчёркивания, и иметь длину от 1 до 255 символов. Например: 4thcafe.

   Полное имя должно начинаться с символа, отличного от пробела, и иметь длину от 1 до 1023 символов. Например: 'Fourth Cafe, Inc.'.

   Опция --association_user свяжет user_name с группой безопасности admins на сервере Chef Infra.

   Автоматически генерируется закрытый ключ RSA. Это ключ chef-validator и его следует сохранить в надёжном месте. Опция --filename сохранит закрытый ключ RSA в указанном абсолютном пути.

Обновление сервера Chef Infra на машинах фронтенда

1. На одном сервере фронтенда выполните процесс обновления для автономных обновлений.
2. Скопируйте /var/opt/opscode/upgrades/migration-level с первого обновлённого фронтенда в /var/opt/opscode/upgrades/migration-level на каждом из оставшихся узлов фронтенда.
3. После копирования обновлённого файла на каждый из оставшихся узлов фронтенда выполните процесс обновления для автономных обновлений на каждом сервере фронтенда.

Настройка членов фронтенда и бэкенда в разных сетях

По умолчанию PostgreSQL позволяет системам в локальной сети подключаться к серверу базы данных, на котором он работает, и pg_hba.conf PostgreSQL управляет сетевым доступом к серверу. По умолчанию pg_hba.conf содержит следующие четыре записи:

host    all         all         samehost               md5
hostssl replication replicator  samehost               md5
host    all         all         samenet                md5
hostssl replication replicator  samenet                md5

Для разрешения подключения других систем, таких как члены группы фронтенда, которые могут находиться в другой сети, необходимо разрешить это использование, добавив следующую строку в файл /etc/chef-backend/chef-backend.rb на всех узлах бэкенда.

postgresql.md5_auth_cidr_addresses = ["samehost", "samenet", "<YOURNET IN CIDR>"]

После установки значения md5_auth_cidr_addresses и перенастройки сервера, в pg_hba.conf будут созданы две записи для каждого значения в массиве md5_auth_cidr_addresses. Существующие значения в pg_hba.conf будут перезаписаны значениями из массива, поэтому мы также должны указать «samehost» и «samenet», которые позволят системам в локальной сети подключаться к PostgreSQL.

Например, если узел фронтенда по адресу 192.168.1.3 может достичь узла бэкенда по сети, но локальная сеть бэкенда — 192.168.2.x, необходимо добавить следующую строку в /etc/chef-backend/chef-backend.rb

postgresql.md5_auth_cidr_addresses = ["samehost", "samenet", "192.168.1.3/24"]

что приведёт к добавлению двух записей в файл pg_hba.conf.

host    all         all         samehost               md5
hostssl replication replicator  samehost               md5
host    all         all         samenet                md5
hostssl replication replicator  samenet                md5
host    all         all         192.168.1.3/24         md5
hostssl replication replicator  192.168.1.3/24         md5

Выполнение chef-backend-ctl reconfigure на всех бэкендах позволит фронтенду завершить подключение.

Меры безопасности кластера

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

Взаимодействие между узлами

Взаимодействие PostgreSQL между узлами в кластере бэкенда зашифровано и использует аутентификацию по паролю. Все остальное взаимодействие в кластере бэкенда незащищено и происходит в открытом виде (без шифрования).

Взаимодействие между группой фронтенда и кластером бэкенда

Взаимодействие PostgreSQL с узлов группы фронтенда с лидером кластера бэкенда использует аутентификацию по паролю, но взаимодействие происходит в открытом виде (без шифрования).

Взаимодействие Elasticsearch незащищено и происходит в открытом виде (без шифрования).

Защита связи

Поскольку большая часть взаимодействия между узлами в кластере бэкенда происходит в открытом виде, кластер бэкенда уязвим для пассивного мониторинга сетевого трафика между узлами. Чтобы помочь предотвратить перехват или изменение данных кластера злоумышленником, Chef рекомендует использовать iptables или аналогичный инструмент сетевых ACL для ограничения доступа к PostgreSQL, Elasticsearch и etcd только для узлов, которым нужен доступ.

Требования доступа по ролям служб:

Службы и секреты

Взаимодействие с PostgreSQL требует аутентификации по паролю. Кластер бэкенда генерирует пользователей и пароли PostgreSQL во время первоначального создания кластера. Эти пароли присутствуют в следующих файлах на диске:

Следующие службы работают на каждом узле в кластере бэкенда. Пользователь, под которым выполняется служба, указан во второй колонке:

Фронтенд сервера Chef Infra

Команда chef-backend-ctl gen-server-config, которую можно выполнить как root с любого узла в кластере бэкенда, автоматически сгенерирует конфигурационный файл, содержащий учетные данные для доступа суперпользователя к базе данных для экземпляра PostgreSQL кластера бэкенда.

Версии программного обеспечения

Кластер бэкенда HA использует установщик Chef для подготовки всего программного обеспечения, необходимого для запуска служб, включённых в кластер бэкенда. Полный список пакетов программного обеспечения (и их версий) см. в файле по адресу /opt/chef-backend/version-manifest.json.

Не пытайтесь обновлять отдельные компоненты пакета Chef. Из-за способа сборки пакетов Chef, изменение любого из отдельных компонентов в пакете приведёт к нестабильности кластера. Если последняя версия кластера бэкенда предоставляет устаревший пакет, сообщите об этом в Chef, создав заявку поддержки по адресу support@chef.io.

Параметры chef-backend.rb

Выполните chef-backend-ctl gen-sample-backend-config для генерации файла chef-backend.rb. Он будет управлять большинством различных флагов функций и конфигурации для узла бэкенда Chef HA. Многие из этих опций управляют надёжностью, стабильностью и временем безотказной работы баз данных PostgreSQL бэкенда, индексом Elasticsearch и системой выбора лидера. Пожалуйста, не изменяйте их, если вам не было дано соответствующего разрешения.

Следующие параметры — единственные, которые вы можете изменять без руководства:

fqdn

Имя узла.

hide_sensitive

Установите в false, если хотите выводить дельты конфиденциальных файлов и шаблонов во время chef-backend-ctl reconfigure запусков.

Значение по умолчанию: true.

ip_version

Установите значение 'ipv4' или 'ipv6'.

Значение по умолчанию: 'ipv4'.

publish_address

Внешний IP-адрес этого бэкенд-узла.

Дополнительную информацию обо всех доступных параметрах см. в документации chef-backend.rb.

chef-backend-ctl

Кластер HA бэкенда Chef Infra Server включает утилиту командной строки с именем chef-backend-ctl. Эта утилита командной строки используется для управления кластером HA бэкенда Chef Infra Server, запуска и остановки отдельных сервисов, а также для просмотра журналов Chef Infra Server. Дополнительную информацию см. в документации chef-backend-ctl.