Gestión de Clúster · 8 min read · Jan 30, 2026

Gestión de Clúster Xen Con Ganeti En Debian Lenny

Gestión de Clúster Xen Con Ganeti En Debian Lenny

Versión 1.0
Autor: Falko Timme

Ganeti es un sistema de gestión de virtualización de clúster basado en Xen. En este tutorial explicaré cómo crear una máquina virtual Xen (llamada instancia) en un clúster de dos nodos físicos, y cómo gestionar y hacer failover de esta instancia entre los dos nodos físicos.

¡Este documento se proporciona sin garantía de ningún tipo! No emito ninguna garantía de que esto funcione para ti.

[Actualización 21/01/2010] Recibí un mensaje del equipo de desarrollo de Ganeti:

[…] En los últimos meses hemos notado el desafortunado hecho de que las personas intentan seguir tus instrucciones al pie de la letra y terminan instalando versiones antiguas o muy antiguas de Ganeti. ¿Podrías actualizar ambos tutoriales con notas que digan que no están actualizados para versiones más recientes de Ganeti y pedir a las personas que consulten la documentación actualizada en http://docs.ganeti.org/ganeti/?

Este tutorial se basa en una versión antigua de Ganeti. Por favor, consulta la documentación actualizada en http://docs.ganeti.org/ganeti/.

1 Nota Preliminar

En este tutorial utilizaré los nodos físicos node1.example.com y node2.example.com:

  • node1.example.com: dirección IP 192.168.0.100; será el maestro del clúster.
  • node2.example.com: dirección IP 192.168.0.101; será el nodo primario de la máquina virtual (también conocida como instancia).

Ambos tienen un disco duro de 500GB de los cuales uso 20GB para la partición /, 1GB para swap, y dejo el resto sin particionar para que pueda ser utilizado por Ganeti (¡el mínimo es 20GB!). Por supuesto, puedes cambiar la partición a tu gusto, pero recuerda el espacio mínimo no utilizado.

El clúster que voy a crear se llamará cluster1.example.com, y tendrá la dirección IP 192.168.0.102. La IP del clúster 192.168.0.102 siempre estará vinculada al maestro del clúster, así que incluso si no sabes qué nodo es el maestro, puedes usar la IP del clúster (o el nombre de host cluster1.example.com) para conectarte al maestro usando SSH.

La máquina virtual Xen (llamada instancia en el lenguaje de Ganeti) se llamará inst1.example.com con la dirección IP 192.168.0.105. inst1.example.com será reflejada entre los dos nodos físicos usando DRBD - puedes ver esto como una especie de RAID1 en red.

Como ves, node1.example.com será el maestro del clúster, es decir, la máquina desde la cual puedes controlar y gestionar el clúster, y node2.example.com será el nodo primario de inst1.example.com, es decir, inst1.example.com se ejecutará en node2.example.com (con todos los cambios en inst1.example.com reflejados de vuelta a node1.example.com con DRBD) hasta que lo transfieras a node1.example.com (si deseas apagar node2.example.com para mantenimiento, por ejemplo). Esta es una configuración activa-pasiva.

Creo que es una buena práctica dividir los roles entre los dos nodos, para que no pierdas el maestro del clúster y el nodo primario a la vez si un nodo falla.

Es importante que todos los nombres de host mencionados aquí sean resolubles para todos los hosts, lo que significa que deben existir en DNS, o debes poner todos los nombres de host en todos los archivos /etc/hosts en todos los hosts (que es lo que haré aquí).

Todos los nodos del clúster deben usar la misma interfaz de red (por ejemplo, eth0). Si un nodo usa eth0 y el otro eth1, entonces Ganeti no funcionará correctamente.

Ok, empecemos…

2 Preparando Los Nodos Físicos

node1:

Quiero que node1 tenga la dirección IP estática 192.168.0.100, por lo tanto, mi archivo /etc/network/interfaces se ve como sigue (ten en cuenta que reemplazo allow-hotplug eth0 con auto eth0; de lo contrario, reiniciar la red no funciona, y tendríamos que reiniciar todo el sistema):

vi /etc/network/interfaces

| # La interfaz de red de loopback auto lo iface lo inet loopback # La interfaz de red 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 |

Si has modificado el archivo, reinicia tu red:

/etc/init.d/networking restart

Luego edita /etc/hosts. Haz que se vea así:

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 # Las siguientes líneas son deseables para hosts compatibles 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 |

A continuación, debemos asegurarnos de que los comandos

hostname

y

hostname -f

impriman el nombre de host completo (node1.example.com). Si obtienes algo diferente (por ejemplo, solo node1), haz esto:

