The initially chosen environment’s location can be changed using the migration option.
that migration between different regions is allowed only if you enable the corresponding Allow migration
check box at the appropriate frame
during its creation/edition. Herewith, the migration within the confines of a single region (if it comprises several hardware node groups) is available by default and can’t be disabled.
This process can be initiated through:
In both cases, you’ll be redirected to the same frame with a Current region of the chosen environment stated and an option for choosing the Target region, i.e. the hardnode group it should be migrated to.
Note that the pricing policy in different regions can vary - the actual information can be discovered using the corresponding link, provided within the tip under the Target region selector.
Just lower down the frame the Live migration section is placed, either with the special switcher shown or providing some additional info, depending on the chosen target region. It is used to define which migration type (among the two provided ones) should be used:
live migration - available only between the hardware node groups of a single region (marked with the special LM label within the list for more convenience)
offline migration - can be used for any hardnode groups
State all the necessary conditions and click on Verify & Migrate at the bottom of the section to initiate the relocation. Confirm your decision within the appeared pop-up frame.
Once the migration is completed, the appropriate information message will appear at the dashboard and the region label next to the environment will be changed. In addition, you’ll receive the notification email with the migration details (like its duration for every container and any changes that happened with their parameters due to this process).
Similar operations can be initiated by a cluster administrator via the JCA > Environments
section using the appropriate Migration
And below we’ll consider both migration modes in more details.
The Live migration option is available only during migration within the confines of the same region, i.e. both current and target hardnode groups should belong to the same datacenter. If this condition is satisfied, a special LM label is used for notification about the option’s availability.
Upon selecting such a hardware node group as a target region, the Live migration switcher will appear beneath (in the enabled state by default).
If choosing this type of migration, the environment relocation will be performed implicitly, i.e. without a restart of containers and any extra configurations needed, so your app’s users won’t face any interruptions.
Note that in case of a high load (i.e. big amount of incoming requests) an environment can still undergo a brief downtime (about 10 seconds) with the 502 - environment stopped error shown. Nevertheless, when data is successfully transferred, it will resume its work automatically.
If for some reason the offline mode is needed - just turn off the corresponding switcher.
In such a case, an environment with all of the containers in it will become unavailable for the whole relocation process and resume its normal work, after this operation completes, with no additional manual adjustments required.
When the live migration option is unavailable (due to moving an environment to another data center) or in case it was disabled manually, the offline mode is used. In contrast to the online one, during such a relocation, an environment will be shut down until the end of this process.
In addition, if this migration type is the only available one, some environment settings, like nodes’ IP addresses and, optionally, domain name assigned (if it differs from the current region’s one), will be changed. Thus, after the migration is completed, some manual configurations may be required to restore the normal operability of the moved application - all of the required information will be additionally sent to an environment owner via email.
Obviously, based on the abovementioned pros and cons, live migration is a much more preferable option, if available.