Documente Academic
Documente Profesional
Documente Cultură
0 High
Availability Management Guide
July 17, 2019
Any reproduction or redistribution of part or all of these materials is strictly prohibited. Information in this publication
is subject to change without notice. MobileIron, Inc. does not warrant the use of this publication. For some phone
images, a third-party database and image library, Copyright © 2007-2009 Aeleeta's Art and Design Studio, is used.
This database and image library cannot be distributed separate from the MobileIron product.
“MobileIron,” the MobileIron logos and other trade names, trademarks or service marks of MobileIron, Inc.
appearing in this documentation are the property of MobileIron, Inc. This documentation contains additional trade
names, trademarks and service marks of others, which are the property of their respective owners. We do not
intend our use or display of other companies’ trade names, trademarks or service marks to imply a relationship
with, or endorsement or sponsorship of us by, these other companies.
HA scenario terminology 1
Two Core servers and two Sentry servers on one data center 5
Three Core servers and two Sentry servers on two data centers 6
HA Configuration window 8
HA setup workflow 9
Atlas configuration 13
The Secondary server periodically synchronizes with its paired Primary server, ensuring it has the latest changes
as the Primary. The synchronization process frequency is configurable and automated. When the synchronization
process detects any changes in the Primary, the Secondary replicates the changes. When it detects that the
Primary is unresponsive, it initiates a failover process. Depending on how the system was configured for failover,
the Secondary could continue to operate in a standby state, but most often it is configured to swap roles with the
Primary server so that the Secondary server is in an active state while the Primary server is inactive.
HA scenario terminology
Terminology is important when discussing HA because while the server names are static (Primary/Secondary), the
states can swap (Active/Standby).
The following tables describes the modes and states for MobileIron Core servers in an HA environment.
TABLE 1. HA SCENARIO TERMINOLOGY
Secondary Standby
Primary is up again. The Primary Swaps roles with the Secondary and returns to an Active
administrator must manually state.
sync Primary from Secondary Secondary Returns to Standby state.
When failover occurs, any number of scenarios can take place depending on how an HA environment is configured.
The following scenarios are described in the following sections:
• Two Core servers across two data centers
• Three Core servers across two data centers
• Two Core servers and two Sentry servers on one data center
• Three Core servers and two Sentry servers on two data centers
NOTE: Disable SSH protection on the Firewall when connecting between two Cores
This approach is typically used in environments where a main data center is expected to be always available and a
Disaster Recovery data center is exclusively used as part of business continuity approach and typically requires
manual intervention to bring online.
Two Core servers and two Sentry servers on one data center
The example in this section describes a typical Core and Sentry High Availability Solution.
FIGURE 3. TWO CORE SERVERS AND TWO SENTRY SERVERS ON ONE DATA CENTER
While the Sentry HA details are outside the scope of this document, it is used here to show a typical MobileIron
complete HA solution architecture. For details about Sentry, please refer to the latest MobileIron Sentry Guide.
Three Core servers and two Sentry servers on two data centers
The example in this section describes one of the most complete and complex Core/Sentry HA Architectures with
all related components.
FIGURE 4. THREE CORE SERVERS AND TWO SENTRY SERVERS ON TWO DATA CENTERS
IMPORTANT: If the option to swap Core roles is implemented as part of the Core HA Recovery, the
necessary changes must be made to the load balancer to match the Core HA
architecture, that is, having the right monitors checking the correct Cores.
Procedure
1. Log into the System Manager.
2. Go to Maintenance > HA Configuration to open the HA Configuration window.
3. Modify one or more of the fields, as necessary.
Refer to HA Configuration window table for details.
4. Click Save > Apply > OK.
HA Configuration window
The following table summarizes fields and descriptions in the HA Configuration window:
TABLE 2. HA CONFIGURATION WINDOW FIELDS
Fields Description
High Availability This feature provides the ability to Enable or Disable HA. The default is Disable. The
Enable radio button needs to be selected followed by Save and Apply in order to
enable HA. Enabling and Disabling HA starts (enable) or stops the scheduling process.
Mode This feature indicate the initial role this server will have in the HA configuration. The two
options are:
• Primary – This is the Core where all traffic and work will go to during normal
operation.
• Secondary – This is the redundant Core server, which frequently checks the status
of the Primary (heartbeat) and periodically replicates from it. The replication
process is initiated and controlled by the Secondary server. This ensures the
Secondary is up-to-date and ready to take over in case of a Primary failure.
Manage Trusted This feature allows for the setup and configuration of the SSH keys between Core
Hosts servers. The exchange of SSH keys is used to establish the trust relationship between
servers by using public-key cryptography and challenge-response authentication. This
step is fundamental for HA Cores to communicate with each other.
Fields Description
HA Status This section provides details on the last recorded HA activity and only displays when
Primary is selected for Mode. It provides the status of its pair system, its hostname/IP
(Primary mode
address, and the last time the Secondary has synchronized with it.
only)
Node Status NOTE: This option only displays when Secondary is selected for Mode.
(Secondary mode This feature indicates the current server status in relationship to the Core HA
only) configuration. The default value of Standby indicates the server is a Standby server
and is allowed to sync with its Primary server. The state of Active indicates the system
was originally set up as Standby, but has been promoted to Active. This occurs when
the Secondary server is not able to communicate with the Primary server and a failover
event occurs OR when the Active button is manually selected. In either case, a
Standby server in Active state does not sync with its Primary server. Only a
Standby/passive server syncs with its Primary server.
HA setup workflow
A proper Core HA setup configuration consists of the following steps:
• Step 1 – Set up network components
• Step 2 – Enable HA on Primary server
• Step 3 – Enable HA on Secondary server
• Step 4 – Exchange SSH keys between servers
• Step 5 – Configure and test HA sync on Secondary Core server
• Step 6 – Configure sync schedule and notifications
• Step 7 – Test and validate the Core HA environment
Secondary Bi-directional connection to Primary Core Both Primary and Secondary Unique
over ports 8443, 443 & 22 in addition to servers must be running the hostname for
standard Core FW requirements same software release each Core
NOTE: The initial sync will copies everything from one server to another while subsequent syncs only
copy changes. Therefore, the initial sync will take more time than subsequent syncs.
Procedure
1. Go to the Secondary server.
2. Go to the Secondary Configuration section.
3. Select the Primary server from the Hostname/IP drop-down menu.
4. Click Run Sync Now to test all the components in the HA environment.
5. Click Sync History to see the sync execution details.
6. Wait for the sync process to complete then click Refresh to update the Last Sync Status fields.
Procedure
1. Go to the Secondary Configuration section.
2. Select a time in the StartTime (GMT) drop-down menu to set the starting time when the first replication is to
occur.
This time is in UTC time. Note that this value overwrites the scheduler every time you save this page.
3. Enter a value into the Run Every box to set how often the replication process executes.
This value starts its reference point from the StartTime value. You can set the time in minutes, hours, or days.
4. Go to the Fail Over Controls section.
5. Enter the following values for:
- Heartbeat Interval: to control how often the Secondary server tries to connect to the Primary server to
check it is alive.
- Consecutive Heartbeat failures before failover: to control how many consecutive connection attempts
to the Primary can failed before attempting to promote the Standby server to Primary (active).
- Re-check interval: to define the amount of time between connection attempts when the previous attempt
resulted in connection failure. This is the retry wait time between attempts.
6. Indicate what happens when the Primary is unavailable and a failover should occur by selecting one of the
options for If Failure Detected:
- Keep in Standby: this option does not allow the Secondary to become Primary. The failover process gets
initiated, notifications are completed, but the Secondary stays in standby mode.
Procedure
1. Disable HA on the Secondary Core.
2. Ensure that any currently running replication process is allowed to complete before upgrading the Core.
NOTE: Do not proceed unless the Last Sync Status has a date/time in the Completed: field and Success
is displayed for Result.
3. Disable the load balancer from detecting any of the HA Cores from becoming unavailable and failing over.
4. Upgrade the Secondary and validate the upgrade.
- Make this server Primary so you can download the Core upgrade software (allowing the server to connect
to support portal)
- Upgrade and validate the upgrade.
- Return the server mode back to Secondary.
5. Upgrade the Primary Core and validate the upgrade.
6. Enable HA on the Secondary.
7. Perform test and validation on the Core HA environment. Complete the steps outlined in the Step 7 – Test and
validate the Core HA environment section.
8. Review and update the rest of the HA configuration parameters, especially the StartTime and Run Every
parameters, as these will most likely need to be updated.
9. Re-enable the load balancer.
Command Description
failover mode primary This command changes the Core mode to Primary. This has the same effect as
having the system automatically failover when the Primary becomes unavailable.
This command is not limited by any other command or Core state and can be re-
executed, achieving the same results.
NOTE: A system in Primary mode will not replicate with any other Core
failover mode This command changes the Core mode to Secondary. This has the same effect as
secondary making the same change through the System Manager Portal, but does not restart
the replication scheduler. It is recommended to only use this command for upgrade
or troubleshooting purposes. The System Manager Portal HA configuration version
of this functionality should be used for normal HA operations.
failover sync <remote This command executes the Core replication process on demand. This command
host address> is identical to the Run Sync Now option in the System Manager Portal. This
command is intended to replicate Core environments either after recovering from a
failover or for troubleshooting purposes. The System Manager Portal HA
configuration version of this functionality should be used for normal HA operations.
failover client- This command prevents new device connections. This command is intended to
connection disable prevent new connections while the system is going through maintenance.
failover client- This command allows new device connections. This command is intended to
connection enable reverse the disable client-connection command.