Historial de problemas
Las pequeñas empresas, por un lado, necesitan un control de alta calidad de su infraestructura (especialmente en vista de la virtualización generalizada) y, por otro lado, les resulta financieramente difícil adquirir nuevos equipos. Los problemas de servidor/hardware también son comunes: a menudo hay de 1 a 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 (distribución) listo para usar, que solo necesita cargar en una tarjeta microSD e insertar en una computadora de placa única común (familias beaglebone, raspberry pi y orange pi, asus tinker board). Además, dicho equipo es económico y puede instalarse en cualquier lugar.
Formulación del problema
En muchos sentidos, el proyecto se desarrolló como una especie de trabajo de laboratorio con posibilidad de aplicar los resultados.
Se eligió Zabbix como sistema de seguimiento porque es un sistema potente, gratuito y bien documentado.
El problema con la plataforma de hardware se ha agudizado. Monitorear una máquina separada tampoco es una muy buena solución: o es costoso comprar equipos nuevos o buscar equipos viejos + en las pequeñas empresas hay problemas frecuentes con el servidor/ hardware.
El uso del sistema de compilación buildroot le permite crear soluciones especializadas que pueden ser operadas por personal con un conocimiento mínimo de los 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 el problema del monitoreo económico pero completamente funcional de la infraestructura de TI, con requisitos mínimos para la capacitación del personal que la opera.
Pasos de la solución
Inicialmente se decidió crear firmware para que x86_64 se ejecutara en qemu, ya que es una solución conveniente y rápida para la depuración. Luego, conéctelo a una computadora de placa única (me gustó la placa asus tinker).
Se seleccionó buildroot como sistema de compilación. Al principio le faltaba el paquete zabbix, por lo que hubo que portarlo, hubo problemas con la configuración regional rusa, que se solucionaron aplicando los parches adecuados (nota: en las versiones más nuevas de buildroot, estos parches ya no son necesarios).
La portabilidad del paquete zabbix se describirá en un artículo aparte.
Dado que todo debería funcionar como firmware (imagen del sistema inmutable + archivos de configuración/base de datos recuperables), era necesario escribir sus propios objetivos, servicios y temporizadores del sistema (objetivo, servicio, temporizador).
Se decidió dividir los medios en 2 secciones: una sección con archivos del sistema y una sección con configuraciones modificables y archivos de base de datos zabbix.
Resolver problemas relacionados con la base de datos resultó un poco más complicado. No quería colocarlo directamente en los medios. Al mismo tiempo, el tamaño de la base de datos puede alcanzar un tamaño que excede el tamaño de un posible disco RAM. Por lo tanto, se eligió una solución de compromiso: la base de datos está ubicada en la segunda partición de la tarjeta SD (las tarjetas SLC modernas tienen hasta 30 ciclos de escritura), pero hay una configuración que permite el uso de medios externos (por ejemplo, USB- disco duro).
El monitoreo de temperatura se implementó a través del dispositivo RODOS-5. Por supuesto, puedes usar el Dallas 1820 directamente, pero fue más rápido y fácil conectar un USB.
Se seleccionó grub86 como gestor de arranque para x64_2. Fue necesario escribir una configuración mínima para ejecutarlo.
Después de la depuración en qemu, se transfirió a la placa asus tinker. Inicialmente, la estructura de mi superposición estaba pensada para ser multiplataforma: asignar configuraciones específicas para cada placa (board defconfig, gestor de arranque, generar una imagen con una partición del sistema) y máxima uniformidad en la personalización del sistema de archivos/creación de una imagen con datos. Gracias a tal preparación, la migración fue rápida.
Se recomienda encarecidamente leer los artículos introductorios:
Como ensamblar
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.shbuildroot-2019.05.tar.gz - archivo buildroot limpio
overlay es mi directorio con árbol externo. Aquí es donde se almacena todo lo que necesita para crear el firmware utilizando buildroot.
README.md: descripción del proyecto y manual en inglés.
run_me.sh es un script que prepara el sistema de compilación. Expande buildroot desde el archivo, le adjunta una 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 esto, simplemente vaya al directorio buildroot-2019.05 y ejecute el comando make.
Una vez que se complete la compilación, todos los resultados de la compilación 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
updateArchivos requeridos:
- sdcard.img: imagen multimedia para grabar en una tarjeta SD (a través de dd o rufus en wibdows).
- qemu.qcow2: imagen multimedia para ejecutar en qemu.
- external.qcow2: imagen de medio externo para la base de datos
- monitor-0.9-beta.tar.gz: archivo para actualizar a través de la interfaz web
Generación de Guías
No vale escribir las mismas instrucciones varias veces. Y lo más lógico es escribirlo 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, todos estos archivos deben generarse antes de ensamblar la imagen del sistema; esos scripts posteriores a la compilación ya son inútiles. Por tanto, la generación se realiza en forma de paquete de manuales. Puede consultar la superposición/paquete/manuales.
El archivo manuals.mk (que hace todo el trabajo)
################################################################################
#
# manuals
#
################################################################################
MANUALS_VERSION:= 1.0.0
MANUALS_SITE:= ${BR2_EXTERNAL_monitorOverlay_PATH}/package/manuals
MANUALS_SITE_METHOD:=local
define MANUALS_BUILD_CMDS
pandoc -s -o ${TARGET_DIR}/var/www/manual_en.pdf ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
pandoc -f markdown -t html -o ${TARGET_DIR}/var/www/manual_en.html ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
endef
$(eval $(generic-package))sistemad
El mundo Linux se está moviendo activamente hacia systemd y yo también tenía que hacerlo.
Una de las agradables innovaciones es la presencia de temporizadores. En general, se escribe un artículo aparte sobre ellos (y no solo sobre ellos), pero te lo contaré brevemente.
Hay acciones que se deben realizar periódicamente. Necesitaba ejecutar logrotate para borrar los registros de lighttpd y php-fpm. Lo habitual sería escribir los comandos en cron, pero decidí usar el temporizador monotónico de systemd. Entonces logrotate se ejecuta en un intervalo de tiempo estricto.
Por supuesto, es posible crear temporizadores que se activen en determinadas fechas, pero yo no lo necesitaba.
Ejemplo de temporizador:
- Archivo de temporizador
[Unit] Description=RODOS temp daemon timer
OnUnitActiveSec=1min [Instalar] WantedBy=timers.target
- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon
[Service]
ExecStart=/usr/bin/rodos.shTableros compatibles
La placa Asus Tinker es la placa principal en la que todo debería funcionar. Seleccionado como económico y muy potente.
Beaglebone black es la primera placa en la que se probó el funcionamiento (durante la selección de una placa más potente).
Qemu x86_64: utilizado para depurar el desarrollo.
Cómo funciona
Al inicio, se produce una restauració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.
- ejecutando el script de preparación (a través del servicio): aquí se preparan zabbix y la base de datos, la IP se envía a la consola.
Cuando lo inicia por primera vez, se determina el tamaño de la segunda partición de la tarjeta SD. Si todavía queda espacio sin asignar, los medios se reparticionan y 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, en este punto se crea el directorio de trabajo de postgresql. Por eso el primer lanzamiento con un nuevo portaaviones será más largo que los siguientes.
Al conectar un disco externo, en el momento del inicio busca un disco libre y lo formatea en ext4 con la etiqueta externa.
¡Atención! 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 el código fuente de su utilidad para trabajar con el dispositivo. Cuando se enciende el sistema, se inicia el temporizador Rodos, que ejecuta 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 de configuración está montado en el directorio /data.
Al iniciar el sistema y prepararlo para su funcionamiento, aparece el siguiente mensaje en la consola:
System starting, please waitDespués de completar el trabajo preparatorio, cambiará y mostrará la dirección IP:
current ip 192.168.1.32
Ready to workConfigurar zabbix para monitorear la temperatura
Para controlar la temperatura, basta con seguir 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
Introduzca 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: período de almacenamiento del historial. quedan 10 dias
- Período de almacenamiento de tendencias: período de almacenamiento de la dinámica de los cambios. Quedan 30 días
- Nueva aplicación: temperatura ambiente del servidor
Y presione el botón AÑADIR.
Administrar la configuración a través de la interfaz 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/restauración/restablecimiento de fábrica
- capacidad de conectar un disco externo
- Actualizacion del sistema
El inicio de sesión en la interfaz web está protegido con contraseña. Página de inicio - manual.
Dirección de interfaz de Zabbix: ${ip/dns}/zabbix
Dirección de la interfaz de administración: ${ip/dns}/manage
Corriendo en qemu
qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm -device intel-iommu -cpu host -net nic -net bridge,br=bridge0 -device virtio-scsi-pci,id= scsi0 -drive file=salida/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á un sistema con 4 núcleos, 2048 RAM, KVM habilitado, una tarjeta de red en bridge0 y dos discos: uno para el sistema y otro 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.vdiLuego impórtelos a virtualbox y conéctese vía sata.
Conclusión
En el proceso, me interesé en crear un producto listo para usar, con una interfaz no muy hermosa (no me gusta escribirlas), pero que funcione y sea fácil de configurar.
El último intento de instalar zabbix-appliance en KVM mostró que este paso fue correcto (una vez completada la instalación, el sistema no se inicia). Quizás estoy haciendo algo mal 😉
Fuente: habr.com