Задать вопрос
@dexxp

Сможет ли кластер minio выдержать 60000 клиентов, стримящих данные?

Я новичок в DevOps, и мне необходимо построить систему, которая сможет собрать файлы с 60к хостов, которые будут делать это, вероятнее всего, параллельно.

Клиент (sender-service)
На каждом хосте запускается клиент на golang(minio-go), который регулярками обходит директории и достаёт из них файлы(файлы в основном небольшие). К этим файлам добавляется префикс hostname/filepath и они сразу же отправляются(стримятся) по сети в S3 в сжатом потоке(lz4.Writer). Каждый клиент запускается на хосте единоразово и работает в однопоточном режиме. За свою работу sender-service отправит всего около 100мб сжатых данных и порядка 3-5к файлов.

Кластер MinIO (предполагаемый мной):
  • Количество хостов: 4
  • ОС: linux
  • Количество ядер: 8-16
  • ОЗУ: 32/64 гб
  • Количество инстансов MinIO: 4, один на хост
  • Количество дисков: 3 локальных SSD (1-2 ТБ), итого 12 дисков
  • Внутреннее соединение между нодами: 10 Gbps
  • Используется EC 8+4
  • Внешний балансировщик (думаю насчет HAProxy или Envoy) с round-robin

reader-service
Когда sender-service закончит работу, он отправит свой hostname в reader-service, в свою очередь он сходит в S3 и достанет из бакета все объекты по этому префиксу. Все эти объекты reader-service заархивирует и отправит во внешнюю систему. То есть, нагрузка на чтение из S3 тоже будет и это нужно как-то учитывать.
(!) Этот сервис обрабатывает ровно одного клиента за раз

Вопросы:
  • Выдержит ли такая конфигурация MinIO 60 000 одновременных клиентов, если нагрузка идёт в стриминге?
  • Есть ли ограничение на количество одновременных соединений/транзакций в MinIO, о котором стоит знать?
  • Есть ли известные узкие места в такой архитектуре?

Очень важно: не потерять файлы
Чем можно пренебречь:
  • Скорость: главное, чтоб всё собралось
  • Долго и надежно хранить: после отправки архива reader-service'ом, данные в бакете по этому хосту больше не нужны

Подытожу:
Система работает разово, но с высокой интенсивностью. Нужно минимизировать стоимость инфраструктуры, не потеряв файлы при параллельной отправке от 60к клиентов, при этом скоростью и долговечностью можно пренебречь.
  • Вопрос задан
  • 295 просмотров
Подписаться 2 Средний 4 комментария
Пригласить эксперта
Ответы на вопрос 3
leahch
@leahch
3D специалист. Dолго, Dорого, Dерьмово.
Странно как-то. Вы же уже предложили "решение", а теперь спрашиваете, будет ли оно работать!
Скажу так - без нагрузочных тестов никто не скажет!
Ну и замечу, seaweedfs раза в 4 произодительнее minio.
Ответ написан
ky0
@ky0
Миллиардер, филантроп, патологический лгун
Если файлы не нужно хранить, зачем S3? Отправляйте их сразу с хостов "во внешнюю систему". Чтобы не потерять по дороге - предусмотрите обработку переотправки, если что-то пошло не так.
Ответ написан
tarazanov-devops
@tarazanov-devops
Решаю проблемы с производительностью IT-систем.
Добрый день!
Коллеги в комментариях дали верные советы: финальный ответ даст только нагрузочное тестирование, и SeaweedFS действительно стоит рассмотреть в будущем за его производительность.
Но если говорить конкретно про вашу предложенную архитектуру с MinIO, то в ней есть несколько неочевидных, но критически важных мест, которые могут привести к потере данных при такой нагрузке.
Если кратко: в текущем виде конфигурация, скорее всего, не выдержит, но ее можно доработать, чтобы она справилась.

Первое слабое место: Сеть и Балансировщик
Вы абсолютно правы, что вынесли балансировщик отдельно. Но при 60 000 одновременных клиентов он станет вашей главной точкой отказа.
Проблема: Один IPv4-адрес на балансировщике может обслуживать не более ~65 000 одновременных TCP-соединений (это теоретический предел количества портов). Ваши 60 000 клиентов подходят к этому пределу вплотную. Любые дополнительные служебные соединения или небольшая погрешность приведут к тому, что новые клиенты просто не смогут подключиться.
Решение: Вам необходимо как минимум два балансировщика (например, два HAProxy на отдельных VM), каждый со своим собственным публичным IP-адресом. На уровне DNS вы настраиваете Round Robin для вашего домена S3, чтобы клиенты случайным образом распределялись между этими двумя IP. Это разделит нагрузку и решит проблему с исчерпанием портов.

Второе слабое место: CPU и Erasure Coding
Вы выбрали Erasure Coding (EC) 8+4. Это отличный выбор для долгосрочного и экономичного хранения данных. Но для вашей задачи — короткий, интенсивный всплеск записи — это худший из возможных вариантов.
Проблема: Erasure Coding — это очень ресурсоемкая по CPU операция. При записи каждого объекта MinIO придется "на лету" вычислять 4 блока четности, что создаст колоссальную, избыточную нагрузку на процессоры и станет главным виновником замедления всего процесса.
Решение: Откажитесь от EC. Учитывая, что вам не нужно долго хранить данные, а важна только надежность записи, вам идеально подойдет стандартная репликация. А еще лучше и дешевле, учитывая вашу задачу — запустить каждый из 4-х инстансов MinIO в standalone-режиме. Риск отказа одного из четырех серверов именно в короткий промежуток загрузки минимален, а производительность и экономия будут максимальными.

Ответы на ваши прямые вопросы:
Выдержит ли такая конфигурация MinIO 60 000 одновременных клиентов?
С предложенными мной изменениями (2+ балансировщика и отключение Erasure Coding) — да, выдержит.

Есть ли ограничение на количество одновременных соединений/транзакций в MinIO?
Само приложение MinIO не имеет жесткого лимита, но оно всегда упирается в ограничения операционной системы (количество файловых дескрипторов, лимиты TCP-стека) и железа. Главное ограничение, как я описал выше, — это количество доступных портов на одном IP-адресе вашего балансировщика.

Есть ли известные узкие места в такой архитектуре?

Да. Это балансировщик (решается несколькими IP) и CPU (решается отключением Erasure Coding). Также критически важна надежность самих клиентов: ваш sender-service на Go обязательно должен иметь встроенную логику повторных попыток (retry) с экспоненциальной задержкой. Если PUT-запрос не удался, клиент должен попробовать еще раз через секунду, потом через три, и так далее. Это и есть ваша главная гарантия от потери файлов.

Рекомендуемая архитектура для вашей задачи на мой взгляд:
Балансировщики: 2 x HAProxy на отдельных VM с двумя публичными IP. DNS Round Robin.
Ноды MinIO: 4 ноды, как вы и планировали, но каждый инстанс MinIO запущен в режиме standalone (без EC).
Диски: 12 SSD — отличный выбор для быстрой обработки метаданных.
Клиент sender-service: Обязательная реализация логики retry.
И, как правильно заметили коллеги из комментариев, финальный ответ даст только нагрузочное тестирование.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы