Capitolo 2 - Infrastruttura

Configurazione di un’infrastruttura di caching

Nel capitolo 1 di questa serie abbiamo introdotto la topologia di base di un sistema Publish e di un dispatcher. Un set di server Publish e Dispatcher può essere configurato in numerose varianti, a seconda del carico previsto, della topologia dei data center e delle proprietà di failover desiderate.

Descriveremo le topologie più comuni e i vantaggi e le situazioni in cui non sono sufficienti. L'elenco - ovviamente - non può mai essere completo. L'unico limite è la vostra immaginazione.

Configurazione "Legacy"

All'inizio, il numero di potenziali visitatori era limitato, l'hardware costoso e i server web non erano visti come business critical come lo sono oggi. Una configurazione comune consisteva nell’avere un Dispatcher che fungeva da load balancer e una cache davanti a due o più sistemi Publish. Il server Apache nel nucleo di Dispatcher era molto stabile e, nella maggior parte delle impostazioni, abbastanza capace per soddisfare una quantità decente di richieste.

Installazione di Dispatcher "legacy" - Non molto comune negli standard attuali

Il dispatcher ha ricevuto il proprio nome da: in pratica stava inviando richieste. Questa configurazione non è più molto comune in quanto non è in grado di soddisfare i requisiti più elevati in termini di prestazioni e stabilità attualmente richiesti.

Configurazione con più leghe

Oggi una topologia leggermente diversa è più comune. Una topologia a più gambe avrebbe un Dispatcher per server Publish. Un load balancer (hardware) dedicato si trova di fronte all’infrastruttura AEM e invia le richieste a queste due (o più) parti:

Installazione moderna di Dispatcher "Standard" - Facile da gestire e mantenere

Ecco le ragioni di questo tipo di configurazione,

Impostazione di "scalabilità orizzontale"

I server Apache sono economici e facili da predisporre, perché non spingere di più la scalabilità di quel livello. Perché non ci sono due o più Dispatcher davanti a ciascun server Publish?

Installazione di

Installazione di "Scale Out": presenta alcune aree dell'applicazione, ma anche limitazioni e avvertenze

Puoi assolutamente farlo! Esistono molti scenari di applicazione validi per questa configurazione. Ma ci sono anche alcune limitazioni e complessità che dovresti considerare.

Annullamento validità

Ogni sistema Publish è connesso a una moltitudine di Dispatcher e deve essere invalidato ogni volta che il contenuto viene modificato.

Manutenzione

Va da sé che la configurazione iniziale dei sistemi Dispatcher e Publish è un po' più complessa. Tuttavia, tieni presente che anche lo sforzo di una versione "continua" è un po’ maggiore. I sistemi AEM possono e devono essere aggiornati durante l'esecuzione. Ma è saggio non farlo mentre stanno attivamente servendo le richieste. Di solito si desidera aggiornare solo una parte dei sistemi Publish, mentre gli altri servono ancora attivamente il traffico e poi, dopo il test, passare all’altra parte. Se sei fortunato e puoi accedere al load balancer nel processo di distribuzione, puoi disabilitare il routing ai server in manutenzione qui. Se ti trovi in un load balancer condiviso senza accesso diretto, è preferibile chiudere i dispatcher del Publish che desideri aggiornare. Più ce ne sono, più dovrai chiudere. Se il numero è elevato e si pianificano aggiornamenti frequenti, si consiglia di eseguire un’automazione. Se non si dispone di strumenti di automazione, la scalabilità è una cattiva idea in ogni caso.

In un progetto precedente abbiamo utilizzato un trucco diverso per rimuovere un sistema Publish dal bilanciamento del carico senza avere accesso diretto al load balancer stesso.

Il load-balancer solitamente esegue un ping, una particolare pagina per vedere se il server è in esecuzione. Una scelta banale di solito è quella di eseguire il ping della home page. Ma se vuoi usare il ping per segnalare al load-balancer di non bilanciare il traffico, puoi scegliere qualcos'altro. Si crea un modello o un servlet dedicato che può essere configurato per rispondere con "up" o "down" (nel corpo o come codice di risposta http). La risposta di quella pagina ovviamente non deve essere memorizzata nella cache di Dispatcher, pertanto viene sempre recuperata appena dal sistema Publish. Ora, se configuri il load balancer per controllare questo modello o servlet, puoi facilmente far "finta" che Publish non funzioni più. Non farebbe parte del bilanciamento del carico e può essere aggiornato.

Distribuzione mondiale

"Distribuzione mondiale" è una configurazione "scalabile" in cui sono presenti più istanze di Dispatcher davanti a ciascun sistema Publish, ora distribuite in tutto il mondo per essere più vicini al cliente e fornire prestazioni migliori. Naturalmente, in questo scenario non si dispone di un load balancer centrale, ma di uno schema di bilanciamento del carico basato su DNS e geo-IP.

Ridimensionamento orizzontale

Anche in un centro dati locale, una topologia con scalabilità orizzontale con più istanze di Dispatcher davanti a ciascun sistema Publish presenta alcuni vantaggi. Se osservi dei colli di bottiglia delle prestazioni sui server Apache a causa del traffico elevato (e di una buona percentuale di hit della cache) e non riesci più a scalare l’hardware (aggiungendo CPU, RAM e dischi più veloci), puoi migliorare le prestazioni aggiungendo Dispatcher. Questa operazione è denominata "ridimensionamento orizzontale". Tuttavia, questo ha dei limiti - soprattutto quando annulli frequentemente la validità del traffico. L’effetto verrà descritto nella sezione successiva.

