#2014lris - liferay in a cloud-driven world

Liferay in a Cloud-Driven WorldSpunti di riflessione sull'utilizzo in Cloud

Mariuzzo MauroLiferay Architect, SMC Treviso srl

Liferay Symposium Italy, Rome 2014- 2 -

Di cosa NON parlerò

● Come realizzare passo-passo– Un cluster Liferay– Una installazione su Amazon Web Services

● Comparazioni tra provider di soluzioni Iaas


Di cosa parlerò

● Di alcune possibili architetture di una soluzione Liferay

● Degli elementi da considerare nella progettazione / realizzazione di un cluster

● Degli elementi da considerare nel valutare il passaggio ad una soluzione in Cloud

● Di AWS come esempio di provider Iaas su cui ho esperienza diretta


Un breve sondaggio

● Quanti di voi già utilizzano Liferay in Cloud?– Quanti su AWS?

● Quanti di voi stanno valutando il passaggio al Cloud?● Quali elementi stanno motivando questo passaggio?


Un breve sondaggio

● Quanti di voi già utilizzano Liferay in Cloud?– Quanti su AWS?

● Quanti di voi stanno valutando il passaggio al Cloud?● Quali elementi stanno motivando questo passaggio?● I motivi più comuni

– Spendere nel modo giusto● Si realizza un POC per capire cosa davvero serve● Startup con poco budget che devono andare live per guadagnare

– Gestire meglio uno scenario di “Disaster Recovery”● Spesso un fault nel proprio datacenter scatena la ricerca di

soluzioni alternative


OK. Ma di cosa stiamo parlando?

Dell'architettura di una soluzione Liferay


Liferay, una soluzione su tre livelliP

rese

ntat

ion HTTP/Web servers.

Il ruolo principale del server HTTP è di bilanciare il carico dell'intero sistema. Esso funge anche da proxy (reverse-proxy) e da unico punto di ingresso al sistema difendendolo dagli accessi esterni (Internet)

App

licat

ions

Servlet Container o Application Server che eseguono Liferay

Dat

abas

e &

R

epos

itorie

s

Database relazionale, Document Library StorageMail Store, Chat Server, ....


Quanti server mi servono?

Quanti server sono necessari per una soluzione Liferay?

Database

Tomcat +

Liferay

Apache


Passare ad un Cluster. Perché?

Ci sono 3 elementi che spingono al passaggio ad una soluzione in cluster

✔ Prestazioni

✔ Scalabilità

✔ Disponibilità


Prestazioni

● CPU– Molte applicazioni web Java sono sensibili alle prestazioni

della CPU. Deve essere veloce per gestire la generazione delle pagine rapidamente

● Memoria– La memoria disponibile non determina solo il peso del GC;

ma anche le strategie di caching ed applicative

● I/O Disco– Hanno un impatto decisivo sul database e sulla ricerca

● Rete– Impattano sugli accessi a risorse non locale, e sulla quantità

e sul tempo di evasione delle richieste


Performance

Fisico != Virtuale● 1 Intel Xeon E5-2670 v2 CPU = 10 Core * 2 Thread/Core● 1 Virtual CPU = più o meno 1 CPU Thread


Scalabilità

● Qual è la capacità di erogazione sufficiente?● Come pianificare la scalabilità?

– Espansione on-demand– Meccanismi di automazione del processo

● Che strategie?– Scalare verticalmente (or scale up)– Scalare orizzontalmente (or scale out)


Disponibilità

Tipologie di disservizio● Server non disponibile (errore hw o sw)

– Cluster

● Data Center non disponibile– Utilizzo di più data center

● Hot-Cold● Hot-Warm● Hot-Hot (Cluster Geografico)


Disponibilità - Disaster Recovery

● Hot-Cold– Economico ma con discreti tempi di ripristino

● Hot-Warm– Il data center passivo non serve le richieste ma è pronto

all'azione– I dati viaggiano soprattutto da attivo a passivo

● Hot-Hot (geoclustering)– Le richieste sono servite da entrambi i data center– Complessità aggiuntive

● Sincronizzazione degli artefatti e dei dati (database, file store, cache, indexes)

● Traffico bidirezionale (latenza e capacità)


Passaggio a Cluster – Cosa serve sapere

E' necessario conoscere alcuni aspetti interni (e non) di Liferay per fare le cose nel modo giusto


Architettura interna di Liferay


Architettura interna di Liferay - caching

✔ Page HTML cache (CacheFilter)✔ Portlet caching (UI and resources)✔ CSS & JS cache: Minified & Bundled

✔ Page HTML cache (CacheFilter)✔ Portlet caching (UI and resources)✔ CSS & JS cache: Minified & Bundled

✔ MultiVM (Cluster Aware)

✔ SingleVM

✔ MultiVM (Cluster Aware)

✔ SingleVM

✔ Entity caching (Hibernate) (opz da 6.2)

✔ Query caching (Service Builder)

✔ Entity caching (Hibernate) (opz da 6.2)

✔ Query caching (Service Builder)


