第18章 SnowFlock

云计算提供了一个令人难以置信的计算平台。用户通过点击几下用户可以以每小时不到10美分的价格租用在云中的服务器，节约了使用物理设备的所有相关时间，精力和前期成本。云供应商提供虚拟机（虚拟机），而不是物理计算机来实现低成本运营。云计算的关键是虚拟化软件，被称为虚拟机监视器（虚拟机M），用来模拟一台物理机器。用户们非常安全地使用相互的客户虚拟机，而没有意识到他们通常与许多人共享物理机（“主机”）。

18.1 SnowFlock简介

云计算是敏捷组织的福音。对于使用物理服务器而言，用户需要焦急地等待着缓慢的审批流程，批准购买服务器，下订单，直至服务器出货，然后安装和配置操作系统（OS）和应用程序组。而云用户不需要等待数周的购买流程，只专注过程控制，并可以在几分钟内创建一个新的独立服务器。

不幸的是，云服务器很少是独立的。在快速实例化和按次使用模式的带动下，云服务器通常是在配置相似的服务器可变池中的一个实例，能够执行动态和可扩展的并行计算，数据挖掘，或web等任务。因为需要多次从相同的静态模板中启动新的实例，商业云还不能兑现真正的按需计算的承诺。服务器实例化后，云用户仍然必须管理群集成员及通过增加新的服务器来调整。

SnowFlock通过虚拟机克隆技术解决了这些问题，这就是我们所提出的云API调用。应用程序代码经常通过一个系统调用接口调用OS服务，它现在也可以以同样的方式通过类似的接口调用云服务。通过SnowFlock的虚拟机克隆技术，我们可以将资源分配，集群管理和应用程序逻辑可编程等诸多方面交织在一起，并作为一个单一的逻辑操作。

根据父虚拟机,虚拟机克隆技术实例化了云服务器的多个完全相同副本。从逻辑上讲，克隆的虚拟机继承了其父节点的所有状态，包括操作系统和应用程序级缓存。此外，虚拟机的克隆都将被自动添加到一个内部私有网络中，从而有效地加入了这个动态可扩展的群集。新的计算资源，被封装为相同的虚拟机，从而可以按需动态创建。

就实际使用而已，虚拟机克隆技术是可用，高效，而且快速的。在这一章中，我们将描述SnowFlock中对虚拟机克隆技术的实现，包括如何有效地在多个不同的编程模型和框架实现克隆， 如何在应用程序运行时使服务器的开销最少，以及如何在5秒或更少的时间内来创造几十个新的虚拟机，等等。

SnowFlock非常灵活，能够使用C， C + +，Python和Java的API来实现虚拟机克隆的程序控制。我们已经成功地将SnowFlock移植到多个不同系统的原型实现中。在并行计算中，我们通过精确克隆技术有效地分担了在许多物理主机的负载，并取得了良好的效果。对于在一个专用的服务器集群上运行的使用了消息传递接口（MPI）的多个并行应用，需要修改MPI的启动管理器，从而提供了良好的性能和更少的开销，并且不需要修改应用就能够在每个新的克隆集群上运行。最后，在一些完全不同的应用案例中，我们使用SnowFlock来提高弹性服务器的效率和性能。今天，基于云服务的新业务一般需要启动新的服务器。而通过克隆运行中的虚拟机，SnowFlock带来了新的服务器功能。由于克隆的虚拟机继承他们的父节点的热缓冲区，从而使性能迅速达到峰值，使上线速度快了20倍。

18.2 虚拟机克隆

顾名思义，虚拟机克隆与父虚拟机几乎是相同的。实际上，还是有一些轻微且必要的差异的，例如避免MAC地址冲突等问题，但我们会稍后讨论。创建一个整个本地磁盘和内存状态的虚拟机克隆是必须的，这也是我们第一个主要的设计权衡：应该如何按需复制前端的状态？

