Wikimedia Quarto/2/tech/Pt

From Meta, a Wikimedia project coordination wiki
< Wikimedia Quarto‎ | 2‎ | tech
(Redirected from WQ/2/tech/Pt)
Desenvolvimento Técnico
Desenvolvimento Técnico

A maior parte do relatório abaixo foi escrito por James Day; a parte sobre as máquinas em Paris foi em maior parte escrita por David Monniaux.
Informações sobre nossos servidores podem ser encontradas a qualquer hora aqui. A atividade de desenvolvedores cai sobre as duas áreas principais: manutenção dos servidores; e desenvolvimento do software MediaWiki, que é também usado para muitas coisas não da Wikimedia. A maioria dos desenvolvedores, apesar de não todos, por sua escolha, estão listados aqui. Você pode mostrar que aprecia a dedicação deles deixando pequenos agradecimentos ou através de apoio financeiro. Obrigado!
Até agora, todos os desenvolvedores estão trabalhando de graça, mas nós poderemos mudar no futuro para darmos suporte ao nosso incrível crescimento.

Instalação de squid caches na França[edit]

O cluster próximo à Paris.
Nossos servidores são os três no meio: (de cima para baixo: bleuenn, chloe e ennael).

Em 18 de dezembro de 2004, três servidores doados foram instaladas numa facilidade em Aubervilliers, um subúrbio de Paris, França. Eles receberam os nomes de bleuenn, chloe e ennael por pedido do doador. Para aqueles que estão por dentro da tecnologia, as máquinas são servidores HP sa1100 1U com 640 MiB de RAM, discos rígidos ATA de 20 GB e processadores Celeron de 600 MHz.

As máquinas serão equipadas com software de squid caching. Eles serão um teste para uma técnica de adicionar caches próximos aos usuários para reduzir a latência. Geralmente, usuários franceses com uma conexão de Internet DSL podem conectar-se à estas máquinas com uma latência de 30 ms, enquanto podem apenas conectar ao cluster principal da Wikimedia na Flórida em torno de 140 ms. A idéia é que usuários de partes da Europa usem os squid caches na França, para reduzir o tempo em 1/10 de segundo, quando usuários tentam acessar o conteúdo multimídia e quando usuários anônimos tentam acessar qualquer tipo de conteúdo. Usuários logados não terão tanto lucro, já que as páginas são geradas especificamente para eles, e não são "cacheadas". Se uma página não estiver em um squid cache, ou a página é para um usuário logado, os servidores web Apache devem tomar de 1/5 a três ou mais segundos fora o tempo da base de dados para fazer a página. O tempo da base de dados é em torno de 1/20 segundo para coisas simples, mas pode atingir vários segundos para categorias, ou até mesmo 100 segundos para uma lista de artigos vigiados bem grande.

O centro de dados Telecity
O centro de dados Telecity

Os squid caches foram ativados no início de janeiro de 2005, e um período de testes seguiu. Em 31 de janeiro, as máquinas fazem o cache para o conteúdo em inglês, francês e de multimídia para a Bélgica, França, Luxemburgo, Suíça e Reino Unido. O sistema ainda está meio que em testes, e espera-se que o desempenho possa ser aumentado com algumas modificações. A instalação de clusters de cache similares em outros países está sendo considerada.

Instalação de mais servidores na Flórida[edit]

No meio de outubro, mais dois servidores escravos de base de dados dual Opteron, com 6 drives em RAID 0 e 4 GB de RAM, e mais cinco servidores Apache 3GHz/1GB foram pedidos. Atrasos, devido à problemas de compatibilidade, que o vendedor teve de resolver antes de enviar os servidores de base de dados, deixaram a página com pouco poder na base de dados; até o início de dezembro, a função de busca tinha de ser desligada, às vezes.

Em novembro de 2004, cinco servidores web, quatro com alta capacidade RAM usadas para Memcached ou squid caching, tiveram problemas. Isto resultou em wikis muito lentas, às vezes.

Foi feito o pedido de cinco servidores de RAM de 3GHz/3GB no início de dezembro. Quatro das máquinas de dezembro irão oferecer serviços de squid cache e memcached como substituições melhoradas das máquinas que estragaram, até que sejam consertadas. Uma máquina com vários drives SATA no RAID 0 serão usadas como teste para ver quanta carga estes servidores de base de dados de menor custo podem agüentar, assim como também oferecer uma outra opção para um escravo da base de dados apenas para backup, também rodando Apache. Estas máquinas estão equipadas com uma nova opção para energia remota e monitoramento da "saúde" do servidor com um custo adicional de US$ 60. Esta opção foi aceita para esta compra, para permitir a comparação de quão efetiva este conselho de monitoramento com uma faixa de energia remota ajuda a reduzir a necessidade de trabalho no local onde os servidores estão instalados, que pode envolver custos ou atrasos.

Uma outra ordem de um servidor mestre de base de dados, para permitir uma divisão dos servidores de base de dados em um mestre e par de escravos, com cada um com cerca de metade da atividade do projeto, assim como cinco novos Apaches estão planejados para compra no fim do último trimestre de 2004 ou nos primeiros dias de 2005. Esta compra irá usar o que sobrou dos US$ 50.000 da última arrecadação de fundos. O servidor de base de dados irá se dividir permitindo um alívio para os servidores servirem os pedidos dos usuários. Esta divisão deve acontecer em três meses, após o novo mestre provar sua confiança durante muitos meses de serviço como escravo da base de dados.

Tráfego e conectividade aumentada[edit]

O tráfego cresceu durante o terceiro trimestre de 2004 de em torno de 400 a 500 pedidos por segundo no início deste período para cerca de 800 por segundo no final. No início do quarto trimestre de 2004, o tráfego cresceu ainda mais, às vezes passando a marca dos 900 pedidos por segundo, com picos diários de até 1.000 a 1.100 pedidos por segundo, depois voltou a 900 e cresceu lentamente, novamente, devido ao final da febre da volta às escolas nos EUA, ou tempos com demora para o servidor responder, ou ambos ([1], [2]). O uso da largura de banda cresceu de uma média de 32 megabits por segundo no início do quarto trimestre de 2004 para cerca de 43 megabits por segundo no final. Picos diários típicos chegaram a até 65 a 75 megabits por segundo, e, às vezes, até mesmo a 100, limite de uma conexão única de ethernet. Para lidar com este tráfego, conexões duplas de 100 megabits foram usadas temporariamente, e uma conexão de fibra de gigabit foi arrumada no local de servidores na Flórida, e as partes necessárias foram pedidas.