Herstel na noodherstel in Azure Service Fabric

Een essentieel onderdeel van het leveren van hoge beschikbaarheid is ervoor te zorgen dat services alle verschillende typen fouten kunnen overleven. Dit is vooral belangrijk voor fouten die niet zijn gepland en die buiten uw controle liggen.

In dit artikel worden enkele veelvoorkomende foutmodi beschreven die noodscenario's kunnen zijn als deze niet correct zijn gemodelleerd en beheerd. Ook worden oplossingen en acties besproken die moeten worden ondernomen als er toch een noodlott zich voor doet. Het doel is om het risico op downtime of gegevensverlies te beperken of te elimineren wanneer er storingen optreden( gepland of anderszins).

Noodscenario's voorkomen

Het belangrijkste doel van Azure Service Fabric is om u te helpen bij het modelleren van zowel uw omgeving als uw services, zodat veelvoorkomende fouttypen geen noodscenario's zijn.

Over het algemeen zijn er twee typen nood-/foutscenario's:

• Hardware- en softwarefouten
• Operationele fouten

Hardware- en softwarefouten

Hardware- en softwarefouten zijn onvoorspelbaar. De eenvoudigste manier om fouten te overleven, is het uitvoeren van meer exemplaren van de service buiten de grenzen van hardware- of softwarefouten.

Als uw service bijvoorbeeld op slechts één computer wordt uitgevoerd, is de storing van die ene computer een noodlott voor die service. De eenvoudige manier om dit noodlot te voorkomen, is ervoor te zorgen dat de service op meerdere computers wordt uitgevoerd. Testen is ook nodig om ervoor te zorgen dat de storing van één computer de service die wordt uitgevoerd niet verstoort. Capaciteitsplanning zorgt ervoor dat een vervangend exemplaar elders kan worden gemaakt en dat de resterende services niet overbelast worden door capaciteitsvermindering.

Hetzelfde patroon werkt ongeacht wat u probeert te voorkomen. Als u zich bijvoorbeeld zorgen maakt over het mislukken van een SAN, kunt u meerdere SAN's gebruiken. Als u zich zorgen maakt over het verlies van een rek met servers, loopt u over meerdere rekken. Als u zich zorgen maakt over het verlies van datacenters, moet uw service worden uitgevoerd in meerdere Azure-regio's, in meerdere Azure-beschikbaarheidszones of in uw eigen datacenters.

