Passieve geo-replicatie configureren voor Premium Azure Cache voor Redis-exemplaren

  • Artikel

In dit artikel leert u hoe u passieve geo-replicatie configureert op een paar Azure Cache voor Redis exemplaren met behulp van Azure Portal.

Passieve geo-replicatie koppelt twee Premium-laag Azure Cache voor Redis exemplaren en maakt een actief-passieve gegevensreplicatierelatie. Actief-passief betekent dat er een paar caches, primaire en secundaire caches zijn waarop hun gegevens worden gesynchroniseerd. Maar u kunt slechts naar één kant van het paar schrijven, de primaire. De andere kant van het paar, de secundaire cache, is alleen-lezen.

Vergelijk actief-passief met actief-actief, waar u naar beide zijden van het paar kunt schrijven en deze wordt gesynchroniseerd met de andere kant.

Bij passieve geo-replicatie bevinden de cache-exemplaren zich meestal in verschillende Azure-regio's, maar dat is niet vereist. Het ene exemplaar fungeert als de primaire en de andere als secundaire instantie. De primaire verwerkt lees- en schrijfaanvragen en de primaire verwerkt wijzigingen in de secundaire.

Failover wordt niet automatisch uitgevoerd. Zie Een failover van geo-primaire naar geo-secundaire initiëren voor meer informatie over het gebruik van failover.

Notitie

Passieve geo-replicatie is ontworpen als een noodhersteloplossing.

Bereik van beschikbaarheid

Laag Basic, Standard Premium Enterprise, Enterprise Flash
Beschikbaar Nr. Ja Ja

Passieve geo-replicatie is alleen beschikbaar in de Premium-laag van Azure Cache voor Redis. De Enterprise- en Enterprise Flash-lagen bieden ook geo-replicatie, maar deze lagen maken gebruik van een geavanceerdere versie, ook wel actieve geo-replicatie genoemd.

Vereisten voor geo-replicatie

Als u geo-replicatie tussen twee caches wilt configureren, moet aan de volgende vereisten worden voldaan:

  • Beide caches zijn Caches in de Premium-laag .
  • Beide caches bevinden zich in hetzelfde Azure-abonnement.
  • De secundaire gekoppelde cache heeft dezelfde cachegrootte of een grotere cachegrootte dan de primaire gekoppelde cache. Als u geo-failover wilt gebruiken, moeten beide caches dezelfde grootte hebben.
  • Beide caches worden gemaakt en hebben een actieve status.
  • Beide caches voeren dezelfde versie van redis-server uit.

Notitie

Gegevensoverdracht tussen Azure-regio's wordt in rekening gebracht tegen de standaardbandbreedtetarieven.

Sommige functies worden niet ondersteund met geo-replicatie:

  • Zoneredundantie wordt niet ondersteund met geo-replicatie.
  • Persistentie wordt niet ondersteund met geo-replicatie.
  • Caches met meer dan één replica kunnen niet worden gerepliceerd.
  • Clustering wordt ondersteund als voor beide caches clustering is ingeschakeld en hetzelfde aantal shards is ingeschakeld.
  • Caches in hetzelfde virtuele netwerk (VNet) worden ondersteund.
  • Caches in verschillende VNets worden ondersteund met opmerkingen. Zie Kan ik geo-replicatie gebruiken met mijn caches in een VNet? voor meer informatie.

