Come realizzare un sito in Plone in Alta Affidabilità in concreto.

Plone e Alta Affidabilità

Come realizzare un sito in Plone in Alta Affidabilità in concreto.

Parlando di Alta Affidabilità pensiamo subito ad una architettura di almeno quattro server, due dedicati a Plone (con RelStorage) e due a PostgreSQL (con Repmnr). Sfruttando la Streaming Replication di PostgreSQL possiamo ottenere un database replicato e sincronizzato, mentre con Relstorage possiamo rimpiazzare lo ZeoDB con un pool di server PostgreSQL.

Attori

  • node1 (10.0.0.101): server PostgreSQL configurato e avviato come Master
  • node2 (10.0.0.102): server PostgreSQL configurato e avviato come Slave
  • plone1 (10.0.0.111): server Plone
  • plone2 (10.0.0.112): server Plone


Partiamo da PostgreSQL: Streaming Replication

Il lavoro piu' complicato va fatto su PostgreSQL. Debian e RedHat, con le relative derivate, offrono diversi metodi per installare PostgreSQL, dai pacchetti di sistema alle repository ad Hoc. Scegliete il metodo che preferite.

Per permettere il recovery dei dati, occorre che gli utenti che gestiscono il database, possano collegarsi in ssh senza l'uso della password, quindi mediante chiavi ssh. Nel caso di Debian, l'utente in questione e' postgres.

Oltre ai pacchetti base, occorre installare Repmgr. Nel caso di Debian:

apt-get install repmgr postgresql-9.2-repmgr

Su entrambi i server, dovete modificare il file postgresql.conf nel seguente modo

listen_addresses='*'
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .' # we can also use exit 0, anything that
# just does nothing
max_wal_senders = 10
wal_keep_segments = 5000 # 80 GB required on pg_xlog
hot_standby = on
shared_preload_libraries = 'repmgr_funcs'

La guida ufficiale di Repmgr, richiede un wal_keep_segments di 5000 elementi, per un totale di 80GB occupati su filesystem. Se non avete a disposizione questo spazio, potete ridurre la dimensione tenendo sotto controllo la dimensione delle transazioni, in modo da poterne conservare una quantita' ragionevole.

Sempre su entrambi i server nodeX, occorre modificare il file pg_hba.conf per permettere l'accesso ai dati sia ai server nodeX che ai server ploneX.

host zope zope 127.0.0.1/32 trust
host zope zope 10.0.0.0/24 trust
host replication all 10.0.0.0/24 trust

Questa configurazione permette all'utente zope di poter accedere al database zope sia dal server locale che dai server ploneX. Se non potete permettervi una configurazione del genere potete utilizzare il metodo password. L'utente replication deve rimanere trust.

Per poter sincronizzare i database, dobbiamo configurare Repmng, creando un file in /etc/repmgr.conf sia su node1 che node2, che abbia questo contenuto:

cluster=zopecluster
node=<node_num>
node_name=<node_name>
conninfo='host=<node_ip> dbname=zope user=zope'
master_response_timeout=60
reconnect_attempts=6
reconnect_interval=10
failover=automatic
promote_command=<script_promote>
follow_command='repmgr standby follow -f /etc/repmgr.conf'

Dove

  • node_num: e' il numero del nodo (node1 -> 1 ecc)
  • node_name: e' il nome del nodo (node1, ecc)
  • node_ip: e' l'ip del nodo (node1 -> 10.0.0.101 ecc)
  • script_promote: e' lo script per la promozione di un nodo da slave a master che dovete realizzare manualmente (vedi sezione Script)
Su node1 possiamo avviare PostgreSql, creare l'utente zope ed il database zope e registrare il nodo come master.

$ /etc/init.d/postgresql start
$ su postgresql
$ createuser  zope
$ createdb -O zope zope
$ repmgr -f /etc/repmgr.conf master register 

Su node2 occorre spegnere PostgreSQL ed eliminare l'attuale database e importare quello realizzato su node1. Su Debian:

$ /etc/init.d/postgresql stop
$ rm -fr ~postgresql/9.2/main 
$ su postgres -c "repmgr -f /etc/repmgr.conf -d zope -U zope -h 10.0.0.101 standby clone"

Sempre su node2, avviamo PostgreSQL, registriamo node2 come slave di node1 ed avviamo il demone che controllera' la presenza del master, promuovera' node2 qual'ora non ottenga risposta.

$ /etc/init.d/postgresql start
$ su postgres -c "repmgr -f /etc/repmgr.conf standby register"
$ su postgres -c "repmgrd -f /etc/repmgr.conf > /var/log/postgresql/repmgr.log 2>&1 &" 


Plone con Relstorage

Plone ha una configurazione molto semplice, in quanto il grosso del lavoro viene svolto da Relstorage. Prendiamo il buildout del sito Plone e aggiungiamo due egg: 

  • psycopg2: connettore per Python 2.x per PostgreSQL
  • Relstorage: implementazione relazionale dell ZODB
Sempre nel buildout, nella sezione relativa all'istanza (instance tipicamente), occorre aggiungere:

rel-storage =
  type postgresql
  dsn dbname='zope' user='zope' port='5432'
  blob-dir ${buildout:directory}/var/blobstorage
  keep-history true
  pack-gc false
  replica-conf ${buildout:directory}/replicas.conf

Da notare la presenza del parametro replica-conf, ovvero il path del file che contiene la lista degli ip di node1 e node2, uno per riga:

10.0.0.101
10.0.0.102

Fate girare il buildout ed avviate tutto. Il gioco e' fatto.

Script per node1 e node2

Script di promozione

#!/bin/bash
repmgr -f /etc/repmgr.conf --verbose standby promote
/etc/init.d/postgresql restart

Questo script promuove uno slave in master, attenzione a non avviarlo quando il master e' attivo, altrimenti otterrete due master disallineati.

Conversione ex-master in slave

#!/bin/bash
/etc/init./postgresql stop
su postgres -c "repmgr -d zope -U zope --force standby clone x.x.x.x"
/etc/init./postgresql start
su postgres -c "repmgrd -f /etc/repmgr.conf > /var/log/postgresql/repmgr.log 2>&1 &"

Quando un ex-master viene riattivato occorre fare molta attenzione e non consentire l'accesso a Plone Immediatamente. Ci troveremmo infatti ad avere due master per lo stesso database senza poter prevedere su quale Plone andrà a lavorare. Avviando poi questo script, la sincronizzazione avverrà in maniera automatica.

Share this on

Share |

On same topics

Commenti

comments powered by Disqus