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 (High Availability) voor uw kritieke applicaties te orkestreren. In slechts enkele stappen kunt u een SafeKit mirror cluster configureren om bedrijfscontinuïteit te waarborgen:

• Application Failover (Tabblad Macros): Definieer de specifieke applicatiediensten die automatisch herstart moeten worden in het geval van een storing.
• Heartbeat-netwerk(en): Toegewezen communicatiepad(en) die door de clusternodes worden gebruikt om elkaars status en beschikbaarheid continu te bewaken en failover-beslissingen te synchroniseren.
• Virtueel IP-beheer: Stel het Virtuele IP-adres (VIP) in voor transparante herverbinding van clients na een failover.
• Real-time Replicatie: Selecteer de kritieke mappen voor host-gebaseerde, synchrone replicatie op byte-niveau.
• Checkers: Bewaak de gezondheid van de applicatie en activeer automatisch herstel als er een procesfout wordt gedetecteerd.

Het SafeKit-cluster bevat een specifieke split-brain checker om netwerkisolatieproblemen op te lossen zonder de noodzaak van een derde witness-machine of een extra heartbeat-netwerk. Lees meer over stroomuitval en netwerkisolatie in een cluster.

De SafeKit-beheerconsole biedt een uniform overzicht van uw high availability-infrastructuur. Hiermee kunnen beheerders de operationele status van het cluster bewaken en de datasynchronisatie in real-time volgen.

Voor een mirror cluster met 2 nodes geeft de console duidelijk de rollen van elke server weer:

• PRIM (Primary): De actieve node die momenteel de applicatie uitvoert en het Virtuele IP-adres beheert. Deze voert schrijfacties uit op de lokale opslag en verzorgt de real-time replicatie naar de secundaire node.
• SECOND (Secondary): De standby-node die synchrone updates op byte-niveau ontvangt. Deze is klaar om direct de taken over te nemen als de primaire node uitvalt.
• ALONE-status: Waarschuwt u visueel wanneer het cluster op één enkele node draait (bijv. tijdens onderhoud of na een storing), wat aangeeft dat de redundantie tijdelijk verloren is gegaan.
• Voortgang van resynchronisatie: Wanneer een uitgevallen node herstelt, wordt de status oranje tijdens de data-reintegratie op de achtergrond. Dit garandeert dat er geen downtime is tijdens de fase van "terugkeer naar normaal".

Naast eenvoudige statuspictogrammen biedt de interface failover-orkestratie met één klik, waarmee u handmatig van rol kunt wisselen (Primair/Secundair) voor gepland onderhoud zonder de activiteit van gebruikers te onderbreken.

Het SafeKit farm-cluster is ontworpen voor hoge beschikbaarheid en schaalbaarheid van diensten. De configuratie richt zich op het gelijktijdig verdelen van inkomend verkeer over beide nodes:

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

De monitoring van een farm-cluster biedt inzicht in de Active-Active architectuur van de infrastructuur, waarbij alle nodes bijdragen aan de prestaties van de applicatie (in dit voorbeeld worden 2 nodes getoond):

• UP-status (50% op 2 nodes): In een gezonde farm verkeren beide nodes in de "UP" (50%) status, wat betekent dat ze beide actief client-aanvragen ontvangen en verwerken via het gedeelde virtuele IP-adres.
• Automatische herverdeling (Re-balancing): Als een node uitvalt, toont de console visueel dat de resterende node 100% van het verkeer overneemt. Er is geen vertraging door een "failover", aangezien de overlevende node al actief is (afgezien van een detectietijd van enkele seconden).
• Node-insertie: Wanneer een herstelde node opnieuw wordt opgestart, gaat deze over van "STOP" naar "UP" en begint automatisch zijn deel van de belasting te ontvangen zonder tussenkomst van de beheerder.
• Geen datasynchronisatie: Merk op dat er in een farm-cluster geen oranje status voor hersynchronisatie bestaat. Dit komt omdat nodes doorgaans stateless zijn of een backend-database delen (die afzonderlijk kan worden beveiligd in een mirror-cluster).

Naast eenvoudige statuspictogrammen biedt de interface node-beheer met één klik. Hiermee kunt u handmatig een node stoppen of starten voor gepland onderhoud, terwijl het gedeelde virtuele IP het verkeer automatisch herverdeelt zonder de gebruikersactiviteit te onderbreken.