Комментарии 20
Minio использует ресурсы fs для чтения файла и ресурсы cpu для чексумминга, что видно из метадаты и возможностей протокола s3. Таким образом, после загрузки файл еще раз читается и строится чексумма. Отсюда следует, что для быстрой работы minio нужно много быстрых ядер (в вашем паттерне) и быстрые диски, куда будут попадать свежие файлы. В случае параллельной загрузки там у вас iowait поди под 100%. Это стоило бы измерить, конечно. В этом смысле, архитектура Minio несовершенна. Какой-нибудь R6 + ssd bcache/lvmcache в режиме writeback вас спасет. ZFS + slog не для этого, это для sync-записи, которую любят СУБД. А ZFS сама из коробки делает writeback, как и любая другая fs, используя буферный кэш.
Есть мнение, что для zfs лучше mirror ничего нет. Во-первых, pay as you go, во-вторых, лучше по iops, в-третих, дешевый ребилд.
Мы предпочитаем использовать один сервер бэкапа 24x10tb zfs mirror на 8 нод vm. И просто добавляем кирпичи.
Много решений, которые прекрасно работают, когда все хорошо, но когда все плохо, их количество стремительно уменьшается. В случае с ZFS MIRROR для 24х дисков, при пересборке скорость доступа упадет примерно на 1/12 (только та пара, которая в ребилде). А как обстоят с этим дела в случае с DRAID2.
Вообще, мне кажется, что 45x10TB RAID6 (DRAID2) в одной полке это от «жадности», а не от того, что это лучший дизайн, в смысле цены/качества.
Еще было бы здорово провести тест выполнения бэкапа в процессе ребилда массива. В духе, вот я выдернул диск 10TB, вкинул новый в полку, а бэкап так же фигачит на XGbit/s и утилизирует XX% диска.
Увы, в таких ситуациях чудес не бывает. Приходится выбирать — или мы гарантируем, что массив будет пересобран за разумное время (и страдает текущая скорость чтения записи), или мы продолжаем приоритетно текущую работу (но тогда ребилд закончится «когда-нибудь, может быть»). Поскольку второй вариант имеет неплохой шанс, что за время ребилда умрёт ещё один диск, то обычно используют первый.
Спасибо за за дельное замечание, в скором времени будем тестировать новое хранилище, обязательно его учтём.
А когда он тестировал идеализированные условия, например, в разрезе Minio, он не посмотрел где именно бутылочное горлышко.
При тестировании minio iowait действительно был приличный, кстати, про то как работает minio тут недавно обсуждали.
В распоряжении имеется сервер Fujitsu Primergy RX300 S7
45 дисков Seagage ST6000NM0115-1YZ110 по 6TB каждый.
А в спеке к серверу указано — max. 6 x 3.5
Во что были диски то воткнуты? Как на сервер поданы?
но позже gmelikov подсказал как можно улучшить производительность ZFS и после применения указанных опций, тесты с ZFS стали намного лучше.
добрый день, ссылка t.me/sds_ru/15724 увы не открывается, не могли бы Вы указать те чудодейственные настройки ZFS сразу в статье?
Спасибо за замечание, описал заветные опции в статье. (они так же были продублированны на картинке с бэнчмарком)
Что-то не подумал что телеграм может быть заблокирован на территории РФ.
ссылка t.me/sds_ru/15724 увы не открывается
Цитирую сам себя:
можно выставить xattr=sa, atime=off, recordsize=1M
Подробности описывал на русском тут в конце habr.com/ru/post/314506
У меня только недавно у знакомого выгорел транзистор в цепи питания и проц на Synology где хранились бэкапы (я понимаю что Synology не энтрерпрайз но всё таки), после включения автомата. (была подключена через ибп APC серии smart)
Хорошо что нашел старую видюшку с точно таким же транзистором и заменив транзистор и проц она завелась. Выходит для надежности и хранилку нужно реплецировать.
В этом смысле одиночные накопители по моему выгодней смотрятся.
Непонятно только что делать, если полка\сервер умрут. Видимо просто «будет печально». В виде прод. решения подобная штука в виде одной машины выглядит конечно рисковано весьма.
и 45 дисков Seagage ST6000NM0115-1YZ110 по 6TB каждый.
А как дела у этих дисков с SMR в свете последних событий?
Бэкап-хранилище для тысяч виртуальных машин свободными инструментами