警告

NOTICE: THIS DOCUMENTATION SITE HAS BEEN SUPERSEDED.

For the current documentation site goto: http://docs.cloudstack.apache.org

使用存储

存储概述

CloudStack定义了两种存储:主存储和辅助存储。主存储可以使用iSCSI或NFS协议。另外,直接附加存储可被用于主存储。辅助存储通常使用NFS协议。

CloudStack不支持临时存储。所有节点上的所有卷都是持久存储。

主存储

本章节讲述的是关于CloudStack的主存储概念和技术细节。更多关于如何通过CloudStack UI安装和配置主存储的信息,请参阅安装向导。

“关于主存储”

主存储的最佳实践

  • 主存储的速度会直接影响来宾虚机的性能。如果可能,为主存储选择选择容量小,转速高的硬盘或SSDs。

  • CloudStack用两种方式使用主存储:

    静态:CloudStack管理存储的传统方式。在这个模式下,要给CloudStack预先分配几个存储(比如一个SAN上的卷)。然后CloudStack在上面创建若干个卷(可以是root和/或者数据盘)。如果使用这种技术,确保存储上没有数据。给CloudStack添加存储会销毁已存在的所有数据。

    动态:这是一个比较新的CloudStack管理存储的方式。在这个模式中,给CloudStack使用的是一个存储系统(但不是预分配的存储)。CloudStack配合存储一起工作,动态的在存储系统上创建卷并且存储系统上的每个卷都映射到一个CloudStack卷。这样做非常有利于存储的QoS。目前数据磁盘(磁盘方案)支持这个特性。

Runtime Behaviour of Primary Storage

当创建虚拟机的时候,root卷也会自动的创建。在VM被销毁的时候root卷也会被删除。数据卷可以被创建并动态的挂载到VMs上。VMs销毁时并不会删除数据卷。

管理员可以监控主存储设备的容量和在需要时添加其他的主存储。强参阅高级安装指导。

管理员通过CloudStack创建存储池来给系统添加主存储。每个存储池对应一个群集或者区域。

对于数据磁盘,当一个用户执行一个磁盘方案来创建数据磁盘的时候,初始化信息就被写到了CloudStack的数据库中。根据第一次给VM附加数据磁盘的请求,CloudStack决定这个卷的位置和空间占用在哪个存储(预分配存储和存储系统(比如SAN)中的任意一种,这取决于CloudStack使用的哪种主存储)。

Hypervisor对主存储的支持

下表显示了针对不同Hypervisors的存储选项和参数。

存储媒介 \ hypervisor VMware vSphere Citrix XenServer KVM Hyper-V
磁盘、模板和快照的格式 VMDK VHD QCOW2 不支持VHD快照。
支持iSCSI VMFS 集群化的LVM 支持,通过Shared Mountpoint
支持FC VMFS 支持,通过已有的SR 支持,通过Shared Mountpoint
支持NFS
支持本地存储
存储超配 NFS 和 iSCSI NFS NFS
SMB/CIFS
Ceph/RBD

XenServer通过在iSCSI和FC卷上使用集群化的LVM系统来存储VM镜像,并且不支持存储超配。尽管存储本身支持自动精简配置。不过CloudStack仍然支持在有自动精简配置的存储卷上使用存储超配。

KVM支持 “Shared Mountpoint”存储。Shared Mountpoint是群集中每个服务器本地文件系统中的一个路径。群集所有主机中的该路径必须一致,比如/mnt/primary1。并假设Shared Mountpoint是一个集群文件系统如OCFS2。在这种情况下,CloudStack不会把它当做NFS存储去尝试挂载或卸载。CloudStack需要管理员确保该存储是可用的。

在NFS存储中,CloudStack管理超配。这种情况下,使用全局配置参数storage.overprovisioning.factor来控制超配的范围。且不受hyperviso类型约束。

在vSphere, XenServer和KVM中,本地存储是一个可选项。当选择了使用本地存储,所有主机会自动创建本地存储池。想要系统虚拟机 (例如虚拟路由器)使用本地存储,请设置全局配置参数system.vm.use.local.storage为true.

CloudStack支持在一个群集内有多个主存储池。比如,使用2个NFS服务器提供主存储。或原有的1个iSCSI LUN达到一定容量时再添加第二个iSCSI LUN。

