Tengo un sitio web que tiene un promedio de 50 millones de visitas por día, y en los próximos 3 meses debería haber más de 100 millones de visitas por día. Estamos intentando utilizar GlusterFS v 3.0.0 (con los últimos parches a partir del 17/01/2010)
Actualmente, acabamos de actualizar a un entorno de equilibrador de carga que tiene 3 hosts físicos con 6 máquinas virtuales Xen-Server 5.5u1 (2 en cada host) para atender el tráfico de la página web. Cada máquina tiene 6 unidades de almacenamiento local Raid-6 (7200RPM-SATA). La vieja máquina de la que venimos tenía 1 unidad SAS 10k reflejada.
También configuramos GlusterFS actualmente con 3 bloques, uno en cada host, y sirve a las 6 máquinas virtuales como clientes. En las pruebas todo parecía estar bien. Sin embargo, cuando pasamos a producción, parecía que simplemente no había suficientes E/S disponibles para atender el tráfico, incluso de más de 15 millones de visitas. Semanas antes, nuestro antiguo servidor podía manejar el tráfico, al máximo, 20 millones.
¿Existe alguna configuración recomendada para dicha aplicación, o cosas a tener en cuenta que no son evidentes en su documentación en gluster.org para un sitio de nuestro tamaño?
Respuesta1
RAID-6 de unidades de 6x7,2 krpm sin caché de escritura (?) tendráhorriblerendimiento de escritura, tan terrible que probablemente atascará los discos lo suficiente como para afectar también el rendimiento de lectura si su aplicación tiene una combinación saludable. Quiero decir, de manera realista, estás viendo como 250 iops aleatorios en una división de lectura/escritura 80/20 de esa matriz. Si está realizando varios cientos de solicitudes http por segundo, entonces algo tan trivial como el registro de acceso de Apache lo atascará como un ataque DoS.
Si puedes, rehazlos como raid10. Le costará algo de espacio bruto pero tendrá un gran impacto en el rendimiento de E/S. Y si puede obtener un caché de escritura respaldado por batería en las tarjetas raid, la diferencia es muy grande.
No estoy familiarizado con glusterfs en particular, pero todos los sistemas de archivos distribuidos tienden a tener el mismo problema básico: latencia de red + bloqueo complejo = rendimiento deficiente, especialmente en archivos pequeños y especialmente en cargas de trabajo de escritura sustancial.
E/S de disco lenta y un sistema de archivos lento, este diseño de clúster simplemente no se adapta a la carga de trabajo. ¿Es demasiado tarde para devolver los servidores o al menos los subsistemas de disco? Si esta es la plataforma principal de una empresa con ingresos sustanciales, debería contratar a un profesional.
Respuesta2
¿A qué medio estás moviendo tu tráfico de GlusterFS? Si es Ethernet, su configuración estará muy limitada debido a los gastos generales de TCP/IP. GlusterFS no es el más eficiente allí. Donde realmente brilla es en RDMA. Puedes lograr esto con Infiniband o 10GigE.
Tampoco tengo claro por qué decidió colocar 2 hosts virtuales en cada host físico si todos realizan las mismas tareas. ¿Por qué no simplemente ejecutarlos sobre el metal desnudo y evitar los gastos generales?
Respuesta3
¿Qué versión de GlusterFs estás usando? GlusterFS 3.0.0 es una versión importante y tiene muchas mejoras, incluido un aumento en el rendimiento de archivos pequeños.
Hay muchos traductores de rendimiento en GlusterFS que se pueden ajustar para diversas cargas de trabajo. Por ejemplo, para aumentar el rendimiento de lectura tenemos un traductor de lectura anticipada y para el rendimiento de escritura tenemos un traductor de escritura retrasada. io-cache es otro traductor de rendimiento que se puede utilizar para el almacenamiento en caché.
¿Qué tipo de configuración es la tuya? ¿Está utilizando replicar, distribuir o ambos? ¿Cuál es el backend de su red? ¿Ha realizado una evaluación comparativa de E/S de red/disco entre los servidores antiguos y nuevos para eliminar los cuellos de botella?
Si puede compartir sus archivos de volumen con nosotros, podemos ayudarlo a ajustar sus archivos de configuración para obtener un rendimiento óptimo para sus cargas de trabajo.
Solo para su información, ofrecemos una suscripción de soporte de prueba gratuita de 30 días[1] donde puede obtener respuestas a sus consultas de manera rápida y detallada.
Saludos, Sachi.
Respuesta4
Sin más información sobre su configuración (por ejemplo, ¿su sitio web es estático o dinámico? ¿Las transacciones de bases de datos se realizan en los servidores que utilizan el mismo subsistema de almacenamiento?), pero RAID 6 es generalmente una mala opción para el rendimiento de escritura, no importa cuando introduce aún más complejidad. a través de gluster. Potencialmente tiene dos conjuntos de traducción de franjas de escritura, uno a nivel de gluster y otro a nivel de controlador. Luego tiene dos cálculos de paridad que ralentizan las cosas y causan bloqueo de E/S a menos que tenga un caché de escritura grande y períodos de baja actividad de E/S.
Le recomendaría que cambie a RAID 10 y lo respalde con un canal de fibra o múltiples enlaces GigE enlazados.