SAI Salicru SPS Advance T 2000VA con Ubuntu 22.04
Recientemente el centro se ha dotado de un
Hay que recordar que las baterías proporcionan corriente continua pero que el servidor espera recibir corriente alterna. El inversor u ondulador es el componente electrónico que transforma la corriente continua en corriente alterna para alimentar a la carga con la energía almacenada en las baterías. Pero los inversores más sencillos no producen una señal de onda senoidal y no son adecuados para alimentar algunas cargas como nuestro servidor.
Curiosamente la forma de onda generada por el SAI APC Back UPS 2200VA no consigue alimentar nunca a nuestro servidor aunque sí que puede alimentar otros equipos como PCs de escritorio. Y el SAI APC Back-UPS 1400 debe generar una forma de onda de mejor calidad porque, en algunas ocasiones, puede alimentar al servidor aunque no siempre lo hace.
La fuente del servidor tiene un LED que puede indicar si el suministro eléctrico es de calidad (encendido) o hay alimentación pero es de mala calidad (intermitente). Cuando la fuente juzga que la alimentación no es de buena calidad no proporciona alimentación al servidor.
Naturalmente el SAI debe proporcionar una alimentación aceptable en cada corte de suministro eléctrico y por eso nos hemos dotado de un SAI que genera una forma de onda senoidal.
Características del SAI Salicru SPS Advance T 2000VA
El SAI SPS Advance T 2000VA es un SAI line-interactive con baterías de plomo selladas y sin mantenimiento. Como ya se ha indicado cuenta con un inversor que genera una forma de onda senoidal pura.
Entre las características del SAI encontramos:
- Potencia de carga máxima: 2000VA / 1400W
- Forma de onda senoidal pura
- Monitorización con RS232 y USB
- 6 tomas IEC para alimentar cargas
- Autonomía de 11 minutos con 420W de carga
- Peso de 14Kg
- Display con indicación de:
- Alimentación en la red y en la carga
- Carga de las baterías
- Consumo de la carga alimentada
- Estimación de autonomía
Sobre la capacidad de las baterías del SAI el fabricante proporciona esta curva de descarga (la línea roja corresponde al SAI y las otras al SAI + varias baterías adicionales):
El servidor tiene una fuente de 400W pero durante el funcionamiento normal no va a consumir esa potencia. Sin embargo debe tenerse en cuenta que en el momento del apagado el servidor sí que pasará a estar en pleno rendimiento (y aumentará su consumo) pues ordenará detener a la vez a todas las máquinas virtuales que se estén ejecutando.
El fabricante marca una autonomía de 11 minutos con las baterías cargadas al 100% y con un consumo de 420W. Con estos datos una configuración prudente puede ser iniciar el apagado del servidor 5 minutos después del corte del suministro eléctrico.
Sin embargo, durante las pruebas de funcionamiento con 4 máquinas virtuales (las otras se estaban ejecutando en el antiguo servidor), el servidor Supermicro ha estado consumiendo mucho menos de 400W y se ha producido esta descarga.
| Hora | Estimación del porcentaje de carga en la batería |
| 12:00 | 100 % |
| 12:02 | 81 % |
| 12:05 | 75 % |
| 12:10 | 77 % |
| 12:15 | 71 % |
| 12:20 | 69 % |
| 12:25 | 65 % |
| 12:30 | 63 % |
| 12:35 | 60 % |
| 12:40 | 56 % |
| 12:45 | 54 % |
| 12:50 | 46 % |
| 12:55 | 42 % |
| 13:00 | 33 % |
El porcentaje de carga en las baterías es una estimación que depende del consumo del servidor. A las 12:00 las baterías estaban cargadas al 100% y se desenchufó el SAI del suministro eléctrico. En muy poco tiempo, 2 minutos, la indicación de carga bajó hasta el 81% y a los 5 minutos era un 75%. A las 12:10 se indica un porcentaje de carga del 77% pero el SAI no ha cargado sus baterías, probablemente el servidor en ese momento estaba consumiendo menos potencia y por eso la estimación de carga de las baterías es mayor.
A las 13:00:39, probablemente al llegar al 30% de carga, el sistema inició su apagado deteniendo las 4 MVs de manera correcta:
nov 17 13:01:14 osgiliath libvirt-guests.sh[1154943]: matrioska-2004, baba-yaga-2004-v2, owncloud, valinor
nov 17 13:01:14 osgiliath libvirt-guests.sh[1155323]: Starting shutdown on guest: matrioska-2004
nov 17 13:01:14 osgiliath libvirt-guests.sh[1155434]: Starting shutdown on guest: baba-yaga-2004-v2
nov 17 13:01:14 osgiliath libvirt-guests.sh[1155563]: Starting shutdown on guest: owncloud
nov 17 13:01:14 osgiliath libvirt-guests.sh[1155595]: Starting shutdown on guest: valinor
:
nov 17 13:01:52 osgiliath libvirt-guests.sh[1158694]: Shutdown of guest matrioska-2004 complete.
nov 17 13:01:52 osgiliath systemd[1]: libvirt-guests.service: Deactivated successfully.
En esta ocasión el apagado de las 4 MVs llevó 38 segundos y el servidor completó su apagado en 2 minutos y 6 segundos. Pero naturalmente estos tiempos dependerán de los servicios que se estén ejecutando y el propio apagado supondrá un pico de consumo energético para el servidor.
Con el comando journalctl --since "2022-11-17 13:00:39" --until "2022-11-17 13:02:50" resulta muy sencillo obtener una traza del apagado del servidor.
Configuración de NUT
Se puede instalar y configurar NUT de la manera habitual. Aunque se ha intentado monitorizar el SAI con el puerto USB no se ha conseguido pero afortunadamente se puede monitorizar el SAI con NUT utilizando el puerto RS232 y el driver blazer_ser.
Fichero: /etc/nut/ups.conf
La definición del SAI utilizando el puerto serie ttyS0 y el driver blazer_ser es:
[ups] driver = blazer_ser port = /dev/ttyS0 desc = "Salicru SPS Advance T 2000VA"
Fichero /etc/udev/rules.d/91-nut-ttyS0.rules
Para que NUT pueda abrir el fichero /dev/ttyS0 es necesario aplicar una regla de udev para que el grupo del fichero sea nut.
KERNEL=="ttyS0", NAME="ttyS0", GROUP="nut", MODE="0660"
Propiedades del SAI
Una vez que se ha configurado NUT es posible obtener las siguientes propiedades del dispositivo.
vcarceler@osgiliath:~$ upsc ups Init SSL without certificate database battery.charge: 100 battery.voltage: 26.50 battery.voltage.high: 26.00 battery.voltage.low: 20.80 battery.voltage.nominal: 24.0 device.type: ups driver.name: blazer_ser driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 1.57 input.current.nominal: 8.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 229.3 input.voltage.fault: 229.3 input.voltage.nominal: 230 output.voltage: 229.4 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.status: OL ups.temperature: 25.0 ups.type: offline / line interactive vcarceler@osgiliath:~$
Entre estas propiedades no aparece battery.charge.low que especifica cuando debe comenzar el apagado del ordenador. Aunque probando el apagado de la máquina al simular un corte eléctrico se ha podido ver que comienza cuando la carga de las baterías desciende hasta el 30%.
Al intentar escribir un nuevo valor para esta propiedad con el comando upsrw se produce un error.
Si se quiere detener el servidor antes será necesario utilizar upssched para reaccionar al evento ONBATT.
Inexplicable encendido de la carga tras el apagado
Como es de esperar, cuando se produce un corte eléctrico:
a) El SAI pasa a alimentar al servidor con sus baterías.
b) Las baterías comienzan a descargarse.
c) Al llegar al 30% de carga NUT registra el evento LB y comienza el apagado de la máquina.
d) Finalmente se apaga el servidor y unos segundos después el SAI corta la alimentación del servidor.
Hasta aquí todo bien, pero ahora ocurre algo que nadie espera y que nunca me había encontrado con otros equipos. Y es que 3 minutos después de haber dejado de alimentar al servidor y sin que se haya vuelto a conectar el SAI a la red eléctrica, el SAI vuelve a alimentar al servidor. Con lo que si el servidor está configurado para arrancar al recibir alimentación se produce un nuevo arranque en la peor situación posible, sin suministro eléctrico y con poca carga en la batería.
Al intentar remediar este comportamiento cambiando el valor de la propiedad ups.delay.start el dispositivo nos informa de que esta propiedad únicamente se puede leer.
Para evitar este comportamiento la única solución a nuestro alcance es configurar el servidor para que no arranque automáticamente al recibir alimentación.
De esta manera cuando se produzca un corte eléctrico el servidor realizará un paro ordenado pero se quedará apagado hasta que un humano se acerque a pulsar el botón de encendido.
Más información: