Volver al blog

TIPS - NFS de Proxmox montado en contenedores(CT)

containers

Hoy vamos a mostrar como montar el espacio NFS que añadimos a nuestro PVE en nuestros contenedores (CT).
Vamos a usar unos de los comandos del sistema df (informe el uso del espacio de disco del sistema de archivos) con la opción -h que es legible por humanos para que muestre los datos en GB. Este comando te va a devolver una lista como la siguiente:

root@pve:~# df -h
Filesystem                        Size  Used Avail Use% Mounted on
udev                              7.8G     0  7.8G   0% /dev
tmpfs                             1.6G  138M  1.5G   9% /run
rpool/ROOT/pve-1                  1.3T  2.5G  1.3T   1% /
tmpfs                             7.9G   60M  7.8G   1% /dev/shm
tmpfs                             5.0M     0  5.0M   0% /run/lock
tmpfs                             7.9G     0  7.9G   0% /sys/fs/cgroup
rpool                             1.3T  128K  1.3T   1% /rpool
rpool/ROOT                        1.3T  128K  1.3T   1% /rpool/ROOT
rpool/data                        1.3T   11G  1.3T   1% /rpool/data
rpool/data/subvol-1111101-disk-1   20G  903M   20G   5% /rpool/data/subvol-1111101-disk-1
/dev/fuse                          30M   24K   30M   1% /etc/pve
10.0.0.9:/storage/nfs/salvas    917G  309G  562G  36% /mnt/pve/NFSSalvas
tmpfs                             1.6G     0  1.6G   0% /run/user/0

Como pueden ver el servidor tiene agregado el volumen NFS /mnt/pve/NFSSalvas.

Para este articulo vamos a usar el contenedor 100, y la utilidad pct "Proxmox Container Toolkit", tengan en cuenta que esta utilidad esta disponible desde el cambio a LXC, para versiones con OpenVZ la utilidad era vzctl.
Usando esta utilidad revisaremos la configuración de nuestro contenedor:

root@pve:~# pct config 100
arch: amd64
cores: 1
hostname: adc1.sysadminsdecuba.com
memory: 512
nameserver: 10.0.0.1 10.0.0.2
net0: name=eth0,bridge=vmbr0,gw=10.0.0.254,hwaddr=42:D9:47:7E:D1:A9,ip=10.0.0.101/24,type=veth
ostype: ubuntu
rootfs: local-zfs:subvol-100-disk-1,size=20G
searchdomain: sysadminsdecuba.com
swap: 512

Para montar el espacio NFS entramos al contenedor, podemos hacerlo abriendo una nueva consola pero vamos a darle utilidad a pct:

## entramos al namespace del contenedor como root
pct enter 100

Una vez dentro del contenedor creamos una carpeta que es donde vamos a vincular la ruta del NFS en este caso sera en /opt/nfsct.

Después de crear la carpeta salimos del contenedor y en el servidor PVE vamos a la configuración para agregarle la linea que servirá para montar el NFS en la carpeta que acabamos de crear vamos al archivo de configuración del contenedor y agregamos la linea:

lxc.mount.entry: /mnt/pve/NFSSalvas /opt/ntfsct none rw,bind 0.0
Para agregar la linea voy a usar como editor nano que viene por defecto, seria como sigue:

nano /etc/pve/nodes/pve/lxc/100.conf

Después de guardarlo verificamos que este en fichero de configuración del contenedor y vemos que tiene la linea que hemos agregado.

root@pve:~# pct config 100
arch: amd64
cores: 1
hostname: adc1.sysadminsdecuba.com
memory: 512
nameserver: 10.0.0.1 10.0.0.2
net0: name=eth0,bridge=vmbr0,gw=10.0.0.254,hwaddr=42:D9:47:7E:D1:A9,ip=10.0.0.101/24,type=veth
ostype: ubuntu
rootfs: local-zfs:subvol-100-disk-1,size=20G
searchdomain: sysadminsdecuba.com
swap: 512
lxc.mount.entry: /mnt/pve/NFSIsos /opt/ntfsct none rw,bind 0.0

Reiniciamos el contenedor, entramos a el y verificamos el contenido de la carpeta.

## entramos al namespace del contenedor como root
pct enter 100
## ls /opt/nfsct

El contenido es exactamente el mismo que tenemos en la carpeta NFS del servidor. Esto es muy útil para tener en lugares donde tengas mayor almacenamiento y para hacer contenedores solo con el espacio de disco necesario para el OS.

Agregando comentarios de Pavel Milanes Costa de la utilidad y lo que ayuda tener esta configuración:

Esto es muy útil para por ejemplo un server de correos, en el CT pongo el server y la carpeta de almacén de correos está en el NFS montada por este método en /home/vmail/ así al hacer una salva (backup) del CT no me llevo los X GB de correos porque se quedan en el NAS.

Está lógica se puede utilizar para por ejemplo la carpeta /var/www/html de un server web, un server samba4 con los profiles móviles de un dominio montado en /home/samba, etc.

Otros detalles interesantes:
* Como los archivos está montados a nivel de Clúster y no localmente cuando mueves un CT este encontrará la carpeta en el lugar exacto en el otro nodo, por lo que el downtime es despreciable.
* Como los archivos está montados a nivel de Clúster y no localmente, puedes tener varias instancias trabajando en diferentes nodos o incluso en un mismo nodo del cluster para incrementar la capacidad, estoy pensando por ejemplo en 2+ servers SMTP/POP/IMAP/WEB/FTP para servir un dominio nacional desde VPN con alta demanda. (piensen en varias instancias docker sirviendo el mismo servicio con los archivos físicos compartidos)
* Al tener el NFS montado solo en un puñado de IPS (Cluster nodes) puedes usar una seguridad mejor y mas ajustada sobre el NFS a diferencia de cuando usas varios CT que debes manejarlos a cada uno. (en concordancia con la filosofía “set & forget” de los sysadmins vagos)
* Esto es “casi” lo mismo que usar NFS dentro de un CT pero con el inconveniente que versiones de Proxmox viejas no tomaban en cuenta y te metían en contenido del mount point dentro del backup. Verificado que Proxmox 5.0 en adelante excluye el NFS montado, en versiones anteriores esto daba palos.
* Sin ánimo de crear una Flame War yo personalmente recomiendo esta opción por se más atómica y con menos puntos de fallos que la versión de montar el NFS dentro del CT.

Saludos, hasta un próximo articulo...

 

Suscríbete · Newsletter

Mantente al día, cada semana

Artículos prácticos sobre Linux, redes, seguridad, virtualización y la nube — escritos por sysadmins cubanos.

  • Guías y tutoriales de administración de sistemas
  • Nuevos artículos sobre servidores, redes y nube
  • Sin spam, cancela cuando quieras

Respetamos tu bandeja de entrada. Cancela con un clic.

Patrocinado por SYSCU

¿Tu infraestructura en la nube te cuesta de más?

SYSCU optimiza tu nube de punta a punta — FinOps, DevOps & CI/CD, migraciones a AWS, seguridad y observabilidad. Equipo 100 % senior que reduce tu factura hasta un 40 % y acelera tus despliegues en semanas.

Nuevo · BetaSYSCU Atlas Insight — la plataforma FinOps que convierte tu gasto AWS en decisiones: visibilidad multi-cuenta, recomendaciones automáticas y alertas de anomalías.

No comments yet