En este post veremos cómo crear OSDs (Object Storage Device), pool de OSD y agregar almacenamiento al clúster Ceph, los OSDs son los discos físicos de cada nodo que se van a presentar al pool de OSD Ceph y poder así crear nuestros datastores para el clúster Ceph.

La topología utilizada sería la siguiente:

• Empezamos a crear el OSD para el nodo pvelab01 > Ceph > OSD > Crear OSD:

• Seleccionamos el disco y Crear:

• Una vez creado, damos a Recargar y vemos que ya nos muestra el OSD para el nodo pvelab01:

• Ahora creamos el OSD para el nodo pvelab02:

• Ahora creamos el OSD para el nodo pvelab03:

• Una vez creados los OSDs en cada uno de nuestros nodos, vamos a crear el pool de OSD Ceph y agregarlo o presentarlo como almacenamiento (datastore) al clúster Ceph, para ello, accedemos a pvelab01 > Ceph > Conjuntos > Crear:

• Le asignamos un nombre, marcamos el check Agregar como almacenamiento, y todo lo demás lo dejamos por defecto, Crear:

• Como podemos ver, aquí tenemos el pool de OSD Ceph creado:

• Si accedemos a los otros nodos del clúster, vemos que también nos muestra el pool de OSD Ceph:

• Si accedemos a Centro de datos > Almacenamiento, ya vemos que tenemos el datastore Ceph del tipo RBD operativo y listo para usarlo, también vemos como se ha agregado automáticamente a todos los nodos de nuestro clúster Ceph:

• Con todo esto, ya tendríamos configurado y operativo todo el almacenamiento compartido para nuestro clúster Ceph, si accedemos a cada nodo > Ceph, podemos ver el estado del nodo Ceph:

• Ahora vamos a desplegar una máquina virtual en este datastore Ceph, para ver como sus discos virtuales se replican de manera automática en todos los nodos del clúster, quedando almacenados estos discos virtuales en cada disco físico de cada nodo.
• Esta es la máquina que hemos desplegado en almacenamiento Ceph RBD:

• Al desplegar la máquina virtual sobre el nodo pvelab02, si accedemos al datastore ceph en cada uno de nuestros nodos del clúster, vemos que los discos virtuales de la máquina se han replicado en cada datastore de cada nodo del clúster Ceph:

Saludos y espero que os sea de ayuda

En este post veremos cómo agregar y configurar almacenamiento ZFS local en un clúster Proxmox VE 9.0.

La topología utilizada sería la siguiente:

• Para empezar, hemos agregado a cada nodo de nuestro clúster, un disco duro de 200 GB, los discos deben tener la misma capacidad en todos los nodos:

• Ahora, sobre nuestro nodo 1, pvelab01, nos vamos a crear un pool para ZFS, para ello, accedemos a pvelab01 > Discos > ZFS > Crear ZFS:

• Le indicamos el nombre, y muy importante, NO marcar el check Agregar almacenamiento, ya que como vamos a trabajar en clúster, lo vamos a configurar a posteriori, le indicamos el nivel de RAID que nos interese, la compresión, seleccionamos el disco y Crear:

• Como vemos, ya tenemos el pool de ZFS, creado:

• Ahora, vamos a agregar el almacenamiento al clúster, para ello, accedemos a Centro de datos > Almacenamiento > Agregar > ZFS:

• Sobre General, le indicamos el ID, el ZFS Pool que creamos anteriormente, el contenido, que se cree en todos los nodos y lo activamos, Agregar:

• Como vemos, el datastore se ha agregado correctamente al cluster, pero si nos fijamos bien, sólo lo tenemos operativo en el nodo 1, pvelab01, en pvelab02 y pvelab03 nos aparece con un signo de interrogación, esto quiero decir que no podemos acceder, y que nos faltan configuraciones por asignar, que las veremos ahora:

• Para activar este nuevo datastore ZFS en los nodos pvelab02 y pvelab03, accedemos al nodo > Discos > ZFS > Crear ZFS, para crear el pool ZFS, muy importante, asignarle el mismo Nombre y no marcar el check Agregar almacenamiento, una vez creado vemos que el signo de interrogación desaparece del datastore y ya lo tendríamos operativo:

• Con todo esto, ya tenemos almacenamiento compartido por ZFS en los tres nodos de nuestro clúster, realmente no es un almacenamiento compartido como en iSCSI, aquí el disco de la máquina virtual solo va a estar en un ZFS perteneciente al nodo, cuando migremos la máquina entre nodos, el proceso va a ser más lento que en iSCSI, ya que tiene que migrar el disco virtual completo al ZFS del nodo al que se realice la migración.

Saludos y espero que os sea de ayuda

En estos posts veremos cómo desplegar y configurar una infraestructura virtualizada con Proxmox VE 9.0, usando el Failover Clúster de Proxmox y la alta disponibilidad HA, vamos a usar tres nodos, pvelab01, pvelab02 y pvelab03, para el almacenamiento vamos a montar y configurar un pool ZFS local.

La topología utilizada sería la siguiente:

Estos post los vamos a dividir en las siguientes entradas:

• Creación y configuración Clúster de tres nodos en Proxmox VE 9.0
• Agregar y configurar almacenamiento ZFS local en Clúster Proxmox VE 9.0
• Migración en vivo de máquinas virtuales en un Cluster Proxmox con ZFS Pool
• Configuración de replicación de máquinas virtuales con ZFS local para HA en un clúster Proxmox

Saludos.

En este post vamos a ver cómo agregar almacenamiento iSCSI multipath al clúster Proxmox VE 9.1.2 con configuraciones más avanzadas y mejor preparadas para trabajar en clúster, esto nos va a permitir:

