Precisa de ajuda para estimar a largura de banda necessária para a replicação de matriz de SAN para SAN na WAN

Question

Eu tenho um objetivo de longo prazo de configurar um site de DR em um local específico e parte desse plano inclui a replicação de alguns volumes da minha SAN EqualLogic. Estou com dificuldades para fazer isso porque não sei se meu método é bom.

Este post pode ser um pouco longo para completar.

Informações gerais relevantes:

1. Eu tenho um EqualLogic PS4000X (~ 4TB).
2. A SAN funciona como armazenamento compartilhado para dois hosts ESXi no ambiente do vSphere 5.
3. Eu tenho 4 volumes de 500GB cada. Os volumes 1 e 2 contêm minhas VMs de "camada 1". Estes serão os únicos volumes que pretendo replicar.
4. Atualmente, temos uma conexão de 3Mb / s com largura de banda de dados real de ~ 2,8Mb / s devido ao nosso PRI (voz).

Meu método de medir a mudança em um volume:

Foi-me dito por um representante da Dell que uma maneira (talvez não a melhor?) estimar deltas em um volume é medir o espaço de reserva de snapshots usado durante um período de tempo de um cronograma regular de snapshots.

Minha primeira experiência com isso foi criar um cronograma de 15 minutos entre instantâneos com uma reserva de instantâneos de 500 GB. Eu deixei isso acontecer durante a noite e até COB no dia seguinte. Não me lembro do número de instantâneos que podem ser mantidos em 500 GB, mas acabei com uma média de ~ 15 GB por instantâneo.

$average_snapshot_delta = $snapshot_reserve_used / $number_of_snapshots

Em seguida, mudei o intervalo de instantâneo para 60 minutos, o que após um total de 24 horas de passagem significa um total de 13 instantâneos em 500 GB. Isso me deixa com ~ 37GB por hora (ou ~ 9GB por 15 minutos).

O problema:

Esses números são astronômicos para mim. Com a minha largura de banda eu posso fazer um pouco mais de 1GB / hora com 100% de utilização. A replicação em nível de bloco é cara ou estou fazendo algo completamente errado?

    

Answer 1

Seus números se resumem a 10,24 MB / s, o que parece um pouco alto para a escrita pura. Mas eu não conheço suas cargas de trabalho.

No entanto, você tem um problema maior. A replicação inicial estará replicando 1 TB de dados em uma palheta de 3MB / s.

1TB = 1024GB = 1,048,576 MB
2.8 MB/s replication speed
~4.33 days

Durante esse tempo, será feito o enfileiramento de sua alteração de rede para quando a sincronização inicial for concluída. E se você precisar extrair dados do array remoto, serão 4,33 dias até que você esteja totalmente em funcionamento (a menos que você tenha um método fora de banda de transferência de dados, como um envio FedEx Overnight ou um caminhão).

Quanto à diferença de net-change entre seus snapshots de 15 minutos e os de 60 minutos, acredito que o snapshot de 60 minutos está obtendo o benefício de muita combinação de gravação. Ou, dito de outra forma, todas essas gravações nos periódicos de sistema de arquivos estão sendo reunidas no instantâneo mais longo da maneira como elas não são tanto nos snaps de 15 minutos.

Este é o lugar onde o modo de sincronização realmente se encaixa. Um canal de 3MB / s está insuficientemente provisionado para replicação síncrona. Uma replicação assíncrona em lote ganhará alguns dos benefícios da combinação de gravação e, portanto, reduzirá a transferência total, ao custo de perder alguns dados em um desastre. Infelizmente, eu não sou bem versado o suficiente em Equilogic para saber o que é capaz de

    

Answer 2

Este é o maior conflito contra equallogic na minha opinião. A replicação é baseada em instantâneos e sua tecnologia de instantâneos é incrivelmente ineficaz.

Executamos cerca de 25 matrizes em nosso ambiente e minha meta de 2 a 3 anos é substituí-los por todos com o netapp. Com base no que vemos em nossos arquivadores cif netapp e no teste do nfs, a largura de banda da replicação e o espaço do snapshot serão reduzidos em 80%. adicionar aos recursos de desduplicação do netapp e é muito mais eficiente.

Certifique-se de colocar seus arquivos de paginação do Windows e seus arquivos de troca de vmware em um volume não replicado.

Além disso, se você puder pagar, adicione alguns otimizadores wan do leito do rio. Eles reduzirão a quantidade de dados em seu wan para replicação em 60% ou mais. Ele nos salvou e temos conexões mínimas ds3 wan até oc-3.

Você também não mencionou a sua latência. É um componente crítico nos cálculos de replicação.

    

Answer 3

Se suas VMs não tiverem seus arquivos de página em um datastore separado, você deve tentar movê-los para um e, em seguida, medir novamente sua taxa de alteração de dados (rotatividade de dados). Isso definitivamente ajudará. Não replique mais do que você precisa.

O EQL suporta replicação assíncrona contínua ou é orientado por um agendamento de instantâneo? Você pode usar o todo 3Mb 24/7?

Também sigo a sugestão de que você sincronize os arrays antes de colocar um no site remoto.

    

Answer 4

Para se concentrar nas informações mais relevantes, sugiro definir um objetivo para seu ponto de recuperação e tempo de recuperação. Estes são inimaginariamente referidos como um "RPO" e "RTO". A replicação de disco deve reduzir os dois mantendo uma cópia consistente dos dados que nunca são mais antigos que alguns minutos em outro site. Depois de ter esses números, você pode definir coisas como a frequência com que você precisa ter uma réplica consistente de falha. .

3Mb / s provavelmente não cortarão a mostarda a menos que você use aceleração de WAN (como a Riverbed, mencionada por um dos outros respondentes). A aceleração de WAN funciona mantendo um cache no disco em ambos os lados do link, onde eles armazenam todos os dados mais recentes que você enviou, e se você enviar um bloco duplicado, ele envia uma referência em vez dos dados.

Dito isso, supondo que seu armazenamento esteja usando o mesmo mecanismo para obter instantâneos, como é usado para replicar instantâneos, a medida de mudança mais precisa é, na verdade, uma reserva instantânea. Você precisaria manter um instantâneo e sua reserva isolados pela duração do período de medição. Supondo que o EqualLogic use copy em snapshots de gravação, comparar os dados da reserva de vários snapshots tirados ao longo do dia pode realmente fazer parecer que seus dados estão mudando mais do que realmente são.

Quanto aos dados em si, concordo com as respostas que sugerem não replicar os arquivos de troca. Os arquivos de troca podem ter muito disco e estão sempre mudando, o que acionaria muito tráfego de replicação. Não sei se o VMWare suporta a replicação de um ambiente sem eles, embora ... Suponho que as VMs em um armazenamento de dados de uma VM replicadas sem arquivos de permuta seriam compatíveis com falhas, no entanto, não posso confirmar isso.

    

Answer 5

Atualmente, estou no processo de algo semelhante, no entanto, com o Solaris 11 e o zfs como nosso backend de san. Por causa da largura de banda, decidi separar a maioria dos componentes. Nós migramos para o Exchange 2010 para que possamos configurar nosso site dr com uma cópia idêntica. O que eu encontrei foi fazer snapshots de nível de san seria ridículo para esses dados por causa de problemas de largura de banda como você está vendo. Nós decidimos que seria mais barato e mais eficiente configurar um dag e replicar dentro da própria troca. Nós também fizemos a mesma coisa com nossos servidores mysql. O que clonamos agora são sistemas com menos deltas entre os instantâneos. Consegui fazer a sincronização inicial no escritório e transportá-lo até o destino final.

    

Answer 6

O tamanho do bloco é 16 Mo para captura instantânea e replicação em SANs Equallogic. É por isso que você tem esses números astronômicos. Não há como mudar isso. A solução para atendermos ao nosso SLA RTO / RPO foi instalar um dispositivo de otimização de WAN da Riverbed entre os dois sites.