Proxmox migrar máquinas con mountpoints locales

Tengo 2 contenedores LXC que comparten un directorio con ficheros de configuración que está sobre glusterfs y está montado en local a todos los nodos. El otro día al tratar de migrar las máquinas me decía que no podía migrar las máquinas porque algo no le gustaba del mountpoint. Es una puñeta porque si se para el nodo en el que se encuentra el contenedor por algún motivo, el HA fallará por no poder migrar el contenedor a otro nodo.
El otro día traté de añadir el mountpoint local desde la interfaz de proxmox y no daba la opción. Hoy tonteando en los foros de proxmox he encontrado la solución.

En los contenedores, había configurado a mano el mountpoint. Para ello, paramos el contenedor y nos vamos al nodo en el que se encuentra en aquel momento cada uno de los contenedores y editamos el fichero de configuración que se encuentra en /etc/pve/lxc/

root@planet1B:/etc/pve/lxc# vi 106.conf
mp0: /mnt/gluster/gvol1/nginx,mp=/mnt/conf-nginx,shared=1

El secreto para poder migrar los contenedores con el mountpoint, es añadirle “shared=1” y el directorio tiene que estar en todos los nodos.

Aquí una capturilla de pantalla de como queda en proxmox

Cambiar la red de ceph

El sábado hice un taller en vivo sobre proxmox en el que enseñé a configurar tanto ceph como glusterfs.

Aquí el vídeo sólo de la parte de la entrevista:

Instalar proxmox es super fácil, pero preparar bien el entorno ya es otra cosa. Al prepararlo cometí un fallo de diseño al reutilitzar configuración antigua.

Tal como dije, se recomienda destinar una red específicamente para la comunicación de los ceph. Así que vamos a ello.

El contenido de mi fichero de configuración de red es el siguiente

# vi /etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.139.39.166/27
        gateway 10.139.39.161
        bridge_ports eth0.10
        bridge_stp off
        bridge_fd 0

auto vmbr1
iface vmbr1 inet static
        address 172.31.0.11
        netmask 255.255.0.0
        bridge_ports eth0.1000
        bridge_stp off
        bridge_fd 0
        post-up echo 1 /proc/sys/net/ipv4/ip_forward

auto vmbr2
iface vmbr2 inet manual
        bridge_ports eth0.1001
        bridge_stp off
        bridge_fd 0


# ceph - glusterfs # dades
iface eth1 inet manual

auto vmbr11
iface vmbr11 inet static
        address 192.168.10.1/24
        bridge-ports eth1
        bridge-stp off
        bridge-fd 0

He cambiado los bridge_ports tanto de vmbr1 como de vmbr2 y añadido el bridge vmbr11 sin vlans y con la red 192.168.10.0/24.

He aplicado la configuración correspondiente a cada nodo del cluster y los he reiniciado.

Una vez iniciados de nuevo y comprobado que lleguen los servidores entre ellos por la red 192.168.10.0/24, he ido al fichero de configuración del ceph (/etc/pve/ceph.conf) y he cambiado el parámetro cluster_network

# vi /etc/pve/ceph.conf
[global]
         auth_client_required = cephx
         auth_cluster_required = cephx
         auth_service_required 

CephFS: Montar ceph en local con Proxmox

Telita las vueltas que he dado para encontrar esta solución y todo por no fijarme bien!

Muy bien, partimos de que tenemos un Ceph funcionando correctamente y lo estamos usando para poner ahí nuestros contenedores y máquinas virtuales. Pero al hacer el backup nos interesa los datos pesados dejarlos fuera y tener un disco compartido en red es algo que es una maravilla para poder migrar libremente maquinas de un nodo a otro y además de forma muy rápida ya que no tiene que copiar los datos.

Hace días que me pregunto, ¿y cómo se hace para montar un pool de ceph como mountpoint para los datos mas pesados? Había buscado donde se montaban los datos, nada de nada, si proxmox daba alguna opción, no se daba la opción de montar ceph como mountpoint ni tampoco te deja usar este pool para hacer backups. Así que llevo con la mosca en la nariz unos días con este tema… hasta que hoy! tras instalar un nuevo cluster y poder jugar (sin romper) una instalación nueva me he puesto a mirar a fondo y tras unas horitas, al clavo!

Ceph lleva bastante tiempo en marcha y hay documentación de hace 4 años, además ha ido evolucionando muy rápido y en las últimas versiones han cambiado incluso de tecnología para escribir a disco, siendo bluestore la actual.

Tras muchas formas de hacerlo (desde el kernel, desde fstab, que crear el volumen a mano desde el servidor, etc.), ninguna me parecía muy fiable …

Proxmox: iptables nat vmbr0 y vmbr11

