La configuración quedó en solo lectura: por qué el lugar donde vive es distinto

Intentas editar un archivo y se deniega el permiso. Eres root. Hay espacio en el disco. Aun así no puedes escribir.

Aquí no hay nada roto. El lugar que estás mirando no es una carpeta normal, y rechaza la escritura a propósito.

El lugar donde vive la configuración no es una carpeta

Proxmox guarda las configuraciones de máquinas, las definiciones de almacenamiento, las reglas del cortafuegos y los trabajos de copia en un solo lugar. Parece un sistema de archivos, tiene carpetas y archivos, pero detrás hay una pequeña base de datos, y esa base se replica a cada nodo del clúster.

La razón es simple: todos los servidores de un clúster tienen que ver la misma definición de máquina. Si vas a mover una máquina de un servidor a otro, el otro lado ya debe saber cómo está definida esa máquina. Si la configuración fuera un archivo corriente en el disco de un servidor, los demás no la conocerían.

Este diseño tiene tres consecuencias, y las tres aparecen en el día a día.

Consecuencia uno: sin mayoría, la escritura se rechaza

Si un servidor no ve la mayoría del clúster, la escritura se cierra. La lectura sigue funcionando, la escritura se detiene.

No es una avería, es una decisión. Si la red se partiera en dos y ambas mitades pudieran escribir, la misma máquina acabaría con dos definiciones distintas. Al volver la red nadie podría decir cuál es la correcta, y no habría forma de fusionarlas. En su lugar el sistema elige esto: el lado que queda en minoría deja de escribir.

Cómo se cuenta una mayoría en un clúster, y por qué las instalaciones de dos servidores son incómodas, se trata en otro artículo. Lo único que hay que añadir aquí es que así es exactamente como se siente esa regla de mayoría en la práctica: de pronto no poder escribir.

Consecuencia dos: la misma estructura funciona incluso en un servidor solo

Aunque no tengas clúster, esta estructura está en marcha. Un servidor solo es por sí mismo una mayoría, así que normalmente no pasa nada.

Pero si el servicio que provee esa estructura no está sano, verás el mismo síntoma también en un servidor solo. Así que "no tengo clúster, a mí no me puede pasar" no es correcto.

También hay un camino menos conocido: la base de datos detrás de esta estructura está en el disco local. Cuando el disco local se llena, las escrituras fallan y a ti te parece que no puedes cambiar los ajustes. El síntoma está del lado de la configuración, la causa del lado del almacenamiento.

Consecuencia tres: todo lo que escribas ahí va a todos

No existe la opción de "lo cambio solo en esta máquina". Lo que se escribe ahí llega a cada nodo del clúster.

El error clásico, cometido sin saberlo, es hacer un cambio de prueba en un nodo suponiendo que no afecta a los demás.

Otro punto: ese lugar se diseñó para configuración, no para datos. Los archivos de texto pequeños pertenecen ahí; los scripts, archivos comprimidos y copias no. No cojas la costumbre de dejar archivos ahí.

Si no puedes escribir, comprueba en orden

Comprueba primero la mayoría: ¿el servidor ve al resto del clúster? Si no lo ve, el problema real está en la red y el archivo de configuración es inocente.

Luego comprueba el servicio: ¿está funcionando el servicio que provee esta estructura?

Luego comprueba el disco local: si está lleno, el camino de arriba está en juego.

Y el último, el que más se salta: puede que un nodo haya salido del clúster. Un corte de red, un vecino apagado, una regla de cortafuegos mal configurada. El síntoma siempre parece el mismo, la causa está cada vez en otro sitio.

Qué hace Atlas

Atlas lee esta estructura directamente como archivos, en vez de ejecutar cada vez la herramienta de consulta del sistema.

Medimos por qué. Cada llamada a esa herramienta cuesta entre cien y doscientos milisegundos de procesador y unos cien megabytes de memoria temporal. Con el panel abierto hay un refresco cada diez segundos, y cada refresco necesita de ocho a diez llamadas. Es decir, la vigilancia producía una oscilación constante en el mismo servidor que vigilaba.

Leer la misma información desde un archivo lleva microsegundos. La diferencia es de miles de veces, y esa diferencia se ve en la máquina del usuario como estabilidad.

El segundo detalle es más elegante: dentro de esa estructura hay un contador de cambios que aumenta cada vez que la configuración cambia. Atlas lo vigila. Así, en el momento en que se cambia un ajuste desde el panel, la caché se refresca sola; preguntar poco y no mostrar nunca información caducada se vuelven posibles a la vez.

Es otra cara de un principio escrito en otras partes de esta wiki: lo que observa no debe ser lo que cuesta. El error más fácil de una herramienta de vigilancia es frenar el sistema que observa, y con ello falsear justo el número que mide.