Spcnet.it

2026-05-26 16:59:19

Retry Storm nelle architetture distribuite: quando la resilienza diventa il problema

Le architetture distribuite moderne sono progettate per la resilienza. Aggiungiamo retry per i fallimenti transitori, replica per la durabilità, autoscaling per l’elasticità, circuit breaker per l’isolamento. Ogni meccanismo, preso singolarmente, migliora la disponibilità. Ma sotto stress, la loro interazione può abbattere l’intero sistema.

La maggior parte delle interruzioni enterprise non è causata dall’assenza di fault tolerance. È causata da meccanismi di fault tolerance non delimitati che reagiscono simultaneamente. Questo articolo analizza il fenomeno del retry storm e mostra come progettare sistemi con bounded reliability.

1. Retry Storm: quando la resilienza moltiplica il traffico

I retry sono progettati per proteggere dai fallimenti temporanei. Ma i retry moltiplicano il carico. Ecco un esempio semplificato della logica di retry che si trova comunemente nei sistemi di integrazione tra servizi:

import time
import random

def downstream_service():
    latency = random.choice([0.1, 0.2, 0.8])
    time.sleep(latency)
    if latency > 0.7:
        raise TimeoutError("Slow response")
    return "OK"

def call_with_retries(max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            print(f"Retry {attempt+1}")
    raise Exception("Failed after retries")

In condizioni normali questa logica funziona correttamente. Ma sotto carico elevato si innesca una spirale:

1. La latenza aumenta
2. Scattano i timeout
3. Ogni richiesta viene ritentata fino a 3 volte
4. Il traffico verso il backend triplica
5. Il backend rallenta ulteriormente
6. Aumentano i retry

In un’architettura a livelli tipica — Gateway → Experience API → Process API → System API → Database — se ogni livello gestisce i retry in modo indipendente, l’amplificazione del carico diventa moltiplicativa, non additiva. Un singolo rallentamento del database può abbattere tre livelli API a cascata in pochi minuti.

Il pattern Bounded Retry (sicuro per la produzione)

La soluzione non è eliminare i retry, ma delimitarli e renderli consapevoli del carico di sistema:

def call_with_bounded_retries(max_attempts=2, system_load=0.5):
    # Fail-fast quando il sistema è sotto stress
    if system_load > 0.75:
        return None

    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            # Exponential backoff con jitter
            backoff = 0.2 * (2 ** attempt)
            time.sleep(backoff + random.uniform(0, 0.1))
    return None

Le differenze chiave rispetto alla versione base:

• Ceiling sui retry: massimo 2 tentativi invece di 3
• Exponential backoff: aumenta il tempo di attesa ad ogni tentativo
• Jitter: aggiunge variabilità casuale per evitare wave di retry sincronizzate
• Load-aware circuit: disabilita i retry completamente quando il sistema è sovraccarico

2. Fan-out della replica e collasso della coordinazione

La replica sincrona migliora la durabilità dei dati. Ma ogni write si moltiplica per il numero di repliche, aumentando il costo di coordinazione:

def write_to_replicas(data, replicas=3):
    for _ in range(replicas):
        time.sleep(0.2)  # Simula latenza di replica

Sotto traffico elevato, il lag delle repliche cresce, i client iniziano a ritentare le scritture, e il carico effettivo di write raddoppia. In sistemi di elaborazione aziendale (ordini, fatturazione, riconciliazione) questo pattern causa un collasso del throughput non perché i dati vadano persi, ma perché la coordinazione sopraffà il sistema.

La soluzione è la durabilità stratificata: non tutte le scritture richiedono le stesse garanzie. Le transazioni critiche usano replica completa; log ed eventi non critici ne richiedono meno. La reliability deve essere proporzionata, non massimizzata ciecamente.

3. Loop di feedback dell’autoscaling

L’autoscaling reagisce alle metriche di traffico. Ma se queste metriche sono gonfiate dai retry, il sistema escala in risposta a traffico artificiale:

def autoscale_safe(request_rate, sustained_load):
    # Scala su domanda sostenuta, non su spike da retry
    if sustained_load and request_rate > 120:
        print("Scaling up — domanda organica confermata")

Segnali più affidabili su cui basare l’autoscaling:

• Domanda sostenuta (non spike improvvisi)
• Tendenze nella distribuzione della latenza (P95, P99)
• RPS organiche (esclusi i retry)
• Velocità di crescita delle code

4. Il problema reale: le reazioni correlate

Retry, replica e autoscaling reagiscono ciascuno a segnali diversi. Ma sotto stress, reagiscono tutti allo stesso segnale di degradazione. Questa correlazione crea il fallimento a cascata.

Scenario reale — payment reconciliation service:

1. La latenza dell’ERP sale a 700ms
2. Il servizio Billing va in timeout a 500ms
3. Billing ritenta 3 volte
4. La Process API ritenta l’orchestrazione
5. Il Gateway ritenta la richiesta client
6. L’autoscaling reagisce allo spike
7. Il lag di replica del database aumenta
8. La Dead Letter Queue inizia a riempirsi

In pochi minuti, un rallentamento minore diventa un’interruzione di piattaforma. La causa principale: reazione non delimitata.

5. Pattern di Bounded Reliability per sistemi API

Retry Budget

Il carico effettivo è: Carico Effettivo = RPS in ingresso × Numero Retry. Con 1.000 RPS e 3 retry, il backend riceve 3.000 richieste. Impostare un budget massimo di retry per richiesta e per servizio è non negoziabile in produzione.

Classificazione degli Errori

Non tutti gli errori sono retriable. Una tassonomia chiara:

Tipo di Errore	Retry?	Azione
CONNECTIVITY	Sì	Bounded retry
TIMEOUT	Sì	Backoff esponenziale
VALIDATION (4xx)	No	Fail fast
AUTH (401/403)	No	Alert immediato

I retry ciechi su errori di validazione o autenticazione sono debito architetturale.

Idempotency obbligatoria

I retry senza idempotency causano corruzione dei dati. Il transaction ID deve essere deterministic, non generato casualmente ad ogni tentativo:

# ❌ Non sicuro: genera un nuovo ID ad ogni retry
transaction_id = uuid()

# ✅ Sicuro: riusa l'ID dalla richiesta originale
transaction_id = payload.get("transaction_id") or request.headers["correlation-id"]

Dead Letter Queue con Osservabilità

Tracciare le seguenti metriche come segnali di early warning:

• Percentuale di retry sul totale delle richieste
• Frequenza dei timeout per endpoint
• Velocità di crescita della DLQ
• Shift nella distribuzione P95 della latenza

Conclusione

Le retry storm non iniziano con un fallimento catastrofico. Iniziano con un piccolo aumento di latenza, qualche timeout, una manciata di retry. Poi i meccanismi di fault tolerance reagiscono insieme — e la loro interazione non controllata trasforma un disagio minore in un’interruzione totale.

La resilienza nelle architetture distribuite non significa aggiungere più safety net. Significa controllare come quei safety net si comportano sotto stress. Delimita i retry. Classifica i fallimenti. Forza l’idempotency. Scala su domanda organica. Monitora i loop di feedback prima che si avvitino.

La differenza tra una piattaforma resiliente e un fallimento a cascata sta quasi sempre nella risposta a una sola domanda: i tuoi meccanismi di reliability sono controllati o sono illimitati?

Fonte: How Retry Storms Crash API-Led Systems: Bounded Reliability Patterns — DZone

How Retry Storms Crash API-Led Systems

Unbounded retries and autoscaling can turn minor latency into cascading outages. API reliability must be bounded and load-aware to prevent retry storms.

^{Manjeera Chanda (dzone.com)}

Spcnet.it

2026-05-26 16:59:55

nmap su Linux: guida completa alla scansione e discovery di rete

nmap è uno degli strumenti più potenti e longevi nell’arsenale di qualsiasi sistemista Linux. Nato nel 1997, è oggi uno standard de facto per l’audit di rete, la verifica della superficie d’attacco esposta e il troubleshooting di connettività. Questa guida copre i comandi e le tecniche che un sysadmin usa davvero in produzione: niente teoria astratta, solo esempi concreti.

Nota legale: scansionate solo reti e host di vostra proprietà o per cui avete un’autorizzazione esplicita. La scansione non autorizzata può essere illegale nella vostra giurisdizione.

Installazione di nmap

nmap è disponibile nei repository di tutte le principali distribuzioni Linux:

# Debian / Ubuntu
sudo apt install nmap

# Fedora / RHEL / CentOS
sudo dnf install nmap

# Arch / Manjaro
sudo pacman -S nmap

Verificate l’installazione con:

nmap --version

Dovreste vedere qualcosa come Nmap version 7.94 o superiore. Le funzionalità più avanzate (SYN scan, OS detection) richiedono privilegi root.

Host Discovery: chi è attivo sulla rete?

Il primo passo in qualsiasi audit è capire quali host sono raggiungibili. Il ping scan usa il flag -sn, che dice a nmap di non eseguire scansioni delle porte:

nmap -sn 192.168.1.0/24

Su una LAN locale nmap usa ARP discovery, più veloce e capace di trovare dispositivi che ignorano il ping ICMP. L’output tipico è:

Nmap scan report for 192.168.1.1
Host is up (0.0011s latency).
MAC Address: A4:3E:51:XX:XX:XX (Ubiquiti Networks)

Nmap scan report for 192.168.1.10
Host is up (0.00032s latency).
MAC Address: DC:A6:32:XX:XX:XX (Raspberry Pi Trading)

È un inventario rapido: ottimo dopo aver aggiunto un nuovo dispositivo e non ricordarsi quale IP ha ottenuto dal DHCP.

Scansione delle Porte

Scansione di default

Senza flag aggiuntivi, nmap scansiona le 1.000 porte TCP più comuni. Non richiede root, ma i risultati sono meno dettagliati:

nmap 192.168.1.10

SYN Scan (Stealth Scan)

La SYN scan è la modalità default quando si esegue nmap come root. Invia un pacchetto SYN senza completare il three-way handshake TCP: più veloce e meno visibile nei log applicativi:

sudo nmap -sS 192.168.1.10

Scansione di tutte le 65.535 porte

Le 1.000 porte di default possono mancare servizi su porte non standard — MySQL su 33060, SSH spostato su 2222:

sudo nmap -sS -p- 192.168.1.10

Porte specifiche o range

# Porte specifiche
sudo nmap -p 22,80,443,3306 192.168.1.10

# Range di porte
sudo nmap -p 1-1024 192.168.1.10

UDP Scanning

L’UDP è spesso dimenticato. DNS (porta 53), SNMP (161) e NTP (123) girano su UDP e sono vettori comuni di attacco e misconfiguration:

sudo nmap -sU -p 53,161,123 192.168.1.1

Rilevamento di Servizi e Versioni

Il flag -sV esegue probe sulle porte aperte per determinare servizio e versione. È il primo scan da eseguire su un server sconosciuto:

sudo nmap -sV 192.168.1.10

Output esempio:

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp   open  http    nginx 1.24.0
3306/tcp open  mysql   MySQL 8.0.35

Rivela immediatamente con cosa si ha a che fare e può evidenziare software obsoleto — un win immediato per la sicurezza.

Rilevamento del Sistema Operativo

nmap può fare ipotesi sull’OS basandosi sul fingerprinting del TCP/IP stack:

sudo nmap -O 192.168.1.10

Output:

OS details: Linux 5.15 - 5.19, Linux 6.1
Network Distance: 1 hop

Non è sempre preciso su VM o dispositivi con stack TCP personalizzati, ma fornisce un segnale utile per distinguere server Linux da macchine Windows o embedded su un segmento di rete.

Aggressive Scan: tutto in uno

Il flag -A abilita OS detection, version detection, script scanning e traceroute in un colpo solo:

sudo nmap -A 192.168.1.10

Genera molto traffico e richiede tempo. Non usatelo su reti di produzione senza motivo, ma per un audit completo di un singolo host è estremamente comodo.

Nmap Scripting Engine (NSE)

L’NSE è ciò che distingue nmap da un semplice port scanner. Permette di eseguire script contro host e servizi scoperti. Gli script si trovano in /usr/share/nmap/scripts/ e coprono vulnerability detection, enumerazione di servizi e molto altro.

Verifiche pratiche

# Categoria default
sudo nmap --script=default 192.168.1.10

# Scansione vulnerabilità (più invasivo - usare deliberatamente)
sudo nmap --script=vuln 192.168.1.10

# FTP anonimo abilitato?
sudo nmap --script=ftp-anon -p 21 192.168.1.10

# Header HTTP esposti (versioni server, debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

# Open SMTP relay?
sudo nmap --script=smtp-open-relay -p 25 192.168.1.20

L’HTTP headers scan è sorprendentemente utile: è frequente trovare server che espongono header con versione del software e informazioni di debug che avrebbero dovuto essere rimosse.

Per elencare tutti gli script disponibili per un servizio:

ls /usr/share/nmap/scripts/ | grep -i ssh

Formati di Output

Per qualunque cosa oltre un controllo rapido, salvare l’output è fondamentale:

# Output normale su file
sudo nmap -sV 192.168.1.0/24 -oN scan_results.txt

# XML (utile per automazione e import in altri tool)
sudo nmap -sV 192.168.1.0/24 -oX scan_results.xml

# Formato grepable
sudo nmap -sV 192.168.1.0/24 -oG scan_results.gnmap

# Tutti i formati in una volta sola
sudo nmap -sV 192.168.1.0/24 -oA scan_results

Il flag -oA crea tutti e tre i file con il prefisso specificato. L’output XML si presta bene al parsing automatizzato.

Timing e Velocità

nmap dispone di sei template di timing, da T0 (lentissimo) a T5 (aggressivo). Il default è T3. Per la maggior parte delle scansioni su reti locali affidabili:

sudo nmap -sS -T4 192.168.1.0/24

Su VPN o connessioni lente, scendere a T2 evita falsi negativi causati da pacchetti persi.

Combinazioni Pratiche per Sysadmin

Questi sono i comandi che si usano davvero nel lavoro quotidiano:

# Porte aperte su un host (solo quelle definitivamente aperte)
sudo nmap -sS -T4 --open 192.168.1.10

# Trovare tutti i server SSH su una subnet
sudo nmap -p 22 --open -sV 192.168.1.0/24

# MySQL esposto sulla rete? (non dovrebbe mai esserlo)
sudo nmap -p 3306 --open 192.168.1.0/24

# Host discovery + version scan concatenati (solo host attivi)
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

L’ultimo comando è particolarmente potente: esegue prima un ping scan, filtra gli host attivi, poi esegue la version scan solo su di loro. Ideale per subnet grandi.

Gestione dei Target e Firewall

# Range di IP
nmap 192.168.1.1-50

# Host da file (uno per riga)
nmap -iL hosts.txt

# Escludere host dalla scansione
nmap 192.168.1.0/24 --exclude 192.168.1.1,192.168.1.5

nmap distingue tre stati delle porte: open, closed e filtered. Una porta filtered indica che un firewall sta bloccando i probe. Se vedete molte porte filtered su un server di vostra proprietà senza aspettarvelo, investigate: potrebbe essere ufw, firewalld, regole nftables o un security group del cloud provider.

Conclusione

Host discovery, port scanning, version detection, NSE scripts e salvataggio dell’output sono le fondamenta di nmap. Iniziate con -sn per la discovery, aggiungete -sV quando servono i dettagli sui servizi, portate gli script NSE quando volete approfondire. Mantenete il timing conservativo sulle reti di produzione e aggressivo nel vostro lab.

Se state verificando le regole firewall, nmap è tra i migliori strumenti per controllare che ciò che pensate sia bloccato lo sia davvero.

Fonte originale: nmap on Linux: Guide to Network Scanning and Discovery — LinuxBlog.io

nmap on Linux: Guide to Network Scanning and Discovery | LinuxBlog.io

A practical guide to nmap on Linux covering host discovery, port and service scanning, OS detection, NSE scripts, output formats, and real-world command combinations sysadmins actually use.

^{Hayden James (LinuxBlog.io)}