You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Voraussetzung

Das System muss vorher auf eine Version mit MySQL 8.x geupdatet werden (Release 3.15 bis 3.17).

Vorbereitung für die Aktualisierung

Bei jeder Aktualisierung gibt es eine goldene Regel, die unabhängig von den Wünschen des Kunden strikt befolgt werden muss:

Goldene Regel Nr. 1

Es muss IMMER einen Weg zurück geben.

Goldene Regel Nr. 2

Bevor man ein System aktualisiert, sollte man es gut kennen.

Authoritative Share Bestimmen

Bei manchen Installationen, ist das File-Share auf ein System, der vom Kunden bereitgestellt wird.

In diesen Fall erfolgt das Checkout der Repositories lokal auf den Load-Balancer auf den Non-Authoritative Share, die Dateien werden aber später auf den "Authoritative" File-Share kopiert.

Nach Änderungen sollte auf den Authoritative File-Share geprüft werden.

Authoritative File-Share

Dieser ist /home/jtel/shared

Non-Authoritative File-Share

Dieser ist /srv/jtel/shared

Bestimmen ob Authoritative

Wenn /home/jtel/shared auf den Load-Balancer von einem Fremdsystem gemountet ist, dann ist es in der Regel nicht authoritative.

Dies kann man einfach bestimmen, indem man eine Datei auf /srv/jtel/shared erzeugt. Erscheint dies nicht in /home/jtel/shared, so ist /srv/jtel/shared nicht authoritative.

Datensicherung

Es sollte unbedingt eine Datensicherung angefertigt werden. Das MINIMUM ist dass die Datenbank gesichert wird, und das Datenverzeichnis gesichert wird, dies sollte jedoch nur die Notlösung sein.

Besser ist ein Snapshot aller beteiligten virtuellen Maschinen, im Kaltzustand (heruntergefahren).

Die Gefahr besteht, dass wenn ein Snapshot im laufenden Betrieb gezogen wird (insbesondere der Datenbankmaschinen), dass dieser nicht konsistent ist.

Manuelle Sicherung

Dienste Stoppen

Alle Dienste des jtel-Systems stoppen

Auf TEL Servern alle Anwendungen stoppen

  • start_launcher.cmd
  • startlistener.bat
  • TK Connector
    • Kann ggf. als Dienst laufen - siehe "Dienste" oder "Services"

  • 8Server durch die GUI oder mit folgender Kommando beenden:

    taskkill /im robot5.exe
     

Alle Webserver, die JBOSS Server stoppen:

service jboss stop

 

Alle DB Master:

service jtel-listener stop
 

Alle Chat Server:

service jtel-clientlistener stop

Datenbank sichern (auf DB Master)

Das entsprechende Passwort bei <password> eintragen:

Sicherung der Datenbank vom primären DATA aus
su jtel
cd
mkdir -p /home/jtel/shared/Backup
mysqldump -u root -p<password> --add-drop-database --add-drop-table --events --routines --triggers --databases JTELWeb JTELStats JTELStats2 JTELLog | gzip > /home/jtel/shared/Backup/backup-$(hostname -s)-database-$(date +%F-%H%M%S).sql.gz

Data Verzeichnis sichern

Dies kann über den Windows Explorer oder ein entsprechender cp Befehl auf den Linux erfolgen.

GIT Status merken (Authoritative Share)

Vom Load-Balancer aus, den GIT Status prüfen:

GIT Status Merken
cd /home/jtel/shared/JTEL
git status
git rev-parse HEAD
(ausgaben sichern)
 
cd /home/jtel/shared/JTELCarrierPortal
git status
git rev-parse HEAD
(ausgaben sichern)
 
# FALLS EIN Kundenspezifischer Verzeichnis vorhanden ist
 
cd /home/jtel/shared/Customer_Directory
git status
git rev-parse HEAD
(ausgaben sichern)

 

Ggf. müssen hier die Verzeichnisse ebenso in die Datensicherung mit aufgenommen werden, insbesondere dann, wenn Patches eingespielt wurden, sodass lokale Änderungen erfolgt sind.

Weitere Komponenten sichern

Sind weitere Komponenten vom Update betroffen, wie der 8-Server selbst, oder der JBOSS Server (nicht die Webanwendung), sollten diese Komponenten vorab auch gesichert werden.

Snapshot Sicherung

Dies erfolgt über die VMWare Konsole, oder Hyper-V Konsole. Dies wird üblicherweise durch den Kunden durchgeführt.

Bestätigung

Datensicherung

Erst wenn die Datensicherung erfolgt ist (ggf. vom Kunden bestätigen lassen!), weitermachen!

Rücksicherung

Snapshots

Die Snapshots werden alle wieder aktiviert, und hochgefahren. Es sollte ein normaler Betrieb mit den alten Software-Stand herrschen.

Manuelle Rücksicherung

Mit allen Diensten gestopped, die Datenbank zurücksichern. Das entsprechende Passwort bei <password> eintragen:

Kopieren und Entpacken des Dumps
cp /home/jtel/shared/Backup/backup-acd-dbm-database-2016-06-30-293211.sql.gz .
gunzip backup-acd-dbm-database-2016-06-30-293211.sql.gz
mysql -u root -p<password> -e"backup-acd-dbm-database-2016-06-30-293211.sql"

Parallel dazu, kann das alte Data Verzeichnis zurückgespielt werden.

Ggf. sind weitere Schritte erforderlich (GIT Repositories zurücksichern, 8-Server zurücksichern, ...) je nach dem welche Komponenten beim Update betroffen waren.

Tipp

Mach lieber ein Snapshot.

Die Aktualisierung des Systems

Es sei hier noch mal erwähnt: alle jtel-Dienste des Systems müssen herunter gefahren sein. 

Danach kann mit der Aktualisierung begonnen werden. Die Schritte erfolgen in der hier dokumentierten Reihenfolge

Aktualisierung der Software auf dem STORE

Dieser Schritt muss als Benutzer "jtel" erfolgen.

New Repository Locations

jtel hat seine Repository-Server umgezogen in die Cloud.

Siehe hier: New Repository Locations

Es ist nötig, die URL der GIT repositories zu verändern, bevor man hier weitermacht.

Prüfung ob Änderungen / Patches vorhanden sind

Bevor die Software aktualisiert wird, sollte noch geprüft werden, ob im jeweiligen Verzeichnis Dateien geändert wurden.

Tipp

Es sollte in /home/jtel/shared eine readme.txt vorhanden sein, der eventuell eingespielte Patches auflistet.

 

Hier ein Beispiel basierend auf das Software-Verzeichnis JTELCarrierPortal:

Prüfen auf Änderungen
su jtel
cd /home/jtel/shared/JTELCarrierPortal
git status
git rev-parse HEAD
exit

Wird hier angezeigt, dass Dateien verändert wurden, ist Vorsicht geboten. Der Projektingenieur muss vorher prüfen, ob die Änderungen lokale Bugfixe sind, die inzwischen ins Release eingeflossen sind. In diesem Falle können die Änderungen vor der Aktualisierung gelöscht werden. Tut man dies nicht, so kann die Aktualisierung scheitern!

Zurücknehmen von Änderungen
su jtel
cd /home/jtel/shared/JTELCarrierPortal
git checkout -- .
exit

Eine allgemeine Vorgehensweise kann in einem solchen Fall aber nicht beschrieben werden. Hier muss von Fall zu Fall geprüft werden, wie vorgegangen wird.

Falls Datei-Modus Änderungen ignoriert werden sollen, kann folgender Befehl genutzt werden:

GIT File Mode
git config core.fileMode false

Aktualisierung der Repositories (Immer auf Non-Authoritative Share)

Die folgende Befehlssequenz aktualisiert alle Software-Verzeichnisse auf dem letzten Stand des jeweilig eingestellten Releases.

Aktualisieren der Software-Verzeichnisse
su jtel
cd /srv/jtel/shared/JTELCarrierPortal
git pull
cd /srv/jtel/shared/JTEL
git pull
cd /srv/jtel/shared/Customer_Directory
git pull
exit

Falls Fehler beim GIT auftreten, beispielsweise:

Merge-Konflikt in (Dateiname)

Oder

fatal: Verweigere den Merge von nicht zusammenhängenden Historien.

muss das lokale Repository resettet werden. Dies kann wie folgt (Beispiel für stable-3.18 auf JTELCarrierPortal) geschehen:

Aktualisieren der Software-Verzeichnisse - reset des lokalen Repositories
su jtel
cd /srv/jtel/shared/JTELCarrierPortal
git reset --hard origin/release/stable-3.18

Auschecken des gewünschten Releases

Nachdem der GIT PULL erfolgt ist, muss das entsprechende Release ausgechecked werden, falls ein anderer als mit git status gewünscht ist.

Aktualisieren der Software-Verzeichnisse
su jtel
cd /srv/jtel/shared/JTELCarrierPortal
git checkout release/stable-3.18
cd /srv/jtel/shared/JTEL
git checkout release/stable-3.18
cd /srv/jtel/shared/Customer_Directory
git checkout release/stable-3.18
exit

Fix Shallow Clones

Es kann sein, dass git den gewünschten Release nicht kennt, trotz git pull und git checkout.
In diesen Fall liegt ein sogenannter "shallow clone" des Repositories vor, der nicht alle Branches beinhaltet.
Dies kann mit folgende Befehle verändert werden:


git fetch --unshallow
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git fetch origin

Dateien auf Authoritative Share kopieren

Nur wenn es ein Authoritative / Non-Authoritative share gibt.

Dies geschieht mit folgender Skript

Komplettaktualisierung
cd /srv/jtel/shared/JTELCarrierPortal/
bash update_fileshare.sh

Aktualisierungsskripte laufen lassen

Folgender Aktualisierungsskript führt alle notwendigen Änderungen durch. Dies wird als root oder jtel mit sudo ausgeführt. Hier mit jtel user:

Komplettaktualisierung
cd /home/jtel/shared/JTELCarrierPortal/Update
sudo ./update_release.sh

Ggf. wird man zuerst nach den sudo Passwort gefragt. 

Das Skript fragt nach den entsprechenden Master Datenbank, Benutzer, Passwort, und Name des Kundenverzeichnisses indem ggf. spezifische Software für den Kunden liegt.

Die Fragen können, in der Regel mit folgende Antworten beantwortet werden, Kenntnis von <password> für die Datenbank vorausgesetzt:

  • mysql host address: acd-dbm
  • mysql user name: root
  • mysql password: <password>
  • customer directory:

Falls kein Customer Directory vorhanden ist, kann dies leer gelassen werden. Das Vorhandensein von Kundenspezifische Software kann mit ls /home/jtel/shared geprüft werden - dort die Namen der Verzeichnisse anschauen. Nur den Namen des Verzeichnisses angeben! Beispielsweise acme

Anschließend wird das Update durchgeführt.

Wichtiger Hinweis

In einer Master/Slave Umgebung ist unbedingt darauf zu achten, diese Prozedur gegen der Master-Datenbank durchzuführen - sprich mysql host address = MASTER-DB. Tut man dies aus Versehen auf einem Slave, hat man Chaos gesät: der Slave ist dann kaputt, und muss neu aufgesetzt werden. Die Aktualisierung muss dann (korrekt auf dem Master) wiederholt werden.

Binaries Herunterladen

Die Binaries werden mit folgenden Befehl heruntergeladen:

Get binaries
cd /home/jtel/shared/JTELCarrierPortal/Update
su jtel
bash get_binaries.sh


Aktualisierung des Platform UDP Listeners

Master Datenbanken

