Alfresco Ha Guida Ufficiale - Setting up high availability systems

La guida ufficiale dice:

In a clustered installation, concurrent writes to the same documents using file server protocols (CIFS, FTP, or NFS) are not currently recommended.

High availability components

Per fare in modo che il sistema funzioni devono essere presenti i seguenti componenti:

  • Content store: la soluzione content store unico e condiviso è la più usata. Come visto sopra si può usare anche la primaria per ogni nodo e secondaria comune
  • Indici: non possono essere condivisi, ci sono dei threads che li aggiornano direttamente dal database quando l'alfresco è in run come cluster. Quando un nodo è creato può essere user, contend o space node. I metadata vengono indicizzati e la transazione è memorizzata in modo permanente nel database. Quando il thread di sicronizzazione viene eseguito nell'altro nodo del cluster gli indici vengono aggiornati usando le informazioni del db. Le tabelle che contengono le informazioni per il tracking degli indici sono:

alf_server: ogni commit il server mette una entry in questa tabella
alf_transaction : ogni operazione di write in un nodo di alfresco genera una transazione con un id univoco. La transazione è attaccata alla entry nella tabella del server. La colonna commit_time_ms assicure che la transazione può essere odrinata da una commit time. Un GUID univoco, per motivi storici, è anche attaccato qui.
alf_node: una entry è creata qui per ogni nodo, includendo nodi che possono essere cancellati. Con ogni modifica lo stato è aggiornato per riferirsi alla entry di transazione per la transazione di committing.
Quando gli indici sono aggiornati su una macchina (per una rebuilding o un tracking) le transazioni sono ordinate nel tempo. Il server può determinare quali nodi sono stati modificati o cancellati in una particolare transazione.

  • Database syncronizzation: è possibile avere databases co-located con una sincronizzazione reciproca. Per usar riferirsi alla documentazione del proprio database. Penso voglia dire copie multiple di db che si sincronizzano a vicenda. Non penso che userò mai soluzioni di questo genere.
  • Level 2 cache: in Alfresco viene usata ehcache per fare caching degli oggetti java, in modo da essere application server indipendent. Gli oggetti di cache Le sono memorizzati in memoria collegati application scope del server. Le sticky session sono usate per tenere traccia della sessione. Alfresco usa l'RMI per replicare lo stato della cache usando le Peer Cache Replicator. Ogni membro che ha la cache replicata notifica a tutte le altre istanze quando il contenuto è cambiato. Se si hanno problemi con il meccanismo delle cache si possono settare a true questi parametri nell'alfresco-global.properties che da quello che capisco anche se non è scritto chiaramente disabilitano la condivisione degli oggetti.
system.cache.disableMutableSharedCaches= 
system.cache.disableImmutableSharedCaches=

High availability scenario

C'è la figura di un uso comune, il balancer deve supportare il mantenimento della sessione per istradare lo stesso utente sempre allo stesso alfresco.
La replicazione degli oggetti in cache è attiva, da quello che ho capito server per mantenere la coerenza tra gli oggetti in memoria e il database ma la le sessioni non sono replicate in questo scenario.

Initiating clustering

Alfresco ha bisogno di scoprire quali sono gli altri nodi del cluster, lo fa tramite un meccanismo di discover con messaggi multicast UDP, forniti da ehcache. I server mandano messaggi e usano informazioni per settare la loro intercomunication. C'è un paragrafo apposta Using EHCache multicast discovery.
Il meccanismo per la sincronizzazione/comunicazione è fornito da JGroups. Questo utilizza udp o tcp e gestisce anche ingresso e uscita dei nodi dal server.
Bisogna settare una serie di parametri tramite alfresco-global.properties oppure copiando ehcache-custom.xml.sample.cluster rinominandolo ehcache-custom.xml ponendolo dentro <classpathRoot>/alfresco/extension/ehcache-custom.xml

Configuring JGroups and Alfresco clustering

Nelle release precedenti un Alfresco per scroprire altri elementi del cluster mandava pacchetti UDP in broadcast adesso si usa JGroups.
Seguono diversi parametri.

Clustering through shared content stores

Parametri per configurare il content store condiviso , da mettere l'alfresco-global.properties

dir.contentstore=<new_location>/contentstore 
dir.contentstore.deleted=<new_location>/contentstore.deleted 
dir.auditcontentstore=<new_location>/audit.contentstore

Using EHCache multicast discovery

Questo serve se non si vuole usare JGroups per configurare il cluster.

Configuring Hazelcast for JLAN Clustering

La libreria Hazelcast fornisce supporto per strutture dati distribuite e canali di comunicazione che permettono a certe componenti dell'alfresco content repository server di funzionare propriamente con un ambiente clustered. Quando si configura jlan clustering se si desidera clusterizzare protocolli cifs , ftp, o nfs con un alfresco repository, si ha bisogno di configurare hazelcastConfig.xml . Questo è localizzato alfresco/tomcat/shared/classes/alfresco/extension.
Si possono creare cluster separati specificando nome e password del gruppo. Si possono specificare inoltre interfacce di rete e discovery multicast che l'Hazelcast dovrebbe usare.
Ecco l'esempio

<group>
   <name>dev</name>
   <password>dev-pass</password>
</group>
<network>
   <port auto-increment="true">5701</port>
   <join>
      <multicast enabled="true">
        <multicast-group>224.2.2.3</multicast-group>
        <multicast-port>54327</multicast-port>
      </multicast>
      <tcp-ip enabled="false">
        <interface>127.0.0.1</interface>
      </tcp-ip>
   </join>
      <interfaces enabled="true">
        <interface>10.244.10.119</interface>
      </interfaces>

Per abilitare hazelcast si devono settare le seguenti property
filesystem.cluster.enabled=true 
filesystem.cluster.configFile=c:\\temp\\hazelcastConfig.xml

Verifying the cluster

Per verificare il funzionamento suggerisce tre test.

  1. Per verificare la cache, Aprire un documento con due browser su due nodi, da uno modificare una proprietà di descrizione e verificare con il refresh che si veda la modifica dall'altra parte
  2. Per verificare gli indici, fare da ogni macchina una ricerca sugli indici
  3. Per verificare la consistenza aggiungere un file da una parte e verificare che ci sia anche dall'altra.

Collegarsi ad entrambe le macchine con la jconsole e verificare se la proprietà

 MBeans > Alfresco > RepoServerMgmt > Attributes > TicketCountAll

Sia la medesima su ogni nodo del cluster dopo aver fatto il login su share.

C'è anche una parte per testare i web project

Configuring Share clustering

Configuring the cache peer URLs

Tracking clustering issues

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