• Definir parámetros avanzados, como round-robin, no_path_retry, rr_min_io…
• Asignar alias legibles a nuestras LUNs.
• Evitaremos que multipath intente agrupar discos locales con la opción de blacklists.
• Aseguraremos un comportamiento idéntico en todos los nodos de nuestro clúster.

Recordamos la topología:

• Para empezar, vamos a instalar en cada nodo los paquetes para el iniciador iSCSI y DM-Multipath, para ello, ejecutamos, apt install -y open-iscsi y apt install -y multipath-tools:

• Habilitamos e iniciamos los servicios para iscsid, ejecutamos, systemctl enable –now iscsid.service y systemctl enable –now open-iscsi.service:

• Habilitamos e iniciamos los servicios para multipathd, ejecutamos, systemctl enable –now multipathd.service:

• Comprobamos el estado de ambos servicios con systemctl status iscsid.service y systemctl status multipathd.service:

• Ahora vamos a ajustar conf, Proxmox recomienda reducir node.session.timeo.replacement_timeout = 15 para iSCSI, por defecto en 120s, lo pasamos a 15s, y para que la sesión sea persistente al arranque modificamos node.startup = automatic, para ello, editamos nano /etc/iscsi/iscsid.conf, esta modificación ayuda a que los timeouts de sesión sean más ágiles y evita esperas largas cuando tenemos fallos:

• Reiniciamos el servicio iscsid, systemctl restart iscsid.service y systemctl restart open-iscsi.service:

• Ahora vamos a descubrir los targets (IQNs) que nos ofrece nuestra cabina en cada IP/portal, esto no cambia ficheros manualmente, sino que guarda la información de esos targets en el directorio /etc/iscsi/nodes/ automáticamente, iscsiadm -m discovery -t st -p 10.10.2.4 y iscsiadm -m discovery -t st -p 10.10.3.4:

• Hacemos login en ambos portales, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -l y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -l, con esto conectamos los nodos pve a la cabina a través de las dos redes iSCSI:

• Para que el login sea persistente y se reconecte en cada reinicio, debemos de ejecutar, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -o update -n node.startup -v automatic y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -o update -n node.startup -v automatic:

• Comprobamos que ambos caminos están activos con, iscsiadm -m session -P3:

• Si accedemos a nuestra cabina SAN iSCSI, podemos ver, que ya tenemos los discos, en este caso, las LUNs conectadas:

• Ejecutamos en cada nodo, ls -l /dev/disk/by-path | grep 10.10 y como vemos la LUN0 tiene dos caminos, por 10.10.2.4 que aparece como /sdf y por 10.10.3.4 que aparece como /sdh, la LUN1 tiene dos caminos, por 10.10.2.4 que aparece como /sdg y por 10.10.3.4 que aparece como /sdi:

• Ahora, Multipath se basa en el WWID único de cada LUN, para obtenerlo ejecutamos:
• Para LUN0, /lib/udev/scsi_id -g -u -d /dev/sdf y /lib/udev/scsi_id -g -u -d /dev/sdh, ambos deben devolver el mismo WWID:

• Para LUN1, /lib/udev/scsi_id -g -u -d /dev/sdg y /lib/udev/scsi_id -g -u -d /dev/sdi, ambos deben devolver el mismo WWID:

• Añadimos el WWID de cada LUN para que multipath lo gestione.
• Para LUN0, multipath -a 360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, multipath -a 360003ff44dc75adc922dc286607e2e6f

• Recargamos multipath con multipath -r:

• Verificamos multipath con multipath -ll, esto significa que multipath creó un dispositivo /dev/dm-2 que representa a la LUN1, y dentro están los dos caminos activos (sdg y sdi), y otro dispositivo /dev/dm-1 que representa a la LUN0, y dentro están los dos caminos activos (sdf y sdh):

• Si ejecutamos ls -l /dev/mapper/ vemos lo siguiente:
• 360003ff44dc75adc922dc286607e2e6f, es el WWID de la LUN1.
• 360003ff44dc75adcbda106c1b22f4b5b, es el WWID de la LUN0.
• Ambos son enlaces simbólicos a los dispositivos multipath, /dev/dm-1 y /dev/dm-2
• control, es el dispositivo de control interno de multipath.

• Ahora vamos a crear el fichero /etc/multipath.conf en nuestros tres nodos con este contenido:

defaults {

user_friendly_names no

find_multipaths strict

path_selector «round-robin 0»

path_checker tur

rr_min_io 100

failback immediate

no_path_retry 12

}

blacklist {

devnode «^sda»

devnode «^sr0»

}

multipaths {

multipath {

wwid «360003ff44dc75adcbda106c1b22f4b5b»

alias «iscsi_saniscsipve_lun0»

}

multipath {

wwid «360003ff44dc75adc922dc286607e2e6f»

alias «iscsi_saniscsipve_lun1»

}

}

• Con este fichero configuramos:
• Round-robin activado
• Alias legibles (iscsi_saniscsipve_lun0 y iscsi_ saniscsipve _lun1)
• Parámetros ajustados para clusters (retry, failback, tur)
• Disco local sda y cdrom sr0 excluidos

• Ahora verificamos que el fichero /etc/multipath/wwids es exactamente igual en los tres nodos:

• Ahora ejecutamos estos tres comandos en los tres nodos:
• systemctl restart multipathd para recargar multipath.
• multipath -r para releer dispositivos multipath.
• multipath -ll para verificar.

• Con el comando ls -l /dev/mapper/iscsi_saniscsipve_lun* verificamos que existen los nuevos dispositivos:

• Ahora, la creación del Physical Volumen (PV) y Volume Group (VG), solo la vamos a hacer en un nodo, en este caso en el nodo 1, pvelab01.
• Para LUN0, pvcreate /dev/mapper/iscsi_saniscsipve_lun0 y vgcreate vg_iscsi0 /dev/mapper/iscsi_saniscsipve_lun0
• Para LUN1, pvcreate /dev/mapper/iscsi_saniscsipve_lun1 y vgcreate vg_iscsi1 /dev/mapper/iscsi_saniscsipve_lun1

