Reverse Proxy Apache im laufenden Betrieb umkonfigurieren

[dschroeder]

Was ist mit STRTCPSVR SERVER(*HTTP) RESTART(*HTTP) HTTPSVR(Server-Instanz) ?

Mein Kollege sagte, beim "normalen" Apache sei der Befehl "reload", um die Konfiguration neu einzulesen. Weiß jemand, ob es beim iseries Apache auch ein "reload" gibt?
Dieter

[Rainer Ross]

Hallo Dieter,

ich habe V7R2 mit der neuesten Apache Version 2.4.2 und habe leider auch keine Möglichkeit für den Reload der httpd Konfiguration gefunden. Unter Linux und unter IBM z/OS http://www-01.ibm.com/support/docvie...d=isg3T1011453 funktioniert es.

STRTCPSVR SERVER(*HTTP) RESTART(*HTTP) HTTPSVR(Server-Instanz) habe ich getestet. Der Server war dann für ca. 20s offline und hatte die neue Konfiguration eingelesen.

kleiner Performance-Tipp: das Subsystem QHTTPSVR in einen eigenen Speicherpool legen

Bis V7R1 war das Subsystem QHTTPSVR für den Webserver festgelegt. Ein kaum beachtetes Annoucement beschreibt, dass es ab V7R2 und V7R1 (HTTP group PTF SF99368 level 30) möglich ist, ein eigenes Subsystem zu erstellen.

http://ibmsystemsmag.com/Blogs/i-can...own-subsystem/

Herzliche Grüße

Rainer

[dschroeder]

Hallo Rainer,

herzlichen Dank! Die Info war sehr wichtig für mich. Das mit dem Announcement habe ich gelesen. Aber wenn das reload im laufenden Betrieb nicht geht, können wir den Apache nicht auf der iSeries verwenden. Wir werden den dann auf einer Linux Kiste aufsetzen.

Dieter

[AG1965_2]

Und den Apachen auf der Linux-Büchse musst Du niemals updaten, niemals aktualisieren?
Ganz verstehe ich die Beweggründe nicht. Wenn der eigentliche Server im gleichen Netz ist, ließe sich das ja netzwerktechnisch abfackeln.

[dschroeder]

Also, wir möchten 2 Server aufsetzen, die Webservices bereitstellen. Einer von den beiden soll der produktive sein, der andere der Testserver. Außerdem würden wir einen dritten Server aufsetzen, der als reverse proxy die User requests annimmt und an den produktiven Webserver weiterleitet.

Wenn wir jetzt Programmänderungen durchführen, die die Webservices beeinflussen, würden wir die erstmal auf dem Testserver installieren. Wenn dort alles OK ist, würden wir den reverse proxy "umkonfigurieren", so dass er die user requests ab sofort auf den bisherigen Testserver, der ab jetzt ja der produktive werden soll, umleitet.
Und dieses Verfahren würden wir gerne eben nicht nur einmal in der Nacht anwenden, sondern auch tagsüber beliebig oft. Deshalb müsste sich der reverse proxy on the fly umkonfiguriereren lassen.

Wenn es um echte Betriebssystem - Updates geht: Das machen wir natürlich nicht ein paar mal täglich. Das machen wir am Wochenende. Das muss natürlich nicht im laufenden Betrieb erfolgen.

Dieter

[Pikachu]

... so dass er die user requests ab sofort auf den bisherigen Testserver, der ab jetzt ja der produktive werden soll, umleitet.

Und wie bringt Ihr die Daten des bisherigen Testservers auf den aktuellen Stand?

[dschroeder]

Da verstehe ich die Frage nicht. Wir tauschen die jar-Files aus und ändern die RPG-Programme, auf die mittels java zugegriffen wird. Vielleicht denke ich da zu einfach.

Dieter.

[Pikachu]

Was ist mit euren produktiven Daten in der Datenbank.
Wie ziehen die mit um bei so einem Wechsel?
Oder habt ihr sowas nicht?

[dschroeder]

Ach so. Der Begriff "Testserver" war von mir vielleicht etwas unglücklich gewählt. Ich meine damit schon einen Server, der Webservice für die echten Datenbanken bereitstellt. Nur ist er für die Clients nicht erreichbar und damit nicht im produktiven Einsatz. Das heißt, wir können Programmänderungen auf diesen (zur Zeit nicht im Echteinsatz befindlichen) Server ausrollen. Wenn das Ausrollen erledigt ist, soll der reverse proxy die Requests aller Client auf diesen Server (der jetzt ja die neuesten Versionen der Programme hat) umleiten.

Dieter

[Pikachu]

Auf welchem Server liegen denn die (aktuellen produktiven) Daten auf die diese Programme zugreifen?

[dschroeder]

Die Daten liegen bei uns immer auf der iSeries.

Vielleicht nochmal als Grobskizzierung unserer Idee:

- Unsere Daten liegen alle auf unserer zentralen iSeries
- Unsere Kernanwendung (Individualprogrammierung) besteht aus RPG-Programmen
- Wir haben auch viele, immer wichtiger werdende, Java-Anwendungen für die PCs.
- Die Java-Anwendungen benötigen Daten aus der iSeries Datenbank.
- Um die im Laufe der Jahre entstandenen diversen Zugriffswege (ODBC, JDBC, SQL-UDF, SQLUDTF, ...) zu vereinheitlichen, möchten wir in Zukunft alles über Webservices abbilden.
- Die Webservices sollen in Java geschrieben werden. Die Java-Programme, aus denen diese Webservices bestehen, sollen ihrerseits ihre Daten mithilfe von SQL und von RPG-Programmen ermitteln.

Wenn das so klappt, hätten wir eine saubere Webservice-Schicht, die alle "PC-Anwendungen" von der iSeries abkapselt. Die Implementierung der Webservices soll in der Hand der iSeries Programmierer liegen.
Auf der iSeries sind wir es im RPG gewohnt, Programme auch mal im laufenden Betrieb kurzfristig auszutauschen. Das wollen wir natürlich auch mit unseren Webservices machen, bzw. mit den RPG-Programmen machen, die unsere Webservices bedienen.

Vielleicht hat der eine oder andere ja auch schon mal so eine Umgebung errichtet. Wir sind für jeden Tipp dankbar.

Dieter