Qual é o caminho mais rápido para mover 1Petabyte de um armazenamento para um novo?

Question

Antes de mais nada, obrigado pela leitura, e desculpe por perguntar algo relacionado ao meu trabalho. Eu entendo que isso é algo que eu deveria resolver sozinho, mas como você vai ver é algo um pouco difícil.

Uma pequena descrição:

Agora

Armazenamento = > 1PB usando armazenamento DDN S2A9900 para OSTs, 4 OSS, rede de 10 GigE. (brilho 1.6)

100 nós de computação com 2x Infiniband

1 comutador infiniband com 36 portas

Depois de

Armazenamento = > Armazenamento anterior + outro 1PB usando DDN S2A 990 ou LSI E5400 (ainda a decidir) (brilho 2.0)

8 OSS, rede 10GigE

100 nós de computação com 2x Infiniband

Experiência anterior: transferiu 120 TB em menos de 3 dias usando o seguinte comando:

 tar -C /old --record-size 2048 -b 2048 -cf - dir | tar -C /new
--record-size 2048 -b 2048 -xvf - 2>&1 | tee /tmp/dir.log

Então, grande problema aqui, usando grandes equações matemáticas, concluo que precisaremos de 1 mês para transferir os dados de um lado para o novo. Durante esse tempo, os pesquisadores precisarão recuar, e pessoalmente não estou feliz com isso.

Estou lhe dizendo que temos conexões infinibais porque acho que pode haver uma chance de usá-lo para transferir os dados usando 18 nós de computação (18 * 2 IB = 36 portas) para transferir os dados de um armazenamento para o outro. Eu estou tentando descobrir se o switch IB vai lidar com todo o tráfego, mas no caso de apenas queimar vai mais rápido do que usar 10GigE.

Além disso, ter agentes do lustre 1.6 e 2.0 no mesmo servidor funciona muito bem, com isso, não é necessário usar 1.8 para atualizar os servidores de metadados com duas etapas.

Alguma idéia?

Muito obrigado

Nota 1: Zoredache, podemos dividi-lo em dois blocos (A) 600TB e (B) 400TB. A idéia é mover (A) para novo armazenamento que é lustre2.0 formatado, então formatar onde (A) estava com o lustre 2.0 e mover (B) para este bloco de lustre 2.0 e estender com o espaço onde (B) estava .

Desta forma, vamos terminar com (A) e (B) em sistemas de arquivos separados, com 1 PB cada.

    

Answer 1

O objetivo é fazer com que cada camada entre o armazenamento antigo e o novo armazenamento seja mais rápida do que a velocidade máxima de leitura que você pode obter da sua máquina antiga. Suas especificações afirmam 6GB / s seqüencial (o que deveria ser). Isso significa que o tempo mínimo possível para mover os dados estaria no reino de 46 horas, se você conseguir obter a velocidade anunciada.

Quando você estava usando alcatrão para mover 120 TB em 3 dias, você deve ter uma média de apenas meio GB por segundo, e isso é consideravelmente menor que os 6 GB / s que as especificações afirmam. O número verdadeiro provavelmente estará em algum lugar no meio.

Primeiro, o alcatrão pode ser o seu problema. Eu sou um cara de armazenamento, não um cara unix, mas tanto quanto eu sei, pode limitar sua taxa de transferência com base na velocidade do processador. Se você seguir essa metodologia, poderá diminuir a janela de migração aumentando o número de nós que executam a migração e fazendo com que eles trabalhem em diferentes partes do conjunto de dados. Continue adicionando nós até que a máquina antiga seja incapaz de servir arquivos mais rapidamente.

Em segundo lugar, certifique-se de que você é capaz de escrever a partir do seu nó de migração para o novo armazenamento o mais rápido possível para ler o armazenamento antigo. Isso pode significar ajustar algumas configurações no novo armazenamento (especialmente se ele tiver um cache de gravação espelhado antigo), além de garantir que não haja gargalos de rede.

Por último, e isso pode ser um pouco improvável, se você puder diminuir o tempo de inatividade e essa caixa estiver servindo LUNs sobre FC, você poderá inserir um dispositivo de virtualização de armazenamento no caminho de dados que permitiria continuar usando o armazenamento, embora seja mais lento, enquanto você faz a migração. O SAN Volume Controller da IBM, o appliance de virtualização da Falconstore ou um storage array HDS são todos capazes de automatizar a migração de dados em segundo plano sem interromper o acesso ao host. Nenhum deles será tão rápido quanto ao que você está acostumado, mas permitirá que você trabalhe enquanto migra após a breve interrupção necessária para obter os nós trabalhando dos novos cabeçotes de armazenamento.

Provavelmente não vale a pena comprar uma vez que você não a usará depois de concluir a migração, mas poderá pedir emprestado ou alugar uma.