LINUX.ORG.RU

Хранилище для HA VM кластера


0

2

В процессе экспериментов с кластером возник вопрос по поводу оптимального хранилища имиджей/данных VM. VM планируется несколько, linux ессно, большого кол-ва дисковых I/O быть не должно (виртуалки - в первую очередь для изоляции публичных ресурсов; БД на них не пользуются, да и огромных объемов файлов нет; исключение - бекапы базы/софта).

Планируется кластер на 2 ноды, возможно когда-то отрастет 3-я. Линк между нодами - 1000M патч-корд, в бондинге с вланом из линкоа на «мир» (для failover).

Итак собссно варианты видятся такие:

1) DRBD. Плюсы - вроде как логично выглядит, минусы - могут быть сложности при миграции, проблема split-brain, плохая масштабируемость;

1а) DRBD + iSCSI. Добавляются плюсы - меньше проблем при живой миграции, и минусы - оверхид (насколько критичен, если ресурс-хранилище живет на той же ноде что и виртуалки? что будет если еще одна нода появится, которая будет работать по сети?), + возможно еще что-то;

2) GlusterFS или что-то подобное. Плюсы - прозрачно. Минус - юзерлевел, т.е. если вдруг виртуалки пригрузят проц на 100% и при этом пойдет обращение к диску - весьма велик шанс, что все весело повиснет, ибо ИМХО приоритет KVM, время которого считается как время ядра, будет выше приоритета glusterfs, а виртуалки при этом будут активно кушать процессорное время, находясь в ожидании завершения дисковой операции;

3) DRBD + NFS, имиджи лежат на NFS. Плюсы - масштабируемость, более простое по сравнению с 1а) обслуживание. Минусы - большой оверхид;

4) DRBD + NFS поверх, рутовые разделы монтируются по NFS неким initrd. Плюсы - экономия места, еще более простое обслуживание (бекапы и т.д.), возможность монтировать поверх рид-онли «заготовки» с бинарниками и т.д. RW каталог с конфигами виртуалки (упрощается апдейт софта). Минусы - пока не выяснил, кроме необходимости собирать initrd свой (хотя выглядит черезчур уж красиво и просто, чтобы нормально работать), но смущает отсутствие массовых реализаций подобного.

Собссно вопрос на засыпку: кто что посоветует? Может я какой-то из вариантов упустил?

★★★★★

то все весело повиснет,

Не должно, если только 12039 не всплывёт :).

ибо ИМХО приоритет KVM, время которого считается как время ядра

ничего подобного, в user оно капает.

В любом случае теория-теорией, а проверять надо будет на стенде или вживую на сколько оно failover.

true_admin ★★★★★ ()

DRBD + iSCSI/NFS работает нормально. А вот «ресурс-хранилище живет на той же ноде что и виртуалки» уже как-то совсем не очень круто имхо.

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

Почему же? Или вы считаете, что оверхид на передачу по сети будет меньше, чем оверхид на чтение с локального раздела? Да и логичнее оно как-то - т.к. если виртуалки на одной ноде, а хранилище на другой, в момент отваливания ноды с хранилищем виртуалкам будет несколько нехорошо.

true_admin во всяком случае в top KVM идет в system время... Надо будет поэкспериментировать на досуге.

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

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

Нет, не считаю. Вопрос в том на сколько критичен этот «оверхид». А вот если одна из виртуалок нагрузит проц, просядет весь i/o кластера.

Да и логичнее оно как-то - т.к. если виртуалки на одной ноде, а хранилище на другой, в момент отваливания ноды с хранилищем виртуалкам будет несколько нехорошо.

Только несколько секунд, пока ресурсы не поднимутся на воторой ноде кластера. Потом продолжат работать. Хотя это, конечно, зависит. А вот если ляжет нода хранилища (что для ha-кластера почти что штатная ситуация и вовсе не потеря), виртуалки придётся кому-то как-то где-то поднимать заново. Грубо говоря, толку от такого кластера оказывается сильно меньше.

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

А у тебя, случайно, нет ссылки на описание такой схемы? Почему не просто DRBD?

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

А вот если одна из виртуалок нагрузит проц, просядет весь i/o кластера.

Проц 4-головый, на каждую виртуалку думаю не более 2 голов давать (имел опыт запуска 2 виртуалок на 2-головом проце - когда обе начинают кушать ресурсы, все внезапно скукоживается и начинает лагать из-за дикого оверхида на переключение контекста), потому проблем особо быть не должно. Да и i/o просядет не только для дисковых операций, но и для iSCSI скорее всего в случае чего. Или я ошибаюсь?

Сейчас к слову виртуалки на одной машине крутятся, проблем каких-либо с ними не испытываю. Хотя, ессно, монтируется все не по iSCSI, а напрямую с файлов-образов.

