| 0
- 12.04.2012 - 19:21
|
вот озадачился, буду поднимать, если есть соображения - велкам тут товарищи посоветовали гостевые системы реплицировать вроде бы должно быть все красево - состояние озу и все такое, но подспудно не лежит душа, интуиция задача: банальный шлюз на 2 внешних канала, 2 абсолютно идентичных по железу машинки, и чтобы никто ничего не заметил) это опционально     | | |
| 1
- 12.04.2012 - 22:15
| не claster, а клустер. | | |
| 2
- 12.04.2012 - 22:26
|
я бы поделил на две задачи. 1. Падение канала -- тут кластер не нужен, все решается в пределах узла (виртуального или нет, не важно). 2. Падение железа или сервиса обеспечивающего маршрутизацию. Тут потребуется, как миниимум, второй узел и общий стораж, без которого не обойтись из за кворум диска. Причем какое-то время на переход с одного узла на второй потребуется в любом случае, вне зависимости от того организован кластер на физических узлах или виртуальных. | | |
| 3
- 12.04.2012 - 22:52
| Уже полтора года работает шлюз из двух машин, в основе keepalived + conntrack-tools. Первый пакет реализует схему active-backup (по факту это перекидывание виртуальных адресов между интерфейсами + управление скриптовой начинкой), второй синхронизацию состояния трассировщика соединений. Переключение шустрое. | | |
| 4
- 13.04.2012 - 00:26
|
ну вот, уже предметно 3-ужос > теперь так, допустим на мастере шлепнулся отдельный /dev/sdb под spool squid'а, что на общий функционал шлюза не влияет, тогда что? | | |
| 5
- 13.04.2012 - 07:50
|
тогда /dev/md0 )) | | |
| 6
- 13.04.2012 - 07:52
|
keepalived + conntrack-tools а тут squid применим? | | |
| 7
- 13.04.2012 - 08:30
|
krotov, сторожа не будет, вопрос уже решенный ужос, за keepalived спасибо пробовать буду все, времени у меня много а тут squid применим? если это правда "High Availability monitor built upon LVS, VRRP and service pollers" то вполне | | |
| 8
- 13.04.2012 - 08:40
|
под линукс решений куча. Если нужно просто HA-кластер, в котором вторая нода будет активироваться при падении первой (без синхронизации данных) - то keepalived наверное самое простое. Если нужно синхронизировать данные на дисках (в режиме мастер-слейв или мастер-мастер) то оптимальным будет heartbeat + drbd года 3...4 назад все это позволяло переключаться между нодами менее чем за секунду, при том, что передача файла по фтп-серверу (или на самба-шару) не прерывалась, при падении одной из нод. Щас софт причесали (я еще на бете собирал), думаю все еще красивее. | | |
| 9
- 13.04.2012 - 08:54
|
3 Винты в зеркале, ну и кэш на сквиде отключен за ненадобностью. 6 На самом роутере нет сквида, он на отдельной виртуалке живет. Исторически так сложилось. Еще упражнялся с corosync + pacemaker. | | |
| 10
- 13.04.2012 - 10:08
|
пока собственноручно не добрался, еще поспрашиваю в варианте с drbd непонятен момент уникальных аппаратных конфигов, таких как fstab, ifcfg-*, итд, поскольку репликация блочная, исключений на уровне fs быть не может, как подобные нюансы обходятся? | | |
| Модератор 11
- 13.04.2012 - 10:16
|
8-burn > при том, что передача файла по фтп-серверу (или на самба-шару) не прерывалась, при падении одной из нод. а можно поподробнее? мне не совсем понятно, как соединение не прерывается, если сведения о соединении, буферы и пр. осталось (вернее было) в памяти упавшей ноды. 10-gloomymen > в варианте с drbd непонятен момент уникальных аппаратных конфигов, таких как fstab, ifcfg-*, итд, поскольку репликация блочная, исключений на уровне fs быть не может, как подобные нюансы обходятся? если я правильно понял, ты имеешь в виду что в зеркало по сети входят все ФС (включая корень и /etc), а обычно внутри DRBD хранятся какие-то отдельные разделы, это типа как NAS, только не на отдельной машине. | | |
| 12
- 13.04.2012 - 10:26
|
ты неправильно понял, я ничего не имею в виду, поскольку могу только фантазировать) навскидку я бы общие данные поместил в отдельный раздел для drbd с симлинками по месту жительства, но тут получается что ось и пакеты обновлять придется на обоих нодах | | |
| 13
- 13.04.2012 - 10:42
| мне не совсем понятно, как соединение не прерывается, если сведения о соединении, буферы и пр. осталось (вернее было) в памяти упавшей ноды. conntrackd этим умеет заниматься, conntrack-tools для 6 собирает пока только CentALT | | |
| 14
- 13.04.2012 - 10:44
| это типа как NAS, только не на отдельной машине drbd это разве не iSCSI? | | |
| 15
- 13.04.2012 - 11:57
| Цитата:
2 ноды, мастер-слейв, общий IP через хеатбит, один раздел с данными синхронизируется через дрбд. При падении одной ноды (тестировал потерю питания, потерю сети) файл продолжал копироваться на самба-шару (которая на дрбд): естественно было некое замирание со стороны передачи, но через секунду система продолжала копирование и при проверке файл был цел. Каков был при этом алгоритм работы буферов - не знаю, но результату радовался как маленький котенок :) | | |
| Модератор 16
- 13.04.2012 - 12:01
|
13-gloomymen > 15-burn > я тогда уточню: кластер был маршрутизатором или samba/ftp-сервером? | | |
| 17
- 13.04.2012 - 12:18
| 16-lithium >в моем случае был самба/ftp-сервер. | | |
| Модератор 18
- 13.04.2012 - 12:51
| а про то что передача файлов не прерывалась -- это субъективные ощущения, или отслеживалось что коннект не рвался? | | |
| 19
- 13.04.2012 - 14:54
| так как нам важно было ехать (передать файл), а не шашечки (отслеживать коннекты) - то тест был прост - копируем авишку с порнушкой на смб-шару посредством проводника виндовс и в момент передачи убиваем активную ноду. Визуально все продолжало копироваться, с небольшими лагами в момент издевательства над сервером. | | |
| Модератор 20
- 13.04.2012 - 15:52
| тут, как мне кажется, есть один момент по поводу SMB -- если это работа какой-нибудь 1С с забирание части данных себе и использованием блокировок, то если просто убить один процесс и запустить другой, это может быть не совсем нормально с точки зрения клиента. | | |
| 21
- 13.04.2012 - 17:28
|
20-lithium > вполне возможно. Но у нас стояла задача создать узлы гарантированной доставки тарификационных файлов с атс в "центр" для дальнейшей обработки. И файлы кластер получал по smb или ftp, а передавал по scp. Кстати основной проблемой на всех 800 кластерах, что были в продакшене, был выход из строя жестких дисков. Но эти проблемы решались без шума, пыли и истерик, пока система работала на второй ноде - первую выключали, меняли диск, включали, заливали ОС из образа и после ребута все само синхронизировалось и срабатывал файловер на первую ноду. | |
Интернет-форум Краснодарского края и Краснодара |
