虚拟机粒度的灾难恢复存在哪些挑战？

作者：Stuart Burns 2017-09-27 08:15:14

存储

虚拟化服务器在没有正确的授权或成本分配的情况下进行配置，这将导致虚拟机（VM）的蔓延。让VM蔓延变得尤其令人讨厌的是，这些蔓延的生产机器经常遇到配置问题。正如他们所说，这些规则是有原因的，例如，为了捕获需要特殊处理的部署，例如虚拟机灾难恢复和VM的依赖关系。

虽然虚拟机灾难恢复与物理DR实践相比，是一个游戏规则的改变者，但它往往是缓慢而不灵活的，而且存在潜在的缺点。良好的DR不是凭空发生的，它必须得到有效的计划、管理和适当的测试。虽然手动捕获设置、配置和管理虚拟DR所需的数据和细节，对于小环境来说可能很简单，但这种方法的伸缩性并不好。

服务器在没有正确的授权或成本分配的情况下进行配置，这将导致虚拟机（VM）的蔓延。让VM蔓延变得尤其令人讨厌的是，这些蔓延的生产机器经常遇到配置问题。正如他们所说，这些规则是有原因的，例如，为了捕获需要特殊处理的部署，例如虚拟机灾难恢复和VM的依赖关系。

[[205056]]

在正常配置期间，捕获需求和所有权数据不是问题。在配置过程之外执行时，在虚拟机灾难恢复情况甚至日常支持中所需的大量关键信息尚未被正确收集和存储，这使得这两个任务更加困难。

妥善保护生产虚拟机

更糟糕的是，VM或服务可能没有DR测试计划或管理员。管理员经常会发现，生产机器并不是支持DR的。文档和DR设置可能没有发生。

如果DR管理器不知道这些机器，那么在真正的DR场景发生之前，问题才会显现。企业集团或所有者可能认为虚拟机灾难恢复已经启用，但事实并未启用，这不仅可能导致对提供商的信心丧失，而且会造成严重的财务损失。

大公司在通信方面是出了名的差，这就是为什么每个生产虚拟机都应该进行全面的生产部署。出于这个原因，用户验收测试和开发VM不应该被重新用于生产虚拟机。

在正确的部署过程中，应该在这些问题变得至关重要之前抓住它们。正确地做到这一点也意味着所有者已经正确地注意到，成本是分摊的，并且虚拟机有一连串的指挥和决策。

这些都是虚拟机灾难恢复实际上不需要做的事情。按照预定的间隔，根据DR计划检查和交叉引用VM是符合业务的利益的。并不是每个机器都有DR计划，但是这样做会使得这些流氓机器能够根据需要进行识别和修复。