Cómo generamos 96 verificadores elegidos

Publicado el

(Indika) (5 de septiembre de 2019)

La última vez que publiqué un artículo fue hace cinco años y se titulaba: Cocinando un servidor web con Chef . Cinco años es mucho tiempo para no escribir. No es que haya perdido el interés por el tema; en cambio, estaba aprendiendo silenciosamente de los mejores.

El tema de discusión, sin embargo, no ha cambiado, excepto que ahora es un orden de magnitud mayor. En aquel entonces estaba cocinando un solo servidor web, y ahora estoy generando 96 verificadores electos (EV).

¿Por qué 96?

En Unification, estamos cambiando el algoritmo de consenso subyacente de Ethereum. Nuestra implementación de gobernanza de estaca distribuida involucra cuatro grupos de 24 vehículos eléctricos, que rotan dentro y fuera de la validación del bloque. La gobernanza de estas rotaciones se facilita mediante un proceso de votación y participación. El resultado final es una red de consorcios más distribuida.

Teorizar este tema en documentos técnicos y en simulaciones solo puede llevarnos hasta cierto punto. La mejor manera de avanzar es producirlo, jugar con él y experimentar cualquier deficiencia.

Entrega continua

Queremos estar en condiciones de evaluar nuestras ideas rápidamente . El desarrollo impulsado por pruebas no necesita limitarse a escribir pruebas unitarias.

Para cualquier Git SHA dado, queremos activar cualquier versión de nuestra Mainchain ejecutando un solo comando, evaluar el estado de la misma y luego hacer refinamientos a su ADN.

Queremos seguir refinando este proceso, hasta que creamos que tenemos algo listo para la producción. El proceso de desarrollo de software no es más que esta simple iteración:

Cuanto más complejo se vuelve un sistema, más difíciles se vuelven cada una de estas partes. La creación de instancias de 96 vehículos eléctricos no es un problema trivial y es el tema central de este artículo.

Definición

Comenzamos definiendo lo que queremos implementar. Un clúster instanciado constará principalmente de vehículos eléctricos, donde algunos de ellos tienen RPC habilitado y otros no. El clúster también puede incluir un grifo UND, un explorador de bloques y tal vez incluso un nodo de supervisión.

Estos clústeres se especifican mediante archivos JSON, y el propósito de la pila de aprovisionamiento puede hacer que lo sean.

Cada nodo dentro del clúster necesita un identificador único y se elige el siguiente esquema de direccionamiento:

x = "{cluster\_name}-{configuration}-{instance\_type}-{index}"

Por ejemplo:

alpha-basic-ev-1

En el declaración anterior, la palabra «básica» se refiere a una configuración, en la que hay cuatro vehículos eléctricos y un explorador de bloques. La palabra «alfa» es el nombre del experimento.

La pila

Podríamos haber optado por Kubernetes.

Sin embargo, también queremos invertir en creando herramientas que nuestra comunidad puede usar para lanzar sus propios vehículos eléctricos. Elegimos Ansible por su simplicidad, y los libros de jugadas que apuntan a CentOS funcionarán en cualquier arquitectura, o pueden adaptarse fácilmente.

Además, aunque he evaluado tanto a Chef como a Puppet en el pasado, yo los he abandonado a ambos por la simplicidad de Ansible. Chef y Puppet necesitan componentes de software en la máquina de destino, sin embargo, Ansible solo necesita una conexión SSH.

Aquí no hay física cuántica con respecto a la pila; sólo los pasos necesarios hacia el éxito. Nuestra pila se compone de:

  • Usuarios de AWS y API de AWS
  • Plantilla de lanzamiento de AWS
  • Etiquetas de AWS
  • Inicio de bash minimalista script
  • Curling un script bash de Github
  • Configure vars de host Ansible desde etiquetas
  • Aprovisione el host usando Ansible

API de AWS y usuarios de AWS

