постоянный том для проекта SaaS на Docker Swarm и НА МОИХ СОБСТВЕННЫХ серверах / VPS (не AWS, не Azure): что использовать для MySQL и для загрузки файлов?

Я не уверен, какая архитектура / какой путь использовать для постоянных данных моего веб-приложения Docker Swarm SaaS.

Набросок макета с traefik_proxy и некоторый контекст для лучшего понимания моих потребностей можно найти на диаграмме: красочный набросок макета с требованиями

1. Что мне выбрать: NFS или glusterfs? для загрузки файлов (=файлы, прикрепленные пользователями арендаторов/проектов)? - или есть другое бесплатное решение можно порекомендовать предоставить контейнерам веб-приложений (docker Swarm) согласованные, специфичные для арендатора файлы, как показано на связанной диаграмме draw.io?
2. Я использую mariadb для хранения данных, необходимых для создания потоков и их содержимого (= сообщений): Галера правильное решение
3. И: должен/могу ли я использовать те же серверы для загрузки файлов, которые я использую для баз данных (по крайней мере, для начала)?

ПОЛЬЗОВАТЕЛЬСКИЙ СЛУЧАЙ для SAAS SAAS — это клиент-серверное веб-приложение LAMP, работающее на докере, сравнимое с доской обсуждений, с разными потоками для разных результатов проекта и с возможностью загрузки файлов. (В зависимости от предмета эти файлы могут быть больше (например, если проект представляет собой фильм) или меньше (как в большинстве проектов, некоторые диаграммы, офисные файлы, фрагменты кода...))

• ВЕБ-ПРИЛОЖЕНИЕ ДЛЯ УПРАВЛЕНИЯ ПРОЕКТОМ / СОТРУДНИЧЕСТВА В КОМАНДЕ, РАБОТАЮЩЕЕ НА DOCKER-КОНТЕЙНЕРАХ
• Должен быть масштабируемым и готовым к обработке 100 000 проектов, при этом в среднем 5 проектных работников публикуют и читают сообщения и загружают файлы (вложения со своими сообщениями).
• Необходимо для работы на «Моих собственных» серверах (= БЕЗ AWS, БЕЗ AZURE, БЕЗ облака XYZ, но на моих собственных «Управляемых серверах» или VPS)
• Высокая доступность (HA-решение)
• Очень безопасный (например, через отдельные пространства имен и сети для разделения прав доступа между арендаторами или регулярное резервное копирование через mysqldump — cURL на 2 сервера резервного копирования, то же самое для загруженных файлов, например, через cronjobs)
• Очень низкое время ожидания для операций CRUD: просмотр потоков должен быть безупречным / таким, как мы ожидаем, чтобы он работал, чтобы не чувствовать себя нарушенным в нашем рабочем процессе сегодня (= менее 5 секунд, лучше менее 2 секунд).