通过网络隔离克隆虚拟机

虚拟实验室管理是软件开发生命周期中的新兴领域。 Visual Studio 实验室管理是 Visual Studio 中的一款产品,它可向开发人员和测试人员提供虚拟实验室管理。 通过使用 Visual Studio 实验室管理,开发团队可以在开发和测试实验室中使用虚拟化技术,以便通过虚拟机构成复杂的多层环境。 然后,它们可以在这些环境上部署应用程序生成并运行测试。

在开发和测试实验室中使用虚拟化的动机之一是,你只需复制少量文件便可创建已部署虚拟机的相同副本(或克隆)。 克隆在许多方案中十分有用。 例如,如果开发人员需要测试人员环境的副本以重现某个问题,则可以创建该环境的克隆。 在测试团队中,每个单独的测试人员可以克隆环境的副本,然后将他或她的测试工作与团队其他成员相整合。 克隆为开发人员和测试人员双方都节省了时间,因为他们不需要在他们创建的每个环境中重复安装操作系统和其他软件。

要求

  • Visual Studio 旗舰版, Visual Studio 高级专业版, Visual Studio 专业测试工具版

尽管克隆虚拟环境很简单,但是你需要考虑一些克隆的后果。 克隆的环境中的计算机具有与原始环境中的计算机相同的计算机名称。 在某些情况下,它们甚至可以具有相同的 IP 地址和 MAC 地址。 这可能导致其中一个克隆丢失网络连接,或者以一个克隆为目标的网络通信传输到另一个克隆。 最终可能产生的意外后果是,你将应用程序部署到特定克隆而对另一个克隆执行测试。

备注

你只能对 SCVMM 环境使用网络隔离。此功能对标准环境不可用。

Visual Studio 实验室管理解决了这些问题,并通过称为网络隔离的技术促进了虚拟环境的安全克隆。 本主题讨论网络隔离的工作原理,并比较使用网络隔离的克隆和不使用网络隔离的克隆。 第一个示例讨论在没有网络隔离时克隆之间可能发生的冲突的各种形式。 后续示例将检查通过使用 Visual Studio 实验室管理防止冲突的多个解决方案。

网络冲突

图 1 显示你可以使用实验室环境创建的典型虚拟环境。 此环境(称为原始环境)有两个虚拟机:web-server 和 db-server。 这些计算机在 3 层 Web 应用程序中分别充当 Web 和数据库服务器的角色。 在此示例中,我们假设开发团队的一个成员创建了此环境,并且将他们的 Web 应用程序最新版本部署到此环境。 我们还假设,在部署该版本后,在此环境上拍摄了称为“最新版本”的快照。 快照是环境在某个时间点的状态。 你可以随时还原到这个已保存的状态或从其恢复执行。 此图显示原始环境中两个虚拟机的计算机名称、IP 地址和 MAC 地址。

原始环境

原始主机中的 VM“web-server”和“db-server”。

除了原始环境之外,图 2 还显示了克隆环境。 克隆后,当两个环境都启动时,可能发生以下类型的网络冲突:

  1. 计算机名称冲突

  2. IP 地址冲突

  3. MAC 地址冲突

公用网络上的原始和克隆环境

包含名称冲突的克隆 VM 的两台主机

每个上述冲突的具体结果取决于多个因素:虚拟机中的操作系统、实验室中的网络基础结构等。 在图 2 中,我们已假设在原始环境的每个虚拟机中已配置静态 IP 地址和静态 MAC 地址。 因此,当克隆此环境时,克隆的虚拟机具有相同的 IP 和 MAC 地址。

计算机名称冲突

计算机名称是由用户分配的友好名称,用于标识网络中的计算机。 两个协议通常用于将计算机名称解析为其 IP 地址:NetBIOS 和域名服务器 (DNS)。 当两个具有相同计算机名称的计算机在同一个网络段中启动时,NetBIOS 检测名称冲突并警告用户。 通常,仅当计算机位于同一个网络段时,NetBIOS 才可检测冲突。 如果计算机不在同一个网络段上或者警告被忽略,那么 DNS 中将发生下一级别的冲突。 DNS 是供计算机注册其名称的中央存储库。 当两个具有相同计算机名称的计算机尝试在 DNS 中注册时,第二个计算机可能覆盖由第一个计算机创建的条目。 在此情况下,第一个启动的计算机无法通过相同的名称解析进行访问。

