Backend

Monitoraggio dei backend

Il Web Accelerator monitora costantemente il funzionamento dei backend, verificando che le richieste per uno specifico URL restituiscano 200.

Quando il monitoraggio segnala un errore, il Web Accelerator smette di inviare richieste a quel backend. Nel caso non ci siano altri backend funzionanti allora continuerà a rispondere con gli oggetti rimasti in cache anche per un certo periodo dopo la loro scadenza, e dopo con una pagina di cortesia. In questo modo brevi guasti o manutenzioni di un sito cacheabile possono restare invisibili ai visitatori.

Normalmente il personale di Seeweb installa un file ping.php nel sito, oppure in un dominio creato ad hoc nel caso il backend gestisca più siti. Nel caso di siti gestiti con Wordpress, il file monitora automaticamente anche il funzionamento del server del database. In ogni caso il cliente può fornire un URL di monitoraggio adeguato alle proprie esigenze.

Pagina di cortesia

Se tutti i backend sono irraggiungibili e non c'è una risposta usabile nella cache allora il Web Accelerator risponde con una pagina di cortesia.

Se desiderato è possibile personalizzarla con la propria grafica.

Poiché la pagina di cortesia deve funzionare anche quando il backend non è disponibile, il nostro personale inserirà inline gli eventuali CSS e immagini. Raccomandiamo che non superi la dimensione di circa 10 kB.

Load balancing dei backend

La ridondanza e scalabilità dei backend è gestibile con un meccanismo di load balancing: il Web Accelerator può inoltrare il traffico a più backend e ignorare quelli non funzionanti.

Backend multipli

In caso di siti complessi in cui diverse parti dello stesso dominio sono gestite da backend diversi, il Web Accelerator può gestire il routing delle richieste verso il backend appropriato sulla base dell'URL o di altre caratteristiche.

Gestione dei veri IP dei visitatori

Il backend vede arrivare tutte le richieste dall'IP del Web Accelerator e può usare l'header standard X-Forwarded-For per ottenere il vero IP del visitatore.

Se il backend usa Apache allora il nostro personale configurerà mod_rpaf o mod_remoteip per gestirlo in modo trasparente.

Per i backend con IIS si può impostare:

Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' ↩
  -filter "system.applicationHost/sites/siteDefaults/logFile/↩
  customFields" -name "." -value @{logFieldName='X-Forwarded-For';↩
  sourceName='X-Forwarded-For';sourceType='RequestHeader'}

Gestione delle richieste HTTPS

Il Web Accelerator svolge anche la funzione di terminatore TLS, quindi le richieste originariamente fatte con HTTPS arrivano al backend sempre con HTTP e sono distinguibili da un header X-Forwarded-Proto: https.

Nella configurazione predefinita il Web Accelerator fa da solo il redirect da HTTP a HTTPS, quindi il backend può essere configurato semplicemente con solo HTTP e senza bisogno di gestire direttamente la logica dei redirect.

Nel caso il CMS voglia distinguere le richieste HTTP da quelle HTTPS si può integrarlo con questa direttiva di Apache, che di solito il nostro personale ha già installato nella configurazione generale del server:

SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on

Nel caso si usi nginx invece è possibile configurare, per esempio in /etc/nginx/fastcgi.conf:

fastcgi_param X_FORWARDED_PROTO $http_x_forwarded_proto if_not_empty;

Raramente alcuni plugin di Wordpress invece richiedono di inserire del codice come questo direttamente in wp-config.php:

/* Per la gestione di HTTPS tramite il Web Accelerator --Seeweb */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
       && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS'] = 'on';

Timeout

Il Web Accelerator implementa timeout a diversi livelli per terminare le richieste che richiedono troppo tempo. Raccomandiamo di non aumentarli in modo generalizzato per evitare di rendere il servizio più vulnerabile ad attacchi denial of service.

Il nostro personale è a disposizione per investigare eventuali timeout troppo brevi, ma tipicamente il caso più comune è che scatti quello relativo al primo byte di risposta inviato dal server. È possibile aumentarlo, ma questo spesso indica che l'applicazione è mal scritta e fa buffering di una grande risposta invece che inviarla man mano che viene generata.