A normal operation of a jtel solution is considered among other variables if:

• The storage is mounted (available via acd-store) 
  
  • redundancy is also synchronised (DRBD is on primary / primary)
• The database replication is synchronised.
• The load balancer for the distribution of the web sessions is accessible, all web servers are available
• The telephony servers are up and processing calls

This can be examined in detail as follows.

Examination Storage

Redundant Storage

Testing that DRBD is synchronised

On one of the STORE, check if the DRBD is synchronised:

cat /proc/drbd

Expected output - DRBD is primary/primary

version: 8.4.11-1 (api:1/proto:86-101)
GIT-hash: 66145a308421e9c124ec391a7848ac20203bb03c build by mockbuild@, 2018-04-26 12:10:42
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
 ns:0 nr:28894328 dw:118174057 dr:74296 al:6116 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Determine which STORE is active.

pcs status

Check on the active STORE if /srv/jtel/shared is mounted

ls /srv/jtel/shared

Expected output:

Output with among others the following directories:

• Data
• JTEL
• JTELCarrierPortal

Alle Storage

Check if the smb service is running (with redundancy to the active STORE):

systemctl status smb
expected output - Active:

[root@test9-store2 ~]# systemctl status smb
● smb.service - Cluster Controlled smb
Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; vendor preset: disabled)
Drop-In: /run/systemd/system/smb.service.d
└─50-pacemaker.conf
Active: active (running) since Tue 2019-03-19 04:02:48 CET; 3 weeks 5 days ago

From any other machine, check access to the storage

From another machine (except STORE itself), either:

ls /home/jtel/shared

Or from the Windows machine, open an Explorer to the \\acd-store\shared directory.

When error:

• Start the SMB service
• Check if the file system is corrupt (see \var\log\messages) and take measures for repair - see man xfs_repair at xfs filesystems
• Recovery of DRBD replication and STORE cluster with redundancy - see DRBD - Maintenance and Resolve Split Brain or Node errors

Check database replication 

On all database slaves, with redundancy, also on both master databases:

Login to mysql

mysql -u root -p

Check slave status

mysql> SHOW SLAVE STATUS\G

The most important points are: 

Slave_IO_Running: Yes
 Slave_SQL_Running: Yes

 Example output:

*************************** 1. row ***************************
 Slave_IO_State: Waiting for master to send event
 Master_Host: acd-dbm2
 Master_User: repl
 Master_Port: 3306
 Connect_Retry: 60
 Master_Log_File: binlog.000014
 Read_Master_Log_Pos: 77769753
 Relay_Log_File: mysqld-relay-bin.000028
 Relay_Log_Pos: 2698
 Relay_Master_Log_File: binlog.000014
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 Replicate_Do_DB:
 Replicate_Ignore_DB:
 Replicate_Do_Table:
 Replicate_Ignore_Table:
 Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
 Last_Errno: 0
 Last_error:
 Skip_Counter: 0
 Exec_Master_Log_Pos: 77769753
 Relay_Log_Space: 2916
 Until_Condition: None
 Until_Log_File:
 Until_Log_Pos: 0
 Master_SSL_Allowed: No
 Master_SSL_CA_File:
 Master_SSL_CA_Path:
 Master_SSL_Cert:
 Master_SSL_Cipher:
 Master_SSL_Key:
 Seconds_Behind_Master: 0
 Master_SSL_Verify_Server_Cert: No
 Last_IO_Errno: 0
 Last_IO_error:
 Last_SQL_Errno: 0
 Last_SQL_error:
 Replicate_Ignore_Server_Ids:
 Master_Server_Id: 2
 Master_UUID: f5b276fa-bb92-11e8-a4a9-005056b98358
 Master_Info_File: /var/lib/mysql/master.info
 SQL_Delay: 0
 SQL_Remaining_Delay: NULL
 Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
 Master_Retry_Count: 86400
 Master_Bind:
 Last_IO_error_Timestamp:
 Last_SQL_error_Timestamp:
 Master_SSL_Crl:
 Master_SSL_Crlpath:
 Retrieved_Gtid_Set:
 Executed_Gtid_Set:
 Auto_Position: 0
1 row in set (0.35 sec)

When error

• Recovery of the Replication
• See Database Operations

Testing load balancers and web servers

Testing load balancer

The basic accessibility of the web server as well as the function of the load balancer can be checked via the haproxy Stats website.

The access takes place via:

http://acd-lb:7777

with indication of user name and password.

The screenshot shows a sample output for a system with: 

• Redundant master-master-slave-slave databases
• Two web servers

The services should be green except for the 2nd database master, which is shown in light blue, as this server is configured as a backup for the first database master.

When error

Check if the haproxy service is started.

For redundancy: check cluster status with:

pcs status

