Обзор сервера Chef Infra

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

Сервер Chef Infra Server служит центром для данных конфигурации. Сервер Chef Infra Server хранит кулинарии, политики, применяемые к узлам, и метаданные, описывающие каждый зарегистрированный узел, управляемый клиентом Chef Infra Client. Узлы используют Chef Infra Client для запроса у сервера Chef Infra Server данных конфигурации, таких как рецепты, шаблоны и распределение файлов. Chef Infra Client выполняет как можно больше работы по конфигурации на самих узлах (а не на сервере Chef Infra Server). Этот масштабируемый подход распределяет усилия по конфигурации по всей организации.

Фронтенд для сервера Chef Infra Server написан на языке программирования Erlang, появившемся в 1986 году, который был выпущен под открытой лицензией в 1998 году и отлично подходит для критически важных задач корпоративного уровня, таких как конкурентность, отказоустойчивость и распределенные среды. Сервер Chef Infra Server может масштабироваться до размера любой корпорации и иногда называется Erchef.

Компоненты сервера

На следующей схеме показаны различные компоненты развертывания сервера Chef Infra Server и их взаимосвязь.

Планирование емкости

Этот раздел содержит рекомендации по планированию емкости и выбору правильной конфигурации — автономной, с высокой доступностью или многоуровневой — для сервера Chef Infra Server. Этот раздел содержит рекомендации, а не жесткие правила. Это связано с тем, что некоторые запросы к API сервера Chef Infra Server более ресурсоемкие, чем другие. В общем, лучше начинать с малого, а затем масштабировать сервер Chef Infra Server по мере необходимости. Преждевременная оптимизация может нанести больше вреда, чем пользы, потому что может добавить ненужную сложность.

Масштабирование сервера Chef Infra Server

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

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

Например, если есть дата-центры на западном и восточном побережье, лучше иметь по одному экземпляру сервера Chef Infra Server в каждом дата-центре. Развертывания на каждом сервере Chef Infra Server могут быть синхронизированы вверх по потоку с помощью программного обеспечения непрерывной интеграции и непрерывной доставки (CI).

Основным ограничивающим фактором для установок сервера Chef Infra Server почти всегда является производительность операций ввода/вывода в секунду (IOPS) для файловой системы базы данных.

CCRs/мин

Ключевой единицей измерения для масштабирования сервера Chef Infra Server является количество запусков Chef Infra Client в минуту: CCRs/мин. Например, 500 узлов, настроенных на вход каждые 30 минут, эквивалентны 16,66 CCRs/мин.

Как правило, сервер Chef Infra Server не требует топологии с высокой доступностью или многоуровневой, пока количество CCRs/мин не превысит 333/мин (приблизительно 10 000 узлов).

Хотя синтетические тесты следует воспринимать с осторожностью, поскольку они обычно не отражают реальной производительности, в Chef проводились внутренние синтетические тесты, в которых автономный сервер Chef Infra Server, установленный на экземпляре c3.2xlarge Amazon Web Services (AWS), обрабатывал более 1000 CCRs/мин (30 000 узлов).

Предположения

На масштабируемость сервера могут влиять различные факторы. Все рекомендации по размеру сервера основаны на следующих предположениях:

• Запуска Chef Infra Client выполняются в фоновом режиме и не инициируются задачей cron. Использование cron для планирования запусков может создавать проблемы «множественных запросов»
• Запуска Chef Infra Client установлены по умолчанию с интервалом 30 минут с разбросом в 5 минут.
• Используются поиск и partial_search, но не интенсивно.
• Количество кулинарий на организацию по всем версиям на сервере Chef Infra Server не превышает 500. (Несколько организаций с менее чем 500 кулинариями каждая, которые в сумме все равно превышают 500 кулинарий на сервере, нормально).
• Максимально допустимый размер объекта узла по умолчанию составляет 1 МБ, хотя редко узлы превышают 150 КБ. Хотя данные сжаты, они дублируются дважды, один раз в Elasticsearch и один раз в PostgreSQL. На практике достаточным должно быть выделение 2 МБ дискового пространства на раздел диска на узел.

Характеристики хоста

В следующих разделах описаны характеристики хоста для различных значений CCRs/мин и показано, когда следует перейти от автономной топологии к топологии с высокой доступностью или многоуровневой.

ДО 33 CCRs/мин (приблизительно 1000 узлов):

• Chef рекомендует использование одного виртуального экземпляра.
• Начните с 2 ядер процессора и 8 ГБ оперативной памяти, что эквивалентно экземпляру Amazon EC2 m3.large.
• Выделите 2 МБ дискового пространства на раздел данных на каждый управляемый узел.

ДО 167 CCRs/мин (приблизительно 5000 узлов):

• Chef рекомендует использование одного виртуального экземпляра.
• Начните с 4 ядер процессора и 16 ГБ оперативной памяти, что эквивалентно экземпляру Amazon EC2 m3.xlarge.

ДО 333 CCRs/мин (приблизительно 10 000 узлов):

• Chef рекомендует использование одного виртуального экземпляра.
• Начните с 8 ядер процессора и 32 ГБ оперативной памяти, что эквивалентно экземпляру Amazon EC2 m3.2xlarge.

ДО 667 CCRs/мин (приблизительно 20 000 узлов):

• Chef рекомендует использование двух хостов: одного фронтенда и одного бэкенда.
• Требование к дисковому пространству для фронтенд-сервера незначительно.
• Начните с 8 ядер процессора и 32 ГБ оперативной памяти для каждого хоста, что эквивалентно экземпляру Amazon EC2 m3.2xlarge.

Масштабирование свыше 20 000 узлов в одном кластере:

• Дополнительную емкость можно получить, разместив фронтенд-узел за балансировщиком HTTP и масштабируя фронтенд-узлы горизонтально.
• Chef рекомендует обратиться к профессиональным службам Chef для помощи в планировании емкости и архитектуры при таком объеме.

Внешние кулинарии

На следующей схеме показаны изменения, которые происходят при хранении кулинарий во внешнем расположении, например, в Amazon Simple Storage Service (S3).

В следующей таблице описаны компоненты, которые отличаются от стандартной конфигурации сервера Chef Infra Server при хранении кулинарий во внешнем расположении:

Настройки AWS

Обязательные настройки

Для настройки внешнего хранилища кулинарных книг с использованием Amazon Simple Storage Service (S3) установите следующие настройки конфигурации в файле chef-server.rb и выполните chef-server-ctl reconfigure:

Пример конфигурации chef-server.rb:

bookshelf['vip'] = 's3-external-1.amazonaws.com'
bookshelf['external_url'] = 'https://s3-external-1.amazonaws.com'
bookshelf['access_key_id'] = '<ACCESS_ID>'
bookshelf['secret_access_key'] = '<ACCESS_KEY>'
opscode_erchef['s3_bucket'] = '<BUCKET_NAME>'

Дополнительные настройки

Также доступны следующие дополнительные настройки, которые могут потребовать изменения при использовании внешнего поставщика S3:

Внешний PostgreSQL

На следующей схеме показаны конкретные изменения, которые происходят при конфигурации и управлении PostgreSQL независимо от конфигурации сервера Chef Infra.

В следующей таблице описаны компоненты в конфигурации внешнего PostgreSQL, которые отличаются от стандартной конфигурации сервера Chef Infra:

Настройки PostgreSQL

Используйте следующие настройки конфигурации в файле chef-server.rb для настройки внешнего PostgreSQL для использования с сервером Chef Infra:

postgresql['db_superuser']

Требуется, когда postgresql['external'] установлено в true. Имя пользователя PostgreSQL. Этому пользователю должны быть предоставлены разрешения CREATE ROLE и CREATE DATABASE в PostgreSQL или разрешение SUPERUSER. У этого пользователя также должен быть запись в файле конфигурации проверки подлинности по хостам, используемом PostgreSQL (обычно именованным как pg_hba.conf). Значение по умолчанию: 'superuser_userid'.

postgresql['db_superuser_password']

Пароль для пользователя, указанного в postgresql['db_superuser']. Требуется, когда postgresql['external'] установлено в true.

db_superuser_password также можно установить с помощью chef-server-ctl set-db-superuser-password из команд Управление секретами.

postgresql['external']

Требуется. Установите в true для запуска PostgreSQL вне сервера Chef Infra. Должен быть установлен только один раз при новой установке сервера Chef Infra перед запуском первой команды chef-server-ctl reconfigure. Если это значение установлено после переконфигурации или установлено в false, любая переконфигурация сервера Chef Infra вернет ошибку. Значение по умолчанию: false.

postgresql['port']

Необязательно, когда postgresql['external'] установлено в true. Порт, на котором служба должна прослушивать. Порт, используемый PostgreSQL, если этот порт не 5432. Значение по умолчанию: 5432.

postgresql['vip']

Требуется, когда postgresql['external'] установлено в true. Виртуальный IP-адрес. Хост для этого IP-адреса должен быть активным и доступным для сервера Chef Infra через порт, указанный в postgresql['port']. Установите это значение на IP-адрес или имя хоста машины, на которой находится внешний PostgreSQL, когда postgresql['external'] установлено в true.

