Differences

This shows you the differences between two versions of the page.

--- cn:ccr:cloud:cloudstorage:owncloud:owncloud_ha [2013/06/12 14:53] – [Ridondanza con bilanciamento del carico o con due server attivi] stalio@infn.it
+++ cn:ccr:cloud:cloudstorage:owncloud:owncloud_ha [2013/06/13 12:58] (current) – [Ridondanza con bilanciamento del carico o con due server attivi] stalio@infn.it
@@ Line 1: / Line 1: @@
+====== ownCloud in HA ======
+Ho fatto qualche prova per vedere quali siano i modi per mettere il servizio ownCloud in HA.
+===== Preparazione =====
+Non ho pensato a replicare i dati: ho creato 2 server uguali che puntano allo stesso folder (AFS, ma solo perche` per me era il modo piu` facile e veloce
+di creare una cartella condivisa) come area dove mantenere i dati degli utenti. Penso che la ridondanza dei dati possa essere trattata separatamente, sia
+essa su base geografica o locale.
+Per ottenere 2 server "uguali" non ho fatto altro che clonare la macchina virtuale del mio ambiente di test originario
+ed apportare al clone delle modifiche minime (se ricordo bene solo indirizzo ip ed hostname).
+Ho poi impostato la replica master-master sul db mysql usato da owncloud, in maniera da avere sia la configurazione e lo stato dei due server sempre perfettamente allineati.
+===== Ridondanza con bilanciamento del carico o con due server attivi =====
+Ho fatto una semplice prova di bilanciamento del carico assegnando lo stesso nome dns ai due server e provando ad accedervi attraverso il browser.
+Questo sistema non va bene perche` se l'utente e` autenticato su uno dei due server e il browser passa sull'altro server (e questo e` successo piu` volte, almeno con chrome),
+le informazioni sulla sessione sono perse e l'utente deve autenticarsi nuovamente.
+Ho provato allora a configurare i due server per lavorare col load balancer LVS (http://www.linuxvirtualserver.org/) in produzione ai LNGS ed in questo modo load balancing ed high availability
+sembrano funzionare bene, sia usando il browser che usando il client di sincronizzazione. LVS si preoccupa di dirigere, se entrambi i server sono funzionanti, tutte le richieste di un client
+verso lo stesso server, evitando agli utenti di doversi riautenticare in continuazione.
+Quando uno dei server "va giu`" l'utente che usa l'interfaccia web perde la sessione e deve riautenticarsi.
+Il client di sincronizzazione opera in maniera connectionless: si autentica e deve essere autorizzato ad ogni operazione, con una granularita` estremamente fine.
+Questo e` un bene per l'HA ma e` un male, come gia` sappiamo per il server authn/authz che viene subissato di richieste.
+===== Ridondanza senza bilanciamento del carico o con un solo server attivo =====
+In una configurazione con ridondanza su rete geografica un load balancer come LVS non e` probabilmente utilizzabile; sarebbe meglio realizzare una configurazione
+HA con un solo server attivo ed un secondo server normalmente in stand-by. Non ho fatto prove di questo tipo ma, stanti i risultati dei test descritti
+qui sopra, direi che sia un sistema basato su un DNS dinamico come quello in uso al CNAF, sia un sistema del tipo linux-HA (heartbeat) dovrebbero funzionare. Ovviamente
+bisogna preoccuparsi di mantenere i server sempre perfettamente allineati (db replica e aree dati condivise).