• En los otros dos nodos ejecutamos, pvscan –cache y vgscan para que detecte el Physical Volumen (PV) y el Volume Group (VG):

• Si accedemos a todos los nodos > Discos > LVM, vemos que se han creado los Volume Group:

• Para terminar, accedemos a Centro de datos > Almacenamiento > Agregar > LVM:

• Sobre General, le indicamos el ID, Almacenamiento de base, Grupo del volumen, Contenido, Nodos, Activar, Compartido (importante activar para las migraciones en vivo), Agregar, para agregar la LUN0:

• Agregamos también la otra LUN1:

• Como podemos ver en, Centro de datos > Almacenamiento, tenemos los dos datastores añadidos:

• Aquí vemos, que los tres nodos, ya disponen del almacenamiento compartido por iSCSI y con Multipath:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo agregar almacenamiento iSCSI multipath al clúster Proxmox VE 9.0

Recordamos la topología:

• Para empezar, vamos a instalar en cada nodo los paquetes para el iniciador iSCSI y DM-Multipath, para ello, ejecutamos, apt install -y open-iscsi y apt install -y multipath-tools:

• Habilitamos e iniciamos los servicios para iscsid, ejecutamos, systemctl enable –now iscsid.service y systemctl enable –now open-iscsi.service:

• Habilitamos e iniciamos los servicios para multipathd, ejecutamos, systemctl enable –now multipathd.service:

• Comprobamos el estado de ambos servicios con systemctl status iscsid.service y systemctl status multipathd.service:

• Ahora vamos a ajustar /etc/iscsi/iscsid.conf, Proxmox recomienda reducir node.session.timeo.replacement_timeout = 15 para iSCSI, por defecto en 120s, lo pasamos a 15s, y para que la sesión sea persistente al arranque modificamos node.startup = automatic, para ello, editamos nano /etc/iscsi/iscsid.conf, esta modificación ayuda a que los timeouts de sesión sean más ágiles y evita esperas largas cuando tenemos fallos:

• Reiniciamos el servicio iscsid, systemctl restart iscsid.service y systemctl restart open-iscsi.service:

• Ahora vamos a descubrir los targets (IQNs) que nos ofrece nuestra cabina en cada IP/portal, esto no cambia ficheros manualmente, sino que guarda la información de esos targets en el directorio /etc/iscsi/nodes/ automáticamente, iscsiadm -m discovery -t st -p 10.10.2.4 y iscsiadm -m discovery -t st -p 10.10.3.4:

• Hacemos login en ambos portales, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -l y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -l, con esto conectamos los nodos pve a la cabina a través de las dos redes iSCSI:

• Para que el login sea persistente y se reconecte en cada reinicio, debemos de ejecutar, iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.2.4 -o update -n node.startup -v automatic y iscsiadm -m node -T iqn.1991-05.com.microsoft:saniscsipve-iscsitarget1saniscsipve-target -p 10.10.3.4 -o update -n node.startup -v automatic:

• Comprobamos que ambos caminos están activos con, iscsiadm -m session -P3:

• Si accedemos a nuestra cabina SAN iSCSI, podemos ver, que ya tenemos los discos, en este caso, las LUNs conectadas:

• Ejecutamos en cada nodo, ls -l /dev/disk/by-path | grep 10.10 y como vemos la LUN0 tiene dos caminos, por 10.10.2.4 que aparece como /sdc y por 10.10.3.4 que aparece como /sde, la LUN1 tiene dos caminos, por 10.10.2.4 que aparece como /sdd y por 10.10.3.4 que aparece como /sdf:

• Ahora, Multipath se basa en el WWID único de cada LUN, para obtenerlo ejecutamos:
• Para LUN0, /lib/udev/scsi_id -g -u -d /dev/sdc y /lib/udev/scsi_id -g -u -d /dev/sde, ambos deben devolver el mismo WWID:

• Para LUN1, /lib/udev/scsi_id -g -u -d /dev/sdd y /lib/udev/scsi_id -g -u -d /dev/sdf, ambos deben devolver el mismo WWID:

• Añadimos el WWID de cada LUN para que multipath lo gestione.
• Para LUN0, multipath -a 360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, multipath -a 360003ff44dc75adc922dc286607e2e6f

• Recargamos multipath con multipath -r:

• Verificamos multipath con multipath -ll, esto significa que multipath creó un dispositivo /dev/dm-0 que representa a la LUN0, y dentro están los dos caminos activos (sdc y sde), y otro dispositivo /dev/dm-1 que representa a la LUN1, y dentro están los dos caminos activos (sdd y sdf):

• Si ejecutamos ls -l /dev/mapper/ vemos lo siguiente:
• 360003ff44dc75adc922dc286607e2e6f, es el WWID de la LUN1.
• 360003ff44dc75adcbda106c1b22f4b5b, es el WWID de la LUN0.
• Ambos son enlaces simbólicos a los dispositivos multipath , /dev/dm-0 y /dev/dm-1
• control, es el dispositivo de control interno de multipath.

• Ahora, la creación del Physical Volumen (PV) y Volume Group (VG), solo la vamos a hacer en un nodo, en este caso en el nodo 1, pvelab01.
• Para LUN0, pvcreate /dev/mapper/360003ff44dc75adcbda106c1b22f4b5b y vgcreate vg_iscsi0 /dev/mapper/360003ff44dc75adcbda106c1b22f4b5b
• Para LUN1, pvcreate /dev/mapper/360003ff44dc75adc922dc286607e2e6f y vgcreate vg_iscsi1 /dev/mapper/360003ff44dc75adc922dc286607e2e6f

• Si accedemos a todos los nodos > Discos > LVM, vemos que se han creado los Volume Group:

• Para terminar, accedemos a Centro de datos > Almacenamiento > Agregar > LVM:

• Sobre General, le indicamos el ID, Almacenamiento de base, Grupo del volumen, Contenido, Nodos, Activar, Compartido (importante activar para las migraciones en vivo), Agregar, para agregar la LUN0:

• Agregamos también la otra LUN1:

• Como podemos ver en, Centro de datos > Almacenamiento, tenemos los dos datastores añadidos:

• Aquí vemos, que los tres nodos, ya disponen del almacenamiento compartido por iSCSI y con Multipath:

Saludos y espero que os sea de ayuda

En este post veremos cómo mover los discos virtuales de las máquinas de almacenamiento en Proxmox VE 9.0.

• Esta operación de mover los discos virtuales de las máquinas de datastore lo podemos hacer con la máquina corriendo, vamos a mover este disco de esta máquina, que como podemos ver está en el datasore DTS01VMCT:

• Si accedemos a Almacenamiento > DTS01VMCT > Discos de la VM, podemos ver que el disco lo tenemos en este datastore ubicado:

• Para mover el disco virtual de datastore, accedemos a la máquina virtual > Hardware > Disco duro (scsi) > Acción de disco > Mover almacenamiento:

• Le indicamos el datastore al que queremos mover el disco, de momento no eliminamos el origen, lo haremos una vez que sepamos que el disco está correctamente migrado y la máquina funcionando, Mover disco:

• Como podemos ver comienza a mover el disco, bueno en este caso, copiar, ya que le hemos indicado que no elimine el origen:

• Aquí vemos que el proceso ha finalizado correctamente:

• Si accedemos a máquina virtual > Hardware, podemos ver, que ya tenemos el disco virtual migrado de datastore, se ha movido a DTS02VMCT, y vemos que el disco virtual original se ha quedado sin uso, verificamos que la máquina está corriendo sin problemas, y si todo ha ido bien, podemos eliminar el disco sin usar:

• Y así nos quedaría definitivamente:

• Si accedemos a Almacenamiento > DTS02VMCT > Discos de la VM, podemos ver que el disco lo tenemos en este datastore ubicado:

• Para el disco EFI, también hemos realizado el mismo proceso y todo OK:

Saludos y espero que os resulte de ayuda

En este post veremos cómo agregar almacenamiento CIFS a un nodo Proxmox VE 9.0, con este tipo de almacenamiento agregamos datastores a nuestro nodo proxmox con recursos compartidos por SMB como pueden ser las carpetas compartidas en un entorno Windows.

• Para empezar, vemos que tenemos este recurso compartido en un servidor de ficheros Windows, si alguien le interesa como montar un servidor de ficheros en Windows Server aquí tiene el enlace a este mismo blog:

• Para crear el almacenamiento CIFS, accedemos a Centro de datos > Almacenamiento > Agregar > SMB/CIFS:

• Le indicamos un nombre, el servidor, las credenciales, el recurso compartido, tipo de contenido, dominio y el subdirectorio dentro del recurso compartido, Agregar:

• Si accedemos a Centro de datos > Almacenamiento, podemos ver, que se ha creado el datastore CIFS con el tipo de contenido Respaldo, Imagen ISO, Plantilla de contenedor, esto quiere decir, que en este datastore podemos almacenar los backups, las imágenes ISO y las plantillas de contenedor, también podemos ver el punto de montaje del datastore:

• Aquí tenemos un resumen del almacenamiento CIFS:

• Si accedemos a nuestro servidor de ficheros Windows, vemos la estructura de carpetas que nos ha creado:

• Con todo esto que hemos configurado, ya podemos usar este almacenamiento para los backups, cargar imágenes ISO y plantillas de contenedores.

Saludos y espero que os resulte de ayuda

En este post veremos cómo agregar almacenamiento tipo Directorio a un nodo Proxmox VE 9.0, con este tipo de almacenamiento vamos a poder cargar imágenes ISO y plantillas de contenedores sobre nuestro servidor de Proxmox, estas imágenes ISO las vamos a poder utilizar a posteriori en el despliegue de máquinas virtuales como medio de instalación del sistema operativo.

• Para empezar, vamos a añadir un nuevo disco físico a nuestro nodo de Proxmox, en mi caso, simularé que voy a agregar un nuevo disco físico, añadiendo un nuevo disco virtual a la máquina de Proxmox virtualizada en un host ESXi, este sería el disco que hemos agregado:

• Si accedemos a proxmoxlab11 > Discos, podemos ver, que ya tenemos disponible el nuevo disco de 200 GB que hemos añadido:

• Para empezar a configurar el tipo de almacenamiento Directorio, accedemos a proxmoxlab11 > Discos > Directorio, y creamos el Directorio:

• Le indicamos el disco que vamos a utilizar, el sistema de archivos, le asignamos un nombre y marcamos el check para que automáticamente nos agregue el almacenamiento al centro de datos, Crear:

• Comienza a crearlo:

• Como podemos ver, aquí se ha creado el Directorio:

• Si accedemos a Centro de datos > Almacenamiento, podemos ver, que también se ha creado el datastore con el tipo de contenido Imagen ISO, Plantilla de contenedor, esto quiere decir, que en este datastore podemos almacenar las imágenes ISO y las plantillas de contenedor (al crearlo, nos asigna todos los tipos de almacenamiento, nosotros lo hemos editado y solo hemos dejado estos Imagen ISO y Plantillas de contenedor):

• Aquí tenemos un resumen del almacenamiento Directorio:

• Y aquí vemos el disco, con el Almacenamiento – Uso en ext4:

• Para cargar una imagen ISO a nuestro almacenamiento accedemos a proxmoxlab11 > DatastoreISO > Imágenes ISO > Cargar:

• Seleccionamos la imagen ISO en nuestro equipo y cargamos:

