Empecé a buscar la creación de un servidor virtual con carga equilibrada, para ejecutar principalmente servicios web, servicios de gestión de proyectos (control de versiones, etc.) y aplicaciones de ese tipo. Y necesito una solución de código abierto (Linux).
Wikipedia tieneesta entrada, hay proyectos estables aparentemente muy prometedores, pero la mayoría están muertos hace mucho tiempo.LVSyKerrighedParece posible, pero no estoy seguro. ¿Vale la pena invertir (en el tiempo)?
¿Cuál sería una buena solución? (aunque no puedo permitirme una solución comercial (Linux o otra), me gustaría conocer estas alternativas y agradecería comentarios al respecto).
Gracias
Respuesta1
Parece que estás intentando resolver el problema en la capa equivocada. No conozco ninguna administración de sistemas sensata que intente utilizar una imagen de sistema única para ejecutar un servidor web cuando existen otros métodos comoproxies inversosque son mucho más sencillos y, por tanto, más fiables.
Como:
Respuesta2
A menos que realmente esté leyendo mal la pregunta, diría que para alojar aplicaciones web, lo está haciendo de manera incorrecta.
Sugeriría tener varios nodos (virtuales o físicos) y administrar su configuración conmarioneta.
Sus nodos podrían ser un bastidor completo de servidores de 1U o un grupo de potentes servidores multiprocesador de 3U ejecutandoKVMy luego un sistema operativo de su elección como invitado de virtualización.
Dados 4 servidores, puedes configurarlos de la siguiente manera:
- Servidor 1: equilibrador de carga + nodo HTTP (ejecutando Varnish y Apache)
- Servidor 2: equilibrador de carga + nodo HTTP (ejecutando Varnish y Apache)
- Servidor 3: Nodo HTTP + DB Master (ejecutando Apache y MySQL)
- Servidor 4: Nodo HTTP + DB Slave (ejecutando Apache y MySQL)
Sería ventajoso tener un quinto servidor que ejecute servicios como nagios, munin, tftpd para un entorno de arranque PXE, un pequeño servidor HTTP para archivos kickstart/preseed, DHCPd, tal vez consolas seriales a través de Rocketport o similar.
La gran ventaja de utilizar Puppet para implementar sus propios sistemas, en lugar de tener una sola imagen, es que los recursos se autodocumentan de manera efectiva. Es mucho más claro y menos recuadro negro que simplemente tener una imagen que se coloca en los servidores. Además, simplifica mucho las actualizaciones y cambios en la imagen.
Respuesta3
No estoy seguro de estar respondiendo lo que realmente estás preguntando, pero si estás buscando una manera de tomar una máquina virtual y reflejarla, puedes usar cualquiera de las herramientas de virtualización gratuitas que conozco (VMware Server , ESXi, kvm, etc.)
- crea tu VM con todo lo que necesitas
- copiar la máquina virtual
- realizar cambios en la copia (dirección IP y nombre de host)
- iniciar ambas máquinas virtuales
- inserte el equilibrador de carga (hardware o software, no importa)
- .. no se me ocurre ningún sexto paso :)
Respuesta4
Por más emocionante que parezca el SSI, es muy poco probable que funcione de manera óptima.
Dado que su objetivo principal son las aplicaciones web, puede (¡debería!) utilizar las mejores prácticas actuales. Normalmente, estos comienzan por:
- un balanceador de carga de almacenamiento en caché como interfaz (squid, barniz, nginx)
- varios servidores HTTP para aplicaciones web (normalmente apache, puede ser nginx+FastCGI, lo que sea)
- base de datos
Si está bien hecho, su primer cuello de botella sería la base de datos; en este punto, debería:
- agregue caché a sus aplicaciones web para reducir los accesos a la base de datos al mínimo. (marcos modernos (RoR, Django), incluyen un gran soporte para Memcached)
- llevar algún tipo de trabajos de la base de datos a aplicaciones más especializadas. Los primeros candidatos son colas de tareas (para RabbitMQ o similar) y almacenes de clave/valor (para Tokyo Cabinet, Resis, MongoDB, muchos de ellos).
- distribuir la base de datos. si son muchas lecturas/pocas escrituras, intente la replicación maestro/esclavo (fácil en MySQL), pero si este es su caso, memcached ya debería haber absorbido la mayor parte de la carga. Prueba también a fragmentar.
Si alguna vez llegas a crecer demasiado (¿eres FaceBook?), tendrás que repensar toda tu estructura, al estilo de Google (donde hacen casi todo "fuera de línea" con MapReduce).