LINUX.ORG.RU
ФорумAdmin

Организация хранилища Proxmox

 , , ,


1

6

Приветствую всех.. Хочу получить совет или услышать мнение знающих, по поводу организации стореджа для хранения образов виртуальных машин и их бекапов.. Дано:

  • хосты: 4 штуки (в кластере proxmox 6.4)
  • хранилки: 2 штуки
  • сеть: хосты связаны между собой 1G, san организован через 8G FC
  • на каждом хосте стоят емкие nvme - 3,2tb (на них же расположены образы требовательных к производительности виртуальных гостей)
  • остальные данные (не шустрые образы и бекапы) лежат на хранилках.
  • хранилки крутятся под управлением ESOS (scst) и раздают луны, сформированные поверх аппаратного рейда, на хранилках есть 3 типа лунов:
    1. lvm (для «среднескоростных» образов) - настроено поверх аппаратного рейд контроллера с ссд кешем (лун общий для всех хостов);
    2. lvm (для «медленных» образов) - настроено поверх аппаратного рейд контроллера без ссд кеша (лун общий для всех хостов);
    3. просто блочное устройство, которое мапится как каталог на хост (для каждого хоста свой лун) для бекапов

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

Описание проблемы: С появлением второй хранилки появилась проблема с миграцией - если миграция делается в пределах одной хранилки и одного луна - все норм.. если перемещение идет между хранилками - все происходит очень не быстро (просто жопа как медленно). Оно, конечно понятно - 1 гигабит.. что ж от него хотеть-то…

Понятно, что нужно менять организацию системы хранения.

Из того что мне первым пришло в голову - это использовать proxmox backup server и убрать мапинг блочного устройства как каталог с ext4 и сэкономить кучу места :) С бекапом - это, видимо, самый простой и продуктивный способ…

Второй идеей была мыль каким-то образом синхронизировать луны 1го и 2го типа… естественно, что я сразу вспомнил про ceph… учитывая что для него нужна сеть 10g - проработал бюджет и, в принципе, мне дали добро.. (покупка свитча, и кучки сетевух) Вижу я конструкцию цефа так: на каждом хосте

  • добавляется еще ссд для osd;
  • 2 lun с данными разной «температуры» уже есть;
  • скоростной диск в виде nvme тоже есть;
  • сеть меняется на 10Г;
  • каждый хост представляет в кластер свои физические и логические (те самые луны) ресурсы. Ну а дальше цеф, согласно конфигу делится на разные пулы и, собственно, делает то, для чего его придумали - раздает одно хранилище с разным уровнем производительности для всех хостов которое размазано по всем хостам… вроде все получается красиво…

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

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

Ответ на: комментарий от DALDON

Это в документации описано? Или по факту так происходит?? Теоретически инкрементальный бекап должен делаться на основании первой копии, а если ее нет, то отталкиваться от текущей запущенной версии.

Но в любом случае спасибо за наводку.. буду проверять

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

Я так понимаю, что proxmox backup использует qemu для бекапа. Следовательно, два вопроса:

Работает ли proxmox backup server с контейнерами, и если да, то как?

Нужно читать что по qemu - насколько я понимаю, они сделали в qemu аналог механизма CBT change block tracking. - Соотно, процесс qemu запустили. Сделали полный backup. Вот пока виртуалочка запущена, мы можем успешно отслеживать какие блоки хотят поменяться, и отправлять эти блоки в резервную копию. Как только виртуалочка стопнулась, и процесс qemu умер, мы после запуска вынуждены снова делать full backup, и после этого снова следить за изменением в блоках.

В документации явного упоминания об этом нет, знаю что proxmox backup server, юзает дедупликацию, по сему, для места это точно проблемой не будет. А вот нагрузка на сеть и CPU - возможно будет после каждого старт/стоп qemu. На форумах на англоязычных читал что поведение именно такое. - Советую вникнуть, и мне рассказать. Самому интересно, с пруфами :)

DALDON ★★★★★ ()

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

Цеф явно не для меня.. по факту надо минимум 5 нод, и как бонус - таки да, придется послать плюшки контроллеров на известные три буковки.

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

zelenij ()
Ответ на: комментарий от iliyap

Ну так и было.. так и осталось..

только 2 хранилки - не надо :)

надо одна хранилка и бекап сервер

хранилка отдает один и тот же лун с лвм нодам по FC, а бекап подключен по 10гб езернету

как-то так…

zelenij ()
Последнее исправление: zelenij (всего исправлений: 2)
Ответ на: комментарий от DALDON

В полном спеклисте от проксбекапа написано что оно умеет и полный и инкрементальный бекап всего что умеет прокс, т.е. и raw, и qcow, и контейнер…

Не знаю, можно ли верить - ещё не щупал, но написано красиво! :)

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

Верный ответ про ceph! Весь день собирался тебе ответить про него, но с мобилы неудобно портянки печатать. Ceph - это отдельная наука, внушительный оверхед на маленьких объемах и идеальный способ отстрелить себе обе ноги по незнанию.

aol ★★★★★ ()