Configurações mínimas do cluster

Neste tópico, descrevemos as configurações mínimas de cluster para a Apigee híbrida. Essas configurações mínimas se aplicam a todas as plataformas Kubernetes compatíveis. As recomendações neste tópico se aplicam a instalações que não são de produção, como cenários de teste. Lembre-se dessas recomendações ao realizar as etapas de instalação da Apigee híbrida.

Sobre pools de nós

Um pool de nós é um grupo de nós em um cluster, que têm a mesma configuração. Por padrão, o híbrido atribui todos os pods ao pool de nós padrão; No entanto, é possível criar pools de nós dedicados e atribuir componentes híbridos a eles como uma maneira de distribuir recursos.

Normalmente, você define pools de nós separados quando tem pods com requisitos de recursos diferentes. Por exemplo, os pods apigee-cassandra exigem armazenamento permanente, e os outros pods híbridos da Apigee não. Por esse motivo, recomendamos que você crie um pool de nós com estado para Cassandra e um pool de nós sem estado para o restante dos serviços de ambiente de execução híbridos. Consulte Configurar pools de nós dedicados para mais detalhes.

Na seção a seguir, você vê uma lista das configurações dos pools de nós com estado e sem estado.

Configurações mínimas

Use estas configurações mínimas ao configurar seu cluster:

Configuração Pool de nós com estado Pool de nós sem estado
Finalidade Um pool de nós com estado usado para o banco de dados do Cassandra. Um pool de nós sem estado usado pelo processador de mensagens do ambiente de execução.
Nome do rótulo apigee-data apigee-runtime
Número de nós 1 por zona (3 por região) 1 por zona (3 por região)
CPU 4 4
RAM 15 15
Armazenamento dynamic Gerenciada com o CRD ApigeeDeployment
IOPS mínimas do disco 2.000 IOPS com SAN ou armazenamento anexado diretamente. O NFS não é recomendado, mesmo que seja compatível com as IOPS necessárias. 2.000 IOPS com SAN ou armazenamento anexado diretamente. O NFS não é recomendado, mesmo que seja compatível com as IOPS necessárias.

Requisitos de rede do Cassandra

O Cassandra usa o protocolo Gossip para trocar informações com outros nós sobre a topologia de rede.

O uso do Gossip e da natureza distribuída do Cassandra, que envolve a comunicação com vários nós para operações de leitura e gravação, resulta em muita transferência de dados pela redes.

A Apigee recomenda usar um tipo de instância com uma largura de banda de rede mínima de 1 Gbps e mais de 1 Gbps para sistemas de produção.

Os clusters do Cassandra precisam de três zonas de disponibilidade para manter a disponibilidade em um ambiente de produção. Se uma zona ficar inativa, as restantes continuarão respondendo a solicitações até a zona remanescente ficar on-line novamente. Se duas ou mais zonas ficarem inativas, o Cassandra não responderá a solicitações até que pelo menos duas zonas fiquem on-line. A Apigee recomenda colocar as zonas on-line novamente em três horas para minimizar o risco de perda de atualizações de dados.

Ao implantar ambientes híbridos multirregionais, a Apigee recomenda usar uma solução de VPN ou nuvem, como o Google Cloud VPN, para proteger a conectividade entre as regiões. Verifique se não há sub-redes sobrepostas, porque elas podem causar problemas de conectividade do Cassandra. Verifique se as configurações atuais de firewall permitem que o tráfego do Cassandra passe entre os pods do Cassandra. Consulte informações sobre as portas do Cassandra em Uso de portas seguras.

A latência máxima ou do 99º percentil do Cassandra deve ser inferior a 100 milissegundos.

Requisitos de NTP do Cassandra

Os dados do Cassandra são sincronizados com base no carimbo de data/hora do sistema. Verifique se o horário está sincronizado em todos os pods e em todas as regiões no cluster do Cassandra. Atrasos entre os nós e as regiões causam inconsistências de dados.

Como escalonar a configuração

Se você precisar escalonar a configuração inicial com base em outras necessidades de capacidade ou capacidade, consulte os tópicos a seguir: