Notas sobre DM-Multipath.

Hace un par de días, tras unos problemas con algún sistema que otro, un compañero me hizo llegar una nota de oracle sobre multipath, que me parece de lo más claro que he leído sobre  esto, en bastante tiempo.
Oracle Doc ID: 470913.1

Como tengo una memoria «privilegiada»…. prefiero apuntar estas notas sueltas, que en conjunto, parece que hasta tienen sentido.

Device-Mapper Multipath (DM-Multipath)

Es una herramienta nativa en linux la cual permite configurar múltiples caminos entre un host y un array de almacenamiento, como si de uno solo se tratara.

Supongamos que vemos la cabina de discos por 4 caminos desde nuestra máquina….
Al ofrecer un disco a la máquina, esta vería 4 discos o cuatro caminos a un disco:

/dev/sdc
/dev/sdd
/dev/sde
/dev/sdf

Multipath realiza la ‘agregación’ o ‘mapeo’, para que podamos trabajar con un dispositivo único (Aunque le da 3 nombres):

"/dev/dm-0" o "/dev/mpath/mpath0" o "/dev/mapper/mpath0"

Según la documentación consultada funciona como una tabla de ‘mapeos’:
‘1’ Mapped device <–> Mapping Table <–> ‘N’ Target device

Como hemos comentado, para cada agregación de caminos, se crean 3 dispositivos (nombre de dispositivo), y aquí viene el problema….. Cual uso, para que y porque.

1.- /dev/dm-X
Este dispositivo es para uso interno de DM-Multipath
NUNCA se debe usar este dispositivo.

2.- /dev/mpath/mpathX
Alias en formato «humano». Se usa para tener agrupados los discos en un mismo directorio «/dev/mpath/»
NUNCA se debe usar este dispositivo, ya que en el arranque UDEV, puede no ser capaz de crear los dispositivos, lo suficientemente rápido, por lo que no estarán disponibles para ser montados.

3.- /dev/mapper/mpathN
Este es el dispositivo que debemos usar ya que es persistente y se crean al arrancar usando el driver device-mapper.
Podemos usar este driver para crear dispositivos lógicos usando «dmsetup»

Nota: Indicar que en distintas máquinas el nombre recibido puede ser diferente, si se quiere garantizar el mismo nombre, deberemos usar UDEV/Multipath y su wwid, para fijarlo.

Por ejemplo:
Single Path:

Obtener UUID
------------------
#scsi_id -g -s /block/sdc
3600a0b8000132XXXXXXXXXXXXb625e
Luego en UDEV
------------------
Editamos:
'/etc/udev/rules.d/10-local.rules'
...
KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="3600a0b8000132XXXXXXXXXXXXb625e", NAME="sda%n"
...

Multipath

