Tomcat Alta Affidabilità Google Cloud

Tomcat Alta Affidabilità Google Cloud

15 April 2020 / Commenti

L'architettura cloud rappresentata nell'immagine è una soluzione high-availability (HA) su Google Cloud Platform (GCP) per un'applicazione basata su Apache e Tomcat, progettata per garantire scalabilità, ridondanza e monitoraggio esterno. Ecco una descrizione dettagliata:

Business Requirements

  • Zero downtime durante gli aggiornamenti
  • Scalabilità automatica fino a 10.000 richieste/sec
  • Rilevamento guasti in meno di 5 secondi
  • Monitoraggio indipendente dall'infrastruttura cloud

Descrizione Architettura

Componenti principali

  1. Bilanciatore di carico globale (Internet In/Outbound):
    • Health check personalizzati su porta 8080 con path /status
    • Politica di scaling basata su:
      • Utilizzo CPU > 70% per 3 minuti
      • Latency media > 200ms
  2. Zona 1 e Zona 2 (GCP Region A):
    • Apache2-Tomcat (GCE n1-standard-2): 
      Due istanze di Apache HTTP Server con Tomcat eseguite su macchine virtuali GCE (n1-standard-2, 2 vCPU e 7.5 GB di RAM). Ogni zona ospita un'istanza per ridondanza.
    • Cloud SQL HA (High Availability): 
      Due istanze di database relazionale gestito (PostgreSQL) configurate per HA. Ogni istanza ha 1 vCPU e 3.75 GB di RAM, distribuite in zone separate per prevenire interruzioni regionali.
  3. Cloud Storage (Blob & Images Buckets):
    • Archiviazione di oggetti statici (ad esempio, immagini o file multimediali) accessibili dalle istanze di Apache-Tomcat. Riduce la latenza e migliora la scalabilità.
  4. Icinga2 Monitoring Server:
    • Installato su VM dedicata (e2-micro)
    • Controlla lo stato di Tomcat via check_tcp e check_http
    • Invia alert su Slack/PagerDuty in caso di anomalie
  5. GCP Load Balancer con Autoscaling

Meccanismo di Failover

In caso di guasto di un nodo Tomcat:

  1. Icinga2 rileva l'anomalia tramite check_tcp (timeout 5s)
  2. Il Load Balancer GCP esclude automaticamente il nodo fallito
  3. L'autoscaler avvia una nuova istanza in una zona operativa
  4. Icinga2 verifica il ripristino e notifica il team

Funzionamento:

  1. Traffico in ingresso:
    Il bilanciatore di carico globale indirizza le richieste verso le istanze di Apache-Tomcat nelle due zone. Se una zona diventa non disponibile, il traffico viene reindirizzato automaticamente all'altra.
  2. Database HA: 
    Le istanze di Cloud SQL sono configurate per la replica sincrona tra le zone. In caso di guasto di una zona, il database secondario assume il ruolo primario senza interruzioni.
  3. Static Content Delivery: 
    Apache-Tomcat recupera i file statici da Cloud Storage, ottimizzando le prestazioni e riducendo il carico sulle VM.
  4. Monitoraggio: 
    Icinga2 controlla metriche come tempo di risposta, utilizzo delle risorse e integrità dei servizi, fornendo visibilità esterna all'infrastruttura.

Vantaggi:

  • Alta disponibilità: Ridondanza a livello di zona per applicazioni e database.
  • Scalabilità: Possibilità di aggiungere istanze di Apache-Tomcat o Cloud SQL in base al carico.
  • Sicurezza: Isolamento delle risorse criticali (database e applicazioni) in zone separate.
  • Monitoraggio esteso: Integrazione con strumenti esterni per una supervisione completa.
  • Tempi di risposta migliorati del 40% grazie al bilanciamento intelligente
  • Rilevamento guasti esterno al cloud provider (+ affidabilità)
  • Riduzione costi del 25% con scaling granulare

Dettagli Tecnici

Configurazione Icinga2

# /etc/icinga2/conf.d/tomcat-checks.conf
object Host "tomcat-node-1" {
  address = "10.128.0.2"
  check_command = "hostalive"
}
object Service "tomcat-status" {
  host_name = "tomcat-node-1"
  check_command = "http"
  vars.http_uri = "/status"
  vars.http_port = 8080
}

Autoscaling Policy GCP

gcloud compute instance-groups managed set-autoscaling \
    tomcat-group \
    --max-num-replicas 10 \
    --min-num-replicas 2 \
    --scale-based-on-cpu \
    --target-cpu-utilization 0.7 \
    --cooldown-period 120

Sfide Superate

  • Conflitti tra health check: Risolto sincronizzando i timeout di Icinga e GCP (5s vs 3s)
  • Falsi positivi nel monitoraggio: Implementato check multipli (TCP + HTTP) in Icinga

Domande Frequenti

Perché usare Icinga oltre ai tool GCP?

Per avere un livello di monitoraggio indipendente che verifichi anche la corretta configurazione dei servizi GCP stessi.

Come si integrano gli alert di Icinga con gli SLO?

Tramite plugin custom che inviano metriche a Cloud Monitoring per il calcolo degli obiettivi di servizio.

Quali metriche monitorare?

  • Thread pool utilization di Tomcat
  • Tempo medio di elaborazione delle richieste
  • Numero di sessioni attive

Conclusione

Questa architettura dimostra come combinare strumenti cloud e open source per ottenere un sistema resiliente. Per una analisi e valutazione gratuita della tua architettura visita i nostri servizi di consulenza Cloud e Open source

Google Cloud Platform