Capitolo 2 - Infrastruttura

Configurazione di un’infrastruttura di caching

Nel capitolo 1 di questa serie abbiamo introdotto la topologia di base di un sistema di pubblicazione e di un dispatcher. Un set di server di pubblicazione 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 prevedeva che un’istanza di Dispatcher fungesse da load balancer e da cache davanti a due o più sistemi di pubblicazione. Il server Apache nella parte centrale di Dispatcher era molto stabile e, nella maggior parte delle impostazioni, abbastanza capace per soddisfare una quantità discreta di richieste.

Configurazione di Dispatcher "legacy": non molto comune secondo gli 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 di pubblicazione. Un load balancer (hardware) dedicato si trova di fronte all’infrastruttura AEM e invia le richieste a queste due (o più) parti:

Configurazione moderna di Dispatcher standard: facilità di gestione e manutenzione

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 di pubblicazione?

Configurazione "Scalabilità orizzontale": presenta alcune aree di 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 di pubblicazione è connesso a una moltitudine di istanze di Dispatcher e ogni istanza deve essere invalidata quando 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 desideri aggiornare solo una parte dei sistemi di pubblicazione, mentre gli altri servono ancora attivamente il traffico e poi, dopo il test, passa 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 della pubblicazione 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 di pubblicazione 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. 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 tale pagina, ovviamente, non deve essere memorizzata nella cache di Dispatcher, pertanto viene sempre recuperata appena dal sistema di pubblicazione. Ora, se configuri il load balancer per controllare questo modello o servlet, puoi facilmente far finta che l’opzione Pubblica non sia attiva. Non farebbe parte del bilanciamento del carico e può essere aggiornato.

Distribuzione mondiale

"Distribuzione mondiale" è una configurazione "scalabile" in cui sono presenti più Dispatcher davanti a ciascun sistema Publish, ora distribuito in tutto il mondo per essere più vicino 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’istanza di Dispatcher annulla la validità "automaticamente": ogni volta che viene pubblicata una pagina, tutte le pagine della cache sullo stesso sito vengono invalidate. Questa è una funzione utile, ne abbiamo parlato in Capitolo 1 di questa serie - ma significa anche, che quando si verificano frequenti modifiche sul sito web si sta invalidando la cache abbastanza spesso. Se disponi di una sola istanza di Dispatcher per pubblicazione, 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. Dispatcher più numerosi per ogni pubblicazione peggiorano ulteriormente le cose. In questo caso il server di pubblicazione 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 - Non è consigliabile condividere un file system comune tra più istanze di Dispatcher.

Se riscontri problemi di prestazioni, aumenta la scalabilità di Publish e Dispatcher allo stesso modo per evitare il picco di carico sulle istanze di Publisher. Non esiste una regola d’oro sul rapporto Publish/Dispatcher, dipende infatti fortemente dalla distribuzione delle richieste e dalla frequenza delle pubblicazioni e degli invalidamenti dati cache.

Se sei anche preoccupato per la latenza di un visitatore, puoi utilizzare una rete di distribuzione dei contenuti, recuperare la cache in anticipo, scaldare la cache in anticipo, impostando un tempo di tolleranza come descritto in Capitolo 1 o fare 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 connessi 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 che siano presenti due sistemi Publish che eseguono il rendering. Inoltre, in caso di arresto anomalo di uno dei sistemi di pubblicazione, sono 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 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