1. ¡OFERTA! con cupón "DIRVPS": hosting por $0,01 y también VPS Linux y Windows por $0,01 el primer mes por Interserver ← publi
    Descartar aviso
Descartar aviso
Al usar este sitio web, aceptas que nosotros y nuestros socios podamos establecer cookies para fines tales como personalizar el contenido y la publicidad. Más información.

Configuración óptima de dedicado: discos extendidos o espejo

Tema en 'Servidores Dedicados' iniciado por chencho, 31 Oct 2017.

  1. chencho

    chencho Usuario activo

    Hola a todos.

    Tenemos la infraestructura en ovh, pero tenemos que empezar a realizar cambios.

    Los servidores que usamos normalmente son de 64 GB de RAM y 2x480GB SSD + 2x2TB SATA

    Por regla general tenemos los discos en ZFS en modo espejo (usamos proxmox) con las máquinas en los SSD y los backups diarios, semanales y mensuales en el SATA

    Tenemos dos servidores en producción que pasan las copias a un tercero, con el disco extendido para tener más almacenamiento.

    El caso es que empiezo a dudar sobre si deberíamos tener los servidores en modo extendido SSD+SSD y SATA+SATA ya que el handicap que tenemos es el espacio para las máquinas virtuales.

    Teniendo las copias en el tercer servidor... ¿es una locura poner los discos en modo extendido en producción?

    Siempre podemos poner un cuarto servidor y balancear, tampoco es cuestión de ir al céntimo, pero iríamos sumando costes.

    ¿Alguna opinión al respecto?
     
  2.  
  3. egrueda

    egrueda Usuario activo

    Si te refieres a un stripe (RAID 0), si, es una locura, a menos que tengas un espejo debajo (RAID10)
    No se trata de tener un backup para cuando algo falle, se trata de mntener el servidor levantado aunque falle un disco.
    Con un RAID espejo, tienes tolerancia a fallos de disco. Sin espejo, la máquina deja de funcionar, y además a la hora que ella quiera :-D
     
    A AMateos, copernico.es y ideasmultiples les gusta esto.
  4. marin

    marin Usuario activo

    Yo utilizaría discos 100% SSD, y si pueden ser NVMe mejor (OVH ofrece este tipo de discos), olvídate de otras tecnologias obsoletas. Está claro que estos discos son más caros y tienen menos espacio pero si quieres ofrecer calidad tendrás que reducir el número de VPS que tienes en cada servidor y no sobrevender recursos (que creo que es el problema que estás teniendo ahora mismo que estás vendiendo más espacio por VPS del que de verdad tienes disponible).

    Para las copias de seguridad yo recomiendo el Storage Box de Hetzner, mírate sus precios.
     
  5. jmginer

    jmginer Usuario activo

    Aclarar que el servidor de OVH que comenta el compañero no tiene controladora RAID, habría que usar mdadm en el caso de Linux para montar un RAID por software y en caso de una de las nuevas BIOS UEFI, es necesario una partición de tipo efi, las cuales NO pueden estar en RAID, con lo que si el disco que tiene la partición efi se rompe, aunque los datos del RAID no se han perdido, el servidor no iba a poder arrancar.

    Entiendo que sería posible montar a mano una segunda partición efi en el segundo disco, clonando la del primero, pero habría que hacerlo previo a una rotura de disco, aunque aún no he llegado a probarlo de verdad.

    Si alguien ha probado algo al respecto, podría dejar sus impresiones.

    Nosotros por el momento lo que estamos haciendo el montar la partición efi en una SATA DOM a parte, solo con la partición efi y así reducimos al mínimo el uso de este disco reduciendo al mínimo las opciones de un posible crash que nos pudiese dejar sin arranque el equipo.
     
  6. chencho

    chencho Usuario activo

    Hola Giner (pues no hace tiempo, desde los foros de ovh!)

    Con el ZFS el problema del boot sería similar al del RADI-1? No he visto nada al respecto.

    Ya no es tanto sobrevender, el problema viene con las copias y levantarlas en caso de desastre.

    Por regla general las bases de datos las copiamos dos veces al día y las mandamos al tercer servidor, y las copias una vez por la noche. En caso de que el servidor se pare y no se pueda arrancar, casi es más rápido levantar las maquinas, mover ip y restaurar la bd que esperar a que cambien un disco y tratar de restaurar el servidor (a mi modo de ver). Lo más problemático serían los ficheros que se puedan haber subido al sistema, pero si se levantara podríamos hacer un rsync posterior (por ejemplo)

    De ahi que el Storage de hetzner (que está muy bien por cierto, y creo que lo usaré para tener el histórico) no sea de lo más funcional, porque quiero tener un servidor donde poder levantar las máquinas en caso de caída.

    Posiblemente es mejor escenario en mi caso sería el siguiente:

    Server A / B: máquinas en producción en SSD y copias en HD. Se mueven las copias al Server C
    Server C: copias de las máquinas, posiblemente sólo la última (en caso de contar con el Storage de hetzner)
    Storage: Copias diarias (3 días), semanales y mensuales de todas las máquinas

    Con esto creo que la infraestructura sería sostenible, porque la posibilidad de que el Server A y B peten a la vez es remota. Aún así, el Server A y B pueden estar en RAID-1 y el C en RAID-0 (temporal, se montan las máquinas en caso de desastre y se mueven de nuevo al servidor en producción cuando se restauren). Incluso se podría añadir uno más a producción con este sistema sin mucho problema.

    Las máquinas más pesadas en cuanto a datos son las relacionadas con owncloud (100 GB cada una); estas las podríamos poner en los HD en lugar de los SSD, porque tampoco se benefician de la velocidad de estos. Así podríamos aliviar también a los SSD en la medida de lo posible.

    Así que en resumidas cuentas:

    Producción: SSD+SSD (Mirror) / HD+HD (Mirror)
    SalvaDesastres: SSD+SSD (Extendido) / HD+HD (Extendido) (haremos el calculo para ver si en mirror cabe toda la info)

    ¿Alguna queja al sistema propuesto?
     
    A 4pr3nd1zfhrer le gusta esto.
  7. Datacenter1

    Datacenter1 Usuario activo

    Con ZFS puedes hacer algo como los SSD para SO y SIL y los HD con comprensión para data de las VPS, dependiendo del uso I/O puede dar un buen rendimiento e incluso puedes colocar los hdd en raid0
    Para el backup el mismo arreglo y usas pve-zsync para syncronizar la data entre nodos a un tiempo razonable, el ssd lo hago cada 5 minutos pero con hdd no se como sería el i/o con la sincronización

    En tu caso particular no veo mucho problema con RAID 0 ya sea mdadm o zfs si estás duplicando todo a un segundo servidor, lo que debes tratar es que esa syncronización sea frecuente y en eso pve-zsync es excelente

    Con dos servidores syncronizados en RAID 0 obtienes la misma protección que con un servidor en RAID10 (protección contra fallos de 1.5 discos)
    En caso de desastre usas el backup como modo temporal mientras rehaces el nodo que ha fallas, vuelves a syncronizar con zsync y los restauras a su ubicación original, con este setup no tendrás que hacer copias de myql dos veces al día
     
  8. chencho

    chencho Usuario activo

    Gracias "Datacenter1"; la verdad es que hace tiempo que no tengo que tocar prácticamente nada de sysadmin y por circunstancias debo ponerme al día de nuevo.

    No conocía la utilidad de pve-zsync y me parece estupenda, mucho mejor que hacer un backup nocturno y cruzar máquinas.

    Esta es la idea, tener dos ( o x ) servidores en producción y uno en backup . Lo ideal es que se "autocreara" la máquina en el de backup y sólo se tuviera que mover la ip y como mucho cambiar el Gateway en proxmox, pero bueno, veremos hasta donde llegamos.

    De momento estoy probando a poner las maquinas en el SSD y en el HD (dentro de la misma máquina), según su tipo y responden bien. Con el pve-zsync podría prescindir incluso de los backups locales por lo que la máquina sería 480 SSD + 2 TB HD (en espejo) todo para máquinas (y sistema, obviamente).

    He visto configuraciones en OVH con los discos NVMe, que no están nada mal de precio (450 + 4 TB en espejo) pero no creo que aún merezca la pena el sobre coste (+31€/maquina) dado que el rendimiento de las máquinas actuales es muy bueno.
     
  9. Datacenter1

    Datacenter1 Usuario activo

    Proxmox tiene la función de replicar nodos espejo y todo funciona automáticamente, es para solo un nodo o pares de nodos pero probablemente funcione con dos nodos haciendo mirror a un nodo de backup, pero es algo que no he probado
     
  10. chencho

    chencho Usuario activo

    Hola de nuevo.

    Refloto un poco el tema para explicar como está al final el asunto.

    De momento tengo 3 servidores en producción, después de jugar con algunos más.

    El A y el B están en producción; con ZFS tiene uno un "RAID-0" (960GB) en los SSD y otro (4 TB) en los HDD; el B realmente tiene un RAID-1 en los SSD, pero simplemente por no volver a configurarlo todo (el espacio de momento no es un problema).

    En los SSD tengo los hosting, vps de webs y vps de aplicaciones

    En los HDD tengo los "owncloud" y las herramientas (gitlab, sentry, etc)

    Ambos hacen copias de los SSD cada 15 minutos (1 día de histórico) al C por pve-zync (una maravilla!) y una vez al día de los HDD (7 días de histórico)

    El A y B adicionalmente hacen copias locales, de 3 días de retención, más una semanal.

    Ya he probado a levantar las máquinas en el C y va muy bien, la verdad es que no conocía el pve-zsync y es una pasada de herramienta.

    Con esta configuración, no hay problema de momento de máquinas (64 GB de Ram en cada una) y si crece, pues se contratarán más máquinas, como toca.
     
    A sysdop, jmginer y AMateos les gusta esto.
  11. hostigal

    hostigal Usuario activo

    No has visto la opción de "Proxmox VE HA Cluster". No somos conocedores de promox a fondo, es tarea pendiente ponernos al día, pero tengo entendido que a partir de la versión 5, dependiendo como tengas configurado el almanenamiento local, tienes la opción incluso de "live migration with local storage"

    saludos
     
  12. chencho

    chencho Usuario activo

    Si, vimos el HA, pero no me convence el tema del cluster, he visto bastantes problemas al respecto.
    Además que no usamos el puerto de ssh por defecto y hace cosas raras el Proxmox en cluster de esta forma; de hecho teníamos dos en cluster y tuvimos que romperlo y volver a local.
    Y por último, no se puede añadir al cluster un servidor con máquinas virtuales, por lo que deberíamos volver a configurarlo todo.
    Pero el pve-zsync es una maravilla, la verdad; aunque es cierto que la copia inicial es un poco pesada (de las máquinas de owncloud al menos, el resto fue relativamente rápido) y tuvimos que darle más procesos al cron.d porque se comía las tareas disponibles en uno de los servidores.
     


Alojamiento web, Hosting Reseller, Servidores Dedicados - All in Hosting


    
    
    
    
Blog · Sitios amigos: GuiaHosting · Unidominios · Interalta ·