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.
Respuestas:
Como descripción general, para lograr la alta disponibilidad necesita:
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.
fuente
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.
fuente
...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.Sin saber qué base de datos y servidor de aplicaciones utiliza, recomendaría:
Ejemplos de HA:
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.
fuente
¿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.
fuente
Puede mirar una solución de replicación virtualizada / de almacenamiento todo en uno.
El sistema de archivos ZFS lo hace posible, como se describe en esta publicación de blog .
Otra opción sería seguir el tutorial que detalla una solución con Red Hat KVM .
fuente