GlusterFS: Storage Scalabile e Distribuito

glusterfsIntroduzione

GlusterFS è un file system open source distribuito e scalabile orizzontalmente, la cui capacità può essere dinamicamente espansa mediante l’aggiunta di nuovi nodi. GlusterFS è in grado di arrivare a gestire fino a diversi Peta Byte, migliaia di client e diverse aree dati (storage) organizzandole in blocchi che rende accessibili su Infiniband RDMA (remote direct memory access, fibra ottica) o connessioni TCP/IP.

Le risorse {memoria e disco} vengono rese disponibili sotto un unico punto di condivisione e tali risorse possono essere montate dai client mediante tre diversi protocolli: CIFS, NFS oppure tramite il client nativo Gluster.

Inoltre GlusterFS supporta la replica geografica ossia la replica dei dati di un Volume su un Server dislocato in un area geografica diversa da quella dove sono presenti gli altri nodi.

Iniziamo a prendere confidenza con alcune terminologie di GlusterFS:

  • Volume: Identifica la condivisione effettiva che viene messa a disposizione
  • Brick: Identifica il file system locale di un server su cui opera GlusterFS
  • Translator: Identifica delle componenti ( librerie ) che estendono le funzionalità del file system
  • Server: Identifica la macchina o le macchine ( reali o virtuali ) dove risiedono i dati
  • Client: Identifica la macchina che monta il volume

La logica quindi è la seguente:

Si installa GlusterFS su ogni server che fa parte del pool di storage del cluster, si definiscono i blocchi ( bricks ) da esportare ( directory ) andando cosi a creare la condivisione effettiva chiamata Volume.

Successivamente su ogni Client interessato installiamo allo stesso modo GlusterFS, e tramite i protocolli citati prima ( NFS, CIFS, GlusterFS Client ) andiamo a montare il cluster rendendo disponibile la condivisione ( Volume ).

Vediamo adesso le diverse TIPOLOGIE DI VOLUME ossia come i dati possono essere organizzati:

  • Distributed: Definisce un {Volume Distribuito} dove i file vengono distribuiti in maniera random tra i vari brick del Volume che compongono il Cluster. Questo comporta maggior scalabilità ma molta meno ridondanza,infatti nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Replicated: Definisce un Volume Replicato dove i file vengono replicati tra i Brick del Volume che compongono il Cluster. Questo comporta una riduzione dello spazio disponibile per lo Storage ma una maggior ridondanza e tale configurazione è consigliabile per avere un Elevata Affidabilità e un Elevata Disponibilità.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporterebbe la perdita dei dati visto che ne abbiamo una replica a disposizione. Le repliche dei dati è consigliabile averle in brick separati cioè che non si trovino sulla stessa macchina.
  • Striped: Definisce un Volume Striped dove i file vengono memorizzati in blocchi nei brick del Volume che compongono il Cluster.
    Questo comporta maggiori prestazioni in lettura e scrittura su file di grandi dimensioni e maggior spazio a disposizione ma una minor ridondanza. Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Distribuited Striped: Definisce un Volume Distribuito e Striped dove il Volume memorizza i file in blocchi tra 2 o più nodi del Cluster. Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Distribuited Replicated: Definisce un Volume Distribuito Replicato dove il Volume distribuisce e replica i file tra i Brick del Cluster. Questo comporta la combinazione dei pregi delle singole soluzioni distributedd e Replicated.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporterebbe la perdita dei dati visto che ne abbiamo una replica a disposizione e il Volume resterebbe sempre accessibile.
  • Striped Replicated: Definisce un Volume Striped Replicato dove il Volume fa lo Stripe dei file e li replica tra i Brick del Cluster.
    Si combinano i pregi dello Stripe ossia maggiori prestazioni in lettura e scrittura utile per esempio su file di grandi dimensioni con i pregi della Replicazione sui Brick del Cluster per avere cosi prestazioni e ridondanza.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporta la perdita dei dati in esso contenuti.

INSTALLIAMOLO
Per procedere all’installazione e testare il software dovremo avvalerci di almeno due macchine, decidete voi se reali o VM, dopodiche’ inizieremo dividendo il lavoro; partiamo con la macchina che fara’ da Server :

modifichiamo a dovere il file /etc/hosts, io ho fatto nel seguente modo

# vim /etc/hosts
192.168.2.138    server1.example.com     server1
192.168.2.182    client1.example.com     client1

aptitude install glusterfs-server

…ora dobbiamo creare le seguenti directory

mkdir /data/
mkdir /data/export
mkdir /data/export-ns
cp /etc/glusterfs/glusterd.vol /etc/glusterfs/glusterd.vol_orig
cat /dev/null > /etc/glusterfs/glusterd.vol
vim /etc/glusterfs/glusterd.vol
volume posix
  type storage/posix
  option directory /data/export
end-volume

volume locks
  type features/locks
  option mandatory-locks on
  subvolumes posix
end-volume

volume brick
  type performance/io-threads
  option thread-count 8
  subvolumes locks
end-volume

volume server
  type protocol/server
  option transport-type tcp
  option auth.addr.brick.allow 192.168.2.182 # inserire qui l'indirizzo od il nome host del vostro client
  subvolumes brick
end-volume
/etc/init.d/glusterfs-server start

…ora passiamo a lavorare sul client

aptitude install glusterfs-client glusterfs-server
mkdir /mnt/glusterfs  

cp /etc/glusterfs/glusterd.vol /etc/glusterfs/glusterd.vol_orig
cat /dev/null > /etc/glusterfs/glusterd.vol
vim /etc/glusterfs/glusterd.vol

volume remote
  type protocol/client
  option transport-type tcp
  option remote-host server1.example.com # inserite qui l'indirizzo od il nome host del server
  option remote-subvolume brick
end-volume

volume writebehind
  type performance/write-behind
  option window-size 4MB
  subvolumes remote
end-volume

volume cache
  type performance/io-cache
  option cache-size 512MB
  subvolumes writebehind
end-volume

ora dobbiamo lanciare uno di questi due comandi :

glusterfs -f /etc/glusterfs/glusterd.vol /mnt/glusterfs

oppure

mount -t glusterfs /etc/glusterfs/glusterd.vol /mnt/glusterfs

….se non avete avuto errori eseguendo il comando mount dovreste vedere qualcosa del genere

# mount
/etc/glusterfs/glusterd.vol on /mnt/glusterfs type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

# [client1] df -h
/etc/glusterfs/glusterd.vol
143G   33G  103G  25% /mnt/glusterfs

che nel mio caso equivale alla partizione /home della macchina server
# [server1] df -h
/home/server1/.Private            143G   33G    103G  25% /home/server1/Private

…come notate dalle dimensioni dei due filesystems

a questo punto non ci rimane altro che modificare il file /etc/fstab in modo da rendere immediato il mount al boot del client

# vim /etc/fstab

/etc/glusterfs/glusterfs.vol  /mnt/glusterfs  glusterfs  defaults  0  0

Questo era solo un semplice esercizio per imparare a capire il software in questione ovviamente con le dovute aggiunte e modifiche del caso si potranno creare Volumi e directory ad hoc della grandezza desiderata in cui salvare tutti i dati per noi importanti.

Buon divertimento !

Piu’ veloci tramite la gestione della RAM

RAM vs SWAPRAM  vs  SWAP 

La maggior parte dei moderni sistemi operativi sono in grado di utilizzare una partizione, nota come swap o file di paging, per estendere la quantità di RAM disponibile scrivendo alcuni dati sul disco rigido. Con il termine swap si intende, l’estensione della capacità della memoria volatile complessiva del computer, oltre il limite imposto dalla quantità di RAM installata, attraverso l’utilizzo di uno spazio sul disco fisso.

Se il vostro computer dispone di 2 GB di RAM o più, difficilmente, nella maggior parte dei casi, avrete bisogno di utilizzare l’area di swap. La RAM infatti è molto più veloce di un disco rigido ed è conveniente lasciare che la RAM gestisca la maggior parte dei processi. La tendenza a ricorrere all’area di swap è chiamata swappiness. Quest’ultima accetta valori numerici interi da 0 a 100: assegnandogli 0 linux utilizzerà lo swap solo quando la ram sarà finita, per evitare che il sistema si blocchi; assegnandogli 100 invece utilizzerà praticamente sempre lo swap. In genere, su Ubuntu (e OS derivati), la priorità è a 60: questo significa che lo swap verrà usato quando la ram sarà piena il 40%. Se avete abbastanza ram, potete abbassare la priorità dello swap in modo che venga usato solo quando la ram occupata è al 90%, ma anche all’ 80% se preferite. Per ridurre lo swappiness in modo tale da forzare l’utilizzo dell RAM del vostro sistema possiamo digitare da terminale il seguente comando:

