Azure Cache voor Redis en operationele uitmuntendheid
Azure Cache voor Redis biedt een gegevensarchief in het geheugen op basis van de Redis-software (Remote Dictionary Server). Het is een beveiligde gegevenscache en berichtenbroker die hoge doorvoer en lage latentie toegang biedt tot gegevens voor toepassingen.
Aanbevolen procedures voor operationele uitmuntendheid zijn onder andere:
De volgende secties bevatten ontwerpoverwegingen, een configuratiecontrolelijst en aanbevolen configuratieopties die specifiek zijn voor Azure Cache voor Redis.
Overwegingen bij het ontwerpen
De Azure Cache voor Redis Sla (Service Level Agreements) heeft alleen betrekking op caches van de Standard- en Premium-laag. De Basic-laag wordt niet gedekt.
Redis is een cache in het geheugen voor sleutelwaardeparen en heeft standaard hoge beschikbaarheid (HA), met uitzondering van de Basic-laag. Er zijn drie lagen voor Azure Cache voor Redis:
Basic: niet aanbevolen voor productieworkloads. De Basic-laag is ideaal voor:
- Eén knooppunt
- Meerdere grootten
- Ontwikkeling
- Testen
- Niet-kritieke workloads
Standaard: een gerepliceerde cache in een primaire en secundaire configuratie met twee knooppunten die wordt beheerd door Microsoft, met een SLA voor hoge beschikbaarheid.
Premium: bevat alle functies van de Standard-laag en bevat de volgende andere functies:
- Snellere hardware en prestaties in vergelijking met de Basic- of Standard-laag.
- Grotere cachegrootte, tot
120GB. - Gegevenspersistentie, waaronder Redis Database File (RDB) en Append Only File (AOF).
- VNET-ondersteuning.
- Clustering
- Geo-replicatie: een secundaire cache bevindt zich in een andere regio en repliceert gegevens van de primaire cache voor herstel na noodgevallen. Als u een failover wilt uitvoeren naar de secundaire, moeten de caches handmatig worden ontkoppeld en is de secundaire beschikbaar voor schrijfbewerkingen. De toepassing die naar Redis wordt geschreven, moet worden bijgewerkt met de cache van de secundaire verbindingsreeks.
- Beschikbaarheidszones: implementeer de cache en replica's in beschikbaarheidszones.
Notitie
Standaard heeft elke implementatie één replica per shard. Persistentie, clustering en geo-replicatie zijn op dit moment allemaal uitgeschakeld met implementaties met meer dan één replica. Uw knooppunten worden gelijkmatig verdeeld over alle zones. U moet een aantal zones voor het aantal
>=replica's hebben. - Importeren en exporteren.
Microsoft garandeert ten minste 99.9% de tijd dat klanten verbinding hebben tussen de cache-eindpunten en de internetgateway van Microsoft.
Controlelijst
Hebt u Azure Cache voor Redis geconfigureerd met operationele uitmuntendheid in gedachten?
- Updates plannen.
- De cache bewaken en waarschuwingen instellen.
- Implementeer de cache binnen een VNET.
- Gebruik het juiste cachetype (lokaal, in rol, beheerd, redis) in uw oplossing.
- Configureer Gegevenspersistentie om een kopie van de cache op te slaan in Azure Storage of gebruik geo-replicatie, afhankelijk van de bedrijfsvereiste.
- Gebruik één statische of singleton-implementatie van de verbindingsmultiplexer met Redis en volg de handleiding voor best practices.
- Raadpleeg How to admin Azure Cache voor Redis (Azure Cache voor Redis beheren).
Aanbevelingen voor configuratie
Bekijk de volgende tabel met aanbevelingen om uw Azure Cache voor Redis configuratie te optimaliseren voor operationele uitmuntendheid:
| Aanbeveling | Beschrijving |
|---|---|
| Updates plannen. | Plan de dagen en tijden waarop Redis Server-updates worden toegepast op de cache, die geen Azure-updates of updates voor het VM-besturingssysteem bevat. |
| De cache bewaken en waarschuwingen instellen. | Stel waarschuwingen in voor uitzonderingen, hoog CPU-gebruik, hoog geheugengebruik, serverbelasting en verwijderde sleutels voor inzicht in wanneer de cache moet worden geschaald. Als de cache moet worden geschaald, is het belangrijk om te weten wanneer de schaal moet worden geschaald, omdat dit de CPU verhoogt tijdens de schaalgebeurtenis voor het migreren van gegevens. |
| Implementeer de cache binnen een VNET. | Geeft de klant meer controle over het verkeer dat verbinding kan maken met de cache. Zorg ervoor dat het subnet voldoende adresruimte heeft om de cacheknooppunten en shards (cluster) te implementeren. |
| Gebruik het juiste cachetype (lokaal, in rol, beheerd, redis) in uw oplossing. | Gedistribueerde toepassingen implementeren gewoonlijk een van de volgende strategieën (of beide) als er gegevens in de cache worden opgeslagen: - Met behulp van een privécache, waarbij gegevens lokaal worden opgeslagen op de computer waarop een exemplaar van een toepassing of service wordt uitgevoerd. - Gebruik van een gedeelde cache, die fungeert als een gemeenschappelijke bron die kan worden geopend door meerdere processen en machines. In beide gevallen kan caching worden uitgevoerd aan de clientzijde en aan de serverzijde. Caching aan de clientzijde wordt uitgevoerd door het proces dat de gebruikersinterface voor een systeem levert, bijvoorbeeld een webbrowser of bureaubladtoepassing. Caching aan de serverzijde wordt uitgevoerd door het proces dat de bedrijfsservices levert die extern worden uitgevoerd. |
| Configureer Gegevenspersistentie om een kopie van de cache op te slaan in Azure Storage of gebruik geo-replicatie, afhankelijk van de bedrijfsvereiste. | Gegevenspersistentie: als de hoofd- en replica opnieuw worden opgestart, worden de gegevens automatisch geladen vanuit het opslagaccount. Geo-replicatie: de secundaire cache moet worden ontkoppeld van de primaire cache. De secundaire wordt nu de primaire en kan schrijfbewerkingen ontvangen. |
| Raadpleeg How to admin Azure Cache voor Redis (Azure Cache voor Redis beheren). | Krijg inzicht in hoe gegevensverlies kan optreden bij het opnieuw opstarten van de cache en hoe u de toepassing kunt testen op tolerantie. |
Bronartefacten
Gebruik de volgende query om Redis-exemplaren te identificeren die zich niet in de Premium-laag bevinden:
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'