Obtener WWID
---------------
multipath -ll
...
mpath1 (360060480000XXXXXXXXXX23544343331)
...
Luego en "multipath.conf"
--------------------------
multipaths {
...
...
multipath {
wwid
360060480000XXXXXXXXXX23544343331
alias NOMBRE
}
...
...

Nota2: Trabajando con dispositivos bajo UDEV, podemos obtener problemas de permisos, que no entraré a detallar, ya que no los he «sufrido», simplemente citar que las definiciones de permisos, se realizan, en la creación del dispositivo, tal y como hemos visto antes, en su linea dentro de «rules.d», añadiendo:

....., OWNER="Nombre_USUARIO", GROUP="Nombre_GRUPO", MODE="0660"

Creando particiones.
Una vez aclarado que debemos usar el dispositivo desde «/dev/mapper/…» y porque. Creamos la partición usando «fdisk»

fdisk /dev/mapper/mpath0

Esto creará la entrada en la tabla de particiones, pero no en los dispositivos que forman la agrupación de discos.
Ni generará los ‘mapeos’ necesarios en «/dev»
Para registrar estos cambios y generar los ‘mapeos’, usamos kpartx que es parte de multipath-tools .

kpartx -a /dev/mapper/mpath0
partprobe

Esto nos creará el ‘mapeo’ en «/dev» para cada partición creada:

/dev/mapper/mpath0p1
/dev/mapper/mpath0p2
/dev/mapper/mpath0p3
...

A este dispositivo (/dev/mapper/mpath0p1), podemos darle formato como a cualquier partición.

Flags útiles:
Para ver las particiones de un device:

kpartx -l /dev/mapper/mpath0
mpath0p1 : 0 2295308 /dev/mapper/mpath0 61

Ver que información hay en la tabla de particiones para ser escrita con «kpartx -a»

kpartx /dev/mapper/mpath0

Referencias del post:
Blogs:
http://www.celtha.es/blog/howto-configuracion-multipath/
http://clemente.pamplona.name/dba/manejo-de-asm-multipath-y-asmlib/

RedHat:
https://www.centos.org/docs/5/html/5.2/Virtualization/sect-Virtualization-Virtualized_block_devices-Configuring_persistent_storage_in_a_Red_Hat_Enterprise_Linux_5_environment.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/DM_Multipath/mpath_devices.html
https://access.redhat.com/documentation/es-ES/Red_Hat_Enterprise_Linux/6/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-6-DM_Multipath-es-ES.pdf
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-7-DM_Multipath-en-US.pdf

Oracle:
Nota 394956.1
Nota 371814.1
Nota 456239.1

Dedicado a las dos ‘chicas’ de la casa, por aguantar mis horas de curro/hobby en casa.

Update Owncloud – Ventana mantenimiento.

Tras el último update con aptitude, al acceder vía web a mi owncloud, me he encontrado con un mensaje indicando que estaba en mantenimiento.
No es la primera vez que me sucede, aunque normalmente funciona correctamente, así que me dejaré este post…

Nota: El acceso desde la app de android era correcto.

Para solucionarlo he usado el comando:

cd /var/www/owncloud
sudo -u www-data php occ maintenance:mode --off

Aquí tenemos más comando útiles.
Tras esto, al acceder vía web, nos indica que tenemos disponible el update, y si lo lanzamos, actualiza la bbdd y funciona perfectamente.

Tuning BD – Cálculo inicial.

En determinadas ocasiones he tenido que realizar un tunning, básico y rápido (seguro que también malo, pero…. ni soy dba ni lo pretendo)

Se que los cálculos genéricos no son el camino, pero aveces no hay mas remedio.
El siguiente script, pretende ofrecer algunos valores calculados sobre el HW de la maquina, y ofrecer algún posible calculo.

Básicamente se ha convertido en un compendio de formulas para tratar de ajustar el rendimiento.
Como curiosidad no esta mal.

NOTA: El script no era el fin, en si mismo…. son ordenes básicamente secuenciales….. 🙂
script

NOTA2: Esto empezó en un post anterior Aquí.

Consumo de Memoria y Caches

Hace unos días he visto un caso curioso sobre un Centos7.
El caso es que la máquina tenia un consumo de memoria que rondaba el 95% y tras un análisis rápido, la memoria no aparecía como cacheada, por lo que suponía que estaba realmente siendo usada.
Lo siguiente fue, ver que proceso / procesos estaban haciendo uso de esta cantidad de memoria, y la sorpresa fue, que no me cuadraban los valores, «faltaban» más menos 7Gb de 8Gb…. ¿?
Tras revisar en detalle la salida de /proc/meminfo, observé esto:

...
Slab:            6903676 kB
...
SReclaimable:    6873888 kB

Aunque la máquina no tenia problemas de rendimiento, por motivos que vienen al caso, no podía llegar a estos umbrales aunque la memoria estuviera como «reclamable»….

Como evitar esto?
Hay muchos posts sobre esto, así que citaré alguno de los que consulté.

https://major.io/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/
http://www.blackmoreops.com/2014/10/28/delete-clean-cache-to-free-up-memory-on-your-slow-linux-server-vps/

Resumiendo….
Tenemos el fichero:

/proc/sys/vm/drop_caches

Que admite los siguientes valores:

0 » Cede el control al Kernel para que administre la memoria

1 » Libera pagecache

2 » Libera dentries y inodes

3 » Libera pagecache, dentries y inodes

Nota:

Pagecache: Paginación en memoria caché

Dentries: Directory entries, relación estructurada entre directorios y ficheros

Inodes: Índice de archivos utilizado por el sistema de ficheros dónde almacena los metadatos de cada archivo (tipo, propietario, permisos, fecha de creación....)Esto se puede ejecutar manualmente o programar en el cron:

EJECUCIÓN MANUAL

#sync ; echo 0 > /proc/sys/vm/drop_caches
#sync ; echo 1 > /proc/sys/vm/drop_caches
#sync ; echo 2 > /proc/sys/vm/drop_caches
#sync ; echo 3 > /proc/sys/vm/drop_caches

CRON

00 04 * * * /bin/sync; /bin/echo 2 > /proc/sys/vm/drop_caches

También podemos configurar esto vía sysctl:

sysctl -a|grep -i cache

Podemos modificar, que  queremos vaciar como

vm.drop_caches = 0

NOTA
Además de esto, también existe el parametro:

vfs_cache_pressure

Este valor indica la prioridad con la que se reclamará la cache de de (inodos/dentry) frente a la de datos (pagecache).
Por defecto tiene un valor de «100»

• Si se decrementa, se preferirá reclamar (pagecache).
• Si se incrementa, se preferirá reclamar (inodos/dentry).
• Un valor de «0» hará que nunca se reclame, por lo que acabaríamos provocando un out of memory.

Raspberry + Telegram

Este post, solo pretende ser unas simples notas sobre la instalación y uso del cliente de Telegram.
Aplicación de mandar avisos al teléfono…. las 1000 y una Frikadas…. que cada uno decida las suyas.

Instalación

apt-get install libreadline-dev libconfig-dev libssl-dev lua5.2 liblua5.2-dev libevent-dev libjansson-dev libpython-dev make python2.7-dev libevent-dev libjansson-dev
cd /opt
git clone --recursive https://github.com/vysheng/tg.git && cd tg
./configure
make

En varios sites he visto que no usan el «recursive», sin esta tendremos cabeceras no resueltas, cuando intentes compilar.

Arrancar el cliente.

Tras esto podemos arrancar la app (Hace uso de algun path relativo por lo que debes entrar en «/opt/tg» aunque la invoque con el path absoluto):

/opt/tg/bin/telegram-cli -k tg-server.pub -W

Nota: La primera vez te dara un codigo que deberas introducir en la app de tu teléfono.
Puedes revisar la lista de comando con «help»

Comandos interesantes.

Un par de comando que he usado:

contact_list (Lista tus contactos.)

NOTA: Con el cliente arrancado puedes tabular para completar, lo cual te permite completar, por ejemplo, el nombre de un contacto y darte cuenta que si tienes espacios para la app son «_» de modo que:

contacto con espacio es contacto_con_espacio y no "contacto con espacio"

Mandar msg y ficheros de texto.

Para mandar msg, basta con teclear con el cliente arrancado…

msg Contacto "Texto a enviar"

Si queremos mandar el contenido de un fichero de texto.

send_text Contacto /ruta/fichero

Nota: Para mandar un msg a alguien por primera vez es necesario crear el chat antes:

chat_add_user Nobre_Chat Contacto

Tras esto podemos mandar el msg con el comando «msg»
Hasta aqui el uso del cliente pero y en un script como…..

Envio del contenido de un fichero de Texto.

Este script «/usr/loca/tg_text.sh» recibe dos argumentos, arranca el cliente y manda el msg (Fichero de texto).

#!/bin/bash
destination=$1;
text=$2;
(sleep 10;echo "send_text $destination $text"; sleep 5; echo "safe_quit") | /opt/tg/bin/telegram-cli -k tg-server.pub -W

Invocamos con: (Recordar…. dentro de «/opt/tg»)

/usr/local/tg_text.sh Usuario /usr/local/fich.txt

Envio de un msg.

Este script es idéntico al anterior pero cambiamos el comando send_text por msg.

#!/bin/bash
destination=$1;
message=$2;
(sleep 10;echo "msg $destination $message"; sleep 5; echo "safe_quit") | /opt/tg/bin/telegram-cli -k tg-server.pub -W

Invocamos con: (Recordar…. dentro de «/opt/tg»)

/usr/local/tg_msg.sh Usuario "Texto a enviar"

Aplicaciones…. lo dicho, muchas por ejemplo, parsear periódicamente webs de descargas y recibir las novedades en el móvil…..

Lo próximo una cámara un sensor de movimiento y….. el gato como actor principal xDDD