Ausfallserver: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: für OrgaMon System mit einem Linux-FirebirdSQL Server ist es leicht möglich einen Ausfall Server zur Verfügung zu stellen, der eine "Spare" Datenbank ständig in Ber...)
 
 
(15 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
für OrgaMon System mit einem Linux-FirebirdSQL Server ist es leicht möglich einen Ausfall Server zur Verfügung zu stellen, der eine "Spare" Datenbank ständig in Bereitschaft hält. Bei Ausfall des Hauptservers können die Clients direkt mit diesem Spare in Verbindung treten. Der Spare Datenbank fehlen in diesem Fall die Änderungen an der Datenbank der letzten 40 Minuten.
für eine OrgaMon-System-Installation mit einem Linux-System als FirebirdSQL Server ist es leicht möglich einen Ausfallserver zur Verfügung zu stellen, der eine "Spare"-Datenbank ständig in Bereitschaft hält. Dabei sollte es sich wiederum um einen Linux-Server handeln. Bei Ausfall des Hauptservers können die Clients direkt mit diesem Ausfallserver in Verbindung treten. Der Spare-Datenbank fehlen in diesem Fall die Änderungen an der Datenbank der letzten 40 Minuten. <b>Ausfallserver</b> und <b>Hauptserver</b> sollten in unterschiedlichen Brandschutzzonen gehostet werden.


== Vorbereitungen ==
== Vorbereitungen ==
Zeile 5: Zeile 5:
'''ssh-Automatisierung'''
'''ssh-Automatisierung'''


Der Spare (genant Client) muss zunächst mit dem Hauptserver (genannt Server) bekannt gemacht werden, dies ist hier  
Der Ausfallserver muss zunächst mit dem Hauptserver bekannt gemacht werden, dies ist hier [[Linux.ssh]] beschrieben. Dies ist notwendig, da wir in der ersten Phase den Client veranlassen das Backup auf dem Server zu starten. Dazu muss sich der Client innerhalb eines Scripts in den Server "einloggen" um ein dortiges Script zu starten.
[[Linux.ssh]] beschrieben. Dies ist notwendig, da wir in der ersten Phase den Client veranlassen das Backup auf dem Server zu starten. Dazu muss sich der Client inerhalb eines Scripts in den Server "einloggen" um ein dortiges Script zu starten.<br>
<br>


'''Samba auf dem Client'''
'''Samba auf dem Client'''


Der Client muss eine SMB-Freigabe anbieten, auf dem der Server sein .fbak (die Datensicherung) ablegen kann. Diese wird nicht umständlich nach der Erzeugung umkopiert, sondern direkt auf dem Share, also direkt auf dem Spare angelegt.
Der Client muss eine SMB-Freigabe anbieten, auf dem der Server sein .fbak (die Datensicherung) ablegen kann. Diese wird nicht umständlich nach der Erzeugung umkopiert, sondern direkt durchen firebird-Server auf dem Share, also direkt auf dem Plattenbereich des Spares angelegt.
Zudem erreichen wir so, dass möglichst zeitnah eine Sicherung der aktuellen Datenbank auf einer anderen Platte (als die der Datenbank selbst) zur Verfügung steht.  


'''FirebirdSQL auf beiden Systemen'''
'''FirebirdSQL auf beiden Systemen'''


Beide Systeme müssen einen FirebirdSQL Dienst am laufen haben.
Beide Systeme müssen einen FirebirdSQL-Dienst am laufen haben.


== Sicherungs-Phasen ==
== Sicherungs-Phasen ==


* In der <code>/etc/crontab</code> des Spares wird ein Sicherungsscript "spare.sh" jede Stunde gestartet
* In der <code>/etc/crontab</code> des Spares wird ein Sicherungsscript "spare.sh" jede Stunde (zu den üblichen Arbeitszeiten) gestartet
 
#min  hour                              daymo  month  daywk  usr  cmd
0    4,6,8,9,10,11,12,13,14,15,16,18  *      *      1-5    root  /etc/spare.sh
 
* Das Script verlanlasst den Server die Datenbanksicherung auf dem Share des Spare abzulegen
* Das Script verlanlasst den Server die Datenbanksicherung auf dem Share des Spare abzulegen
* Danach wird die Datenbank vom Spare restored und online geschaltet (STOP/COPY/START).
* Danach wird die Datenbank vom Spare restored und online geschaltet (STOP/COPY/START).


  #!/bin/bash
  #!/bin/bash
  #  spare.sh (auf dem Client)
  #  
#
  # /etc/spare.sh (auf dem Client)
  #
  #
  BAND=$(date +%s)
  BAND=$(date +%s)
  ssh server /root/save.sh prod-db $BAND
  ssh server /etc/save.sh prod-db $BAND
  GBAK -R -P 16384 -USER SYSDBA -PASSWORD masterkey $BAND.fbak spare.fdb.tmp
  rm /srv/smb/spare.fdb.tmp
/opt/firebird/bin/gbak -R -P 16384 -USER SYSDBA -PASSWORD masterkey /srv/smb/$BAND.fbak /srv/smb/spare.fdb.tmp
  rcfirebird stop
  rcfirebird stop
  rm spare.fdb
  rm /srv/smb/spare.fdb
  mv spare.fdb.tmp spare.fdb
  mv /srv/smb/spare.fdb.tmp /srv/smb/spare.fdb
rcfirebird start


* Das Server Script mountet das Share frisch, damit keine Notwendigkeit besteht, dass das Spare 24 Stunden durchläuft.
* Das Server Script mountet das Share frisch, damit keine Notwendigkeit besteht, dass das Spare 24 Stunden durchläuft.


  #!/bin/bash
  #!/bin/bash
# save.sh (auf dem Server)
  #
  #
# /etc/save.sh (auf dem Server)
  #
  #
  umount /srv/mnt
  umount /srv/mnt
  umount /srv/mnt
  umount /srv/mnt
  mount -t cifs //raib90/i\$ /srv/mnt -o user=Administrator,password=pass
  mount -t cifs //raib90/i\$ /srv/mnt -o user=Administrator,password=pass
  /opt/firebird/bin/gbak -B -V -T -USER SYSDBA -PASSWORD masterkey $1.fdb /srv/mnt/fdb/sewa/$2.fbak
  /opt/firebird/bin/gbak -B -V -T -USER SYSDBA -PASSWORD masterkey $1.fdb /srv/mnt/fdb/$2.fbak
  umount /srv/mnt
  umount /srv/mnt
== Notfall-Plan ==
* Tritt der Notfall ein sollte man prüfen, ob auf einem Spare noch ein Restore läuft -> wenn JA, warten, bis dieses zu Ende gelaufen ist oder die Datenbank wegkopieren, und zunächst den aktuellen spare.fdb zur Verfügung stellen.
* auf dem Spare den Cron-Job stoppen damit keine weiteren Versuche mehr unternommen werden -.fbaks zu ziehen oder den firebird Dienst zu unterbrechen.
* Nachdem das spare bereitsteht, sich um das Server Problem kümmern, ev. dafür sorgen dass die Original DB wieder online geht, wenn nicht möglich das spare als neue Haupt DB einspielen.
== Skripte, neuester Ausprägung ==
#!/bin/bash
#
# /etc/save.sh (auf dem Server)
#
umount /srv/mnt
umount /srv/mnt
mount -t cifs //ka045a/share\$ /srv/mnt -o user=Administrator,password=pass
rm /srv/mnt/$1.fbak
/opt/firebird/bin/gbak -B -V -T -USER SYSDBA -PASSWORD ****** firma.fdb /srv/mnt/$1.fbak
umount /srv/mnt
#
++++++++++++++++++++++++++++++++++++++++++++++++
#!/bin/bash
#
# /etc/spare.sh (auf dem Client)
#
BAND=$(date +%H)
ssh ka044a /etc/save.sh $BAND
#
# Restore
#
rm /srv/smb/$BAND.tmp
/opt/firebird/bin/gbak -R -P 16384 -USER SYSDBA -PASSWORD ***** /srv/smb/$BAND.fbak /srv/smb/$BAND.tmp
#
# Ensure NN.fdb
#
rm /srv/smb/$BAND.fdb
mv /srv/smb/$BAND.tmp /srv/smb/$BAND.fdb
chmod 666 /srv/smb/$BAND.fdb
#
# Ensure spare.fdb
#
cp /srv/smb/$BAND.fdb /srv/smb/spare.tmp
rm /srv/smb/spare.fdb
mv /srv/smb/spare.tmp /srv/smb/spare.fdb
chmod 666 /srv/smb/spare.fdb
#

Aktuelle Version vom 22. August 2019, 13:09 Uhr

für eine OrgaMon-System-Installation mit einem Linux-System als FirebirdSQL Server ist es leicht möglich einen Ausfallserver zur Verfügung zu stellen, der eine "Spare"-Datenbank ständig in Bereitschaft hält. Dabei sollte es sich wiederum um einen Linux-Server handeln. Bei Ausfall des Hauptservers können die Clients direkt mit diesem Ausfallserver in Verbindung treten. Der Spare-Datenbank fehlen in diesem Fall die Änderungen an der Datenbank der letzten 40 Minuten. Ausfallserver und Hauptserver sollten in unterschiedlichen Brandschutzzonen gehostet werden.

Vorbereitungen

ssh-Automatisierung

Der Ausfallserver muss zunächst mit dem Hauptserver bekannt gemacht werden, dies ist hier Linux.ssh beschrieben. Dies ist notwendig, da wir in der ersten Phase den Client veranlassen das Backup auf dem Server zu starten. Dazu muss sich der Client innerhalb eines Scripts in den Server "einloggen" um ein dortiges Script zu starten.

Samba auf dem Client

Der Client muss eine SMB-Freigabe anbieten, auf dem der Server sein .fbak (die Datensicherung) ablegen kann. Diese wird nicht umständlich nach der Erzeugung umkopiert, sondern direkt durchen firebird-Server auf dem Share, also direkt auf dem Plattenbereich des Spares angelegt. Zudem erreichen wir so, dass möglichst zeitnah eine Sicherung der aktuellen Datenbank auf einer anderen Platte (als die der Datenbank selbst) zur Verfügung steht.

FirebirdSQL auf beiden Systemen

Beide Systeme müssen einen FirebirdSQL-Dienst am laufen haben.

Sicherungs-Phasen

  • In der /etc/crontab des Spares wird ein Sicherungsscript "spare.sh" jede Stunde (zu den üblichen Arbeitszeiten) gestartet
#min  hour                              daymo   month   daywk   usr   cmd
0     4,6,8,9,10,11,12,13,14,15,16,18   *       *       1-5     root  /etc/spare.sh
  • Das Script verlanlasst den Server die Datenbanksicherung auf dem Share des Spare abzulegen
  • Danach wird die Datenbank vom Spare restored und online geschaltet (STOP/COPY/START).
#!/bin/bash
# 
# /etc/spare.sh (auf dem Client)
#
BAND=$(date +%s)
ssh server /etc/save.sh prod-db $BAND
rm /srv/smb/spare.fdb.tmp
/opt/firebird/bin/gbak -R -P 16384 -USER SYSDBA -PASSWORD masterkey /srv/smb/$BAND.fbak /srv/smb/spare.fdb.tmp
rcfirebird stop
rm /srv/smb/spare.fdb
mv /srv/smb/spare.fdb.tmp /srv/smb/spare.fdb
rcfirebird start
  • Das Server Script mountet das Share frisch, damit keine Notwendigkeit besteht, dass das Spare 24 Stunden durchläuft.
#!/bin/bash
#
# /etc/save.sh (auf dem Server)
#
umount /srv/mnt
umount /srv/mnt
mount -t cifs //raib90/i\$ /srv/mnt -o user=Administrator,password=pass
/opt/firebird/bin/gbak -B -V -T -USER SYSDBA -PASSWORD masterkey $1.fdb /srv/mnt/fdb/$2.fbak
umount /srv/mnt

Notfall-Plan

  • Tritt der Notfall ein sollte man prüfen, ob auf einem Spare noch ein Restore läuft -> wenn JA, warten, bis dieses zu Ende gelaufen ist oder die Datenbank wegkopieren, und zunächst den aktuellen spare.fdb zur Verfügung stellen.
  • auf dem Spare den Cron-Job stoppen damit keine weiteren Versuche mehr unternommen werden -.fbaks zu ziehen oder den firebird Dienst zu unterbrechen.
  • Nachdem das spare bereitsteht, sich um das Server Problem kümmern, ev. dafür sorgen dass die Original DB wieder online geht, wenn nicht möglich das spare als neue Haupt DB einspielen.

Skripte, neuester Ausprägung

#!/bin/bash
#
# /etc/save.sh (auf dem Server)
#
umount /srv/mnt
umount /srv/mnt
mount -t cifs //ka045a/share\$ /srv/mnt -o user=Administrator,password=pass
rm /srv/mnt/$1.fbak
/opt/firebird/bin/gbak -B -V -T -USER SYSDBA -PASSWORD ****** firma.fdb /srv/mnt/$1.fbak
umount /srv/mnt

#

++++++++++++++++++++++++++++++++++++++++++++++++

#!/bin/bash
#
# /etc/spare.sh (auf dem Client)
# 
BAND=$(date +%H)
ssh ka044a /etc/save.sh $BAND

#
# Restore
#
rm /srv/smb/$BAND.tmp
/opt/firebird/bin/gbak -R -P 16384 -USER SYSDBA -PASSWORD ***** /srv/smb/$BAND.fbak /srv/smb/$BAND.tmp

#
# Ensure NN.fdb
#
rm /srv/smb/$BAND.fdb
mv /srv/smb/$BAND.tmp /srv/smb/$BAND.fdb
chmod 666 /srv/smb/$BAND.fdb

#
# Ensure spare.fdb
#
cp /srv/smb/$BAND.fdb /srv/smb/spare.tmp
rm /srv/smb/spare.fdb
mv /srv/smb/spare.tmp /srv/smb/spare.fdb
chmod 666 /srv/smb/spare.fdb

#