Este esquema y descripción está copiado de una entrada del espacio de Infrastructure de Confluence /wiki/spaces/INFRA/pages/59473923
- ror1, ror2 y ror3 son los servidores donde se ejecuta la parte web de la API. ror4 se eliminó al desaparecer Skade.
- ror1: entrada/ingestión de datos
- ror2: lectura de datos (no debe utilizarse para ingestión)
- ror3: entrada de datos mediante la API pública, descrita aquí Envío de datos IoT API . Muy importante: este es el servidor que debe utilizarse para ingestión de datos enviados por terceros, ror1 debe utilizarse únicamente para nuestras propias estaciones/integraciones.
- ux1 es el servidor donde se ejecuta la parte web del frontend. ux2 se eliminó al desaparecer Skade.
- mysql1, mysql2 son los servidores de bases de datos donde están almacenados los datos de la API (los del frontend están almacenados en ux1). mysql1 es maestro y mysql2 está configurado como esclavo. La idea inicial es que todas las escrituras se realizaran en mysql1 y todas las lecturas en mysql2, para mejorar el rendimiento (esto se configuró a nivel de aplicación con la gema octopus https://github.com/thiagopradi/octopus ). Sin embargo, dado que el volumen de Skade era tan grande, la sincronización del esclavo siempre iba varias horas por detrás del maestro, con lo cuál los datos leídos estaban totalmente desactualizados. Actualmente tanto lecturas como escrituras se hacen sobre mysql1, y las copias de seguridad se hacen desde mysql2.
- redis1 es el servidor que provee el servicio de Redis. Lo utlizan los servidores web de la API para encolar los trabajos de procesamiento de tramas, y los servidores de background que ejecutan dichos trabajos.
- background1 es el servidor que ejecuta Sidekiq para procesar las tramas recibidas en la API. Lee los trabajos de redis1. background2 y background3 se eliminaron al desaparecer Skade.
- nfs1 provee almacenamiento adicional mediante NFS a los servidores web y background de la API. Se montan los directorios de log de la API y el directorio de imágenes recibidas.