存储标签

存储是可以被”标签”的。标签是与主存储、磁盘方案或服务方案关联的字符串属性。标签允许管理员给存储添加额外的信息。比如”SSD”或者”慢速”。CloudStack不负责解释标签。它不会匹配服务和磁盘方案的标签。CloudStack要求在主存储上分配root或数据磁盘之前,所有服务和磁盘方案的都已存在对应的标签。服务和磁盘方案的标签被用于识别方案对存储的要求。比如,高端服务方案可能需要它的root磁盘卷是”快速的”

标签,分配,跨集群或机架的卷复制之间的关系是很复杂的。简单的环境就是在一个机架内所有集群的主存储使用相同的标签。即使用这些标签表示不同设备,展现出来的标签组仍可以是一样的。

主存储的维护模式

主存储可以被设置成维护模式。这很有用,例如,替换存储设备中坏的RAM。对存储设备的维护模式将首先停止任何新的来自预处理的来宾虚机,然后停止所有有数据卷的来宾虚机。当所有来宾虚机被停止的时候,这个存储设备就进入维护模式了并且可以关机。当存储设备再次上线的时候,你可以对这个设备取消维护模式。CloudStack将返回在线状态并且试着启动所有曾在这个设备进入维护模式前运行的来宾机器。

辅助存储

本章节讲述的是关于CloudStack的辅助存储概念和技术细节。更多关于如何通过CloudStack UI安装和配置主存储的信息,请参阅高级安装向导。

“关于辅助存储”

使用磁盘卷

卷为来宾虚机提供存储。卷可以作为root分区或附加数据磁盘。CloudStack支持为来宾虚机添加卷。

不同的hypervisor创建的磁盘卷有所不同。当磁盘卷被附加到一种hypervisor的虚拟机(如:xenserver),就不能再被附加到其他类型的hypervisor,如:vmware、kvm的虚拟机中。因为它们所用的磁盘分区模式不同。

CloudStack定义一个卷作为来宾虚机的一个有效的存储单元。卷可能是root磁盘或者数据磁盘。root磁盘在文件系统中有 “/” 并且通常用于启动设备。数据磁盘提供额外的存储,比如:”/opt”或者”D:”。每个来宾VM都有一个root磁盘,VMs可能也还有数据磁盘。终端用可以给来宾VMs挂在多个数据磁盘。用户通过管理员创建的磁盘方案来选择数据磁盘。用户同样可以在卷上创建模板;这是标准私有模板的创建流程。针对不同的hypervisor卷也不同:一个hypervisor类型上的卷不能用于其它的hypervisor类型上的来宾虚机。

注解

CloudStack supports attaching up to

  • 13 data disks on XenServer hypervisor versions 6.0 and above, And all versions of VMware.
  • 64 data disks on Hyper-V.
  • 6 data disks on other hypervisor types.

创建新卷

你可以在符合你存储能力的情况下随时向来宾虚拟机添加多个数据卷。CloudStack的管理员和普通用户都可以向虚拟机实例中添加卷。当你创建了一个新卷,他以一个实体的形式存在于CloudStack中,但是在你将其附加到实例中之前他并不会被分配实际的物理空间。这个优化项允许CloudStack提供最接近来宾虚机的卷,并在第一个附加至虚机的时候使用它。

使用本地存储作为数据卷

您可以将数据盘创建在本地存储上(XenServer、KVM和VMware支持)。数据盘会存放在和所挂载的虚机相同的主机上。这些本地数据盘可以象其它类型的数据盘一样挂载到虚机、卸载、再挂载和删除。

在不需要持久化数据卷和HA的情况下,本地存储是个理想的选择。其优点包括降低磁盘I/O延迟、使用廉价的本地磁盘来降低费用等。

为了能使用本地磁盘,区域中必须启用该功能。

您可以为本地存储创建一个数据盘方案。当创建新虚机时,用户就能够选择该磁盘方案使数据盘存放到本地存储上。

你不能将使用了本地存储作为磁盘的虚机迁移到别的主机,也不能迁移磁盘本身到别的主机。若要将主机置于维护模式,您必须先将该主机上所有拥有本地数据卷的虚机关机。

