Refrigeración de la raspberry

En relación al post anterior voy a exponer mi experiencia con el ventilador que se suele vender para la raspberry. Es un ventilador pequeño de 3 cm que expulsa un flujo de aire bastante limitado.

Como se ve en la foto, puse el ventilador en la parte superior de la caja, agujereando esta para dejar pasar el aire. El ventilador consume 1W según especificaciones por lo que está alimentado desde la fuente.

La temperatura de la CPU está monitorizada y puede verse un descenso de casi 10ºC en reposo.

Como dato adicional, si se quiere valorar la temperatura en términos absolutos, los chips tienen disipadores puestos. Aparte del disipador en el que se apoya la caja.

Arrancar raspberry desde disco duro

En internet hay muchos tutoriales de cómo arrancar la raspberry desde un SO instalado en un disco duro externo. Yo leí un par de ellos y lo conseguí. El problema es que estos tutoriales sólo hacen mención a la parte software y no hablan del problema hardware que puede existir.

Este problema es el del consumo del disco duro. La raspberry viene con una fuente de 12,5W (2,5 A), que a priori es suficiente para ambos.

Buscando un poco por ahí podemos sacar el consumo de ambos a pleno rendimiento:

Raspberry: 5,1 W enlace

Disco duro: 3,9 W enlace

En total suman 9W, que es el 72% de la fuente original. No debería haber problemas, pero el caso es que en ocasiones los hay. Usando la raspberry como cliente de torrent y descargando 3 enlaces con un ancho de banda total de 5,8 MByte/s se bloqueaba algunas veces. Y la pista de la causa es el led rojo. Cuando el disco estaba siendo usado con frecuencia, este parpadeaba indicando un problema en la alimentación.

Cambié la fuente original por una de 50W, pero el problema continuaba. Quedó claro entonces que había algún cuello de botella que hacía que la raspberry sólo usara una parte de la potencia que le da la fuente y que se peleara con el disco duro por ella.

Llegado a este punto decidí alimentar el disco duro directamente desde la fuente. Las cajas externas para discos duros de 2.5” de ahora sólo traen la conexión USB, pero las de hace un tiempo traían un conector auxiliar por si se necesitaba alimentar el disco. No me refiero al cable Y USB, me refiero a un adaptador de 220V. En la siguiente foto se ve el conector circular a la derecha.

Tenía una caja de estas, pero perdí el adaptador, por lo que aproveché para simplificar el conjunto. Soldé dos cables directamente al interior del conector.

Después los conecté a la fuente.

Con esta configuración, el led rojo ya no parpadea y la raspberry ya es totalmente estable.

Mi recomendación final es que todo lo que se conecte a la raspberry se conecte directamente a la fuente en caso de ser posible. En mi caso también he conectado también el ventilador.

Bendito LVM

Andaba yo en plan autómata borrando un LV de un grupo de máquinas idénticas hasta que me pasé y borré uno que no debía. Las manos a la cabeza y después a estrellarla contra el teclado. Por suerte LVM puede echarnos una mano para solucionar estos problemas.

Todas las operaciones que se realizan en la configuración de LVM se guardan en un histórico ubicado en /etc/lvm/archive y estos son los datos que nos hacen falta para restaurar la configuración.

 Cuando se hace un lvremove o un pvremove no se están borrando realmente los datos, por lo que la restauración es posible. Vamos a ver la peor situación en la que hemos borrado un LV y el PV en el que estaba. Primero hay que buscar el archivo de configuración que vamos a utilizar. En /etc/lvm/archive buscamos el que nos sirva (están en texto plano). Para la búsqueda nos guiamos por las variables "description" y "creation_time" que nos ayudarán a concretar el archivo. Nos quedaremos con aquel justo antes de haber ejecutado los comando de borrado.

Buscamos en el archivo el UUID que tenía el PV que hemos borrado y ejecutamos lo siguiente:

• pvcreate --restorefile  #archivo_cfg# --uuid #uuid# #particion#

Con esto ya tenemos presentado el PV y ahora tenemos que restaurar los metadatos del VG:

• vgcfgrestore  -f  #archivo_cfg# -v #nombre_vg#

Por último ponemos disponibles los nuevos LV:

• vgchange -ay #ruta_vg#

Después ya sólo queda montar el FS y ver posibles problemas de corrupción.

Fuente

LVM: Cómo borrar un PV

