Configuración para entorno virtualizado de alta disponibilidad


9

Para un proyecto, tengo la tarea de planificar una configuración de alta disponibilidad para una tienda web y un sistema CMS. Sin embargo, por supuesto, el proyecto tiene un presupuesto ajustado. Por lo tanto, una solución de alta gama podría no estar en el presupuesto.

Habrá dos máquinas que ejecutan un servidor web (CMS, tienda), una máquina que ejecuta la base de datos y una máquina para ejecutar un servidor de fax necesario para entregar pedidos a los socios. Todos los sistemas ejecutan Linux. Todos estos componentes deben estar altamente disponibles y deben admitir la conmutación por error transparente.

Para reducir los costos de hardware, pienso en un entorno virtualizado. Hay mucha información por ahí, pero no sé exactamente dónde comenzar. Parece obvio que al menos los servidores son necesarios como host para las máquinas virtuales, por lo que no hay un único punto de falla.

¿Cuál es la mejor manera de apoyar la alta disponibilidad?

La primera pregunta es qué solución de virtualización es la mejor en esta situación. Debe haber algún tipo de interfaz de gestión. Debe haber una forma de mover una máquina virtual en ejecución de un host a otro, de modo que se pueda realizar el mantenimiento del host. Debe haber algún tipo de mecanismo, de modo que las máquinas virtuales sigan disponibles si falla un host. ¿Podría aconsejar sobre una solución válida aquí?

Un almacenamiento de archivos compartidos parece ser un requisito previo de alta disponibilidad en la mayoría de los casos (esperemos que VMware vSphere sea bastante costoso). Sin embargo, preferiría poner más dinero en los hosts de la máquina virtual que agregar otros dos servidores a la configuración para proporcionar un almacén de archivos NFS redundante. ¿Existe la posibilidad de llevarse bien solo con los dos hosts de máquinas virtuales? Una solución podría ser dos, use estos dos como hosts NFS también. ¿Hay mucha penalización de rendimiento para hacer esto?

EDITAR: Mi objetivo es una disponibilidad del 99,9%. Sin embargo, no se requiere disponibilidad las 24 horas del día, los 7 días de la semana, ya que hay horarios de atención regulares, lo que le da espacio para maniobrar. El período de disponibilidad que debe garantizarse de alguna manera es entre las 10 a.m. y la medianoche.


2
¿Qué tan 'alto' es 'alta disponibilidad'? ¿Estás disparando para disponibilidad de 1-nueve o 6-nueve, o en algún punto intermedio? Hasta que tenga requisitos concretos establecidos, es imposible decir si lo que quiere hacer se puede lograr con un presupuesto determinado.
Growse

Sí, tiene usted razón. Apunto a una disponibilidad del 99,9%.
spa

"99.9%" no es solo una frase sobre la que hablamos. Equivale a aproximadamente 8.8 horas de tiempo de inactividad al año . Eso lo saca de la gama de sistemas que se unen con un presupuesto ajustado. Si su presupuesto es limitado, ¿puede permitirse el lujo de soportar ese nivel de disponibilidad?
Rob Moir

1
@RobMoir: diría que si cumple con los criterios que describí en mi respuesta, no hay muchos problemas que no pueda solucionar en esas 8 horas (y el presupuesto aún podría ser pequeño). Si se asegura de que el tiempo de inactividad programado de advertencia avanzada fuera de horario no cuente para su SLA (para software que no sea 24/7).
Mark Henderson

@MarkHenderson Sé que tienes razón, solo digo que el proceso requiere un poco de pensamiento y planificación y no "simplemente sucederá" (debes asegurarte de que puedas obtener piezas de repuesto en el sitio dentro de esas 8 horas, por ejemplo, para que no quiera perder 7 horas de 'ventana' a la oficina de correos, o encuentre que su proveedor favorito eligió ese día para quedarse sin existencias en algún cable trivial que normalmente tendrían en existencia por miles) .
Rob Moir

Respuestas:


13

Como descripción general, para lograr la alta disponibilidad necesita:

  1. Servidores múltiples
  2. Múltiples copias consistentes de los datos.
  3. Datos consistentes a los que se puede acceder entre múltiples servidores
  4. Una forma de iniciar automáticamente una segunda instancia en el servidor en espera

El número 1 es tan simple como parece: compre dos servidores idénticos.

El número 2 se puede lograr mediante una SAN replicada (costosa, muy rápida, muy confiable) o un sistema de archivos replicado en cada uno de los servidores (barato, la velocidad y la confiabilidad pueden depender de su conocimiento de la tecnología elegida).

El número 3 puede lograrse mediante una SAN (un LUN de almacenamiento al que acceden dos servidores) o un sistema de archivos replicado (dos áreas de almacenamiento separadas, cada servidor solo puede ver el suyo).

El número 4 se puede lograr mediante una aplicación de latidos.

Para hacer esto con un presupuesto pequeño, digamos VMWare vSphere, puede usar una SAN o VMWare ahora ofrece un dispositivo de almacenamiento autorreplicante que ofrece dos almacenes de datos distintos en dos servidores que pueden usarse para alta disponibilidad. vSphere también ofrece latidos integrados y configuraciones de alta disponibilidad.

Para hacer esto sin presupuesto, puede seguir la ruta Xen y usar DRBD para replicar el almacenamiento entre los dos nodos. Luego configura los latidos para cambiar el nodo de almacenamiento DRBD activo y la instancia de Xen para iniciar las máquinas virtuales en el segundo host cuando el primero se cae.

