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.

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

Error al actualizar archivos de configuración en spacewalk

-->

Si tienes algun sistema en español suscrito a algún canal de configuración, puede ocurrirte el siguiente error.

Recibes un correo en con el asunto:

RHN TRACEBACK from spacewalk

En el cuerpo del mensaje aparece: exceptions.UnicodeEncodeError : 'ascii' codec can't encode character u'\xfa' in position 225: ordinal not in range(128).

Si ejecutas en el sistema rhn_check teniendo pendiente una sincronización del canal obtendrás:

Could not submit results to server
Error code: 1While running 'queue.submit': caught
exceptions.UnicodeEncodeError : 'ascii' codec can't encode character u'\xfa' in position 225: ordinal not in range(128)

Esto se debe a que diff, al comparar los archivos del canal con los existentes en el sistema, suelta un mensaje de advertencia:

No hay ningún carácter de nueva línea al final del fichero.

Este mensaje no es de error, y no debe impedir la ejecución de la actualización. El problema viene por el script que llama
a diff. Este script está hecho en python y al interpretar el resultado de diff, genera un error al encontrar las tildes.

La solución correcta es modificar el script. Otras soluciones altenativas para rodear el problema son configurar
el sistema en inglés para que el mensaje no lleve tildes o evitar que salga el mensaje.

Para esto último hay que asegurarse que tanto los archivos existentes en el sistema como los cargados en
los canales de configuración, terminan con una línea en blanco.

Archivos perdidos en SpaceWalk

En alguna ocasión, un cliente registrado en spacewalk puede resolver un paquete, pero fallar al descargarlo del repositorio. Si vamos a la página de administración de spacewalk y buscamos el paquete en el canal apropiado, lo encontraremos registrado, pero el archivo físico no estará. El mensaje es :

Descargar: Archivos perdidos

Para solucionarlo, abrimos una consola en la máquina spacewalk.

Ejecutamos

cat /var/log/rhn/rhn_server_xmlrpc.log | grep found

y buscamos el paquete que queremos, por ejemplo bsf:

2010/05/12 10:05:47 +02:00 14509 10.1.125.252: server/rhnPackage.get_package_path('ERROR', 'Package not found', '/var/satellite/redhat/1/630/bsf/2.3.0-11jpp.1/x86_64/630785a6e03d28715a54cd125f670ec0/bsf-2.3.0-11jpp.1.x86_64.rpm')

Hay que asegurarse que el directorio existe:

mkdir -p /var/satellite/redhat/1/630/bsf/2.3.0-11jpp.1/x86_64/630785a6e03d28715a54cd125f670ec0

Y después copiar aquí el paquete desde el repositorio superior.

History

El comando history sirve para ver los comandos que ha ejecutado el usuario actual en el pasado. Esa es la configuración por defecto, pero hay algunas variables interesantes que se pueden configurar:

HISTSIZE=2000
Establece el número de comandos que se almacenan.

HISTTIMEFORMAT='%F %T '
Añade fecha de ejecución y hora del comando.

HISTIGNORE="[ ]*"
Ignora los comandos que empiecen con espacio. Estos comandos se ejecutan normalmente, pero no se guardan el history.

Estas variables se pueden exportar con el comando "export" en el archivo profile del usuario o del sistema en /etc.