Herstel na noodgeval in Azure Service Fabric

  • Artikel

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

In dit artikel worden enkele veelvoorkomende foutmodi beschreven die noodgevallen kunnen zijn als ze niet correct worden gemodelleerd en beheerd. Ook worden oplossingen en acties besproken die moeten worden ondernomen als zich toch een noodgeval voordoet. Het doel is om het risico van downtime of gegevensverlies te beperken of te elimineren wanneer er al dan niet geplande fouten optreden.

Noodgeval voorkomen

Het belangrijkste doel van Azure Service Fabric is om u te helpen bij het modelleren van zowel uw omgeving als uw services op een zodanige manier dat veelvoorkomende fouttypen geen rampen zijn.

Over het algemeen zijn er twee soorten scenario's voor noodgevallen/fouten:

  • 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 kopieën van de service over hardware- of softwarefoutgrenzen heen.

Als uw service bijvoorbeeld op slechts één computer wordt uitgevoerd, is de storing van die ene machine een noodgeval voor die service. De eenvoudige manier om dit noodgeval 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 actieve service niet verstoort. Capaciteitsplanning zorgt ervoor dat ergens anders een vervangend exemplaar kan worden gemaakt en dat capaciteitsvermindering de resterende services niet overbelast.

Hetzelfde patroon werkt, ongeacht wat u probeert te voorkomen. Als u zich bijvoorbeeld zorgen maakt over het mislukken van een SAN, voert u meerdere SAN's uit. Als u zich zorgen maakt over het verlies van een rek met servers, voert u meerdere rekken uit. 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 is verdeeld over meerdere fysieke exemplaren (machines, rekken, datacenters, regio's), hebt u nog steeds te maken met bepaalde soorten gelijktijdige fouten. Maar enkele en zelfs meerdere fouten van een bepaald type (bijvoorbeeld één virtuele machine of netwerkkoppeling mislukt) worden automatisch verwerkt en zijn dus geen 'noodgeval' meer.

Service Fabric biedt mechanismen voor het uitbreiden van het cluster en verwerkt het terugbrengen van mislukte knooppunten en services. Met Service Fabric kunnen ook veel exemplaren van uw services worden uitgevoerd om te voorkomen dat ongeplande fouten in echte rampen worden omgezet.

Er kunnen redenen zijn waarom het niet haalbaar is om een implementatie uit te voeren die groot genoeg is om fouten te overspannen. Het kan bijvoorbeeld meer hardwareresources kosten dan u bereid bent te betalen in verhouding tot de kans op fouten. Wanneer u te maken hebt met gedistribueerde toepassingen, kunnen extra communicatiehops of kosten voor statusreplicatie over geografische afstanden leiden tot onaanvaardbare latentie. Waar deze lijn wordt getekend, verschilt per toepassing.

Specifiek voor softwarefouten kan de fout zich voordoen in de service die u wilt schalen. In dit geval voorkomen meer kopieën het noodgeval niet, omdat de foutvoorwaarde is gecorreleerd voor alle exemplaren.

Operationele fouten

Zelfs als uw service over de hele wereld wordt verspreid met veel redundanties, kan deze nog steeds rampzalige gebeurtenissen ervaren. Iemand kan bijvoorbeeld per ongeluk de DNS-naam voor de service opnieuw configureren of deze volledig verwijderen.

Stel dat u een stateful Service Fabric-service hebt en dat 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 dit soort operationele rampen ('oeps') 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 operationele toegang tot de omgeving.
  • Controleer strikt gevaarlijke bewerkingen.
  • Dwing automatisering op, voorkom handmatige of out-of-bandwijzigingen en valideer specifieke wijzigingen voor de omgeving voordat u ze uitvoert.
  • Zorg ervoor dat destructieve bewerkingen 'zacht' 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 op rollen gebaseerd toegangsbeheer voor clusterbewerkingen. De meeste van deze operationele fouten vereisen echter organisatorische inspanningen en andere systemen. 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 als u bepaalde soorten fouten wilt afhandelen, moeten services aanvullende code hebben. Andere soorten fouten mogen niet automatisch worden aangepakt vanwege veiligheids- en bedrijfscontinuïteitsredenen.

Enkele fouten verwerken

Afzonderlijke machines kunnen om allerlei redenen uitvallen. Soms zijn het hardware-oorzaken, zoals voedingen en netwerkhardwarefouten. Andere fouten zijn in software. Deze omvatten fouten van het besturingssysteem en de service zelf. Service Fabric detecteert automatisch dit soort fouten, inclusief gevallen waarin de machine wordt geïsoleerd van andere machines 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 welke reden dan ook mislukt.

Als u één fout wilt afhandelen, kunt u er het eenvoudigst voor zorgen dat uw services standaard op meer dan één knooppunt worden uitgevoerd. Zorg ervoor dat InstanceCount voor staatloze services groter is dan 1. Voor stateful services is de minimale aanbeveling dat TargetReplicaSetSize en MinReplicaSetSize beide zijn ingesteld op 3. Als u meer kopieën van uw servicecode uitvoert, zorgt u ervoor dat uw service elke fout automatisch kan verwerken.

Gecoördineerde fouten verwerken

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

Service Fabric houdt standaard rekening met fout- en upgradedomeinen bij het plannen waar uw services moeten worden uitgevoerd. Service Fabric probeert er standaard voor te zorgen dat uw services worden uitgevoerd in verschillende fout- en upgradedomeinen, zodat uw services beschikbaar blijven als er geplande of niet-geplande wijzigingen plaatsvinden.

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

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

Upgradedomeinen zijn handig voor het modelleren van gebieden waar software tegelijkertijd wordt bijgewerkt. Daarom definiëren upgradedomeinen vaak ook de grenzen waar software wordt verwijderd 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 dat helpt voorkomen dat onbedoelde wijzigingen van invloed zijn op het cluster en uw service:

U kunt de indeling van uw cluster visualiseren met behulp van de clustertoewijzing in Service Fabric Explorer:

Knooppunten verspreid over foutdomeinen in Service Fabric Explorer

Notitie

Het modelleren van foutgebieden, rolling upgrades, het uitvoeren van veel exemplaren van uw servicecode en status, plaatsingsregels om ervoor te zorgen dat uw services worden uitgevoerd in fout- en upgradedomeinen, en ingebouwde statusbewaking zijn slechts enkele van de functies die Service Fabric biedt om te voorkomen dat normale operationele problemen en fouten in noodgevallen worden omgezet.

Gelijktijdige hardware- of softwarefouten verwerken

We hebben het gehad over individuele fouten. Zoals u ziet, zijn ze eenvoudig te verwerken voor zowel staatloze als stateful services door meer kopieën van de code (en status) te bewaren die worden uitgevoerd in fout- en upgradedomeinen.

Meerdere gelijktijdige willekeurige fouten kunnen ook optreden. De kans is groter dat deze leiden tot downtime of een werkelijke ramp.

Stateless services

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

Stel dat de staatloze service de InstanceCount waarde -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 wordt geprobeerd 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.)

Herstel na een storing van een 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 actieve secundaire databases). Als een meerderheid van de replica's de gegevens ontvangt, worden gegevens beschouwd als quorum vastgelegd. (Voor vijf replica's zijn er 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, wordt gegarandeerd dat ten minste één replica volledige gegevens bevat.)

Wanneer een quorum van replica's mislukt, wordt de partitie gedeclareerd als een quorumverliesstatus . 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, kan 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 schrijfbewerkingen naar de partitie te voorkomen, quorumverlies te declareren en te wachten tot een quorum van replica's is hersteld.

