Configurazioni minime del cluster

Questo argomento descrive le configurazioni minime del cluster per Apigee hybrid. Queste configurazioni minime si applicano a tutte le Piattaforme Kubernetes. I consigli contenuti in questo argomento si applicano alle installazioni non di produzione, ad esempio scenari di prova o test. Conserva a questi suggerimenti durante l'esecuzione dei passaggi di installazione ibrida di Apigee.

Informazioni sui pool di nodi

Un pool di nodi è un gruppo di nodi all'interno di un cluster che hanno tutti la stessa configurazione. Di Il modello ibrido assegna tutti i pod al pool di nodi predefinito. ma puoi creare modelli pool di nodi e assegnarvi componenti ibridi per distribuire le risorse.

In genere, definisci i pool di nodi dedicati quando hai pod con requisiti di risorse diversi. Ad esempio, i pod apigee-cassandra richiedono uno spazio di archiviazione permanente, mentre gli altri pod ibride Apigee no. Per questo motivo, ti consigliamo di creare un pool di nodi stateful per Cassandra e un pool di nodi stateless per il resto dei servizi di runtime ibridi. Consulta Configurare pool di nodi dedicati per i dettagli.

La sezione seguente elenca le configurazioni per i pool di nodi stateful e stateless.

Configurazioni minime

Utilizza queste configurazioni minime durante la configurazione del cluster:

Configurazione Pool di nodi con stato Pool di nodi senza stato
Finalità Un pool di nodi con stato utilizzato per il database Cassandra. Un pool di nodi senza stato utilizzato dal processore di messaggi di runtime.
Nome dell'etichetta apigee-data apigee-runtime
Numero di nodi 1 per zona (3 per regione) 1 per zona (3 per regione)
CPU 4 4
RAM 15 15
Archiviazione dinamica Gestito con il CRD ApigeeDeployment
IOPS disco minime 2000 IOPS con SAN o archiviazione direttamente collegata. NFS non è consigliato anche se può supportare le IOPS richieste. 2000 IOPS con SAN o archiviazione direttamente collegata. La funzionalità NFS non è consigliata anche se può supportare le IOPS richieste.

Requisiti di rete Cassandra

Cassandra utilizza protocollo Gossip per scambiano informazioni con altri nodi sulla topologia di rete.

L'utilizzo di Gossip e la natura distribuita di Cassandra, che prevede l'interazione con più nodi per le operazioni di lettura e scrittura, comportano un elevato trasferimento di dati attraverso la rete.

Apigee consiglia di utilizzare un tipo di istanza con una larghezza di banda di rete minima di 1 Gbps e superiore a 1 Gbps per i sistemi di produzione.

I cluster Cassandra richiedono tre zone di disponibilità per mantenere la disponibilità in un nell'ambiente di produzione. Se una zona non è disponibile, le altre continueranno a rispondere alle richieste mentre la zona non disponibile torna online. Se due o più zone non sono disponibili, Cassandra non potrà rispondere alle richieste finché almeno due zone non torneranno online. Apigee consiglia di portare zone di nuovo online entro tre ore per ridurre al minimo il rischio di perdita di dati aggiornamenti.

Durante il deployment di ambienti ibridi multiregionali, Apigee consiglia di utilizzare una VPN o una soluzione cloud come Google Cloud VPN per proteggere la connettività tra regioni. Assicurati che non esistano subnet sovrapposte poiché potrebbero causare Problemi di connettività di Cassandra. Assicurati che le configurazioni firewall attuali consentano il passaggio del traffico Cassandra tra i pod Cassandra. Consulta: Utilizzo delle porte protette per le informazioni sulle porte Cassandra.

La latenza massima o del 99° percentile per Cassandra deve essere inferiore a 100 millisecondi.

Requisiti NTP di Cassandra

I dati di Cassandra si sincronizzano in base al timestamp del sistema. Assicurati che l'ora sia sincronizzata su tutti i pod e in tutte le regioni all'interno del cluster Cassandra. I ritardi tra i nodi e le regioni causano incoerenze nei dati.

Scalabilità della configurazione

Se devi scalare la configurazione iniziale in base a esigenze di capacità o throughput aggiuntive, consulta i seguenti argomenti: