Обзор сервера 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 могут быть синхронизированы вверх по потоку с помощью программного обеспечения непрерывной интеграции.

Основным ограничивающим фактором для установок сервера 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