51学通信论坛2017新版

标题: 确保KVM迁移完成的技术分析 [打印本页]

---

作者: admin    时间: 2017-11-15 21:51
标题: 确保KVM迁移完成的技术分析
原文地址：
https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/
正文
实时在线迁移是QEMU / KVM（以及其他虚拟化平台）长期支持的特性，但是，默认情况下它不能很好地处理内存写密集型的虚拟机（在线迁移）。要模拟一个默认配置不能完成迁移的高负荷的虚拟机非常容易。例如，一个持续不断的向1GB的内存区域中写入每个字节的虚拟机就不可能通过1Gb/s的NIC（网卡）成功迁移。即便使用10Gb/s的NIC（网卡），一个稍大的客户机就可以足够快的污染内存从而造成迁移后不可接受的大量停机时间。因此，多年来，QEMU一些可选功能已经开发以帮助完成迁移。
如果你不想读关于迁移功能和测试工具的背景信息，可以直接跳到文章底部的数据表，后面跟的是分析结果。
可用的技术

停机调优。除非客户机完全空闲，内存100%转移到目标主机的那个点是不可能达到的。因此，有必要决定在某一点是否足够的内存已被转移以在可接受的锁定期内允许切换到目标主机。停机的调优是在迁移时可以控制允许多久的停机时间。QEMU衡量它可实现的网络传输速率，和剩余内存对比来确定是否能在配置的停机时间窗口期内迁移。迁移时，直接设置QEMU使用可接受的最大停机时间是不可取的，因为那样只能保证能令虚拟机总是遭受最大停机时间锁定期。相反，最好以一个相当小的停机时间值开始，并随着时间的推移增加允许的停机时间。关键点是最大化类似的想法：可以在一个短暂的停机时间内完成迁移。
带宽调优。如果迁移发生在网卡用于其他非迁移相关的任务时，它应该会阻止迁移流占用所有带宽。如前所述，即使是相对较小的客户机也会足够快的搞乱内存，以致甚至10Gbs的网卡将无法完成迁移。因此，如果目的是最大限度地获得成功迁移的可能性，其目标应该是最大限度地提高迁移操作的网络带宽。基于这一点，不试图并发运行多个迁移操作是明智的，除非他们的传输速率表明他们并未耗尽可用带宽，因为并发迁移可能意味着都将不能完成迁移。
暂停CPUs。最简单的和最原始的保证客户机迁移完成机制就是暂停客户机的CPU。这阻止了客户机继续污染内存，即便在最慢的网络也能确保在有限的时间内完成迁移。代价是客户机的负载会完全停顿一个长期的时间。考虑一下为客户机设置一个相当于任意长的最大允许的停机时间。例如，假设有8 GB的RAM和一个空闲的10Gbs的网卡的客户机，在最坏的情况下暂停会导致约6秒的停机时间。如果速度更高的网卡可用，暂停的影响将减弱直至收敛于典型的最大停机时间设定。
自收敛性。客户机污染内存的速度与客户机的CPU被提交运行的时间有关。因此通过压制CPU执行时间可以阻止客户机将内存污染得如此之快，这让迁移数据传输得以抢在内存污染的前面。如果启用了此功能，默认情况下，QEMU以削减20%的客户机vCPU执行时间开始。在每次内存迭代的起始，它会检查前两个迭代的进展。如果进展不顺利，它将重复削减10%的许可给vCPU的运行时间。QEMU会一直削减CPU直至99%。这应该保证迁移可以在最缓慢的网络完全完成。但是以客户机的CPU性能的高消耗为代价。同时因为同样原因所有客户机的vCPUs都被不分青红皂白的削减了，即使只有一个客户机进程该为内存污染负责。
后拷贝。通常，当所有的内存都已被传输的情况下，只会在目标主机上运行。与后拷贝，目标是要传输“足够的”或“最”的内存，然后切换到目标上运行。当目标QEMU获取故障存储器页面尚未转移，它会显出来，从源QEMU页带的要求。因为它有可能在任何时候切换到拷贝模式，它避免了在一个固定的停机时间窗口内完成迁移的整个问题。成本是，虽然在后拷贝模式运行时，客户页面故障可能是相当昂贵的，因为有需要等待源主机将内存页转移到目标，这会影响性能的客户机在后拷贝阶段。如果在后拷贝模式中有一个网络中断，也不可能恢复。因为无论是源或目标主机有一个完整的视图的来宾内存，这将是必要的重新启动的客户机。
压缩。迁移页面通常照原样被转移到目标主机上。对于很多客户工作负载，内存页面内容很容易压缩。所以如果有在源主机上可用的CPU周期并且网络带宽是限制因素，为了压缩网络上传输的数据可能值得烧源主机的CPU。根据实现的压缩级别可使迁移完成。但是如果内存不是压缩友好的，消耗CPU周期没有任何好处。QEMU支持两种压缩方法，XBZRLE和多线程，两者都可启用。XBZRLE维护之前发送的内存页的缓存使其大小限定在客户机RAM的一定比例内。当一个页面被客户机弄脏，QEMU对比新的页面内容和缓存的页面内容，然后只发送增量的变化而不是整个页面。为使其高效缓存必须是相当大的，50%的客户机RAM才是合理的。另一种压缩方法是使用多线程，简单地使用zlib直接压缩整个内存页。这避免了需要维持一个庞大的以前的内存页的缓存，但它变得更CPU密集，除非硬件加速可用于zlib压缩算法。

衡量技术影响
了解各种技术是有益的能最大限度的提高迁移成功率，但很难预测在现实世界中当面对不同的工作负载表现如何。尤其是，事实上是否真的能够在最坏的工作负载情况下以及什么样水平的虚拟机负载的性能影响下确保完成。这是OpenStack Nova项目目前难以得到明确的答案的一个问题，以期提高Nova的libvirt迁移的管理。为了尝试并在这方面提供一些指导，我花了几个星期致力于涉及到上面概述的各种不同的迁移技术主题中的测试QEMU虚拟机性能的框架工作。
OpenStack的目标是使迁移成为一个对于云管理员来说可以完全“撒手不管”的操作。他们应该能够请求一个迁移，然后忘记它，直到它完成，而不必乖乖坐在那儿应用调整参数。另一个目标是，Nova API不必暴露任何虚拟机管理程序的具体概念如后拷贝，自动收敛，压缩，等等。必要时Nova自身决定使用哪种QEMU迁移特性并且只“做正确的事”来确保完成。无论选择什么方法必须能够应付任何类型的客户机的负载情况，因为云管理员将不能查看实际运行在客户机上的任何应用程序。有了这个想法，当测试QEMU迁移特性的性能时就要去看当面对最坏的情况下他们的行为。因此要写这样一个压力程序，它可以分配大量内存，然后每个VCPU产生一个线程从/dev/random获取字节簇永远循环xor'ing到内存的每个字节。这确保了客户机读取和写入到内存工作都很繁重，同时创建对压缩不友好的内存页。该压力程序被静态链接为初始化程序编译进ramdisk，以使Linux启动那一瞬间即运行该压力负荷。为了衡量客户机的性能，每1GB的内存改动，程序会输出关于更新这个GB花费的时间长度和绝对时间戳的细节。这些记录从客户机的串口控制台捕获，后来与主机侧关于迁移发生了什么形成关联。
接下来是时候创建一个工具来控制主机的QEMU和管理迁移过程，激活所需的功能。定义一个测试方案，它编码的细节是迁移的什么功能将被测试以及设置（激活后拷贝之前迭代次数，带宽限制，最大停机时间值，压缩线程数等）。硬件配置定义了扩展运行测试的虚拟机的硬件特性（vCPU数量，内存大小，主机NUMA内存和CPU绑定，大页面的使用，内存锁定，等）。测试/迁移/guestperf.py工具提供了在任何可能的配置调用测试机制。例如，为测试后拷贝迁移，3次迭代后切换到后拷贝，给定1Gbs带宽具有4个vCPU和8GB内存的客户机上可以运行
$ tests/migration/guestperf.py --cpus 4 --mem 8 --post-copy--post-copy-iters 3 --bandwidth 125 --dst-host myotherhost --transport tcp--output postcopy.json
Myotherhost.json文件包含测试结果的完整报告。包括测试方案和硬件配置的所有细节，在每次迭代起始时的迁移状态记录，每秒一次主机处理器的使用量记录，以及客户机压力测试输出。伴随测试/迁移/guestperf-plot.py工具可以使用该数据文件生成交互式HTML图表说明结果。
$ tests/migration/guestperf-plot.py --split-guest-cpu --qemu-cpu--vcpu-cpu --migration-iters --output postcopy.html postcopy.json
然而，为了协助进行运行间比较，也定义了可通过测试/迁移/guestperf-batch.py工具运行的一组标准化的测试方案，在这种情况下，仅要求提供所需的硬件配置
$ tests/migration/guestperf-batch.py --cpus 4 --mem 8 --dst-hostmyotherhost --transport tcp --output myotherhost-4cpu-8gb
这将运行所有的标准定义的测试方案并在myotherhost-4cpu-8gb目录下保存很多数据文件。同样的guestperf-plot.py工具可用于同时创建结合多个数据集的图表便于比较。
QEMU 2.6 的性能结果
用上面写的工具，我打算运行一些针对QEMU Git主代码库的测试，这同刚刚发布的QEMU 2.6代码一样有效。主机对采用戴尔PowerEdge R420服务器具有8 CPU，24GB RAM，在2个NUMA节点传播。主网卡是Broadcom Gigabit，但它被Mellanox 10-Gig-E RDMA能力的网卡增强了，为迁移数据的传输而挑选。为了测试我决定为两个不同的硬件配置收集数据，一个小的单处理器的客户机（1个vCPU和1 GBRAM ）和一个中等大小的多处理器的客户机（4个vCPU和RAM 8 GB）。指定内存和CPU绑定，如此客户机都局限于单个NUMA节点避免交叉NUMA节点的内存访问影响性能测量的准确性。主机和客户机都运行RHEL-7 3.10.0-0369.el7.x86_64内核。
为了解不同网络传输的延迟特性的影响，两者的硬件配置组合扩展到了针对4种不同的网络配置–本地UNIX传输，本地TCP传输，远程10Gbs的TCP传输和远程运输10Gbs的RMDA传输。
全套结果与后续的表格相关联。每一行中的第一个链接都给出了一个在该行中的每个方案的一个客户处理器的性能比较。该行中的其他单元格为特定方案提供了完整的主机和客户机的性能细节
UNIX socket, 1 vCPU, 1 GB RAM
使用UNIX套接字迁移到本地主机，客户机配置为1 vCPU，1 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

