Ajustes de memoria ZFS en Proxmox VE 6

Recientemente hemos migrado un  sistema de producción a una nueva instalación en ZFS con la versión 6 de PVE, lo cual ha sido en general un gran éxito, pero hemos  tenido que hacer una rápida investigación sobre la puesta a punto de la memoria para evitar el infame asesino OOM (Out Of Memory), y eso es lo que vamos  a compartir con ustedes hoy. Lo ideal sería añadir suficiente RAM para cubrir todas las  asignaciones de VM, además de un 50% a un 55% para ZFS y Proxmox, pero no podemos  justificar ese gasto ahora mismo.

Si puedes permitírtelo, simplemente consigue más RAM; si no puedes o no quieres hacerlo, los siguientes consejos te ayudarán a gestionar la memoria que tienes disponible.

Se habla mucho de que ZFS requiere memoria RAM de corrección de errores (ECC), esto simplemente no es cierto, ZFS no requiere memoria RAM ECC más que otros sistemas de archivos. Dicho esto, siempre es mejor usar la RAM ECC independientemente del sistema de archivos que se use, pero no te asustes si no tienes ECC, yo tampoco lo tengo.

¿Qué es el asesino de OOM
El Asesino OOM es un proceso de Linux que evita que el sistema se quede sin memoria matando un proceso (probablemente uno de sus VMs) para liberar algo de espacio en la RAM.

¿Por qué no añadir espacio de intercambio
Generalmente, el OOM Killer puede mantenerse a raya agregando espacio de intercambio, pero el intercambio en ZFS es inestable en el momento de escribir este artículo y es bien sabido que causa el bloqueo completo del sistema en escenarios de alta presión de memoria. Esto deja sólo unas pocas opciones para utilizar el intercambio; se podría añadir espacio de intercambio en otro disco sin RAID, lo cual no es deseable ya que debido a la falta de redundancia, perder esa unidad podría potencialmente bloquear todo el sistema, o configurar una matriz MD RAID en dos discos más para el espacio de intercambio.

Todos los puertos SATA están en uso en mi sistema, por lo que tampoco es una opción, probablemente debería haber reducido el tamaño del volumen ZFS raíz durante la instalación para hacer espacio para un par de particiones MD RAID para usar como espacio de intercambio en los mismos discos que la instalación, pero en retrospectiva es 20/20, ¿verdad? Así que en mi caso, sólo voy a ejecutar un sistema sin swap, lo que significa que el ajuste de la memoria que probablemente debería hacerse incluso con swap es aún más importante.

1) Asignación de la memoria RAM de la VM
Lo más simple y más importante que debes hacer es no sobrecomprometer tu RAM. Claro, con el KSM y el globo de memoria puedes sobrecomprometer la RAM, pero tu sistema será mucho más estable si no lo haces.

El mejor enfoque es dejar suficiente RAM para el ZFS ARC (Adaptive Replacement Cache) sin asignar, además de al menos 1 GiB o más para el host Proxmox, me meteré en el ARC más abajo. El tamaño máximo del ARC por defecto es el 50% del total de la RAM instalada en el sistema.

Tengo 62.83 GiB de RAM total según la GUI de Proxmox Web, lo que me deja aproximadamente 30 GiB de RAM máxima disponible para usar con seguridad para la asignación de VM, pero pude aumentarlo a casi 54 GiB de RAM afinando el ARC.

2) Sintonización de KSM
KSM (Kernel Same-page Merging) es una gran herramienta para obtener un poco más de tu preciosa RAM, está habilitada por defecto en Proxmox, pero la configuración por defecto no es ideal para su uso en un sistema ZFS donde el uso de la RAM puede dispararse la primera vez que se realiza una operación de disco pesado (por ejemplo, una copia de seguridad o un clon de un zpool a otro).

KSM funciona reduciendo las páginas de memoria duplicadas a una sola página, de modo que cuando varias máquinas virtuales tienen el mismo recurso almacenado en la memoria sólo se almacena una vez en la RAM y se comparte entre ellas en lugar de desperdiciar el espacio de la RAM con múltiples copias del mismo recurso. Esto funciona mejor cuando se ejecuta el mismo sistema operativo en la mayoría de las máquinas virtuales.

KSM Tuning no aumentará la cantidad de RAM que puede asignar con seguridad a sus VM, pero le dará un búfer extra para los períodos de alta utilización de la RAM, y eso me hace sentir un poco mejor acerca de la asignación de toda la RAM que pueda con seguridad a las VM, lo cual debería hacer, porque ¿por qué tener toda esa RAM tan costosa si no la está utilizando?

Nota: La compensación por usar KSM es un aumento de la superficie de ataque para las hazañas de canal lateral. Depende de ti decidir el beneficio vs. el riesgo de KSM, si decides no usar KSM debes deshabilitarlo ejecutando el comando systemctl disable ksmtuned de una sesión de shell en tu host Proxmox.

Sólo cambié un parámetro aquí, KSM_THRES_COEF, que determina el umbral de RAM disponible que hará que KSM empiece a hacer lo suyo. Hay más opciones de sintonización disponibles y si desea realmente sumergirse en ellas, hay una gran información sobre estas opciones en la documentación en línea de Red Hat. Quiero activar KSM un poco antes, pero no demasiado pronto, ya que KSM utiliza los ciclos de la CPU, y eso es un desperdicio si tienes mucha RAM disponible.

El valor por defecto para KSM_THRES_COEF es 20, lo que significa que KSM se disparará si menos del 20% del total de la RAM del sistema está libre, una fórmula para este cálculo es:

Umbral * RAM total / 100

Tengo 62.83 GiB de RAM total según la GUI de la web de Proxmox, así que en mi sistema el valor por defecto es:

20 * 62.83 GiB / 100 = 12.566 GiB

Lo que significa que KSM comenzará a trabajar sólo cuando mi uso de la RAM alcance los 50.264 GiB (62.83 GiB de RAM total – 12.566 GiB libres

Conocemos a expertos en estos temas los cuales puedes contactar 

Esta entrada fue publicada en Virtualizacion y etiquetada , , , , . Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *