Oversubscription en vSphere – Memoria

Buenas a todos!

Vamos a repasar las técnicas que utiliza nuestros ESXi para reducir la cantidad de memoria física usada por nuestras VM:

Page Sharing. Es una técnica propietaria que permite compartir páginas de memoria entre diferentes máquinas virtuales de manera segura y transparente para nosotros. Por ejemplo: Si tenemos muchas VM con el mismo sistema operativo, habrá muchas páginas de memoria que serán “iguales”: Con esta técnica, los hosts ESXi comparte dichas páginas eliminando las páginas de memoria redundantes. Esta técnica se usa por defecto.

Ballooning. Para usar esta técnica, la VM debe de tener las VMWare Tools (Deberíais de tenerlas instaladas en todas vuestras máquinas). Mediante un módulo de las VMWare Tools, nuestros ESXi harán que la VM deseche las páginas de memoria que sean menos importantes. Esta técnica es utilizada por el ESXi cuando se va quedando con poca memoria libre y las VM van alcanzado el máximo de memoria asignada.

Memory compression. Si la VM llega a un nivel de uso de memoria en el que se requiere un swapping a nivel de host, el ESXi comprimirá páginas de memoria para tener que hacer un swap-out de una menor cantidad de ellas. ¿Porque hace esto? Porque la latencia de descomprimir una página de memoria es menos que la de hacer un swap-in.

Swap to host cache. Para usar esta técnica debemos tener algún datastore con discos SSD (De hecho, si los datastores no son de discos SSD, no aparecerán en la página de configuración del host cache). Esta técnica hace que que el ESXi use estos datastores para escribir archivos swap de las máquinas virtuales. Aunque el rendimiento se verá aumentado, esto no es lo mismo que usar un datastore SSD para almacenar los archivos regular swap de las VM, ya que estos se seguirán creando en el almacenamiento que tengamos configurado para ello.

Regular host-level swapping. Si no se ha configurado el host cache o si este se llena, los ESXi hará un swap-out de la memoria de las VM a un archivo regular swap. Al igual que con la técnica anterior, esto puede hacer que el ESXi haga un swap-out de páginas de memoria que se estén usando, pero al no tratarse de discos SSD (Lo normal es que sean discos SATA/SAS), la latencia se verá aumentada impactando negativamente en el rendimiento ofreció por nuestras VM.


Una vez vistas las técnicas que utiliza ESXi podemos observar que, al menos que tengamos muchas máquinas virtuales con el mismo sistema operativo, no deberíamos de abusar del overcommit con la memoria. De hecho, muchos expertos en virtualización aseguran que es una buena práctica no hacer overcommit de memoria en absoluto, y que en caso de hacerlo, este no debe sobrepasar nunca el 125% de la memoria física del host ESXi.

Al igual que con el ratio vCPU:pCPU, mucho de dependerá de la cantidad y el tipo de carga que tengan nuestras VM. Si es necesario podemos ir introduciendo VM en nuestro cluster e ir monitorizando tanto el ESXi como el rendimiento de las VM hasta que veamos que el rendimiento de las mismas se esta viendo afectado. ¿Que debemos de monitorizar? Según VMWare:

En la pestaña de rendimiento de la VM: Memory Balloon (Average), Consumed and active memory, Swap-in y Decompress.

  • Si el valor del memory balloon es nulo o pequeño, eso indica que la VM no está bajo una gran carga de uso de memoria.
  • Si el valor de la consumed memory es mayor que la active memory, esto es indicativo de que la máquina está usando la memoria que necesita para ofrecer su mejor rendimiento.
  • Si existe Swapping-in y decompressing, indica que la VM esta siendo sometida a carga en el uso de la memoria.

Espero que os haya parecido interesante!

Un saludo!

 

Oversubscription en vSphere – Ratio vCPU:pCPU

Para los que no sepan lo que quiere decir el título del post, y de una manera resumida, significa que cuantos vCPU podemos asignar en total a todas nuestras máquinas virtuales por cada host ESXi:

vCPU (Virtual CPU) : pCPU (Physical CPU)

Todos nos hemos hecho esta pregunta, pero la verdad es que no tiene una respuesta igual para todos. Muchos recomiendan no superar el ratio 1:1, otros dicen que ellos están usando un ratio 10:1, y VMware dice que vSphere (En la versión 5) soporta hasta un ratio de 25:1…¿Con cual nos quedamos?

La verdad es que esto depende del tipo de carga de trabajo al que estén sometidas nuestras VM, de si nuestros procesadores soportan o no HT (Hyper Threading), de como tengamos configurado nuestro entorno vSphere y nuestras VM…

