SafeKit: Alles-in-één SANless High Availability & Applicatie-clustering Software

SafeKit biedt de volgende functies voor Windows en Linux in één enkel softwareproduct:

• Load balancing
• Synchrone realtime bestandsreplicatie
• Automatische applicatie-failover
• Automatische failback na een serverstoring

Nee. SafeKit is eenvoudig te implementeren — er is geen geavanceerde expertise vereist.

Nee. SafeKit draait op uw bestaande servers, virtuele machines of in de cloud — er zijn geen gedeelde schijven of SAN-opslag nodig.

Nee. SafeKit werkt met standaard Windows- en Linux-edities en heeft geen enterprise database-licenties nodig.

SafeKit lost het volgende op:

• Hardwarestoringen (20% van de problemen), inclusief het volledig uitvallen van een serverruimte
• Softwarefouten (40% van de problemen), inclusief het herstarten van kritieke processen
• Menselijke fouten (40% van de problemen) dankzij het gebruiksgemak

U kunt realtime replicatie en failover implementeren voor:

• Alle soorten applicaties, bestandslocaties en services
• Databases
• Volledige Hyper-V of KVM virtuele machines
• Docker, Podman en cloud-applicaties

SafeKit elimineert de noodzaak voor de volgende zaken:

• Network load balancers of dedicated proxyservers
• Gedeelde schijven of gerepliceerde SAN-opslag
• Enterprise-edities van besturingssystemen en databases
• Gespecialiseerde vaardigheden voor clusteronderhoud

Nee. Datareplicatie is simpelweg het kopiëren van gegevens van Server A naar Server B. Hoewel dit essentieel is, biedt replicatie op zichzelf geen beschikbaarheid. Zonder de overige componenten van een HA-stack is replicatie slechts een "passieve kopie" die handmatige, tijdrovende interventie vereist om nuttig te zijn:

• Als Server A crasht, zal datareplicatiesoftware uw gebruikers niet automatisch naar Server B leiden.
• Het zal niet detecteren dat de applicatie is gestopt.
• Het zal de services niet herstarten.

Veel leveranciers vereisen dat u verschillende producten aan elkaar koppelt om host-gebaseerde replicatie, failover en load balancing te realiseren. Deze gefragmenteerde architectuur is een gevaarlijke strategie voor bedrijfskritische systemen:

• Fragiele integratie: Wanneer u product A gebruikt voor replicatie en product B voor clustering, creëert u een "kaartenhuis". Elke OS-update of beveiligingspatch vormt een risico voor de kwetsbare communicatieverbinding tussen deze afzonderlijke engines.
• Hoge cognitieve belasting & menselijke fouten: Het beheren van meerdere interfaces verhoogt het risico op fouten. Tijdens een systeemstoring onder hoge druk leidt het schakelen tussen verschillende GUI's of het gebruik van verschillende CLI-syntaxis tot verwarring en langere downtime.
• Vingerwijzen door leveranciers: Als een failover mislukt, kan de replicatieleverancier de clusteringtool de schuld geven, waardoor u er tussenin komt te zitten zonder duidelijke oplossing. Een alles-in-één oplossing biedt één enkel aanspreekpunt.
• Complex onderhoud: Gefragmenteerde systemen vereisen gespecialiseerde vaardigheden voor elk afzonderlijk onderdeel, waardoor de oplossing moeilijker te onderhouden is en na verloop van tijd aanzienlijk duurder wordt.

Om herstel te automatiseren en downtime te elimineren, moet een alles-in-één product verschillende technische onderdelen gelijktijdig beheren:

• Host-gebaseerde replicatie: realtime, synchrone replicatie van kritieke applicatiegegevens tussen servers zonder afhankelijk te zijn van gedeelde opslag (SAN). Dit garandeert nul dataverlies (RPO=0) en elimineert dure hardware-afhankelijkheden.
• Virtueel IP-adres (VIP): Dit biedt één centraal toegangspunt voor gebruikers. Wanneer er een storing optreedt, verplaatst de software het VIP van de defecte node naar de gezonde node, zodat gebruikers hun configuratie niet hoeven aan te passen.
• Hardware- en softwarefoutdetectoren: Het systeem moet constant een "heartbeat" uitvoeren op zowel de fysieke server als de specifieke softwareprocessen om een vastloper of crash onmiddellijk te identificeren.
• Aanpasbare opstartscripts: Niet elke applicatie start op dezelfde manier. Een alles-in-één tool maakt aangepaste scripts mogelijk om ervoor te zorgen dat complexe services in de juiste volgorde starten.
• Automatische failover: De intelligentie om de volledige overgang van de ene server naar de andere te orkestreren zonder menselijke tussenkomst.

Als uw failover-manager en uw datareplicatie twee verschillende producten zijn, lopen ze mogelijk niet "in de pas".

