Вобщем мне абсолютно обязательно bare metal ZFS ноды, и потом чем-то задублировать их zvols.

HAST поверх zvol IMHO идеально, или любые другие несложные аналоги HAST. Причем ради сравнения можно сделать одну ноду на OpenZFS, а другую на Illumos. Zvol блоки то у них универсально совместимые получаются на выходе. Это вероятно снижает опасность влияния потенциальных багов в однотипном софте хранилок низкого к железу уровня .

Ты предлагаешь колхозить свое решение для синхронизации

Ты предлагаешь колхозить свое решение для синхронизации

HAST - это ведь готовое?

Лучше конечно максимум готового.

Сколько тысяч установок на нем есть?

Сколько тысяч установок на нем есть?

Я не предлагаю прям точно FreeBSD HAST, но какие-нибудь аналоги. Якобы DRBD - аналог, он более популярен? А есть и другие, Gluster, GPFS, но они сложнее.

https://upload.wikimedia.org/wikipedia/commons/5/5b/DRBD_concept_overview.png

Одну ноду поднять на SmartOS, вторую на Proxmox. Объединить их zvols в DRBD HA, соответственно линупсы для DRBD пусть работают в виртуалках, куда проброшены zvols в виде виртуальных блочных устройств. Если время выявит нестабильность хостовой оси одного из узлов, то потом можно оставить одну зарекомендовавшую себя хостовую ось на обоих узлах.

И ждать когда это со звоном упадёт

И ждать когда это со звоном упадёт

Упадет быстрее, чем просто одиночный хост SmartOS без вые***ов?

И ждать когда это со звоном упадёт

И это не для бэкапов ессно, а только для HA прода, где важен именно SLA, а не теоретический риск потери данных.

И ждать когда это со звоном упадёт

В точку 😁

В точку 😁

Поверх дублированного блока может работать софт с проверкой целостности типа IBM Db2 прямо на блочном без FS или опять еще одна ZFS для файликов, они сразу же заметят любые отклонения в целостности данных. "Highly available" refers to accessibility, not the reliability of the storage. An HA system is a tricky thing to do, correctly, and also ensure good performance. There are partitioning issues and other fun stuff. A typical HA system is actually a bit risky to the data, because there are more vectors for things to go wrong ... and badly wrong at that. This is important to companies where you are running a service and want to come as close to 100% uptime as possible.

я вот кстати думал как-то над HA зфс стораджем (фц таргет или айскази - неважно). Кончилось тем, что не было оборудования идею обкатать.

Что-то типа этого? https://rawdr.org/rawdr/

и https://github.com/ewwhite/zfs-ha/wiki

Что-то типа этого? https://rawdr.org/rawdr/

О, прикольно. Похоже, да :)

и https://github.com/ewwhite/zfs-ha/wiki

А можно эту хрень поднять на дедиках Хетцнер/Контабо?

В описании мужик все сам собирает, в целом так вернее будет, но все же)

Хотя... shared storage он и в Африке шаред

Можно ли у пула заменить его числовой GUID ?

Похоже штатно нельзя: https://zfs-discuss.opensolaris.narkive.com/QjeTN3hY/changing-guid

Поверх дублированного блока может работать софт с проверкой целостности типа IBM Db2 прямо на блочном без FS или опять еще одна ZFS для файликов, они сразу же заметят любые отклонения в целостности данных. "Highly available" refers to accessibility, not the reliability of the storage. An HA system is a tricky thing to do, correctly, and also ensure good performance. There are partitioning issues and other fun stuff. A typical HA system is actually a bit risky to the data, because there are more vectors for things to go wrong ... and badly wrong at that. This is important to companies where you are running a service and want to come as close to 100% uptime as possible.

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

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

+1

А вообще, зачем пытаться использовать zfs как кластерное решение, если оно изначально не кластерное?

А вообще, зачем пытаться использовать zfs как кластерное решение, если оно изначально не кластерное?

+ так о том и речь

есть цепф, всан и на крайняк сторедж директ

наверняка еще пачка других

Ну да, тут 2 варианта - либо у тебя программный продукт сам умеет в кластеризацию и распределение своихх данных по своим репликам, тогда можно накатить это на независимые ФС - или нет, тогда берешь решение которое это обеспечит. А брать то, которое не для этого и поверх него колхозить какие-то неродные ему сущности - вдвойне колхоз

если сможешь воспроизвести ситуацию - будет прекрасно.

Настроил в линоде iSCSI target на одном хосте Alpine и iSCSI клиента на другом хосте Devuan через приватный нетарифицируемый VLAN. С прицелом в будущем на использование других хостеров для разных частей зеркал, у них цены бывают в разы ниже Линоды, до 5 раз и более. Создал пул на Devuan из нескольких remote iSCSI блоков с Alpine. Попробовал реплицировать датасеты с прерыванием по Ctrl+C По умолчанию без -s на приемнике никаких токенов не создается. При указании -s появляется возможность продолжить до ближайшего незавершенного снэпшота, рулез. Но у меня ведь раньше при возникновении проблем с блокировкой датасета на приемнике не использовалась опция -s на приемнике, почему тогда отвисали датасеты после прерывания?

Ну да, тут 2 варианта - либо у тебя программный продукт сам умеет в кластеризацию и распределение своихх данных по своим репликам, тогда можно накатить это на независимые ФС - или нет, тогда берешь решение которое это обеспечит. А брать то, которое не для этого и поверх него колхозить какие-то неродные ему сущности - вдвойне колхоз

Вероятно все, кто пишут про необходимость единого и готового интегрированного решения HA хранилки для прода правы в общем случае, но мне хотелось бы именно open source на базе ZFS сначала just for fun. Я пока не тащу это в прод, мне просто интересно.

А вообще, зачем пытаться использовать zfs как кластерное решение, если оно изначально не кластерное?

ZFS - это с моей точки зрения самый надежный способ работы с baremetal дисками. Я доверяю ZFS для низкоуровнего хранения данных намного больше, чем всевозможным LVM, CEPH и уж тем более Microsoft. Мне очень нравится Microsoft близко к юзерам для GUI в связке с DevExpress XAF, но хранилки и СУБД лучше бы без них. PG и Db2 - вот это норм. Хотелось бы найти open source вариант "сильно упрощенный Lustre для нищебродов" ессно на базе ZFS.

ZFS - это с моей точки зрения самый надежный способ работы с baremetal дисками. Я доверяю ZFS для низкоуровнего хранения данных намного больше, чем всевозможным LVM, CEPH и уж тем более Microsoft. Мне очень нравится Microsoft близко к юзерам для GUI в связке с DevExpress XAF, но хранилки и СУБД лучше бы без них. PG и Db2 - вот это норм. Хотелось бы найти open source вариант "сильно упрощенный Lustre для нищебродов" ессно на базе ZFS.

Тут идёт сравнение тёплого с мягким.

Раз уж на то пошло, то и на лвм том же, правильно его приготовив, можно сделать хранилку с приемлемым уровнем надёжности.

Если рассматривать хранилку как сервис

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

Раз уж на то пошло, то и на лвм том же, правильно его приготовив, можно сделать хранилку с приемлемым уровнем надёжности.

Мне не хочется изучать 100500 разных LVMов, я лучше изучу варианты реализации ZFS типа OmniOS и SmartOS.

Чтобы выбрать решение из нескольких, надо их изучить все.

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

HA каталог, расшаренный по NFS для образов файловых систем виртуалок, с низкой IO нагрузкой. Вся нагрузка будет в СУБД, а там свой HA, отдельный от NAS.

А где тут зфс?

А где тут зфс?

ZFS - должна быть прослойкой между аппаратными дисками и NAS каталогом.

Мне не хочется изучать 100500 разных LVMов, я лучше изучу варианты реализации ZFS типа OmniOS и SmartOS.

серебряной пули нет, если что

ZFS - должна быть прослойкой между аппаратными дисками и NAS каталогом.

С какой целью?

ZFS - это с моей точки зрения самый надежный способ работы с baremetal дисками. Я доверяю ZFS для низкоуровнего хранения данных намного больше, чем всевозможным LVM, CEPH и уж тем более Microsoft. Мне очень нравится Microsoft близко к юзерам для GUI в связке с DevExpress XAF, но хранилки и СУБД лучше бы без них. PG и Db2 - вот это норм. Хотелось бы найти open source вариант "сильно упрощенный Lustre для нищебродов" ессно на базе ZFS.

^

Аргументируй необходимость использования ЗФС, которая не про ХА, в ХА решении.

Аргументируй необходимость использования ЗФС, которая не про ХА, в ХА решении.

Не доверяю CEPH, как он работает с железяками по крайне мере по сравнению с ZFS.

Не доверяю CEPH, как он работает с железяками по крайне мере по сравнению с ZFS.

Что именно в нем не устраивает?

Конкретика

Это не аргумент, как ты понимаешь :)

Это не аргумент, как ты понимаешь :)

Лучше эту тему вероятно прекратить, потому что у нас разные ценности при оценке надежности софтовых решений, превращаюих физические блоки в транзакционные с контролем целостности данных.

ХА это так и так про репликацию - тут ты от этого никуда не денешься.

Требования по RTO/RPO какие?

Лучше эту тему вероятно прекратить, потому что у нас разные ценности при оценке надежности софтовых решений, превращаюих физические блоки в транзакционные с контролем целостности данных.

Оценка надёжности проверяется всесторонними тестами, к слову.

Оценка надёжности проверяется всесторонними тестами, к слову.

Что бы эти тесты не показали, никогда не поверю, что отдельно взятые узлы цефа хранят данные надежнее одиночных узлов ZFS.

