Допустим у меня есть 10 дисков по 1ТБ в raidz1. Доступная емкость: 1 ТБ * (10-1) = 9ТБ.
Я решил увеличить пул, в два раза, купил 1 диск на 10 ТБ и обломался.
Из вашего предложения я понял решение задачи таким:
Надо взять 9 ТБ данных и куда-нибудь скопировать, достать 10 дисков по 1 ТБ и вставить вместо ВСЕХ старых дисков новые по 2 ТБ, собрать raidz1 заново на новых дисках и получится 2 ТБ * (10-1) = 18 ТБ доступной емкости? На эту операцию мне дополнительно надо где-то разместить всю занятую емкость пула (то есть заиметь еще такую же хранилку). Так это, извините, не расширить пул, а уничтожить пул и создать заново.
Отвечу сразу зачем надо: люди папками навигацию выстраивают и часто бывает так, что один и тот же ресурс должен находиться сразу в нескольких навигаторах. Например есть отдел1 и отдел2 и надо чтобы документN находился и в папке отдел1 и в папке отдел2. Только не надо про симлинки: они одни проблемы решают, а другие создают, не говоря уже о том, что не понятны юзверям и требуют слишком много навыков для их создания для обычного пользователя.
права на каталоги ставятся как обычно. Кто хочет галочками через интерфейс, кто хочет и через командную строку
Хорошо, когда пользуются папками сисадмины. А когда юзвери?
Поэтому давайте вообще спрячем файловую систему от пользователя, и пусть он страдает, когда захочет скачать файл из интернета, а потом открыть в локальном редакторе, а после этого обработать данные уже в третьем приложении.
Dropbox, Google Drive, Yandex Disk, Mail cloud и, конечно, Microsft SharePoint и OneDrive так и сделали и пипл доволен. А вот про успешный успех облачных CIFS провайдеров я что-то не слышал. Да, иногда это делается через синхронизующее ПО (синхронизация локальных файлов в облако).
Кстати, толстые продукты MS умеют работать по сети с ресурсами не по CIFS и делают это так, что пользователи даже не понимают, что идет синхронизация изменений в облако с совместным редактированием. В MS тоже дураки сидят, не понимающие всех преимущество собственного CIFS?
Этот класс ПО называется digital asset management. Я его давно смотрел, поэтому актуальные интерфейсы не могу рекомендовать, но в реестре видел и российское ПО.
Из популярного можно на NextCloud посмотреть, хотя он обычно относится не к DAM, а к коллективной работе и несколько тормозной. NextCloud умеет отдавать папки по webdav, то есть можно монтировать в Windows как диск. Но webdav у него совсем тормозной.
Когда тестировал GlusterFS, листинг директории в нем дико тормозил даже при небольшом количестве файлов (локально листинг работал быстро). Народ где-то писал, что эта ФС предполагалась для хранения дисков виртуалок, поэтому создатели не предполагают использование с большим количеством файлов.
Клиенты, возможно, надо будет руками переподключать с net use после быстрого поднятия. Это надо тестировать.
Ну и тут наверняка это не просто файлопомойка, так как для файлопомойки даже примитивный DAS будет лучше SMB, а просто есть какая-то прога, которая вот такую структуру создает и работает типа локально (а ей подсовывают SMB-шару). Вот этой проге может сильно поплохеть, когда у нее внезапно все файлы исчезнут и последствия этого сложно предсказать (например может посчитать, что архив удален и очистит базу по архиву).
отказоустойчивость можно обеспечить средствами платформы виртуализации
Согласен, это пропустил. Виртуализация уменьшает критичность к прилеганию SMB-сервера, но здесь скорее не отказоустойчивость, а высокая доступность. Цена при этом: умножение IOPS примерно на 0.5 из-за оверхэда виртуализации на ввод-вывод + оверхэд на Ethernet.
В итоге будет автоподнятие при падении SMB-хоста за счет виртуализации или нет с учетом возможных проблем с SMB-подключениями и логикой работы ПО - надо тестировать. Может будет, а может нет.
Касательно приведенной схемы: она переживает выход из строя любого одного сервера с дисками. Это плюс этой костыльной SMB SDS. Если собрать RAIDZ2, то переживет и смерть любых двух хостов с дисками.
Минус, как уже выше правильно спросили, раз ZFS не знает про деградацию дисков, так как её просто не видит и ничего о ней не знает из-за использования RAID на хостах, ребилд будет приводить к жестким тормозам при записи и чтении из файлов, которым не повезло на ребилдещемся контроллере оказаться.
Также сам сервер с SMB является единой точкой отказа. Хост с дисками можно потерять, но если потерять хост с SMB, то все встает колом. При этом производительность системы хранения упрется в скорость работы этого самого сервера с SMB и много IOPS через него не прокачать, в то время как сервера с дисками постоянно будут недогружены.
Также выше правильно спросили, что будет если воткнуть диск другой емкости. На сколько я помню, в ZFS диски в пуле должны быть одного размера, поэтому экспортируемые по iSCSI диски тоже должны быть одного размера. Поэтому если вывести хост с дисками из эксплуатации, заменить диски на более емкие, то чтобы поиметь место, надо создать больше iSCSI-таргетов.
Предположу, что раз производительность все равно упирается в сервер с SMB, более разумно было иметь не сервер с дисками, а полки с дисками и просто воткнуть полки в единственный сервер с SMB.
Файлопомойки на SMB - это тот еще архитектурный эпик, который в общем говорит о проблемах в архитектуре ПО, раз оно такое там потребовалось.
По SMB в большой файлопомойке: - управлять правами неудобно; - если "да точно было, куда делось?", то виноватого в удалении скорее всего не найдешь; - навигация неудобна (ограничение на символы в названиях, один родитель у файла или папки, ограничения на длину файла и уровень вложенности; - проблемы с совместной работой (сложно делиться доступом, контролировать кто к чему имеет, видеть ссылки только на те папки, на которые есть доступ и т.д.).
То есть SMB лучше вообще не использовать. А если SMB не использовать, а говорить про какой-то веб-сервис для большого количества файлов, то архитектура уже другая будет разумна.
Время ребилда большое, все как обычно так как за ребилд обычные контроллеры отвечают.
Деградация значительная. ZFS ничего не знает про ребилд экспортированных iSCSI, с ее точки зрения просто вдруг диск начинает тормозить, благо за счет CoW может это и не заметно будет, а может неповезет и будет заметно.
При ребилде нескольких дисков будет еще заметнее, а при ребилде на разных хостах еще заметнее.
Заменить диски на больший объем можно, но пространства в пуле видимо больше не станет. Поэтому точно такие же диски искать не нужно, ну а если хочется в разы более емкие диски вставить, то видимо нужен новый пул и миграция.
Все вроде ок, но при обновлениях (CentOS8) из офф. репозитария часто (в большинстве обновлений) портится индекс (документы перестают находиться, иногда сервер не может стартовать), хотя документов немного (в районе 1 млн.). Помогает перестроение индекса, но это долго и требует ручного вмешательства в процесс.
Можете подсказать, это у меня какие-то проблемы или такое у многих бывает при обновлении сервера?
Если на вебинаре вы будете показывать себя в полный кадр (на весь экран, а не маленьким окошечком), то лучше вебки взять дороже, с большей матрицей и меньшими шумами. У меня была Logitech c310, качество у нее довольно так себе. При выборе вебки, если сидеть будете близко, стоит обратить внимание умеет ли она исправлять геометрические искажения объектива, так как они, эти искажения, могут портить ваше лицо, когда сидите близко к камере.
Также если будете вести в темноте, понадобиться взять свет, возможно для засветки с двух сторон (а не в лоб), так как ставить кольцо прямо в поле зрении плохо - будет слепить и тени могут быть нежелательные.
Может пригодиться хромакей, но это надо смотреть по тому месту, откуда ведете вебинары, можно ли его подвесить. Хромакей (зеленый материал) в некоторых программах позволяет заменить фон. При использовании хромакея надо, чтобы ваша голова была контрастна, то есть стоит тогда и свет взять.
Совсем не сказано про наушники. Считайте при проведении вебинара наушники обязательным элементом, чтобы звук "не заводился". Конечно есть шумодавы, но лучше не испытывать судьбу и надеть наушники. Большие наушники при этом не всегда красивы и с ними есть проблемы при использовании хромакея, а сидеть в капельках многие часы может быть некомфортно.
Да, проблема порчи данных на уровне жестких дисков есть.
Ну в контексте резервного хранения RAID1 никто использовать не будет. Скорее всего будет RAID5 (так как потеря бэкапов при ребилде из-за второго сдохшего винта как правило не критична) или RAID6.
Кроме того, вполне вероятно, что если бэкап сжатый (а такое бывает не редко), то контрольные суммы будут в самом алгоритме сжатия и да, восстановить при этом данные будет нельзя, но что бэкап битый станет ясно при попытке восстановления. Ну тогда откатиться на день позже. Если люди восстанавливаются из бэкапов, они уже готовы потерять 1-2 дня работы ибо там где откатываться на 1-2 дня нельзя, там снапшоты, репликацию и т.п. подходы используют.
Опять же про восстановление данных, если исходить из ненадежности хранилища (есть еще передача по сети, если хранилище по сети монтируется к бэкапилке), то разумно это вынести в бэкапилку, а не в файловую систему, чтобы она могла прожевать сбои и сети и дисков и здесь тогда разумно поднимать вопрос не про ZFS, а про наличие такого функционала в бэкапилке.
З.Ы. все это в контексте бэкапа, а не работы виртуальных машин и системы хранения для них, где действительно фичи ZFS более сильную позицию имеют.
Здесь, видимо, использование Veeam является требованием и в данном случае лучше поставить Windows Server и на него Veeam и подключить диски напрямую через контроллер.
Можно, конечно, поднять ZFS с SMB на дополнительном сервере и примонтировать к Veeam по SMB, только это +1 сервер к полке только ради ZFS и прогон трафика по Ethernet будет не бесплатен для процессора, поэтому в данном случае просто не имеет смысла.
А так какие преимущества ZFS при бэкапах? Запись и чтение обычно линейные в очень большие файлы, записанные файлы уже сжатые, снапшоты не нужны. Ну ок, можно RAIDZ3 собрать ценой повышения нагрузки на CPU, но то такое, надо еще обосновать чем это лучше альтернативных вариантов в контексте бэкапового профиля нагрузки.
Чтобы вот таких проводов не иметь, надо свою матплату разрабатывать с выводом контактов IPMI в шасси и свою плату для шасси, что просто не очень выгодно.
Поэтому с одной стороны костыль, с другой я в стоечных 1U-серверах такое тоже видел (вывод Ethernet через патч-корд на внешнюю панель корпуса и ITX-плату внутри).
Поэтому не костыль, а широко используемое технологическое решение ))
Есть методологический вопрос: а качество не дефолтовое ставить пробовали? Просто при q=38 там же смотреть будет ничего не возможно. При больших q (низком качестве) алгоритмы загрубляют картинку и поэтому, боюсь, у вас получается высокая производительность.
Поставьте q=18 или такое, качество картинки при котором вас будет устраивать как зрителя.
Для CentOS8 можно попробовать ffmpeg взять из реп: https://elibsystem.ru/node/531. Пробрасывал Quadro P400 в Proxmox и все заработало. Quadro P400 так как 1 слот занимает, а кодировщики в одном поколении одинаковые с 1030 стоят.
А что в компаниях используют на тему "облачных дисков" в корпоративных облаках?
По SharePoint закупок мало у госов, очевидно госы его перестали закупать.
NextCloud на госзакупках не вижу, по ownCloud одна закупка Шереметьево.
Спросил вчера в чатике SharePoint в Телеге, ответили, что госы может быть идут на Битрикс24 в связи с импортозамещением. Битрикс24 для многих задач ок, но мне он не кажется именно облачным диском, хотя с файлами может работать.
Можно чуть подробнее?
Допустим у меня есть 10 дисков по 1ТБ в raidz1. Доступная емкость: 1 ТБ * (10-1) = 9ТБ.
Я решил увеличить пул, в два раза, купил 1 диск на 10 ТБ и обломался.
Из вашего предложения я понял решение задачи таким:
Надо взять 9 ТБ данных и куда-нибудь скопировать, достать 10 дисков по 1 ТБ и вставить вместо ВСЕХ старых дисков новые по 2 ТБ, собрать raidz1 заново на новых дисках и получится 2 ТБ * (10-1) = 18 ТБ доступной емкости? На эту операцию мне дополнительно надо где-то разместить всю занятую емкость пула (то есть заиметь еще такую же хранилку). Так это, извините, не расширить пул, а уничтожить пул и создать заново.
Так:
Отвечу сразу зачем надо: люди папками навигацию выстраивают и часто бывает так, что один и тот же ресурс должен находиться сразу в нескольких навигаторах. Например есть отдел1 и отдел2 и надо чтобы документN находился и в папке отдел1 и в папке отдел2. Только не надо про симлинки: они одни проблемы решают, а другие создают, не говоря уже о том, что не понятны юзверям и требуют слишком много навыков для их создания для обычного пользователя.
Хорошо, когда пользуются папками сисадмины. А когда юзвери?
Dropbox, Google Drive, Yandex Disk, Mail cloud и, конечно, Microsft SharePoint и OneDrive так и сделали и пипл доволен. А вот про успешный успех облачных CIFS провайдеров я что-то не слышал. Да, иногда это делается через синхронизующее ПО (синхронизация локальных файлов в облако).
Кстати, толстые продукты MS умеют работать по сети с ресурсами не по CIFS и делают это так, что пользователи даже не понимают, что идет синхронизация изменений в облако с совместным редактированием. В MS тоже дураки сидят, не понимающие всех преимущество собственного CIFS?
Этот класс ПО называется digital asset management. Я его давно смотрел, поэтому актуальные интерфейсы не могу рекомендовать, но в реестре видел и российское ПО.
Из популярного можно на NextCloud посмотреть, хотя он обычно относится не к DAM, а к коллективной работе и несколько тормозной. NextCloud умеет отдавать папки по webdav, то есть можно монтировать в Windows как диск. Но webdav у него совсем тормозной.
Когда тестировал GlusterFS, листинг директории в нем дико тормозил даже при небольшом количестве файлов (локально листинг работал быстро). Народ где-то писал, что эта ФС предполагалась для хранения дисков виртуалок, поэтому создатели не предполагают использование с большим количеством файлов.
Клиенты, возможно, надо будет руками переподключать с net use после быстрого поднятия. Это надо тестировать.
Ну и тут наверняка это не просто файлопомойка, так как для файлопомойки даже примитивный DAS будет лучше SMB, а просто есть какая-то прога, которая вот такую структуру создает и работает типа локально (а ей подсовывают SMB-шару). Вот этой проге может сильно поплохеть, когда у нее внезапно все файлы исчезнут и последствия этого сложно предсказать (например может посчитать, что архив удален и очистит базу по архиву).
Согласен, это пропустил. Виртуализация уменьшает критичность к прилеганию SMB-сервера, но здесь скорее не отказоустойчивость, а высокая доступность. Цена при этом: умножение IOPS примерно на 0.5 из-за оверхэда виртуализации на ввод-вывод + оверхэд на Ethernet.
В итоге будет автоподнятие при падении SMB-хоста за счет виртуализации или нет с учетом возможных проблем с SMB-подключениями и логикой работы ПО - надо тестировать. Может будет, а может нет.
Касательно приведенной схемы: она переживает выход из строя любого одного сервера с дисками. Это плюс этой костыльной SMB SDS. Если собрать RAIDZ2, то переживет и смерть любых двух хостов с дисками.
Минус, как уже выше правильно спросили, раз ZFS не знает про деградацию дисков, так как её просто не видит и ничего о ней не знает из-за использования RAID на хостах, ребилд будет приводить к жестким тормозам при записи и чтении из файлов, которым не повезло на ребилдещемся контроллере оказаться.
Также сам сервер с SMB является единой точкой отказа. Хост с дисками можно потерять, но если потерять хост с SMB, то все встает колом. При этом производительность системы хранения упрется в скорость работы этого самого сервера с SMB и много IOPS через него не прокачать, в то время как сервера с дисками постоянно будут недогружены.
Также выше правильно спросили, что будет если воткнуть диск другой емкости. На сколько я помню, в ZFS диски в пуле должны быть одного размера, поэтому экспортируемые по iSCSI диски тоже должны быть одного размера. Поэтому если вывести хост с дисками из эксплуатации, заменить диски на более емкие, то чтобы поиметь место, надо создать больше iSCSI-таргетов.
Предположу, что раз производительность все равно упирается в сервер с SMB, более разумно было иметь не сервер с дисками, а полки с дисками и просто воткнуть полки в единственный сервер с SMB.
Файлопомойки на SMB - это тот еще архитектурный эпик, который в общем говорит о проблемах в архитектуре ПО, раз оно такое там потребовалось.
По SMB в большой файлопомойке:
- управлять правами неудобно;
- если "да точно было, куда делось?", то виноватого в удалении скорее всего не найдешь;
- навигация неудобна (ограничение на символы в названиях, один родитель у файла или папки, ограничения на длину файла и уровень вложенности;
- проблемы с совместной работой (сложно делиться доступом, контролировать кто к чему имеет, видеть ссылки только на те папки, на которые есть доступ и т.д.).
То есть SMB лучше вообще не использовать. А если SMB не использовать, а говорить про какой-то веб-сервис для большого количества файлов, то архитектура уже другая будет разумна.
Я не автор, но рискну предположить:
Время ребилда большое, все как обычно так как за ребилд обычные контроллеры отвечают.
Деградация значительная. ZFS ничего не знает про ребилд экспортированных iSCSI, с ее точки зрения просто вдруг диск начинает тормозить, благо за счет CoW может это и не заметно будет, а может неповезет и будет заметно.
При ребилде нескольких дисков будет еще заметнее, а при ребилде на разных хостах еще заметнее.
Заменить диски на больший объем можно, но пространства в пуле видимо больше не станет. Поэтому точно такие же диски искать не нужно, ну а если хочется в разы более емкие диски вставить, то видимо нужен новый пул и миграция.
Спасибо, Manticore действительно быстро развивается вашими усилиями!
Смигрировал электронную библиотеку со Sphinx в Manticore.
Все вроде ок, но при обновлениях (CentOS8) из офф. репозитария часто (в большинстве обновлений) портится индекс (документы перестают находиться, иногда сервер не может стартовать), хотя документов немного (в районе 1 млн.). Помогает перестроение индекса, но это долго и требует ручного вмешательства в процесс.
Можете подсказать, это у меня какие-то проблемы или такое у многих бывает при обновлении сервера?
Если на вебинаре вы будете показывать себя в полный кадр (на весь экран, а не маленьким окошечком), то лучше вебки взять дороже, с большей матрицей и меньшими шумами. У меня была Logitech c310, качество у нее довольно так себе. При выборе вебки, если сидеть будете близко, стоит обратить внимание умеет ли она исправлять геометрические искажения объектива, так как они, эти искажения, могут портить ваше лицо, когда сидите близко к камере.
Также если будете вести в темноте, понадобиться взять свет, возможно для засветки с двух сторон (а не в лоб), так как ставить кольцо прямо в поле зрении плохо - будет слепить и тени могут быть нежелательные.
Может пригодиться хромакей, но это надо смотреть по тому месту, откуда ведете вебинары, можно ли его подвесить. Хромакей (зеленый материал) в некоторых программах позволяет заменить фон. При использовании хромакея надо, чтобы ваша голова была контрастна, то есть стоит тогда и свет взять.
Совсем не сказано про наушники. Считайте при проведении вебинара наушники обязательным элементом, чтобы звук "не заводился". Конечно есть шумодавы, но лучше не испытывать судьбу и надеть наушники. Большие наушники при этом не всегда красивы и с ними есть проблемы при использовании хромакея, а сидеть в капельках многие часы может быть некомфортно.
Да, проблема порчи данных на уровне жестких дисков есть.
Ну в контексте резервного хранения RAID1 никто использовать не будет. Скорее всего будет RAID5 (так как потеря бэкапов при ребилде из-за второго сдохшего винта как правило не критична) или RAID6.
Кроме того, вполне вероятно, что если бэкап сжатый (а такое бывает не редко), то контрольные суммы будут в самом алгоритме сжатия и да, восстановить при этом данные будет нельзя, но что бэкап битый станет ясно при попытке восстановления. Ну тогда откатиться на день позже. Если люди восстанавливаются из бэкапов, они уже готовы потерять 1-2 дня работы ибо там где откатываться на 1-2 дня нельзя, там снапшоты, репликацию и т.п. подходы используют.
Опять же про восстановление данных, если исходить из ненадежности хранилища (есть еще передача по сети, если хранилище по сети монтируется к бэкапилке), то разумно это вынести в бэкапилку, а не в файловую систему, чтобы она могла прожевать сбои и сети и дисков и здесь тогда разумно поднимать вопрос не про ZFS, а про наличие такого функционала в бэкапилке.
З.Ы. все это в контексте бэкапа, а не работы виртуальных машин и системы хранения для них, где действительно фичи ZFS более сильную позицию имеют.
Здесь, видимо, использование Veeam является требованием и в данном случае лучше поставить Windows Server и на него Veeam и подключить диски напрямую через контроллер.
Можно, конечно, поднять ZFS с SMB на дополнительном сервере и примонтировать к Veeam по SMB, только это +1 сервер к полке только ради ZFS и прогон трафика по Ethernet будет не бесплатен для процессора, поэтому в данном случае просто не имеет смысла.
А так какие преимущества ZFS при бэкапах? Запись и чтение обычно линейные в очень большие файлы, записанные файлы уже сжатые, снапшоты не нужны. Ну ок, можно RAIDZ3 собрать ценой повышения нагрузки на CPU, но то такое, надо еще обосновать чем это лучше альтернативных вариантов в контексте бэкапового профиля нагрузки.
У них обычные ITX-платы с Ryzen, но с IPMI.
Чтобы вот таких проводов не иметь, надо свою матплату разрабатывать с выводом контактов IPMI в шасси и свою плату для шасси, что просто не очень выгодно.
Поэтому с одной стороны костыль, с другой я в стоечных 1U-серверах такое тоже видел (вывод Ethernet через патч-корд на внешнюю панель корпуса и ITX-плату внутри).
Поэтому не костыль, а широко используемое технологическое решение ))
Есть методологический вопрос: а качество не дефолтовое ставить пробовали? Просто при q=38 там же смотреть будет ничего не возможно. При больших q (низком качестве) алгоритмы загрубляют картинку и поэтому, боюсь, у вас получается высокая производительность.
Поставьте q=18 или такое, качество картинки при котором вас будет устраивать как зрителя.
Спасибо за опыт!
Для CentOS8 можно попробовать ffmpeg взять из реп: https://elibsystem.ru/node/531. Пробрасывал Quadro P400 в Proxmox и все заработало. Quadro P400 так как 1 слот занимает, а кодировщики в одном поколении одинаковые с 1030 стоят.
У ASRock много интересных плат с IPMI под Ryzen, но не видел их в продаже в России.
А как их можно купить, кто-то знает?
Тут купил минипк с Ryzen Pro 8-ядерным и не нашел на него в России память SO-DIMM ECC.
На сколько понял, Pro линейка отличается только лишь шифрованием RAM и официальной поддержкой ECC.
Мешало-мешало.
Не раз сталкивался, что окно отрисовывается от 0 координаты и оказывается под панелью.
Но это скорее недоработка разработчиков приложений, чем ОС, но полетит-то в МС.
А что в компаниях используют на тему "облачных дисков" в корпоративных облаках?
По SharePoint закупок мало у госов, очевидно госы его перестали закупать.
NextCloud на госзакупках не вижу, по ownCloud одна закупка Шереметьево.
Спросил вчера в чатике SharePoint в Телеге, ответили, что госы может быть идут на Битрикс24 в связи с импортозамещением. Битрикс24 для многих задач ок, но мне он не кажется именно облачным диском, хотя с файлами может работать.
SeaFile также не вижу на госзакупках.
Некоторое время назад тестировал Optane и NVM NAND диски со сбросом кеша и без. Может кому будет интересны результаты:
Ключевой вопрос: можно ли провести fio такой простой тест с параметром fsync и без, чтобы по (не)падению скорости выявить, что SSD игнорирует fsync?