The ROBO SDDC provides two deployment models. The first is a centralized model in which the management of ROBO sites is performed from a central hub. The second is a decentralized model in which each ROBO site is managed locally from within itself.

A ROBO location can be a storefront (point of sale), manufacturing facility, medical office, or other IT infrastructure located in a remote, distributed site. These locations are critical to the business but have a smaller number of workloads compared to the corporate datacenter, typically running 100 or less workload virtual machines. Due to the critical nature of the workloads, there should be limited dependencies on a Wide Area Network (WAN) connection. This reduces the impact on workloads should a WAN outage occur.

The VMware Validated Design for ROBO uses the VMware Validated Design for SDDC as the starting point. You must first have the VMware Validated Design for SDDC deployed in either a single or a dual region deployment. The ROBO Validated Design utilizes the provisioning and monitoring components from the SDDC Validated Design. In this VMware Validate Design for ROBO the decentralized management approach is used.

In the centralized model, all management, provisioning, and monitoring components are located in a region deployed as part of the VVD for SDDC. The only components located at the ROBO site are ESXi hosts. The centralized model has the following considerations.

Figure 1. Centralized Management for Remote Office and Branch Office


Centralized Management for ROBO

Table 1. Centralized Management

Pros

Cons

Single pane of glass management.

Large fault domain.

Centralized lifecycle management operations such as patching and upgrading.

Patching and upgrading involves coordinating downtime windows for management components in all locations.

Less management virtual machine footprint.

Patching and upgrading is a higher risk operation due to the large fault domain.

Rapid and reduced complexity site deployment.

WAN outage leaves the ESXi host disconnected, virtual machine workloads continue to run but can only be managed locally via Host Client or API/CLI access for basic operations. No provisioning via vCenter or CMP is possible. NSX management changes are not possible, however the network data plane continues to function.

Doesn't allow for the ability to add local disaster recovery.

In the decentralized model, core management components, such as vCenter Server and NSX Manager, are installed locally along with a vRealize Log Insight instance for logging in each ROBO site. This allows for independent management of each ROBO site while leveraging the centralized provisioning and monitoring capabilities of a region deployed as part of the VVD for SDDC. The decentralized model has the following considerations.

Figure 2. Decentralized Management for Remote Office and Branch Office


Decentralized Management for ROBO

Table 2. Decentralized Management

Pros

Cons

A WAN outage does not impact local management or backup operations.

No Single pane of glass for vSphere and NSX management.

Patching and upgrades is less of a risk due to smaller fault domains.

Larger management virtual machine footprint.

Log data is available locally for troubleshooting even when WAN connection is down.

Increased product licensing cost due to deployment at each ROBO.

Utilizes the central provisioning process.

Additional management components to patch and upgrade.

Log data is forwarded to the centralized vRealize Log Insight infrastructure allowing a single pane of glass.

More complex design to deploy and operate.

Event, alert, and utilization monitoring utilizes the central vRealize Operations Manager instance.

vRealize Operations Manager Remote Collectors are placed in the ROBO so data collection occurs even during a WAN outage.

Can add local disaster recovery.