Notas sobre journal / journalctl

Algunas notas que me resultan útiles casi a diario, sobre el uso de journalctl…

 

Por defecto es volátil y por lo tanto no persiste tras un reboot.

Tenemos en

/run/log/journal/$ID/system.journal

Los logs de cada arranque disponible, donde $ID es un id que asigna systemd al log.

/run/log/journal/d0c4a268300a404b9cbc7a39f31a47bd/system.journal

 

  • Consultar logs disponibles.
journalctl --list-boots 
 0 bf51a6d4b1a749dfb22eb955a2764e84 lun 2017-09-25 20:49:23 CEST

Podremos ver salidas del tipo:

-3 XXXXX3 fecha ….

-2 XXXXX2 fecha ….

-1 XXXXX1 fecha ….

0 XXXXX0 fecha ….

 

  • Consultar logs de un boot determinado.
journalctl -b -3
journalctl _BOOT_ID=-3
  • Consultar logs del kernel.
journalctl -k
  • Consultar últimas entradas. 
journalctl -b -k -n 10 #(Ultimas 10 entradas de logs de kernel y boot)
  • Logs de un proceso.
journalctl /bin/xxxx #(Full path)
journalctl _PID=XXXX
  • Logs de un usuario.
journalctl _UID=XXXX
  • Logs de un servicio.
journalctl -u httpd.service
journalctl _SYSTEMD_UNIT=httpd.service
  • Logs de varios servicios.
journalctl _SYSTEMD_UNIT=XX.service + _SYSTEMD_UNIT=YY.service
  • Establecer rangos de fecha.
--since=09:30
--until=16:25
--since='30 min ago'
--until='2 days ago'
  • Logs por criticidades.
journalctl -p 2
journalctl -p err

0 emergency / 1 alert / 2 crit / 3 err / 4 warn / 5 notice / 6 info / 7 debug
  • Logs por disco.
journalctl /dev/sda
journalctl /dev/sda1
  • Check espacio usado de journal.
journalctl --disk-usage
Archived and active journals take up 8.0M on disk.
  • Permitir journal a usuarios.

El grupo ‘adm‘ tiene acceso a journal.

usermod -a -G adm USUARIO
  • Configurar persistencia de logs.
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
chown root:systemd-journal /var/log/journal
chmod 2775 /var/log/journal
systemctl restart systemd-journal
  • Configuración general.

En el fichero:

/etc/systemd/journald.conf

Storage=

volatile –> Es volatil en /run/systemd/journal/

Persistent –> Es persistente en /var/log/journal/

Auto  –> Por defecto persistente, pero si no esta el path NO lo crea y pasa a volatil.

Nohe –> Logs a consola

Compress=  –> Por defecto true

Seal= –> Se crean claves para asegurar la integridad de los logs.

SystemMaxUse= 50M #(Por defecto 10% de filesystem, tamaño al que rota)

  • Rotado manual.
journalctl --vacuum-size=2G #(Limpiar y retener 2G)
journalctl --vacuum-time=2years #(Limpiar y retener 2 años)

 

Publicado en journalctl, Linux | Deja un comentario

Consideraciones sobre tuning para Graylog y ElasticSearch

Algunas consideraciones sobre rendimiento para Graylog y ElasticSearch, que he ido afinando ha base de leer, probar y volver a ajustar….

NOTA:

Todas las consideraciones están basadas en pruebas de carga, con estos criterios:

1.- Inserciones de un fichero de unas 3.000.000 lineas distintas de logs.

2.- Múltiples repeticiones para intentar eliminar desviaciones en las muestras.

2.- Usando como agente graylog_sidecar.

 

Consideraciones sobre HW…

Graylog.

CPU (8vCPU)

Testado con 4, 6, 8, 12 y 16 vCPU’s, reajustando valores de configuración que dependen de los cores, explicados más adelante.

Hasta los 8 cores el crecimiento es lineal y la sensación de uso mejora considerablemente. Llegados a este punto ya no se percibe mejora.

RAM (8Gb)

Testado con 4, 6, 8 y 16 Gb de RAM, siempre destinando el 50% a la JVM.

El funcionamiento ha ido mejorando, sobre todo en la sensación de uso, hasta llegar a 8Gb con 4Gb para  graylog. Al subir a 16Gb, la mejora deja de ser significativa, usando dashboards y lanzando queries mientras se insertan datos.

HD (N.A)

No he podido detectar repercusión mencionable. He realizado pruebas pasando el journal que que usa como buffer, a memoria e incluso deshabilitándolo.

message_journal_enabled = true --> false
message_journal_dir = /var/lib/graylog-server/journal

Conclusión:

Con estas pruebas “8vCPU / 8Gb Ram” parece razonable, llegados a este punto y con las pruebas realizadas, si se necesita más rendimiento, lo más recomendable parece un crecimiento horizontal, usando algún tipo de balanceo.

 

ElasticSearch.

CPU (8vCPU)

Testado con 4, 6, 8, 12… Pasar de 4 a 8 vCPU ha supuesto un incremento de más del 20%. en inserciones. Seguir subiendo no parece lo mejor ya que desde los 8vCPU, se deja de notar mejoría y el uso del CPU del equipo, esta lejos de ser alto.

RAM

16Gb ha sido el único valor testado. En la documentación que he podido consultar por parte del fabricante, generalizan nodos con cerca de 64Gb Ram. Así que invertir aquí puede ser buena idea.

HD

Toda la documentación del fabricante indica que se recomiendan discos lo más rápidos posibles, y creo que es evidente el motivo, pero la verdad, es que he podido probar discos SATA, SAS 7200, SAS 10000 y SSD y no he sido capaz de cargar los discos, como para notar diferencias y detectar algún cuello de botella. Supongo que en entornos productivos con inserciones más grandes y queries exigentes, si debe existir impacto.

Conclusión:

Con las pruebas realizadas la máquina más optima, “Recursos/Rendimiento”, parece “8vCPU / 16Gb Ram”.

Según la documentación del fabricante, no parece que el crecimiento vertical (más recursos) sea el camino a seguir. Todo indica, que es preferible múltiples máquinas de pocos recursos que menos máquinas de más recursos.

También es cierto que en entornos productivos, como he dicho antes, elasticsearch hace recomendaciones con muchísimo más HW y los considera máquinas pequeñas …  (16vCPU/64Gb RAM) por ejemplo.

 

Consideraciones sobre Software…

Graylog.

He probado diferentes parámetros e intentado ajustarlos en función del HW disponible. Los que han tenido repercusión sobre el rendimiento han sido los siguientes…

 

output_batch_size = 500 --> 5000
output_flush_interval = 1

Estos parámetros indican que los datos son enviados a ElasticSearch cada 5000 mensajes o cada segundo, lo que antes suceda. Para inserciones altas, 500 es un número demasiado bajo, lo que hace que intentemos insertar demasiadas veces, bajando así el rendimiento.

 

processbuffer_processors = 5 --> 8 --> 10 --> 20 --> 8
outputbuffer_processors = 3 --> 8 --> 10 --> 20 --> 8
inputbuffer_processors = 2 --> 6 --> 8 --> 10 --> 20 --> 8

He podido probar con la lista de valores indicada, sin detectar cambios una vez superado el umbral del número de cores disponibles en la máquina que corre graylog. Así que … No se recomienda pasar del número de cores disponibles.

ElasticSearch.

index.refresh_interval: 30s
curl -XPUT 'X.X.X.X:9200/graylog2_001/_settings' -d '{
    "index" : {
        "refresh_interval" : "30s"
    }
}'

Con este curl, podemos realizar el cambio de valor en caliente.

Este es el valor que más repercusión ha tenido en el rendimiento con mucha diferencia. En las guías de Graylog, se indica que es necesario y que tiene mucha repercusión en el rendimiento, y así es… Cambio obligado si se usa graylog

Notas:

Aquí simplemente unas observaciones que tienen repercusión sobre el rendimiento pero que dependen tanto de cada caso particular que no es posible dar números…

  • Más nodos de elasticsearch (con al menos un número de shards igual al número de nodos ), mejoran el rendimiento en queries.
  • Menos nodos (Por lo tanto menos menos shards, pero más grandes, mejoran la inserción).
Publicado en ElasticSearch, Graylog, Linux | Deja un comentario

Snapshots sobre ElasticSearch

ElasticSearch provee un mecanismos de snapshots, que podemos gestionar vía su api. No se trata de snapshots vivos al uso, sino más bien de dumps incrementales, ya que tendremos la información completa (todos los indices), más los diferenciales para cada snapshot. Cuando un dato no es usado por ningún snapshot, el indice respaldado se vacía pero no se elimina el directorio del repositorio de snapshots.

 

0.- Montar los paths

Elasticsearch, necesita que se le defina un path a nivel de filesystem, sobre el cual creará el repositorio para los snapshots y almacenará los datos. Todos los hosts de elasticsearrch de nuestro cluster, deben tener (rw) sobre el path.

ej.

mount -t nfs 10.X.X.X:/backupsElastic /mnt/snapshots/
vi /etc/fstab
...
10.X.X.X:/backupsElastic /mnt/snapshots nfs defaults 0 0

 

1.- Definición de paths

Tras tener el path disponible en los hosts, necesitamos que elasticsearch haga uso de ellos. Para esto se le define la variable “path.repo

vi /etc/elasticsearch/elasticsearch.yml
path.repo: /mnt/snapshots/elastic

 

2.- Registrar paths.

Este proceso intenta acceder al path definido para escribir y eliminar unos ficheros temporales.

(Verificación del registro en el punto 6 )

Si alguno de los nodos no puede realizar la acción correctamente, indicará un error con el nodo implicado.

Preparado en el script:

#!/bin/bash
curl -XPUT 'http://X.X.X.X:9200/_snapshot/backups' -d '{
    "type": "fs",
        "settings": {
        "location": "/mnt/snapshots/elastic/"
        }
}'

 

3.- Creación y eliminación de snapshots.

Para la creacion / eliminación de snapshots se realizan invocaciones a la api.

curl -XPUT http://X.X.X.X:9200/_snapshot/backups/$NAME?wait_for_completion=false
curl -XDELETE http://X.X.X.X:9200/_snapshot/backups/$NAME

 

Ej.

Script sencillo para la creación de snapshot diarios, con retención semanal.

#!/bin/bash

DAY=`date +%u`
NAME="backup_$DAY"

if [ `ls -als /mnt/snapshots/elastic/|grep $NAME|wc -l` -gt 0 ]; then
 curl -XDELETE http://X.X.X.X:9200/_snapshot/backups/$NAME
 curl -XPUT http://X.X.X.X:9200/_snapshot/backups/$NAME?wait_for_completion=false
else
 curl -XPUT http://X.X.X.X:9200/_snapshot/backups/$NAME?wait_for_completion=false
fi

 

4.- Verificación de snapshots.

La verificación de los snapshots podemos realizarla con la siguiente invocación:

curl -XGET http://X.X.X.X:9200/_snapshot/backups/$NAME?pretty

Obteniendo el valor de “state” para crear nuestros script de monitorización.

 

5.- Restauración de snapshots.

La restauración la podemos realizar a nivel de indices, recuperando un indice en concreto de uno de nuestros snapshots o a niveld e snapshot, recuperando el snapshot full con todos los indices que lo componen.

Ambas acciones se realizan con invocaciones a la api:

 

  • Recuperación de indice concreto.

Esto restaura un indice concreto (index_1 y index_2) de un snapshot concreto ($NAME), este indice debe existir en ese snapshot, cambiando el nombre del indice restaurado. Para restaurar sin modificar nombres… en caso de desastre completo, se deben quitar las dos clausulas “rename

curl -XPOST http://X.X.X.X:9200/_snapshot/backups/$NAME/_restore" -d '{
    "indices": "index_1,index_2",
    "ignore_unavailable": true,
    "include_global_state": false,
    "rename_pattern": "index_(.+)",
    "rename_replacement": "restored_index_$1"
}'
  • Recuperación de snapshot full.

Esto restaura todos los indices de un snapshot concreto.

curl -XPOST http://X.X.X.X:9200/_snapshot/backups/$NAME/_restore"

 

6.- Invocaciones útiles.

Obtener información del repositorio.

curl -XGET http://X.X.X.X:9200/_snapshot/$repositorio

 

Verificación del registro.

curl -XGET http://X.X.X.X:9200/_snapshot/$repositorio/_verify

 

Obtener información del snapshot.

curl -XGET http://X.X.X.X:9200/_snapshot/snapshots/$snapshot

 

Obtener información de todos los snapshots.

curl -XGET http://X.X.X.X:9200/_snapshot/snapshots/_all

 

Con esto es posible tener un mecanismo de backup bastante completo.

Publicado en ElasticSearch, Linux | Deja un comentario

Proxmox – Interfaces promiscuas.

Otra entrada corta sobre interfaces promiscuas… y últimamente ya van unas cuantas.

En este caso la necesidad es capturar tráfico desde una vm que corre sobre proxmox. Por defecto esto se realiza con normalidad, una interfaz física es asociada a un Vbridge, el cual es usado por la/las máquinas virtuales.

La interfaz en la VM se puede configurar promiscua sin mayor problema.

ethX –> vmbrX –> VM(ethx promisc)

El problema viene cuando al capturar tráfico desde la VM, solo vemos tráfico multicast y no todo el trafico como era de esperar.

Según parece por defecto esta deshabilitada la posibilidad de que un bridge actúe en modo promiscuo desde proxmox, por temas de seguridad.

Para habilitar esta posibilidad, es necesario, el parámetro “bridge_ageing 0” el cual no es posible configurar desde la WUI. (Ni como admin, lo cual estaría bastante bien)

Podemos configurarlo desde el fichero “interfaces” en el propio proxmox

/etc/network/interfaces

auto vmbr4
iface vmbr4 inet manual
    bridge_ports eth1
    bridge_stp off
    bridge_fd 0
    bridge_ageing 0
#PROMISC

Este cambio según las indicaciones de proxmox, requiere reboot aunque hay maneras de recargarlo correctamente, sin necesidad de reboot completo.

Nota: Según las pruebas, si editamos desde la WUI tras este cambio, el parámetro se mantiene y no es “machacado”.

Nota2: Este cambio solo es valido para entornos con máquinas bajo kvm y no bajo qemu (Sin verificar)

Tras esto la VM, ya recibe el tráfico promiscuo como se esperaba.

Publicado en Kvm, Linux, Proxmox | Deja un comentario

Configurando Bond promisc

Hace poco he tenido la necesidad, de agregar varias interfaces  en modo promiscuo, en solo una interfaz virtual.

Ya escribí una pequeña introducción sobre configuración de bond, hace mucho tiempo, en la que se indican los distintos tipos. aquí

En esta ocasión el modo usado es el “3” o Broadcast.

La configuración de la interfaz de bond y de sus interfaces físicas es la siguiente.

/etc/sysconfig/network-scripts/ifcfg-bond0

TYPE="Bond"
BONDING_MASTER="yes"
BOOTPROTO="none"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="bond0"
DEVICE="bond0"
ONBOOT="yes"
PROMISC="yes"
BONDING_OPTS="mode=3"
NM_CONTROLLED="no"

/etc/sysconfig/network-scripts/ifcfg-eno1

DEVICE="eno1"
ONBOOT="yes"
BOOTPROTO="none"
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="eno1"
PROMISC="yes"
MASTER="bond0"
SLAVE="yes"
NM_CONTROLLED="no"

/etc/sysconfig/network-scripts/ifcfg-eno2

DEVICE="eno2"
ONBOOT="yes"
BOOTPROTO="none"
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="eno2"
PROMISC="yes"
MASTER="bond0"
SLAVE="yes"
NM_CONTROLLED="no"

Tras esta configuración, simplemente queda garantizar que las interfaces levanten en modo promiscuo, para lo que editamos rc.local

/etc/rc.local

