Высокая доступность: бэкенд Chef
В данном разделе рассматриваются основные концепции, лежащие в основе архитектуры кластера высокодоступного сервера Chef Infra. Затем описывается процесс настройки и установки кластера высокодоступного сервера Chef Infra, состоящего из пяти узлов в целом (два фронтенда и три бэкенда).
Обзор
Сервер Chef Infra может работать в конфигурации высокой доступности, обеспечивая автоматическое распределение нагрузки и резервирование для состоятельных компонентов в архитектуре системы. Такая конфигурация обычно разделяет серверы на два сегмента: кластер бэкенда и группу фронтенда.
Группа фронтенда, состоящая из одного (или более) узлов, на которых запущен сервер Chef Infra. Узлы группы фронтенда обрабатывают запросы к API сервера Chef Infra и доступ к консоли управления Chef. Узлы группы фронтенда должны быть сбалансированы по нагрузке и могут масштабироваться горизонтально, увеличивая количество узлов, доступных для обработки запросов.
-
Кластер бэкенда, состоящий из трех узлов, работающих вместе, обеспечивает высокую доступность и сохранение данных для группы фронтенда.
Примечание
На данный момент кластеры бэкенда могут содержать только три узла.
Важно
Ключевые отличия от автономного сервера Chef Infra
Новое в Chef Infra Server 14 Начиная с Chef Infra Server 14, автономные экземпляры используют Elasticsearch для внутреннего поиска. Elasticsearch предоставляет более гибкие варианты кластеризации, сохраняя при этом совместимость API поиска с Apache Solr.
Рекомендуемая топология кластера
Узлы
- Установка бэкенда HA требует трех узлов кластера. Chef не тестировал и не поддерживает установки с другим количеством узлов кластера бэкенда.
- Один или несколько узлов группы фронтенда
Требования к оборудованию
Ниже приведен список общих требований к оборудованию для серверов фронтенда и бэкенда. Важным направлением является то, что серверы фронтенда обычно более ограничены по процессору, а серверы бэкенда — по диску и памяти. Кроме того, объем дискового пространства для серверов бэкенда должен увеличиваться с количеством узлов, которые управляют этими серверами. Хорошим правилом является выделение 2 МБ на узел. Указанные ниже значения дисков должны быть хорошим значением по умолчанию, которое вы захотите изменить позже, если/когда количество узлов увеличится.
- 64-разрядная архитектура
Требования к фронтенду
- 4 ядра (физические или виртуальные)
- 4 ГБ ОЗУ
- 20 ГБ свободного дискового пространства (SSD, если на локальном сервере, Премиум-хранилище в Microsoft Azure, EBS-оптимизированный GP2 в AWS)
Требования к бэкенду
- 2 ядра (физические или виртуальные)
- 8 ГБ ОЗУ
- 50 ГБ/сервер бэкенда (SSD, если на локальном сервере, Премиум-хранилище в Microsoft Azure, EBS-оптимизированный GP2 в AWS)
Предупреждение
Сервер Chef Infra НЕ должен использовать файловую систему сетевого типа любого типа — виртуальную или физическую — для хранения бэкенда. База данных сервера Chef Infra работает быстро. Поведение операций, таких как запись файлов журналов, будет непредсказуемым при работе через сетевую файловую систему.
Сеть услуги
- Бэлансировщик нагрузки между остальной частью сети и группой фронтенда (не предоставлено). Поскольку данные сеансов консоли управления хранятся на каждом узле в группе фронтенда индивидуально, балансировщик нагрузки должен быть настроен со «входящими» сеансами.
Требования к сетевым портам
Входящие подключения с балансировщика нагрузки в группу фронтенда
- TCP 80 (HTTP)
- TCP 443 (HTTPS)
Входящие подключения с группы фронтенда в кластер бэкенда
- TCP 2379 (etcd)
- TCP 5432 (PostgreSQL)
- TCP 7331 (leaderl)
- TCP 9200-9300 (Elasticsearch)
Взаимодействие между узлами, кластер бэкенда
- 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), если они у вас еще не установлены.
Перед созданием кластера бэкенда HA и созданием хотя бы одного сервера Chef Infra, который будет частью группы фронтенда, проверьте:
- Пользователь, который будет устанавливать и создавать кластер бэкенда HA и группу фронтенда, имеет права root на всех узлах.
- Количество узлов бэкенда и фронтенда, которые необходимы. Требуется три узла бэкенда, но количество узлов фронтенда может варьироваться от одного узла до конфигурации сбалансированного по нагрузке уровня.
- Доступ по SSH ко всем машинам, которые будут принадлежать кластеру бэкенда HA, с узла, который будет первоначальным началом работы.
- Установлено политика синхронизации времени, например, протокол Network Time Protocol (NTP). Разница должна быть менее 1,5 секунд на всех узлах кластера бэкенда HA.
Шаг 1: Создание кластера
Первый узел должен быть запущен для инициализации кластера. Узел, используемый для запуска кластера, будет лидером кластера, когда кластер заработает. После завершения загрузки этот узел ничем не отличается от любого другого узла бэкенда.
-
Установите пакет Chef Backend на первый узел бэкенда с правами root.
- Загрузите Chef Backend (chef-backend)
- В Red Hat/CentOS:
yum install PATH_TO_RPM - В Debian/Ubuntu:
dpkg -i PATH_TO_DEB
-
Обновите
/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в/etc/chef-backend/chef-backend.rbсо следующим содержимым, где, "<NET-1_IN_CIDR>", ..., "<NET-N_IN_CIDR>"— это список всех сетей, в которых находятся ваши бэкенды и фронтенды. См. раздел Настройка фронтенд- и бэкенд-узлов в разных сетях для получения дополнительной информации: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>"] Запустите
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 будет выполнен для каждого узла бэкенда, присоединяемого к кластеру.
Шаг 3: Установка и настройка оставшихся узлов бэкенда
Для каждого дополнительного узла выполните следующие действия последовательно (если вы попытаетесь присоединить узлы параллельно, кластер может не стать доступным):
-
Установите пакет Chef Backend на узел.
- Загрузите Chef Backend (chef-backend)
- В Red Hat/CentOS:
yum install PATH_TO_RPM - В Debian/Ubuntu:
dpkg -i PATH_TO_DEB
-
Если вы добавили строку
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лидера. Если все кластеры бэкенда и фронтенда находятся в одной сети, вам не нужно изменять этот узел/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>"] -
С правами root или с использованием sudo:
chef-backend-ctl join-cluster <IP_BE1> -s /home/<USER>/chef-backend-secrets.json Ответьте на запросы, касающиеся использования публичного 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.Если вы скопировали общий файл
chef-backend-secrets.jsonв домашнюю папку пользователя на этом узле, удалите его сейчас.-
Повторите эти шаги для каждого узла-фолловера, после чего кластер будет онлайн и доступен. С любого узла в кластере бэкенда 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 и сгенерируйте конфигурацию узла фронтенда 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>
Примечание
/etc/chef-backend/chef-backend-secrets.json не предоставляется узлам фронтенда сервера Chef Infra.Шаг 5: Установка и настройка первого фронтенда
На первом узле фронтенда, предполагая, что сгенерированная конфигурация была скопирована, как описано в шаге 4:
Установите текущий пакет
chef-server-core-
Скопируйте файл в
/etc/opscodeс помощью:`cp /home/<USER>/chef-server.rb.<FE1> /etc/opscode/chef-server.rb` -
С правами root, запустите
chef-server-ctl reconfigure
Шаг 6: Добавление дополнительных узлов фронтенда
Для каждого дополнительного узла фронтенда, который вы хотите добавить в свой кластер:
Установите текущий пакет
chef-server-core.-
Сгенерируйте новый
/etc/opscode/chef-server.rbс любого из узлов бэкэнда, используяchef-backend-ctl gen-server-config <FE_NAME-FQDN> > chef-server.rb.<FE_NAME> Скопируйте его в
/etc/opscodeна новом узле фронтенда.-
С первого узла фронтенда, настроенного на шаге 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
-
На новом узле фронтенда выполните:
mkdir -p /var/opt/opscode/upgrades/ С первого узла фронтенда скопируйте
/var/opt/opscode/upgrades/migration-levelв то же место на новом узле.-
На новом фронтенде выполните:
touch /var/opt/opscode/bootstrapped` -
На новом фронтенде, как root, выполните:
chef-server-ctl reconfigure
Шаг 7: Настройка сервера
Примечание
-
Выполните следующую команду для создания администратора:
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 -
Выполните следующую команду для создания организации:
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 4thcoffee 'Fourth Coffee, Inc.' --association_user janedoe --filename /path/to/4thcoffee-validator.pemИмя должно начинаться с маленькой буквы или цифры, содержать только маленькие буквы, цифры, дефисы и нижние подчёркивания, и должно быть от 1 до 255 символов. Например:
4thcoffee.Полное имя должно начинаться с символа, отличного от пробела, и должно быть от 1 до 1023 символов. Например:
'Fourth Coffee, Inc.'.Опция
--association_userассоциируетuser_nameс группой безопасностиadminsна сервере Chef Infra.Приватный ключ RSA генерируется автоматически. Это ключ chef-validator, и его следует сохранить в безопасном месте. Опция
--filenameсохранит приватный ключ RSA в указанном абсолютном пути.
Обновление Chef Infra Server на узлах фронтенда
- На одном сервере фронтенда выполните процесс обновления standalone.
- Скопируйте
/var/opt/opscode/upgrades/migration-levelс первого обновлённого фронтенда в/var/opt/opscode/upgrades/migration-levelна каждом из оставшихся фронтендов. - После копирования обновлённого файла на каждый из оставшихся фронтендов выполните процесс обновления standalone на каждом из серверов фронтенда.
Настройка узлов фронтенда и бэкэнда в разных сетях
По умолчанию 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.md5_auth_cidr_addresses должны быть идентичными для всех узлов кластера бэкэнда. В случае, если настройки подсети кластера фронтенда отличаются от настроек подсети кластера бэкэнда, значения, заданные на узлах кластера бэкэнда, должны содержать подсеть кластера фронтенда. Это гарантирует, что все узлы кластера смогут общаться друг с другом после изменения состояния кластера. Например, если подсеть фронтенда — «192.168.1.0/24», а подсеть бэкэнда — «192.168.2.0/24», то настройки подсети postgresql.md5_auth_cidr_addresses должны быть postgresql.md5_auth_cidr_addresses = ["samehost", "samenet", "192.168.1.0/24", 192.168.2.0/24]Учетные соображения безопасности кластера
Ожидается, что кластер бэкэнда будет работать в надёжной среде. Это означает, что ненадёжные пользователи, взаимодействующие с услугами кластера бэкэнда или перехватывающие трафик, могут потенциально получить доступ к конфиденциальным данным.
Взаимодействие между узлами
Взаимодействие PostgreSQL между узлами кластера бэкэнда шифруется и использует аутентификацию по паролям. Всё остальное взаимодействие в кластере бэкэнда неаутентифицировано и происходит в открытом виде (без шифрования).
Взаимодействие между группой фронтенда и кластером бэкэнда
Взаимодействие PostgreSQL между узлами группы фронтенда и лидером кластера бэкэнда использует аутентификацию по паролям, но происходит в открытом виде (без шифрования).
Взаимодействие Elasticsearch неаутентифицировано и происходит в открытом виде (без шифрования).
Защита взаимодействия
Поскольку большая часть взаимодействия между узлами кластера бэкэнда происходит в открытом виде, кластер бэкэнда уязвим для пассивного мониторинга сетевого трафика между узлами. Чтобы предотвратить перехват или изменение данных кластера активным злоумышленником, Chef рекомендует использовать iptables или аналогичный инструмент сетевых ACL для ограничения доступа к PostgreSQL, Elasticsearch и etcd только к хостам, которым нужен доступ.
Требования к доступу по ролям служб следующие:
| Сервис | Требования к доступу |
|---|---|
| PostgreSQL | Все узлы кластера бэкэнда и все узлы группы фронтенда Chef Infra Server. |
| Elasticsearch | Все узлы кластера бэкэнда и все узлы группы фронтенда Chef Infra Server. |
| etcd | Все узлы кластера бэкэнда и все узлы группы фронтенда Chef Infra Server. |
Службы и секреты
Взаимодействие с PostgreSQL требует аутентификации по паролю. Кластер бэкэнда генерирует пользователей и пароли PostgreSQL во время создания кластера. Эти пароли находятся в следующих файлах на диске:
| Секрет | Владелец | Группа | Режим |
|---|---|---|---|
/etc/chef-backend/secrets.json |
root |
chef_pgsql |
0640 |
/var/opt/chef-backend/leaderl/data/sys.config |
chef_pgsql |
chef_pgsql |
0600 |
/var/opt/chef-backend/PostgreSQL/9.5/recovery.conf |
chef_pgsql |
chef_pgsql |
0600 |
Следующие службы выполняются на каждом узле кластера бэкэнда. Пользователь, под которым выполняется служба, указан во второй колонке:
| Служба | Владелец процесса |
|---|---|
postgresql |
chef_pgsql |
elasticsearch |
chef-backend |
etcd |
chef-backend |
leaderl |
chef_pgsql |
epmd |
chef_pgsql (или первый пользователь, запускающий процесс erlang) |
Chef Infra Server фронтенд
Команда 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.
© Chef Software, Inc.
Licensed under the Creative Commons Attribution 3.0 Unported License.
The Chef™ Mark and Chef Logo are either registered trademarks/service marks or trademarks/servicemarks of Chef, in the United States and other countries and are used with Chef Inc's permission.
We are not affiliated with, endorsed or sponsored by Chef Inc.
https://docs.chef.io/install_server_ha/