k
Тем не менее для прокса нормальный Linstor-драйвер запилили https://habr.com/en/post/423101/
Size: a a a
2019 April 30
h
Скейлится горизонтально, только хранилки добавляй
NS
Так внутри ж метадата
Да, реально спасает, у меня тоже подобное извращение есть: mdraid и локального и iscsi диска, отдающийся по iscsi и за всем этим смотри pacemaker.
k
Тут без выделенной сети под это дело ваще никак, может даже на две надо делить, на репликацию и доставку дисклесс.
а как ты хотел с iSCSI?
k
Да, реально спасает, у меня тоже подобное извращение есть: mdraid и локального и iscsi диска, отдающийся по iscsi и за всем этим смотри pacemaker.
тут в соседнем чатике чел собирал отказоустойчивый такргет с mdadm и clustered-metadata + VDO, тоже говорит что ребилдится быстро
NS
тут в соседнем чатике чел собирал отказоустойчивый такргет с mdadm и clustered-metadata + VDO, тоже говорит что ребилдится быстро
эт я и есть ;)
k
NS
а как ты хотел с iSCSI?
Не, ну тут надо одну на репликацию, вторую на доставку прям, и куосы крутить как минимум
FD
так что ничего не знаю
zvol?
k
zfs
NS
тут в соседнем чатике чел собирал отказоустойчивый такргет с mdadm и clustered-metadata + VDO, тоже говорит что ребилдится быстро
Я там кстати немного ошибся, имелась ввиду internal metadata, clustered это про другое.
IH
Постараюсь подытожить, ZFS можно использовать на хосте гипервизора, как локальное хранилище, работает это в достаточной степени надежно, но есть целый ворох нюансов, которые нужно учитывать. Потому, при наличии сколь-нибудь хорошей сети и нескольких хостов гипервизоров, более целесообразным выглядит использование выделенного под хранилище хоста, а уже на нем можно ZFS (причем лучше на какой-то соляре) и iSCSI (comstar на соляре хвалят). Кстати, в том же Proxmox, например, даже есть реализация програмная возможности использовать ZFS over iSCSI (т.е. оно скриптом заходит на хранилище, создает ZVOL и потом экспортирует его через iSCSI taget подключая к создаваемому гостю). В результате получаем одновременно преимущества ZFS, отпадают нюансы гиперконвергентной системы (и при использовании соляры, еще и нюансы ZoL отпадают), кроме того появляется возможность использовать shared storage (т.е. можно по живому мигрировать машинки между хостами).
Но iSCSI — это уже другая история и, как я понимаю, спрашивающие про ZFS как локальное хранилище, не ищут совета по созданию многоуровневой инфраструктуры с выделенным слоем хранения данных 😊
Но iSCSI — это уже другая история и, как я понимаю, спрашивающие про ZFS как локальное хранилище, не ищут совета по созданию многоуровневой инфраструктуры с выделенным слоем хранения данных 😊
Ну там уже наверное лучше использовать ceph
NS
Не, ну тут надо одну на репликацию, вторую на доставку прям, и куосы крутить как минимум
Почитал тут немного про линстор, в принципе да, разницы нет, если использовать выделенные ноды под хранилки, и интерконнект для репликации. А роль quorum-device выполняет контроллер. Я чет подумал что оно типа только HC-кластера, а ставить две сетки в compute node жирновато канеш для нас. Будем дальше копать какие у них есть варианты HA.
П
Ну там уже наверное лучше использовать ceph
Нет, далеко до ceph, более того, где можно обойтись без ceph - лучше туда не лезть. Это отдельная песня, куда более "тонкая" и чувствительная ко всякому, чем zfs даже :)
Кроме того, ceph условно начинается с 3 узлов хранилища и то в варианте для тестов погонять, в продакшн нужно минимум 5 ставить... и это для скромного ceph хранилища. Вопрос, с какого размера кластера рабочих нод можно начинать разговор про выделенные 5 нод по ceph?
Я уже не говорю про требования к сети, к железу (процам), и при всем этом latency всегда будет больше чем через 1гбит сеть на iscsi :)
P. S. Если у вас есть ceph как система хранения, созданная под те задачи где она нужна, и вы сбоку хотите крутить насколько десятков виртуалок не особо требовательных к lat и операциями записи в один поток, то в принципе можно. Делать отдельный ceph кластер как хранилище образов виртуалок под систему виртуализации -- это ещё нужно доказать, что оно вам хоть как-то оправдано (95% нет), по сравнению с другими более простыми решениями (в первую очередь iscsi или fc хранилками). Я тут даже не начинаю обсуждать нюансы.
Кроме того, ceph условно начинается с 3 узлов хранилища и то в варианте для тестов погонять, в продакшн нужно минимум 5 ставить... и это для скромного ceph хранилища. Вопрос, с какого размера кластера рабочих нод можно начинать разговор про выделенные 5 нод по ceph?
Я уже не говорю про требования к сети, к железу (процам), и при всем этом latency всегда будет больше чем через 1гбит сеть на iscsi :)
P. S. Если у вас есть ceph как система хранения, созданная под те задачи где она нужна, и вы сбоку хотите крутить насколько десятков виртуалок не особо требовательных к lat и операциями записи в один поток, то в принципе можно. Делать отдельный ceph кластер как хранилище образов виртуалок под систему виртуализации -- это ещё нужно доказать, что оно вам хоть как-то оправдано (95% нет), по сравнению с другими более простыми решениями (в первую очередь iscsi или fc хранилками). Я тут даже не начинаю обсуждать нюансы.
SK
На zfs и хардов меньше понпдобится) но это вообще разные решения разного класса
k
Почитал тут немного про линстор, в принципе да, разницы нет, если использовать выделенные ноды под хранилки, и интерконнект для репликации. А роль quorum-device выполняет контроллер. Я чет подумал что оно типа только HC-кластера, а ставить две сетки в compute node жирновато канеш для нас. Будем дальше копать какие у них есть варианты HA.
>роль quorum-device выполняет контроллер
Неа, для каждого девайса может быть свой кворум, формально можно даже контроллер выключить на время, ничего странного не произойдёт
Неа, для каждого девайса может быть свой кворум, формально можно даже контроллер выключить на время, ничего странного не произойдёт
NS
>роль quorum-device выполняет контроллер
Неа, для каждого девайса может быть свой кворум, формально можно даже контроллер выключить на время, ничего странного не произойдёт
Неа, для каждого девайса может быть свой кворум, формально можно даже контроллер выключить на время, ничего странного не произойдёт
ну quorum-device тоже можно выключить, просто от сплита вас уже никто не спасет
FD
@PavelTacid
Делать отдельный ceph кластер как хранилище образов виртуалок под систему виртуализации -- это ещё нужно доказать
«
🙆♀️Как же я жить то теперь буду.
А если виртуалок больше, чем ~10? Сотни-тысячи %)
Делать отдельный ceph кластер как хранилище образов виртуалок под систему виртуализации -- это ещё нужно доказать
«
🙆♀️Как же я жить то теперь буду.
А если виртуалок больше, чем ~10? Сотни-тысячи %)
NS
ну quorum-device тоже можно выключить, просто от сплита вас уже никто не спасет
в целом ок, продолжаю изучать доку. Уж очень боязно мне в прод тянуть свое поделие.
k
ну quorum-device тоже можно выключить, просто от сплита вас уже никто не спасет
Сплитбрейн в drbd это стандартная ситуация, нужно настраивать политику разрешения конфликтов.