En cuanto al HT, hay que entender, que aunque lo activemos (Si lo hacemos, el ESXi nos enseñará 2 procesadores lógicos por cada core físico), el rendimiento no aumenta en un 100%. Por ejemplo:

Tenemos 1 host ESXi con dos procesadores de 8 cores cada uno: Sin HT activado, el ESXi nos enseñara 16 procesadores lógicos pero si activamos, nos enseñará 32. Aunque pensemos que de 16 a 32 el rendimiento mejoraría el doble, la realidad es que mejora alrededor de un 20-30%.

Una vez aclarado esto, no nos queda más remedio que ir probando en nuestro entorno e ir introduciendo MV (Siempre siguiendo las buenas prácticas que escribiré en un post más adelante) y monitorizando el host ESXi (Sobre todo, y para esto, debemos fijarnos en el valor CPU Ready. Más adelante escribiré otro post acerca de esto.)

Según este whitepaper de Dell se pueden seguir las siguientes recomendaciones:

The following vCPU:pCPU guidelines are established:

  • 1:1 to 3:1 is no problem
  • 3:1 to 5:1 may begin to cause performance degradation
  • 6:1 or greater is often going to cause a problem
  • Additional guidance suggests that keeping the CPU Ready metric at 5% or below is considered a best practice.

Ahora, que cada uno saque sus propias conclusiones:)

¿Qué es VMWare VAAI?

VAAI (vStorage API for Array Integration) son un conjunto de API´s que permiten a los ESXi comunicarse con dispositivos de almacenamiento  descargando en los SP (Storage Processors) trabajo que de otro modo tendría que realizar el propio ESXi: Snapshots, Clonar VM, discos Eager/lazy zeroed, etc. Esto permite una importante reducción en el uso de la red de almacenamiento, siendo especialmente importante en entornos 1GB iSCSI.

Esta característica se introdujo en la versión 4.1 de vSphere pero solo soportaba SAN´s con tecnologías iSCSI y Fiber Channel. En las versión 5.1 se soportó VAAI en LUN´s NFS.

Para poder usarla esta característica se deben cumplir dos requisitos: Que nuestro dispositivo de almacenamiento la soporte (Hoy en día la inmensa mayoría de SAN´s la soportan) y que tengamos la licencia VMware necesaria para poder usarla.

Si queremos comprobar que dispositivos soportan VAAI, podemos verlo en la HCL (Hardware Compatibility List) de VMWare.

En cuanto a la licencia VMware, necesitaremos como mínimo la versión Standard (Novedad en vSphere 6.0). Podéis comprobarlo aquí. Los Kits Essential y Essential Plus no permiten el uso de estas API, aunque hay rumores que dicen que si instalamos una versión de prueba de 60 días (Enterprise Plus) y después le cambiamos la licencia a la Essential…VAAI sigue funcionando. No he podido comprobarlo personalmente: Hay gente que dice que sí sigue funcionando y otros que después de reiniciar el host ESXi se desactiva.

Pero lo que si tengo claro, es que en el caso de que siguiese funcionando estaríamos violando el apartado 3.1 de la EULA de VMWare, por lo que os dejo el link del artículo de la KB que indica como desactivarlo.

Si cumplís todos los requisitos, aquí tenéis el TechPaper.

Un saludo!

MailStore: Backup del correo electrónico

Recientemente he tenido un problema con mi proveedor de correo y he perdido correos electrónicos muy valiosos. Como lo tenía conigurado via IMAP y no tenía copia de seguridad ya que la hacía el propio proveedor de correo (Pensaba que para eso les pagaba, para que las hicieran ellos…) he intentado buscar un remedio para que no me vuelva a pasar.

Hay varios modos de hacer una copia de seguridad, pero he encontrado un programa que esta realmente bien. Permite hacer copias de seguridad de tu correo local, de un servidor pop, imap, exchange…o de todos a la vez. Te permite exportar de un proveedor a otro todo tu correo vía Imap, buscar en las copias de seguridad correos electrónicos y muchas cosas más. La configuración es super sencilla, ya que prácticamente es como configurar una cuenta de correo electrónico en cualquier cliente y hacer un doble click encima de la cuenta.

En fin, a lo mejor hay otras herramientas, pero a mí con esta me vale (Además es gratuita para uso personal…). Aquí os dejo el enlace: MailStore

Nagios en Debian Lenny

Hoy veremos como instalar y configurar Nagios de una manera básica en Debian Lenny.

Para instalarlo, bastará con un:

aptitude install nagios3

Nos vamos al directorio del Nagios:

cd /etc/nagios3

Creamos un login para entrar en Nagios e introducimos la contraseña:

htpasswd -c htpasswd.users nagiosadmin

