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 und funktionell
- 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)