LINUX.ORG.RU
ФорумAdmin

Репликация между серверами , как лучше ? :)


0

2

Вот есть два файловых сервера по 2 ТБ инфы, соединение между ними 1 Гбит, Задача, репликация, и тут несколько идей

Взять CentOS

1) Класика DRBD

И такой можно вариант как эксперимерт :

2) На одном с помощью ISCSI расшарить винт, подцепить к другому серверу клиентом, и объеденить в рейд mdadm по скорости примерно одинакого с DRBD по тестам.

Взять FreeBSD

3) Сделать HAST + ZFS

4)Ну или где сто статью читал что можно использовать GEOM с одного сервера отдать винт по сети , а на другом ZFS mirror , или Raid-Z, что то даже какие то плюсы такого подхода были

Так бы вообще можно было взять DRBD и не мучатся, но в моем случае интересно еще и расширение , добавление еще одного сервера хорошо выдержат варианты 2 (Raid5 5)и 4(Raid-Z) , DRBD точно нет, тк это тупое зеркало, а HAST точно не знаю, но вроде Raid подобного по сети ничего не держит.

Еще сильно у DRBD раздражает полная проверка при сбое всего пространства что достаточно долго. Вариант 4 как бы средствами файловой ситемы ZFS должен быстро делать.

Кто что думает по данному поводу ? Что делать ? :)



Последнее исправление: mag_box2 (всего исправлений: 2)

Да, и у DRBD при сбое с мастера пересинхронизируются только измененные блоки, а не всё. Если хочется именно отказоустойчивости, то DRBD + Pacemaker это самое то.

blind_oracle ★★★★★
()
Последнее исправление: blind_oracle (всего исправлений: 1)

2ТБ немного совсем. А нужна именно файловая система или просто key-value с метаданными?

Vit ★★★★★
()
Ответ на: комментарий от blind_oracle

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

mag_box2
() автор топика
Ответ на: комментарий от blind_oracle

У меня были случаи когда DRBDшные ноды «теряли» друг друга, только полная перепроверка помогала вернуть все на место

mag_box2
() автор топика
Ответ на: комментарий от Vit

в общем файловые сервера построены Samba+ winbind для интеграции с AD Windows 2008, так что файловая система нужна

mag_box2
() автор топика
Ответ на: комментарий от ipeacocks

Да ядра желательно свежие, вдруг с KVMками захочется поигратся, а там с каждой версией ядра все лучше скорость, ну и поддержка железа лучше :)

mag_box2
() автор топика
Ответ на: комментарий от mag_box2

Когда в кластере две ноды и они теряют друг друга - Split Brain гарантирован и нужно в итоге выбрать какую-то одну ноду с более актуальными данными и синхронизировать с нее на вторую. Тут другого быть не может.

А вот то, что ноды друг друга теряют, это уже проблемы админа - нормальная отказоустойчивая сеть + fencing и всё будет гуд.

blind_oracle ★★★★★
()
Ответ на: комментарий от ipeacocks

Gluster работает через FUSE, я думаю ядра там до барабана в общем и целом.

blind_oracle ★★★★★
()
Ответ на: комментарий от dbzer0

Для примера - каждая первая железка для SAN и дедупликации у IBM как раз использует GFS.

dbzer0
()
Ответ на: комментарий от blind_oracle

А вот то, что ноды друг друга теряют, это уже проблемы админа - нормальная отказоустойчивая сеть + fencing и всё будет гуд.

Тоже самое хотел сказать. Два года эксплуатации DRBD ни одного split-brain.

petav ★★★★★
()
Ответ на: комментарий от petav

Ну как бы да, DRBD сам в праймари режим перейти то не может, чтобы словить разрыв мозга нужно чтобы менджеры кластера на обоих нодах его в праймари произвели :) А уж менеджеров можно для отказоустойчивости хоть через ком-порты соеденить - даже если ВСЕ линки лягут, менеджеры друг друга увидят.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

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

С com-портами Вас поддерживаю.

petav ★★★★★
()
Ответ на: комментарий от dbzer0

ну я просто о том, что в центосах ядра древнючие.

ipeacocks ★★★★★
()

что будет со второй стороны - DR, хот фейловер, балансировка чтений, или балансировка вего ИО?

val-amart ★★★★★
()
Ответ на: комментарий от ugoday

у меня был как то вариант, два узла с DRBD , а в другой офис по узкому 2 Мегабитнику зеркалировалось раз в сутки через Rsync , все отлично работало.

mag_box2
() автор топика
Ответ на: комментарий от frozenexordium

Про Гластер я уже отвечал, не стабилен

mag_box2
() автор топика
Ответ на: комментарий от petav

Ну хорошо когда так, а менеджер ресурсов обычный Hearbet был? Тогда понятно можно и COM порт завязать, но у меня Bonding используется , 2 сетевые между узлами, 2 сетевые на внешку на обоих узлах, вроде проблем быть не должно, но как то случалось пару раз за год что ноды бах и обе в слейве , или бах DRBD который мастер показывает что слейва то и нету вовсе, и влогах вроде все нормально, что не понравилось фиг разберешь

mag_box2
() автор топика
Ответ на: комментарий от blind_oracle

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

mag_box2
() автор топика
Ответ на: комментарий от mag_box2

Через ком порт можно завязать любой менеджер. Поднимаешь по PPP канал через него и вуаля тебе айпи связность.

Если у тебя ТРИ канала - COM порт, кроссовер линк между серверами и внешний линк через свитчи между серверами (оба в бондинге), и по всем идёт hearbeat, то шанс того, что у тебя обе ноды будут живы и не увидят друг друга сильно меньше шанса того, что в твою серверную долбанёт метеорит.

blind_oracle ★★★★★
()
Ответ на: комментарий от mag_box2

Фенсинг в наше время реализуется вполне бюджетно: 1. Использовать IPMI-over-LAN и просто гасить второй ноде питание. В любой современной материнке даже от супермикро IPMI имеет место быть, через выделенный сетевой порт (без IPMI мать вообще смысла брать нет, экономия копеечная).

2. Если мать без IPMI (а это уже двойка админу), то можно заюзать какой-нибудь PDU с управлением, эффект тот же.

3. Еще можно гасить второй ноде порты на свиче через SNMP. Тоже достаточно действенно, но питание лучше.

В общем, как видишь, вариантов куча и совсем недорогих.

blind_oracle ★★★★★
()
Ответ на: комментарий от mag_box2

В документации написано что ethernet нельзя использовать в production, та же документация рекомендует сom порты. Не смогу документацию процитировать.

petav ★★★★★
()
Ответ на: комментарий от mag_box2

а какие требования к RPO и RTO?

и какой линк между серверами - есть шанс что он может не пережевать синхронно ваши обьемы записи? если есть, то лучше асинхронную репликацию.

на самом деле, если это не БД с большим кол-вом конкурентных записей, то может оказаться что асинхронной репликации снапшотами достаточно - а это куда надежнее чем дрбд. zfs send | zfs recieve или rsync или что там у вас есть.

и даже для БД так можно, переводишь базу в хотбекап режим, берешь снапшот, выводишь ее назад в нормальный режим и отправляешь снапшоп на r2.

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.