Design for a pod deployment

In a pod deployment, we take a blueprint design to host a single client. This blueprint can be deployed either at the customer’s premises or in the Service Provider’s cloud environment. Clients who land on this environment, either purchase a Fully Managed Service or a Semi-Managed Service from the Service Provider. With a Semi-Managed Service, the client receives direct access to the Veeam Explorers for full self-service restore capabilities.

Main reasons for this deployment type are:

• Complete client isolation.
• Separate larger clients with many users and objects to backup from smaller ones. E.g. deploy dedicated pods for large clients, while small clients land on the multi-tenant infrastructure.
• Self-service portal per client with custom URL if desired.
• Exit strategy. When a client decides to leave the service, all servers can be handed over to the client or decomissioned without impacting any other clients.

Other reasons are:

• Maintenance in a pod does not impact any other clients.
• Predictable infrastructure cost as you deploy a standard blueprint per client, then add proxy/repo servers as needed.
• Allow for centralized licensing and usage reporting of each pod into VCSP Pulse via VSPC.

Shared Responsibility Model

Responsibility of a Service Provider:

• The entire service platform (servers, networking, storage, application, licenses, updates, maintenance etc.).
• Providing the client with secure remote access (VPN) to the environment.
• (Optional) Deploy a dedicated self-service portal for the client.

Responsibility of a Client:

• All tasks related to Backup & Restore such as:
  • Configure Backup Jobs based on the company’s requirements (e.g. retention policy, backup frequency, what needs backup etc.)
  • Initiate restores via the Veeam Explorers.
  • (Optional) Initiates restores via the self-service portal. Restore capabiltiies can be delegated to dedicated restore operators or even end-users.. The self-service portal is entirely optional and can be configured on a per-client basis. To allow self-service, additional configuration is required in the client’s M365 tenant.

Depending on the agreement, the Service Provider can help with initial deployment of the solution, provide training and documentation.

This design has been simplified to focus on the specific scenario. For ports usage, check the blueprint design.

Sizing

General

General component sizing is covered in the VB365 components section and applies to any scenario. The following recommendations are specific to the pod deployment scenario.

Backup Proxy Servers

• Use dedicated backup proxies depending on the application type’s source size.
  E.g. If a client uses SharePoint extensively, dedicate one or more backup proxies to process more at the same time, shortening the backup window.

Backup Repositories

• Use dedicated backup repositories 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.
  • Simplifies exit strategy.

Please check out other important Backup Repository considerations.

---