10tb questão de design de armazenamento de arquivos no site da mídia

2

Eu tenho um site de mídia bastante ocupado, onde arquivos de áudio MP3 são carregados por membros e transmitidos / baixados de dois servidores Windows que estão com carga balanceada no momento ... ambos os servidores simplesmente se espelham e são mantidos em sincronia.

O que fazemos atualmente é simplesmente adicionar novos HDs de 2 TB cada vez que a unidade atual ficar cheia, então os usuários carregam dados para a nova unidade ... temos baias suficientes para 24 discos.

Estamos obtendo gargalos de E / S no disco rígido adicionado mais recentemente porque todas as novas mídias são adicionadas a esse disco, que também é o mais popular ... isso pode ser superado ao espalhar os dados em cada disco, mas fica complicado quando ficar sem espaço e adicionar uma nova unidade em branco.

O motivo pelo qual estou espelhando meus arquivos é para que eu tenha um backup de 1: 1, o failover no caso 1 servidor fique inativo e para que eu possa facilmente carregar meu site com duas máquinas.

Somone recomendou anteriormente usar NAS / SAN, eu não tenho acesso a isso infelizmente.

O que você recomendaria na minha situação ... há alguma maneira de melhorar minha configuração?

Eu li sobre Sistemas de Arquivos Distribuídos no outro dia, o que soou como pode caber, no entanto, todos parecem ser apenas linux ... convertendo para linux agora seria um desafio para dizer o mínimo que eu tenho pouca experiência.

Se eu perdi alguma coisa que poderia ajudá-lo a responder, por favor me avise.

Obrigado Paul

    
por Paul Hinett 17.03.2011 / 00:00

2 respostas

4

Um problema de balanceamento de carga de dados. Isso é divertido. Aqui estão algumas experiências que tive lidando com grandes conjuntos de dados, mesmo que normalmente tenhamos espalhado por vários servidores.

  1. Parece que você ainda não separou o armazenamento da apresentação. Você precisa fazer isso. Projete uma interface para seu armazenamento (ele pode ser apresentado como arquivo como um servidor separado, um compartilhamento NFS ou similar). Pessoalmente, sou strongmente a favor de ter um servidor de "mídia", que serve apenas os dados. Dessa forma, você se move para o modelo NAS e economizará uma enorme quantidade de dor à medida que crescer.

  2. Depois de separar a mídia do aplicativo, você poderá começar a procurar soluções sobre como lidar com essa grande quantidade de dados que você tem.

Existe um grande número de produtos SAN comerciais. Eles normalmente carregam o saldo em uma grande quantidade de discos e manipulam bem ou adicionam / removem armazenamento. Eles também são muito caros, e parece que você já tem hardware.

No lado do Linux, existe um software padrão para lidar com essa quantidade de dados sem problemas. O LVM e o EXT4 podem lidar com sistemas de arquivos muito grandes (tenha cuidado com o tempo do FSCK). Se eu fosse construir isso, provavelmente iria LVM, EXT4 e servir os dados usando o Apache. Essa combinação também permite aumentar o armazenamento do tamanho necessário.

Mas isso é apenas estratégias gerais. Agora, para atacar o problema específico que você tem. É um pouco difícil sem conhecer os detalhes da implementação, mas posso oferecer algumas sugestões:

Parece que você não está balanceando a carga do seu IO corretamente. Eu suponho que você pode acompanhar qual disco serve seus dados. Nesse caso, você deve criar um script de "rebalanceamento". Quando você adiciona um novo disco ao seu sistema, esse script coleta dados de todos os discos antigos e preenche o novo disco. Em seguida, você pode distribuir os arquivos recebidos por todos os discos e, assim, obter um melhor balanceamento da carga de E / S. Isso pressupõe que você tenha sistemas de arquivos diferentes nos diferentes discos e não apenas está criando um JBOD enorme, o que é uma má ideia em geral.

Um segundo passo é iniciar o perfil. Faça um pequeno aplicativo que registra cada solicitação de arquivo. Se você vir um disco específico sendo atingido mais do que seu quinhão, você troca dados entre o disco e o disco menos utilizado. Esse tipo de balanceamento de carga é feito preferencialmente como um trabalho regular, talvez a cada hora ou dia.

Além disso, certifique-se de obter grandes caches de E / S. O que normalmente mata o desempenho de E / S no tipo de aplicativo que você tem é quando você atende a tantos arquivos diferentes que sobrecarrega os caches, fazendo com que o disco comece a ser descartado. Maximize o cache em seus controladores de disco e jogue a maior quantidade de memória possível no sistema. O Windows terá todo o prazer de usar RAM reserva como cache de leitura. Não é difícil, ou mesmo especialmente caro, encher mais de 128G de RAM em um servidor hoje. Esse é um cache muito grande, mesmo que seu conjunto de arquivos seja 1TB.

Com a quantidade de dados que você está veiculando, sugiro que você fique longe das soluções RAID. Reconstruir grandes arrays de ataque tende a ser uma experiência dolorosa.

    
por 17.03.2011 / 01:49
0

Uma pergunta básica - você está usando uma matriz RAID e não apenas espelhando as duas unidades que está adicionando?

Usar algo como o RAID10 na caixa de armazenamento permitirá que você aumente a matriz (adicionando unidades e, em seguida, informando ao subsistema RAID ou ao subsistema RAID de software para usar os discos adicionais.

No entanto, é aconselhável mudar para um modelo de armazenamento desacoplado. Simplesmente de uma perspectiva de dimensionamento, você tem um problema em que seu conjunto de dados vai crescer e crescer. Se você não arquivar os dados antigos, nunca parará de crescer.

Por exemplo, quando você preenche todas as baias da sua máquina existente, o que você faz? ; -)

Usando o Windows, eu pessoalmente me afastei do sistema de arquivos distribuído que eles usam. use as soluções mais simples. Felizmente, o Windows 2008r2 é fornecido com suporte a iSCSI - para que você possa criar seu próprio SAN com bastante facilidade ( link ).

Melhor ainda, construa uma caixa Linux como o alvo iSCSI e aponte para ela a partir das máquinas Windows.

    
por 17.03.2011 / 06:12