Historial de tareas
Las pequeñas empresas, por un lado, necesitan un monitoreo de alta calidad de su infraestructura (especialmente a la luz de la virtualización generalizada), por otro lado, es financieramente difícil para ellos comprar nuevos equipos. Además, a menudo hay problemas con el servidor / hardware: a menudo hay 1-3 servidores en torre junto a las estaciones de trabajo de los usuarios o en un pequeño nicho / armario.
Es más fácil usar un ensamblaje listo para usar (distribución), que es suficiente para cargarlo en una tarjeta microSD e insertarlo en una computadora común de una sola placa (beaglebone, raspberry pi y orange pi, familias de placas asus tinker). Además, dicho equipo es económico y se puede instalar en cualquier lugar.
Declaración del problema.
En muchos sentidos, el proyecto se desarrolló como una especie de trabajo de laboratorio con la posibilidad de aplicar los resultados.
Se eligió a Zabbix como sistema de monitoreo, ya que es un sistema potente, gratuito y bien documentado.
La pregunta surgió bruscamente con la plataforma de hardware. Poner una máquina separada bajo supervisión tampoco es una buena solución: o es costoso comprar un nuevo equipo o buscar uno viejo + en pequeñas empresas, hay problemas frecuentes con el servidor / hardware.
El uso del sistema de construcción buildroot le permite crear soluciones especializadas que pueden ser operadas por personal con un conocimiento mínimo de la familia de sistemas operativos Linux Este sistema es amigable para principiantes, pero al mismo tiempo brinda amplias oportunidades de personalización en manos de un desarrollador experimentado. Es perfecto para resolver la tarea de monitoreo no costoso, pero con todas las funciones de la infraestructura de TI, que es mínimamente exigente en la capacitación de su personal operativo.
Pasos de la solución
Se decidió inicialmente crear firmware para x86_64 para ejecutar en qemu, ya que esta es una solución conveniente y rápida para la depuración. Luego conecte a un brazo de computadora de una sola placa (me gustó la placa asus tinker).
El buildroot fue elegido como el sistema de construcción. Inicialmente, carecía del paquete zabbix, así que tuve que portarlo. Hubo problemas con la configuración regional rusa que se resolvieron aplicando los parches apropiados (nota: en las versiones más nuevas de buildroot, estos parches ya no son necesarios).
La portación del paquete zabbix se describirá en un artículo separado.
Como todo debería funcionar como firmware (imagen del sistema sin cambios + archivos de configuración / base de datos recuperables), era necesario escribir los objetivos, servicios y temporizadores del sistema (objetivo, servicio, temporizador).
Se decidió dividir los medios en 2 secciones: una sección con archivos de sistema y una sección con configuraciones mutables y archivos de base de datos zabbix.
Resultó ser un poco más difícil de resolver los problemas asociados con la base de datos. No quería colocarlo directamente en los medios. Al mismo tiempo, el tamaño de la base puede alcanzar un tamaño que excede el tamaño de un posible ramdisk. Por lo tanto, se eligió una solución de compromiso: la base de datos se encuentra en la segunda sección de la tarjeta SD (las tarjetas SLC modernas tienen hasta 30,000 ciclos de escritura), pero hay una configuración que le permite usar medios externos (por ejemplo, usb-hdd).
El monitoreo de temperatura se implementó a través del dispositivo RODOS-5. Por supuesto, puede usar el dallas 1820 directamente, pero fue más rápido y fácil conectar un USB.
Grub2 fue elegido como el gestor de arranque para x86_64. Me llevó escribir una configuración mínima para ejecutar.
Después de la depuración en qemu, se realizó la transferencia a la placa asus tinker. En la estructura de mi superposición, inicialmente se diseñaron plataformas cruzadas: la selección de configuraciones específicas para cada placa (defconfigboards, bootloader, generación de imágenes con una partición del sistema) y la máxima uniformidad en el ajuste del sistema de archivos / creación de una imagen con datos. Debido a tal preparación, la transferencia fue rápida.
Se recomienda encarecidamente que lea los artículos introductorios:
https://habr.com/en/post/448638/
https://habr.com/en/post/449348/
Cómo montar
El proyecto se almacena en github
Después de clonar el repositorio, se obtiene la siguiente estructura de archivos:
[alexey@comp monitor]$ ls -1 buildroot-2019.05.tar.gz overlay README.md run_me.sh
buildroot-2019.05.tar.gz - archivo de buildroot limpio
superposición es mi directorio con árbol externo. Contiene todo lo que necesita para construir firmware usando buildroot
README.md - descripción del proyecto y orientación en inglés.
run_me.sh es un script que prepara el sistema de compilación. Expande la raíz de compilación del archivo, le agrega superposición (a través del mecanismo de árbol externo) y le permite seleccionar la placa de destino para el ensamblaje
[0] my_asus_tinker_defconfig [1] my_beaglebone_defconfig [2] x86_64_defconfig Select defconfig, press A for abort. Default [0]
Después de eso, solo vaya al directorio buildroot-2019.05 y ejecute el comando make.
Después de completar el ensamblaje, todos los resultados del ensamblaje estarán en el directorio de salida / imágenes:
[alexey@comp buildroot-2019.05]$ ls -1 output/images/ boot.img boot.vfat bzImage data data.img external.img external.qcow2 grub-eltorito.img grub.img intel-ucode monitor-0.9-beta.tar.gz qemu.qcow2 rootfs.cpio sdcard.img sys update
Archivos necesarios:
- sdcard.img: la imagen del medio para escribir en la tarjeta SD (a través de dd o rufus bajo wibdows).
- qemu.qcow2: imagen de medios para ejecutar en qemu.
- external.qcow2: imagen de medios externos para la base de datos
- monitor-0.9-beta.tar.gz: archivo para actualizar a través de la interfaz web
Generación manual
No vale la pena escribir las mismas instrucciones varias veces. Y es más lógico escribir una vez en Markdown, y luego convertirlo a PDF para descargar y html para la interfaz web. Esto es posible gracias al paquete pandoc.
Al mismo tiempo, debe generar todos estos archivos antes de ensamblar la imagen del sistema, esos scripts posteriores a la compilación ya son inútiles. Por lo tanto, la generación se realiza en forma de paquete de manuales. Puede verlo en superposición / paquete / manuales.
El archivo manuals.mk (que hace todo el trabajo)
systemd
El mundo de Linux se está moviendo activamente a systemd, y yo también tuve que hacerlo.
De las bonitas innovaciones: la presencia de temporizadores. En general, se escribe un artículo separado sobre ellos (y no solo sobre ellos), pero le contaré brevemente.
Hay acciones que deben realizarse periódicamente. Necesitaba ejecutar logrotate para borrar los registros lighttpd y php-fpm. Sería más común escribir comandos en cron, pero decidí usar el monótono temporizador systemd. Por lo tanto, logrotate comienza en un intervalo de tiempo estricto.
Por supuesto, existe la posibilidad de crear temporizadores que funcionen en ciertas fechas, pero no lo necesitaba.
Temporizador de ejemplo:
[Temporizador]
OnBootSec = 1min
OnUnitActiveSec = 1min
[Instalar]
WantedBy = timers.target
- , : ```bash [Unit] Description=RODOS temp daemon [Service] ExecStart=/usr/bin/rodos.sh
Juntas Soportadas
Asus tinker board: la placa principal en la que todo debería funcionar. Seleccionado como económico y muy poderoso.
Beaglebone black es la primera placa en la que se probó el trabajo (durante la selección de una placa más potente).
Qemu x86_64: se utiliza para desarrollar la depuración.
Como funciona
Al inicio, se produce una recuperación de la configuración en dos etapas:
- ejecutando el script settings_restore (a través del servicio). Restaura la configuración básica del sistema: zona horaria, configuración regional, configuración de red, etc.
- ejecutar el script de preparación (a través del servicio): aquí se prepara zabbix, la base de datos, la IP se muestra en la consola.
En el primer inicio, se determina el tamaño de la segunda sección de la tarjeta SD. Si todavía hay espacio sin asignar: los medios se reparticionan, la sección de datos ocupa todo el espacio libre. Esto se hace para reducir el tamaño de la imagen de instalación (sdcard.img). Además, el directorio de trabajo postgresql se crea en este punto. Es por eso que el primer lanzamiento con un nuevo medio será más largo que los posteriores.
Cuando conecta una unidad externa, en el momento del inicio, busca una unidad libre y la formatea en ext4 con la etiqueta externa.
Atencion ¡Al conectar una unidad externa (además de desconectarla o reemplazarla), debe hacer una copia de seguridad y restaurar la configuración!
Para controlar la temperatura, se utiliza el dispositivo RODOS 5. El fabricante proporciona las fuentes de su utilidad para trabajar con el dispositivo. Cuando se enciende el sistema, se inicia el temporizador rodos, que inicia esta utilidad una vez por minuto. La temperatura actual se escribe en el archivo / tmp / rodos_current_temp, después de lo cual zabbix puede monitorear este archivo como un sensor.
El medio de almacenamiento para la configuración está montado en el directorio / data.
Cuando inicia el sistema y lo prepara para el trabajo, aparece un mensaje en la consola:
System starting, please wait
Después de completar el trabajo preparatorio, cambiará para mostrar la dirección IP:
current ip 192.168.1.32 Ready to work
Configurar zabbix para monitoreo de temperatura
Para controlar la temperatura, solo realice 2 pasos:
- conecte el dispositivo RODOS al puerto usb
- crear elemento de datos en zabbix
Abra la interfaz web de zabbix:
- Abra la sección Configuración → Hosts
- Haga clic en Elementos en la línea de nuestro servidor zabbix
- Haga clic en Crear elemento
Ingrese los siguientes datos:
- nombre - a su discreción (por ejemplo, serverRoomTemp)
- Tipo - agente zabbix
- Clave - rodos
- Tipo- numérico
- Unidades - C
- Período de almacenamiento del historial: el término del historial. quedan 10 días
- Periodo de almacenamiento de tendencias: período de almacenamiento de la dinámica de los cambios. Quedan 30 días
- Nueva aplicación - servidor Room Temp
Y presione el botón AGREGAR.
Gestión basada en web
La interfaz web está escrita en php. Hay funciones principales:
- ver el estado del dispositivo
- cambiar la configuración de red
- cambiar contraseña de usuario
- selección de zona horaria
- copia de seguridad / restaurar / restablecer a la configuración de fábrica
- la capacidad de conectar un disco externo
- Actualización del sistema
Iniciar sesión en la interfaz web está protegido por contraseña. Página de inicio - manual.
Dirección de la interfaz de Zabbix: \ $ {ip / dns} / zabbix
Dirección de la interfaz de administración: \ $ {ip / dns} / manage
Corre en qemu
qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35, accel = kvm-service intel-iommu -cpu host -net nic -net bridge, br = bridge0 -device virtio-scsi-pci, id = scsi0 -drive file = output / images / qemu.qcow2, format = qcow2, aio = threads -device virtio-scsi-pci, id = scsi0 -drive file = output / images / external.qcow2, format = qcow2, aio = threads
Este comando iniciará el sistema con 4 núcleos, 2048 RAM activados por KVM, una tarjeta de red en bridge0 y dos discos: para el sistema y externo para postgresql.
Las imágenes se pueden convertir y ejecutar en Virtualbox:
qemu-img convert -f qcow2 qemu.qcow2 -O vdi qcow2.vdi qemu-img convert -f qcow2 external.qcow2 -O vdi external.vdi
Luego impórtelos a virtualbox y conéctese vía sata.
Conclusión
En el proceso, me interesé en preparar un producto para el trabajo, con una interfaz no muy agradable (no me gusta escribirlos), pero funciona y es fácil de configurar.
El último intento de instalar el dispositivo zabbix en KVM mostró la corrección de este paso (el sistema no se inicia después de que se completa la instalación). Tal vez estoy haciendo algo mal;)
Materiales
https://buildroot.org/