Armazenamento redundante de conteúdo estático da Web - que tecnologias? (pequena escala) [fechado]

Question

Situação atual de nossos servidores da Web estáticos:

• 2 servidores 2U cheios de SSDs (raid5) para armazenamento de dados
• os dados são gravados para eles somente por meio de nossos aplicativos (*)
• grande quantidade de pequenos arquivos de imagem (uma imagem é ~ 50kB)
• tráfego balanceado por registros de 2 dns + keepalived / heartbeat entre servidores
• ~ 4Gbps no total do tráfego HTTP no pico (~ 2Gps por servidor)
• usuários acessam arquivos via nginx, aplicativos internos via ftp
• estamos usando somente get, delete, put - quero dizer, não há arquivos anexados e outras chamadas posix usadas, operamos apenas com arquivos inteiros (mesmo solicitações de intervalo http não são permitidas)

(*) Somente nossos aplicativos internos gravam em ambos os servidores via ftp. Se um deles falhar, toda a operação falhará = > o upload não funciona quando um dos servidores está inativo. Mas a veiculação do conteúdo estático para os clientes da Web ainda está funcionando.

Alcançamos 50% da nossa capacidade de disco e começamos a procurar uma solução melhor. Como não precisamos de chamadas posix padrão, eu estava pensando em migrar para armazenamento de objetos.

Eu descobri que o Openstack Swift é muito famoso e pode ser útil. O que eu tenho medo é:

• estaremos executando em dois servidores somente para o próximo meio ano
• temos muito tráfego http na web que não tenho certeza de que o swift possa lidar com

A outra pergunta é um pouco mais específica. Gostaríamos de fornecer aos nossos usuários a capacidade de fazer upload de seu conteúdo por meio de algum formulário de upload (por exemplo, produtos de imagens na loja virtual). Então a questão é - existe alguma forma de upload direto com barra de progresso, ...? Ou temos que enviá-lo para o servidor web padrão que não está manipulando nenhum conteúdo estático (= conteúdo que não esteja no git) e, em seguida, fazer o upload para o armazenamento de objetos.

Sinta-se à vontade para postar sua opinião ou, ainda melhor, suas melhores práticas.

E uma coisa importante - não queremos usar nenhum provedor de CDN.

Atualização # 1:

Ok, pessoal. Existem mais algumas tecnologias que encontrei:

• GlusterFS: Infelizmente muito lento e não estável.
• HDFS: não tenho experiência com isso. O que você acha?

Answer 1

A estimativa de carga real no seu armazenamento seria muito útil.

Os cálculos brutos com os parâmetros fornecidos fornecem cerca de ~ 10K Gets / seg (4Gbps / 50KB). Mas não leva em conta os recursos de armazenamento em cache.

Suponho que a configuração SWIFT capaz de atender a essa carga exige investimentos significativos. Nossos colegas tentaram usar o SWIFT para armazenar partes de seu banco de dados de propósito especial que requer milhares de IOPS de desempenho do SWIFT. Mas eu não ouvi que obtiveram ótimos resultados. A última coisa que sei é que ainda está em teste. Além disso, eu fiz não encontrar ótimos resultados relatados de outras pessoas.

Eu compartilho sua razão de que um armazenamento compartilhado com requisitos POSIX reduzidos é certamente benéfico. Mas o SWIFT é implementado em camadas altas que introduz uma sobrecarga significativa para as operações. Além disso, possui uma arquitetura bastante complexa. Portanto, não tenho certeza se o SWIFT é adequado para instalação pequena com carga pesada de IOPS.

Além disso, leve em conta que o uso do SWIFT faz pensar sobre a implementação da camada de armazenamento em cache da RAM que estava disponível "da caixa" com o sistema de arquivos local clássico.

E a última redundância - SWIFT é obtida com duplicação total de dados. Assim, a eficiência do seu espaço SSD será de cerca de 40% fornecendo RAID5 (4 + 1).

Acho que a abordagem clássica é mais atraente: caixa de armazenamento dedicada com controlador RAID redundante e sistema de arquivos de cluster GFS / OCFS2.