Wanneer een service meerdere fysieke exemplaren omvat (machines, rekken, datacenters, regio's), is er nog steeds een aantal soorten gelijktijdige storingen. Maar één en zelfs meerdere fouten van een bepaald type (bijvoorbeeld één virtuele machine of netwerkkoppeling die niet werkt) worden automatisch afgehandeld en zijn dus niet langer een 'noodlottige'.

Service Fabric biedt mechanismen voor het uitbreiden van het cluster en zorgt voor het terughalen van mislukte knooppunten en services. Service Fabric kunt ook veel exemplaren van uw services uitvoeren om te voorkomen dat ongeplande storingen echte rampen worden.

Er zijn mogelijk redenen waarom het uitvoeren van een implementatie die groot genoeg is om fouten te overspannen, niet haalbaar is. Er zijn bijvoorbeeld meer hardwareresources nodig dan u bereid bent om te betalen ten opzichte van de kans op fouten. Wanneer u te maken hebt met gedistribueerde toepassingen, kunnen extra communicatiehops of replicatiekosten voor statussen over geografische afstanden onacceptabele latentie veroorzaken. Waar deze lijn wordt getekend, verschilt voor elke toepassing.

Specifiek voor softwarefouten kan het fout zijn in de service die u probeert te schalen. In dit geval kunnen meer exemplaren het noodgeval niet voorkomen, omdat de foutvoorwaarde is gecorreleerd aan alle exemplaren.

Operationele fouten

Zelfs als uw service wereldwijd wordt overspannen met veel redundantie, kunnen er nog steeds noodgebeurtenissen zijn. Iemand kan bijvoorbeeld per ongeluk de DNS-naam voor de service opnieuw configureren of deze direct verwijderen.

Stel dat u een stateful service hebt Service Fabric en iemand die service per ongeluk heeft verwijderd. Tenzij er een andere beperking is, zijn die service en alle statussen die deze had nu verdwenen. Voor deze typen operationele rampen ('oops') zijn andere oplossingen en stappen voor herstel vereist dan gewone niet-geplande fouten.

De beste manieren om dit soort operationele fouten te voorkomen zijn:

• Beperk de operationele toegang tot de omgeving.
• Controleer strikt gevaarlijke bewerkingen.
• Automatisering opleggen, handmatige of out-of-band-wijzigingen voorkomen en specifieke wijzigingen in de omgeving valideren voordat ze worden doorgevoerd.
• Zorg ervoor dat destructieve bewerkingen 'soft' zijn. Zachte bewerkingen worden niet onmiddellijk van kracht of kunnen binnen een tijdvenster ongedaan worden gemaakt.

Service Fabric biedt mechanismen om operationele fouten te voorkomen, zoals het bieden van op rollen gebaseerd toegangsbeheer voor clusterbewerkingen. Voor de meeste van deze operationele fouten zijn echter organisatie-inspanningen en andere systemen vereist. Service Fabric biedt mechanismen voor het overleven van operationele fouten, met name back-up en herstel voor stateful services.

Fouten beheren

Het doel van Service Fabric is automatisch beheer van fouten. Maar voor het afhandelen van bepaalde typen fouten moeten services aanvullende code hebben. Andere typen fouten moeten niet automatisch worden aangepakt om veiligheids- en bedrijfscontinuïteitsredenen.

Enkele fouten verwerken

Eén machine kan om allerlei redenen mislukken. Soms zijn dit hardware-oorzaken, zoals voedingen en netwerkhardwarestoringen. Andere fouten zitten in software. Dit zijn onder andere fouten van het besturingssysteem en de service zelf. Service Fabric detecteert automatisch dit soort fouten, waaronder gevallen waarin de machine wordt geïsoleerd van andere computers vanwege netwerkproblemen.

Ongeacht het type service leidt het uitvoeren van één exemplaar tot downtime voor die service als die ene kopie van de code om een of andere reden mislukt.

Het eenvoudigste wat u kunt doen is ervoor zorgen dat uw services standaard op meer dan één knooppunt worden uitgevoerd. Voor staatloze services moet u ervoor zorgen dat InstanceCount groter is dan 1. Voor stateful services is de minimale aanbeveling dat TargetReplicaSetSize en beide zijn ingesteld op MinReplicaSetSize 3. Door meer exemplaren van uw servicecode uit te voeren, zorgt u ervoor dat uw service elke fout automatisch kan afhandelen.

Gecoördineerde fouten afhandelen

Gecoördineerde fouten in een cluster kunnen worden veroorzaakt door geplande of ongeplande infrastructuurfouten en -wijzigingen of geplande softwarewijzigingen. Service Fabric infrastructuurzones die gecoördineerde fouten als foutdomeinen ervaren. Gebieden met gecoördineerde softwarewijzigingen worden gemodelleerd als upgradedomeinen. Zie Een Service Fabric-cluster beschrijven met behulp van Cluster Resource Manager voor meer informatie over foutdomeinen, upgradedomeinen en clustertopologie.

Standaard worden fout Service Fabric en upgradedomeinen in overweging bij het plannen waar uw services moeten worden uitgevoerd. Standaard wordt Service Fabric ervoor te zorgen dat uw services worden uitgevoerd in verschillende fout- en upgradedomeinen, zodat uw services beschikbaar blijven als geplande of ongeplande wijzigingen plaatsvinden.

Stel bijvoorbeeld dat een storing van een voedingsbron ervoor zorgt dat alle machines in een rek tegelijkertijd uitvallen. Als meerdere exemplaren van de service worden uitgevoerd, verandert het verlies van veel computers in foutdomeinen in slechts een ander voorbeeld van één fout voor een service. Daarom is het beheren van fout- en upgradedomeinen essentieel voor hoge beschikbaarheid van uw services.

Wanneer u een Service Fabric in Azure, worden foutdomeinen en upgradedomeinen automatisch beheerd. In andere omgevingen is dat mogelijk niet zo. Als u uw eigen on-premises clusters bouwt, moet u ervoor zorgen dat u de indeling van uw foutdomein correct toe te passen en te plannen.

Upgradedomeinen zijn handig voor het modelleren van gebieden waar software tegelijkertijd wordt bijgewerkt. Daarom definiëren upgradedomeinen vaak ook de grenzen waar software wordt uitgenomen tijdens geplande upgrades. Upgrades van zowel Service Fabric als uw services volgen hetzelfde model. Zie voor meer informatie over rolling upgrades, upgradedomeinen en het Service Fabric-statusmodel waarmee wordt voorkomen dat onbedoelde wijzigingen van invloed zijn op het cluster en uw service:

• Toepassingsupgrade
• Zelfstudie toepassingsupgrade
• Service Fabric health model

U kunt de indeling van uw cluster visualiseren met behulp van de clusterkaart die is opgegeven in Service Fabric Explorer:

Gelijktijdige hardware- of softwarefouten afhandelen

We hebben het over enkele fouten. Zoals u ziet, zijn ze eenvoudig te verwerken voor staatloze en stateful services door alleen maar meer exemplaren van de code (en status) te bewaren die in fout- en upgradedomeinen worden uitgevoerd.

Er kunnen ook meerdere gelijktijdige willekeurige fouten optreden. Deze zullen waarschijnlijk leiden tot downtime of een daadwerkelijk noodlot.

Staatloze services

Het aantal exemplaren voor een stateless service geeft het gewenste aantal exemplaren aan dat moet worden uitgevoerd. Wanneer een of alle exemplaren mislukken, reageert Service Fabric door automatisch vervangende exemplaren te maken op andere knooppunten. Service Fabric blijven vervangingen maken totdat de service weer het gewenste aantal exemplaren heeft.

Stel bijvoorbeeld dat de stateless service een InstanceCount waarde van -1 heeft. Deze waarde betekent dat er één exemplaar moet worden uitgevoerd op elk knooppunt in het cluster. Als sommige van deze exemplaren mislukken, detecteert Service Fabric dat de service niet de gewenste status heeft en probeert de exemplaren te maken op de knooppunten waar ze ontbreken.

Stateful services

Er zijn twee soorten stateful services:

• Stateful met persistente status.
• Stateful met niet-persistente status. (Status wordt opgeslagen in het geheugen.)

Het herstel na een storing stateful service is afhankelijk van het type stateful service, hoeveel replica's de service had en hoeveel replica's zijn mislukt.

In een stateful service worden binnenkomende gegevens gerepliceerd tussen replica's (de primaire en eventuele actieve secundaire replica's). Als een meerderheid van de replica's de gegevens ontvangt, worden gegevens beschouwd als quorumverdeeld. (Voor vijf replica's is drie een quorum.) Dit betekent dat er op elk moment ten minste een quorum van replica's met de meest recente gegevens is. Als replica's mislukken (bijvoorbeeld twee van de vijf), kunnen we de quorumwaarde gebruiken om te berekenen of we kunnen herstellen. (Omdat de resterende drie van de vijf replica's nog steeds in gebruik zijn, is het gegarandeerd dat ten minste één replica volledige gegevens heeft.)

Wanneer een quorum van replica's mislukt, wordt de partitie gedeclareerd als quorumverlies. Stel dat een partitie vijf replica's heeft, wat betekent dat ten minste drie gegarandeerd volledige gegevens hebben. Als een quorum (drie van de vijf) replica's mislukt, kunnen Service Fabric niet bepalen of de resterende replica's (twee van de vijf) voldoende gegevens hebben om de partitie te herstellen. In gevallen waarin Service Fabric quorumverlies detecteert, is het standaardgedrag om extra schrijfingen naar de partitie te voorkomen, quorumverlies te declareeren en te wachten tot een quorum van replica's is hersteld.

Het bepalen of er een noodgevallen voor een stateful service en vervolgens het beheren ervan volgen drie fasen:

1. Bepalen of er al dan niet quorumverlies is.

   Quorumverlies wordt gedeclareerd wanneer een meerderheid van de replica's van een stateful service tegelijkertijd niet werkt.

2. Bepalen of het quorumverlies permanent is of niet.

   In de meeste tijd zijn fouten tijdelijk. Processen worden opnieuw gestart, knooppunten worden opnieuw opgestart, virtuele machines worden opnieuw gestart en netwerkpartities worden hersteld. Soms zijn fouten echter permanent. Of fouten permanent zijn of niet, hangt ervan af of de stateful service de status behoudt of dat deze alleen in het geheugen wordt opgeslagen:

   • Voor services zonder persistente status leidt een storing van een quorum of meer replica's onmiddellijk tot permanent quorumverlies. Wanneer Service Fabric quorumverlies in een stateful niet-permanente service detecteert, gaat het onmiddellijk door naar stap 3 door (mogelijk) gegevensverlies te declareren. Doorgaan met gegevensverlies is logisch omdat Service Fabric weet dat het geen zin heeft om te wachten tot de replica's terug zijn. Zelfs als ze worden hersteld, gaan de gegevens verloren vanwege de niet-persistente aard van de service.
   • Voor stateful permanente services zorgt een storing van een quorum of meer replica's ervoor dat Service Fabric wachten tot de replica's terug zijn en het quorum herstellen. Dit resulteert in een service-storing voor schrijf naar de betrokken partitie (of 'replicaset') van de service. Leess kunnen echter nog steeds mogelijk zijn met minder consistentiegaranties. De standaard hoeveelheid tijd die Service Fabric voordat het quorum wordt hersteld, is oneindig, omdat het doorgaan een (mogelijk) gegevensverliesgebeurtenis is en andere risico's met zich meebrengt. Dit betekent dat Service Fabric niet verdergaat met de volgende stap, tenzij een beheerder actie onderneemt om gegevensverlies te declaren.

3. Bepalen of gegevens verloren gaan en herstellen vanuit back-ups.

   Als quorumverlies is gedeclareerd (automatisch of via een beheeractie), gaan Service Fabric en de services verder met het bepalen of gegevens daadwerkelijk verloren zijn gegaan. Op dit moment weet Service Fabric dat de andere replica's niet meer terug komen. Dat was de beslissing die werd genomen toen we niet meer wachtten op het quorumverlies om zichzelf op te lossen. De beste aanpak voor de service is meestal om te blokkeren en te wachten op specifieke administratieve interventie.

   Wanneer Service Fabric methode OnDataLossAsync aanroept, komt dit altijd door verdacht gegevensverlies. Service Fabric zorgt ervoor dat deze aanroep wordt geleverd aan de beste resterende replica. Dit is de replica die de meeste voortgang heeft gemaakt.

   De reden dat we altijd verdacht gegevensverlies zeggen, is dat het mogelijk is dat de resterende replica dezelfde status heeft als de primaire replica tijdens het verloren quorum. Zonder deze status is er echter geen goede manier om dit te Service Fabric operators om dit zeker te weten.

   Wat doet een typische implementatie van OnDataLossAsync de methode dan?

   1. De implementatielogboeken OnDataLossAsync die zijn geactiveerd en de benodigde beheerwaarschuwingen worden geactiveerd.

   2. Normaal gesproken wordt de implementatie onderbroken en gewacht tot verdere beslissingen en handmatige acties worden ondernomen. Dit komt doordat zelfs als er back-ups beschikbaar zijn, ze mogelijk moeten worden voorbereid.

      Als bijvoorbeeld twee verschillende services informatie coördineren, moeten deze back-ups mogelijk worden gewijzigd om ervoor te zorgen dat de informatie die deze twee services belangrijk vinden, consistent is nadat het herstellen is gebeurd.

   3. Vaak is er andere telemetrie of uitputting van de service. Deze metagegevens kunnen zijn opgenomen in andere services of in logboeken. Deze informatie kan zo nodig worden gebruikt om te bepalen of er aanroepen zijn ontvangen en verwerkt op de primaire die niet aanwezig waren in de back-up of zijn gerepliceerd naar deze specifieke replica. Deze aanroepen moeten mogelijk opnieuw worden afgespeeld of aan de back-up worden toegevoegd voordat herstel mogelijk is.

   4. De implementatie vergelijkt de status van de resterende replica met de status die is opgenomen in beschikbare back-ups. Als u betrouwbare verzamelingen Service Fabric gebruikt, zijn er hulpprogramma's en processen beschikbaar om dit te doen. Het doel is om te zien of de status binnen de replica voldoende is en om te zien wat er mogelijk ontbreekt in de back-up.

   5. Nadat de vergelijking is voltooid en het herstellen is voltooid (indien nodig), moet de servicecode true retourneren als er statuswijzigingen zijn aangebracht. Als de replica heeft vastgesteld dat dit de best beschikbare kopie van de status was en geen wijzigingen heeft aangebracht, retourneert de code false.

      De waarde true geeft aan dat andere resterende replica's nu mogelijk inconsistent zijn met deze replica. Ze worden uit deze replica gedropt en opnieuw opgebouwd. De waarde false geeft aan dat er geen statuswijzigingen zijn aangebracht, zodat de andere replica's kunnen behouden wat ze hebben.

Het is van cruciaal belang dat serviceauteurs mogelijke scenario's voor gegevensverlies en -fouten oefenen voordat services in productie worden geïmplementeerd. Om u te beschermen tegen de mogelijkheid van gegevensverlies, is het belangrijk om periodiek een back-up te maken van de status van uw stateful services naar een geografisch redundante opslag.

U moet er ook voor zorgen dat u de status kunt herstellen. Omdat back-ups van veel verschillende services op verschillende tijdstippen worden gemaakt, moet u ervoor zorgen dat uw services na een herstel een consistente weergave van elkaar hebben.

Denk bijvoorbeeld aan een situatie waarin de ene service een getal genereert en op slaat, en het vervolgens verzendt naar een andere service waarin het nummer ook wordt op slaat. Na een herstelbewerking kunt u ontdekken dat de tweede service het nummer heeft, maar de eerste niet, omdat de back-up die bewerking niet bevat.

Als u erachter komt dat de resterende replica's onvoldoende zijn om door te gaan in een scenario voor gegevensverlies en u de servicetoestand niet kunt reconstrueren op basis van telemetrie of uitputting, bepaalt de frequentie van uw back-ups uw best mogelijke RPO (Recovery Point Objective). Service Fabric biedt veel hulpprogramma's voor het testen van verschillende foutscenario's, waaronder permanent quorum- en gegevensverlies die herstel vanuit een back-up vereisen. Deze scenario's zijn opgenomen als onderdeel van de testprogramma's in Service Fabric, beheerd door de Fault Analysis Service. Zie Inleiding tot de Fault Analysis Service voor meer informatie over deze hulpprogramma's en patronen.

Problemen met quorumverlies oplossen

Replica's kunnen af en toe niet werken vanwege een tijdelijke fout. Wacht even terwijl Service Fabric deze probeert weer te geven. Als replica's langer dan een verwachte duur niet zijn gebruikt, volgt u deze actie voor probleemoplossing:

• Replica's kunnen crashen. Controleer de statusrapporten op replicaniveau en uw toepassingslogboeken. Verzamel crashdumps en neem de nodige maatregelen om te herstellen.
• Het replicaproces reageert mogelijk niet meer. Inspecteer uw toepassingslogboeken om dit te controleren. Verzamel procesdumps en stop vervolgens het niet-reagerende proces. Service Fabric maakt een vervangend proces en probeert de replica terug te brengen.
• Knooppunten die als host voor de replica's worden gebruikt, zijn mogelijk niet in staat. Start de onderliggende virtuele machine opnieuw op om de knooppunten te starten.

Soms is het niet mogelijk om replica's te herstellen. De stations zijn bijvoorbeeld uitgevallen of de machines reageren fysiek niet. In dergelijke gevallen moet Service Fabric dat ze niet moeten wachten op replicaherstel.

Gebruik deze methoden niet als mogelijk gegevensverlies onaanvaardbaar is om de service online te brengen. In dat geval moeten alle inspanningen worden gedaan om fysieke machines te herstellen.

De volgende acties kunnen leiden tot gegevensverlies. Controleer voordat u ze volgt.

• Gebruik de Repair-ServiceFabricPartition -PartitionId - of System.Fabric.FabricClient.ClusterManagementClient.RecoverPartitionAsync(Guid partitionId) -API. Met deze API kunt u de id van de partitie opgeven om het quorumverlies te verwijderen en mogelijk gegevensverlies te veroorzaken.
• Als uw cluster regelmatig fouten ondervindt die ertoe leiden dat services de status quorumverlies krijgen en mogelijk gegevensverlies acceptabel is, kan het opgeven van een geschikte QuorumLossWaitDuration-waarde helpen uw service automatisch te herstellen. Service Fabric wacht op de opgegeven waarde QuorumLossWaitDuration (standaard is oneindig) voordat u herstelt. We raden deze methode niet aan, omdat dit onverwachte gegevensverlies kan veroorzaken.

Beschikbaarheid van het Service Fabric cluster

Over het algemeen is Service Fabric cluster een zeer gedistribueerde omgeving zonder single points of failure. Een storing van één knooppunt veroorzaakt geen beschikbaarheids- of betrouwbaarheidsproblemen voor het cluster, voornamelijk omdat de Service Fabric-systeemservices dezelfde richtlijnen volgen die eerder zijn opgegeven. Dat wil zeggen dat ze altijd standaard worden uitgevoerd met drie of meer replica's en systeemservices die stateless worden uitgevoerd op alle knooppunten.

De onderliggende Service Fabric netwerken en foutdetectielagen zijn volledig gedistribueerd. De meeste systeemservices kunnen opnieuw worden opgebouwd op basis van metagegevens in het cluster of weten hoe ze hun status opnieuw moeten synchroniseren vanaf andere locaties. De beschikbaarheid van het cluster kan in gevaar komen als systeemservices in situaties met quorumverlies komen, zoals eerder beschreven. In dergelijke gevallen kunt u mogelijk bepaalde bewerkingen niet uitvoeren op het cluster (zoals het starten van een upgrade of het implementeren van nieuwe services), maar het cluster zelf is nog steeds actief.

Services op een actief cluster blijven in deze omstandigheden actief, tenzij schrijf-naar-de-systeemservices nodig zijn om te blijven functioneren. Als er bijvoorbeeld Failover Manager quorumverlies is, blijven alle services worden uitgevoerd. Maar services die mislukken, kunnen niet automatisch opnieuw worden opgestart, omdat hiervoor de betrokkenheid van Failover Manager.

Fouten in een datacenter of een Azure-regio

In zeldzame gevallen kan een fysiek datacenter tijdelijk niet meer beschikbaar zijn als er geen stroom of netwerkverbinding meer is. In dergelijke gevallen zijn uw Service Fabric en services in dat datacenter of de Azure-regio niet beschikbaar. Uw gegevens blijven echter behouden.

Voor clusters die worden uitgevoerd in Azure, kunt u updates over uitval bekijken op de azure-statuspagina. In het zeer onwaarschijnlijke geval dat een fysiek datacenter gedeeltelijk of volledig wordt vernietigd, gaan alle Service Fabric-clusters die daar worden gehost of de services erin verloren. Dit verlies omvat alle statussen die geen back-up maken buiten dat datacenter of die regio.

Er zijn verschillende strategieën voor het overleven van de permanente of langdurige storing van één datacenter of regio:

• Voer afzonderlijke Service Fabric in meerdere dergelijke regio's uit en gebruik een mechanisme voor failover en failback tussen deze omgevingen. Voor dit type actief/actief of actief/passief model met meerdere clusters is aanvullende beheer- en operationele code vereist. Dit model vereist ook coördinatie van back-ups van de services in het ene datacenter of de ene regio, zodat ze beschikbaar zijn in andere datacenters of regio's wanneer er een uitvalt.

• Voer één cluster Service Fabric meerdere datacenters uit. De minimaal ondersteunde configuratie voor deze strategie is drie datacenters. Zie Deploy a Service Fabric cluster across Beschikbaarheidszones (Een cluster Service Fabric implementeren in Beschikbaarheidszones.

  Voor dit model is aanvullende installatie vereist. Het voordeel is echter dat het uitvallen van één datacenter wordt geconverteerd van een noodlott naar een normale storing. Deze fouten kunnen worden afgehandeld door de mechanismen die werken voor clusters binnen één regio. Foutdomeinen, upgradedomeinen en Service Fabric zorgen ervoor dat workloads worden gedistribueerd zodat ze normale fouten tolereren.

  Zie Plaatsingsbeleid voor Service Fabric services voor meer informatie over beleidsregels die kunnen helpen bij het gebruik van services in Service Fabric cluster.

• Voer één cluster Service Fabric meerdere regio's uit met behulp van het zelfstandige model. Het aanbevolen aantal regio's is drie. Zie Een zelfstandig cluster maken voor meer informatie over zelfstandige Service Fabric installatie.

Willekeurige fouten die leiden tot clusterfouten

Service Fabric heeft het concept van seed-knooppunten. Dit zijn knooppunten die de beschikbaarheid van het onderliggende cluster behouden.

Seed-knooppunten helpen ervoor te zorgen dat het cluster up blijft door leases met andere knooppunten tot stand te brengen en als tiebreakers te dienen tijdens bepaalde soorten fouten. Als willekeurige fouten een meerderheid van de seed-knooppunten in het cluster verwijderen en ze niet snel worden terug gebracht, wordt uw cluster automatisch afgesloten. Het cluster mislukt vervolgens.

In Azure beheert Service Fabric resourceprovider Service Fabric clusterconfiguraties. Standaard distribueert Resource Provider seed-knooppunten over fout- en upgradedomeinen voor het primaire knooppunttype. Als het primaire knooppunttype is gemarkeerd als Silver- of Gold-duurzaamheid, probeert het cluster een ander niet-seed-knooppunt te promoveren van de beschikbare capaciteit van het primaire knooppunttype wanneer u een seed-knooppunt verwijdert (door het primaire knooppunttype in te schalen of handmatig te verwijderen). Deze poging mislukt als u minder beschikbare capaciteit hebt dan het betrouwbaarheidsniveau van uw cluster vereist voor uw primaire knooppunttype.

In beide zelfstandige Service Fabric clusters en Azure is het primaire knooppunttype het knooppunttype dat de vruchten voert. Wanneer u een primair knooppunttype definieert, profiteert Service Fabric automatisch van het aantal knooppunten dat wordt geboden door maximaal negen seed-knooppunten en zeven replica's van elke systeemservice te maken. Als bij een reeks willekeurige fouten een meerderheid van deze replica's tegelijkertijd wordt uitgenomen, zullen de systeemservices quorumverlies veroorzaken. Als een meerderheid van de seed-knooppunten verloren gaat, wordt het cluster kort daarna afgesloten.

Volgende stappen

• Leer hoe u verschillende fouten simuleert met behulp van het testabiliteitsraamwerk.
• Lees andere resources voor herstel na noodherstel en hoge beschikbaarheid. Microsoft heeft een groot aantal richtlijnen voor deze onderwerpen gepubliceerd. Hoewel sommige van deze resources verwijzen naar specifieke technieken voor gebruik in andere producten, bevatten ze veel algemene best practices die u kunt toepassen in Service Fabric context:
  • Controlelijst voor beschikbaarheid
  • Een noodhersteloefening uitvoeren
  • Herstel na noodgevallen en hoge beschikbaarheid voor Azure-toepassingen
• Meer informatie over Service Fabric ondersteuningsopties.