Failover en patching voor Azure Cache voor Redis

Als u robuuste en succesvolle clienttoepassingen wilt bouwen, is het essentieel om inzicht te krijgen in failover in de Azure Cache voor Redis service. Een failover kan deel uitmaken van geplande beheerbewerkingen of kan worden veroorzaakt door niet-geplande hardware- of netwerkfouten. Cache-failover wordt vaak gebruikt wanneer de beheerservice de Azure Cache voor Redis patcht.

In dit artikel vindt u deze informatie:

  • Wat is een failover?
  • Hoe failover plaatsvindt tijdens het patchen.
  • Een flexibele clienttoepassing bouwen.

Wat is een failover?

Laten we beginnen met een overzicht van failover voor Azure Cache voor Redis.

Een kort overzicht van de cachearchitectuur

Een cache is opgebouwd uit meerdere virtuele machines met afzonderlijke privé-IP-adressen. Elke virtuele machine, ook wel een knooppunt genoemd, is verbonden met een gedeelde load balancer één virtueel IP-adres. Elk knooppunt voert het Redis-serverproces uit en is toegankelijk met behulp van de hostnaam en de Redis-poorten. Elk knooppunt wordt beschouwd als een primair knooppunt of een replica-knooppunt. Wanneer een clienttoepassing verbinding maakt met een cache, gaat het verkeer via deze load balancer en wordt het automatisch doorgeleid naar het primaire knooppunt.

In een Basic-cache is het ene knooppunt altijd een primair knooppunt. In een Standard- of Premium-cache zijn er twee knooppunten: één knooppunt is de primaire cache en de andere de replica. Omdat Standard- en Premium-caches meerdere knooppunten hebben, is het ene knooppunt mogelijk niet beschikbaar terwijl het andere door blijft gaan met het verwerken van aanvragen. Geclusterde caches zijn gemaakt van veel shards, elk met afzonderlijke primaire knooppunten en replicaknooppunten. De ene shard is mogelijk niet beschikbaar terwijl de andere beschikbaar blijven.

Notitie

Een Basic-cache heeft niet meerdere knooppunten en biedt geen Service Level Agreement (SLA) voor de beschikbaarheid ervan. Basiscaches worden alleen aanbevolen voor ontwikkelings- en testdoeleinden. Gebruik een Standard- of Premium-cache voor een implementatie met meerdere knooppunt om de beschikbaarheid te vergroten.

Uitleg van een failover

Een failover treedt op wanneer een replica-knooppunt zichzelf promovert tot een primair knooppunt en het oude primaire knooppunt bestaande verbindingen sluit. Nadat het primaire knooppunt weer een back-up heeft gemaakt, ziet het de wijziging in rollen en degradeert het zichzelf tot een replica. Het maakt vervolgens verbinding met de nieuwe primaire en synchroniseert gegevens. Een failover kan gepland of ongepland zijn.

Een geplande failover vindt plaats op twee verschillende momenten:

  • Systeemupdates, zoals Redis-patching of upgrades van het besturingssysteem.
  • Beheerbewerkingen, zoals schalen en opnieuw opstarten.

Omdat de knooppunten vooraf van de update op de hoogte worden ontvangen, kunnen ze rollen wisselen en snel de load balancer van de wijziging bijwerken. Een geplande failover wordt doorgaans in minder dan 1 seconde voltooien.

Er kan een niet-geplande failover plaatsvinden vanwege hardwarestoringen, netwerkstoringen of andere onverwachte storingen naar het primaire knooppunt. Het replica-knooppunt promovert zichzelf naar het primaire knooppunt, maar het proces duurt langer. Een replica-knooppunt moet eerst detecteren dat het primaire knooppunt niet beschikbaar is voordat het failoverproces kan worden start. Het replica-knooppunt moet ook controleren of deze niet-geplande fout niet tijdelijk of lokaal is, om onnodige failover te voorkomen. Deze vertraging in de detectie betekent dat een niet-geplande failover doorgaans binnen 10 tot 15 seconden wordt voltooien.

Hoe vindt patching plaats?

De Azure Cache voor Redis-service werkt uw cache regelmatig bij met de nieuwste platformfuncties en oplossingen. Als u een patch wilt maken voor een cache, volgt de service deze stappen:

  1. De beheerservice selecteert één knooppunt dat moet worden gepatcht.
  2. Als het geselecteerde knooppunt een primair knooppunt is, promoveert het bijbehorende replica-knooppunt zichzelf. Deze promotie wordt beschouwd als een geplande failover.
  3. Het geselecteerde knooppunt wordt opnieuw opgestart om de nieuwe wijzigingen door te voeren en wordt weer als een replica-knooppunt gemaakt.
  4. Het replica-knooppunt maakt verbinding met het primaire knooppunt en synchroniseert gegevens.
  5. Wanneer de gegevenssynchronisatie is voltooid, wordt het patchproces herhaald voor de resterende knooppunten.

Omdat patching een geplande failover is, wordt het replica-knooppunt snel een primaire replica. Vervolgens start het knooppunt serviceaanvragen en nieuwe verbindingen. Basic-caches hebben geen replica-knooppunt en zijn niet beschikbaar totdat de update is voltooid. Elke shard van een geclusterde cache wordt afzonderlijk gepatcht en sluit geen verbindingen met een andere shard.

