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

Запуск нового вычислительного центра на бумаге выглядит как логистический кошмар. На создание текущей системы у вас ушли месяцы и годы. Как быстро воссоздать ее в другом месте? Благодаря автоматизации развертывания перспектива построения всего комплекса, начиная с уровня «голого железа», выглядит не столь устрашающе.

Вместо повторения каждой системы исходного сайта на уровне отдельных хостов процесс выглядит так:

• Создание управляющих хостов в новом вычислительном центре. Базовая установка может проводиться в ручном режиме, чего не скажешь о настройке. Конфигурации управляющих хостов должны входить в систему управления конфигурацией!
• Настройка базовых конфигураций для новой среды, ведь конфигурация DNS и данные маршрутизации будут отличаться от старых настроек.
• Назначение ролей новых компьютеров на загрузочном сервере (или в системе учета оборудования).
• Загрузка хостов, которые начинают установку и настройку своего программного обеспечения.

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

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

Итак, вы реализовали заветную цель управления конфигурацией — инфраструктуру с нескольким и правильно настроенным и серверами, на которые вам никогда не придется входить для выполнения управляющих операции.

А если все таки придется? В некоторых случаях удобно выполнить команду от имени всех участников некоторой роли. К счастью, существуют инструменты, упрощающие решение этой задачи, от простых сценариев «выполнить ssh в цикле for» до изощренных систем удаленного выполнения сценариев вроде Capistrano.

В идеале такой инструмент должен интегрироваться с системой управления конфигурацией. Желательно иметь возможность входа на группы серверов по роли или даже по службе. Возможно, для этого придется написать сценарный код, который будет преобразовывать определения ролей и служб в формат, понятный инструменту. Возможно, такой инструмент уже входит в системы управления конфигурацией или мониторинга (как, например, утилита gexec из поставки Ganglia).

Итак, вы можете выполнять команды на нескольких серверах. Но стоит ли это делать?

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

Когда это может быть нежелательно? Во всех случаях, когда более уместно использовать средства управления конфигурацией. Всегда существует вероятность того, что вы забудете о внесенных «разовых» изменениях, а потом не раз пожалеете об этом.

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

Существует несколько способов. Весьма популярны сетевые службы аутентификации и авторизации такие как LDAP. Чтобы представить пользователям и группам доступ к отдельным компьютерам или структурам хостов, администратор вносит изменения в одном месте, а коррекции разрешений и паролей распространяются автоматически. В то же время эти системы становятся еще одной службой, нуждающейся в наблюдении, обеспечении работоспособности и масштабировании в процессе развития инфраструктуры.

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

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

Оба варианта работоспособны. Какой из них лучше подойдет для вашей инфраструктуры? Это зависит от существующих систем аутентификации, количества пользователей и частоты внесения изменений. Если LDAP уже используется в вашей организации, такой выбор будет наиболее естественным. Если в системе работает малое количество пользователей, а изменения относительно редки, возможно, пакетная система более уместна.

Допустим, у вас имеется кластер из четырех веб-серверов. Каждая машина предоставляет клиенту комбинацию статического контента и динамических страниц, генерируемых РНР. Значение параметра MaxClients в Apache уменьшено до 80 одновременных подключений, чтобы предотвратить переполнение доступной памяти и подкачку с диска (swapping). Роль веб-сервера может выглядеть примерно так, как показано на рисунке.

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

Сначала службы, общие для обеих ролей, выделяются в отдельную базовую службу HTTP (base_http). Эта служба включает функциональность, которая должна поддерживаться любым веб-сервером например, проверку общей работоспособности HTTP и получение метрик от модуля Apache status_module.

Затем создаются две новые службы. Динамическая служба HTTP содержит исходные конфигурации Apache и PHP. Статическая служба HTTP настраивается с упрощенной конфигурацией httpd.conf, более высоким клиентским порогом и без модуля РНР.

Далее роли для каждого типа сервера определяются комбинированием этих служб. Новые роли изображены на рисунке.

После определения новой роли вы можете либо открыть систему учета оборудования и назначить одному или нескольким существующим веб-серверам роль static_webserver, либо развернуть новое оборудование с новой ролью. Если в будущем потребуется добавить дополнительные метрики или проверки, применимые к обеим ролям, включите их в службу base_http, тогда они будут унаследованы обеими ролями.

Итак, вы установили новенькую систему управления конфигурацией. Как ею пользоваться? Лучше всего выбрать стратегию «разделяй и властвуй». Службы (совокупности взаимосвязанных программ и конфигураций) атомы, роли (типы машин в вашей инфраструктуре) — молекулы. Определив достаточно полный набор служб, вы сможете объединять существующие службы в альтернативные комбинации для выполнения новых ролей или же распределять существующие роли по более специализированным конфигурациям.

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

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

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

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

У таких систем имеется одна раздражающая особенность: они часто перестают соответствовать действительности из-за перемещения, списания или перепрофилирования оборудования.

Чтобы выбраться из этой ловушки, сделайте систему учета оборудования частью инфраструктуры развертывания. Используя информацию из базы данных оборудования для управления установкой и настройкой, вы превращаете ее из «моментального снимка» инфраструктуры в источник достоверных данных, который управляет вашими системами и сообщает им жизненно важную информацию.