Het gevaar: Als er een failover plaatsvindt terwijl de replicatie de laatste bits nog niet volledig heeft verzonden, zal Server B de applicatie opstarten met verouderde of corrupte gegevens.

Een alles-in-één SANless HA-oplossing garandeert dat het failover-mechanisme op de hoogte is van de replicatiestatus. Het staat het opstarten van de applicatie op de back-upnode alleen toe als de gegevens gegarandeerd up-to-date zijn, waardoor conflicterende actieve nodes en gegevensverlies worden voorkomen.

Automatische failback wordt vaak over het hoofd gezien in technische handleidingen en slecht uitgevoerd door traditionele HA-oplossingen, maar het blijft de meest kritieke vereiste voor echte veerkracht. Een echt alles-in-één product handelt de "terugkeer naar normaal" net zo elegant af als de storing zelf. Wanneer de defecte server weer online komt, loopt deze achter qua gegevens. De HA-software moet dan:

1. Gegevens hersynchroniseren op de achtergrond van de actieve node naar de herstelde node.
2. Uptime behouden: Deze hersynchronisatie moet plaatsvinden zonder de applicatie die momenteel op de actieve node draait te onderbreken.
3. Redundantie herstellen: Zodra de gegevens weer gespiegeld zijn, keert het cluster automatisch terug naar een beveiligde status, klaar voor een volgende gebeurtenis.

De technische methode die wordt gebruikt voor host-gebaseerde replicatie heeft een grote invloed op de mate waarin u uw bestaande applicatieconfiguratie moet aanpassen.

• De uitdaging van replicatie op blokniveau: De meeste SANless-oplossingen repliceren op schijf-/blokniveau. Dit is niet transparant voor de applicatie. Het vereist dat u de applicatie volledig opnieuw configureert om de gegevens naar een specifiek, nieuw aangemaakt "gerepliceerd schijfvolume" te verplaatsen. Dit gaat vaak gepaard met complexe migraties en mogelijke wijzigingen in de applicatielogica.
• Het voordeel van SafeKit op bestandsniveau: SafeKit voert host-gebaseerde replicatie uit op bestandsniveau, wat volledig transparant is voor de applicatie. U hoeft geen gegevens naar een speciale schijf te verplaatsen; u configureert SafeKit simpelweg om de bestaande applicatiemappen te repliceren. Deze mappen kunnen zelfs op de systeemschijf blijven staan, waardoor u een applicatie kunt beschermen precies op de plek waar deze al is geïnstalleerd.

Resynchronisatietijd na een storing (stap 3)

• 1 Gb/s netwerk ≈ 3 uur voor 1 terabyte.
• 10 Gb/s netwerk ≈ 1 uur voor 1 terabyte of minder, afhankelijk van schrijfsnelheid van de schijf.

Alternatief

• Voor een groot datavolume, gebruik externe gedeelde opslag.
• Duurder, complexer.

• Resynchronisatieprestaties na een storing (stap 3).
• Tijd om elk bestand tussen beide nodes te controleren.

Alternatief

• Plaats de vele te repliceren bestanden in een virtuele harde schijf / virtuele machine.
• Alleen de bestanden die de virtuele harde schijf / virtuele machine vertegenwoordigen, worden in dit geval gerepliceerd en gesynchroniseerd.

• Elke VM draait in een onafhankelijk spiegelmodule.
• Maximum van 32 spiegelmodules op dezelfde cluster.

Alternatief

• Gebruik externe gedeelde opslag en een andere VM-clusteringoplossing.
• Duurder, complexer.

• Automatische failover van het virtuele IP-adres met 2 nodes in hetzelfde subnet.
• Goede bandbreedte voor resynchronisatie (stap 3) en goede latency voor synchrone replicatie (typisch een round-trip van minder dan 2 ms).

Alternatief

• Gebruik een load balancer voor het virtuele IP-adres als de 2 nodes zich in 2 subnets bevinden (ondersteund door SafeKit, vooral in de cloud).
• Gebruik back-upoplossingen met asynchrone replicatie voor netwerken met hoge latency.

De SafeKit webconsole biedt een intuïtieve interface om hoge beschikbaarheid voor uw kritieke applicaties te orkestreren. In slechts een paar stappen kunt u een SafeKit mirror-cluster configureren om de bedrijfscontinuïteit te waarborgen:

• Applicatie-failover (tabblad Macros): Definieer de specifieke applicatiediensten die automatisch herstart moeten worden in het geval van een storing.
• Heartbeat-netwerk(en): Toegewijde communicatiepaden die door de clusternodes worden gebruikt om continu elkaars status en beschikbaarheid te controleren en failover-beslissingen te synchroniseren.
• Virtueel IP-beheer: Stel het virtuele IP-adres (VIP) in voor een transparante herverbinding van clients na een failover.
• Realtime replicatie: Selecteer de kritieke mappen (directories) voor host-gebaseerde, synchrone replicatie op byte-niveau.
• Checkers: Monitor de status van de applicatie en activeer automatisch herstel zodra er een procesfout wordt gedetecteerd.

