Plan-y-procedimiento-de-actualización-del-cluster-Proxmox-5.X-a-6.md

@@ -6,17 +6,18 @@ 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.
 
-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)
+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. 
+
+A grandes rasgos, procedemos según los pasos siguientes:
+- Migrar todos los servidores con datos dinámicos críticos a uno de los dos servidores aplicativos, `Botija` y `Gurí`. Elegimos `Botija`, que ya tiene a `Gödel` el host más voluminoso (1TB aprox.)
+- Detención de servicios (apagado de los LXC/KVM) en la madrugada previa y horas despues respaldos Proxmox programados en frío de los servidores críticos.
+- Llevar adelante los pasos iniciales de la actualización Proxmox (upgrade sencillo a PVE 5.4-13, dist-upgrade a Corosync 3, reboot hardware para tomar en cuenta los nuevos kernel) simultáneamente en todos los nodos mediante la ejecución del playbook `upgrade_proxmox_5_a_6.yml`
+- Actualización PVE 5.4 -> PVE 6 de `Mate` (nodo de staging) como primer prueba (teniendo `Mate` el hardware más antiguo y limitado, es un nodo dedicado a pruebas, no es un eslabón crítico en la cadena de servicios que se encuentran en producción). Verificaciones, en particular alguna migración.
+- Actualización PVE 5.4 -> PVE 6 de `Gurí`, el servidor madre aplicativo que tiene los hosts menos críticos (ya que fueron movidos a `Botija` en el primer paso.
+- Encendido de virtuales en `Gurí`, verificaciones.
+- Actualización PVE 5.4 -> PVE 6 de `Redota` (acá debe funcionar sí o sí... Es el único nodo de storage). Encendido, verificaciones. 
+- Actualización PVE 5.4 -> PVE 6 de `Botija`. Encendido, verificaciones. 
+- Verificaciones globales (en particular re-establecer los respaldos periódicos que debimos desactivar).
 
 ## Paso 0: detención de servicios y respaldos
 
@@ -26,6 +27,7 @@ Para orquestar la detención de servicios el día anterior ejecutamos:
 ```
 ansible -i hosts_prod seciu_hosts -a "shutdown -h 01:00" -u deploy --become
 ```
+
 Los servidores considerados críticos ([al 13 de Enero de 2020](https://pad.interior.edu.uy/p/adminsys2019)) son: 
 
 En Botija:
@@ -50,14 +52,11 @@ En Guri:
 En Redota:
 - Che (Respaldos. che.interior)
 
-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` ![backup flag](uploads/c26146e55d308ba2fdcacfc8c94815ba/image.png)
+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` ![backup flag](uploads/c26146e55d308ba2fdcacfc8c94815ba/image.png)
 
-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`.
+El destino de los respaldos será el storage `RespaldosLocales`, del correspondiente nodo en que se encuentre cada hosts. Se utiliza este storage por encontrarse físicamente en `Gurí` y `Botija` sobre un RAID5 de discos SSD, aumentando la performace tanto por la velocidad de escritura en disco como por evitar realizar transferencias a través de la red de la plataforma.
 
-Teniendo `Mate` el hardware más antiguo y limitado, es un nodo dedicado a pruebas, no es un eslabón crítico en la cadena de servicios que se encuentran en producción. Por esta razón, días previos al upgrade definitivo, se planea **vaciarlo, extraerlo del cluster, actualizarlo (independientemente) a Proxmox 6, y probar en él la recuperación de los respaldos realizados a los servidores críticos.**
-A su vez, se tendrá `Mate` a disposición en todo momento durante los sucesivos upgrades entre versiones menores y mayores, para realizar otras pruebas o chequeos que se necesiten.
 
 ## Pasos automatizados