Usando o fantoche para implantar o backup do Windows com o Microsoft iSCSI

Question

Atualmente, começamos a usar a seguinte estratégia para backups do Windows, que estou procurando implantar via fantoche:

O
• Iniciador iSCSI está ativado no servidor do cliente.
• Disco virtual iSCSI + VHD são configurados no servidor de backup, com arquivos VHD espalhados em vários contêineres RAID.
• Também no servidor de backup, um novo destino iSCSI é configurado apontando para esse disco virtual, restrito ao nome DNS ou ao IP do servidor cliente. Um nome de usuário / senha aleatórios estão configurados.
• O iniciador iSCSI no servidor do cliente está configurado para se conectar ao novo destino e o disco virtual é adicionado por meio do gerenciamento de disco.
• Finalmente, o backup do Windows é configurado para apontar para o VHD localmente, para executar o backup.

Eu só comecei a usar o fantoche, e meu principal desafio até agora é que eu devo configurar dois nós separados, em uma ordem específica (por exemplo, o iniciador iSCSI não pode se conectar ao destino antes que ele exista).

Soluções possíveis

Coleção de recursos exportados

Eu tenho procurado uma maneira de fazer isso, e até agora, o padrão de configuração mais adequado que eu posso encontrar é Coleção de recursos exportados . Eu observei alguns exemplos usando o Nagios, e parece que ele exigiria que eu definisse um novo tipo, que é essencialmente código Ruby, para executar ações nos recursos exportados.

Eu gostaria de evitar fazer algo tão avançado assim, embora eu tenha experiência em programação, meus colegas não, e estou tentando mantê-lo o mais simples possível.

Entradas de nó separadas

Uma ideia com a qual estou brincando é que, em vez da complexidade adicional envolvida na tentativa de definir o backup inteiro (servidor de destino e iniciador) do nó cliente, simplesmente defina as duas funções separadas em cada nó.

E para simplificar as coisas, embora a configuração deva ser feita em uma ordem específica para que as coisas funcionem, eu simplesmente confiaria no fantoche para continuar tentando executar a configuração e, eventualmente, todos os pré-requisitos seriam atendidos. (Por exemplo, na primeira vez, o fantoche provavelmente tentaria se conectar ao alvo iSCSI antes de ser criado, mas ao tentar pela segunda vez, o outro nó deveria ter terminado de criar o alvo, então se o fantoche tentasse isso pela segunda vez , deve suceder.)

Algo como:

node 'backup-server' { 
    windows_backup::server::target { 'client01':
        dns_name => 'client01.example.com',
        username => '',
        password => '',
        drive_letter => '',
        drive_size => '',
    },
    windows_backup::server::target { 'client02':
        dns_name => 'client02.example2.com',
        username => '',
        password => '',
        drive_letter => '',
        drive_size => '',
    }
}

Então ...

node 'client01' { 
    windows_backup::client::backup { 'client01':
        username => '',
        password => '',
        drive_letter => '',
}

Mas, como você pode ver, você começa a entrar no território de codificar muitos valores (por exemplo, determinar o tamanho do VHD exigirá que façamos login no servidor e determinemos o tamanho manualmente - enquanto isso pode ser feito automaticamente em potencial). E isso, então, volta a compartilhar automaticamente dados / recursos entre os dois nós envolvidos.

Em algum momento, toda a codificação manual manual não fornece vantagem suficiente (por exemplo, tempo gasto fazendo configuração) para justificar a camada extra de complexidade envolvida no uso do fantoche para implementar isso.

Alguém implantou fluxos de trabalho semelhantes no passado e existem maneiras mais simples de fazer isso?