Architettura interna di Liferay - caching

● One to one● RMI (default <6.1)

● Multicast (default 6.1+)

● Centralized● Terracota (Terracota Edition)

● Memcache

Invalidation



● Database– tutti i nodi applicativi che incidono sul medesimo

schema database devono essere in cluster

● Document Library Store– deve essere condiviso tra i nodi– meglio cartella NFS per sfruttare il lock nativo



● Lucene– ogni nodo ha la sua copia locale– se le attività di ricerca sono predominanti oppure i

nodi sono superiori a 4 verificare convenienza di un Search Server esterno

– Meccanismo di bootstrap

● Schedulatore– Lo schedulatore interno Quartz usa il database come

coordinatore. Un solo nodo esegue il job. Ci sono meccanismi di resume / recovery



● Cache– Gli oggetti in cache vivono a lungo e finiscono

nella Old (non sono memory leak!)– Decide EhCache la strategia migliore per il

garbaging– Con una cache invalidante ogni nodo contiene

elementi diversi– Overflow su disco poco conveniente


Il cluster a rombo (Load Balancing)

Pre

sent

atio

nA

pplic

atio

nsD

atab

ase

&

Rep

osito

ries

Database Repository

Tomcat Tomcat

Web server

LiferayCluster


Il cluster applicativo Liferay

● Chiamato ClusterLink, sfrutta JGroups● Diversi meccanismi di discovery

– Multicast– Unicast– JDBCPing (6.2+)– Altri (vedere sorgenti JGroups)

● Più canali di comunicazione– Control-channel– Transfer-channel


Load-Balancer e Reverse-Proxy

Il WebServer svolge funzioni di bilanciatore del traffico e di unico punto di accesso verso i nodi applicativi (reverse-proxy)

Meglio “mod_proxy” o “mod_jk” ?


Load-Balancer e Reverse-Proxy

AJP!

● la richiesta che giunge all'Application Server mantiene diverse informazioni della richiesta originale (es: http o https)

● Vengono effettuate meno conversioni o analisi su dati di tipo stringa


Sticky Session e Replica Sessione

Liferay sfrutta la sessione del container il minimo indispensabile.

Un cluster Liferay è un “bilanciamento del carico tra i nodi”. Non è richiesta la replica della sessione

La richiesta di una risorsa prevede attività collaterali. Usare lo “sticky-session” per vincolare le richieste di un utente al medesimo nodo e sfruttare questo lavoro già compiuto.


Verso l'alta disponibilità

● Intervenire sul Database Engine– OracleRAC– MySQL Galera– PostgreSQL repmgr oppure PostgreSQL-XC– Oppure una soluzione custom Attivo / Passivo



● Intervenire sul Document Library Store– NAS con hardware ridondato– FreeNAS– Soluzione custom con 2 VM Linux in cluster di

sistema con file system replicato



● Intervenire su Liferay– Aumentare i nodi in relazione ai picchi rilevati

durante gli stress test o l'uso quotidiano



● Intervenire sul Web Server– Almeno due nodi (attivo / passivo) che si

contendono un Virtual-IP

192.168.1.101 192.168.1.102

VIP = 192.168.1.90

CentOS 6.4+ cman + pacemaker

Apache



● Intervenire sul motore di ricerca (opzionale)– Quando i nodi aumentano le attività di replica di

Lucene possono essere rilevanti– Solr 4 introduce SolrCloud che permette di avere

più nodi master.– Plugin su Liferay Marketplace per Solr 4



● Intervenire sui contenuti “statici” (opzionale)– Liferay prevede out-of-the-box l'uso di Content

Delivery Network (CDN) per fornire contenuti statici o considerabili tali

– Integrare una CDN è molto diverso da “configurare una cache delle richieste”: è Liferay che decide quali risorse far fornire dalla CDN, e di sicuro non quelle html

– E' possibile usare Squid come “CDN casalinga”. Squid si troverà accanto alla coppia “WebServer + Liferay” non davanti



● Intervenire sulla sessione (opzionale)– Introdurre un sistema di Single SignOn per evitare

la replica della sessione


Verso l'altra disponibilità

Database

Pre

sent

atio

nA

pplic

atio

nsD

atab

ase

&

Rep

osito

ries

Tomcat Tomcat

LiferayCluster

Repository

LiferayCluster

Web server Active Web server Passive

Tomcat


Verso il Cloud

Quanto visto finora può essere tranquillamente realizzato e gestito “on-premise”

E per andare in Cloud?● Performance● Scalabilità● Disponibilità


Performance in Cloud (AWS)

Fisico != Virtuale● 1 Intel Xeon E5-2670 v2 CPU = 10 Core * 2 Thread/Core● 1 Virtual CPU = più o meno 1 CPU Thread


Scalabilità in Cloud – AWS Horizontal Scaling


Scalabilità in Cloud – AWS AutoScaling


Disponibilità in Cloud – AWS Multi-AZ

● Più data-center distribuiti geograficamente (Regions e Zones)– La latenza tra le zone è bassa

