Docs for all releases
Page History
...
The tool is used for management of System Services. It allows to correctly start, stop and perform other actions over various JeraSoft Billing Services such as RADIUS Server, SIP Server, Calculator, etc.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<APP_PATH>/bin/system/service <ACTION><COMMAND> [<service-name>] [<options>] |
The tool should be run under root or vcs user. The tool typically takes 2 arguments – action to perform and related system service. Actions prefixed with "all-*" do not require service name and operate over all services.
Command | Description |
---|
start | Start System Service Takes "--wait" |
option in order to wait and exit only when service finishes its execution. |
<action>
Action to perform, one of the following:
- start - start the service
- stop - stop the service
- restart - stop and then start the service
- reload - force config re-read without restart
- status - return current status of the tool
<service-name>
<action>
Action to perform, one of the following:
- start - start the service
- stop - stop the service
- restart - stop and then start the service
- reload - force config re-read without restart
- status - return current status of the tool
Additionally, you may pass the next options:
...
--path=<path>
...
--user=<user>
...
stop | Stop System Service |
restart | Stop and then start System Service |
reload | Send reload (HUP) signal to the System Service (forces reload of settings, connections, etc) |
status | Show current status of the System Service |
all-start | Start all required System Services (list of services varies depending on the role of the current node in the cluster) |
all-stop | Stop all running System Services |
all-status | Show status of all System Services on the current node |
Usage Examples
For your convenience there are some examples below:
Code Block | ||||
---|---|---|---|---|
| ||||
<VCS<APP_PATH>/bin/system/service restart bbradiusd restart |
Code Block | ||||
---|---|---|---|---|
| ||||
<VCS<APP_PATH>/bin/system/service start files_downloader start |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<APP<VCS_PATH>/bin/system/service bbsipd status | ||||||
Panel | ||||||
| ||||||
Attention The tool also complies with LSB Init Scripts standard. It allows analyzing exit code of each action in case of automated usage.all-start |
Cluster Manager
The tool is used to manage clustersnodes in the cluster deployment. It allows to init initialize the cluster, add and promote a slave a new node, promote redundancy to master, etc.
Code Block | ||||
---|---|---|---|---|
| ||||
<VCS<APP_PATH>/bin/system/cluster <command><COMMAND> [<options>] |
The tool requires "requires root" permissions. Cluster Manager takes command as a mandatory argument and additional options. Some of the commands may be run only on Master and others only on Slave. There are two available types of Slave: redundancy and reporting. All extra options for the commands are explained below in the corresponding subsection permissions. The list of arguments and other requirements depend on the command used. Please refer to the below table for a summary and respective sections for details.
Command | Description | Nodes | Root Required |
---|---|---|---|
status | Show status of the cluster | Any node | No |
init-master | Init Master Node configuration | Master | Yes |
init-slave | Init Slave Node configuration | Master | Yes |
promote | Promote current node to Master | Redundancy | Yes |
sync-files | Sync files from Master | Redundancy, Reporting, Processing | No |
remove-node | Remove Node from the Cluster | Master | Yes |
Cluster Status
The command shows Cluster Status, including all nodes with their roles, IP addresses, current lag to Master, and overall status.
Code Block | ||
---|---|---|
| ||
<APP_PATH>/bin/system/cluster status |
The command can be executed on the Master in order to get the most detailed information about the cluster:
Alternatively, the command can be executed at any other node - in this case, only the status of the connection between this particular node and the Master will be shown.
If any node failed and has been disconnected from the cluster it will be shown like this:
In this case, you have to re-check failed node, fix it and then return to the cluster using the "init-slave" command.
Init Master
The command is run on Master and used for Master to configure its parametersthe initial configuration of the Master Node.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster init-master --ip=<IP-of-master>ADDRESS> [<extra-options>]<options>] |
Command has to be executed on the Master node and requires root permissions. The following options are supportedThis command may require additional options:
Option | Description | Default |
---|---|---|
<IP- |
ADDRESS> | IP Address of the Master server (required) |
none
| |
--ssh-port=<port> | SSH Port |
as the master |
node | 22 |
--pg-data=<path> | Path to PostgreSQL data |
directory | autodetect |
--vcs-path=<path>
<VCS_PATH>
...
Init Slave
The command is run on the Master and used for:is used to add a node to the cluster. There are different contexts when it is required:
- First-time deployment of the cluster
- Addition of a new slave node to the cluster
- Addition of the
- first-time initialization of the cluster;
- addition of the new slave node to the cluster;
- addition of the old master to work as a slave after after failover.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster init-slave --ip=<IP-of-slave>ADDRESS> [<extra-options>] |
This command encapsulates 4 sub-commands:
- configuration of the Master to ship replication logs (
init-master
) - configuration of the Master to accept connections from the Slave (
init-master-access
) - configuration of the Slave to receive replication logs (
init-slave
) - show status of the cluster (
status
).
Each of these commands may be performed separately if you know exactly what you need.
This command may require additional options:
<options>] |
Command has to be executed on the Master node and requires root permissions. The following options are supported:
--ip=<ip>
none
Option | Description | Default |
---|---|---|
<IP-ADDRESS> | IP Address of the Slave server (required) |
|
--role=<role> | Role of the new node:
| redundancy |
--ssh-port=<port> | SSH Port at the |
remote node | 22 |
-- |
ssh-user= |
<user> | SSH User at the remote node |
jerasupport | |
--pg-data=<path> | Path to PostgreSQL data |
same as master
--vcs-path=<path>
<VCS_PATH>
--role=<role>
redundancy
...
directory at the remove node | autodetect |
Promote to Master
The command is run on the Slave and used to promote the current Slave Redundancy node to Master.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster promote |
Command has to be executed on the Redundancy node and requires root permissions. Reporting node can be used as a last resort if there are no Redundancy node alive. There are no options required.
After the promotion is performed, all required System Services will be started on the current node (new master)The command is used for failover. After you fix the old Master, you may add it as a new Slave using the "init-slave" command.
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Attention In case when you have more than 2 nodes in the cluster, you need to re-init all other slaves nodes from this new Master. |
...
Sync Files
The command is run on the Slave and used to synchronize files sync data and application files from the Master. The command is mostly used in crontab for auto-sync.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster sync-files |
During initialization of the cluster, tool adds this command to the crontab (/etc/cron.d/vcs-cluster) at the Slave node.
Cluster Status
Command has to be executed on the Redundancy node and by default, it is added to the crontab for automatic synchronization.
Remove Node
The command may be run on any node and used to get status of the cluster. The command is used to remove a node from the cluster.
Code Block | ||
---|---|---|
| ||
<VCS<APP_PATH>/bin/system/cluster status |
When the command is run on the Master, it shows the type of the node and attached Slaves that are up to date:
Code Block |
---|
[ NOTICE ] Cluster Status
ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'
Master (master ip): ACTIVE
Redundancy (slave ip): ACTIVE |
When the command is run on the Slave, it shows the type of the node and synchronization delay.
Code Block |
---|
[ NOTICE ] Cluster Status
ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}'
Master (master ip): NOT AVAILABLE | Activity delay: -00:00:58.393423
Redundancy (slave ip): ACTIVE |
Please don't worry if you see the following:
Code Block |
---|
the row: Master (master ip): NOT AVAILABLE |
It's normal behavior. Instead, please pay attention to Activity delay parameter − it shows large values if replication is broken and servers are not in sync.
...
remove-node <IP-ADDRESS> |
Command has to be executed on the Master node. The node in question shouldn't have any active database replication. The following options are supported:
Option | Description | Default |
---|---|---|
<IP-ADDRESS> | IP Address of the remote node (required) |
|