and take appropriate measures.

Testing web server

The web servers can be checked individually for function by accessing and logging on to the jtel system, for example as sysadmin.

The following URL applies to https:

https://acd-lb/admin

After successful login the portal main page of the system administrator should be visible, here an example output:

When error

Restart single web server with:

service jboss restart

Testing Telephony

The telephony services are either:

• In the autostart of the respective user
• Configured as a service to the system

In a standard case (with user login), the following applications are started:

• jtel 8-Server
• GI2

Note: depending on the installation, a PBX connector may also be started.

Normal readiness and processing is shown in the following screenshot. Note the light green active line and the system messages in yellow.

The following services are visible:

• jtel 8-Server
• GI2 Dienst
• Cluster Listener Dienst
• Innovaphone PBX Connector

When error

Close all applications and restart them via the autostart group.

Or reboot the system.

Ein normaler Betrieb einer jtel Lösung liegt unter anderen vor wenn:

• Das Storage gemountet ist (über acd-store verfügbar), 
  • Bei Redundanz auch synchron ist (DRBD ist auf primary / primary)
• Die Datenbankreplikation ist syncrhon
• Der Load-Balancer für die Verteilung der Websessions ist erreichbar, alle Webserver sind verfügbar
• Die Telefonieserver sind hochgefahren und verarbeiten Gespräche

Dies kann im Einzelnen wie folgt geprüft werden.

Prüfung Storage

Redundanter Storage

Prüfung, dass DRBD syncrhon ist

Auf einer der STORE, prüfen ob das DRBD syncrhon ist:

cat /proc/drbd

Erwartete Ausgabe - DRBD ist primary/primary:

version: 8.4.11-1 (api:1/proto:86-101)
GIT-hash: 66145a308421e9c124ec391a7848ac20203bb03c build by mockbuild@, 2018-04-26 12:10:42
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
 ns:0 nr:28894328 dw:118174057 dr:74296 al:6116 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Feststellung, welcher STORE aktiv ist.

pcs status

Auf den aktiven STORE prüfen ob /srv/jtel/shared gemountet ist

ls /srv/jtel/shared

Erwartete Ausgabe:

Ausgabe mit unter Anderen folgende Verzeichnisse:

• Data
• JTEL
• JTELCarrierPortal

Alle Storage

Prüfen ob der smb dienst läuft (bei Redundanz auf den aktiven STORE):

systemctl status smb
Erwartete Ausgabe - Active:

[root@test9-store2 ~]# systemctl status smb
● smb.service - Cluster Controlled smb
Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; vendor preset: disabled)
Drop-In: /run/systemd/system/smb.service.d
└─50-pacemaker.conf
Active: active (running) since Tue 2019-03-19 04:02:48 CET; 3 weeks 5 days ago

Von einer beliebigen anderen Maschine, den Zugriff auf das Storage prüfen

Von einer anderen Maschine (ausser STORE selbst), entweder:

ls /home/jtel/shared

Oder von der Windows Maschine, einen Explorer auf das Verzeichnis \\acd-store\shared öffnen.

Bei Fehler

• Starten des SMB Dienstes
• Prüfung ob das File-System korrupt ist (siehe \var\log\messages) und Maßnahmen zur Reparatur ergreifen - siehe man xfs_repair bei xfs Dateisysteme
• Wiederherstellung der DRBD Replikation und STORE Cluster bei Redundanz - siehe DRBD - Maintenance and Resolve Split Brain or Node Errors

Prüfung Datenbankreplikation

Auf allen Datenbank Slaves, bei Redundanz, auch auf beide Master Datenbanken:

Auf mysql anmelden

mysql -u root -p

Slave Status prüfen

mysql> SHOW SLAVE STATUS\G

Wichtigste Stellen sind: 

Slave_IO_Running: Yes
 Slave_SQL_Running: Yes

 Beispielausgabe:

