Essa é uma arquitetura razoável para um site de jornal?

5

Executamos um site em estilo de jornal e estamos consolidando nossa arquitetura de uma que cresceu de forma amorfa em uma solução resiliente e mais escalável.

Eu estava pensando no seguinte:

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 as máquinas serão executadas em centos de 64 bits.

Precisamos conseguir atender 7 usuários simultâneos nos servidores de aplicativos e fornecer 840 arquivos estáticos por segundo. Então eu estava pensando em especular coisas como abaixo:

  • nós de armazenamento mogilefs - 2 GB de RAM, Intel Atom (1,6 GHz)
  • servidores de aplicativos - 8 GB de RAM, AMD Athlon II X2 (2,8 GHz)
  • proxies reversos & servidor de controle - 4 GB de RAM, AMD Athlon II X2 (2,8 GHz)
  • dbs - RAM de 8 GB, AMD Phenom II X6 (2,8 GHz)

Todos teriam discos de 7,2krpm. Não há uma quantidade enorme de dados no banco de dados, então basicamente tudo pode ser armazenado em cache em buffers. Além disso, temos apenas cerca de 15% de taxa memcached, então não há uma carga enorme no banco de dados.

Um estágio futuro seria um DNS round-robin com tudo espelhado para um data center diferente.

Há algo faltando nessa topologia? Alguém já fez algo parecido com algum dos componentes? As máquinas parecem estar sub-especificadas?

Obrigado

EDITAR

Um pouco mais de informação:

7 exibições de páginas simultâneas por segundo a serem atendidas pelo apache - muito do conteúdo do cms é armazenado em cache, em disco & usando memcached sempre que possível. 840 arquivos estáticos precisam ser veiculados por segundo - mas isso pode ser um pouco alto, já que com datas de expiração muito futuras, apenas uma fração das visualizações de página será com caches frios no cliente.

Os únicos administradores enviarão conteúdo estático para os nós de armazenamento mogilefs. Eles podem fazer upload de ~ 100 arquivos por dia. Eu sou novo no mogilefs - eles apenas usam discos de commodity (7.2krpm)

Este conteúdo será então acessado através do link * .dominio ... Nginx fará o proxy do pedido para este conteúdo e o armazenará em cache localmente, enquanto a primeira recuperação pode ser um pouco lento, recuperações subseqüentes virão do cache nginx.

    
por timmy 18.08.2010 / 10:24

2 respostas

1

Isso é um pouco geral demais para fazer em uma pergunta simples. Você precisará fornecer muito mais informações sobre sua solução proposta e sobre a carga:

  • Qual carga (páginas / recursos armazenados em cache) será atendida por qual software nesta pilha (nginx, mogilefs, localfs, apache)? O que o loadbalancer fará, de que tipo é?
  • Qual CMS você estará usando? Como isso interage com o mogile? Que tipo de armazenamento seu mogilefs vai rodar?
  • Enquanto você pode rodar mogile feliz em nós de 2Gb e apache em 4Gb, eu não economizaria em RAM. Mais memória tornará as coisas mais fáceis.
  • Você não menciona CPU, isso é ainda mais importante na imagem do CMS

Além disso, não vejo nenhum memcached lá; dependendo da configuração que poderia ser útil.

7 usuários simultâneos não soam muito, quantas exibições de página por segundo são na sua opinião?

Editar para refletir as novas informações:

Existem muitos detalhes para detalhar, mas isso parece razoável. Muito dependerá de como você configura o cache nginx e o CMS. Mantenha a rede em mente também, sugiro pelo menos gigabit.

Estou um pouco preocupado com o desempenho do mogilefs. Se você ainda estiver na fase de design, sugiro que veja alternativas (talvez replicação direta do sistema de arquivos) ou futuros cenários de migração, dependendo de suas necessidades.

Além disso, o balanceador de carga é atualmente um elemento de alto nível no design. Até que você esteja muito certo dos requisitos em termos de desempenho e recursos, deixarei todas as opções na mesa.

    
por 18.08.2010 / 11:30
4

Você está fazendo ~ 7 page req / s a partir dos servidores web (dinâmicos), e ~ 850 req / s para conteúdo estático (smallfile), e para isso você precisa de uma arquitetura multi-camadas com ~ 10 servidores ?

Apenas fora do topo da minha cabeça, isso soa muito lento. Ou você está com excesso de recursos ou seu site tem algum código lento e lento ou algo mais?

Gostaria de propor uma avaliação completa de seu aplicativo e, a partir disso, criar uma estimativa de qual hardware você precisa para sua carga.

Algumas ideias:

  • Ter duas camadas de balanceamento de carga é uma complexidade adicional, é necessário? Que tal apenas um balanceador de carga HW e um único servidor de cache (Squid ou Varnish).

  • Nunca use CPUs Atom para servidores reais, elas são muito fracas.

  • Não vejo por que você quer usar CPUs de classe de desktop antigas como Athlon de núcleo duplo. As CPUs modernas do servidor quad-core são pelo menos 2x mais rápidas em uso real. Usar um hardware moderno e mais potente permitiria consolidar camadas e simplificar sua arquitetura.

  • O MogileFS é provavelmente ótimo; Eu não sei muito sobre isso, exceto a sua origem e que tem sido em uso pesado há anos com grande sucesso. Mas por que configurar uma tecnologia com a qual você não está familiarizado apenas para dimensionar para dois servidores? Se você precisa apenas do nível de desempenho de 2 servidores com processadores Intel Atom, desative essa configuração e obtenha um único servidor quadcore moderno com um subsistema de disco rápido (4 ou 8 discos rígidos RAID 10 ou SSDs).

Recomendações:

  • Avalie seu próprio aplicativo e obtenha as melhores métricas possíveis para sua taxa de acertos do cache real.
  • Talvez encontre um consultor que tenha criado algo assim várias vezes antes e trabalhe junto com ele sobre o design final?

Sua arquitetura acima é sólida e bem considerada. Mas obtenha alguns números para o desempenho real das partes individuais. : -)

    
por 22.08.2010 / 13:56