创建新卷

  1. 使用用户或管理员登录到CloudStack用户界面。

  2. 在左侧导航栏点击存储。

  3. 在选择视图中选择卷。

  4. 点击添加卷来创建一个新卷,填写以下信息后点击确定。

    • 名字。给卷取个唯一的名字以便于你以后找到它。
    • 可用的资源域。你想让这个存储在哪个地方有效?这个应该接近要是用这个卷的VM。(就是说你要 在单个资源域内使用这个存储就选择单个资源域,如果此存储要在多个资源与内共享你就选所有资源域)
    • 磁盘方案。选择存储特性。

    新建的存储会在卷列表中显示为“已分配”状态。卷数据已经存储到CloudStack了,但是该卷还不能被使用。

  5. 通过附加卷来开始使用这个卷。

上传一个已存在的卷给虚拟机

已存在的数据现在可以被虚拟机存取。这个被称为上传一个卷到VM。例如,这对于从本地数据系统上传数据并将数据附加到VM是非常有用的。Root管理员、域管理员和终端用户都可以给VMs上传已存在的卷。

使用HTTP上传。上传的卷被存储在区域中的辅助存储中。

如果预配置的卷已经达到了上限的话,那么你就不能上传卷了。默认的限制在全局配置参数max.account.volumes中设置,但是管理员同样可以为每个用户域设置不同于全局默认的上限值。请参阅设置使用限制。

要上传一个卷:

  1. (可选项)为将要上传的磁盘镜像文件创建一个MD5哈希(校验)。再上传数据磁盘之后,CloudStack将使用这个校验值来检查这个磁盘文件再上传过程中没有出错。

  2. 用管理员或用户账号登录CloudStack UI

  3. 在左侧导航栏点击存储。

  4. 点击上传卷。

  5. 填写以下内容:

    • 名称和描述。你想要的任何名称和一个简洁的描述,这些都会显示在UI中。

    • 可用的区域:选择你想存储卷的区域。运行在该区域中的主机上的VMs都可以附加这个卷。

    • 格式。在下面所指出的卷的磁盘镜像格式中选择一种。

      Hypervisor 磁盘镜像格式
      XenServer VHD
      VMware OVA
      KVM QCOW2
    • URL。CloudStack用来访问你的磁盘的安全HTTP或HTTPS URL。URL对应的文件种类必须符合在格式中选择的。例如,格式为VHD,则URL必须像下面的:

      http://yourFileServerIP/userdata/myDataDisk.vhd

    • MD5校验。(可选项)使用在步骤1中创建的哈希。

  6. 等到卷的上传显示完成。点击实例-卷,找到你在步骤5中指定的名称,单后确保状态是已上传。

附加一个卷

你可以通过附加一个卷来提供虚拟机的额外磁盘存储。当你第一次创建新卷,或移动已存在的卷到另一台虚拟机,或实在从另一个存储池迁移过来一个卷的时候你才可以附加一个卷。

  1. 使用用户或管理员登录到CloudStack用户界面。
  2. 在左侧导航栏点击存储。
  3. 在选择视图中选择卷。
  4. 在卷列表中点击卷的名称,然后点击附加磁盘按钮 Attach Disk Button.
  5. 在弹出的实例界面,选择你打算附加卷的那台虚拟机。你只能看到允许你附加卷的实例;比如,普通用户只能看到他自己创建的实例,而管理员将会有更多的选择。
  6. 当卷被附加之后,你通过点击实例看到实例名和该实例所附加的卷。

卸载和移动卷

注解

这个过程不同于从一个存储池移动卷到其他的池。这些内容在 `“VM存储迁移” <#vm-storage-migration>`_中有描述。

卷可以从来宾虚机上卸载再附加到其他来宾虚机上。CloudStack管理员和用户都能从VMs上卸载卷再给其他VMs附加上。

如果两个VMs存在于不同的群集中,并且卷很大,那么卷移动至新的VM上可能要耗费比较长的时间。

  1. 使用用户或管理员登录到CloudStack用户界面。
  2. 在左侧的导航栏,点击存储,在选择视图中选择卷。或者,如果你知道卷要附加给哪个VM的话,你可以点击实例,再点击VM名称,然后点击查看卷。
  3. 点击你想卸载卷的名字,然后点击卸载磁盘按钮。 Detach Disk Button.
  4. 要移动卷至其他VM,按照`“附加卷” <#attaching-a-volume>`_中的步骤。

VM存储迁移

Supported in XenServer, VMware and KVM

注解

这个过程不同于从一个虚拟机移动磁盘卷到另外的虚拟机。这些内容在 “查看挂载和移动卷” <#detaching-and-moving-volumes>`_中有描述。

你可以从同一区域中的一个存储池迁移虚机的root磁盘卷或任何其他的数据磁盘卷到其他的池

你可以使用存储迁移功能完成一些常用的管理目标。如将它们从有问题的存储池中迁移出去以平衡存储池的负载和增加虚拟机的可靠性。

在XenServer和VMware上,由于CloudStack支持XenMotion和vMotion,VM存储的在线迁移是启用的。在线存储迁移允许没有在共享存储上的VMs从一台主机迁移到另一台主机上。它提供选项让VM的磁盘与VM本身一起在线迁移。它让XenServer资源池之间/VMware群集之间迁移VM,或者在本地存储运行的VM,甚至是存储库之间迁移VM的磁盘成为可能,而且迁移同时VM是正在运行的。

注解

由于VMware中的限制,仅当源和目标存储池都能被源主机访问时才允许VM存储的在线迁移;也就是说,当需要在线迁移操作时,源主机是运行VM的主机。

For KVM, live storage migration is available from the 4.11 release and currently only supports migration from NFS/CEPH to SolidFire Managed Storage.

将数据卷迁移到新的存储池

当你想迁移磁盘的时候可能有两种情况:

  • 将磁盘移动到新的存储,但是还将其附加在原来正在运行的VM上。
  • 从当前VM上卸载磁盘,然后将其移动至新的存储,再将其附加至新的VM。
Migrating Storage For a Running VM on XenServer and VMware
  1. 使用用户或管理员登录到CloudStack用户界面。
  2. 在左侧的导航栏,点击实例,再点击VM名,接着点击查看卷。
  3. 点击你想迁移的卷。
  4. 从VM卸载磁盘。请参阅 “卸载和移动卷” 但是跳过最后的”重新附加”步骤。你会在迁移过后在新的存储上做这一步。
  5. 点击迁移卷按钮 button to migrate a volume. ,然后从下拉列表里面选择目标位置。
  6. 这期间,卷的状态会变成正在迁移,然后又变回已就绪。
Migrating Storage For a Running VM on KVM

KVM live storage migration is currently supported only from CEPH and NFS to SolidFire Managed Storage, and is currently only supported via API call (i.e. we can use CloudMonkey)

  1. Identify the VM UUID to be migrated.
  2. Identify the volume(s) UUID(s) which are attached to VM and needs to be migrated.
  3. Identify the SolidFire pool UUID to which you want to migrate VM’s volumes.
  4. Identify suitable KVM host UUID to which the VM will be live migrated.

Using CloudMonkey issue the command as in example given below:

migrateVirtualMachineWithVolume virtualmachineid=ec5d3a84-2eb8-4a37-83f3-007b5013e3d9
hostid=bee55404-68e9-4710-bb10-ab9f4a3d357d
migrateto[0].pool=67654174-e2b6-4734-813d-2a4f0b027c0d migrateto[0].volume=ea390749-0194-4088-860c-71717c4efabe
migrateto[1].pool=67654174-e2b6-4734-813d-2a4f0b027c0d migrateto[1].volume=3b37927b-2cd2-46d1-aeca-18d4af46bda2

In the command above, new volumes are being created on SolidFire Managed Storage, internal volume mirroring process is started via libvirt (from current storage NFS/CEPH to SolidFire) and at the end of the volume mirroring process, the VM live migration is done to the host defined above.

In the command above we have “pairing” of volume and the storage pool to which to migrate specific volume to. In example above, we are migrating 2 volumes to the same SolidFire Storage Cluster, but optionally you could migrate 2 volumes to 2 different SolidFire Storage Clusters.

Order of volumes, as attached to VM, is NOT relevant - i.e. first volume in the migration command ( migrateto[0].volume ) can be any DATA volume, while second volume ( migrateto[1].volume ) can be i.e. ROOT volume

You can migrate only some or all of the volumes (attached to specific VM) to a new Storage Pool.

Note, that depending on your configuration, you will need to change Compute/Data Disk Offerings, in case you have different storage tags set on CEPH/NFS versus tags on SolidFire (and in case your Compute/Data disk offerings reference these tags).

迁移存储和附加到不同的VM
  1. 使用用户或管理员登录到CloudStack用户界面。
  2. 从VM卸载磁盘。请参阅 “卸载和移动卷” 但是跳过最后的”重新附加”步骤。你会在迁移过后在新的存储上做这一步。
  3. 点击迁移卷按钮 button to migrate a volume. ,然后从下拉列表里面选择目标位置。
  4. 观察卷的状态会变成正在迁移,然后又变回已就绪。你可以点击左侧导航条中的存储找到卷。在选择查看的下拉列表中,确保卷显示在窗口的顶部。
  5. 在新的存储服务器中给运行在同一群集中的任何想要的VM附加卷。请参阅 “附加卷”

迁移VM的Root卷到新的存储池

(XenServer、VMware)你可以在停止VM的情况下,使用在线迁移将VM的root磁盘从一个存储池移动到另外一个。

(KVM)当前已root磁盘卷的时候,VM必须关机,这时用户不能访问VM。在迁移完成之后,VM就能重启了。

  1. 使用用户或管理员登录到CloudStack用户界面。

  2. 在左侧的导航栏里,点击实例,然后点击VM名。

  3. (仅限于KVM)停止VM。

  4. 点击迁移按钮 button to migrate a volume. ,然后从下拉列表中选择目标位置。

    注解

    如果VM的存储与VM必须一起被迁移,这点会在主机列表中标注。CloudStack会为你自动的进行存储迁移。

  5. 观察卷的状态会变成迁移中,然后变回运行中(或者停止,在KVM中)。这过程会持续一段时间。

  6. (仅限于KVM)重启VM。

重新规划卷

CloudStack提供了调整数据盘大小的功能;CloudStack借助磁盘方案控制卷大小。这样提供了CloudStack管理员可以灵活地选择他们想要给终端用户多少可用空间。使用相同存储标签的磁盘方案中的卷可以重新划分。比如,如果你只想提供 10,50和100GB的方案,重新划分允许的极限就不会超过这些。也就是说,如果你定义了10GB,50GB和100GB的磁盘方案,用户可以从10GB升级到50GB,或者从50GB升级到100GB。如果你创建了自定义大小的磁盘方案,那么你可以重新规划卷的大小为更大的值。

另外,使用 resizeVolume API,数据卷可以从一个静态磁盘方案移动到指定大小的自定义磁盘方案。此功能允对特定容量或磁盘方案进行收费,同时可以灵活地更改磁盘大小。

KVM, XenServer和VMware主机支持这个功能。但是VMware主机不支持卷的收缩。

在你试图重新规划卷大小之前,请考虑以下几点:

  • 与卷关联的VMs是停止状态。
  • 与卷关联的数据磁盘已经移除了。
  • 当卷缩小的时候,上面的磁盘会被截断,这么做的话可能会丢失数据。因此,在缩小数据磁盘之前,重新规划任何分区或文件系统以便数据迁移出这个磁盘。

要重新规划卷容量:

  1. 使用用户或管理员登录到CloudStack用户界面。

  2. 在左侧导航栏点击存储。

  3. 在选择视图中选择卷。

  4. 在卷列表中选择卷名称,然后点击调整卷大小按钮 button to display the resize volume option.

  5. 在弹出的调整卷大小窗口中,为存储选择想要的方案。

    option to resize a volume.

    1. 如果你选择自定义磁盘,请指定一个自定义大小。

    2. 点击是否确实要缩小卷大小来确认你要缩小的容量。

      此参数避免了不小心的失误造成数据的丢失。你必须知道你在做什么。

  6. 点击确定。

在VM重启时重设VM的root盘

你可以指定你想要放弃的root磁盘和创建一个新的,并且无论何时在VM重启时都使用新的。每次启动时都是一个全新的VM并且桌面不需要保存它的状态,出于安全环境考虑这非常有用。VM的IP地址在这个操作期间不会改变。

