miércoles, 26 de febrero de 2020

Eliminar disco de un cluster GPFS



Cómo eliminar un disco de un cluster GPFS bajo un sistema operativo Linux en IBM Spectrum Scale.



Si tenemos una máquina Linux con IBM Spectrum Scale instalado y varios discos formando un cluster GPFS en dicha máquina, en algún momento puede que queramos eliminar un disco del cluster para liberar espacio en el nodo/cabina. A continuación, mostraré cómo quitar un disco de un cluster GPFS en caliente, es decir, sin tener que parar el servicio que corre sobre ese cluster GPFS.

Para este ejemplo, quitaré un disco de 100 GB del cluster.

Empezaremos mirando qué discos están montados en el sistema operativo:

HOST# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0 2:0 1 4K 0 disk sda 8:0 0 128G 0 disk ├─sda1 8:1 0 148M 0 part /boot/efi ├─sda2 8:2 0 95.9G 0 part / └─sda3 8:3 0 32G 0 part [SWAP] sdb 8:16 0 250G 0 disk └─sdb1 8:17 0 250G 0 part sdc 8:32 0 250G 0 disk └─sdc1 8:33 0 250G 0 part sdd 8:48 0 100G 0 disk └─sdd1 8:49 0 100G 0 part sde 8:64 0 300G 0 disk └─sde1 8:65 0 300G 0 part sr0 11:0 1 4.1G 0 rom /run/media/root/lenovo-saphana-DVD1-X61 sr1 11:1 1 4.1G 0 rom /run/media/root/lenovo-saphana-DVD1-X6 sr2 11:2 1 8.5M 0 rom /run/media/root/CDROM

Vemos que el disco que queremos quitar, el de 100 GB, es el marcado como sdd.

Ahora miramos qué discos (NSD's) forman parte del cluster GPFS con mmlsnsd como ya expliqué:

HOST# mmlsnsd Disk name NSD volume ID Device Node name Remarks ----------------------------------------------------------------------------- data01node01 C0A86E9D573D888F /dev/sdb gpfsnode01 server node data02node01 C0A86F055C45EA46 /dev/sdc gpfsnode01 server node data03node01 C0A86F055D7F94E3 /dev/sdd gpfsnode01 server node data04node01 C0A86F055E5F80EA /dev/sde gpfsnode01 server node

Eliminamos el disco data03node01 (es decir, el disco sdd de sistema operativo) del cluster:

HOST# mmdeldisk sapmntdata data03node01 Deleting disks ... Scanning file system metadata, phase 1 ... Scan completed successfully. Scanning file system metadata, phase 2 ... Scan completed successfully. Scanning file system metadata, phase 3 ... Scan completed successfully. Scanning file system metadata, phase 4 ... Scan completed successfully. Scanning user file metadata ... 0.28 % complete on Mon Dec 9 11:14:15 2019 (49305 inodes with total... 0.36 % complete on Mon Dec 9 11:14:39 2019 (49316 inodes with total... 0.53 % complete on Mon Dec 9 11:15:00 2019 (49337 inodes with total... 0.55 % complete on Mon Dec 9 11:15:21 2019 (49353 inodes with total... .... 100.00 % complete on Mon Dec 9 11:44:09 2019 (1013248 inodes with total... Scan completed successfully. Checking Allocation Map for storage pool system tsdeldisk completed.

Comprobamos que el disco está liberado en el cluster:

HOST# mmlsnsd File system Disk name NSD servers --------------------------------------------------------------------------- sapmntdata data01node01 gpfsnode01 sapmntdata data02node01 gpfsnode01 sapmntdata data04node01 gpfsnode01 (free disk) data03node01 gpfsnode01

Por último, eliminamos el disco:

HOST# mmdelnsd data03node01 mmdelnsd: Processing disk data03node01

Comprobamos que ya no aparece el disco en cuestión en el cluster:

HOST# mmlsnsd File system Disk name NSD servers --------------------------------------------------------------------------- sapmntdata data01node01 gpfsnode01 sapmntdata data02node01 gpfsnode01 sapmntdata data04node01 gpfsnode01

Ya podemos borrar el disco de 100 GB de la máquina virtual con seguridad.
0

miércoles, 19 de febrero de 2020

Ubuntu AWS Rolling Kernel



Qué es el rolling kernel de Ubuntu en AWS y cómo instalarlo.



En el momento de escribir este artículo, las AMIs de Ubuntu en AWS se despliegan con un kernel 4.15, kernel por defecto de Ubuntu 18.04 LTS.

Canonical y AWS han unido fuerzas para introducir un modelo rolling kernel en las instancias Ubuntu de AWS cuya función es permitir disponer de kernels de última generación en las instancias Ubuntu, verificados por AWS y Canonical para su correcto funcionamiento en el hardware de AWS.

Un kernel de última generación proporciona las más nuevas correcciones de errores, mejoras de rendimiento en torno a la programación de tareas y optimización para contenedores, entre otros.


Instalar el rolling kernel



Para instalar un rolling kernel en una instancia Ubuntu en Amazon Web Services, hay que verificar que la instancia ejecute la versión más reciente del kernel estándar linux-aws (v4.15.0):

ubuntu @ ip-xxx-xxx-xxx-xxx $ uname -r 4.15.0-xxxx-aws

Si la versión de kernel es inferior, actualizar sistema operativo con apt update.

Instalar el kernel linux-aws-edge:

ubuntu @ ip-xxx-xxx-xxx-xxx $ sudo apt install -y linux-aws-edge

Nota: Si se solicita una nueva versión de /boot/grub/menu.lst, seleccionar la opción predeterminada: "mantener la versión local actualmente instalada".

Reiniciar la instancia:

ubuntu @ ip-xxx-xxx-xxx-xxx $ sudo reboot

Confirmar que la instancia ahora está ejecutando el kernel linux-aws-edge (v5.0.0):

ubuntu @ ip-xxx-xxx-xxx-xxx $ uname -r 5.0.0-xxxx-aws


Volver a un kernel base



Para volver a un kernel basado en 4.15 (que continuará obteniendo soporte y actualizaciones completas para la longitud del LTS), simplemente hay que escribir las siguientes instrucciones:

ubuntu @ ip-xxx-xxx-xxx-xxx $ sudo apt install linux-aws-lts-18.04

Y reiniciar la instancia.


Fuentes:

https://ubuntu.com/blog/introducing-the-ubuntu-aws-rolling-kernel
0

miércoles, 12 de febrero de 2020

Script se ejecuta en terminal pero no desde cron



Cómo hacer que un script que se ejecuta en terminal pero no desde crontab se ejecute.



Creas un script en bash. Lo ejecutas y funciona correctamente. Programas su ejecución periódica usando cron y cuando llega el momento de su primera ejecución, el script no se ejecuta. O, dicho de otra forma, sí se ejecuta pero no hace lo que tiene que hacer.

¿Qué ocurre?

El causante de que un script no se ejecute correctamente cuando es llamado desde cron puede variar, pero normalmente el problema reside en las variables de entorno. Más concretamente, en la variable PATH, encargada de definir las rutas hacia los binarios (comandos) del sistema operativo.

Bajo cron, las rutas hacia los binarios (comandos) incluidas en PATH no son las mismas que las de una sesión corriente, por lo que algunos de los comandos invocados desde el script no se ejecutarán. Digamos que el script no encontrará los comandos.

En una sesión como root en una terminal, podemos ver las rutas incluidas en la variable de entorno PATH, es decir, las rutas donde se encuentran los binarios del sistema, escribiendo:

HOST# echo $PATH /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin

Para ver qué rutas contiene la variable PATH presente en el entorno generado por cron:

* * * * * env > /tmp/cronenv

Esto generará un archivo con las variables presentes en una sesión de cron.

Ahora, podemos emular el comportamiento de un script bajo las variables de entorno de cron:

env - $(cat /tmp/cronenv) /bin/sh

Esto hará que nuestra sesión actual tome las mismas variables de entorno presentes en cron cuando se ejcuta un script. Útil para testear y debugar shell scripts.

Alternativamente, podemos añadir la variable de entorno PATH al inicio del script en sí:

#!/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ...

De la misma forma, se puede añadir la variable PATH al principio del archivo cron para que todos los archivos llamados desde cron cojan todas las rutas por defecto:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin ...

Por último, y menos recomendable, podemos llamar a los binarios usando sus rutas absolutas.

Por ejemplo, para llamar al comando sendmail, deberemos llamarlo con la ruta absoluta del binario:

#!/bin/bash /sbin/sendmail ...
0

miércoles, 5 de febrero de 2020

NGINX: 502 Bad Gateway



Solucionar error "502 Bad Gateway" en NGINX.



Pongámonos en situación. Accedemos a una URL que nos lleva a un NGINX que actúa como servidor web. En esta URL vemos un error "502 Bad Gateway" presentado por el NGINX.

Lo primero que deberíamos hacer para solucionar este problema es echar un ojo a los logs del NGINX.

Recordemos que el archivo general de log de NGINX se encuentra en /var/log/nginx/error.log.

HOST# sudo tail -30 /var/log/nginx/error.log ... 2020/01/27 10:14:26 [error] 1607#1607: *7 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.101.36, server: ejemplo.com, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "ejemplo.com" ...

Mirando el log, vemos que ha fallado el protocolo fastcgi.

En un NGINX que actúe como servidor web, fastcgi está servido por el módulo php-fpm.

Verificamos el módulo php-fpm:

HOST# service php-fpm status ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled) Active: inactive (dead)

Vemos que, en este caso, php-fpm está deshabilitado.

Iniciamos el servicio:

HOST# service php-fpm start

Lo configuramos para que se inicie automáticamente tras un reinicio de máquina:

HOST# systemctl enable php-fpm Created symlink /etc/systemd/system/multi-user.target.wants/ php-fpm.service → /usr/lib/systemd/system/php-fpm.service.

Una vez hecho esto, podemos acceder a la URL que mostraba el error 502 y veremos que ya funciona.
0