可使用简单的方法避免或解决计算机名称冲突。 你可以在创建时使用称为 sysprep 的机制自定义每个克隆,而不是创建环境的相同副本。 Sysprep 是 Windows 操作系统的一部分。 当你使用 sysprep 克隆环境时,环境的每个虚拟机都会获得与原始环境中不同的唯一计算机名称、IP 地址和 MAC 地址。 但是,这些克隆不再完全相同。

每个克隆具有唯一计算机名称的影响(无论通过 sysprep 还是通过用户的手动干预来避免冲突)取决于安装在虚拟机中的软件。 若要理解此内容,请查看示例。 当应用程序已部署在环境上时,Web 服务器上将创建 web.config 文件。 在此文件中,我们已将计算机名称 db-server 配置为连接字符串的一部分。 此处显示该文件的代码片段:

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server"/>
  </appSettings>
</configuration>

当我们更改克隆环境中的数据库服务器的计算机名称时,我们还必须手动按以下方式更改 web.config 文件以使用新名称(db-server2 是提供给克隆环境中的虚拟机的新计算机名称)。

<?xml version="1.0"?>
<configuration>
  <appSettings>
    <add key="ConnectionString" 
      value="Persist Security Info=True;User ID=dbuser;  
        Password=password;Initial Catalog=Store;Data Source=db-server2"/>
  </appSettings>
</configuration>

此外,当它的计算机名称更改时,SQL 服务器需要进行其他步骤。 下面显示了用于实现此目的的 SQL 脚本代码片段:

sp_dropserver db-server
sp_addserver db-server2, local
GO

上一示例显示了当计算机名称更改时必须如何重新配置应用程序。 不难理解,此过程依赖应用程序。 如果应用程序将计算机名称写入数据库中的条目,则需要以类似的方式更改这些条目。 在某些情况下,你可能需要在计算机名称更改时重新安装应用程序。 执行此类重新配置和重新安装显然是我们从一开始就希望通过使用克隆来避免的操作。 这需要更加可靠的独立于应用程序的解决方案,可安全地允许多个克隆共存,并且没有计算机名称冲突。

IP 地址冲突

Internet 协议 (IP) 地址用于使计算机在 TCP 网络上互相通信。 IP 地址由网络上 DHCP 的服务器以静态或动态方式分配。 计算机中每个连接的网络接口都有 IP 地址。 如果克隆使用静态 IP 地址的虚拟机计算机,并将其放到与原始虚拟机相同的网络上,那么除了计算机名称冲突外,还将发生 IP 地址冲突。 你可以通过更改其中一个克隆的 IP 地址来手动解决此冲突。 同样,更改 IP 地址的影响取决于安装在虚拟机上的应用程序如何使用静态 IP 地址。

当你开始克隆使用动态 IP 地址配置的虚拟机时,将发生短时间的网络冲突。 在克隆第一台虚拟机后不久,第二台要连接到该网络的虚拟机将检测到此冲突,并通过续订其 IP 地址来更正自身。 每当克隆的环境还原到已在原始环境中拍摄的快照时,都存在类似的短时间冲突。 这些冲突的持续时间通常不足以影响应用程序。

MAC 地址冲突

媒体访问控制 (MAC) 地址是分配到计算机中每个网络接口的地址。 对于物理机,它由网卡制造商分配到每个网络接口。 对于虚拟机,有两种分配 MAC 地址的方法:静态或动态 MAC。 你可以为虚拟机的网络接口指定要使用的特定 MAC 地址。 这称为静态 MAC。 或者,你可以使虚拟机监控程序动态分配 MAC 地址。 这称为动态 MAC。 每当虚拟机启动时,Hyper-V 会从 MAC 地址池中分配动态 MAN 地址。 每个主机有用于生成 MAC 地址的架构,以使它们不会与其他主机上的虚拟机发生冲突。

如果静态 MAC 地址用于原始环境中的虚拟机,那么克隆环境中的虚拟机将拥有相同的 MAC 地址。 这将立即导致 MAC 冲突。 复制 MAC 地址更难检测,因为计算机不会始终报告它们。 即使报告它们,此类消息仍会记录在 Windows 事件查看器中。 对于最终用户,复制 MAC 地址有两个可能的后果。 一个后果是在一个或两个克隆上丢失网络连接。 另一个后果是,发送到一台计算机的网络数据包可能到达另一台计算机。 当原始计算机及其克隆具有相同的 MAC 地址时,它们的 IP 地址也相同。 即使当 DHCP 用于获取动态 IP 地址时,DHCP 服务器仍将向它们分配相同的 IP 地址,因为它们的 MAC 地址完全相同。

某种程度上,你可以通过使用动态 MAC 地址来避免 MAC 冲突。 但是,当克隆环境还原到已在原始环境中拍摄的快照时,这些虚拟机的整个状态将回滚,包括 MAC 地址。 这将再一次导致 MAC 冲突,而且之前描述的相同问题仍然存在,直到克隆的虚拟机重新启动。 重新启动克隆环境会导致虚拟机监控程序使用其自身范围内的值释放并续订 MAC 地址。

检测和解决我们刚刚描述的冲突的形式,然后手动修复操作系统/应用程序,以便在解决冲突后继续工作,这一过程对于虚拟实验室管理的常用用户来说是一个耗时且易出错的重大难题。 在许多情况下,更改任意这些参数会更改虚拟环境,这足以使生产环境丢失 bug 重现能力或导致类似问题。 将应用程序一次性安装到虚拟环境的原则以及轻松安全地克隆该环境以创建多个相同副本所需要的复杂方法超出了普通用户的能力范围。

网络隔离

到目前为止已确立了两个要求。 第一个要求是克隆环境中的虚拟机必须具有与原始环境中相同的计算机名称、IP 地址和 MAC 地址。 但与此同时,这些克隆必须可从该环境之外进行独立访问。 例如,对于要从桌面连接到每个克隆的人、对于要部署在特定克隆上的应用程序,或者对于要在特定克隆上运行的测试,该要求是必需的。 这导致了第二个要求,即,克隆环境中的虚拟机必须还具有与原始环境中不同的唯一计算机名称、IP 地址和 MAC 地址。 完成这两个要求的符合逻辑的方法是使每个虚拟机具有两个接口:一个计算机名称、IP 地址和 MAC 地址在每个克隆中都相同的专用接口;一个这些值在每个克隆中都独一无二的公共接口。

为了防止专用接口的网络冲突,它们必须连接到每个克隆中的专用网络。 专用网络是限定为仅用于某个环境中的虚拟机的虚拟网络。 由于此网络未在环境边界之外公开,因此不可能发生冲突,即使另一个克隆中使用相同的计算机名称、IP 地址和 MAC 地址也是如此。 为了使其可从环境外部访问,所有公共接口必须连接到常用公共网络。 公共网络或实验室网络是环境的虚拟机可在实验室中与客户端和其他计算机交互的网络。

图 3 显示专用和公共接口如何处理网络冲突。

包含使用专用和公用端口的 VM 的两台主机

Visual Studio 实验室管理中的网络隔离

Visual Studio 实验室管理通过在每个虚拟机中引入两个网络接口来为 SCVMM 环境实现网络隔离。 其中一个网络接口是连接到专用网络的专用接口,另一个是连接到公共网络的公共接口。

实验室管理软件以及安装在每个虚拟机上的代理确保了原始环境和克隆环境可以在没有冲突的情况下共存。

专用网络上的专用接口

以下描述是计算机名称、IP 地址和 MAC 地址如何分配到环境的专用接口的总结。

**计算机名称:**专用网络上的计算机名称通过 NetBIOS 解析并且不需要实验室管理软件的任何其他处理。 配置为与 NetBIOS 计算机名称兼容的应用程序将在每个克隆中按预期方式工作。 在我们的示例中,web-server 计算机使用其名称指代 db-server 计算机。 这些名称在原始和克隆环境中相同。 因此,web.config 文件在克隆环境中无需更改。

由于专用网络上没有 DNS 服务器,我们需要处理虚拟机使用完全限定的域名 (FQDN) 而不是 NetBIOS 名称互相指代的状况。 例如,如果 web.config 文件将 db-server 称为 db-server.lab.contoso.com,那么在专用网络上没有 DNS 的情况下无法将该名称解析为 IP 地址。 为了解决此问题,在虚拟机上运行的实验室代理在主机文件中添加对应于相同环境的其他虚拟机的条目。 主机文件是另一种向操作系统指示名称必须解析为特定 IP 地址的方法。 在我们的示例中,web-server 上的主机文件将具有以下条目:

192.168.23.2 db-server.lab.contoso.com

**IP 地址:**192.168.23.1 - 255 范围中的静态 IP 地址将分配到每台虚拟机的专用网络接口。 例如,为 web-server 的专用接口分配 192.168.23.1,为 db-server 的专用接口分配 192.168.23.2。 实验室管理确保 web-server 和 db-server 在每个克隆中获得相同的静态 IP 地址。 因此,即使 web-server 上的 web.config 文件使用 db-server 的 IP 地址进行配置,它也无需在克隆环境中重新进行配置。 在任何使用网络隔离配置的环境中,专用接口将获取这个相同范围内的 IP 地址,从 192.168.23.1 开始。 此范围中所需的地址最大数与环境中虚拟机的最大数相同。 由于这组 IP 地址不可从专用网络外进行路由,所以只要共用网络上未使用相同的范围,使用预定义范围非常安全。

**MAC 地址:**随机静态 MAC 地址分配到网络隔离环境中每个虚拟机的专用网络接口。 在我们的示例中,将向原始 web-server 中的专用接口提供 MAC 地址,例如 00-15-5D-07-57-01。 实验室管理会确保克隆环境中的此 web-server 也获得相同的 MAC 地址。 由于这组 MAC 地址无法从专用网络外部路由,所以只要它们不属于虚拟机监控程序在该主机上使用的范围,使用随机地址非常安全。

公共网络上的公共接口

以下描述是计算机名称、IP 地址和 MAC 地址如何分配到环境的公共接口的总结。

**计算机名称:**我们不希望 NetBIOS 解析公共网络上的计算机名称,因为此操作将导致计算机名称冲突。 为了防止此状况,实验室管理禁用每个虚拟机上的公共接口的 NetBIOS 广播。 与 NetBIOS 类似,我们不希望虚拟机在 DNS 中注册它们的 NetBIOS 计算机名称。 实验室管理还禁用每个公共接口的 DNS 注册。 在没有 NetBIOS 和默认 DNS 注册的情况下,我们仍然希望虚拟机具有可用在公共网络上使用的唯一名称。 实验室管理代表每个虚拟机生成唯一的别名并将其在 DNS 中注册为“A”记录。 在我们的示例中,原始环境中的 web-server 可以使用与 VSLM-195ea870-34d87df83883add23-47ab86ff.lab.contoso.com 相似的唯一别名进行注册。 克隆环境中的相同 web-server 使用与 VSLM-87ead667a-8787adde877919aaa-2001874d0.lab.contoso.com 类似的不同名称进行注册。

**IP 地址:**配置每个虚拟机上的公共网络接口以从 DHCP 服务器获取动态 IP 地址。 这保证了原始和克隆环境中的虚拟机具有唯一的 IP 地址。 例如,原始环境中的 web-server 可以获取 IP 地址 172.52.20.140,克隆环境中的相同 web-server 可以获取 IP 地址 172.52.20.205。

**MAC 地址:**若要防止 MAC 冲突,可以配置每个虚拟机上的公共网络接口以从虚拟机监控程序获取 MAC 地址。 这将确保我们示例中的 web-server 计算机在原始和克隆环境中获取不同的 MAC 地址。 但是,如之前所述,当克隆环境还原到在原始环境中拍摄的快照时,克隆虚拟机的 MAC 和 IP 地址假设使用与原始环境相同的值。 例如,当克隆环境还原到最新版本快照时,web-server 的 IP 地址变为 10.86.51.61(请参见图 3),这与原始环境中的值相同。 MAC 地址也会发生相同情况。 在 DHCP 续订 IP 地址前会临时发生 IP 地址冲突,与此同时,在重启虚拟机前存在 MAC 冲突。 由于此限制,将从虚拟机监控程序动态分配的 MAC 地址用于公共接口不是一个可行的解决方案。

为了处理此问题,实验室管理使用其自身的 MAC 地址池。 此池中的唯一 MAC 地址分配到虚拟机的公共接口。 每当克隆环境还原到快照时,实验室管理都会自动更改 MAC 地址以防止冲突。 若要了解此工作原理,请假设原始环境中的 web-server 的 MAC 地址是 1D-D8-B7-1C-00-05,而克隆环境中 web-server 的 MAC 地址是 1D-D8-B7-1C-00-07。 当克隆环境还原到在原始环境中拍摄的快照时,web-server 的 MAC 地址暂时变为 1D-D8-B7-1C-00-05。 实验室管理将此地址改回 1D-D8-B7-1C-00-07 以防止网络冲突。

与网络隔离的典型交互

接下来,我们将讨论当环境内的两台虚拟机互相通信时会发生什么状况:

  1. Web-server 使用 NetBIOS 或主机文件将计算机名称“db-server”解析为 db-server 的专用接口的 IP 地址 (192.168.23.2)。

  2. Web-server 在此 IP 地址与 db-server 通信。

当环境外的客户端必须与克隆环境中的 web-server 通信时,遵循以下过程:

  1. 客户端将查询实验室管理软件以获取克隆环境中的 web-server 的唯一别名。

  2. 实验室管理软件响应唯一别名。

  3. DNS 服务器将唯一别名解析为 web-server 的公共接口的 IP 地址 (10.86.51.63)。

  4. 客户端在此 IP 地址与 web-server 通信。

网络隔离的替代方法

使用两个接口不是网络隔离的唯一方法。 一个非常类似的方法是使用双向 NAT。 NAT 是为需要与公共网络上的设备进行通信的设备创建专用网络的常用方法。 即使典型 NAT 中的通信必须始终源自专用网络,双向 NAT 也可使其进一步发展并允许进行由专用网络或公共网络上的计算机发起的通信。

若要使用此方法实现网络隔离,必须在环境中引入双向 NAT 服务器。 通常通过将一台充当双向 NAT 服务器角色的特殊虚拟机添加到该环境来实现此目的。 在创建网络隔离的环境时,将通过与双接口方法相同的方式分配虚拟机的公共和专用 IP 地址。 但是,映射将存储在双向 NAT 服务器的 NAT 表格中,而不是将公共 IP 地址分配到虚拟机中的网络接口。

使用双向 NAT 对 VM 进行公共访问

环境中的两台虚拟机使用双向 NAT 方式互相通信的步骤与它们使用双接口方法时完全相同:

  1. Web-server 使用 NetBIOS 或主机文件将计算机名称 db-server 解析为 db-server 的专用接口的 IP 地址 (192.168.23.2)。

  2. Web-server 在此 IP 地址与 db-server 通信。

当环境外的客户端必须与克隆环境中的 web-server 通信时,所用步骤稍有不同,如下所示:

  1. 通过实现 NAT 方法,客户端查询实验室管理软件以获取克隆环境中的 web-server 的唯一别名。 (Visual Studio 实验室管理不实现 NAT 方法)。

  2. 实验室管理软件响应唯一别名。

  3. DNS 服务器将唯一别名解析为 web-server 的公共 IP 地址 (10.86.51.63)。

  4. 此 IP 地址实际映射到双向 NAT 服务器上的接口。 客户端与双向 NAT 服务器通信,但是假设它正在与 web-server 通信。

  5. NAT 服务器检索存储在配置表中的映射,并将公共 IP 地址 (10.86.51.63) 转换为专用 IP 地址 (192.168.23.1)。

  6. NAT 服务器将来自专用网络上客户端的消息转发到 192.168.23.1,这是 web-server 的 IP 地址。

此方法相比于双接口方法的优势是,无需以任何方式修改环境中的虚拟机。 无需在每台虚拟机中引入其他网络接口。 将其他网络接口引入虚拟机可能导致某些应用程序中断。

此方法的另一个优势是,达到网络隔离的整个逻辑封装在额外的虚拟机中。 无需在每台其他虚拟机中具有一个代理。 通过额外的虚拟机路由所有数据包还为支持更高级的网络隔离功能提供了其他控制点,例如:

  • **对外隔离:**不允许由环境外的客户端启动的网络数据包到达环境内的虚拟机。

  • **带有特定端口例外的对外隔离:**不允许由环境外的客户端启动的网络数据包到达环境内的虚拟机,除非它们的目标是特定端口。

在双向 NAT 方法中,通过引入 NAT 服务器上的防火墙可轻松实现这些功能。双向 NAT 方法的主要缺点是,某些应用程序无法跨 NAT 工作。 例如,Windows 应用程序中常用的 DCOM 和 .NET 远程协议在客户端和服务器由 NAT 服务器分隔时无法工作。 因此,Visual Studio 实验室管理使用双接口方法。 双向 NAT 方法的另一个缺点是,它在每个环境中需要额外的虚拟机,这将在虚拟机上进行创建或其他操作期间造成额外的开销。

其他冲突

到目前为止,我们已介绍了可如何通过网络隔离处理计算机名称、IP 地址和 MAC 地址冲突。 在克隆环境时,还可能发生其他形式的冲突。 每当依赖虚拟环境外的外部组件时,都可能在克隆该环境时发生冲突。 在此部分中,我们将了解可能发生此类冲突的两种常见情况。

Active Directory 冲突

为了目录服务或者用户身份验证和授权,Windows 计算机和应用程序经常依赖 Active Directory (AD)。 使用 AD 组策略集中管理 Windows 计算机是非常常见的做法。 通过使用我们的示例,让我们假设原始环境中的 web-server 和 db-server 加入到由 AD 管理的域中。 该 AD 在环境外托管。 当我们克隆此环境时,我们现在有两个相同的 web-serve 克隆,但 AD 中只有一个条目。 这明显不可取,而且可能导致多个问题。 例如,如果其中一个 web-server 克隆因为用户操作而从该域脱离,则另一个克隆也将脱离。 在一个环境中进行的更改将在无意之中影响另一个环境。

为了防止 Active Directory 冲突,AD 服务器必须托管在该环境中的虚拟机上。 AD 服务器不应该与环境外的其他目录有任何信任关系。

在网络隔离环境内设置 AD 时有一些其他的考虑事项。 第一,AD 虚拟机不应该连接到公共网络。 在双接口方法中,这意味着 AD 虚拟机不应该有公共接口。 在双向 NAT 方法中,这意味着 NAT 表格不应该有用于 AD 虚拟机的映射。

第二,由于 AD 位于独立林中,所以该环境中必须有 DNS 服务器。 环境中的其他虚拟机必须在专用网络上使用此 DNS 服务器与该 AD 进行正确通信。 作为示例,虚拟机可能无法加入专用 AD 中的域,除非在专用接口上正确配置了 DNS 服务器设置。

当你配置环境以包含 AD 虚拟机时,Visual Studio 实验室管理自动将 AD 与公共网络断开连接,并使用 DNS 设置配置虚拟机的专用接口。

可能出现无法在环境中托管 AD 的情况。 例如,当正在开发的应用程序必须使用公司 AD 与其他现有公司应用程序集成时,可能发生此情况。 当计算机加入环境外的域时,没有已知的解决方法可实现环境的安全克隆。

数据库冲突

虚拟环境的另一个常见用法涉及到在环境外托管应用程序的数据库。 通常,当数据库足够大而且对每个环境克隆数据库不现实时,会执行此操作。 当正在开发的应用程序是与托管在其他位置的数据库交互的简单 Web 客户端时,也可能发生此情况。 在此类情况下,当两个相同的克隆与数据库交互时,数据库服务器无法区分两个客户端的身份。

摘要

创建虚拟环境的相同克隆的能力对虚拟实验室管理中的多个方案非常重要。 但是,在创建相同的克隆时,存在计算机名称、IP 地址和 MAC 地址冲突。 解决这些冲突的简单技术(例如更改计算机名称或 IP 地址)通常需要重新配置或重新安装应用程序,这将大大打消创建相同克隆的意图。 网络隔离通过允许你同时创建并运行两个克隆来解决此问题。

后续步骤

**规划你的 SCVMM 环境:**了解何时使用 SCVMM 环境的不同选项,例如使用运行的虚拟机、已存储虚拟机、模板、已存储环境和网络隔离。 请参阅SCVMM 环境的创建和管理指南

**创建网络隔离环境:**当你准备好创建网络隔离环境时,使用此主题。 请参阅创建和使用网络独立环境

请参见

概念

自动系统测试