tareas # 3942 (en curso): implementación nas en … · luego de descartar por el momento freenas,...

Almacenamiento en red - Tareas #3929

Tareas # 3942 (En curso): Implementación NAS en CURE

Pruebas con OpenMediaVault

01/15/2015 04:40 PM - Victor Alem

Status: Resuelta Start date: 07/08/2014

Priority: Normal Due date: 01/20/2016

Assignee: Victor Alem % Done: 100%

Category: Estimated time: 0.00 hour

Target version: Spent time: 4.00 hours

Description

Luego de descartar por el momento FreeNas, probamos OpenMediaVault.

Related issues:

Related to Almacenamiento en red - Tareas # 3917: Instalación de FreeNas en e... Rechazada 07/08/2014 07/08/2014

Follows Licitación 59/2013 Servidores - Tareas # 3126: Seguimiento de entrega... Cerrada 07/07/2014

History

#1 - 01/16/2015 04:57 PM - Pablo García

- Parent task set to #3942

#2 - 01/16/2015 05:30 PM - Victor Alem

- % Done changed from 0 to 40

Logré instalar el OpenMediaVault (OMV) e interconectarlo (iscsiadm mediante) con el storage HP. Ahora para el aprovisionamiento de los discos y lograr

tocar lo menos posible, pretendo que, cuando se cree/elimine un volumen en el storage, se vea reflejado en el OMV.

Lo primero que hice fue que en el arranque de open-iscsi, el demonio se conectase solo a los targets, para esto fue necesario configurar en el archivo

/etc/iscsi/iscsid.conf la siguiente línea:

node.startup = automatic

y luego, en la configuración individual del nodo (en el fichero /etc/iscsi/nodes/ * / * /default):

node.conn[0].startup = automatic

y verificar que en el archivo /etc/iscsi/iscsid.conf la opción node.leading_login esté en "No".

Con esta configuración, cuando agregamos un volumen en el storage, luego vamos al OMV y vemos en seguida reflejado el cambio (haciendo un "scan"

en el menú Almacenamiento->Discos Físicos.

Hasta ahora no he podido que, cuando se elimina un volumen del storage, se vea reflejado el cambio en el OMV. Lo que veo es que cuando borro el

disco, ejecutando el comando "fdisk -l" efectivamente desaparece el dispositivo, pero listando el directorio /dev/disk/by-path/ veo aún el enlace simbólico a

un dispositivo de bloque y si listo los datos de la sesión iSCSI veo conectada la unidad que eliminé.

Sigo investigando....

#3 - 01/20/2015 03:12 PM - Victor Alem

09/28/2018 1/4

http://openmediavault.org/

Lo que tampoco funciona es que, cuando expandimos un LUN, los cambios no se reflejan haciendo un "scan" en OMV.

Tenemos esta línea del log:

Warning! Received an indication that the LUN assignments on this target have changed. The Linux SCSI layer does not automatically remap LUN

assignments.

#4 - 01/20/2015 05:13 PM - Victor Alem

Cambiamos la lógica: Creamos un solo volumen en el storage y lo levantamos por iSCSI desde Atlático. Luego desde Atlántico repartimos. Por lo tanto no

tenemos (por ahora) el problema con los volúmenes y actualizando los LUNs.

#5 - 01/20/2015 05:18 PM - Victor Alem


Ya levantamos el volumen del storage (pacífico) desde el OMV (atlántico). Tenemos un solo volumen para compartir. ;-)

Arrancamos con la segunda etapa: Dividir este disco y compartirlo con los servidores.

#6 - 01/23/2015 09:03 AM - Daniel Viñar Ulriksen

Quzás que estas tareas merezcan tener un sub-proyecto NAS. ¿no?

#7 - 01/23/2015 11:10 AM - Victor Alem

Daniel Viñar Ulriksen escribió:


Sin duda, debemos diseñar los criterios de utilización de los dispositivos de almacenamiento. Se me ocurre en ese proyecto contestarse preguntas tales

como:

- ¿Cuándo utilizamos los recursos de nuestra red NAS?

- ¿Qué aplicaciones? contestaría algunas:

- Respaldos

- Servidores de archivos

- Cloud

- ¿dónde ubicamos estos equipos?

- etc...

Y también armar planes de evolución y escalabilidad para la arquitectura que estamos pensando.

Seguimos...

#8 - 01/29/2015 08:38 AM - Daniel Viñar Ulriksen

09/28/2018 2/4


Sin duda,

Ok, pasé las tareas a un sub-proyecto, con un grupo de proyecto específico.

#9 - 01/13/2016 11:31 AM - Victor Alem

Continuamos con el diseño de la solución. Para que quede documentado:

Nos conectamos desde el servidor NAS al storage mediante el paquete open-iscsi. Esto lo hacemos porque Openmediavault no maneja desde su interfaz

para conectarse a un servidor iscsi, por tanto configuramos a línea de comandos esta(s) conexión(es).

Desde el servidor NAS (OpenMediaVault - OMV), segmentamos el espacio de almacenamiento con LVM y lo compartimos con el servidor madre. Para

que sea más transparente para los virtuales y los administradores de los mismos no tengan que preocuparse por la conexión iSCSI, eso será problema

del sysadmin del servidor madre y la solución NAS.

Hasta aquí hemos configurado todo. Nos falta configurar la conexión con un servidor madre con KVM con el OMV.

#10 - 01/15/2016 12:57 PM - Victor Alem

Procedimiento para asignar espacio del storage

Como regla general, desde el servidor NAS (OMV), le asignamos un disco iSCSI al servidor madre. Este es quién se encarga de repartirlo entre los

virtuales (como se explicó en la entrada anterior). El procedimiento es el siguiente:

- En el servidor NAS:

- Crear un LV en OMV del tamaño que deseamos asignar al servidor,

- Crear un nuevo destino iSCSI para ese servidor, colocando autenticación y asignando el dispositivo LV creado anteriormente al LUN,

- En el servidor madre:

- Instalar el paquete open-iscsi,

- Descubrir los recursos del portal:

iscsiadm -m discoverydb -t sendtargets -p ip:puerto --discover

- pueden aparecer recursos en otras interfaces de OMV (no deberían, por ahora los bloqueamos en el firewall), los eliminamos con:

iscsiadm -m node -T nombre_del_target -p ip:puerto --op delete

- agregamos inicio automático, configuramos el método de autenticación, nombre de usuario y contraseña:

iscsiadm -m node -T nombre_del_target -p ip:puerto --op update -n node.startup -v automatic

iscsiadm -m node -T nombre_del_target -p ip:puerto --op update -n node.session.auth.authmethod -v CHAP

iscsiadm -m node -T nombre_del_target -p ip:puerto --op update -n node.session.auth.username -v NOMBRE

iscsiadm -m node -T nombre_del_target -p ip:puerto --op update -n node.session.auth.password -v CONTRASEÑA

- Intentamos loguearnos al portal:

iscsiadm -m node -T nombre_del_target -p ip:puerto --login

- Si todo ha ido bien, nos aparecerá un nuevo dispositivo de bloque, por ejemplo:

root@barrancas:/etc/iscsi# ls -l /dev/disk/by-path/

total 0

lrwxrwxrwx 1 root root 9 ene 15 11:55 ip-10.10.11.2:3260-iscsi-iqn.2016-01.uy.edu.cure.atlantico:barrancas01-lun-0 -> ../../sdb

09/28/2018 3/4

- Creamos un nuevo VG en el servidor madre para identificar los discos compartidos por el servidor NAS, por ejemplo:

vgcreate storage /dev/disk/by-path/ip-10.10.11.2\:3260-iscsi-iqn.2016-01.uy.edu.cure.atlantico\:barrancas01-lun-0

- Creamos el LV para el virtual, por ejemplo:

lvcreate -l100% -n polonio storage

- Abrimos el virt-manager o la interfaz proxmox y agregamos el VG a la interfaz

- Asignamos el LV creado al virtual como dispositivo físico

- Terminamos

#11 - 01/15/2016 12:58 PM - Victor Alem

- Status changed from En curso to Resuelta


#12 - 01/18/2016 01:27 PM - Victor Alem

- Status changed from Resuelta to Comentarios

Hicimos una prueba de reinicio de los servidores y se rompió todo...

Estamos evaluando otras opciones.....

#13 - 01/20/2016 04:02 PM - Victor Alem

- Status changed from Comentarios to Resuelta

Descubrí el problema:

Parece que el plugin para manejar volúmenes lógicos de OMV, no activa los volúmenes en el inicio. La solución, poco elegante para mi gusto, fue

iniciarlos en el rc.local con el siguiente comando:

/sbin/vgchange -ay Pacifico

Y tamibén reiniciar el plug-in de iSCSI Target:

/etc/init.d/iscsitarget restart

Con esto, pasamos las pruebas de reinicio de los servidores. Hay que lograr que se apaguen en la siguiente secuencia:

1. Virtuales

2. Madre de virtuales

3. Servidor NAS

#14 - 01/20/2016 04:03 PM - Victor Alem

- Due date changed from 07/08/2014 to 01/20/2016

09/28/2018 4/4

tareas # 3942 (en curso): implementación nas en … · luego de descartar por el momento freenas,...

Documents