Muitas tecnologias de replicação de dados no ambiente

Question

É possível configurar a replicação de dados remotos em várias camadas da pilha de armazenamento. Alguns exemplos para explicar o que quero dizer com camadas:

• Camada de volume físico (TruCopy, SRDF / MirrorView, SnapMirror)
• Camada de servidor virtual (vReplicator, Veeam)
• Camada de volume lógico (VVR, AVS)
• Camada do sistema de arquivos (Rsync, envio / recebimento do ZFS)
• Camada de Aplicação (Data Guard, MySQL / Replicação PostgreSQL, Replicação do AD)

A replicação em cada camada tem uma proposição de valor única, mas seria loucura usá-las todas. Meu problema particular é a proliferação de diferentes soluções; Gostaria de padronizar uma ou duas soluções para reduzir os custos de licença, a complexidade e os requisitos de especialização.

A minha pergunta é: ignorando os exemplos de produtos individuais, qual camada ou combinação de camadas de replicação fornece o maior valor em um ambiente corporativo típico e quais estão se tornando mais valiosas?

Possíveis métricas incluem facilidade de administração, disponibilidade de experiência, proteção contra corrupção de dados, tempo / complexidade de recuperação em um cenário de DR, redução de janelas de interrupções planejadas, desempenho de aplicativos, flexibilidade de aplicativos e qualquer outra coisa que possa ser valiosa. p>

Esta é uma pergunta que encontro frequentemente como administrador do sistema, por isso gostaria de receber alguns conselhos.

    

Answer 1

Qual solução é mais adequada para um determinado cenário depende strongmente dos aplicativos e dados envolvidos, não há uma abordagem "global" que possa funcionar sempre, em qualquer lugar.

Existem muitos cenários diferentes envolvidos. Alguns exemplos:

• Os controladores de domínio do Active Directory são projetados para funcionar como um banco de dados distribuído, multi-mestre e replicado; e você também precisa ter DCs locais em uma configuração WAN, porque as máquinas Windows associadas ao domínio precisam ter um DC disponível para funcionar corretamente. Ao mesmo tempo, com o AD você não se beneficiaria de ter uma replicação de nível inferior, na camada do servidor virtual ou na camada de armazenamento físico, já que você não pode ter um controlador de domínio. mount "um banco de dados copiado de outro, e você não pode iniciar um CD clonado e esperar que ele funcione (nem tente fazer isso, a reversão do USN é desagradável ).
• Para um servidor de arquivos, o oposto é verdadeiro: embora existam tecnologias de replicação em nível de aplicativo (DFS no Windows), para grandes quantidades de dados, uma replicação em nível de armazenamento é provavelmente a melhor abordagem .
• Agora, digamos que você esteja usando o Exchange; sistemas Exchange recentes (2007-2010) são projetados com a replicação de banco de dados transacional em mente, e essa é a única abordagem oficialmente suportada; você realmente pode copiar um banco de dados do Exchange e montá-lo em outro servidor do Exchange (chamado de "portabilidade do banco de dados"), para que a replicação em nível de armazenamento possa funcionar ... mas é muito mais doloroso, e mover os usuários para tal servidor requer uma reconfiguração pesada. Além disso, embora nos dois cenários mencionados acima, realmente é um ponto em ter cópias locais dos dados em vários locais (o AD é necessário em todos os lugares e os usuários em diferentes escritórios podem precisar acessar os mesmos dados do servidor de arquivos ), para o Exchange, isso só faz sentido em um cenário de recuperação de desastre, porque, em operação normal, cada usuário acessa apenas sua própria caixa de correio, que só pode estar ativa em um único servidor por vez.
• Para vários sistemas de banco de dados, isso pode funcionar tanto no nível do aplicativo quanto em qualquer nível subjacente; mas isso depende muito do aplicativo: se você precisar modificar dados em vários locais (em vez de apenas lê-los), não há como a replicação de armazenamento mesclar cópias conflitantes, e você precisará permitir que o DBMS lide com isso.

Cada tecnologia tem seus próprios benefícios e casos de uso; realmente não existe uma abordagem "tamanho único".

    

Answer 2

Até agora, considerei duas opções. A idéia mais abrangente de ambos é atribuir a responsabilidade pela replicação a apenas uma equipe: os administradores do sistema ou os administradores do aplicativo. Com apenas uma equipe envolvida, você diminui a complexidade do sistema e o risco.

Padronizar na replicação de camada de servidor virtual

Configurando a replicação somente na camada do servidor virtual, você pode tratar o sistema operacional e quaisquer aplicativos executados como uma caixa preta. Os administradores do sistema estão no controle.

Vantagens:

• O procedimento de DR para todos os aplicativos é idêntico: interrompa a replicação, inicie os servidores virtuais de DR e peça às diferentes equipes de aplicativos para confirmar se tudo está bem.
• É fácil confirmar que você tem cobertura completa de todos os dados.
• É fácil planejar a manutenção do servidor / armazenamento porque o envolvimento das equipes de aplicativos é mínimo.

Desvantagens:

• Os servidores de DR estão inativos a maior parte do tempo: um possível desperdício de recursos do servidor.
• Pode ser difícil testar o DR sem um failover completo, pois os endereços IP correspondem ao Prod.
• A replicação é imediata, portanto, se houver corrupção de dados no Prod, ela será propagada imediatamente para o DR.
• Pode ser difícil usar esse método para clonar em Dev / Test.
• Não pode ser usado com sistemas que não funcionam bem em uma VM.

Pode ser usado em combinação com tecnologias de camada de volume físico para melhorar o desempenho da replicação (enquanto ainda está sendo gerenciado a partir do software da VM).

Padronizar na replicação da camada de aplicativo

Ao configurar a replicação apenas na camada de aplicativo, você pode tratar o servidor, o armazenamento e o sistema operacional como uma caixa preta. Os administradores do aplicativo estão no controle.

Vantagens:

• Muitos aplicativos podem ser executados em um modo multi-mestre ou mestre-escravo para aproveitar todos os recursos do servidor.
• Muitos aplicativos podem transmitir alterações em um formato conciso, economizando largura de banda e melhorando o desempenho.
• Alguns aplicativos podem atrasar a aplicação de alterações para evitar que a corrupção seja propagada imediatamente no DR.
• É relativamente fácil separar a replicação e reconfigurar servidores como Dev / Test.

Desvantagens:

• Cada equipe de aplicativos deve configurar a replicação de maneira exclusiva.
• Nem todos os aplicativos suportam esse tipo de replicação, portanto, é necessário que haja uma opção de fall-back.

Pode ser usado em combinação com tecnologias de camada de sistema de arquivos para suportar aplicativos sem a capacidade de replicar.