Proxmox y Ceph de 0 a 100 Parte IV

Creación de VM y Contenedor en HA

En este post "Proxmox y Ceph de 0 a 100 parte IV", veremos como crear una máquina virtual y un contenedor en alta disponibilidad.

Cada tipo de almacenamiento permitirá unas características u otras, si nos dirigimos a nuestro cluster en la sección almacenamiento veremos cuales tenemos disponibles y para que fin

Como podemos observar tenemos nuestro Pool1 que nos permite Imagen de disco y contenedores, local Archivos de VZdump backup, Imagen ISO, Plantillas de contenedor y local-lvm Imagen de disco y contenedor. Según el tipo de almacenamiento, si hacemos click en editar nos permitirá seleccionar un fin o varios para el almacenamiento. Por ejemplo el local

Nos permite utilizarlo para cualquier fin, mientras que Pool1 y LVM-thin solo nos permitirá Imagen del disco y Contenedor.

Por lo tanto para poder almacenar una ISO solo tenemos el local, donde el almacenamiento local en este laboratorio no es muy grande y una ISO de Windows por ejemplo no entraría, para ello necesitaríamos añadir otro tipo de almacenamiento que nos lo permita más grande. En este laboratorio nos descargaremos una ISO en PVE1 y una Plantilla en PVE2

Para cargar las ISO tenemos 2 opciones, por la gui o conectarnos a la consola y utilizar por ejemplo wget, esto último por norma general será lo más rápido, puesto que nuestro CPD tendrá más ancho de banda de descarga que la subida que podemos proporcionar con nuestra linea.

Por la GUI iremos a nuestro almacenamiento y en contenido tendremos 2 opciones, Plantillas y Cargar, si hacemos click en Cargar nos saldrá un desplegable para si queremos subir una plantilla o una Imagen ISO, seleccionaríamos el fichero y hacemos click en cargar.

Esto es muy sencillo, pero como os indico, más lento y que no tengas que volver a subirla porque se haya cortado. El mejor método es por consola, nos dirigimos al punto de montaje del almacenamiento, en este caso /var/lib/vz/ y dentro de el al directorio template/iso, es decir,

cd /var/lib/vz/template/iso

Ahora por ejemplo para tener la ISO de Debian 10 minimal, escribimos

wget https://cdimage.debian.org/cdimage/archive/10.13.0/amd64/iso-cd/debian-10.13.0-amd64-netinst.iso

Una vez terminado tendremos nuestra ISO en dicho almacenamiento y podremos utilizarla para crear una máquina en el nodo donde hemos descargado la ISO, tendrías que realizar este proceso en el nodo donde quieres instalar la máquina utilizando almacenamiento local, puedes tener también  un nodo con las ISOS en local y luego mover la máquina cuando esté terminada a otro nodo expulsando dicha ISO de la máquina virtual, lo más cómodo sería un almacenamiento para las ISO NFS o CIFS por ejemplo, y así poder disponer de ellas desde cualquier nodo.

Respecto al apartado Plantillas o subida de Plantillas se refiere a Plantillas de contenedores. Proxmox además de poner a tu disposición varias plantillas también te ofrece descargarte las de Turnkey directamente. Si nos dirigimos al almacenamiento local, ahora de PVE2 ya que en el uno tenemos la ISO de Debian y no tenemos mucho espacio, si  hacemos click en Plantillas veremos todas las plantillas que podemos descargarnos.

Seleccionamos la que queramos y le damos a Descargar. Ya tenemos nuestra ISO y nuestra plantilla para desplegar una VM y un CT. 

Una vez tenemos las ISO nos vamos a dirigir a cluster/Permisos/Pools y crearemos un Pool con el nombre VirtualMachine y otro Contenedores. ¿Para que sirve? Esto nos permitirá asignar MV o CT a un pool en la creación , imaginaros tenemos 2, uno para VM y otro para CT, luego podemos crear un usuario que solo tenga permisos sobre las VM, otro sobre los CT y otro sobre ambos, esto nos da flexibilidad para delegar. También nos permitirá ver los recursos por grupos en la GUI

lo siguiente sería crearnos un grupo de HA en Cluster/HA/Grupos que luego asignaremos a las máquinas y contenedores, podemos definir varios grupos de HA, en función de nuestras necesidades o divisiones en la infraestructura. Damos a crear

ID ponemos un nombre identificativo para nosotros.

Restricted, si marcamos dicha casilla las VM o CT asociados en este grupo de HA solo podrán arrancar en este grupo, si todos los nodos del grupo están caídos no levantará hasta que haya uno disponible. Si lo dejamos sin marcar y los nodos del grupo están caídos se irían a otro grupo disponible hasta que hubiera un nodo disponible del grupo al que pertenece y movería dicha máquina a su grupo.

Nofailback activado intenta ejecutar servicios en el nodo con la prioridad más alta, es decir, si un nodo con mayor prioridad se conectara el servicio se migraría a ese nodo

Y por último tenemos los nodos que queramos asignar al grupo de HA y si le queremos dar prioridad o no.

Además si os acordáis en el primer post instalamos una tercera tarjeta para la red de las máquinas la cual procederemos a configurar. En cada nodo nos vamos a Sistema/red/Crear/Linux Bridge, donde solo necesitaremos darle un nombre, marcar inicio automático, cual es nuestra tarjeta física de puente y un comentario para identificarla

Le damos a crear y como instalamos ifupdown2 podemos dar a Apply Configuration arriba sin necesidad de reiniciar los nodos.

Pasemos a crear nuestra máquina, hacemos click en la parte superior derecha en el botón azul Crear VM y nos saldrá la primera pantalla de creación

Seleccionamos el nodo, el id que queremos darle a la máquina por defecto empieza en el 100, un nombre y el conjunto de recursos donde aparecerán los pools que creamos en la parte de permisos.

Marcamos la casilla Avanzado para que nos salga las opciones inferiores. Si queremos o no que inicien en el arranque del nodo, si le queremos dar un orden de Inicicio/Apagado, esto es muy interesante cuando tenemos máquinas críticas y no críticas priorizando nuestro servicio. Si priorizamos a las no críticas le metemos un Retardo de inicio para que las críticas tengan más recurso en el arranque.

En la siguiente pantalla elegimos el SO, no hay mucho que explicar es muy intuitivo

Continuamos y tendremos Sistema, esta parte es bastante extensa como para explicar en un post porque dependerá un poco de cada máquina, lo único que haremos es activar Qemu Agent que será usado para intercambiar información entre el host y la máquina , en la ayuda viene todo muy bien explicado, cualquier duda comentarnos y os ayudamos.

La parte de disco también es muy extensa pero si explicaremos que por norma general, VirtIO Block con Write back tiene un rendimiento muy bueno y muy importante, el formato, como podréis apreciar en la siguiente imagen viene deshabilitado porque utilizará RBD Format 2. Esto nos permite por ejemplo clonado y snapshot, en los almacenamientos basados en archivos solo el formato qcow2 nos permitirá la funcionalidad de snapshot. Importante también la casilla Copia de seguridad, si está desactivada como en la imagen cuando creemos una tarea de backup este disco no lo incluirá, al igual con la de Replicación pero al contrario, si la marcamos no lo incluirá.

Respecto al resto de opciones son bastante intuitivas pero también están en la ayuda explicadas.

Pasamos a la CPU, donde ya tenemos opciones para aburrir y todo dependerá de nuestro escenario, como digo esto mirarlo en la ayuda y si tenéis dudas o algún problema preguntarnos.

Respecto a memoria, tenemos la opción de asignarle una memoria fija o hacer Ballooning, esto dependerá de lo que vayamos a montar. La casilla Compartiendo nos permitirá dar más prioridad frente a otras máquinas si aumentamos el valor por defecto 1000 cuando activamos Ballooning

