Комментарии 36
А почему в списке вариантов нет cephfs? Из которобки отличная fault tolerance и наработанные практики, плюс мощное кеширование метаданных, плюс точно хорошо работающее масштабирование? Я понимаю, что сам cephfs сильно свежее, чем ceph, но даже не рассматривать его в списке вариантов - странно.
Сейчас ZFS хорошо работает и по Linux. Портированы много новых фич.
Хотя у меня есть похожий проект, в котором в 2011 году сделали "временное" решение на FreeBSD+ZFS. Объёмы вырос уже вдвое, но все ещё работает. На том же само оборудовании. 🙂
Прелесть "промышленных" OSS решений.
Очень бы хотелось подробности реализации второй схемы с ZFS ( хотябы общую схему детально)
GLUSTER не дружит с vmware даже в новых версиях, нет заявленной поддержки, как я понял, более того нет ответа в тредах с проблемами с Vmware
Но это же про холодный бэкап, а не про продуктив с которым почему то сравнивают цену. Каково время ребилда при замене диска? Деградация производительности при ребилде? А если несколько дисков на одном и/или разных холстах? Возможность и время замены всех дисков на новые большего объема? Ведь найти семилетний давности становится сложнее. Что с предсказанием поломки дисков? Руками на каждом хосте?
Вообще сделать и продать самопал - всегда история успеха с громадной экономией. Тот кто так сделал и исчез в тумане - успешный рыцарь на белом коне. Намного интереснее услышать эту историю от людей которые это обслуживают и живут с этим. Но они почему-то не пишут как им хорошо от того что кто-то отчитался об экономии на закупке...
Я не автор, но рискну предположить:
Время ребилда большое, все как обычно так как за ребилд обычные контроллеры отвечают.
Деградация значительная. ZFS ничего не знает про ребилд экспортированных iSCSI, с ее точки зрения просто вдруг диск начинает тормозить, благо за счет CoW может это и не заметно будет, а может неповезет и будет заметно.
При ребилде нескольких дисков будет еще заметнее, а при ребилде на разных хостах еще заметнее.
Заменить диски на больший объем можно, но пространства в пуле видимо больше не станет. Поэтому точно такие же диски искать не нужно, ну а если хочется в разы более емкие диски вставить, то видимо нужен новый пул и миграция.
Если заменить все диски на бОльший объем, то пул без проблем растягивается на этот объем, один минус - его придется экспортировать и импортировать, т.е. будет небольшой период в оффлайне.
Можно чуть подробнее?
Допустим у меня есть 10 дисков по 1ТБ в raidz1. Доступная емкость: 1 ТБ * (10-1) = 9ТБ.
Я решил увеличить пул, в два раза, купил 1 диск на 10 ТБ и обломался.
Из вашего предложения я понял решение задачи таким:
Надо взять 9 ТБ данных и куда-нибудь скопировать, достать 10 дисков по 1 ТБ и вставить вместо ВСЕХ старых дисков новые по 2 ТБ, собрать raidz1 заново на новых дисках и получится 2 ТБ * (10-1) = 18 ТБ доступной емкости? На эту операцию мне дополнительно надо где-то разместить всю занятую емкость пула (то есть заиметь еще такую же хранилку). Так это, извините, не расширить пул, а уничтожить пул и создать заново.
В ситуации с 1 диском на 10 терабайт я бы мог предложить только добавление десятка vdev к существующему массиву, расположенных на этом диске. Теоретически, такое решение возможно, но вот его целесообразность сомнительна.
При замене дисков в 1 терабайт на диски по 2 терабайта не требуется ничего копировать, достаточно вывести старый диск в оффлайн, подключить новый диск к компу и дать команду "zpool replace" с указанием заменяемого диска и дождаться, пока пройдет resilver. Итерацию придется повторить столько раз, сколько у Вас дисков.
После этого нужно сделать экспорт и импорт пула, чтобы увидеть новый объём.
После этого нужно сделать экспорт и импорт пула, чтобы увидеть новый объём.
это ещё зачем?
содаём пул
root@zfs-test2:~# truncate -s 10G file1 file2
root@zfs-test2:~# zpool create -f test mirror /root/file1 /root/file2
root@zfs-test2:~# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 9.50G 104K 9.50G - - 0% 0% 1.00x ONLINE -
mirror 9.50G 104K 9.50G - - 0% 0.00% - ONLINE
/root/file1 - - - - - - - - ONLINE
/root/file2 - - - - - - - - ONLINE «увеличиваем» диски, пока всё так же
root@zfs-test2:~# truncate -s 20G file1 file2
root@zfs-test2:~# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 9.50G 104K 9.50G - - 0% 0% 1.00x ONLINE -
mirror 9.50G 104K 9.50G - - 0% 0.00% - ONLINE
/root/file1 - - - - - - - - ONLINE
/root/file2 - - - - - - - - ONLINE говорим zfs, что надо актуалиризовать размер пула
root@zfs-test2:~# zpool online -e test /root/file1
root@zfs-test2:~# zpool online -e test /root/file2
root@zfs-test2:~# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 19.5G 164K 19.5G - - 0% 0% 1.00x ONLINE -
mirror 19.5G 164K 19.5G - - 0% 0.00% - ONLINE
/root/file1 - - - - - - - - ONLINE
/root/file2 - - - - - - - - ONLINE
root@zfs-test2:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
test 146K 18.9G 24K /testто же самое и с заменой дисков
root@zfs-test2:~# truncate -s 30G file1a file2a
root@zfs-test2:~# zpool replace test /root/file1 /root/file1a
root@zfs-test2:~# zpool replace test /root/file2 /root/file2a
root@zfs-test2:~# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 19.5G 252K 19.5G - - 0% 0% 1.00x ONLINE -
mirror 19.5G 252K 19.5G - - 0% 0.00% - ONLINE
/root/file1a - - - - - - - - ONLINE
/root/file2a - - - - - - - - ONLINE
root@zfs-test2:~# zpool online -e test /root/file1a
root@zfs-test2:~# zpool online -e test /root/file2a
root@zfs-test2:~# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
test 29.5G 156K 29.5G - - 0% 0% 1.00x ONLINE -
mirror 29.5G 156K 29.5G - - 0% 0.00% - ONLINE
/root/file1a - - - - - - - - ONLINE
/root/file2a - - - - - - - - ONLINE Как раз лет 6 назад у нас был похожая работа, но мы выбрали moosefs. Не знаю даже сейчас этот проект жив или нет.
и в каждой из этих папок — по миллиону небольших файлов
не самое лучшее решения, скажем прямо, далеко не всё оптимизировано под каталоги с таким большим числом элементов. даже ls по умолчанию сортирует список файлов, будут вполне ощутимые задержки.
обычно всё-таки делают каталоги нескольких уровней вложенности, чтобы число элементов в каждом каталоге исчислялось тысячами
Видимо такие условия.
Мне как-то попал диск от знакомого, из китайского медиапроигрывателя (при чём хороший по тем меркам, куплен был в Китае во время проживания там, не с Алиэкспресс) для восстановления данных, так этот проигрыватель очень странно писал данные: миллионы файлов в корне. И много-много папок, в которых также было громадное количество файлов. И всё это на диске 1Тб.
А изначально на нём держали видео, музыку, фото и остальное, эдакий комбайн.
Восстановили вроде как практически всё, а что с этим делать - не знали, так и отдал мешанину
Когда тестировал GlusterFS, листинг директории в нем дико тормозил даже при небольшом количестве файлов (локально листинг работал быстро). Народ где-то писал, что эта ФС предполагалась для хранения дисков виртуалок, поэтому создатели не предполагают использование с большим количеством файлов.
На всякий случай скажу что в open source есть уже готовое решение:
https://github.com/LINBIT/linstor-gateway
LINSTOR можно накатить поверх ZFS и получить отказоустойчивый сторадж с репликацией, снапшотами, автоматическими бэкапами и прочими плюшками
Файлопомойки на SMB - это тот еще архитектурный эпик, который в общем говорит о проблемах в архитектуре ПО, раз оно такое там потребовалось.
По SMB в большой файлопомойке:
- управлять правами неудобно;
- если "да точно было, куда делось?", то виноватого в удалении скорее всего не найдешь;
- навигация неудобна (ограничение на символы в названиях, один родитель у файла или папки, ограничения на длину файла и уровень вложенности;
- проблемы с совместной работой (сложно делиться доступом, контролировать кто к чему имеет, видеть ссылки только на те папки, на которые есть доступ и т.д.).
То есть SMB лучше вообще не использовать. А если SMB не использовать, а говорить про какой-то веб-сервис для большого количества файлов, то архитектура уже другая будет разумна.
оворить про какой-то веб-сервис для большого количества файлов
а можно пример удобного веб-интерфейса?
Этот класс ПО называется digital asset management. Я его давно смотрел, поэтому актуальные интерфейсы не могу рекомендовать, но в реестре видел и российское ПО.
Из популярного можно на NextCloud посмотреть, хотя он обычно относится не к DAM, а к коллективной работе и несколько тормозной. NextCloud умеет отдавать папки по webdav, то есть можно монтировать в Windows как диск. Но webdav у него совсем тормозной.
>управлять правами неудобно;
если SMB, то это обычно виндовая инфраструктура, права на каталоги ставятся как обычно. Кто хочет галочками через интерфейс, кто хочет и через командную строку.
>если "да точно было, куда делось?", то виноватого в удалении скорее всего не найдешь;
Включается аудит на удаление файлов. Умеет Windows, умеет samba, дальнейшие логи отправляются куда угодно.
>один родитель у файла или папки
Это как?
>То есть SMB лучше вообще не использовать.
Максимализм здесь чувствую я. Если прикладной софт в windows нормально работает с сетевыми ресурсами, то пусть и работает. И работать он будет явно быстрее и стабильнее, чем через какой-нибудь webdav.
>Файлопомойки на SMB - это тот еще архитектурный эпик
Поэтому давайте вообще спрячем файловую систему от пользователя, и пусть он страдает, когда захочет скачать файл из интернета, а потом открыть в локальном редакторе, а после этого обработать данные уже в третьем приложении.
>один родитель у файла или папки
Это как?
Так:
Отвечу сразу зачем надо: люди папками навигацию выстраивают и часто бывает так, что один и тот же ресурс должен находиться сразу в нескольких навигаторах. Например есть отдел1 и отдел2 и надо чтобы документN находился и в папке отдел1 и в папке отдел2. Только не надо про симлинки: они одни проблемы решают, а другие создают, не говоря уже о том, что не понятны юзверям и требуют слишком много навыков для их создания для обычного пользователя.
права на каталоги ставятся как обычно. Кто хочет галочками через интерфейс, кто хочет и через командную строку
Хорошо, когда пользуются папками сисадмины. А когда юзвери?
Поэтому давайте вообще спрячем файловую систему от пользователя, и пусть он страдает, когда захочет скачать файл из интернета, а потом открыть в локальном редакторе, а после этого обработать данные уже в третьем приложении.
Dropbox, Google Drive, Yandex Disk, Mail cloud и, конечно, Microsft SharePoint и OneDrive так и сделали и пипл доволен. А вот про успешный успех облачных CIFS провайдеров я что-то не слышал. Да, иногда это делается через синхронизующее ПО (синхронизация локальных файлов в облако).
Кстати, толстые продукты MS умеют работать по сети с ресурсами не по CIFS и делают это так, что пользователи даже не понимают, что идет синхронизация изменений в облако с совместным редактированием. В MS тоже дураки сидят, не понимающие всех преимущество собственного CIFS?
Только не надо про симлинки: они одни проблемы решают, а другие создают, не говоря уже о том, что не понятны юзверям и требуют слишком много навыков для их создания для обычного пользователя.
можно подумать ваши папки с несколькими родителями понятны пользователям и не создают проблем
Dropbox, Google Drive, Yandex Disk, Mail cloud и, конечно, Microsft SharePoint и OneDrive так и сделали и пипл доволен. А вот про успешный успех облачных CIFS провайдеров я что-то не слышал. Да, иногда это делается через синхронизующее ПО (синхронизация локальных файлов в облако).
вот именно, что тот же дропобокс взлетел как сервис синхронизации файлов между разными компьютерами, а не как web-сервис доступа к файлам.
А вот про успешный успех облачных CIFS провайдеров я что-то не слышал
ну тот же webdav достаточно популярен. и на всякие fuse для доступа к облачным хранилищам через файловую систему спрос есть.
Хорошо, когда пользуются папками сисадмины. А когда юзвери?
повторю вопрос: что за волшебный вебинтерфейс, где всё просто и понятно для обычных пользователей? в прошлый раз вы как-то уклонились от ответа
можно подумать ваши папки с несколькими родителями понятны пользователям и не создают проблем
Понятны. Но да, проблемы создают, правда не в смысле "как бухгалтеру создать симлинк", а что когда навигация из наложенных друг на друга деревьев, в них заметно сложнее разбираться, чем когда дерево навигации одно. У симлинков проблема не в том, что это симлинк, а в том, что есть проблемы с удобными инструментами работы, ибо что тебе интерфейс Explorer-а даст, только с тем ты и будешь работать. Если же рисовать свою хранилку с веб-интерфейсом, то этот веб-интерфейс можно заточить на работу с файлами.
что за волшебный вебинтерфейс, где всё просто и понятно для обычных пользователей
Дак вот же он:
Dropbox, Google Drive, Yandex Disk, Mail cloud и, конечно, Microsft SharePoint и OneDrive
вот именно, что тот же дропобокс взлетел как сервис синхронизации файлов между разными компьютерами, а не как web-сервис доступа к файлам.
Ну компании его используют для совместной работы с файлами. Здесь надо разделить личные проблемы и корпоративные. Личные, это "как мне одному с разных компов иметь доступ к одним и тем же файлам". А корпоративные проблемы: "как нам совместно работать над общими ресурсами".
Соответственно, CIFS-шару можно сделать для корпоративного использования, только задача-то не в том, чтобы иметь централизованный доступ к файлам, а в том, чтобы совместно над этими файлами работать. И вот для совместной работы CIFS-шара имеет только "вызвать контекстное меню правым кликом мыши...".
Я хочу особо донести эту мысль для CIFS-филов: людям в компании нужна не общая шара с файлами, им нужна совместная работа с ресурсами!
Дак вот же он:
Dropbox, Google Drive, Yandex Disk, Mail cloud и, конечно, Microsft SharePoint и OneDrive
нет, давайте конкретнее.
вот google drive я пользуюсь, да, там нет проблем с двумя и больше родителями у папки. нет папок — нет ограничений по работе с ними )))
Я хочу особо донести эту мысль для CIFS-филов: людям в компании нужна не общая шара с файлами, им нужна совместная работа с ресурсами!
совместную работу в плане одновременного открытия одного и того же документа тот же гугл предоставляет, но вот удобство работы с кучей файлов — это серьёзно?
в одних сценариях работы важно одно, в каких-то другое, в каких-то — и то, и другое разом. ну а где-то, разумеется, не нужно ничего из этого )
пока у меня впечатление, что вы построили у себя в голове некоторую идеальную картинку того, как это может выглядеть в теории, а какого-то реального опыта использования и соответствующего знакомства с подводными камнями и ограничениями конкретных продуктов у вас нет.
но вот удобство работы с кучей файлов — это серьёзно?
Эта ветка не в контексте топика: "есть программа и она плодит миллионы файлов в одной папке", а в контексте: "CIFS не нужно использовать в качестве корпоративной шары". Что из Dropbox, Google Drive и далее по списку подойдет под задачу топика (программа плодит миллионы файлов) - правильный ответ: ничто не подойдет.
нет папок — нет ограничений
Если надо, я могу сделать исследование и обзор по имеющимся системам по хранению файлов с веб-интерфейсам, их достоинствам и недостаткам, но оплату работы за это исследование попрошу вперед ;)
Про несколько родителей у "папки" я говорил не в качестве преимуществ Google Диска и всех остальных перечисленных систем, а в качестве недостатка CIFS (и вообще файловых систем и всему, что использует в качестве навигатора папки на файловых системах).
с подводными камнями и ограничениями конкретных продуктов
Есть много скилов по электронной библиотеке. Но она не файловая хранилка, не DAM, не средство коллективной работы и со всеми этими "дисками" не конкурирует. Хотя все перечисленные системы должны иметь хранилища, выстраивать навигаторы через базу данных, ограничивать доступ, иметь поиск, каталог, плееры ресурсов и т.д. (то есть имеют много схожего), однако в виду решения разных задач имеется много и различий, которые делают системы удобными для решения одних задач и неудобными для решения других.
Касательно приведенной схемы: она переживает выход из строя любого одного сервера с дисками. Это плюс этой костыльной SMB SDS. Если собрать RAIDZ2, то переживет и смерть любых двух хостов с дисками.
Минус, как уже выше правильно спросили, раз ZFS не знает про деградацию дисков, так как её просто не видит и ничего о ней не знает из-за использования RAID на хостах, ребилд будет приводить к жестким тормозам при записи и чтении из файлов, которым не повезло на ребилдещемся контроллере оказаться.
Также сам сервер с SMB является единой точкой отказа. Хост с дисками можно потерять, но если потерять хост с SMB, то все встает колом. При этом производительность системы хранения упрется в скорость работы этого самого сервера с SMB и много IOPS через него не прокачать, в то время как сервера с дисками постоянно будут недогружены.
Также выше правильно спросили, что будет если воткнуть диск другой емкости. На сколько я помню, в ZFS диски в пуле должны быть одного размера, поэтому экспортируемые по iSCSI диски тоже должны быть одного размера. Поэтому если вывести хост с дисками из эксплуатации, заменить диски на более емкие, то чтобы поиметь место, надо создать больше iSCSI-таргетов.
Предположу, что раз производительность все равно упирается в сервер с SMB, более разумно было иметь не сервер с дисками, а полки с дисками и просто воткнуть полки в единственный сервер с SMB.
Также сам сервер с SMB является единой точкой отказа. Хост с дисками можно потерять, но если потерять хост с SMB, то все встает колом
быстро поднятое упавшим не считается? )
если запихать сервер с smb в виртуалку (а мне показалось, что именно так и сделали), то отказоустойчивость можно обеспечить средствами платформы виртуализации.
жаль, что smb — не stateless протокол, для клиентов, например, отказ одного физического сервера и миграция виртуалки на другой может не пройти незамеченной.
Предположу, что раз производительность все равно упирается в сервер с SMB, более разумно было иметь не сервер с дисками, а полки с дисками и просто воткнуть полки в единственный сервер с SMB.
тут мы как раз привязываемся к единственному физическому серверу, который будет точкой отказа
быстро поднятое упавшим не считается? )
Клиенты, возможно, надо будет руками переподключать с net use после быстрого поднятия. Это надо тестировать.
Ну и тут наверняка это не просто файлопомойка, так как для файлопомойки даже примитивный DAS будет лучше SMB, а просто есть какая-то прога, которая вот такую структуру создает и работает типа локально (а ей подсовывают SMB-шару). Вот этой проге может сильно поплохеть, когда у нее внезапно все файлы исчезнут и последствия этого сложно предсказать (например может посчитать, что архив удален и очистит базу по архиву).
отказоустойчивость можно обеспечить средствами платформы виртуализации
Согласен, это пропустил. Виртуализация уменьшает критичность к прилеганию SMB-сервера, но здесь скорее не отказоустойчивость, а высокая доступность. Цена при этом: умножение IOPS примерно на 0.5 из-за оверхэда виртуализации на ввод-вывод + оверхэд на Ethernet.
В итоге будет автоподнятие при падении SMB-хоста за счет виртуализации или нет с учетом возможных проблем с SMB-подключениями и логикой работы ПО - надо тестировать. Может будет, а может нет.
«Очумелые ручки», или Как мы слепили СХД из спичек и желудей