В настоящее время мы начали использовать следующую стратегию для резервного копирования Windows, которую я собираюсь развернуть с помощью марионетки:

• Инициатор iSCSI включен на клиентском сервере.
• Виртуальный диск iSCSI + VHD настраиваются на сервере резервного копирования, а файлы VHD распределены по многочисленным контейнерам RAID.
• Также на резервном сервере настроена новая цель iSCSI, указывающая на этот виртуальный диск, ограниченная DNS-именем или IP-адресом клиентского сервера. Настраивается случайное имя пользователя / пароль.
• Инициатор iSCSI на клиентском сервере настроен для подключения к новой цели, и виртуальный диск добавляется через управление дисками.
• Наконец, резервное копирование Windows настроено так, чтобы указывать на VHD локально для выполнения резервного копирования.

Я только начал использовать марионетку, и моя основная проблема до сих пор заключается в том, что я должен настроить два отдельных узла в определенном порядке (например, инициатор iSCSI не может подключиться к цели, пока она не существует).

Возможные решения

Экспортированная коллекция ресурсов

Я искал способ сделать это, и пока что наиболее подходящий шаблон конфигурации, который я могу найти, это Экспортированная коллекция ресурсов. Я просмотрел несколько примеров использования Nagios, и мне кажется, что мне потребуется определить новый тип, который по сути является кодом Ruby, чтобы выполнять действия с экспортированными ресурсами.

Я бы не хотел сразу делать что-то настолько сложное, хотя у меня есть опыт программирования, а у моих коллег - нет, и я стараюсь сделать это как можно проще.

Отдельные записи узлов

Одна идея, с которой я работаю, заключается в том, что вместо дополнительной сложности, связанной с попыткой определить всю резервную копию (целевой сервер и инициатор) с клиентского узла, просто определите две отдельные роли в каждом узле.

А затем, чтобы упростить ситуацию, хотя для того, чтобы все работало, конфигурация должна выполняться в определенном порядке, я бы просто полагался на марионетку, чтобы продолжать попытки запустить конфигурацию, и в конечном итоге все предварительные условия будут выполнены. (Например, в первый раз марионетка, возможно, попытается подключиться к цели iSCSI до ее создания, но после второй попытки другой узел должен завершить создание цели, поэтому, если марионетка попытается это сделать во второй раз , должно получиться.)

Что-то вроде:

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 => '',
    }
}

Затем...

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

Но затем, как вы можете видеть, вы начинаете попадать на территорию жесткого кодирования слишком большого количества значений (например, определение размера VHD потребует от нас входа на сервер и определения размера вручную - тогда как это может быть возможно, выполняется автоматически). И это затем возвращается к идеальному автоматическому обмену данными / ресурсами между двумя задействованными узлами.

В какой-то момент все ручное жесткое кодирование не дает достаточных преимуществ (например, времени, затраченного на настройку), чтобы оправдать дополнительный уровень сложности, связанный с использованием марионетки для ее развертывания.

Развертывал ли кто-нибудь подобные рабочие процессы в прошлом, и есть ли более простые способы сделать это?