|
|
|
## Procedimiento de Upgrade de Proxmox 6 a 8
|
|
|
|
|
|
|
|
### Pasos previos
|
|
|
|
|
|
|
|
* **Primero que nada, es estrictamente necesario contar con alguien en Mdeo con disponibilidad de trasladarse hacia SeCIU en caso de que ocurra algún problema durante el upgrade** (ej.: no arranquen los nodos luego de actualizciones)
|
|
|
|
|
|
|
|
* **Dar un aviso general a los usuarios de nuestros servicios acerca de tareas de mantenimiento que estaremos realizando sobre nuestros servidores durante toda la semana (upgrades de nodos)**
|
|
|
|
|
|
|
|
* **Snapshots de la totlidad de los servicios**
|
|
|
|
- En cada uno de los nodos y para cada LXC y VM que lo permita realizar un Snapshot, de modo de poder recuperar rapidamente un estado previo de cada servicio en caso de catastrofe.
|
|
|
|
|
|
|
|
* **Respaldos nocturnos de servicios críticos y que no admiten Snapshots**
|
|
|
|
- Programar respaldos Proxmox de servicios (con detención) de acuerdo a la siguiente lista de host a respaldar:
|
|
|
|
- Servicios con discos NFS que **NO admiten Snapshots**
|
|
|
|
- Envido
|
|
|
|
- Po
|
|
|
|
- Candombe
|
|
|
|
- Garraphinada??
|
|
|
|
- Mondongo
|
|
|
|
- Servicios archicríticos que manejan datos dinámicos:
|
|
|
|
- Asado
|
|
|
|
- Godel
|
|
|
|
- Dirac
|
|
|
|
- Timbo
|
|
|
|
- Arrayan
|
|
|
|
- Impecable
|
|
|
|
- Imponente
|
|
|
|
- Escabio (Hospedaje)
|
|
|
|
- Cafetin
|
|
|
|
- **A no olvidarse de activar `backup` para los discos NFS montados en los LXC a respaldar.**
|
|
|
|
|
|
|
|
* En la IAC ubicar a Botija, Guri, Redota y Guyunusa dentro del grupo del invetario `seciu_fierrosToUpgrade`.
|
|
|
|
|
|
|
|
* Por precausión armar un listado de máquinas prendidas y apagadas previo a proceder con la actualización.
|
|
|
|
|
|
|
|
* En cada nodo además ejecutamos playbook `previo_upgrade_paquetes_proxmox_6.4.yml`:
|
|
|
|
|
|
|
|
`ANSIBLE_STDOUT_CALLBACK=yaml ansible-playbook -i hosts_prod tools/previo_upgrade_paquetes_proxmox_6.4.yml -vv`
|
|
|
|
|
|
|
|
El cual se encargará de:
|
|
|
|
- Configurar repositorios de Debian externos
|
|
|
|
- Verificar directivas en `/etc/default/grub`
|
|
|
|
- Chequear que el paquete `ifupdown2` esté instalado
|
|
|
|
- Tomar nota de las direcciones MAC de los bridges de los nodos
|
|
|
|
|
|
|
|
### Agenda
|
|
|
|
|
|
|
|
La idea es continuar con el resto del procedimiento de acuerdo a la siguiente Agenda:
|
|
|
|
|
|
|
|
- Lunes
|
|
|
|
- Extender LVM-thin de Botija y Guri
|
|
|
|
- Actualización de paquetes dentro de Proxmox 6.4 (4 nodos)
|
|
|
|
- Downtime de servicios aproximado: 2 horas
|
|
|
|
- Martes
|
|
|
|
- Upgrade Proxmox 6 a 7 (4 nodos)
|
|
|
|
- Downtime de servicios máximo: 4 horas
|
|
|
|
- Miercoles
|
|
|
|
- Upgrade Proxmox 7 a 8 (4 nodos)
|
|
|
|
- Downtime de servicios máximo: 4 horas
|
|
|
|
|
|
|
|
### Actualización de paquetes dentro de Proxmox 6.4
|
|
|
|
|
|
|
|
- Actualizar los paquetes del sistema opertivo a la última versión disponible dentro de Buster y Proxmox 6.4
|
|
|
|
* de a un nodo a la vez:
|
|
|
|
- Gurí
|
|
|
|
- Guyuusa
|
|
|
|
- Redota **(previamente hay que detener todo servidor que tenga discos en redota)**
|
|
|
|
- Botija
|
|
|
|
* procediendo así:
|
|
|
|
- **`screen`**
|
|
|
|
- `pveversion` (determinar en este punto si habrá cambio de Kernel)
|
|
|
|
- si el nodo tiene cambio de Kernel (como Botija y Redota) apagamos cada una de sus virtuales (LXCs y Vms)
|
|
|
|
- `apt update`
|
|
|
|
- `apt dist-upgrade`
|
|
|
|
- `reboot` (si cambió el kernel)
|
|
|
|
|
|
|
|
- Si da problemas con el grub ir a mirar [esto](https://git.interior.edu.uy/adminsys/config/-/issues/406#note_7515)
|
|
|
|
|
|
|
|
### Upgrade Proxmox 6 a 7
|
|
|
|
|
|
|
|
- En cada nodo ejecutamos de forma manual el script `pve6to7` tomando acciones de acuerdo a los warnings obtenidos.
|
|
|
|
- Ejecutamos el playbook `previo_upgrade_proxmox_6_a_7.yml`:
|
|
|
|
|
|
|
|
`ANSIBLE_STDOUT_CALLBACK=yaml ansible-playbook -i hosts_prod tools/previo_upgrade_proxmox_6_a_7.yml -vv`
|
|
|
|
|
|
|
|
- Proceder con el upgrade a PVE 7,
|
|
|
|
* de a un nodo a la vez:
|
|
|
|
- Gurí
|
|
|
|
- Guyuusa
|
|
|
|
- Redota
|
|
|
|
- Botija
|
|
|
|
* procediendo así:
|
|
|
|
- **`screen`**
|
|
|
|
- `apt update`
|
|
|
|
- **Detener la totalidad de LXCs y VMs del nodo**
|
|
|
|
- **Si es Redota, además hay que detener todo servidor (de otros nodos) que use discos NFS**
|
|
|
|
- `apt dist-upgrade` (ver Las preguntas)
|
|
|
|
- `reboot`
|
|
|
|
|
|
|
|
- Verificaciones de correcto funcionamiento de los servicios
|
|
|
|
- Editar a mano el archivo de configuración de LXCs que funcionen como VPNs, como Zarpado y Pulperia, cambiando `cgroup` por `cgroup2`.
|
|
|
|
|
|
|
|
### Upgrade Proxmox 7 a 8
|
|
|
|
|
|
|
|
- En cada nodo ejecutamos de forma manual el script `pve7to8` tomando acciones de acuerdo a los warnings obtenidos.
|
|
|
|
- Ejecutamos el playbook `previo_upgrade_proxmox_7_a_8.yml`:
|
|
|
|
|
|
|
|
`ANSIBLE_STDOUT_CALLBACK=yaml ansible-playbook -i hosts_prod tools/previo_upgrade_proxmox_7_a_8.yml -vv`
|
|
|
|
|
|
|
|
- Proceder con el upgrade a PVE 8,
|
|
|
|
* de a un nodo a la vez:
|
|
|
|
- Gurí
|
|
|
|
- Guyuusa
|
|
|
|
- Redota **(previamente hay que detener todo servidor que tenga discos en redota)**
|
|
|
|
- Botija
|
|
|
|
* procediendo así:
|
|
|
|
- **`screen`**
|
|
|
|
- `apt update`
|
|
|
|
- **Detener la totalidad de LXCs y VMs del nodo**
|
|
|
|
- **Si es Redota, además hay que detener todo servidor (de otros nodos) que use discos NFS**
|
|
|
|
- `apt dist-upgrade` (ver Las preguntas)
|
|
|
|
- `reboot`
|
|
|
|
|
|
|
|
- Verificaciones de correcto funcionamiento de los servicios
|
|
|
|
|
|
|
|
### Servicios con discos NFS en Redota
|
|
|
|
|
|
|
|
En parentesis se indica si permite snapshat o no:
|
|
|
|
|
|
|
|
- Tala (NO)
|
|
|
|
- Envido (NO)
|
|
|
|
- Po (NO)
|
|
|
|
- Candombe (NO)
|
|
|
|
- Ibirapita (NO)
|
|
|
|
- Rambla (NO)
|
|
|
|
- Garraphinada (NO)
|
|
|
|
- Mondongo (NO)
|
|
|
|
- Buenaso (NO)
|
|
|
|
- Dirac (SI)
|
|
|
|
|
|
|
|
A excepción de Dirac, a los demás habría que progrmarle respaldos nocturnos antes de proceder.
|
|
|
|
|
|
|
|
### Las preguntas
|
|
|
|
|
|
|
|
El sistema consultará durante el upgrade si se desea instalar (**Sí**) nuevas versiones provenientes del desarrollador de determinados archivos de configuración (en conflicto) o por el contrario conservar (**No**) las versiones actuales de los mismos. Los casos y mí respuesta fueron los siguientes:
|
|
|
|
* **De PVE 6 a 7**:
|
|
|
|
* `/etc/issue`, **No**, porque solo le dá efectos "cosmeticos" al login
|
|
|
|
* `/usr/share/unattended-upgrades/50unattended-upgrades`, **Sí**, que instale la nueva versión porque incorpora cambios en la nomenclatura de los repos fundamentalmente (luego vemos si merece ejecutar el playbook arriba o no)
|
|
|
|
* `/etc/apt/sources.list.d/pve-enterprise.list`, **No**, porque hemos comentado a propósito este repo vía playbooks.
|
|
|
|
* **De PVE 7 a 8**:
|
|
|
|
* `/etc/issue`, **No**,
|
|
|
|
* `/etc/default/grub`, **Sí**, que instale la versión del responsable del paquete. Este conflicto se dá porque explicitamente le pusimos al archivo un `GRUB_DISABLE_OS_PROBER=true`, que luego habrá que reincorporar...
|
|
|
|
* `/etc/lvm/lvm.conf`, **Sí**, porque cambia un monton:
|
|
|
|
|
|
|
|
> Changes relevant for Proxmox VE will be updated, and a newer config version might be useful.
|
|
|
|
>
|
|
|
|
> If you did not make extra changes yourself and are unsure it's suggested to choose "Yes" (install the package maintainer's version) here.
|
|
|
|
|
|
|
|
* `/etc/apt/sources.list.d/pve-enterprise.list`, **No**
|
|
|
|
|
|
|
|
### Cambios de Kernel
|
|
|
|
|
|
|
|
**Primer dist-upgrade (6.4)**
|
|
|
|
* PVE: 6.4-15
|
|
|
|
* Kernel: 5.4.203
|
|
|
|
|
|
|
|
**Upgrade 6 a 7**
|
|
|
|
* PVE: 7.4-17
|
|
|
|
* Kernel: 5.15.131
|
|
|
|
|
|
|
|
**Upgrade 7 a 8**
|
|
|
|
* PVE: 8.1.3
|
|
|
|
* Kernel: 6.5.11
|
|
|
|
|
|
|
|
### Comandos utiles
|
|
|
|
|
|
|
|
* `systemctl status pve*`
|
|
|
|
* `pvenode config get`
|
|
|
|
* `pvenode cert info`
|
|
|
|
* `pveverion -v`
|
|
|
|
|
|
|
|
En un cluster:
|
|
|
|
|
|
|
|
* `pvecm status`
|
|
|
|
* `pvecm nodes` |
|
|
\ No newline at end of file |
