Configurazione di un cluster con Corosync

Pacemaker è un tool in grado di aiutarci nella configurazione e nella gestione di un cluster formato da due o più server. Difatti Pacemaker è un pacchetto in grado di comunicare con i due sistemi di alta affidabilità più diffusi in Linux: Heartbeat e Pacemaker.

In questo articolo abbiamo già analizzato come configurare un cluster utilizzando pacemaker in collaborazione con heartbeat; in quest’articolo, invece, useremo corosync al posto di heartbeat.

Innanzi tutto installiamo pacemaker e corosync sui due server che comporranno il cluster. In questo esempio utilizzerò come distribuzione Gentoo, ma qualsiasi altra va bene.

emerge pacemaker

In Gentoo corosync è una dipendenza di pacemaker, pertanto verrò installato automaticamente.
La configurazione di corosync è all’interno del file /etc/corosync/corosync.conf

<strong>/etc/corosync/corosync.conf</strong>
compatibility: whitetank

totem {
    version: 2
    secauth: off
    threads: 0
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.0.100 # <------Sostituire l'ip del server
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }
}

logging {
    fileline: off
    to_stderr: no
    to_logfile: yes
    to_syslog: yes
    logfile: /var/log/cluster/corosync.log
    debug: off
    timestamp: on
    logger_subsys {
        subsys: AMF
        debug: off
    }
}

amf {
    mode: disabled
}

aisexec {
    user: root
    group: root
}

service {
    name: pacemaker
    ver: 0
}

Riportiamo questa configurazione sul secondo server, ovviamente modificando l’indirizzo IP e avviamo il demone su entrambi i server:

/etc/init.d/corosync start

Dopo qualche minuto il cluster dovrebbe essere attivo:

crm_mon -1 | grep Online
Online: [ server01 server02 ]

Ora possiamo utilizzare l’interfaccia crm di Pacemaker per creare le risorse condivise.
Innanzi tutto configuriamo i parametri di default:

crm configure
property no-quorum-policy=ignore
property stonith-enabled=false
property default-resource-stickiness=1000
commit
bye

Ora, ad esempio, configuriamo un ip condiviso:

crm configure
primitive lan_ip IPaddr params ip=192.168.0.250 cidr_netmask="255.255.255.0" nic="eth0" op monitor interval="40s" timeout="20s"
commit
bye

Infine settiamo il nodo “master” come preferito:

crm configure
location master_pref lan_ip 100: master
commit
bye

Un po’ di pulizia sul Mac con CleanMyMac

E’ inutile, il Mac è uno strumento talmente facile da usare, che alla fine ci si fa di tutto tranne che l’ordinaria amministrazione. Ecco perchè, dopo 3 anni di onorato servizio, quest’oggi mi ritrovo con il mio iMac con il disco pieno!

Continuando a seguire la filisofia Mac per cui non mi devo preoccupare ma si deve arrangiare lui, vado alla ricerca (e all’acquisto) di un programma in grado di occuparsi della pulizia del mio computer in modo da guadagnare quella manciata di GB che mi consentiranno di continuare a viver sereno.

CleanMyMac è una utility nata proprio per questo: una volta scaricata ed installata permette di pulire l’hard disk del mac per mantenerlo in perfetta efficienza. Il software riesce ad agire su più elementi che occupano spazio inutilmente:

  • i file di cache dei programmi

  • i file di log

  • i file di lingue (all’avvio viene chiesto quali lingue si desidera mantenere)

  • i binari universali (è in grado di levare il codice precompilato per piattaforme diverse da quella utilizzata, ad esempio il codice per PowerPC)

  • Junk di sistema (i file.DS_Store, le cartelle Spotlight-V100, ecc.)

  • Rifiuti e Avanzi (i file lasciati da applicazioni installate e poi rimosse)

Inoltre permette di rimuovere in modo completo e sicuro le applicazioni e di mantenere monitorato il cestino in modo da ottimizzarne l’uso.

Primo avvio ho recuperato 4 GB su 250 di disco, mi sa proprio che dovrò archiviare vecchie email, foto e brani di iTunes…

Ottimizzare il proprio server MySQL con mysqltuner

MySQL Tuner è uno script in perl in grado di analizzare una installazione di MySQL e consigliare come migliorare le performance configurando oppurtunamente il demone in my.cf.

L’utilizzo è davvero semplice: basta scaricare il file, renderlo eseguibile e lanciarlo. Chiederà username e password di amminstratore e, dopo qualche secondo, arriverà l’analisi.

wget http://mysqltuner.com/mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl

Ed ecco l’output una volta lanciato su questo server:

# ./mysqltuner.pl 

 >>  MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password: 

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 48M (Tables: 316)
[--] Data in InnoDB tables: 46M (Tables: 31)
[!!] Total fragmented tables: 45

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3m 47s (451 q [1.987 qps], 19 conn, TX: 2M, RX: 64K)
[--] Reads / Writes: 92% / 8%
[--] Total buffers: 106.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 374.7M (18% of installed RAM)
[OK] Slow queries: 0% (0/451)
[OK] Highest usage of available connections: 5% (5/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/11.1M
[!!] Key buffer hit rate: 94.3% (3K cached / 193 reads)
[OK] Query cache efficiency: 30.4% (117 cached / 385 selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 39 sorts)
[!!] Temporary tables created on disk: 45% (19 on disk / 42 total)
[OK] Thread cache hit rate: 73% (5 created / 19 connections)
[OK] Table cache hit rate: 88% (64 open / 72 opened)
[OK] Open file limit used: 10% (110/1K)
[OK] Table locks acquired immediately: 100% (361 immediate / 361 locks)
[OK] InnoDB data size / buffer pool: 46.6M/48.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
 Run OPTIMIZE TABLE to defragment tables for better performance
 MySQL started within last 24 hours - recommendations may be inaccurate
 Enable the slow query log to troubleshoot bad queries
 When making adjustments, make tmp_table_size/max_heap_table_size equal
 Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
 tmp_table_size (> 32M)
 max_heap_table_size (> 32M)

Confronto tra diversi metodi di condivisione dei file

Quando si ha a che fare con più server, sicuramente prima o poi nascerà l’esigenza di avere un unico posto dove salvare i propri dati, in modo da poterci accedere contemporaneamente da più server. Questo è uno dei problemi più difficili da affrontare quando si progetta un sistema di server, in quanto esistono moltissimi metodi per arrivare allo scopo ma ciascuno ha le sue peculiarità che lo rendono più o meno adatto ad essere sfruttato in determinate applicazioni.
Diciamo che fare un confronto non è cosa semplice, anche perchè in alcuni casi è possibile avere situazioni ibride di due sistemi concatenati (ad es. NFS su GlusterFS)

NFS
NFS è il sistema di condivisione file classico del modo Unix: è senza ombra di dubbio il più usato, il più conosciuto ed il più semplice da implementare. Per quanto riguarda il funzionamento, il server NFS ha accesso ad uno spazio fisico a blocchi che può essere formattato utilizzando un qualsiasi FileSystem con funzionalità POSIX. Il server NFS ha il compito di gestire l’accesso contemporaneo ai dati contenuti all’interno del dispositivo a blocchi, oltre ovviamente a gestire i permessi utente. I client NFS (gli altri server della rete) potranno montare la directory condivisa (in gergo esportata) come se fosse un disco locale, un po’ come avviene con la condivisione di windows CIFS/SAMBA.
I punti a favore di questo sistema sono senza dubbio la facilità di implementazione, la stabilità del protocollo e, tutto sommato, discrete velocità di rete.
I punti debili di questo sistema sono la totale impossibilità di scalare “on line” aggiungendo nuovo storage nel momento in cui se ne ha la necessità, il fatto di avere un SPoF (Single Point of Failure) costituito dal server NFS che è suscettibile a guasti e che rischia di sovraccaricarsi in maniera considerevole all’aumentare di richieste di rete.

OCFS2 e GFS
OCFS2 e GFS sono due FileSystem concettualemente simili in quanto prevedono nativamente l’accesso contemporaneo ai file: OCFS2 è sviluppato da Oracle mentre GFS2 è sviluppato da RedHat. La teoria di funzionamento è identica: ogni server che ha accesso allo storage deve avere attivo un demone che dialoga continuamente con gli altri server in modo da conoscere esattamente lo stato dello storage. Il disco condiviso viene montato in locale deve essere formattato con il suo filesystem, non è possibile utilizzare un filesystem tradizionale (ext3, xfs, ecc); la cosa interessante è che, trattandosi della formattazione di un disco, questo può essere di qualsiasi tipo, basta che sia accessibile da tutti i server: quindi può essere un disco di rete iSCSI o AoE, ma anche una partizione locale replicata su un secondo server attraverso DRBD8 configurato in modalità Attivo/Attivo o un disco FireWire collegato a più server.
Da un confronto tra i due filesystem, GFS è il più semplice da configurare dato che utilizza i tools di alta affidabilità di RedHat, mentre OCFS2 è più macchinoso. OCFS2 è però nettamente più veloce anche se non supporta le quote in nessun modo (è una delle cose in implementazione).
I maggiori pregi di questo sistema è che non serve un server che faccia da tramite e quindi non si ha un SPoF e le prestazioni sono le migliori in assoluto (specie con OCFS2).
Il difetto principale, deriva direttamente dal pregio: non avendo un server che gestisce la condivisione dei file, ogni nuovo nodo che entra a far parte del cluster comporta un riconfigurazione di tutto il cluster. Anche la scalabilità del sistema è relativa: anche ammettendo di avere un dispositivo di storage che consente di “aggiungere dischi”, è necessario eseguire un resize della partizione con rischi, annessi e connessi.

I figli di FUSE
FUSE è l’acronimo di File System in Userspace ed è un nuovo metodo di utilizzo di dispositivi di rete. Molti filesystem di nuova generazione utilizzano questo sistema per gestire i dischi di rete. L’utilizzo di un ulteriore layer per la comunicazione tra disco e client va nella direzione opposta rispetto all’utilizzo di un filesystem cluster come OCFS2 o GFS, cosa che porta una maggiore flessibilità e stabilità a discapito di una leggera perdita in termini di prestazioni.
Analizziamo due filesystem che fanno affidamento a FUSE: GlusterFS e MooseFS.

GlusterFS
GlusterFS è un filesystem che in questo momento va molto “di moda”. Consente di unire più “commodity computer” per realizzare un cluster di storage server: è possibile realizzare uno stripe (unire lo storage di più server, simile concettualmente al raid 0) o un mirror (avere lo stesso dato copiato su più server, simile concettualmente al RAID 1). Lo storage ove viene creato il filesystem Gluster è, come per NFS, un filesystem comune (EXT3, XFS, ecc,)
Una volta creato lo storage, è possibile accedevi sia utilizzando il protocollo NFS, sia il protocollo CIFS (Samba), sia, come dicevo pocanzi, usando il protocollo nativo attraverso FUSE: questo sistema è quello che garantisce le migliori performance.
Il pregio maggiore di questo protocollo è a mio avviso che non esiste alcun SPoF: tutti i server sono autoritativi allo stesso modo, quando un client monta la partizione attraverso FUSE seve specificare un server, ma poi la comunicazione avviene direttamente con tutto il cluster. Altro pregio è la diffusione: essendo molto diffuso e mantenuto, è anche molto stabile.
Il difetto maggiore a mio avviso è la complessità concettuale: Gluster è formato da tanti layer ciascuno dei quali assove una sua funzione: comprenderli e tarali non è semplicissimo e l’ordinaria manutenzione (aggiungere un nodo ecc.) è spesso fonte di problemi. Le prestazioni del sistema sono buone in lettura se configurato in modalità mirror (le letture possono avvenire contemporaneamente da più nodi), però in scrittura non sono esaltanti.

MooseFS
Operativamente è simile a GlusterFS in quanto condivide FUSE per il montaggio dei dischi in rete, MooseFS è però diverso in quanto a sistema di gestione che lo rende simile a Openstack Swift. In Moose, a differenza di Gluster, i nodi non sono paritetici, ma si compone di un Master Server, un Metalogger server (che può essere promosso a Master in caso di guasto) e di X nodi dati.
Il Master fa da Proxy e conosce esattamente dove sono salvati i dati all’interno dei nodi dati; i dati possono essere replicati su un numero arbitrario di zone in modo da avere sia un sistema tollerante ai guasti sia un sistema di lettura parallelo. Purtroppo, al contrario di OpenStack Swift, anche le scritture avvengono in parallelo, cosa che di fatto lo rende un po’ lento in questo frangente.
Due cose interessanti di questo FileSystem sono l’interfaccia web per il controllo dello stato del cluster e il plugin appena rilasciato per l’integrazione diretta con OpenNebula.
Il principale pregio di questo sistema è la facilità di implementazione e di scalabilità, unita a una velocità generale di tutto rispetto.
Il principale difetto è la quantità di server necessari ad implementare un sistema funzionante: almeno 3 per ambienti di test, almeno 5 per ambienti in produzione.

Ceph
Ceph è l’ultimo Filesystem che prendiamo in considerazione. Diciamo che promette bene e, non a caso, è stato già introdotto nella mainline del kernel linux. Ultima cosa che mi sarei aspettato, quindi, è di avere problemi di sorta, cosa che puntualmente è avvenuta cercando di creare un ambiente misto di nodi a 32 e a 64 bit.
Concettualmente è simile a MooseFS, però introduce due feature interessanti: il driver nel kernel è in grado di lavorare a diretto contatto con lo storage del cluster, senza quindi necessitare di FUSE, pertanto dovrebbe garantire prestazioni superiori; inoltre introduce un proxy in grado di esporre una interfaccia REST API compatibile con Amazon S3.
Diciamo che è ancora un prodotto giovane e, a causa delle limitazioni di gioventù, non ho potuto sperimentarlo in maniera approfondita, peranto ritornerò a provarlo sicuramente in futuro.