I
а какие еще требования к хранилке имеются ?
Size: a a a
2020 September 25
I
может быть подойдет линстор ? https://t.me/drbd_ru
I
я его никогда не юзал, но поверхностно изучил
ВИ
мне важно не протерять данные ВМ, с минимальной потерей производительности дисковой подсистемы. Желателно иметь возможность мигрировать ВМ с ноды на ноду во вменяемое время. Объем ВМ от 300Гб
ВИ
win2k16
1C + MSSQL
1C + MSSQL
N
Я использовал. В целом работает отлично. но надо следить.
R
мне важно не протерять данные ВМ, с минимальной потерей производительности дисковой подсистемы. Желателно иметь возможность мигрировать ВМ с ноды на ноду во вменяемое время. Объем ВМ от 300Гб
Цепх - это не про бешеную производительность. Либо про очень дорого) цепх про масштабируемость и отказаустойчивость. Линстор - быстрее
R
Если прям нужна скорость, а точнее йопсы - Линстор
V
win2k16
1C + MSSQL
1C + MSSQL
вместо mssql у нас постргря, около 80 сессий с толстых-тонких клиентов + цитриксы там же + куча других виртуалок, все это на 5ти нодах и цефе, да-да гиперконвергентно без "мухи отдельно слоны отдельно" и диски и вычисления на тех же самых машинах, и нормально живет не кашляет
r
окей, а какие мне огда остаются варианты?
у меня сейчас есть сетевое хранилище, но его уже по производительноти дисковой подсистемы не хватает.
У меня в нодах есть возможность добавить локальных дисков.
Тогда поднимать на каждой файловую систему и просто rsync-ом забирать файлы ВМ на соседнюю ноду?
у меня сейчас есть сетевое хранилище, но его уже по производительноти дисковой подсистемы не хватает.
У меня в нодах есть возможность добавить локальных дисков.
Тогда поднимать на каждой файловую систему и просто rsync-ом забирать файлы ВМ на соседнюю ноду?
ZFS, snapshots + send/receive -эта связка в разы, а может быть и на порядок будет быстрее. Но у вас не будет онлайн миграции и вообще это не разделяемое хранилище. Но проблему с быстродействием и бекапами вы точно решите.
ВИ
ну вот и я начал в эту сторону думать. но опять таки, надо будет за всеми изменениями следить очень сильно
R
riv1329
ZFS, snapshots + send/receive -эта связка в разы, а может быть и на порядок будет быстрее. Но у вас не будет онлайн миграции и вообще это не разделяемое хранилище. Но проблему с быстродействием и бекапами вы точно решите.
Сейчас бы send/receive сравнивать с цепх\дрбд)
r
мне важно не протерять данные ВМ, с минимальной потерей производительности дисковой подсистемы. Желателно иметь возможность мигрировать ВМ с ноды на ноду во вменяемое время. Объем ВМ от 300Гб
zfs send / receive - самая быстрая, но offline миграция, поддерживается проксмоксом из интерыейса.
R
riv1329
zfs send / receive - самая быстрая, но offline миграция, поддерживается проксмоксом из интерыейса.
Онлайн
r
Онлайн
Дело в том, что она хоть и офлайн, зато очень очень быстрая. Она делается в 2 этапа: подготовка прямо на работающей виртуальной машине, передается 99.9% данеых. Потом нода выключается и передается отавшийся 0.1% и сразу включается на новом месте.
Такой сценарий правда придётся написать в виде скрипта.
Такой сценарий правда придётся написать в виде скрипта.
I
riv1329
Дело в том, что она хоть и офлайн, зато очень очень быстрая. Она делается в 2 этапа: подготовка прямо на работающей виртуальной машине, передается 99.9% данеых. Потом нода выключается и передается отавшийся 0.1% и сразу включается на новом месте.
Такой сценарий правда придётся написать в виде скрипта.
Такой сценарий правда придётся написать в виде скрипта.
как это поможет, если нода с нужными данными упадёт ?
I
актуальных данных уже не достать
r
ну вот и я начал в эту сторону думать. но опять таки, надо будет за всеми изменениями следить очень сильно
Не совсем понял о чём речь. В zfs нет такой проблемы устаревания и неполноты документации.
I
синк же делается по рассписанию
I
он не каждую транзакцию синхронизирует на другие ноды