实现虚拟机克隆最简单的方式是采用标准的虚拟机“迁移”能力。通常情况下，迁移是指将运行中的虚拟机服务移动到不同的主机上，例如如当主机超载或需要维修的情况下。但是，因为虚拟机是纯粹的软件，所以可以被封装在一个数据文件，然后将其复制到一个新的主机上，在短暂中断后重新执行。要做到这一点，现有的VMMS要包含一个“检查点”来创建文件，该文件包括本地文件系统，内存映像，虚拟CPU（VCPU）寄存器等等。在迁移过程中，新启动的副本替换原来的虚拟机，但这个过程是可以改变的，例如离开原来的虚拟机运行时可以产生一个虚拟机克隆。在这种所谓的“渴望”进程中，因为整个虚拟机处于状态转移前的执行状态，所以整个虚拟机提供了最好的初始性能。这种复制的缺点是在开始执行前必须费力地复制整个虚拟机，这严重地影响了实例化的过程。

SnowFlock采用了另一种极端方式，即是延迟状态复制。不再复制全部虚拟机，而是复制虚拟机转移时所需得重要数据，在虚拟机转移后，SnowFlock在复制克隆中所需的其他数据。这有两个好处，首先，它最大限度地减少了工作量，尽可能实例化延迟加载。其次，它只复 制真正使用的状态数据，实际上是提高了虚拟机克隆的效率。当然，这样做的好处取决于克隆的行为，但少量的应用程序需要访问内存和在本地文件系统的每个文件的每一页时就效果不大了。

然而，延时复制的好处不是免费的。由于状态转移被推迟到最后，需要在状态到达时，才能继续执行克隆。在时间共享工作站内将内存交换到磁盘，而并行的应用程序从高延迟的数据源获取状态可能被阻塞。在SnowFlock的用例中，这些阻塞降低了克隆的性能，其严重程度取决于应用程序。对于高性能计算应用，我们已经发现这种退化的影响不大，但可能会首先克隆的数据库服务器性能。应当指出的是，这是一个瞬态影响：在几分钟之内，大多数必要的状态已被转移且性能父节点匹配。

顺便说一句，如果你熟悉虚拟机，你可能考虑在这里使用实时迁移的优化。实时迁移的优化，可以缩短原始虚拟机的暂停和恢复执行新副本之间的间隔。要做到这一点，虚拟机监视器（VMM）需要在父节点仍在运行时预拷贝它的状态，从而使只有最近更改过的页才迁移。这项技术不会影响之间的迁移要求和副本开始执行的时间间隔，因此不会降低虚拟机克隆的实例化延迟。

18.3 SnowFlock的实现方法

SnowFlock实现虚拟机克隆被称为“虚拟机fork”，这就像标准的Unix系统调用fork一样，但有几个重要的差异。第一，系统调用fork是复制一个单一的进程，虚拟机fork重复整个虚拟机，包括所有的内存，所有的进程和虚拟设备，以及本地文件系统。第二，系统调用fork是产生在同一物理主机上运行的单个副本，虚拟机fork可以同时产生多个并行备份。最后，虚拟机可以被复制到不同的物理服务器，让你迅速提高云服务的需要。

以下是SnowFlock中的核心概念：

• 虚拟化：虚拟机封装了计算环境，使机器复制和云服务成为可能。

• 延迟传播：直到需要的时候才复制虚拟机的状态，虚拟机克隆在几秒钟内生成。

• 组播：诸多的虚拟机克隆有着类似的状态需求。通过多播，几十个虚拟机克隆可以尽快执行。

• 页故障：当一个克隆使用了无效的内存空间，这一故障将触发一个请求到父节点，直到所需的内存页可用了，才继续执行克隆操作。

• 写复制（COW）：在虚拟机克隆生成前，父虚拟机先保留一个当前内存和磁盘页的副本，在保留虚拟机克隆所需的状态同时可以继续运行。

我们使用Xen虚拟化系统来实现的SnowFlock，所以弄清一些Xen的专用术语是非常有用的。在Xen环境中，VMM被称为虚拟机管理程序，虚拟机被称为域。在每台物理机（主机）说，是一个特权域，称为“域0（dom0），每个特权域能够完整地访问主机及其物理设备。如果虚拟机被用来控制额外的“访问者”或“用户”，则被称为“域U”（domU）。

