Questo documento definisce i concetti di base e le topologie di deployment per Spanner Omni. Descrive la relazione gerarchica tra regioni, zone e server e spiega come questi componenti si relazionano alla replica e all'archiviazione dei dati all'interno di un deployment.
Concetti di Spanner Omni
Le sezioni seguenti forniscono definizioni dettagliate della terminologia utilizzata in tutta la documentazione di Spanner Omni. Familiarizzare con questi concetti garantisce una chiara comprensione dell'architettura e del comportamento operativo del sistema.
Deployment
Un deployment di Spanner Omni, che ti consente di utilizzare i database nei tuoi data center o nei tuoi account cloud pubblico. Crei il deployment in base ai parametri specificati nella configurazione del deployment. Un deployment di Spanner Omni equivale a un'istanza Spanner inGoogle Cloud.
Configurazione del deployment
Fornisce il posizionamento e la specifica di regioni, zone e server per il deployment di Spanner Omni. Puoi scegliere una singola configurazione di deployment di server, regione o più regioni.
Località
L'equivalente della regione nei termini di Google Cloud . La latenza di rete tra due regioni non è trascurabile. Per i deployment on-premise, puoi definire le tue regioni. Per i deployment cloud, la regione deve essere allineata alle regioni del rispettivo cloud provider. Una regione può avere più zone.
Processo
Il server Spanner esegue il fork e gestisce più processi. Ad esempio, TimeServer e spanserver sono tutti processi in Spanner. I singoli processi possono avere statistiche di monitoraggio come l'utilizzo di CPU e memoria. Un processo può aprire le porte per comunicare con altri server nel deployment.
Replica
Spanner replica i dati per garantire la disponibilità dei dati e la località geografica. A livello generale, Spanner organizza tutti i dati in righe. Spanner crea più copie o repliche di queste righe, quindi le archivia in diverse aree geografiche. Spanner utilizza uno schema di replica sincrono basato su Paxos, in cui le repliche di voto votano ogni richiesta di scrittura prima di eseguire il commit della scrittura nel database. Come in Spanner, in Spanner Omni esistono tre tipi di replica: lettura/scrittura, sola lettura e testimone. Per saperne di più, consulta Tipi di replica nella documentazione di Spanner.
Server
Un server è una risorsa di calcolo, ad esempio una VM o un container, in cui viene eseguito il server Spanner Omni. Ogni server ha le proprie risorse di sistema: CPU, memoria e spazio di archiviazione. Il server fornisce le funzionalità di Spanner Omni memorizzando e gestendo i dati degli utenti.
Server radice
I server radice archiviano metadati critici per supportare la zona. Ad esempio, il server radice memorizza l'appartenenza al server e altre informazioni di configurazione della zona.
Il numero di server radice per zona deve essere un numero dispari compreso tra 1 e 9 inclusi, per garantire il quorum per la coerenza. Se il numero di server è pari, i deployment potrebbero non riuscire. Quando configuri le zone, designa i server come server radice. Ti consigliamo di utilizzarne una per lo sviluppo o i test e tre per le zone di produzione ad alta disponibilità.
Valuta attentamente il numero di server radice durante la pianificazione del deployment. Anche se puoi modificare il numero di server radice nel deployment dopo averlo creato, non è consigliabile.
Server non root
I server non root archiviano e pubblicano i dati utente e forniscono un modo per scalare la capacità di calcolo e l'archiviazione di una zona. Puoi aggiungere al deployment tutti i server non root necessari per il workload. Puoi modificare il numero di server non root dopo aver creato il deployment.
Suddividi
Una suddivisione Spanner contiene un intervallo di righe di dati contigue, in cui Spanner ordina le righe in base alla chiave primaria. Spanner crea repliche di ogni suddivisione che memorizza in ogni zona.
Archiviazione
Lo spazio di archiviazione permanente collegato al server.
Zona
Un gruppo di uno o più server. Per la replica dei dati, devi creare una zona per replica. Per i deployment on-premise, consigliamo di ridurre al minimo la condivisione dell'infrastruttura (VM, dischi) tra le zone. Per i deployment cloud, allinea le zone alle zone di disponibilità in AWS o alle zone in Google Cloud.