/sbin/ip link set bond0 promisc on
/sbin/ip link set eno1 promisc on
/sbin/ip link set eno2 promisc on

Llegados aquí podremos capturar todo el tráfico de las interfaces enoX en la interfaz bond0

 

Publicado en Bond, Linux | Deja un comentario

Notas sobre Rsyslog

En esta nota dejaré algunos apuntes interesantes, sobre configuraciones que estoy encontrando, al hacer un uso mas intensivo de rsyslog.

Es una nota un poco desordenada, más como recordatorio que como post estructurado.

– Problemas de drops en Rsyslog por exceso de msg. RedHat 6.X –

Rsyslog define el numero de mensajes por intervalo de tiempo. Superado este umbral se producirá un dropeo y perderemos entradas.

Superar este umbral deja una entrada en los logs de la máquina, en:

/var/log/messages
Jul 5 18:51:01 localhost rsyslogd-2177: imuxsock lost 538 messages from pid 433 due to rate-limiting

Esto implica que tenemos cargado el modulo imuxsock con la librería  /usr/lib/rsyslog/imuxsock.so en el fichero /etc/rsyslog.conf

$ModLoad imuxsock

La configuración de estos intervalos se define con los parámetros :

$SystemLogRateLimitInterval 10
$SystemLogRateLimitBurst 500

Por defecto son bastante conservadores, así que podemos ajustarlos como necesitemos.

$SystemLogRateLimitInterval (Tiempo en segundos)
$SystemLogRateLimitBurst (Número de msg)

También podemos encontrar entradas equivalentes más “legacy”, aunque no es lo normal:

$IMUXSockRateLimitBurst [number] - equivalent to: RateLimit.Burst
$IMUXSockRateLimitSeverity [numerical severity] - equivalent to: RateLimit.Severity
$IMUXSockRateLimitSeverity [numerical severity] - equivalent to: RateLimit.Severity

Si queremos eliminar este control podemos definir el tiempo en “0s”

$SystemLogRateLimitInterval 0

Tras los cambios, reiniciamos rsyslogd

 

– Problemas de drops en Rsyslog por exceso de msg. RedHat 7.X –

En RedHat 7, podemos tener este problema tanto en rsyslog como en systemd-journald, dejando en ambos casos, sus respectivos logs:

Jun 28 03:08:43 localhost systemd-journal[1864]: Suppressed 917 messages from /

o

Jun  28 10:32:15 localhost rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
Jun  28 10:32:17 localhost rsyslogd-2177: imjournal: 236 messages lost due to rate-limiting

Para systemd-journald, editamos /etc/systemd/journald.conf casi como en el caso anterior

RateLimitInterval= (Tiempo en segundos)
RateLimitBurst= (Numero de msg.)

Tras los cambios, reiniciamos systemd-journald

 

Para rsyslog y con el formato tradicional, como en el caso de RedHat 6, editamos, /etc/rsyslogd.conf

$imjournalRatelimitInterval = (Tiempo en segundos)
$imjournalRatelimitBurst = (Numero de msg)

 

También podemos encontrar esto, aunque aun no lo he visto.

if rsyslog.conf has been modified to use new-style module-loading syntax, well, stick with thatExample excerpt:

module(load=”imjournal” StateFile=”/var/lib/rsyslog/imjournal.state” ratelimit.interval=”300″ ratelimit.burst=”30000″)

Tras los cambios, reiniciamos rsyslogd

 

– Problemas por  tamaño de msg. –

También podemos tener problemas con el tamaño de msg. tanto para recibir como para enviar, si este supera el valor por defecto. 2k

UDP soporta un valor máximo de 4k

testing showed that 4k seems to be the typical maximum for UDP based syslog. This is an IP stack restriction. Not always … but very often.

Más detalle (aquí), así que si queremos tamaños mayores debemos usar TCP.

Por ejemplo, los registros de sucesos de windows tienen tamaños de hasta 64k

Si detectamos msg incompletos, deberemos ajustar el tamaño máximo, usando la directiva:

$MaxMessageSize (Tamaño en bytes)

Tras los cambios, reiniciamos rsyslogd

 

Publicado en Linux, Syslog | Deja un comentario

Añadir DS a RRD – Problema PNP4Nagios – No DS called …

Me he encontrado varias veces problemas con los ficheros rrd que usa pnp para graficar en Nagios.
Indicando que faltan uno o varios (DS)-DataSource… esto sucede normalmente, porque se ha cambiado el plugin de un servicio y el nuevo plugin genera una salida diferente, lo cual genera un nuevo XML, pero el RRD que teníamos sigue con la definición anterior y faltan los (DS) indicados.

NOTA:
Para cada servicio, tenemos dos ficheros….
XML –> Estructura de BBDD rrd.
RRD –> BBDD

Como proceder… tenemos dos alternativas….

1.- Mas rápida… pero con perdida de histórico del servicio.

Borramos el rrd y el xml, y en el siguiente check se generaran de nuevo, pero habremos perdido el histórico para ese servicio.

2.- Creamos los DS que faltan.

De este modo mantendremos el historico del servicio para el resto de DS’s

NOTA: El script usado “rrd_add_datasource.pl” se puede descargar o copiarlo directamente.-
– Caso Practico –

1.- Verificar los DS que tenemos en el XML:

#cat /var/lib/pnp4nagios/XXXXXXX/DISK-linux.xml |grep "<DS>"
 <DS>1</DS>
 <DS>2</DS>
 <DS>3</DS>
 <DS>4</DS>
 <DS>5</DS>

2.- Verificar los DS que tenemos en el rrd:

#rrdtool info /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd |grep type
 ds[1].type = "GAUGE"
 ds[2].type = "GAUGE"
 ds[3].type = "GAUGE"

3.- Debemos añadir el DS 4 y 5

# /root/rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 4 GAUGE
Processing /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd... ok.
# /root/rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 5 GAUGE
Processing /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd... ok.

4.- Verificamos que el RRD ya tiene los DS correctos

[root@s2-argos ~]# rrdtool info /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd |grep type
ds[1].type = "GAUGE"
ds[2].type = "GAUGE"
ds[3].type = "GAUGE"
ds[4].type = "GAUGE"
ds[5].type = "GAUGE"

Tras esto el mapa se mostrara correctamente.
– Script “rrd_add_datasource.pl” –

#!/usr/bin/perl

use strict;
use warnings;
use RRD::Simple();

my $rrd_file = shift @ARGV;
my $DS_name = shift @ARGV;
my $DS_type = shift @ARGV;

my $rrd = RRD::Simple->new();

print "Processing $rrd_file...";
$rrd->add_source($rrd_file, $DS_name => $DS_type);
print " ok.\n";

e.j.

./rrd_add_datasource.pl $RRD_FILE $DS_NAME $TYPE
./rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 5 GAUGE
Publicado en Nagios | Deja un comentario

Configurando VLAN tagging sobre Bond

No hace mucho, he tenido que configurar un bond con tagging y he tenido algunos problemas que me parece buena idea, dejar por escrito.

La configuración de una interfaz “tagueada” con el id de una VLAN, no tiene más complicación. Existe mucha documentación al respecto.

Defines tu fichero de interfaz ifcfg-eth0 y su copia “link” con un “.” seguido del vlan_id…. ifcfg-eth0.10 (En este fichero, se define la configuración de red y se añade la clausula “VLAN=yes”)

Hasta aquí, todo según la documentación….

Al combinar, bond y tagging, es cuando he tenido estos problemas principalmente:

 

1.- Para vlans, necesitamos el modulo 8021q, el cual no carga por defecto, por lo que creamos un fichero /etc/modules-load.conf/8021q.conf

8021q

2.- Según la documentación consultada, desde la versión 6.3 de CentOS, existen problemas con bonding+tagging y NetworkManager. En los “bug reports” se recomienda que se pare NetWorkManager.

Estas pruebas se han realizado con CentOS 7.2 y tenia el mismo problema.

3.- Al parar NetworkManager, el modulo de bond no se carga al arranque. Para esto, tenemos dos alternativas:

3a.- Definir la carga del modulo creando un fichero en /etc/modprob.d/bond.conf

