Комментарии 7
Весьма познавательно, спасибо за ваш труд.
Подскажите, как вы боретесь с bit rot?
При чтении система проверяет контрольные суммы. Если обнаружено повреждение, а данные реплицированы, запрос перенаправляется на здоровую копию - клиент получает корректные данные.
Для борьбы с последствиями появления "битого" участка мы настроили мониторинг алертов и периодическую проверку целостности томов. При обнаружении bit rot поврежденные тома восстанавливаются из здоровых реплик.
В планах полностью автоматизировать этот процесс, чтобы система сама восстанавливала поврежденные блоки в фоновом режиме.
Использую это открытое "ЧУДО" https://github.com/s4core/s4core пока еще в альфе, бьет всех минио/garage/seaweedfs/rustfs по скорости и надежности. В комплекте дедупликация, атомарные операции, полная совместимость с S3 (версионирование, политика lifecycle, блокировка обьектов), в комплекте дашборд (на гитхабе есть демка), слежу за развитием дальше)
4 NVMe Диска и сеть на 10Гб. Дальше можно не читать. Вы просто уперлись в сеть и ваш тест не релевантный
Спасибо за внимательность! Вы правы, конфигурация стенда важна. Мы поправили опечатку в статье, тесты проводились на сети 25GbE.
Однако ваш тезис про "упор в сеть" остается актуальным. Тем не менее, тесты релевантны по двум причинам:
1. Эффективность ресурсов (CPU/RAM). Чтобы просто забить сеть до предела S3 Архипелаг использовал 28% доступной мощности. Это означает, что у нас остается большой запас вычислительной мощности, который можно реализовать, использовав более быструю сеть.
2. Тесты на IOPS (мелкие файлы) и LIST-операции (метаданные) упираются не в пропускную способность сети, а в архитектуру хранения и работу с диском. Там сеть не является "узким горлышком", и именно там S3 Архипелаг демонстрирует кратный отрыв от конкурентов (в 2-3 раза быстрее).
Тест показывает главное: мы получаем максимум из доступного канала с минимальными затратами ресурсов сервера.
S3 Архипелаг: как мы в Диасофте построили свое объектное хранилище