广义而言，SnowFlock包括一套修改了的Xen虚拟机管理程序（使其在无效资源被访问时能够顺利恢复），一组运行在dom0上的支持进程和系统服务包括无效虚拟机状态的合作迁移，以及一些虚拟机克隆中OS修改，由六个主要组成部分 。

• 虚拟机描述器：这个小对象是虚拟机克隆的抽象描述，描述了需要开始执行的虚拟机基本框架。它没有需要执行任何实际工作血肉。

• 组播分发系统（mcdist）：这是父节点系统，能够同时向所有克隆有效地发布虚拟机的状态信息。

• 内存服务器进程：父节点服务器进程中维护了父节点状态的多个副本，并使其根据需求通过多播mcdist发布给所有克隆。

• Memtap进程：一个虚拟机克隆端的进程，与内存服务器通信请求那些克隆所需要但又缺失的内存页。

• 克隆提示器：运行在克隆内的guest内核，通过为VMM提供线索来按需减少虚拟机状态的迁移。尽管是可选的，却是高效的。

• 控制栈：运行在每个物理主机上得守护进程,协调其他组件以及管理SnowFlock的父节点和虚拟机克隆。

图18.1：SnowFlock 虚拟机复制架构

如图所示，图18.1描绘克隆一个虚拟机的过程，主要有四个主要步骤：（1）暂停父虚拟机并产生一个虚拟机描述器;（2）将虚拟机描述器分发到所有目标主机（3）克隆初始化;（4）按需加载状态。该图还描述了使用mcdist 进行组播分发的方法，并取通过访问启示避免相关问题 。

如果你有兴趣尝试SnowFlock，这里有两种方法。多伦多大学SnowFlock研究项目组提供了文文档和开放的源代码1， . 如果您愿意采用一个工业化的版本，可以从GridCentric公司2 获得一个免费的非商业许可证.由于SnowFlock包括hypervisor的修改和dom0的访问的，所以安装SnowFlock需要对主机的访问权限。出于这个原因，你需要使用自己的硬件，将不能使用如亚马逊的EC2云环境等商业云服务。

在接下来的几节中，我们将描述瞬时实现和高效克隆的协同工作。我们将所以地内容结合在一起，如图18.2所示 。

图18.2：SnowFlock的的软件组件

18.4 构建虚拟机描述器

SnowFlock的设计关键是决定推迟虚拟机的状态复制到一个延迟运行操作。换句话说，复制虚拟机的内存是后期绑定操作，从而为优化的许多机会。

第一步的设计决定是生成虚拟机状态的架构描述器。这是将用于创建克隆虚拟机的种子。它包含了创建一个虚拟机的最低必要条件，使其可以被调度。顾名思义，这一必要条件是由架构规范所需要的数据结构组成。在SnowFlock中，该架构是Intel x86处理器和Xen的结合。因此，架构的描述包含数据结构，如页表，虚拟寄存器，设备元数据，wallclock时间戳等.我们推荐有兴趣的读者可以参考[LCWB +11 ]架构描述器的内容来深入理解。

一个架构描述器有三个重要的属性：首先，它可以在短时间内创建200毫秒的情况并不少见。其次，它是小的，通常是小于原虚拟机的内存分配三个数量级（1 MB为1 GB的虚拟机）。第三，从一个描述符创建克隆虚拟机可以在一秒钟之内（通常为800毫秒）。

当然，主要的时间开销是从描述他们的记忆状态创建克隆虚拟机全部的时间。以下各节我们说明如何解决这个问题，如何利用优势，并提出优化的机会。

18.5父节点组件

一旦被克隆的虚拟机成为一个父节点, 就和所有其他父节点一样，它需要为子节点提供克隆服务。父节点是通过维护一套内存和磁盘状态，克隆的集会,为克隆虚拟机提供按需服务。

18.5.1 memserver进程

