msgbartop
Blog di Bernardino (Dino) Ciuffetti
msgbarbottom

22 Gen 14 Alta affidabilità o bilanciamento di carico su OpenLDAP 2.4.x?

Come saprete, l’ultimo filone di openldap (2.4.x) supporta una varietà di meccanismi di replica utili per la realizzazione dell’alta affidabilità. Si trovano in rete vari documenti su cui potete osservare i vari meccanismi e i loro pro e contro. Ne riporto un paio tra i più rappresentativi (in lingua inglese):
http://www.openldap.org/doc/admin24/replication.html
http://www.synetis.com/en/2012/09/03/replication-openldap

Faccio presente che non esistono configurazioni di ldap che permettono una gestione trasparente dell’alta affidabilità, infatti tutte le configurazioni hanno bisogno di un bilanciatore di carico o un sistema di cluster manager per poter gestire il flusso di dati verso il server ldap attivo, la replica ha il solo scopo di mantenere aggiornati tutto il tempo gli ldap server.

In particolare, se vi è la disponibilità di soli due server e la volontà di realizzare l’alta affidabilità, vorrei consigliare la modalità di replica di opendap 2.4.X chiamata MIRROR MODE, di cui riporto pro e contro come indicato nel documento “http://www.synetis.com/en/2012/09/03/replication-openldap/”:

A mirror is composed of only two nodes. Both nodes are configured in both master and slave. In this mode, both nodes are identical at all times. They are writable and it is possible to update either one or the other.

Advantages:
If a node is down, on his return, it automatically updates;
– If the data files of a node is destroyed, when it restarts, it will synchronize completely from the other node;
A node is configured as a master. It is possible to connect consumers.

Disadvantages:
– Mass treatment of update of a node are longer in fashion provider / consumers, because the two nodes are updated simultaneously and in full mode.

Sebbene in questa modalità sia prevista l’operatività sia in scrittura che in lettura di entrambi i nodi ldap, il documento ufficiale di openldap “http://www.openldap.org/doc/admin24/replication.html”, relativamente al paragrafo 18.2.3, specifica che la corretta configurazione è quella di utilizzare in scrittura un nodo per volta.

Riporto il testo del paragrafo in questione:

MirrorMode is a hybrid configuration that provides all of the consistency guarantees of single-master replication, while also providing the high availability of multi-master. In MirrorMode two providers are set up to replicate from each other (as a multi-master configuration), but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync.

Il fatto che le scrittura debbano essere spedite ad un master per volta è necessario (come in un qualsiasi sistema multi master) ad evitare l’accesso concorrente alla stessa risorsa (record).
Questo tipo di configurazione infatti risolve a priori qualsiasi conflitto di concorrenza a livello di record e allo stesso tempo garantisce l’alta affidabilità.

A questo punto è possibile ipotizzare un paio di configurazioni architetturali per identificare quale sarà il frontend esterno che dovrà gestire le richieste in scrittura su uno dei nodi ldap:
1) l’utilizzo di un bilanciatore di carico hardware a livello TCP/IP, impostato non in modalità round robind ma in modalità Active/Standby con controllo della risorsa (porta TCP/389);
2) l’utilizzo di un gestore di cluster come Linux HA (http://www.linux-ha.org/wiki/Main_Page) che gestisca lo switch dell’IP di erogazione del servizio ldap su uno dei nodi ldap in replica incrociata, erogato sul server supersite in caso di fault di uno dei due nodi.

Se si sceglie la prima ipotesi, volendo, si potrebbe prevedere una terza possibilità utile al mantenimento dell’alta affidabilità in lettura/scrittura e allo stesso tempo per ottenere il bilanciamento di carico per le richieste in sola lettura sui due nodi. Quest’ultima possibilità prevede l’utilizzo di due indirizzi IP, uno in HA da utilizzarsi per le sole scritture, nelle modalità indicate al punto 1 di cui sopra, e l’altro IP che bilancia il traffico in lettura sui due nodi, tramite una configurazione in modalità round robin verso i due nodi ldap.

Per riassumere, considerando che le macchine sono linux redhat 6, se si sceglie la prima ipotesi (letture e scritture LDAP in HA su uno dei due nodi tramite utilizzo di un bilanciatore hardware), la lista della spesa è:

– installazione di OpenLDAP 2.4.X su tutti e due i nodi. I processi devono sempre essere mantenuti attivi contemporaneamente;
– configurazione di un indirizzo IP (VIP) da associare all’erogazione del servizio che viene impostato sul bilanciatore di carico;
– configurazione dei due nodi LDAP in modalità MirrorMode

Se si sceglie la seconda ipotesi (utilizzo di un gestore di cluster per ottenere letture e scritture LDAP in HA), la lista è:
– installazione di OpenLDAP 2.4.X su tutti e due i nodi. I processi devono sempre essere mantenuti attivi contemporaneamente;
– installazione e configurazione di un cluster manager come linux-ha (http://www.linux-ha.org/wiki/Main_Page) sui due nodi;
– configurazione di un indirizzo IP (VIP) da associare all’erogazione del servizio che viene impostato sul cluster manager;
– configurazione dei due nodi LDAP in modalità MirrorMode

La terza ipotesi (utilizzo di due IP su bilanciatore hardware, con scritture in HA su uno dei due nodi e letture in bilanciamento di carico) prevede la seguente lista della spesa:
– installazione di OpenLDAP 2.4.X su tutti e due i nodi. I processi devono sempre essere mantenuti attivi contemporaneamente;
– configurazione di due indirizzi IP (VIP), uno da associare all’erogazione del servizio di sole letture che viene impostato sul bilanciatore di carico in modalità round robin, l’altro da associare all’erogazione del servizio di lettura e scrittura che viene impostato sul bilanciatore di carico in modalita’ active/standby con controllo della risorsa;
– configurazione dei due nodi LDAP in modalità MirrorMode

Sono tutte e tre valide, anche se secondo me la migliore è la terza perchè permette HA + bilanciamento di carico in lettura, HA in scrittura, e soprattutto la divisione logica dei flussi di scrittura e lettura.

Ciao, Dino Ciuffetti.

Lascia un commento

*