En éste caso la configuración que tenemos del servidor tenemos como siempre en vmbr0 una IP de guifi.net (que trato como ip local) y debido a que el numero de IPs públicas que tengo es limitada, tengo otro bridge vmbr11 con una red interna para comunicar las aplicaciones que sirven HTTP, luego tengo un contenedor con nginx y acceso a las 3 redes, la de guifi, la pública y la interna de las aplicaciones.

Para que las máquinas que están en la red de guifi y la de las aplicaciones puedan acceder a internet tendremos que configurar el NAT, para ello haremos lo siguiente:

En /etc/network/interfaces

root@wezen1A:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
	address 10.90.234.166
	netmask 255.255.255.224
	gateway 10.90.234.161
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0
	post-up echo 1 /proc/sys/net/ipv4/ip_forward

iface eth1 inet manual

auto vmbr1
iface vmbr1 inet static
        address 192.168.10.1
        netmask 255.255.255.0
        bridge_ports eth1     
        bridge_stp off
        bridge_fd 0

auto vmbr138
iface vmbr138 inet manual
        bridge_ports eth0.138
        bridge_stp off
        bridge_fd 0

auto vmbr11
iface vmbr11 inet static
        address 192.168.100.1
        netmask 255.255.255.0
        bridge_ports eth0.11
        bridge_stp off
        bridge_fd 0

La vmbr1 la tengo destinada a ceph, para que las maquinas compartan el disco ahí, además con su switch a parte! :) la vmbr138 es la que uso para las IPs públicas, en ésta red no vamos a aplicar NAT porqué las máquinas que estén en ésta red tendrán como gateway la IP del router. En vmbr0 ponemos en post-up el …

Proxmox: habilitar virtualización anidada (nesting virtualization)

Uno de los problemas que me estoy encontrando últimamente es que los contenedores lxc que instalo con debian 10 no arrancan los servicios porque tengo que reconfigurar systemd para decirle que el PrivateTmp es false, por ejemplo para poder levantar apache2 tendría que hacer ésto

Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
invoke-rc.d: initscript apache2, action "start" failed.
* apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-07-01 16:35:29 UTC; 9ms ago
     Docs: https://httpd.apache.org/docs/2.4/
  Process: 11730 ExecStart=/usr/sbin/apachectl start (code=exited, status=226/NAMESPACE)

Jul 01 16:35:29 wordpress systemd[1]: Starting The Apache HTTP Server...
Jul 01 16:35:29 wordpress systemd[11730]: apache2.service: Failed to set up mount namespacing: Permission denied
Jul 01 16:35:29 wordpress systemd[11730]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: Permission denied
Jul 01 16:35:29 wordpress systemd[1]: apache2.service: Control process exited, code=exited, status=226/NAMESPACE
Jul 01 16:35:29 wordpress systemd[1]: apache2.service: Failed with result 'exit-code'.
Jul 01 16:35:29 wordpress systemd[1]: Failed to start The Apache HTTP Server.

# vi /lib/systemd/system/apache2.service
PrivateTmp=false
:wq
# systemctl daemon-reload
# systemctl start apache2.service

Pero me encuentro el mismo problema con otros servicios que instalo.

Por lo que entiendo systemd crea como una especie de “entorno virtual” para cada uno de los servicios y para que funcione correctamente, leyendo documentación veo que la solución es habilitar la virtualización anidada.

Así que en la documentación de proxmox encontramos ésta página que nos dice como hacerlo.

Tendremos …

GlusterFS

GlusterFS es un gestor de ficheros en red. Básicamente lo que permite es replicar unos mismos ficheros en varios servidores, para luego con los clientes de glusterfs conectar a alguno de ellos y definir otro de backup en el caso de que se caiga el primero. Con éste sistema tenemos redundancia de los datos.

La recomendación es usar 3 nodos servidores de gluster, en mi caso, ahora mismo no dispongo del tercero, y lo añadiré mas tarde.

Vamos a trabajar con 3 nodos, Node1A, Node1B y Node2A, los dos primeros serán los servidores que tendrán el disco duro que queremos compartir en red, y el último sólo va a actuar como cliente.…

proxmox 6 + ceph

Por fin otro logro mas que me había dado guerra durante muchas horas, el motivo un ceph roto al que de momento he preferido migrar los datos a otro sitio y ya con mas calma intentaremos recuperarlo (ya vendrá otro post otro día sobre éste tema).

En motivo del ceph roto he aprovechado para reinstalar la infraestructura de proxmox entera sobre proxmox6 (debian10).

Partimos de 5 nodos unidos en el cluster (pvecm add ipmaster), sólo vamos a instalar ceph en 3 de ellos.

- node1A - 172.31.0.1 (ceph)
- node1B - 172.31.0.2
- node1C - 172.31.0.3 (ceph)
- node1D - 172.31.0.4 (ceph)
- node2D - 172.31.0.8

El nodo maestro del cluster es “node1D”, y para ver que ésto no implica nada a la hora de configurar ceph y también porque romper el 1D era una cosa que no me podía permitir… vamos a empezar por “node1A”.

Para ello vamos a la interfaz web de proxmox e instalamos ceph:…

Levantar tunnel vtun con lxc (proxmox)

Me encuentro con éste error

Oct 31 13:16:06 asterisk vtund[1748]: VTun client ver 3.X 05/15/2013 started
Oct 31 13:16:06 asterisk vtund[1748]: Connecting to 213.162.195.57
Oct 31 13:16:06 asterisk vtund[1748]: Use SSL-aware challenge/response
Oct 31 13:16:06 asterisk vtund[1748]: Remote Server sends #012.
Oct 31 13:16:06 asterisk vtund[1748]: Session sipcapa8[213.162.195.57] opened
Oct 31 13:16:06 asterisk vtund[1748]: Can't allocate tun device tun1000. No such file or directory(2)
Oct 31 13:16:06 asterisk vtund[1748]: Session sipcapa8[x.x.x.x] closed
Oct 31 13:16:06 asterisk vtund[1748]: Exit
Oct 31 13:17:09 asterisk vtund[1727]: Terminated

El motivo es que al tratar de levantar interfaces de red dentro del lxc no tenemos permisos y tenemos que definirle que éste contenedor si puede levantar interfaces de red.

Primero entramos en el host donde se encuentra el contenedor y apagamos el contenedor

# pct shutdown 104

Para ello modificamos el fichero de configuración del contenedor y añadimos al final ésta línea

root@wezen-04:/etc/pve/lxc# vi /etc/pve/lxc/104.conf
lxc.cgroup.devices.allow: c 10:200 rwm

Ahora arrancamos el contenedor de nuevo y ejecutamos los siguientes comandos

root@wezen-04:/etc/pve/lxc# pct start 104
root@wezen-04:/etc/pve/lxc# pct enter 104
root@asterisk:/# mkdir /dev/net
root@asterisk:/# mknod /dev/net/tun c 10 200
root@asterisk:/# ip tuntap add mode tap
root@asterisk:/# ip link
root@asterisk:/# service vtun restart
root@asterisk:/# ifconfig |grep tun
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00   
tun1000   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-0

Los comandos que hemos puesto los tendremos que ejecutar cada vez que reiniciemos la máquina, así que le decimos que ejecute éstos comandos justo después de levantar la interfaz de red

auto eth1
iface eth1 inet static
        address x.x.x.x
        netmask 255.255.255.224
        

Clúster Proxmox + añadir disco

El resumen de la de hoy, montar un clúster proxmox y luego añadir un disco addicional a /var/lib/vz2.

La primera es que partimos de 3 servidores, que es el mínimo recomendado para montar un clúster de proxmox. El motivo es que los nodos del clúster sincronizan continuamente los datos y si uno de los nodos se cae, si sólo hubiese dos podría dar problemas al reconstruir el nodo, ya que algunos datos se quedaron desactualizados o a medias en el nodo del clúster que está caído (que ha dejado de funcionar). Así que si montas cualquier tipo de clúster, el mínimo son 3 nodos, o 3 servidores distintos, en éste caso con instalaciones de proxmox.

Tengo 3 servidores con éstos nombres y éstas IPs (todos sin maquinas virtuales y se recomienda así para que no haya problemas de IDs duplicados)

– wezen-01.capa8.cat 10.90.226.90
– wezen-02.capa8.cat 10.90.226.91
– wezen-03.capa8.cat 10.90.226.92

Wezen-01 será el “master”, siempre que tengamos que levantar el clúster después de un corte de electricidad, vamos a levantar primero ésta máquina.

Entramos en el servidor wezen-01 y ejecutamos pvecm create nombredelcluster. Tenemos que tener en cuenta que se no se puede cambiar el nombre una vez creado y se recomienda no cambiar las IPs.

root@wezen-01:~# pvecm create wezen

Ahora entramos en los dos otros nodos y los conectamos con el nodo maestro. Nos pedirá el password de root del servidor maestro.

root@wezen-02:~# pvecm add 10.90.226.90
root@wezen-03:~# pvecm add 10.90.226.90

Y listos, ahora si miramos el estado del clúster nos …

Proxmox + nat + iptables

Acabo de contratar un servidor en un datacenter y sólo me dan una sola ip.
Como me gusta tener los servicios separados y todo bien ordenadito le he instalado proxmox 4, con soporte LXC, pero necesito que el host se comunique con los contenedores de alguna forma.

Lo que vamos a crear va a ser una interfaz virtual nueva, donde crearemos nuestra subred y luego redigiremos los puertos con iptables. Esto es lo que se llama hacer nat y redirección de puertos :P…