Bepalen of er een noodgeval is opgetreden voor een stateful service en vervolgens het beheer ervan volgt drie fasen:

  1. Bepalen of er quorumverlies is geweest of niet.

    Quorumverlies wordt gedeclareerd wanneer een meerderheid van de replica's van een stateful service op hetzelfde moment niet beschikbaar is.

  2. Bepalen of het quorumverlies permanent is of niet.

    Meestal zijn fouten tijdelijk. Processen worden opnieuw opgestart, knooppunten worden opnieuw opgestart, virtuele machines worden opnieuw gestart en netwerkpartities worden hersteld. Soms zijn fouten echter permanent. Of fouten permanent zijn of niet, is afhankelijk van het feit of de stateful service de status behoudt of dat deze alleen in het geheugen wordt bewaard:

    • Voor services zonder persistente status leidt een storing van een quorum of meer replica's onmiddellijk tot permanent quorumverlies. Wanneer Service Fabric quorumverlies detecteert in een stateful niet-permanente service, gaat het onmiddellijk verder met stap 3 door (mogelijk) gegevensverlies te declareren. Het is logisch om door te gaan met gegevensverlies, omdat Service Fabric weet dat het geen zin heeft om te wachten totdat de replica's terugkomen. 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 moet wachten totdat de replica's terugkomen en het quorum herstellen. Dit resulteert in een servicestoring voor schrijfbewerkingen naar de betreffende partitie (of replicaset) van de service. Leesbewerkingen kunnen echter nog steeds mogelijk zijn met beperkte consistentiegaranties. De standaardtijd die Service Fabric wacht totdat het quorum is hersteld, is oneindig, omdat doorgaan een (mogelijk) gegevensverliesgebeurtenis is en andere risico's met zich meebrengt. Dit betekent dat Service Fabric niet doorgaat met de volgende stap, tenzij een beheerder actie onderneemt om gegevensverlies te declareren.

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

    Als quorumverlies is gedeclareerd (automatisch of via administratieve actie), gaan Service Fabric en de services verder met het bepalen of gegevens daadwerkelijk verloren zijn gegaan. Op dit moment weet Service Fabric ook dat de andere replica's niet terugkomen. Dat was de beslissing die is genomen toen we stopten met wachten totdat het quorumverlies vanzelf werd opgelost. De beste aanpak voor de service is meestal om te blokkeren en te wachten op specifieke administratieve interventie.

    Wanneer Service Fabric de OnDataLossAsync methode aanroept, is dit altijd het gevolg van vermoedelijk gegevensverlies. Service Fabric zorgt ervoor dat deze aanroep wordt geleverd aan de best resterende replica. Dit is de replica die de meeste vooruitgang heeft geboekt.

    De reden waarom we altijd zeggen dat er sprake is van vermoedelijk gegevensverlies, is dat het mogelijk is dat de resterende replica dezelfde status heeft als de primaire replica toen het quorum verloren ging. Zonder die status om deze mee te vergelijken, is er echter geen goede manier voor Service Fabric of operators om dit zeker te weten.

    Wat doet een typische implementatie van de OnDataLossAsync methode?

    1. De implementatielogboeken die OnDataLossAsync zijn geactiveerd en alle benodigde beheerderswaarschuwingen worden geactiveerd.

    2. Meestal wordt de implementatie onderbroken en wordt gewacht op verdere beslissingen en handmatige acties die moeten worden genomen. Dit komt omdat zelfs als er back-ups beschikbaar zijn, deze mogelijk moeten worden voorbereid.

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

    3. Vaak is er een andere telemetrie of uitlaat 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 locatie die niet aanwezig waren in de back-up of die zijn gerepliceerd naar deze specifieke replica. Deze aanroepen moeten mogelijk opnieuw worden afgespeeld of toegevoegd aan de back-up voordat herstel mogelijk is.

    4. De implementatie vergelijkt de status van de resterende replica met de status in alle beschikbare back-ups. Als u betrouwbare Service Fabric-verzamelingen 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 de back-up mogelijk mist.

    5. Nadat de vergelijking is voltooid en nadat het herstel is voltooid (indien nodig), moet de servicecode true retourneren als er statuswijzigingen zijn aangebracht. Als de replica heeft vastgesteld dat dit de beste beschikbare kopie van de status is 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 verwijderd en opnieuw opgebouwd op basis van deze replica. 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 in de praktijk uitvoeren voordat services in productie worden geïmplementeerd. Ter bescherming tegen de mogelijkheid van gegevensverlies, is het belangrijk om periodiek een back-up te maken van de status van een 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 nummer genereert en opslaat en het vervolgens verzendt naar een andere service waarin het nummer ook wordt opgeslagen. Na een herstelbewerking ontdekt u mogelijk dat de tweede service het nummer heeft, maar de eerste niet, omdat de back-up die bewerking niet bevat.

Als u ontdekt dat de resterende replica's onvoldoende zijn om door te gaan in een scenario met gegevensverlies en u de servicestatus 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 waarvoor herstel vanuit een back-up is vereist. Deze scenario's zijn opgenomen als onderdeel van de hulpprogramma's voor testbaarheid in Service Fabric, die worden beheerd door de Foutanalyseservice. Zie Inleiding tot de foutanalyseservice voor meer informatie over deze hulpprogramma's en patronen.

Notitie

Systeemservices kunnen ook quorumverlies ondervinden. De impact is specifiek voor de betreffende service. Quorumverlies in de naamgevingsservice is bijvoorbeeld van invloed op naamomzetting, terwijl quorumverlies in de Failover Manager-service het maken van nieuwe services en failovers blokkeert.