Belangrijk

Knooppunten worden één voor één gepatcht om gegevensverlies te voorkomen. Basiscaches verliezen gegevens. Geclusterde caches worden één shard tegelijk gepatcht.

Meerdere caches in dezelfde resourcegroep en regio worden ook één voor één gepatcht. Caches in verschillende resourcegroepen of verschillende regio's kunnen tegelijkertijd worden gepatcht.

Omdat volledige gegevenssynchronisatie wordt uitgevoerd voordat het proces wordt herhaald, is het onwaarschijnlijk dat gegevensverlies optreedt wanneer u een Standard- of Premium-cache gebruikt. U kunt u verder beschermen tegen gegevensverlies door gegevens te exporteren en persistentie in te stellen.

Extra cachebelasting

Wanneer er een failover plaatsvindt, moeten de Standard- en Premium-caches gegevens van het ene knooppunt naar het andere repliceren. Deze replicatie veroorzaakt een toename van de belasting in zowel het servergeheugen als de CPU. Als het cache-exemplaar al zwaar is geladen, kunnen clienttoepassingen een verhoogde latentie ervaren. In uitzonderlijke gevallen kunnen clienttoepassingen time-out-uitzonderingen ontvangen. Configureer de instelling van de cache om het effect van meer belasting te maxmemory-reserved beperken.

Wat is de invloed van een failover op mijn clienttoepassing?

Het aantal fouten dat door de clienttoepassing wordt gezien, is afhankelijk van het aantal bewerkingen dat op die verbinding in behandeling was op het moment van de failover. Elke verbinding die wordt doorgeleid via het knooppunt dat de verbindingen heeft gesloten, krijgt fouten te zien. Veel clientbibliotheken kunnen verschillende soorten fouten veroorzaken wanneer verbindingen worden storingen, waaronder time-out-uitzonderingen, verbindings-uitzonderingen of socket-uitzonderingen. Het aantal en het type uitzonderingen zijn afhankelijk van waar in het codepad de aanvraag is wanneer de cache de verbindingen sluit. Een bewerking die bijvoorbeeld een aanvraag verzendt, maar geen antwoord heeft ontvangen wanneer de failover plaatsvindt, kan een time-out-uitzondering krijgen. Nieuwe aanvragen op het gesloten verbindingsobject ontvangen verbindings-uitzonderingen totdat de nieuwe verbinding tot stand is brengen.

De meeste clientbibliotheken proberen opnieuw verbinding te maken met de cache als ze zijn geconfigureerd om dit te doen. Onvoorziene fouten kunnen de bibliotheekobjecten echter af en toe in een onherkenbare toestand plaatsen. Als fouten langer dan een vooraf geconfigureerde hoeveelheid tijd blijven bestaan, moet het verbindingsobject opnieuw worden gemaakt. In Microsoft.NET en andere objectgeoriënteerde talen kunt u de verbinding opnieuw maken zonder de toepassing opnieuw te starten met behulp van een <T> Lui-patroon.

Hoe kan ik mijn toepassing flexibel maken?

Omdat u failovers niet volledig kunt vermijden, schrijft u uw clienttoepassingen voor tolerantie voor verbindingsbreaks en mislukte aanvragen. Hoewel de meeste clientbibliotheken automatisch opnieuw verbinding maken met het cache-eindpunt, proberen slechts enkele ervan mislukte aanvragen opnieuw uit te proberen. Afhankelijk van het toepassingsscenario kan het zinvol zijn om logica voor opnieuw proberen te gebruiken met back-off.

Als u de tolerantie van een clienttoepassing wilt testen, gebruikt u opnieuw opstarten als een handmatige trigger voor verbindingsbreaks. Daarnaast raden we u aan om updates voor een cache te plannen. Laat de beheerservice redis-runtimepatches toepassen tijdens opgegeven wekelijkse vensters. Deze vensters zijn doorgaans perioden waarin het verkeer van clienttoepassing laag is, om mogelijke incidenten te voorkomen.

Kan ik van tevoren op de hoogte worden gesteld van gepland onderhoud?

Azure Cache voor Redis publiceert nu meldingen op een kanaal voor publiceren/abonneren met de naam AzureRedisEvents, ongeveer 30 seconden vóór geplande updates. De meldingen zijn runtimemeldingen. Ze zijn speciaal gebouwd voor toepassingen die circuit breakers kunnen gebruiken om de cache- of bufferopdrachten te omzeilen, bijvoorbeeld tijdens geplande updates. Het is geen mechanisme dat u dagen of uren van tevoren op de hoogte kan stellen.

Wijzigingen in clientnetwerkconfiguratie

Bepaalde wijzigingen in de netwerkconfiguratie aan de clientzijde kunnen leiden tot fouten met de fout 'Geen verbinding beschikbaar'. Deze wijzigingen kunnen onder andere het volgende omvatten:

  • Het virtuele IP-adres van een clienttoepassing wisselen tussen faserings- en productiesleuven.
  • De grootte of het aantal exemplaren van uw toepassing schalen.

Dergelijke wijzigingen kunnen een verbindingsprobleem veroorzaken dat minder dan één minuut duurt. Uw clienttoepassing verliest waarschijnlijk de verbinding met andere externe netwerkbronnen, maar ook met de Azure Cache voor Redis service.

Volgende stappen