Categoria: Proxmox

Proxmox: redireccionar puerto con iptables y preservar la ip

Published by admin on

Hace un par de años hice éste post sobre como redireccionar puertos a los contenedores que se encuentran dentro de un proxmox. Esta solución me fué de maravilla hasta que me di cuenta que el servidor nginx que estaba escuchando en los puertos 80 y 443 en lugar de guardar la IP del cliente que se conectaba, aparecía la IP del proxmox, cosa que creaba algunos problemas a la hora de bloquear intentos de acceso, ya que bloqueabas el acceso a todo el mundo… vamos… un pequeño problemilla de nada :P

Hace unos meses me propuse encontrar la solución pero hasta ahora no me ha sido urgente solucionarlo, ya que tengo que configurar otro proxmox con una ip compartida entre varios contenedores, cada uno de ellos con sus servicios y la cosa era mirar como afinaba esto… así que tras unos 4 días de estar rascando, aquí os traigo la solución :)

iptables -A PREROUTING -t nat -i vmbr0 -d 163.172.109.193 -p tcp --dport 443 -j DNAT --to-destination 192.168.1.2:443
iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 443 -j ACCEPT
iptables -A FORWARD -i vmbr1 -j ACCEPT
iptables -A FORWARD -i vmbr0 -o vmbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i vmbr1 -o vmbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o vmbr0 -j MASQUERADE

– La primera regla de PREROUTING, los paquetes entran por la interfaz vmbr0 des de la ip 163.172.109.193, que es la ip pública del servidor. Mandamos todo el …

Acceso ssh lento contenedores proxmox debian 11

Published by admin on

Llevo unos días que me encuentro que el acceso ssh de los contenedores lxc de proxmox con debian 11 es horrorosamente lento.

Si miramos el log del servicio ssh nos encontramos esto:

root@ns2:/etc/ssh# cat /var/log/auth.log
Jan  4 13:55:25 ns2 dbus-daemon[70]: [system] Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Jan  4 13:55:25 ns2 sshd[280]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Jan  4 13:58:54 ns2 dbus-daemon[70]: [system] Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Jan  4 14:00:20 ns2 dbus-daemon[70]: [system] Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

El motivo es porqué el servicio systemd-logind no está levantado:

root@ns2:~# systemctl status systemd-logind
● systemd-logind.service
     Loaded: masked (Reason: Unit systemd-logind.service is masked.)
     Active: failed (Result: exit-code) since Tue 2022-01-04 14:59:55 CET; 22min ago
   Main PID: 3620 (code=exited, status=226/NAMESPACE)

Jan 04 14:59:55 ns2 systemd[1]: systemd-logind.service: Main process exited, code=exited, status=226/NAMESPACE
Jan 04 14:59:55 ns2 systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Jan 04 14:59:55 ns2 systemd[1]: Failed to start User Login Management.
Jan 04 14:59:55 ns2 systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 5.
Jan 04 14:59:55 ns2 systemd[1]: Stopped User Login Management.
Jan 04 14:59:55 ns2 systemd[1]: systemd-logind.service: Start request repeated too quickly.
Jan 04 14:59:55 ns2 systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Jan 04 14:59:55 ns2 systemd[1]: Failed to start User Login Management.

Tenemos dos opciones, la primera es posible que tengamos que activar el nesting en el contenedor (ya configurado por defecto en proxmox 7) o la otra opción es:

Lo …

Benchmarking y tunning de servidores para ceph

Published by admin on

Una vez tenemos una infraestructura de servidores funcionando bajo ceph, nos podemos preguntar ¿Cómo compruebo que mi cluster está funcionando a máximo rendimiento? En este post vamos a ver algunas herramientas para comprobar el rendimiento y tunning que podemos realizar en nuestros servidores para sacarle mas partido a Ceph.

Comprobar la escritura de disco
La forma mas sencilla para hacer un benchmark del disco es usando el comando dd. Para ello vamos a usar el siguiente comando, añadiendo la etiqueta oflag para bypassear la cache del disco:

# dd if=/dev/zero of=here bs=1G count=1 oflag=direct

Esta es la salida de uno de mis servidores, la primera sobre /root y la otra sobre /mnt/pve/ceph_data que es donde está montado un pool de ceph

root@wezen3D:~# dd if=/dev/zero of=here bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.1835 s, 96.0 MB/s

