Betrouwbaarheid in Azure Managed Redis

Azure Managed Redis biedt volledig geïntegreerde en beheerde Redis Enterprise in Azure en biedt krachtige gegevensopslag in het geheugen voor toepassingen. Deze service is gebouwd voor bedrijfsworkloads waarvoor ultra lage latentie, hoge doorvoer en geavanceerde gegevensstructuren zijn vereist.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt de betrouwbaarheid in Azure Managed Redis beschreven, waaronder tolerantie voor tijdelijke fouten, fouten in beschikbaarheidszones en regiobrede fouten. In het artikel worden ook back-upstrategieën en de SLA (Service Level Agreement) beschreven.

Aanbevelingen voor productie-implementatie

Om hoge betrouwbaarheid voor uw productieomgeving van Azure Managed Redis-exemplaren te garanderen, raden we u aan:

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Azure Managed Redis is gebouwd op Redis Enterprise en biedt betrouwbaarheid via configuraties en replicatiemogelijkheden met hoge beschikbaarheid.

U implementeert een exemplaar van Azure Managed Redis, dat ook wel een cache-exemplaar of een cache wordt genoemd. Uw clienttoepassingen slaan gegevens in de cache op en gebruiken deze met behulp van Redis-API's.

Fysieke architectuur

Er zijn twee belangrijke concepten die u moet begrijpen bij het plannen van tolerantie voor Azure Managed Redis: knooppunten en shards.