alias bond0 bonding
options bond0 miimon=100 mode=0

El detalle de los modos disponibles, lo tenéis aqui

3b.- Definir en el fichero de configuración del bond, la opción BONDING_OPTS:

BONDING_OPTS="mode=balance-rr miimon=100"

Esto hace que el modulo se cargado al arranque

Tras esto, la configuración siguiente funciona sin problemas:

 

ifcfg-eno1

TYPE="Ethernet" 
BOOTPROTO="none" 
NAME="eno1" 
DEVICE="eno1" 
ONBOOT="yes" 
NM_CONTROLLED="no" 
MASTER="bond0" 
SLAVE="yes"

ifcfg-eno2

TYPE="Ethernet" 
BOOTPROTO="none" 
NAME="eno2" 
DEVICE="eno2" 
ONBOOT="yes" 
NM_CONTROLLED="no" 
MASTER=bond0 
SLAVE=yes

ifcfg-bond0

TYPE="Bond" 
BOOTPROTO="none" 
DEVICE="bond0" 
NAME="bond0" 
ONBOOT="yes" 
BONDING_OPTS="mode=balance-rr miimon=100" 
NM_CONTROLLED="no"

ifcfg-bond0.10

BOOTPROTO="none" 
DEFROUTE="yes" 
NAME="bond0.10" 
DEVICE="bond0.10" 
NM_CONTROLLED="no" 
ONBOOT="yes" 
IPADDR="192.168.1.23" 
PREFIX="24" 
GATEWAY="192.168.1.1"
DNS1="8.8.8.8"
DNS2="8.8.4.4"
BONDING_MASTER=yes 
VLAN="yes"

 

Con esto tendremos nuestro bond “tagueado” con el id de la vlan, como vemos a continuación.

# ip -d link show bond0.10
7: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff promiscuity 0 
    vlan protocol 802.1Q id 10 <REORDER_HDR> addrgenmode eui64

 

[root@papaya network-scripts]# ip a l 
1: lo: ...
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
4: ...
5: ...
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever 
7: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
    inet 192.168.1.23/24 brd 192.168.1.255 scope global bond0.10 
       valid_lft forever preferred_lft forever 
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

 

Publicado en Bond, Linux | Deja un comentario

Networking con Docker – docker0 bridge…. Y si coincide

He estado realizando unas pruebas con docker y me he encontrado con lo siguiente..

La red que usa docker como bridge 172.17.0.0 /16 coincide con la red del segmento en el que se aloja la máquina de pruebas. Por lo que al arrancar el demonio de docker la interfazdocker0, dejaba la máquina no accesible.

Leyendo un poco, hay varias formas de abordar esto…. podemos pasarle a docker, parámetros para indicarle que red bridge debe usar, por lo que nuestra interfaz docker0, sera creada en dicho segmento.

Sin embargo, me parece más sencillo, el segundo mecanismo que viene a indicar, que si tenemos una interfaz docker0 en la máquina anfitrión, al arrancar docker, usará esta interfaz para la red bridge. De este modo no hay que indicarle nada en el arranque a docker.

1.- Desde consola.

Si hemos arrancado docker, aunque paremos el servicio, ya tendremos la interfaz docker0, tumbamos la interfaz:

systemctl stop docker.service
ip link set dev docker0 down

Modificamos la red.

ip addr add 172.19.0.0/16 dev docker0
ip link set dev docker0 up

Con esto al arrancar docker, este usara la nueva interfaz docker0 en la red 172.19.0.0

2.- Mismo concepto pero desde fichero.

(Centos7) Creamos el fichero para la interfaz docker0:

/etc/sysconfig/network-scripts/ifcfg-docker0

DEVICE=docker0
TYPE=Bridge
IPADDR=172.19.0.1
NETMASK=255.255.0.0
ONBOOT=yes
BOOTPROTO=none
NM_CONTROLLED=no
DELAY=0

De este modo dejaremos el cambio persistente.

Publicado en Docker, Virtualización | Deja un comentario

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.

Publicado en Linux, Multipath | Deja un comentario