# etcd: un database per coppie chiave-valore

Nel panorama informatico, i sistemi distribuiti come le piattaforme cloud stanno acquisendo un’importanza sempre maggiore. I singoli [database](https://www.ionos.it/digitalguide/hosting/tecniche-hosting/database/) stanno cedendo il posto a cluster flessibili e scalabili. A una lunga serie di nuove sfide che questo cambio di paradigma comporta si accompagnano altrettanti grattacapi per molti responsabili nel settore dell’informatica: blackout di rete, ritardi, limitazioni del flusso di dati, componenti del sistema su piccola scala e il grande tema della sicurezza nel trasporto dei dati sono questioni con le quali gli amministratori si ritrovano a dover fare i conti.

Una possibile soluzione è rappresentata da **un luogo centrale per le informazioni modificabili** che sia a prova di errore, stabile e coerente, come il pratico database di archivio chiave-valore etcd.

## Che cos’è etcd?

etcd è un [database chiave-valore](https://www.ionos.it/digitalguide/hosting/tecniche-hosting/key-value-store/ "Key Value Store") distribuito, sviluppato dal team CoreOS e scritto in Go, il linguaggio di Google, come molti strumenti in ambiente Docker. L’obiettivo del team di sviluppo era quello di creare un **luogo di archiviazione sicuro per i dati critici** delle applicazioni distribuite, così da renderne più semplice la gestione.

etcd prende il nome dalla directory per i file di configurazione nei sistemi operativi GNU/Linux “/etc”, mentre la “d” finale sta per “distributed”(distribuito). Il database etcd è **gestito come software open source** dalla [Cloud Native](https://www.ionos.it/digitalguide/siti-web/programmazione-del-sito-web/che-cosa-significa-cloud-native/ "Che cosa significa cloud native?") Computing Foundation.

## Come funziona etcd?

Per poter comprendere la logica di etcd, è fondamentale conoscere i tre concetti chiave del cluster di applicazioni per quanto riguarda la gestione dello spazio di archiviazione:

- **capi** (leader)
- **elezioni** (elections)
- **periodi** (terms)

Nei sistemi basati su Raft, il cluster elegge un leader per un determinato periodo di tempo. Questo gestisce tutte le richieste di archiviazione che ottengono il consenso del cluster. Le richieste che non richiedono il consenso del cluster, come gli accessi in lettura, possono essere risposte indipendentemente da qualsiasi membro del cluster. Se il leader accetta un cambiamento, etcd si assicura che l’**informazione venga replicata ai nodi successivi**. Una volta che questi ne hanno confermato la ricezione, il leader attua il cambiamento.

Il coordinamento del leader con i nodi del cluster attraverso un database etcd si rivela particolarmente prezioso nelle applicazioni distribuite. Se le modifiche influenzano il funzionamento di un determinato nodo, questo può andare a bloccarne l’attuazione. Il coordinamento assicura che l’**applicazione funzioni in modo stabile e riduce al minimo i problemi conseguenti**.

Se il leader cessa di funzionare o non risponde in modo prolungato ai comandi, trascorso un determinato intervallo di tempo i nodi rimanenti del cluster **eleggono** un nuovo leader. Il lasso di **tempo** che intercorre dal momento in cui un nodo **chiede di eleggere un nuovo leader** e **si autodesigni come candidato** varia da nodo a nodo ed è determinato per mezzo di un “cronometro” che ogni nodo possiede. Ciò fa sì che i nodi siano in grado di andare a sostituire il leader il più rapidamente possibile.

Affinché si possa sempre raggiungere una maggioranza, il numero di nodi nel cluster deve essere dispari. Per motivi di prestazioni, è raccomandabile non utilizzare un cluster che abbia più di sette nodi.

Consiglio È possibile testare etcd eseguendolo su un computer portatile o in una semplice configurazione cloud. Poiché etcd scrive dati su disco, l’utilizzo di un’unità a stato solido (SSD) è fortemente raccomandato. Vi raccomandiamo di seguire le linee guida mostrate nella [documentazione ufficiale](https://github.com/etcd-io/website/ "Documentazione ufficiale di etcd").

## I vantaggi di etcd

Oltre a rendere l’applicazione stabile, l’utilizzo di un database etcd porta con sé numerosi altri benefici.

- **Completamente replicabile:** tutta la memoria è disponibile su ogni nodo del cluster.
- **Elevata disponibilità**: i database etcd offrono il vantaggio di neutralizzare le singole fonti di errori come i problemi hardware o di rete.
- **Coerente**: attraverso più host, ogni operazione di lettura fornisce l’ultima operazione di scrittura.
- **Semplice**: etcd include una [API (gRPC) orientata all’utente](https://www.ionos.it/digitalguide/server/know-how/introduzione-al-grpc/) ben definita, basata su REST e JSON.
- **Sicuro**: etcd implementa automaticamente una trasmissione sicura tramite SSL/TLS; a scelta, è possibile utilizzare l’autenticazione tramite certificato del client.
- **Veloce**: il benchmark supporta più di 10.000 processi di scrittura al secondo.
- **Affidabile**: l’algoritmo Raft assicura sempre una corretta distribuzione della memoria.

## Un esempio di etcd: come si comporta l’archivio chiave-valore quando è in azione

Nel 2014, gli sviluppatori di etcd hanno implementato il database in [Kubernetes](https://www.ionos.it/digitalguide/server/know-how/che-cose-kubernetes/), creando così le condizioni per una rapida crescita della comunità etcd. I fornitori di cloud come AWS, Google Cloud Platform e Azure hanno presto intuito il potenziale di etcd, implementandolo con altrettanto successo nei rispettivi ambienti di produzione.

Concentriamoci però sul **primo esempio di implementazione di etcd, ovvero Kubernetes**. Kubernetes è un sistema distribuito che gira su un cluster di più macchine. Di conseguenza, beneficia enormemente di un **archivio dati distribuito** come etcd per **mantenere i dati critici al sicuro**. All’interno di Kubernetes, il database etcd funge da archivio dati primario, memorizzando i dati di configurazione, lo stato e i metadati. Se vengono apportate delle modifiche, etcd assicura che **tutti i nodi del cluster Kubernetes possano leggere e scrivere i dati**. Allo stesso tempo, etcd **monitora** lo stato attuale o desiderato del sistema: se gli stati differiscono, Kubernetes apporta le modifiche necessarie per il loro riallineamento.

N.B. Il comando “kubectl” è usato per recuperare un valore di lettura dal database di etcd. Le modifiche fatte con “kubectl apply” creano o aggiornano le voci presenti all’interno dell’archivio etcd. Qualsiasi crash del sistema cambia automaticamente i valori in etcd.


This is a markdown version of: [https://www.ionos.it/digitalguide/hosting/tecniche-hosting/che-cose-etcd/](https://www.ionos.it/digitalguide/hosting/tecniche-hosting/che-cose-etcd/) for AI/LLM consumption.