• Knooppunten: Elk cache-exemplaar bestaat uit knooppunten, die virtuele machines (VM's) zijn. Elke VM fungeert als een onafhankelijke rekeneenheid in het cluster. U ziet of beheert de VM's niet rechtstreeks. Het platform beheert automatisch het maken van exemplaren, statuscontrole en vervanging van beschadigde exemplaren. De set virtuele machines, die samen worden genomen, wordt ook wel een cluster genoemd.

  U kunt uw exemplaar configureren voor hoge beschikbaarheid. Wanneer u dit doet, zorgt Azure Managed Redis ervoor dat er ten minste twee knooppunten zijn en worden gegevens automatisch tussen de knooppunten gerepliceerd. In regio's met beschikbaarheidszones worden de knooppunten in verschillende beschikbaarheidszones geplaatst. Zie Tolerantie voor fouten in beschikbaarheidszones voor meer informatie.

  De service abstraheert het specifieke aantal knooppunten dat in elke configuratie wordt gebruikt om complexiteit te voorkomen en optimale configuraties te garanderen.

• Scherven: Elk knooppunt voert meerdere Redis-serverprocessen met de naam shards uit, waarmee een subset van de gegevens van uw cache wordt beheerd. Wanneer uw cache is geconfigureerd voor hoge beschikbaarheid, worden shards automatisch gedistribueerd en gerepliceerd tussen knooppunten. U geeft een clusterbeleid op, waarmee wordt bepaald hoe shards worden verdeeld over knooppunten.

Zie Azure Managed Redis-architectuur en failover en patching voor Azure Managed Redis voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Volg deze aanbevelingen voor het beheren van tijdelijke fouten bij het gebruik van Azure Managed Redis:

• Gebruik SDK-configuraties die automatisch opnieuw proberen wanneer tijdelijke fouten optreden en die de juiste uitstel- en time-outperioden gebruiken. Overweeg het Retry-patroon en Circuit Breaker-patroon in uw toepassingen te gebruiken.
• Ontwerp voor cache-aside-patronen waarin uw toepassing kan blijven werken met verminderde prestaties wanneer Redis tijdelijk niet beschikbaar is door terug te vallen naar het primaire gegevensarchief.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Managed Redis-cache-exemplaren kunnen zone-redundant worden gemaakt, waardoor de cacheknooppunten automatisch worden verdeeld over meerdere beschikbaarheidszones binnen een regio. Zoneredundantie vermindert het risico dat datacentrum- of beschikbaarheidszonestoringen ertoe leiden dat uw cache niet beschikbaar is.

Als u een zone-redundante cache wilt maken, moet u deze implementeren in een ondersteunde regio en configuratie met hoge beschikbaarheid inschakelen. In regio's zonder beschikbaarheidszones maakt de configuratie voor hoge beschikbaarheid nog steeds ten minste twee knooppunten, maar ze bevinden zich niet in afzonderlijke zones.

In het volgende diagram ziet u een zone-redundante cache met twee knooppunten, elk in een afzonderlijke zone:

Requirements

• Regioondersteuning: Zone-redundante Azure Managed Redis-caches kunnen worden geïmplementeerd in elke regio die beschikbaarheidszones ondersteunt en waar de service beschikbaar is. Zie Azure-regio's met beschikbaarheidszones voor de meest recente lijst met regio's die beschikbaarheidszones ondersteunen. Zie Product beschikbaarheid per regio voor de lijst met regio's die ondersteuning bieden voor Azure Managed Redis.

• Configuratie voor hoge beschikbaarheid: U moet configuratie met hoge beschikbaarheid inschakelen voor uw cache, zodat deze zone-redundant is.

• Tiers: Alle Azure Managed Redis-tiers ondersteunen beschikbaarheidszones.

Kosten

Zoneredundantie vereist dat uw cache is geconfigureerd voor hoge beschikbaarheid, waardoor minimaal twee knooppunten voor uw cache worden geïmplementeerd. Configuratie van hoge beschikbaarheid wordt gefactureerd tegen een hoger tarief dan configuratie van niet-hoge beschikbaarheid. Voor meer informatie, zie Azure Managed Redis prijzen

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuw zone-redundant exemplaar: Wanneer u een nieuw azure Managed Redis-exemplaar maakt, schakelt u de configuratie van hoge beschikbaarheid in en implementeert u deze in een regio met beschikbaarheidszones. Vervolgens bevat het automatisch zoneredundantie standaard. U hoeft geen configuratie meer uit te voeren.

  Zie quickstart: Een azure Managed Redis-exemplaar maken voor gedetailleerde stappen.

• Zoneredundantie inschakelen voor een bestaand exemplaar: Als u een bestaand Azure Managed Redis-exemplaar wilt configureren om zone-redundant te zijn, moet u ervoor zorgen dat het wordt geïmplementeerd in een regio die beschikbaarheidszones ondersteunt en hoge beschikbaarheid in de cache mogelijk maakt.

• Zoneredundantie uitschakelen: Zoneredundantie kan niet worden uitgeschakeld voor bestaande exemplaren, omdat u hoge beschikbaarheid niet kunt uitschakelen zodra deze is ingeschakeld op een cache-exemplaar.

Capaciteitsplanning en -beheer

Tijdens een zone-uitval heeft uw instantie mogelijk minder middelen beschikbaar voor uw workload. Als uw instance vaak onder resourcedruk staat en u zich moet voorbereiden op het uitvallen van de beschikbaarheidszone, kunt u een van de volgende methoden overwegen.

• Uw exemplaar overprovisionen: Overprovisioning omvat het selecteren van een hogere prestatielaag dan u mogelijk nodig hebt. Hiermee kan uw exemplaar capaciteitsverlies tolereren en blijven werken zonder verslechterde prestaties. Zie Capaciteit beheren door overprovisioning voor meer informatie over het principe van overprovisioning. Zie Een Azure Managed Redis-exemplaar schalen om te leren hoe u uw exemplaar kunt schalen.

• Actieve geo-replicatie gebruiken: U kunt meerdere exemplaren in verschillende regio's implementeren en actieve geo-replicatie configureren om uw belasting over deze afzonderlijke exemplaren te verdelen.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een beheerde Redis-cache zone-redundant is en alle beschikbaarheidszones operationeel zijn:

• Verkeersroutering tussen zones: Shards worden verdeeld over knooppunten op basis van uw clusterbeleid. Uw clusterbeleid bepaalt ook hoe verkeer naar elk knooppunt wordt gerouteerd. Zoneredundantie verandert niet hoe verkeer wordt gerouteerd.

• Gegevensreplicatie tussen zones: Shards worden automatisch gerepliceerd tussen knooppunten en gebruiken asynchrone replicatie. Normaal gesproken wordt de replicatievertraging tussen shards in seconden gemeten, maar dat kan variëren, afhankelijk van de workload van de cache, met scenario's met veel schrijf- en netwerkintensieve gegevens, die doorgaans een hogere replicatievertraging zien.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een beheerde Redis-cache zone-redundant is en een of meer beschikbaarheidszones niet beschikbaar zijn:

• Detectie en reactie: Azure Managed Redis is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.

• Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Aanvragen tijdens de vlucht kunnen worden verwijderd en moeten opnieuw worden geprobeerd. Toepassingen moeten logica voor opnieuw proberen implementeren om deze tijdelijke onderbrekingen af te handelen.

• Verwachte gegevensverlies: Gegevens die niet zijn gerepliceerd naar shards in een andere zone, gaan mogelijk verloren tijdens een zonefout. Doorgaans wordt de hoeveelheid gegevensverlies in seconden gemeten, maar dit is afhankelijk van de replicatievertraging.

• Verwachte downtime: Een kleine hoeveelheid downtime, meestal 10-15 seconden, kan optreden terwijl shards een failover uitvoeren naar knooppunten in gezonde zones. Zie Uitleg van een failover voor informatie over het niet-geplande failoverproces. Wanneer u toepassingen ontwerpt, volg dan de praktijken voor het omgaan met tijdelijke fouten.

• Verkeer omleiden: Met Azure Managed Redis wordt verkeer automatisch omgeleid naar knooppunten in gezonde zones.

Zoneherstel

Wanneer de getroffen beschikbaarheidszone herstelt, worden bewerkingen van Azure Managed Redis automatisch in die zone hersteld. Het Azure-platform beheert dit proces volledig en vereist geen tussenkomst van de klant.

Testen op zonefouten

Omdat Azure Managed Redis verkeersroutering, failover en failback volledig beheert voor zonefouten, hoeft u geen processen voor fouten in de beschikbaarheidszone te valideren of verdere invoer te geven.

Tolerantie voor storingen in de hele regio

Azure Managed Redis biedt systeemeigen ondersteuning voor meerdere regio's via actieve geo-replicatie, waarmee u meerdere Azure Managed Redis-exemplaren in verschillende Azure-regio's kunt koppelen aan één replicatiegroep. Vervolgens kunt u uw eigen failover-benadering tussen de exemplaren configureren.

Actieve geo-replicatie

Wanneer u actieve geo-replicatie gebruikt, kunnen toepassingen lezen van en schrijven naar elk cache-exemplaar in de groep, waarbij wijzigingen automatisch in alle regio's worden gesynchroniseerd. De service ondersteunt actief-actieve replicatiepatronen waarbij elke regio zowel lees- als schrijfbewerkingen tegelijk kan verwerken. Wanneer er conflicten optreden als gevolg van gelijktijdige schrijfbewerkingen in verschillende regio's, lost de service deze automatisch op met behulp van vooraf vastgestelde conflictoplossingsalgoritmen zonder handmatige tussenkomst. Deze benadering biedt tolerantie voor regiofouten terwijl de toegang met lage latentie voor wereldwijd gedistribueerde toepassingen behouden blijft.

In het volgende diagram ziet u twee cache-exemplaren in verschillende regio's binnen dezelfde actieve geo-replicatiegroep, met clienttoepassingen die verbinding maken met elk cache-exemplaar:

U bent verantwoordelijk voor het configureren van uw clienttoepassingen, zodat, als een regionale instantie mislukt, uw aanvragen kunnen worden omgeleid naar een werkende instantie. In het volgende diagram ziet u hoe een toepassing aanvragen kan omleiden naar een goed functionerend cache-exemplaar wanneer het exemplaar dat ze gewoonlijk gebruiken mislukt:

Requirements

• Regioondersteuning Actieve geo-replicatie van Azure Managed Redis kan worden geconfigureerd tussen azure-regio's waar de service beschikbaar is.

• Exemplaarconfiguratie: Actieve geo-replicatie vereist Azure Managed Redis-exemplaren van dezelfde laag en grootte voor alle deelnemende regio's. Alle cache-exemplaren in een replicatiegroep moeten worden geconfigureerd met identieke instellingen, waaronder persistentieopties, modules en clusteringbeleid.

• Andere vereisten: Uw cache-exemplaren moeten voldoen aan andere vereisten, inclusief de modules die u gebruikt, en dit is van invloed op de schaal van uw cache-exemplaren. Zie Vereisten voor actieve geo-replicatie voor meer informatie.

Overwegingen

• Failover-verantwoordelijkheid: Wanneer u actieve geo-replicatie gebruikt, bent u verantwoordelijk voor failover tussen cache-exemplaren. U moet uw toepassing voorbereiden en configureren om failover af te handelen. Failover omvat voorbereiding en vereist mogelijk dat u meerdere stappen uitvoert. Zie Force-unlink als er sprake is van een storing in de regio voor meer informatie.

• Uiteindelijke consistentie: Toepassingen moeten worden ontworpen voor het afhandelen van uiteindelijke consistentiescenario's, omdat het tijd kan duren voordat wijzigingen in alle regio's worden doorgegeven, afhankelijk van de netwerkomstandigheden en geografische afstand. Tijdens regio-storingen kunnen er meer inconsistenties optreden voor gegevens totdat de verbinding is hersteld en de synchronisatie is voltooid.

Kosten

Wanneer u actieve geo-replicatie inschakelt, wordt u gefactureerd voor elk Azure Managed Redis-exemplaar in elke regio binnen de replicatiegroep. Daarnaast worden er mogelijk kosten in rekening gebracht voor gegevensoverdracht voor replicatieverkeer tussen regio's. Voor meer informatie over prijzen, zie Azure Managed Redis prijzen en bandbreedte prijsdetails.

Ondersteuning voor meerdere regio's configureren

• Maak een nieuw geo-gerepliceerd cache-exemplaar: Configureer actieve geo-replicatie tijdens het inrichten van de cache door een replicatiegroep op te geven en meerdere exemplaren te koppelen. Zie Een actieve geo-replicatiegroep maken of eraan deelnemen voor meer informatie.

• Een bestaand cache-exemplaar inschakelen voor geo-replicatie: u kunt een bestaand cache-exemplaar toevoegen aan een actieve geo-replicatiegroep.

  Wanneer een bestaand exemplaar echter wordt toegevoegd aan een actieve geo-replicatiegroep, moeten de gegevens in het exemplaar worden leeggemaakt en is er een kleine hoeveelheid downtime. Plan indien mogelijk actieve geo-replicatie in te schakelen wanneer u cache-exemplaren maakt.

  Zie Een bestaand exemplaar toevoegen aan een actieve geo-replicatiegroep voor meer informatie.

• Schakel geo-replicatie uit op een cache-exemplaar: verwijder een exemplaar uit een geo-replicatiegroep door het cache-exemplaar te verwijderen. De resterende instanties worden automatisch opnieuw geconfigureerd.

Capaciteitsplanning en -beheer

Tijdens een storing in de regio kunnen de andere instanties onder hogere druk staan. Als een exemplaar vaak al onder resourcedruk staat en u zich moet voorbereiden op de verhoogde capaciteitsvereisten tijdens een storing in een regio, kunt u overwegen om het exemplaar te overprovisioneren. Zie Een azure Managed Redis-exemplaar schalen voor meer informatie over het schalen van een exemplaar.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer exemplaren zijn geconfigureerd voor het gebruik van actieve geo-replicatie en alle regio's operationeel zijn.

• Verkeersroutering tussen regio's: u bent verantwoordelijk voor het configureren van uw toepassingen om verbinding te maken met een specifiek cache-exemplaar. Toepassingen kunnen verbinding maken met elk cache-exemplaar in de replicatiegroep en zowel lees- als schrijfbewerkingen uitvoeren. Verkeersroutering wordt verwerkt door de toepassing, zodat u clients naar de dichtstbijzijnde regio kunt leiden voor minimale latentie. Azure Managed Redis biedt geen automatische verkeersroutering tussen regio's.

• Gegevensreplicatie tussen regio's: de service maakt gebruik van asynchrone replicatie tussen regio's om uiteindelijke consistentie te behouden. Schrijfbewerkingen worden onmiddellijk doorgevoerd in de lokale regio en vervolgens doorgegeven aan andere regio's op de achtergrond. Conflictvrije gerepliceerde gegevenstypen (CRDT's) zorgen ervoor dat gelijktijdige schrijfbewerkingen in verschillende regio's automatisch worden samengevoegd.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer exemplaren zijn geconfigureerd voor het gebruik van actieve geo-replicatie en er een storing in één regio is:

• Detectie en reactie: u bent verantwoordelijk voor het detecteren van de fout van een cache-exemplaar en het bepalen wanneer een failover moet worden uitgevoerd. U kunt de status van een geo-gerepliceerd cluster bewaken, zodat u kunt bepalen wanneer u een failover wilt starten. Zie Geo-replicatie-metriek voor meer informatie.

  Voor failover moet u meerdere stappen uitvoeren. Zie Force-unlink als er sprake is van een storing in de regio voor meer informatie.

• Kennisgeving: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  U kunt ook de gezondheid van elke instantie bewaken.

  Als u de status van de geo-replicatierelatie wilt bewaken, kunt u de metriek Geo-replicatie-gezond gebruiken. De metrische waarde heeft altijd een waarde van 1 (in orde) of 0 (niet in orde). U kunt Azure Monitor-waarschuwingen voor deze metrische gegevens configureren om te begrijpen wanneer de exemplaren mogelijk niet synchroon zijn.

• Actieve aanvragen: aanvragen naar de mislukte regio worden beëindigd en moeten worden verwerkt door de failoverlogica van uw toepassing. Toepassingen moeten beleid voor opnieuw proberen implementeren waarmee verkeer naar gezonde caches kan worden omgeleid.

• Verwacht gegevensverlies: vanwege asynchrone replicatie tussen regio's gaan sommige recente schrijfbewerkingen naar de mislukte regio mogelijk verloren als ze nog niet zijn gerepliceerd naar andere regio's. De hoeveelheid mogelijk gegevensverlies is afhankelijk van de replicatievertraging op het moment van de fout. Zie Active-Active geografisch gedistribueerde Redis en overwegingen over consistentie en gegevensverlies in een regionale CRDB-fout voor meer informatie.