• Aquí vemos, que la tarea ha finalizado correctamente y ya tenemos la imagen ISO subida al almacenamiento del tipo Directorio:

• Una opción bastante interesante que tenemos en este tipo de almacenamiento, es que podemos descargar una imagen ISO desde una URL, para ello, accedemos al datastore > Imágenes ISO > Descargar desde URL:

• Nos vamos a descargar la última versión de debian, copiamos la dirección de enlace:

• En Descargar desde URL, copiamos el enlace y damos a Consultar URL, entonces nos mostrará la imagen ISO a descargar, damos a Descargar:

• Comienza la descarga:

• Aquí vemos que se ha descargado correctamente, y ya tenemos nuestra imagen ISO lista para ser usada:

• Con todo esto que hemos configurado, ya podemos usar este almacenamiento para cargar imágenes ISO y plantillas de contenedores.

Saludos y espero que os resulte de ayuda

En este post veremos cómo agregar almacenamiento ZFS a un nodo Proxmox VE 9.0, en este link podemos ver las características de ZFS en Proxmox.

• Para empezar, vamos a añadir un nuevo disco físico a nuestro nodo de Proxmox, en mi caso, simularé que voy a agregar un nuevo disco físico, añadiendo un nuevo disco virtual a la máquina de Proxmox virtualizada en un host ESXi, este sería el disco que hemos agregado:

• Si accedemos a proxmoxlab11 > Discos, podemos ver, que ya tenemos disponible el nuevo disco de 500 GB que hemos añadido:

• Para empezar a configurar el tipo de almacenamiento ZFS, accedemos a proxmoxlab11 > Discos > ZFS, y creamos el pool ZFS:

• Le indicamos el disco que vamos a utilizar, le asignamos un nombre y marcamos el check para que automáticamente nos agregue el Datastore al almacenamiento del centro de datos, como nivel de RAID en este caso lo vamos a realizar para un único disco, Crear:

• Como podemos ver, aquí se ha creado el pool de ZFS:

• Si accedemos a Centro de datos > Almacenamiento, podemos ver, que también se ha creado el datastore con el tipo de contenido Imagen de disco, Contenedor, esto quiere decir, que en este datastore podemos almacenar los discos virtuales de las máquinas virtuales y los contenedores LXC:

• Aquí tenemos un resumen del almacenamiento ZFS:

• Y aquí vemos el disco, con el Almacenamiento – Uso en ZFS:

• Con todo esto que hemos configurado, ya podemos usar este almacenamiento para crear las máquinas virtuales y contenedores.

Saludos y espero que os sea de ayuda

En este post veremos cómo agregar almacenamiento LVM o LVM-Thin a un nodo Proxmox VE 9.0, antes de empezar vamos a aclarar que LVM y LVM-Thin son el mismo tipo de almacenamiento, la diferencia está, si hemos trabajado con VMware, es lo mismo que usar Thick Provision (LVM) y Thin Provision (LVM-Thin), es decir, Thin Provision es una técnica que solo asigna el espacio de almacenamiento físico que el disco virtual necesita inicialmente, permitiendo que crezca según la demanda, mientras que Thick Provision asigna todo el espacio físico necesario desde el momento de su creación, en nuestro caso, vamos a trabajar con LVM-Thin.

• Para empezar, vamos a añadir un nuevo disco físico a nuestro nodo de Proxmox, en mi caso, simularé que voy a agregar un nuevo disco físico, añadiendo un nuevo disco virtual a la máquina de Proxmox virtualizada en un host ESXi, este sería el disco que hemos agregado:

• Si accedemos a proxmoxlab11 > Discos, podemos ver, que ya tenemos disponible el nuevo disco de 500 GB que hemos añadido:

• Para empezar a configurar el tipo de almacenamiento LVM-Thin, accedemos a proxmoxlab11 > Discos > LVM-Thin, y creamos un Thinpool:

• Le indicamos el disco que vamos a utilizar, le asignamos un nombre y marcamos el check para que automáticamente nos agregue el Datastore al almacenamiento del centro de datos, Crear:

• Comienza a crearlo:

• Como podemos ver, aquí se ha creado el Thinpool:

• Al acceder a proxmoxlab11 > Discos > LVM, vemos que se ha creado este Volume Group:

• Si accedemos a Centro de datos > Almacenamiento, podemos ver, que también se ha creado el datastore con el tipo de contenido Imagen de disco, Contenedor, esto quiere decir, que en este datastore podemos almacenar los discos virtuales de las máquinas virtuales y los contenedores LXC:

• Aquí tenemos un resumen del almacenamiento LVM-Thin:

• Y aquí vemos el disco, con el Almacenamiento – Uso en LVM:

• Con todo esto que hemos configurado, ya podemos usar este almacenamiento para crear las máquinas virtuales y contenedores.

Saludos y espero que os sea de ayuda

En este post veremos los tipos de almacenamiento que tenemos en nuestro servidor Proxmox VE 9.0

• Si accedemos a proxmoxlab11 > Discos, podemos ver, que nuestro nodo de proxmox tiene dos discos duros de 50 GB, con estos dos discos, en la instalación configuramos un RAID1 en ZFS:

• Si accedemos a Centro de datos > Almacenamiento, vemos que tenemos dos datastores, que son los dos que se han creado durante la instalación, uno de ellos, es el almacenamiento local dónde se instala el sistema operativo, y el otro es un datastore local-zfs dónde podemos ubicar los discos virtuales de las máquinas y contenedores LXC, como buena práctica, en estos datastore no es aconsejable ubicar nada, para ello, iremos agregando nuevos discos a nuestro nodo y los configuraremos con el tipo de almacenamiento que nos interese:

• Si accedemos a proxmoxlab11 > Discos > ZFS > rpool, vemos el pool ZFS que se creó durante la instalación:

• En Proxmox tenemos distintos tipos de almacenamiento que podemos agregar y tienen un tipo de contenido específico, cuando los vayamos a desplegar podemos configurar este tipo de contenido según el uso que le vayamos a dar, si accedemos a Centro de datos > Almacenamiento > Agregar, podemos ver, los distintos tipos de almacenamiento que podemos añadir:

• Para los siguientes post, vamos a ir configurando algunos de estos tipos de almacenamiento, como van a ser, LVM, LVM-Thin, Directorio, CIFS, NFS, ZFS, iSCSI, etc…
• En este link podemos ver una comparativa de los distintos tipos de almacenamiento en Proxmox.

Estos post los vamos a dividir en las siguientes entradas:

• Agregar almacenamiento LVM o LVM-Thin en Proxmox VE 9.0
• Agregar almacenamiento ZFS en Proxmox VE 9.0
• Agregar almacenamiento tipo Directorio en Proxmox VE 9.0
• Agregar almacenamiento CIFS en Proxmox VE 9.0
• Agregar almacenamiento NFS en Proxmox VE 9.0

Saludos

En este post vamos a ver como ampliar el disco de sistema en una máquina virtual Ubuntu Server 24.04 LTS desplegada en una infraestructura de VMware vSphere, lo haremos con la máquina iniciada y sin detenerla.

• Como podemos ver, tenemos esta máquina virtual Ubuntu Server 24.04 LTS con el disco de sistema de 50 GB:

• Ejecutamos fdisk -l, lsblk o df -h para ver la información del disco:

• Sin apagar ni detener la máquina virtual, ampliamos el disco de sistema a 100 GB:

• Ahora, para que el sistema detecte los nuevos parámetros del disco modificado, ejecutamos echo «1» >> /sys/block/sda/device/rescan:

• Ahora ejecutamos growpart /dev/sda 2 para ajustar la partición después de haber ampliado el almacenamiento, el 2 significa el número de la partición, debemos de dejar un espacio entre el nombre del dispositivo y el número de la partición:

• Volvemos a realizar un fdisk -l, lsblk o df-h y cómo podemos ver, ya tenemos el disco y la partición con los 100 GB de la ampliación:

• Para terminar, ejecutamos resize2fs /dev/sda2 para aumentar el tamaño del sistema de archivos:

• Para verificar que todo está correcto, volvemos a realizar un fdisk -l, lsblk o df-h y vemos que la partición ya la tenemos ampliada a 100 GB:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como liberar espacio del disco /storage/archive del vCenter Server Appliance, ya que seguramente os habéis encontrado con este disco lleno en más de una ocasión.

• Si accedemos a la interfaz VAMI del vCenter (puerto 5480), sobre Supervisar > Discos podemos ver, el estado de uso de capacidad de todos los discos de nuestro vCenter, puede ser que en más de una ocasión nos encontremos con el disco número 13, partición archive sin espacio, en este caso, sólo tenemos ocupado un 21,4%:

• Si accedemos por SSH también podemos ver el uso de ocupación con el comando df -h:

• Para liberar espacio nos situamos en cd /storage/archive/vpostgres y si hacemos un ls -lsahn podemos ver muchos de los archivos .gz que se utilizan como historial, estos archivos hacen que el disco se vaya llenando poco a poco:

• Para solucionar este problema y liberar espacio en nuestro vCenter ejecutamos este comando find -name «*.gz» -type f -mtime +30 -exec rm -f {} \; que depura los archivos con más de 30 días, aquí podemos poner el número de días que nos interese:

• Si volvemos a realizar un ls -lsahn podemos ver que nos ha eliminado los ficheros con más de 30 días:

• Y si hacemos un df -h podemos todo el espacio que ha liberado:

• Si accedemos de nuevo a la interfaz VAMI del vCenter (puerto 5480), sobre Supervisar > Discos podemos ver, el espacio que ha liberado sobre el disco número 13 partición archive, tarda unos minutos en refrescar:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo ampliar un disco de datos en una máquina virtual Linux en Azure, vamos a realizar la ampliación de 32 GB a 64 GB.

• Como podemos ver, esta es nuestra máquina Ubuntu 20.04 en Azure con el disco de datos de 32 GB:

• Ahora vamos a aumentar el tamaño del disco de 32 GB a 64 GB, para ello, debemos de Detener la máquina:

• Una vez detenida cambiamos el tamaño del disco:

• Como vemos, ya lo hemos cambiado a 64 GB:

• Volvemos a iniciar la máquina:

• Ahora accedemos a nuestra máquina Linux por SSH y ejecutamos fdisk -l, lsblk y df -h para listar nuestros discos y ver los puntos de montaje, y cómo podemos ver, tenemos el disco de Datos con el nuevo tamaño de 64 GB, aunque la partición todavía se encuentra con los 32 GB:

• Para proceder con la ampliación, desmontamos el punto de montaje de la partición umount /opt/datos y con df -h vemos que ya no está montado:

• Para la ampliación vamos a usar la utilidad parted, y ejecutamos parted /dev/sdc con print y Fix nos muestra la capacidad del disco y la capacidad que está utilizando nuestra partición:

• Con el comando resizepart 1 100% ampliamos la partición con todo lo disponible que tengamos en el disco, el 1 significa que vamos a ampliar la partición 1, en este caso la única que tenemos en el disco, quit para salir de parted:

• Con el comando resize2fs /dev/sdc1 lo ejecutamos y nos indica que debemos antes de realizar un chequeo del disco con e2fsck -f /dev/sdc1 y una vez realizado el chequeo volvemos a ejecutar resize2fs /dev/sdc1 para ampliar el sistema de ficheros con la nueva capacidad, como podemos ver lo ha realizado correctamente:

• Volvemos a montar la partición de datos con mount /opt/datos y con df -h y lsblk vemos que ya está todo montado con la nueva capacidad de 64 GB:

