Architettura sistemistica Ocmis¶
Panoramica¶
L'infrastruttura Ocmis ospita i servizi di telecontrollo irrigazione (dominio irrigation-dataserver.com) ed e' distribuita su AWS con gestione DNS e protezione perimetrale su Cloudflare. Il perimetro coperto da questa pagina comprende: server web e di sviluppo, database RDS, server di log (Syslog + Elastic Search), backup e aggiornamenti schedulati, gestione certificati TLS e bilanciamento/proxy.
Migrazione Farmfront
I server www di questa architettura e il database portalcfg sono stati migrati sotto l'architettura Farmfront. Le informazioni di questa pagina restano valide per la parte non migrata (RDS Ocmis, Syslog, Elastic Search, dev).
Server e componenti¶
| Host / Servizio | Ruolo |
|---|---|
| web1.irrigation-dataserver.com | Frontend web (produzione) |
| web2.irrigation-dataserver.com | Frontend web (produzione) |
| www.irrigation-dataserver.dev | Ambiente di sviluppo |
| syslog.irrigation-dataserver.com | Raccolta log (Graylog + Nxlog client) |
| Server Elastic Search Ocmis | Storage log per Graylog |
| Db RDS Ocmis | Database principale (AWS RDS) |
| Db portalcfg | Configurazione portale (migrato su Farmfront) |
Gestione log¶
La raccolta dei log avviene via Graylog con agenti Nxlog installati sulle macchine sorgente. L'obiettivo originario era abilitare la comunicazione TLS tra Nxlog e Graylog sulla porta 1618 di syslog.irrigation-dataserver.com.
Problema riscontrato sulla terminazione TLS¶
In fase di test, pur avendo configurato correttamente i certificati nella sezione Input di Graylog, la connessione restituiva un certificato self-signed sconosciuto:
openssl s_client -connect syslog.irrigation-dataserver.com:1618 \
-CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
Dettagli del certificato presentato:
| Campo | Valore |
|---|---|
| subject | CN = 0.0.0.0:null |
| issuer | CN = 0.0.0.0:null |
| Errore | Verification error: self-signed certificate |
Il CN = 0.0.0.0:null indica con alta probabilita' un certificato di default non sostituito dal listener.
Workaround adottato¶
Per non bloccare l'abilitazione di SSL e' stato configurato Nxlog con:
CAFile %TRUSTSTORE%
La soluzione non e' quella ideale (il certificato presentato non viene verificato contro una CA attendibile), ma per una comunicazione punto-punto tra agente e collector viene considerata accettabile in via temporanea.
Backup periodici e manutenzioni¶
Effetto dell'ora legale sui job schedulati¶
L'orario effettivo di partenza dei cron dipende dal fuso orario del sistema che esegue lo scheduler.
Sistema in UTC (es. AWS): il job parte sempre alla stessa ora UTC, ma l'orario locale italiano cambia tra estate e inverno.
- Estate (CEST, UTC+2):
23:00 UTC=01:00ora italiana - Inverno (CET, UTC+1):
23:00 UTC=00:00ora italiana
Il servizio AWS Backup fa eccezione: anche specificando l'ora in UTC, l'orario si adatta automaticamente all'ora legale per mantenere costante l'orario locale (comportamento dichiarato da AWS).
Sistema in orario locale (es. Jenkins su Europe/Rome): il job parte sempre alla stessa ora locale, quindi e' l'ora UTC a cambiare tra estate e inverno.
- Estate:
23:00 CEST=21:00 UTC - Inverno:
23:00 CET=22:00 UTC
Schedulazione backup e manutenzioni¶
| Attivita' | Frequenza / orario | Durata | Cron estate | Cron inverno | Esecutore |
|---|---|---|---|---|---|
| Dump Db Rds | Ogni giorno ore 2:00 locali (tz Europe/Rome), retention 1 mese |
5 min | 0 2 * * * |
0 2 * * * |
Jenkins |
| Snapshot Db Rds | Ogni giorno ore 22 UTC, retention 1 mese | 30 min | 0 24 * * * |
0 23 * * * |
AWS |
| Manutenzione periodica | Ogni domenica ore 23:00 UTC | 30 min | 0 1 * * 0 |
0 24 * * 0 |
AWS |
| Snapshot web1 | Mensile, ore 24:30 UTC il giorno 1 (partenza entro 1 ora, termine entro 6 ore; di norma entro 15 min). Retention 91 giorni (1 a caldo + 90 a freddo) | 30 min | 30 24 1 * * |
30 24 1 * * |
AWS Backup |
| Snapshot web2 | Come web1 | 30 min | 30 24 1 * * |
30 24 1 * * |
AWS Backup |
| Snapshot dev | Come web1 | 30 min | 30 24 1 * * |
30 24 1 * * |
AWS Backup |
| Snapshot Syslog-Ocmis | Come web1 | 30 min | 30 24 1 * * |
30 24 1 * * |
AWS Backup |
| Snapshot Elastic Search Ocmis | Come web1 | 30 min | 30 24 1 * * |
30 24 1 * * |
AWS Backup |
Finestra stagionale per gli aggiornamenti RDS¶
Da Maggio a Settembre compresi non vengono applicati aggiornamenti al Db RDS (periodo di alta stagione irrigua). Negli altri mesi si effettua una verifica mensile ed eventuale applicazione degli aggiornamenti disponibili.
Dump su S3¶
I backup dei database OCMIS e portalcfg vengono copiati su S3, nel bucket rds-history-snapshot dell'account AWS Ocmis.
| Parametro | Valore |
|---|---|
| Bucket | rds-history-snapshot |
| Schedulazione | Ogni domenica ore 21:00 (21 * 7 in Jenkins) |
| Esecutore | Jenkins |
| Notifica email | [email protected] (inviata indipendentemente dall'esito) |
Aggiornamenti periodici¶
Tutti gli aggiornamenti sistema sono lanciati da Jenkins con timezone Europe/Rome.
| Macchina | Data di aggiornamento | Cron (tz Europe/Rome) | Esecutore |
|---|---|---|---|
| web1.irrigation-dataserver.com | Giorno 7 del mese ore 23 | 0 23 7 * * |
Jenkins |
| web2.irrigation-dataserver.com | Giorno 21 del mese ore 23 | 0 23 21 * * |
Jenkins |
| www.irrigation-dataserver.dev | Giorno 2 del mese ore 12:30 | 30 12 2 * * |
Jenkins |
| syslog.irrigation-dataserver.com (+ Elastic Search) | Ore 4 del giorno 1 dei mesi pari | 0 4 1 2,4,6,8,10,12 * |
Jenkins |
La separazione temporale tra web1 (giorno 7) e web2 (giorno 21) permette di mantenere sempre almeno un frontend in produzione durante la finestra di aggiornamento.
Balancing, Cloudflare e CloudFront¶
Tutte le macchine Ocmis hanno attiva la modalita' Proxy di Cloudflare, che nasconde l'IP pubblico del server e attiva la protezione DDoS. L'impostazione ha richiesto valutazioni specifiche nei casi in cui il dominio sorgente non e' gestito direttamente nell'account Cloudflare Ocmis.
Vincolo sui CNAME¶
Per i domini non appartenenti a Cloudflare ma con CNAME che punta a un DNS gestito da Cloudflare, non e' possibile attivare la modalita' Proxy. In questi casi il CNAME va configurato con Proxy disattivato (traffico diretto DNS).
Caratteristiche del Load Balancer Cloudflare¶
| Aspetto | Dettaglio |
|---|---|
| Quota gratuita | Prime 500.000 query/mese condivise tra tutti i LB dell'account |
| Costo oltre soglia | 0,50 $ ogni 500.000 richieste per hostname abilitato, fatturato a fine mese |
| Intervallo health check | 60 secondi |
| Copertura geografica check | Singola area geografica |
| Criterio di routing | Disponibilita' degli host di backend |
Scelte sulla topologia di bilanciamento¶
Il ragionamento seguito durante la progettazione, per domini con CNAME esterno verso www:
| Scenario | Problema |
|---|---|
CNAME punta a una singola macchina www |
La macchina resta esposta (Proxy non attivabile sul CNAME). Single point of failure. |
| CNAME punta a un Load Balancer Cloudflare (senza Proxy sul CNAME) | Il LB e' resiliente, ma espone gli IP delle macchine di backend: dopo il bilanciamento i backend restano attaccabili direttamente. |
Condizione per abilitare la modalita' Proxy su un CNAME¶
Non basta che il dominio del CNAME sia registrato su Cloudflare: e' necessario che la gestione del dominio sia configurata nello stesso account Cloudflare del record di destinazione.
Esempio: il record www.irriverso.com (CNAME) per poter essere proxato deve essere gestito dallo stesso account Cloudflare che gestisce sso.irrigation-dataserver.com (record di destinazione).
La strategia adottata e' stata quindi quella di spostare sotto Cloudflare la gestione dei soli domini realmente necessari (es. irriverso.com), puntandone gli NS all'account Cloudflare Ocmis. Cosi' facendo e' stato possibile abilitare la modalita' Proxy sui CNAME senza errori.
CloudFront per i domini non gestibili su Cloudflare¶
Per i domini non spostabili sotto Cloudflare e' stato introdotto Amazon CloudFront come CDN intermedio.
Flusso:
Utente → CloudFront (distribution *.cloudfront.net) → Bucket S3 → Redirect a URL finale
(es. www.irrigation-dataserver.it/b1, b2, b3)
CloudFront e' necessario perche':
| Limitazione S3 | Soluzione CloudFront |
|---|---|
| S3 non supporta certificati TLS personalizzati su domini custom | CloudFront espone HTTPS con certificati gestiti da AWS Certificate Manager (ACM) |
| S3 abilita HTTPS solo sul proprio endpoint predefinito | La distribuzione CloudFront fa da proxy HTTPS verso S3 |
Il risultato e' la possibilita' di servire in HTTPS i domini personalizzati di Ocmis, Marani e Irtec.
Gestione certificati TLS¶
Acquisto e rinnovo¶
I certificati TLS gestiti fuori Cloudflare (es. backend raggiunti senza Proxy) seguono il normale ciclo di acquisto/rinnovo e vanno installati sugli host di backend.
Certificati generati da Cloudflare¶
Quando su Cloudflare viene configurato un Load Balancer associato a un hostname (es. www di irrigation-dataserver.com), Cloudflare genera automaticamente un certificato Wildcard utilizzato per la terminazione TLS/SSL sul balancer.
| Modalita' del LB | Chi termina TLS | Requisito sugli host di backend |
|---|---|---|
| LB con Proxy attivo | Cloudflare (terminazione TLS completa sul balancer, certificato Wildcard Cloudflare) | Nessun certificato TLS necessario sugli host. Nessun Virtual Host per www richiesto: il LB contatta direttamente www1 e www2, i cui VH specifici devono essere configurati |
| LB senza Proxy | Server di backend | Necessario installare il certificato di www sugli host e configurare il Virtual Host www su ciascun backend, che deve rispondere direttamente al nome pubblico |
La scelta di attivare la modalita' Proxy centralizza la gestione dei certificati su Cloudflare ed evita rinnovi manuali sui singoli host di frontend.