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.
Escolha 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 keyspace 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 ter uma performance de preço melhor, faça escalonar horizontalmente horizontal 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ós disponíveis você escolhe:
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âncias 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 do nó vai mostrar o limite de armazenamento quando você definir 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 | 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 Memorystore para Redis Cluster, 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 destas ações:
- Adicione fragmentos à instância. Isso é escalonar horizontalmente a instância.
- Remova fragmentos da instância. Isso está escalonando a instância para dentro.
- 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 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 escolhido.
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ó | Capacidade máxima considerando um formato de cluster de 62 nós principais e 3 réplicas por nó | Capacidade máxima para um cluster com 50 nós principais e 4 réplicas por nó | Capacidade máxima considerando um formato de cluster de 41 nós principais e 5 réplicas por nó |
|---|---|---|---|---|---|---|
| redis-shared-core-nano - 1,4 GB | 350 GB | 175 GB | 116,2 GB | 86,8 GB | 70 GB | 57,4 GB |
| redis-standard-small: 6,5 GB | 1.625 GB | 812,5 GB | 539,5 GB | 403 GB | 325 GB | 266,5 GB |
| redis-highmem-medium - 13 GB | 3.250 GB | 1.625 GB | 1.079 GB | 806 GB | 650 GB | 533 GB |
| redis-highmem-xlarge: 58 GB | 14.500 GB | 7.250 GB | 4.814 GB | 3.596 GB | 2.900 GB | 2.378 GB |
Desempenho
Usando a ferramenta de comparativo de mercado memtier do OSS na região us-central1, foram obtidas 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 fazer o bootstrap dos clientes de cluster do Redis OSS, mantendo-os atualizados em estado estável. A topologia do 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. Em seguida, o cliente cuida das atualizações e dos 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 no nó de back-end ou atualizações de nó.
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 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 do 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. O aplicativo não pode ter dependências ou pressupostos de que os endpoints de nós vão permanecer inalterados em um determinado cluster.
Endpoint de dados
Além do endpoint de descoberta, cada cluster tem um endpoint de dados. Esse endpoint é reservado para o Memorystore for Redis Cluster usar para conectar seu cliente a nós no cluster. Portanto, não se conecte diretamente a esse endpoint.