Только несколько секунд, пока ресурсы не поднимутся на воторой ноде кластера. Потом продолжат работать. Хотя это, конечно, зависит. А вот если ляжет нода хранилища (что для ha-кластера почти что штатная ситуация и вовсе не потеря), виртуалки придётся кому-то как-то где-то поднимать заново. Грубо говоря, толку от такого кластера оказывается сильно меньше.

DRBD+iSCSI мастер что, увеличивает вероятность падения ноды? Если нет - то тогда какбы мастер хранилища имеет смысл делать там же, где и виртуалки... Ведь в таком случае если падает 2-я нода - на 1й никаких неудобств нет, а если падает 1-я - то на 2й в любом случае виртуалки придется поднимать...

Если же смущает то, что нода будет бездельничать - то собссно 2-я нода простаивать не будет, на ней будет крутиться БД, а также кое-какие критичные сервисы (типа радиуса). В виртуалках же будут только некритичные сервисы (веб-проекты и т.п.), отсутствие которых даже в течение 2-3 минут катастрофой не станет.

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

Не просто DRBD - потому, что возможно возникнет потребность в 3-4 нодах, если производительности не будет хватать. А возможно и не возникнет. Но в любом случае, лучше таки заложить расширяемость на этапе проектирования, чем потом переделывать живую систему.

NiTr0 ★★★★★ ()

Я бы посоветовал DRBD + iSCSI. Сам не делал, но «рекомендации лучших собаководов». Сам делал простой DRBD.

А у меня встречный вопрос: а чем можно это дело централизованно бэкапить? Я пока использую бэкап каждой виртуалки её (виртуалки) средствами. Неудобно, нетехнологично. Можно ли бэкапить всё разом? Естественно, очень желательно количество необходимого пространства при этом не (кол-во бэкапов)x(размер тома с виртуалками).

shamus24 ()
Ответ на: комментарий от NiTr0

во всяком случае в top KVM идет в system время...

как ты тогда определил что это system именно от kvm? :). Короче, показывай top

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

DRBD+iSCSI мастер что, увеличивает вероятность падения ноды?

Нет, конечно.

Если нет - то тогда какбы мастер хранилища имеет смысл делать там же, где и виртуалки... Ведь в таком случае если падает 2-я нода - на 1й никаких неудобств нет, а если падает 1-я - то на 2й в любом случае виртуалки придется поднимать...

А, понятно. У тебя всего два компа в наличии? Тогда да, не парься. Только, если это делается не на месяц, лучше сразу закладывайся на NFS/iSCSI. Потом (при расширении и просто миграции) сильно удобнее будет.

Ximen ★★★★ ()
Ответ на: комментарий от true_admin
top - 00:24:12 up 15 days, 12:16,  1 user,  load average: 0.85, 0.72, 0.40
Tasks: 176 total,   1 running, 175 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.3%us, 49.4%sy,  0.0%ni, 47.6%id,  2.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  1.5%sy,  0.0%ni, 62.0%id, 35.9%wa,  0.6%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us, 35.8%sy,  0.0%ni, 46.1%id, 17.8%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu3  :  0.0%us, 20.1%sy,  0.0%ni, 69.5%id, 10.5%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8174664k total,  8127684k used,    46980k free,   534772k buffers
Swap:  5242872k total,      148k used,  5242724k free,  3056812k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3747 root      15   0 4506m 3.0g 1216 S 105.1 38.3   1220:19 kvm

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

Ximen спасибо, так наверное и сделаю. Кластер пока на 2 ноды, но сколько нод у него отрастет в перспективе через годик-другой - предсказывать не берусь. Может на 2х и остановится, может - придется кучку еще каки-то ресурсоемких сервисов поднимать...

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

Ну вон оно показывает 105% cpu. Что там в system упало хз, но его у тебя как-то очень много. Впрочем, может у тебя интенсивное io внутри виртуалки?

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

Кластер пока на 2 ноды, но сколько нод у него отрастет в перспективе через годик-другой - предсказывать не берусь.

Отрастут - просто раздели хранилищи и вирт. хосты. Собственно в кластере хранилища так два и останутся, а сами машины будут крутиться на отдельных машинах. Если не будешь привязан к локальным ресурсам, это элементарно.

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

В system как раз и упал весь KVM. В user его-то нет :) I/O черезчур интенсивного нет - шла компиляция чего-то в виртуалке.

Ximen собссно так и планирую.

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

В user его-то нет :)

Вон в показаниях top 105% занял, это и есть user. Почему у тебя по процам оно в system отображается хз, но что это меняет?

У меня ещё больший дурдом: в user 30% жрёт виртуалка, но top показывает что процы почти свободны. Но у меня ядро старое, посмотрим что будет когда ось обновлю.

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