...
Sv translation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VoraussetzungDas System muss vorher auf eine Version mit MySQL 8.x geupdatet werden (Release 3.15 bis 3.17). Vorbereitung für die AktualisierungBei jeder Aktualisierung gibt es eine goldene Regel, die unabhängig von den Wünschen des Kunden strikt befolgt werden muss:
Authoritative Share BestimmenBei 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-ShareDieser ist /home/jtel/shared Non-Authoritative File-ShareDieser ist /srv/jtel/shared Bestimmen ob AuthoritativeWenn /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. DatensicherungEs 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 SicherungDienste Stoppen
Datenbank sichern (auf DB Master)Das entsprechende Passwort bei <password> eintragen:
Data Verzeichnis sichernDies 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:
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 sichernSind 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 SicherungDies erfolgt über die VMWare Konsole, oder Hyper-V Konsole. Dies wird üblicherweise durch den Kunden durchgeführt. Bestätigung
RücksicherungSnapshotsDie Snapshots werden alle wieder aktiviert, und hochgefahren. Es sollte ein normaler Betrieb mit den alten Software-Stand herrschen. Manuelle RücksicherungMit allen Diensten gestopped, die Datenbank zurücksichern. Das entsprechende Passwort bei <password> eintragen:
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.
Die Aktualisierung des SystemsEs 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 STOREDieser Schritt muss als Benutzer "jtel" erfolgen.
Prüfung ob Änderungen / Patches vorhanden sindBevor die Software aktualisiert wird, sollte noch geprüft werden, ob im jeweiligen Verzeichnis Dateien geändert wurden.
Hier ein Beispiel basierend auf das Software-Verzeichnis JTELCarrierPortal:
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!
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:
Aktualisierung der Repositories (Immer auf Non-Authoritative Share)Die folgende Befehlssequenz aktualisiert alle Software-Verzeichnisse auf dem letzten Stand des jeweilig eingestellten Releases.
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:
Auschecken des gewünschten ReleasesNachdem der GIT PULL erfolgt ist, muss das entsprechende Release ausgechecked werden, falls ein anderer als mit git status gewünscht ist.
Dateien auf Authoritative Share kopierenNur wenn es ein Authoritative / Non-Authoritative share gibt. Dies geschieht mit folgender Skript
Aktualisierungsskripte laufen lassenFolgender Aktualisierungsskript führt alle notwendigen Änderungen durch. Dies wird als root oder jtel mit sudo ausgeführt. Hier mit jtel user:
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:
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.
Binaries HerunterladenDie Binaries werden mit folgenden Befehl heruntergeladen:
Aktualisierung des Platform UDP ListenersMaster DatenbankenBei 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.
Die Aktualisierung des Platform UDP Listeners muss als Benutzer "root" ausgeführt werden und erfolgt auf die Master Datenbanken durch Eingabe folgendem Befehls:
Dieser Befehl aktualisiert den Listener und startet ihn. Der Erfolg kann durch Sichtung der Datei
TelefonieservernHier 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.
Aktualisierung der WEB ServerDer JBOSS Server wird komplett ersetzt durch ein Wildfly Server. Hazelcast Konfiguration sichernFalls keine Sicherung bereits vorhanden:
JBOSS Server und Java 7 DeinstallierenAls root:
Java 8 und Wildfly Installieren
Wildfly konfigurierenDie hazelcast.xml muss kopiert werden, und die Standardeinstellungen für die Datenbank müssen angepasst werden. Im folgenden <password> bitte entsprechend ersetzen:
Aktualisierung der PortalsoftwareDie Aktualisierung der Portalsoftware muss als Benutzer "root" auf dem Webserver ausgeführt werden und erfolgt durch Eingabe folgendem Befehls:
Dieser Befehl aktualisiert die Portalsoftware und startet den wildfly Server. Der Erfolg kann durch Sichtung der Datei Dort sollten in der Log-Datei folgende Einträge zu sehen sein, wenn die Aktualisierung erfolgreich war: Aktualisierung des 8ServersDie 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.
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:
Bei einem Telefonie-Server mit Aculab Media Service erfolgt dies mit folgendem Befehl:
Im Anschluss kann der 8Server gestartet werden. Aktualisierung der KonnektorenGrundsä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
Abschließende ArbeitenIst die Aktualisierung beendet und die Anlage ohne Fehler wieder hochgefahren, sind folgende Aufgaben zwingend auszuführen:
|