De Service Fabric-systeemservices volgen hetzelfde patroon als uw services voor statusbeheer, maar we raden u niet aan ze te verplaatsen van quorumverlies naar mogelijk gegevensverlies. In plaats daarvan raden we u aan ondersteuning te zoeken om een oplossing te vinden die is afgestemd op uw situatie. Het is meestal beter om gewoon te wachten totdat de down replica's terugkeren.

Problemen met quorumverlies oplossen

Replica's kunnen af en toe offline zijn vanwege een tijdelijke fout. Wacht even terwijl Service Fabric deze probeert weer te geven. Als replica's langer dan verwacht niet beschikbaar zijn geweest, volgt u deze probleemoplossingsacties:

  • Replica's kunnen vastlopen. Controleer statusrapporten op replicaniveau en uw toepassingslogboeken. Verzamel crashdumps en onderneem de benodigde acties 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 vervangingsproces en probeert de replica terug te brengen.
  • Knooppunten waarop de replica's worden gehost, zijn mogelijk niet beschikbaar. Start de onderliggende virtuele machine opnieuw op om de knooppunten omhoog te brengen.

Soms is het niet mogelijk om replica's te herstellen. De stations zijn bijvoorbeeld mislukt of de machines reageren fysiek niet. In deze gevallen moet Service Fabric worden verteld niet te wachten op herstel van replica's.

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.

Notitie

Het is nooit veilig om deze methoden te gebruiken, behalve op een gerichte manier tegen specifieke partities.

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

Beschikbaarheid van het Service Fabric-cluster

Over het algemeen is het Service Fabric-cluster een sterk 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 dus dat ze standaard altijd worden uitgevoerd met drie of meer replica's en systeemservices die stateless zijn, worden uitgevoerd op alle knooppunten.

De onderliggende Service Fabric-netwerk- 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 te zitten, zoals eerder beschreven. In dergelijke gevallen kunt u bepaalde bewerkingen op het cluster mogelijk niet uitvoeren (zoals het starten van een upgrade of het implementeren van nieuwe services), maar het cluster zelf is nog steeds actief.

Services in een actief cluster blijven actief in deze omstandigheden, tenzij schrijfbewerkingen naar de systeemservices zijn vereist om te kunnen blijven werken. Als failoverbeheer bijvoorbeeld quorumverlies heeft, blijven alle services actief. Maar services die mislukken, kunnen niet automatisch opnieuw worden opgestart, omdat hiervoor failoverbeheer nodig is.

Fouten van een datacenter of een Azure-regio

In zeldzame gevallen kan een fysiek datacenter tijdelijk niet meer beschikbaar zijn vanwege stroomverlies of netwerkconnectiviteit. In deze gevallen zijn uw Service Fabric-clusters en -services in dat datacenter of die Azure-regio niet beschikbaar. Uw gegevens blijven echter behouden.

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

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

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

  • Voer één Service Fabric-cluster uit dat meerdere datacenters omvat. De minimaal ondersteunde configuratie voor deze strategie is drie datacenters. Zie Een Service Fabric-cluster implementeren in Beschikbaarheidszones voor meer informatie.

    Voor dit model is aanvullende installatie vereist. Het voordeel is echter dat een storing van één datacenter wordt omgezet van een noodgeval in een normale storing. Deze fouten kunnen worden afgehandeld door de mechanismen die werken voor clusters binnen één regio. Foutdomeinen, upgradedomeinen en Service Fabric-plaatsingsregels 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 uitvoeren van services in dit type cluster.

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

Willekeurige fouten die leiden tot clusterfouten

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

Seed-knooppunten helpen ervoor te zorgen dat het cluster actief blijft door leases tot stand te brengen met andere knooppunten en als tiebreakers te fungeren tijdens bepaalde soorten fouten. Als met willekeurige fouten het merendeel van de seed-knooppunten in het cluster wordt verwijderd en deze niet snel worden teruggezet, wordt uw cluster automatisch afgesloten. Het cluster mislukt dan.

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

In zowel zelfstandige Service Fabric-clusters als Azure is het primaire knooppunttype het type dat de seeds uitvoert. Wanneer u een primair knooppunttype definieert, profiteert Service Fabric automatisch van het aantal knooppunten dat wordt geleverd door maximaal negen seed-knooppunten en zeven replica's van elke systeemservice te maken. Als een set willekeurige fouten een meerderheid van deze replica's tegelijkertijd opneemt, gaan de systeemservices quorumverlies in. Als het merendeel van de seed-knooppunten verloren gaat, wordt het cluster kort daarna afgesloten.

Volgende stappen