Selección del hardware

29.12.2022

Introducción

¿Cómo ejecutar 200+ cámaras en un servidor por 300 euros?

A menudo nos preguntan cuántas cámaras se pueden agregar a Yucca en un servidor con determinados recursos de hardware. La pregunta siempre es individual y no es posible dar una respuesta genérica válida para todos. Mucho depende del tipo de cámaras, el bitrate, el procesador y otras variables. Por eso decidimos recopilar algunas estadísticas del servidor de uno de nuestros clientes, con capturas de pantalla y explicaciones detalladas, para que cada uno pueda hacerse una idea de cuántos recursos necesita en su caso concreto...

Publicamos estadísticas similares sobre el funcionamiento en Raspberry Pi 4

Nuestra instalación

Entonces, está instalado Yucca versión 0.7.2, con 154 cámaras conectadas, casi 4 años de profundidad de archivo, y un bitrate de flujo de las cámaras de alrededor de 1M (megabits por segundo). Además de Yucca, en este mismo servidor está instalado postgresql, como base de datos.

(Si quiere el mismo panel, la instrucción está disponible en este enlace)

¿Qué recursos se usan para todo esto y cuánto se utilizan?

Placa base (Motherboard)

Z8NR-D12 es un chasis muy antiguo; se puede comprar uno en el mercado de segunda mano por unos 200 euros.

captura de pantalla de uno de los sitios que conocemos

En esta variante, tal vez falte una segunda fuente de alimentación, pero se puede buscar un chasis similar, por ejemplo de Supermicro.

Procesador (CPU)

Intel(R) Xeon(R) CPU X5690 @ 3.47GHz: 2 procesadores de 12 hilos cada uno, en total 24. En el mercado de segunda mano se puede comprar uno por unos 30 euros la unidad.

La CPU es uno de los recursos más importantes; es justamente en ella donde siempre se topará con el límite al aumentar la cantidad de flujos. Cuanto más flujos, más procesos, y más tiempo de CPU se necesita. En consecuencia, hay que prestar más atención no tanto a la utilización, como en la 1.ª captura, sino al LA o Load Average (si no sabe qué es esto, lea aquí), 2.ª captura.

Veamos entonces la utilización durante 24 horas; hay picos, pero la utilización promedio ronda el 30%

En el gráfico de LA durante el día la situación es similar, entre 30% y 40%

Recordemos que este indicador corresponde a 150 cámaras, lo que significa que el servidor está aproximadamente a la mitad de su capacidad, y en teoría se podría agregar la misma cantidad de cámaras nuevamente, siempre que tengan un bitrate similar.

No recomendamos agregar cámaras a servidores donde el LA ya está por encima de uno. Con LA > 1, esto significa que la cola crecerá constantemente y los problemas de servicio y la degradación son casi inevitables; se necesita más CPU o un servidor Yucca adicional. Por eso, con una gran cantidad de clientes y cámaras, siempre visualice primero sus instalaciones en el monitoreo y siga de cerca los indicadores.

Memoria RAM

9965447-034.A00LF: memoria ECC de servidor, en el mercado de segunda mano por unos 10 euros por placa.

En nuestro caso, 16 gigabytes (8 por zócalo de procesador) alcanza con un margen de 3 veces y se utiliza alrededor de 4 gigabytes.

Disco

La matriz de discos es un tema que merece una nota aparte sobre cómo hacerlo bien y cómo no hacerlo; les contaré aproximadamente cómo calcular manualmente el volumen previsto, pero siempre pueden encontrar una calculadora en línea para su bitrate y tipo de matriz.

En este banco de pruebas, nuestro cliente aloja solo cámaras públicas, y la pérdida inesperada del archivo de estas cámaras no es crítica para él. Por eso, si su archivo tiene un gran valor, no haga esto como se describe aquí.

ST10000VN0004-1Z: Seagate IronWolf 10Tb NAS. 4 unidades en configuración Raid0 dan 37 terabytes, a un costo de unos 200 euros por unidad.

$ df -h | grep yucca
/dev/md0            37T          15T   20T           43% /opt/yucca/data/alloc

$ cat /etc/mdadm/mdadm.conf 
DEVICE partitions
ARRAY /dev/md0 level=raid0 num-devices=4 metadata=1.2 name=yucca:0 UUID=xxx

Por supuesto, gracias a que se trata de Raid0, no experimentamos ningún problema de rendimiento al escribir el archivo en paralelo desde 150 cámaras, y tampoco lo habría con 300, pero la tolerancia a fallos es nula, así que cada uno elige la solución que más le convenga.

Cómo calcular el espacio necesario para el archivo

Supongamos que tenemos 150 cámaras idénticas con un bitrate de flujo de 2M, de las cuales queremos escribir un archivo con una profundidad de 14 días:

• 2 megabits por segundo, esto es 2/8 = 0,25 megabytes
• 0,25 * 60 * 60 = 900 megabytes por hora
• 900 * 24 = 21600 megabytes => 21,6 gigabytes al día por 1 cámara
• 21,6 * 14(días) = 302,4 gigabytes en 14 días por 1 cámara
• 302,4 * 150 = 45360 gigabytes => 45,36 terabytes

Este simple cálculo permite estimar aproximadamente cuánto espacio ocupará nuestro archivo. También conviene tener en cuenta que las matrices no deben llenarse al 99%, y es mejor mantener libre al menos un 5-10%.

Conclusiones

En resumen, tenemos chasis + procesadores + memoria RAM por unos 300 euros y una matriz de discos por 400 euros. En total, unos 700 euros por una solución de trabajo completa, con la posibilidad de vender servicios a clientes con una capacidad de hasta 300 cámaras.

Fantaseemos un poco... Una licencia de Yucca cuesta 40 euros al mes, y no tenemos límites de cámaras; si tiene un chasis moderno y 10 000 cámaras, no lo limitamos :) La tarifa promedio por cámara con un archivo de 14 días que cobran actualmente los proveedores es de unos 5-7 euros al mes, es decir que se podrían ganar 1500 euros al mes con un servidor así sin gastos considerables, con un retorno de la inversión en 1 mes, aunque esto supone que ya cuenta con 300 clientes listos 🙂

¡Gracias a todos los que leyeron hasta el final! Puede hacer una pregunta a través del formulario de contacto en nuestro sitio web, escribiendo a info@yucca.app o en el chat de Telegram de la comunidad.