Bei Release 3.18 und höher, wird Java 8 verwendet. Das (vorhandene) Java 7 muss deinstalliert werden, und Java 8 wird installiert.

Wir verwenden den openjdk, sodass es unter Linux Updatefähig bleibt.

service jtel-listener stop
yum -y remove jdk.x86_64
yum -y install java-1.8.0-openjdk

Die Aktualisierung des Platform UDP Listeners muss als Benutzer "root" ausgeführt werden und erfolgt auf die Master Datenbanken durch Eingabe folgendem Befehls:

Aktualisierung des Platform UDP Listeners
updatepl.sh

Dieser Befehl aktualisiert den Listener und startet ihn. Der Erfolg kann durch Sichtung der Datei /home/jtel/PlatformUDPlistener/log/listener.log geprüft werden.

Tipp

Der Listener ist nur auf die Master-Datenbanken dann installiert, wenn eine SOAP Schnittstelle lizenziert ist.

Telefonieservern

Hier ist zu prüfen ob Java 8 installiert ist. Ggf. Java 8 von einer der Quellen hier herunterladen (dies sind BCL lizenzierte Versionen, also Lizenzfrei):

Das Start-Skript für den Platform-Listener kopiert die neue Version des Listeners selbst.

Hinweis

Ist der Platform-Listener auf den TEL Servern als Dienst installiert, reicht ein Neustart als Dienst NICHT aus. In diesen Fall sollte der Listener einmal von der Konsole aus gestartet werden, damit das Kopieren auch geschieht.

Aktualisierung der WEB Server

Der JBOSS Server wird komplett ersetzt durch ein Wildfly Server.

Hazelcast Konfiguration sichern

Falls keine Sicherung bereits vorhanden:

cp /home/jtel/jboss-as-7.1.1.FINAL/standalone/configuration/hazelcast.xml /home/jtel/shared

JBOSS Server und Java 7 Deinstallieren

Als root:

service jboss stop
yum -y remove jdk.x86_64
cd /home/jtel
chkconfig jboss off
rm -f /etc/init.d/jboss
rm -f /etc/cron.daily/jboss-logmaint.sh
rm -f /etc/cron.daily/jboss-restart.sh
rm -f /usr/local/bin/updatejb.sh
rm -Rf jboss-as-7.1.1.FINAL

Java 8 und Wildfly Installieren

yum -y install https://cdn.jtel.de/downloads/java/jdk-8u202-linux-x64.rpm
wget http://cdn.jtel.de/downloads/jboss/wildfly-18.0.1.Final.01.tar.gz
tar xzf wildfly-18.0.1.Final.01.tar.gz
rm -f wildfly-18.0.1.Final.01.tar.gz
mkdir -p wildfly-18.0.1.Final/standalone/deployments
chown -R jtel:jtel wildfly-18.0.1.Final
mkdir -p /home/jtel/upload
chown -R jtel:jtel /home/jtel/upload
ln -s /home/jtel/wildfly-18.0.1.Final wildfly-current
ln -s /home/jtel/wildfly-current/init.d/wildfly /etc/init.d/wildfly
ln -s /home/jtel/wildfly-current/default/wildfly /etc/default/wildfly
cd /etc/cron.daily
ln -s /home/jtel/wildfly-current/bin/jboss-logmaint.sh
ln -s /home/jtel/wildfly-current/bin/jboss-restart.sh
cd /usr/local/bin
ln -s /home/jtel/wildfly-current/bin/updatejb.sh
chkconfig wildfly on

Wildfly konfigurieren

Die hazelcast.xml muss kopiert werden, und die Standardeinstellungen für die Datenbank müssen angepasst werden.

Im folgenden <password> bitte entsprechend ersetzen:

