U kent dat misschien wel. U heeft een schitterende WebSphere Portal-oplossing opgezet voor uw klanten. U blij, uw klanten blij en ook nog een flinke kostenbesparing gerealiseerd doordat men nu zelf de orders in kan geven. Daar ging het tenslotte om. Echter, vanochtend belde er een klant om te melden dat hij het systeem niet kon gebruiken. Helaas is uw systeem na de nachtelijke back-up niet goed teruggekomen, waardoor het crashte. Gelukkig volstaat het om alles opnieuw te starten, waardoor uw klanten er weer gebruik van kunnen maken. Toch zet dit u aan het denken, want hoeveel klanten hebben er vanochtend niet gebeld en hebben hun artikelen ergens anders besteld? Hoeveel omzet bent u misgelopen? Het is tijd geworden om na te denken over High Availability en/of failover voor uw Portal-omgeving.
Afhankelijk van de gekozen licentie voor de WebSphere-producten (Express, Enable of Extend) zijn er verschillende manieren om High Availability of failover te realiseren met WebSphere Portal. Met WebSphere Enable en Extend kunt u een Portal-cluster bouwen. Daarbij kan een keuze gemaakt worden voor een verticaal cluster of een horizontaal cluster. Een verticaal cluster bestaat uit meerdere Portal-servers op één machine welke onderling geclusterd zijn. Een horizontaal cluster is verdeeld over meerdere machines, die zelfs verschillende operating systemen kunnen hebben. Een voorbeeld daarvan zou kunnen zijn dat een productie-Portal (de primary node in dit geval) op uw System i (iSeries) draait, terwijl de back-up-Portal (de secondary node) op een goedkope Linux-machine draait. Deze heeft weliswaar wat minder capaciteit qua aantal gebruikers, maar voldoet prima in geval van een storing.
Indien er gekozen is voor WebSphere Portal Express zijn er wat minder mogelijkheden. De Express-versies zijn flink goedkoper in de licentiestructuur, maar bieden daardoor ook minder mogelijkheden. Onder andere clustering is hier niet bij inbegrepen. Een goede alternatieve oplossing zou in dit geval zijn om gebruik te maken van een cold-standby. U betaalt voor slechts één Portal-server.
De Portal-server op de andere machine staat normaal gesproken uitgeschakeld. Indien zich een probleem voordoet op de primaire machine, kan deze uitgeschakeld worden en wordt de Portal-server op de secundaire machine ingeschakeld. Aangezien beide Portal-servers zo ingericht zijn dat ze gebruik kunnen maken van dezelfde DB2-database mist u geen informatie en kan er met minimale downtime doorgewerkt worden.
Bovenstaande situaties schetsen hoofdzakelijk de mogelijkheden voor failover, maar onder High Availability valt natuurlijk ook load balancing. Met WebSphere is dit prima mogelijk op alle ondersteunde platformen. Binnen de WebSphere-architectuur draait een extra server, namelijk de Deployment Manager. Deze WebSphere-server kan gezien worden als een soort managementserver voor alle WebSphere-servers in uw omgeving. Deze servers worden door de Deployment Manager gezien als managed nodes. U kunt de individuele applicatie- of Portalservers stoppen, starten en configureren vanuit één webinterface. Maar het is ook mogelijk om bijvoorbeeld twee (of meer) servers in een clusterconfiguratie te zetten. Met de juiste extra software (edge components) kan er op deze manier een ‘load balanced cluster’ opgezet worden.
Wanneer moet er nu gekozen worden voor een clusterconfiguratie? Zoals in de inleiding al aangegeven kan het spreiden van risico’s een goede reden zijn om te gaan clusteren en op die manier de beschikbaarheid van het systeem te vergroten. Een cluster is helaas zo zwak als de zwakste schakel in het geheel. Er kan een Portal- of WAS-cluster ingericht zijn, maar als de back-endsystemen dat niet zijn, dan heeft het weinig nut om te clusteren. Als de back-endapplicatie, in ons geval vaak een iSeries-applicatie op DB2, niet beschikbaar is, dan kan er nog zo’n mooi Portal-cluster staan, maar zonder de achterliggende applicaties heeft dat niet zo veel nut.
Back-end mirroring
Indien uw back-end een System (iSeries) is dan bestaan er diverse mogelijkheden voor High Availability. Indien u zich enige uren downtime kunt veroorloven, dan is het mogelijk gebruik te maken van een uitwijkcontract. Uw back-end komt dan na enkele uren in de lucht op een andere machine, met een kopie van uw laatste back-up. Aandachtspunt hierbij is hoe u de ingevoerde gegevens vanaf de laatste back-up herstelt.
Een meer professionele, maar ook kostbaardere, oplossing is om uw gegevensbestanden te ‘mirroren’. Alle wijzigingen in uw database worden ook weggeschreven naar een exacte kopie van de database op een ander systeem. Voor heel eenvoudige databases kunt u dit zelf programmeren – de basismogelijkheden zijn onderdeel van OS/400 -, maar normaal gesproken zult u dan gebruikmaken van een mirroring-oplossing van een van IBM’s High Availability-partners.
Een gemirrorde database is ook een ideale manier om een 24/7-beschikbaarheid te realiseren. Terwijl het zenden van gegevens naar het andere systeem (in een remote journal, oftewel transactielog) gewoon doorgaat, stopt u het bijwerken van de database op het gespiegelde systeem. U kunt nu een volledige back-up van de kopiedatabase maken, terwijl de oorspronkelijke database volledig online is, en zonder dat u gevaar loopt gegevens kwijt te raken.
Conclusie
Er zijn zeer veel mogelijkheden om High Availability en failover in te zetten bij gebruik van de WebSphere-productenlijn. Het is daarbij zeer belangrijk om de volledige keten van toepassingen onder de loep te nemen. Een Portal-cluster waarbinnen een essentiële, achterliggende applicatie niet dubbel uitgevoerd is, heeft weinig toegevoegd waarde. Voor niet-essentiële applicaties maakt het natuurlijk geen verschil, zolang dat voor de gebruikers maar duidelijk is.
Hilgert Bos en Ronald Portier
Gepubliceerd in iSeriesinfo
Follow