Share via

Failover en toepassing van een patch voor Azure Cache voor Redis

  • Artikel

Om tolerante en succesvolle clienttoepassingen te bouwen, is het essentieel om inzicht te hebben 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. Er wordt vaak gebruikgemaakt van cachefailover wanneer de beheerservice de binaire Azure Cache voor Redis patches uitvoert.

In dit artikel vindt u deze informatie:

  • Wat is een failover?
  • Hoe failover optreedt tijdens het patchen.
  • Een tolerante clienttoepassing bouwen.

Wat is een failover?

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

Een beknopt overzicht van cachearchitectuur

Een cache is samengesteld uit meerdere virtuele machines met afzonderlijke en privé-IP-adressen. Elke virtuele machine, ook wel een knooppunt genoemd, is verbonden met een gedeelde load balancer met éé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 of replicaknooppunt. Wanneer een clienttoepassing verbinding maakt met een cache, wordt het verkeer via deze load balancer geleid en automatisch doorgestuurd naar het primaire knooppunt.

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

Notitie

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

Uitleg van een failover

Een failover treedt op wanneer een replicaknooppunt zichzelf bevordert om een primair knooppunt te worden en het oude primaire knooppunt bestaande verbindingen sluit. Nadat het primaire knooppunt is teruggekomen, ziet het de wijziging in rollen en wordt zichzelf gedegradeert om een replica te worden. Vervolgens wordt er verbinding gemaakt met de nieuwe primaire en worden gegevens gesynchroniseerd. Een failover kan gepland of ongepland zijn.

Er vindt een geplande failover plaats gedurende twee verschillende tijden:

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

Omdat de knooppunten voorafgaande kennisgeving van de update ontvangen, kunnen ze samen rollen wisselen en de load balancer van de wijziging snel bijwerken. Een geplande failover wordt doorgaans binnen 1 seconde voltooid.

Een niet-geplande failover kan optreden vanwege hardwarefouten, netwerkfouten of andere onverwachte storingen naar het primaire knooppunt. Het replicaknooppunt bevordert zichzelf tot primair, maar het proces duurt langer. Een replicaknooppunt moet eerst detecteren dat het primaire knooppunt niet beschikbaar is voordat het failoverproces kan worden gestart. Het replicaknooppunt 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 voltooid.

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 voor een cache wilt uitvoeren, voert de service de volgende stappen uit:

  1. De service patcht eerst het replicaknooppunt.
  2. De gepatchte replica bevordert zichzelf gezamenlijk tot primair. Deze promotie wordt beschouwd als een geplande failover.
  3. Het voormalige primaire knooppunt wordt opnieuw opgestart om de nieuwe wijzigingen te maken en wordt als een replicaknooppunt weergegeven.
  4. Het replicaknooppunt 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, bevordert het replicaknooppunt zichzelf snel om een primaire te worden. Vervolgens begint het knooppunt met serviceaanvragen en nieuwe verbindingen. Basiscaches hebben geen replicaknooppunt en zijn pas beschikbaar als 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 hebben gegevensverlies. Geclusterde caches worden één shard tegelijk gepatcht.

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

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

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 zekere belastingstoename in zowel servergeheugen als CPU. Als het cache-exemplaar al zwaar is geladen, kunnen clienttoepassingen een verhoogde latentie ervaren. In extreme gevallen ontvangen clienttoepassingen mogelijk time-outuitzondering. Om het effect van meer belasting te beperken, configureert u de instelling van maxmemory-reserved de cache.

Wat is de invloed van een failover op mijn clienttoepassing?

Clienttoepassingen kunnen enkele fouten ontvangen van hun Azure Cache voor Redis. Het aantal fouten dat door een clienttoepassing wordt gezien, is afhankelijk van het aantal bewerkingen dat in behandeling was op die verbinding op het moment van failover. Elke verbinding die wordt gerouteerd via het knooppunt dat de verbindingen heeft gesloten, ziet fouten.

Veel clientbibliotheken kunnen verschillende typen fouten veroorzaken wanneer verbindingen worden verbroken, waaronder:

  • Time-outuitzondering
  • uitzonderingen voor Verbinding maken ion
  • Socket-uitzonderingen

