Cambiar la red de ceph

El sábado hice un taller en vivo sobre proxmox en el que enseñé a configurar tanto ceph como glusterfs.

Aquí el vídeo sólo de la parte de la entrevista:

Instalar proxmox es super fácil, pero preparar bien el entorno ya es otra cosa. Al prepararlo cometí un fallo de diseño al reutilitzar configuración antigua.

Tal como dije, se recomienda destinar una red específicamente para la comunicación de los ceph. Así que vamos a ello.

El contenido de mi fichero de configuración de red es el siguiente

# vi /etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.139.39.166/27
        gateway 10.139.39.161
        bridge_ports eth0.10
        bridge_stp off
        bridge_fd 0

auto vmbr1
iface vmbr1 inet static
        address 172.31.0.11
        netmask 255.255.0.0
        bridge_ports eth0.1000
        bridge_stp off
        bridge_fd 0
        post-up echo 1 /proc/sys/net/ipv4/ip_forward

auto vmbr2
iface vmbr2 inet manual
        bridge_ports eth0.1001
        bridge_stp off
        bridge_fd 0


# ceph - glusterfs # dades
iface eth1 inet manual

auto vmbr11
iface vmbr11 inet static
        address 192.168.10.1/24
        bridge-ports eth1
        bridge-stp off
        bridge-fd 0

He cambiado los bridge_ports tanto de vmbr1 como de vmbr2 y añadido el bridge vmbr11 sin vlans y con la red 192.168.10.0/24.

He aplicado la configuración correspondiente a cada nodo del cluster y los he reiniciado.

Una vez iniciados de nuevo y comprobado que lleguen los servidores entre ellos por la red 192.168.10.0/24, he ido al fichero de configuración del ceph (/etc/pve/ceph.conf) y he cambiado el parámetro cluster_network

# vi /etc/pve/ceph.conf
[global]
         auth_client_required = cephx
         auth_cluster_required = cephx
         auth_service_required 

CephFS: Montar ceph en local con Proxmox

Telita las vueltas que he dado para encontrar esta solución y todo por no fijarme bien!

Muy bien, partimos de que tenemos un Ceph funcionando correctamente y lo estamos usando para poner ahí nuestros contenedores y máquinas virtuales. Pero al hacer el backup nos interesa los datos pesados dejarlos fuera y tener un disco compartido en red es algo que es una maravilla para poder migrar libremente maquinas de un nodo a otro y además de forma muy rápida ya que no tiene que copiar los datos.

Hace días que me pregunto, ¿y cómo se hace para montar un pool de ceph como mountpoint para los datos mas pesados? Había buscado donde se montaban los datos, nada de nada, si proxmox daba alguna opción, no se daba la opción de montar ceph como mountpoint ni tampoco te deja usar este pool para hacer backups. Así que llevo con la mosca en la nariz unos días con este tema… hasta que hoy! tras instalar un nuevo cluster y poder jugar (sin romper) una instalación nueva me he puesto a mirar a fondo y tras unas horitas, al clavo!

Ceph lleva bastante tiempo en marcha y hay documentación de hace 4 años, además ha ido evolucionando muy rápido y en las últimas versiones han cambiado incluso de tecnología para escribir a disco, siendo bluestore la actual.

Tras muchas formas de hacerlo (desde el kernel, desde fstab, que crear el volumen a mano desde el servidor, etc.), ninguna me parecía muy fiable …

Introducción al trabajo con Dockerfile

Continuamos con los posts de Docker, en éste otro post hemos visto los comandos básicos para manejarnos con docker. Ahora vamos a entrar con Dockerfile para después centrarnos en docker-compose.

DOCKERFILE
El dockerfile consiste en un fichero con el nombre “Dockerfile” el cual contiene una “receta” para construir una imagen para después desplegarla como contenedor. Éste fichero lo encontraremos solo o acompañado de ficheros que se usarán para el despliegue del contenedor. Éste fichero tiene unas palabras reservadas que atienden a lo siguiente (se describen los mas usados):

FROM indica cuál es la imagen en la que se basa el contenedor que vamos a crear

MAINTAINER los datos del autor de la imagen
Sintaxis: MAINTAINER

RUN Esta instrucción ejecuta cualquier comando en una capa nueva encima de una imagen y hace un commit de los resultados. Esa nueva imagen intermedia es usada para el siguiente paso en el Dockerfile. Cuando creamos una imagen nos interesa hacerla con el mínimo de capas posible. RUN tiene 2 formatos
Sintaxis: RUN comando
Sintaxis: RUN [“ejecutable”, “parametro1”, “parametro2”]

ENV variables de entorno a pasar al crear el contenedor (-e)
Éstas variables pueden usarse dentro de cualquier fichero del entorno, por ejemplo un script ejecutable. Éstos son los valores por defecto a menos que se especifique otro en -e
Sintaxis: ENV key value
Sintaxis: ENV key=value

ADD/COPY copiar ficheros o directorios que se encuentran en el mismo sitio que el Dockerfile hacia dentro del contenedor. ADD permite descargar un fichero alojado por http.

Sintaxis: …

Comandos básicos de Docker

El otro día vimos como instalar un cluster de docker con swarm. Mas adelante veremos como se monta un cluster de Docker con Kubernettes. Tanto Swarm como Kubernettes son orquestadores de docker y para entender como funcionan antes debemos entender como usar Docker a pelo.

Docker puede funcionar perfectamente en una sola máquina y no es necesario montar un cluster, para tenerlo a mano, pego en modo resumen la parte de instalación de docker del anterior post (instalación en Debian):

root@docker-master:~# apt update && apt -y upgrade && apt -y dist-upgrade
root@docker-master:~# apt-get remove docker docker-engine docker.io containerd runc
root@docker-master:~# apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
root@docker-master:~# curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
root@docker-master:~# apt-key fingerprint 0EBFCD88
root@docker-master:~# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
root@docker-master:~# apt update
root@docker-master:~# apt-get install docker-ce docker-ce-cli containerd.io

Una vez instalado Docker, voy a explicar de que va ésto.

Docker es un software de virtualización. La virtualización nace en AIX, el sistema operativo de los mainframes de IBM. La virtualización nace de la necesidad de correr otros sistemas operativos dentro de un sistema operativo. A lo largo de los años y a medida que los servidores y ordenadores de sobremesa han sido mas potentes, han ido apareciendo muchos programas y métodos de virtualización.
Por un lado tenemos los sistemas de virtualización de un sistema operativo entero como podrían ser VirtualBox, VMWare, KVM, Xen, etc. y mas adelante salieron otros sistemas que compartían el núcleo del sistema operativo (kernel) con el host.…

Instalar cluster docker (swarm) + portainer.io

Ésta semana y la anterior estoy con un curso de DevOPs. En él estamos viendo principalmente docker y los orquestadores swarm y kubernetes.
En éste post nos vamos a centrar de momento con swarm.

Swarm viene “instalado” cuando instalamos docker y no tendremos que instalar nada addicional, simplemente configurarlo que lo veremos mas adelante.

Primero de todo pues tendremos que instalar docker, pero no usaremos los paquetes del repositorio, sino que vamos a seguir la instalación de la página web de docker para debian.

El entorno donde vamos a instalar docker van a ser 3 máquinas virtuales con KVM, docker-master (172.31.0.201), docker-worker1 (172.31.0.202) y docker-worker2 (172.31.0.203). La instalación la repetimos en las 3 máquinas.

Instalar docker

Comprobamos que docker no esté instalado y si lo está, lo desinstalamos

root@docker-master:~# apt update && apt -y upgrade && apt -y dist-upgrade
root@docker-master:~# apt-get remove docker docker-engine docker.io containerd runc

Instalamos las dependencias necesarias

root@docker-master:~# apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

Añadimos la clave GPG

root@docker-master:~# curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
root@docker-master:~# apt-key fingerprint 0EBFCD88

Configuramos el repositorio “stable”

root@docker-master:~#  add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

Instalamos docker

root@docker-master:~# apt update
root@docker-master:~# apt-get install docker-ce docker-ce-cli containerd.io

A partir de aquí ya tenemos docker instalado y procederemos a montar el cluster swarm.

Activar cluster swarm

A continuación, montaremos 1 master y 2 workers. La recomendación es tener mínimo 3 master y 3 workers. En swarm, un master puede actuar como worker. De momento en el entorno que estamos …

Instalar openstack en ubuntu 20.04 (virtualizado)

El propósito del post de hoy es investigar un poco sobre openstack. Openstack es un conjunto de programas que permiten la creación de entornos virtuales donde desplegar tus aplicaciones.

Mi idea era instalarlo en un contenedor lxc, pero no ha sido posible, nisiquiera activando el modo nested virtualization, así que la única solución ha sido instalarlo en un kvm. Mi objetivo final es ver qué posibilidades me ofrece openstack para reemplazar la infraestructura actual que tengo desplegada con proxmox.

En ésta primera prueba vamos a instalar openstack usando devstack que consiste en un conjunto de scripts que van a instalar todo lo necesario para tener un openstack completo funcionando. Si la cosa avanza, vendrán otros posts de como desplegar openstack en un cluster de 4 maquinas. En el siguiente gráfico podemos ver de que partes se compone openstack

Cada uno de los componentes tiene una función:

Dashboard: Llamado Horizon, va a ser el interfaz web para gestionar openstack. Está desarrollado en python y django (cosa que me ha alegrado muchísimo!)
Identity: Llamado Keystone, se encarga de la autenticación de los usuarios en el sistema de openstack y la asignación de permisos.
Image: Llamado glance, que es donde se pueden consultar las imágenes disponibles
Object Storage: Llamado swift, que es donde están almacenadas las imagenes
Compute: Llamado nova, que es quien se encarga de desplegar las imágenes según las necesidades de cómputo que se necesiten
Network: Llamado neutron, que …