*************************** 1. row ***************************
 Slave_IO_State: Waiting for master to send event
 Master_Host: acd-dbm2
 Master_User: repl
 Master_Port: 3306
 Connect_Retry: 60
 Master_Log_File: binlog.000014
 Read_Master_Log_Pos: 77769753
 Relay_Log_File: mysqld-relay-bin.000028
 Relay_Log_Pos: 2698
 Relay_Master_Log_File: binlog.000014
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 Replicate_Do_DB:
 Replicate_Ignore_DB:
 Replicate_Do_Table:
 Replicate_Ignore_Table:
 Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
 Last_Errno: 0
 Last_Error:
 Skip_Counter: 0
 Exec_Master_Log_Pos: 77769753
 Relay_Log_Space: 2916
 Until_Condition: None
 Until_Log_File:
 Until_Log_Pos: 0
 Master_SSL_Allowed: No
 Master_SSL_CA_File:
 Master_SSL_CA_Path:
 Master_SSL_Cert:
 Master_SSL_Cipher:
 Master_SSL_Key:
 Seconds_Behind_Master: 0
 Master_SSL_Verify_Server_Cert: No
 Last_IO_Errno: 0
 Last_IO_Error:
 Last_SQL_Errno: 0
 Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
 Master_Server_Id: 2
 Master_UUID: f5b276fa-bb92-11e8-a4a9-005056b98358
 Master_Info_File: /var/lib/mysql/master.info
 SQL_Delay: 0
 SQL_Remaining_Delay: NULL
 Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
 Master_Retry_Count: 86400
 Master_Bind:
 Last_IO_Error_Timestamp:
 Last_SQL_Error_Timestamp:
 Master_SSL_Crl:
 Master_SSL_Crlpath:
 Retrieved_Gtid_Set:
 Executed_Gtid_Set:
 Auto_Position: 0
1 row in set (0.35 sec)

Bei Fehler

• Wiederherstellung der Replikation
• Siehe Database Operations

Prüfung Loadbalancer und Webserver

Prüfung Loadbalancer

Die grundsätzliche Erreichbarkeit der Webserver sowie Funktion des Load-Balancers kann über den haproxy Stats-Webseite geprüft werden.

Der Zugriff erfolgt über:

http://acd-lb:7777

Mit Angabe vom Benutzernamen und Passwort.

Im Screenshot ist eine Beispielausgabe für ein System mit: 

• Redundante Master-Master-Slave-Slave Datenbanken
• Zwei Webserver

abgebildet.

Die Dienste sollten grün sein, bis auf den 2. Datenbankmaster, der Hellblau abgebildet ist, da dieser Server als Backup für den ersten Datenbankmaster konfiguriert ist.

Bei Fehler

Prüfen ob der haproxy Dienst gestartet ist.

Bei Redundanz: prüfung Cluster Status mit:

pcs status

und entsprechende Maßnahmen ergreifen.

Prüfung Webserver

Die Webserver können einzeln auf Funktion geprüft werden, indem das Anmelden am jtel System aufgerufen und durchgeführt wird, beispielsweise als sysadmin.

Folgende URL gilt für https:

https://acd-lb/admin

Nach erfolgter Login sollte die Portal-Hauptseite des Systemadministrators sichtbar sein, hier eine Beispielausgabe:

Bei Fehler

Einzelner Webserver neutstarten mit:

service jboss restart

Prüfung Telefonie

Die Telefoniedienste sind entweder:

• In der Autostart des jeweiligen Benutzers
• Als Dienst am System konfiguriert

Im Normalfall (mit Benutzeranmeldung), werden folgende Anwendungen gestartet:

• jtel 8-Server
• GI2

Beachte: je nach Installation, wird ggf. auch ein PBX-Connector mit gestartet.

Eine normale Bereitschaft, sowie Verarbeitung, wird im folgenden Screenshot dargestellt. Beachten Sie die hellgrüne aktive Leitung, sowie die Systemmeldungen in Gelb.

Folgende Dienste sind sichtbar:

• jtel 8-Server
• GI2 Dienst
• Cluster Listener Dienst
• Innovaphone PBX Connector

Bei Fehler

Sämtliche Anwendungen schließen, und über die Autostartgruppe neu starten.

Oder das System neu booten.

Un fonctionnement normal d'une solution jtel est considéré parmi d'autres variables si :

• Le stockage est monté (disponible via acd-store) 
  
  • a redondance est également synchronisée (DRBD est sur le primaire / primaire)
• La réplication de la base de données est synchronisée.
• L'équilibreur de charge pour la distribution des sessions web est accessible, tous les serveurs web sont disponibles
• Les serveurs de téléphonie sont en place et traitent les appels

Ce point peut être examiné en détail comme suit.

Stockage des examens

Stockage redondant

Tester que le DRBD est synchronisé

Sur l'un des MAGASINS, vérifiez si le DRBD est synchronisé :

cat /proc/drbd

Résultats escomptés - DRBD est primaire/primaire

version: 8.4.11-1 (api:1/proto:86-101) GIT-hash: 66145a308421e9c124ec391a7848ac20203bb03c build by mockbuild@, 2018-04-26 12:10:42 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----- ns:0 nr:28894328 dw:118174057 dr:74296 al:6116 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Détermine quel MAGASIN est actif.

Statut pcs

Vérifiez sur le MAGASIN actif si /srv/jtel/shared est monté

ls /srv/jtel/shared

Résultats escomptés :

Sortie avec entre autres les répertoires suivants :

• Données
• JTEL
• JTELCarrierPortal

Tout le stockage

Vérifiez si le service smb fonctionne (avec redondance vers le magasin actif):

systemctl status smb expected output - Active: [root@test9-store2 ~]# systemctl status smb ● smb.service - Cluster Controlled smb Loaded: loaded (/usr/lib/systemd/system/smb.service; disabled; vendor preset: disabled) Drop-In: /run/systemd/system/smb.service.d └─50-pacemaker.conf Active: active (running) since Tue 2019-03-19 04:02:48 CET; 3 weeks 5 days ago

Depuis toute autre machine, vérifiez l'accès au stockage

D'une autre machine (sauf STORE lui-même), non plus :

ls /home/jtel/shared

Ou à partir de la machine Windows, ouvrez un explorateur vers la répertoire\\acd-store\shared.

Lorsque l'erreur :

• Démarrer le service SMB
• Vérifiez si le système de fichiers est corrompu (voir \var\log\messages) et prenez des mesures pour le réparer - voir man xfs_repair sur les systèmes de fichiers xfs
• Récupération de la réplication de la DRBD et du cluster STORE avec redondance - voir DRBD - Maintenance et résolution des erreurs de division du cerveau ou des nœuds

Vérifier la réplication de la base de données 

Sur tous les esclaves de la base de données, avec redondance, également sur les deux bases de données principales:

Se connecter à mysql

mysql -u root -p

Vérifier le statut de l'esclave

mysql> SHOW SLAVE STATUS\G

Les points les plus importants sont les suivants : 

Slave_IO_Running: Oui Slave_SQL_Running: Oui

 Exemple de sortie :

*************************** 1. row *************************** Slave_IO_State: Attente que le maître envoie l'événement Master_Host: acd-dbm2 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000014 Read_Master_Log_Pos: 77769753 Relay_Log_File: mysqld-relay-bin.000028 Relay_Log_Pos: 2698 Relay_Master_Log_File: binlog.000014 Slave_IO_Running: Oui Slave_SQL_Running: Oui Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_error: Skip_Counter: 0 Exec_Master_Log_Pos: 77769753 Relay_Log_Space: 2916 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_error: Last_SQL_Errno: 0 Last_SQL_error: Replicate_Ignore_Server_Ids: Master_Server_Id: 2 Master_UUID: f5b276fa-bb92-11e8-a4a9-005056b98358 Master_Info_File: /var/lib/mysql/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULLE Slave_SQL_Running_State: L'esclave a lu tous les journaux de relais; attendant que le thread d'E / S esclave le mette à jour Master_Retry_Count: 86400 Master_Bind: Last_IO_error_Timestamp: Last_SQL_error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0.35 sec)

Lorsque l'erreur

• Récupération de la réplique
• Voir Database Operations

Tester les équilibreurs de charge et les serveurs web

Test de l'équilibreur de charge

L'accessibilité de base du serveur web ainsi que le fonctionnement de l'équilibreur de charge peuvent être vérifiés via le site web de haproxy Stats.

L'accès se fait via :

http://acd-lb:7777

avec indication du nom d'utilisateur et du mot de passe.

La capture d'écran montre un exemple de sortie pour un système avec : 

• Bases de données redondantes maître-maître-esclave-esclave
• Deux serveurs web

Les services devraient être en vert, sauf pour le deuxième maître de base de données, qui est en bleu clair, car ce serveur est configuré comme une sauvegarde pour le premier maître de base de données.

Lorsque l'erreur

Vérifiez si le service d'haproxie est lancé.

En cas de redondance : vérifier le statut du cluster avec :

pcs status

et prendre les mesures appropriées.

Test du serveur web

Le fonctionnement des serveurs web peut être vérifié individuellement en accédant et en se connectant au système jtel, par exemple en tant que sysadmin.

L'URL suivante s'applique à https :

https://acd-lb/admin

Après une connexion réussie, la page principale du portail de l'administrateur système devrait être visible, voici un exemple de sortie :

Lorsque l'erreur

Redémarrer un seul serveur web avec :

service jboss restart

Tester la téléphonie

Les services de téléphonie ne le sont pas non plus :

• Dans le démarrage automatique de l'utilisateur respectif
• Configuré comme un service au système

Dans un cas standard (avec login utilisateur), les applications suivantes sont lancées :

• 8-Server jtel
• GI2

Note : selon l'installation, un connecteur PBX peut également être démarré.

L'état de préparation et le traitement normaux sont illustrés dans la capture d'écran suivante. Notez la ligne active en vert clair et les messages système en jaune.

Les services suivants sont visibles :

• 8-Server jtel
• Service GI2
• Service d'écoute des clusters
• Connecteur PBX Innovaphone

Lorsque l'erreur

Fermez toutes les applications et redémarrez-les via le groupe autostart.

Ou redémarrer le système.