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ó
Todos 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
keyspace 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.
Se você tiver cargas de trabalho que exigem uma taxa maior de capacidade de processamento em relação à memória, escolha o tipo de nó redis-highcpu-medium. Se você precisar de mais capacidade do que o redis-highmem-medium oferece, recomendamos escolher os tipos de nó redis-standard-large, redis-highmem-xlarge ou redis-highmem-2xlarge. Quando você adiciona vCPUs a nós cada vez maiores (escalonamento vertical),
o desempenho do Redis pode não ser escalonado de forma linear. Em vez disso, para ter uma melhor relação preço-performance, recomendamos que você aumente a escala horizontal adicionando mais nós a um cluster.
Especificação do tipo de nó
A capacidade e as características do nó dependem do tipo de nó escolhido:
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-highcpu-medium | 10,4 GB | 13 GB |
| redis-standard-large | 20,8 GB | 26 GB |
| redis-highmem-xlarge | 46,4 GB | 58 GB |
| redis-highmem-2xlarge | 88 GB | 110 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 os 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 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 | Número padrão de conexões de cliente | Número máximo de conexões de clientes | Memória máxima para clientes (configuração maxmemory-clients) |
|---|---|---|---|---|---|
| redis-shared-core-nano | 0,5 | Não | 5.000 | 5.000 | 12% |
| redis-standard-small | 2 | Sim | 16.000 | 32.000 | 7% |
| redis-highmem-medium | 2 | Sim | 32.000 | 64.000 | 7% |
| redis-highcpu-medium | 8 | Sim | 32.000 | 64.000 | 7% |
| redis-standard-large | 8 | Sim | 32.000 | 64.000 | 7% |
| redis-highmem-xlarge | 8 | Sim | 64.000 | 64.000 | 4% |
| redis-highmem-2xlarge | 16 | Sim | 64.000 | 64.000 | 4% |
Quanto mais CPUs virtuais (vCPUs) você selecionar para o cluster, melhor será a performance. Se o cluster executar cargas de trabalho que consomem muitos recursos, selecione um tipo de nó com uma vCPU maior (por exemplo, redis-highmem-xlarge). Se o cluster executar tarefas menos exigentes, selecione um tipo de nó com uma vCPU menor (por exemplo, redis-highmem-medium).
Dimensionar uma instância
Ao criar uma instância do Memorystore for Redis Cluster, você escolhe um tipo de nó para a instância e especifica o número de fragmentos para a instância. 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 os 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 tipos:
- Mude para um tipo de nó maior. Isso está aumentando a instância.
- 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 gravação de chaves. Ele é igual ao tamanho de um nó de instância. Portanto, dependendo do tipo de nó, a capacidade mínima gravável fica entre 1,4 GB e 110 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 considerando um formato de cluster de 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-núcleo compartilhado-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-highcpu-medium - 13 GB | 3.250 GB | 1.625 GB | 1.079 GB | 806 GB | 650 GB | 533 GB |
| redis-standard-large - 26 GB | 6.500 GB | 3.250 GB | 2.158 GB | 1.612 GB | 1.300 GB | 1.066 GB |
| redis-highmem-xlarge: 58 GB | 14.500 GB | 7.250 GB | 4.814 GB | 3.596 GB | 2.900 GB | 2,378 GB |
| redis-highmem-2xlarge: 110 GB | 27.500 GB | 13.750 GB | 9.130 GB | 6.820 GB | 5.500 GB | 4.510 GB |
Desempenho
Usando a ferramenta de comparativo de mercado memtier do OSS na região us-central1, foram geradas 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 do cluster do Memorystore para Redis.
Endpoints de cluster
Esta seção explica os dois endpoints de cada instância.
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, inicializar clientes de cluster do Redis OSS e mantê-los 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. Depois disso, 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 tem alta disponibilidade 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 qualquer outra ação realizada, como escalonamento horizontal ou vertical ou alteração da 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. Seu aplicativo não pode ter dependências ou pressupostos de que os endpoints de nó vão permanecer inalterados para 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.