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:
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
Slave Status prüfen
Wichtigste Stellen sind:
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:
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.