No obtendrá 5-nueve (99.999%) de tiempo de actividad utilizando estas recomendaciones básicas, pero podría obtener fácilmente 3-nueve (99.9%) utilizando los métodos más baratos si sabe lo que está haciendo.


9

Se habla de "gasto" en términos de "cuánto dinero costará comprar" cuando se habla de almacenamiento compartido. Es un punto totalmente válido, por supuesto, el dinero es escaso en todas partes .

Pero si habla de alta disponibilidad, entonces también debe preguntarse " ¿por qué queremos alta disponibilidad?" y si la respuesta es, por ejemplo, "porque el negocio entrega $ 2000 por hora en ventas en línea, entonces si estamos fuera por una hora, entonces hemos perdido $ 2000", entonces la cuestión del gasto y la asequibilidad pueden convertirse en "¿Podemos ¿ No puede comprar algo que permita o mejore en gran medida nuestra implementación de alta disponibilidad? "

Este es un detalle importante y se ajusta a su comentario sobre el presupuesto: la 'cola' de TI no debe mover al 'perro' del negocio al insistir en una solución demasiado compleja y costosa para un pequeño problema, pero al mismo tiempo si el negocio tiene ciertos requisitos de su infraestructura de TI, entonces debe estar preparado para presupuestarlos adecuadamente o para ajustar sus requisitos.

Creo que la virtualización tiene mucho potencial para mejorar la disponibilidad de los sistemas, pero no es una varita mágica. El lado del hardware de las cosas, aunque importante, es muy secundario a los requisitos del software: no es bueno tener un clúster de base de datos SQL que se caiga sin problemas en caso de que uno de los servidores SQL falle si la aplicación front-end que habla a las estrangulaciones de la base de datos porque no puede manejar la conmutación por error.

Y dos servidores "altamente disponibles" uno al lado del otro en un centro de datos aún son vulnerables a fallas de energía, robo, etc. Una vez más, dependiendo de la respuesta a " ¿por qué estamos haciendo esto?" con cuidado, ya que puede agregar gastos y complejidad a bastantes partes de su proyecto.


3
...no good having a SQL database cluster that falls over with no trouble in the event of one of the SQL servers crashing if the front-end application that talks to the database chokes because it can't handle the failover.- No podría enfatizar esto lo suficiente. Tuvimos un cliente que nos hizo implementar un clúster HA SQL Server en una SAN grande y, al final del día, su software tuvo que reiniciarse en el caso de una conmutación por error porque no podía manejar una interrupción en las comunicaciones. Fue un ejercicio costoso que fue inútil cuando un SQL Mirror y NLB habrían bastado.
Mark Henderson

Parece que ambos tenemos cicatrices similares de proyectos antiguos
Rob Moir

@ MarkHenderson, ¿por qué se interrumpió la comunicación (por cierto, SAN o red)?
Nils

5

Sin saber qué base de datos y servidor de aplicaciones utiliza, recomendaría:

  • Use XEN> 3.2 en modo PV para las máquinas virtuales (solo mi favorito personal): los compartimentos u otras soluciones de virutalización lightwight también pueden encajar (OpenVZ para nombrar uno).
  • Cree cuatro máquinas virtuales en cada nodo físico
  • Utilice un RAID 5 local con discos SAS de 3,5 ", tantos discos como sea posible localmente (5 es bueno)
  • Use discos de 15k RPM (sus bases de datos lo necesitarán)
  • Use DRBD y OCFS2 para proporcionar almacenamiento "compartido" barato, use una red local rápida, segura y confiable para esta conexión (la unión de interconexiones directas es bastante rápida y buena).
  • Hacer el HA a nivel de aplicación
  • Utilice el equilibrio de carga entre los pares de máquinas, para obtener 8 máquinas que realicen tareas concurrentes

Ejemplos de HA:

  • Servidor de aplicaciones: utilice Tomcat en modo activo / activo en clúster
  • LVS: utilice la replicación concurrente esclava y maestra de lvs
  • Oracle-DB: use RAC (no sé si hay una solución equivalente para OpenSource DBs)

Si hace HA en la capa de aplicación, esa capa sabe mejor cómo replicar sesiones. Si un nodo se cae (planificado o no), el nodo sobreviviente se hará cargo, incluidas las sesiones.


"Oracle-DB: Use RAC" - Standard Edition no tiene licencia ni es compatible con OCFS2. Aparte de eso, una respuesta muy informativa.
kubanczyk

@kubanczyk Oracle-RAC es más que ocfs2. Pero ocfs2 es gratis. Para que pueda usarlo cuando lo desee.
Nils

2

¿Por qué quieres comprar tus propios anfitriones? ¿Por qué no encuentra un proveedor de Enterprise Cloud / IaaS como BlueLock o Terremark que le proporcionará la infraestructura que necesita? Proporcionarán servicios como vSphere HA (más como tiempo de inactividad reducido que el servicio HA pero es una solución rentable), Firewall, Descargador LTM / SSL, SAN (con estantes redundantes), Monitoreo / Alerta, etc. Tenga en cuenta que no estamos hablando de soluciones de nube de consumo aquí, así que prepárate para pagar por el valor.


Sí, tiene usted razón. Sin embargo, la configuración incluye hardware personalizado para la entrega de fax. Entonces, una solución en la nube no funcionará tristemente.
spa

@spa, aún puede aprovisionar el hardware personalizado en su entorno físico, el resto en virtual y conectar las VLAN.
HTTP500

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.