| ... | ... | @@ -6,11 +6,25 @@ El procedimiento se basa en la [recomendación oficial de Proxmox](https://pve.p |
|
|
|
|
|
|
|
Los pasos finales se realizan manualmente ya que son más críticos y cada nodo puede tener detalles particulares, no del todo previsibles.
|
|
|
|
|
|
|
|
## Paso 0: respaldos
|
|
|
|
Decidimos priorizar la minimización del riesgo de pérdida de datos respecto a la interrupción de servicios, que prevemos de menos de un día. Procedemos según los pasos siguientes:
|
|
|
|
- eventualmente (estimar tiempos): migrar todos los servidores con datos dinámicos críticos a uno de los dos servidores aplicativos, `Botija` y `Gurí`. Digamos `Botija`, que ya tiene a `Gödel`, el más voluminoso,
|
|
|
|
- detención de servicios de madrugada y respaldos en frío de los servidores críticos,
|
|
|
|
- pasos iniciales de la actualización Proxmox (pve 5.4-13, corosync 3, reboot hardware para tomar en cuenta los nuevos kernel
|
|
|
|
- actualización pve5.4->pve6 de `Mate`, como primer prueba. verificaciones, en particular alguna migración.
|
|
|
|
- actualización pve5.4->pve6 de `Gurí`, el servidor madre que tiene los virtuales menos críticos,
|
|
|
|
- encendido de virtuales, verificaciones.
|
|
|
|
- actualización pve5.4->pve6 de `Redota` (acá debe funcionar sí o sí....). Encendido, verificaciones.
|
|
|
|
- eventualmente: Migración de los servicios más críticos de `Botija` a `Gurí` (esto vale de verificación antes de actualizar el último pve5)
|
|
|
|
- actualización pve5.4->pve6 de `Botija`. Encendido, verificaciones.
|
|
|
|
- verificaciones globales (en particular re-establecer los respaldos periódicos que sin duda vamos a desactivar)
|
|
|
|
|
|
|
|
Se planea hacer resplados "Proxmox" completos a todos los hosts (VMs y containers) que son considerados críticos por contener datos y/o configuraciones no recuperables a través de los playbooks y roles desarrollados hasta el momento.
|
|
|
|
## Paso 0: detención de servicios y respaldos
|
|
|
|
|
|
|
|
Los servidores considerados críticos (al 13 de Enero de 2020) son:
|
|
|
|
Se planea detener y hacer resplados "Proxmox" completos en frío a todos los hosts (VMs y containers) que son considerados críticos por contener datos dinámicos no recuperables desde los últimos respaldos. Se dejan de lado todos los hosts que sólo requieren configuraciones a través de los playbooks y roles desarrollados hasta el momento.
|
|
|
|
|
|
|
|
Debemos considerar las herramientas para orquestar la detención de servicios y los respaldos la madrugada anterior.
|
|
|
|
|
|
|
|
Los servidores considerados críticos ([al 13 de Enero de 2020](https://pad.interior.edu.uy/p/adminsys2019)) son:
|
|
|
|
|
|
|
|
En Botija:
|
|
|
|
- Asado (AlternC. alternc.interior)
|
| ... | ... | @@ -34,7 +48,9 @@ En Guri: |
|
|
|
En Redota:
|
|
|
|
- Che (Respaldos. che.interior)
|
|
|
|
|
|
|
|
Al momento de realizar los respaldos, **es importante estar atentos a los hosts que contienen puntos de montaje adicionales** (Asado, Chingolo, Sabiá). En dichos puntos de montaje, es necesario que se active el flag `backup` 
|
|
|
|
Quizás convenga previamente migrar los servidores más críticos a uno de los servidores Botija o Gurí.
|
|
|
|
|
|
|
|
Al momento de realizar los respaldos, **es importante estar atentos a los hosts que contienen puntos de montaje adicionales** (Asado ok, Chingolo ok, Sabiá ok). En dichos puntos de montaje, es necesario que se active el flag `backup` 
|
|
|
|
|
|
|
|
El destino de los respaldos será el storage correspondiente al segundo RAID de discos de `Redota`. Este storage se encuentra compartido con los demás nodos del cluster a través de NFS, con nombre de recurso `respaldosEnRedota`.
|
|
|
|
|
| ... | ... | |
| ... | ... | |
