Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Policy di dimensionamento con monitoraggio degli obiettivi
Con le policy di dimensionamento con monitoraggio degli obiettivi, puoi scegliere un parametro e impostare un valore obiettivo. ElastiCache con Valkey o Redis Auto OSS Scaling crea e gestisce gli allarmi che attivano CloudWatch la politica di scalabilità e calcola la regolazione della scalabilità in base alla metrica e al valore target. La policy di dimensionamento aggiunge o rimuove partizioni in base alle necessità, per mantenere il parametro al valore di destinazione specificato o vicino a esso. Oltre a mantenere il parametro vicino al valore di destinazione, una policy di dimensionamento di monitoraggio dei target si adatta anche alle fluttuazioni del parametro dovute a un modello di carico fluttuante e riduce al minimo le fluttuazioni rapide nella capacità del parco istanze.
Ad esempio, si consideri una policy di dimensionamento che utilizza la media predefinitaElastiCachePrimaryEngineCPUUtilizationMetrica con il valore di destinazione configurato. Tale politica può mantenere l'CPUutilizzo pari o vicino al valore target specificato.
Metriche predefinite
Una metrica predefinita è una struttura che fa riferimento a un nome, una dimensione e una statistica (average) specifici di una determinata metrica. CloudWatch La policy di dimensionamento automatico definisce le seguenti metriche predefinite per il cluster:
| Nome parametro predefinito | CloudWatch Nome della metrica | CloudWatch Dimensione metrica | Tipi di istanza non idonei |
|---|---|---|---|
ElastiCachePrimaryEngineCPUUtilization |
|
ReplicationGroupId, Ruolo = primario |
Nessuno |
ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage |
|
Metriche del gruppo di OSS replica Valkey o Redis |
Nessuno |
ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage |
|
Metriche del gruppo di replica Valkey o Redis OSS |
R6gd |
I tipi di istanze a più livelli di dati non possono essere utilizzatiElastiCacheDatabaseMemoryUsageCountedForEvictPercentage, poiché questi tipi di istanza archiviano i dati sia in memoria che. SSD Il caso d'uso previsto per le istanze a più livelli di dati consiste nell'utilizzare la memoria al 100% e riempirla secondo necessità. SSD
Criteri Auto Scaling per le partizioni
Quando il servizio rileva che la metrica predefinita è uguale o maggiore dell'impostazione Target, la capacità delle partizioni verrà aumentata automaticamente. ElastiCache con Valkey o Redis, OSS ridimensiona gli shard del cluster in base a un conteggio pari al più grande tra due numeri: variazione percentuale rispetto a Target e 20% rispetto agli shard attuali. Per quanto riguarda la scalabilità in entrata, ElastiCache non verrà eseguita automaticamente a meno che il valore della metrica complessivo non sia inferiore al 75 percento del Target definito.
Per un esempio di scala orizzontale, se hai 50 frammenti e
-
se Target viene violato del 30 percento, ElastiCache con Valkey o Redis la OSS scalabilità orizzontale si riduce del 30 percento, il che si traduce in 65 shard per cluster.
-
se Target viene violato del 10 percento, ElastiCache con Valkey o Redis viene OSS ridimensionato di default almeno del 20 percento, il che si traduce in 60 shard per cluster.
Ad esempio, se hai selezionato un valore Target del 60 percento, ElastiCache con Valkey o Redis non verrà eseguito lo scaling automatico finché la metrica OSS non sarà inferiore o uguale al 45 percento (25 percento inferiore al 60 percento di Target).
Considerazioni su Auto Scaling
Tieni a mente le seguenti considerazioni:
-
Una policy di dimensionamento di monitoraggio obiettivi presuppone che essa debba eseguire un dimensionamento orizzontale quando il parametro specificato supera il valore di destinazione. Non è possibile utilizzare una politica di ridimensionamento del tracciamento del target per la scalabilità orizzontale quando la metrica specificata è inferiore al valore target. ElastiCache con Valkey o Redis, OSS ridimensiona gli shard con una deviazione minima del 20% rispetto all'obiettivo degli shard esistenti nel cluster.
-
Una policy di dimensionamento di monitoraggio obiettivi non esegue il dimensionamento quando il parametro specificato non dispone di dati sufficienti. Non esegue la riduzione orizzontale perché l’insufficienza di dati non viene interpretata come basso utilizzo.
-
Potrebbero esserci delle differenze tra il valore di destinazione e i punti di dati dei parametri reali. Questo perché ElastiCache con Valkey o Redis Auto OSS Scaling agisce sempre in modo conservativo arrotondando verso l'alto o verso il basso quando determina quanta capacità aggiungere o rimuovere. In questo modo si impedisce l'aggiunta di capacità insufficiente o la rimozione di capacità eccessiva.
-
Per garantire la disponibilità delle applicazioni, il servizio aumenta in proporzione al parametro il più veloce possibile, ma si riduce in modo più conservativo.
-
È possibile disporre di più politiche di scalabilità di tracciamento degli obiettivi per un OSS cluster ElastiCache with Valkey o Redis, a condizione che ciascuna di esse utilizzi una metrica diversa. L'intenzione di ElastiCache (RedisOSS) Auto Scaling è quella di dare sempre la priorità alla disponibilità, quindi il suo comportamento varia a seconda che le policy di tracciamento di destinazione siano pronte per la scalabilità orizzontale o verticale. Il servizio viene aumentato se una qualsiasi delle policy di monitoraggio obiettivi è pronta per l'aumento, ma viene ridotto solo se tutte le policy di monitoraggio obiettivi (con la porzione di riduzione abilitata) sono pronte per la riduzione.
-
Non modificate o eliminate gli CloudWatch allarmi che ElastiCache con Valkey o Redis OSS Auto Scaling gestiscono una politica di scalabilità di tracciamento degli obiettivi. ElastiCache Auto Scaling elimina automaticamente gli allarmi quando si elimina la politica di ridimensionamento.
-
ElastiCache L'Auto Scaling non impedisce di modificare manualmente gli shard del cluster. Queste regolazioni manuali non influiscono sugli CloudWatch allarmi esistenti associati alla politica di scalabilità, ma possono influire sulle metriche che potrebbero attivare questi allarmi. CloudWatch
-
Questi CloudWatch allarmi gestiti da Auto Scaling sono definiti sulla base AVG della metrica su tutti gli shard del cluster. Quindi, avere frammenti caldi può comportare uno scenario di:
-
ridimensionamento quando non necessario a causa del caricamento su alcuni hot shard che fa scattare un allarme CloudWatch
-
non si ridimensiona quando necessario a causa dell'aggregazione di AVG tutti i frammenti che influiscono sull'allarme da non violare.
-
-
ElastiCache con Valkey o Redis si applicano ancora i limiti OSS predefiniti sui nodi per cluster. Pertanto, quando si opta per il Auto Scaling e se si prevede che i nodi massimi siano superiori al limite di default, è necessario richiedere un aumento del limite aAWS Restrizioni dei servizie scegliere il tipo di limiteNodi per cluster per tipo di istanza.
-
Assicurati di avere abbastanza interfacce di rete ENIs (Elastic Network Interface) disponibili nel tuo dispositivoVPC, necessarie durante la scalabilità orizzontale. Per ulteriori informazioni, consulta Interfacce di rete elastiche.
-
Se non è disponibile una capacità sufficienteEC2, ElastiCache Auto Scaling non scalerà e verrà ritardato fino a quando la capacità non sarà disponibile.
-
ElastiCache (RedisOSS) Auto Scaling durante lo scale-in non rimuoverà gli shard con slot con una dimensione dell'elemento superiore a 256 MB dopo la serializzazione.
-
Durante la scale-in non rimuoverà i frammenti se la memoria disponibile è insufficiente nella configurazione di partizioni risultante.
