Alfresco HA/Cluster

Considerazioni iniziali

Per applicazioni web complesse come alfresco o per esempio liferay sono quattro i componenti da tenere in considerazione quando si effettuano operazioni di alta affidabilità / load balancing

  1. l'application server, tomcat o altro
  2. il dabatase
  3. gil indici di ricerca
  4. il repository dei file

Docs ufficiale Administratig > Setting up high availability systems

guida ufficiale

Guida del wiki - Cluster Configuration V2.1.3 and Later

Questa guida parte dalla 2.1 ma ha anche riferimenti più aggiornati.

High availability components

Per funzionare bisogna configurare jgroup la pagina in questione è questa http://wiki.alfresco.com/wiki/Configuring_JGroups_and_Alfresco_Clusters

Configuring JGroups and Alfresco Clusters

È stato introdotto dalla versione 3.1 di alfresco e sostituisce il meccanismo di discover di ehcache funziona solo sulla enterprise non sulla comunity.
Dalla versione 3.1 il cluster funziona solo se aggiungiamo ad alfresco-global.properties la riga

alfresco.cluster.name=<CLUSTERNAME>

in questo modo ignora eventuali altri cluster sulla stessa rete, che abbiano nomi diversi.

Ci sono diversi modi di collegarsi non solo tramite jgroups alcuni anche originali come scrivere le info sul bucket s3 di amazon. Sulla pagina sono descritti i metodi.

JLAN clustering

Se vogliamo clusterizzare l'utilizzo dei protocolli FTP, CIFS, NFS è possibile farlo dalla versione 4.0 tramite Configuring Hazelcast for JLAN clustering http://wiki.alfresco.com/wiki/Configuring_Hazelcast_for_JLAN_clustering

Client session replication

È supportato dalla versione 2.2.0 in avanti.

Index synchronization

Gli indici non devono essere condivisi ma ogni nodo ha i propri. Possono essere ricreati a partire dalle informazioni sul db.

Cache replication

Serve per replicare gli oggetti del db.

Soluzione dal forum

A questo indirizzo https://forums.alfresco.com/en/viewtopic.php?f=6&t=43310#p126688 c'è una soluzione di ha con alfresco 3.6

Installazione del cluster step to step

Ho eseguito una installazione semplice indici replicati , content store condiviso con db oracle in comune. Come motore degl indici ho usato lucene con solr è un po' diverso.

  • configurare ip delle macchine e montare una cartella condivisa per l'alf_data
  • configurare ntp sulle macchina in modo che l'ora sia sincronizzata dice che deve essere meno di 10 secondi meglio se meno di 5 di differenza
yum install ntp
chkconfig ntpd on
ntpdate pool.ntp.org
/etc/init.d/ntpd start
  • fare l'installazione passo di alfresco , io ho scelto quella a componenti http://gborgese.wikidot.com/alfresco-installazione
  • dopo che entrambe le istanze funzionano alternate sullo stesso content store con lo stesso db bisogna spostare gli indici su una directory locale in modo che funzionino separati. Ho copiato la directory lucene-indexes su una parte del file system non condiviso e cambiato queste proprietà negli alfresco-global.properties
  • l'alf_data con il content store condiviso deve stare su una dir condivisa
dir.root=/condivisa/alf_data

dir.alfresco=/opt/edocumento/alfresco-tomcat

dir.indexes=${dir.alfresco}/lucene-indexes
dir.indexes.backup=${dir.alfresco}/backup-lucene-indexes
dir.indexes.lock=${dir.indexes}/locks
index.subsystem.name=lucene

Deve esserci settata nella java_opts la variabile per gli ipv4 altrimenti di default va sul ipv6

JAVA_OPTS="-Xms1000m -Xmx2000m -XX:PermSize=1000M -XX:MaxPermSize=2000M -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true"

Se sul log da qualcosa del genere è corretto
GMS: address=alfha2-22228, cluster=napoli-cluster:EHCACHE_HEARTBEAT, physical address=192.168.99.169:7801

Se invece da qualcosa con indirizzi ip v6 allora la variabile non è stata settata correttamente.
-------------------------------------------------------------------
GMS: address=alfha2-54827, cluster=napoli-cluster:org.alfresco.enterprise.repo.management.subsystems.PropertyBackedBeanExporter, physical address=fe80:0:0:0:250:56ff:feb5:7342%2:7800
-------------------------------------------------------------------

Per abilitare il riconoscimento delle istanze si devono settare queste properties dentro l'alfresco-global.properties