Nadat geo-replicatie is geconfigureerd, gelden de volgende beperkingen voor uw gekoppelde cachepaar:

  • De secundaire gekoppelde cache heeft het kenmerk Alleen-lezen. U kunt ermee lezen, maar u kunt er geen gegevens naar schrijven. Als u ervoor kiest om te lezen uit het geo-secundaire exemplaar wanneer er een volledige gegevenssynchronisatie plaatsvindt tussen de geo-primaire en de geo-secundaire instantie, genereert het geo-secundaire exemplaar fouten bij een Redis-bewerking, totdat de volledige gegevenssynchronisatie is voltooid. De fouten geven aan dat er een volledige gegevenssynchronisatie wordt uitgevoerd. De fouten worden ook gegenereerd wanneer geo-primaire of geo-secundaire gegevens worden bijgewerkt en bij sommige scenario's voor opnieuw opstarten. Toepassingen die van geo-secundaire gegevens lezen, moeten worden gebouwd om terug te vallen op de geo-primaire wanneer de geo-secundaire dergelijke fouten genereert.

  • Alle gegevens die zich in de secundaire gekoppelde cache bevinden voordat de koppeling werd toegevoegd, worden verwijderd. Als de geo-replicatie later wordt verwijderd, blijven de gerepliceerde gegevens echter in de secundaire gekoppelde cache.

  • U kunt beide caches niet schalen terwijl de caches zijn gekoppeld.

  • U kunt het aantal shards niet wijzigen als clustering is ingeschakeld voor de cache.

  • U kunt persistentie niet inschakelen voor beide caches.

  • U kunt exporteren vanuit een van beide caches.

  • U kunt niet importeren in de secundaire gekoppelde cache.

  • U kunt gekoppelde cache of de resourcegroep die deze bevat, niet verwijderen totdat u de caches ontkoppelt. Zie Waarom is de bewerking mislukt wanneer ik mijn gekoppelde cache heb verwijderd voor meer informatie?

  • Als de caches zich in verschillende regio's bevinden, zijn de kosten voor uitgaand verkeer van het netwerk van toepassing op de gegevens die worden verplaatst tussen regio's. Zie hoeveel kost het om mijn gegevens te repliceren in Azure-regio's voor meer informatie?

  • Failover wordt niet automatisch uitgevoerd. U moet de failover starten van de primaire naar de secundaire gekoppelde cache. Zie Een failover van geo-primaire naar geo-secundaire initiëren voor meer informatie over het gebruik van failover.

  • Privékoppelingen kunnen niet worden toegevoegd aan caches die al geo-gerepliceerd zijn. Een privékoppeling toevoegen aan een geo-gerepliceerde cache: 1. Ontkoppel de geo-replicatie. 2. Voeg een Private Link toe. 3. Ten slotte koppelt u de geo-replicatie opnieuw.

  1. Als u twee caches wilt koppelen voor geo-replicatie, selecteert u eerst Geo-replicatie in het resourcemenu van de cache die u wilt gebruiken als primaire gekoppelde cache. Selecteer vervolgens de koppeling Cachereplicatie toevoegen in het werkvenster.

    Screenshot showing the cache's Geo-replication menu.

  2. Selecteer de naam van de beoogde secundaire cache in de lijst Compatibele caches . Als uw secundaire cache niet wordt weergegeven in de lijst, controleert u of aan de vereisten voor geo-replicatie voor de secundaire cache wordt voldaan. Als u de caches per regio wilt filteren, selecteert u de regio in de kaart om alleen die caches weer te geven in de lijst Compatibele caches .

    Screenshot showing compatible caches for linking with geo-replication.

    U kunt het koppelingsproces ook starten of details over de secundaire cache bekijken met behulp van het contextmenu.

    Screenshot showing the Geo-replication context menu.

  3. Selecteer Koppeling om de twee caches te koppelen en het replicatieproces te starten.

    Screenshot showing how to link caches for geo-replication.

  4. U kunt de voortgang van het replicatieproces bekijken met behulp van geo-replicatie in het menu Resource.

    Screenshot showing the current Linking status.

    U kunt de koppelingsstatus ook weergeven met overzicht in het menu Resource voor zowel de primaire als de secundaire cache.

    Screenshot that highlights how to view the linking status for the primary and secondary caches.

    Zodra het replicatieproces is voltooid, verandert de inrichtingsstatus koppeling in Geslaagd.

    Screenshot showing cache linking status as Succeeded.

    De primaire gekoppelde cache blijft beschikbaar voor gebruik tijdens het koppelingsproces. De secundaire gekoppelde cache is pas beschikbaar als het koppelingsproces is voltooid.

Geo-primaire URL

Zodra de caches zijn gekoppeld, wordt er een URL gegenereerd voor elke cache die altijd verwijst naar de geo-primaire cache. Als een failover wordt gestart van de geo-primaire naar de geo-secundaire, blijft de URL hetzelfde en wordt de onderliggende DNS-record automatisch bijgewerkt zodat deze verwijst naar de nieuwe geo-primaire.

Screenshot showing four URLs created by adding geo-replication.

Er worden drie URL's weergegeven:

  • Geo-primaire URL is een proxy-URL met de indeling .<cachename>.geo.redis.cache.windows.net De URL verwijst altijd naar de cache in het geo-replicatiepaar is de huidige geo-primaire.
  • Huidige geo-primaire cache is het directe adres van de cache die momenteel de geo-primaire cache is. Het adres is redis.cache.windows.net niet geo.redis.cache.windows.net. Het adres dat in het veld wordt vermeld, wordt gewijzigd als er een failover wordt gestart.
  • Huidige geo-secundaire cache is het directe adres van de cache die momenteel de geo-secundaire cache is. Het adres is redis.cache.windows.net niet geo.redis.cache.windows.net. Het adres dat in het veld wordt vermeld, wordt gewijzigd als er een failover wordt gestart.

Een failover starten van geo-primair naar geo-secundair

Met één selectie kunt u een failover van de geo-primaire naar de geo-secundaire activeren.

Screenshot of linked caches with Failover highlighted.

Dit zorgt ervoor dat de volgende stappen worden uitgevoerd:

  1. De geo-secundaire cache wordt gepromoveerd naar geo-primair.
  2. DNS-records worden bijgewerkt om de geo-primaire URL's om te leiden naar de nieuwe geo-primaire.
  3. De oude geo-primaire cache wordt gedegradeerd naar secundaire cache en probeert een koppeling te maken naar de nieuwe geo-primaire cache.

Het duurt enkele minuten voordat het proces voor geo-failover is voltooid.

Instellingen om te controleren voordat geo-failover wordt gestart

Wanneer de failover wordt gestart, wisselen de geo-primaire en geo-secundaire caches om. Als de nieuwe geo-primaire locatie anders is geconfigureerd dan de geo-secundaire, kan dit problemen voor uw toepassing veroorzaken.

Controleer de volgende items:

  • Als u een firewall in een van beide caches gebruikt, moet u ervoor zorgen dat de firewallinstellingen vergelijkbaar zijn, zodat er geen verbindingsproblemen zijn.
  • Zorg ervoor dat beide caches dezelfde poort en TLS/SSL-instellingen gebruiken
  • De geo-primaire en geo-secundaire caches hebben verschillende toegangssleutels. Als een failover wordt geactiveerd, moet u ervoor zorgen dat uw toepassing de toegangssleutel kan bijwerken die wordt gebruikt om overeen te komen met de nieuwe geo-primaire. Of gebruik Microsoft Entra-tokens voor cacheverificatie, waarmee u dezelfde verificatiereferenties kunt gebruiken voor zowel de geo-primaire als de geo-secundaire cache.

Failover met minimaal gegevensverlies

Geo-failovergebeurtenissen kunnen tijdens de overgang leiden tot inconsistenties van gegevens, met name als de client een verbinding onderhoudt met de oude geo-primaire tijdens het failoverproces. Het is mogelijk om gegevensverlies in een geplande geo-failovergebeurtenis te minimaliseren met behulp van de volgende tips:

  • Controleer de metrische gegevenssynchronisatie van geo-replicatiegegevens. De metrische gegevens worden verzonden door de huidige geo-primaire cache. Deze metrische waarde geeft aan hoeveel gegevens nog moeten worden gerepliceerd naar de geo-primaire. Indien mogelijk start u alleen een failover als de metrische waarde aangeeft dat er minder dan 14 bytes moeten worden geschreven.
  • Voer de CLIENT PAUSE opdracht uit in de huidige geo-primaire voordat u een failover start. Als u nieuwe schrijfaanvragen uitvoertCLIENT PAUSE, worden in plaats daarvan time-outfouten aan de Azure Cache voor Redis-client geretourneerd. Voor de CLIENT PAUSE opdracht moet een time-outperiode in milliseconden worden opgegeven. Zorg ervoor dat er een lange time-outperiode is opgegeven om de failover mogelijk te maken. Het instellen van de pauzewaarde op ongeveer 30 minuten (1.800.000 milliseconden) is een goede plek om te beginnen. U kunt dit nummer altijd naar behoefte verlagen.

U hoeft de opdracht CLIENT UNPAUSE niet uit te voeren, omdat de nieuwe geo-primaire de client onderbreekt.

Notitie

Het gebruik van verificatie op basis van Microsoft Entra ID voor uw cache wordt aanbevolen in scenario's voor geo-failover, omdat hiermee de moeilijkheid wordt verwijderd om verschillende toegangssleutels voor de geo-primaire en de geo-secundaire cache te beheren.

  1. Als u de koppeling tussen twee caches wilt verwijderen en geo-replicatie wilt stoppen, selecteert u Caches ontkoppelen uit de geo-replicatie aan de linkerkant.

    Screenshot showing how to unlink caches.

    Wanneer het ontkoppelingsproces is voltooid, is de secundaire cache beschikbaar voor zowel lees- als schrijfbewerkingen.

Notitie

Wanneer de geo-replicatiekoppeling wordt verwijderd, blijven de gerepliceerde gegevens uit de primaire gekoppelde cache in de secundaire cache.

Veelgestelde vragen over geo-replicatie

Kan ik geo-replicatie gebruiken met een Standard- of Basic-laagcache?

Nee, passieve geo-replicatie is alleen beschikbaar in de Premium-laag. Een geavanceerdere versie van geo-replicatie met de naam actieve geo-replicatie is beschikbaar in de Enterprise- en Enterprise Flash-laag.

Is mijn cache beschikbaar voor gebruik tijdens het koppelings- of ontkoppelingsproces?

  • De primaire gekoppelde cache blijft beschikbaar totdat het koppelingsproces is voltooid.
  • De secundaire gekoppelde cache is pas beschikbaar als het koppelingsproces is voltooid.
  • Beide caches blijven beschikbaar totdat het ontkoppelingsproces is voltooid.

Wanneer kan ik schrijven naar de nieuwe geo-primaire na het initiëren van een failover?

Wanneer het failoverproces wordt gestart, ziet u de update van de inrichtingsstatus van de koppeling naar Verwijderen, wat aangeeft dat de vorige koppeling wordt opgeschoond. Nadat dit is voltooid, wordt de inrichtingsstatus bijgewerkt naar Maken. Dit geeft aan dat de nieuwe geo-primaire actief is en probeert een geo-replicatiekoppeling opnieuw tot stand te brengen naar de oude geo-primaire cache. Op dit moment kunt u direct verbinding maken met het nieuwe cache-exemplaar van geo-primaire cache voor zowel lees- als schrijfbewerkingen.

Ja, er zijn verschillende metrische gegevens beschikbaar om de status van de geo-replicatie bij te houden. Deze metrische gegevens zijn beschikbaar in Azure Portal.

  • Geo-replicatie in orde toont de status van de geo-replicatiekoppeling. De koppeling wordt weergegeven als beschadigd als de geo-primaire of geo-secundaire caches niet beschikbaar zijn. Dit wordt meestal veroorzaakt door standaardpatchingbewerkingen, maar dit kan ook duiden op een foutsituatie.
  • Geo-replicatie Verbinding maken iviteitsvertraging toont de tijd sinds de laatste geslaagde gegevenssynchronisatie tussen geo-primaire en geo-secundaire gegevens.
  • Verschuiving van geo-replicatiegegevenssynchronisatie toont de hoeveelheid gegevens die nog moet worden gesynchroniseerd met de geo-secundaire cache.
  • Geo Replication Fully Sync Event Started geeft aan dat er een volledige synchronisatieactie is gestart tussen de geo-primaire en geo-secundaire caches. Dit gebeurt als standaardreplicatie het aantal nieuwe schrijfbewerkingen niet kan bijhouden.
  • De gebeurtenis Volledige synchronisatie van geo-replicatie voltooid geeft aan dat een volledige synchronisatieactie is voltooid.

Er is ook een vooraf samengestelde werkmap met de naam geo-replicatiedashboard met alle metrische gegevens over geo-replicatiestatus in één weergave. Het gebruik van deze weergave wordt aanbevolen omdat hiermee informatie wordt samengevoegd die alleen wordt verzonden vanuit de instanties van de geo-primaire of geo-secundaire cache.

Nee, u kunt slechts twee caches aan elkaar koppelen wanneer u passieve geo-replicatie gebruikt. Actieve geo-replicatie ondersteunt maximaal vijf gekoppelde caches.

Nee, beide caches moeten zich in hetzelfde Azure-abonnement bevinden.

Ja, zolang de secundaire gekoppelde cache groter is dan de primaire gekoppelde cache. U kunt de failoverfunctie echter niet gebruiken als de caches verschillende grootten hebben.

Kan ik geo-replicatie gebruiken met clustering ingeschakeld?

Ja, zolang beide caches hetzelfde aantal shards hebben.

Kan ik geo-replicatie gebruiken met mijn caches in een VNet?

We raden u aan azure Private Link te gebruiken via VNet-injectie in de meeste gevallen. Zie migreren van VNet-injectiecaches naar Private Link-caches voor meer informatie.

Hoewel het technisch nog steeds mogelijk is om VNet-injectie te gebruiken bij het repliceren van uw caches, raden we Azure Private Link aan.

Belangrijk

Azure Cache voor Redis raadt u aan om Azure Private Link te gebruiken, wat de netwerkarchitectuur vereenvoudigt en de verbinding tussen eindpunten in Azure beveiligt. U kunt vanuit uw virtuele netwerk verbinding maken met een Azure Cache-exemplaar via een privé-eindpunt, waaraan een privé-IP-adres in een subnet binnen het virtuele netwerk is toegewezen. Azure Private Links worden aangeboden in alle lagen en bevatten Azure Policy-ondersteuning en vereenvoudigd beheer van NSG-regels. Zie de Private Link-documentatie voor meer informatie. Zie Caches met VNet-injectie migreren naar Private Link-caches om uw caches met VNet-injectie te migreren naar Private Link.

