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 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.

etcd è un database chiave-valore 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 Computing Foundation.

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.

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 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.

Nel 2014, gli sviluppatori di etcd hanno implementato il database in 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.