En este artículo os muestro como montar de forma básica un Ubuntu que actúe como servidor ISCSI y NFS. Dejaremos para posteriores entradas en mi blog como optimizarlos.
El servidor nos permitirá realizar laboratorios para nuestros entornos de virtualización, donde necesitamos por una parte almacenar las máquinas virtuales en un almacenamiento externo con alto rendimiento (ISCSI), y por otra parte otro espacio donde almacenar las ISOS para montar las máquinas virtuales así como almacenamiento de Backups de las máquinas virtuales, servidor NFS.
Así mismo también nos permitirá montar sistemas de alta disponibilidad.
Para empezar comentaros que existen en el mercado diversas soluciones FREE basadas en distribuciones Linux, que nos permiten montar sistemas similares al que os propongo, entre ellos:
Yo he decidido montarlo desde 0, es decir, directamente sobre una distribución base de Ubuntu 22.04, la última a día de hoy. De esta forma aprendemos como hacerlo, además de tenerlo todo más controlado a nivel de parches de seguridad y evolución de la distribución.
Al final del POST tenéis un video de mi canal con todo esto, pero conectando los servicios a un Servidor Windows y a un hipervisor ESXI.
Instalación de los paquetes NFS e iSCSI
Empezaremos por mostraros la distribución de Linux con la que estoy trabajando:
demo@demosrv:~$ sudo lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy
La IP del servidor Ubuntu es la 192.168.153.156/24.
Lo primero que podemos hacer en un entorno virtualizado, NUNCA en uno real, es actualizar nuestra distribución.
demo@demosrv:~$ sudo apt update demo@demosrv:~$ sudo apt upgrade
Luego instalaremos los dos paquetes necesarios.
Para el servidor NFS:
demo@demosrv:~$ sudo apt install nfs-kernel-server
Para el servidor ISCSI:
demo@demosrv:~$ sudo apt install tgt
En ambos casos los habilitaremos para que arranques de forma automática al inicio del sistema con las órdenes:
demo@demosrv:~$ sudo systemctl enable nfs-kernel-server demo@demosrv:~$ sudo systemctl enable tgt
Así mismo nos aseguramos que estén arrancados:
demo@demosrv:~$ sudo systemctl status nfs-kernel-server.service demo@demosrv:~$ sudo systemctl status tgt.service
Veremos por pantalla algo similar a lo siguiente:
demo@demosrv:~$ sudo systemctl status nfs-kernel-server.service
Por pantalla veremos algo similar a lo siguiente:
nfs-server.service - NFS server and services
Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; enabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: active (exited) since Fri 2022-11-25 02:52:38 UTC; 12min ago
Main PID: 1028 (code=exited, status=0/SUCCESS)
CPU: 9ms
Si el servicio no está activo bastará con arrancarlo manualmente:
demo@demosrv:~$ sudo systemctl start nfs-kernel-server.service demo@demosrv:~$ sudo systemctl start tgt.service
Los puertos de comunicaciones utilizados por ambos servicios son los siguientes:
2049/tcp and 2049/udp NFSV4 y NFSV3 111/tcp y 111/udp RPC (requerido solo por NFSV3) 3260/tcp y 3260/udp ISCSI 860/tcp y 860/udp ISCSI
Configuración servidor NFS
Hay que tener claros los pasos para configurar el servicio:
- Particionar y formatear el nuevo disco duro o partición
- Montarlo en la estructura de archivo de linux
- Configurar el servicio NFS
- Conectarse desde hipervisor
En mi laboratorio lo tengo montado todo sobre una versión de Trial de VM Workstation 16.2. He instalado una distribución Ubuntu 22.04 como os he mostrado antes, y he añadido tres discos duros. El primero, /dev/sda, para el sistema, el segundo, /dev/sdb, para el servicio NFS, y el tercero, /dev/sdc, para el servicio ISCI. De esta forma simulamos un mejor rendimiento si fuera un entorno real. Nada de tener todo en un disco grande con 3 particiones… Eso implica: BAJO RENDIMIENTO
Inicialmente el segundo y tercer disco no tienen ni partición ni formato. Lo podemos ver con la orden:
demo@demosrv:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS loop0 7:0 0 63,2M 1 loop /snap/core20/1695 loop6 7:6 0 62M 1 loop /snap/core20/1587 sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1M 0 part └─sda2 8:2 0 100G 0 part / sdb 8:16 0 100G 0 disk sdc 8:32 0 100G 0 disk
Igualmente lo podemos verificar de otra manera:
demo@demosrv:~$ sudo fdisk -l /dev/sdb Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 sectors Disk model: VMware Virtual S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xcd4eff0f
A diferencia del primer disco duro que si que tiene particiones:
demo@demosrv:~$ sudo fdisk -l /dev/sda Disk /dev/sda: 100 GiB, 107374182400 bytes, 209715200 sectors Disk model: VMware Virtual S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: C150C0DE-972C-4CAE-9380-C67836FC4C6E Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M BIOS boot /dev/sda2 4096 209713151 209709056 100G Linux filesystem
Lo primero será particionar el segundo disco duro que actuará de almacenamiento para el servicio NFS. Para ello invocamos la orden:
demo@demosrv:~$ sudo fdisk /dev/sdb Welcome to fdisk (util-linux 2.37.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0x87dc6fd7. Command (m for help):
Entramos en la aplicación en modo interactivo donde debemos ir pulsando las opciones que corresponden a cada acción. Si pulsamos la letra “m” veremos las diferentes opciones:
Command (m for help): m Help: DOS (MBR) a toggle a bootable flag b edit nested BSD disklabel c toggle the dos compatibility flag Generic d delete a partition F list free unpartitioned space l list known partition types n add a new partition p print the partition table t change a partition type v verify the partition table i print information about a partition
Las opciones que podemos utilizar son :
- p print the partition table
- n add a new partition
- F list free unpartitioned space
- w write table to disk and exit
- q quit without saving changes
- l list known partition types
- t change a partition type
Cómo no se trata de hacer un master en particionado, iré al grano…. Bastará con crear una nueva partición primaria que ocupe los 100 G del disco y listo 😊. En primer lugar ver el total de espacio no particionado que tenemos, que será todo…100 GB
Command (m for help): F Unpartitioned space /dev/sdb: 100 GiB, 107373133824 bytes, 209713152 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes Start End Sectors Size 2048 209715199 209713152 100G
Creamos la nueva partición pulsando “n”. Se os pedirá el tipo de partición, primaria en nuestro caso. El número de las cuatro posibles particiones primarias que podemos tener. 1 en nuestro caso, será la única que ocupa todo el disco, y finalmente el tamaño. El propone todo el tamaño indicando el primer y último sector libre. Pulsaremos <enter> a los valores por defecto. Podéis evidentemente especificar un tamaño diferente. En el vídeo os muestro cómo.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): <enter>
First sector (2048-209715199, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-209715199, default 209715199): <enter>
Created a new partition 1 of type 'Linux' and of size 100 GiB.
Podemos comprobar pulsando “p” que la partición ya está creada:
Command (m for help): p Disk /dev/sdd: 100 GiB, 107374182400 bytes, 209715200 sectors Disk model: VMware Virtual S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x87dc6fd7 Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 209715199 209713152 100G 83 Linux
Importante destacar que la partición si no le decimos lo contrario con pulsando “t” antes de crearla será del tipo 83 Linux, que ya es la que nos interesa, para formatearla posteriormente con mkfs.
Podemos salir guardando los cambios pulsando “w”
Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks.
La partición ha sido felizmente creada y ya está preparada para ser formateada 😊
demo@demosrv:~$ sudo lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:48 0 100G 0 disk └─sdb1 8:49 0 100G 0 part
También lo podemos ver con:
demo@demosrv:~$ sudo fdisk -l /dev/sdb Disk /dev/sbd: 100 GiB, 107374182400 bytes, 209715200 sectors Disk model: VMware Virtual S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x87dc6fd7 Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 209715199 209713152 100G 83 Linux
Ahora solo queda darle formato ext4 con el comando mkfs:
demo@demosrv:~$ sudo mkfs.ext4 /dev/sdb1 mke2fs 1.46.5 (30-Dec-2021) Creating filesystem with 26214144 4k blocks and 6553600 inodes Filesystem UUID: fcb3025a-56e0-4883-b872-661194ce2ccb Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Allocating group tables: done Writing inode tables: done Creating journal (131072 blocks): done Writing superblocks and filesystem accounting information: done
Ya tenemos el disco duro preparado finalmente. Con el parámetro -f nos muestra el sistema de archivos de la partición:
demo@demosrv:~$ sudo lsblk -f /dev/sdb NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sdb └─sdb1 ext4 1.0 4fde5f55-9319-4430- 91,5G 1%
Ahora nos queda “montarlo” dentro de la estructura de ficheros de nuestro sistema linux. Yo he decidido montar la partición /dev/sdb1 en la ruta /mnt/hd-nfs
Creamos en primer lugar la carpeta con la orden:
demo@demosrv:/mnt$ sudo mkdir /mnt/hd-nfs/
Luego montamos el disco duro sobre dicha carpeta:
demo@demosrv:/mnt$ sudo mount /dev/sdb1 /mnt/hd-nfs/
Ya tenemos el disco duro preparado y accesible:
demo@demosrv:/mnt/hd-nfs$ ls -la drwxr-xr-x 5 root root 4096 nov 24 09:13 . drwxr-xr-x 3 root root 4096 nov 24 09:08 .. drwx------ 2 root root 16384 nov 24 09:06 lost+found
Lo comprobamos también con la orden df:
demo@demosrv:/$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 389M 1,6M 388M 1% /run /dev/sda2 98G 7,2G 86G 8% / tmpfs 1,9G 248K 1,9G 1% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock /dev/sdb1 98G 1,4G 92G 2% /mnt/hd-nfs
Ahora tenemos que hacer que el disco esté disponible (“montado”) siempre al arrancar el sistema, para ello editamos el archivo /etc/fstab que está para eso… Añadimos la línea correspondiente:
# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda2 during curtin installation /dev/disk/by-uuid/1d241f11-2a7f-4fc3-89c1-72a137a8ab71 / ext4 defaults 0 1 /swap.img none swap sw 0 0 /dev/sdb1 /mnt/hd-nfs ext4 defaults 0 2
Reiniciamos el sistema y comprobamos que efectivamente está disponible con df -h
Un montón de texto y todavía no hemos empezado a configurar el servicio…. 😊 He creído oportuno enseñar en el mismo post como preparar el disco duro, pues es algo con lo que la gente no se siente demasiado cómoda en Linux.
Configurando el servicio NFS
Crearemos en primer lugar la carpeta que compartiremos vía NFS para ser utilizada con nuestro sistema hipervisor. En nuestro caso un PROXMOX. Podemos crear y compartir con tantos sistema como queramos carpeta diferentes con opciones distintas.
Creamos la carpeta y le asignamos los permisos oportunos. Os pongo todos los comandos del tirón:
demo@demosrv:/$ sudo mkdir /mnt/hd-nfs/nfs-proxmox demo@demosrv:/$ sudo chown nobody:nogroup /mnt/hd-nfs/nfs-proxmox/ demo@demosrv:/$ sudo chmod 777 /mnt/hd-nfs/nfs-proxmox/ demo@demosrv:/$ ls -l /mnt/hd-nfs/ drwx------ 2 root root 16384 nov 24 09:06 lost+found drwxrwxrwx 2 nobody nogroup 4096 nov 25 03:55 nfs-proxmox
Evidentemente podéis ajustar los permisos en función de las necesidades de cada uno.
El siguiente paso es compartir la carpeta vía NFS. Para ellos editamos el archivo /etc/exports
demo@demosrv:/$ sudo nano /etc/exports
El contenido está auto comentado y es muy sencillo configurarlo:
# /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # /mnt/hd-nfs/nfs-proxmox 192.168.153.60(rw,sync,no_subtree_check)
Los parámetros:
| /mnt/hd-nfs/nfs-proxmox | Carpeta que estamos compartiendo con NFS |
| 192.168.153.60 | IP del servidor PROXMOX en nuestro caso. |
| rw | Monta el directorio compartido como editable. El host remoto pude hacer cambios en el directorio: editar, borrar, …. |
| sync | Los cambios en los datos del archivo se realizan en el disco de inmediato, lo que tiene un impacto en el rendimiento, pero es menos probable que provoque la pérdida de datos si no tenemos SAI |
| no_subtree_check | Esta opción desactiva la verificación de subárboles, lo que tiene implicaciones leves de seguridad, pero puede mejorar la confiabilidad en algunas circunstancias. |
Podemos encontrar más información y ejemplo en el siguiente artículo: Understanding the /etc/exports File, al igual que recurriendo a la ayuda vía man o vía internet. Un ejemplo: https://linux.die.net/man/5/exports
En un entorno de producción DEBEMOS EXAMINAR todos los parámetros posibles que mejoren la seguridad y el rendimiento. Recordad que estoy es una máquina para un entorno de laboratorio, no de producción.
Tal como pone la ayuda, podemos compartir dicha carpeta con más hosts simplemente añadiendo nuevas líneas con las IPs de dichos hosts. No es nuestro caso.
Guardaremos el fichero y los cambios estarán disponibles en el siguiente reinicio del sistema, o bien si reiniciamos manualmente el servicio:
demo@demosrv:~$sudo systemctl restart nfs-kernel-server.service
Con el comando export -a podemos evitar tener que reiniciar el servicio 😉
Ya solo queda conectarlo a nuestro servidor PROXMOX. Para ello en la opción correspondiente DataCenter 🡪 Storage
Añadimos un Storage NFS: Add 🡪 NFS
Añadimos la información para la conexión, que es evidente:
Y en unos segundos ya está disponible:
Ya podemos ir subiendo las imágenes ISO que nos interesen:
Si queremos mejorar la seguridad, con NFS v4 tendremos que verificar si nuestro servidor lo admite. Podemos comprobarlo de la siguiente manera:
demo@demosrv:~$ sudo cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 +4.2
También podemos establecer en el firewall órdenes que solo permitan conexiones desde la IP de nuestro PROXMOX. Si nuestro firewall está con política por defecto ACCEPT podemos crear las siguientes reglas iptables:
ServidorNFS=192.168.153.60 iptables -A INPUT -s $ServidorNFS -p tcp --dport 111 -j ACCEPT iptables -A INPUT -s $ServidorNFS -p tcp --dport 2049 -j ACCEPT iptables -A INPUT -s $ServidorNFS -p udp--dport 111 -j ACCEPT iptables -A INPUT -s $ServidorNFS -p udp--dport 2049 -j ACCEPT iptables -A INPUT -p tcp --dport 111 -j DROP iptables -A INPUT -p tcp --dport 2049 -j DROP iptables -A INPUT -p udp --dport 111 -j DROP iptables -A INPUT -p udp --dport 2049 -j DROP
Los puertos 111/tcp y 2049/tcp son los que utilizan NFS v3 y v4 respectivamente. Aunque si suplantan la IP del servidor PROXMOX estamos perdidos….. Tendrán acceso a todo….
Configuración servidor ISCSI
iSCSI (Abreviatura de Internet SCSI) es un estándar que permite el uso del protocolo SCSI sobre redes TCP/IP. iSCSI es un protocolo de la capa de transporte definido en las especificaciones SCSI-3. Otros protocolos en la capa de transporte son SCSI Parallel Interface y canal de fibra.
Los pasos para la configuración son muy sencillos:
- Desinstalar servicio LVM2 en el servidor Ubuntu
- Configuración del protocolo ISCSI en el servidor, Target
- Conexión desde el cliente, Inicializador
El primer punto importante a tener en cuenta es que para evitar problemas posteriores con PROXMOX, tenemos que desinstalar el servicio LVM2 en el servidor Ubuntu. Da problemas con la gestión de volúmenes con PROMOX.
Para ello podemos verificar si está o no instalado mediante la orden:
demo@demosrv:~$ sudo apt list lvm2 Listando... Hecho lvm2/jammy 2.03.11-2.1ubuntu4 amd64
En este caso no lo tengo instalado, pero de estarlo bastará con ejecutar la orden:
demo@demosrv:~$ sudo apt remove --purge LVM2
Si necesitamos sí o sí LVM2 en el servidor que actúa como iSCSI server, os tocará bregar con los filtros de LVM al arrancar. Es decir, evitar que detecte el dispositivo iSCI montado en el PROXMOX y tome el control, evitando de esta manera que PROXMOX lo vuelva a montar al reiniciar el sistema. Consultar directivas de Filter en los archivos /etc/lvm/lvm.conf y /etc/lvmlocal.conf.
Ya podemos empezar con al configuración del servidor. En primer lugar realizaremos una pequeña configuración de resolución de nombres que utilizaremos posteriormente para definir el Target en el servidor.
En caso de tener un servidor DNS en nuestra red debemos añadir un registro apuntando a nuestro servidor ISCSI. En mi servidor de Laboratorio, no dispongo de un servidor DNS, y por lo tanto añado un registro en el archivo /etc/hosts
demo@demosrv:~$ cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 demosrv # IP del servidor ISCSI 192.168.153.156 demosrv.mytcpip.loc
Comprobamos que podemos resolver por nombre:
demo@demosrv:~$ ping demosrv.mytcpip.loc -c 1 PING demosrv.mytcpip.loc (192.168.153.156) 56(84) bytes of data. 64 bytes from demosrv.mytcpip.loc (192.168.153.156): icmp_seq=1 ttl=64 time=0.024 ms --- demosrv.mytcpip.loc ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.024/0.024/0.024/0.000 ms
Recordad que vamos a utilizar el tercer disco duro entero para ISCSI. En este caso no es necesario particionarlo ni prepararlo con antelación. Siempre, insisto, que deseemos aprovechar el disco entero. En caso contrario toca crear la partición del tamaño que nos interese. Lo que no es necesario es formatear la partición, dado que de crear el sistema de archivos se encargará el propio sistema cliente, es decir, nuestro hipervisor.
Comprobamos que el tercer disco duro es accesible desde el servidor ISCSI, además de observar que está sin particionar:
demo@demosrv:~$ lsblk /dev/sdc NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdc 8:32 0 100G 0 disk
Una vez comprobado tanto el registro DNS como que el disco duro está disponible pasamos a la configuración.
La configuración se basa en dos componentes, el primero definir el Target en el servidor. Punto donde se conectará el cliente. En segundo componente es el inicializador, encargado de la conexión desde el cliente.
La configuración del TARGET es a nivel básico sumamente sencilla. Dentro de la carpeta /etc/tgt tenemos toda la configuración del servicio:
demo@demosrv:~$ ls -la /etc/tgt drwxr-xr-x 3 root root 4096 nov 23 09:42 . drwxr-xr-x 105 root root 4096 nov 26 17:40 .. drwxr-xr-x 2 root root 4096 nov 24 09:57 conf.d -rw-r--r-- 1 root root 199 feb 16 2022 targets.conf
En distribuciones anteriores, toda la configuración de los TARGETS se realizaba en el fichero targets.conf. Actualmente recomiendan que cada definición la pongamos dentro de la carpeta conf.d. Una por TARGET.
Vamos a crear la configuración de nuestro TARGET dentro de conf.d con el nombre de target01.conf
demo@demosrv:~$ ls -la /etc/tgt/conf.d/ drwxr-xr-x 2 root root 4096 nov 24 09:57 . drwxr-xr-x 3 root root 4096 nov 23 09:42 .. -rw-r--r-- 1 root root 575 nov 24 09:57 target01.conf
Os enseño el contenido del fichero target01.conf que he creado:
demo@demosrv:~$ cat /etc/tgt/conf.d/target01.conf <target iqn.2022-11.loc.mytcpip.demosrv:target01> # provided devicce as a iSCSI target backing-store /dev/sdc # iSCSI Initiator's IQN you allow to connect initiator-name iqn.1993-08.org.debian:01:944868bdf19 # IP Initiator initiator-address 192.168.153.60 # incominguser username password </target>
Importante en primer lugar tener claro el label que hemos utilizado parea definir el target.
<target iqn.2022-11.loc.mytcpip.demosrv:target01>
- iqn: literal… Iscsi Qualified Name. Lo escribimos tal cual.
- 2022: año en que hemos creado el target
- 11: mes en que hemos creado el target
- loc.mytcpip.demosrv: nuestro nombre FQDN de máquina al revés
- target01: una label que identifica el target.
Os detallo a continuación el resto de directivas empleadas:
| backing-store | Indica el disco /dev/sdc que estamos utilizando entero como target. Si fuera por ejemplo una partición pondríamos /dev/sdc4. |
| initiator-name | El nombre del Inicializador del cliente al que le estamos dando permiso para conectarse. Puede ser más de uno.
Cada cliente tiene su propio nombre. Para un sistema PROXMOX el nombre lo podemos obtener del fichero /etc/iscsi/initiatorname.iscsi. root@pve:/etc/iscsi# cat /etc/iscsi/initiatorname.iscsi En el video veréis un ejemplo diferente de conexión.. Con un cliente Windows y con un ESXI. Si no especificamos ninguno, estamos dando permiso a cualquier iniciador para conectarse, lo que representa un riesgo de seguridad. |
| initiator-address | Otra media de seguridad adicional. La IP del cliente que permitimos se conecte. En nuestro caso la del PROMOX. Al igual que antes si no podemos ninguna estamos autorizando a cualquier cliente. Imaginad el riesgo… Cualquier persona se conecta y puede hacer lo que sea…. Copiar, borrar, formatear… |
Como tercera medida de seguridad, se aconseja establecer un usuario y contraseña de acceso al TARGET. Yo en primer lugar suelo establecer la conexión sin dichos datos, y luego cuando ya verifico que todo ok, establezco usuario y contraseña para el acceso. En un sistema de producción es indispensable…
Pasamos a reiniciar el servicio y comprobar que está activo.
demo@demosrv:~$ sudo systemctl restart tgt.service
Vemos que no hemos tenido problema alguno:
demo@demosrv:~$ sudo systemctl status tgt.service tgt.service - (i)SCSI target daemon Loaded: loaded (/lib/systemd/system/tgt.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2022-11-26 18:02:06 UTC; 5s ago Docs: man:tgtd(8)
El puerto está evidentemente a la escucha:
demo@demosrv:~$ sudo lsof -i :3260 tgtd 2024 root 6u IPv4 45858 0t0 TCP *:iscsi-target (LISTEN)
Podemos ver más información mediante el comando tgtadm:
demo@demosrv:~$ sudo tgtadm --mode target --op show Target 1: iqn.2022-11.loc.mytcpip.demosrv:target01 System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No SWP: No Thin-provisioning: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00010001 SCSI SN: beaf11 Size: 107374 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No SWP: No Thin-provisioning: No Backing store type: rdwr Backing store path: /dev/sdc
Ahora solo queda conectarnos desde el cliente, en nuestro caso el PROXMOX. Dentro de Datacenter 🡪 Storage 🡪 Add 🡪 iSCSI definimos las opciones:
Nos aparece una pantalla donde introducimos la IP o FQDN del servidor Ubuntu con el servicio TGT configurado y el target. En nuestro caso solo hay uno:
Al pulsar el botón Add ya lo tendremos disponible.
El disco iSCSI conectado todavía no está disponible. Debemos utilizarlo bajo LVM. Para ello, en el PROXMOX, vamos a la opción Datacenter 🡪 Storage 🡪 LVM
Y rellenamos con los datos adecuados, teniendo en cuenta la conexión ISCSI creada anteriormente:
Ya lo tendremos disponible a los pocos segundos después de pulsar el botón Add.
Os adjunto un “pantallazo” de la pestaña “Disk” al crear una VM nueva en PROMOX. Podremos seleccionar como Storage para almacenar el disco duro virtual en el volumen LVM creado: LVM-ISCI. En mi caso, y pasa instalar un Ubuntu de pruebas, le he especificado de tamaño 32GB.
Podemos ver dentro de nuestro PROXMOX el espacio libre y ocupado.
Así como el disco duro que se ha creado:
Espero que este POST-Libro por su longitud os haya gustado. En el vídeo encontraréis el proceso, pero esta vez conectando un ESXI y un sistema Windows al servidor NFS y iSCSI. Así os enseño todas las alternativas 😉
