Hoge beschikbaarheid en herstel na noodgevallen
Net als bij alle cloudsystemen kunnen niet-geplande storingen optreden, waardoor een VM-instantie (virtuele machine), een beschikbaarheidszone of een volledige Azure-regio uitvalt. We raden klanten aan een plan te hebben voor het afhandelen van zone- of regionale storingen.
Dit artikel bevat de informatie voor klanten om een plan voor bedrijfscontinuïteit en herstel na noodgevallen te maken voor hun Azure Cache voor Redis of Azure Cache voor Redis Enterprise-implementatie.
Er zijn verschillende opties voor hoge beschikbaarheid beschikbaar in de lagen Standard, Premium en Enterprise:
| Optie | Omschrijving | Beschikbaarheid | Standaard | Premium | Enterprise |
|---|---|---|---|---|---|
| Standaardreplicatie | Gerepliceerde configuratie met twee knooppunten in één datacenter met automatische failover | 99,9% (zie details) | ✔ | ✔ | ✔ |
| Zoneredundantie | Gerepliceerde configuratie met meerdere knooppunten in Beschikbaarheidszones, met automatische failover | 99,9% in Premium; 99,99% in Enterprise (zie details) | - | ✔ | ✔ |
| Geo-replicatie | Gekoppelde cache-exemplaren in twee regio's, met door de gebruiker beheerde failover | Premium; Onderneming (zie details) | - | Passieve | Actief |
| Import/export | Momentopname van gegevens in cache naar een bepaald tijdstip. | 99,9% (zie details) | - | ✔ | ✔ |
| Persistentie | Periodiek opslaan van gegevens in opslagaccount. | 99,9% (zie details) | - | ✔ | Preview |
Standaardreplicatie voor hoge beschikbaarheid
Toepasselijke lagen: Standard, Premium, Enterprise, Enterprise Flash
Aanbevolen voor: Hoge beschikbaarheid
Azure Cache voor Redis heeft een architectuur met hoge beschikbaarheid die ervoor zorgt dat uw beheerde exemplaar functioneert, zelfs wanneer storingen van invloed zijn op de onderliggende virtuele machines (VM's). Of de storing nu geplande of niet-geplande storingen is, Azure Cache voor Redis hogere beschikbaarheidspercentages levert dan wat kan worden bereikt door Redis op één VIRTUELE machine te hosten.
Een Azure Cache voor Redis in de toepasselijke lagen wordt standaard uitgevoerd op een paar Redis-servers. De twee servers worden gehost op toegewezen VM's. Met Opensource Redis kan slechts één server aanvragen voor het schrijven van gegevens verwerken.
Met Azure Cache voor Redis is de ene server het primaire knooppunt, terwijl de andere de replica is. Nadat de serverknooppunten zijn ingericht, Azure Cache voor Redis primaire en replicarollen aan hen toewijst. Het primaire knooppunt is meestal verantwoordelijk voor het onderhoud van schrijf- en leesaanvragen van clients. Bij een schrijfbewerking voert deze een nieuwe sleutel en een sleutelupdate door naar het interne geheugen en reageert deze onmiddellijk op de client. De bewerking wordt asynchroon doorgestuurd naar de replica .
Notitie
Normaal gesproken communiceert een Azure Cache voor Redis clienttoepassing met het primaire knooppunt in een cache voor alle lees- en schrijfaanvragen. Bepaalde clients kunnen worden geconfigureerd om te lezen vanuit het replicaknooppunt.
Als het primaire knooppunt in een cache niet beschikbaar is, bevordert de replica zichzelf automatisch om de nieuwe primaire te worden. Dit proces wordt een failover genoemd. Een failover is slechts twee knooppunten, primaire/replica, handelsrollen, replica/primair, waarbij een van de knooppunten mogelijk enkele minuten offline gaat. In de meeste failovers coördineren de primaire en replicaknooppunten de overdracht, zodat u bijna nul tijd hebt zonder een primaire.
De voormalige primaire versie gaat kort offline om updates van de nieuwe primaire te ontvangen. Vervolgens komt de replica nu weer online en wordt de cache volledig gesynchroniseerd. De sleutel is dat wanneer een knooppunt niet beschikbaar is, het een tijdelijke voorwaarde is en het weer online komt.
Een typische failoverreeks ziet er als volgt uit wanneer een primaire service moet worden uitgeschakeld voor onderhoud:
- Primaire en replicaknooppunten onderhandelen over een gecoördineerde failover en handelsrollen.
- Replica (voorheen primair) gaat offline voor opnieuw opstarten.
- Een paar seconden of minuten later komt de replica weer online.
- Replica synchroniseert de gegevens van de primaire.
Een primair knooppunt kan uit de service gaan als onderdeel van een geplande onderhoudsactiviteit, zoals een update naar Redis-software of het besturingssysteem. Het kan ook stoppen met werken vanwege niet-geplande gebeurtenissen, zoals storingen in onderliggende hardware, software of netwerk. Failover en patching voor Azure Cache voor Redis biedt een gedetailleerde uitleg over typen failovers. Een Azure Cache voor Redis doorloopt veel failovers tijdens de levensduur. Het ontwerp van de architectuur voor hoge beschikbaarheid maakt deze wijzigingen in een cache zo transparant mogelijk voor de clients.
Azure Cache voor Redis biedt ook meer replicaknooppunten in de Premium-laag. Een cache met meerdere replica's kan worden geconfigureerd met maximaal drie replicaknooppunten. Als u meer replica's hebt, wordt de tolerantie over het algemeen verbeterd, omdat u knooppunten hebt die een back-up maken van de primaire. Zelfs met meer replica's kan een Azure Cache voor Redis exemplaar nog steeds ernstig worden beïnvloed door een storing in een datacenter of beschikbaarheidszone. U kunt de beschikbaarheid van de cache verhogen met behulp van meerdere replica's met zoneredundantie.
Zoneredundantie
Toepasselijke lagen: Premium, Enterprise, Enterprise Flash
Aanbevolen voor: hoge beschikbaarheid, herstel na noodgevallen - intraregio
Azure Cache voor Redis ondersteunt zone-redundante configuraties in de Premium- en Enterprise-lagen. Een zoneredundante cache kan de knooppunten in verschillende Azure-Beschikbaarheidszones in dezelfde regio plaatsen. Het elimineert datacentrum- of AZ-storingen als single point of failure en verhoogt de algehele beschikbaarheid van uw cache. Zie dit artikel voor informatie over het instellen ervan.
Als een cache is geconfigureerd voor het gebruik van twee of meer zones, zoals eerder beschreven in het artikel, worden de cacheknooppunten in verschillende zones gemaakt. Wanneer een zone uitvalt, zijn cacheknooppunten in andere zones beschikbaar om de cache te laten functioneren zoals gebruikelijk.
Azure Cache voor Redis ondersteunt zone-redundante configuraties in de Premium- en Enterprise-lagen. Een zoneredundante cache kan de knooppunten in verschillende Azure-Beschikbaarheidszones in dezelfde regio plaatsen. Het elimineert storingen in datacenters of beschikbaarheidszones als een single point of failure en verhoogt de algehele beschikbaarheid van uw cache.
Premium-laag
In het volgende diagram ziet u de zone-redundante configuratie voor de Premium-laag:
Azure Cache voor Redis knooppunten in een zoneredundante cache op een round robin-manier over de geselecteerde Beschikbaarheidszones distribueert. Het bepaalt ook het knooppunt dat in eerste instantie als primair fungeert.
Zone Down Experience voor Premium-laag
Een zoneredundante cache biedt automatische failover. Wanneer het huidige primaire knooppunt niet beschikbaar is, neemt een van de replica's het over. Uw toepassing kan een hogere reactietijd van de cache ervaren als het nieuwe primaire knooppunt zich in een andere AZ bevindt. Beschikbaarheidszones zijn geografisch gescheiden. Als u van de ene AZ naar een andere overschakelt, verandert de fysieke afstand tussen waar uw toepassing en cache worden gehost. Deze wijziging heeft invloed op retournetwerklatenties van uw toepassing naar de cache. De extra latentie valt naar verwachting binnen een acceptabel bereik voor de meeste toepassingen. U wordt aangeraden uw toepassing te testen om ervoor te zorgen dat deze goed werkt met een zone-redundante cache.
Enterprise- en Enterprise Flash-lagen
Een cache in een Enterprise-laag wordt uitgevoerd op een Redis Enterprise-cluster. Het vereist altijd een oneven aantal serverknooppunten om een quorum te vormen. Standaard zijn er drie knooppunten, die elk worden gehost op een toegewezen VM.
- Een Enterprise-cache heeft twee gegevensknooppunten met dezelfde grootte en één kleiner quorumknooppunt.
- Een Enterprise Flash-cache heeft drie gegevensknooppunten van dezelfde grootte.
Het Enterprise-cluster verdeelt Azure Cache voor Redis gegevens in partities intern. Elke partitie heeft een primaire en ten minste één replica. Elk gegevensknooppunt bevat een of meer partities. Het Enterprise-cluster zorgt ervoor dat de primaire en replica('s) van een partitie nooit op hetzelfde gegevensknooppunt worden geplaatst. Partities repliceren gegevens asynchroon van primaries naar de bijbehorende replica's.
Zone Down Experience voor Enterprise-lagen
Wanneer een gegevensknooppunt niet meer beschikbaar is of een netwerksplitsing plaatsvindt, vindt er een failover plaats die vergelijkbaar is met de failover die wordt beschreven in de standaardreplicatie . Het Enterprise-cluster maakt gebruik van een quorummodel om te bepalen welke overlevende knooppunten deelnemen aan een nieuw quorum. Het bevordert ook replicapartities binnen deze knooppunten tot primaries indien nodig.
Regionale beschikbaarheid
Zone-redundante Premium-laagcaches zijn beschikbaar in de volgende regio's:
| Noord- en Zuid-Amerika | Europa | Midden-Oosten | Afrika | Azië en Stille Oceaan |
|---|---|---|---|---|
| Brazilië - zuid | Frankrijk - centraal | Qatar - centraal | Zuid-Afrika - noord | Australië - oost |
| Canada - midden | Duitsland - west-centraal | India - centraal | ||
| Central US | Europa - noord | Japan East | ||
| VS - oost | Noorwegen - oost | Korea - centraal | ||
| VS - oost 2 | VK - zuid | Azië - zuidoost | ||
| VS - zuid-centraal | Europa -west | Azië - oost | ||
| VS (overheid) - Virginia | Zweden - centraal | China - noord 3 | ||
| VS - west 2 | Zwitserland - noord | |||
| US - west 3 |
Zone-redundante Enterprise- en Enterprise Flash-laagcaches zijn beschikbaar in de volgende regio's:
| Noord- en Zuid-Amerika | Europa | Midden-Oosten | Afrika | Azië en Stille Oceaan |
|---|---|---|---|---|
| Canada - centraal* | Europa - noord | Australië - oost | ||
| VS - centraal* | VK - zuid | India - centraal | ||
| VS - oost | Europa -west | Azië - zuidoost | ||
| VS - oost 2 | Japan - oost* | |||
| VS - zuid-centraal | Azië - oost* | |||
| VS - west 2 | ||||
| US - west 3 | ||||
| Brazilië - zuid |
* Enterprise Flash-laag is niet beschikbaar in deze regio.
Opnieuw implementeren en migreren van beschikbaarheidszone
Momenteel is de enige manier om uw cache te converteren van een niet-AZ-configuratie naar een AZ-configuratie om de cache opnieuw te implementeren. Zie Een Azure Cache voor Redis exemplaar migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie over het opnieuw implementeren van uw huidige cache.
Persistentie
Toepasselijke lagen: Premium, Enterprise (preview), Enterprise Flash (preview)
Aanbevolen voor: Duurzaamheid van gegevens
Omdat uw cachegegevens worden opgeslagen in het geheugen, kan een zeldzame en ongeplande fout van meerdere knooppunten ertoe leiden dat alle gegevens worden verwijderd. Om te voorkomen dat gegevens volledig verloren gaan, kunt u met Redis persistentie periodieke momentopnamen van in-memory gegevens maken en opslaan in uw opslagaccount. Als er een fout opgetreden is op meerdere knooppunten die gegevensverlies veroorzaken, laadt uw cache de momentopname van het opslagaccount. Zie Gegevenspersistentie configureren voor een Premium Azure Cache voor Redis-exemplaar voor meer informatie.
Opslagaccount voor persistentie
Overweeg om een geografisch redundant opslagaccount te kiezen om een hoge beschikbaarheid van persistente gegevens te garanderen. Zie Redundantie in Azure Storage voor meer informatie.
Import/Export
Toepasselijke lagen: Premium, Enterprise, Enterprise Flash
Aanbevolen voor: herstel na noodgevallen
Azure Cache voor Redis ondersteunt de optie voor het importeren en exporteren van RDB-bestanden (Redis Database) om gegevensportabiliteit te bieden. Hiermee kunt u gegevens importeren in Azure Cache voor Redis of gegevens exporteren uit Azure Cache voor Redis met behulp van een RDB-momentopname. De RDB-momentopname van een Premium-cache wordt geëxporteerd naar een blob in een Azure Storage-account. U kunt een script maken om periodiek exporteren naar uw opslagaccount te activeren. Zie Gegevens importeren en exporteren in Azure Cache voor Redis voor meer informatie.
Opslagaccount voor export
Overweeg om een geografisch redundant opslagaccount te kiezen om hoge beschikbaarheid van uw geëxporteerde gegevens te garanderen. Zie Redundantie in Azure Storage voor meer informatie.
Passieve geo-replicatie
Toepasselijke lagen: Premium
Aanbevolen voor: Herstel na noodgevallen - één regio
Geo-replicatie is een mechanisme voor het koppelen van twee of meer Azure Cache voor Redis exemplaren, meestal in twee Azure-regio's. Geo-replicatie is voornamelijk ontworpen voor herstel na noodgevallen tussen regio's. Er worden twee cache-exemplaren van de Premium-laag verbonden via geo-replicatie op een manier die lees- en schrijfbewerkingen naar uw primaire cache biedt en die gegevens worden gerepliceerd naar de secundaire cache.
Zie Geo-replicatie configureren voor Premium Azure Cache voor Redis instanties voor meer informatie over het instellen ervan.
Als de regio die als host fungeert voor de primaire cache uitvalt, moet u de failover starten door eerst de secundaire cache los te koppelen en vervolgens de toepassing bij te werken zodat deze verwijst naar de secundaire cache voor lees- en schrijfbewerkingen.
Actieve geo-replicatie
Toepasselijke lagen: Enterprise, Enterprise Flash
Aanbevolen voor: hoge beschikbaarheid, herstel na noodgevallen - meerdere regio's
De Enterprise-lagen ondersteunen een geavanceerdere vorm van geo-replicatie genaamd actieve geo-replicatie die zowel hogere beschikbaarheid als herstel na noodgevallen tussen regio's in meerdere regio's biedt. De Azure Cache voor Redis Enterprise-software maakt gebruik van conflictvrije gerepliceerde gegevenstypen ter ondersteuning van schrijfbewerkingen naar meerdere cache-exemplaren, voegt wijzigingen samen en lost conflicten op. U kunt maximaal vijf cache-exemplaren van de Enterprise-laag in verschillende Azure-regio's samenvoegen om een geo-replicatiegroep te vormen.
Een toepassing die een dergelijke cache gebruikt, kan via de bijbehorende eindpunten lezen en schrijven naar een van de geografisch gedistribueerde cache-exemplaren. De toepassing moet gebruiken wat het dichtst bij elk toepassingsexemplaren ligt, waardoor u de laagste latentie krijgt. Zie Actieve geo-replicatie configureren voor Enterprise Azure Cache voor Redis-exemplaren voor meer informatie.
Als een regio van een van de caches in uw replicatiegroep uitvalt, moet uw toepassing overschakelen naar een andere regio die beschikbaar is.
Wanneer een cache in uw replicatiegroep niet beschikbaar is, raden we u aan het geheugengebruik voor andere caches in dezelfde replicatiegroep te bewaken. Terwijl een van de caches niet beschikbaar is, beginnen alle andere caches in de replicatiegroep met het opslaan van metagegevens die ze niet konden delen met de cache die niet beschikbaar is. Als het geheugengebruik voor de beschikbare caches met een hoge snelheid groeit nadat een van de caches uitvalt, kunt u overwegen de cache die niet beschikbaar is van de replicatiegroep te ontkoppelen.
Zie Force-Unlink voor meer informatie over force-unlinking als er sprake is van een storing in de regio.
Cache verwijderen en opnieuw maken
Toepasselijke lagen: Standard, Premium, Enterprise, Enterprise Flash
Als u een regionale storing ondervindt, kunt u overwegen om uw cache in een andere regio opnieuw te maken en uw toepassing bij te werken om in plaats daarvan verbinding te maken met de nieuwe cache. Het is belangrijk om te begrijpen dat gegevens verloren gaan tijdens een regionale storing. Uw toepassingscode moet bestand zijn tegen gegevensverlies.
Zodra de getroffen regio is hersteld, wordt uw niet-beschikbare Azure Cache voor Redis automatisch hersteld en weer beschikbaar voor gebruik. Zie Azure Cache voor Redis exemplaren verplaatsen naar verschillende regio's voor meer strategieën voor het verplaatsen van uw cache naar een andere regio.
Volgende stappen
Meer informatie over het configureren van Azure Cache voor Redis opties voor hoge beschikbaarheid.