Web 2.0 in the real world

alt
 

Hot topics

Migratie HTTP server

Guus Disselkoen  24 September 2014 21:16:35
Image:Migratie HTTP server

Soms kan het toch zo simpel zijn....

Om mijn websites en web applicaties beschikbaar te stellen via internet maak ik gebruik van een (IBM) HTTP server en de WebSphere plugin. De reden waarom ik hiervoor gekozen heb is eigenlijk vrij simpel, een paar websites en applicaties draaien op WebSphere en een aantal op Lotus Domino. Aangezien de WebSphere plugin zowel WebSphere als Lotus Domino ondersteund is dit de meest logische keuze. Daarnaast heb ik nog een aantal sites die op een 'gewone' http server draaien. Ook deze kan ik via de IBM HTTP server ontsluiten door deze ook als reverse proxy te configureren. Hiervoor wordt de standaard methode van Apache gebruikt, het definieren van virtual hosts in de httpd.conf. Ik heb er vanuit oogpunt van beheer, het gaat om zo'n 30 verschillende url's met websites, voor gekozen per virtuele host een apart configuratie bestand te maken en deze in een directory te plaatsen. Deze directory wordt vervolgens included in de httpd.conf file.

De IBM HTTP server is gebaseerd op de Apache HTTP server en door IBM gemodificeerd om als frontend voor WebSphere en Lotus Domino gebruikt te kunnen worden. Veel van de standaard Apache functionalitijd is ook beschkbaar in de IBM HTTP server. Wat op de IBM HTTP server ontbreekt is het configureren van de http server als load balancer. Maar die taak is overgenomen door de WebSphere plugin.
De WebSphere pluging maakt geen gebruik van de standaard configuratie file van de http server, maar gebruikt een eigen configuratie bestand, de plugin-cfg.xml. In deze XML file worden  virtuele host geconfigureerd voor iedere webite die door de plugin verwerkt moet worden. Per virtuele host wordt een cluster gedefineerd met servers die het request afhandelen. Ook als er maar 1 server is die het request afhandeld, dan wordt er toch een cluster gedefinieerd. Verder wordt er in de configuratie opgenomen welke uri's bij de site horen. Ook het transport type, http of https, wordt in de plugin geconfigureerd. Op deze manier is het ook mogelijk SSL ofloading te doen op de http server.

Onlangs ben ik begonnen met het "migreren" van alle servers naar mijn, inmiddels niet meer zo nieuwe, internet aansluiting. deze heeft een hogere down en upload snelheid. Alle clients maakten al gebruik van deze internet verbinding, maar de servers nog niet. Aangezien ik een aantal websites heb draaien is een hogere upload snelheid wenselijk, aangezien dit de snelheid bepaald waarmee de site geopend wordt voor de bezoekers.

Tevens is dit een mooie gelegenheid om de bestaande HTTP server, een 32-bits server op CentOS 5.10, te vervangen door een 64-bits versie op CentOS 6.5. Bijkomend voordeel is dat ik website  voor website kan migreren naar de nieuwe internet verbinding en nieuwe HTTP server. Oftewel geen downtime voor de websites. Helaas ging deze vlieger niet helemaal op. In eerste instantie door een foutje van mijzelf. Na het aanpassen van het publieke IP adres in de DNS was ik 1 dingetje vergeten; het aanpassen van de configuratie in de firewall waardoor de requests niet aankwamen op de nieuwe http server, maar op de huidige. Angezien de huidige HTTP server nog steeds gebruik maakt van de andere internet verbinding ging dit niet goed. Gelukkig was dit probleem snel hersteld.

Het volgende probleem waar ik tegen aan liep waren de websites die gebruik maken van https en die op de Lotus Domino servers draaien. Websites die gebruik maken van SSL en op een andere http server draaien werketen zonder problemen, maar de Domino based websites gaven een status 500 melding terug. Gelukkig heeft de WebSphere plugin ook logging. Standaard toont deze alleen de errors, en die waren er niet, maar je kunt ook het loglevel aanpassen naar bijvoorbeeld “trace”. Je krijgt dan heel wat meer informatie te zien.

De logging liet onder andere het volgende zien:
[24/Sep/2014:19:09:37.39217] 00005a67 77fff700 - ERROR: ws_common: websphereHandleRequest: Failed to handle request
[24/Sep/2014:19:09:37.76691] 00005a83 7dd0b700 - ERROR: ws_common: websphereFindTransport: Nosecure transports available
[24/Sep/2014:19:09:37.76719] 00005a83 7dd0b700 - ERROR: ws_common: websphereWriteRequestReadResponse: Failed to find a transport
[24/Sep/2014:19:09:37.76735] 00005a83 7dd0b700 - ERROR: ESI: getResponse: failed to get response: rc = 4

Na een poosje Googlen kwam ik er achter wat er mis was. Er was in ieder geval niets mis mijn configuratie van de http server of de WebSphere plugin. Maar IBM heeft een wijziging doorgevoerd in de laatste versie van WebSphere, en de daarbij behorende WebSphere plugin, die ik ook gebruik. Het is in de laatste versie niet meer standaard ondersteund dat er gebruik gemaakt wordt van een niet secure http connectie. Oftewel, alles moet via https verlopen met de benodigde SSL certificaten. En dat wil ik juist niet. Alle servers draaien op een ESX omgeving en sommige servers ook nog op dezelfde ESX host. Op het interne netwerk en servers wil ik niet de overhead van SSL gebruiken, maar good old plain http.

Gelukkig is er een oplossing. Kennelijk heeft IBM ook bedacht dat niet iedereen gebruik wil maken van SSL voor de communicatie tussen HTTP server en (WebSphere) backend en is er een 'trucje'.
Door een custom property,  UseInsecure="true", op te nemen in de global config sectie kun je afdwingen dat de plugin overschakelt naar “nonsecure” transport als er geen https transport geconfigureerd is.
Na deze wijziging doorgevoerd te hebben werken de websites, die via https gaan, inmiddels ook weer.

Translate

Feeds

Companies

    Atos Origin
    Achmea
    Inter Access
    ilionx
    transavia.com
    IBM

Google searches

Referrers