要启用在VM重启时重置root磁盘:

当创建一个新的服务方案时,设置isVolatile这个参数为True。从这个服务方案创建的VMs一旦重启,它们的磁盘就会重置。请参阅 “创建新的计算方案”

卷的删除和回收

删除卷不会删除曾经对卷做的快照

当一个VM被销毁时,附加到该VM的数据磁盘卷不会被删除。

使用回收程序后,卷就永久的被销毁了。全局配置变量expunge.delay和expunge.interval决定了何时物理删除卷。

  • expunge.delay:决定在卷被销毁之前卷存在多长时间,以秒计算。
  • expunge.interval:决定回收检查运行频率。

管理员可以根据站点数据保留策略来调整这些值。

使用卷快照

(支持以下hypervisors:XenServer, VMware vSphereKVM)

CloudStack支持磁盘卷的快照。快照为虚拟机某一时间点的抓取。内存和CPU状态不会被抓取。如果你使用Oracle VM hypervisor,那么你不能做快照,因为OVM不支持。

卷,包括root和数据磁盘(使用Oracle VM hypervisor除外,因为OVM不支持快照)都可以做快照。管理员可以限制每个用户的快照数量。用户可以通过快照创建新的卷,用来恢复特定的文件,还可以通过快照创建模板来启动恢复的磁盘。

用户可以手动或者设置自动循环快照策略创建快照。用户也可以从快照创建附磁盘卷,并像其他磁盘卷一样附加到虚机上。root和数据磁盘支持快照。但是,CloudStack目前不支持通过恢复的root盘启动VM。从快照恢复的root盘会被认为是数据盘;恢复的磁盘可以附加到VM上以访问上面的数据。

完整快照慧聪主存储拷贝到附加存储,并会一直存储在里面知道删除或被新的快照覆盖。

如何给卷做快照

  1. 是用用户或者管理员登录CloudStack。
  2. 在左侧导航栏点击存储。
  3. 在选择视图,确认选择的是卷。
  4. 点击你要做快照的卷的名称。
  5. 点击快照按钮。 Snapshot Button.

创建和保留自动快照

(支持以下hypervisors:XenServer, VMware vSphereKVM)

用户可以设置循环快照策略来自动的为磁盘定期地创建多个快照。快照可以按小时,天,周或者月为周期。每个磁盘卷都可以设置快照策略。比如,用户可以设置每天的02:30做快照。

依靠每个快照计划,用户还可以指定计划快照的保留数量。超出保留期限的老快照会被自动的删除。用户定义的限制必须等于或小于CloudStack管理员设置的全局限制。请参阅 “全局配置的限制”.。限制只能应用给作为自动循环快照策略的一部分的快照。额外的手动快照能被创建和保留。

增量快照和备份

创建的快照保存在磁盘所在的主存储。在创建快照之后,它会立即被备份到辅助存储并在主存储上删除以节省主存储的空间。

CloudStack给一些 hypervisors做增量备份。当使用了增量备份,那么每N备份就是一个完全备份。

  VMware vSphere Citrix XenServer KVM
支持增量备份

卷状态

当快照操作是由一个循环快照策略所引发的时候,如果从其上次创建快照后,卷一直处于非活跃状态,快照被跳过。如果卷被分离或附加的虚拟机没有运行,那么它就被认为是非活跃的。CloudStack会确保从卷上一次变得不活跃后,至少创建了一个快照。

当手动创建了快照,不管改卷是不是活跃的,快照会一直被创建。

快照恢复

有两种方式恢复快照。用户能够从快照中创建一个卷。卷可以随后被挂载到虚拟机上并且文件根据需要被复原。另一种方式是,模板可以从一个root 盘的快照创建。用户能够从这个模板启动虚拟机从而实际上复原root盘。

快照工作调节

当虚拟机需要快照时,VM所在的主机上就会运行快照工作,或者在VM最后运行的主机上。如果在一台主机上的VMs需要很多快照,那么这会导致太多的快照工作进而占用过多的主机资源。

针对这种情况,云端的root管理员可以利用全局配置设置中的concurrent.snapshots.threshold.perhost调节有多少快照工作同时在主机上运行。借助这个设置,当太多快照请求发生时,管理员更好的确认快照工作不会超时并且hypervisor主机不会有性能问题。

给concurrent.snapshots.threshold.perhost设置一个你结合目前主机资源和在主机上运行的VMs数量的最佳值,这个值代表了在同一时刻有多少快照工作在hypervisor主机上执行。如果一个主机有比较多的快照请求,额外的请求就会被放在等待队列里。在当前执行 的快照工作数量下降至限制值之内,新的快照工作才会开始。

管理员也可以通过job.expire.minutes给快照请求等待队列的长度设置一个最大值。如果达到了这个限制,那么快照请求会失败并且返回一个错误消息。

VMware卷快照性能

当你为VMware中的数据卷或root卷做快照时,CloudStack使用一种高效率的存储技术来提高性能。

快照不会立即从vCenter导出OVA格式文件到挂载的NFS共享中。这个操作会消耗时间和资源。相反的,由vCenter提供的原始文件格式(比如VMDK)被保留。OVA文件只有在需要的时候被创建。CloudStack使用与原始快照数据存储在一起的属性文件(*.ova.meta)中的信息来生成OVA。

注解

对于旧版本升级的客户:这个过程只适用于在升级到CloudStack 4.2之后新创建的快照。已经做过快照并且使用OVA格式存储的将继续使用已有的格式,并且也能正常工作。

Disk caching (KVM)

This is for advanced user only, since may cause issues with improper DB changes.

Disk cache mode is the property of Compute Offering (ROOT disk) and Disk Offering (DATA disk). Currently, disk cache mode can only be set by editing “disk_offering” table inside “cloud” DB and can not be done via API/GUI (although there is “Write-cache Type” filed in the GUI on the “Add Disk Offering” wizard). Cache modes available are: write-back and write-through

Before proceeding with changing cache mode on disks (Offerings), please make sure that you understand the consequences and limitations it might bring.

  1. If the guest storage is hosted on a clustered file system (or is read-only or is marked shareable), then the cache mode is ignored when determining if VM live migration can be allowed.
  2. If guest storage is hosted on shared storage (NFS/CEPH) libvirt will not allow VM live migration unless the cache mode is set to “none”.
  3. This means that in case of NFS and CEPH, VM live migrations will not be possible, and this will also make it impossible to put host into maintenance mode (VMs being live migrated away from this host - will not work)

In order to set disk write-back or write-through cache mode, we need to edit it’s parent Compute Offering (for ROOT disk) or Disk Offering (for DATA disks). Please note that this means that all volumes/disks which are created from specific offering will inherit cache mode.

mysql> select id from disk_offering where name="8vCPU-64GB-HDD-STD-NFS";
+-----+
| id  |
+-----+
| 111 |
+-----+
1 row in set (0.00 sec)
mysql> select id from disk_offering where name="100GB-HDD-STD-NFS";
+-----+
| id  |
+-----+
| 114 |
+-----+
1 row in set (0.00 sec)
mysql> UPDATE disk_offering SET cache_mode='writeback' WHERE id in ('111','114');
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2  Changed: 2  Warnings: 0

In example above, we have set the write-back cache mode for a single Compute Offering and single Disk Offering. In order for KVM to actually pick-up the cache mode we have set, we need to stop VM and start VM. VM Reboot (“Reboot Instance” button) via GUI will not be enough.

After VM is started we can confirm that the both the ROOT and DATA disk of a VM have cache mode set to write-back:

root@ix1-c7-4:~# virsh dumpxml i-2-10-VM | grep cache -A2
   <driver name='qemu' type='qcow2' cache='writeback'/>
   <source file='/mnt/63a3ae7b-9ea9-3884-a772-1ea939ef6ec3/1b655159-ae10-41cf-8987-f1cfb47fe453'/>
   <target dev='vda' bus='virtio'/>
   ...
   <driver name='qemu' type='qcow2' cache='writeback'/>
   <source file='/mnt/63a3ae7b-9ea9-3884-a772-1ea939ef6ec3/09bdadcb-ec6e-4dda-b37b-17b1a749257f'/>
   <target dev='vdb' bus='virtio'/>