Para probar, introducimos la IP de nuestro servidor seguido de nagios3 en la barra de direcciones y nos debería de salir algo parecido a esto:



Los archivos de configuración se encuentran en el directorio /etc/nagios3/conf.d. En el directorio /etc/nagios3 se encuentra un archivo de configuración (nagios.cfg) que de momento no vamos a tocar, ya que no es necesario para una configuración básica.

Vamos a centrarnos en los archivos que están en el directorio conf.d. El primero, contacts.cfg:

Aqui se le dice a Nagios a quien enviará emails, de que tipo, con que frecuencia, etc. Podemos crear grupos de usuarios para que reciban las mismas notificaciones. En este caso, solo creare un usuario y un grupo.

Ahora, voy a explicar del modo en que yo configuro Nagios. Seguro que los habrá mejores, pero a mi me funciona bien así. Vamos a configurar 3 archivos:

El primero, es el hosts.cfg. Si este archivo no existe, lo creamos. En el, vamos a introducir todos los hosts, dispositivos de red, etc. de los que queramos monitorizar algo. Soy partidario de organizar muy bien los archivos de texto, por lo que pongo etiquetas por grupos y demás. Un ejemplo de este archivo de configuración, podría ser el siguiente:

########################################

### DISPOSITIVOS DE RED ###

########################################

define host {

host_name Fortinet_Interna

alias Fortinet_Interna

address 192.168.1.1

use generic-host

}

define host {

host_name Fortinet_Externa

alias Fortinet_Interna

address 172.16.0.2

use generic-host

}

define host {

host_name Router_Ono_Interna

alias Router_Ono_Interna

address 172.16.0.1

use generic-host

}

define host {

host_name Switch1

alias Switch1

address 192.168.1.205

use generic-host

}

define host {

host_name Switch2

alias Switch2

address 192.168.1.206

use generic-host

}

define host {

host_name Switch3

alias Switch3

address 192.168.1.207

use generic-host

}

define host {

host_name Switch4

alias Switch4

address 192.168.1.208

use generic-host

}

define host {

host_name DiscoRed1

alias DiscoRed1

address 192.168.1.22

use generic-host

}

define host {

host_name DiscoRed2

alias DiscoRed2

address 192.168.1.240

use generic-host

}

define host {

host_name Centralita1

alias Centralita1

address 192.168.1.200

use generic-host

}

define host {

host_name Centralita2

alias Centralita2

address 192.168.1.201

use generic-host

}

define host {

host_name iLO-SRV*****

alias iLO-SRV*****

address 192.168.1.250

use generic-host

}

define host {

host_name iLO-ESXi1

alias iLO-ESXi1

address 192.168.1.251

use generic-host

}

define host {

host_name iLO-SRVW2008

alias iLO-SRVW2008

address 192.168.1.252

use generic-host

}

########################################

### SERVIDORES WINDOWS ###

########################################

define host {

host_name SRV*****

alias SRV*****

address 192.168.1.5

use generic-host

}

define host {

host_name vSRV*****

alias vSRV******

address 192.168.1.4

use generic-host

}

define host {

host_name vSRVApliWeb

alias vSRVApliWeb

address 192.168.1.47

use generic-host

}

########################################

### SERVIDORES DEBIAN ###

########################################

define host {

host_name vSRVDebian

alias vSRVDebian

address 127.0.0.1

use generic-host

}

define host {

host_name vSRVDebianWS1

alias vSRVDebianWS1

address 192.168.1.103

use generic-host

}

########################################

### SERVIDORES VMWARE ###

########################################

define host {

host_name ESXi1

alias ESXi1

address 192.168.1.14

use generic-host

}

El siguiente archivo es el hostgroups_nagios2.cfg. En este archivo vamos a agrupar todos los hosts dados de alta en el archivo anterior. A Nagios no le gusta que un host no esté dentro de un grupo (Nos mandará “Warnings”). Así que no se debe olvidar meter a todos los host en grupos. En mi caso el archivo ha quedado así:

########################################

### GRUPOS DISPOSITIVOS DE RED ###

########################################

define hostgroup {

hostgroup_name Dispositivos_Red

alias Dispositivos_Red

members Fortinet_Interna,Fortinet_Externa,Router_Ono_Interna,Centralita1,Centralita2,DiscoRed1,DiscoRed2,Switch1,Switch2,Switch3,Switch4,iLO-SRVAstarte,iLO-ESXi1,iLO-SRVW2008

}

########################################

### GRUPOS SERVIDORES WINDOWS ###

########################################

define hostgroup{

hostgroup_name Servidores_Windows ; The name of the hostgroup

alias Servidores Windows ; Long name of the group

members SRV*****,vSRV*****,vSRVApliWeb

}

########################################

### GRUPOS SERVIDORES DEBIAN ###

########################################

define hostgroup {

hostgroup_name Servidores_Debian

alias Servidores Debian GNU/Linux

members vSRVDebian, vSRVDebianWS1

}

########################################

### GRUPOS SERVIDORES WEB ###

########################################

define hostgroup {

hostgroup_name Servidores_Web

alias Servidores Web

members vSRVDebian, vSRVDebianWS1

}

########################################

### GRUPOS SERVIDORES VMWARE ###

########################################

define hostgroup {

hostgroup_name Servidores_VMWARE

alias Servidores VMWARE

members ESXi1

}

El último archivo a editar es el services_nagios2.cfg. En este, vamos a dar de alta todos los servicios que queramos que Nagios monitoree y le asignaremos los grupos de hosts a dichos servicios. Los servicios los he “copiado” del archivo /etc/nagios3/conf.d/localhost_nagios2.conf (Servicios a monitorear en máquinas Linux) y del archivo windows.cfg (Servicios a monitorear en máquinas Windows). Este último archivo lo he buscado con un updatedb + locate, porque no me acordaba de donde se encontraba. En mi caso, este archivo ha quedado así:

########################################

### SERVICIOS DISPOSITIVOS DE RED ###

########################################

define service {

hostgroup_name Dispositivos_Red

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES WINDOWS ###

########################################

define service{

hostgroup_name Servidores_Windows

service_description NSClient++ Version

check_command check_nt!CLIENTVERSION

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Tiempo Funcionando

check_command check_nt!UPTIME

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Rendimiento CPU

check_command check_nt!CPULOAD!-l 5,80,90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Uso de memoria

check_command check_nt!MEMUSE!-w 80 -c 90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Espacio en Unidad C

check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

#define service{

# hostgroup_name Servidores_Windows

# service_description W3SVC

# check_command check_nt!SERVICESTATE!-d SHOWALL -l W3SVC

# use generic-service

# notification_interval 0 ; set > 0 if you want to be renotified

# }

define service{

hostgroup_name Servidores_Windows

service_description Explorer

check_command check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES DEBIAN ###

########################################

define service {

hostgroup_name Servidores_Debian

service_description SSH

check_command check_ssh

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if

# < 10% free space on partition.

define service{

hostgroup_name Servidores_Debian

service_description Espacio en disco

check_command check_all_disks!20%!10%

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the number of currently logged in

# users on the local machine. Warning if > 20 users, critical

# if > 50 users.

define service{

hostgroup_name Servidores_Debian

service_description Usuarios Actuales

check_command check_users!20!50

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if

# > 400 processes.

define service{

hostgroup_name Servidores_Debian

service_description Procesos Totales

check_command check_procs!250!400

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the load on the local machine.

define service{

hostgroup_name Servidores_Debian

service_description Rendimiento CPU

check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES WEB ###

########################################

define service {

hostgroup_name Servidores_Web

service_description HTTP

check_command check_http

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES VMWARE ###

########################################

define service {

hostgroup_name Servidores_VMWARE

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

Ahora vamos a comprobar que la configuración que hemos introducido es correcta. Para ello:

nagios -v /etc/nagios3/nagios.cfg

Seguramente Nagios nos de algún error. Pero nos indica el archivo y línea en el que se encuentra, por lo que solo tendremos que ir y corregirlos. Habrá que repetir este proceso hasta que NAgios nos diga que no encuentra ningún error. Una vez conseguido, reiniciamos Nagios:

/etc/init.d/nagios3 restart

Si nos vamos a la interfaz web de Nagios e intentamos forzar un check de los servicios en todos los hosts, nos dará un error porque Nagios por defecto no ejecute comandos externos. El error en cuestión es el siguiente:

Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

Para arreglar esto, editamos el archivo /etc/nagios3/nagios.cfg y nos vamos a la línea donde se encuentra la directiva ‘check_external_commands’ y le ponemos un valor igual a 1, como en la imagen:

c3 external commands.png

Ejecutamos los siguientes comandos:

/etc/init.d/nagios3 stop

dpkg-statoverride —update —add nagios www-data 2710 /var/lib/nagios3/rw

dpkg-statoverride —update —add nagios nagios 751 /var/lib/nagios3

/etc/init.d/nagios3 start

Ahora ya deberá funcionar correctamente la interfaz web, le pidamos lo que le pidamos…
El siguiente paso es configurar el envío de correos electrónicos. En el primer archivo que editamos pusimos la configuración de los contactos a los que les tenía que llegar el correo y ahora vamos a configurar el envío de los mails. Hay varios modos de hacerlo (Con scripts de Perl, usando un servidor de correo local, un smarthost, etc.). En mi caso he instalado y configurado un Postfix en el propio servidor de Nagios para que mande los emails usando un servidor de correo externo.
Instalamos Postfix:

aptitude install postfix

Durante la instalación, le diremos que vamos a usar un SmartHost y le pondremos el nombre de nuestro servidor de correo. Por ejemplo: smtp.midominio.com
Una vez instalado, creamos el archivo /etc/postfix/sasl/passwd y le introducimos la siguiente información:

[smtp.tudominio.com]:25 tucuenta@tudominio.com:TuPassword

Guardamos el archivo y ahora le asignamos los permisos correspondientes:

chmod 600 /etc/postfix/sasl/passwd

Y por último lo transformamos en un fichero indexado de tipo hash con la ayuda de postmap:

postmap /etc/postfix/sasl/passwd

Reiniciamos Postfix (/etc/init.d/postfix restart) y para probar el envío ejecutamos:

mail -s “Prueba” tucorreo@tudominio.com

Debemos pulsar CTRL+D para que envíe

Y nos debería de llegar el correo…

Para monitorear equipos con Linux o dispositivos de red a los que solo queramos hacerle un ping, con esto será bastante. Pero como supongo que también habrá que controlar máquinas Windows, vamos a seguir con la configuración. Ahora vamos a editar el archivo /etc/nagios-plugins/config/nt.cfg y lo dejamos así:

# ‘check_nt’ command definition

define command{

command_name check_nt

command_line /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -p 12489 -s TuPassword -v $ARG1$ $ARG2$

}

Reiniciamos el Nagios para que valide los cambios y ahora vamos a configurar los equipos Windows. Para que Nagios recupere la información de estos equipos, vamos a instalarle un cliente llamado NSClient++. Lo podemos descargar de aquí. Como este cliente no es solo para Nagios, tendremos que hacer unos cuantos ajustes en su configuración para que funcione correctamente.

Durante la instalación, le diremos la IP del servidor Nagios, así como la contraseña que escribimos antes en el archivo /etc/nagios-plugins/config/nt.cfg. A la hora de seleccionar la ventana con los “checks”, marcaremos todos menos la última opción (WMI Checks…creo que se llamaba). Cuando nos pregunté si queremos iniciar el servicio, le decimos que NO.

Ahora deberemos seguir 5 pasos para terminar de configurar el cliente.

1. Nos vamos al administrador de servicios, buscamos el servicio del NSClient y le damos a ver sus propiedades. Debemos marcar la casilla que “Permite a los servicios interactuar con el escritorio”. Lo tenemos en la siguiente imagen:

Todavía NO inciamos el servicio. Sigamos.

El archivo de configuración se llama NSC.ini y se encuentra en el directorio donde hemos instalado el cliente (Normalmente en Archivos de Programa >> NSclient). Este archivo consta de varias secciones con distintas directivas en cada una. Vamos a seguir los 4 pasos restantes:

2. Dentro de la sección [Modules] vamos a descomentar todo, a excepción de las directivas ‘RemoteConfiguration.dll’ y ‘CheckWMI.dll’. También descomentamos la directiva ‘Password’ y le ponemos la contraseña que pusimos durante la instalación del cliente

3. Ahora, en la sección [Settings], descomentamos la directiva ‘allowed_host’ y le ponemos la IP del servidor Nagios.

4. En la sección [NSClient], descomentamos la directiva ‘port’, dejando el número de puerto establecido por defecto.

5. Por último, desde una ventana de MS-DOS, ejecutamos el comando: lodctr /R. Con este comando, aunque no es obligatorio, reiniciamos los contadores de rendimiento y demás, evitando errores como el de la siguiente imagen:

Pues ya hemos terminado. Ahora, si apuntamos a la interfaz web de Nagios y nos validamos, debería de aparecernos algo parecido a esto: (Variará según los equipos que hayáis dado de alta)

Leer más »

Backups con Bacula (II)

Bueno, continuemos. La primera parte del artículo esta aquí.

Una vez hecha la copia de seguridad de todos los archivos de configuración, vamos a instalar el paquete necesario para que Bacula use MySQL para guardar su base de datos.

Primero, instalemos el servidor MySQL:

aptitude install mysql-server

Durante la instalación, nos pedirá la contraseña del usuario root de MySQL y algunas cosas más.

Luego, instalaremos el paquete necesario para que Bacula use MySQL:

aptitude install bacula-director-mysql

A mi, personalmente, me gusta usar phpmyadmin para gestionar las bases de datos de MySQL. Para instalarlo:

aptitude install phpmyadmin

Una vez esté todo instalado, ya podemos empezar a configurar Bacula.

Lo primero que hago es saber donde voy a almacenar mis copias de seguridad. En mi caso, lo haré en un disco de red al que accederé montando una carpeta en Debian que apunta a un recurso compartido por el disco de red.

Para montar esa unidad, primero creo el directorio con el siguiente comando:

mkdir /mnt/bacula

Una vez creado, monto en ese diectorio la carpeta del disco de red con el siguiente comando:

mount -t smbfs -o usuario@dominio,password=Password //192.168.1.240/bacula /mnt/bacula

Lo probamos, y si funciona, creamos un script que contenga el comando anterior y lo copiamos en la carpeta /etc/init.d. Luego, ejecutamos el siguiente comando para que el script se ejecute siempre al arranque de nuestro sistema:

update-rc.d montar_carpetas_bacula.sh defaults

Aclaración: montar_carpetas_bacula.sh es el nombre que le he dado al script que he creado. Luego le di permisos 744 y de ejecución, antes de copiarlo a la carpeta /etc/init.d

Ahora, vamos a empezar a tocar los archivos de configuración de Bacula. Vamos a empezar por los más sencillos, pero antes debemos modificar unos parámetros del archivo principal. Para ello:

nano /etc/bacula/bacula-dir.conf

Aquí modificamos el nombre del demonio Director y le ponemos una IP (En este caso el propio ordenador) y le establecemos una contraseña.

Continuemos editando los archivos más sencillos. Nos vamos a editar el bconsole.conf:

Le ponemos el nombre y la contraseña del Director. Guardamos y salimos (Si usamos nano sería un CTRL+O y CTRL+X, respectivamente)

Ahora vamos a por el bacula-sd.conf:

En el punto 1, configuramos el nombre y la IP del propio demonio. En el 2, le ponemos los datos del Director. En el 3, ponemos los datos para el Tray Monitor (Ya lo veremos más adelante). En punto 4 es un ejemplo de un dispositivo donde guardar las copias de seguridad. (En nuestro caso, es un archivo). Si queremos guardar las copias de cada equipo/servidor en carpetas diferentes, deberemos crear un dispositivo por cada equipo/servidor.configuración

Continuamos con el bacula-fd.conf. La configuración es muy parecida al archivo anterior:

En el punto 1, configuramos los datos del director. En el 2, los del Tray Monitor. En el 3, el nombre y la IP del propio demonio y en el 4, la configuración de los envíos de alertas por email. Este archivo es el que tendremos que modificar en cada cliente del que hagamos copias de seguridad. Ya lo iremos viendo…

El archivo que nos queda por configurar, el bacula-dir.conf, es el principal. En el vamos a poner cuando se hacen las copias, de que clientes, que tipo de copias, etc. Voy a poner una breve descripción de cada apartado que configuraremos dentro de este archivo y un ejemplo de cada uno:

Director

En el configuraremos (Aunque ya lo hicimos anteriormente) los datos del propio demonio (Su IP, nombre, puerto a usar, etc.) En mi caso, la configuración quedó así:

Director { # define myself

Name = vSRVDebian-dir

DIRport = 9101 # where we listen for UA connections

QueryFile = “/etc/bacula/scripts/query.sql”

WorkingDirectory = “/var/lib/bacula”

PidDirectory = “/var/run/bacula”

Maximum Concurrent Jobs = 3

Password = “*****************” # Console password

Messages = Daemon

DirAddress = 127.0.0.1

}

Catalogo

Aquí vamos a definir los datos del Catálogo, que es la base de datos que usa Bacula. Pondremos el nombre de la base de datos, así como su usuario y contraseña. (Estos datos los pusimos cuando instalamos el paquete bacula-director-mysql). En mi caso queda así:

# Generic catalog service

Catalog {

Name = Catalogo

dbname = “bacula”; dbuser = “bacula”; dbpassword = “************”

}

Clientes (File Services)

En este apartado tendremos que “dar de alta” a todos los clientes de los que realizaremos copia de seguridad:

# Client (File Services) to backup

Client {

Name = vSRVDebianWS1-fd

Address = 192.168.1.103

FDPort = 9102

Catalog = Catalogo

Password = “*******************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

Client {

Name = vSRVApliWeb-fd

Address = 192.168.1.47

FDPort = 9102

Catalog = Catalogo

Password = “************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

Client {

Name = vSRVDebian-fd

Address = 192.168.1.115

FDPort = 9102

Catalog = Catalogo

Password = “**************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

JobDefs

En un Jobdef podemos tener las mismas directivas que un job (Tarea). Al crear un jobdef, no estamos creando una tarea, sino que estamos configurando una serie de directivas “por defecto” que podremos usar para configurar uno o varios jobs, ahorrándonos muchas líneas de configuración. Por ejemplo: Tenemos varios servidores Linux de los que deseamos hacer copias de seguridad completas. En vez de crear varios jobs con todas sus directivas en cada uno, creamos varios jobs a los que le decimos que se “alimenten” de las directivas del jobdef. Si repetimos una directiva en el job, que ya esté referenciada en el jobdef, Bacula usará la opción que hayamos puesto en el job.

JobDefs {

Name = “JD-vSRVDebianWS1”

Type = Backup

Level = Incremental

Client = vSRVDebianWS1-fd

FileSet = “LinuxCompleto”

Schedule = “CicloSemanal”

Storage = FS-vSRVDebianWS1

Messages = Standard

Pool = Pool-vSRVDebianWS1

Priority = 10

}

JobDefs {

Name = “JD-vSRVApliWeb”

Type = Backup

Level = Incremental

Client = vSRVApliWeb-fd

FileSet = “Alfresco”

Schedule = “CicloSemanal”

Storage = FS-vSRVApliWeb

Messages = Standard

Pool = Pool-vSRVApliWeb

Priority = 10

}

JobDefs {

Name = “JD-vSRVDebian”

Type = Backup

Level = Incremental

Client = vSRVDebian-fd

FileSet = “LinuxCompleto”

Schedule = “CicloSemanal”

Storage = FS-vSRVDebian

Messages = Standard

Pool = Pool-vSRVDebian

Priority = 10

}

Jobs

Los jobs son las “tareas” que deberá realizar Bacula. Pueden ser de backup, restauración, etc. Como dije antes, las tengo referenciadas a jobdefs.

# Define the main nightly save backup job

# By default, this job will back up to disk in /nonexistant/path/to/file/archive/dir

Job {

Name = “Backup-vSRVDebianWS1”

JobDefs = “JD-vSRVDebianWS1”

Write Bootstrap = “/mnt/bacula/vSRVDebianWS1/vSRVDebianWS1.bsr”

}

Job {

Name = “Backup-vSRVApliWeb”

JobDefs = “JD-vSRVApliWeb”

Write Bootstrap = “/mnt/bacula/vSRVApliWeb/vSRVApliWeb.bsr”

}

Job {

Name = “Backup-vSRVDebian”

JobDefs = “JD-vSRVDebian”

Write Bootstrap = “/mnt/bacula/vSRVDebian/vSRVDebian.bsr”

}

# Backup the catalog database (after the nightly save)

Job {

Name = “Backup-Catalog”

JobDefs = “JD-Catalogo”

# This creates an ASCII copy of the catalog

# WARNING!!! Passing the password via the command line is insecure.

# see comments in make_catalog_backup for details.

# Arguments to make_catalog_backup are:

# make_catalog_backup

RunBeforeJob = “/etc/bacula/scripts/make_catalog_backup bacula bacula ********* 127.0.0.1”

# This deletes the copy of the catalog

RunAfterJob = “/etc/bacula/scripts/delete_catalog_backup”

Write Bootstrap = “/var/lib/bacula/BackupCatalog.bsr”

Priority = 11 # run after main backup

}

#

# Standard Restore template, to be changed by Console program

# Only one such job is needed for all Jobs/Clients/Storage …

#

Job {

Name = “Restaurar-vSRVDebianWS1”

Type = Restore

Client=vSRVDebianWS1-fd

FileSet=”LinuxCompleto”

Storage = FS-vSRVDebianWS1

Pool = Pool-vSRVDebianWS1

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVDebianWS1

}

Job {

Name = “Restaurar-vSRVApliWeb”

Type = Restore

Client=vSRVApliWeb-fd

FileSet=”Alfresco”

Storage = FS-vSRVApliWeb

Pool = Pool-vSRVApliWeb

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVApliWeb

}

Job {

Name = “Restaurar-vSRVDebian”

Type = Restore

Client=vSRVDebian-fd

FileSet=”LinuxCompleto”

Storage = FS-vSRVDebian

Pool = Pool-vSRVDebian

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVDebian

}

Job {

Name = “Restaurar-Catalogo”

Type = Restore

Client=vSRVDebian-fd

FileSet=”Catalogo”

Storage = FS-Catalogo

Pool = Pool-Catalogo

Messages = Standard

Where = /mnt/bacula/restaurar/catalogo

}

Schedules

Los “schedules” son las programaciones horarias con las que se realizaran los trabajos. Yo he optado por dejar la que trae Bacula, ya que me parece buena para los servidores de los que tengo que realizar copias de seguridad. Por defecto, hace copias completas el primer domingo de cada mes, diferenciales el resto de domingos del mes e incrementales todos los demás días.

Schedule {

Name = “CicloSemanal”

Run = Full 1st sun at 02:00

Run = Differential 2nd-5th sun at 02:00

Run = Incremental mon-sat at 02:00

}

# This schedule does the catalog. It starts after the WeeklyCycle

Schedule {

Name = “CicloSemanalDespuesBackup”

Run = Full sun-sat at 23:10

}

Filesets

Los filesets son las listas de archivos de los que queremos hacer copias de seguridad. Aquí incluyo listas de ejemplo de servidores Linux y de servidores Windows.

# List of files to be backed up

FileSet {

Name = “LinuxCompleto”

Include {

Options {

signature = MD5

}

File = /

}

Exclude {

File = /proc

File = /tmp

File = /.journal

File = /.fsck

}

}

FileSet {

Name = “Alfresco”

Enable VSS = yes

Include {

Options {

signature = MD5

}

File = “C:/Alfresco”

}

}

FileSet {

Name = “Catalogo”

Include {

Options {

signature = MD5

}

}

File = /var/lib/bacula/bacula.sql

}

}

Storages

Aqui damos de alta los dispositivos que pusimos en el archivo bacula-sd.conf.

# Definition of file storage device

Storage {

Name = FS-vSRVDebianWS1

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVDebianWS1

Media Type = File

}

Storage {

Name = FS-vSRVApliWeb

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVApliWeb

Media Type = File

}

Storage {

Name = FS-vSRVDebian

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVDebian

Media Type = File

}

Storage {

Name = FS-Catalogo

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-Catalogo

Media Type = File

}

Pools

Un Pool es un “almacén” de volúmenes. Un volumen es un dispositivo donde Bacula almacenará las copias de seguridad (Una cinta, un archivo, un DVD, etc.). Los volúmenes no los creamos aquí, lo haremos posteriormente desde la consola de Bacula.

# Default pool definition

Pool {

Name = Pool-vSRVDebianWS1

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-vSRVApliWeb

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-vSRVDebian

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-Catalogo

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Emails

Esta es la última directiva que tendremos que configurar. Es la que nos permitirá enviar los emails a través de Bacula. Para ello, Bacula usa bsmtp. Con solo añadir nuestros servidor de correo electrónico e introducir las direcciones a las que queremos que lleguen los emails, estará todo listo.

# Reasonable message delivery — send most everything to email address

# and to the console

Messages {

Name = Standard

#

# NOTE! If you send to two email or more email addresses, you will need

# to replace the %r in the from field (-f part) with a single valid

# email address in both the mailcommand and the operatorcommand.

# What this does is, it sets the email address that emails would display

# in the FROM field, which is by default the same email as they’re being

# sent to. However, if you send email to more than one address, then

# you’ll have to set the FROM address manually, to a single address.

# for example, a ‘no-reply@mydomain.com’, is better since that tends to

# tell (most) people that its coming from an automated source.

#

mailcommand = “/usr/lib/bacula/bsmtp -h mail.tu-dominio.com -f \”\(Bacula\) \\” -s \”Bacula: %t %e of %c %l\” %r”

operatorcommand = “/usr/lib/bacula/bsmtp -h mail.tu-dominio.com -f \”\(Bacula\) \\” -s \”Bacula: Intervention needed for %j\” %r”

mail = alertas@tu-dominio.com = all, !skipped

operator = alertas@tu-dominio.com = mount

console = all, !skipped, !saved

#

# WARNING! the following will create a file that you must cycle from

# time to time as it will grow indefinitely. However, it will

# also keep all your messages if they scroll off the console.

#

append = “/var/lib/bacula/log” = all, !skipped

}

Una vez hecho esto, solo tendremos que reiniciar los demonios de Bacula e instalar los clientes en los equipos/Servidores que queramos. En los clientes, modificaremos en el archivo bacula-fd.conf y le pondremos los datos del demonio Director de Bacula.

Para probar todo, arrancamos la consola de bacula con el comando “bconsole”, creamos los volúmenes con el comando “label” y escribimos “run” desde dentro de esta consola. Nos saldrá una lista con todos nuestros trabajos y solo tendremos que elegir uno.

Si queremos comprobar el estado de los demonios de bacula, ejecutaremos el comando “status”.

Y, por último, para restaurar algo, o bien usamos las tareas de restauración que hemos creado, o bien ejecutamos el comando “restore”.

De este modo es como lo he configurado. Seguro que hay mejores modos de hacerlo, pero a mí de este me funciona bien. Una última cosa, tened siempre a mano una copia del catálogo de Bacula y los archivos bootstrap intentad ponerlos en un sitio que también tengáis a mano. Harán falta si queremos recuperarnos de un desastre.