Что бы эти тесты не показали, никогда не поверю, что отдельно взятые узлы цефа хранят данные надежнее одиночных узлов ZFS.

ХА это уже сервис, а мы пока даже не определили требования к этому сервису по доступности, не говоря уж о надёжности.

Тебе не нужен этот сервис. Видимо ты написал про него так, чтоб разговор поддержать.

Тебе не нужен этот сервис. Видимо ты написал про него так, чтоб разговор поддержать.

Это "прекрасно", когда за меня определяют, что мне нужно, а что ненужно.

Вот ты опять редактируешь свои сообщения. Просто смешно :)

Вот ты опять редактируешь свои сообщения. Просто смешно :)

Промазал мышкой в браузере, сегодня сильно не выспался :(

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

What Every Programmer Should Know About SSDs https://databasearchitects.blogspot.com/2021/06/what-every-programmer-should-know-about.html

What Every Programmer Should Know About SSDs https://databasearchitects.blogspot.com/2021/06/what-every-programmer-should-know-about.html

Это к слову, почему иногда л2арк или слог тормозят

Коллеги, у меня по дискуссии выше вопрос назрел насчёт HA Сейчас я использую ZFS-репликацию между нодами. Это псевдо-HA, я понимаю. Но мне норм. Но тру-HA для хранилки в таком случае это что вообще? Какие критерии? Пример: есть БД, которая интенсивно пишет. Сторадж при этом HA. Одна нода хранилки падает. Настоящее HA реально обеспечит мне 0 простоя и 0 потери данных?

Хочется просто понять, чего я лишён с ZFS )

Чтобы выбрать решение из нескольких, надо их изучить все.

+100%

ZFS - должна быть прослойкой между аппаратными дисками и NAS каталогом.

ну если тебе так хочешься зфс, поставь цепф в виртуалке на зфс

Коллеги, у меня по дискуссии выше вопрос назрел насчёт HA Сейчас я использую ZFS-репликацию между нодами. Это псевдо-HA, я понимаю. Но мне норм. Но тру-HA для хранилки в таком случае это что вообще? Какие критерии? Пример: есть БД, которая интенсивно пишет. Сторадж при этом HA. Одна нода хранилки падает. Настоящее HA реально обеспечит мне 0 простоя и 0 потери данных?

У классических промышленных РСУБД (не share all) обычно свой HA, который более оптимален для СУБД? HA хранилки нужны обычно для других кейсов?

Коллеги, у меня по дискуссии выше вопрос назрел насчёт HA Сейчас я использую ZFS-репликацию между нодами. Это псевдо-HA, я понимаю. Но мне норм. Но тру-HA для хранилки в таком случае это что вообще? Какие критерии? Пример: есть БД, которая интенсивно пишет. Сторадж при этом HA. Одна нода хранилки падает. Настоящее HA реально обеспечит мне 0 простоя и 0 потери данных?

VSAN. указываешь на сколько копий бить. любой сервак можешь выключить, а время выключения, все данные предназначенные для этого сервера пишутся на другие сервера. если сервер недоступен больше заданного времени, начинается построение новой копии на оставшихся серверах

итого: все очень ХА, можно добавлять вынимать диски, все очень быстрое

но очень дорого и хочет 10g

У классических промышленных РСУБД (не share all) обычно свой HA, который более оптимален для СУБД? HA хранилки нужны обычно для других кейсов?

Ну да... но БД это лишь один пример. Конкретное мне вирт машины интереснее

Ну да... но БД это лишь один пример. Конкретное мне вирт машины интереснее

тем более всан

но есть одно но: ESX only

но очень дорого и хочет 10g

10g-то не проблема, а вот дороговизна и проприетарность... Это ж строго VMware?

Коллеги, у меня по дискуссии выше вопрос назрел насчёт HA Сейчас я использую ZFS-репликацию между нодами. Это псевдо-HA, я понимаю. Но мне норм. Но тру-HA для хранилки в таком случае это что вообще? Какие критерии? Пример: есть БД, которая интенсивно пишет. Сторадж при этом HA. Одна нода хранилки падает. Настоящее HA реально обеспечит мне 0 простоя и 0 потери данных?

Любая нормальная двухконтроллерная СХД это обеспечивает.

10g-то не проблема, а вот дороговизна и проприетарность... Это ж строго VMware?

да. но работет хорошо. обновление без простоев

Любая нормальная двухконтроллерная СХД это обеспечивает.

Так она же всё равно SPOF?

VSAN. указываешь на сколько копий бить. любой сервак можешь выключить, а время выключения, все данные предназначенные для этого сервера пишутся на другие сервера. если сервер недоступен больше заданного времени, начинается построение новой копии на оставшихся серверах

Vsan та ещё шляпа касаемо скорости

Так она же всё равно SPOF?

Для этих рисков делается метрокластер из 2 СХД.

С надёжностью все норм, а вот быстродействие оставляет желать лучшего