当创建架构描述器的时候，虚拟机将在进程中停止。这保证了虚拟机的内存状态稳定;在暂停虚拟机并执行调度或取消调度前，内部OS驱动程序处于停顿状态，从克隆可以重新连接到外部网络。我们采取这种静止状态的优势来创建一个“内存服务器”即memserver。

内存服务器将提供克隆虚拟机所需的所有父节点内存数据。内存转移是以x86的内存页（4字节）为粒度单位的。最简单的形式是内存服务器等待来自克隆的内存页请求，在一个时间上为一个克隆提供一个内存页的转移。

然而，这些需要转移的内存在父虚拟机中需要继续使用并执行。如果我们允许父节点去修改这个内存，那将会以损坏的内存内容克隆虚拟机：内存供应将是从不同的克隆点完成的，使克隆容易混淆。以破解内核的词汇来说，这是一个堆栈信息跟踪的问题。

为了克服这个问题，采用经典的操作系统概念来救援：Copy-on-Write, 即CoW memory.。通过辅助的Xen hypervisor，我们可以移除父虚拟机的所有内存页写入权限。当父节点试图修改一个内存页，将触发硬件内存页错误。Xen通过页面的副本知道这种情况发生的原因。父虚拟机允许写入到原来的页面，并继续执行，而被告知使用原来的副本，这就是保持只读的内存服务器。在这种方式下，被克隆的内存状态仍然冻结，且不混淆，而父节点能够继续执行。CoW的开销是最小的：Linux使用了类似的机制，如创建一个新的进程。

18.5.2 Multicast与Mcdist

克隆通常存在被称为“命运的决定”的问题。 我们希望创建克隆是为了一个单一的目的：例如，相对于Y调整一个数据库的DNA中X链。此外，我们期望要创建一套克隆，使所有的兄弟姐妹做的一样，也许对数据库的不同部分对准相同的X链，或调整不同的链对准Y链，从而明确地表现为大量内存访问的时间局部性：他们将使用相同的代码和大部分常见的数据。

我们利用时间局部性，为SnowFlock量身定制了自己的组播分发系统—— mcdist。mcdist使用IP组播，同时为接收器集合分发相同的数据包。它利用网络硬件并行处理的优势减少了内存的服务器上的负载。因为所有克隆具有类似的内存访问模式，通过对所有克隆的第一个要求发送一个应答，每个克隆的要求被作为它的兄弟姐妹预处理。

不像其他的组播系统，mcdist并不一定是可靠的，没有以一个有序的方式提供数据包，也没有以原子方式提供所有拟接收的应答。组播是严格意义上的优化，并确保克隆明确请求内存页的需要。因此，该设计优雅简单：简单的服务器多播的响应，而因为客户端超时，当克隆没有收到一个请求的答复时重新请求。

SnowFlock的三个优化都体现在mcdist上：

• 一致性检测：当时间局部性发生时，多个无差别请求都非常密切的继承在同一页。mcdist服务器忽略所有除第一个以外的请求。

• 流量控制：接收器的获取率与请求相关。服务器的发送率取决于客户端接受率的加权平均。否则，接收器将会淹没在服务器发送过多的内存页中。

• 游戏结束：当服务器已经发送了大多数页面时，将回到单播响应。在这一时间点上的大多数请求是重试，从而通过网络的内存页轰炸所有克隆是不必要的。

18.5.3虚拟磁盘

SnowFlock的克隆，由于其短寿命和命运决定，很少使用的磁盘。SnowFlock 虚拟机的虚拟磁盘包括了二进制文件，库和配置文件的根分区。通过合适的文件系统如HDFS 或PVFS 是完成大量的数据处理。因此，当SnowFlock克隆决定从他们的根磁盘读取数据时，它们通常由内核的文件系统页面缓存来满足这样要求。 尽管如此，我们仍需提供克隆的虚拟磁盘访问，在一些罕见的实例中这种访问需求是需要的。我们在这里采用了最小阻力路径，依据内存复制的设计来实现虚拟磁盘访问。首先，在克隆的时间里磁盘的状态被冻结。父虚拟机保持以CoW的方式使用其磁盘：对存储备份的写操作被发送到单独的位置，在磁盘克隆时也是不可改变的。二，磁盘的状态将使用 mcdist组播到所有克隆，且具有相同的4 KB页的粒度，并根据时间局部性完成相同的期望。第三，严格复制克隆虚拟机的磁盘状态是短暂的：它存储在一个文件中，当克隆被摧毁后被删除。

