Meus maravilhosos colegas do departamento de suporte técnico escrevem não apenas dicas e truques prejudiciais, mas também úteis para configurar o Veeam Backup & Replication. Desde a publicação do artigo para usuários iniciantes, sua autora, Evgeny Ivanov, enquanto continua trabalhando com a equipe romena em Bucareste, passou do cargo de engenheiro sênior para a posição de líder da equipe. Mas Eugene não deixou o campo técnico e literário, pelo qual muitos agradecimentos a ele!
O novo artigo de Zhenya contém recomendações para especialistas já experientes do Veeam Backup & Replication que enfrentam a tarefa de aproveitar ao máximo os recursos da infraestrutura de backup. No entanto, o artigo será útil para aqueles que planejam instalar e configurar nosso produto.

Otimização da distribuição de carga em tempos de tubo quente

Para dicas úteis, bem-vindo ao gato.

Sobre as vantagens da instalação distribuída

O Veeam Backup & Replication é um software modular que consiste em vários componentes, cada um deles executando funções específicas. Entre esses componentes estão o diretor-gerente central do servidor de backup Veeam, servidor proxy, repositório, acelerador de WAN e outros. Vários componentes podem ser instalados em uma máquina (é claro, bastante poderosa), o que muitos usuários fazem. No entanto, uma instalação distribuída tem suas vantagens, a saber:

Para empresas com uma rede de filiais, torna-se possível instalar os componentes necessários localmente nessas filiais. Isso ajuda a otimizar o tráfego, organizando a maior parte dele novamente localmente.
À medida que sua infraestrutura cresce, você precisa aumentar sua solução de backup. Se o backup demorar mais (a “janela de backup” está aumentando), você poderá instalar um servidor proxy adicional. Se você precisar aumentar a capacidade do repositório de backup, poderá configurar um repositório de backup em expansão e adicionar novas extensões conforme necessário.
Para alguns componentes, você pode garantir disponibilidade constante (Alta Disponibilidade) - por exemplo, se você tiver vários servidores proxy implantados e um deles for desligado repentinamente, outros continuarão funcionando e o backup não será afetado.

Deve-se ter em mente que os sistemas distribuídos serão eficazes apenas com uma distribuição de carga razoável. Caso contrário, podem ocorrer gargalos, sobrecarga de componentes individuais - e isso é repleto de uma queda geral na produtividade e desaceleração.

Como os dados são transmitidos?

Para ter uma idéia mais clara de onde e onde os dados são transferidos durante o processo de backup, considere este diagrama (por exemplo, use a infraestrutura na plataforma vSphere):

Como você pode ver, os dados são transferidos do local de origem (origem) para o destino (destino) usando os "agentes de transporte" (VeeamAgent.exe) trabalhando nos dois locais. Portanto, quando a tarefa de backup está em execução, acontece o seguinte:

O agente de transporte "origem" é executado em um servidor proxy; ele lê dados de um armazenamento de dados, executa compactação e desduplicação e envia os dados neste formulário ao agente de transporte "alvo".
O agente de transporte "destino" é executado diretamente no repositório (Windows / Linux) ou no gateway (servidor de gateway), se o compartilhamento CIFS for usado. Esse agente, por sua vez, também realiza a desduplicação de lado e salva os dados em um arquivo de backup (.VBK, .VIB, etc.).

Assim, 2 componentes estão sempre envolvidos na transmissão de dados, mesmo que estejam realmente localizados na mesma máquina. Isso deve ser considerado ao planejar uma implantação de solução.

Balanceamento de carga entre servidor proxy e repositório

Primeiro, vamos definir o conceito de "tarefa". Na terminologia do Veeam Backup & Replication, cada tarefa está processando um disco de uma máquina virtual. Ou seja, se você tiver uma tarefa de backup (tarefa), que inclui 5 VMs com 2 discos cada, isso significa que é necessário processar 10 tarefas (e se a máquina tiver apenas 1 disco, 1 tarefa = 1 VM). O Veeam Backup & Replication é capaz de processar várias tarefas em paralelo, mas seu número, é claro, não é infinito.

Para cada servidor proxy em suas propriedades, você pode especificar o número máximo de tarefas para execução paralela:

Para operações de backup padrão, a mesma interpretação será para o repositório: uma tarefa é transferir dados de um disco virtual. Na interface, parece muito semelhante:

Aqui, precisamos corrigir uma regra muito importante número 1: certifique-se de equilibrar ao atribuir recursos de proxy e repositório e ao especificar o número máximo de tarefas para processamento paralelo!

Exemplo

Suponha que você tenha 3 proxies, cada um dos quais pode processar 4 tarefas em paralelo (ou seja, um total de 12 discos virtuais das VMs de origem). Mas o repositório está configurado para processar apenas 4 tarefas em paralelo (esse, a propósito, é o valor padrão). Com essas configurações, apenas 4 unidades serão salvas em paralelo do local de origem até o destino, embora possam ser para todos os 12. Ou seja, os recursos serão sobrecarregados.

No entanto, quando se trata de criar um backup completo sintético (e operações similares), o conceito de uma tarefa relativa ao repositório assume um significado ligeiramente diferente. Lembramos que essas operações não envolvem proxies, mas são executadas localmente no repositório (Windows ou Linux) ou (no caso de compartilhamento CIFS) usando um gateway.

Nesta opção, ao criar uma cadeia de backup normal, task = tarefa de backup. Ou seja, um limite de 4 tarefas para processamento paralelo aqui significa que os backups sintéticos para 4 tarefas de backup podem ser criados simultaneamente no repositório.

Ao criar uma cadeia de backups decompostos de acordo com as VMs originais (o chamado "armazenamento por armazenamento" - por VM), a tarefa = 1 VM. Ou seja, um limite de 4 tarefas para processamento paralelo aqui significa que 4 arquivos VBK para 4 máquinas virtuais podem ser gerados no repositório ao mesmo tempo.

Portanto, chegamos à regra nº 2: dependendo das configurações de backup, o mesmo número de tarefas pode significar uma carga completamente diferente no repositório. Portanto, ao planejar recursos, você definitivamente precisa verificar as mesmas configurações: modo de backup, agendamento de tarefas, maneira de organizar cadeias de backup.

Nota: Ao contrário das configurações de proxy, o repositório pode desativar o limite do número de tarefas. Nesse caso, o repositório aceitará todos os dados provenientes de servidores proxy. Mas isso é apenas uma aparente liberdade de restrições, pois existe o risco de sobrecarga do repositório e falhas no trabalho das tarefas de backup. Portanto, não recomendamos renunciar a esse limite.

Outro exemplo

Suponha que você tenha uma tarefa de backup que inclua um número bastante grande de VMs com um total de 100 discos virtuais. Ao mesmo tempo, o repositório está configurado para armazenar cadeias de backup "manualmente" (por VM). As configurações de processamento paralelo são as seguintes: para um proxy - 10 discos por vez e para um repositório - não há restrições. Durante um backup incremental, a carga no repositório será limitada devido às configurações de proxy e, portanto, o saldo será mantido. Mas então chega o momento de criar um backup completo sintético. Esse backup não usa um proxy e todas as operações para criar “sintéticos” ocorrem exclusivamente no repositório. Como não há restrição no processamento paralelo de tarefas para o repositório, o servidor do repositório tentará processar centenas inteiras de cada vez. Isso exigirá um estresse significativo dos recursos e provavelmente levará à sobrecarga.

Recursos do uso do compartilhamento CIFS como repositório

Se você trabalha com um repositório baseado em um servidor Windows ou Linux, o agente "target" inicia diretamente neste servidor. No entanto, se você usar a pasta de compartilhamento CIFS (compartilhamento CIFS) como um repositório, o agente "alvo" será iniciado em uma máquina especialmente projetada para essa finalidade - esse é o chamado “Gateway”, que receberá o fluxo de dados de entrada do agente no lado da VM de origem. O agente "alvo" receberá esses dados e enviará os blocos de dados para a bola do CIFS. Essa máquina auxiliar deve ser colocada o mais próximo possível da máquina que fornece as pastas compartilhadas SMB - isso é especialmente importante para scripts que usam conectividade WAN.

Regra número 3: você não deve colocar a máquina auxiliar (proxy \ gateway) em um site e o CIFS compartilhará a pasta compartilhada em outro site (inclusive na nuvem) - caso contrário, haverá constantes problemas de rede.

Você também pode aplicar aos gateways todas as considerações acima sobre o balanceamento da carga no sistema. Além disso, você deve ter em mente que o gateway possui 2 configurações adicionais: o servidor pode ser atribuído a ele selecionado de forma explícita ou automática:

Em princípio, qualquer servidor Windows incluído na infraestrutura de backup da Veeam pode ser usado como um gateway. Dependendo do seu cenário de implantação, uma das opções pode ser adequada para você:

Um servidor especificado explicitamente - isso obviamente simplifica muito, porque você saberá exatamente em qual máquina o agente "alvo" está executando. Essa opção é recomendada, especialmente, para casos em que o acesso à bola é permitido apenas a partir de determinados servidores, bem como para cenários com uma infraestrutura distribuída - você provavelmente deseja usar o agente em uma máquina localizada perto do servidor de arquivos com o objetivo como pessoas razoáveis a bola
Servidor selecionado automaticamente (opção de seleção automática ). Aqui, as coisas tomam um rumo interessante: se você usa vários servidores proxy, a escolha dessa opção leva ao fato de que o programa usa mais de um gateway, distribuindo a carga. Observo que “automaticamente” não significa “arbitrariamente” - regras de seleção bastante específicas são aplicadas aqui.