sudo sysctl -w vm.swappiness=60

Ora quello che possiamo fare per lavorare sulla gestione della RAM da parte del kernel e’ di “abbassare” questo valore, quindi fate coma al solito una copia di backup del file, prima di effettuare le modifiche, e cerchiamo di fare alcuni test per vedere quale valore meglio si adatta al vostro PC ed alla vostra RAM.

Le modifiche effettuate da questo comando però resteranno attive solo per la sessione in corso e non al successivo riavvio del sistema. Se invece, vogliamo mantenere le modifiche in maniera permanente bastera’ editare il file sysctl.conf:

sudo gedit /etc/sysctl.conf

Inserire il valore vm.swappiness=10 al termine del file e salvarlo;a questo punto potete tenere sotto controllo le modifiche effettuate ed i relativi miglioramenti tramite l’utilizzo di un comodo tool qual’e’ htop .

Ma, nel caso in cui  si doveste necessariamente dover creare un file per aumentare lo swap allora eseguite questa procedura:

dd if=/dev/zero of=/media/swapfile bs=1M count=1024
mkswap /media/swapfile
swapon /media/swapfile
cat /proc/swaps
nano /etc/fstab
/media/swapfile swap swap defaults 0 0

 

Vedi anche (proteggersi da scansioni ed intrusi)

Proteggersi da scansioni ed intrusioni

SysctlSysctl

Molte volte si pensa che per poter difendere il nostro amato PC da occhi indiscreti ci voglia chissa’ quale software sofisticato , oppure una decennale esperienza nella scrittura di regole con iptables ; certo tutto questo aiuta comunque, ma e’ anche vero che nella maggior parte dei casi il nostro PC non e’ poi cosi’ invitante e non contiene nessun vero segreto che valga la pena, per un hacker ( o x meglio dire chracker ) di perderci del tempo. Quindi molte volte alziamo fortificazioni esagerate, oltre il nostro vero sapere e controllo, senza avere un buon motivo. Si potrebbe invece iniziare a prendere dimestichezza con tutta quella serie di tools che Linux fornisce di base per cominciare a restringere le possibilita’ di accesso agli estranei ed ai curiosi.

Oggi inizieremo da sysctl ossia ” la gestione dei parametri del kernel  ”

Il comando sysctl viene usato per la personalizzazione dei parametri in run-time del kernel che si trovano in /proc/sys.
Per avere uno sguardo dell’output del comando basterà digitare da root:

sysctl -a

Le categorie

                 debug
                 dev
                 fs
                 kernel
                 net
                 vm

Significato
parametri per il debug.
parametri dei dispositivi.
parametri dei filesystem.
parametri generici del kernel.
parametri della rete.
parametri della memoria virtuale.

Praticamente possiamo modificare molti valori riguardanti il sistema,la rete,ecc.

Possiamo cambiare valore ai vari parametri in base alle nostre esigenze, facciamo un esempio.
Vogliamo cambiare valore all’ip forward:

sysctl -a | grep ip_forward

@lorenzo:/etc# sysctl -a | grep ip_forward
net.ipv4.ip_forward = 0

Come vediamo il valore è a 0 e noi lo vogliamo mettere a 1:

sysctl -w net.ipv4.ip_forward=”1″

Come possiamo vedere ha preso il valore 1:

@lorenzo:/etc# sysctl -a | grep ip_forward
net.ipv4.ip_forward = 0

Ovviamente questa modifica è temporanea infatti dopo un riavvio il valore torna a 0, ma possiamo renderla definitiva andato a editare il file /etc/sysctl.conf (facendo sempre prima un bel backup) mettendo 1 alla voce net.ipv4.ip_forward.

Una volta scritta la regola nel file ed usciti dalla modalita’ scrittura dovremo far rileggere la configurazione dei parametri di questo file tramite il seguente comando:

