ha-claster
 

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

не claster, а клустер.

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

Уже полтора года работает шлюз из двух машин, в основе keepalived + conntrack-tools. Первый пакет реализует схему active-backup (по факту это перекидывание виртуальных адресов между интерфейсами + управление скриптовой начинкой), второй синхронизацию состояния трассировщика соединений. Переключение шустрое.

ну вот, уже предметно
3-ужос > теперь так, допустим на мастере шлепнулся отдельный /dev/sdb под spool squid'а, что на общий функционал шлюза не влияет, тогда что?

тогда /dev/md0
))

keepalived + conntrack-tools
а тут squid применим?

krotov, сторожа не будет, вопрос уже решенный
ужос, за keepalived спасибо
пробовать буду все, времени у меня много

[em]а тут squid применим?[/em]
если это правда "High Availability monitor built upon LVS, VRRP and [u]service pollers[/u]" то вполне

под линукс решений куча.
Если нужно просто HA-кластер, в котором вторая нода будет активироваться при падении первой (без синхронизации данных) - то keepalived наверное самое простое.
Если нужно синхронизировать данные на дисках (в режиме мастер-слейв или мастер-мастер) то оптимальным будет heartbeat + drbd
года 3...4 назад все это позволяло переключаться между нодами менее чем за секунду, при том, что передача файла по фтп-серверу (или на самба-шару) не прерывалась, при падении одной из нод.
Щас софт причесали (я еще на бете собирал), думаю все еще красивее.

3
Винты в зеркале, ну и кэш на сквиде отключен за ненадобностью.

6
На самом роутере нет сквида, он на отдельной виртуалке живет. Исторически так сложилось.

Еще упражнялся с corosync + pacemaker.

пока собственноручно не добрался, еще поспрашиваю
в варианте с drbd непонятен момент уникальных аппаратных конфигов, таких как fstab, ifcfg-*, итд, поскольку репликация блочная, исключений на уровне fs быть не может, как подобные нюансы обходятся?

8-burn > при том, что передача файла по фтп-серверу (или на самба-шару) не прерывалась, при падении одной из нод.

а можно поподробнее? мне не совсем понятно, как соединение не прерывается, если сведения о соединении, буферы и пр. осталось (вернее было) в памяти упавшей ноды.

10-gloomymen > в варианте с drbd непонятен момент уникальных аппаратных конфигов, таких как fstab, ifcfg-*, итд, поскольку репликация блочная, исключений на уровне fs быть не может, как подобные нюансы обходятся?

если я правильно понял, ты имеешь в виду что в зеркало по сети входят все ФС (включая корень и /etc), а обычно внутри DRBD хранятся какие-то отдельные разделы, это типа как NAS, только не на отдельной машине.

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

[em]мне не совсем понятно, как соединение не прерывается, если сведения о соединении, буферы и пр. осталось (вернее было) в памяти упавшей ноды.[/em]
conntrackd этим умеет заниматься, conntrack-tools для 6 собирает пока только CentALT

[em]это типа как NAS, только не на отдельной машине[/em]
drbd это разве не iSCSI?

[quote=lithium;24544425] 8-burn > при том, что передача файла по фтп-серверу (или на самба-шару) не прерывалась, при падении одной из нод. а можно поподробнее? мне не совсем понятно, как соединение не прерывается, если сведения о соединении, буферы и пр. осталось (вернее было) в памяти упавшей ноды.
[/quote]
Ничего точно по поводу буферов не скажу, но на стенде (и затем на многих кластерах по краю) это все работало:
2 ноды, мастер-слейв, общий IP через хеатбит, один раздел с данными синхронизируется через дрбд.
При падении одной ноды (тестировал потерю питания, потерю сети) файл продолжал копироваться на самба-шару (которая на дрбд): естественно было некое замирание со стороны передачи, но через секунду система продолжала копирование и при проверке файл был цел. Каков был при этом алгоритм работы буферов - не знаю, но результату радовался как маленький котенок :)

13-gloomymen >
15-burn >

я тогда уточню: кластер был маршрутизатором или samba/ftp-сервером?

16-lithium >в моем случае был самба/ftp-сервер.

а про то что передача файлов не прерывалась -- это субъективные ощущения, или отслеживалось что коннект не рвался?

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

тут, как мне кажется, есть один момент по поводу SMB -- если это работа какой-нибудь 1С с забирание части данных себе и использованием блокировок, то если просто убить один процесс и запустить другой, это может быть не совсем нормально с точки зрения клиента.

20-lithium >
вполне возможно.
Но у нас стояла задача создать узлы гарантированной доставки тарификационных файлов с атс в "центр" для дальнейшей обработки.
И файлы кластер получал по smb или ftp, а передавал по scp.
Кстати основной проблемой на всех 800 кластерах, что были в продакшене, был выход из строя жестких дисков. Но эти проблемы решались без шума, пыли и истерик, пока система работала на второй ноде - первую выключали, меняли диск, включали, заливали ОС из образа и после ребута все само синхронизировалось и срабатывал файловер на первую ноду.