Desplegando nodos de Storj en un VPS con Ubuntu 16.04

Muchas son las aplicaciones que recientemente surgen alrededor de la filosofía blockchain. Una de ellas es la de prestar un almacenamiento distribuido y encriptado en clara competencia con las corporaciones que copan el mercado actual en almacenamiento en la nube.

Blockchain no está pensada para tener un alto almacenamiento de datos debido a su excesivo coste en gas para la ejecución de la misma. Es por eso que los Smart Contracts se optimizan al máximo para reducir las llamadas de escritura a la blockchain y en ese caso la información que se guarda.

Paralelamente se ha forjado el Interplanetary File System (IPFS) como un protocolo para el almacenamiento descentralizado de archivos basado en la distribución peer-to-peer. Usa un árbol de Merkle para la gestión de los bloques de enlaces y las tablas de los hashes.

De entre las alternativas de IPFS, este caso se centra en Storj. Basado en código libre, permite guardar archivos de formas segura y privada (encriptada) en los nodos que cuenta su red. El protocolo se basa en el uso de espacio de disco duro de usuarios que no lo necesitan. La acumulación de porciones de discos duros entre los nodos de la red de Storj permite el almacenamiento masivo. Los usuarios pueden almacenar archivos, pagándoe por la cantidad de datos guardados y el ancho de banda utilizado. También existe la posibilidad de crear un nodo en un ordenador con espacio de disco duro que no vaya a ser requerido.

Antes de empezar, es bueno comentar que Storj recompensa a los nodos por la cantidad de datos que los dichos guardan y lo hace en periodos mensuales. Es altamente recomendable que el ordenador esté conectado 24/7 a Internet ya que se penalizan tanto las desconexiones como las interrupciones. El mínimo para poder obtener recompensa es de 1Gb con lo que las particiones que se conecten a la red deben ser mucho mayores. Más adelante se comenta la lógica de la distribución de los datos en Storj.

Teniendo todos los puntos anteriores, se entiende que está orientado a servidores y no a ordenadores de sobremesa por su dedicación e intensidad de recursos. Igual que la minería de datos, aunque los equipos de sobremesa puedan realizar las operaciones no compensa el gasto que lleva asociadas las mismas.

Así pues, decidimos iniciar unos nodos en el servidor VPS con Ubuntu 16.4. con el ánimo de apoyar la red de nodos de Storj por su filosofía más que como inversión como la gran mayoría de los miembros de la comunidad blockchain.

Instalación

Para la instalación, las instrucciones que hay que seguir son sencillas. Quizás lo más interesante es el conocmiento de la configuración para no llevarse sorpresas futuras. En cualquier caso, el usuario que debe usarse para instalar no debe ser root. Eso es importante tenerlo en cuenta para prevenir cualquier ataque o uso incorrecto de la aplicación.

Básicamente se debe instalar NVM en el servidor.

En un terminal, se descarga NVM

esteve:~$ wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.33.3/install.sh | bash

En otro terminal se ejecuta la instalación de NVM

esteve:~$ nvm install --lts

Se recomienda volver a ejecutarlo (tal y como lo reseñan en su guía). Eso debe asgurar la instalación del mismo y evita problemas futuros.

