GlassFish & Payara Auto-Clustering: Het uitvoeren van Jakarta EE High-Availability-applicaties in de cloud
Het waarborgen van een storingsvrije 24/7 service is een van de meest besproken gebieden in cloudhosting de afgelopen jaren. De meest voor de hand liggende en veelgebruikte oplossing hierbij is het bouwen van een geclusterde infrastructuur voor jouw project.
Om onze klanten te helpen hiermee om te gaan en om tijd te besparen voor andere werkzaamheden is er een speciale high-availability oplossing beschikbaar, ontworpen om het hosten van Jakarta EE-toepassingen te versimpelen: embedded Auto-Clustering voor GlassFish- en Payara servers.
Het belangrijkste voordeel van deze oplossing is de automatische verbinding van meerdere applicatie servers bij wijzigingen in de topologie van de applicatie.
Dit artikel beschrijft dus hoe GlassFish- en Payara auto-clustering werkt en hoe je de juiste ontwikkelaarsomgeving kunt opzetten en draaien binnen Previder PaaS+.
Kies op het Java-tabblad van de wizard tussen de GlassFish- of Payara server. Zoek daarna in het midden van het scherm de optie Auto-Clustering en activeer de Auto-Clustering-optie. Configureer de overige instellingen naar je wensen maar zorg dat je horizontaal schalen in ieder geval inschakelt.
Tip: De Auto-Clustering functie is ook beschikbaar voor andere software sjablonen (bijvoorbeeld MySQL, MariaDB, PostgreSQL, Tomcat/TomEE, WildFly, Shared Storage, MongoDB en Couchbase).
Afhankelijk van het doel van jouw ontwikkelaarsomgeving kun je overwegen om geen gebruik te maken van Auto-Clustering (bijvoorbeeld tijdens ontwikkeling). Dan wordt er een normale server gemaakt zonder een cluster te configureren.
Voor development is clustering vrijwel een verplichte optie om de hoge beschikbaarheid van je applicatie te waarborgen en een soepele ervaring te garanderen. Het gebruik van Auto-Clustering is de eenvoudigste manier om een betrouwbare topologie voor je services te implementeren zonder dat je handmatig iets hoeft te configureren. Hiervoor vinden de volgende aanpassingen plaats:
- Voor 2+ GlassFish (Payara) wordt de omgevingstopologie aangevuld met een load balancer (LB), bedoeld om de inkomende verzoeken te verwerken en deze over de werkers te verdelen.
- Er wordt automatisch een extra Domain Administration Server (DAS) node toegevoegd - een instantie voor de centrale controle van cluster nodes en om de interactie tussen hen via SSH te configureren. De integratie houdt de volgende specifieke aspecten in:
- De administratieserver is verbonden met alle werkers binnen de toepassingsserverlaag met de DAS-alias hostnaam, die door de werkers kan worden gebruikt voor verdere interactie.
- Om de juiste connectiviteit en controle van nodes mogelijk te maken, genereert het systeem automatisch een SSH-sleutelpaar voor de DAS-node en plaatst dit in een volume dat is gekoppeld aan alle andere clusterinstanties.
Implementatie van Sessiereplicatie
Om de hoge beschikbaarheid van jouw GlassFish/Payara clustering te waarborgen, configureert PaaS+ automatisch sessiereplicatie over de nodes. Op deze manier wordt alle gebruikerssessiedata die tijdens verwerking wordt opgeslagen, verdeeld over alle instanties van de toepassingsserver vanaf de node die daadwerkelijk het verzoek heeft verwerkt.
Samen met het automatisch geconfigureerde mechanisme voor plakkerige sessies op het load balancer-niveau, zorgt sessiereplicatie voor een verhoogde betrouwbaarheid en verbetert het de failover-mogelijkheden van jouw toepassing binnen zo'n GlassFish- of Payara-cluster. Hierbij zal, afhankelijk van de gebruikte stack, het geïmplementeerde replicatiemechanisme enigszins verschillen - laten we elk benadering in meer detail bekijken.
Sessiereplicatie in GlassFish met GMS
Binnen de GlassFish-cluster wordt sessiereplicatie aangedreven door de Group Management Service (GMS) - een ingebouwde component van de toepassingsserver die failoverbescherming, in-memory replicatie, transactie- en timerservices biedt voor clusterinstanties.
GMS gebruikt TCP zonder multicast om clusterinstanties te detecteren. Wanneer een nieuwe node zich bij een GlassFish-cluster aansluit, detecteert het systeem opnieuw alle actieve werkers en DAS-node - een dergelijk automatisch ontdekkingsmechanisme wordt toegepast door de eigenschap GMS_DISCOVERY_URI_LIST in te stellen op de waarde generate.
Sessiereplicatie in Payara met Hazelcast
Sessiereplicatie binnen de Payara-cluster is gebaseerd op Hazelcast, wat als extra voordeel heeft dat het voldoet aan JCache en de ingebouwde Web- en EJB-sessiepersistentie biedt. Dit in-memory datagrid is automatisch ingeschakeld voor alle Payara-instanties om jouw clusterleden in de omgeving te ontdekken via TCP zonder multicast.
Om sessiereplicatie mogelijk te maken, moet u eerst de beschikbaarheid van de webcontainer inschakelen. Dit stelt beheerde webcontainerinstellingen zoals sessies in staat om te worden gebruikt over meerdere instanties met dezelfde configuratie.
In Payara Server 4 moest je Hazelcast inschakelen en toegankelijkheid handmatig configureren. Dit is standaard ingesteld in de huidige Payara 5. Als u enige configuratiewijzigingen heeft aangebracht, zorg er dan voor dat de toegankelijkheidsservice is ingeschakeld en dat het opslagtype is ingesteld op "hazelcast" op de toegankelijkheidspagina van de webcontainer.
Om Hazelcast-instellingen te beheren, kun je toegang krijgen tot de beheerconsole en verwijzen naar de configuratiepagina van het domeingegevensraster. De Domain Data Grid-functie van Payara is gebaseerd op de Hazelcast-bibliotheek. Het biedt de benodigde functionaliteit voor de implementatiegroep (clusteringfunctionaliteit), cachingfunctionaliteit, een enkel CDI-clusterobject en monitoring van gegevensopslag in Payara.
Implementeer nu een voorbeeldtoepassing om de hoge beschikbaarheid van een automatisch samengestelde cluster te testen, met als voorbeeld een geschaalde GlassFish-server. Om de fouttolerantie te controleren, zullen we een speciale testtoepassing implementeren waarmee aangepaste sessiegegevens kunnen worden toegevoegd en gedetailleerde informatie over de server waarop deze sessie wordt verwerkt, kan worden bekeken. Op deze manier kunnen we door bepaalde clusterinstanties te stoppen, controleren of de al lopende gebruikerssessies blijven worden verwerkt, zelfs als de overeenkomstige server uitvalt. Laten we dit in de praktijk bekijken.
Deploy voorbeeld applicatie voor HA test
Nu gaan we de hoge beschikbaarheid van zo'n automatisch samengestelde cluster controleren aan de hand van het voorbeeld van een geschaalde GlassFish-server. Om er zeker van te zijn dat deze fouttolerant is, zullen we een speciale testtoepassing implementeren. Deze toepassing stelt ons in staat om aangepaste sessiegegevens toe te voegen en gedetailleerde informatie te bekijken over de server die deze sessie verwerkt. Op deze manier kunnen we door bepaalde clusterinstanties te stoppen, controleren of de al lopende gebruikerssessies blijven worden verwerkt, zelfs als de overeenkomstige server uitvalt. Laten we dit in de praktijk bekijken.
- Klik op "Openen in browser" naast uw omgeving om toegang te krijgen tot de startpagina van de toepassingsserver. Navigeer binnen de geopende pagina naar de Beheerconsole en log in met de inloggegevens die naar u zijn verzonden via e-mail bij het aanmaken van de omgeving.
- Ga naar de sectie "Toepassingen" en upload het clusterjsp.ear-toepassing naar de locatie "Verpakte bestanden om naar de server te uploaden".
- Controleer of "Beschikbaarheid" is ingeschakeld en stel "cluster1" in als de toepassingsdoelgroep. Klik vervolgens op "OK" om door te gaan.
- Open nu de omgeving in uw browser en voeg "/clusterjsp" toe aan de URL. Geef een aangepaste naam en waarde op voor uw eigen sessieattribuut en klik op "Sessiegegevens toevoegen".
- Schakel terug naar het beheerpaneel en ga naar "Clusters" > "cluster1" > "Instanties". Selecteer hier de instantie waarop uw sessie wordt uitgevoerd (de hostname is gemarkeerd in de bovenstaande afbeelding) en stop deze.
- Ga terug naar onze toepassing en vernieuw de pagina met de juiste knop.
Zoals je kunt zien, ondanks dat de sessie wordt verwerkt door een andere instantie, wordt ons aangepaste attribuut nog steeds weergegeven.
Tip: Alle replicatie-instellingen zijn beschikbaar in het gedeelte "Configuraties" > "cluster1-config" > "Beschikbaarheidsservice" van het beheerderspaneel van de server. Hier kun je zien dat de volgende replicatiemodi standaard zijn ingeschakeld:
- Beschikbaarheid van webcontainer
- Beschikbaarheid van EJB-container
Cloning cluster voor A/B testen
Bij het uitbrengen van een nieuwe versie van een toepassing of het aanbrengen van essentiële aanpassingen is het een goede praktijk om te controleren hoe de nieuw geïmplementeerde wijzigingen de werking van de service en de aantrekkelijkheid voor je gebruikers kunnen beïnvloeden. Previder PaaS+ stelt je in staat om dergelijke tests 'on-the-fly' uit te voeren (dat wil zeggen, zonder serviceonderbreking en impliciet voor uw klanten) met de optie "Clone Environment". Hierdoor wordt een gekloonde omgeving gemaakt waarin je de wijzigingen kunt testen voordat je ze naar de productieomgeving implementeert.
Hiermee wordt er een gekloonde clusterkopie gemaakt die direct klaar is voor gebruik, met alle benodigde wijzigingen die al zijn toegepast. Dit betekend dat een gekloonde DAS-node werkt met de bijbehorende gekloonde werkers, die al vermeld staan in het beheerderspaneel, en dat alle toepassingen uit de oorspronkelijke omgeving ook naar de gekloonde omgeving worden gedeployeerd. Het enige wat je dan nog hoeft te doen, is jouw app-code en aangepaste serverconfiguraties controleren op vaste IP-adressen/domeinen en deze zo nodig aanpassen.
Op deze manier kun je de geïmpliceerde wijzigingen toepassen op je omgevingskopie zonder de daadwerkelijke productieomgeving te beïnvloeden. Vervolgens kun je ook de productiviteit en effectiviteit van de gewijzigde toepassingsversie evalueren in vergelijking met de huidige originele versie, oftewel zogenaamde A/B-tests uitvoeren. Bij Previder PaaS+ kan dit worden geïmplementeerd met een speciale aanvullende Traffic Distributor add-on.
Hiermee kun je verkeer verdelen tussen verschillende versies van je toepassing om te bepalen welke versie het beste presteert en welke wijzigingen effectiever zijn voor jouw gebruikers. Dit helpt bij het nemen van weloverwogen beslissingen over welke wijzigingen je in jouw productieomgeving wilt implementeren.
Wanneer het wordt geplaatst voor een paar omgevingen waarbij de Sticky Sessions-modus is gekozen, biedt het slimme routering van binnenkomende verzoeken op basis van het opgegeven gewicht van de back-ends. Voor meer details over de juiste configuratie van Traffic Distributor (TD) in dit geval, raadpleeg de speciale A/B Testing richtlijn die daarvoor is opgesteld.
Hiermee kun je verkeer verdelen tussen verschillende versies van je toepassing en de belasting op je servers evenwichtiger maken, wat handig is bij het uitvoeren van A/B-tests om de prestaties van verschillende versies te vergelijken en te optimaliseren.
...nog een paar handige tips voor GlassFish & Payara Clustering
Wanneer je GlassFish- of Payara-cluster is ingesteld en je ervoor hebt gezorgd dat alles naar wens werkt, kun je ook rekening houden met de volgende tips om de maximale efficiëntie van de werking ervan binnen de Previder Cloud te bereiken met uitgebreide platformfunctionaliteit:
- Voor geoptimaliseerd resourceverbruik kun je automatische schalingstriggers instellen binnen je omgevingsinstellingen, zodat knooppunten automatisch aan/uit worden geschakeld binnen een cluster, afhankelijk van de inkomende belasting.
- Voor verbinding met een willekeurige database-softwarestack, moeten de juiste bibliotheken worden geïntegreerd met de beheerserver van het cluster. De meest populaire zijn standaard beschikbaar bij alle nieuw gemaakte GF/Payara-knooppunten. Als je met oudere instanties werkt, zorg er dan voor dat de /opt/glassfish/glassfish/domains/domain1/lib DAS-map de juiste bestanden bevat (anders kun je ze handmatig naar de genoemde locatie uploaden).
Hopelijk hebben beschreven details van de GlassFish- en Payara-clusterimplementatie je voldoende inzicht gegeven om te beslissen of dit de oplossing is die jij nodig hebt. Probeer het uit door je eigen cluster te maken op het Previder PaaS+ platform in de 30 dagen gratis proefperiode.
Probeer Previder PaaS+ 30 dagen gratis! Maak direct jouw PaaS 30 dagen free trial account aan.
Maak direct je account aan en probeer Previder PaaS+ 30 dagen gratis!
- Ongelimiteerd aantal gebruikers
- Geen creditcard vereist
- 30 dagen volledige functionaliteit
- Binnen 1 minuut aan de slag
Maak gratis account aan
Meer weten over GlassFish & Payara Auto-Clustering?
Neem contact op met jouw accountmanager of neem contact op via onze contactpagina.
Lees hier alles over:
- Dienst: Platfom as a Service
- Markt: IT oplossingen voor ontwikkelaars
- Blog: Wat is PaaS?
- Blog: Wat is Kubernetes?
- Blog: Platform as a Service van Previder vs. Internationale hyperscalers
- Techblog: Kubernetes (k8s)
- Techblog: Grafana kubernetes dashboard
- Techblog: BitNinja: security add-on op Previder PaaS+
- Techblog: Hoe connect je PostgreSQL met een Java-toepassing?
- Kubernetes website: Kubernetes
- BitNinja website: BitNinja