sysctl -p

Vediamo ora alcuni parametri e scopriamo a cosa servono :

net.ipv4.tcp_syncookies:  Quando abilitato, protegge dagli attacchi SYN FLOOD

net.ipv4.icmp_echo_ignore_broadcasts: Quando abilitato, ignora tutte le richieste ICMP ECHO e TIMESTAMP dirette ad indirizzi broadcast e multi cast proteggendo il server da attacchi SMURF.

net.ipv4.icmp_ignore_bogus_error_responses: Quando abilitato, protegge da errori ICMP maligni

net.ipv4.tcp_keepalive_time: Definisce ogni quanti secondi inviare al client con una connessione keepalive aperta un pacchetto in modo tale da mantenerla aperta.

L’abilitazione dei seguenti paramentri permette di inoltrare il traffico di rete da un’interfaccia ad un’altra agendo come un router:

net.ipv4.ip_forward
net.ipv4.conf.all.send_redirects
net.ipv4.conf.default.send_redirects

net.ipv4.tcp_max_syn_backlog=512   Quando la coda dei segmenti SYN provenienti da un certo host supera il numero stabilito in questo parametro il kernel invece di tenere i dati in arrivo nella coda dei pacchetti SYN in attesa di risposta, invierà un SYN+ACK di risposta.
Si svuota cosi la coda SYN, evitando che diventi troppo grande,

net.ipv4.icmp_echo_ignore_broadcasts = 1  Il kernel ignorerà i ping destinati all’indirizzo di broadcast della rete. Questo può evitare diversi tipi di attacchi DOS.

net.ipv4.ip_conntrack_max=15000  Viene impostato il numero massimo di connessioni che il sistema può gestire. E’ bene dimensionare tale numero in base alle risorse del sistema, per evitare in ogni momento il rischio che la RAM si esaurisca. *** ***Prevenzione attacchi DOS.

net.ipv4.ipfrag_high_tresh=131072

net.ipv4.ipfrag_low_tresh=102400

Queste due opzioni indicano la quantità di RAM massima e minima che deve essere usata nel momento in cui i segmenti TCP vengono riassemblati, per non esaurire la RAM.  ***Prevenzione attacchi DOS.

net.ipv4.ipfrag_time=20 Quest’opzione indica in secondi il tempo che i segmenti TCP devono essere tenuti in memoria

net.ipv4.conf.all.rp_filter=1 Quest’opzione è utile quando un pacchetto arriva in ingresso su un’interfaccia di rete diversa da quella che ci si aspetterebbe secondo le tabelle di routing.  ***Protezione contro attacchi di Spoofing

net.ipv4.tcp_mem = 12288, 16384, 24576
Queste impostazioni istruiscono lo stack TCP su come compostarsi nei riguardi dell’uso della memoria. Indicano al kernel qual’e’ la soglia al di sopra della quale debba iniziare un uso più attento della memoria. Il primo attributo indica il valore per il quale il kernel non si deve preoccupare dell’utilizzo della memoria. Il secondo attributo invece indica la valore per il quale il kernel deve iniziare a forzare la diminuzione dell’uso della memoria. Questo stato si chiama memory pressure mode.
L’ultimo valore indica il valore per il quale il kernel non può piu assegnare pagine di memoria finchè non torna sotto la soglia.

Per l’architettura x86 ad esempio le pagine di memoria sono grandi 4096 byte.
E’ bene dimensionare la configurazione di questa variabile in base alla RAM disponibile sulla propria macchina, per evitare l’esaurimento delle risorse.

Nel prossimo articolo vedremo altri tool ed altri sistemi di protezione integrati , bye !!

Il valore della certificazione per Linux OpenStack

RedHat Enterprise OpenStack Platform

RedHat Enterprise OpenStack Platform

Openstack è sempre più un punto di riferimento per chi intraprende un percorso di trasformazione del data center verso il mondo cloud. Mentre si parla di cloud oramai da anni, sono oltre la metà, sul totale delle aziende di media grandezza e con infrastruttura complessa, a non avere implementato il cloud computing se non in modo parziale o solo ricorrendo a risorse di cloud pubblico all’occorrenza. Nel tempo sta emergendo con chiarezza il bisogno di interoperabilità e di supporto aperto, a un livello superiore rispetto all’etereogeneità delle infrastrutture dei diversi vendor, tanto che l’84 percento delle aziende con progetti cloud decida di fare il deploying di OpenStack.