18.6克隆端组件

克隆在从架构描述器创建时是空心弹，和我们一样，他们需要从父母那里获得很大的帮助才能长大：子虚拟机们迁出时要立即给家里打电话，他们发现很多需要的东西缺失，要求他们的父母马上发送。

18.6.1 memtap进程

memtap进程连接到每个创建后的克隆，是一个克隆的生命线。它映射到克隆的所有内存并按需加载。通过Xen的hypervisor，它登记了一些关键的数据位：访问克隆内存的权限被关闭，由第一次访问一个内存页造成的硬件故障由hypervisor路由到memtap进程。

在其最简单的化身中，memtap进程只需简单地要求内存的服务器处理错误内存页，但也有更复杂的情况。首先，memtap助手使用了mcdist。这意味着，在任何时间点，任何页面可以凭借已被另一个克隆的异步预取请求到达克隆。第二，我们允许SnowFlock虚拟机是多处理器的虚拟机。这就不那么有趣了。这意味着，在并行处理时存在同一页的多个故障需要。第三，在以后的版本中,memtap助手可以明确地预取批量的内存页，在缺乏保证情况下,以任何次序从mcdist服务器到达克隆。这些因素可能导致并发噩梦，我们遇到了所有这些问题。

内存页位图是整个memtap的设计中心。当处理架构描述器创建克隆虚拟机时，创建和初始化该位图。该位图是一个比特数组,其大小由虚拟机内存可容纳的内存页数量决定。英特尔处理器有方便的原子位互斥指令：设置了一个比特，或做一个测试和设置，可以保证原子发生与其他处理器在同一个盒子里。这使得我们在大多数情况下，从而提供不同的实体，在不同的保护域的访问位图以避免锁：Xen管理程序，memtap进程，以及guest内核本身的克隆。

当Xen的处理由第一次访问页面产生的硬件页错误时，它使用内存页位图来决定是否需要提醒 memtap。它还使用该位图依赖于不在同一页的多个虚拟处理器来队列化memtap缓冲页。当其缓冲区是满的，或到达一个明确请求的内存页时暂停虚拟机，位图被用来丢弃那些已经到达的任何重复的已经存在内存页。所需的任何剩余内存页被复制到虚拟机的内存，并设置适当的位图比特。

18.6.2 明智的克隆，避免不必要的提取

我们刚刚提到，运行于克隆内核的该内存页位图是可见的，并没有锁，需要修改。这给克隆提供了一个强大的“启蒙”工具：它们可以防止通过修改位图和假装已经存在的是当前内存页的抓取。这是非常有用的性能，在内存页没有完全覆盖之前，他们都可以被安全使用。

恰好是一个非常普遍的情况，当发生这种情况，并获取可避免。在内核中的所有内存分配（虚拟机alloc的使用 ，kzalloc，get_free_page，用户空间的BRK，等等）最终处理内核页分配器。内存页通常由中间开始分配，管理细粒度块要求是：slab分配器，glibc在一个用户空间进程的malloc分配，等等。然而，无论是显式或隐式的分配，一个关键的语法含义始终正确：没有人关注内存页中包含的内容，因为它的内容将随时被覆盖。为什么取这样一个内存页呢？没有任何理由这样做，实际经验表明，避免这种获取方式是极其有利的。

18.7虚拟机克隆的应用程序接口

到目前为止，我们都集中一个虚拟机有效克隆的内部机制。作为服务系统非常有趣，所以我们需要把注意力放在谁将使用这样的系统：应用。

