Hub and spoke model overview

Hub and spoke model allows a single administrator to manage backups for multiple applications that exist on the different clusters.

The Hub is the single location from where the administrator can login and manage all the applications on all the spoke and hub clusters. The hub location hosts the server and facilitates the Backup & restore administrator to run backup and restore jobs across all clusters.

The hub includes all the Backup & restore server components and agent components for backing up components on its own cluster. The spoke has only the Backup & restore agent installed in it. The Backup & restore hub maintains all scheduling, retention, policy handling, location management, and everything else from a management point of view. The agent or spoke takes care of requests to facilitate Backup & restore jobs on that cluster.

Whenever you want to manage applications on a spoke cluster, you must install IBM Storage Fusion and the Backup & restore Agent Service on that cluster. As part of the spoke agent installation process, a communication gets established between the hub and spoke cluster. The spoke Agent installation requests for a connection snippet to be generated on the hub and you must provide it within an hour to the Agent installation. This temporary connection snippet generates a permanent communication between the hub and spoke by generating a certificate from the Certificate Authority (CA) of the hub. By default, this certificate expires after 90 days. IBM Storage Fusion takes care of the needed steps to auto-renew a certificate before it expires.

IBM Storage Fusion is also resilient to unreliable network connections and can recover with network disconnections between the hub and spoke clusters up to an hour .

In the Jobs page of the hub cluster, you can view all the backup and restore jobs across all clusters. You can filter jobs of a specific cluster. When a backup or restore job gets initiated, it gets remotely deployed to the cluster where the agent picks up the job to run it locally on that cluster.

The Service Protection feature provides the ability to restore applications from remote S3 backups (local snapshot only backups not supported) across all hub and spoke clusters. While the Service Protection backup is configured on the hub cluster, all backup information for spoke clusters is automatically included and no configuration on the spoke clusters are required.

In the event of a cluster crash, you can restore application backups on the replacement cluster.

Note: Service protection is just for backup restore on the hub cluster and not for other configurations that exist in IBM Storage Fusion. For example, Red Hat® OpenShift® Container Platform cluster, disaster recovery, Red Hat OpenShift Data Foundation.

In the Topology page, you can see the hub cluster in the first row followed by all connected spoke clusters. The details of the connected clusters, such as health, status, success rate are available in this view.

The two available backup storage locations are the in place local snapshots and S3 remote object store locations. If you want to restore applications on another cluster, configure a S3 remote object store for the backup storage locations. The S3 remote object store is to store data on an external location. During instances wherein the cluster crashes, the backups that are stored in the local snapshots are lost along with it. Hence, it is important to offload your backups to an external storage location, and later restore the application on a replacement cluster.

You can share the locations and policies for applications that are backedup up across the cluster. From the hub cluster, you can apply policies to any number of applications across any number of clusters. All applications get backed up at the same time as they share policies and the schedules. However, it can cause resource contention in the network cluster. For example, all backups need network connection to a S3 location at the same time. Though it gives the advantage of maintaining limited number of policies, it might place a strain on the network. Similar to the policies, you can use one location to store every backup of all clusters. It can cause contention of network requests on the same backup location.

The Applications page shows only applications on that cluster and not any applications on the spoke cluster. The Backedup application page shows all applications that are protected across the cluster. To protect new applications in the cluster, click Protect apps in the Backedup application page, and select applications from a specific cluster.