Saludos y epsero que os sea de ayuda

En este post vamos a ver cómo desplegar y configurar un disco de datos en una máquina virtual Linux en Azure.

Para explicar este laboratorio, tenemos una máquina virtual con Ubuntu 20.04 en nuestra infraestructura de Azure, con un disco de sistema de 30 GB y otro disco de datos de 32 GB, el despliegue de máquinas Linux en Azure ya lo vimos en otro post, por si le queréis echar un ojo, pues bien, el tema que nos ocupa hoy es la configuración de este segundo disco de datos en nuestra máquina virtual Ubuntu, ya que una vez añadido a la máquina tenemos que configurar la tabla de particiones, particionarlo, darle formato y montarlo.

• Como podemos ver, esta es nuestra máquina Ubuntu 20.04 en Azure con los dos discos que hemos comentado, uno para Sistema y otro para Datos:

• Ahora accedemos a nuestra máquina Linux por SSH y ejecutamos fdisk -l y lsblk para listar nuestros discos, y cómo podemos ver, tenemos el disco de Datos de 32 GB:

• Para particionar el disco vamos a usar la utilidad parted, aquí debemos de tener en cuenta, si el tamaño del disco es de 2 TB o superior, debemos usar la creación de particiones GPT, y si el tamaño del disco es menor de 2 TB, podemos usar la creación de particiones de MBR o GPT, en mi caso, siempre uso GPT, por si en un futuro vamos ampliando el disco no encontrarnos con esta limitación.
• Ejecutamos por tanto parted /dev/sdc –script mklabel gpt mkpart datos ext4 0% 100% para establecer la tabla de particiones como GPT, la etiqueta como datos, el sistema de ficheros como ext4 y usamos todo el espacio disponible del disco:

• Con el comando mkfs.ext4 /dev/sdc1 formateamos el disco con el sistema de ficheros ext4:

• Con el comando partprobe /dev/sdc1 garantizamos que el kernel reconozca inmediatamente la nueva partición y el sistema de archivos:

• Ahora nos creamos el directorio dónde vamos a montar el nuevo disco de datos, utilizaremos mkdir /opt/datos y mount /dev/sdc1 /opt/datos:

• Para que nuestro disco de datos se quede montado permanentemente, vamos a utilizar el comando blkid para buscar el UUID de la unidad nueva:

• Una vez que tenemos el UUID del disco editamos el fichero fstab con nano /etc/fstab:

• Introducimos esta línea UUID=»59f7b18e-b3e8-4334-906e-3987cdbf8318″ /opt/datos   ext4   defaults,nofail   1   2 y guardamos los cambios:

• Si ejecutamos el comando df -h y lsblk podemos ver como el nuevo disco de datos ya lo tenemos configurado y montado:

Saludos y espero que os sea de ayuda

En este post vamos a ver Azure Files, los recursos compartidos de archivos en la nube totalmente administrados podemos acceder con los protocolos SMB y NFS estándar del sector. Los recursos compartidos de archivos de Azure se pueden montar simultáneamente en implementaciones de Windows, Linux y macOS en el entorno local o en la nube. También se pueden almacenar en la memoria caché de los servidores Windows Server con Azure File Sync, lo que permite un acceso rápido cerca de donde se utilizan los datos.

Este post lo vamos a dividir en cuatro entregas:

• Azure Storage – Azure Files con Active Directory local – Habilitar la autenticación Active Directory
• Azure Storage – Azure Files con Active Directory local – Habilitar permisos de nivel de recurso compartido
• Azure Storage – Azure Files con Active Directory local – Asignar permisos de nivel de archivo o directorio
• Azure Storage – Azure Files con Active Directory local – Montar el recurso compartido de archivos con credenciales de AD

Saludos.

En este post vamos a ver el Explorador de Azure Storage, se trata de una herramienta bastante interesante llamada Explorador de Storage, es una aplicación que nos podemos instalar en nuestro equipo o en un servidor para administrar fácilmente los recursos de almacenamiento en la nube de Azure desde cualquier lugar.

• Para descargar la herramienta, accedemos a Nuestra cuenta de almacenamiento > Información general > Herramientas para desarrolladores > Explorador de Storage, si pinchamos en la herramienta nos manda directamente a la web para su descarga:

• Como podemos ver, tenemos la opción de descargarla para distintas plataformas, en mi caso Windows:

• Como podemos ver, ya la tenemos descargada:

• Ahora la vamos a instalar sobre nuestro servidor de ficheros, la instalo solo para mi usuario, es una instalación típica de Windows:

• Nos abrimos Microsoft Azure Storage Explorer:

• En primer lugar, vamos a ver como conectarnos a través de nuestra suscripción de Azure:

• Seleccionamos un entorno de Azure, clic en Siguiente:

• Comienza a redirigirnos a la página de inicio de sesión:

• Como podemos ver, ya hemos registrado el Inquilino y la suscripción, abrimos el explorador:

• Si accedemos a Nuestra cuenta de almacenamiento > Blob Containers > Contenedor podemos ver el contenido de nuestros blobs, desde aquí vamos a poder cargar, descargar archivos, crear carpetas, copiar, pegar, cambiar nombres, eliminar:

• Para terminar, vamos a ver otra opción, que va a ser conectarnos con Azure Storage explorer, a través de una cuenta de almacenamiento, en lugar de hacerlo por suscripción como lo hemos realizado anteriormente, para ello, accedemos a Conectar > Servicio o cuenta de almacenamiento:

• Seleccionamos el Nombre y la clave de la cuenta, clic en Siguiente:

• Introducimos la información de nuestra cuanta de almacenamiento de Azure, Nombre de la cuenta, Clave de la cuenta y el Dominio de almacenamiento, clic en Siguiente:

• Nos muestra un resumen y conectamos:

