Spec-Zone.ru › Chef 17

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

[редактировать на GitHub]

Предупреждение

Сервер Chef Backend устарел и больше не находится в активной разработке. Обратитесь к своему представителю по работе с клиентами Chef для получения информации об обновлении вашей системы.

Этот документ больше не поддерживается.

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

Обзор

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

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

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

    Примечание

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

image

Важно

При развертывании в облаке кластеры Chef HA не предназначены для географического распределения по нескольким регионам или центрам обработки данных; однако в облачных провайдерах, таких как AWS, вы можете развернуть кластеры HA по нескольким зонам доступности в одном регионе.

Основные отличия от автономного сервера Chef Infra Server

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

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

Узлы

  • Установка бэк-энда HA требует трех узлов кластера. Chef не тестировал и не поддерживает установки с другим количеством узлов кластера бэк-эндов.
  • Один или несколько узлов группы фронт-эндов

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

Ниже приведен список общих требований к оборудованию для серверов фронт-энда и бэк-энда. Важное руководство, которому вы должны следовать, заключается в том, что серверы фронт-энда, как правило, более CPU-зависимы, а серверы бэк-энда — более зависимы от диска и памяти. Кроме того, объем дискового пространства для серверов бэк-энда должен увеличиваться с количеством узлов, которые они управляют. Хорошим правилом является выделение 2 МБ на узел. Значения диска, указанные ниже, должны быть хорошими значениями по умолчанию, которые вы захотите изменить позже, если/когда количество узлов вырастет.

  • 64-битная архитектура

Требования к фронт-ендам

  • 4 ядра (физические или виртуальные)
  • 4 ГБ оперативной памяти
  • 20 ГБ свободного дискового пространства (SSD, если на локальном сервере, Премиум хранилище в Microsoft Azure, EBS-оптимизированный GP2 в AWS)

Требования к бэк-ендам

  • 2 ядра (физические или виртуальные)
  • 8 ГБ оперативной памяти
  • 50 ГБ/сервер бэк-энда (SSD, если на локальном сервере, Премиум хранилище в Microsoft Azure, EBS-оптимизированный GP2 в AWS)

Предупреждение

Сервер Chef Infra Server НЕ должен использовать сетевую файловую систему любого типа — виртуальную или физическую — для хранения данных бэк-энда. База данных сервера Chef Infra Server работает быстро. Поведение операций, таких как запись журналов, будет непредсказуемым при запуске через сетевую файловую систему.

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

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

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

Входящие подключения от балансировщика нагрузки к группе фронт-эндов

  • 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 Server для включения в группу фронт-эндов проверьте:

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

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

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

  1. Установите пакет Chef Backend на первом узле бэк-энда в качестве 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. Если какие-либо из бэк-эндов или фронт-эндов находятся в разных сетях друг от друга, добавьте строку 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>"]
    
  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 для каждого узла бэк-энда, подключаемого к кластеру.

Шаг 3: Установка и настройка оставшихся узлов бэк-энда

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

  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 лидера. Если все кластеры бэк-энда и фронт-энда находятся в одной сети, то вам не нужно изменять /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. Повторите эти шаги для каждого узла-последователя, после чего кластер будет онлайн и доступен. С любого узла в кластере бэк-энда 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 Server.

Шаг 5: Установка и настройка первого фронт-энда

На первом узле фронт-энда, предположим, что сгенерированная конфигурация была скопирована, как указано в шаге 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: Добавление дополнительных узлов фронт-энда

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

  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: Настройка сервера

Примечание

Для восстановления резервной копии на этой системе, следуйте инструкциям chef-server-ctl или knife ec восстановления.
  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.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.
Elasticsearch Все члены кластера бэкенда и все узлы группы фронтенда сервера Chef Infra.
etcd Все члены кластера бэкенда и все узлы группы фронтенда сервера Chef Infra.

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

Взаимодействие с 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

Команда 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/server/install_server_ha/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API