A fronte di questo grande interesse RedHat collabora in modo intenso con molti fornitori di soluzioni di gestione come BMC e HP i quali, come membri del Red Hat OpenStack Cloud Infrastructure Partner Network, hanno fornito informazioni, feedback e supporto per la creazione delle nuove certificazioni sulla piattaforma OpenStack.

RedHat introduce la certificazione Cloud Management per RedHat Enterprise Linux OpenStack come parte del Red Hat OpenStack Cloud Infrastructure Partner Network. Il progetto OpenStack, nato come sistema Iaas e piattaforma per il cloud computing open abilita l’interoperabilità tra le piattaforme cloud. RedHat propone un percorso formativo per consentire alle soluzioni di cloud management dei partner di interoperare e di gestire la piattaforma Red Hat Enterprise Linux OpenStack. I clienti certificati sulla piattaforma RedHat Enterprise Linux OpenStack sono in grado cosi’ di implementare soluzioni di management testate con la certezza che siano supportate congiuntamente da Red Hat e dalle aziende partecipanti.

I corsi prevedono diversi livelli d’interazione, potendo cosi trovare quello che piu’ si adatta ad ogni esigenza di tempo, soldi ed impegno da profondere, questo in quanto esistono in pratica queste categorie :

  • CL210 RedHat OpenStack Administrator (Corso in Aula)
  • CL210VT RedHat OpenStack Administrator (Virtual Training)
  • CL210R RedHat OpenStack Administrator-ROLE (e-learning) 

Per ogni altra informazione inerente ai corsi ed ai relativi esami vi rimando alla pagina ufficiale:
redhat.com_training_dates

 

Wireshark Network Analyzer

wiresharkCos’e’ Wireshark 

E’ un network analyzer, tra i piu’ potenti, ossia e’ un software che permette l’analisi dei pacchetti che transitano in rete, con lo scopo di analizzarli e capire cosa sta succedendo sul nostro PC . E’ fornito di una serie di tool che rendono piu’ “dinamiche” l’analisi per poter cosi’ capire cosa c’e’ che non va nella nostra rete.

Wireshark ci permette di capire approfonditamente quali e quanti pacchetti ci sono in transito nella rete e tramite i molti tool a disposizione si potranno individuare i fenomeni che disturbano la nostra navigazione, permettendoci cosi’ anche di capire cosa fanno i computer vicino a noi.

Passato e futuro [ Ethereal & Wireshark] 

Ethereal e’ il nome originale di questo progetto ma la separazione tra gli sviluppatori originali ha contribuito alla nascita nel 2006 di Wireshark decretando poco dopo la fine del progetto Ethereal che attualmente non viene piu’ sviluppato.

Sniffer vs Network Analyzer 

Uno sniffer e’ un software che intercetta pacchetti transitanti in rete e li correla con il preciso intento di ricavarne dettagliate informazioni quali (password, dati , ed ogni sorta di credenziali…) [ dsniff, ettercap ].

Un network analyzer e’ un software che intercetta pacchetti in rete e li presenta all’operatore in una forma che possa facilitarne l’analisi (human-readable form) [ wireshark, tcpdump ].

Normal vs promiscuous 
Nel normal mode l’interfaccia di rete processa solo i pacchetti diretti a lei (modo di funzionamento standard).
In promiscuous mode l’interfaccia processa anche gli altri pacchetti (sniffa) e li passa al kernel,in pratica sniffer e network analyzer lavorano tutti in promiscuous mode.

Non e’ compito di questo articolo spiegare come adoperare Wireshark il quale, come spiegato, e’ un prodotto molto avanzato e ricco di tools; per fortuna internet e’ zeppa di documentazioni ufficiali e non che dettagliano al meglio le mille funzioni. Quello che spero e di aver destato in voi la voglia di essere piu’ curiosi possibile su cio’ che passa dal vostro PC, i mezzi per saperlo ci sono quindi siate curiosi e ricordatevi sempre che :
” il sapere e’ potere “.