UNIX socket, 4 vCPU, 8 GB RAM
使用UNIX套接字迁移到本地主机，客户机配置为4 vCPU，8 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

TCP socket local, 1 vCPU, 1 GB RAM
使用TCP套接字迁移到本地主机，客户机配置为1 vCPU，1GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

TCP socket local, 4 vCPU, 8 GB RAM
使用TCP套接字迁移到本地主机，客户机配置为4 vCPU，8 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

TCP socket remote, 1 vCPU, 1 GB RAM
使用TCP套接字迁移到本地主机，客户机配置为1 vCPU，1 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

TCP socket remote, 4 vCPU, 8 GB RAM
使用TCP套接字迁移到远程主机，客户机配置为4 vCPU，8 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

RDMA socket, 1 vCPU, 1 GB RAM
使用RDMA套接字迁移到远程主机，客户机配置为1 vCPU，1 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

RDMA socket, 4 vCPU, 8 GB RAM
使用RDMA套接字迁移到远程主机，客户机配置为4 vCPU，8 GB RAM

Scenario	Tunable
Pause unlimited BW	0 iters	1 iters	5 iters	20 iters
Pause 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Post-copy unlimited BW	0 iters	1 iters	5 iters	20 iters
Post-copy 5 iters	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
Auto-converge unlimited BW	5% CPU step	10% CPU step	20% CPU step
Auto-converge 10% CPU step	100 mbs	300 mbs	1 gbs	10 gbs	unlimited
MT compression unlimited BW	1 thread	2 threads	4 threads
XBZRLE compression unlimited BW	5% cache	10% cache	20% cache	50% cache

结果分析
上面的图表提供了完整的原始结果，欢迎你得出自己的结论。试验控制也张贴在QEMU开发邮件列表并有望被合并到Git，所以任何人都可以重复试验或运行测试比较其他方案。下面是我的解释以及由此展现的有趣的点。

虚拟机的性能在每个迁移迭代的开始都有一个一致清晰的周期模式。尤其是在每一次迭代开始时，客户机CPU有一个显著的连续短暂性能下降。摘例一个效果明显的——1个vCPU，1GB 内存配置为“暂停5次迭代，300mbs”的测试——我们可以看到客户机的CPU性能从200ms/GB的数据修改，下降到450ms/GB。QEMU维护一个与客户机内存相关的位图来追踪执行迁移时被客户机的脏页。在每次内存迭代的开始，这个位图必须被读取并重置，这个动作该为瞬间下降的性能负责。
随着更大的虚拟机规模，客户机的性能有第二个大致具周期性但稍微有点混乱的模式持续整个迁移过程。这些尖峰的幅度约为发生在每一次迭代开始时的幅度的1/2，这种效果的一个明显例子是4个vCPU，8GB内存配置为“暂停无限带宽、20次迭代”的测试——我们可以看到客户机的CPU性能是从500ms/GB下降至700ms/GB和800ms/GB之间。限定于有4个CPU的客户机的NUMA节点主机和客户机本身有4个CPU。当迁移执行时，QEMU有专门的线程用来执行迁移数据I/O，这在4个主机CPU和客户机CPU之间共享时间。所以QEMU模拟器线程和vCPU线程共享相同的pCPUs，我们有5个工作负载竞争4个CPU。贯穿整个迁移迭代的客户机性能中的频繁的微微混乱的尖峰是由于过量使用主机pCPUs。尖峰的大小直接与迁移所允许的总传输带宽成正比。这并不是一个迁移固有的问题–如果想要强行隔离客户机负载和迁移进程，可以把QEMU模拟器线程放到有别于vCPU线程的单独pCPU上。
1 vCPU, 1 GB RAM的客户机与4 vCPU 8 GB RAM的客户机基准性能不同。比较1个vCPU和4个vCPU配置的UNIX套接字“暂停无限带宽、20次迭代”的测试结果我们看到前者的基准性能是200ms/GB的数据修改，后者是400ms/GB的数据修改。这显然与迁移一点都没有关系。天真的人可能会认为，从1个vCPU到4个vCPU会导致性能翻4倍，因为我们有4倍多的线程用来工作。我们在这里看到的可能是命中内存带宽限制的结果，所以每个vCPU竞争内存带宽，因此每个VCPU的整体性能有所下降。这样反而让从1到4个vCPU本可x4的性能只翻了一番。
当后拷贝在其预拷贝阶段时，没有相较于未启用后拷贝时对客户机性能的可衡量的影响。这可以通过比较TCP套接字“暂停5次迭代，1Gbs”的试验结果与“后拷贝5次迭代，1 Gbs”测试结果来看到。在每一次迭代开始两者都显示相同的基准客户机的CPU性能和相同大小的尖峰。这表明，无条件地启用所有的迁移操作的后拷贝功能是切实可行的，即使无需从预拷贝到后拷贝阶段切换迁移也是有可能完成的。它提供了管理/应用程序的灵活性来动态地决定是否切换到后拷贝模式或留在预拷贝模式，直到完成。
当后拷贝的迁移从它的预拷贝阶段到后拷贝阶段转换时，客户机的CPU性能有一个主要但短暂的尖峰。这里发生的是，当客户机可能有80%的内存转移到目标主机时，后拷贝阶段开始，但客户机的工作负载仍然在碰源上的一些页面文件，所以页面错误不得不等待页面通过网络被转移。后拷贝阶段的峰值和持续时间的大小与总的客户机的内存大小和可用带宽有关。以远程TCP例1个vCPU，1 GB的RAM的硬件配置清晰，对比“后拷贝5次迭代，1Gbs”的场景与“后拷贝5次迭代，10Gbs”的场景，我们可以看到客户机性能的尖峰幅度在这两种情况下是同样大小的。在10Gbs的案例中每一次迭代的预拷贝阶段的总时间明显更短。如果我们进一步比较本地的UNIX域套接字，我们可以看到性能尖峰在后拷贝阶段更低。这告诉我们的是，在后拷贝阶段的尖峰幅度很大程度上是由从源到目标转移的带外请求的页面延迟驱动的，而不是整体可用带宽。QEMU计划允许迁移使用多个TCP连接，这可以显著降低后拷贝延迟峰，因为带外请求的页面将不会停滞在一长串TCP后台批量拷贝传输队列之后。
对于较大的客户规模或当带宽有限时自动收敛往往会很努力地确保收敛。考虑4个vCPU，8 GB的RAM远程TCP测试，对比不同带宽限制的效果，我们可以看到10Gbs的带宽上限，自动收敛了削减到80%来让迁移完成，而其他的试验表明，在某些情况下高达95%甚至99%。更低的带宽限制1Gbs，测试用例运行5分钟后超时，仅仅尝试削减20%，显示面对低带宽链路自动收敛几乎没有足够的侵略性。最坏的情况下，当运行自动收敛的CPU削减到80%客户机性能等同于切换到后拷贝阶段后立即后拷贝。不同的是，自动收敛显示，最坏情况在预拷贝期间命中很长一段时间，潜伏多分钟，而后拷贝只显示了几秒钟。
多线程压缩对成功迁移的机会是有害的。考虑4个vCPU，8 GB的RAM远程TCP测试对比线程计数，我们可以看到，增加线程数量实际上使得性能更差，5分钟超时来临前内存迭代次数更少了。每一次迭代的时间越长，客户机就有越多时间搞脏内存，迁移越不可能完成。此处有两个因素被认为使得MT压缩的结果如此糟糕。第一，正如前面提到的QEMU限于4 pCPUs，所以4 vCPUs运行时压缩线程不得不与vCPU线程争时间而减缓了压缩速度。客户机上运行的的压力测试工作负载一直在向内存写入完全随机字节，这对压缩来说是一个病态的的输入数据集，几乎不允许被压缩。但是假设这样一个事实该压缩是CPU限制的，即使压缩比率良好也不太可能有显著的收益，由于迭代内存而增加的时间使客户机得以搞脏更多数据而终结压缩的优势。如果QEMU模拟器线程能使用专有的主机pCPUs来运行在某种程度上是会提高性能的，但那需要假设主机有未运行其他客户机的空闲CPU。
XBZRLE压缩表现优于MT压缩一点。再来考虑4个vCPU，8 GB的RAM远程TCP测试比较内存缓存大小，我们可以看到每次迭代内存所需的时间并没有明显的增加。这表明，虽然XBZRLE压缩对于客户机的CPU性能有显著的影响，相较于MT压缩来说每个页面处理过程中并未看到主要瓶颈。然而再次，它并没有帮助实现迁移完成，5分钟或30次迭代内存后所有测试都超时了。这是由于这样的事实，客户机的压力负载再一次传输输入数据击中了算法里最异常病态糟糕的情况。面对这样的工作负载，无论多么多的CPU时间和内存缓存可用，XBZRLE都不可能对迁移产生积极作用。
·RDMA数据传输出现一些怪癖。首先，通过查看RDMA结果比较暂停带宽，我们可以清楚地识别QEMU的RDMA实现的一个bug–不遵守请求的带宽限制–总是以最大链路速度传输。其次，所有后拷贝结果显示失败，确认后拷贝目前不兼容RDMA迁移。当比较10Gbs的RDMA和10Gbs的TCP传输，使用RDMA没有明显优势–在任何的测试场景都不可能完成迁移。

综合测试的所有不同功能，显然后拷贝是赢家。它每次都能够保证完成迁移，无论客户机的内存大小与对客户机的性能最小的持久影响。虽然它确实在从前拷贝到后拷贝阶段切换时有一个显着的尖峰影响客户机的性能，这种影响是短暂的，只有几秒钟。下一个最好的结果是自动收敛，在大多数情况下成功完成迁移。通过与后拷贝比较，最坏的情况下影响客户机的CPU性能的幅度大小相同，但它持续了很长一段时间，几分钟长。此外，更高带宽限制的场景下，自动收敛无法足够快地削减客户机CPU以避免碰到整个5分钟的超时，而后拷贝总能成功除了在最有限的带宽情况下（100M–没策略能）。后拷贝的另一个好处是，只有对页面故障负责的操作系统线程被延迟了，如果客户操作系统上的其他线程的RAM已经在主机上，他们将继续以正常速度运行。使用自动收敛，所有客户机的CPU和线程都被削减，不论他们是否该对脏页负责。IOW后拷贝具有有目标的性能损失，而自动收敛是无差别的。最后，正如前面提到的，后拷贝确实有故障的情况，如果到源主机的网络连接丢失时间太久造成TCP连接超时会导致在后拷贝模式下失去VM。这种风险可以通过网络层冗余减轻，而且风险只存在客户机运行在后拷贝模式下短期时间，这在10Gbs的链接中只有短短的几秒钟。
预计压缩功能在给定的客户机的工作量下会相当糟糕，但影响远比预期要更糟，特别是MT压缩。假定主要要求是压缩主机CPU时间（MT压缩）或主机RAM（XBZRLE压缩），它们都不是可用的普适特性。他们应该只被使用在工作负载是压缩友好的，主机有CPU和/或RAM资源分配，并且后拷贝和自动收敛都不可用的情况下。为了使这些功能的使用在一个自动化的通用方式更加实用，QEMU将被增强允许管理应用在迁移中可以直接控制打开或关闭他们。这将允许应用程序尝试使用压缩，监控其效率，然后如果它是有害的就关闭压缩，而不是不得不放弃整个迁移并重新启动迁移。
对RDMA研究范围需要有进一步的测试，因为用于测试的硬件上限10Gbs。新的RDMA硬件应该是能够达到更高的速度，40Gbs，甚至100Gbs，这可能会对迁移能力有一个相对积极的影响。但是至少在任何不高于10Gbs的速度，似乎不值得使用RDMA，应用应该是将使用TCP与后拷贝联合起来。
在网络I/O方面，不管什么样的客户机工作负载，QEMU一般能够充分占满带宽直至完成。很容易创造永远不会完成的负载，并且减少可用带宽，只会增加迁移的机会。有个想法很诱人，如果你有2个客户机，它会采取相同的总时间，无论你是否一个接一个地迁移他们，或平行地迁移他们。但这并不是必然的，因为平行迁移带宽将在他们之间共享，这增加了两个客户机都将永远不会完成的几率。所以，作为一般规则，序列化给定主机上的所有迁移操作似乎是明智的，除非有多个网卡可用。
总之，如果可行，使用后拷贝，否则使用自动收敛。别惹压缩，除非负载已知为非常压缩友好的。别惹RDMA除非它支持超过10Gbs，否则坚持普通的TCP。

声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。

---

欢迎光临 51学通信论坛2017新版 (http://bbs.51xuetongxin.com/)

Powered by Discuz! X3