Назад | Перейти на главную страницу

дешевая, высокодоступная распределенная файловая система на базе аппаратного обеспечения

У меня есть два компьютера под управлением Linux, диск на 2 ТБ каждый и один небольшой гигабитный коммутатор. Чтобы построить высокодоступную систему по дешевке, я прибег к следующему стеку:

  1. кастомное ядро ​​5.6 с ZFS и DRBD9 на обоих ПК.
  2. по одному зволу в разделе каждого локального диска каждого ПК - сжатие включено, дедупликация отключена (пробовал включить сжатие, все плохо виснет)
  3. двойной первичный DRBD9 для зеркалирования между ними
  4. OCFS2 сверху, чтобы смонтировать получившееся устройство на обоих ПК

Третья очень старая машина действует как арбитр DRBD, не имея фактического дискового пространства, участвующего в зеркале DRBD.

Второй коммутатор и вторая сетевая карта прибывают для повышения доступности.

Хотелось бы понять, есть ли более простой стек для достижения того же результата. Я уже отказался от некоторых опций, исходя из моих текущих знаний: Lustre (слишком сложно для небольших сред), BeeGFS (не обновляется), GlusterFS (не работает с необработанными устройствами, только с подключенными папками)

РЕДАКТИРОВАТЬ - меня попросили сосредоточиться на одном вопросе. Поскольку на первый был дан ответ, я оставил вторую.

Вы объединяете кластерные файловые системы с распределенной файловой системой.

С настройкой ZVOL + DRBD + OCFS2 вы достигли кластерной файловой системы «без совместного использования», в которой DRBD имитирует настоящий SAN с разделяемыми блоками, а OCFS2 (или GFS2) обеспечивает одновременное монтирование нескольких головных узлов. В этой конфигурации вы можете не уровни подкачки 2 и 3 (например: DRBD + ZVOL + OCFS2), потому что ZFS не является файловой системой кластера - если она установлена ​​на двух разных хостах, она очень быстро повредит себя (это верно даже для ZVOL, которые представляют собой не более чем скрытые файлы). в корневом наборе данных ZFS).

Lustre, Gluster, Ceph и т. Д. Представляют собой распределенную файловую систему: они используют индивидуальную файловую систему / поля / базы данных на каждом хосте, которые объединяются на уровне пользовательского пространства в единую файловую систему, охватывающую несколько хостов (то есть распределенную).

Как выбрать один из двух подходов? Это зависит от нескольких факторов:

  • если холодная, асинхронная репликация достаточна, вы можете использовать zfs send/recv и назови это днем

  • если требуется настоящая репликация в реальном времени, но не требуется жесткая / немедленная HA и возможна ручная отработка отказа, вы можете использовать DRBD в одноосновном режиме и полностью исключить накладные расходы на файловую систему кластера (например, использование простой XFS вместо OCFS2 / GFS2)

  • если он используется для большого файлового хранилища (например, виртуальных образов) и с небольшим количеством хостов, ваш текущий подход, вероятно, будет лучшим (за счет дополнительной сложности и снижения производительности). Если у вас много узлов, GlusterFS (с правильными параметрами - sharding быть первым) может быть разумным выбором, но конечно следить за списком рассылки (в нем много ошибок)

  • если вам нужен «большой NAS» для хранения большого количества файлов среднего размера (1-128M), GlusterFS в режиме реплики может быть правильным выбором (опять же, обязательно следите за списком рассылки)

  • если у вас много узлов и большой ресурс системного администратора (читай: выделенная команда), вы можете рассмотреть Lustre или Ceph, которые являются опциями более высокого уровня в распределенной файловой системе.

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

ПРИМЕЧАНИЕ: вы можете читать Вот для дополнительной информации