echo node1.example.com > /etc/hostname  
/etc/init.d/hostname.sh start

Después, los comandos de nombre de host deberían mostrar el nombre de host completo.

Luego actualiza el sistema:

aptitude update
aptitude safe-upgrade

node2:

Ahora hacemos lo mismo en node2.example.com (ten en cuenta que node2 tiene una IP diferente):

vi /etc/network/interfaces

| # La interfaz de red de loopback auto lo iface lo inet loopback # La interfaz de red 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 restart
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 # Las siguientes líneas son deseables para hosts compatibles 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 start
aptitude update
aptitude safe-upgrade

3 Configurando LVM En El Espacio Libre Del HDD

node1/node2:

Vamos a averiguar sobre nuestro disco duro:

fdisk -l
node1:~# fdisk -l  

Disco /dev/sda: 500.1 GB, 500107862016 bytes  
255 heads, 63 sectors/track, 60801 cylinders  
Units = cylinders of 16065 * 512 = 8225280 bytes  
Identificador del disco: 0x00023cd1  

   Dispositivo Boot      Start         End      Blocks   Id  System  
/dev/sda1   *           1          62      497983+  83  Linux  
/dev/sda2              63        6141    48829567+  8e  Linux LVM  
node1:~#

Ahora crearemos la partición /dev/sda3 (en ambos nodos físicos) usando el resto del disco duro y la prepararemos para LVM:

fdisk /dev/sda

node1:~# fdisk /dev/sda

El número de cilindros para este disco está configurado en 60801.
No hay nada de malo en eso, pero esto es más grande que 1024,
y podría en ciertas configuraciones causar problemas con:

  1. software que se ejecuta en el momento del arranque (por ejemplo, versiones antiguas de LILO)
  2. software de arranque y particionamiento de otros SOs
    (por ejemplo, DOS FDISK, OS/2 FDISK)

Comando (m para ayuda): <– n
Acción del comando
e extended
p primary partition (1-4)
<– p
Número de partición (1-4): <– 3
Primer cilindro (6142-60801, valor predeterminado 6142): <– ENTER
Usando el valor predeterminado 6142
Último cilindro o +size o +sizeM o +sizeK (6142-60801, valor predeterminado 60801): <– ENTER
Usando el valor predeterminado 60801

Comando (m para ayuda): <– t
Número de partición (1-4): <– 3
Código hexadecimal (tipo L para listar códigos): <– L

0 Empty 1e Hidden W95 FAT1 80 Old Minix be Solaris boot
1 FAT12 24 NEC DOS 81 Minix / old 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 hidden C: c6 DRDOS/sec (FAT-
5 Extended 41 PPC PReP Boot 85 Linux extended 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 bootable 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 or Sys ab Darwin boot f2 DOS secondary
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
Código hexadecimal (tipo L para listar códigos): <– 8e
Cambiado el tipo de sistema de la partición 3 a 8e (Linux LVM)

Comando (m para ayuda): <– w
¡La tabla de particiones ha sido alterada!

Llamando a ioctl() para volver a leer la tabla de particiones.

ADVERTENCIA: Volver a leer la tabla de particiones falló con error 16: Dispositivo o recurso ocupado.
El núcleo todavía usa la tabla antigua.
La nueva tabla se usará en el próximo reinicio.
Sincronizando discos.
node1:~#


Ahora echemos un vistazo a nuestro disco duro nuevamente:

fdisk -l

node1:~# fdisk -l

Disco /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Identificador del disco: 0x00023cd1

Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 1 62 497983+ 83 Linux
/dev/sda2 63 6141 48829567+ 8e Linux LVM
/dev/sda3 6142 60801 439056450 8e Linux LVM
node1:~#


Se ve bien. Ahora debemos reiniciar ambos nodos físicos para que el núcleo pueda leer la nueva tabla de particiones:

reboot


Después del reinicio, instalamos LVM (probablemente ya esté instalado, pero es mejor asegurarse):

aptitude install lvm2


Después del reinicio, preparamos /dev/sda3 para LVM en ambos nodos y lo añadimos al grupo de volúmenes xenvg:

pvcreate /dev/sda3
vgcreate xenvg /dev/sda3


(Ganeti quiere usar un grupo de volúmenes propio, por eso creamos xenvg; teóricamente podríamos usar un grupo de volúmenes existente con suficiente espacio no asignado, pero el comando gnt-cluster verify se quejará de esto.)
Share: X/Twitter LinkedIn

Recibe nuevas publicaciones en tu bandeja de entrada.

No spam. Cancela la suscripción en cualquier momento.