Zie Geo-replicatie met behulp van VNet-injectie met Premium-caches voor meer informatie over ondersteuning voor geo-replicatie met VNet's.

Wat is het replicatieschema voor geo-replicatie van Redis?

Replicatie is continu en asynchroon. Dit gebeurt niet volgens een specifiek schema. Alle schrijfbewerkingen die naar de primaire worden uitgevoerd, worden onmiddellijk en asynchroon gerepliceerd op de secundaire.

Hoe lang duurt geo-replicatiereplicatie?

Replicatie is incrementeel, asynchroon en continu en de tijd die nodig is, verschilt niet veel van de latentie tussen regio's. Onder bepaalde omstandigheden kan de secundaire cache vereist zijn om een volledige synchronisatie van de gegevens uit de primaire cache uit te voeren. De replicatietijd in dit geval is afhankelijk van veel factoren, zoals: belasting van de primaire cache, beschikbare netwerkbandbreedte en latentie tussen regio's. We hebben replicatietijd gevonden voor een volledig geo-gerepliceerd paar van 53 GB tussen 5 en 10 minuten. U kunt de hoeveelheid gegevens bijhouden die nog moeten worden gerepliceerd met behulp van de Geo Replication Data Sync Offset metrische gegevens in Azure Monitor.

Is het replicatieherstelpunt gegarandeerd?

Voor caches in een geo-gerepliceerde modus is persistentie uitgeschakeld. Als een geo-gerepliceerd paar niet is gekoppeld, zoals een door de klant geïnitieerde failover, bewaart de secundaire gekoppelde cache de gesynchroniseerde gegevens tot dat moment. In dergelijke situaties is er geen herstelpunt gegarandeerd.

Als u een herstelpunt wilt verkrijgen, exporteert u vanuit een van beide caches. U kunt later importeren in de primaire gekoppelde cache.

Kan ik PowerShell of Azure CLI gebruiken om geo-replicatie te beheren?

Ja, geo-replicatie kan worden beheerd met behulp van Azure Portal, PowerShell of Azure CLI. Zie de PowerShell-documenten of Azure CLI-documenten voor meer informatie.

Hoeveel kost het om mijn gegevens te repliceren in Azure-regio's?

Wanneer u geo-replicatie gebruikt, worden gegevens uit de primaire gekoppelde cache gerepliceerd naar de secundaire gekoppelde cache. Er worden geen kosten in rekening gebracht voor de gegevensoverdracht als de twee gekoppelde caches zich in dezelfde regio bevinden. Als de twee gekoppelde caches zich in verschillende regio's bevinden, zijn de kosten voor gegevensoverdracht het uitgaande netwerk van gegevens die in beide regio's worden verplaatst. Zie Prijsinformatie voor bandbreedte voor meer informatie.

Waarom is de bewerking mislukt wanneer ik probeerde mijn gekoppelde cache te verwijderen?

Geo-gerepliceerde caches en de bijbehorende resourcegroepen kunnen pas worden verwijderd wanneer u de geo-replicatiekoppeling verwijdert. Als u probeert de resourcegroep te verwijderen die een of beide gekoppelde caches bevat, worden de andere resources in de resourcegroep verwijderd, maar blijft de resourcegroep in de deleting status en blijven gekoppelde caches in de resourcegroep in de running status. Als u de resourcegroep en de gekoppelde caches erin volledig wilt verwijderen, ontkoppelt u de caches zoals beschreven in Een geo-replicatiekoppeling verwijderen.

Welke regio moet ik gebruiken voor mijn secundaire gekoppelde cache?

Over het algemeen raden we u aan om uw cache te laten bestaan in dezelfde Azure-regio als de toepassing die er toegang toe heeft. Voor toepassingen met afzonderlijke primaire en terugvalregio's raden we aan dat uw primaire en secundaire caches in dezelfde regio's aanwezig zijn. Zie Aanbevolen procedures : gekoppelde Azure-regio's voor meer informatie over gekoppelde regio's.

Kan ik een firewall configureren met geo-replicatie?

Ja, u kunt een firewall configureren met geo-replicatie. Als geo-replicatie naast een firewall werkt, moet u ervoor zorgen dat het IP-adres van de secundaire cache wordt toegevoegd aan de firewallregels van de primaire cache. Als openbare netwerktoegang echter is uitgeschakeld in de cache en alleen privé-eindpunt is ingeschakeld, wordt het gebruik van firewall in de cache niet ondersteund.

Volgende stappen

Meer informatie over Azure Cache voor Redis functies.