Situación.
Máquina virtual, tres discos, 3 PV (uno por disco) que están añadidos a un VG. Sobre este VG hay 3 LV. Uno de estos LV, que ocupa bastante más que los otros dos va a dejar de usarse y es prescindible. Para liberar recursos y disponerlos para otro uso, hay que liberar un PV para poder destruir uno de los discos virtuales.


El primer paso es desmontar el LV a borrar y despues borrarlo con:

• lvremove nombre_lv

Ahora el VG tiene bastantes PE libres, pero los tiene repartidos entre los tres PV. Hay que elegir el PV a borrar, teniendo en cuenta que los PE que tenga tienen que caber en los otros dos PV. Para realizar este movimiento de PEs, se ejecuta el comando:

• pvmove nombre_pv

Ahora el PV está vacío, pero todavía pertenece al VG. Para quitarselo:

• vgreduce -a nombre_vg

Se borra el PV:

• pvremove nombre_pv

Ya se puede quitar el disco de la máquina. Si se hace en caliente, después hay que reescanear el bus:

• scsi-rescan --remove

Nagios y cacti

Nagios es una herramienta de monitorización muy buena y extendida. Mediante scripts consulta los parámetros de las máquinas y en función de los límites definidos manda alertas por correo o SMS.

Pero, ¿y los valores de ayer? Un histórico de los datos es casi imprescindible en la monitorización. Pues también es posible, aunque no viene configurado por defecto. Esto lo hace nagios a partir de un dato que devuelven los scripts llamado "performance data". Este campo proporciona el valor del parámetro que se ha leído y se añade al campo básico, que devuelve un valor entre 0 y 3 para saber el estado del parámetro. Una vez que nagios tiene estos valores, mediante un script que se ejecuta periódicamente, lo va metiendo en una RRD (Round Robin Database). Finalmente, un software de terceros genera las gráficas a partir de estas RRD.

Hay varios programas que realizan esta tarea, como pnp4nagios, check_mk, nagiosgraph, ... Por otro lado está cacti, que es un caso especial. Cacti es por si mismo un sistema de monitorización. Tiene sus scripts, alimenta sus RRD y genera sus gráficos. Como ventaja tiene que la generación de gráficos es totalmente personalizable y como desventaja que no genera alertas en función de los valores de los parámetros. Y aquí es donde viene la pregunta: ¿se puede utilizar cacti sólo para la parte de gráficos, dejando a nagios la adquisición de datos?

Hay varia maneras de realizar está integración:

1. Por separado. Realmente no se integran, cada uno ejecuta sus scripts. Los dos sistemas son independientes. Todo el trabajo de consultar los parámetros se duplica.
2. Cacti consulta. Este se encarga de ejecutar los scripts y alimentar sus RRD. Después nagios consulta el último valor de la RRD y genera el estado (y alarma en su caso) del parámetro.
3. Nagios consulta. Este se encarga de ejecutar los scripts. Como ventaja tiene que los scripts se pueden ejecutar con los agentes NRPE o NCSA. Después cacti consulta a nagios y crea su propia RRD.
4. Parecido al paso 3. Pero nagios aprovecha para crear su RRD. Después cacti genera la gráfica a partir de esta RRD. La diferencia es que no crea su propia RRD sino que utiliza la de nagios, siendo este quien la alimenta.

A continuación se describe este último paso.

Primero hay que configurar nagios para que genere las RRD. Esto se puede hacer con scripts de terceros, por ejemplo los de pnp4nagios. La configuración es simple y en su página web viene muy bien explicado.

Después, hay que realizar los pasos normales para crear la gráfica en cacti, pero rellenando los campos del datasource con datos adaptados a lo que queremos.



Estos son los campos a rellenar:

• data source path: Normalmente se deja en blanco para que cacti lo cree, o se le da la ruta de un archivo inexistente. En este caso se le da la ruta de la RRD que ha creado nagios.
• data input method: None. Cacti no va a alimentar esta RRD.
• associated rra's: Seleccionados todos.
• data source active: no seleccionado. Cacti no va a alimentar esta RRD.

El resto de campos (step y los de data source item) hay que rellenarlos con la información específica de la RRD. Para conocer esta información, hay que ir a la máquina donde está instalado nagios y ejecutar el comando rrdinfo, que muestra los parámetros de configuración de la RRD.

