Cluster Management · 8 min read · Jan 30, 2026
Gestione del Cluster Xen con Ganeti su Debian Lenny
Gestione del Cluster Xen con Ganeti su Debian Lenny
Versione 1.0
Autore: Falko Timme
Ganeti è un sistema di gestione della virtualizzazione dei cluster basato su Xen. In questo tutorial spiegherò come creare una macchina virtuale Xen (chiamata un’istanza) su un cluster di due nodi fisici e come gestire e fare il failover di questa istanza tra i due nodi fisici.
Questo documento viene fornito senza alcuna garanzia! Non rilascio alcuna garanzia che questo funzionerà per te!
[Aggiornamento 21/01/2010] Ho ricevuto un messaggio dal team di sviluppo di Ganeti:
“ […] Negli ultimi mesi abbiamo notato il triste fatto che le persone cercano di seguire le tue istruzioni alla lettera e finiscono per installare versioni vecchie o molto vecchie di Ganeti. Potresti per favore aggiornare entrambi i tutorial con note che dicono che non sono aggiornati per versioni più recenti di Ganeti e chiedere alle persone di consultare la documentazione aggiornata su http://docs.ganeti.org/ganeti/? “
Questo tutorial si basa su una vecchia versione di Ganeti. Si prega di fare riferimento alla documentazione aggiornata su http://docs.ganeti.org/ganeti/.
1 Nota Preliminare
In questo tutorial utilizzerò i nodi fisici node1.example.com e node2.example.com:
- node1.example.com: indirizzo IP 192.168.0.100; sarà il master del cluster.
- node2.example.com: indirizzo IP 192.168.0.101; sarà il nodo primario della macchina virtuale (alias istanza).
Entrambi hanno un disco rigido da 500GB di cui utilizzo 20GB per la partizione /, 1GB per lo swap e lascio il resto non partizionato in modo che possa essere utilizzato da Ganeti (il minimo è 20GB!). Naturalmente, puoi cambiare la partizione a tuo piacimento, ma ricorda lo spazio minimo non utilizzato.
Il cluster che andrò a creare sarà chiamato cluster1.example.com e avrà l’indirizzo IP 192.168.0.102. L’IP del cluster 192.168.0.102 sarà sempre legato al master del cluster, quindi anche se non sai quale nodo è il master, puoi utilizzare l’IP del cluster (o il nome host cluster1.example.com) per connetterti al master utilizzando SSH.
La macchina virtuale Xen (chiamata un’istanza nel linguaggio di Ganeti) sarà chiamata inst1.example.com con l’indirizzo IP 192.168.0.105. inst1.example.com sarà replicata tra i due nodi fisici utilizzando DRBD - puoi vedere questo come una sorta di RAID1 di rete.
Come puoi vedere, node1.example.com sarà il master del cluster, cioè la macchina da cui puoi controllare e gestire il cluster, e node2.example.com sarà il nodo primario di inst1.example.com, cioè inst1.example.com verrà eseguita su node2.example.com (con tutte le modifiche su inst1.example.com replicate su node1.example.com con DRBD) fino a quando non verrà trasferita a node1.example.com (se desideri spegnere node2.example.com per manutenzione, ad esempio). Questa è una configurazione attiva-passiva.
Penso sia buona pratica suddividere i ruoli tra i due nodi, in modo da non perdere il master del cluster e il nodo primario contemporaneamente se uno dei nodi si guasta.
È importante che tutti i nomi host menzionati qui siano risolvibili da tutti gli host, il che significa che devono esistere in DNS, oppure devi inserire tutti i nomi host in tutti i file /etc/hosts su tutti gli host (cosa che farò qui).
Tutti i nodi del cluster devono utilizzare la stessa interfaccia di rete (ad es. eth0). Se un nodo utilizza eth0 e l’altro eth1, Ganeti non funzionerà correttamente.
Ok, iniziamo…
2 Preparazione Dei Nodi Fisici
node1:
Voglio che node1 abbia l’indirizzo IP statico 192.168.0.100, quindi il mio file /etc/network/interfaces appare come segue (si prega di notare che sostituisco allow-hotplug eth0 con auto eth0; altrimenti il riavvio della rete non funziona e dovremmo riavviare l’intero sistema):
vi /etc/network/interfaces| # L'interfaccia di rete di loopback auto lo iface lo inet loopback # L'interfaccia di rete primaria #allow-hotplug eth0 #iface eth0 inet dhcp auto eth0 iface eth0 inet static address 192.168.0.100 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.1 |
Se hai modificato il file, riavvia la tua rete:
/etc/init.d/networking restartPoi modifica /etc/hosts. Fai in modo che appaia così:
vi /etc/hosts| 127.0.0.1 localhost.localdomain localhost 192.168.0.100 node1.example.com node1 192.168.0.101 node2.example.com node2 192.168.0.102 cluster1.example.com cluster1 192.168.0.105 inst1.example.com inst1 # Le seguenti righe sono desiderabili per host compatibili con IPv6 ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts |
Successivamente dobbiamo assicurarci che i comandi
hostnamee
hostname -fstampino il nome host completo (node1.example.com). Se ottieni qualcosa di diverso (ad es. solo node1), fai questo:
echo node1.example.com > /etc/hostname
/etc/init.d/hostname.sh startDopo, i comandi hostname dovrebbero mostrare il nome host completo.
Poi aggiorna il sistema:
aptitude updateaptitude safe-upgradenode2:
Ora facciamo lo stesso su node2.example.com (si prega di tenere a mente che node2 ha un IP diverso!):
vi /etc/network/interfaces| # L'interfaccia di rete di loopback auto lo iface lo inet loopback # L'interfaccia di rete primaria #allow-hotplug eth0 #iface eth0 inet dhcp auto eth0 iface eth0 inet static address 192.168.0.101 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.1 |
/etc/init.d/networking restartvi /etc/hosts| 127.0.0.1 localhost.localdomain localhost 192.168.0.100 node1.example.com node1 192.168.0.101 node2.example.com node2 192.168.0.102 cluster1.example.com cluster1 192.168.0.105 inst1.example.com inst1 # Le seguenti righe sono desiderabili per host compatibili con IPv6 ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts |
echo node2.example.com > /etc/hostname
/etc/init.d/hostname.sh startaptitude updateaptitude safe-upgrade3 Configurazione di LVM Sulla Spazio HDD Libero
node1/node2:
Scopriamo di più sul nostro disco rigido:
fdisk -lnode1:~# fdisk -l
Disco /dev/sda: 500.1 GB, 500107862016 byte
255 teste, 63 settori/traccia, 60801 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificatore disco: 0x00023cd1
Dispositivo Avvio Inizio Fine Blocchi Id Sistema
/dev/sda1 * 1 62 497983+ 83 Linux
/dev/sda2 63 6141 48829567+ 8e Linux LVM
node1:~#Ora creeremo la partizione /dev/sda3 (su entrambi i nodi fisici) utilizzando il resto del disco rigido e la prepareremo per LVM:
fdisk /dev/sdanode1:~# fdisk /dev/sda
Il numero di cilindri per questo disco è impostato su 60801.
Non c’è nulla di sbagliato in questo, ma è più grande di 1024,
e potrebbe in alcune configurazioni causare problemi con:
- software che gira all’avvio
(e.g., vecchie versioni di LILO) - software di avvio e partizionamento
proveniente da altri OS
(e.g., DOS FDISK, OS/2 FDISK)
Comando (m per aiuto): <– n
Comando azione
e esteso
p partizione primaria (1-4)
<– p
Numero partizione (1-4): <– 3
Primo cilindro (6142-60801, default 6142): <– ENTER
Utilizzando il valore predefinito 6142
Ultimo cilindro o +dimensione o +dimensioneM o +dimensioneK (6142-60801, default 60801): <– ENTER
Utilizzando il valore predefinito 60801
Comando (m per aiuto): <– t
Numero partizione (1-4): <– 3
Codice esadecimale (tipo L per elencare i codici): <– L
0 Vuoto 1e Hidden W95 FAT1 80 Vecchio Minix be Solaris avvio
1 FAT12 24 NEC DOS 81 Minix / vecchio Lin bf Solaris
2 XENIX root 39 Plan 9 82 Linux swap / So c1 DRDOS/sec (FAT-
3 XENIX usr 3c PartitionMagic 83 Linux c4 DRDOS/sec (FAT-
4 FAT16 <32M 40 Venix 80286 84 OS/2 nascosto C: c6 DRDOS/sec (FAT-
5 Esteso 41 PPC PReP Boot 85 Linux esteso c7 Syrinx
6 FAT16 42 SFS 86 NTFS volume set da Non-FS data
7 HPFS/NTFS 4d QNX4.x 87 NTFS volume set db CP/M / CTOS / .
8 AIX 4e QNX4.x 2nd part 88 Linux plaintext de Dell Utility
9 AIX avviabile 4f QNX4.x 3rd part 8e Linux LVM df BootIt
a OS/2 Boot Manag 50 OnTrack DM 93 Amoeba e1 DOS access
b W95 FAT32 51 OnTrack DM6 Aux 94 Amoeba BBT e3 DOS R/O
c W95 FAT32 (LBA) 52 CP/M 9f BSD/OS e4 SpeedStor
e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a0 IBM Thinkpad hi eb BeOS fs
f W95 Ext’d (LBA) 54 OnTrackDM6 a5 FreeBSD ee EFI GPT
10 OPUS 55 EZ-Drive a6 OpenBSD ef EFI (FAT-12/16/
11 Hidden FAT12 56 Golden Bow a7 NeXTSTEP f0 Linux/PA-RISC b
12 Compaq diagnost 5c Priam Edisk a8 Darwin UFS f1 SpeedStor
14 Hidden FAT16 <3 61 SpeedStor a9 NetBSD f4 SpeedStor
16 Hidden FAT16 63 GNU HURD o Sys ab Darwin avvio f2 DOS secondario
17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fd Linux raid auto
18 AST SmartSleep 65 Novell Netware b8 BSDI swap fe LANstep
1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid ff BBT
1c Hidden W95 FAT3 75 PC/IX
Codice esadecimale (tipo L per elencare i codici): <– 8e
Tipo di sistema della partizione 3 cambiato in 8e (Linux LVM)
Comando (m per aiuto): <– w
La tabella delle partizioni è stata alterata!
Chiamando ioctl() per rileggere la tabella delle partizioni.
ATTENZIONE: Rileggere la tabella delle partizioni non è riuscito con errore 16: Dispositivo o risorsa occupata.
Il kernel utilizza ancora la vecchia tabella.
La nuova tabella sarà utilizzata al prossimo riavvio.
Sincronizzazione dischi.
node1:~#
Ora diamo un'occhiata al nostro disco rigido di nuovo:
fdisk -l
node1:~# fdisk -l
Disco /dev/sda: 500.1 GB, 500107862016 byte
255 teste, 63 settori/traccia, 60801 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificatore disco: 0x00023cd1
Dispositivo Avvio Inizio Fine Blocchi Id Sistema
/dev/sda1 * 1 62 497983+ 83 Linux
/dev/sda2 63 6141 48829567+ 8e Linux LVM
/dev/sda3 6142 60801 439056450 8e Linux LVM
node1:~#
Sembra buono. Ora dobbiamo riavviare entrambi i nodi fisici in modo che il kernel possa leggere la nuova tabella delle partizioni:
reboot
Dopo il riavvio, installiamo LVM (probabilmente è già installato, ma è meglio esserne certi):
aptitude install lvm2
Dopo il riavvio, prepariamo /dev/sda3 per LVM su entrambi i nodi e lo aggiungiamo al gruppo di volumi xenvg:
pvcreate /dev/sda3
vgcreate xenvg /dev/sda3
(Ganeti vuole utilizzare un gruppo di volumi di sua proprietà, ecco perché creiamo xenvg; teoricamente potremmo utilizzare un gruppo di volumi esistente con spazio non allocato sufficiente, ma il comando gnt-cluster verify si lamenterà di questo.)Ricevi i nuovi post nella tua casella di posta.
Nessuno spam. Disiscriviti in qualsiasi momento.