https://www.opennet.ru/openforum/vsluhforumID1/97747.html Здравствуйте.<br>Есть 4 диска по 2Тb. Нужно их объединить в один логический диск 8Tb, но так, чтобы при выходе из строя любого из дисков файлы с остальных можно было без особых усилий восстановить (в идеале вообще сохранить целостность объединенного логического), а вышедший из строя диск заменить. Потерей файлов с вышедшего из строя можно пренебречь (предполагается резервная копия)<br>Что-то типа gconcat, но с желательным сохранением файловых систем исходных дисков.<br>Спасибо<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#25 Thu, 01 Jul 2021 19:50:27 GMT &gt; Для Ceph надо поднимать целую инфраструктуру, отдельно серваки для метаданных и т.п. <br><br>Оно в контейнерах, можно хоть всю инфраструктуру на 1 серваке поднять.<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#24 Thu, 01 Jul 2021 18:09:22 GMT &gt;&gt; GlusterFS ?<br>&gt;&gt; https://wiki.freebsd.org/GlusterFS <br>&gt; RH отказался от поддержки GlusterFS в OpenShift. Поэтому я бы лучше смотрел <br>&gt; в сторону Ceph.<br><br>Смотрел я в ее сторону. Слишком много накладных расходов. GlusterFS реализуется проще, прозрачнее и гибче. Для Ceph надо поднимать целую инфраструктуру, отдельно серваки для метаданных и т.п. Если у тебе в наличии 4 машины на которых по 4 диска, то Ceph не оптимальна и бессмыслена, имхо.<br><br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#23 Tue, 29 Jun 2021 14:31:14 GMT &gt; GlusterFS ?<br>&gt; https://wiki.freebsd.org/GlusterFS <br><br>RH отказался от поддержки GlusterFS в OpenShift. Поэтому я бы лучше смотрел в сторону Ceph.<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#22 Tue, 29 Jun 2021 06:01:57 GMT GlusterFS ?<br>https://wiki.freebsd.org/GlusterFS<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#21 Tue, 29 Jun 2021 05:59:46 GMT Кто что добавит ещё про кластеризацию? Выше прозвучали названия файловых систем.<br><br>Каким решением лучше объединить в сетевую файловую систему, так, как будто каждый диск принадлежит независимому компу в сети. Тупо типа запустить серверов по числу дисков.<br><br>Тогда по идее глюк одного процесса сервера, сбой одного диска независимы от остальных. Типа что-то получается похожее на ответ на вопрос - каждый диск независим, консистентность в рамках каждого диска - отслеживается независимым, несвязанным с др. процессом.<br><br>На процессор сильна нагрузка?<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#20 Wed, 23 Jun 2021 18:31:32 GMT &gt; Столько ответов по файловой системе и ещё никто не предложил zfs, btrfs? <br><br>ZFS прекрасная файловая система, но она такого не может. Скорее всего в качестве основной файловой системы на тех четырех дисках будет ZFS. Сейчас там используется RaidZ. Выпадает емкость одного диска из массива + (из собственного опыта) замена вылетевшего диска в массиве занимает почти 12 часов на пересчет и не всегда заканчивается удачно (учитывая, что диcкам по 8-9 лет, а ZFS в RaidZ не любит бэды и т.п.) Так что, учитывая что зеркало все равно есть, хочу попробовать пул MergeFS. Это все делается для GlusterFS, которая критична к скорости сетевых интерфейсов (у меня обычный гигабит) и количеству "кирпичей". Чем меньше бриков в медленной сети, тем быстрее работает GlusterFS, что естественно. Вот и минимизирую брики, объединяя в массивы. Как-то так.<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#19 Wed, 23 Jun 2021 14:58:46 GMT Столько ответов по файловой системе и ещё никто не предложил zfs, btrfs?<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#18 Wed, 23 Jun 2021 09:06:40 GMT &gt;[оверквотинг удален]<br>&gt;&gt;&gt; 8Tb, но так, чтобы при выходе из строя любого из дисков <br>&gt;&gt;&gt; файлы с остальных можно было без особых усилий восстановить (в идеале <br>&gt;&gt;&gt; вообще сохранить целостность объединенного логического), а вышедший из строя диск заменить.<br>&gt;&gt;&gt; Потерей файлов с вышедшего из строя можно пренебречь (предполагается резервная копия) <br>&gt;&gt;&gt; Что-то типа gconcat, но с желательным сохранением файловых систем исходных дисков.<br>&gt;&gt;&gt; Спасибо <br>&gt;&gt; mhddfs, unionfs, ...<br>&gt; Вот второй адекватный ответ (первый был про mergefs) Спасибо.<br>&gt; Как раз читаю инфу про &#1108;ти три решения. Надо выбрать наиболее подходящий <br>&gt; вариант для FreeBSD.<br><br>в продакшн, unionfs и mhddfs под FreeBSD использовать опасно,<br>просто имейте это ввиду. Смотрите что есть в портах,<br>даты последних изменений, и по совокупности, принимайте<br>решение, но прежде соберите стенд и протестируйте, попробуйте<br>заполнение до 70-90%. Попробуйте выводить один из дисков<br>и тд и тп.<br> https://www.opennet.ru/openforum/vsluhforumID1/97747.html#17 Wed, 23 Jun 2021 07:50:31 GMT &gt;[оверквотинг удален]<br>&gt;&gt; Избыточность не нужна, может я неточно описал задачу. Достаточно, чтоб осталось то, <br>&gt;&gt; что осталось..<br>&gt; При таком подходе бэкап нужен всему массиву... и значит можно рассмотреть крайний <br>&gt; вариант- упало все и не осталось ничего. То есть поднимаем из <br>&gt; бэкапа 8 Тб.<br>&gt; А дальше все просто - делайте что хотите- хотите- страйп.. <br>&gt; хотите- lvm...<br>&gt; Это конечно не то что вы хотели изначально, но если у вас <br>&gt; есть бэкап всего массива- то не стоит закладываться на экзотику. решайте <br>&gt; задачу в рамках традиционных вещей.<br><br>Да, в принципе так и есть - есть копия всего массива.<br>Но есть два "НО" -<br>1 - переписать 2 ТБ в 4 раза быстрее, чес переписать 8 ТБ. <br>2 - И все-таки при вылете диска 3 дубля их 4-х как то спокойнее чем ни одного дубля<br>