Управление приложением на нескольких серверах или PXE против cfEngine/Chef/Puppet
У нас есть приложение, которое работает на нескольких (5 или около того и будет расти) коробках. Аппаратное обеспечение идентично на всех машинах, и в идеале программное обеспечение также должно быть. Я управлял ими вручную до сих пор и больше не хочу (статические IP-адреса, отключение всех необходимых служб, установка необходимых пакетов...) . Может кто-нибудь уравновесить плюсы и минусы следующих вариантов, или предложить что-то более умное?
1: Индивидуально установите centos на все коробки и управляйте конфигами с помощью chef/cfengine/puppet. Это было бы хорошо, так как я хотел найти оправдание, чтобы научиться использовать одно из приложений, но я не знаю, действительно ли это лучшее решение.
2: Сделайте одну коробку прекрасной и изобразите это. Служите образу по PXE, и всякий раз, когда я хочу внести изменения, я могу просто перезагрузить коробки из нового образа. Как кластерные парни обычно обрабатывают такие вещи, как наличие mac-адресов в файлах /etc/sysconfig/network-scripts/ifcfg*? Мы также используем Infiniband, и он также отказывается запускаться, если hwaddr не прав. Могут ли они быть правильно сгенерированы при загрузке?
Я склоняюсь к решению PXE, но я думаю, что мониторинг с munin или nagios будет немного сложнее с этим. Кто-нибудь имеет опыт работы с этим типом проблемы?
Все серверы имеют твердотельные накопители, они быстрые и мощные.
Спасибо, Мэтт.
4 ответа
Ваш кластер больше похож на кластер HPC, чем на OLTP, как мой, но я думаю, что настройка, которую я использую, будет работать и для вас. Я называю это "mpdehaan trifecta", потому что это идиот от парня, который написал или управляет тремя задействованными инструментами.
1.) Cobbler для обеспечения базовой сборки. Cobbler - это проект, целью которого является пересечение ваших систем кикстарта, pxe, yum-repo, dhcp, dns и т. Д. На сегодняшний день это самый простой способ настроить и запустить кикстарт, и вы можете использовать другие функции по мере необходимости.
2.) Кукольный для управления конфигурацией. В идеале ваши собранные в сапожнике хосты - это очень простые конфиги, которые знают достаточно, чтобы позвонить домой на ваш кукольный сервер при запуске. Затем 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, чтобы связать все вместе с помощью простого, но эффективного веб-интерфейса.
Общая теория:
- Выполняйте все установки из одного унифицированного минималистичного файла KickStart (хорошо, хорошо, один для x86 и один для x86-64, но все же, практически идентичные файлы с минимальным выбором пакетов).
- KickStat скрипт после установки загрузит Puppet.
- 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 для управления процессом загрузки.
Если бы я знал больше о том, что вы на самом деле пытаетесь объединить, я мог бы подумать о решении, которое больше подходило бы вам.