18.7.1。API实现

通过简单的SnowFlock API（如图18.1所示），应用程序可以利用虚拟机克隆。利用克隆的方式基本上是一个两阶段的过程。你第一次请求分配一个克隆实例，虽然依赖于系统策略的影响，分配的实例可能会小于所请求的内容。第二，你可以使用分配给你的虚拟机克隆。一个关键的假设是你的重点聚焦于虚拟机上一个操作。虚拟机克隆是适用于单一应用的虚拟机，如Web服务器或一个渲染工厂组件。如果你在一百多个桌面环境进程中的多个应用程序同时调用虚拟机克隆，你就头大了。

sf_request_ticket（N） 请求分配n个克隆。返回一个分配M≤N 克隆的ticket。

sf_clone（ticket） 使用的ticket分配克隆。返回克隆ID，0≤ID

sf_checkpoint_parent（） 准备一个检查点ç不可改变的父虚拟机，可用于以后任意创建克隆。

sf_create_clones（C，门票） 与sf_clone相同，只是使用检查点ç。在哪个对应点开始执行

sf_checkpoint_parent（）时调用克隆。

sf_exit（） 终止子克隆（1≤ID

sf_join（ticket） 父节点使用（ID = 0），块，直到所有使用ticket的子节点调用sf_exit前一直处于阻塞状态。在这一时间点上，所有的子节点都被终止和ticket被弃用。

sf_kill（ticket） 家长弃用ticket票，并立即杀死所有相关的子节点进程。

表18.1：SnowFlock虚拟机克隆API

API简化了编组消息，同时传递给XenStore，Xen通过共享内存的低吞吐量接口来控制平面交易。在hypervisor上运行的一个SnowFlock本地守护进程（SFLD）执行监听这样的请求，包括消息解组，执行，并要求回调。

通过API，程序可以直接控制虚拟机的克隆。API编程语言包括C，C + +，Python和Java。我们既可以使用shell脚本执行程序，也可以使用所提供的命令行脚本。并行框架（如MPI）可以嵌入到API中：MPI程序就可以使用SnowFlock了，且并不需要修改源代码。置于Web服务器或应用服务器前的负载平衡器可以使用API克隆他们所管理的服务器。

SFLDs协调虚拟机克的隆执行请求。他们创建和传输架构描述器，创建克隆的虚拟机，启动磁盘和内存的服务器，并启动memtap辅助进程。他们是分布在一个物理集群系统上负责管理虚拟机的一个微型发布系统。

SFLDs推迟分配的决策给一个集中SnowFlock的主守护进程（SFMD）。SFMD使用相应的集群管理软件简化了接口。我们没有看到任何需求需要推倒重来，包括资源分配，配额，策略等，例如Sun的网格引擎或平台的EGO等都是适合的。

18.7.2必要的突变

克隆后，大多数克隆的虚拟机进程不再是父节点，而且他们现在运行在一个副本上。在大多数情况下，这是正常的，没有问题。毕竟，操作系统的主要任务是从低层次的细节（如网络标识）隔离应用程序。然而，平稳过渡需要一套有效的机制。如果管理在克隆的网络身份以避免冲突和混乱，我们就必须引入在克隆过程中的轻微突变。此外，因为这些调整可能需要更高级别的权限，所以允许用户配置一个钩子程序来插入到任何必要的任务中，例如依靠克隆的身份安装网络文件系统。

克隆的产生有可能是不必要的。尽管父虚拟机可能是由DHCP服务器管理的网络的一部分，或系统管理员通过其他各种途径能够做到克隆的IP地址分配。为了保持灵活的应用场景，我们将父节点和所有克隆置于虚拟的私有网络中。从同一父节点的克隆都分配一个唯一的ID，他们的IP地址在这个私有网络中被自动设置后，克隆的ID生效。这保证了不需要系统管理员的干预参与，而且没有IP地址冲突。

