- 3 minutes to read
- Print
- DarkLight
- PDF
How to manage the cluster
- 3 minutes to read
- Print
- DarkLight
- PDF
The entire process of configuring a cluster and checking its status can be performed using the cluster
command. In addition to the process, we will use the application
command to start instances and define a primary instance.
mt4adm@vmdf-giskard:~$ sudo orbit cluster --help
Usage: orbit cluster <command>
High Availability and Disaster Recovery settings tools
Commands:
cluster config
cluster start
cluster stop
cluster restart
cluster status
cluster arbiter
cluster net-check
cluster nodename
cluster rotate-ssl
Flags:
-h, --help Show context-sensitive help.
Create the cluster
If there are doubts about enabling connections between the nodes, use the orbit cluster net-check
command, adding the desired hosts for verification. Consult the documentation on the ports that need to be opened in the Firewall Rules for more information.
To create the cluster, at least two instances are required. For example, we will call the instances A and B. Follow the following order to set up the cluster.
- Activate instance A for both activation license and application activation.
- Start the application on instance A with the
orbit application start
command.
Before configuring the cluster, it is crucial to include the cluster members in the allow list of the firewall of each instance. For example, on instance A, it is necessary to add instance B to the allow list, and vice versa. For more details, For more details, see the How to Manage the firewall with the Orbit CLI documentation
The following commands are for sudo orbit cluster config
:
- The
--ip
argument should be used with the IP of the instance the command is being executed on; - Configure the cluster on instance A by filling the
--ip
parameter with the IP of instance A and the--nodes
parameter with the IPs of instances A and B respectively;
Start the cluster on instance A with the 'orbit cluster start' command and wait at least 1 minute for normalization.
Having an arbitrator in a cluster is crucial for resolving disputes between nodes, ensuring system stability and integrity. It acts as a neutral third party in case of failure, avoiding inconsistencies and maintaining environment reliability. Learn more about the configuration and importance of the arbitrator at Arbitrator documentation.
- Designate instance A as primary through the
orbit application primary
command.
Activate instance B with the activation license and keep the application inactive.
Configure the cluster on instance B by filling the
--ip
parameter with the IP of instance B and the--nodes
parameter with the IPs of instances A and B respectively;Start the cluster on instance B with the
orbit cluster start
command and wait at least 1 minute for normalization.
Instance A
mt4adm@vmdf-giskard:~$ sudo orbit application master
The application services will be stopped or restarted during the process.
Are you sure you want to proceed: y
Application: Active
Replication: Inactive
Instance: Primary
For clusters with members in different data centers, it is recommended to use high latency between the members.
Members from the same data center should be configured with the same segment. If a data center has only one member, you can leave the Network Segments field empty.
mt4adm@vmdf-giskard:~$ sudo orbit cluster config
--ip=172.18.77.184
--nodes=172.18.77.184,172.18.77.186
--segment=0
--latency="low"
Are you sure you want to proceed: y
Done!
No errors reported
mt4adm@vmdf-giskard:~$ sudo orbit cluster start
Are you sure you want to proceed: y
Done!
No errors reported
Instance B
mt4adm@vmdf-giskard:~$ sudo orbit cluster config
--ip=172.18.77.186
--nodes=172.18.77.184,172.18.77.186
--segment=1
--latency="low"
Are you sure you want to proceed: y
Done!
No errors reported
mt4adm@vmdf-giskard:~$ sudo orbit cluster start
Are you sure you want to proceed: y
Done!
No errors reported
To ensure proper cluster operation, it is essential to maintain network latency between nodes below 30ms. Additionally, specific recovery settings are required to facilitate recovery in case of failure. You can find details on these settings at the recovery documentation .
Cluster Status
Through the orbit cluster status
command, you can observe various properties of the cluster. Since there is a lot of information, we will not list all the details in the manual. But we will present the essential information to understand if the cluster is active and without problems.
Pay attention to the final block of the status, called Cluster nodes
. In this block, you will see who the cluster members are and the synchronization timestamp between them. There is also the status of the current instance which should be marked as synced.
mt4adm@vmdf-giskard:~$ sudo orbit cluster status
...
============================================================
Cluster nodes
Cluster member: ID [0] - UUID [64661644-b0df-11ea-80b2-8ee23c1303c0] -
Hostname [vmdf-giskard-3232290344] - Timestamp [1592428528]
Cluster member: ID [1] - UUID [9dff00d8-b0df-11ea-86c4-83725d654e03] -
Hostname [vmdf-giskard-3232290348] - Timestamp [1592428528]
Cluster UUID: 64679b9f-b0df-11ea-a6e5-67ba900fecc0
vmdf-giskard details: status=synced
vmdf-giskard is primary node ?: 1
============================================================"