Я рассматриваю архитектуру на основе ZFS / iSCSI для платформы баз данных высокой доступности / горизонтального масштабирования / без совместного использования, работающей на слабых узлах обычного оборудования ПК и работающей под управлением FreeBSD 9.
Это будет работать? Какие возможные недостатки?
Архитектура
Узлы хранения имеют прямые подключенные дешевые диски SATA / SAS. Каждый диск экспортируется как отдельный iSCSI LUN. Обратите внимание, что на этом уровне не используется RAID (ни аппаратное, ни программное обеспечение), разбиение на разделы, управление томами или что-либо подобное. Всего 1 LUN на физический диск.
Узлы базы данных работают под управлением ZFS. Зеркальный vdev ZFS создается из iSCSI LUN из 3 разные узлы хранения. Пул ZFS создается поверх vdev, а внутри него файловая система, которая, в свою очередь, поддерживает базу данных.
При выходе из строя диска или узла хранения соответствующий ZFS vdev продолжит работу в режиме пониженной производительности (но по-прежнему будет иметь 2 зеркальных диска). Другой (новый) диск назначается vdev для замены отказавшего диска или узла хранения. Выполняется перенос обновлений ZFS. Отказавший узел хранения или диск всегда полностью перерабатывается, если он снова становится доступным.
При выходе из строя узла базы данных LUN, которые ранее использовались этим узлом, освобождаются. Загружается новый узел базы данных, который воссоздает ZFS vdev / pool из оставшихся LUN отказавшего узла базы данных. Репликация на уровне базы данных не требуется по причинам высокой доступности.
Возможные проблемы
Как обнаружить деградацию vdev? Проверять каждые 5 секунд? Есть ли в ZFS механизм уведомления?
Возможно ли вообще воссоздать новый пул из существующих LUN, составляющих vdev? Есть ловушки?
Это не прямой ответ на ваш вопрос, но более традиционная архитектура для такого рода вещей будет использовать HAST и Карп позаботиться о избыточности хранилища.
Базовый план (подробности см. В связанной документации):
Большое предостережение заключается в том, что HAST работает только на уровне Master / Slave, поэтому вам нужны пары машин для каждого LUN / набора LUN, которые вы хотите экспортировать.
Еще одна вещь, о которой следует знать, - это то, что ваша архитектура хранилища не будет такой гибкой, как с предложенным вами дизайном:
С HAST вы ограничены количеством дисков, которые вы можете вставить в пару машин.
С предложенной вами сеткообразной структурой ISCSI вы теоретически можете добавить больше машин, экспортирующих больше LUN, и вырасти столько, сколько захотите (до предела вашей сети).
Этот компромисс в гибкости дает вам проверенное, проверенное, документированное решение, которое любой администратор FreeBSD поймет из коробки (или сможет прочитать руководство и выяснить) - для меня это стоящий компромисс :-)
«zpool status -x» выведет, все ли пулы исправны, или выведет статус тех, которые не работают. Если iSCSI LUN vdev отключается, задание cron, запускающее сценарий, основанный на этой команде, должно дать вам возможность регулярно получать предупреждения cron.
"zpool import" должен иметь возможность импортировать существующий zpool из vdevs iSCSI LUN. Возможно, вам придется принудительно выполнить импорт, если пул не был экспортирован чисто, но внутренние метаданные должны сохранять данные в согласованном состоянии, даже если запись была прервана из-за сбоя узла базы данных.