Comments 71
Неплохая статья, очень в тему для меня сейчас.
У нас крутиться кластер из 4 нод, правда на локальных дисках, так что из всех плюшек кластера получаем только единый интерфейс управления. Как раз задумываемся об ISCSI таргете, что бы уже ни что не мешало пользоваться всеми прелестями кластера на полную.
А как на счёт производительности?
Было бы очень интересно взглянуть на резульаты каких-никаких тестов на производительность дисковой подсистемы из самого Proxmoxa и из виртуалки. Это очень обогатло бы вашу статью.
У нас крутиться кластер из 4 нод, правда на локальных дисках, так что из всех плюшек кластера получаем только единый интерфейс управления. Как раз задумываемся об ISCSI таргете, что бы уже ни что не мешало пользоваться всеми прелестями кластера на полную.
А как на счёт производительности?
Было бы очень интересно взглянуть на резульаты каких-никаких тестов на производительность дисковой подсистемы из самого Proxmoxa и из виртуалки. Это очень обогатло бы вашу статью.
По производительности, это тянет на отдельную статью.
Повторюсь, решение собрано из того что было под рукой, поэтому на тестах дисковой подсистемы не акцентировались.
Здесь, конечно можно поиграться с SSD, агрегированием каналов и пр. И будут разные результаты.
Предложите Ваши варианты конфигурации дисковой подсистемы, мы постараемся реализовать и протестировать.
Повторюсь, решение собрано из того что было под рукой, поэтому на тестах дисковой подсистемы не акцентировались.
Здесь, конечно можно поиграться с SSD, агрегированием каналов и пр. И будут разные результаты.
Предложите Ваши варианты конфигурации дисковой подсистемы, мы постараемся реализовать и протестировать.
RAID1 — массив. WD диски. Из железа — широкодоступное что-то. Например D-link (Cisco) гигабитные свичи. Остально оставить как есть.
С агрегацией, ну скажем 2 (или 4) каналов.
С агрегацией, ну скажем 2 (или 4) каналов.
Имхо, RAID-массив избыточен(и даже вреден), если используется ZFS.
А что ZFS скажет на падение диска. Падение от слова "совсем", сдох контроллер, например. У меня тут на днях как раз таким образом SAS Hitachi помер. Если бы не RAID пришлось бы мне АТС разворачивать. так что RAID — наше всё.
Я Вас не совсем понял — всё-таки, выход из строя контроллера, что приведёт к отвалу всех подключенных к нему дисков, или падение одного диска в пуле из нескольких? Это разные ситуации.
В первом случае за сбоем контроллера последует отказ всего хранилища, RAID обеспечивает избыточность только на уровне группы дисков. И если вдруг в ЗИПе не найдётся такой же железки вплоть до совпадения версии фирмвари (представим такую ситуацию), то кому-то предстоит отправиться дорогой приключений (примета такая, говорят).
В случае выхода одного диска из пула ZFS отработает так же как и RAID контроллер — выкинет из пула сбойный диск, добавит горячий резерв и начнёт ребилд.
P.S. В целях проверки "запаса прочности" проверял дистрибутив Nas4Free — вынимал "на горячую" диски из корзины, ставил обратно, делал hard reset серверу и т.д. — и пришёл к выводу что ZFS удивительно устойчива к нештатным ситуациям подобного рода.
В первом случае за сбоем контроллера последует отказ всего хранилища, RAID обеспечивает избыточность только на уровне группы дисков. И если вдруг в ЗИПе не найдётся такой же железки вплоть до совпадения версии фирмвари (представим такую ситуацию), то кому-то предстоит отправиться дорогой приключений (примета такая, говорят).
В случае выхода одного диска из пула ZFS отработает так же как и RAID контроллер — выкинет из пула сбойный диск, добавит горячий резерв и начнёт ребилд.
P.S. В целях проверки "запаса прочности" проверял дистрибутив Nas4Free — вынимал "на горячую" диски из корзины, ставил обратно, делал hard reset серверу и т.д. — и пришёл к выводу что ZFS удивительно устойчива к нештатным ситуациям подобного рода.
Предположу, что имелся в виду контроллер диска, а не RAID-контроллер...
Удивительные вещи вы расказываете) И всё это на уровне файловой системы??? Надо бы освежить свои знания на счёт ZFS)
Коротко говоря — ZFS совмещает в себе функции файловой системы и менеджера томов.
Софт-рейд, как-бы. Бонусом идёт несколько разных алгоритмов прозрачного сжатия данных "на лету", дедупликация, контроль целостности (и всё это работает на блочном уровне), механизм квот, мгновенные снапшоты, и прочая, и прочая. Вкусно, короче.
Софт-рейд, как-бы. Бонусом идёт несколько разных алгоритмов прозрачного сжатия данных "на лету", дедупликация, контроль целостности (и всё это работает на блочном уровне), механизм квот, мгновенные снапшоты, и прочая, и прочая. Вкусно, короче.
Вспомним: каждый инструмент делает только свою задачу, и делает её хорошо. Это Unix-way.
ZFS в эту идеологию совсем не укладывается. В нём все слои (отказоустойчивость, сжатие, менеджер томов, файловая система) в одном. Не очень-то вкусно.
Причём, мы совершенно точно знаем, что это необязательно — существуют решения, в которых эти слои вообще друг от друга не зависят.
ZFS в эту идеологию совсем не укладывается. В нём все слои (отказоустойчивость, сжатие, менеджер томов, файловая система) в одном. Не очень-то вкусно.
Причём, мы совершенно точно знаем, что это необязательно — существуют решения, в которых эти слои вообще друг от друга не зависят.
Не вполне согласен с вами.
Юниксвей — это всего лишь один из подходов к построению операционных систем, и отнюдь не "серебряная пуля". Монолитная архитектура тоже имеет право на реализацию, потому что уступая в универсальности раздробленой, может быть спроектирована оптимальнее.
Чем более unix-way система, тем больше у неё слоёв абстракции, и тем длиннее тянется за ней шлейф legacy-совместимости и костылей. Имхо.
Возвращаясь к обсуждению ZFS — Вы, однако, не привели никаких аргументов против использования ZFS кроме идеологических. Приведите практический пример, который бы продемонстрировал неудобство использования этой ФС именно в силу её "неверной" идеологической реализации.
Не претендую на правоту, возможно мой взгляд однобокий, прошу не агриться, а то потом мне будет неудобно постить прилично оформленные комментарии — "ни картинку не вставить, ни болдом написать".
Юниксвей — это всего лишь один из подходов к построению операционных систем, и отнюдь не "серебряная пуля". Монолитная архитектура тоже имеет право на реализацию, потому что уступая в универсальности раздробленой, может быть спроектирована оптимальнее.
Чем более unix-way система, тем больше у неё слоёв абстракции, и тем длиннее тянется за ней шлейф legacy-совместимости и костылей. Имхо.
Возвращаясь к обсуждению ZFS — Вы, однако, не привели никаких аргументов против использования ZFS кроме идеологических. Приведите практический пример, который бы продемонстрировал неудобство использования этой ФС именно в силу её "неверной" идеологической реализации.
Не претендую на правоту, возможно мой взгляд однобокий, прошу не агриться, а то потом мне будет неудобно постить прилично оформленные комментарии — "ни картинку не вставить, ни болдом написать".
(Был на хабре вой про то, что нельзя высказать мнение, отличное от мнения т.н. "толпы". Ну вот оно, я высказал — тут ведь принято боготворить ZFS. Я уже не в первый раз его высказываю. И как-то ничего.)
Практических примеров не будет. Я по своей воле даже пробовать использовать систему, структура которой мне заведомо не нравится, не буду. Я не вижу кардинальных преимуществ ZFS перед связкой, скажем, MD+LVM+ext4, по крайней мере таких, чтобы можно было пробовать её использовать в качестве альтернативы. Зато у указанной связки вижу явные преимущества:
Во-первых, я очень хорошо с ней знаком. Я практически руками читаю суперблоки MD. Был случай, что я вносил в суперблок изменения руками, чтобы собрать сломавшийся массив ("не себе", принесли для восстановления данных). Существует уйма утилит для восстановления данных со сбойнувшей ext4.
Во-вторых, ZFS нет ни в ванильном ядре, ни в популярных дистрибутивах (Debian). Чтобы её использовать, требуются дополнительные телодвижения. Я не могу просто взять и поставить систему сразу на ZFS. А вот все указанные компоненты связки есть.
В третьих, вот эта слоёная структура, которая вся уложена в один инструмент. Бывают случаи, когда я какой-либо функционал могу не использовать, либо наоборот — хочу туда что-то встроить. Есть у меня аппаратный RAID — и я не использую MD. Бывают случаи, когда не нужно управление томами — и я исключаю LVM. Сервер виртуализации? ext4 будет только в качестве корневой ФС системы хоста — LVM-тома как блочные устройства виртуальными дисками. Потребуется мне шифрование — добавится LUKS между MD и LVM; потребуется кэширование на SSD — появится и оно, в зависимости от ситуации — между MD и LVM (bcache) либо внутри LVM (DM-cache). При этом, неиспользуемые слои реально отсутствуют — они не тратят никакие ресурсы. Несмотря на это, я всегда могу достаточно быстро и просто "добавить" отсутствующий слой. С ZFS такое невозможно — для всех перечисленных облегчённых случаев она является over-engineered структурой, из которой ничего не убрать, а для случаев с наворотами — наоборот, если уж ZFS не поддерживает что-то, добавить нельзя. Например, в ZFS не получится добавить шифрование каноническим способом: слои менеджера томов и зеркалирования у неё внутри, я не могу вставить LUKS между ними (как между MD и LVM).
Далее. Вспомним, что приходится работать не только с локальными дисками. Вариантов конфигурации становится море, в работу включается сначала multipath, а потом и кластерные сервисы. Есть у ZFS функционал, аналогичный cLVM? Это когда я добавляю логический том в общую группу на одной ноде кластера, а он сразу же видится на всех нодах. Этот функционал — базовый для обеспечения, скажем, миграции виртуальных машин. Да хотя бы что станет с ZFS, если я размещу её на DRBD и буду одновременно обращаться с двух нод? Про LVM всё ясно: можно, если cLVM настроен; про ext4 — известно, что нельзя, зато есть OCFS и другие кластерные ФС, которые монтировать можно сразу на нескольких нодах (при правильной настройке демонов синхронизации).
P.S. что-то сломали в хабре. Писать комментарии стало неудобно, он как-то стал вольно образщаться с newline и т. п.
Практических примеров не будет. Я по своей воле даже пробовать использовать систему, структура которой мне заведомо не нравится, не буду. Я не вижу кардинальных преимуществ ZFS перед связкой, скажем, MD+LVM+ext4, по крайней мере таких, чтобы можно было пробовать её использовать в качестве альтернативы. Зато у указанной связки вижу явные преимущества:
Во-первых, я очень хорошо с ней знаком. Я практически руками читаю суперблоки MD. Был случай, что я вносил в суперблок изменения руками, чтобы собрать сломавшийся массив ("не себе", принесли для восстановления данных). Существует уйма утилит для восстановления данных со сбойнувшей ext4.
Во-вторых, ZFS нет ни в ванильном ядре, ни в популярных дистрибутивах (Debian). Чтобы её использовать, требуются дополнительные телодвижения. Я не могу просто взять и поставить систему сразу на ZFS. А вот все указанные компоненты связки есть.
В третьих, вот эта слоёная структура, которая вся уложена в один инструмент. Бывают случаи, когда я какой-либо функционал могу не использовать, либо наоборот — хочу туда что-то встроить. Есть у меня аппаратный RAID — и я не использую MD. Бывают случаи, когда не нужно управление томами — и я исключаю LVM. Сервер виртуализации? ext4 будет только в качестве корневой ФС системы хоста — LVM-тома как блочные устройства виртуальными дисками. Потребуется мне шифрование — добавится LUKS между MD и LVM; потребуется кэширование на SSD — появится и оно, в зависимости от ситуации — между MD и LVM (bcache) либо внутри LVM (DM-cache). При этом, неиспользуемые слои реально отсутствуют — они не тратят никакие ресурсы. Несмотря на это, я всегда могу достаточно быстро и просто "добавить" отсутствующий слой. С ZFS такое невозможно — для всех перечисленных облегчённых случаев она является over-engineered структурой, из которой ничего не убрать, а для случаев с наворотами — наоборот, если уж ZFS не поддерживает что-то, добавить нельзя. Например, в ZFS не получится добавить шифрование каноническим способом: слои менеджера томов и зеркалирования у неё внутри, я не могу вставить LUKS между ними (как между MD и LVM).
Далее. Вспомним, что приходится работать не только с локальными дисками. Вариантов конфигурации становится море, в работу включается сначала multipath, а потом и кластерные сервисы. Есть у ZFS функционал, аналогичный cLVM? Это когда я добавляю логический том в общую группу на одной ноде кластера, а он сразу же видится на всех нодах. Этот функционал — базовый для обеспечения, скажем, миграции виртуальных машин. Да хотя бы что станет с ZFS, если я размещу её на DRBD и буду одновременно обращаться с двух нод? Про LVM всё ясно: можно, если cLVM настроен; про ext4 — известно, что нельзя, зато есть OCFS и другие кластерные ФС, которые монтировать можно сразу на нескольких нодах (при правильной настройке демонов синхронизации).
P.S. что-то сломали в хабре. Писать комментарии стало неудобно, он как-то стал вольно образщаться с newline и т. п.
Кстати, только хотел предложить аналогичную альтернативу ZFS.
конечно я не знаю всех вкусностей ZFS, но на мой взгляд аппаратный RAID + LVM много надежнее.
конечно я не знаю всех вкусностей ZFS, но на мой взгляд аппаратный RAID + LVM много надежнее.
Адепты ZFS скажут, что эта связка морально устарела т.к. рейд контроллер ничего не знает о файлах. Например если у вас есть Raid0 на обычном контроллере и у вас произойдет ошибка чтения с диска — то все данные — пропали. В случае с ZFS она отрапортует вам что такой-то файл поврежден и продолжит работать дальше. Кроме того аппаратные рейд контроллеры от модели к модели ведут себя сильно по-разному (читай не предсказуемо).
Если в силу каких-то обстоятельств случиться ребилд массива, то ZFS будет ребилдить только блоки с данными. Тогда как рейд в виду того, что он ничего не знает о файлах, будет ребилдить все подряд (что в свою очередь может разрушить рейд. Например если при ребилде 5го рейда произойдет ошибка чтения). Ну еще можно вспомнить про Write hole, ZFS этой проблеме не подвержен.
Если в силу каких-то обстоятельств случиться ребилд массива, то ZFS будет ребилдить только блоки с данными. Тогда как рейд в виду того, что он ничего не знает о файлах, будет ребилдить все подряд (что в свою очередь может разрушить рейд. Например если при ребилде 5го рейда произойдет ошибка чтения). Ну еще можно вспомнить про Write hole, ZFS этой проблеме не подвержен.
То, что связка MD+LVM+фс морально устарела вовсе не означает, что ZFS лучше и годится на замену.
И по поводу RAID5: так же точно и при ребилде RAID1, если единственная живая реплика отказывает в процессе ребилда. И вы, и адепты ZFS заблуждаетесь по поводу поведения массива в этой ситуации, видимо, потому, что не знаете, что там произойдёт при ошибке чтения.
Ничего не разрушится, ребилд правда тоже до конца не дойдёт — наткнувшись на ошибку чтения, MD начинает ребилд с начала, потом дойдя до ошибки процесс снова перезапустится и т. д. Не очень хорошее поведение, однако на моей памяти сервер с такой проблемой и MD RAID1 выжил: на оставшейся полуживой реплике перезаписали hdparm-ом сектор с ошибкой чтения, в результате чего накопитель переназначил блок. Репликация MD прошла через этот блок и успешно завершилась. Да, данные в этом блоке испортились (блок затёрт нулями), но в итоге ни на что это не повлияло.
А вот как себя поведёт в аналогичном случае ZFS — что она сделает, если в процессе восстановления отказоустойчивости один из уникальных источников будет выдавать ошибки — вы знаете? Интересно. И если в случае MD сам честно сказал, какой блок сбоил, то как в случае ZFS вычислить точку, в которую писать?
И по поводу RAID5: так же точно и при ребилде RAID1, если единственная живая реплика отказывает в процессе ребилда. И вы, и адепты ZFS заблуждаетесь по поводу поведения массива в этой ситуации, видимо, потому, что не знаете, что там произойдёт при ошибке чтения.
Ничего не разрушится, ребилд правда тоже до конца не дойдёт — наткнувшись на ошибку чтения, MD начинает ребилд с начала, потом дойдя до ошибки процесс снова перезапустится и т. д. Не очень хорошее поведение, однако на моей памяти сервер с такой проблемой и MD RAID1 выжил: на оставшейся полуживой реплике перезаписали hdparm-ом сектор с ошибкой чтения, в результате чего накопитель переназначил блок. Репликация MD прошла через этот блок и успешно завершилась. Да, данные в этом блоке испортились (блок затёрт нулями), но в итоге ни на что это не повлияло.
А вот как себя поведёт в аналогичном случае ZFS — что она сделает, если в процессе восстановления отказоустойчивости один из уникальных источников будет выдавать ошибки — вы знаете? Интересно. И если в случае MD сам честно сказал, какой блок сбоил, то как в случае ZFS вычислить точку, в которую писать?
ZFS отрапортует наверх что такой-то файл поврежден и будет ребилдить дальше. На моем домашнем рейд0 такое было однажды — я просто получил сообщение, примерно такого вида:
The volume my-volume (ZFS) state is ONLINE: One or more devices has experienced an error resulting in data corruption. Applications may be affected.
Device: /dev/ada3, 2 Currently unreadable (pending) sectors
Через CLI можно посмотреть какой файл побился. Больше ни на чем это не сказалось. Так что нет необходимости выяснять в какую точку нужно что-то писать.
The volume my-volume (ZFS) state is ONLINE: One or more devices has experienced an error resulting in data corruption. Applications may be affected.
Device: /dev/ada3, 2 Currently unreadable (pending) sectors
Через CLI можно посмотреть какой файл побился. Больше ни на чем это не сказалось. Так что нет необходимости выяснять в какую точку нужно что-то писать.
Довольно странный в технической дискуссии аргумент: "Практических примеров не будет. Я по своей воле даже пробовать использовать систему, структура которой мне заведомо не нравится, не буду."
ZFS есть не только на Линукс. Точнее, как раз на линукс ZFS ещё довольно сырой, и многие функции отсутствуют вообще. FreeBSD, например, спокойно ставится на ZFS.
Про шифрование — вам нужно шифрование, или вам нужен LUKS? Если всё-таки во главу угла ставится "получить шифрование", а не "запилить LUKS", то есть GELI, поверх которого спокойно разворачивается ZFS. Или наоборот — поверх ZVOL разворачивается GELI с любой файловой системой внутри криптоконтейнера.
Никаких "неиспользуемых слоёв" в ZFS нет — когда вы запускаете ZFS, то практически все слои используются, за малым исключением и в отдельных сценариях.
Именно на ZFS такого функционала нет — пул, подключенный к одной системе, будет виден только ей. Но есть многое другое.
Как насчёт компрессии на лету?
Дедупликации?
Простых средств расширения дискового пространства?
"Тонких" блочных устройств (разумеется, также с компрессией и дедупликацией, на базе ZVOL)
С двухуровневым кэшем (SLOG/ARC/L2ARC)?
С возможностью сохранять более одной копии файлов на датасете, с автоматическим выбором не-битых блоков в случае сбоя носителя?
С автоматическим scrub'ом?
Сколько ещё уровней нужно накрутить будет в связку MD+LVM+ext4 (что влечёт за собой отдельные разборки с каждым из уровней — набор команд, ключей, структура сущностей, что поверх чего должно применяться и т. п.), чтобы получить весь вот этот функционал? Я даже дома использую его ВЕСЬ, за исключением дедупликации и SLOG. Не говоря уже про продакшн. Так что не очень понятно, какие "неиспользуемые" слои можно выделить в ZFS.
Да не вопрос, если вы будете обращаться к ZVOL. Причём все функции — кэши, компрессия, дедупликация, чексуммы — всё это будет работать.
Я не могу просто взять и поставить систему сразу на ZFS.
ZFS есть не только на Линукс. Точнее, как раз на линукс ZFS ещё довольно сырой, и многие функции отсутствуют вообще. FreeBSD, например, спокойно ставится на ZFS.
Про шифрование — вам нужно шифрование, или вам нужен LUKS? Если всё-таки во главу угла ставится "получить шифрование", а не "запилить LUKS", то есть GELI, поверх которого спокойно разворачивается ZFS. Или наоборот — поверх ZVOL разворачивается GELI с любой файловой системой внутри криптоконтейнера.
Никаких "неиспользуемых слоёв" в ZFS нет — когда вы запускаете ZFS, то практически все слои используются, за малым исключением и в отдельных сценариях.
Есть у ZFS функционал, аналогичный cLVM? Это когда я добавляю логический том в
общую группу на одной ноде кластера, а он сразу же видится на всех нодах.
Именно на ZFS такого функционала нет — пул, подключенный к одной системе, будет виден только ей. Но есть многое другое.
Как насчёт компрессии на лету?
Дедупликации?
Простых средств расширения дискового пространства?
"Тонких" блочных устройств (разумеется, также с компрессией и дедупликацией, на базе ZVOL)
С двухуровневым кэшем (SLOG/ARC/L2ARC)?
С возможностью сохранять более одной копии файлов на датасете, с автоматическим выбором не-битых блоков в случае сбоя носителя?
С автоматическим scrub'ом?
Сколько ещё уровней нужно накрутить будет в связку MD+LVM+ext4 (что влечёт за собой отдельные разборки с каждым из уровней — набор команд, ключей, структура сущностей, что поверх чего должно применяться и т. п.), чтобы получить весь вот этот функционал? Я даже дома использую его ВЕСЬ, за исключением дедупликации и SLOG. Не говоря уже про продакшн. Так что не очень понятно, какие "неиспользуемые" слои можно выделить в ZFS.
Да хотя бы что станет с ZFS, если я размещу её на DRBD и буду одновременно
обращаться с двух нод?
Да не вопрос, если вы будете обращаться к ZVOL. Причём все функции — кэши, компрессия, дедупликация, чексуммы — всё это будет работать.
Добавлю свое имхо, для виртуализации всегда использую 10й, так как raid1,5,6 начинают жутко проседать при активном использовании ВМ больше 3х.
Не думали про кеширование. У меня проседаний не наблюдается, WD1002F9YZ в RAID1 с 4-мя виртуалками честно выдают заявленные производителем 600 Мб/сек
Ну тут смотря какие ВМ и для каких задач, если нагрузка не большая, вполне и первый raid справится. В моем случае — это виртуалки для разработчиков, на которые постоянно деплоятся приложения и активно используется postgresql. Был неприятный опыт, когда попортилась БД при отлючении питания, хотя raid controller был с батарейкой. Возможно какой-то сбой в железе, но с тех пор для надежности стараюсь не использовать кеширование на raid. Хотя с того времени много воды утекло и может сейчас все изменилось в лучшую сторону. Нужно проверять…
Батарейка на RAID это конечно хорошо, но страховки, как известно, много не бывает. Поэтому только LVM и правильно настроенная ext4 (шлагбаумы там всякие и кеши)
Кстати в пользу этого решения говорит и то, что корпорация добра в числе многих других рекомендует такой подход и сами его используют.
Кстати в пользу этого решения говорит и то, что корпорация добра в числе многих других рекомендует такой подход и сами его используют.
Никакие шлагбаумы он спасут вашу ext4, если RAID-контроллер, хотя бы и в режиме HBA, ей отчитался "записано", а сам записал в свой гигабайтный кэш. Смысл батарейки на контроллере — поддерживать работу этого кэша.
Решит проблему тут режим WriteThrough, но вы быстро заметите что оно как-то небыстро работает.
Решит проблему тут режим WriteThrough, но вы быстро заметите что оно как-то небыстро работает.
Delaem software raid, v srednem (zavisit ot kolichestva diskov)
performance = RAID10
capacity = RAIDz-2
Diski grupiruutsia v vDevs, naprimer RAID10 na 6 diskah s dvoinim zerkalom = 3 vDev, i t.d.
v Srednem chem bolshe vDev tem lu4she performance
performance = RAID10
capacity = RAIDz-2
Diski grupiruutsia v vDevs, naprimer RAID10 na 6 diskah s dvoinim zerkalom = 3 vDev, i t.d.
v Srednem chem bolshe vDev tem lu4she performance
Скажите: Nexenta не имеет ограничений на объем хранилища?
Еще хочу рассказать про CEPH. Это тоже неплохой вариант организации хранения образов виртуальных машин.
Здесь вам не нужно отдельное физическое хранилище, вы можете настроить распределенное хранилище прямо на нодах, оно также будет отказоустойчевым и к тому же поддерживается Proxmox.
Если интересно, вот ссылка на wiki-страничку на сайте Proxmox и на мою статью.
Еще хочу рассказать про CEPH. Это тоже неплохой вариант организации хранения образов виртуальных машин.
Здесь вам не нужно отдельное физическое хранилище, вы можете настроить распределенное хранилище прямо на нодах, оно также будет отказоустойчевым и к тому же поддерживается Proxmox.
Если интересно, вот ссылка на wiki-страничку на сайте Proxmox и на мою статью.
Однако то, что доступно в Community версии, покрывает большинство начальных потребностей. Это и 18ТБ объема хранилища, и ZFS со снэпшотами, и возможность репликации из коробки!
Интересный это вариант. Мы пробовали вплоть до запуска Ceph на самих нодах виртуализации. В сухом минимальном остатке требуется три компа и коммутатор.
Спасибо за статью. Побольше бы такого материала на хабре.
Спасибо за статью, было интересно прочитать.
А вы не подскажете вариант настройки отказоустойчивого кластера (на какой угодно программной платформе) который бы обеспечивал 100% времени доступа к ресурсам (т.е. при выходе из строя одной ноды — сам кластер работал бы как ни в чем не бывало)?
А вы не подскажете вариант настройки отказоустойчивого кластера (на какой угодно программной платформе) который бы обеспечивал 100% времени доступа к ресурсам (т.е. при выходе из строя одной ноды — сам кластер работал бы как ни в чем не бывало)?
Первое что приходит в голову — это VMWare Fault Tolerance. См. ссылку. Там суть в том что на определенном вами ресурсе (VM) всегда работает резервная копия на другой ноде.
При падении рабочей ноды, ресурс работать не прекращает.
Опять же, в этом случае надо покупать лицензию!
При падении рабочей ноды, ресурс работать не прекращает.
Опять же, в этом случае надо покупать лицензию!
Также похожий функционал, есть у XenServer, скорее всего дешевле чем у VMWare, но там надо уточнять.
Вот кстати интересная штука.
У Proxmox, VM переезжает на другую ноду с рестартом.
Вот кстати интересная штука.
У Proxmox, VM переезжает на другую ноду с рестартом.
Не, вы не правы. При использовании ISCSI — таргета и правильной настройки тригеров HA, виртуалка продолжает работать как ни в чём не бывало.
Буду рад ошибиться, к сожалению онлайн-миграция бывает только при старте вручную.
Это показано в ролике, в конце статьи.
Если нода по каким-то причинам падает, то VM рестартуют на другом хосте в соот-и с настройками HA.
Если же у вас работает по другому, давайте подробнее про ваши настройки?!
Это показано в ролике, в конце статьи.
Если нода по каким-то причинам падает, то VM рестартуют на другом хосте в соот-и с настройками HA.
Если же у вас работает по другому, давайте подробнее про ваши настройки?!
Да где-то тут на хабре была статья про HA на Proxmox. По ней и настраивал. Машинки мигрировали наживую, только в dmesg выкидывали предупреждение, что-то там с таймерами связанное и всё. Правда в качестве гостя Linux был. Может с Windows что-то по другому, не проверял.
Всё там нормально с Windows.
Если вы инициируете миграцию руками на с живого хоста на живой, то да, без единого разрыва. Точнее, длительность разрыва он напишет в конце миграции и это будет порядка нескольких микросекунд.
А если нода с виртуалкой вышла из строя, и виртуалка обслуживалась HA, то она снова запустится на другой ноде. Но для ОС виртуалки это будет как будто нажали на Reset.
Если вы инициируете миграцию руками на с живого хоста на живой, то да, без единого разрыва. Точнее, длительность разрыва он напишет в конце миграции и это будет порядка нескольких микросекунд.
А если нода с виртуалкой вышла из строя, и виртуалка обслуживалась HA, то она снова запустится на другой ноде. Но для ОС виртуалки это будет как будто нажали на Reset.
А, ну тогда естественно да, по другому никак, только держать в горячем резерве полный дубль виртуалки для подхватывания.
Хотя многое зависит от самих сервисов нап виртуалках. Например ту же 1С можно запустить на двух виртуалках, которые в свою очередь разнести на разные ноды в кластере Proxmox, а вот сами виртуалки уже объединить в кластер 1С.
С одной стороны они поделять нагрузку, а с другой стороны при падении любой из них сервис не остановится.
Лично я так и сделал.
Хотя многое зависит от самих сервисов нап виртуалках. Например ту же 1С можно запустить на двух виртуалках, которые в свою очередь разнести на разные ноды в кластере Proxmox, а вот сами виртуалки уже объединить в кластер 1С.
С одной стороны они поделять нагрузку, а с другой стороны при падении любой из них сервис не остановится.
Лично я так и сделал.
Речь в ветке о том, что VMWare и XenServer в принципе умеют выполнять виртуалку синхронно на двух нодах. Если одна из нод отказывает, виртуалка ничего не замечает. Она как бы постоянно мигрирует на вторую ноду в процессе выполнения.
В своё время это была прорывная фича Xen под названием Kemari, так что видимо Citrix в итоге коммерциализовал это в своём XenServer. Когда и как это появилось в VMWare я не знаю, наверняка недавно.
Proxmox такого не умеет, хотя принципиально в нём это тоже вполне возможно реализовать.
В своё время это была прорывная фича Xen под названием Kemari, так что видимо Citrix в итоге коммерциализовал это в своём XenServer. Когда и как это появилось в VMWare я не знаю, наверняка недавно.
Proxmox такого не умеет, хотя принципиально в нём это тоже вполне возможно реализовать.
Все нормальные гипервизоры предлогают такой функционал — VMWare, Hyper-V, KVM, Xen
Работает всё примерно одинаково — все ноды обращаются к одному хранилищу, а актуальное состояние реплицируется через сеть. Всё в принципе уперается в общее хранилище. Под линукс или виндовс есть возможноси объеденить локальные диски в одно хранилище.
У VMWare есть дополнительная опция. Если у вас к примеру нету общего хранилища, то можно образовать одно из дисков в нодах, что-то типа рейда через сеть, название забыл. Делали, работает не очень быстро и доступно только половина памяти.
В линуксе можно сделать к примеру ceph кластер, можно на те же сервера где proxmox установить, поэтому не понятно нафига огорот с iscsi городить.
Hyper-v с отдельным хранилищем работает как кластер очень хорошо, виртуальные машины перекидываются без проблем и без обрывов, во всяком случае версия начиная с 2012
Работает всё примерно одинаково — все ноды обращаются к одному хранилищу, а актуальное состояние реплицируется через сеть. Всё в принципе уперается в общее хранилище. Под линукс или виндовс есть возможноси объеденить локальные диски в одно хранилище.
У VMWare есть дополнительная опция. Если у вас к примеру нету общего хранилища, то можно образовать одно из дисков в нодах, что-то типа рейда через сеть, название забыл. Делали, работает не очень быстро и доступно только половина памяти.
В линуксе можно сделать к примеру ceph кластер, можно на те же сервера где proxmox установить, поэтому не понятно нафига огорот с iscsi городить.
Hyper-v с отдельным хранилищем работает как кластер очень хорошо, виртуальные машины перекидываются без проблем и без обрывов, во всяком случае версия начиная с 2012
Настраивал (по инструкциям в интернете, в том числе с хабра) кластер на Hyper-V (сервер AD + две ноды + СХД от IBM) везде стояла 2012 R2, СХД была настроена как общий ресурс с кворумом, MPIO и т.д. При выключении "активной" ноды виртуальные машины мигрировали и были недоступны примерно с минуту. Хотелось бы узнать как всетаки правильно создать кластер, чтобы виртуальные машины не перезагружались при выходе из строя "активной" ноды, какие ПО и железо использовать.
на hyper-v пока такое не возможно самим гипервизором, да и наврятли microsoft сделает в ближайшее время такую возможность.
если у вас виртуальная машина на windows, то поднимайте кластер майкрософта уже на виртуальных машина. если у вас linux то смотрите в сторону keepalived
если у вас виртуальная машина на windows, то поднимайте кластер майкрософта уже на виртуальных машина. если у вас linux то смотрите в сторону keepalived
Несовсем понял про кластер внутри "виртуалок", не могли ли бы вы поподробнее объяснить, пожалуйста? А за keepalived спасибо, нашел статью на хабре, вроде бы понятную :)
Многий корпоративный софт на данный момент имеет функционал кластеризации на уровне сервисов. То есть, на примере 1С:
1) Два сервера 1С, обединяются в кластер, с одинаковым набором баз, с подключением к одному SQL-серверу и делят нагрузку от клиентов между собой. В случае падения одного из них, клиенты сами переподключаются на оставшийся сервер и вся нагрузка ложится на него. При этом сам сервис 1С ни на секунду не останавливается.
2) Исходя из вышесказанного, что нам нужно. Две виртуалки, на разных нода кластера Proxmox. Внутри каждой из них установлено по одному желтому серверу, которые уже механизмами самой 1С объеденены в кластер серверов 1С. Они делят между собой нагрузку, а не дублируют состояние друг друга. То есть ресурсы железа не простаивают не расходуются вхолостую
3) Таким образом при падении одной из нод Proxmox падает и виртуалка, расположенная на нём. Но в строю остаётся вторая виртуалка с сервером 1С, так-как она расположена на второй ноде. Тоесть сервис 1С продолжает работать. Просто оставшийся в строю теперь всю нагрузку берёт на себя.
Аналогиный механизм можно применить и к SQL-серверу, и разместить две sql-ноды на тех же хостах что 1с-сервера.
Получится отказоустойчивая связка 1с-sql.
1) Два сервера 1С, обединяются в кластер, с одинаковым набором баз, с подключением к одному SQL-серверу и делят нагрузку от клиентов между собой. В случае падения одного из них, клиенты сами переподключаются на оставшийся сервер и вся нагрузка ложится на него. При этом сам сервис 1С ни на секунду не останавливается.
2) Исходя из вышесказанного, что нам нужно. Две виртуалки, на разных нода кластера Proxmox. Внутри каждой из них установлено по одному желтому серверу, которые уже механизмами самой 1С объеденены в кластер серверов 1С. Они делят между собой нагрузку, а не дублируют состояние друг друга. То есть ресурсы железа не простаивают не расходуются вхолостую
3) Таким образом при падении одной из нод Proxmox падает и виртуалка, расположенная на нём. Но в строю остаётся вторая виртуалка с сервером 1С, так-как она расположена на второй ноде. Тоесть сервис 1С продолжает работать. Просто оставшийся в строю теперь всю нагрузку берёт на себя.
Аналогиный механизм можно применить и к SQL-серверу, и разместить две sql-ноды на тех же хостах что 1с-сервера.
Получится отказоустойчивая связка 1с-sql.
Про кластер SQL-сервера в курсе, но он не особо поможет, 1С для меня совсем не в тему. хотелось бы отказоустойчивую именно виртуалку, а не определенный "чужой" софт. Но за комментарий спасибо :) Только мне в вашем комментарии непонятно зачем вообще вам кластер Proxmox. Берем 2 физических сервера "фигак один SQL-сервер, фигак второй, и в продакшен" :)
Товарищ имел в виду так называемую «гостевую кластеризацию». Например, вам нужен отказоустойчивый MS SQL. Тогда делаете два виртуальных сервера с MS SQL, и далее собираете кластер средствами Windows и MS SQL. А в правилах размещения машин указываете, что они должны выполняться строго на разных узлах. Тогда при выходе из строя одного узла сервис у вас не пострадает — на другом узле останется работать второй виртуальный узел кластера MS SQL.
И high availability, вообще говоря, так и строится — если гипервизор падает, то машины переподнимаются на остальных оставшихся узлах, но для виртуалок это равносильно нажатию reset.
Если же речь о технологии, которую VMware называет fault tolerance, то она имеет определённые особенности экслуатации и приличные ограничения. До версии VMware 6 с помощью FT можно было зарезервировать только машину с 1 vCPU и с ограничением по объёму памяти (вроде бы, не более 16 Гб). И линк между узлами обязательно должен был быть 10G. В VMware 6 можно резервировать машины с не более чем 4 vCPU и 64 GB RAM. Ну и надо понимать, что фактически такая машина превращается в две машины аналогичной конфигурации — на другом узле будет работать теневая копия, равная по объёму ресурсов защищаемой машине.
И high availability, вообще говоря, так и строится — если гипервизор падает, то машины переподнимаются на остальных оставшихся узлах, но для виртуалок это равносильно нажатию reset.
Если же речь о технологии, которую VMware называет fault tolerance, то она имеет определённые особенности экслуатации и приличные ограничения. До версии VMware 6 с помощью FT можно было зарезервировать только машину с 1 vCPU и с ограничением по объёму памяти (вроде бы, не более 16 Гб). И линк между узлами обязательно должен был быть 10G. В VMware 6 можно резервировать машины с не более чем 4 vCPU и 64 GB RAM. Ну и надо понимать, что фактически такая машина превращается в две машины аналогичной конфигурации — на другом узле будет работать теневая копия, равная по объёму ресурсов защищаемой машине.
Я понимаю что имел в виду "товарищ", но мне бы хотелось "отказоустойчивую виртуалку" :)
А про VMware вы имели в виду vSphere 6.0?
И у вас таже "проблема" что и у "товарища". Зачем мне кластер Proxmox, который как оказывается нефига не отказоустойчивый, зачем мне заводить в нем виртуалки, зачем разносить из на разные ноды? В данном случае или вообще не париться и поставить на железо без виртуалок, или использовать два обособленных гипервизора.
А про VMware вы имели в виду vSphere 6.0?
И у вас таже "проблема" что и у "товарища". Зачем мне кластер Proxmox, который как оказывается нефига не отказоустойчивый, зачем мне заводить в нем виртуалки, зачем разносить из на разные ноды? В данном случае или вообще не париться и поставить на железо без виртуалок, или использовать два обособленных гипервизора.
Да, я имел в виду vSphere 6.
Это вопрос терминологии. То, что у нас обычно называется "отказоустойчивостью", по-английски называется HA — high availability. Что в буквальном переводе означает "высокая доступность". В этом смысле рестарт виртуалок на оставшихся в живых гипервизорах — гораздо более высокая доступность, нежели отвал сервиса на физическом сервере.
Из более-менее production-ready технологий, обеспечивающих совсем уж "отказоустойчивые виртуалки", я знаю только VMware Fault Tolerance. Есть ещё Xen Remus, но там всё сыро, большие проблемы с производительностью, и главное, как ни странно — проблемы с устойчивостью таких отказоусточивых виртуалок — они часто крэшатся из-за вносимых технологией задержек исполнения инструкций.
Поэтому если вам реально нужно "ехать", а не просто шашечки, то для обеспечения отказоустойчивого СЕРВИСА можно использовать кластер HA из трёх и более хостов + гостевую кластеризацию. Логика будет такая:
Это вопрос терминологии. То, что у нас обычно называется "отказоустойчивостью", по-английски называется HA — high availability. Что в буквальном переводе означает "высокая доступность". В этом смысле рестарт виртуалок на оставшихся в живых гипервизорах — гораздо более высокая доступность, нежели отвал сервиса на физическом сервере.
Из более-менее production-ready технологий, обеспечивающих совсем уж "отказоустойчивые виртуалки", я знаю только VMware Fault Tolerance. Есть ещё Xen Remus, но там всё сыро, большие проблемы с производительностью, и главное, как ни странно — проблемы с устойчивостью таких отказоусточивых виртуалок — они часто крэшатся из-за вносимых технологией задержек исполнения инструкций.
Поэтому если вам реально нужно "ехать", а не просто шашечки, то для обеспечения отказоустойчивого СЕРВИСА можно использовать кластер HA из трёх и более хостов + гостевую кластеризацию. Логика будет такая:
- у вас гостевой кластер работает на разных гипервизорах;
- если гипервизор падает, работающий на нём узел гостевого кластера автоматически рестартует на любом из оставшихся узлов;
- гостевой кластер синхронизируется;
- у вас опять получается полный гостевой кластер.
Бесшовная отказоустойчивость a la VMware FT — это же не единственный бонус виртуализации. В большинстве случаев виртуализацией занимаются ради упрощения обслуживания за счёт отвязки от железа. Та же самая миграция ВМ между хостами нужна не только в случае падения хоста (да и в случае падения хоста поднять ВМ проще), миграция может быть запланированной — хост требует обслуживания или нужно изменить распределение ВМ по хостам.
Я точно такой-же делал (сервер AD + две ноды + СХД от IBM) всё работало. Делается failover cluster, настраиваете одну сеть для репликации (live migration), потом подключаете схд и делаете cluster shared storage (этот массив появляется в c:\cluster volume...) и потом все виртуалки складываете в эту папку. Виртуальные машины надо потом создавать как ресурсы кластера или конвертировать существующие в такие ресурсы.
Тоже самое делал и я :) И у вас при этом "не было ни единого разрыва" при отключении активной ноды?
Примерно на пальцах, говорим про винду
у вас есть уже кластер hyper-v из двух нод и общего строрейджа
поднимаете две виртуальные машины, и к обоим подключаем виртуальный диск кворума (сейчас не вспомню как в hyper-v это опция звучит в настройках жёсткого диска)
далее на виртуальным машинах поднимайте роль кластера с общим IP адресом ну и настраивайте его под свои нужны.
при выключении одной из физических нод, у вас в виртуальном кластере выпадет одна из нод и у вас отработает ваш виртуальный кластер, простоя минимум в худшем случае пару пакетов
у вас есть уже кластер hyper-v из двух нод и общего строрейджа
поднимаете две виртуальные машины, и к обоим подключаем виртуальный диск кворума (сейчас не вспомню как в hyper-v это опция звучит в настройках жёсткого диска)
далее на виртуальным машинах поднимайте роль кластера с общим IP адресом ну и настраивайте его под свои нужны.
при выключении одной из физических нод, у вас в виртуальном кластере выпадет одна из нод и у вас отработает ваш виртуальный кластер, простоя минимум в худшем случае пару пакетов
я ещё раз поковырял кластер, да вы правы — жму шляпу, снимаю руку )
Используем в работе, при обновлениях иногда меняется протокол (может нам повезло) и с одних нод уже не получается управлять другими, пока не обновишь все ноды.
Отличная статья, спасибо.
Хорошая статья, но в подобных решениях часто зацикливаются на отказоустойчивости узлов виртуализации и забывают про отказоустойчивость СХД (или всей SAN). В данном случае мы получаем кластер, работа которого зависит от одиночного сервера с Нексентой и одиночного свитча.
Конечно, если по условиям задачи клиента устраивает соответствующее RTO, то почему бы и нет. Только RTO нужно просчитать заранее:
— время замены свитча (взять новый из запасов на складе, или дожидаться замены по гарантии от поставщика, находящегося в 500 км)
— время восстановления СХД при различных сценариях. Например, переустановить Нексенту + восстановить данные из бэкапа или переключиться на использование резервной СХД на время диагностики/ремонта основной СХД.
Конечно, если по условиям задачи клиента устраивает соответствующее RTO, то почему бы и нет. Только RTO нужно просчитать заранее:
— время замены свитча (взять новый из запасов на складе, или дожидаться замены по гарантии от поставщика, находящегося в 500 км)
— время восстановления СХД при различных сценариях. Например, переустановить Нексенту + восстановить данные из бэкапа или переключиться на использование резервной СХД на время диагностики/ремонта основной СХД.
Все правильно, здесь мы упростили схему по максимуму.
Время простоя, можно минимизировать даже в бесплатном варианте.
Т.е. добавить в схему второй свитч(это недорого) + сделать в качестве Secondary Storage такую же Nexenta.
Переключение на другой сторадж, займет какое-то время, но это не сравнить с его заменой.
Схема работы двух хранилищ NexentaStor в режиме Active-Active конечно же есть, но уже за деньги.
Все зависит от желания и возможностей клиента. Можно сделать по разному.
Время простоя, можно минимизировать даже в бесплатном варианте.
Т.е. добавить в схему второй свитч(это недорого) + сделать в качестве Secondary Storage такую же Nexenta.
Переключение на другой сторадж, займет какое-то время, но это не сравнить с его заменой.
Схема работы двух хранилищ NexentaStor в режиме Active-Active конечно же есть, но уже за деньги.
Все зависит от желания и возможностей клиента. Можно сделать по разному.
Спасибо, интересная статья.
Товарищи, насколько сложно построить такую систему на базе «гиперконвергентной» платформы Supermicro 2022TG-HTRF?
Я так понимаю, в таком случае можно будет отказаться от Nexenta и задействовать Ceph, но я с ним ни разу не сталкивался.
Я так понимаю, в таком случае можно будет отказаться от Nexenta и задействовать Ceph, но я с ним ни разу не сталкивался.
Эта платформа (как и все остальные Supermicro Twin / 2U Twin2 / Fat Twin) сама по себе является не более «гиперконвергентной», чем аналогичный набор из 2/4/8 отдельных серверах. Строить что-нибудь гиперконвергентное на основе бесплатного софта — не сложнее и не проще.
Если требование бесплатности/открытость не на первом месте, то существуют готовые решения с поддержкой — тот же Nutanix, например, работает на Supermicro 2U Twin2 (с другой стороны, в случае готового решения — какая разница, на чем оно работает).
Если требование бесплатности/открытость не на первом месте, то существуют готовые решения с поддержкой — тот же Nutanix, например, работает на Supermicro 2U Twin2 (с другой стороны, в случае готового решения — какая разница, на чем оно работает).
Задача стоит переехать в виртуальную и отказоустойчивую среду в условиях крайне ограниченнго бюджета.
По большей части мне интересно узнать про две вещи:
1) имеют ли эти или подобные блэйды какой-то внутренний интерконнект, чтобы не гонять трафик Ceph по гигабитным сетевым картам.
2) есть ли уже такие реализации на Proxmox + Ceph и маны по ним?
По большей части мне интересно узнать про две вещи:
1) имеют ли эти или подобные блэйды какой-то внутренний интерконнект, чтобы не гонять трафик Ceph по гигабитным сетевым картам.
2) есть ли уже такие реализации на Proxmox + Ceph и маны по ним?
В том-то и дело, что у этих штук из общего с блейдами только плотность размещения и консолидация питания, т.е. никаких модульных свитчей. В некоторых 2U Twin2 и FatTwin есть один набортный порт InfiniBand, в некоторых — два порта 10GBASE-T вместо гигабитных + есть низкопрофильный слот PCI-E.
Шаг в сторону блейдов в небольших шасси — это MicroBlade в 3U варианте: 14 серверных модулей (в т.ч. и под 2x E5-2600v3 с двумя 10GbE) + пара свитчей.
У Супермикры есть список конфигураций для цефостроения, но именно у меня опыта с реализацией нет. В таких случаях наши заказчики занимаются самовнедрением. В вики у Proxmox есть описание решения с Ceph, в том числе гиперконвергентного.
Но самое главное — супермикровские Twin, Microcloud и другую экзотику нельзя использовать в небольших проектах, где речь идёт об 1-2 шасси, т.е. когда вы не готовы внезапно потерять на месяц 1–2 сервера или даже всё шасси целиком. Мы, например, держим на складе ЗиП для блейдов, а экзотику — только под крупные проекты и/или при наличии договора на расширенную поддержку. Примеры:
1) У заказчика два FatTwin 4-в-1. Выходит из строя PDB (плата распределителя питания). Их два в шасси, каждый питает два сервера. Заказчик расстроен потерей двух серверов. Через 4 недели приходит замена, но к шасси не подходит. За это время Supermicro успела сменить ревизию шасси и ревизию этих PDB. Приходится ждать ещё 4 недели.
2) В Твине выходит из строя контроллер SAS. Заказчик от нас далеко, сервисный контракт или ЗиП для самостоятельной замены не покупал. Мы бы и рады помочь, выслав подменный контроллер но форм-фактор у RAID-контроллера для Твинов нестандартный, придётся ждать.
Шаг в сторону блейдов в небольших шасси — это MicroBlade в 3U варианте: 14 серверных модулей (в т.ч. и под 2x E5-2600v3 с двумя 10GbE) + пара свитчей.
У Супермикры есть список конфигураций для цефостроения, но именно у меня опыта с реализацией нет. В таких случаях наши заказчики занимаются самовнедрением. В вики у Proxmox есть описание решения с Ceph, в том числе гиперконвергентного.
Но самое главное — супермикровские Twin, Microcloud и другую экзотику нельзя использовать в небольших проектах, где речь идёт об 1-2 шасси, т.е. когда вы не готовы внезапно потерять на месяц 1–2 сервера или даже всё шасси целиком. Мы, например, держим на складе ЗиП для блейдов, а экзотику — только под крупные проекты и/или при наличии договора на расширенную поддержку. Примеры:
1) У заказчика два FatTwin 4-в-1. Выходит из строя PDB (плата распределителя питания). Их два в шасси, каждый питает два сервера. Заказчик расстроен потерей двух серверов. Через 4 недели приходит замена, но к шасси не подходит. За это время Supermicro успела сменить ревизию шасси и ревизию этих PDB. Приходится ждать ещё 4 недели.
2) В Твине выходит из строя контроллер SAS. Заказчик от нас далеко, сервисный контракт или ЗиП для самостоятельной замены не покупал. Мы бы и рады помочь, выслав подменный контроллер но форм-фактор у RAID-контроллера для Твинов нестандартный, придётся ждать.
Хотелось бы конечно, использовать Starwind или FreeNAS (NAS4Free), но если одному для работы нужен Windows и шаманство с ISCSI, то у другого функция кластеризации не предусмотрена вообще.
Однако, у Nas4Free (или FreeNAS) есть кластеризация. Называется HAST (+ CARP).
Пару лет назад тоже выбирал платформу для бюджетного софтового дискового хранилища, пробовал нексенту и нас4фри. Остановился на последнем варианте, потому что нексента показалась мне бедной по функционалу, при том тяжеловесной и чрезмерно требовательной к ресурсам.
Эта схема в продакшене работала?
Я пробовал около полугода назад на VMware поднять тестовый кластер из nas4free.
Собирается, реплицирует между собой данные, но вот добиться автоматического восстановления или устойчивой работы не удалось.
Возможно, из-за некорректной настройки виртуальных сетевых интерфейсов. Железа для теста на физике не хватило.
Я пробовал около полугода назад на VMware поднять тестовый кластер из nas4free.
Собирается, реплицирует между собой данные, но вот добиться автоматического восстановления или устойчивой работы не удалось.
Возможно, из-за некорректной настройки виртуальных сетевых интерфейсов. Железа для теста на физике не хватило.
Пару лет использую Nas4Free в качестве Shared Storage для виртуалок, для бэкапов и в качестве Samba-шар, однако HAST не пользовался, т.к. эта фича довольно долгое время была в состоянии экспериментальной.
Тоже пробовал поднимать хранилище из-под виртуалки, но понял что это не есть гуд — страдает производительность, и как пишут — файловая система ZFS лучше работает с физическими накопителями, нужно как минимум пробрасывать HBA-контроллер в гостевую систему.
Тоже пробовал поднимать хранилище из-под виртуалки, но понял что это не есть гуд — страдает производительность, и как пишут — файловая система ZFS лучше работает с физическими накопителями, нужно как минимум пробрасывать HBA-контроллер в гостевую систему.
P.S.
Для работы CARP в виртуальных окружениях требуется доп. настройка гипервизора.
Для примера вот описание настройки CARP в Pfsense под гипервизором.
Собирается, реплицирует между собой данные, но вот добиться автоматического восстановления или устойчивой работы не удалось.
Для работы CARP в виртуальных окружениях требуется доп. настройка гипервизора.
Для примера вот описание настройки CARP в Pfsense под гипервизором.
Среди перечисленных пунктов были выполнены с 1 по 3:
1) Enable promiscuous mode on the vSwitch
2) Enable "MAC Address changes"
3) Enable "Forged transmits"
4) If multiple physical ports exist on the same vswitch, the Net.ReversePathFwdCheckPromisc option must be enabled to work around a vswitch bug where multicast traffic will loop back to the host, causing CARP to not function with "link states coalesced" messages. (See below)
1) Enable promiscuous mode on the vSwitch
2) Enable "MAC Address changes"
3) Enable "Forged transmits"
4) If multiple physical ports exist on the same vswitch, the Net.ReversePathFwdCheckPromisc option must be enabled to work around a vswitch bug where multicast traffic will loop back to the host, causing CARP to not function with "link states coalesced" messages. (See below)
Спасибо за замечание, исправлю. Здесь акцент на то, что доступно из коробки и Production-Ready.
Действительно, их(FreeNAS (NAS4Free)) можно допилить до кластера.
Но можно ли рекомендовать получившееся решение в Production?
Лично я бы не стал.
Действительно, их(FreeNAS (NAS4Free)) можно допилить до кластера.
Но можно ли рекомендовать получившееся решение в Production?
Лично я бы не стал.
Действительно, несколько человек отметили единую точку отказа — СХД. Почему бы не воспользоваться DRBD, который поддердивается ProxMoxом из коробки?
Sign up to leave a comment.
Бесплатный кластер (Proxmox + Nexenta)