Дополнительные настройки

Следующие дополнительные настройки необходимы при настройке внешнего PostgreSQL в Microsoft Azure:

bookshelf['sql_connection_user']

Имя пользователя PostgreSQL в формате 'username@hostname' (например, 'bookshelf@my_postgresql.postgres.database.azure.com'), где username обычно равно значению bookshelf['sql_user'] (значение по умолчанию: 'bookshelf'). Эта настройка обязательна во внешней конфигурации Azure PostgreSQL как службы базы данных. Если установлено значение nil, сервер Chef Infra предполагает, что база данных не находится в Azure, и подключение к PostgreSQL будет выполнено с использованием значения, указанного в bookshelf['sql_user']. Значение по умолчанию: nil.

oc_bifrost['sql_connection_user']

Имя пользователя PostgreSQL в формате 'username@hostname' (например, 'bifrost@my_postgresql.postgres.database.azure.com'), где username обычно равно значению oc_bifrost['sql_user'] (значение по умолчанию: 'bifrost'). Эта настройка обязательна во внешней конфигурации Azure PostgreSQL как службы базы данных. Если установлено значение nil, сервер Chef Infra предполагает, что база данных не находится в Azure, и подключение к PostgreSQL будет выполнено с использованием значения, указанного в oc_bifrost['sql_user']. Значение по умолчанию: nil.

oc_id['sql_connection_user']

Имя пользователя PostgreSQL в формате 'username@hostname' (например, 'oc_id@my_postgresql.postgres.database.azure.com'), где username обычно равно значению oc_id['sql_user'] (значение по умолчанию: 'od_id'). Эта настройка обязательна во внешней конфигурации Azure PostgreSQL как службы базы данных. Если установлено значение nil, сервер Chef Infra предполагает, что база данных не находится в Azure, и подключение к PostgreSQL будет выполнено с использованием значения, указанного в oc_id['sql_user']. Значение по умолчанию: nil.

opscode_erchef['sql_connection_user']

Имя пользователя PostgreSQL в формате 'username@hostname' (например, 'opscode_chef@my_postgresql.postgres.database.azure.com'), где username обычно равно значению opscode-erchef['sql_user'] (значение по умолчанию: 'opscode_chef'). Эта настройка обязательна во внешней конфигурации Azure PostgreSQL как службы базы данных. Если установлено значение nil, сервер Chef Infra предполагает, что база данных не находится в Azure, и подключение к PostgreSQL будет выполнено с использованием значения, указанного в opscode_erchef['sql_user']. Значение по умолчанию: nil.

postgresql['db_connection_superuser']

Имя суперпользователя PostgreSQL в формате 'username@hostname' (например, 'opscode_pgsql@my_postgresql.postgres.database.azure.com'), где username обычно равно значению postgresql['db_superuser'] с заменой всех дефисов на подчеркивания. Эта настройка обязательна во внешней конфигурации Azure PostgreSQL как службы базы данных. Если установлено значение nil, сервер Chef Infra предполагает, что база данных не находится в Azure, и подключение к PostgreSQL будет выполнено с использованием значения, указанного в postgresql['db_superuser']. Значение по умолчанию: nil.

Пример конфигурации chef-server.rb для внешнего PostgreSQL в Microsoft Azure:

topology 'standalone'
postgresql['external'] = true
postgresql['vip'] = 'my_postgresql.postgres.database.azure.com'
postgresql['db_superuser'] = 'opscode_pgsql'
postgresql['db_superuser_password'] = 'My_postgres_password1!'
postgresql['db_connection_superuser'] = 'opscode_pgsql@my_postgresql.postgres.database.azure.com'
# postgresql['sslmode']='require' # required if 'Enforce SSL connection' is enabled on Azure PostgreSQL
bookshelf['sql_connection_user'] = 'bookshelf@my_postgresql.postgres.database.azure.com'
oc_bifrost['sql_connection_user'] = 'bifrost@my_postgresql.postgres.database.azure.com'
oc_id['sql_connection_user'] = 'oc_id@my_postgresql.postgres.database.azure.com'
opscode_erchef['sql_connection_user'] = 'opscode_chef@my_postgresql.postgres.database.azure.com'

Настройки Bookshelf

В случаях, когда требуется хранить кулинарные книги в SQL-бекенде, например, в высокодоступной настройке, необходимо установить storage_type на :sql:

bookshelf['storage_type'] = :sql