Por último antes de confirmar debemos configurar la red seleccionando nuestra red de VM y CT, en este apartado comentar que dependiendo del sistema necesitaras jugar con ellos para conseguir un buen rendimiento, por norma general VirtIO funciona muy bien pero por ejemplo en FreeBSD es problemático.

Le damos a siguiente, marcamos Start after created y Finalizar

Una vez arrancada la máquina, la seleccionamos, nos dirigimos a consola y realizamos la instalación del sistema operativo. En este caso al ser un Debian 10 cuando terminemos instalaremos el agente qemu para poder tener ese intercambio de información entre host y máquina virtual con:

apt install qemu-guest-agent

systemctl start qemu-guest-agent

En Windows hay que realizar más pasos, nos descargaríamos la última ISO de Windows VirtIO Drivers en nuestro almacenamiento de ISOs. Montaríamos la ISO en el DVD, buscaríamos qemu-ga-x86_64.msi o qemu-ga-i386.msi en el directorio guest-agent y lo instalaríamos. 

Perfecto, repetimos los pasos para el CT pero con alguna diferencia, ya que no tendremos que definir hardware al correr sobre el host. Hacemos click en el botón azul en la parte superior derecha Crear CT.

Como podemos observar esta primera parte es un poco diferente. Hemos seleccionado PVE2 que es donde tenemos nuestra plantilla almacenada en local, le hemos puesto un id y nombre, asignado al pool Contenedores y establecido nuestra pass de root al contenedor, también podemos cargarle una clave SSH.

A continuación en Plantilla seleccionamos local y nuestra plantilla, click siguiente, pasamos a Disco root

Aquí seleccionaremos el almacenamiento y el tamaño, flags de montaje como noexec para impedir la ejecución de binarios, ACLs que permite establecer una propiedad de archivo más detallada que el modelo tradicional de usuario / grupo / otro y saltar replicación que es igual que en las VM.

Lo siguiente sería la CPU donde no hay mucho que explicar si se leyeron la documentación cuando crearon la Máquina Virtual por lo tanto pasamos a la memoria donde nos encontramos la memoria y el tamaño de la partición swap donde dependiendo de la memoria y tipo de contenedor le asignaremos un tamaño u otro por debajo de 1 GB pongan siempre la misma cantidad de SWAP. Como observaran aquí no hay Ballooning ya que los contenedores a diferencia de las máquinas no tienen memoria reservada, es decir, si ponemos 4 GB y está consumiendo 512MB el resto estará disponible para el cluster, en la Máquinas virtuales si ponemos mínimo 2GB esa memoria queda reservada aunque no se use.

El siguiente paso sería la red donde tendremos que asignar nuestra configuración bien con ips fijas o estáticas, normalmente utilizaran estáticas en producción. Como estamos utilizando una rednat de virtualbox le asigno una ip de dicha red. Tienen también opción de Etiquetado VLAN y limitación.

Por último los DNS si quieren utilizar otros que no sean los del propio host y Confirmar

Tras unos minutos tendremos en este caso un Jenkins totalmente funcional sin necesidad de instalar sistema operativo,nginx,jenkins,solo en el primer arranque es posible que te pida algunos datos como en el caso de Jenkins que te pedirá que pongas una password para el jenkins-admin, por ejemplo. Un ahorro de tiempo brutal, aunque un arma de doble filo porque luego cuando quieres montar un Jenkins en una máquina virtual ya no te acuerdas y todo el tiempo que ganaste con los contenedores lo vas a gastar en levantar un Jenkins jajaja, es broma.

Una vez tenemos nuestras máquinas necesitamos añadirlo al grupo de HA que creamos anteriormente, para ello tenemos 2 opciones, seleccionar la máquina y a la derecha en Más seleccionar Administrar alta disponibilidad

Donde nos aparecerá la siguiente pantalla

Reiniciar Máx es el número máximo de intentos para reiniciar un servicio fallido en el nodo actual.

Max Relocate es el número de intentos para reubicar el servicio en un nodo diferente, esto solo ocurrirá cuando se excede el valor de Reiniciar Máx.

El grupo de HA al que vamos a asociar el servicio, en este caso el que creamos anteriormente PVE1-2-3

Por último el Request size donde tenemos las siguientes opciones.

started: Intenta iniciar el servicio y lo marcará como iniciado si es exitoso o en error si tras los parámetros establecidos no ha conseguido arrancar el servicio en otro nodo. Esto último pasará por ejemplo, si hacemos uso del Backup, si la caída se produce durante dicho backup HA no podrá levantar el servicio en otro nodo porque está bloqueado por el backup, habría que desbloquear la máquina por consola manualmente con qm unlock id-maquina

stopped: dejará el recurso en estado detenido pero lo migrará a otro nodo.

disabled: dejará el recurso en estado detenido y no lo migrará a otro nodo

ignored: el recurso es eliminado del estado de administrador y todas las llamadas a la API a este recurso se ejecutarán sin pasar directamente por la pila de HA.

Por lo tanto para mantener el servicio levantado, seleccionamos started y hacemos click en agregar.

El otro lugar donde agregar recursos en HA sería en Cluster/HA haciendo click en Agregar.

Saldrá la misma ventana de configuración, seleccionamos nuestro contenedor, lo configuramos y ya tendremos ambos recursos en HA

En Proxmox podremos hacer simulación de HA con pve-ha-simulator, para ello necesitamos descomentar el repositorio que añadimos pve-no-subscription en /etc/apt/sources.list eliminando la almohadilla del principio en

deb http://download.proxmox.com/debian/pve buster pve-no-subscription

Salvamos y realizamos

apt update

apt install pve-ha-simulator xauth

Una vez instalado en /root por ejemplo creamos el directorio hasimulator

mkdir hasimulator

Para poder ejecutar dicho comando debemos redireccionar las X11 de ahí que hayamos instalado el paquete xauth, por lo tanto nos conectamos al nodo por ssh con

ssh root@pve1 -Y

(en Windows podéis utilizar MobaXterm ) y ejecutamos 

pve-ha-simulator hasimulator/

Nos aparecerá la siguiente ventana.

Eliminamos las que hay con la X roja y añadimos nuestra vm y CT, encendemos arriba los nodos y nos quedará así

Ahora podemos empezar hacer pruebas sin miedo para comprobar nuestra configuración  ya que esto solo simulará no ejecutará ninguna orden en Proxmox, por ejemplo apagamos el nodo 1 y observamos todo el proceso que hubiera hecho nuestra plataforma ante este evento.

Como podemos observar en el log nos indica todo lo que ha realizado ante la caída del nodo 1 migrando la vm con id 100 al nodo 3. Podéis hacer todas las simulaciones que necesitéis para ver como se comportaría vuestro cluster según las configuraciones.

Podéis hacer esto mismo apagando una de las máquinas virtuales para ver como se comporta el HA y CEPH.

Vamos a apagar la vm del nodo PVE2 como si hubiera caído repentinamente, simplemente en VirtualBox le damos a la x de la ventana y apagar y observaremos en nuestra plataforma como el CT 101 lo levanta en otro nodo, en este caso en el PVE3.

Si ahora apagamos el PVE3 veremos que ya no podrá hacer nada porque hemos perdido el acceso a ceph y no hay quorum en PVE1 por lo tanto veremos todas las máquinas apagadas y Pool1 con interrogación en los 3 nodos.

Si volvemos a encender los otros 2 nodos veremos como se recupera todo de manera automática sin perder ningún dato de las máquinas ya que al quedar una sola réplica de ellas ceph bloqueo el acceso, manteniendo una copia intacta de los datos y evitando que se dañará la única que queda. Eso sí paciencia porque en este laboratorio con los recursos que tenemos tardará un rato.

Como siempre un placer, terminaremos esta serie de post con Backups y algunos comandos útiles del día a día. Si quieres adquirir alguna de las licencias ponte en contacto con nosotros,  somos partner de Proxmox.

TL.