Adding a region in a multi-region Swift Object deployment

Perform the following steps to add a region in a multi-region Swift Object deployment environment.

In the command examples, Europe is the first region and Asia is the second region.

Export the information of the first region to a file by using the mmobj multiregion export command:
```
[europe] mmobj multiregion export --region-file /tmp/multiregion_europe.dat
```

Copy the file manually to the second region:

[europe]# scp /tmp/multiregion_europe.dat asia:/tmp

From the second region, join the multi-region environment as follows:
1. Use the file that is generated in the first region while you deploy Swift Object in the second region by using the mmobj swift base command:
```
[asia] mmobj swift base -g /mnt/gpfs0 --cluster-hostname gpfs-asia --pwd-file mmobjpwd
-i 100000 --admin-user admin \
  --enable-multi-region  --remote-keystone-url  http://gpfs-asia:35357/v3
 --join-region-file /tmp/multiregion_europe.dat \
        --region-number 2 --configure-remote-keystone
```
  This step installs the Swift Object protocol in the second region and it joins the first region. More devices are added to the primary ring files for this region.

Export the ring file data of the second region:

[asia] mmobj multiregion export --region-file /tmp/multiregion_asia.dat

Copy the file manually to the first region:

[asia]# scp /tmp/multiregion_asia.dat europe:/tmp

In the first region, update the local ring files with the configuration of the second region:
```
[europe] mmobj multiregion import --region-file /tmp/multiregion_asia.dat
```
This step reads in the ring files that are updated with the information of the second region. This update ensures that the data of the second region contains a new region. It also replaces the associated ring files in the first region with the ones from the second region.

Note:

The two clusters are now synced together and can be used as a multi-region cluster. Swift Objects can be uploaded and downloaded from either region. If the installation of the second region specified the --configure-remote-keystone flag, a region-specific endpoint for the Swift Object-store service for the second region is created in Keystone.

The regions must be synced in the future anytime region-related information changes. These changes include changes in the set of CES IP addresses (added or removed) or if storage policies were created or deleted within a region. Changes that affect the swift.conf file or ring files need to be synced to all regions. For example, adding more CES addresses to a region causes the ring files to be rebuilt.

In the second region, add CES addresses and update other clusters:
```
[asia] mmces address add --ces-ip asia9
```
This step adds an address to the CES IP pool and triggers a ring rebuild that changes the IP-to-device mapping in the ring files.
Export the ring data so the other clusters in the region can be updated with the new IP addresses from the second region:
```
[asia] mmobj multiregion export --region-file /tmp/multiregion_asia.dat
```

Copy the file manually to the first region:

[asia]# scp /tmp/multiregion_asia.dat europe:/tmp

In the first region, update with changes for the new second region address in the ring:
```
[europe] mmobj multiregion import --region-file /tmp/multiregion_asia.dat
```
This step imports the changes from the second region. When the change import is complete, a checksum is displayed which can be used to determine when regions are synchronized together. By comparing it to the one printed when the region data was exported, you can determine that the regions are synchronized when they match. In some cases, the checksums do not match after import. The checksums do not match because some local configuration changes on this cluster that are not yet synced to the other regions. If the checksums do not match, then this region's configuration needs to be exported and imported into the other region to sync them.