root@wezen3D:/mnt/pve/ceph_data# dd if=/dev/zero of=here bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 46.5157 s, 23.1 MB/s

Comprobar la velocidad de la red
Cuando estamos usando ceph, la red es un factor muy importante. En mi actual infraestructura estoy usando puertos ethernet a 1Gbps. En los foros de proxmox muchos de los administradores usan varios puertos ethernet en bonding o incluso puertos de fibra de 10Gbps. Espero que en unas semanas pueda tener funcionando la segunda opción, de mientras todo el tunning que puedo hacer es tocar parámetros y configuración (ahora entraremos en ello).

La herramienta por excelencia …

Ceph: El maldito deep scrubbing

Published by admin on

Si has llegado aquí es que estás buscando ¿qué coño es esto del deep scrubbing? y es que no hay sólo deep scrubbing, sino que ¡hay también otro! el scrubbing a secas. Si aún no has llegado aquí te lo cuento.

En ceph hay los pg, que vendrían a ser las unidades de datos dentro de ceph. En estas unidades de dados es realmente donde se almacena la información y una forma de verlos sería como ficheros o volúmenes de datos.
Para que los datos sean coherentes entre los distintos servidores, ceph hace scrubbing y deep scrubbing. Aquí lo explican muy bien.

En resumen sería

  • scrubbing (a secas). captura los errores del OSD o del sistema de ficheros. Este proceso suele ser ligero y no generar un gran impacto en la lectura y escritura de disco (iout o io)
  • deep scrubbing, compara los datos de los objetos PG, bit a bit. Busca sectores defectuosos en los discos. Este proceso genera un I/O alto.

Una cosa que ya he identificado es que un I/O alto afecta al rendimiento de todo el sistema. Hace que todo vaya leeeeentooooo, que mover ficheros de un lugar a otro sea un supliciooooo….

Desde que actualicé de proxmox 6 a proxmox 7 y actualizando la versión del ceph, todo ha ido empeorando con el paso de los días. He comprado un switch mikrotik con 8 puertos de fibra de 10G y a ver si con las tarjetas de red de 10Gb de fibra y los …

Proxmox: Ceph y error SECURITY information

Published by admin on

Olrait! otro problemilla de estos tontos que tenía pendientes de solucionar, resuelto!

La cosa es que hace un par de meses actualicé un proxmox 6.4 a 7.0, con major upgrade del sistema operativo (debian 10 a debian 11) incluso antes que saliese liberada la propia debian 11! Al hacerlo también tuve que subir la versión de ceph de nautilus (14.x) a octopus (15.x).

Al terminar, aquella misma noche recibo un mensaje de todos y cada uno de los servidores que había actualizado el ceph

Asunto: *** SECURITY information for planet1A.lamardebits.org ***

Cuerpo:
planet1A.lamardebits.org : Sep 9 00:08:13 : ceph : a password is required ; PWD=/ ; USER=root ; COMMAND=nvme wdc_wd4003ffbx-68mu3n0 smart-log-add –json /dev/sdb

La solución viene hoy pues tras encontrar éste mail en las listas de proxmox. Hay que entender el problema, falta algo en sudo o algo otro en otro programa para que suelte esto:

Primero será mirar qué hay en sudoers

root@planet1A:/etc/sudoers.d# cat ceph-osd-smartctl 
## allow ceph-osd (which runs as user ceph) to collect device health metrics

ceph ALL=NOPASSWD: /usr/sbin/smartctl -a --json=o /dev/*
ceph ALL=NOPASSWD: /usr/sbin/nvme * smart-log-add --json /dev/*

Después será mirar si existe el keyring de ceph para conectar con los otros ceph:

root@planet1A:~# cat /var/lib/ceph/bootstrap-osd/ceph.keyring
[client.bootstrap-osd]
	key = *****************************

Finalmente y lo que ha sido creo la solución, porque al mirar ambas cosas estaban correctas, ha sido instalar el paquete nvme-cli y listos, sin reiniciar ni nada.

root@planet1A:~# apt -y install nvme-cli

Cada día, al ejecutarse la copia de seguridad salía el …

Proxmox migrar máquinas con mountpoints locales

Published by admin on

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

Published by admin on

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

Published by admin on

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

Published by admin on

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)

Published by admin on

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 …