In a multi-tenant deployment, we use the design from the blueprint to host multiple clients on. Clients who land on this environment, generally purchase a Fully Managed Service from the Service Provider. Main reasons for this deployment type are:
- Share resources efficiently (CPU/RAM/STORAGE) amongst multiple clients.
- Single management pane.
- Single Self-service Restore Portal. (optional)
- Single RESTful API endpoint for 3rd party applications to talk to.
- Easy to scale by adding more Backup Proxy/Repo servers.
- Ability to create dedicated Backup Proxy/Repo servers for large clients.
- Allow for centralized licensing and usage reporting into VCSP Pulse via VSPC.
Only one VB365 management server and one API/Portal server exist in this architecture. When maintenance is scheduled for updating, upgrading or else, the service will become completely unavailable for all clients on the platform. Consider deploying dedicated pods for clients to increase the overal service availability at an increased cost of IT infrastructure.
Shared Responsibility Model
Responsibility of a Service Provider:
- The entire service platform (servers, networking, storage, application, licenses, updates, maintenance etc.)
- All tasks related to Backup & Restore such as:
- Configuring the Backup Jobs based on a standardized (preferred) or custom offering (e.g. retention policy, backup frequency etc.)
- Servicing restores on behalf of the customer using the Veeam Explorers.
Responsibility of a Client:
- Requests restores via the service desk of the service provider.
- Initiates restores via the self-service portal. Restore capabilities can be delegated to dedicated restore operators or even end-users. The self-service portal should be configured on a per-client basis. To allow self-service, additional configuration is required in the client’s M365 tenant.
This design has been simplified to focus on the specific scenario. For ports usage, check the blueprint design.
General component sizing is covered in the VB365 components section and applies to any scenario. The following recommendations are specific to the multi-tenant deployment scenario.
- Use dedicated backup proxies for large organizations or split large organizations accross different backup proxies to allow room for growth.
The recommendation is a maximum of 5000 users (20.000 objects) per proxy. If an organization contains this amount or more, it is better to split it into 2 or more proxies.
This way, one proxy will not get overloaded, but the load is spread across.
- Use dedicated backup proxies to reserve resources for organizations where you need to guarantee a low RPO.
- Each proxy can have the same or different amount of hardware resources allocated to it.
- Use dedicated backup repositories per client and per application type.
- To spread the load, assign backup repositories to different proxies.
- Each backup repository can have a different retention policy.
- Create JetDB-backed repositories on different volumes/LUNs to reserve space for future growth.
- Allow for customer segregation.
- Simplifies exit strategy.
Please check out other important Backup Repository considerations.