Celtha.sh: 2016

domingo, 4 de septiembre de 2016

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.107: bond0.10@bond0: 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 addrgenmode eui64

[root@XXXXnetwork-scripts]# ip a l 1: lo: ...2: eno1: 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: 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: 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: 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

domingo, 17 de julio de 2016

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.

jueves, 28 de enero de 2016

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: