Spec-Zone.ru › Chef 16

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

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

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

Обзор

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

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

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

    Примечание

    На данный момент кластеры бэкенда могут содержать только три узла.

image

Важно

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

Ключевые отличия от автономного сервера 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: Создание кластера

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

  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.

Шаг 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 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 на узлах фронтенда

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

Spec-Zone.ru

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