persistent volume for a SaaS project on docker Swarm & ON MY OWN Servers / VPS (non-AWS, non-Azure): what to use for the MySQL & for the file-uploads?

I am not sure, what architecture / which way to go for the persistent data of my docker Swarm SaaS webapp.

A draft of the layout with traefik_proxy and some context for a better understanding of my needs can be found in the diagram: colorful draft of the layout with requirements

1. Shall I go with NFS or with glusterfs for the file uploads (=files, attached by the users of the tenants/projects)? - or, is there another, free of charge solution one can recommend for providing the web-app-containers (docker Swarm) with the consistent, tenant-specific files like explained in the linked draw.io diagram?
2. I am using mariadb for storing the data needed to create the threads and its content (=the posts): is galera the right solution
3. And: shall/can I use the same servers for the file uploads I use for the databases (at least for the beginning)?

USECASE for the SAAS The SAAS is a Client-Server LAMP web-app running on docker, comparable to a discussion board, with different threads for the different deliverables of the project & with the option to upload files. (Related to the subject these files could be bigger (eg if the project is a movie) or smaller (like in most projects, some diagrams, office files, code snippets...))

• A PROJECT MANAGEMENT / TEAM COLLABORATION WEB APP RUNNING ON DOCKER CONTAINERS
• Should be scalable and ready to handle 100.000 projects with an average of 5 project-workers posting and reading messages and uploading files (attachments with their postings)
• Needed to run on "My own" servers (= NO AWS, NO AZURE, NO XYZ-cloud, but on my own "Managed Servers" or VPS)
• Highly Available (HA-solution)
• Very Secure (eg via individual namespaces and networks to separate the access permissions between the tenants or regularly made backups via mysqldump → cURL to 2 backup-servers, same for the uploaded files eg via cronjobs)
• Very low waiting times for the CRUD operations: browsing through the threads must be flawless/the way we expect it to work for not to feel disrupted in our workflow today (= below 5 seconds, better below 2 seconds).