etcd: base de datos para pares clave-valor

Los sistemas di­s­tri­bui­dos, como las pla­ta­fo­r­mas en la nube, son cada vez más im­po­r­ta­n­tes. Por ello, las bases de datos in­di­vi­dua­les están cediendo el paso a los clústeres flexibles y es­ca­la­bles. Esto plantea una serie de nuevos retos para muchos ad­mi­ni­s­tra­do­res: los fallos de red, los retrasos, el volumen de datos limitado, los pequeños co­m­po­ne­n­tes de sistemas y la seguridad del tra­n­s­po­r­te de datos son algunos de los problemas más complejos que deben abordar.

Una posible solución es contar con una ubicación central para la in­fo­r­ma­ción cambiante que sea segura, a prueba de fallos y co­n­si­s­te­n­te: justo lo que ofrece la práctica base de datos de clave-valor etcd.

etcd es una base de datos de clave-valor di­s­tri­bui­da, de­sa­rro­lla­da por el equipo de CoreOS y, como muchas otras he­rra­mie­n­tas del entorno Docker, escrita en Go, el lenguaje de Google. El objetivo a la hora de de­sa­rro­llar­la era crear un espacio de al­ma­ce­na­mie­n­to seguro para los datos críticos de las apli­ca­cio­nes di­s­tri­bui­das, que fa­ci­li­ta­ra su su­pe­r­vi­sión.

Su nombre proviene de la carpeta de archivos de co­n­fi­gu­ra­ción de los sistemas ope­ra­ti­vos GNU/Linux, “/etc”, al que se añadió la “d” de di­s­tri­bu­ted (en español, “di­s­tri­bui­do”). Ac­tua­l­me­n­te, la Cloud Native Computing Fou­n­da­tion gestiona etcd como software de código abierto.

Para co­m­pre­n­der cómo funciona etcd, es im­po­r­ta­n­te conocer los tres términos clave del clúster de la apli­ca­ción para ad­mi­ni­s­trar bases de datos:

• Líder (leader)
• Ele­c­cio­nes (elections)
• Términos (terms)

En los sistemas basados en Raft, el clúster elige un líder por un cierto período de tiempo, que procesa todas las so­li­ci­tu­des de al­ma­ce­na­mie­n­to que están en consenso con el clúster. Cada in­te­gra­n­te del clúster puede responder de manera in­de­pe­n­die­n­te a las so­li­ci­tu­des que no requieren el co­n­se­n­ti­mie­n­to del clúster, como los accesos de solo lectura. Si el líder acepta un cambio, etcd asegura que este replique la in­fo­r­ma­ción a los nodos sucesores. Tan pronto como estos hayan co­n­fi­r­ma­do la recepción, el líder acepta el cambio.

La coor­di­na­ción del líder con los nodos del clúster a través de una base de datos etcd es es­pe­cia­l­me­n­te co­n­ve­nie­n­te en el caso de las apli­ca­cio­nes di­s­tri­bui­das. Si los cambios afectan a la fu­n­cio­na­li­dad de un nodo, este puede blo­quear­los, lo que asegura que la apli­ca­ción se mantenga estable y que se minimicen los problemas po­s­te­rio­res.

Si el líder falla o no responde durante un período pro­lo­n­ga­do, el resto de nodos del clúster elige un nuevo líder después de cierto tiempo. El tiempo que pasa hasta que otro nodo solicita una nueva elección y se presenta como candidato varía de un nodo a otro y se determina mediante una especie de cro­nó­me­tro que tiene cada uno de ellos. De esta manera, se garantiza que los nodos puedan in­te­r­ve­nir como líderes lo más rápido posible.

El número de nodos del clúster debe ser impar para ga­ra­n­ti­zar que siempre haya una mayoría. Por motivos de re­n­di­mie­n­to, no se re­co­mie­n­da utilizar un clúster que tenga más de siete nodos.

Además del hecho de que la apli­ca­ción se ejecuta de forma estable, la base de datos etcd tiene muchas otras ventajas:

• To­ta­l­me­n­te re­pli­ca­ble: la base de datos al completo está di­s­po­ni­ble en todos los nodos del clúster.
• Altamente di­s­po­ni­ble: las bases de datos etcd evitan fuentes de error como los problemas de hardware o los fallos de red.
• Co­n­si­s­te­n­te: cada proceso de lectura pro­po­r­cio­na el último proceso de escritura en varios hosts.
• Fácil: etcd contiene una API orientada al usuario (gRPC) bien definida, basada en REST y JSON.
• Segura: etcd im­ple­me­n­ta au­to­má­ti­ca­me­n­te la tra­n­s­mi­sión segura a través de SSL/TLS. Op­cio­na­l­me­n­te, puedes utilizar la au­te­n­ti­ca­ción de ce­r­ti­fi­ca­do de cliente.
• Rápida: el análisis se sitúa en más de 10.000 ope­ra­cio­nes de escritura por segundo.
• Fiable: el algoritmo Raft siempre asegura que la memoria se di­s­tri­bu­ya co­rre­c­ta­me­n­te.

Ya en 2014, algunos de­sa­rro­lla­do­res im­ple­me­n­ta­ron etcd en Ku­be­r­ne­tes, lo que provocó que la comunidad de etcd creciera rá­pi­da­me­n­te. Pro­vee­do­res de la nube como AWS, Google Cloud Platform y Azur siguieron su ejemplo, im­ple­me­n­ta­n­do etcd con éxito en sus entornos de pro­du­c­ción.

Pero sigamos con Ku­be­r­ne­tes, el ejemplo de etcd me­n­cio­na­do en primer lugar. Ku­be­r­ne­tes en sí es un sistema di­s­tri­bui­do que se ejecuta en un clúster desde varios di­s­po­si­ti­vos. En co­n­se­cue­n­cia, se beneficia eno­r­me­me­n­te de una base de datos di­s­tri­bui­da como etcd, que almacena de forma segura los datos críticos. Dentro de Ku­be­r­ne­tes, la base de datos etcd sirve como almacén de datos principal, en el que se guardan los datos de co­n­fi­gu­ra­ción, el estado y los metadatos. Si se realizan cambios, etcd garantiza que todos los nodos del clúster de Ku­be­r­ne­tes puedan leer y escribir los datos. Al mismo tiempo, etcd monitorea el estado actual o deseado del sistema. Si los estados difieren, Ku­be­r­ne­tes realiza los cambios ne­ce­sa­rios para que vuelvan a alinearse.