Proxmox: habilitar virtualización anidada (nesting virtualization)

Uno de los problemas que me estoy encontrando últimamente es que los contenedores lxc que instalo con debian 10 no arrancan los servicios porque tengo que reconfigurar systemd para decirle que el PrivateTmp es false, por ejemplo para poder levantar apache2 tendría que hacer ésto

Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xe" for details.
invoke-rc.d: initscript apache2, action "start" failed.
* apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2020-07-01 16:35:29 UTC; 9ms ago
     Docs: https://httpd.apache.org/docs/2.4/
  Process: 11730 ExecStart=/usr/sbin/apachectl start (code=exited, status=226/NAMESPACE)

Jul 01 16:35:29 wordpress systemd[1]: Starting The Apache HTTP Server...
Jul 01 16:35:29 wordpress systemd[11730]: apache2.service: Failed to set up mount namespacing: Permission denied
Jul 01 16:35:29 wordpress systemd[11730]: apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: Permission denied
Jul 01 16:35:29 wordpress systemd[1]: apache2.service: Control process exited, code=exited, status=226/NAMESPACE
Jul 01 16:35:29 wordpress systemd[1]: apache2.service: Failed with result 'exit-code'.
Jul 01 16:35:29 wordpress systemd[1]: Failed to start The Apache HTTP Server.

# vi /lib/systemd/system/apache2.service
PrivateTmp=false
:wq
# systemctl daemon-reload
# systemctl start apache2.service

Pero me encuentro el mismo problema con otros servicios que instalo.

Por lo que entiendo systemd crea como una especie de “entorno virtual” para cada uno de los servicios y para que funcione correctamente, leyendo documentación veo que la solución es habilitar la virtualización anidada.

Así que en la documentación de proxmox encontramos ésta página que nos dice como hacerlo.

Tendremos …

Redirección de puertos con iptables + contrack

Pues seguimos con éstos pequeños errores que hemos cometido siempre y que ahora en un momento de cambios y con mucho mas entendimiento llegan mejores soluciones para que las cosas funcionen mejor (tanto a nivel técnico como personal). Hoy estoy tiernecilla y quiero agradecer con éste post todas éstas personas que seguís los posts que publico y tenéis al igual que yo éste blog como una herramienta de consulta, un lugar claro, sin muchas complicaciones donde encontrar justo aquello que necesito en cada momento o me da la pista para poder seguir avanzando con algo mas grande que estoy construyendo con el paso de los días.

Ésta vez me encuentro solucionando un problema que inicialmente parecía de nginx pero ha resultado ser de iptables, y es que las cosas nunca son lo que parecen a primera vista y es necesario tener un gran conocimiento del sistema para entender como poder solucionar los problemas de base y encontrar una solución definitiva que evita fallos futuros, para casos como hoy que ya en producción me encuentro con un problema grave de base. Para que un sistema funcione bien, las capas inferiores (base) deben estar bien.

Me dejo ya de palabrerías y comentarios dobles y me pongo en materia. El post que rectifico es éste: Proxmox + nat + iptables.

Gracias a las configuraciones de las antenas en los supernodos entiendo que se deben marcar los paquetes tanto de entrada (prerouting) como de salida (postrouting). En TCP hay una llamada de un …

GlusterFS

GlusterFS es un gestor de ficheros en red. Básicamente lo que permite es replicar unos mismos ficheros en varios servidores, para luego con los clientes de glusterfs conectar a alguno de ellos y definir otro de backup en el caso de que se caiga el primero. Con éste sistema tenemos redundancia de los datos.

La recomendación es usar 3 nodos servidores de gluster, en mi caso, ahora mismo no dispongo del tercero, y lo añadiré mas tarde.

Vamos a trabajar con 3 nodos, Node1A, Node1B y Node2A, los dos primeros serán los servidores que tendrán el disco duro que queremos compartir en red, y el último sólo va a actuar como cliente.…

proxmox 6 + ceph

Por fin otro logro mas que me había dado guerra durante muchas horas, el motivo un ceph roto al que de momento he preferido migrar los datos a otro sitio y ya con mas calma intentaremos recuperarlo (ya vendrá otro post otro día sobre éste tema).

En motivo del ceph roto he aprovechado para reinstalar la infraestructura de proxmox entera sobre proxmox6 (debian10).

Partimos de 5 nodos unidos en el cluster (pvecm add ipmaster), sólo vamos a instalar ceph en 3 de ellos.

- node1A - 172.31.0.1 (ceph)
- node1B - 172.31.0.2
- node1C - 172.31.0.3 (ceph)
- node1D - 172.31.0.4 (ceph)
- node2D - 172.31.0.8

El nodo maestro del cluster es “node1D”, y para ver que ésto no implica nada a la hora de configurar ceph y también porque romper el 1D era una cosa que no me podía permitir… vamos a empezar por “node1A”.

Para ello vamos a la interfaz web de proxmox e instalamos ceph:…