When building a Storage Platform it may be desirable to ensure geographic affinity for specific groups of backup clients to corresponding Storage Servers or Storage Pools.
Doing this may allow for best use of local administrative resources for both backup client and Storage Platform, and help to minimise travel time for both personnel and snapshot disks.
Typical Storage Platform
For a typical Storage Platform, the backup clients backup over the internet to Storage Servers in one datacentre, and replicate that data to a Mirror Server in another datacentre.
When snapshots are required, removable disks containing initial backup data from backup clients must be physically conveyed to the datacentre for import.
For an administrator, this fits well when the Storage Server is physically close to the backup clients or base of operations, and travel time between these and the datacentre is minimal.
It does not fit as well if the Storage Server is remote and travel time is considerable.
Configuring the Storage Platform to match physical locations can help to reduce this issue.
Storage Platform with Geographical Affinity
When configuring a Storage Platform with geographical affinity, the following need to apply:
- Storage Servers should be present in different geographical locations.
- Mirroring, if configured, is recommended to be present in an alternate site - but can be at the same site as other Storage Servers.
- Backup clients should be configured to backup to Storage Servers in appropriate locations, so for example backup clients in London backup to Storage Servers in a London Datacentre.
To achieve this, the following configuration can assist:
- Assign Collections and Groups to appropriate Storage Servers or Storage Pools where new accounts will be created.
Example Collection to Storage Pool assignment:
- Create MSI deployment files (or enter details manually for Linux and Mac) for the appropriate groups, so that the accounts will be created on Storage Servers in the correct locations.
Example of Deploying for a Group:
Snapshots when run, can then be imported at a site local to the backup clients, rather than requiring long travel time between sites.
Note: The geographic affinity principle described here can also be applied as �?oanti-affinity�?� where it is desirable to locate backup clients��away from��the local site. This is often desirable from a Disaster Recovery perspective to ensure that backup data is located in a separate location to source data. In our example above, backup clients from London would use the Manchester Storage Server if anti-affinity was desired.
Using a Temporary Site for Snapshot or Initial Backups
Whilst geographic affinity may be appropriate if you have permanent sites in different locations, it may also be desirable to set up a site on a temporary basis before relocating the accounts to their permanent location.
Temporary Site Example
In the example above, the �?oGlasgow DC�?� is a temporary site. Backup clients in the Glasgow area are created on the ss02.domain.com Storage Server in the Glasgow DC, either sending over the network or using a snapshot for the initial backup.
When snapshots and initial backups are complete, the accounts can then be moved to their permanent location on ss01.domain.com using an account move. This does not interrupt backups, and incremental backup data is sent direct to the permanent Storage Server without requiring a full backup or snapshot.
To achieve this, as with the conventional affinity configuration, the appropriate group should be configured to match the Storage Server, and MSI file deployed for this group.
Old Article ID: 340
Previous Views: 97
Posted: 11 Dec, 2015 by Flood A.