У нас есть приложение, которое работает на нескольких (5 или около того и будет расти) коробках. Аппаратное обеспечение одинаково на всех машинах, и в идеале программное обеспечение должно быть таким же. Я управлял ими вручную до сих пор и больше не хочу (статические IP-адреса, отключение всех необходимых служб, установка необходимых пакетов ...). Может ли кто-нибудь сбалансировать плюсы и минусы следующих вариантов или предложить что-то более умное?

1: индивидуально установите centos на все коробки и управляйте конфигами с помощью chef / cfengine / puppet. Это было бы хорошо, так как я хотел найти оправдание, чтобы научиться использовать одно из приложений, но я не знаю, действительно ли это лучшее решение.

2: Сделайте одну коробку прекрасной и изобразите это. Служите образу по PXE, и всякий раз, когда я хочу внести изменения, я могу просто перезагрузить коробки из нового образа. Как кластерные парни обычно обрабатывают такие вещи, как наличие mac-адресов в файлах / etc / sysconfig / network-scripts / ifcfg *? Мы также используем Infiniband, и он также отказывается запускаться, если hwaddr не прав. Могут ли они быть правильно сгенерированы при загрузке?

Я склоняюсь к решению PXE, но я думаю, что мониторинг с munin или nagios будет немного сложнее с этим. Кто-нибудь имеет опыт работы с этим типом проблемы?

Все серверы имеют твердотельные накопители, они быстрые и мощные.

Спасибо, Мэтт.

Ваш кластер больше похож на кластер HPC, чем на OLTP, как мой, но я думаю, что настройка, которую я использую, будет работать и для вас. Я называю это «mpdehaan trifecta», потому что это идиот от парня, который написал или управляет тремя задействованными инструментами.

1.) Cobbler для обеспечения базовой сборки. Cobbler - это проект, целью которого является пересечение ваших систем кикстарта, pxe, yum-repo, dhcp, dns и т. Д. Это, безусловно, самый простой способ настроить и запустить кикстарт, и вы можете использовать другие функции по мере необходимости.

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

3.) Функция для специальных команд для нескольких машин параллельно. Например, «разверните новую svn проверку кода и перезапустите apache». Довольно просто использовать func для вызова одной и той же команды bash на группе серверов, очень похожих на cluster-ssh. Если вы действительно хотите войти в него, вы можете написать свои собственные модули для него с некоторым действительно простым Python.

Все три из этих инструментов имеют хорошие вики-каналы и активные IRC-каналы для помощи по freenode.

обзор

В некотором смысле, у вас есть два вопроса здесь ..

• Как мне построить и поддерживать стандартные серверы?
• Как сохранить стандартную конфигурацию и внести изменения позже?

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

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

Сборка серверов

Я не люблю изображения в мире UNIX; это скорее подход в стиле Windows. Кажется, что даже некоторые пользователи Windows сейчас переориентируются на сценарии для стандартных сборок.

Спутник, кажется, становится несколько популярным в мире RHEL. Spacewalk - это аналог Open Source. Вы определенно должны купить в подходе RHEL полностью, чтобы использовать это. Это служит как для построения сервера, так и для управления конфигурацией.

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

Во-первых, воспользуйтесь автоматизацией сборки дистрибутива, например Kickstart в RHEL / CentOS. Кикстарт будет основой с вариациями, в зависимости от ваших потребностей. Сборки Kickstart могут быть инициированы с PXE-сервера.

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

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

Поддержание стандартов

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

Если вы решите полагаться на системные пакеты, а не на создание собственных сборок на основе исходного кода для своих наиболее важных ролей сервера, многие из них можно будет поддерживать с помощью системных системных утилит. Это может быть простой скрипт для запуска forцикла со списком серверов и запуска yum -y update package.

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

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

Недавно я закончил большой проект по развертыванию централизованной системы управления сборкой / подготовкой и конфигурацией в $ WORK. Мы работаем с CentOS.

Мой дизайн, который мне очень нравится, дает нам процесс сборки практически одним щелчком мыши (ну, одна веб-страница с графическим интерфейсом), используя некоторые пользовательские сценарии PHP, чтобы связать все вместе с помощью простого, но эффективного веб-интерфейса.

Общая теория:

1. Все установки выполняются из одного унифицированного минималистичного файла KickStart (хорошо, хорошо, один для x86 и один для x86-64, но все же, практически идентичные файлы с минимальным выбором пакетов).
2. KickStat сценарий постинсталляции начальной загрузки Puppet.
3. Puppet применяет все специфичные для узла / хоста конфигурации, установку пакетов и т. Д.

Я согласен с тем, что образы - это не Unix-й способ сделать что-то ... они действительно больше подходят для мира Windows, где установка и настройка с помощью сценариев / автоматики не так просты.

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

Эта система дает ряд преимуществ:

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

Если вы идете по маршруту pxe, обязательно посмотрите на

http://etherboot.org/wiki/index.php

Gpxe даст вам больше гибкости с загрузочными целями. Загрузиться с Aoe Blade довольно просто, и нет ничего лучше загрузки ядра с удаленного http-сервера !!!!!!!!!! :-).

Какой период работы сервера вам нужен?

Невозможно создать идеальный образ, так как вам всегда нужно применять исправления безопасности и обновления программного обеспечения. Если они выходят в Интернет, вы не можете просто игнорировать исправления.

Что касается pxe, у вас есть несколько вариантов, в зависимости от вашего файлового ввода-вывода вашего кластера. Либо просто загрузите ядро ​​и смонтируйте диск удаленно через aoe или iscsi.

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

Я также имел успех, используя корень NFS, используя кластерное решение NFS. Вы можете указать различные файлы для обслуживания в зависимости от их клиентских адресов.

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

кластерный сервер NFS может содержать 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

Таким образом, каждый клиент ссылается на один и тот же файл, но получает файл, который имеет отношение к клиенту. Это довольно внушительные вещи, однако это не просто!

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

Если вы используете какое-либо из этих решений, убедитесь, что у вас есть хорошо спроектированный и отказоустойчивый сетевой уровень и что ваш сервер nfs / SAN хорошо спроектирован и безопасен!

Потеря соединения с вашей NFS / SAN будет вредна для здоровья сервера. :-(

Довольно просто создать несколько сценариев для tftp / pxe для управления процессом загрузки.

Если бы я знал больше о том, что вы на самом деле пытаетесь объединить, я мог бы подумать о решении, которое было бы более подходящим для вас.