хорошие решения по отказоустойчивости/высокой доступности для Linux?

хорошие решения по отказоустойчивости/высокой доступности для Linux?

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

На Solaris мы делаем это с помощью VCS (Veritas Cluster Server). Какие варианты доступны для Linux?

Пожалуйста, укажите уровень усилий по настройке/обслуживанию или стоимость (если таковая имеется) для каждого варианта.

-- Добавлены дополнительные сведения --

Чтобы дать представление об уровне сложности:

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

Это узел сбора данных или вычислений, а не база данных, поэтому могут подойти более простые решения.

-- еще больше подробностей (извините) --

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

Большое спасибо за все ваши посты.

решение1

http://linux-ha.org/для всех ваших потребностей в высокой доступности. Как поется в песне, лучшие вещи в жизни бесплатны.

решение2

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

Veritas Cluster Server (VCS). Прошло некоторое время, но мы развернули несколько кластеров Linux VCS на RHEL 3.0. Я надеюсь, что это доступно на RHEL 5.0. Вы должны быть знакомы со сложностью настройки, поскольку это знакомая территория. Как вы, возможно, знаете, VCS стоит дорого. По слухам, VCS не очень хорошо подходит для настройки с помощью управления конфигурацией.

Говоря о RHEL, Red Hat Cluster Suite значительно усовершенствовался с момента своего первоначального выпуска в RHEL 2.1. Фаза настройки/конфигурации довольно проста, а документация очень полная и полезная, и, как и VCS, вы можете приобрести поддержку у поставщика. Для коммерческих продуктов HA RHCS имеет разумную цену. Я бы использовал управление конфигурацией только для установки пакетов и поддерживал их «вручную» через веб-интерфейс. Кроме того, я слышал, что некоторые люди используют его на платформах, отличных от Red Hat, хотя у меня нет опыта работы с этим напрямую.

Linux-HA (drbd/heartbeat) тоже хороши, хотя, исходя из VCS, конфигурация может показаться упрощенной, но при этом громоздкой. Это довольно легко автоматизировать с помощью инструмента управления конфигурацией.

В качестве доказательства концепции я установил кластер Linux с IBM HACMP — их ПО для кластеризации AIX. Я бы не рекомендовал это, поскольку, насколько я помню, это дороже, чем даже VCS. У IBM есть специальные процедуры для установки и обслуживания HACMP, я бы не стал использовать здесь управление конфигурацией.

решение3

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

На самом деле, все это есть, просто это невозможно понять. Что вам действительно нужно, так это электронная книга "Объяснение конфигурации кардиостимулятора"... (Ссылка на PDF-файл). Вам нужно будет прочитать его около дюжины раз, а затем попытаться применить его на практике, а затем прочитать его еще дюжину раз, чтобы вы действительно смогли его усвоить.

На данный момент лучшей поддерживаемой реализацией кластерных сервисов для Linux, вероятно, будет Novell SLES11 и его High Availability Extension (HAE). Он ТОЛЬКО что вышел месяц или два назад и поставляется с хорошим толстым руководством на 200 страниц, в котором описывается, как его настроить и запустить. Novell также отлично поддерживает конфигурации Pacemaker в различных формах.

Кроме того, есть реализация RHEL5, которая имеет тот же пакет и приличную документацию, но я думаю, что она дороже, чем SLES. По крайней мере, для нас.

Я бы сейчас избегал Heartbeat и выбрал Pacekmaker/OpenAIS, потому что они будут гораздо лучше поддерживаться в будущем. ОДНАКО, текущее состояние сообщества таково, что есть несколько экспертов, есть несколько людей, которые запускают его в производстве, и есть целая куча людей, которые совершенно ничего не понимают. Подпишитесь на рассылку Pacemaker и обратите внимание на человека по имени Эндрю Бикхоф.

Отредактируйте, чтобы предоставить запрошенные данные:

Pacemaker/OpenAIS использует операцию «монитор» на «примитивном ресурсе» (например, nfs-сервере) для отслеживания того, что делает ресурс. Если сервер NFS не отвечает на остальную часть кластера в течение X секунд, кластер выполнит операцию STONITH (Shoot The Other Node In The Head), чтобы отключить основной узел, переводя вторичный узел в активный. Вы решаете в конфигурации, что выводить на экран после этого и какие действия выполнять. Детали реализации зависят от того, какую службу вы пытаетесь сделать отказоустойчивой, окна выполнения для определенных операций (например, перевод основного узла обратно в главный), и все это в значительной степени настраивается настолько, насколько это возможно.

решение4

В Linux мы реализовали кластеризацию с heartbeat и drbd. Heartbeat проверяет состояние сервера. DRBD используется для синхронизации данных между серверами. У нас есть служба Oracle, запущенная на одном сервере, и Apache на другом сервере. Когда сервер, на котором работает Oracle, выходит из строя, Heartbeat чувствует это и восстанавливает службу Oracle на сервере, на котором работает Apache. и наоборот. Я использовал эту настройку для многих других целей, и она была надежной до сих пор.

Связанный контент