В частности, такой подход был выбран системой iClassify. Она поддерживает автоматическую регистрацию, а также ручную и автоматизированную классификацию. Кроме того, iClassify интегрируется с Puppet для управления конфигурацией и с Capistrano для ситуативного управления серверами.

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

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

Типичная система управления конфигурацией состоит из сервера, на котором хранятся конфигурации, и клиентского процесса, который выполняется на каждом хосте и запрашивает конфигурационные данные у сервера. В инфраструктуре с автоматизированным развертыванием клиент запускается в процессе исходной установки или после первой загрузки новой операционной системы.

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

Если ОС устанавливается сразу на нескольких машинах, установка с физического носителя (например, CD-ROM) быстро становится утомительной, и к тому же требует физического присутствия специалиста в вычислительном центре. Удобнее создать сетевой загрузочный сервер, в архитектуре PC обычно используется РХЕ (Pre-boot Execution Environment).

Процесс РХЕ-установки основан на совместной работе нескольких служб. Микрокод РХТ на стороне клиента обращается с запросами к рабочей среде через протокол DHCP. Сервер DHCP предоставляет информацию, необходимую для получения загрузочного образа (IP-адрес, загрузочный сервер и имя образа). Наконец, клиент получает образ с загрузочного сервера по протоколу TFTP.

В системах автоматизированной установки загрузочный образ состоит из ядра и виртуального диска, содержащего установочную программу. (Такой подход отличается от бездисковой установки, когда загрузочный образ содержит ядро, используемое клиентом для монтирования сетевого тома в качестве корневой файловой системы.)

Программа установки определяет тип хоста и форматирует локальные файловые системы соответствующим образом. Существует несколько методов установления соответствия между аппаратными профилями и хостами, как правило, конфигурации назначаются в зависимости от имени или MAC-адреса хоста. Например, Kickstart передает имя конфигурационного файла через DHCP и получает его с сервера TFTP, тогда как у SystemImager конфигурационный файл хранится на специальном сервере, устанавливающем соответствие между типами образов и именами хостов.

Затем программа устанавливает ОС по сети на отформатированных томах. Для пакетных программ это означает копирование пакетных файлов из сетевого хранилища (например, apt или yum). Для систем, использующих образы, образ ОС сбрасывается непосредственно на локальный том, обычно при помощи rsync или аналогичной программы.

После того как образ ОС будет скопирован, сервер РХЕ устанавливает признак готовности хоста к установке. Как правило, для этого загрузочный файл хоста замещается заглушкой, которая приказывает хосту выполнять загрузку с локального диска. Компьютер перезапускается и загружается обычным образом.

В стандартном варианте поставки системы автоматизированной установки приходится настраивать вручную. Администратор должен создать конфигурации сервера DHCP и определить соответствия между именами хостов и ролями.

Впрочем, система учета оборудования должна располагать всей информацией о компьютере, необходимой для загрузки: МАС-адрес, роль, IP-адрес и имя хоста. Если творчески подойти к написанию сценария вы сможете автоматизировать процедуру построения необходимых конфигурационных файлов, используй базу данных оборудования.

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

Процедура развертывания, столь нелюбимая многими администраторами, наконец-то укрощена.

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

В пакетных системах образ ОС определяется в конфигурационном файле с перечнем устанавливаемых пакетов. Достигая целей автоматического развертывания, администратор просто загружает список пакетов с существующего сервера и изменяет его так, как считает нужным. Далее конфигурационный файл размещается в соответствующем месте загрузочного сервера, и все готово к работе.

В системах, использующих образы, настройка конфигурации проходит несколько сложнее. Обычно один из серверов резервируется в качестве эталонного клиента, который предоставляет шаблон для развертываемого образа. Им может быть как физический сервер, так и виртуальная машина. Администратор выполняет обычную установку ОС и устанавливает все программы, необходимые в его инфраструктуре. Затем образ клиента копируется на новый сервер.

Прежде чем задумываться о настройке конфигурации, необходимо сначала привести серверы в состояние, в котором такая настройка возможна. Вам нужна система, способная автоматически установить выбранную вами ОС (и не на одной, а на нескольких машинах). За последние годы было создано немало таких систем, и все они используют похожие методы.

Существует два основных подхода к задаче установки образов на новых машинах. Многие поставщики ОС поддерживают режим пакетной установки, в котором обычный процесс установки выполняется в неинтерактивиом режиме. Программа установки получает конфигурационный файл, в котором перечисляются устанавливаемые пакеты. В качестве примеров можно назвать Solaris Jumpstart, Red Hat Kickstart и Debian FAI.

Многие продукты независимых разработчиков используют дисковые образы. На одном компьютере готовится эталонный клиентский образ, который затем дублируется байт-в-байт на новых хостах. Нередко для всех серверов в инфраструктуре используется один образ, а хосты различаются только по набору настраиваемых и активизируемых служб. В частности, этот подход используется продуктом SystemImager.

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

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