Como isso funciona?

O agente "alvo" inicia no servidor proxy que está executando o backup.

No caso da cadeia de backup usual, a lógica é a seguinte: se houver várias tarefas executadas simultaneamente, cada uma com seu próprio servidor proxy, você poderá executar vários agentes "de destino". No entanto, dentro de um trabalho, a lógica é diferente: mesmo se as VMs contidas nele forem processadas por proxies diferentes, o agente “alvo” será iniciado apenas em um - no que começará a funcionar primeiro.
No caso de uma cadeia de backup em "cadeia", um agente de "destino" separado é iniciado para cada VM. Assim, mesmo dentro da mesma tarefa, ocorre a distribuição de carga.

Ao criar backups sintéticos, os servidores proxy não são usados e, aqui, a máquina para iniciar o agente "destino" é selecionada da seguinte maneira: usamos um servidor de montagem auxiliar (servidor de montagem no qual os arquivos são montados, por exemplo, durante operações de recuperação) associados ao repositório e em inicia o agente. Se o servidor de montagem não estiver disponível por algum motivo, é possível alternar para o norte do backup da Veeam. Como você entende, não haverá distribuição de carga nesta versão.

Portanto, repito: ( IMPORTANTE! ) Não é recomendável que esses cenários removam o limite do número de tarefas processadas em paralelo, porque ao executar operações com "sintéticos", isso pode levar a uma enorme sobrecarga do servidor de montagem ou mesmo do servidor de backup Veeam.

Recursos adicionais

Repositório escalável. SOBR é um conjunto de repositórios padrão (aqui eles são chamados de "extensões"). Se você já usa SOBR, na tarefa de backup, especifique-o, e não a extensão. Em certa medida, você pode usar algumas configurações, por exemplo, balanceamento de carga.

Todos os princípios básicos que funcionam para repositórios regulares também funcionam para SOBR. Para otimizar o uso de recursos, é aconselhável configurar o SOBR com armazenamento de backup de backup (por VM - esta é a opção padrão), com a política de alocação de "Desempenho" ("otimizar para melhor desempenho") e distribuir em cadeia pelos repositórios-extensão-s.

Transferência de backups (cópia de backup). Aqui, os agentes "source" funcionarão no repositório de origem. Tudo o que foi mencionado acima também é aplicável aos repositórios de origem (exceto no caso de um trabalho de transferência de Trabalho de Cópia de Backup, operações com “sintéticos” não são executadas no repositório de origem).

Nota: Se o repositório de origem for um compartilhamento CIFS, o agente "source" será iniciado no servidor de montagem apropriado (com a capacidade de alternar para o servidor de backup Veeam).

Dispositivos com desduplicação interna. Para os sistemas de armazenamento DataDomain e StoreOnce (e provavelmente para outros no futuro), para os quais a integração com a Veeam está configurada, as mesmas considerações se aplicam ao compartilhamento CIFS. Para um repositório no StoreOnce com desduplicação no lado da fonte (modo Baixa largura de banda ), apenas o requisito de colocar o gateway o mais próximo possível do repositório está perdendo relevância - o gateway em um site pode ser configurado para enviar dados para o StoreOnce em outro site via WAN.

Servidor proxy preferido. Esse recurso apareceu, como você se lembra, na liberação 9.5 e é responsável por manter a "lista de prioridades de proxy" à qual o programa aderirá ao trabalhar com um repositório específico.

Se o proxy desta lista não estiver disponível, a tarefa funcionará com qualquer outro disponível. No entanto, se houver acesso ao proxy, mas o servidor proxy não tiver slots livres para processar a tarefa, a tarefa de backup será suspensa enquanto os estiver pendentes. Portanto, você precisa usar esse recurso com muito cuidado (e não no estilo "ativado e esquecido") - tivemos usuários que, assim, desligaram as tarefas de backup. Você pode ler mais sobre o recurso aqui (em inglês).

Em conclusão

Não importa se você instala o Veeam Backup & Replication pela primeira vez ou se é um usuário antigo - quero acreditar que neste artigo você encontrará informações úteis para você e com sua ajuda para otimizar a operação da infraestrutura de backup ou até eliminar os riscos potenciais de perda de dados. Aqui estão alguns links mais úteis:

Otimize o balanceamento de carga na infraestrutura Veeam Backup & Replication