alfresco.cluster.name=napoli-cluster
alfresco.jgroups.bind_address=192.168.99.169
alfresco.jgroups.bind_interface=eth1
alfresco.jgroups.defaultProtocol=TCP
alfresco.tcp.initial_hosts=192.168.99.170[7800]
  • il nome del cluster deve essere lo stesso ovviamente
  • il bind_address è l'indirizzo della macchina dove l'alfresco si trova in esecuzione
  • bind_interface è l'interfaccia di rete della macchina dove l'alfresco si trova in esecuzione
  • queste sono le impostazioni per usare jgroups con tcp si può usare anche con udp sono però altri i parametri da utilizzare
  • initial_hosts elenco dei possibili host e porte che fanno parte del cluster, è opzionale perchè comunque la cosa viene fatta a caldo si può mettere nell'elenco separato da virgole anche l'host stesso.

Bisogna copiare il file ehcache-custom.xml.sample.cluster rinominandolo dentro ./shared/classes/alfresco/extension/ehcache-custom.xml
E qui si presentano due modi per configurare il cluster con cache replication o senza,
In entrambi i modi dentro il file nella prima parte deve essere abilitata questa dichiarazione

    <cacheManagerPeerProviderFactory
        class="org.alfresco.repo.cache.AlfrescoCacheManagerPeerProviderFactory"
        properties="heartbeatInterval=5000,
                    peerDiscovery=automatic,
                    multicastGroupAddress=230.0.0.1,
                    multicastGroupPort=4446"
    />

Installazione con sincronizzazione della cache disabilitata

Questa è l'unica modalità che mi è funzionata l'altra invece non andava. Deve essere abilitata la dichiarazione sotto, se invece si vuole fare con replicazione della cache vedi sotto

    <cacheManagerPeerListenerFactory
        class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
        properties="socketTimeoutMillis=10000"
    />

Installazione con replicazione di ehcache abitlitata

Al posto della dichiarazione sopra deve esserci questa

 <cacheManagerPeerListenerFactory
        class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
        properties="hostName=${alfresco.ehcache.rmi.hostname},
                    port=${alfresco.ehcache.rmi.port},
                    remoteObjectPort=${alfresco.ehcache.rmi.remoteObjectPort},
                    socketTimeoutMillis=${alfresco.ehcache.rmi.socketTimeoutMillis}"
        />

e dentro l'alfresco-globarl.properties devono esserci i seguenti valori
alfresco.ehcache.rmi.hostname=192.168.99.170
alfresco.rmi.services.external.host=192.168.99.170
alfresco.ehcache.rmi.port=40001
alfresco.ehcache.rmi.remoteObjectPort=45001

dove l'ip è quella della macchina locale
Al riavvio le istanze si identificano quando si trovano scrivendo sul catalina.out qualcosa del genere
 New View:  [alfha2-22228|1] [alfha2-22228, alfha1-47099]

QUESTA CONFIGURAZIONE NON MI È MAI FUNZIONATA. Dava eccezione alla prima visualizzazione e il controllo con la jconsole guardando il parametro MBeans > Alfresco > RepoServerMgmt > Attributes > TicketCountAll attribute era diverso per ogni nodo.

Appunti del corso

ehcache

Le query per il db e l'accesso all'alf_data vengono cachati da ehcache. Se faccio una modifica invalido la parte di cache in modo da mantenere una coerenza. Se faccio modifiche dirette al db la cache rimane non aggiornata. C'è la situazione in cluster dove il db viene modificato da un'istanza del cluster che non passa dalla stessa cache.

content store

Anche se nella letteratura di alfresco è presente la possibilità, è sconsigliato usare dei content store replicati, conviene usare un content store condiviso.

indici gestione

Lucene ha bisogno di un accesso esclusivo agli indici niente storage condiviso, quindi indici in locale.
A Solr invece ci si accede tramite ws.
Va impostato il parametro

index.recovery.mode= AUTO

Per Lucene le istanze (web app alfresco.war) controllano di default ogni 5 secondi tramite accesso al db se ci sono modifiche da fare.
Solr fa il controllo ogni 15 secondi. Modificare la frequenza è sconsigliato.

db

Non si può usare il cluster di mysql perchè non è compatibile, almeno fino a qualche versione precedente alla 4. Alfresco fa il controllo perchè vuole tabelle innodb che sono diverse da quelle di mysql cluster.

connessione nodi del cluster

