Preciso armazenar 25 milhões de fotos em 4 tamanhos = total de 100 milhões de arquivos, o tamanho do arquivo varia entre 3 KB e 200 KB por arquivo e o armazenamento usado no início é de cerca de 14 a 15 TB.
Nosso objetivo é ter os dados em 2-4 servidores disponíveis e para servi-los com um servidor Web local rápido (nginx ou lighthttpd), precisamos servir o máximo possível de req/s.
Meu plano é usar Servercase 2U da Intel com 12x2TB (WD RE4) com Raid 6 (ou FS com redundância ??) para os dados e SSD de 2x60GB para o sistema operacional, é uma boa maneira? Agora: encontrei o Adaptec 5805ZQ que pode usar Drives SSD SLC para cache dos arquivos mais usados, alguma sugestão para isso?
Qual tamanho de cache de leitura devo escolher?
Qual será a melhor maneira de redundância e balanceamento de carga, se eu planejo ter de 2 a 4 servidores desse tipo?
Quais são as vantagens/contras entre Cluster e FS distribuído em relação ao nosso objetivo?
Responder1
Se este for um desenvolvimento greenfield, entãoEu absolutamente usaria a nuvem para isso. 100 milhões de arquivos são muitos dados; seria uma grande melhoria descarregar o armazenamento redundante para corrigir o Amazon S3.
Dado que estamos falando de arquivos de 100 M, acredito que podemos dizer com segurança que algumas partes do conjunto de dados estarão 'quentes' (solicitadas com frequência) e a maioria estará fria. Portanto, realmente queremos armazenamento em cache.
Uma visão geral de como isso poderia ser feito na Amazon Web Services:
- Primeira camada:Elastic Load Balancing gerenciado pela Amazon e monitoramento do Amazon CloudWatch para algumas pequenas instâncias do EC2 com nginx ou Apache. Esses servidores são apenas balanceadores de carga burros com arquivos de configuração estáticos, então o Cloudwatch pode monitorá-los para nós e gerar automaticamente novas instâncias se uma delas travar.
- Da primeira camada:Aceleração consistente com base no URL da solicitação (nome do arquivo)para uma camada de servidores de cache. Você deseja hash baseado no nome do arquivo para garantir que cada arquivo não seja armazenado em cache muitas vezes (reduzindo a taxa de acertos do cache), mas com N servidores de cache, cada servidor lida com 1/N do espaço de endereço.
- Segunda camada:Servidor(es) de cache. Seus servidores de cache são instâncias EC2 com mais memória e Squid ou Varnish ouServidor de tráfego Apachecache instalado.
- Da segunda camada: HTTP antigo simples para armazenamento de arquivos Amazon S3.
Como esta configuração é fracamente acoplada,dimensionar horizontalmente é fácil(no que diz respeito aos problemas de escala).
A rapidez com que será dependerá muito da proporção entre dados quentes e frios. Se sua carga de trabalho estiver muito quente, não ficaria surpreso em ver bem acima de 10.000 req/s de apenas 2 EC2s de balanceador de carga pequeno e 2 instâncias de EC2 de cache de alta memória.
Responder2
SSDs para o sistema operacional em si são um exagero, a menos que você esteja realmente interessado em inicializar 30 segundos mais rápido. Basta adquirir um par de unidades SAS pequenas e isso será mais que suficiente.
Escrita. o cache, a utilidade do cache depende do conjunto de trabalho. Ou seja, espera-se que as solicitações de imagens sejam distribuídas uniformemente por todas as imagens ou você espera que a maioria das solicitações seja para um pequeno subconjunto? Neste último caso, um cache pode ser útil; no primeiro, nem tanto. Observe que o cache no controlador de disco é útil principalmente para armazenar gravações em cache (se o cache não for volátil), o que é útil para aplicativos com uso intensivo de fsync(), como bancos de dados. Para veiculação de imagens, suspeito que o benefício não será tão grande.
Um problema com FS agrupados e distribuídos é que eles são mais complicados de configurar e, especialmente, FS distribuídos são menos maduros do que FS "normais" de nó único. Um cluster FS normalmente significa armazenamento compartilhado, o que significa uma SAN relativamente cara se você quiser evitar pontos únicos de falha.
Uma alternativa seria configurar um cluster executando algum tipo de Amazon S3 semelhante que fornece um armazenamento de valor-chave distribuído e replicado acessível por HTTP. Por exemploarmazenamento em pilha aberta.
Responder3
Depende muito da frequência com que esses itens serão usados. Se você pode esperar que uma pequena porcentagem deles esteja muito ativa ao mesmo tempo, então você pode querer considerar o Varnish para fazer seu manuseio de front-end, balanceando a carga de seus back-ends nginx/lighttpd. Como as imagens usadas com frequência seriam armazenadas em cache, a velocidade do disco é um pouco menos importante.
No entanto, se as imagens não forem solicitadas repetidamente e o cache não fornecer um grande impulso, o nginx/lighttpd em um ou dois servidores servirá. Você também precisa considerar a quantidade de largura de banda que irá fornecer. 800 MB/s de um pequeno subconjunto do seu conjunto de dados seriam facilmente armazenados em cache pelo sistema operacional. 800 MB/seg de um subconjunto enorme do seu conjunto de dados provavelmente enfrentará um gargalo de E/S, pois você não conseguirá retirar os dados do disco rápido o suficiente para serem servidos; nesse caso, você precisará dividir seu sistema em partes suficientes para ter o IO largura de banda.
Mesmo que você esteja executando o raid-6, isso ainda não substitui os backups; portanto, faça um orçamento de uma máquina semelhante para fazer backups ou, possivelmente, para atuar como um servidor de armazenamento de failover.
Responder4
Eu escolheria um cluster personalizado em vez de um FS distribuído, porque é mais simples de entender e solucionar problemas, enquanto ainda funciona. Ou seja, as compensações de confiabilidade do seu próprio cluster são óbvias, embora seja uma tarefa por si só descobrir como um FS distribuído reage a um servidor morto ou a um switch com falha.
Uma possível solução para o seu tipo de problema é dividir todo o arquivo de fotos em partes (digamos, 2 partes) e tornar o ID da parte explícito na URL (por exemplo, torná-lo um subdomínio ou um parâmetro GET que seja fácil de extrair com regular expressões). Então você terá 4 servidores de armazenamento com fotos (2 servidores para cada parte). Use o quinto servidor como proxy reverso que distribui e equilibra a carga. Todos os cinco servidores podem executar lighttpd. Ou seja, proponho um muito burro, mas funcional (para a empresa em que trabalhei - com carga total de ~5000 solicitações por segundo, arquivos com tamanho de 3 a 10 KB, 8 TB de arquivos únicos no total, servidor de 24 backends que , no entanto, execute uma solução HTTP daemon personalizada em vez de lighttpd).
Quanto aos discos e RAM: usamos um software RAID-0 feito de quatro discos SATA rápidos, mas baratos em cada servidor (se um disco falhar, todos os dados podem ser copiados de qualquer maneira de uma réplica em um servidor diferente), além de uma solução personalizada para colocar todo o servidor offline após um único erro de leitura. RAID-5 e RAID-6 são muito ruins em termos de velocidade, mesmo se um disco falhar, por favor, não os use. Nos servidores de conteúdo, muita RAM é essencial (como cache de disco), procure 24 GB ou mais. Mesmo assim, esteja preparado para um aquecimento de 30 minutos. No proxy reverso, se você usar lighttpd, leve em consideração que ele armazena toda a resposta upstream na RAM o mais rápido possível e pode gastar muito tempo enviando a foto em cache para alguém em dial-up ou GPRS (e durante esse tempo , precisa desse buffer na RAM). Também pegamos 24 GB apenas para ter configurações idênticas, mas não tenho certeza se isso é um exagero. O cache HTTP baseado em memória no proxy reverso não é essencial (mesmo se houver imagens quentes!), porque o cache de disco fornecido pelo sistema operacional nos back-ends funciona da mesma forma.
Para garantir que todos os back-ends que atendem a mesma parte do seu arquivo tenham os mesmos dados: isso é fácil. Ao publicar fotos, basta copiá-las para todos os servidores. Em seguida, use o rsync em partes antigas do arquivo para corrigir quaisquer discrepâncias, tornando assim uma cópia do mestre.