Riscrittura URL HAProxy in caso di errore 404

Come far riscrivere HAProxy su un back-end diverso quando il primo manca il file? Ciò di cui ho bisogno è errorlocfare una riscrittura invece del reindirizzamento, quindi il client non è a conoscenza del reindirizzamento.

Abbiamo sviluppato un'applicazione pensando a NginX, che era sia il proxy inverso di bilanciamento del carico sia il server Web per i file statici. L'applicazione si basa sul framework Opa che richiede sessioni permanenti basate su cookie, supportate sia da NginX che da HAproxy. La funzionalità dell'applicazione con cui abbiamo problemi è la generazione dinamica di contenuti. Genera immagini su richiesta, ma dopo la generazione viene salvato su disco ed è possibile accedervi staticamente con percorso deterministico.

Il problema è stato facilmente risolto con NginX: tenta di leggere il file locale e di utilizzare il back-end con bilanciamento del carico solo se il file è mancante (non ancora generato):

server {
  server_name wkaliszu.pl;
  location /thumb {
    root /path_on_disk/to_cached_content;
    expires 7d;
    # try to access already generated content
    try_files $uri @wkaliszu;
  }
  location / {
    # reverse proxy to the application
    [...]
  }
  location @wkaliszu {
    # reverse proxy to the application
    [...]
  }
}

Il server è stato migrato e ora utilizza HAPproxy per il bilanciamento del carico, che non è un server Web e non supporta questa funzionalità. Ora la generazione dinamica del software viene eseguita ogni volta che il client tenta di accedere alla risorsa, ciò che è molto più lento e spreca risorse. Andrebbe bene se potesse utilizzare il back-end successivo se il primo (semplice server Web di memorizzazione nella cache per file statici) non fosse riuscito con errore 404, ma non riesco a trovare un modo per farlo in modo semplice. /thumbMi viene in mente il reindirizzamento a NginX, che tenta di leggere il file statico e riscrive nuovamente su HAproxy con la nuova intestazione HTTP, ma vorrei trovare qualcosa di meglio.

I backend di HAProxy sono su o giù (o stanno per essere su / giù).

Esistono vari modi per verificare lo stato di un back-end, ma non sono a conoscenza di alcuno che fornisca il monitoraggio basato sulla richiesta. Una volta che una richiesta fallisce, quel backend verrebbe contrassegnato come down o fallire (in procinto di essere considerato down).

Questa è una logica molto diversa dalla configurazione di Nginx che stava instradando le richieste in base alla richiesta.

Vedo un paio di opzioni qui:

• Nginx come proxy di cache
• Usa i server app per i contenuti statici
• Usa un CDN

Caching Proxy

In HAProxy, utilizzeresti ACL per indirizzare le richieste di contenuto statico a un back-end specifico. Quei nodi backend eseguono nginx con un proxy di memorizzazione nella cache. Se nginx avesse il file nella cache, lo servirebbe solo. Altrimenti, chiamerebbe il tuo backend.

Usa i server app per i contenuti statici

Se i server delle app sono efficienti nel fornire contenuto statico, potrebbe non essere necessario suddividere la richiesta in haproxy. Basta inviare tutte le richieste ai back-end dell'applicazione. Costruisci la logica in essi per servire contenuto statico se disponibile e se non invia la richiesta al back-end.

Opzione CDN

Se è possibile utilizzare un dominio dedicato per il contenuto statico, è possibile utilizzare una rete CDN. Alla CDN, basta puntare all'URL di origine per i nodi dell'applicazione. È quindi possibile controllare la memorizzazione nella cache a livello di CDN. Questo è simile alla precedente memorizzazione nella cache di Nginx, tranne per il fatto che il provider CDN lo gestisce.