● Servizi gestiti in alta disponibilità all'interno della regione– S3/ESB backend hanno visibilità per region– ELB vede solo nodi all'interno della region. E'

necessario usare S3 Route per distribuire le richieste in base a policy configurabili (latenza, geolocation, peso, etc.)

– ELB a volte non sente i nodi ripristinati


Disponibilità in Cloud – AWS Multi-AZ


Cloud vs On-premise

● Cloud– Incidenza geografica

(Azs)– Scalabilità flessibile in

base al carico– Le VM in cloud

gestiscono meno utenti per macchina

– Solo licenze OPEX

● Il tuo data center– Costruirli o affittarli– Acquistare hardware

sufficiente gestire il picco di carico

– Maggiore flessibilità sulle soluzioni hardware (CPU potenti, memoria ad-hoc, etc.)

– Licenze CAPEX e OPEX


Cloud vs On-premise

● I conti dell'oste AWS– Una istanza EC2 Compute Optimized c3.4xlarge

● 16 vCPU (Intel Xeon E5-2680 v2 2.5GHz)● 30 GiB RAM● Riservata ad utilizo medio, per 3 anni costa: $7,148.16 ($3,300.00

anticipati)

– Un Dell PowerEdge R920● 2 x Intel Xeon E7-4820 v2 2.0GHz, 16M cache, 7.2 GT/s QPI Turbo,

8Core● 16 GiB RAM● Costa $10,164.32

● Non sono considerati i costi di elettricità, gestione infrastrutturale, etc.


Cloud vs On-premise

● I conti dell'oste AWS– Traferimento dati attraverso un IP Pubblico o Elastic IP

● Costa $0.01/GiB per istanza EC2

– Trasferimento dati verso Internet da istanza EC2● Primo GiB/mese gratuito● Fino a 10TiB/mese costa $0.12 per GiB

– S3 Route ha un costo– Trasferimento dati tra zone o tra regioni ha un costo– Le regole e gli allarmi CloudWatch hanno un costo


Considerazioni Finali

● Non scartate l'approccio ibrido– Realizzate una soluzione on-premise capace di gestire il 60-70% del

carico– Demandate al cloud la tolleranza agli errori ed i sovraccarichi

● Quando scegliete un provider Iaas, controllate le funzionalità chiave– Scalabilità automatica

● Possibilità di scalare (in e out) in base al carico

– Sistemi di monitoraggio● Controllo dello stato dei vari sistemi per attivare auto scaling

– Zone di disponibilità multiple– API

● Possibilità di avere automatizzare in modo custom il processo di deploy● Ecosistema dei tool e delle applicazioni


Liferay in a Cloud-Driven WorldSpunti di riflessione sull'utilizzo in Cloud

Mariuzzo MauroLiferay Architect on SMC


Riferimenti

● Gartner IaaS Comparison (Magic Quadrant)– “http://www.gartner.com/technology/reprints.do?id=1-1UKQQA6&ct=140528&st=sb”– “http://blogs.gartner.com/lydia_leong/2014/05/30/the-2014-cloud-iaas-magic-quadrant”

● Netflix talks on AWS re:Invent– “http://techblog.netflix.com/search/label/reinvent”

● EC2 instances types– “http://aws.amazon.com/ec2/instance-types”

● Virtual CPUs in EC2 machines (Blog Post)– “http://www.pythian.com/blog/virtual-cpus-with-amazon-web-services/”

● Web search for a planet: the Google cluster architecture (IEEE 2003 Paper)– “http://static.googleusercontent.com/media/research.google.com/en/us/archive/googlecluster-ieee.pdf”

● Designing for Fault-tolerance in Cloud Computing (SOA Cloud 2012 Talk)– “http://www.infoq.com/presentations/Design-Fault-tolerance-Cloud”

● AWS Route 53 routing policies (AWS documentation)– “http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html”

● Overcoming Outages in AWS : High Availability Architectures (Blog Post)– “http://harish11g.blogspot.in/2012/06/aws-high-availability-outage.html”

● Configuring a Liferay cluster (Liferay Blog Post)– “https://www.liferay.com/web/fimez/blog/-/blogs/configuring-a-liferay-cluster-and-make-it-use-unicast-”

http://www.gartner.com/technology/reprints.do?id=1-1UKQQA6&ct=140528&st=sb

http://blogs.gartner.com/lydia_leong/2014/05/30/the-2014-cloud-iaas-magic-quadrant

http://techblog.netflix.com/search/label/reinvent

http://aws.amazon.com/ec2/instance-types

http://www.pythian.com/blog/virtual-cpus-with-amazon-web-services/

http://static.googleusercontent.com/media/research.google.com/en/us/archive/googlecluster-ieee.pdf

http://www.infoq.com/presentations/Design-Fault-tolerance-Cloud

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html

http://harish11g.blogspot.in/2012/06/aws-high-availability-outage.html

https://www.liferay.com/web/fimez/blog/-/blogs/configuring-a-liferay-cluster-and-make-it-use-unicast-

#2014lris - liferay in a cloud-driven world

Technology