Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This section describes shell tools required for management of the system at the very system level. All these tools are shipped with the JeraSoft Billing distributive. You need to use SSH or direct access to the server in order to run any of these tools. Please notice that most of the given tools require root access and show inline help when run running without arguments.

Panel
borderColor#FFBABA
bgColor#FFBABA
borderWidth2px
borderStylesolid

Important!

Please use these tools only if you have a clear understanding of what you are doing. Misuse of the tools may cause improper functioning of the system.

...

  1. Before installation of the JeraSoft Billing to check minimal hardware and software requirements. At this stage, you may download the tool separately from the JeraSoft Billing.
  2. After installation of the JeraSoft Billing to check security recommendations. Usually, you need to tune your firewall settings according to the JeraSoft Billing First Steps.

...

ArgumentDescription
<service-name>
Short name of the service. Run the tool without arguments to get a list of the services at your system. 
<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:

OptionDescription
--path=<path>
Specify the JeraSoft Billing location. Only if different from <VCS_PATH>
--user=<user>
Specify user the JeraSoft Billing runs under. Only if different from "vcs".

...

Panel
borderColor#ffffb3
bgColor#ffffb3
borderWidth2px

(warning)   Attention

The tool also complies with LSB Init Scripts standard. It allows to analyse analyzing exit code of each action in case of automated usage.

...

The tool is used to manage clusters. It allows to init the cluster, add and promote a slave to master, etc. 

Code Block
languagebash
titleUsage
<VCS_PATH>/bin/cluster <command> [<options>]

The tool 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.

...

OptionDescriptionDefault
--ip=<ip>
IP Address of the Master server
none
--ssh-port=<port>
SSH Port at the master server
22
--data=<path>

PostgreSQL data path on the master system

autodetect
--vcs-path=<path>
Path to the JeraSoft Billing on Slave
<VCS_PATH>

...

The command is run on the Master and used for:

  • 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 failover.
Code Block
titleBash
<VCS_PATH>/bin/cluster init-slave --ip=<IP-of-slave> [<extra-options>]

...

OptionDescriptionDefault
--ip=<ip>
IP Address of the Slave server
none
--ssh-port=<port>
SSH Port at the slave server
22
--username=<login>
Login to the slave server
jerasupport
--data=<path>

PostgreSQL data path on the slave system

same as master

--vcs-path=<path>
Path to the JeraSoft Billing on Slave
<VCS_PATH>
--role=<role>
Role of the secondary system. Could be [redundancy or reporting]
redundancy

...

The command is run on the Slave and used to promote the current Slave to Master

Code Block
titleBash
<VCS_PATH>/bin/cluster promote

The command is used for failover. After you fix old Master, you may add it as a new Slave using "init" command.

Panel
borderColor#ffffb3
bgColor#ffffb3
borderWidth2px

(warning)   Attention

In case when you have more than 2 nodes in the cluster, you need to re-init all other slaves from this new Master.

...

During initialization of the cluster, the tool adds this command to the crontab (/etc/cron.d/vcs-cluster) at the Slave node. 

...

Code Block
titleBash
<VCS_PATH>/bin/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
the row: Master (master ip): NOT AVAILABLE 

It's a normal behavior. Instead, please pay attention to Activity delay parameter − it shows large values if replication is broken and servers are not in sync. 

...