Het SafeKit-cluster bevat een ingebouwde split-brain checker om netwerklokalisatieproblemen op te lossen zonder dat er een derde 'witness machine' (getuige) of een extra heartbeat-netwerk nodig is. Lees meer over heartbeat, failover en quorum in een cluster.

De SafeKit-beheerconsole biedt een universeel overzicht van uw hoge beschikbaarheidsinfrastructuur. Hiermee kunnen beheerders de operationele status van het cluster controleren en de datasynchronisatie in realtime volgen.

Voor een mirror-cluster met 2 nodes toont de console duidelijk de rollen van elke server:

• PRIM (Primary): De actieve node die momenteel de applicatie uitvoert en het virtuele IP-adres beheert. Deze voert schrijfbewerkingen uit op de lokale opslag en verzorgt de realtime replicatie naar de secundaire node.
• SECOND (Secondary): De stand-by node die synchrone updates op byte-niveau ontvangt. Deze staat klaar om direct de taken over te nemen als de Primary uitvalt.
• ALONE-status: Waarschuwt u visueel wanneer het cluster op een enkele node draait (bijv. tijdens onderhoud of na een storing), wat aangeeft dat de redundantie tijdelijk is weggevallen.
• Voortgang van de hersynchronisatie: Wanneer een uitgevallen node herstelt, kleurt de status ervan oranje tijdens de gegevensreïntegatie op de achtergrond. Dit garandeert dat er geen downtime is tijdens de fase van de "terugkeer naar normaal".

Naast eenvoudige statuspictogrammen biedt de interface failover-orkestratie met één klik, waardoor u de primaire rol handmatig kunt herverdelen voor gepland onderhoud, terwijl de continue beschikbaarheid voor gebruikersactiviteiten gewaarborgd blijft.

Het SafeKit-cluster in farm-modus is ontworpen voor hoge beschikbaarheid en schaalbaarheid van diensten. De configuratie is gericht op het gelijktijdig verdelen van inkomend verkeer over beide knooppunten (nodes):

• Load Balanced Services (tabblad Macros): Definieer de specifieke applicatiediensten (bijv. Apache, IIS, Nginx) die op alle knooppunten actief moeten blijven.
• Hartslagnetwerk(en) (Heartbeat): Communicatiepad(en) die worden gebruikt om te detecteren of een knooppunt de farm heeft verlaten, wat een onmiddellijke herverdeling van de belasting activeert.
• Virtueel IP (Farm VIP): In tegenstelling tot een spiegelcluster (mirror cluster) wordt het Farm VIP gedeeld tussen knooppunten met behulp van een kernelfilteralgoritme om netwerkverkeer te distribueren.
• Loadbalancingregels: Definieer het beleid voor verkeersdistributie op basis van het bron-IP-adres of de poort.
• Checkers: Bewaak de gezondheid van de applicatie en activeer een automatische herstart als er een procesfout wordt gedetecteerd.

Het bewaken van een cluster in farm-modus biedt inzicht in het Active-Active karakter van de infrastructuur, waarbij alle knooppunten (nodes) bijdragen aan de prestaties van de applicatie (in dit voorbeeld worden 2 knooppunten getoond):

• UP-status (50% op 2 knooppunten): In een gezonde farm verkeren beide knooppunten in de "UP"-status (50%), wat betekent dat ze beide actief clientverzoeken ontvangen en verwerken via het gedeelde virtuele IP-adres.
• Automatische herverdeling: Als één knooppunt uitvalt, laat de console visueel zien dat het resterende knooppunt 100% van het verkeer overneemt. Er is geen "failover"-vertraging, aangezien het overlevende knooppunt al actief is (afgezien van een detectietijd van enkele seconden).
• Invoegen van een knooppunt: Wanneer een hersteld knooppunt opnieuw wordt opgestart, gaat het over van "STOP" naar "UP" en begint het automatisch zijn deel van de belasting te ontvangen zonder tussenkomst van de beheerder.
• Geen gegevenssynchronisatie: Let op: in een cluster in farm-modus is er geen "oranje" hersynchronisatiestatus, aangezien de knooppunten stateless horen te zijn of een backend-database delen (die afzonderlijk kan worden beveiligd in een spiegelcluster).

Naast eenvoudige statuspictogrammen biedt de interface knooppuntbeheer met één klik, waarmee u handmatig een knooppunt kunt stoppen of starten voor gepland onderhoud, terwijl het gedeelde virtuele IP-adres automatisch het verkeer herverdeelt zonder de activiteit van de gebruiker te onderbreken.