Università degli Studi di Bologna                          FACOLTÀ DI I NGEGNERIA                       Corso di Laurea in...
Parole chiave:         File system distribuito         Cluster         Linux         Global File System         Logical Vo...
A chi voglio bene,         a chi me ne vorrà sempree a chi non ho ancora incontrato.
AneddotoIl poeta romantico John Keats1 alla fine di un pranzo, alzandosi in piedi con il bicchiere in                      ...
IndiceFrontespizio                                                                                               iIndice  ...
viii                                                                                            INDICE             2.4.2 I...
INDICE                                                                                                                    ...
x                                                                                               INDICE          6.6.1 Aggi...
Elenco delle figure 1     Tux la mascotte del sistema operativo linux. . . . . . . . . . . . . . xvi 1.1   Un sistema clust...
xii                                                                    ELENCO DELLE FIGURE      B.2   Esempio di mappatura...
Elenco delle tabelle 4.1   Pacchetti software della suite   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   . ...
xiv   ELENCO DELLE TABELLE
Introduzione                                                    Failure is not an option.                                 ...
xvi                                                                     IntroduzioneVerranno esaminati e paragonati i vari...
Capitolo 1Cluster linux                                                    Perché in ultima analisi, il legame            ...
2                                                                       Cluster linux                     Figura 1.1: Un s...
1.3. I cluster Beowulf                                                               31.2.3 High-Performance clusters (HPC...
4                                                                       Cluster linuxapparati governativi ed industriali a...
1.6. Cluster linux: Conclusioni                                                     5Il Software per la gestione del clust...
6   Cluster linux
Capitolo 2File System locali e distribuiti                                                   Non è la libertà che manca.  ...
8                                                    File System locali e distribuiti    Un Distribuited File System (DFS)...
2.4. Analisi dei file system candidati                                             92.3.1 Distribuited Fault Tolerant File ...
10                                                    File System locali e distribuitidell’Università del Minnesota per po...
Capitolo 3Scelta del sistema                                                  We chose to go to the moon [. . . ]         ...
12                                                                Scelta del sistema3.2     GFS: Caratteristiche generali3...
3.2. GFS: Caratteristiche generali                                                   13In GFS sono disponibili due differe...
14                                                                Scelta del sistema3.2.8    Diskless shared root clusteri...
3.3. GFS: Architetture implementabili                                               15                       Figura 3.1: T...
16                                                               Scelta del sistema3.3.3    GFS over GNBD-DASLa più econom...
Capitolo 4Analisi degli strumenti software                                                   Ci sono 10 tipi di persone al...
18                                                Analisi degli strumenti software                        Pacchetti softwa...
4.2. CCS (Cluster Configuration System)                                             194.2.2 Il file /etc/cluster/cluster.con...
20                                              Analisi degli strumenti software4.2.3    Il tool ccs_testIl comando ccs_te...
4.3. Magma e Magma-plugins                                                        21    [root@masternode ~]# ccs_tool -h  ...
22                                                  Analisi degli strumenti software    A livello concettuale CMAN si comp...
4.4. CMAN (Cluster MANager)                                                         23come il join del nodo dopo l’avvio d...
24                                                 Analisi degli strumenti softwareOperazione leave:Comunica a CMAN che il...
4.5. Fence                                                                     25    [root@masternode ~]cman_tool nodes   ...
26                                                  Analisi degli strumenti software                  Figura 4.2: Interazi...
4.9. LVM2 - Cluster (Logical Volume Manager 2)                                      274.9 LVM2 - Cluster (Logical Volume M...
28                                                 Analisi degli strumenti software4.9.2     CLVM (Clustered LVM)CLVM è un...
4.10. GNBD (Global Network Block Device)                                      29                        Figura 4.4: GNBD -...
30                                                Analisi degli strumenti software4.10.2      Complex setupIl Complex Setu...
4.10. GNBD (Global Network Block Device)                                          31   Questo comando, come visto, si può ...
32                                                 Analisi degli strumenti softwareMultipathed setup     <fence_devices>  ...
4.12. Gulm                                                                      334.12 GulmGULM è uno dei due lock manager...
34   Analisi degli strumenti software
Capitolo 5Implementazione in laboratorio                                                    Mai fidarsi di un computer che ...
36                                                 Implementazione in laboratorio5.1.1     Profilo HardwareI tre nodi del s...
5.2. Topologia I: GFS over GNBD-DAS                                           37    Come abbiamo introdotto nel capitolo 3...
38                                               Implementazione in laboratorio     • GFS Node2: Il secondo dei nodi GFS n...
5.2. Topologia I: GFS over GNBD-DAS                                            395.2.3 Interconnessione Software: Il file s...
40                                                   Implementazione in laboratorio5.3      ImplementazioneVedremo ora l’i...
5.3. Implementazione                                                               41                       Partizionament...
42                                                 Implementazione in laboratorio     • Passo 4: Genereazione ed installaz...
5.3. Implementazione                                                             43   • Passo 5: Creazione del file cluster...
44                                                   Implementazione in laboratorio     • Passo 6: Settaggio dei servizi a...
5.3. Implementazione                                                              45     failover domain (lab4failover). D...
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux
Upcoming SlideShare
Loading in …5
×

Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux

1,382 views
1,294 views

Published on

Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,382
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux

  1. 1. Università degli Studi di Bologna FACOLTÀ DI I NGEGNERIA Corso di Laurea in Ingegneria Informatica A MMINISTRAZIONE DI RETI DI CALCOLATORI A NALISI ED IMPLEMENTAZIONE DI FILE SYSTEM DISTRIBUITI IN AMBIENTE LINUXTesi di Laurea di: Relatore:R AUL C AFINI D OTT. I NG . M ARCO P RANDINI Correlatori: I NG . L UCA G HEDINI Sessione prima Anno Accademico 2005/2006
  2. 2. Parole chiave: File system distribuito Cluster Linux Global File System Logical Volume ManagerD.E.I.S., Dipartimento di Elettronica, Informatica e Sistemistica.Università di Bologna.La tesi è scritta in LTEX 2ε , utilizzando come testo di riferimento [1]. ALa stampa è in P OST S CRIPT.Le immagini sono create in A DOBE R P HOTOSHOP R E LEMENTS 2.0.A DOBE R P HOTOSHOP R E LEMENTS è un marchio registrato A DOBE R S YSTEMS I NC .
  3. 3. A chi voglio bene, a chi me ne vorrà sempree a chi non ho ancora incontrato.
  4. 4. AneddotoIl poeta romantico John Keats1 alla fine di un pranzo, alzandosi in piedi con il bicchiere in mano, esclamò: – Sia biasimata la memoria di Newton! – Stupore di tutti i commensali. – Come mai questo strano brindisi? – Chiese William Wordsworth2 suo collega. – Perchè – spiegò il poeta inglese – ha distrutto tutta la poesia di un arcobaleno riducendolo ad un prisma. 1 John Keats (Londra 31 Ottobre 1795 – Roma 23 Febbraio 1821) 2 William Wordsworth (Cumberland 7 Aprile 1770 – Rydal Mount 23 Aprile 1850)
  5. 5. IndiceFrontespizio iIndice viiElenco delle figure xiElenco delle tabelle xiiiIntroduzione xv1 Cluster linux 1 1.1 Che cos’è un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Tipologie di cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2.1 High-Avaiability clusters (HA-Clusters) . . . . . . . . . . . 2 1.2.2 Load-Balancing clusters (LB-Clusters) . . . . . . . . . . . 2 1.2.3 High-Performance clusters (HPC) . . . . . . . . . . . . . . 3 1.3 I cluster Beowulf . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 I cluster e linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Analisi di un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5.1 Cluster Hardware . . . . . . . . . . . . . . . . . . . . . . . 4 1.5.2 Cluster Software . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 Cluster linux: Conclusioni . . . . . . . . . . . . . . . . . . . . . . 52 File System locali e distribuiti 7 2.1 Il File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 File System locali o Disk File Systems . . . . . . . . . . . . . . . . 8 2.3 File System distribuiti o Distribuited File Systems . . . . . . . . . . 8 2.3.1 Distribuited Fault Tolerant File Systems . . . . . . . . . . . 9 2.3.2 Distribuited Parallel File Systems . . . . . . . . . . . . . . 9 2.3.3 Distribuited Parallel - Fault Tolerant File Systems . . . . . . 9 2.4 Analisi dei file system candidati . . . . . . . . . . . . . . . . . . . 9 2.4.1 Red Hat/Fedora GFS (Global File System) . . . . . . . . . 9
  6. 6. viii INDICE 2.4.2 IBM GPFS (General Parallel File System) . . . . . . . . . . 10 2.5 File System locali e distribuiti: Conclusioni . . . . . . . . . . . . . 103 Scelta del sistema 11 3.1 Scelta del sistema e del file system: Perchè Red Hat/Fedora GFS? . 11 3.2 GFS: Caratteristiche generali . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 Caratteristiche tecniche . . . . . . . . . . . . . . . . . . . . 12 3.2.2 La struttura . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3 Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4 Locking manager . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.6 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.7 LAN-free backup . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.8 Diskless shared root clustering . . . . . . . . . . . . . . . . 14 3.3 GFS: Architetture implementabili . . . . . . . . . . . . . . . . . . 14 3.3.1 GFS over SAN . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2 GFS over GNBD-SAN . . . . . . . . . . . . . . . . . . . . 15 3.3.3 GFS over GNBD-DAS . . . . . . . . . . . . . . . . . . . . 16 3.4 Scelta del sistema: Conclusioni . . . . . . . . . . . . . . . . . . . . 164 Analisi degli strumenti software 17 4.1 Cluster Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 CCS (Cluster Configuration System) . . . . . . . . . . . . . . . . . 17 4.2.1 Il demone /sbin/ccsd: . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Il file /etc/cluster/cluster.conf . . . . . . . . . . . . 19 4.2.3 Il tool ccs_test . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.4 Il tool ccs_tool . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.5 Avvio del servizio ccsd . . . . . . . . . . . . . . . . . . . . 21 4.3 Magma e Magma-plugins . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 CMAN (Cluster MANager) . . . . . . . . . . . . . . . . . . . . . . 21 4.4.1 CM (Connection Manager) . . . . . . . . . . . . . . . . . . 22 4.4.2 SM (Service Manager) . . . . . . . . . . . . . . . . . . . . 22 4.4.3 I demoni di cman . . . . . . . . . . . . . . . . . . . . . . . 22 4.4.4 Il tool cman_tool . . . . . . . . . . . . . . . . . . . . . . 23 4.5 Fence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.6 DLM (Distribuited Lock Manager) . . . . . . . . . . . . . . . . . . 25 4.7 RGManager (Resource Group Manager) . . . . . . . . . . . . . . . 26 4.8 GFS (Global File System) . . . . . . . . . . . . . . . . . . . . . . 26 4.9 LVM2 - Cluster (Logical Volume Manager 2) . . . . . . . . . . . . 27 4.9.1 Architettura di un sistema LVM . . . . . . . . . . . . . . . 27
  7. 7. INDICE ix 4.9.2 CLVM (Clustered LVM) . . . . . . . . . . . . . . . . . . . 28 4.10 GNBD (Global Network Block Device) . . . . . . . . . . . . . . . 28 4.10.1 Basic setup . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.10.2 Complex setup . . . . . . . . . . . . . . . . . . . . . . . . 30 4.10.3 Il file cluster.conf sotto GNBD . . . . . . . . . . . . . . . . 31 4.11 System-Config-Cluster . . . . . . . . . . . . . . . . . . . . . . . . 32 4.12 Gulm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.13 Perl-net-Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Implementazione in laboratorio 35 5.1 Il cluster del Lab4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1.1 Profilo Hardware . . . . . . . . . . . . . . . . . . . . . . . 36 5.1.2 Profilo Software . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Topologia I: GFS over GNBD-DAS . . . . . . . . . . . . . . . . . 37 5.2.1 Gli attori: . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.2 Interconnessione Hardware: Il cluster . . . . . . . . . . . . 38 5.2.3 Interconnessione Software: Il file system distribuito . . . . . 39 5.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.1 Installazione del cluster . . . . . . . . . . . . . . . . . . . . 40 5.4 Installazione del file system distribuito . . . . . . . . . . . . . . . . 46 5.5 Automatismi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.5.1 Caricamento automatico delle componenti GNBD . . . . . 48 5.5.2 Montaggio automatico delle partizioni GFS . . . . . . . . . 49 5.6 Il Cluster Deployment Tool . . . . . . . . . . . . . . . . . . . . . . 496 Fault tolerance 51 6.1 Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.1.1 Multipath over SAN . . . . . . . . . . . . . . . . . . . . . 52 6.1.2 Multipath over DAS . . . . . . . . . . . . . . . . . . . . . 53 6.2 Mirroring hardware con RAID . . . . . . . . . . . . . . . . . . . . 56 6.3 Mirroring software con LVM . . . . . . . . . . . . . . . . . . . . . 57 6.4 Channel Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Conclusioni 59 6.5 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.5.1 Analisi della gamma di file system distribuiti . . . . . . . . 59 6.5.2 Creazione del cluster . . . . . . . . . . . . . . . . . . . . . 60 6.5.3 Realizzazione del file system distribuito . . . . . . . . . . . 60 6.5.4 Implementazione della topologia GFS over GNBD-DAS . . 60 6.5.5 Analisi delle tecnologie di fault tolerance . . . . . . . . . . 60 6.6 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
  8. 8. x INDICE 6.6.1 Aggiunta di più server GNBD . . . . . . . . . . . . . . . . 61 6.6.2 Accesso al file system GFS anche dai nodi GNBD . . . . . 61 6.6.3 Realizzazione di un sistema fault tolerance . . . . . . . . . 61 6.6.4 Analisi delle prestazioni . . . . . . . . . . . . . . . . . . . 61 6.7 Un pò di numeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62A Il File System di Linux 63 A.1 Il file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 A.1.1 Il File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 A.1.2 Struttura interna dei file . . . . . . . . . . . . . . . . . . . 65 A.1.3 Metodi di accesso al file . . . . . . . . . . . . . . . . . . . 65 A.1.4 Il Direttorio . . . . . . . . . . . . . . . . . . . . . . . . . . 66 A.1.5 Metodi di Allocazione . . . . . . . . . . . . . . . . . . . . 67 A.2 Il file system in linux a livello hardware . . . . . . . . . . . . . . . 68 A.2.1 Organizzazione fisica . . . . . . . . . . . . . . . . . . . . . 68 A.2.2 Dispositivi: Operazione di Montaggio e Smontaggio . . . . 70 A.3 Il file system in linux a livello software . . . . . . . . . . . . . . . . 71B Il Logical Volume Manager 73 B.1 Come funziona LVM . . . . . . . . . . . . . . . . . . . . . . . . . 73 B.1.1 I Physical Volume . . . . . . . . . . . . . . . . . . . . . . 74 B.1.2 Il Volume Group . . . . . . . . . . . . . . . . . . . . . . . 74 B.1.3 I Logical Volume . . . . . . . . . . . . . . . . . . . . . . . 74 B.1.4 I Physical Extent e i Logical Extent . . . . . . . . . . . . . 75 B.2 Proprietà di LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 B.3 Differenze tra LVM e sistemi RAID . . . . . . . . . . . . . . . . . 77 B.4 Limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Ringraziamenti 81Bibliografia 85Elenco degli acronimi 87
  9. 9. Elenco delle figure 1 Tux la mascotte del sistema operativo linux. . . . . . . . . . . . . . xvi 1.1 Un sistema cluster della IBM. . . . . . . . . . . . . . . . . . . . . 2 3.1 Topologia GFS over SAN . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Topologia GFS over GNBD-SAN . . . . . . . . . . . . . . . . . . 15 3.3 Topologia GFS over GNBD-DAS . . . . . . . . . . . . . . . . . . 16 4.1 La struttura di CMAN . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Interazione tra Fence DLM e CMAN . . . . . . . . . . . . . . . . . 26 4.3 Architettura del sistema LVM . . . . . . . . . . . . . . . . . . . . . 27 4.4 GNBD - Basic Setup . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5 GNBD - Complex Setup . . . . . . . . . . . . . . . . . . . . . . . 30 4.6 Cluster Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1 Il modello di macchine usato in laboratorio . . . . . . . . . . . . . 35 5.2 Dettaglio della macchina . . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Topologia GNBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.4 Lab4 - Interconnessioni hardware . . . . . . . . . . . . . . . . . . 38 5.5 Lab4 - Interconnessioni software . . . . . . . . . . . . . . . . . . . 39 5.6 Il tool Cluster Manager . . . . . . . . . . . . . . . . . . . . . . . . 45 5.7 Il Cluster Deployment Tool . . . . . . . . . . . . . . . . . . . . . . 50 6.1 Supporto multipath in architettura SAN - GNBD . . . . . . . . . . 52 6.2 DAS storage in architettura GNBD . . . . . . . . . . . . . . . . . . 53 6.3 Supporto multi-ported in architettura GNBD . . . . . . . . . . . . . 54 6.4 Supporto mirroring in architettura GNBD . . . . . . . . . . . . . . 55 6.5 Mirroring hardware con RAID . . . . . . . . . . . . . . . . . . . . 56 6.6 Mirroring via software con LVM . . . . . . . . . . . . . . . . . . . 57 6.7 Channel Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.1 Organizzazione fisica . . . . . . . . . . . . . . . . . . . . . . . . . 68 B.1 Astrazione del Logical Volume Manager . . . . . . . . . . . . . . . 74
  10. 10. xii ELENCO DELLE FIGURE B.2 Esempio di mappatura reale . . . . . . . . . . . . . . . . . . . . . . 76 B.3 Snapshot sotto LVM . . . . . . . . . . . . . . . . . . . . . . . . . 76 B.4 Mapping Linear-Striped . . . . . . . . . . . . . . . . . . . . . . . . 77 B.5 Mirroring software con LVM . . . . . . . . . . . . . . . . . . . . . 79
  11. 11. Elenco delle tabelle 4.1 Pacchetti software della suite . . . . . . . . . . . . . . . . . . . . . 18 4.2 Pacchetti software aggiuntivi . . . . . . . . . . . . . . . . . . . . . 18 4.3 Pacchetti software di CMAN . . . . . . . . . . . . . . . . . . . . . 21 4.4 Pacchetti software di DLM . . . . . . . . . . . . . . . . . . . . . . 25 4.5 Pacchetti software di GFS . . . . . . . . . . . . . . . . . . . . . . . 26 4.6 Pacchetti software di GNBD . . . . . . . . . . . . . . . . . . . . . 28 5.1 Caratteristiche tecniche . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Software installato . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3 Partizionamento del GNBD Server: . . . . . . . . . . . . . . . . . 40 5.4 Partizionamento dei Client GFS: . . . . . . . . . . . . . . . . . . . 41 5.5 Settaggio sottorete: . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.6 Utenti del sistema: . . . . . . . . . . . . . . . . . . . . . . . . . . 41
  12. 12. xiv ELENCO DELLE TABELLE
  13. 13. Introduzione Failure is not an option. Eugene F. Kranz (Former flight director, NASA) Questa tesi si pone l’obiettivo dell’analisi e della implementazione di file systemdistribuiti in ambiente linux, dedicando particolare attenzione alle problematichepresenti nell’implementazione di un sistema reale altamente performante, in termi-ni di prestazioni, tollerante ai guasti, dedicato all’erogazione di servizi informatici.Un file system distribuito è, come vedremo meglio in seguito, uno strumento in gra-do di gestire una piattaforma dati comune tra più macchine distribuendo il contenu-to informativo globale tra di esse, garantendo la consistenza, l’integrità e l’accessoconcorrente ai dati, anche in caso di guasti. L’infrastruttura hardware portante su cui è implemetato il file system prende no-me di cluster. Un cluster (dall’inglese grappolo) è un insieme di computer connessitramite una rete telematica. Lo scopo di questa architettura è l’incremento presta-zionale in termini di calcolo computazionale e/o di risorse distribuite, dedicato allarisoluzione di un problema (algoritmo) o al supporto di più servizi informatici. Larealizazione di una struttura cluster è teoricamente indipendente dalla piattaformahardware o software dei suoi nodes (nodi), ovvero dei calcolatori che la compongo-no. In particolare però queste soluzioni hanno trovato un forte alleato nel sistemaoperativo linux dato che ad oggi la maggior parte di questi sistemi è principalmentebasato su questa piattaforma. Linux è un sistema operativo open source creato da Linus Torvald nel 1991, de-rivato da Minix, uno spin-off di Unix a scopo didattico, e distribuito sotto licensaGNU is Not Unix/General Public License (GNU/GPL). La scelta dell’uso di questosistema operativo in questo progetto di tesi, e in particolare della distribuzione Fe-dora Core release 4, deriva dal largo uso di linux in ambiente accedemico e il nativosupporto alla costruzione di soluzioni cluster e di distribuited file system per le qualiprevede un’ampia gamma di applicativi software per la gestione ed il set-up. In questa tesi saranno dunque esaminate tecnologie ed architetture, volte allosviluppo di una implementazione di file system distribuito su piattaforma linux.
  14. 14. xvi IntroduzioneVerranno esaminati e paragonati i vari software commerciali ed open source dispo-nibili, sui quali verrà effettuata una scelta motivata da fattori prestazionali e acca-demici, allo scopo ultimo di realizzare una piattafiorma tecnologica di base, per losviluppo di un cluster con finalità di high avaiability per servizi informatici dellafacoltà di Ingegneria dell’Univeristà di Bologna. Figura 1: Tux la mascotte del sistema operativo linux.
  15. 15. Capitolo 1Cluster linux Perché in ultima analisi, il legame fondamentale che unisce tutti noi é che abitiamo tutti su questo piccolo pianeta. Respiriamo tutti la stessa aria. Abbiamo tutti a cuore il futuro dei nostri figli. E siamo tutti solo di passaggio. John Fitzgerald Kennedy (28 Ottobre, 1962)1.1 Che cos’è un clusterCome già detto un cluster (dall’inglese grappolo) è un insieme di computer connes-si tramite una rete telematica e gestiti come un singolo sistema. Lo scopo di questaarchitettura è l’incremento prestazionale in termini di calcolo computazionale o dirisorse distribuite dedicate alla risoluzione di un problema o al supporto di più ser-vizi informatici. I calcolatori che compongono la rete vengono detti nodi del clustero semplicemente nodi.1.2 Tipologie di clusterI sistemi cluster si categorizzano in varie tipologie: 1. High-Avaiability clusters (HA-Clusters) 2. Load-Balancing clusters (LB-Clusters) 3. High-Performance clusters (HPC o HP-Clusters)
  16. 16. 2 Cluster linux Figura 1.1: Un sistema cluster della IBM.1.2.1 High-Avaiability clusters (HA-Clusters)Questa tipologia di cluster, che sarà quella presa in esame in questa tesi di laurea, èimplementata con lo scopo di generare un ambiente fail-safe, a prova di guasto, incui la rottura di uno dei componenti hardware, software o di rete non influisca sulladisponibilità di servizi che la struttura eroga.Per garantire ciò questa soluzione si basa su di una struttura a nodi ridondanti chegarantiscono il supporto al servizio in caso di un generico guasto ad uno dei no-di o ad un componente della rete. L’esempio minimo di una tipologia HA-Clusterprevede due nodi con accesso condiviso su di uno spazio di memoria. All’atto diuna richiesta solo uno dei nodi esegue le istruzioni mentre l’altro rimane in stand-by pronto in caso in cui il nodo operante subisca un guasto. Se ciò si verifica ilsecondo nodo fa sue le risorse di rete e di spazio fisico gestendo la richiesta senzache l’utente ne sia interessato. Questo procedimento di gestione dei guasti prende ilnome di failover.La scelta di questa tipologia ricade spesso per applicazioni di file sharing su di unarete, applicazioni business, servizi web, web-server e commercio elettronico.1.2.2 Load-Balancing clusters (LB-Clusters)Questa tipologia di cluster opera gestendo il carico di lavoro, o workload, distri-buendolo sui vari nodi della struttura. Queste architetture sono principalmente im-plementate per l’aumento delle prestazioni in ambiti in cui vi è un carico di lavoromolto grande che tende ad avere tempi di computazione troppo elevati.
  17. 17. 1.3. I cluster Beowulf 31.2.3 High-Performance clusters (HPC)Questa tipologia di cluster tende ad incrementare le potenzialità di calcolo computa-zionale dividendo il lavoro di un singolo processo su diversi nodi. Questa soluzionetrova spazio negli ambiti scientifici e della simulazione di modelli matematici com-plessi. A questo scopo è possibile consultare il sito http://top500.org che contienel’elenco dei 500 supercomputer più potenti del pianeta alcuni dei quali basati sucluster linux. Inoltre è interessante citare come uno dei calcolatori più potenti almondo risieda a Bologna, nella sede del Cineca.1.3 I cluster BeowulfNel 1994 Thomas Sterling e Don Becker crearono per conto della NASA un clustercomposto da 16 nodi realizzato con hardware Commercial-Off-The-Shelf (COTS)che prese nome di progetto Beowulf, dal titolo del primo poema epico romantico,finora conosciuto, scritto in lingua inglese.Un cluster Beowulf non identifica una tipologia, a differenza di quelle sopra elen-cate, bensì un approccio, una modalità di realizzazione di una struttura cluster conalcune caratteristiche particolari. Un nodo è preso come server node o head node,cioè nodo principale, da cui viene gestita l’intera struttura e da cui si ha la visioned’insieme del cluster, e uno o più client nodes, o nodi secondari, connessi via Ether-net o altro standard di rete tramite uno switch a completamento del sistema cluster.A rafforzare l’idea che un cluster Beowulf identifica solo una modalità di realiz-zazione di un cluster vi è la mancanza di alcun pacchetto software direttamenteriferibile al progetto, ma bensì una serie di software indipendente, compatibile conquesto approccio.1.4 I cluster e linuxLa natura gratuita ed open source di linux e l’alto interesse del mondo accademicoper le soluzioni cluster hanno dato il via ad un connubio fondamentale nella realiz-zazione delle prime infrastrutture di questo tipo, fino a raggiungere con lo sviluppodella comunità mondiale, la piena concorrenza in termini di rapporto prezzo/presta-zioni con le soluzioni proprietarie e dedicate, come i supercomputer, con l’enormevantaggio di un costo nettamente contenuto rispetto a quest’ultime.Al giorno d’oggi le soluzioni cluster linux cominciano ad entrare a far parte degli
  18. 18. 4 Cluster linuxapparati governativi ed industriali a livello mondiale, fatto che ne sancisce la loroaffidabilità, potenzialità ed economicità.1.5 Analisi di un clusterAnalizziamo i principi di funzionamento di una infrastruttura cluster con particolareattenzione ai suoi componenti hardware e software principali, ai loro ruoli e alla lorointerazione.1.5.1 Cluster HardwareI nodiI nodi di un cluster non sono altro che i computer interconnessi nella rete. I nodipossono avere una gerarchia, ci possono essere nodi computazionali, di gestione odi monitoraggio o non avere distinzioni di grado, in questo caso vengono detti nodipeer.La reteLa rete, o meglio l’infrastruttura di rete che interconnette i nodi, rappresenta laspina dorsale del sistema permettendo la comunicazione e l’interscambio di dati edinformazioni tra i vari nodi.1.5.2 Cluster SoftwareIl Sistema OperativoIl sistema operativo di un sistema cluster provvede a rendere i nodi operativi dalpunto di vista computazionale e garantisce una piattaforma software omogenea doveelaborare le informazioni. La scelta del sistema operativo ricadrà nel nostro caso,per i motivi fin quì discussi, su una distribuzione GNU/Linux, ed in particolare sulladistribuzione Fedora Core release 4. Ecco un elenco di sistemi operativi alla basedi soluzioni cluster: • GNU/Linux • AIX • Microsoft R Windows R • ...
  19. 19. 1.6. Cluster linux: Conclusioni 5Il Software per la gestione del clusterIl software per la gestione del cluster è un tool essenziale nella creazione di un si-stema di questo tipo che permette la costruzione, il mantenimento e l’espansionedella struttura mantenendo la visione d’insieme. Esistono differenti implementa-zioni di questo tipo di software, alcune open source altre proprietarie. Elencheremole principali: • Red Hat/Fedora Cluster Suite • IBM CSM (Cluster Systems Management) • OSCAR (Open Source Cluster Application Resources) • xCAT (eXtreme Cluster Administration Toolkit)Un file system ad alte prestazioniUn cluster è composto da molti nodi che necessitano la condivisione delle infor-mazioni garantendo però l’affidabilità, la concorrenza e la velocità d’accesso ne-cessaria a sostenere la gamma di servizi erogati. Per questo una struttura clusterche aspira a gestire dei servizi in distribuito deve avere una solida base di memoriz-zazione comune, affidabile e concorrente. I file system orientati a questo supportovengono definiti Distribuited File System e nel prossimo capitolo verranno esamina-ti in dettaglio alla ricerca di una soluzione adatta alla problematica in esame. Eccoi principali: • Red Hat/Fedora Global File System (GFS) • IBM General Parallel File System (GPFS) • Andrew File System (AFS) • ...1.6 Cluster linux: ConclusioniAbbiamo discorso come le varie tipologie di cluster aderiscono a problematiche ditipo diverso (potenza di calcolo computazionale, erogazione di servizi e bilancia-mento di risorse) passando per una analisi delle componenti hardware e softwareprincipali di una architettura di questo tipo. Questi concetti sono alla base del si-stema che verrà implementato in laboratorio, fornendo una valida base al file sy-stem distribuito. Nel prossimo capitolo verranno esaminati in dettaglio i file systemdistribuiti, analizzando a fondo le caratteristiche di alcuni di questi.
  20. 20. 6 Cluster linux
  21. 21. Capitolo 2File System locali e distribuiti Non è la libertà che manca. Mancano gli uomini liberi. Leo Longanesi (Giornalista e scrittore italiano) Dopo aver discusso ed introdotto le tecnologie alla base dei sistemi cluster esa-miniamo ora, in una panoramica, i file system e la loro natura, con particolareattenzione rivolta ai file system distribuiti, oggetto di analisi del nostro progetto.2.1 Il File SystemConcettualmente il file system è una collezione di data types astratti che sono imple-mentati per l’immagazzinamento, l’organizzazione gerarchica, la manipolazione, lanavigazione, la ricerca e l’accesso ai dati.Concretamente, invece, il file system è quella parte del sistema operativo che sioccupa, ad esempio, della gestione di file e delle directory, assicurando anche lasicurezza, la coerenza ed il controllo delle operazioni di accesso alle informazionida parte dell’utente. Il file system tipicamente usa dei dispositivi di memorizzazione come hard disko CD-ROM che mantengono l’informazione fisicamente, in questo caso si parla difile system locali o disk file system. Generalmente, però, può rappresentare ed orga-nizzare l’accesso a qualsiasi tipo di dato, sia che sia immagazzinato fisicamente inun dispositivo, sia generato dinamicamente. In questo caso il file system è di tipovirtuale o network file system, cioè esiste solo come strumento per l’accesso e lagestione di dati non necessariamente provenienti da un supporto fisico permanen-te, o locale, come ad esempio i dati provenienti da una connesione di rete (ad es.Network File System (NFS)).
  22. 22. 8 File System locali e distribuiti Un Distribuited File System (DFS) è un file system che supporta la condivisionedi file e risorse tra più client connessi tramite una rete telematica.2.2 File System locali o Disk File SystemsCome descritto, i file system locali tipicamente usano dei dispositivi di memorizza-zione fisica come hard disk o CD-ROM che mantengono l’informazione fisicamen-te e localmente. Esistono varie implementazioni di file system, alcune standard esupportate da tutti i sistemi operativi come i file system dei CD-ROM, alcune peri sistemi Unix-like, come Ext2 e ReiserFS, ed altre basate sulle varie versioni diWindows, come FAT e NTFS. • Unix-like file systems: – Ext2 – Ext3 – ReiserFS – XFS – ... • Windows file systems: – FAT16 – FAT32 – NTFS • ISO file systems: – ISO9660 – ...2.3 File System distribuiti o Distribuited File SystemsLe principali categorie in cui si suddividono i Distribuited File System (DFS) sono: 1. Distribuited Fault Tolerant File Systems 2. Distribuited Parallel File Systems 3. Distribuited Parallel - Fault Tolerant File Systems
  23. 23. 2.4. Analisi dei file system candidati 92.3.1 Distribuited Fault Tolerant File SystemsUn file system che appartiene a questa tipologia replica i dati tra i nodi che com-pongono il cluster per il supporto di operazioni offline e di high-availability. • Red-Hat/Fedora Global File System (GFS) • Andrew File System (AFS) • Open (Source) Global File System (OpenGFS) • Open (Source) Andrew File System (OpenAFS)2.3.2 Distribuited Parallel File SystemsUn file system che appartiene a questa tipologia esegue uno split dei dati tra i nodiche compongono il cluster per ottenere performance computazionali migliori adesempio per soluzioni HP-Cluster. • Parallel Virtual File System 2 (PVFS2) • Lustre2.3.3 Distribuited Parallel - Fault Tolerant File SystemsUn file system che appartiene a questa tipologia replica i dati tra i nodi che com-pongono il cluster per il supporto di operazioni offline e di high availability, sup-portando inoltre l’accesso parallelo di applicazioni ed utenti ai dati. • IBM General Parallel File System (GPFS) • Google File System (GFS)2.4 Analisi dei file system candidatiAnalizziamo ora in maniera più approfondita due dei file system distribuiti presen-tati, candidati per la successiva implementazione in laboratorio.2.4.1 Red Hat/Fedora GFS (Global File System)Red Hat/Fedora GFS è un file system distribuito e fault tolerant, recentemente ri-lasciato in licenza open source sulle distribuzioni Fedora Core a partire dalla re-lease 4. GFS è stato originariamente sviluppato come parte di un progetto di tesi
  24. 24. 10 File System locali e distribuitidell’Università del Minnesota per poi approdare per il completo sviluppo alla so-cietà Sistina Software. Nel 2001 GFS divenne un prodotto commerciale e il relativoprogetto open source, OpenGFS, si divise dall’ultima public release di GFS. NelDicembre 2003 Red Hat acquista Sistina e nel Giugno 2004, rilascia GFS e molteparti della sua cluster infrastructure sotto licensa GPL. Gli obiettivi attuali di RedHat per il proggetto sono garantire lo sviluppo della comunità open source con ilsupporto fornito dalla distribuzione Fedora Core. GFS permette di condividere datiin una piattaforma comune di archiviazione su una struttura cluster linux, massimiz-zando l’uso dello storage e diminuendo i costi. Inoltre GFS è uno dei pochi clusterfile system nativo a 64-bit con supporto per le architetture x86, AMD64/EM64T, epiattaforme Itanium. La sua implementazione supporta fino a 256 nodi ed inoltre èpienamente supportato sulle piattaforme Red Hat Enterprise Linux e Fedora Core(cioè non richiede patch per il kernel). Le applicazioni tipicamente supportate in unambiente GFS includono: • Databases (Oracle RAC) • Applicazioni e Web servers (Apache) • Applicazioni con supporto NFS • ...2.4.2 IBM GPFS (General Parallel File System)Il file system GPFS della IBM è un file system ad alte performance che permetteun accesso ai dati veloce e affidabile, da tutti i nodi, in un ambiente omogeneo e/oeterogeneo di cluster servers di tipo AIX o linux. GPFS permette accesso simulta-neo, ad applicazioni parallele, ad una varietà di file o ad un singolo file da qualsiasinodo garantendo un alto livello di protezione e controllo sulle operazioni del filesystem. Inoltre GPFS può essere configurato per gestire ed eliminare i Single PointOf Failure (SPOF) ovvero i singoli punti di guasto nella rete, facendo transitare idati dalla sorgente alla destinazione tramite diversi percorsi (supporto nativo al mul-tipath). A questo si aggiungono le funzionalità di logging e di replicazione dati chegarantiscono la consistenza e l’affidabiltà dei dati in caso di guasto.2.5 File System locali e distribuiti: ConclusioniCome presentato, i due file system candidati per l’implementazione hanno analogiee differenze che li caratterizzano. La nostra scelta verterà su uno dei due per i motividiscussi e analizzati nel seguente capitolo.
  25. 25. Capitolo 3Scelta del sistema We chose to go to the moon [. . . ] and do the other things, not because they are easy but because they are hard. John Fitzgerald Kennedy (12 Settembre, 1962) In questo capitolo analizzeremo la scelta di implementare il file system distri-buito Global File System (GFS) su piattaforma linux Fedora Core release 4, esami-nando le componenti caratterizzanti il sistema in termini di prestazioni e di fault-tollerance oltre ad apprendere le varie topologie di realizzazione dei cluster GFSbasati sul sistema operativo linux.3.1 Scelta del sistema e del file system: Perchè Red Hat/Fedora GFS?GFS è uno dei file system distribuiti con le maggiori referenze del settore ed èin continua crescita ed evoluzione. La recente apertura di questa tecnologia daparte della società proprietaria Red Hat, verso la comunità open source, rilasciandola serie di paccchetti di corredo che formano la cluster suite, oltre ai componentifondamentali di GFS sotto la distribuzione Fedora Core release 4 lascia intravedereun futuro molto roseo per questo file system globale. Da qui la nostra scelta dettatasia dalle necessità prestazionali che GFS è capace di fornire sia con un occhio diriguardo all’ambiente accademico che ha nell’open source e nei programmi sottolicenza GPL, la spina dorsale di molti progetti.
  26. 26. 12 Scelta del sistema3.2 GFS: Caratteristiche generali3.2.1 Caratteristiche tecnicheGFS è il primo file system con sviluppo nativo a 64-bit, permette la connessione dipiù server ad un file system comune basato su di una SAN o su di uno storage con-diviso, utilizzando la semantica standard per i file system UNIX/POSIX. Inoltre èaltamente scalabile in quanto è possibile aggiungere fino a 256 nodi ed è pienamen-te integrato con Red Hat Enterprise Linux e Fedora Core release 4. Infine, comeanticipato sopra, è recentemente stato rilasciato sotto licenza GPL, il che lo rendecostantemente aggiornato ed ampliato dalla comunità open source.3.2.2 La strutturaLe macchine del cluster GFS si appoggiano sul sistema operativo linux. Un com-plesso volume manager, con estensione per la gestione clusterized dei comandi,virtualizza in locale le storage units aggregandole in un singolo raggruppamentologico, il Volume Group (VG). I cambiamenti che un nodo applica al volume sonovisibili all’intero cluster. Su questo volume è possibile creare molteplici partizionilogiche, ognuna con un proprio file system, tipo GFS, accessibile da tutti i nodi.3.2.3 JournalingGFS è un file system di tipo journaled il che significa che tutte le operazioni effet-tuate sul file system dalle applicazioni, o dagli utenti dei vari nodi, vengono regi-strate in un journal (diario) prima di essere effettivamente trasmesse al file system.Ogni nodo mantiene quindi il proprio journal e in caso di node failure la consistenzadel file system può essere rispristinata grazie alle informazioni in esso contenute.3.2.4 Locking managerIl lock manager coordina le molteplici richieste che giungono dai nodi per l’ac-cesso concorrente file sullo stesso file system GFS garantendo la consistenza deidati. Fin dalla sua creazione GFS è provvisto di un gestore di lock di tipo modula-re. Nelle prime versioni le lock information venivano scambiate tramite protocolloSCSI (DLOCK, DMEP). Dalla versione 6.1 è integrato il Distribuited Lock Mana-ger (DLM) che permette ad ogni server, tramite la comunicazione del sergnale diheartbeat, il servizio di lock sul file system. Se il server non è in grado di comuni-care tramite heartbeat allora il lock manager lo rimuoverà fisicamente, disconnet-tendolo o spegnendolo, dal cluster, un’operazione detta di fencing. GFS supportamolteplici fencing mechanisms come i network power switch e HP’s ILO interface.
  27. 27. 3.2. GFS: Caratteristiche generali 13In GFS sono disponibili due differenti lock manager, lo storico GULM o il recenteDLM.3.2.5 ScalabilityUn classico sistema per l’IT consiste di servizi e applicazioni che girano su serversingoli. Se l’hardware dedicato a queste particolari applicazioni è limitato può suc-cedere che, con il tempo, questo non sia più sufficente andando incontro a quelloche si definisce come una capability shortage. A questo punto l’aggiunta di nuovicomponenti (server o storage device) possono essere facilmente implementati ed in-tegrati nel sistema finchè non si raggiunge la nuova disponibilità di risorse richiesta.La possibilità di espansione e modifica dei volume group e dei nodi in un sistemaGFS permette questo tipo supporto in modo semplice e altamente supportato.3.2.6 AvailabilityLa disponibilità o availability del sistema è un aspetto fondamentale della fornituradi servizi per l’IT. Per raggiungere una class 3 availability (dal 99% al 99.9%)è necessario eliminare qualsiasi Single Point Of Failure (SPOF). Per una class 4availability (dal 99.9% al 99.99%) inoltre è necessario avere dei mirrored data eun data center secondario per un eventuale disaster recovery. I servizi hanno lapossibilità di essere eseguiti su server multipli o differenti e il breakdown di unserver o dell’intero data center non devono causare che un temporanea sospensionedei servizi, limitata nel tempo. Un GFS cluster può essere connesso ad un centralstorage system via SAN con multi-path I/O, mirror e tecnologia RAID per garantirequeste specifiche.3.2.7 LAN-free backupUn data backup è generalmente eseguito da un backup client su di una LAN ad undedicato backup server tramite un software dedicato o LAN-free dagli applicationserver direttamente verso il backup device. E’ possibile in GFS convertire un serverin un backup server. Il backup server sarà in grado di effettuare un backup durantel’esecuzione di operazioni sul file system senza compromettere le operazioni incorso sugli application server. Inoltre la possibilità di generare snapshots, o cloni divolumi, per poi montarli in caso di procedure di ripristino estende questa proprietà.Per garantire ciò GFS include una quiesce capability per garantire la consistenza deidati durante le operazioni di backup. Significa tutti gli accessi al file system sonohalted (fermati) dopo una file system sync operation che coinvolge dati e metadatiin uno stato consistente prima della cattura dello snapshot.
  28. 28. 14 Scelta del sistema3.2.8 Diskless shared root clusteringServer addizionali possono essere aggiunti facilmente, come abbiamo visto, peraumentare le capacità del cluster. Se i dati condivisi e l’immagine del sistema ope-rativo sono sullo shared storage il risultato è un diskless shared root cluster dovenessuno dei server necessita di un hard disk locale ma ognuno può effettuare il bootdirettamente dalla rete SAN. Sia i dati che l’immagine del sistema operativo sonocondivisi il che significa che la partizione di root (/) per tutti i nodi del cluster ècomune. Come conseguenza la gestione è semplificata. I cambiamenti sono cosìeffettuati una sola volta e si ripercuotono su tutta la struttura.3.3 GFS: Architetture implementabiliDopo aver esaminato a fondo le caratteristiche e le peculiarità di GFS, vediamoora in dettaglio alcune delle principali topologie e architetture supportate, per losviluppo di un cluster basato sul file system di Red Hat. Una Storage Area Network (SAN) e una Local Area Network (LAN) si differen-ziano per molti aspetti, a partire dalle interfacce fisiche delle due reti, Fibre Chan-nel (FC) per le SAN ed Ethernet per le LAN. Le Fibre Channel (FC) sono moltocostose ma raggiungono migliori performance nella gestione del carico di lavorodello storage sulla rete, mentre il protocollo Ethernet è molto economico e garan-tisce delle performance adeguate, anche se non eccellenti, nel traffico di networkstorage workload, oltre ad essere altamente scalabile. Potendo fare affidamento su queste tecnologie ci si chiede se e come è possibilefondere questi due tipi di protocolli per raggiungere le migliori prestazioni, il mi-glior rapporto prezzo/prestazioni o la minor spesa possibile nell’implementazionedi un sistema GFS. In altre parole ci è possibile mantenere i benefici della tecnolo-gia SAN in quanto a performance ed efficenza con il basso costo e la scalabilità diuna Gigabit Ethernet? Vediamo alcune architetture ed i relativi benefici.3.3.1 GFS over SANQuesta architettura permette di ottenere le più alte performance in termini di shared-file in quanto le applicazioni accedono allo storage direttamente. La configurazioneGFS over SAN garantisce file performance superiori per i file condivisi e per i fi-le system come GFS. Le applicazioni linux sono in esecuzione direttamente suinodi GFS. Senza file protocols (presenti su Ethernet) o storage servers a rallenta-re il flusso dati, le performance sono simili ad un singolo server con uno storagedirettamante connesso (DAS).
  29. 29. 3.3. GFS: Architetture implementabili 15 Figura 3.1: Topologia GFS over SAN3.3.2 GFS over GNBD-SANMolteplici applicazioni client linux possono condividere gli stessi dati della reteSAN sulla locale LAN. Il blocco di storage SAN è visto dai nodi GFS come dispo-sitivi di block storage gestiti da diversi GNBD server. Dalla prospettiva di una clientapplication lo storage è acceduto come se si trattasse di un device locale ma i datisono in realtà residenti sulla SAN. Il file locking e le funzioni di condivisione (sha-ring) sono gestite da GFS per ogni nodo GFS client. GNBD è un software protocolper la condivisione in rete dei block device, come iSCSI, anch’esso supportato daGFS. Quando GFS è usato in congiunzione con GNBD o iSCSI esso è eseguito suinodi, la rete SAN e i server GNBD rendono disponibili come locali i device fisicisu cui è mappato il file system. Figura 3.2: Topologia GFS over GNBD-SAN
  30. 30. 16 Scelta del sistema3.3.3 GFS over GNBD-DASLa più economica alternativa implementabile prevede come le applicazioni clientlinux possano ottenere vantaggio sfruttando una topologia Ethernet esistente in gra-do di garantire un accesso condiviso allo storage. Il failover di una applicazione èautomaticamente gestito dalla parte di gestione del cluster (Cluster Suite) mentre ilfailover di uno dei server GNBD o di un disk device porta a più serie conseguen-ze. Da notare che questa architettura si pone come obiettivo la massima econo-micità possibile, in cui sofisticati meccanismi di fault tollerance non sono previsti.E’ però possibile implementare degli accorgimenti particolari per incrementare daquesto punto di vista le performance di questo tipo di architetture. Si rimanda ladiscussione di tali migliorie al capitolo 6. Figura 3.3: Topologia GFS over GNBD-DAS3.4 Scelta del sistema: ConclusioniDi seguito realizzeremo un sistema GFS su architettura GNBD-DAS, non primaperò di aver introdotto le componenti software e i vari pacchetti che costituisconotale implementazione.
  31. 31. Capitolo 4Analisi degli strumenti software Ci sono 10 tipi di persone al mondo: chi capisce il codice binario e chi no. Anonimo In questo capitolo analizzeremo le varie componenti software aggiuntive, ri-spetto al solo sistema operativo, per la realizzazione del nostro sistema basato supiattaforma linux Fedora Core release 4 e Red Hat Global File System.4.1 Cluster SuiteQuesta suite prevede una serie di componenti software per la realizzazione dellanostra architettura cluster su cui verrà implementato il file system distribuito. Ipacchetti sono disponibili in formato source code dal sito del cluster project e anchedal sito di Fedora, comprendono vari software per la gestione del cluster, per larealizzazione dei volumi logici per la creazione di file system di tipo GFS.4.2 CCS (Cluster Configuration System)Questo pacchetto provvede alla configurazione delle informazioni per la gestionedel cluster, quali il nome dello stesso, i nomi dei nodi che lo compongono, etc. CCSè lo strumento che permette ai nodi di localizzare le informazioni di cui hanno bi-sogno. Il pacchetto comprende vari applicativi e file di configurazione, alcuni deiquali fondamentali che analizzeremo in dettaglio: 1. Il demone /sbin/ccsd
  32. 32. 18 Analisi degli strumenti software Pacchetti software della suite: CCS: ccs-0.25-0.17.i386.rpm Magma: magma-1.0-0.pre21.7.i386.rpm Magma-plugins: magma-plugins-1.0-0.pre18.3.i386.rpm CMAN: cman-1.0-0.pre33.15.i386.rpm CMAN-Kernel: cman-kernel-smp-2.6.11.5- [...] .i686.rpm Fence: fence-1.27-16.i386.rpm RGManager: rgmanager-1.9.31-3.i386.rpm DLM: dlm-1.0-0.pre21.10.i386.rpm DLM-Kernel: dlm-kernel-smp-2.6.11.5- [...] .i686.rpm GFS: GFS-6.1-0.pre22.6.i386.rpm GFS-Kernel: GFS-kernel-smp-2.6.11.8- [...] .i686.rpm LVM2: lvm2-2.01.08-2.1.i386.rpm LVM2-Cluster: lvm2-cluster-2.01.09-3.0.i386.rpm GNBD: gnbd-1.0-0.pre14.6.i386.rpm GNBD-Kernel: gnbd-kernel-smp-2.6.11.2- [...] .i686.rpm System-Config-Cluster: system-config-cluster-1.0.24-1.0.noarch.rpm Perl-Net-Telnet: perl-Net-Telnet-3.03-4.noarch.rpm GULM: gulm-1.0-0.pre30.1.i386.rpm Repository: http://fedora.redhat.com/ Tabella 4.1: Pacchetti software della suite Pacchetti software aggiuntivi: Cluster Deployment Tool: cs-deploy-tool-0.9.7-1.0.noarch.rpm Repository: http://people.redhat.com/rkenna/gfs-deploy-tool/ Tabella 4.2: Pacchetti software aggiuntivi 2. Il file /etc/cluster/cluster.conf 3. Il tool ccs_test 4. Il tool ccs_tool4.2.1 Il demone /sbin/ccsd:Il demone /sbin/ccsd è uno dei servizi attivi sui nodi del cluster. Questo demoneprovvede all’interscambio delle informazioni tra i nodi e la loro corretta configura-zione. E’ possibile monitorare il suo stato eseguendo il comando: [root@masternode ~]service ccsd status ccsd (pid 1825) in esecuzione...
  33. 33. 4.2. CCS (Cluster Configuration System) 194.2.2 Il file /etc/cluster/cluster.conf <?xml version="1.0"?> <cluster alias="lab4cluster" config_version="4" name="114890487422"> <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/> <clusternodes> <clusternode name="node1" votes="1"> <fence> <method name="1"> <device name="manual" nodename="node1"/> </method> </fence> </clusternode> <clusternode name="node2" votes="1"> <fence> <method name="1"> <device name="manual" nodename="node2"/> </method> </fence> </clusternode> <clusternode name="gnbd1" votes="1"> <fence> <method name="1"> <device name="manual" nodename="gnbd1"/> </method> </fence> </clusternode> </clusternodes> <cman/> <fencedevices> <fencedevice agent="fence_manual" name="manual"/> </fencedevices> <rm> <failoverdomains> <failoverdomain name="lab4faildomain" ordered="0" restricted="1"> <failoverdomainnode name="node1" priority="1"/> <failoverdomainnode name="node2" priority="1"/> <failoverdomainnode name="gnbd1" priority="1"/> </failoverdomain> </failoverdomains> <resources/> </rm> </cluster> Il file /etc/cluster/cluster.conf contiene tutte le informazioni principalidella struttura cluster. La sua estensione .conf indica che è un file di configurazionema la sua struttura interna rivela la sua natura di documento XML. Analizziamoloin dettaglio. La prima riga contiene l’intestazione del documento XML, seguitadal tag che definisce le informazioni riguardanti il cluster, nome, alias, e versionedel file di configurazione. Segue poi il tag dedicato al demone di fencing, a cuisi accoda la sezione dedicata ai nodi, con nome e voti di quorum degli stessi e leinformazioni relative ad ogni nodo sul proprio sistema di fencing. Chiusa questasezione vi è quella relativa ai failover domain, alle risorse ed ai servizi attivi sulcluster.
  34. 34. 20 Analisi degli strumenti software4.2.3 Il tool ccs_testIl comando ccs_test può essere seguito da 7 diversi comandi, visualizzabili esplo-rando l’help, da console digitando semplicemente ccs_test. I comandi principalisono connect e disconnect seguiti poi da altri comandi secondari per il recuperodelle informazioni gestite dal CCS. Il comando ccs_tool connect cerca di con-nettere il nodo al sistema CCS e in caso di successo ritorna il connection descrip-tor. Il comando ccs_test disconnect comunica al sistema CCS l’intenzione didisconnettersi. [root@masternode ~]# ccs_test -h Usage: ccs_test [Options] <Command> Options: -h Print usage. -V Print version information. Commands: connect <force> <block> Connect to CCS and return connection descriptor. disconnect <desc> Disconnect from CCS. get <desc> <request> Get a value from CCS. get_list <desc> <request> Get a value from CCS. set <desc> <path> <val> Set a value in CCS. get_state <desc> Get the state in the connection. set_state <desc> <ncwp> Set the current working path4.2.4 Il tool ccs_toolIl comando ccs_tool può essere seguito da 2 comandi, update e upgrade. Il co-mando ccs_tool update comunica al demone ccsd di aggiornare il file XML diconfigurazione /etc/cluster/cluster.conf su tutti i nodi della struttura. Il co-mando ccs_tool upgrade comunica al demone ccsd di aggiornare gli eventualivecchi file di configurazione in formato .ccs al più nuovo formato XML (retrocom-patibilità con vecchie versioni di GFS).
  35. 35. 4.3. Magma e Magma-plugins 21 [root@masternode ~]# ccs_tool -h Usage:: ccs_test [options] <command> Options: -h Print this usage and exit. -V Print version information and exit. Commands: help Print this usage and exit. update <xml file> Tells ccsd to upgrade to new config file. upgrade <location> Upgrade old CCS format to new xml format.4.2.5 Avvio del servizio ccsdIn fase di init del runlevel, dopo l’installazione, questo demone viene avviato auto-maticamente dal sistema operativo. In caso di necessità è possibile avviare, stopparee visualizzare lo stato del servizio direttamente da consolle: [root@masternode ~]# service ccsd start Starting ccsd: [ OK ] [root@masternode ~]# service ccsd status ccsd (pid 1825) in esecuzione... [root@masternode ~]# service ccsd stop Stopping ccsd: [ OK ]4.3 Magma e Magma-pluginsI pacchetti magma e magma-plugins contengono le librerie e le rispettive pluginsper i lock manager del cluster.4.4 CMAN (Cluster MANager)Questo pacchetto provvede alla gestione del cluster e dei moduli aggiuntivi per ilkernel. Pacchetti software di CMAN: CMAN: cman-1.0-0.pre33.15.i386.rpm CMAN-Kernel: cman-kernel-smp-2.6.11.5- [...] .i686.rpm Repository: http://fedora.redhat.com/ Tabella 4.3: Pacchetti software di CMAN
  36. 36. 22 Analisi degli strumenti software A livello concettuale CMAN si compone di due sottosistemi, come si evincedalla figura, il Connection Manager (CM) e il Service Manager (SM) entrambiapprofonditi in seguito. Figura 4.1: La struttura di CMAN Il pacchetto comprende vari applicativi e file di configurazione, alcuni dei qualifondamentali che analizzeremo in dettaglio: • I demoni di cman • Il tool cman_tool4.4.1 CM (Connection Manager)E’ uno dei sottosistemi di CMAN che gestisce le operazioni di membership deinodi del cluster, le operazioni di join/leave, dei livelli di quorum per evitare glisplit-brain, gestisce la sincronizzazione tramite broadcast/multicast con i segnalidi heartbeat, gestisce gli ID dei nodi, effettua le transazioni multi-stage del join/-leave di un nodo per garantire la consistenza, usando le Application ProgrammingInterface (API) per la comunicazione dei suoi membri (SM e CLVMD)4.4.2 SM (Service Manager)Il secondo dei sottosistemi di CMAN che gestisce quelli che sono i servizi di co-municazione con il cluster da parte degli applicativi superiori (GFS, DLM, Fence),implementa il concetto di service group e recovering dei servizi layered.4.4.3 I demoni di cmanI demoni raccolti sotto il servizio cman sono quattro, cman_comms, cman_memb,cman_serviced e cman_hbeat. Tutti questi servizi sono gestiti da un unico demo-ne che li esegue automaticamente insieme all’avvio del sistema. In caso di necessitàè possibile avviare, stoppare e visualizzare lo stato dei servizi direttamente da con-solle. In realtà tra le fasi di avvio, stato e stop del servizio intercorrono altre fasi,
  37. 37. 4.4. CMAN (Cluster MANager) 23come il join del nodo dopo l’avvio del servizio e lo stop dei sottosistemi attivi primadello stop del servizio, come documentato nell’help: [root@node1 ~]# service cman start Starting ccsd: [ OK ] ... [root@node1 ~]# service cman status Protocol version: 5.0.1 Config version: 3 Cluster name: 114768214408 Cluster ID: 8280 Cluster Member: Yes Membership State: Cluster-Member Nodes: 2 Expected_votes: 1 Total_votes: 2 Quorum: 1 Active subsystems: 4 Node name: node1 Node address: 192.168.4.1 ... [root@node1 ~]# service cman stop Stopping ccsd: [ OK ]4.4.4 Il tool cman_toolIl tool cman_tool permette una serie di operazione per la gestione del cluster edei suoi nodi. In particolare è possibile fare il join di un nodo al cluster, oppureeliminarlo dalla struttura con l’operazione leave o altro, come operazioni di reportsul cluster tramite i comandi status, nodes, services.Operazione join:Il comando principale dello strumento cman_tool è il join di un nodo nel cluster. Senon sono specificate a riga di comando delle opzioni, il join si basa sulle informazio-ni fornitegli dal CCS ovvero le informazioni del file /etc/cluster/cluster.conf.Altrimenti è possibile fornire le informazioni necessarie per il join del nodo diretta-mente da console, vediamo un esempio: [root@node1 ~]# cman_tool -d join -X -c <clustername> -n <nodename>
  38. 38. 24 Analisi degli strumenti softwareOperazione leave:Comunica a CMAN che il nodo intende lasciare il cluster. Questa operazione nonè permessa se ci sono sottosistemi attivi come DLM o GFS. In tal caso occorresmontare tutti i filesystem GFS, disattivare DLM, Fenced e qualsiasi altro servizioo risorsa del nodo che usi CMAN. [root@node1 ~]cman_tool leaveOperazione kill:Comunica a CMAN di ”uccidere” kill un’altro nodo nel cluster. Il nodo locale man-da un segnale di kill ed i sottosistemi di CMAN provvederanno al suo spegnimento(tramite i fence device). [root@node1 ~]cman_tool kill -n <nodenames>Operazione status:Visualizza lo stato locale del cluster: [root@node1 ~]cman_tool status Protocol version: 5.0.1 Config version: 3 Cluster name: 114768214408 Cluster ID: 8280 Cluster Member: Yes Membership State: Cluster-Member Nodes: 2 Expected_votes: 1 Total_votes: 2 Quorum: 1 Active subsystems: 4 Node name: node1 Node address: 192.168.4.1Operazione nodes:Visualizza lo stato locale dei nodi del cluster:
  39. 39. 4.5. Fence 25 [root@masternode ~]cman_tool nodes Node Votes Exp Sts Name 1 1 1 M node1 2 1 1 M node2Operazione services:Visualizza quanti e quali servizi stanno girando sul cluster: [root@masternode ~]cman_tool services Service Name GID LID State CODE "Fence Domain:" default4.5 FenceIl pacchetto Fence e il demone fenced rappresentano e gestiscono il sistema diI/O fencing del cluster, composto da una serie di agenti in grado di connettersiai power-switch connessi alla rete per gestire l’accensione e lo spegnimento fisicodelle macchine. Nella nostra implementazione non faremo uso di power-switch e lagestione del fencing sarà manuale.4.6 DLM (Distribuited Lock Manager)DLM è uno dei due sistemi di lock manager di GFS: Pacchetti software di DLM: DLM: dlm-1.0-0.pre21.10.i386.rpm DLM-Kernel: dlm-kernel-smp-2.6.11.5- [...] .i686.rpm Repository: http://fedora.redhat.com/ Tabella 4.4: Pacchetti software di DLM DLM è usato in aggiunta con CMAN. In alternativa il solo GULM svolgele stesse funzioni. Molti sistemi cluster distribuiti usano DLM per inter-processsynchronization dove i processi possono essere residenti su macchine differenti.GFS e CLVM sono due esempi particolari: GFS usa il DLM dal kernel e CLVMdall’userspace
  40. 40. 26 Analisi degli strumenti software Figura 4.2: Interazione tra Fence DLM e CMAN4.7 RGManager (Resource Group Manager)RGManager è un group failover open source dedicato all’high availability che ga-rantisce la disponibilità di sistemi critical server e applicazioni in caso di previsti oimprovvisi system downtime.4.8 GFS (Global File System)Questo pacchetto è la componente del file system distribuito vero e proprio dei suoimoduli kernel: Pacchetti software di GFS: GFS: GFS-6.1-0.pre22.6.i386.rpm GFS-Kernel: GFS-kernel-smp-2.6.11.8- [...] .i686.rpm Repository: http://fedora.redhat.com/ Tabella 4.5: Pacchetti software di GFS Il Global File System (GFS) è un file system distribuito disponibile per clusterlinux. GFS si differenzia dagli altri file system distribuiti come AFS, Coda, o Inter-Mezzo perchè richiede che tutti i nodi abbiano un’accesso diretto e concorrente alloshared storage. Tutti i nodi in una struttura cluster GFS sono peer. I protocolli piùusati per lo shared storage in ambienti cluster GFS sono FC, iSCSI, GNBD o AoE.GFS inoltre dipende da un lock manager distribuito come GULM or DLM.
  41. 41. 4.9. LVM2 - Cluster (Logical Volume Manager 2) 274.9 LVM2 - Cluster (Logical Volume Manager 2)Il Logical Volume Manager è un gestore di volumi logici avanzato che estende ilconcetto di disk storage rispetto ai tradizionali concetti di disco e partizione disco.LVM concede all’amministratore un maggiore flessibilità e dinamicità nella gestio-ne dello spazio per applicazioni ed utenti. I volumi LVM possono essere ridimen-sionati e manipolati a piacere dall’amministratore in caso di necessità a differenzadelle normali partizioni linux standard. Un approfondimento particolare al sistemaLVM sarà effettuato nella B.4, mentre in questo capitolo ci limiteremo ad osservarela sua struttura e la sua gestione in un ambiente clusterized.4.9.1 Architettura di un sistema LVM Figura 4.3: Architettura del sistema LVM
  42. 42. 28 Analisi degli strumenti software4.9.2 CLVM (Clustered LVM)CLVM è un demone userland che realizza una estensione a livello di cluster deicomandi di LVM. • Comandi eseguibili da qualsiasi nodo del cluster • Stessi comandi di LVM usati sul singolo host4.10 GNBD (Global Network Block Device)GNBD è un sistema di import/export di dispositivi a blocchi locali da/sulla rete. Alsuo interno si trovano i tool di supporto a queste operazioni sia per il lato server cheper il lato client. E’ possibile dunque esportare ed importare device locali tra i nodiche hanno GNBD. Vedremo ora in dettaglio due dei setup tipici dei sistemi GNBD. Pacchetti software di GNBD: GNBD: gnbd-1.0-0.pre14.6.i386.rpm GNBD-Kernel: gnbd-kernel-smp-2.6.11.2- [...] .i686.rpm Repository: http://fedora.redhat.com/ Tabella 4.6: Pacchetti software di GNBD4.10.1 Basic setupIn un setup di questo tipo la macchina server GNBD esporta sulla rete i suoi dischilocali, che vengono importati dalla rete dai client GNBD. Analizziamo in dettaglioi componenti di questa architettura: • 2+ GNBD client machines, con GFS • 1 GNBD server machine, senza GFSGNBD Server Machine • Avvio il gnbd server daemon: [root@masternode ]# gnbd_serv Esporto i block devices (Questo comando si può eseguire molteplici volte, per esportare molteplici block devices): [root@masternode ~]# gnbd_export -c -e <unique_gnbd_device_name> -d <local_partition_name>}
  43. 43. 4.10. GNBD (Global Network Block Device) 29 Figura 4.4: GNBD - Basic SetupGNBD Client Machines (GFS Servers) • Monto sysfs, se non è già in running: [root@node1 ~]# mount -t sysfs sysfs /sys • Carico il modulo gnbd: [root@node1 ~]# modprobe gnbd • Importo i devices gnbd (Questo comando importa tutti i device gnbd esportati dal server. I dispositivi gnbd appariranno in /dev/gnbd/...): [root@node1 ~]# gnbd_import -i <gnbd_server_machine>
  44. 44. 30 Analisi degli strumenti software4.10.2 Complex setupIl Complex Setup comprende inoltre la possibilità di gestire queste modalità: 1. Macchina server con incluso GFS. 2. Macchine server che condividono lo stesso shared storage, possibilità di dm- multipath dei clients. 3. Combinazioni delle precedenti 1 e 2. Il setup per la modalità 1 è lo stesso del Basic-Setup. Il setup per la modalità 2invece è il seguente: Figura 4.5: GNBD - Complex SetupServer machines • Avvio il cluster manager (CMAN) e il fencing come da setup di GFS. • Avvio il gnbd server daemon. • Esporto i block devices.
  45. 45. 4.10. GNBD (Global Network Block Device) 31 Questo comando, come visto, si può eseguire molteplici volte, per esportaremolteplici block devices. Se l’opzione -c caching non è inclusa nel comando ildevice è esportato in modalità uncached, il che permette che sia acceduto da altremacchine o montato dalla stessa macchina senza avere problemi di consistenza dati.Inoltre tutti i dispositivi gnbd devono avere nomi univoci sulla rete, se vengonoesportati dei device con gli stessi nomi locali da molteplici server.Clients machines • Monto sysfs, se non è già in esecuzione. • Carico il modulo gnbd. • Avvio il cluster manager. • Importo i device gnbd. Come sopra, questo comando si può eseguire molteplici volte, per importaremolteplici block devices da molteplici server.4.10.3 Il file cluster.conf sotto GNBDIn un setup simple cached non è strettamente necessario includere il server gnbdnella sezione nodes del file /etc/cluster/cluster.conf. Se questo non vienefatto il cluster manager non sarà però in grado di gestirlo in caso diventi unrespon-sive (non risponda). Questo significa che il cluster può rimanere senza acceso alloshared storage finchè il server gnbd non viene manualmente riavviato. In un setup complex uncached invece il server gnbd deve essere incluso nellasezione nodes del file /etc/cluster/cluster.conf. In questa architettura molte-plici server gnbd gestiscono lo stesso dispositivo dello shared storage per garantireil multipath. I server gnbd devono essere gestiti da un agente che in realtà fermile macchine invece di tagliare semplicemente l’accesso allo shared storage. Per lagestione di questi eventi è consigliato l’uso di un network power switch al posto delfencing manuale.Non-multipathed setup <fence_devices> . . (other fence_devices) . <device name="gnbd" agent="fence_gnbd" servers="gnbd_server"> </fence_devices>
  46. 46. 32 Analisi degli strumenti softwareMultipathed setup <fence_devices> . . (other fence_devices) . <device name="gnbd" agent="fence_gnbd" option="multipath" servers="gnbd_server_1 ... gnbd_server_m"/> </fence_devices>General setupPer tutti e due i setup la sezione di fencing deve apparire così: <node name="gnbd_client_1" votes="1" > <fence> <method name="single"> <device name="gnbd" nodename="gnbd_client_1"/> </method> </fence> </node>4.11 System-Config-ClusterIl pacchetto system-config-cluster fornisce tutti gli strumenti di gestione del clustersotto un’unica interfaccia grafica gestibile da ogni nodo: Figura 4.6: Cluster Manager
  47. 47. 4.12. Gulm 334.12 GulmGULM è uno dei due lock manager per GFS, GNBD e CLVM, ed è una alternativaa CMAN e DLM. Un singolo server GULM può girare in modalità stand-alone, in-troducendo così un Single Point Of Failure (SPOF) per GFS. Tre o quattro GULMserver possono essere in esecuzione contemporaneamente così facendo il failuredi uno o più server può essere tollerato. GULM è ancora supportato come lockmanager per GFS per motivi storici e di retrocompatibilità. L’introduzione nell’ul-tima versione di DLM chiarisce le intenzioni a riguardo del suo uso da parte deglisviluppatori del progetto.4.13 Perl-net-TelnetQuesto pacchetto è un modulo perl per le connessioni client a porte TCP o adoperazioni di I/O su di una rete tramite protocollo telnet.
  48. 48. 34 Analisi degli strumenti software
  49. 49. Capitolo 5Implementazione in laboratorio Mai fidarsi di un computer che non è possibile gettare dalla finestra. Steve Wozniack (Co-fondatore della Apple) Il risultato dell’analisi dei file system distribuiti e delle architetture cluster finqui prese in esame si finalizza nell’implementazione di un piccolo sistema con filesistem distribuito, realizzato nel Laboratorio 4 (LAB4) della facoltà di Ingegneriadell’Università di Bologna.5.1 Il cluster del Lab4Il sistema realizzato si compone di 3 macchine (nodi) interconnesse tra loro tra-mite una sottorete privata, lab4cluster, della rete interna al laboratorio. Su questemacchine, con piattaforma software comune (Fedora Core release 4), è distribuitoil Global File System (GFS). Figura 5.1: Il modello di macchine usato in laboratorio
  50. 50. 36 Implementazione in laboratorio5.1.1 Profilo HardwareI tre nodi del sistema cluster sono macchine di tipo desktop basate su architetturaAMD64 con le seguenti caratteristiche tecniche: Caratteristiche tecniche: Sistema: Hewlett-Packard HP dx5150 MT(PE679AV) Processore: DualCore AMD Athlon 64 X2 3800+ Memoria Primaria: 512MB (PC3200 DDR SDRAM) Memoria Secondaria: ST380013AS (80GB, 7200 RPM, SATA) Scheda Rete: Broadcom Gigabit Ethernet (10-100 MBit/s) Tabella 5.1: Caratteristiche tecniche Figura 5.2: Dettaglio della macchina5.1.2 Profilo SoftwareI tre nodi del sistema cluster condividono anche alcune componenti software, comead esempio il sistema operativo e la serie di pacchetti caratterizzanti la gestione delsoftware del cluster e del file system distribuito: Software: Sistema operativo: Fedora Core release 4 Kernel release: 2.6.11-1.1369_FC4smp Tabella 5.2: Software installato
  51. 51. 5.2. Topologia I: GFS over GNBD-DAS 37 Come abbiamo introdotto nel capitolo 3 la scelta per l’implementazione delsistema ricade sulla realizzazione di una struttura GFS over GNBD-DAS basatasull’architettura cluster implementata in laboratorio.5.2 Topologia I: GFS over GNBD-DASCome visto nel capitolo 3 esistono diverse topologie di implementazione di un si-stema basato su GFS. La prima scelta ricade sulla topologia GFS over GNBD-DAS,ovvero su di un sistema che prevede l’uso di tre nodi di cui due saranno nodi GFSe al tempo stesso client GNBD e uno sarà il server GNBD che esporterà tramite ilprotocollo una partizione del suo disco interno o Direct Attached Storage (DAS). Figura 5.3: Topologia GNBD5.2.1 Gli attori: • GNBD Server: Il server GNBD è il nodo centrale di condivisione dei block device. Tramite il protocollo il server rende disponibile, con il comando di export, uno o più dei suoi block devices sulla rete. • GFS Node1: Il primo dei nodi GFS nonchè uno dei due GNBD client ov- vero uno dei nodi che importa, con il comando di import, i block device resi disponibili dal GNBD server.
  52. 52. 38 Implementazione in laboratorio • GFS Node2: Il secondo dei nodi GFS nonchè uno dei due GNBD client ov- vero uno dei nodi che importa, con il comando di import i block device resi disponibili dal GNBD server.5.2.2 Interconnessione Hardware: Il clusterLe interconnessioni fisiche tra le macchine sono mostrate in figura 5.4. Le tre mac-chine hanno ognuna un univoco nome e indirizzo IP e appartengono alla stessasottorete (lab4cluster). Le loro schede di rete sono connesse tramite cavi Ethernetcat. 5e al gruppo prese 159-162 del tavolo del laboratorio. Le prese 159, 161 e 162forniscono accesso alle tre macchine, tramite lo switch, alla sottorete 192.168.4.x(lab4cluster), mentre la porta addizionale 160, sempre tramite switch, permette laconnessione esterna alla rete Internet (per usi di servizio). Figura 5.4: Lab4 - Interconnessioni hardware
  53. 53. 5.2. Topologia I: GFS over GNBD-DAS 395.2.3 Interconnessione Software: Il file system distribuitoLe interconnessioni delle componenti software tra le macchine del cluster sonomostrate in figura 5.5. Dal basso verso l’alto i dispositivi Direct Attached Sto-rage (DAS) connessi tramite protocollo SCSI al server GNBD vengono esportatisulla rete TCP/IP. Qui vengono importati dai nodi GFS come device locali e tramitei comandi clusterized di LVM, gestiti dal demone CLVMD, viene creata la strutturadei volumi logici a supporto del file system. Sul Logical Volume (LV) comune ècreato il file system GFS, acceduto contemporaneamente dai due nodi come se fosseuna risorsa locale. Figura 5.5: Lab4 - Interconnessioni software
  54. 54. 40 Implementazione in laboratorio5.3 ImplementazioneVedremo ora l’implementazione, passo passo, eseguita in laboratorio. Questa sicompone di due fasi, la prima riguardante la creazione del cluster, la seconda lagenerazione su di esso del file system distribuito.5.3.1 Installazione del clusterUna volta ottenuto l’accesso al laboratorio, l’assegnazione di uno spazio dedicatoal progetto e delle tre macchine su cui implementare il sistema, si è provveduto allarealizzazione del cluster. • Passo 1: Collocazione fisica delle macchine in laboratorio. Collegamento dei cavi di alimentazione, delle periferiche di Input/Output (I/O) (tastiera, mouse e schermo), delle periferiche di rete dei nodi alla rete del laboratorio tramite cavi Ethernet dalle prese delle postazioni allo switch del LAB4. • Passo 2: Installazione del sistema operativo (Fedora Core release 4) sulle macchine. Una volta ottenuto il DVD della distribuzione Fedora Core release 4 dal sito ufficiale di Fedora, si provvede ad installare il sistema opertivo sulle tre macchine, seguendo la procedura grafica guidata. – Passo 2.1: Creazione delle partizioni per il sistema operativo e per i dati. Per i due tipi di macchine facenti parte del cluster devo provvedere a partizionamenti separati che si rispecchieranno poi nella suddivisione dei ruoli tra GNBD client e server come specificato nella tabella 5.3. Partizionamento del GNBD Server: Device Mount point File system Dimensione /dev/sda1 / ext3 10GB /dev/sda2 LVM 65GB /dev/sda3 estesa 1024 /dev/sda4 swap 1024 Tabella 5.3: Partizionamento del GNBD Server: – Passo 2.2) Settaggio software della sottorete del cluster: Al prossi- mo passo della installazione verrà chiesto all’utente se desidera settare i parametri di connessione alla rete locale del proprio sistema. Questa operazione è possibile anche in seguito, ma in fase di installazione è consigliato da subito configurare tale interfaccia come elencato nella ta- bella 5.5. Successivamente verrà chiesto di inserire la password di root del sistema, quella presente in LAB4 è visibile in tabella 5.6.
  55. 55. 5.3. Implementazione 41 Partizionamento dei Client GFS: Device Mount point File system Dimensione /dev/sda1 / ext3 78GB /dev/sda2 estesa 1024 /dev/sda3 swap 1024 Tabella 5.4: Partizionamento dei Client GFS: Settaggio sottorete: Nodo Nome IP Subnet mask gndb1 gnbd1.lab4cluster 192.168.4.254 255.255.255.0 node1 node1.lab4cluster 192.168.4.1 255.255.255.0 node2 node2.lab4cluster 192.168.4.2 255.255.255.0 Tabella 5.5: Settaggio sottorete: – Passo 2.3) Fine dell’installazione: Una volta completata l’installazio- ne il sistema si riavvia, una volta eseguito il reboot una seconda fase di installazione segue chiedendo la registrazione di un utente principale, per poi permettere di effettuare il login. La lista degli utenti e degli am- ministratori del sistema e le relative password installate correntemente nel LAB4 è presente in tabella 5.6 Utenti del sistema: Utente Password root piripicchio pikkio ncc1701d Tabella 5.6: Utenti del sistema: • Passo 3: Modifica dei file di sistema. Per permettere il corretto funziona- mento della cluster suite, è necessario modificare il file di sistema /etc/hosts, in particolare nella riga riguardante l’indirizzo di loopback, dove inserisco l’indirizzo di broadcast della sottorete oltre ad aggiungere come know hosts gli indirizzi e gli alias degli altri nodi componenti il cluster: # Do not remove the following line, or various programs # that require network functionality will fail. 192.168.4.255 localhost.localdomain localhost localhost 192.168.4.254 gnbd1.lab4cluster gnbd1 gnbd1 192.168.4.1 node1.lab4cluster node1 node1 192.168.4.2 node2.lab4cluster node2 node2
  56. 56. 42 Implementazione in laboratorio • Passo 4: Genereazione ed installazione delle chiavi pubbliche. Questo passaggio non è strettamente necessario alla fine della realizzazione dell’in- frastruttura cluster, ma torna di estrema utilità nel caso dell’uso del tool di configurazione grafico GFS Deployment Tool, e per la gestione dell’installa- zione del software dai pacchetti .rpm da uno solo dei nodi del cluster. Que- sta procedura permetterà il login tramite Secure SHell (SSH) senza digitare ogni volta la password della macchina target essendoci registrati come uten- ti autorizzati. La generazione delle chiavi pubbliche prevede una serie di comandi: – Passo 4.1: Generazione coppia chiavi. Dal nodo da cui voglio eseguire le shell remote, ad esempio il server GNBD, genero una coppia di chiavi tramite il comando ssh-keygen specificando l’algoritmo di criptazione RSA. – Passo 4.2: Installazione delle chiavi. Una volta generata la chiave la installo tramite SSH sui nodi del cluster. – Passo 4.3: Login senza pasword. A questo punto è possibile loggar- si ad uno dei due nodi del cluster dal GNBD server senza digitare la password di login: [root@gnbd1 ~] ssh-keygen -t rsa Generating public/private rsa key pair. Entering file in wich to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your Identification has been saved in /root/.ssh/id_rsa. Your public key has neen saved in /root/.ssh/id_rsa.pub. The key fingerprint is: ea:c5:f8:32:b8:ff:3a:2e:5d:a8:b7:85:12:69:ea:a7 root@gnbd1.lab4cluster [root@gnbd1 ~] cat /root/.ssh/id_rsa.pub | ssh node1 ’mkdir -p /root/.ssh/; cat >> /root/.ssh/authorized_keys’ root@node1’s password: [root@gnbd1 ~] cat /root/.ssh/id_rsa.pub | ssh node2 ’mkdir -p /root/.ssh/; cat >> /root/.ssh/authorized_keys’ root@node2’s password: [root@gnbd1 ~] ssh node1 [root@node1 ~] exit node1 session closed. [root@gnbd1 ~] ssh node2 [root@node2 ~] exit node2 session closed.
  57. 57. 5.3. Implementazione 43 • Passo 5: Creazione del file cluster.conf. A questo punto è necessario creare il file di configurazione, in formato XML, del cluster. Questa procedu- ra può essere eseguita tramite il tool grafico di Cluster Management contenuto nel pacchetto system-config-cluster o manualmente con un banale edi- tor di testo rispettando però la struttura sintattica del documento XML. Il file deve essere posto nella cartella /etc/cluster/cluster.conf che va creata se non esiste e va copiato nella sua forma definitiva su tutti i nodi del clu- ster. A seguito è mostrato il file cluster.conf della implementazione in laboratorio: <?xml version="1.0"?> <cluster alias="lab4cluster" config_version="4" name="114890487422"> <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/> <clusternodes> <clusternode name="node1" votes="1"> <fence> <method name="1"> <device name="manual" nodename="node1"/> </method> </fence> </clusternode> <clusternode name="node2" votes="1"> <fence> <method name="1"> <device name="manual" nodename="node2"/> </method> </fence> </clusternode> <clusternode name="gnbd1" votes="1"> <fence> <method name="1"> <device name="manual" nodename="gnbd1"/> </method> </fence> </clusternode> </clusternodes> <cman/> <fencedevices> <fencedevice agent="fence_manual" name="manual"/> </fencedevices> <rm> <failoverdomains> <failoverdomain name="lab4faildomain" ordered="0" restricted="1"> <failoverdomainnode name="node1" priority="1"/> <failoverdomainnode name="node2" priority="1"/> <failoverdomainnode name="gnbd1" priority="1"/> </failoverdomain> </failoverdomains> <resources/> </rm> </cluster>
  58. 58. 44 Implementazione in laboratorio • Passo 6: Settaggio dei servizi all’avvio. La gerarchia e la comunicazione all’interno del cluster è gestita da numerosi servizi che all’avvio del siste- ma comunicano tra loro interscambiando informazioni sullo stato dei nodi e dei servizi su di loro attivi. Questi vanno settati affinchè all’avvio del siste- ma vengano lanciati in automatico all’esecuzione del runlevel. I servizi che devono essere caricati all’avvio sono: – Il demone ccsd – Il servizio cman – Il demone fenced – Il demone clvmd – Il servizio gfs – Il servizio rgmanager In Fedora Core release 4, per settare un servizio in avvio automatico al cor- rente runlevel, è possibile eseguire il comando chkconfig <servizio> on, che equivale a settare nel menù servizi di sistema l’avvio automatico del servi- zio. Con questo comando, o dal menù, settiamo ad on i servizi sopra elencati. Questa operazione va effettuata su tutti i nodi del cluster, per quanto riguarda il servizio gfs*, solo sui nodi GFS. chkconfig ccsd on chkconfig cman on chkconfig fenced on chkconfig clvmd on chkconfig gfs on * chkconfig rgmanager on • Passo 7: Riavvio del sistema. Procedo al riavvio dei nodi del cluster. Al riavvio del sistema nella finestra in cui sono elencati i servizi in esecuzione nel runlevel, vedo apparire i servizi settati in precedenza (ccsd, cman, fenced, clvmd, gfs e rgmanager) che, se non vi sono stati errori nel settaggio al passo precedente, partono correttamente segnalando il loro stato con i caratteri di [ OK ] • Passo 8: Verifica del cluster. Per verificare la riuscita implementazione del cluster è possibile, oltre ad aver avuto conferma del corretto avvio dei servizi, eseguire il tool di gestione o Cluster Management da cui è possibile gestire e monitorare l’attività dei nodi e dei relativi servizi. Come mostrato in figura 5.6 la struttura del cluster è ben definita nella prima finestra, dove appaio- no i nodes del cluster (node1, node2 e gnbd1), il fence device (manual) e il
  59. 59. 5.3. Implementazione 45 failover domain (lab4failover). Da qualsiasi nodo è possibile lanciare il Clu- ster Manager e modificare la configurazione aggiungendo/eliminando nodi, dispositivi di fence e domini di failover oltre ad aggiungere risorse e servi- zi. Una volta modificata la struttura, le modifiche vengono trascritte nel file /etc/cluster/cluster.conf della macchina locale e tramite il pulsante send to cluster è possibile trasmettere la nuova configurazione a tutte le mac- chine facenti parte del cluster. Nella seconda finestra è possibile visualizzare lo stato corrente del cluster con i nodi membri e l’elenco dei servizi attivi su di essi. Figura 5.6: Il tool Cluster Manager

×