Perform the following steps to add a region in a multi-region
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.
For example:
[europe]# mmobj multiregion export --region-file /tmp/multiregion_europe.dat
- Copy the file manually to the second region.
For
example:
[europe]# scp /tmp/multiregion_europe.dat asia:/tmp
- From the second region, join the multi-region environment
as follows:
- Use the file generated in the first region while deploying
object on the second region by using the mmobj swift base command.
For example:
[asia]# mmobj swift base -g /mnt/gpfs0 --cluster-hostname gpfs-asia --admin-password Passw0rd
-i 100000 --admin-user admin --enable-s3 \
--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 object protocol in the 2nd region and joins the
1st region. Additional devices are added to the primary ring files
for this region.
- Export the ring file data of the second region.
For
example:
[asia]# mmobj multiregion export --region-file /tmp/multiregion_asia.dat
- Copy the file manually to the first region.
For
example:
[asia]# scp /tmp/multiregion_asia.dat europe:/tmp
- In the first region, update the local ring files with the
configuration of the second region.
For example:
[europe]# mmobj multiregion import --region-file /tmp/multiregion_asia.dat
This
step reads in the ring files which are updated with the information
of the second region. This update ensures that the data of the second
region contains a new region and therefore replaces the associated
ring files in the first region with the ones from the second region.
Note: Now the two clusters have been synced together
and can be used as a multi-region cluster. 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 object-store service for the 2nd
region is created in Keystone.
The regions need to be synced
in the future any time region-related information changes. This includes
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 additional CES addresses
to a region causes the ring files to be rebuilt.
- In the second region, add CES addresses and update other
clusters.
For example:
[asia]# mmces address add --ces-ip asia9
This
steps adds an address to the CES IP pool. This also triggers a ring
rebuild which 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 IPs from the second region.
For
example:
[asia]# mmobj multiregion export --region-file /tmp/multiregion_asia.dat
- Copy the file manually to the first region.
For
example:
[asia]# scp /tmp/multiregion_asia.dat europe:/tmp
- In the first region, update with changes for the new second
region address in the ring.
For example:
[europe]# mmobj multiregion import --region-file /tmp/multiregion_asia.dat
This
step imports the changes from the second region. When this 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. This is typically due to some local configuration
changes on this cluster which 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.