Эмм.. даже не знаю что сказать.
Кластер для чего? Или кластер чего?
И вообще, скажите уж, что вы подразумеваете под словом «кластер»?

man pacemaker/corosync

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

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

Зависит от задач. Я как раз на debian сделал 3 кластера для виртуалок на kvm. Бегает и прыгает на heartbeat/drbd.

А без задач нельзя? Ну, допустим задача - хостинг.

А без задач нельзя? Ну, допустим задача - хостинг.

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

Без правильно заданного вопроса - ты не получишь нужного тебе ответа.

HA Кластер на уровне виртуальных машин [В общих чертах][Общим языком]

I. Варианты организации системы хранения данных

DRBD репликация блочных устройств. Кластер высокой доступности с использование сетевой репликации блочных устройств на основе DRBD технологии. Данный метод позволяет в реальном масштабе времени синхронизировать жесткие диски компьютера. В результате чего в любой момент времени имеется полная копия данных на вторичной машине. Выключив первичную машину сможем, без лишних движений, начать работу на вторичной машине, с места разъединения. Данная технология накладывает ограничения на кол-во узлов кластера. Кол-во узлов не может быть более 2-х. При не верном конфигурировании и обслуживании возможны ситуации splitbrain (расщепления сознания). Ситуация проявляется когда оба узла считают себя главными. Данную ситуации необходимо разрешать исходя из конкретно сложившихся условий расщепления.

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

II. Автоматизация управления ресурсами кластера

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

III. Автоматизация failover

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

Величины непрерывности В следствии failover, когда несущий узел прекращает функционирование, простой в работе определяется формулой:

Простой =  <определение_проблемы> + 
<загрузка_виртуальной_машины_на_резервном_узле>. 

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

Простой = <временя_переноса_оперативной_памяти>

Ууух...как все сложно... я надеялся получить подобие рейд1 но из серверов, а не из двух винтов...

Без потерь данных и задержек.

Тогда ВАМ кластер на уровне аппликаций нужно строить. А как конкретно зависит от аппликаций. Аппликация - это приложение. Только так без «задержек».

Ууух...как все сложно... я надеялся получить подобие рейд1 но из серверов, а не из двух винтов...

То есть тебе важно реплецировать только данные, без процессов и прочего? Ты понимаешь, что рейд1 это тупо блочные данные? При этом ядро там почти никаким боком?
А в случае того же хостинга у тебя есть, как минимум: 1) база данных 2) файлы сайта/ов 3) сетевые соединения (трафик).
То есть у тебя тогда придеться реплицировать аж 3 типа данных. Поэтому я и спрашиваю подробно, чтобы указать тебе на соответсвующий гайд.

Организация общего хранилища это только часть задачи.

Если на лету все так сложно -то я готов на а-ля рейд1. Но хотелось вот чего - работают два сервера в этом типа рейде... один из них нечаянно распадается на атомы, я беру другой, абсолютно чистый сервер, запускаю на нем дебиан, пишу sync(это я образно). И через некоторое время они так-же как и прежде весело и синхронно шуршат... можно и с остановкой, но чтоб это было как можно быстрее и проще

Если на лету все так сложно -то я готов на а-ля рейд1. Но хотелось вот чего - работают два сервера в этом типа рейде... один из них нечаянно распадается на атомы, я беру другой, абсолютно чистый сервер, запускаю на нем дебиан, пишу sync(это я образно). И через некоторое время они так-же как и прежде весело и синхронно шуршат... можно и с остановкой, но чтоб это было как можно быстрее и проще

Ты меня специально невнимательно читаешь? :) Еще раз: все зависит от списка софта, который на сервере у тебя. Перечисли его и тебе дадут рецепт.

https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial

Организация общего хранилища это только часть задачи.

Да не усложняй, ему намного проще сетап нужен.

тогда proxmox?

В этом и вопрос...будет хостинг сайтов со всем вытекающим под управлением ispmanager... а что еще будет не имею понятия... апач мускл пхп - это точно.

В этом и вопрос...будет хостинг сайтов со всем вытекающим под управлением ispmanager... а что еще будет не имею понятия... апач мускл пхп - это точно.

Если не имеешь понятия, то найми себе админа для решения подобных вопросов.

Зеркальный рейд из нескольких СХД.
Для данного метода необходимо, помимо двух узлов кластера, наличие двух СХД.

обычно можно одной СХД обойтись

К чему приведет выход из строя единственного СХД?

К чему приведет выход из строя единственного СХД?

нормальные СХД не имеют единой точки отказа(single point of failure), СХД это тот же кластер, ничто не вечно, но disaster recovery site никто не отменял.

А без задач нельзя? Ну, допустим задача - хостинг.

Без задач нельзя, без задач будет каша в голове, а не кластер. Хостинг - это без подробностей сервер, база данных и php скрипты. В самом простом варианте у тебя будет два сервера мастер, который обслуживает запросы и второй в горячем резерве. Если мастер падает резерв должен поднять на себе IP адрес мастера, поднять вебсервер, апача к примеру, и начать обслуживать клиентов. Софт для этой задачи называется pacemaker. http://www.linux-ha.org/wiki/Main_Page сайт тебе в помощь.

Но физическое резервирование сервера это еще не все. Тебе надо добиться того, чтобы резервный сервер был полной копией мастера, для этого надо решить еще две задачи: репликация базы данных и синхронизация php скриптов и прочей статики сайтов. Для БД я брал связку MariaDB + Galera Cluster, работает как часы.

Ну а файлы можно по разному начиная от скрипта rsync в кроне, до зеркалирования блочных устройств по сети (это drdb) и кластерных файловых систем (GlusterFS, к примеру)

red hat cluster suite

Openstack

Зависит от задач.

Парни, может ли кто-то прокомментировать что можно/нужно сделать при более детальном описании.

Имеется территориально разделенная пара, то есть сервер с виртуалками + сторадж с одной и с другой стороны. Виртуалки хранятся локально на сервере, а все данные (аплоад) хранятся на подмаунченом сторадже. Одна виртуалка допустим веб-приложение, которая аплоад хранит на НФС, а в качестве майскл использует вторую виртуалку.

Точно так же все выглядит и с другой стороны.

Пусть я раз в день синхронизирую второй сторадж с первым и точно так же второй майскл с первым.

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

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

По-поводу майскл не совсем ясно. Следует ли использовать нативные схемы мастер-мастер или мастер-слейв или какие-то сторонние методы/приложения?

С переводом клиентов на другой ИП тоже не ясно как быть.

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

Openstack

Казалось бы, причем тут он? Каким образом там ha обеспечивается, расскажешь?

Ключевые слова: drbd для nas (можешь в ocfs2, хоть ты этот вопрос и уже решил) , mysql => mariadb galera cluster (как тут советовали уже раньше), к всему этому corosync/pacemaker (которые будут рулить живостью нод), а трафик (читай айпи) - рулишь очень просто - rr в днс. Либо тупо суешь сразу два ip в А запись. В таком случае, у тебя если ляжет один - браузер пойдет на второй. (все браузеры на данный момент пробуют айпишки по очереди, в случае, если их в А записи много, а первая попавшаяся недоступна).

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

В таком случае куда логичнее было бы прикрутить vrrp + heartbeat, а остальное синхать чем угодно (тот же drbd и mariadb galera выше).

Либо можешь, как я писал в начале. Весь хостинг унести в виртуалку (допустим в lvm), а её в drbd сунуть. И heartbeat пусть включает её на второй ноде, в случае недоступности первой.