Hyper-V 2016中的标准检查点和生产检查点
Hyper-V 2016中的标准检查点和生产检查点2017年1月24日由埃里克Siron12检查点是几乎所有虚拟机管理程序中发现的最古老的功能之一。尽管它无处不在,但这项技术还是有很多困惑。它是什么?什么时候合适?在哪里不应该使用它?为什么这么多人说不使用它?Hyper-V的2016年发行版通过添加一种新型的检查点(奇怪地称为“生产检查点”)使情况更加混乱,即使它们不比“标准”检查...
Hyper-V 2016中的标准检查点和生产检查点
检查点是几乎所有虚拟机管理程序中发现的最古老的功能之一。尽管它无处不在,但这项技术还是有很多困惑。它是什么?什么时候合适?在哪里不应该使用它?为什么这么多人说不使用它?Hyper-V的2016年发行版通过添加一种新型的检查点(奇怪地称为“生产检查点”)使情况更加混乱,即使它们不比“标准”检查点更适合生产环境。但是,它们确实向检查点机制添加了更多范围的有效用例。要正确使用检查点,您需要了解它们。
什么是Hyper-V检查点?
Hyper-V检查点是虚拟机生命周期的不变点。虚拟机仍然可以正常使用,但是检查点受到保护,不会对虚拟机进行任何更改。通常将此类“更改”理解为是指附加的虚拟硬盘中的数据。那只是故事的一部分。虚拟机的任何更改都不会影响检查点。它还与虚拟硬盘的断开/连接,网络拓扑更改,内存重新分配以及有关可修改的虚拟机的几乎所有其他事物隔离。
检查点过程很简单,但是结果有些矛盾,因此令人困惑。以下是适用于标准检查点和生产检查点的通用说明,省略了区别性详细信息。
- 检查点服务将创建虚拟机配置文件的副本,并将其放置在虚拟机已配置的Checkpoint File Location中。
- 检查点服务会为连接到虚拟机的每个VHD [X]文件创建一个差异磁盘。这些差异磁盘始终与其父VHD [X]文件放在同一文件夹中。
- 创建检查点将完全忽略直通磁盘。
- 虚拟机继续从原始配置文件运行,并继续从原始VHD [X]文件读取未更改的数据。
这部分看起来很简单。混乱源于Hyper-V处理这些文件以进行更改的方式。
- Hyper-V将虚拟机配置的更改分配给其原始配置文件(在2012 R2和更早版本中为XML,在2016年为VMCX)。Hyper-V不会对检查点服务在上面的步骤1中创建的配置文件的副本进行任何更改。
- Hyper-V将虚拟机连接的虚拟硬盘中的数据更改写入AVHD [X]文件。Hyper-V 不会对原始VHD [X]文件进行任何更改。
- Hyper-V将直通磁盘中的数据更改直接写入直通磁盘。
了解所有这些很重要,因为我发现检查点行为存在很多混乱。人们正在复制并修改AVHD [X]文件,以为他们在某种程度上操纵检查点。实际上,他们正在使用活动的虚拟机。实际上,我们经常使用诸如“属于该检查点的AVHDX文件…”之类的术语,实际上,检查点与AVHDX文件没有任何关系(检查点树中嵌套层的检查点有,但现在让我们考虑一下具有单个检查点的虚拟机)。
让我们看一下带有检查点的虚拟机的可视化:
检查点图
如果您打算对文件做任何事情,那么了解虚拟机状态的哪一部分拥有每个文件就至关重要。如果您不打算将其提高到这个水平,那么最重要的要了解的是虚拟机是所有这些部分的总和。虚拟机的惰性部分从技术上讲可以独立存在,但是更改虚拟机的任何部分都会导致在活动状态下发生的任何事情变为无效。
那“快照”呢?它们如何与检查点相关?
大多数其他虚拟机管理程序,包括较旧版本的Hyper-V,都将此技术称为“快照”。Hyper-V的先驱Virtual Server将其称为“检查点。System Center Virtual Machine Manager始终使用该术语。为了使所有内容保持同步,Microsoft已经开始逐渐将其称为“检查点”,但是您仍然会看到许多对“快照”的引用。一个明显的位置是保存它们的文件夹。
还有其他技术称为“快照”。最值得注意的是卷影复制服务(VSS)快照。这是新生产检查点中非常重要的部分,因此我们将在该部分中对此进行扩展。
如何使用Hyper-V检查点作为备份?
简短的答案是:您不能将Hyper-V检查点用作备份。根据定义,备份是数据的重复。检查点不重复数据。
您可以做的是导出检查点。这将创建数据的副本,因此有资格作为备份。它没有使用专用的备份应用程序有效,但是如果您没有更好的选择,它会做到。
但是,检查点出口使很多人感到困惑。他们被告知AVHDX文件属于检查点。因此,他们自然地认为导出检查点将捕获AVHDX中所有已更改的数据。不幸的是,前提是不正确的。AVHDX不属于检查点;它属于活动的虚拟机。如果导出检查点,则可以得到发生到检查点被采取为止的所有事情,但是之后没有任何事情。如果要导出在检查点之后发生的事件,则需要导出虚拟机的活动状态,或者采用另一个检查点并将其导出。Hyper-V可以导出实时虚拟机,因此可以利用它。
如果仅需要更改的数据,则需要深入研究API。这些更改由原始数据块表示,因此您将需要一些编程技能来充分利用它们。但是,我认为大多数人并不真正了解这些更改不是完整的文件。
本节最重要的一点是,检查点不是备份。
如何使用“应用”,“删除”和“还原检查点”功能?
创建检查点后,可以使用三个操作来管理它。
应用检查点
“应用”操作是最恰当的命名。当您“应用”检查点时,检查点将变为虚拟机的活动状态。当您使用GUI来应用检查点时,将有机会捕获另一个检查点中的当前活动状态。如果您拒绝,则在最新检查点和虚拟机的活动状态之间发生的所有事情都将永久丢失。在较早的文章中,我们已经编写了检查点应用程序的说明。
Apply具有两个主要用途:
- 您想像使用特定检查点时一样使用虚拟机。通过这种用法,建议您在出现提示时采取另一个检查点。
- 您不喜欢虚拟机的当前状态,而是想使用其他状态。通过这种用法,采取另一个检查点的鼓励并不那么强烈。
根据您的情况,您可能更喜欢还原操作。
还原检查点
“恢复”也是一个恰当的名称,尽管它不能说明全部内容。“还原”与“应用” 完全相同,除了:
- 您无法选择检查点。还原总是应用最新的检查点。
- 您没有选择检查点当前状态的选项。它是永久丢失的。
还原有一种用途:
- 您不喜欢虚拟机的当前状态,而是想回到先前的检查点。
当紧接在前一个检查点是您想要的位置并且您不在乎保持当前状态时,Revert优于Apply。
删除检查点
如果从字面上删除了检查点,那么它将破坏上面可视化图中分隔线左侧的所有内容。更改后的数据将成为孤立数据并且毫无用处。但是,它确实删除了\ Snapshot文件夹中代表任何配置差异的文件,因此该动词确实保留了一定的适用性。我要说的是,“合并”在描述“删除”检查点时会发生什么方面做得更好。源VHDX和AVHDX文件中的数据将合并回到源VHDX文件中。没有数据被删除。只有原始虚拟机配置信息会丢失,而有利于当前配置(例如,动态内存设置)。在较早的文章中,我们已经编写了删除检查点的说明。
标准和生产Hyper-V检查点之间有什么区别?
从历史上看,从管理程序的角度来看,虚拟机通常是一个黑匣子。这意味着虚拟机管理程序知道所有CPU和内存以及I / O活动都在其中发生,但是它并不真正知道“某些”是什么。因此,快照/检查点本质上在某个时间点冻结了虚拟机的活动……就像它们所命名的摄影快照一样。快照中没有捕获快照后发生的任何事情……就像它们以其命名的摄影快照一样。由于管理程序不知道虚拟机内部正在发生什么,因此它只是将这些资源锁定在当时的状态。这是一个“标准”检查点。
新的所谓“生产”检查点依赖于虚拟机管理程序技术的最新进展。包括Hyper-V在内的大多数公司现在都有一些技巧可以进入“黑匣子”并与内部运行的特殊设计的组件进行交互。对于Hyper-V,它们在Windows中称为“集成服务”,在Linux中称为“集成组件”。这些服务之一是 备份(卷影复制)服务,该服务又与卷影复制服务(我们大多数人都简称为“ VSS” )交互。
有关VSS的许多文章可以(并且已经)写过。它的核心是备份应用程序和操作系统之间的网关。存在VSS是为了解决在进行备份时数据可能并且确实会更改的事实。我们已经有一篇文章集,涵盖与VSS和备份相关的术语和机制。关于VSS的最重要的了解是,它为应用程序提供了停止所有I / O并将未完成的数据和操作从内存刷新到磁盘的功能,从而使备份不会丢失任何内容。要了解VSS在宇宙中的位置,最重要的一点是,并非所有应用程序都可以利用它。这就是我们在“标准”和“生产”检查点之间进行区分的地方。
标准检查站的特征是什么?
从最初的“检查点是什么”部分开始。那里的所有内容都适用于标准检查点。此外,标准检查点还可以捕获:
- 虚拟机CPU活动的活动状态
- 虚拟机内存的活动状态
标准检查点的简短形式定义是:虚拟机与采用检查点时的状态完全相同。
让我们来看看它的作用。在虚拟机内部,我在桌面上创建了一个新的文本文件,在记事本中将其打开,键入一些文本,并在不保存文件的情况下执行了检查点操作:
未保存的数据预检查点
接下来,我进行了一些更改:
标准后检查点更改
然后我将其还原(请记住,这会使我失去检查点之后所做的一切):
还原的标准检查点
那么,这时,记事本中的哪些内容存在于VM的VHDX中?没什么,就是那样。我什么也没保存 但是,文档的内存版本中的所有文本仍然存在,因为已保存了内存状态。检查点代表在执行检查点的确切时刻的虚拟机。记事本不知道发生了什么事。虚拟机中任何地方唯一意识到没有什么不同的是时间服务。我确实启用了时间同步服务,因此时钟已立即更新。
生产检查站的特征是什么?
从最初的“检查点是什么”部分开始。那里的所有内容都适用于生产检查点。与标准检查点不同,生产检查点不会捕获其他任何内容。相反,它们在来宾中触发VSS。在其中运行的任何已注册VSS编写器的应用程序都将执行编写器要执行的所有操作。例如,Microsoft Exchange将其日志提交到存储。Windows还将阻止正在进行的I / O发生和刷新文件系统队列。
重要的是要知道,活动的CPU操作和内存状态不会受到任何保护。
为了演示,我将继续使用与上面“标准检查点”部分相同的VM。我合并(“删除”)了该检查点。我将虚拟机设置为使用生产检查点,然后使用一个检查点。完成此操作后,我将执行与标准检查点相同的操作:在记事本文件中键入了一些数据。然后,我还原了检查点。
首先要注意的是,在还原的标准检查点还原虚拟机的确切状态的情况下,还原完成后,还原到生产检查点的虚拟机将关闭:
恢复生产检查点
之后,我打开了虚拟机的电源并打开了在桌面上创建的文件。看起来是这样的:
恢复生产检查点后数据丢失
数据怎么了?首先,我从未保存过它。这些话只在记忆中。其次,Notepad.exe没有VSS编写器。当生产检查点触发VSS时,Notepad.exe不知道要做什么,因此它什么也没做。
什么时候应该使用检查点?
在计划内的事件中,应该将检查点用于短期保护,否则可能会对虚拟机造成无法挽回的损害。对于标准和生产检查点都是如此。检查点的有效用法示例:
- 一个不是特别值得信赖的供应商想要升级其应用程序。在永久提交之前,您希望看到该应用程序在您的环境中正常运行。
- Microsoft / Windows更新,尤其是在以前的更新已严重破坏的系统上。
- 用于测试进行系统级更改的开发中应用程序的系统。
无论您出于何种原因使用检查点,它们仅用于短期用途。我听说有人允许检查站放置长达一年的时间,然后才决定对此采取任何措施。即使他们可以毫无问题地解决问题,但这也不是该技术的良好用法。就个人而言,我不希望检查站居住超过几个小时。我认为深层次的升级过程可能会保证一个检查点可以使用一两天。我不能给您一个严格的规则,但是我可以给您一个可靠的经验法则:永远不要让检查点超过它的用处。我的意思是,对于您拥有的每个检查点,请问自己:“如果还原此检查点,虚拟机的状态是否有用,否则我会丢失太多?”如果没有用,请现在合并它。
有些人说:“我从不在生产中使用检查点”(暗示您也不应使用检查点),并以一连串的借口为它辩护。其中一些借口:
- “我听说别人发生了不好的事情。”-这些都是可怕的原因。
- “不同的磁盘会占用大量空间,可能会占用太多空间,以至于我的虚拟机会暂停。” —这是事实。但是,差异磁盘(AVHDX)的增长速度仅与对VM数据所做的更改一样快。如果寿命不长,它们就不会增长到难以控制的规模。另外,无论如何,您都应该监视空间使用情况。
- “不同的磁盘会损害性能。” —差异磁盘会影响性能,但是它被夸大了。对于初学者来说,大多数人使用的IOPS并不像他们认为的那么多。另外,除非您已经接近容量或要嵌套检查点/差异磁盘,否则对性能的影响是最小的。这是一个可管理的问题,甚至不能说是“从不”使用检查点的可靠借口。最多是提醒您明智地使用检查点。
- “人们忘记删除检查点。”-主管管理员找到一种管理方法。我使用Nagios监视我的(您需要注册才能访问Hyper-V检查点监视器)。如果太多,请设置Outlook提醒和/或任务。偶尔运行Get-VMSnapshot。此借口的有效性为零。
我应该使用标准检查点还是生产检查点?
不允许使用术语“生产检查点”来暗示不能在生产中使用标准检查点。在生产环境中始终支持标准检查点。在某些情况下,它们仍然是首选。
标准检查点的用例
我假设我的记事本演示不指示正常的服务器操作。但是,有很多基于服务器的应用程序不响应VSS事件。 当满足以下所有条件时,对于要在虚拟机中保护的应用程序,标准检查点优于生产检查点:
- 该应用程序不支持VSS。
- 该应用程序主动处理虚拟机拥有的VHDX中的数据,或者执行内存中的操作,如果可以避免的话,这些操作必定不会丢失。这不适用于针对远程服务器上的数据的内存中操作,因为还原的虚拟机上的数据状态不会同步到任何远程服务器。
- 采取检查点时,应用程序处于活动状态(正在运行)。
这类应用程序的示例是不支持VSS的数据库和邮件服务器。我曾与许多使用非常古老的数据库技术的供应商合作(阅读:应用程序供应商及其客户可以避免使用现代RDBMS的许可费用)。这些最好由标准检查点提供。
生产检查点的用例
通常,在任何要求“标准”检查点的条件都不成立时,最好使用生产检查点。让我们直接指定它们。当任何条件适用于您要保护的应用程序时,请选择“生产检查点”而不是“标准检查点”:
- 该应用程序可识别VSS
- 该应用程序是被动的,处于只读状态,或从远程计算机提供数据。
- 该应用程序已停止
生产检查点有许多明显的用途,因此我将跳过这些检查点。对于像Apache Web服务器那样充当远程SQL Server前端的产品,生产检查点将是一个不错的选择。如果还原,则Apache Web服务器将从“关闭”状态恢复,因此它将不会尝试继续执行采用检查点时处于活动状态的任何操作。如果改用标准检查点,并且Web用户试图更新记录,则可能导致某些数据不一致。
是否有应避免所有检查站的情况?
我显然不赞成检查站的“从不”理念。但是,某些应用程序的虚拟机永远不应被检查点:
- 多域控制器环境中的Active Directory域服务器。多DC环境中域控制器的标准检查点可能会导致USN回滚。运行Windows Server 2012或更高版本的域控制器应该不受干扰,但是USN的回滚可能会造成灾难性的后果,以致风险不值得。如果使用生产检查点,从技术上讲,您也应该安全,但是,再次这样做可能不值得。如果您的环境足够复杂,无法证明多个域控制器的合理性,则它们根本不应运行任何可以证明使用Hyper-V检查点合理性的东西。具有单个域控制器的环境不能遇到USN回滚,但是我仍然看不到那里的检查点有效的用例。
- 集群成员。此限制对受Microsoft故障转移群集和非Microsoft群集技术保护的应用程序同样适用。检查点可能会导致这些应用程序中的USN回滚。当这些应用程序与其他成员同步时,这些其他成员将不必费心跟踪该同步点之前的任何对象的状态。如果将成员还原到检查点,它将不知道不知道的内容,其他成员也不知道为什么不知道。如果由于某些原因必须检查点,请先停止集群并关闭所有其他成员。当集群成员仅是数据的前端并且不将任何内容保留在本地时,这会有一些例外,但是您必须对这些应用程序中的数据流有深刻的了解。
- 具有先天复制的应用程序。我认为我们正在这里建立模式。如果您的应用程序正在执行某些操作以将本地数据与其他服务器上的其他应用程序进行同步,则对于任何检查点而言,这都不是一个好用处,除非您确保还原不会对其他成员或其数据造成负面影响。
生产检查点可以解决其中一些问题。还原带有生产检查点的虚拟机时,至少知道发生了什么事。该“内容”通常等效于从完整备份中还原。如果您了解您的应用程序在这种情况下将如何反应,那么您将了解它如何对生产检查点的应用程序作出反应。
生产检查点的一个好处是,对于运行虚拟机,它们要比标准检查点小。生产型虚拟机不需要内存状态,因此它们不保存副本。标准检查点在捕获时会保留虚拟机内存确切状态的磁盘上副本。
如何在Hyper-V 2016中配置检查点?
此版本的检查点配置过程已更改。在以前的版本中,唯一可以更改的是放置检查点文件的位置。在2016年(包括Windows 10 Client Hyper-V)中,您可以:
- 完全禁用虚拟机的检查点。
- 在标准或生产检查点之间进行选择。
- 当生产检查点操作失败时,允许创建标准检查点。
- 选择将虚拟机的检查点文件放置在何处(这仅适用于配置和状态信息文件; AVHD [X]始终与其VHD [X]父代位于同一位置。
默认情况下,为每个虚拟机启用标准后备的生产检查点。若要更改这些设置,请在Hyper-V管理器中打开虚拟机的设置,然后切换到“ 检查点”选项卡:
Hyper-V 2016中的检查点设置
您还可以使用PowerShell,它是批量操作的理想选择。该cmdlet是Set-VM。检查点类型的参数选择很容易使用-CheckpointType。它接受Disabled,Standard,Production和ProductionOnly的值。使用SnapshotFileLocation参数告诉它将配置和状态信息文件放置在何处。
2016年检查站的分类混乱
Get-VMSnapshot的输出包含一个SnapshotType字段,您可能会认为该字段可以帮助您区分生产检查点和标准检查点。如果您尝试将其用于此目的,则将发现它始终指示检查点类型为“标准”,即使它是生产类型也是如此。该字段适用于Hyper-V副本,而不适用于新的Production检查点类型。我找不到任何地方可以从外部确定检查点是“生产”还是“标准”。我建议您在创建时为它们命名。
更多推荐










所有评论(0)