• Verwachte downtime: toepassingen ondervinden alleen downtime voor de duur die nodig is om de fout te detecteren en verkeer om te leiden naar gezonde regio's. Dit varieert doorgaans van seconden tot enkele minuten, afhankelijk van hoe u de statuscontrole en failoverconfiguratie van uw toepassing hebt geconfigureerd.

• Verkeer omleiden: u bent verantwoordelijk voor het implementeren van logica in uw toepassingen om regiofouten te detecteren en verkeer naar gezonde regio's te routeren. Dit kan worden bereikt via statuscontroles, circuitonderbrekerpatronen of externe taakverdelingsoplossingen.

Herstel van de regio

Wanneer een mislukte regio wordt hersteld, worden in Azure Managed Redis exemplaren in die regio automatisch opnieuw geïntegreerd in de actieve geo-replicatiegroep zonder dat uw tussenkomst is vereist. De service synchroniseert automatisch gegevens van gezonde exemplaren. Tijdens dit proces haalt het herstelde exemplaar geleidelijk wijzigingen op die zijn opgetreden tijdens de storing. Zodra de synchronisatie is voltooid, worden de herstelde exemplaren volledig actief en kunnen zowel lees- als schrijfbewerkingen worden verwerkt.

U bent verantwoordelijk voor het opnieuw configureren van uw toepassing om verkeer terug te sturen naar het herstelde regio-exemplaar.

