Multiple Regions: End-Users’ Experience

Note: This document is based on Jelastic version 3.3.

The significant versatility that the Multiple Regions model brings to hosting service providers and ISVs in building their complex cloud solution, can be leveraged by the end-users as well.

Depending on the chosen multi-region structure applied to a particular Jelastic installation, they can receive a number of benefits due to the ability to select the most suitable hardware for their purposes according to their group. In the most common case, this choice can be driven by differentiation of a region parameters, such as:

  • geographical location - for getting a better response time and/or wide services’ distribution
  • quality & capacity - for adjusting the hosting conditions up to the current needs, e.g. cheaper hardware - for development and testing, a more superior one - for production
  • cost - for choosing the most affordable pricing policy based on the budget available

Herewith, alongside selecting the desired hardware set during a new environment creation, the already running project can be subsequently easily moved to another location, within a few clicks if needed.

So, let’s discover how these operations can be performed through the end-users’ dashboard.

Environment Regions at the Jelastic Dashboard

1. Once the Multi-Regions feature is enabled for the end-users, a new drop-down list with the available hardnode groups enumerated appears at the corresponding dashboard dialog frames, which are intended to initiate creation of a new environment:

  • environment wizard

Note: The only exception is the operation of cloning - in this case a new environment is automatically created in the same hardware group. However, it can be easily moved to the desired location manually, with the help of the migration option.

You may also notice, that upon selecting particular hardware, the environment domain (shown next to the field with its name) may also vary, depending on a region settings.

2. The last More details point of the list, shown above, redirects a user to the Regions tab inside the Quotas & Pricing information window by default.

It is suggested that here the detailed info on the provided regions can be found (specified according to the appropriate instruction), e.g. a general description with the list of supplied parameters and included features. However, in case you’ve modified the More details string’s parameters during the customization, this link would lead to the corresponding documentation or site page.

In addition, in the next Pricing tab within the same frame, the details on the charged resources and licenses’ cost for every region can be viewed:

Tip: In case the Regions tab has been disabled with the help of the ENV_REGIONS_PANEL setting, this one will be shown instead.

3. For the quick environment differentiation by regions at the dashboard home page, every one of them is supplied with a special tiny icon.  

Upon hovering over a particular pictogram, it is expanded for the corresponding hardnode group name to be displayed.

Environment Migration between Regions

The initially chosen environment’s location can be changed using the migration option.

Note 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:

  • clicking on the Change environment topology button and choosing the Migrate option within the regions’ list

  • selecting the Settings button and switching to the Migration menu option

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).

Tip: Similar operations can be initiated by a cluster administrator via the JCA > Environments section using the appropriate Migration option.

And below we’ll consider both migration modes in more details.

Live Migration

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.

Offline Migration

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.