Limiti della topologia di scalabilità orizzontale

L'aggiunta di server proxy dovrebbe di norma aumentare le prestazioni. Esistono tuttavia scenari in cui l'aggiunta di server può effettivamente ridurre le prestazioni. Come? Considera di avere un portale di notizie, in cui introdurre nuovi articoli e pagine ogni minuto. Un Dispatcher invalida tramite "annullamento automatico della validità": ogni volta che una pagina viene pubblicata, tutte le pagine nella cache sullo stesso sito vengono invalidate. Questa è una funzione utile - l'abbiamo trattata nel Capitolo 1 di questa serie - ma significa anche che quando si apportano frequenti modifiche al sito Web, la cache viene invalidata molto spesso. Se disponi di un solo Dispatcher per ogni istanza di Publish, il primo visitatore che richiede una pagina attiva una nuova memorizzazione in cache della pagina. Il secondo visitatore ottiene già la versione cache.

Se disponi di due istanze di Dispatcher, il secondo visitatore ha il 50% di possibilità di non memorizzare la pagina in cache e quindi riscontra una latenza più ampia quando viene eseguito di nuovo il rendering di quella pagina. Disporre di un numero ancora maggiore di Dispatcher per Publish peggiora ulteriormente le cose. In questo caso, il server Publish riceve un carico maggiore perché deve eseguire nuovamente il rendering della pagina separatamente per ogni Dispatcher.

Prestazioni ridotte in uno scenario di scalabilità orizzontale con frequenti scaricamenti della cache.

Mitigazione dei problemi di overscaling

Per attenuare i problemi, puoi utilizzare un’archiviazione condivisa centrale per tutti i Dispatcher o sincronizzare i file system dei server Apache. Possiamo fornire solo un’esperienza diretta limitata, ma dobbiamo essere preparati che questo aggiunga complessità al sistema e possa introdurre una nuova classe di errori.

Abbiamo fatto alcuni esperimenti con NFS, ma NFS introduce enormi problemi di prestazioni dovuti al blocco dei contenuti. Questo ha effettivamente diminuito le prestazioni complessive.

Conclusione - La condivisione di un file system comune tra diversi dispatcher NON è un approccio consigliato.

Se riscontri problemi di prestazioni, aumenta allo stesso modo Publish e Dispatcher per evitare il picco di carico sulle istanze di Publisher. Non esiste una regola d'oro per quanto riguarda il rapporto Publish / Dispatcher: dipende in larga misura dalla distribuzione delle richieste e dalla frequenza delle pubblicazioni e degli invalidamenti della cache.

Se sei anche preoccupato per la latenza di un visitatore, prendi in considerazione l'utilizzo di una rete di distribuzione del contenuto, il recupero della cache, il riscaldamento preventivo della cache, l'impostazione di un tempo di tolleranza come descritto nel Capitolo 1 di questa serie o fai riferimento ad alcune idee avanzate di Parte 3.

Configurazione di Cross Connected

Un’altra configurazione che abbiamo visto di tanto in tanto è la configurazione "cross connected": le istanze Publish non dispongono di Dispatcher dedicati, ma tutti i Dispatcher sono collegati a tutti i sistemi Publish.

Topologia cross-connected: maggiore ridondanza e complessità.

A prima vista, questo fornisce un po' più di ridondanza per un budget relativamente piccolo. Quando uno dei server Apache non è attivo, è comunque possibile avere due sistemi Publish che eseguono il rendering. Inoltre, in caso di arresto anomalo di uno dei sistemi Publish, sono ancora presenti due dispatcher che servono il carico memorizzato nella cache.

Questo però viene fornito con un prezzo.

Primo, togliere una gamba per il mantenimento è abbastanza complicato. In realtà, questo è lo scopo del progetto: essere più resilienti e rimanere operativi con tutti i mezzi possibili. Abbiamo visto piani di manutenzione complicati su come affrontare questo problema. Riconfigura prima Dispatcher 2, rimuovendo la connessione incrociata. Riavvio di Dispatcher 2. Arresto di Dispatcher 1, aggiornamento di Publish 1, … e così via. Deve considerare attentamente se si possono raggiungere più di due gambe. Arriverete alla conclusione che in realtà aumenta la complessità, i costi ed è una fonte formidabile di errore umano. Sarebbe meglio automatizzare questa operazione. Verificate quindi se disponete delle risorse umane necessarie per includere questa attività di automazione nella programmazione del progetto. Anche se con questo si potrebbero risparmiare alcuni costi hardware, si potrebbe spendere il doppio per il personale IT.

In secondo luogo, potresti avere un’applicazione utente in esecuzione sull’AEM che richiede un accesso. Utilizza le sessioni permanenti per garantire che un utente sia sempre servito dalla stessa istanza AEM in modo da poter mantenere lo stato della sessione su tale istanza. Con questa configurazione con connessione incrociata, devi assicurarti che le sessioni permanenti funzionino correttamente sul load balancer e sui Dispatcher. Non è impossibile, ma è necessario tenerne conto e aggiungere ore aggiuntive di configurazione e test, che potrebbero livellare il risparmio pianificato con il risparmio di hardware.

Conclusione

Si sconsiglia di utilizzare questo schema di connessione incrociata come opzione predefinita. Tuttavia, se decidi di utilizzarla, dovrai valutare attentamente i rischi e i costi nascosti e pianificare l’inclusione dell’automazione della configurazione come parte del progetto.

Passaggio successivo