• Una vez agregada la cuenta, abrimos el explorador:

• Como podemos ver, ya tenemos acceso a nuestra cuenta de almacenamiento de Azure, y podemos acceder al contenedor que nos creamos anteriormente:

Saludos y espero que os sea de ayuda

En este post vamos a ver Azure Blob Storage, que es la solución de almacenamiento de objetos de Microsoft para la nube. El almacenamiento de blobs está optimizado para almacenar grandes cantidades de datos no estructurados. Los datos no estructurados son datos que no se ciñen a ningún modelo de datos o definición concretos, como texto o datos binarios.

Blob Storage está diseñado para:

• Visualización de imágenes o documentos directamente en un explorador.
• Almacenamiento de archivos para acceso distribuido.
• Streaming de audio y vídeo.
• Escribir en archivos de registro.
• Almacenamiento de datos para copia de seguridad y restauración, recuperación ante desastres y archivado.
• Almacenamiento de datos para el análisis en local o en un servicio hospedado de Azure.

• Lo primero que vamos a realizar será crearnos un dominio personalizado para nuestra cuenta de almacenamiento en Azure, para ello, accedemos a Cuentas de almacenamiento > NuestraCuenta > Redes > Dominio personalizado > Opción 1 > Agregamos nuestro Nombre de dominio > Guardar:

• Antes de Guardar, nos hemos creado, el registro del tipo CNAME en nuestro proveedor de DNS, tal y como nos indica la opción 1:

• Ahora sobre nuestra cuenta de almacenamiento de Azure, nos vamos a crear un Contenedor, accedemos a Almacenamiento de datos > Contenedores > + Contenedor.
• Un contenedor organiza un conjunto de blobs, de forma parecida a un directorio en un sistema de archivos. Una cuenta de almacenamiento puede contener un número ilimitado de contenedores y un contenedor puede almacenar un número ilimitado de blobs:

• Le indicamos el Nombre el Nivel de acceso público y Crear:

• Como podemos ver ya lo tenemos creado:

• Si accedemos al contenedor, aquí podemos ver, las distintas opciones para su administración:

• Ahora vamos a cargar un fichero en el contenedor, para ello, damos clic a Cargar:

• En Cargar blob, le indicamos el fichero a cargar, y sobre Avanzado elegimos el Tipo de autenticación que será por Clave de cuenta, el Tipo de blob que será Blob en bloques, el Tamaño del bloque que lo dejamos en 4 MB, el Nivel de acceso que será tipo Frecuente, el Ámbito de cifrado que será el predeterminado y damos clic a Cargar:

• Aquí lo tenemos cargado:

• Si accedemos al fichero, podemos descargarlo:

• Ahora desde nuestra cuenta de almacenamiento, podemos acceder al Explorador de Storage y si nos vamos a CONTENEDORES DE BLOB podemos ver los contenedores creados con sus blobs, desde este explorador vamos a poder cargar, descargar archivos, crear carpetas, copiar, pegar, cambiar nombres, eliminar:

Saludos y espero que os sea de ayuda

En este post vamos a ver las cuentas de almacenamiento en Microsot Azure, una cuenta de almacenamiento es un recurso para poder tener los diferentes tipos de almacenamiento en Azure Storage, esta cuenta de almacenamiento se encarga de agrupar los distintos servicios de Azure Storage.

• Para crear una cuenta de almacenamiento accedemos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Opciones avanzadas, en principio, lo dejaremos todo por defecto, con un nivel de acceso frecuente en el Blob Storage, luego crearemos otra cuenta con un nivel de acceso esporádico:

• Sobre Redes, configuramos el Método de conectividad como Punto de conexión público (todas las redes) y la Preferencia de enrutamiento como Enrutamiento de red de Microsoft:

• Sobre Protección de datos, lo dejamos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles, clic en Siguiente:

• Aquí nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos a Cuentas de almacenamiento, podemos ver que ya la tenemos creada:

• Si accedemos a la Cuenta de almacenamiento, tendremos las distintas opciones para poder configurarla y administrarla:

• Ahora nos vamos a crear otra Cuenta de almacenamiento, las configuraciones durante la creación van a ser las mismas, excepto que esta nueva cuenta la vamos a configurar con un nivel de acceso esporádico en el Blob Storage, la utilizaremos, por ejemplo, para almacenar datos de copias de seguridad:

• Si nos vamos a Cuentas de almacenamiento, podemos ver que ya la tenemos creada:

• Y que el nivel de acceso es Esporádico:

• A partir de ahora, cuando nos creemos un servicio que necesite de Azure Storage, podemos usar cualquiera de estas dos cuentas, ya sean los accesos frecuentes o esporádicos.

Saludos y espero que os resulte de ayuda

En este post vamos a ver como sustituir un disco averiado de un Raid-5 en una Synology RS819.

• Accedemos a Inicio > Administrador de almacenamiento:

• Nos vamos a Grupo de almacenamiento, y cómo podemos ver, el grupo de almacenamiento nos indica que está en un estado de advertencia, debido a que el disco 3 está con errores:

• Si accedemos a HDD/SSD podemos ver que el disco 3 está fallando:

• Ahora sacamos de la Synology el disco averiado e introducimos el nuevo disco de la misma capacidad, como podemos ver, aquí tenemos el nuevo disco, que nos lo muestra en buen estado y No iniciado:

• Si nos vamos a Grupo de almacenamiento, nos muestra que el RAID-5 está degradado, y nos indica cómo solucionar el problema:

• Nos vamos entonces a Acción > Reparar:

• Nos indica que tenemos el nuevo disco número 3 que hemos sustituido, disponible para agregarlo al RAID-5, clic en Siguiente y OK:

• Confirmamos y aplicamos:

• Como podemos ver, comienza a reparar nuestro RAID-5:

Saludos y espero que os sea de ayuda