[root@XXX~]# rrdtool info /usr/local/pnp4nagios/var/perfdata/XXX/Linux-CPU.rrd
filename = "/usr/local/pnp4nagios/var/perfdata/XXX/Linux-CPU.rrd"
rrd_version = "0003"
step = 60
last_update = 1304006344
header_size = 5044
ds[1].index = 0
ds[1].type = "GAUGE"
ds[1].minimal_heartbeat = 8640
ds[1].min = NaN
ds[1].max = NaN
ds[1].last_ds = "0.000"
ds[1].value = 0,0000000000e+00
ds[1].unknown_sec = 0
ds[2].index = 1
ds[2].type = "GAUGE"
ds[2].minimal_heartbeat = 8640
ds[2].min = NaN
ds[2].max = NaN
ds[2].last_ds = "0.000"
ds[2].value = 0,0000000000e+00
ds[2].unknown_sec = 0
ds[3].index = 2
ds[3].type = "GAUGE"
ds[3].minimal_heartbeat = 8640
ds[3].min = NaN
ds[3].max = NaN
ds[3].last_ds = "0.000"
ds[3].value = 0,0000000000e+00
ds[3].unknown_sec = 0

En este ejemplo se ve una RRD con 3 datasource configurados. Los nombres de los datasources están entre corchetes. No hay que confundir este valor con algún tipo de ID numérico. Este se corresponde en cacti con internal data source name.

Los demás campos (step, min, max, heartbeat, type) son fáciles de identificar.

Una vez configurado el data source, el proceso para la generación del gráfico es el normal, que se puede encontrar en la documentación de cacti.

Monitorización de ancho de banda con SNMP

A la hora de monitorizar interfaces de red, los sistemas operativos (de servidores o switches) no suelen proporcionar el consumo de ancho de banda instantáneo. O al menos no suelen proporcionarlo de una manera que pueda recolectarse de manera fácil.

A día de hoy casi cualquier aparato dentro de un CPD implementa SNMP, y aunque tampoco proporciona el valor de ancho de banda consumido, se puede calcular mediante otros valores. El proceso para calcularlo es el siguiente.

Se toma una medida de tiempo y se consulta al aparato cuántos bytes se han transferido. Un tiempo después se vuele a repetir el proceso y se calcula la velocidad. Para esto, se utilizan los OID IfInOctets (1.3.6.1.2.1.2.2.1.10) y IfOutOctets (1.3.6.1.2.1.2.2.1.16). Estos proporcionan en bytes, la cantidad de datos transferida, de entrada y salida, desde que se reinició el contador. Normalmente el reinicio del contador se produce con un reinicio del sistema.

Hasta aquí el proceso es simple, pero hay un problema con estos OID: son de 32 bits. Hoy en día la velocidad básica en un CPD para red ethernet es de de 1Gbps. Esto implica que el contador se desbordará a los 34 segundos. Y en menos tiempo para red SAN, que suelen usar velocidades entre 2 Gbps y 8 Gbps.

Este problema se resuelve con otros OID que son la versión de 64 bits de los anteriores: IfHCInOctets (1.3.6.1.2.1.31.1.1.1.6) y IfHCOutOctets (1.3.6.1.2.1.31.1.1.1.10). Estos OID deben consultarse mediante SNMP v2.

Pero algunos sistemas no implementan estos OID, por lo que hay que trabajar con los de 32 bits. En estos casos, no es suficiente con que las consultas se separen menos de 34 segundos, ya que puede haber ocurrido un desbordamiento. Una manera de detectar el desbordamiento es comprobar que el segundo valor leído es menor que el primero. En este caso se puede sumar 2^32-1 bytes con lo que se resuelve el problema. Pero si se ha tardado mucho en realizar la segunda lectura, puede ser que esta sea mayor que la primera, por lo que el desbordamiento no se puede detectar.

Reescanear bus scsi en RHEL.

En ocasiones puede ser necesario reescanear el bus scsi para encontrar nuevos dispositivos o actualizar los que ya están. Por ejemplo un disco hot swap o uno virtual al que se le ha aumentado el tamaño.

El paquete sg3_utils contiene un comando que permite mandar comandos al bus con el fin de encontrar cambios en los dispositivos. A continuación están los comandos para instalar el paquete y actualizar un dispositivo concreto. Estos datos se pueden encontrar en dmesg.

yum install sg3_utils
scsi-rescan --hosts=0 --channels=0 --ids=2 --luns=0 --forceremove