¡Saludos entusiastas de ZimaBoard! Hoy, nos complace traerles un tutorial completo de nuestro dedicado miembro de la comunidad, Tyrehl. No solo Tyrehl te guía expertamente a través del proceso de instalación de ZFS en ZimaBoard, sino que también ofrece una visión holística del propio ZimaBoard.
Desde conocimientos de la comunidad hasta instrucciones detalladas de instalación, el artículo de Tyrehl es tu recurso integral para desbloquear todo el potencial tanto de ZFS como de ZimaBoard. Nuestro más sincero agradecimiento a Tyrehl por esta enriquecedora contribución, que une el compromiso comunitario con el conocimiento técnico. Emprendamos este viaje juntos y elevemos tu experiencia con ZimaBoard. ¡Feliz exploración!
Introducción
Las computadoras de placa única (SBC) son muy populares en escenarios de laboratorios caseros, y en los últimos años han ganado terreno en entornos profesionales y en la industria también. Hoy en día existe un gran ecosistema centrado en la computación en el borde y sistemas de pequeño factor de forma.
Es fácil conseguir un cómputo decente, con varias SBC que ofrecen 4 núcleos y mucha RAM para diversas aplicaciones. Donde usualmente fallan es en el frente del almacenamiento. Las tarjetas SD y el almacenamiento Flash en general son lentos y propensos a fallos en escenarios con muchas escrituras. Los discos conectados por USB no ofrecen la misma fiabilidad, y elegir un buen conector USB a SATA tampoco es trivial.
El ZimaBoard tiene un as bajo la manga. Dos puertos SATA, el Ethernet dual 100/1000 y varias opciones de extensión PCIe, hacen un sistema muy flexible.
¿Cuáles son los límites de lo que una SBC puede lograr de manera realista, y por qué el almacenamiento siempre es un problema? ¿Dónde está el punto medio ideal entre una máquina compacta, que no domina ninguna tarea particularmente bien, y un monstruo de cables con 6 discos SATA que requiere una fuente de alimentación ATX externa?
Este artículo tiene como objetivo explorar las fortalezas del ZimaBoard y cómo pueden aprovecharse para darle un buen uso. Sin terminar con una configuración ridícula e impráctica.
Motivación
Como se mencionó anteriormente, mucha capacidad de cómputo es fácil de desplegar y utilizar. La memoria también es barata, por lo que el almacenamiento rápidamente se convierte en el factor limitante. Cualquiera que haya tenido que lidiar con infraestructura probablemente sea consciente de esto. Solo eche un vistazo a las opciones de almacenamiento en red de k8s, las diversas plataformas que afirman traer APIs compatibles con S3 a su clúster, y lo molestas que son de desplegar y operar correctamente.
El ZimaBoard, con sus excelentes capacidades de E/S, es un gran candidato para un NAS de factor de forma pequeño o un servidor de propósito general con almacenamiento local resistente. Y aquí está el desafío: ¿cómo proporcionamos almacenamiento tolerante a fallos en un paquete de factor de forma pequeño, en una plataforma que "simplemente funciona" y es operativamente aburrida?
En el lado del hardware, nos limitaremos a usar solo dos discos de 2.5 pulgadas conectados a la alimentación y conectores SATA en la parte trasera del ZimaBoard. Esto crea una solución muy compacta sin la necesidad de una fuente de alimentación externa ni tarjetas de extensión.
Menos es más
Desplegar mucho almacenamiento es bueno, pero tener almacenamiento tolerante a fallos es aún mejor. Para eso necesitamos un sistema de archivos más avanzado que ofrezca redundancia de almacenamiento.
ZFS ofrece capacidades de RAID por software que superan a la mayoría de los controladores RAID por hardware. Es un sistema de archivos realmente excelente con muchas otras características notables como snapshots incrementales, sincronización entre sistemas remotos y pools de almacenamiento, y cifrado.
El enfoque hoy es puramente ejecutar los discos de forma redundante. Normalmente ZFS se usa para gestionar un arreglo RAIDZ. Pero como nos hemos limitado a dos discos, solo queda una opción relevante: el pool espejo ZFS. Esto efectivamente reducirá a la mitad la capacidad de almacenamiento, pero al mismo tiempo nos proporcionará mejor redundancia y la capacidad de soportar la falla de un solo disco. No es ideal, pero tendrá que servir.
Hardware
Discos
Generalmente, la comunidad de ZimaBoard recomienda a los usuarios usar discos de 2.5 pulgadas. Su principal ventaja es que no necesitan un riel de 12V para funcionar. Hay reportes de pruebas exitosas con discos de 3.5 pulgadas, así que tu experiencia puede variar. En mi caso, opté por dos SSD de 1TB. También puedes elegir HDDs si necesitas más capacidad.
Conectores y accesorios impresos en 3D
Se recomienda encarecidamente el Y-Splitter oficial para conectar y alimentar los dos discos. Hay soluciones alternativas, como usar adaptadores de alimentación USB a SATA. Esto se ve feo, pero funcionará. Para mantener todo junto, un soporte dual para HDD impreso en 3D funciona muy bien. El resultado final es un paquete muy portátil y de perfil bajo.
Los enlaces están incluidos al final del artículo. Encontré esta versión muy compacta y práctica debido a su pequeño tamaño. También existen varias placas impresas en 3D para montaje en rack, si tienes espacio para ello.
Instalando ZFS
El ZimaBoard viene con Debian por defecto. Esta es también mi recomendación personal para una distro sólida que no interfiera ni te sorprenda. Para otras distribuciones, consulta la documentación respectiva y las instrucciones de instalación de ZFS.
Antes de comenzar, recuerda actualizar a la última versión LTS si puedes. Haz una copia de seguridad de tus datos para que sea fácil desmontar todo y empezar de nuevo. Y documenta cada paso, para que la solución de problemas sea más sencilla. Investiga en el script comando para una forma conveniente de hacer esto.
Instrucciones detalladas y casos de uso avanzados están documentados en https://wiki.debian.org/ZFS esta es la fuente primaria recomendada para configurar ZFS.
Requisitos previos
Asegúrate de que se pueda acceder a los repositorios HTTPS:
1 apt install -y lsb-release apt-transport-https
Agrega el repositorio Backports para tu versión editando /etc/apt/sources.list o añade un nuevo archivo de fuentes bajo ‘/etc/apt/sources.list.d/’:
1 #determinar el nombre clave o reemplazar manualmente abajo:
2 codename=$(lsb_release -cs)
3 #agregar el repositorio backports a la lista de fuentes:
4 echo “deb http://deb.debian.org/debian $codename-backports main contrib non-free”|sudo tee /etc/apt/sources.list.d/debian_backports.list && sudo apt update
Paquetes ZFS
Finalmente, según la documentación de Debian, instala los últimos encabezados de Linux y los paquetes ZFS relevantes:
1 sudo apt install linux-headers-amd64;sudo apt install -t $codename-backports zfsutils-linux zfs-dkms
“Oh no – algo salió mal”
La falla al instalar ZFS generalmente se debe a un kernel antiguo o incorrecto, o a encabezados faltantes. Lo mejor es purgar todos los paquetes relacionados con ZFS, verificar los encabezados instalados y releer la documentación de instalación.
1 sudo dpkg -l | egrep ‘linux-image|linux-headers’
Creando un pool y un sistema de archivos
Listar discos por IDs:
1 ls -l /dev/disk/by-id/
2 ls -l /dev/disk/by-id/
3 lrwxrwxrwx 1 root root 9 22 Dic 15:29 ata-KINGSTON_SA400S37960G_50026B73818333D1 -> ../../sdb
lrwxrwxrwx 1 root root 9 22 Dic 15:29 ata-KINGSTON_SA400S37960G_50026B73818333DB -> ../../sda
4 lrwxrwxrwx 1
Y crear un pool especificando los IDs de dispositivo estables, por ejemplo:
1 zpool create $mirror_pool_name mirror ata-KINGSTON_SA400S37960G_50026B73818333D1 ata-KINGSTON_SA400S37960G_50026B73818333DB
Crear un sistema de archivos encriptado:
1 zfs create \
2 -o encryption=on \ # eliminar si no es necesario
3 -o keyformat=passphrase -o casesensitivity=mixed \
4 -o acltype=posixacl -o xattr=sa -o dnodesize=auto $mirror_pool_name/$dataset_name
Escenarios de uso real y rendimiento
ZimaBoard no tiene problemas para ejecutar ZFS, y tiene mucho rendimiento, solo la encriptación afecta notablemente el uso de la CPU. La transcodificación y transmisión (por ejemplo, con Jellyfin) tampoco es un problema. Vale la pena señalar que leer o escribir archivos muy grandes en un sistema de archivos encriptado exigirá mucho la CPU. Esto podría afectar otras cargas de trabajo que se ejecuten en el sistema.
SMB/NFS
Durante las pruebas generales, escribir un solo archivo de 12GB en el pool espejo ZFS tomó alrededor de 5 minutos, siendo el IO del disco el cuello de botella. Leer del pool ZFS fue mucho más rápido, tomando menos de la mitad del tiempo. Efectivamente, la conexión de red de 1Gbps se saturó completamente. Ambas pruebas se hicieron hacia/desde un sistema de archivos sin encriptar:
La siguiente prueba muestra el gran impacto que tiene la encriptación en la CPU. Se leyó el mismo archivo de 12GB desde el sistema de archivos ZFS sin encriptar, y se escribió en uno encriptado. El rendimiento sigue siendo excelente, pero el uso de la CPU se disparó y se mantuvo muy alto durante todo el proceso.
Recursos y referencias
- Instalación de ZFS en Debian: https://wiki.debian.org/ZFS#Installation
- https://www.printables.com/model/224057-zimaboard-dual-hdd-stand
- Cable SATA en Y: https://shop.zimaboard.com/products/sata-y-cable-for-zimaboard-2-5-inch-hdd-3-5-inch-hdd-raid-free-nas-unraid
Conclusión
¿Tienes preguntas o buscas más aclaraciones sobre algún aspecto del tutorial? ¡Tyrehl está aquí para ayudar! Únete a nuestra comunidad de Discord para conectar directamente con Tyrehl y participar en discusiones interesantes. Tu curiosidad no tiene que detenerse con el tutorial – Tyrehl está listo para asistirte en tu viaje con ZFS. Únete a nuestro servidor de Discord: [ zimaboard.com/discord]