AWS ofrece un control extremadamente granular sobre sus servicios a través de su API y usuarios autorizados. Se puede acceder de manera decente a la API a través de la biblioteca boto3 de Python. Un precursor del uso de la API es la creación del usuario relevante a través de la interfaz de IAM. Un usuario es un identificador de acceso de usuario típico y un par secreto.

Un usuario puede asociarse a una o más políticas. Una política consiste en un conjunto de acciones permitidas o denegadas en un conjunto de recursos.

Nuestro usuario spawn tiene una política adjunta con acciones minimalistas para crear una instancia EC2 y acciones para leer el conjunto de recursos completo.

Plantillas de lanzamiento

Una de las características clave que nos brinda AWS son las plantillas de lanzamiento.

Con una plantilla de lanzamiento, uno puede especificar una AMI base (el identificador de la imagen de la máquina virtual para construir una instancia) y preconfigurar configuraciones, incluidos dos componentes esenciales: etiquetas y un script de ejecución. Además, se puede especificar el grupo de seguridad al que debe pertenecer la máquina.

Las plantillas de lanzamiento se pueden versionar y las instancias se pueden lanzar desde el usuario de AWS.

Tags

Cada instancia EC2 es única en función de las etiquetas con las que está configurada. La siguiente información se envía al nodo:

  • Nombre (identificador único del nodo)
  • Clase (el tipo de instancia)
  • Índice ( la posición de la instancia)
  • Configuración (la variedad de clúster que se instanciará)
  • SHA (un Git SHA)
  • RegistrationIP (la dirección IP del Torre de registro)

Cada una de estas etiquetas se configuran en las variables de hosts de Ansible.

Bootstrapping con Bash

El script de bootstrap de Bash prepara el host para aprovisionamiento. Algunos de los trabajos que se realizan son instalar un entorno Python básico, analizar las etiquetas de AWS, escribirlas en el archivo vars del host de Ansible y seleccionar el libro de estrategias de Ansible adecuado para el tipo de nodo.

Ansible

Finalmente, el nodo se aprovisiona con Ansible. No me desviaré de Ansible, ya que hay suficientes otros recursos en Internet. No hay nada especial aquí, excepto que normalmente uno configura un servidor remoto con Ansible, pero en nuestro caso, estamos configurando el servidor local.

Torre de registro

Usamos una Torre de registro en lugar de un Bootnode para iniciar la red. Los vehículos eléctricos registran sus direcciones IP al crear una instancia con el nodo de registro y se obtiene una lista de nodos estáticos antes de la activación del servicio.

La ventaja de usar una torre de este tipo es que podemos comenzar a registrar datos arbitrarios, como estadísticas de salud, ayudando a cerrar el ciclo de evaluación.

Cuando se crea una instancia de un EV, escribe en la API de registro, su nombre de clúster, dirección IP, índice y tipo de instancia.

Evaluación

El enfoque principal de la evaluación es determinar cómo exitoso fue el experimento. Cuáles son las condiciones de éxito se abordarán en otro artículo. Sin embargo, una métrica inmediata a tener en cuenta es el costo.

El precio de una instancia t2-micro es 0.012 / h. El costo de ejecutar 96 de estos durante una hora solo debería ser de un dólar. Esto se puede confirmar en el Explorador de costos.

Más

Esta pila funciona a la perfección. Un solo comando de manera consistente e impecable genera una cadena principal completamente conectada y que se propaga por bloques. Lo que más me gusta de esta pila es que es disparar y olvidar; Puedo crear una instancia del clúster, desconectarme de Internet y hacer malabares. Habrá una cadena principal lista para mí cuando regrese.

Esto sirve como una base sólida para nuestro próximo paso. Podemos comenzar a evaluar diferentes configuraciones de nuestro ADN de consenso. En nuestro próximo artículo titulado «Gobernanza de estaca distribuida», maduraremos nuestro algoritmo de consenso simple actual y evaluaremos contra la realidad brutal.

El código fuente de la pila de aprovisionamiento de vehículos eléctricos se puede encontrar aquí: https://github.com/unification-com/ev-provision

Únase a nosotros en Unification Gitter: https://gitter.im/unification-com

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *