可能的解决方案

2024-5-29 • tag-icon

我们目前已开始使用以下策略进行 Windows 备份，我希望通过 puppet 进行部署：

客户端服务器上已启用 iSCSI 发起程序。
备份服务器上配置了 iSCSI 虚拟磁盘 + VHD，VHD 文件分布在众多 RAID 容器中。
此外，在备份服务器上，配置了指向此虚拟磁盘的新 iSCSI 目标，限制为客户端服务器的 DNS 名称或 IP。配置了随机用户名/密码。
客户端服务器上的 iSCSI 启动器配置为连接到新目标，并通过磁盘管理添加虚拟磁盘。
最后，将 Windows 备份配置为本地指向 VHD，以执行备份。

我才刚刚开始使用 puppet，到目前为止，我面临的主要挑战是必须按照特定顺序配置两个独立的节点（例如，iSCSI 启动器无法在目标存在之前连接到它）。

可能的解决方案

导出资源集合

我一直在寻找一种方法来做到这一点，到目前为止，我能找到的最合适的配置模式是导出资源集合。我查看了一些使用 Nagios 的示例，似乎需要我定义一种新类型（本质上是 Ruby 代码），才能对导出的资源执行操作。

我希望避免这么快就做一些这么高级的事情，因为虽然我有编程经验，但我的同事没有，而且我试图让它尽可能简单。

单独的节点条目

我正在考虑的一个想法是，不要尝试从客户端节点定义整个备份（目标服务器和启动器），而只需在每个节点中定义两个独立的角色。

然后为了简化事情，尽管配置应该按照特定的顺序进行才能正常工作，但我只会依靠 puppet 继续尝试运行配置，最终所有先决条件都会得到满足。（例如，第一次，puppet 可能会在创建 iSCSI 目标之前尝试连接到它，但第二次尝试时，另一个节点应该已经完成创建目标，因此如果 puppet 第二次尝试，它应该会成功。）

就像是：

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 的大小将需要我们登录到服务器并手动确定大小 —— 而这可以自动完成）。然后理想情况下，这又回到了在所涉及的两个节点之间自动共享数据/资源。

在某些时候，所有的手动硬编码都没有足够的优势（例如，花在配置上的时间）来证明使用 puppet 部署所涉及的额外复杂性是合理的。

以前有人部署过类似的工作流程吗？有没有更简单的方法来做到这一点？

可能的解决方案

相关内容