Nesta página, descrevemos as especificações de cluster e nó para instâncias do Memorystore for Redis Cluster. Para instruções sobre como criar uma instância, consulte Criar instâncias.
Escolher um tipo de nó
Os fragmentos no cluster usam o mesmo tipo de nó escolhido. O melhor tipo de nó para seu cluster depende dos seus requisitos de preço, desempenho e capacidade do keyspace.
O tipo de nó redis-shared-core-nano é para cargas de trabalho pequenas. Esse tipo de nó oferece performance variável e não tem um SLA, o que o torna inadequado para cargas de trabalho de produção.
O tipo de nó redis-standard-small permite provisionar clusters pequenos e aumentar o cluster em incrementos menores a custos potencialmente mais baixos do que outros tipos de nós. O redis-standard-small também oferece a vantagem de distribuir seu espaço de chaves em mais nós com uma contagem total maior de vCPUs. Isso oferece uma melhor relação preço-performance em comparação com redis-highmem-medium, desde que a capacidade total do espaço de chaves dos nós menores seja suficiente para suas necessidades de dados.
Recomendamos escolher o tipo de nó redis-highmem-xlarge somente se você precisar de mais capacidade de cluster do que o redis-highmem-medium oferece. Embora o tipo de nó redis-highmem-xlarge seja quatro vezes maior que o tipo redis-highmem-medium, o desempenho não é quatro vezes maior, já que o desempenho do Redis não é escalonado linearmente quando vCPUs são adicionadas a nós cada vez maiores (escalonamento vertical). Em vez disso, para melhorar a performance de preço, aumente a escala adicionando mais nós a um cluster.
Especificação do tipo de nó
A capacidade e as características do nó dependem de qual dos quatro tipos de nó disponíveis você escolher:
Capacidade do keyspace e sobrecarga reservada
| Tipo de nó | Capacidade padrão do keyspace gravável | Capacidade total do nó |
|---|---|---|
| redis-shared-core-nano | 1,12 GB | 1,4 GB |
| redis-standard-small | 5,2 GB | 6,5 GB |
| redis-highmem-medium | 10,4 GB | 13 GB |
| redis-highmem-xlarge | 46,4 GB | 58 GB |
O Memorystore reserva automaticamente uma parte da capacidade da instância para evitar erros de falta de memória (OOM). Isso garante uma experiência tranquila de leitura e gravação de chaves. Os limites de memória e detalhes de armazenamento são os seguintes:
Personalizar seu armazenamento:embora recomendemos usar as configurações padrão, você pode ajustar a quantidade de armazenamento reservado usando a configuração
maxmemory. Para informações sobremaxmemory, consulte Configurações de instância compatíveis.Quanto espaço de armazenamento você tem? Consulte a coluna Capacidade padrão do keyspace gravável da tabela anterior. Isso mostra quanto armazenamento está disponível para suas chaves por padrão.
Maximizar o armazenamento: se você quiser o máximo de armazenamento possível, a coluna Capacidade total de nós mostra o limite de armazenamento quando você define a configuração
maxmemorycomo 100%. No entanto, não recomendamos escolher um valor demaxmemorymaior que a configuração padrão.O tipo de nó
redis-shared-core-nanotem um limite fixo de 1, 12 GB e não pode ser alterado com a configuraçãomaxmemory.
Características do nó
| Tipo de nó | Contagem de vCPU | SLA oferecido | Número máximo de clientes | Memória máxima para clientes (configuração maxmemory-clients) |
|---|---|---|---|---|
| redis-shared-core-nano | 0,5 | Não | 5.000 | 12% |
| redis-standard-small | 2 | Sim | 16.000 (padrão). O valor máximo é 32.000 | 7% |
| redis-highmem-medium | 2 | Sim | 32.000 (padrão). O valor máximo é 64.000 | 7% |
| redis-highmem-xlarge | 8 | Sim | 64.000 | 4% |
Quanto mais CPUs virtuais (vCPUs) você selecionar para o cluster, melhor será o desempenho. Se o cluster executar cargas de trabalho que exigem muitos recursos, selecione um tipo de nó com um vCPU maior (por exemplo, redis-highmem-xlarge). Se o cluster executar tarefas menos exigentes, selecione um tipo de nó com um vCPU menor (por exemplo, redis-highmem-medium).
Dimensionar uma instância
Ao criar uma instância do cluster do Memorystore para Redis, você escolhe um tipo de nó e especifica o número de fragmentos. Depois de criar a instância e conforme as necessidades de capacidade dela mudam, talvez seja necessário escalonar a instância das seguintes maneiras:
- Mude o número de fragmentos da instância. Isso é chamado de escalonamento horizontal.
Para escalonar uma instância horizontalmente, faça uma das seguintes ações:
- Adicione fragmentos à instância. Isso está escalonando a instância horizontalmente.
- Remova fragmentos da instância. Isso está escalonando a instância in.
- Mude o tipo de nó da instância. Isso é chamado de escalonamento vertical. Para escalonar uma instância verticalmente, mude o tipo de nó dela para um dos seguintes:
- Mude para um tipo de nó maior. Isso é escalonar a instância verticalmente.
- Mude para um tipo de nó menor. Isso está reduzindo a escala da instância.
Especificação do cluster
Esta seção mostra as capacidades mínima e máxima do cluster, considerando o formato, o tipo de nó e a contagem de réplicas.
Capacidade mínima gravável
A capacidade gravável é a quantidade de armazenamento disponível para gravar chaves. Ele é igual ao tamanho de um nó de instância. Portanto, dependendo do tipo de nó, a capacidade mínima gravável é de 1,4 GB, 6,5 GB, 13 GB ou 58 GB. A capacidade mínima gravável não é afetada pelo número de réplicas escolhidas.
Capacidade máxima gravável
| Tipo e tamanho do nó | Capacidade máxima para um cluster com 250 nós principais e 0 réplicas por nó | Capacidade máxima considerando um cluster com 125 nós principais e uma réplica por nó | Capacidade máxima considerando um formato de cluster de 83 nós principais e duas réplicas por nó |
|---|---|---|---|
| redis-shared-core-nano - 1,4 GB | 350 GB | 175 GB | 116,2 GB |
| redis-standard-small: 6,5 GB | 1.625 GB | 812,5 GB | 539,5 GB |
| redis-highmem-medium - 13 GB | 3.250 GB | 1.625 GB | 1.079 GB |
| redis-highmem-xlarge: 58 GB | 14.500 GB | 7.250 GB | 4.814 GB |
Desempenho
Usar a ferramenta de comparativo de mercado memtier do OSS na região us-central1 gerou de 120.000 a 130.000 operações por segundo por nó de 2 vCPUs (redis-standard-small e redis-highmem-medium) com latência de microssegundos e tamanho de dados de 1 KiB.
Recomendamos que você faça seu próprio comparativo de mercado com cargas de trabalho reais ou sintéticas que se pareçam com seu tráfego de produção. Além disso, recomendamos que você dimensione seus clusters com um buffer (ou "headroom") para picos de carga de trabalho ou tráfego inesperado. Para mais orientações, consulte Práticas recomendadas para o cluster do Memorystore para Redis.
Endpoints do cluster
Esta seção explica os dois endpoints que cada instância tem.
Endpoint de descoberta
Cada instância tem um endpoint de descoberta a que seu cliente se conecta. É uma combinação de um endereço IP e um número de porta. Para instruções sobre como encontrar o endpoint de descoberta do cluster, consulte Ver o endpoint de descoberta do cluster.
Seu cliente também o usa para descoberta de nós. Seu cliente usa o endpoint de descoberta para recuperar a topologia de cluster da sua instância e inicializar os clientes de cluster do Redis OSS, mantendo-os atualizados em estado estável. A topologia de cluster resultante fornece endpoints de nós do Redis (combinações de IP e porta) para serem armazenados em cache na memória pelo cliente do cluster do Redis. O cliente cuida das atualizações e redirecionamentos automaticamente, sem necessidade de outras mudanças no aplicativo. Para informações sobre o comportamento de descoberta de clientes e práticas recomendadas, consulte Descoberta de clientes.
O endpoint de descoberta é altamente disponível porque é apoiado por vários nós do Redis em várias zonas para atender à topologia do cluster. A veiculação da topologia pelo endpoint é robusta, mesmo quando há falhas ou atualizações de nós de back-end.
O endpoint de descoberta tem o seguinte comportamento:
O endpoint de descoberta do cluster permanece inalterado durante todo o ciclo de vida da instância, mesmo durante a manutenção ou por qualquer outra ação realizada, como escalonamento horizontal ou vertical ou mudança na contagem de réplicas.
Os endpoints de nós do Redis podem mudar e ser reciclados à medida que os nós são adicionados e removidos ao longo do tempo. O ideal é usar um cliente de cluster Redis que possa processar essas mudanças automaticamente por atualizações e redirecionamentos de topologia. Exemplos de clientes de cluster do Redis podem ser encontrados em Exemplos de código da biblioteca de cliente. Seu aplicativo não pode ter dependências ou pressupostos de que os endpoints de nós vão permanecer inalterados para um determinado cluster.
Endpoint de dados
Cada instância também tem um endpoint de dados do Private Service Connect que o Memorystore para Redis Cluster usa para conexão do cliente. Não se conecte diretamente a ele. No entanto, o Memorystore para Redis Cluster usa esse endpoint para conectar seu cliente aos nós do cluster.