esteve:~$ nvm install --lts
Installing latest LTS version.
v8.11.2 is already installed.
Now using node v8.11.2 (npm v5.6.0)
esteve:~$ nvm ls
-> v8.11.1
system
default -> lts/* (-> v8.11.1)
node -> stable (-> v8.11.1) (default)
stable -> 8.11 (-> v8.11.1) (default)
iojs -> N/A (default)
lts/* -> lts/carbon (-> v8.11.1)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.14.1 (-> N/A)
lts/carbon -> v8.11.1

Se procede a la actualización de la distribución instalando a continuación los paquetes de git y python.

esteve:~$ sudo apt-get update && sudo apt-get dist-upgrade
esteve:~$ sudo apt-get install git python build-essential -y

Queda sólo instalar el servicio de Storj con NPM.

esteve:~$ npm install --global storjshare-daemon

La conexión entre los nodos debe estar muy bien sincronizada y se penaliza una alta latencia por lo que se debe instalar un servicio de NTP.

Se actualiza o instala el servicio NTP y se para asignando un servidor de tiempo.

esteve:~$ sudo apt-get install ntp ntpdate -y
...
esteve:~$ sudo service ntp stop

Se actualiza con un servidor externo e inicia de nuevo.

esteve:~$ sudo ntpdate -s time.nist.gov
esteve:~$ sudo service ntp start

Al estar en servidor en el área de Paris, le asignamos esa zona horaria.

esteve:~$ sudo timedatectl set-timezone Europe/Paris

En caso necesario, se pueden buscar las zonas más cercanas al servidor con

timedatectl list-timezones

La información de configuración de NTP se encuentra en /etc/ntp.conf.

esteve:~$ timedatectl status
Local time: Wed 2018-04-13 12:08:04 CEST
Universal time: Wed 2018-04-13 10:08:04 UTC
RTC time: Wed 2018-04-13 10:08:04
Time zone: Europe/Paris (CEST, +0200)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no

Configuración y ejecución

La configuración de los nodos es sencilla per requiere de conocer la lógica del almacenamiento que rige Storj. Como hemos comentado, la remuneración tiene como corte 1Gb/mes/nodo. Un usuario puede tener más de un nodo en la misma máquina. Los nodos se pueden entender como particiones del disco que se comparten con la red de Storj. Con una partición de 3Gb, como la que usan en los ejemplos uno debería disponer de suficiente espacio como para poder optar a la recompensa.

La realidad es otra. El espacio que se comparte se divide en 256 bloques llamados shards (trozo con cantos afilados proveniente de una rotura de un cuerpo rígido de vidrio o cerámica), siendo el valor del tamaño máximo que se permite almacenar en el nodo. Eso significa que con un nodo de 3Gb, el archivo con tamaño máximo que se puede almacenar es de unos 11,78Mb.

Igualmente, el protocolo de Storj penaliza a los nodos que rechazan archivos por no disponer de espacio o porque el tamaño del archivo es mayor al que pueden almacenar. Con un tamaño tan pequeño, lo más normal es que el nodo no tenga una reputación muy alta y que quede fuera del reparto de archivos. Al no estar muy explicitado, esta situación conlleva a una sensación de frustración y desánimo entre los gestores de nodos primerizos.

A modo ilustrativo se crean cuatro nodos, uno de 50Gb y tres de 3Gb.

La creación de un nodo es sencilla. Los datos a tener en cuenta son,

  • la cuenta en ETH a la que se debe recompensar (en formato 0x…)
  • el directorio dónde se destina la partición (con toda la ruta)
  • definición del archivo de configuración del nodo (con toda la ruta acabando en config.json)
  • la ip del servicio RPC y su puerto
  • gestión de NAT
  • directorio de registro del log

En la ejecución para la creación de un nodo, los parámetros no se entrecomillan. En el caso del servidor VPS, no debe hacerse una configuración de NAT así que se designa como que no debe haber manualforwarding. Los puertos deben estar abiertos para poder establecer conexiones remotas a cada uno de los nodos.

esteve:~$ storjshare-create --storj CUENTA_ETH --storage /home/esteve/Node_1 --size 50GB --outfile /home/esteve/Node_1/config.json --rpcaddress IP_DEL_SERVIDOR --rpcport 4003 --manualforwarding false --logdir /home/esteve/Node_4

El nodo puede levantarse para que empiece a conectarse a la red y estar escuchando posibles envíos de archivos.

esteve:~$ storjshare start --config Node_1/config.json

* daemon is not running, starting...

* starting node with config at /home/esteve/Node_1/config.json

Mientrastanto se procede a la creación de los otros tres nodos. Se puede realizar de la misma manera que se ha hecho con el Nodo_1 o puede basarse en la configuración que se ha creado con el Nodo_1 ya que la inicialización se hace en base a dicho archivo de configuración. Todos los datos serán muy similares a diferencia de la ruta y el tamaño del nodo.

Se crea un directorio para cada nodo y se copia el archivo de configuración del nodo inicial.

esteve:~$ mkdir Node_2
esteve:~$ cp Node_1/config.json Node_2
esteve:~$ vi Node_2/config.json

La edición del archivo de configuración requiere de actualización en los parámetros

  • «rpcPort»: 4001,
  • «loggerOutputFile»: «/home/esteve/Node_2»,
  • «storagePath»: «/home/esteve/Node_2»,
  • «storageAllocation»: «3GB»

Al disponer el VPS de buena conectividad, no se requiere la limitación del maxShardSize.

Se aplica el mismo procedimiento con los nodos Nodo_3 (puerto 4002 y directorio Node_3) y Nodo_4 (puerto 4003 y directorio Node_4) y se inician.

Habiendo iniciado los cuatro nodos, es recomendable guardar las configuraciones para un inicio cómodo en futuras ocasiones.

¡storjshare save

Teniendo la configuración guardada, tan sólo con

storjshare load

se levantan todos los nodos configurados.

Configuración

Habiendo pasado ya más de un mes desde el inicio de la ejecución se comprueba que el Nodo_1 (50Gb) dispone de 3Gb mientras que los otros tres nodos rondan los 50-100Mb. A modo de ejemplo, se comprueba que aunque la latencia es buena y los puertos están abiertos.

esteve:~$ storjshare status

┌─────────────────────────────────────────────┬─────────┬──────────┬──────────┬─────────┬───────────────┬─────────┬──────────┬───────────┬──────────────┐
│ Node                                        │ Status  │ Uptime   │ Restarts │ Peers   │ Allocs        │ Delta   │ Port     │ Shared    │ Bridges      │
├─────────────────────────────────────────────┼─────────┼──────────┼──────────┼─────────┼───────────────┼─────────┼──────────┼───────────┼──────────────┤
│ 2ff406753ab5cb6f393b078a5944c3f6f845b024    │ running │ 35d 15h… │ 0        │ 4       │ 1368          │ 1ms     │ 4000     │ 3.03GB    │ connected    │
│   → /home/esteve/Node_1                     │         │          │          │         │ 100 received  │         │ (TCP)    │ (6%)      │              │
├─────────────────────────────────────────────┼─────────┼──────────┼──────────┼─────────┼───────────────┼─────────┼──────────┼───────────┼──────────────┤
│ ad6b0b396227e4c162ff3c8ebe9ced56cf5523aa    │ running │ 40d 1h … │ 0        │ 11      │ 893           │ 38ms    │ 4001     │ 45.73MB   │ connected    │
│   → /home/esteve/Node_2                     │         │          │          │         │ 32 received   │         │ (TCP)    │ (1%)      │              │
├─────────────────────────────────────────────┼─────────┼──────────┼──────────┼─────────┼───────────────┼─────────┼──────────┼───────────┼──────────────┤
│ b5f10bedf785741090f639833442178e3726f5c7    │ running │ 35d 3h … │ 0        │ 52      │ 639           │ -3ms    │ 4002     │ 91.2MB    │ connected    │
│   → /home/esteve/Node_3                     │         │          │          │         │ 32 received   │         │ (TCP)    │ (1%)      │              │
├─────────────────────────────────────────────┼─────────┼──────────┼──────────┼─────────┼───────────────┼─────────┼──────────┼───────────┼──────────────┤
│ 2b49050ffa40f4c37d4942d380aa31727817518a    │ running │ 35d 23h… │ 0        │ 24      │ 782           │ 2ms     │ 4003     │ 55.84MB   │ connected    │
│   → /home/esteve/Node_4                     │         │          │          │         │ 46 received   │         │ (TCP)    │ (2%)      │              │
└─────────────────────────────────────────────┴─────────┴──────────┴──────────┴─────────┴───────────────┴─────────┴──────────┴───────────┴──────────────┘
esteve:~$

Como se observa, de los cuatro nodos que hay sólo el primero podrá obtener en el futuro alguna recompensa por almacenar por encima de 1Gb.

En cualquier momento se puede parar un nodo, paso previo a la modificación de la configuración del mismo en caso necesario. Se debe proveer el id del nodo que se quiere parar.

storjshare stop --nodeid 2ff406753ab5cb6f393b078a5944c3f6f845b024

Para visualizar el log de un nodo se procede casi de la misma manera.

storjshare logs --nodeid 2ff406753ab5cb6f393b078a5944c3f6f845b024

El análisis de cómo funcionan y reaccionan los nodos puede realizarse con una herramienta gratuita llamada StorjStat. En dicha web se pueden registrar los nodos para que se vayan analizando.

Se observa el comportamiento inicial tanto del tiempo de respuesta de los nodos registrados como el análisis por nodo de la reputación que va en aumento.

Evolución de los nodos (tiempo de respuesta)
Evolución del Nodo 1 (tiempo de respuesta y reputación)