Continuamos o tópico, que começou a ser considerado na
primeira parte . Hoje falaremos sobre conexões de rede e servidores de destino, apresentaremos possíveis opções e opções de planejamento de infraestrutura para uma recuperação ideal do Instant VM Recovery. Bem-vindo ao gato.
Sobre conexões de rede
Obviamente, é bom ter um canal com largura de banda de 10 Gbit / s, através do qual os dados são transferidos durante o backup. No entanto, o canal é mais modesto para restaurar a partir de um backup, mas é recomendável usar a equipe da NIC com o LACP ou o SMB Multicanal, ou alguma outra opção com agregação de largura de banda. Você pode usar, por exemplo, portas LOM na versão 4x1 Gbit / s. Essa configuração é recomendada para a conexão “vários dispositivos de origem - 1 dispositivo de backup de destino”, ou seja, ao conectar “muitos para um”. (Da mesma forma, a recuperação paralela de um armazenamento de backup para os dispositivos de destino - como regra, esses são os mesmos iniciais em que os backups foram executados - é uma conexão um para muitos.)
Por exemplo, você pode configurar várias tarefas de backup de vários hosts Hyper-V / LUNs e salvar backups no mesmo armazenamento de destino. Se você possui 10 hosts com uma largura de banda total de canal de 4x1 Gbit / s, se possui um canal de 10 Gbit / s no dispositivo de destino, essa é uma configuração bastante adequada.
No caso em que o armazenamento de backup é compartilhamento SMB, o multicanal funciona muito bem (ele pode ser complementado pelo SMB Direct se você tiver NICs com suporte a RDMA configurado). Esses recursos agora são suportados em muitas implantações de cluster do Hyper-V. No entanto, o componente da solução Veeam responsável pelo movedor de dados pode usar o SMB Multichannel e o SMB Direct (novamente, com NICs configuradas com suporte a RDMA) apenas no cenário em que você usa VMs armazenadas no compartilhamento de arquivos SMB para fazer backup. proxy fora do host. Esses Veeam Data Movers funcionam respectivamente no proxy de backup off-host e no repositório. Esse cenário é descrito em detalhes
aqui .
Outro ponto importante: ao usar a equipe da NIC do Windows no
modo independente Switch , é permitida a transferência de dados de todos os participantes e o recebimento de apenas um. Se você deseja obter a taxa de transferência ideal nas duas direções para um processo, não é necessário usar o LACP. Mas, neste caso, você precisa garantir que várias restaurações sejam feitas no mesmo host.
Como você pode ver, a agregação de largura de banda traz várias limitações e não é completamente idêntica a ter um bom canal. De qualquer forma, você precisa aproveitar os cenários de uso planejado.
Resumindo: dependendo da sua infraestrutura, você pode usar a equipe da NIC do Windows no modo LACP ou no modo Alternar Independente / SMB Multicanal. A última opção é útil se você estiver trabalhando com o compartilhamento de arquivos SMB e quiser usar o SMB Direct (não se esqueça dos recursos do trabalho mencionado acima).
É necessária alta largura de banda e baixa latência para fornecer o melhor desempenho durante a montagem de discos virtuais, ao acessar e copiar dados durante a Recuperação Instantânea da VM.
Você pode executar várias operações de recuperação ao mesmo tempo e ainda não interromper as tarefas de backup. Ou seja, novamente, na presença de um canal decente, o principal papel é desempenhado pelo recurso e armazenamento de computação. Se tudo isso for projetado corretamente para backup, a recuperação será efetiva.
Recomendações para dispositivos de destino
Considere várias opções, das quais, possivelmente, você escolherá o melhor para si.
Opção 1: recuperar para hosts Hyper-V e diretamente para o LUN na infraestrutura de produção
Mesmo se você tiver um sistema de armazenamento de alto desempenho com armazenamento em cache de leitura / gravação ou o nível 1 estiver configurado, então, conforme mencionado
em uma postagem anterior , tenha cuidado para não estourar. Caso contrário, as VMs de produção serão afetadas. E isso pode acontecer, por exemplo, se você tentar gravar grandes quantidades de dados no sistema de armazenamento o mais rápido possível - isso acontece ao migrar sistemas de armazenamento. Nessas operações, tentamos evitar o uso de sistemas de armazenamento de nível 1. Considerações semelhantes se aplicam à restauração de grandes VMs.
Você pode recomendar a recuperação para separar LUNs com perfis diferentes. VMs restauradas podem ser migradas lentamente para CSVs de produção. Para garantir alta disponibilidade, você pode usar o cluster usando a migração ao vivo do Storage (funcionalidade de migração de armazenamento “ao vivo”). Naturalmente, você precisa se concentrar no desempenho da sua matriz de armazenamento.
Opção 2: recuperação para hosts Hyper-V com unidades SSD / NMVe locais
Outro cenário de recuperação em produção, bastante eficaz: usar o host Hyper-V do armazenamento local para SSD ou NVMe. O tamanho do espaço em disco depende de quantas VMs você deseja recuperar em um determinado período de tempo e do tamanho dessas VMs.
Em teoria, é improvável que você precise restaurar tudo e todos, portanto essa configuração deve ter um custo bastante econômico. Por exemplo, você pode usar um SSD em cada um dos nós do cluster, ou apenas em alguns, ou em geral apenas em um. Quanto mais SSD / NVMe você usar, mais orçamento eles terão, mantendo uma distribuição de carga bastante eficiente entre os hosts. No estágio final do procedimento de recuperação instantânea, as máquinas virtuais podem ser facilmente transferidas para CSVs de produção, usando a mesma funcionalidade de migração ao vivo do Storage.
O diagrama mostra uma opção de planejamento de infraestrutura. Obviamente, você pode combinar as abordagens acima a seu critério.
Opção 3: recuperar para hosts Hyper-V dedicados com unidades SSD / NVMe locais
Nesta opção, alocamos um ou mais hosts especificamente para dar suporte à recuperação. Isso evita uma possível falta de recursos e o impacto na operação dos hosts de produção no cluster. Você pode usar unidades NVMe. Recomendamos que você teste os recursos de recuperação nesta configuração com antecedência para entender como os recursos estão acabando.
Se você planeja aumentar o consumo deles, para a migração final de máquinas recondicionadas para a produção, é possível usar a chamada migração sem compartilhar recursos Migração compartilhada com nada ao vivo. (Para isso, é necessário definir configurações de segurança adicionais.) Quanto aos recursos de rede, você pode usar, por exemplo, os recursos SMB Multicanal e SMB Direct para migração para CSV / Live Migration / S2D Hyper-V.
Sim, a migração dos sistemas de armazenamento (migração ao vivo do Storage) não é o processo mais rápido, é um sinal de menos. Mas há uma vantagem - suas máquinas virtuais são restauradas e continuam a trabalhar durante esse processo.
Em conclusão
Obviamente, todo mundo escolhe as opções preferidas, dependendo de qual é o gargalo em uma infraestrutura específica (servidor de origem, servidor de destino, recursos de rede). Além disso, é bem possível que um estudo cuidadoso seja necessário apenas para planejar a recuperação das VMs mais críticas ou para os consumidores que pagam por esse serviço.
De qualquer forma, o objetivo principal sempre será a recuperação mais rápida possível.
Depois disso, já é possível migrar com segurança para o sistema de armazenamento em cluster, garantindo alta disponibilidade e tolerância a falhas. E, é claro, as máquinas virtuais devem ser protegidas na forma de backup \ replicação, caso precisem ser restauradas novamente em algum momento.
O que mais se pode ler: