Wat zijn de aanbevolen procedures voor de Enterprise- en Enterprise Flash-lagen
Hier volgen de aanbevolen procedures voor het gebruik van de Enterprise- en Enterprise Flash-lagen van Azure Cache voor Redis.
Zoneredundantie
We raden u ten zeerste aan nieuwe caches te implementeren in een zone-redundante configuratie. Zoneredundantie zorgt ervoor dat Redis Enterprise-knooppunten worden verdeeld over drie beschikbaarheidszones, waardoor redundantie van storingen op datacentrumniveau wordt gestimuleerd. Het gebruik van zoneredundantie verhoogt de beschikbaarheid. Zie Service Level Agreements (SLA) voor onlineservices voor meer informatie.
Zoneredundantie is belangrijk voor de Enterprise-laag, omdat uw cache-exemplaar altijd ten minste drie knooppunten gebruikt. Twee knooppunten zijn gegevensknooppunten, die uw gegevens en een quorumknooppunt bevatten. Door de capaciteit te vergroten, wordt het aantal gegevensknooppunten in stappen met even getallen geschaald.
Er is ook een ander knooppunt dat een quorumknooppunt wordt genoemd. Dit knooppunt bewaakt de gegevensknooppunten en selecteert automatisch het nieuwe primaire knooppunt als er een failover is. Zoneredundantie zorgt ervoor dat de knooppunten gelijkmatig worden verdeeld over drie beschikbaarheidszones, waardoor het risico op quorumverlies wordt geminimaliseerd. Klanten worden niet in rekening gebracht voor het quorumknooppunt en er worden geen andere kosten in rekening gebracht voor het gebruik van zoneredundantie buiten de kosten voor intrazonegebonden bandbreedte.
Schalen
In de Enterprise- en Enterprise Flash-lagen van Azure Cache voor Redis raden we u aan om omhoog schalen te prioriteren ten opzichte van uitschalen. Prioriteit geven aan omhoog schalen omdat de Enterprise-lagen zijn gebouwd op Redis Enterprise, die meer CPU-kernen in grotere VM's kunnen gebruiken.
Omgekeerd geldt de tegenovergestelde aanbeveling voor de Basic-, Standard- en Premium-lagen, die zijn gebouwd op opensource Redis. In deze lagen wordt het prioriteren van omhoogschalen aanbevolen in de meeste gevallen.
Sharding en CPU-gebruik
In de lagen Basic, Standard en Premium van Azure Cache voor Redis is het bepalen van het aantal gebruikte virtuele CPU's (vCPU's) eenvoudig. Elk Redis-knooppunt wordt uitgevoerd op een toegewezen VM. Het Redis-serverproces is één thread, waarbij één vCPU op elke primaire en elk replicaknooppunt wordt gebruikt. De andere vCPU's op de virtuele machine worden nog steeds gebruikt voor andere activiteiten, zoals werkstroomcoördinatie voor verschillende taken, statuscontrole en TLS-belasting, onder andere.
Wanneer u clustering gebruikt, is het effect om gegevens over meer knooppunten te verdelen met één shard per knooppunt. Door het aantal shards te verhogen, verhoogt u lineair het aantal vCPU's dat u gebruikt, op basis van het aantal shards in het cluster.
Redis Enterprise kan daarentegen meerdere vCPU's gebruiken voor het Redis-exemplaar zelf. Met andere woorden, alle lagen van Azure Cache voor Redis kunnen meerdere vCPU's gebruiken voor achtergrond- en bewakingstaken, maar alleen de Enterprise- en Enterprise Flash-lagen kunnen meerdere vCPU's per VM gebruiken voor Redis-shards. In de tabel ziet u het aantal effectieve vCPU's dat wordt gebruikt voor elke SKU en capaciteit (dat wil gezegd uitschalen) configuratie.
De tabellen geven het aantal vCPU's weer dat wordt gebruikt voor de primaire shards, niet voor de replica-shards. Shards wijzen niet een-op-een toe aan het aantal vCPU's. De tabellen illustreren alleen vCPU's, geen shards. Sommige configuraties gebruiken meer shards dan beschikbare vCPU's om de prestaties in sommige gebruiksscenario's te verbeteren.
E5
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capaciteit | Effectieve vCPU's |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capaciteit | Effectieve vCPU's |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capaciteit | Effectieve vCPU's |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capaciteit | Effectieve vCPU's |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering in Enterprise
Enterprise- en Enterprise Flash-lagen zijn inherent geclusterd, in tegenstelling tot de Basic-, Standard- en Premium-lagen. De implementatie is afhankelijk van het clusteringbeleid dat is geselecteerd. De Enterprise-lagen bieden twee opties voor clusterbeleid: OSS en Enterprise. OSS-clusterbeleid wordt aanbevolen voor de meeste toepassingen omdat het hogere maximale doorvoer ondersteunt, maar er zijn voor- en nadelen voor elke versie.
Het OSS-clusterbeleid implementeert dezelfde Redis-cluster-API als opensource Redis. Met de Redis-cluster-API kan de Redis-client rechtstreeks verbinding maken met elk Redis-knooppunt, waardoor latentie wordt geminimaliseerd en de netwerkdoorvoer wordt geoptimaliseerd. Als gevolg hiervan wordt bijna lineaire schaalbaarheid verkregen bij het uitschalen van het cluster met meer knooppunten. Het OSS-clusteringbeleid biedt over het algemeen de beste latentie en doorvoerprestaties, maar vereist dat uw clientbibliotheek Ondersteuning biedt voor Redis Clustering. OSS-clusteringbeleid kan ook niet worden gebruikt met de RediSearch-module.
Het clusteringbeleid voor ondernemingen is een eenvoudigere configuratie die gebruikmaakt van één eindpunt voor alle clientverbindingen. Met behulp van het clusterbeleid voor ondernemingen worden alle aanvragen gerouteerd naar één Redis-knooppunt dat vervolgens wordt gebruikt als proxy, intern routeringsaanvragen naar het juiste knooppunt in het cluster. Het voordeel van deze aanpak is dat Redis-clientbibliotheken geen ondersteuning hoeven te bieden voor Redis Clustering om te profiteren van meerdere knooppunten. Het nadeel is dat de proxy met één knooppunt een knelpunt kan zijn in het rekengebruik of de netwerkdoorvoer. Het clusteringbeleid voor ondernemingen is de enige die kan worden gebruikt met de RediSearch-module.
Opdrachten met meerdere sleutels
Omdat de Enterprise-lagen een geclusterde configuratie gebruiken, ziet CROSSSLOT u mogelijk uitzonderingen voor opdrachten die op meerdere sleutels werken. Het gedrag varieert afhankelijk van het gebruikte clusterbeleid. Als u het OSS-clusteringbeleid gebruikt, moeten voor opdrachten met meerdere sleutels alle sleutels worden toegewezen aan dezelfde hash-site.
Mogelijk ziet CROSSSLOT u ook fouten met enterprise-clusteringbeleid. Alleen de volgende opdrachten met meerdere sleutels zijn toegestaan voor sites met Enterprise-clustering: DEL, MSET, MGET, EXISTS, , UNLINKen TOUCH.
In Active-Active-databases kunnen schrijfopdrachten met meerdere sleutels (DEL, MSET, ) UNLINKalleen worden uitgevoerd op sleutels die zich in dezelfde site bevinden. De volgende opdrachten met meerdere sleutels zijn echter toegestaan voor sites in Active-Active-databases: MGET, EXISTSen TOUCH. Zie Databaseclustering voor meer informatie.
Enterprise Flash Best Practices
De Enterprise Flash-laag maakt gebruik van zowel NVMe Flash-opslag als RAM-geheugen. Omdat Flash-opslag lager is, kunt u met de Enterprise Flash-laag bepaalde prestaties voor prijsefficiëntie afruilen.
Op Enterprise Flash-exemplaren bevindt 20% van de cacheruimte zich in ram-geheugen, terwijl de andere 80% flashopslag gebruikt. Alle sleutels worden opgeslagen in ram-geheugen, terwijl de waarden kunnen worden opgeslagen in Flash Storage of RAM. De locatie van de waarden wordt intelligent bepaald door de Redis-software. Hot-waarden die fequent worden geopend, worden opgeslagen in ram-geheugen, terwijl 'Koude' waarden die minder vaak worden gebruikt, op Flash worden bewaard. Voordat gegevens worden gelezen of geschreven, moeten ze worden verplaatst naar ram-geheugen en worden ze 'Dynamische' gegevens.
Omdat Redis zal optmiseren voor de beste prestaties, vult het exemplaar eerst het beschikbare RAM-geheugen in voordat items worden toegevoegd aan Flash-opslag. Dit heeft enkele gevolgen voor de prestaties:
- Bij het testen met weinig geheugen kunnen prestaties en latentie aanzienlijk beter zijn dan bij een volledig cache-exemplaar, omdat alleen RAM wordt gebruikt.
- Naarmate u meer gegevens naar de cache schrijft, neemt het aandeel gegevens in RAM-geheugen in vergelijking met Flash-opslag af, waardoor de latentie en doorvoerprestaties ook afnemen.
Workloads die geschikt zijn voor de Enterprise Flash-laag
Werkbelastingen die waarschijnlijk goed worden uitgevoerd op de Enterprise Flash-laag, hebben vaak de volgende kenmerken:
- Lees zwaar, met een hoge verhouding van leesopdrachten tot schrijfopdrachten.
- Access is gericht op een subset sleutels die veel vaker worden gebruikt dan de rest van de gegevensset.
- Relatief grote waarden in vergelijking met sleutelnamen. (Omdat sleutelnamen altijd worden opgeslagen in het RAM-geheugen, kan dit een knelpunt worden voor geheugengroei.)
Workloads die niet geschikt zijn voor de Enterprise Flash-laag
Sommige workloads hebben toegangskenmerken die minder zijn geoptimaliseerd voor het ontwerp van de Flash-laag:
- Schrijf zware werkbelastingen.
- Willekeurige of uniforme gegevenstoegang tot vaders in de meeste gegevenssets.
- Lange sleutelnamen met relatief kleine waardegrootten.
Scenario's voor regio-omlaag verwerken met actieve geo-replicatie
Actieve geo-replicatie is een krachtige functie om de beschikbaarheid aanzienlijk te verbeteren bij het gebruik van de Enterprise-lagen van Azure Cache voor Redis. U moet echter stappen ondernemen om uw caches voor te bereiden als er een regionale storing is.
Bekijk bijvoorbeeld de volgende tips:
- Bepaal vooraf naar welke andere cache in de geo-replicatiegroep moet worden overgeschakeld als een regio uitvalt.
- Zorg ervoor dat firewalls zo zijn ingesteld dat toepassingen en clients toegang hebben tot de geïdentificeerde back-upcache.
- Elke cache in de geo-replicatiegroep heeft een eigen toegangssleutel. Bepaal hoe de toepassing overschakelt naar verschillende toegangssleutels bij het richten van een back-upcache.
- Als een cache in de geo-replicatiegroep uitvalt, begint er een opbouw van metagegevens in alle caches in de geo-replicatiegroep op te treden. De metagegevens kunnen pas worden verwijderd als schrijfbewerkingen opnieuw naar alle caches kunnen worden gesynchroniseerd. U kunt voorkomen dat de metagegevens worden opgebouwd door het ontkoppelen van de cache die niet beschikbaar is, af te dwingen. Overweeg om het beschikbare geheugen in de cache te bewaken en ontkoppelen als er geheugenbelasting is, met name voor schrijfintensieve werkbelastingen.
Het is ook mogelijk om een circuitonderbrekerpatroon te gebruiken. Gebruik het patroon om verkeer automatisch om te leiden van een cache die te maken heeft met een storing in een regio en naar een back-upcache in dezelfde geo-replicatiegroep. Gebruik Azure-services zoals Azure Traffic Manager of Azure Load Balancer om de omleiding in te schakelen.
Gegevenspersistentie versus gegevensback-up
De functie voor gegevenspersistentie in de Enterprise- en Enterprise Flash-lagen is ontworpen om automatisch een snel herstelpunt voor gegevens te bieden wanneer een cache uitvalt. Het snelle herstel wordt mogelijk gemaakt door het RDB- of AOF-bestand op te slaan op een beheerde schijf die is gekoppeld aan het cache-exemplaar. Persistentiebestanden op de schijf zijn niet toegankelijk voor gebruikers.
Veel klanten willen persistentie gebruiken om periodieke back-ups van de gegevens in hun cache te maken. We raden u niet aan om gegevenspersistentie op deze manier te gebruiken. Gebruik in plaats daarvan de functie importeren/exporteren . U kunt kopieën van cachegegevens rechtstreeks in de RDB-indeling exporteren naar uw gekozen opslagaccount en de gegevensexport zo vaak activeren als u nodig hebt. Exporteren kan worden geactiveerd vanuit de portal of met behulp van de CLI-, PowerShell- of SDK-hulpprogramma's.