Dalla 4.1 c'è la modalità multicast per aggiunta nodi a caldo del cluster. Se aggiungo un membro al cluster in unicast devo riavviare perchè aggiungo i nodi del cluster nei file di conf, questa modalità è più sicura. In multicast la join funziona con il nome del cluster.
Modificare alfresco-global.properties aggiungendo clustern name, il cron per l'aggironamento degli indici ogni 5 secondi, index.mode=AUTO

sessioni

Le session tra i nodi di alfresco non sono condivise quindi un utente deve andare sempre sullo stesso nodo e se questo muore deve rifare la login.

solr multiplo

Se si usa solr in cluster bisogna metterne due, con un bilanciatore davanti, altrimenti si ha un single point of failure. È stata sperimentata in un ambiente molto stressato che ognuno dei solr per effettuare il controllo per l'aggiornamento degli indici usi un alfresco interno che poi accede al db unico condiviso. In questo caso l'alfresco sarà più leggero rispetto a quello usato normalmente e non paghi un ulteriore licenza per i socket. In ogni caso sono situazioni di carico estremo.

Slides sintetiche per comprendere ad alto livello

generiche

In queste slides ci sono delle interessanti problematiche da capire http://www.slideshare.net/alfresco/06192008-high-availability-clustering-with-alfresco

  • Alla slide 4 -5 - 7 si vede la possibilità di un content store su due livelli, quindi il content store primario in locale sull'ambiente e il secondario su uno storage condiviso che ovviamente sarà più lento.
  • per gli indici slides 6 invece serve che ogni nodo abbia la sua copia
  • per il db slides 8-9 ci possono essere soluzioni di master/slave oppure master/master

Piccoli accorgimenti di utilizzo per non sovraccaricare

http://www.slideshare.net/alfresco/scale-your-alfresco-solutions intorno a slides 30

  • usare versionamento e indicizzazione solo quando è appropriato e non solo perchè c'è. Quindi non applicare cm:versionable a cm:content
  • usare le quote salva il repository dall'esplosione.

tuning best practice

  • il numero di connessioni al database sono molto importanti il numero è numero di threads per workers + 75 per ogni nodo del cluster. Per il tomcat il valore di default è 275 . Non ho capito bene come usare questa formula.
  • la cache se si ha a disposizione più ram va incrementata, usare un tool per tracciare ehcache e incrementarla maggiori dettagli http://wiki.alfresco.com/wiki/Repository_Cache_Configuration
  • ci sono altre considtezione per alfresco lucene e network

indicazioni generali per ogni sistema

  • non usare soluzione troppo originali, ci sono già soluzioni fatte da alfresco
  • separare i livelli db, content store, application server
  • gli indici devono sempre stare su store veloci, no nfs o usb ecc.
  • non far morire il db dare il numero di connessioni adeguate al pool db.pool.max
  • per l'application server il numero di threads appropriato
  • quando si fa cluster usare jgroups e unicast (booo)

interessante le cose da non fare slides 37

riferimenti per il profiling e nagios

interessante http://www.slideshare.net/alfresco/large-scale-enterprise-deployments

Alfresco FAILOVER high availability infrastructure in real life

Questo paragrafo tratto da articoli di un blog wordpress, viene dal lavoro di un'azienda che come descritto nella prima pagina
http://alfrescoshare.wordpress.com/2009/11/29/alfresco-high-availability-infrastructure-in-real-life-part-1/ ha deciso di usare alfresco con due application server che funzionano in failover. Stanno in sedi differenti e uno entra in funzione solo se l'altro va giù. Quindi niente balancing, dicevano che era troppo complicato per il loro scenario.
Dal terzo post in poi ho lasciato perdere dato che è più finalizzato a soluzioni di backup che al momento non sto usando.

Guide RiveltLogic

Quest'azienda partner di alfresco ha scritto una guida che è pubblicata in due pagine qui http://wiki.rivetlogic.com/pages/viewpage.action?pageId=622786 e http://wiki.alfresco.com/wiki/High_Availability_On_Linux
Si riferisce alla versione 2.1 di Alfresco un po' datata al momento in cui scrivo siamo alla 4.02 su entrambe le pagine è scritta quasi la stessa cosa ma le indicazioni per modificare i parametri sono un po' datate, per esempio quelle per il db non vengono modificate attraverso alfresco-global.properties ma in altri file.
Interessante la parte per il debug di ehcache.

ixuss configurazione ha

Sembra interessante, scrivono bene in questo blog c'è anche una bella spiegazione della jconsole http://www.ixxus.com/blog/2012/01/setting-up-alfresco-cluster/
Ci sono alla fine della pagina le configurazioni per fare i load balancer con apache.

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License