Test voor regiofouten

U moet de failoverprocedures van uw toepassing regelmatig testen. Het is belangrijk dat uw toepassing een failover kan uitvoeren tussen exemplaren en dat deze, terwijl dat gebeurt, binnen uw bedrijfsvereisten voor downtime blijft. Het is ook belangrijk dat u uw algehele reactieprocessen test, inclusief eventuele herconfiguratie van firewalls en andere infrastructuur en uw herstelproces.

Tolerantie voor serviceonderhoud

Azure Managed Redis voert reguliere service-upgrades en andere onderhoudstaken uit.

Wanneer er onderhoud wordt uitgevoerd, worden in Azure Managed Redis automatisch nieuwe knooppunten gemaakt en wordt automatisch een failover uitgevoerd. Clienttoepassingen kunnen verbindingsonderbrekingen en andere tijdelijke fouten zien. Toepassingen moeten logica voor opnieuw proberen implementeren om deze tijdelijke onderbrekingen af te handelen.

Zie voor meer informatie over de onderhoudsprocessen voor Azure Managed Redis Failover en patching voor Azure Managed Redis.

Backups en herstel

Azure Managed Redis biedt zowel gegevenspersistentie- als back-upmogelijkheden om te beschermen tegen scenario's voor gegevensverlies die andere betrouwbaarheidsfuncties mogelijk niet aanpakken. Back-ups kunnen bescherming bieden tegen scenario's zoals beschadigde gegevens, onbedoelde verwijdering of configuratiefouten.

• Gegevenspersistentie: In Azure Managed Redis worden standaard alle cachegegevens in het geheugen opgeslagen. U kunt desgewenst momentopnamen van uw gegevens naar schijf schrijven met behulp van gegevenspersistentie. Als er een hardwarefout optreedt die van invloed is op het knooppunt, worden de gegevens automatisch hersteld door Azure Managed Redis. Er zijn verschillende typen gegevenspersistentie waaruit u kunt kiezen, die verschillende afwegingen bieden tussen de frequentie van momentopnamen en de prestatie-effecten op uw cache.

  Gegevensbestanden kunnen echter niet worden hersteld naar een ander exemplaar en u hebt geen toegang tot de bestanden. Gegevenspersistentie beschermt u niet tegen beschadiging van gegevens of onbedoeld verwijderen.

• Importeren en exporteren: Azure Managed Redis ondersteunt back-ups van uw gegevens met behulp van de import- en exportfunctionaliteit, waarmee back-upbestanden worden opgeslagen in Azure Blob Storage. U kunt geografisch redundante opslag configureren in uw Azure Storage-account of u kunt de back-upblobs kopiëren of verplaatsen naar andere locaties voor verdere beveiliging.

  Geëxporteerde bestanden kunnen worden hersteld naar hetzelfde cache-exemplaar of een ander cache-exemplaar.

  Er is geen ingebouwde import- of exportplanner, maar u kunt uw eigen automatiseringsprocessen ontwikkelen die gebruikmaken van de Azure CLI of Azure PowerShell om exportbewerkingen te starten.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

De SLA voor Azure Managed Redis omvat connectiviteit met de cache-eindpunten. De SLA biedt geen bescherming tegen gegevensverlies.

In aanmerking komen voor beschikbaarheids-SLA's voor Azure Managed Redis:

• U moet configuratie voor hoge beschikbaarheid inschakelen.
• U mag geen productfuncties of beheeracties initiëren die volgens documentatie tijdelijke onbeschikbaarheid veroorzaken.

SLA's voor hogere beschikbaarheid zijn van toepassing wanneer uw exemplaar zone-redundante is. In sommige lagen kunt u in aanmerking komen voor een SLA met een hogere beschikbaarheid wanneer u zone-redundante instanties in ten minste drie regio's hebt geïmplementeerd met behulp van actieve geo-replicatie.