Het aantal en het type uitzonderingen is afhankelijk van waar de aanvraag zich in het codepad bevindt wanneer de cache de verbindingen sluit. Een bewerking die bijvoorbeeld een aanvraag verzendt, maar geen antwoord heeft ontvangen wanneer de failover optreedt, kan een time-outuitzondering krijgen. Nieuwe aanvragen voor het gesloten verbindingsobject ontvangen verbindingsonderzondering totdat de nieuwe verbinding tot stand is gebracht.

De meeste clientbibliotheken proberen opnieuw verbinding te maken met de cache als ze hiervoor zijn geconfigureerd. Onvoorziene fouten kunnen de bibliotheekobjecten echter af en toe in een onherstelbare status plaatsen. Als fouten langer dan een vooraf geconfigureerde 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 ForceReconnect-patroon.

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

Azure Cache voor Redis publiceert runtime-onderhoudsmeldingen op een publicatie-/abonneren-kanaal (pub/sub) met de naam AzureRedisEvents. Veel populaire Redis-clientbibliotheken ondersteunen abonneren op pub-/subkanalen. Het ontvangen van meldingen van het AzureRedisEvents kanaal is meestal een eenvoudige toevoeging aan uw clienttoepassing. Zie AzureRedisEvents voor meer informatie over onderhoudsevenementen.

Notitie

Het AzureRedisEvents kanaal is geen mechanisme waarmee u dagen of uren van tevoren op de hoogte kunt stellen. Het kanaal kan clients op de hoogte stellen van toekomstige onderhoudsactiviteiten van servers die van invloed kunnen zijn op de beschikbaarheid van de server. AzureRedisEvents is alleen beschikbaar voor Basic-, Standard- en Premium-lagen.

Wat zijn de updates die onder onderhoud zijn opgenomen?

Onderhoud omvat deze updates:

  • Redis Server-updates: elke update of patch van de binaire Redis-serverbestanden.
  • Updates voor virtuele machines (VM's): alle updates van de virtuele machine die als host fungeert voor de Redis-service. VM-updates omvatten het patchen van softwareonderdelen in de hostingomgeving om netwerkonderdelen te upgraden of uit bedrijf te nemen.

Wordt onderhoud weergegeven in de servicestatus in Azure Portal vóór een patch?

Nee, onderhoud wordt nergens onder de servicestatus in de portal of op een andere plaats weergegeven.

Hoeveel tijd kan ik de melding ontvangen vóór het geplande onderhoud?

Wanneer u het AzureRedisEvents kanaal gebruikt, ontvangt u 15 minuten vóór het onderhoud een melding.

Wijzigingen in clientnetwerkconfiguratie

Bepaalde wijzigingen aan de netwerkconfiguratie aan de clientzijde kunnen geen verbindingsfouten veroorzaken. Dergelijke wijzigingen kunnen het volgende omvatten:

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

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

Bouwen in tolerantie

U kunt failovers niet volledig vermijden. Schrijf in plaats daarvan uw clienttoepassingen om bestand te zijn tegen verbindingseinden en mislukte aanvragen. De meeste clientbibliotheken maken automatisch opnieuw verbinding met het cache-eindpunt, maar weinigen proberen mislukte aanvragen opnieuw uit te voeren. Afhankelijk van het toepassingsscenario kan het zinvol zijn om logica voor opnieuw proberen te gebruiken met uitstel.

Hoe kan ik mijn toepassing tolerant maken?

Raadpleeg deze ontwerppatronen om tolerante clients te bouwen, met name de circuitonderbreker en patronen voor opnieuw proberen:

Als u de tolerantie van een clienttoepassing wilt testen, gebruikt u opnieuw opstarten als handmatige trigger voor verbindingseinden.

Daarnaast raden we u aan geplande updates te gebruiken om een updatekanaal en een onderhoudsvenster voor uw cache te kiezen om Redis-runtimepatches toe te passen tijdens specifieke wekelijkse vensters. Deze vensters zijn meestal perioden waarin verkeer van clienttoepassingen laag is, om potentiële incidenten te voorkomen. Zie Updatekanaal en Updates plannen voor meer informatie.

Zie Verbinding maken ietolerantie voor meer informatie.

Gerelateerde inhoud