13-02-2022, 02:30 PM
TS-364 como servidor de aplicaciones + backup datos (secundario).
|
¡ADVERTENCIAS!
1. No soy un experto en QNAP ni SO Linux, así que hacer un doble check de lo que voy a comentar. 2. Tener en cuenta que se va a tocar por línea de comando configuraciones de raid, que cada uno se haga responsable. 3. Fuente original de donde he sacado la info (literal): https://forum.qnap.com/viewtopic.php?t=130788 En el post indicado, Dagma contempla un uso de la NAS en el que dispone de bahías de HD mecánicos y SSD o NMVE, donde los mecánicos solo giran cuando son usados al copiar/leer datos de ellos y en el SSD/NMVE vaya los datos de sistemas, fichero swap, para que no se activen los mecánicos. Puede ser una perogrullada, pero no lo es. Mi equipo. TS-364 con los siguientes discos y la nomenclatura que se verán al listar los raid. Tened en cuenta que en vuestros equipos los nombres de los discos es posible que cambien. HD1 -> sda HD2 -> sdb HD3 -> sdc (forman un raid5) NMVe1 -> nvme1n1p1 NMVe1 -> nvme1n1p4 (forman un raid1) Por un lado, y ya teniendo en el disco SSD/NMVe la parte de sistema, QTS hace un par de configuraciones que no se ven ni se pueden reconfigurar via web, y son: 1. Dos RAID 1 que monta QTS entre los distintos discos para replicar los datos de Sistemas (no se si todos los ficheros o partes) para tener mayor redundancia. a. ¿Cómo se puede ver? cat /proc/mdstat (muestra los raid y las unidades que lo componen) Hay que centrarse en las entradas de los raid1 md13 y md9 donde QTS va a replicar ficheros de sitemas: En mi caso me devuelve (entre otros) los radid mencionados: md13 : active raid1 sda4[0] sdb4[128] nvme1n1p4[2] sdc4[1] md9 : active raid1 sda1[0] sdb1[128] nvme1n1p1[2] sdc1[1] b. ¿Qué hacer para que estos datos no estén en los HD mecánicos?. Se fuerza un fallo de esos discos en esos raid (en mi caso): sudo mdadm /dev/md9 --fail /dev/sda1 sudo mdadm /dev/md9 --fail /dev/sdb1 sudo mdadm /dev/md9 --fail /dev/sdc1 sudo mdadm /dev/md13 --fail /dev/sda4 sudo mdadm /dev/md13 --fail /dev/sdb4 sudo mdadm /dev/md13 --fail /dev/sdc4 c. Se puede comprobar de nuevo con el comando cat /proc/mdstat que ya no aparecen en los raid. d. Como estos cambios no sobreviven a los reinicios, hay que hacer un pequeño script que lance ese fallo de los discos y meterlo en el autorun (fichero que se ejecuta cada vez que arranca QTS). i. Crear script. Con vuestro editor favorito, y eligiendo la carpeta que deseéis (yo he utilizado una nueva compartida en mi raid1 de NMVE llamado Scripts): El contenido del fichero desconexion.sh (nombre que he utilizado yo pero podéis poenerle el que quedais) es: #!/bin/bash echo "Desconectando de md9" sudo mdadm /dev/md9 --fail /dev/sda1 sudo mdadm /dev/md9 --fail /dev/sdb1 sudo mdadm /dev/md9 --fail /dev/sdc1 echo "Desconectando de md13" sudo mdadm /dev/md13 --fail /dev/sda4 sudo mdadm /dev/md13 --fail /dev/sdb4 sudo mdadm /dev/md13 --fail /dev/sdc4 ii. Dar permisos de ejecución al fichero: chmod +x desconexion.sh iii. A continuación hay que crear el fichero autorun.sh. Para ello primero hay que montar la partición /tmp/config. El problema que esta partición no se monta de igual manera en todas las QNAP. En la siguiente entrada de la wiki de QNAP podéis encontrar las distintas opciones. https://wiki.qnap.com/wiki/Running_Your_...at_Startup En mi caso (que no venia en la wiki y tuve que estar probando): mount -t ext2 /dev/mmcblk0p6 /tmp/config iv. En la ruta /tmp/config se crea el fichero autorun.sh con la ejecución del script que se acaba de crear antes de desconexión: #!/bin/bash sudo /share/Scripts/desconexion.sh v. Habilitar via web el autorun y comprobar que aparece el contenido. vi. Permisos de ejecución del autorun.sh con: sudo chmod +x /tmp/config/autorun.sh vii. Y se puede lanzar para verificar que funciona correctamente: ./ autorun.sh viii. Verificado que funciona desmontamos el recurso: Sudo umount /tmp/config ix. Reinicar la nas y comprobar que los discos no aparecen en los raid md13 y md9 FIN PARTE 1. CONTINUARÁ |
Users browsing this thread: 1 Guest(s)