networking – ¿Es esta una arquitectura razonable para un sitio de periódicos?

Pregunta:

Dirigimos un sitio al estilo de un periódico y estamos consolidando nuestra arquitectura de una que creció amorfamente a una solución más escalable y resistente.

Estaba pensando en lo siguiente:

internet
    |
h/w firewall
    | 
h/w load balancer
    |        |
    |     control server (nagios, mail server & misc)   
    |
pair of nginx load-balancing reverse caching proxies
    |                                  |
pair of apache app servers          pair of mogilefs storage nodes
and mogilefs trackers
    |
 pair of mysql dbs (master/slave)
 and mogilefs db

todas las máquinas ejecutarán centos de 64 bits.

Necesitamos poder atender a 7 usuarios simultáneos en los servidores de la aplicación y entregar 840 archivos estáticos por segundo. Entonces estaba pensando en especificar cosas como a continuación:

  • Nodos de almacenamiento de mogilefs: 2 GB de RAM, Intel Atom (1,6 GHz)
  • servidores de aplicaciones: 8 GB de RAM, AMD Athlon II X2 (2,8 GHz)
  • Proxies inversos y servidor de control – 4GB RAM, AMD Athlon II X2 (2.8GHz)
  • dbs – 8 GB de RAM, AMD Phenom II X6 (2,8 GHz)

Todos tendrían discos de 7.2krpm. No hay una gran cantidad de datos en la base de datos, por lo que básicamente todos se pueden almacenar en caché en búferes. Además, solo tenemos alrededor de un 15% de tasa de errores en memcached, por lo que no hay una gran carga en la base de datos.

Una etapa futura sería el DNS por turnos con todo reflejado en un centro de datos diferente.

¿Falta algo en esta topología? ¿Alguien ha hecho algo similar con alguno de los componentes? ¿Parecen las máquinas que tienen especificaciones insuficientes o excesivas?

Gracias

EDITAR

Un poco más de información:

7 vistas de página simultáneas por segundo para ser atendidas por apache: gran parte del contenido de cms se almacena en caché de todos modos, en el disco y utilizando memcached siempre que sea posible. Es necesario servir 840 archivos estáticos por segundo, pero esto puede ser un poco demasiado alto, ya que con fechas de vencimiento en el futuro lejano, solo una fracción de las visitas a la página tendrá cachés fríos en el cliente.

Los únicos administradores subirán contenido estático a los nodos de almacenamiento de mogilefs. Pueden cargar ~ 100 archivos por día. Soy nuevo en mogilefs: solo usarán discos básicos (7.2krpm)

Luego, se accederá a este contenido a través de http: // static * .ourdomain … Nginx enviará la solicitud a este contenido y lo almacenará en caché localmente, por lo que, si bien la primera recuperación puede ser un poco lenta, las recuperaciones posteriores provendrán de la caché de nginx.

Respuesta:

Esto es demasiado general para hacer una pregunta simple. Deberá proporcionar mucha más información sobre su solución propuesta y sobre la carga:

  • ¿Qué carga (páginas / páginas en caché / activos) servirá qué software en esta pila (nginx, mogilefs, localfs, apache)? ¿Qué hará el equilibrador de carga, de qué tipo es?
  • ¿Qué CMS usarás? ¿Cómo interactúa con mogile? ¿En qué tipo de almacenamiento funcionarán tus mogilefs?
  • Si bien puede ejecutar mogile happy en nodos de 2Gb y apache en 4Gb, no escatimaría en RAM. Más memoria facilitará muchas cosas.
  • No mencionas las CPU, esto es aún más importante en la imagen de CMS

Además, no veo ningún memcached allí; dependiendo de la configuración que pueda ser útil.

7 usuarios simultáneos no suena mucho, ¿cuántas páginas vistas por segundo es eso en tu vista?

Edite para reflejar la nueva información:

Hay muchos detalles que desarrollar, pero esto parece razonable. Mucho dependerá de cómo configure el almacenamiento en caché de nginx y el CMS. Tenga en cuenta la red también, sugeriría al menos gigabit.

Estoy un poco preocupado por el desempeño de mogilefs. Si todavía se encuentra en la fase de diseño, le sugiero que busque alternativas (tal vez la replicación directa del sistema de archivos) o escenarios de migración futuros, según sus requisitos.

Además, su equilibrador de carga es actualmente un elemento de muy alto nivel en el diseño. Hasta que esté muy seguro de los requisitos en términos de rendimiento y características, dejaría todas las opciones sobre la mesa allí.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım