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.
• Deployed at the customer’s premises.
• 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.
• Billing. Charge clients for the entire pod (infrastructure, networking, storage).
• Allow for centralized licensing and usage reporting of each pod into VCSP Pulse via VSPC.

Remote pod: When a pod is remotely deployed (at the customer’s premises), the design below changes. In this case we have VB365 and its components located at the customer and VCC/VSPC located at the service provider (See MSP design). On the remote VB365 server a VSPC Management Agent must be deployed for remote management.

Shared Responsibility Model

Responsibility of a Service Provider:

• The entire service platform (servers, networking, storage, application, licenses, updates, maintenance etc.).
  • E.g. Use Veeam ONE for in-depth monitoring and reporting
• Providing self-service to the client:
  • via a secure connection (VPN) directly into the environment (VB365 Console)
  • via the VSPC web portal
• (Optional) Deploy a dedicated self-service portal for the client.

Responsibility of a Client:

• All tasks related to Backup & Restore such as:
  • Configure Backup and Backup Copy 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.

---