DBPRI=acd-dbm
DBSTA=acd-dbs
DBREP=acd-dbr
DBPWD=<password>
sed -i -e "s/DATA_PRIMARY/${DBPRI}/g" -e "s/DATA_STATS/${DBSTA}/g" -e "s/DATA_REPORTS/${DBREP}/g" -e "s/DB_PASSWORD/${DBPWD}/g" /home/jtel/wildfly-current/standalone/configuration/standalone.xml
unset DBPWD
unset DBREP
unset DBSTA
unset DBPRI
cp /home/jtel/shared/hazelcast.xml /home/jtel/wildfly-current/standalone/configuration/


Aktualisierung der Portalsoftware

Die Aktualisierung der Portalsoftware muss als Benutzer "root" auf dem Webserver ausgeführt werden und erfolgt durch Eingabe folgendem Befehls:

Aktualisierung des Jboss
updatejb.sh

Dieser Befehl aktualisiert die Portalsoftware und startet den wildfly Server. Der Erfolg kann durch Sichtung der Datei /home/jtel/wildfly-current/standalone/log/server.log geprüft werden.

 Dort sollten in der Log-Datei folgende Einträge zu sehen sein, wenn die Aktualisierung erfolgreich war:

Aktualisierung des 8Servers

Die Aktualisierung des 8Server erfolgt im Windows-Explorer mittels GIT. Hierfür wird mit einem Rechtsklick auf das Verzeichnis C:\8Server\deploy ein GIT Pull durchgeführt, und auf das gewünschte Version nach dem Pull gewechselt.

New Repository Locations

jtel hat seine Repository-Server umgezogen in die Cloud.

Siehe hier: New Repository Locations

Es ist nötig, die URL der GIT repositories zu verändern, bevor man hier weitermacht.

Möchte man nicht auf die letzte Version, sondern auf eine spezifische Version aktualisieren, erfolgt dies Über "git checkout" mit Angabe des Releases.

Nach dem Aktualisieren, muss die Version dann installiert werden. Bei einem Daemon-Server erfolgt dies mit dem Befehl:

Daemon Server aus der Befehlszeile aktualisieren
C:
cd \8Server\Install
copy_keyfile_en_daemon.cmd

Bei einem Telefonie-Server mit Aculab Media Service erfolgt dies mit folgendem Befehl:

Telefonie Server aus der Befehlszeile aktualisieren
C:
cd \8Server\Install
copy_keyfile_en_mcp.cmd

Im Anschluss kann der 8Server gestartet werden.

Aktualisierung der Konnektoren

Grundsätzlich gilt: die entsprechenden Dateien aus dem Software-Verzeichnis im STORE müssen ins Zielverzeichnis kopiert werden.

Diese kommen in der Regel aus dem Bereich JTELCarrierPortal/WebServices/Install

ACHTUNG

Bei Kopieraktionen ist unbedingt darauf zu achten, die Konfigurationsdateien nicht zu überschreiben!

Diese haben Namen, die sich an den Namen des ausführbaren Programm häufig anlehnen.

Beispiel: JTELInnovaphonePBXService.exe.config ist der Name der Konfigurationsdatei vom Innovaphone Connector.

Abschließende Arbeiten

Ist die Aktualisierung beendet und die Anlage ohne Fehler wieder hochgefahren, sind folgende Aufgaben zwingend auszuführen:

  • Anmelden ans Portal. Kurzer Test um zu sehen, dass auch Agenten und Supervisoren zu sehen bekommen, was sie erwarten.
  • Testanruf! Idealerweise gibt es eine Testnummer. Falls nicht, eine der regulären Servicerufnummern anrufen. Prüfen, dass der 8Server korrekt antwortet.
    • Testanruf mit beobachtung des Portals.
      Als User anmelden, und schauen ob ein Anruf im Portal korrekt angezeigt wird, wenn es dem Agenten zugestellt wird.

 

Sicherungen

Auf VMWare sowie Hyper-V können Snapshots zu Performance-Verlusten führen.

Die Snapshots sollten gelöscht werden, aber erst dann, wenn sichergestellt ist, dass es kein Zurück mehr geben muss. Dies ist in der Regel nach der ein Wenig Live-Zeit des Call-Centers der Fall.

  • No labels