2-узловой кластер HA: DRBD или CEPH?, Proxmox Виртуальная Среда
Dexter23
Guest
0
12.01.2022 11:56:00
Привет, ребята, хочу сделать двухузловой кластер с высокой доступностью и третью машину для Qdevice. Подскажите, что в этом случае лучше использовать — DRBD или CEPH? Конфигурация серверов может быть такой: Сервер А: SSD 120 ГБ (Proxmox), 2 HDD по 1 ТБ в RAID 1 (хранилище для виртуальных машин). Спасибо!
fr1000
Guest
0
26.07.2024 20:56:00
Привет, я в точно (!) такой же ситуации. Нашёл ли ты надёжное решение? Заранее спасибо!
hellfire
Guest
0
26.07.2024 23:36:00
Некоторый опыт по темам, обсуждаемым здесь:
a) DRBD / LinStor Лично я некоторое время работал с DRBD на двух кластерах. Содержать его в актуальном состоянии оказалось довольно хлопотно, так как он не интегрирован напрямую в Proxmox VE. Опыт такой — DRBD время от времени терял синхронизацию, и мне приходилось исправлять это вручную. Я даже писал собственные скрипты для интеграции на одном из кластеров, но они не всегда работали хорошо (думаю, причина была в моих скриптах и настройках). DRBD к тому же довольно сложен, особенно новая архитектура LinStor. И еще: DRBD медленный, потому что пишет данные синхронно по сети. Это связано с тем, что DRBD должен работать в режиме Dual-Primary, что здесь является строгим требованием, а в этом режиме протокол синхронизации C (полностью синхронные записи) — единственный вариант. Но! Это гарантирует репликацию данных в реальном времени. Думаю, LinStor работает лучше, чем старый DRBD. Но для меня управление кластерами Proxmox VE порой было довольно напряжённым. Если вам действительно нужны синхронизированные данные в реальном времени на двухузловом кластере и есть только сеть 1 Gbe, LinStor — вполне рабочий вариант. Вот короткое руководство: Вероятно, вам придется внимательно изучить всю документацию.
b) Ceph Что касается Ceph, я управляю двумя кластерами по 3 узла каждый. Первый кластер с 9 SATA-SSD-OSD, второй — с 6 NVMe-SSD-OSD (не идеально, но на момент создания кластера оптимальные SSD были недоступны). Оба работают безупречно. Я гораздо больше доволен Ceph, чем DRBD. Были небольшие проблемы при апгрейде Ceph, но тут нужно внимательно читать подробные руководства по обновлению Proxmox. Если у вас есть (или вы можете позволить себе) хотя бы три узла и сеть минимум 10 Gbe — выбирайте Ceph!
c) Репликация хранилища с ZFS Недавно настроил кластер с репликацией хранилища ZFS. По сравнению с двумя предыдущими вариантами — это просто песня. Мне это очень нравится. Так как у меня есть довольно важный сервер с базой данных Postgres, я добавил сервер-резерв в режиме реального времени, чтобы всегда иметь свежие данные. Поскольку высокая доступность не требуется, оставлю всё как есть. Если синхронизация в реальном времени не нужна — репликация хранилища будет отличным решением.
---- GlusterFS — еще один вариант. Я игрался с ним 5-10 лет назад, но тогда не смог привести его в рабочее состояние, приемлемое для эксплуатации.
LnxBil
Guest
0
27.07.2024 11:35:00
Единственное надёжное и неприхотливое решение — это НЕ использовать «двухузловой кластер», а брать минимум три (или больше, но обязательно нечётное количество) узлов с нормальным общим хранилищем для настоящего HA-кластера. Этого нельзя недооценивать. Если бы всё было так просто, об этом бы писали в официальной документации. Извиняюсь за предстоящую тираду, но это нужно сказать... Ребята, перестаньте спрашивать об этом хотя бы раз в месяц, просто поверьте тем, кто этим занимается уже много лет, если не десятилетий. Об этом постоянно пишут на форумах и в RTFM, где это уже чётко объяснено. Здорово, что у VMware и других это работает, но PVE (и CEPH) требуют как минимум 3 узла — это нижний порог. Просто примите это. Я тоже раньше использовал двухузловой DRBD-кластер, и он работал, но, как уже говорили другие, иногда требовал вмешательства. Работал, да, но работы по сравнению с нынешними полноценными PVE-кластерами было гораздо, гораздо больше. Сейчас это как у Apple — всё просто работает, если сделать правильно, следуя документации.
esi_y
Guest
0
29.07.2024 11:21:00
Думаю, нет ничего плохого в том, чтобы добавить что-то в уже существующую тему, даже спустя время. В форуме полно странных вопросов (которые, кстати, могли бы и на какой-нибудь hardware reddit уйти), и никого это не раздражает. Не могу говорить за автора поста, но обычно на таком форуме, когда кто-то говорит мне «не делай так», мне всё равно интересно узнать «а почему».
Mad_Hat
Guest
0
24.02.2026 17:39:00
Я использую DRBD с 2017 года, начиная с двух узлов для данных и третьего «пустышечного» узла для кворума. DRBD 8 было не так просто освоить, тем более что я тогда ещё почти не разбирался в Linux/Debian. Он достаточно хорошо работал для пары RDP-серверов и NAS, которые я на нём держал, но я не пробовал нагрузки вроде базы данных с высокими требованиями к производительности. Возможность «на лету» мигрировать работающую виртуальную машину — всего за время синхронизации оперативной памяти между узлами — просто потрясает. Всегда запускал DRBD по 10 Гбит через изолированный или оффлайн-коммутатор, а сейчас DRBD работает на пяти узлах с управлением через LINSTOR. LINSTOR — это «новый» инструмент управления, и он намного лучше и надежнее тех времён, когда приходилось править конфиги вручную на каждом узле. Конечно, к нему всё равно нужно привыкнуть — разобраться с Resource Definitions, Storage Pools, Volume Definitions, Volume Groups и многим другим, если хочешь довести его до максимальной производительности. Потери данных из-за проблем с DRBD у меня не было, хотя пару раз ошибки стоили бессонных ночей и кучи нервов на поиск и устранение неполадок. Данные реплицируются в реальном времени, но у меня не настроен HA или автоматический фейловер, потому что я предпочитаю вмешиваться вручную, если что-то идёт не так, и круглосуточная безостановочная работа для меня вовсе не критична. При этом я бы ни за что не стал работать с меньшим, чем 3 узла, хотя технически это возможно и с двумя.
