Buenas!! el tema es que ya me estaba volviendo loco y al final descubrí lo que creo que descubrí, y es que me da la sensación que los usuarios de OpenVZ han estado tragando con los cuellos de botella durante los procesos de «backup» y hasta que alguien no le dio por notificarlo, pues no ha sido resuelto. SÍ, después de ese parche cuando haces un backup o comprimes o haces un uso elevado de disco, el %IO del procesador se pone al 30-40% como mucho, y no el 80-90% al que nos tenía acostumbrado. SÍ, funciona en CentOS, pero el tema es que hasta que esto se vea reflejado en el kernel de Proxmox puede pasar un tiempo. Aquí explicado en inglés… El tiempo dirá…
Mientras tanto, cambio el servidor y me cojo un servidor hybrido con dos discos SSD, rápidos como un rallo pero pequeños de 80GB cada uno (es lo que hay hoy en día) y otros SATA2 normales de 750GB para almacenamiento que con la ayuda de NFS simulo un sistema de «storage» en OpenVZ, que me permite tener una partición extra dentro de una máquina virtual.
Empezamos el proceso… nos entregan el servidor y sin miramientos, me cargo todas las historias de RAID (manual de RAID) y me cargo los discos sdb (el segundo SSD) y sdc y sdd. En este caso lo hice desde el asistente de este instalador que no había probado todavía… luego reinstalé el servidor con Proxmox marcando «formatear solo el primer disco».
Ya con el sistema instalado solo en 1 disco, me dispuse a definir las particiones que usaré en el tiempo de vida del servidor, todas ellas en LVM, manual de particionado LVM:
- Moví la partición /var/lib/vz al 2º disco SSD (sdb), para así conseguir el máximo tamaño de partición para las máquinas OpenVZ, ya que es ahí donde se guardan.
- Cree una partición en el el 1er disco SSD con lo que me queda disponible de los 10GB que he dado a la / + swap, esta partición queda montada como /dev-qemu, y es así como decido aprovechar el resto de mis valiosos GB SSD. Para las máquinas KVM!! creando el correspondiente storage en Proxmox para ello… Otra delicia…
- Ya con los discos SATA, a lo bruto… todo particionado en todo el disco, ya veremos en el futuro… con lvresize muy fácil editar el tamaño.
Luego todo el rollo de crear una máquina OpenVZ, que recordemos se almacenará en el 2º disco SSD, instalar cPanel en CentOS y… EMPIEZA LA HISTORIA DEL NFS (en caso de no querer usar mount –bind, que es más fácil en caso de solo disponer de un solo servidor, pero con varios discos, como es el caso… pero es que este post va de NFS :P).
En el servidor Proxmox, instalamos NFS
# apt-get install nfs-common
# aptitude -t lenny-backports install nfs-kernel-server
Editamos este ficherito para dar permiso a la máquina virtual a usar el disco SATA (/dev/sata2 en mi caso)
# nano /etc/exports
Y añadimos:
/dev-sata2/cpanel-backup IP.DE.LA.MAQUINA-VIRTUAL(rw,sync,no_subtree_check,no_root_squash)
Luego, con la máquina virtual parada, le añadimos las funciones del kernel NFS
# vzctl set 101 –features «nfs:on» –save
Encendemos y nos vamos a la máquina virtual cPanel… Instalamos NFS con:
# yum install nfs-utils nfs-utils-lib nfs-utils-lib-devel nfs4-acl-tools libevent libgssapi
o simplemente # yum install nfs*
conectamos con la unidad NFS previamente creada con este comando y siendo /backup/remote el directorio que queremos que sea nuestro storage dentro de la vm.
# mount -t nfs IP.DE.PROX.MOX:/dev-sata2/cpanel-backup /backup/remote -o nolock,udp
Y… tachaaan, tengo una máquina virtual OpenVZ con 40GB SSD ultrarápidos [hasta 72GB podría ampliar, que es el resultado de crear el lv en el disco de 80GB (se pierden 8GB)] y 700GB en SATA para llenarlo de lo que quiera…
root@shared [~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 40G 4.7G 32G 13% /
none 2.0G 4.0K 2.0G 1% /dev
IP.DE.PROX.MOX:/dev-sata2/cpanel-backup
680G 81G 565G 13% /backup/remote
Nota: Igual me he dejado algún comando olvidado, lo cierto es que a mi no me funcionó a la primera, si ves que no va, haz un reboot 🙂
Esto funciona? el tiempo dirá, pero me he permitido el lujo de poner a la vez a hacer un vzdump desde Proxmox de todas las máquins virtuales (kvm + openvz) y al mismo tiempo, un backup dentro del propio cpanel (máquina virtual), y lo que en un servidor normal (solo con discos SATA) es muerte segura con un 90% de IO delay, en este servidor y gracias a que las webs + bases de datos + correos están en discos SSD, las webs son más que funcionales y operativas, el procesador se pone con un IO delay del 30-60% y como digo funcional, resolviendo 100 consultas sql de distintos tamaños en torno a 0.050 y 0.400 segundos.
La realidad es que, en un servidor que no esté sobrecargado, el cliente final, ni se entera de que estás haciendo un backup…
Pregunta- Y si se rompe el disco SSD donde tienes las webs??
Respuesta- Restauraré el último vzdump que tengo… me permito el lujo de tener el servidor en constante proceso de backup, varios al día y que ninguno machaca a uno del mismo día, solo los del día anterior. Calculo que como mucho, perderé las modificaciones de las últimas 6 horas…
Pregunta- Y si se rompe el disco SSD donde tienes Proxmox instalado?
Simplemente vuelvo a reinstalar el servidor marcando la opción «formatear solo el primer disco» solo tengo que regenerar en fstab las particiones, la información sigue estando el los otros discos.
Pregunta- Y si se rompen los dos discos SSD?
No hay problema, tengo todos mis backups bien repartidos por los discos SATA, tanto los dump de Proxmox como los backups de cPanel!!
Pregunta- Y si se rompen todos los discos?
mmm, pero esto ya con cualquier servidor, o has replicado la información en otro sitio o te jodes!! Compraré un disco USB de 500GB por si acaso… 😛
Hay posibilidad de fallo? de perder información… pues si, vemos que hay punto donde nos quedamos con el culo al aire. ¿Pero acaso no te quedas con el culo al aire si se te rompe un disco en RAID con una partición LVM dentro? que te coja confesado Dios el día que esto te pase, seguramente en ese momento estarás rezando por tener un buen backup o snap para poder reinstalar y restaurar sin comerte mucho la cabeza o en el menor tiempo posible…
En mi caso, calculo que tras una rotura que me obligue a intervenir, tardo 1 hora y poco en dejar operativo el servidor (incluyendo ya los 30 minutitos del Manager) + otro tanto que pueda tardar en restaurar los snaps, cosa que en SSD va bastante rapidito, aunque el origen sea SATA, hablamos de que este solo lee… Vamos que en 3-4 horas lo tengo listo…
El siguiente nivel sería coger un HG con 36 discos SSD (bueno tampoco son necesarios tantos :)) y entonces ya podemos montar algo que no se caiga nunca, o un rsync con otro server o DRBD o Heartbeat o historias varias también compatibles con este sistema… Hablamos de construir esto y tener un rendimiento óptimo para no estar esperando a que termine el backup para poder usar el servidor con la ventaja de que me olvido de monitorizar el estado del RAID con mdadm, por que no tengo!! xDD
Un saludo!!!
1 Comment