El entorno LAMP multiservidor ideal

Question

Hay mucha información sobre cómo configurar las pilas LAMP en una sola caja, o tal vez mover MySQL a su propia caja, pero ir más allá no parece estar muy bien documentado.

Mi entorno web actual está teniendo problemas de capacidad, y por lo que estoy buscando las mejores prácticas con respectoajuste de la configuración, determinar los cuellos de botella , seguridad, etc.

Me alojo en la actualidad en torno 400 sitios, con una necesidad justa de redundancia y seguridad, y así he crecido más allá de la solución de caja única, pero no estoy al nivel de un ISP completo o una empresa dedicada de alojamiento web.

¿Alguien me puede indicar una buena experiencia en en la configuración de una gran granja web apache con vistas a la seguridad y la futura expansión?

Mi entorno web consta de 2 servidores MySQL redundantes, 2 servidores de contenido web redundantes, 2 servidores apache de equilibrio de carga que montan el contenido a través de nfs y comparten directorios de configuración y sesiones Apache entre ellos, y un único "desarrollador "servidor que también monta el contenido web a través de nfs, y contiene todas las cuentas de desarrollador.

Estoy bastante contento con una gran cantidad de esta configuración, pero parece estar asfixiando a la carga prematuramente.

Gracias!

--UPDATE--

Resulta que la "asfixia de la carga" se relaciona con mod_log_sql, que utilizo para enviar mis registros de Apache a una base de datos MySQL. Al reconfigurar los servidores web para escribir sus sentencias SQL en un archivo de disco, y luego crear un proceso separado para enviarlos a la base de datos, permite a los servidores web liberar sus hilos mucho más rápido y manejar una carga mucho mayor.

Answer 1

La forma de hacerlo en el libro de texto sería identificar los cuellos de botella con datos empíricos reales.

¿Es el database, apache, red, cpu, memoria, io? ¿Necesita más memoria RAM, sharding (+), es el DiskIO, la carga de red NFS, la CPU para realizar escaneos de tabla completa?

Cuando descubra dónde está el problema, puede encontrarse con el problema de que no es suficiente para escalar la infraestructura, debido a la forma en que funciona el código, y termina con la necesidad de simplemente crear más instancias de usted configuración actual o hacer el código diferente.

Answer 2

Debe ser capaz de identificar los cuellos de botella y las mejoras de prueba.

Para identificar los cuellos de botella, debe utilizar las herramientas de generación de informes de su sistema. Algunos ejemplos:

• MySQL tiene un registro lento de consultas.
• Linux proporciona estadísticas como promedio de carga, iostat, vmstat, netstat, etc.
• Apache tiene el registro de acceso y la página de estado del servidor.
• Los lenguajes de programación tienen perfiladores, como Pear Benchmark.

Utilice estas herramientas para identificar a los delincuentes más lentos/más grandes y concéntrese en ellos. Pruebe una mejora y mida para ver si realmente mejora el rendimiento.

Esto se convierte en un ciclo interminable por dos razones: siempre hay algo en un sistema complejo que puede ser más rápido y, a medida que su sistema crece, las diferentes funciones comenzarán a desacelerarse.

De acuerdo con la descripción de su sistema, mi primera corazonada sería disk io y network io en los servidores NFS, luego miraría los tiempos de consulta de MySQL. También verificaría el rendimiento de las sesiones compartidas.

Answer 3

También recomendaría como primer paso en términos de escalabilidad, descargar su contenido a un CDN como Edgecast. Use sus dos servidores de contenido actuales como servidores web adicionales.