我们通过一个钩子程序在虚拟的网络驱动程序直接对IP进行重新配置。然而，我们也催动驱动程序自动生成合成的DHCP响应。因此，无论你如何分发，虚拟的网络接口将确保正确的IP地址传播到客户机操作系统，甚至当你重新启动主机是都可以。

为了防止来自不同父母的克隆碰撞以及隔离彼此的虚拟专用网络，可以防止相互DDoS攻击克隆虚拟网络的以太网（或第二层交换）。我们劫持了以太网MAC OUIs范围3，奉献他们的克隆。OUI将是一个父虚拟机的功能。像通过一个虚拟机的ID确定其IP地址一样，这同样决定了其非OUI的以太网MAC地址。虚拟的网络驱动器具有将虚拟机的MAC地址转换成它所分配虚拟机ID的功能，过滤出所有虚拟专用网络与不同OUI们的流量。这种隔离是通过 ebtables简单实现的。

让彼此克隆间通信可能是有趣的，但不是情趣盎然。有时我们会想让克隆响应来自互联网的HTTP请求，或连接公共数据仓库。我们为虚拟机的任何一套父节点和克隆配备一个专用的路由器。这个路由器的小虚拟机执行从克隆到互联网的防火墙，节流和NAT的功能。这也限制了父虚拟机的接入连接和众所周知的端口。路由器的虚拟机是轻量级的，但代表了网络流量的集中化，从而严重限制了可伸缩性的单点。相同的网络规则，可用于每个克隆虚拟机运行主机的一个分布式环境。我们还没有发布这个实验室补丁。

SFLDs分配了虚拟机ID，并指导虚拟网络驱动程序应该如何配置自己内部的MAC和IP地址，DHCP指令，路由器虚拟机的坐标，过滤规则，等等。

18.8结论

通过调整Xen hypervisor和延迟转移虚拟机的状态，SnowFlock可以在几秒钟内产生几十个运行中的虚拟机克隆。SnowFlock克隆虚拟机的瞬时性和热加载极大地改善了自动化集群管理的可用性和为应用提供云资源的更大可编程性。SnowFlock也提高了云的灵活性，虚拟机实例加快了20倍，并通过利用他们的父节点内存中的操作系统和应用程序缓存提高了最新创建的虚拟机的性能。SnowFlock高效性能的关键是启发式，避免了不必要的页面抓取，组播系统，让克隆们合作预取它们的状态。它是巧妙应用了一些尝试和真正的技术，一些技巧，以及一些工业界调试的慷慨帮助。

我们认识到整个SnowFlock经历了两个重要的教训。首先是经常被低估的价值KISS定理。我们期待实现复杂的预取技术，以减轻一连串的内存页在克隆启动时会发出的请求。令人惊讶的是这也许没有必要。该系统作为以一个单一原则为基础的许多工作有很好的表现：只是带来了超出需要的内存。简单化的另一个例子是内存页位图。通过一个简单的数据结构和清晰的原子访问语义，这大大简化了由于多个虚拟CPU，页面更新的竞争，通过多播的异步页到达等可能产生的并发性问题。

第二个教训是规模不再是谎言。换句话说，你发现每次你都会碰到准备切换系统和新出现瓶颈的规模性问题。这是紧密联系在一起的教训：随着负载的增加，简单而优雅的解决方案使规模化隐藏了起来。这个原则的一个最好的例子是mcdist系统。在大规模的测试表明，一个以TCP / IP为基础的页面分配机制进行数百克隆时经常惨遭失败。mcdist凭借其极端的分发机制和角色良好定义的获得了成功：客户只关心自己的内存页，服务器只关心维持一个全局的流量控制。保持mcdist优雅简单，使SnowFlock能够扩展得非常好。

如果你有兴趣了解更多，您可以访问网站多伦多大学的网站1获得在GPLv2授权许可下的学术论文和开放源码，GridCentric 4为一个工业化的实现。

注：

1. http://sysweb.cs.toronto.edu/projects/1

2. http://www.gridcentriclabs.com/architecture-of-open-source-applications

3. OUI：MAC地址分配的范围。

4. http://www.gridcentriclabs.com/