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.