etcd: un database per coppie chiave-valore

Nel panorama in­for­ma­ti­co, i sistemi di­stri­bui­ti come le piat­ta­for­me cloud stanno ac­qui­sen­do un’im­por­tan­za sempre maggiore. I singoli database stanno cedendo il posto a cluster fles­si­bi­li e scalabili. A una lunga serie di nuove sfide che questo cambio di paradigma comporta si ac­com­pa­gna­no al­tret­tan­ti grat­ta­ca­pi per molti re­spon­sa­bi­li nel settore dell’in­for­ma­ti­ca: blackout di rete, ritardi, li­mi­ta­zio­ni del flusso di dati, com­po­nen­ti del sistema su piccola scala e il grande tema della sicurezza nel trasporto dei dati sono questioni con le quali gli am­mi­ni­stra­to­ri si ritrovano a dover fare i conti.

Una possibile soluzione è rap­pre­sen­ta­ta da un luogo centrale per le in­for­ma­zio­ni mo­di­fi­ca­bi­li che sia a prova di errore, stabile e coerente, come il pratico database di archivio chiave-valore etcd.

etcd è un database chiave-valore di­stri­bui­to, svi­lup­pa­to dal team CoreOS e scritto in Go, il lin­guag­gio di Google, come molti strumenti in ambiente Docker. L’obiettivo del team di sviluppo era quello di creare un luogo di ar­chi­via­zio­ne sicuro per i dati critici delle ap­pli­ca­zio­ni di­stri­bui­te, così da renderne più semplice la gestione.

etcd prende il nome dalla directory per i file di con­fi­gu­ra­zio­ne nei sistemi operativi GNU/Linux “/etc”, mentre la “d” finale sta per “di­stri­bu­ted”(di­stri­bui­to). Il database etcd è gestito come software open source dalla Cloud Native Computing Foun­da­tion.

Per poter com­pren­de­re la logica di etcd, è fon­da­men­ta­le conoscere i tre concetti chiave del cluster di ap­pli­ca­zio­ni per quanto riguarda la gestione dello spazio di ar­chi­via­zio­ne:

• capi (leader)
• elezioni (elections)
• periodi (terms)

Nei sistemi basati su Raft, il cluster elegge un leader per un de­ter­mi­na­to periodo di tempo. Questo gestisce tutte le richieste di ar­chi­via­zio­ne che ottengono il consenso del cluster. Le richieste che non ri­chie­do­no il consenso del cluster, come gli accessi in lettura, possono essere risposte in­di­pen­den­te­men­te da qualsiasi membro del cluster. Se il leader accetta un cam­bia­men­to, etcd si assicura che l’in­for­ma­zio­ne venga replicata ai nodi suc­ces­si­vi. Una volta che questi ne hanno con­fer­ma­to la ricezione, il leader attua il cam­bia­men­to.

Il coor­di­na­men­to del leader con i nodi del cluster at­tra­ver­so un database etcd si rivela par­ti­co­lar­men­te prezioso nelle ap­pli­ca­zio­ni di­stri­bui­te. Se le modifiche in­fluen­za­no il fun­zio­na­men­to di un de­ter­mi­na­to nodo, questo può andare a bloccarne l’at­tua­zio­ne. Il coor­di­na­men­to assicura che l’ap­pli­ca­zio­ne funzioni in modo stabile e riduce al minimo i problemi con­se­guen­ti.

Se il leader cessa di fun­zio­na­re o non risponde in modo pro­lun­ga­to ai comandi, trascorso un de­ter­mi­na­to in­ter­val­lo di tempo i nodi rimanenti del cluster eleggono un nuovo leader. Il lasso di tempo che in­ter­cor­re dal momento in cui un nodo chiede di eleggere un nuovo leader e si au­to­de­si­gni come candidato varia da nodo a nodo ed è de­ter­mi­na­to per mezzo di un “cro­no­me­tro” che ogni nodo possiede. Ciò fa sì che i nodi siano in grado di andare a so­sti­tui­re il leader il più ra­pi­da­men­te possibile.

Affinché si possa sempre rag­giun­ge­re una mag­gio­ran­za, il numero di nodi nel cluster deve essere dispari. Per motivi di pre­sta­zio­ni, è rac­co­man­da­bi­le non uti­liz­za­re un cluster che abbia più di sette nodi.

Oltre a rendere l’ap­pli­ca­zio­ne stabile, l’utilizzo di un database etcd porta con sé numerosi altri benefici.

• Com­ple­ta­men­te re­pli­ca­bi­le: tutta la memoria è di­spo­ni­bi­le su ogni nodo del cluster.
• Elevata di­spo­ni­bi­li­tà: i database etcd offrono il vantaggio di neu­tra­liz­za­re le singole fonti di errori come i problemi hardware o di rete.
• Coerente: at­tra­ver­so più host, ogni ope­ra­zio­ne di lettura fornisce l’ultima ope­ra­zio­ne di scrittura.
• Semplice: etcd include una API (gRPC) orientata all’utente ben definita, basata su REST e JSON.
• Sicuro: etcd im­ple­men­ta au­to­ma­ti­ca­men­te una tra­smis­sio­ne sicura tramite SSL/TLS; a scelta, è possibile uti­liz­za­re l’au­ten­ti­ca­zio­ne tramite cer­ti­fi­ca­to del client.
• Veloce: il benchmark supporta più di 10.000 processi di scrittura al secondo.
• Af­fi­da­bi­le: l’algoritmo Raft assicura sempre una corretta di­stri­bu­zio­ne della memoria.

Nel 2014, gli svi­lup­pa­to­ri di etcd hanno im­ple­men­ta­to il database in Ku­ber­ne­tes, creando così le con­di­zio­ni per una rapida crescita della comunità etcd. I fornitori di cloud come AWS, Google Cloud Platform e Azure hanno presto intuito il po­ten­zia­le di etcd, im­ple­men­tan­do­lo con al­tret­tan­to successo nei ri­spet­ti­vi ambienti di pro­du­zio­ne.

Con­cen­tria­mo­ci però sul primo esempio di im­ple­men­ta­zio­ne di etcd, ovvero Ku­ber­ne­tes. Ku­ber­ne­tes è un sistema di­stri­bui­to che gira su un cluster di più macchine. Di con­se­guen­za, beneficia enor­me­men­te di un archivio dati di­stri­bui­to come etcd per mantenere i dati critici al sicuro. All’interno di Ku­ber­ne­tes, il database etcd funge da archivio dati primario, me­mo­riz­zan­do i dati di con­fi­gu­ra­zio­ne, lo stato e i metadati. Se vengono apportate delle modifiche, etcd assicura che tutti i nodi del cluster Ku­ber­ne­tes possano leggere e scrivere i dati. Allo stesso tempo, etcd monitora lo stato attuale o de­si­de­ra­to del sistema: se gli stati dif­fe­ri­sco­no, Ku­ber­ne­tes apporta le modifiche ne­ces­sa­rie per il loro rial­li­nea­men­to.