News

Soundbyte 85: Clustering…

10 maart 2013

Na een heerlijke week met maximum temperaturen van ruim 18C (18.8C in Eindhoven zelfs), kijk ik nu naar buiten en zie enkel sneeuw en zoutstrooiers. Wat een tegenstelling in één week, de winter is terug. Nu ben ik groot liefhebber van wintersporten, maar ik moet zeggen dat ik het nu wel zat ben en wel weer toe ben aan lekkere warme temperaturen. De truien mogen wat mij betreft weer terug in de kast en de t-shirts en blouses er weer uit. Klaar … basta …

Wat viel mij op de afgelopen week? Zoals de meesten van jullie wel weten, ben ik bij een klant van Luminis een project aan het doen waarmee domeinnamen kunnen worden geregistreerd. Hierbij is gekozen om gebruik te maken van JavaEE. We lopen aan het eind van het traject en gaan nu bezig met de transitie richting productie.

En daarvoor willen wij natuurlijk graag dat het geheel schaalt, ook bij veel gebruikers tegelijkertijd, en dat het geheel veilig 24-7 kan draaien. Knalt er een machine onderuit, dan mag dit niet meteen gevolgen hebben voor de bereikbaarheid; komen honderden gebruikers tegelijkertijd op het idee om het systeem te gebruiken, dan moet dit mogelijk zijn met het liefst nog een acceptabele performance.

De keuze is eenvoudig gemaakt. We gaat het product draaien in een geclusterde omgeving. De backend zal draaien op drie nodes, waarbij twee load-balancers alle load verdelen over deze drie nodes. We hadden hier natuurlijk al vanaf het begin over nagedacht en hebben het systeem stateless opgezet. Zo moet het mogelijk zijn om de processen te starten op één machine en na een suspend te herstarten op een andere machine.

Maar toch blijkt het behoorlijk lastig te zijn om één en ander in een cluster te draaien. Laat ik een aantal voorbeelden noemen:

  • EJB Timers: wanneer processen worden ge-suspend (in wachtstand gezet), dan werden er hier een daar timers gestart om bijvoorbeeld bepaalde statussen te verwijderen na een bepaalde periode, of om de processen automatisch te herstarten wanneer er na een bepaalde periode nog geen event van buiten is geweest. Een perfect voorbeeld van het gebruik van EJB Timers zou je zeggen, ware het niet dat EJB timers zijn gebonden aan EJB instanties en dus aan Java VMs. Ze zijn dus niet cluster-aware en mede daardoor hebben we besloten om geen gebruik te maken van de JavaEE standaard maar over te stappen op de Quartz Scheduler. Quartz ondersteund namelijk wel clustering.
  • Connecties: In ons systeem worden er veel connecties gemaakt met registries, via welke wij domeinnamen registreren. Deze registries moeten worden benaderd via socket gebaseerde verbindingen. Deze registries hebben ook geen oneindige resources en limiteren daarom vaak deze verbindingen. Zo worden er limieten op aantal connecties gelegd, maar ook limieten op bandbreedte en hoeveelheid requests komen voor. Daar komt nog bij dat connecties altijd vanuit OSGi bundles worden gebruikt, draaiende buiten de Java EE containers. Ook bij het clustering aware maken van deze issues, kon JavaEE met zijn standaarden ons dus geen hulp bieden, maar ook de OSGi implementaties van de gebruikte applicatie servers laat ons hierbij in de steek. Hierdoor zijn we moeten overstappen op een gedistribueerde in-memory datagrid oplossing, Hazelcast. In de Hazelcast collecties konden we perfect bijhouden of we de limieten al hadden bereikt en op welke nodes bepaalde connecties zijn geopend.
  • Deployment: nu bieden de applicatie servers, vaak wel goede manieren om software op een juiste manier te publiceren over een cluster. Maar dit geldt vaak enkel voor de software zelf; bij het publiceren van properties lijkt dit weer tegen te vallen. Ook hier zijn we van property bestanden af moeten stappen en deze moeten opslaan in de databases, die wel door elke node te benaderen is.

En zo zijn we er nog wel een paar voorbeelden tegengekomen. Ook al hebben we nog zo goed nagedacht over het systeem, het blijkt toch dat we in de transitie fase nog veel aanpassingen hebben moeten doen om het geheel cluster-ware te moeten maken.

Het rare aan dit alles vind ik dat JavaEE ons hierbij vrijwel niet te hulp schiet. Ondanks dat de JavaEE versie uitermate geschikt zou moeten zijn voor “enterprises“, waar volgens mij clustering meer de norm zou moeten zijn dan de uitzondering, wordt er in de Java EE standaard schrikbarend weinig aandacht aan clustering besteed. Nu bieden de javaEE gecertificeerde applicatie servers vaak wel mogelijkheden tot clustering, maar ook die zijn vaak heel specifiek voor de applicatie server zelf (laten wij nu net JBoss gebruiken en niet van Glassfish bijvoorbeeld) en zijn vaak ook gelimiteerd. En dan ben je aangewezen op vakmanschap en ervaring en die is binnen Luminis gelukkig in ruime mate aanwezig.

Ik wil afsluiten met iedereen te attenderen op een nieuwe film die binnenkort in premiere gaat (ik dacht 24 mei 2013): ‘The Hangover III’. Deel 3 van mijn favoriete chaos movie. Hierbij alvast een trailer en ik zie jullie daar:

Na een heerlijke week met maximum temperaturen van ruim 18C (18.8C in Eindhoven zelfs), kijk ik nu naar buiten en zie enkel sneeuw en zoutstrooiers. Wat een tegenstelling in één week, de winter is terug. Nu ben ik groot liefhebber van wintersporten, maar ik moet zeggen dat ik het nu wel zat ben en wel weer toe ben aan lekkere warme temperaturen. De truien mogen wat mij betreft weer terug in de kast en de t-shirts en blouses er weer uit. Klaar … basta …

Wat viel mij op de afgelopen week? Zoals de meesten van jullie wel weten, ben ik bij een klant van Luminis een project aan het doen waarmee domeinnamen kunnen worden geregistreerd. Hierbij is gekozen om gebruik te maken van JavaEE. We lopen aan het eind van het traject en gaan nu bezig met de transitie richting productie.

En daarvoor willen wij natuurlijk graag dat het geheel schaalt, ook bij veel gebruikers tegelijkertijd, en dat het geheel veilig 24-7 kan draaien. Knalt er een machine onderuit, dan mag dit niet meteen gevolgen hebben voor de bereikbaarheid; komen honderden gebruikers tegelijkertijd op het idee om het systeem te gebruiken, dan moet dit mogelijk zijn met het liefst nog een acceptabele performance.

De keuze is eenvoudig gemaakt. We gaat het product draaien in een geclusterde omgeving. De backend zal draaien op drie nodes, waarbij twee load-balancers alle load verdelen over deze drie nodes. We hadden hier natuurlijk al vanaf het begin over nagedacht en hebben het systeem stateless opgezet. Zo moet het mogelijk zijn om de processen te starten op één machine en na een suspend te herstarten op een andere machine.

Maar toch blijkt het behoorlijk lastig te zijn om één en ander in een cluster te draaien. Laat ik een aantal voorbeelden noemen:

  • EJB Timers: wanneer processen worden ge-suspend (in wachtstand gezet), dan werden er hier een daar timers gestart om bijvoorbeeld bepaalde statussen te verwijderen na een bepaalde periode, of om de processen automatisch te herstarten wanneer er na een bepaalde periode nog geen event van buiten is geweest. Een perfect voorbeeld van het gebruik van EJB Timers zou je zeggen, ware het niet dat EJB timers zijn gebonden aan EJB instanties en dus aan Java VMs. Ze zijn dus niet cluster-aware en mede daardoor hebben we besloten om geen gebruik te maken van de JavaEE standaard maar over te stappen op de Quartz Scheduler. Quartz ondersteund namelijk wel clustering.
  • Connecties: In ons systeem worden er veel connecties gemaakt met registries, via welke wij domeinnamen registreren. Deze registries moeten worden benaderd via socket gebaseerde verbindingen. Deze registries hebben ook geen oneindige resources en limiteren daarom vaak deze verbindingen. Zo worden er limieten op aantal connecties gelegd, maar ook limieten op bandbreedte en hoeveelheid requests komen voor. Daar komt nog bij dat connecties altijd vanuit OSGi bundles worden gebruikt, draaiende buiten de Java EE containers. Ook bij het clustering aware maken van deze issues, kon JavaEE met zijn standaarden ons dus geen hulp bieden, maar ook de OSGi implementaties van de gebruikte applicatie servers laat ons hierbij in de steek. Hierdoor zijn we moeten overstappen op een gedistribueerde in-memory datagrid oplossing, Hazelcast. In de Hazelcast collecties konden we perfect bijhouden of we de limieten al hadden bereikt en op welke nodes bepaalde connecties zijn geopend.
  • Deployment: nu bieden de applicatie servers, vaak wel goede manieren om software op een juiste manier te publiceren over een cluster. Maar dit geldt vaak enkel voor de software zelf; bij het publiceren van properties lijkt dit weer tegen te vallen. Ook hier zijn we van property bestanden af moeten stappen en deze moeten opslaan in de databases, die wel door elke node te benaderen is.

En zo zijn we er nog wel een paar voorbeelden tegengekomen. Ook al hebben we nog zo goed nagedacht over het systeem, het blijkt toch dat we in de transitie fase nog veel aanpassingen hebben moeten doen om het geheel cluster-ware te moeten maken.

Het rare aan dit alles vind ik dat JavaEE ons hierbij vrijwel niet te hulp schiet. Ondanks dat de JavaEE versie uitermate geschikt zou moeten zijn voor “enterprises“, waar volgens mij clustering meer de norm zou moeten zijn dan de uitzondering, wordt er in de Java EE standaard schrikbarend weinig aandacht aan clustering besteed. Nu bieden de javaEE gecertificeerde applicatie servers vaak wel mogelijkheden tot clustering, maar ook die zijn vaak heel specifiek voor de applicatie server zelf (laten wij nu net JBoss gebruiken en niet van Glassfish bijvoorbeeld) en zijn vaak ook gelimiteerd. En dan ben je aangewezen op vakmanschap en ervaring en die is binnen Luminis gelukkig in ruime mate aanwezig.

Ik wil afsluiten met iedereen te attenderen op een nieuwe film die binnenkort in premiere gaat (ik dacht 24 mei 2013): ‘The Hangover III’. Deel 3 van mijn favoriete chaos movie. Hierbij alvast een trailer en ik zie jullie daar:

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *