Система КВГ (кластер высокой готовности)

Да кстати, надеюсь понятно, что железные раиды и прочее это не реально в моем случае =( денег не дадут. И весь софт опен сорс должен быть.

> "сервера ну ооочень высокой важности"

если начальству такое нужно, то пусть не жмотятся. на low-end железе что-то более-менее надежное сделать очень геморно.

А если все же говорить про софтовую реализацию?

хз, я таким не занимался...

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

При наличии фиксированного master'а для любой операции говорить о КВГ не приходится. Сбой master-машинки приводит к неработоспособности системы.

master всегд должен быть! Так сказать основной. Смысл о том, что всегда есть slave который в случае чего спасет ситуацию. А как только master оклемается, так обратно заберет все обязанности на себя.

>master всегд должен быть! Так сказать основной. Смысл о том, что всегда есть slave который в случае чего спасет ситуацию.

накуй, ha-кластеры строятся на равноценных составляющих, желательно с load-balancing, но это уже по ситуации...

а запендюрить единственную нормальную машину обсасывать ВСЕ и двух полудохлых падаванов на подхвате - это ламерство, при нормальной нагрузке вся система захлебнеца

с твоим подходом не избежать single point of failure, ha кластеры должны иметь полное дублирование как минимум (например дисковой подсистемы), а значит ключевое слово тут - симметрия

вот тебе минимальная архитектура настоящего ha-cluster http://en.wikipedia.org/wiki/Image:2nodeHAcluster.png

Ты хоть http://linux-ha.org/ посети.

Эх, посмотришь на некоторых из Вас... называется ради красного словца! А сами *ля не раз и не пробовали! Посетить линух-ха? Это ты сейчас нашел в гугле? Молодец, я нашел это ещё 1.5 года назад. И посещал! Доволен?

Короче пустословов прошу не разводить здесь туфтологию. Со всеми остальными могу продолжить дискуссировать.

> вот тебе минимальная архитектура настоящего ha-cluster http://en.wikipedia.org/wiki/Image:2nodeHAcluster.png

это тебе минимальная архитектура.

> А сами *ля не раз и не пробовали!

Я и не говорил, что пробовал.

> Это ты сейчас нашел в гугле? Молодец, я нашел это ещё 1.5 года назад. И посещал! Доволен?

Нет. Результатов не видно.

> Heartbeat & drdb?

Вообще-то, DRBD. Это по сути, RAID1 по сети, следовательно, отпадает необходимость в дополнительной репликации MySQL. То есть, если в основном, изменяться будут данные в базе, то можно просто настроить HA/LB репликацию MySQL, а остальные данные копировать с master-ноды rsync'ом по мере необходимости.

Вот тебе список HOWTO по настройке различных решений: http://www.howtoforge.com/howtos/high-availability

>Серверную машину сделать master'ом, на которой будет крутиться проект. Из демонов будут подняты apache (с поддержкой ПХП) и мускул. Которая собственно должна работать, но в ситуации если вдруг она по каким то причинам накроеться должна подняться вторая машина (без моего вмешательства). А это значит, что между серверами все данные от мускула до файла (заданного мной) должны реплицироваться постоянно. Что бы даже 2-х секундного разрыва между ними не было. Третью тачку собираюсь использовать как управляющий сервер для мускульной репликации.

ты лох.
потому что:
1. запускаешь мускуль и апач на одной тачке
2. надеешься на синхронную репликацию на разных по мощностям тачках (подумай что будет при высокой нагрузке)

DRBD тут совсем не в тему - лучше iscsi забахать

> ты лох. пмс?

> 1. запускаешь мускуль и апач на одной тачке и че?

> 2. надеешься на синхронную репликацию на разных по мощностям тачках (подумай что будет при высокой нагрузке) подумал. И пришел к выводу, что с учетом нынешней загрузки всё будет чики-пуки.

Теперь лох ты?