计算虚拟化是将物理服务器资源通过虚拟化技术抽象成逻辑资源，让一台物理服务器变成多台相互隔离的虚拟服务器，CPU、内存、磁盘、I/O设备等硬件资源变成虚拟化资源池进行统一动态管理，从而提高资源利用率，降低系统管理成本，让IT对业务变化更具适应力。

如图 1所示：

ZStack ZSphere支持采用基于KVM的硬件虚拟化技术。KVM是一个Linux内核模块，将Linux内核变成一个Hypervisor。KVM在Linux系统内以进程形式出现，由标准Linux调度程序进行调度，因此KVM能够使用Linux内核已有功能，例如：内存管理、CPU调度等。但是，KVM本身仅提供CPU与内存虚拟化，I/O设备虚拟化需结合Qemu才能完成。Qemu是一个用户态的设备模拟器，为虚拟机提供虚拟设备模型，负责各种虚拟设备的创建、调用及管理。

如图 2所示：

在x86体系架构上，CPU一般有4个特权级别：RING0~RING3，用于给操作系统和应用程序访问硬件。在Linux中，仅使用其中2个特权级别：RING0（内核态）、RING3（用户态）。

关于VMX根模式与VMX非根模式。对于硬件辅助虚拟化而言，为能在不对操作系统做任何修改的前提下使用虚拟机，CPU引入2种运行模式：VMX根模式、VMX非根模式。宿主机运行在根模式下，宿主机内核处于RING0，用户态程序处于RING3。虚拟机运行在非根模式下，虚拟机内核处于RING0，用户态程序处于RING3。

关于VM Exit与VM Entry。处于非根模式的虚拟机，当外部中断或缺页异常，或主动调用VMCALL指令来调用VMM服务时，CPU会从非根模式切换至根模式，整个过程称为VM Exit。相反，当VMM通过显式调用VMLAUNCH或VMRESUME指令切换至非根模式时，硬件自动加载虚拟机上下文，运行虚拟机指令，这一转换称为VM Entry。

如图 1所示：

当虚拟机通过VM Exit从非根模式退出至根模式后，KVM会根据退出原因执行进一步操作，若是I/O操作则交由QEMU处理，若是非I/O操作则由KVM自行处理，处理完成后通过VM Entry再次切入非根模式运行。

如图 2所示：

虚拟机管理器（VMM）负责管理和分配每个虚拟机的物理内存。虚拟机操作系统看到的是一个虚构的虚拟机物理地址空间。操作系统的内存管理模块负责将虚拟机虚拟地址（GVA）映射到虚拟机物理地址（GPA），其指令目标地址也是一个虚拟机物理地址。这样的地址在无虚拟化情况下，其实是实际物理地址。但在有虚拟化情况下，这样的地址不能被直接处理使用，需VMM先将虚拟机物理地址转换成一个主机物理地址（HPA），再交由物理处理器执行。

如图 1所示：

内存的硬件辅助虚拟化使用扩展页表（EPT）技术，通过硬件完成虚拟机虚拟地址到主机物理地址的转换。

如图 2所示：

设备虚拟化方式主要有三种：设备模拟、半虚拟化设备、设备直通。

设备模拟

设备模拟通过QEMU提供的设备模型，可完全模拟出与物理设备一样的接口。因此，在虚拟机操作系统中，使用原生驱动即可使用设备。设备模拟只能模拟出具有基本功能的设备，不支持复杂功能和模型的设备。完全模拟的设备兼容性好，但由于是纯软件模拟，性能相对较低。

如图 1所示：

半虚拟化设备

半虚拟化设备实现前后端驱动。利用虚拟机中的前端驱动，通过基于事务的通信机制，将请求直接发给宿主机端的后端驱动，从而很大程度上减少上下文切换的开销，性能相比完全设备模拟有较大提升。然而，Virtio后端驱动仍在QEMU中实现，在IO处理过程中会经过用户态与内核态之间的多次切换。为进一步提升性能，可将Virtio后端驱动的功能放至内核态实现，称为Vhost-kernel后端，于是数据仅需经过从用户态到内核态的一次切换，就可完成数据传输，实现性能提升。

随着技术发展，将数据放入用户态处理可得到更灵活的形式。因此，在原有Vhost架构中进行改动，增加Vhost-user后端，搭配DPDK、SPDK中相关用户态函数库，性能进一步提升。

如图 2所示：

设备直通

设备透传基于硬件的设备虚拟化技术，支持将PCI/PCIe物理设备直接映射到虚拟机的地址空间，在虚拟机中，使用原生设备驱动就可直接使用设备，达到近乎物理设备的性能。物理设备被透传后由虚拟机独享，其它虚拟机无法共享使用该设备。

如图 3所示：

SR-IOV是由PCI-SIG组织定义的PCIe规范的扩展规范，目的是通过提供一种标准规范，为虚拟机提供独立的内存空间、中断、DMA数据流。 SR-IOV支持单个物理PCIe设备（PF）虚拟出多个虚拟PCIe设备（VF），然后通过设备透传技术将虚拟PCIe设备直通到各虚拟机，以实现单个物理PCIe设备支撑多虚拟机的应用场景。

如图 4所示：

存储虚拟化是将服务器存储资源池化，实现服务器存储资源的统一整合、管理及调度，并向上层提供多种存储接口，供业务虚拟机根据自身的存储需求灵活分配使用资源池中的存储空间。ZStack ZSphere支持对接集中式存储和分布式存储。

集中式存储是指将数据存储在一台或多台服务器组成的中心节点上。集中式存储所有业务均集中部署在中心节点，中心节点统一管理各分部节点数据，数据访问仅需经过一个控制器即可实现。集中式存储分为DAS、NAS、SAN三类，用户可根据不同数据存储需求选择不同存储类型。

关于集中式存储架构的说明。在集中式存储架构中，机头是最核心部件。通常机头包含两个控制器，互为备用， 避免硬件故障导致整个存储系统不可用。此外，机头包含前端端口和后端端口，前端端口用于为服务器提供存储服务，后端端口用于扩充存储系统容量。通过后端端口，机头可连接更多存储设备，从而形成一个庞大的存储资源池。

如图 1所示：

SAN存储

ZStack ZSphere支持对接多种集中式存储。这里主要介绍SAN存储。该方式可将用户在SAN存储上划分的LUN设备直接作为存储池，再提供给业务虚拟机使用。与基于文件系统的数据存储不同，SAN存储具备便捷部署、灵活扩展、性能优异等优势。据实测数据显示，SAN存储可完全发挥物理磁盘的性能。目前SAN存储支持iSCSI、FC、NVMe-oF共享访问协议。

SAN存储工作原理：

• 块级访问：SAN存储可将数据分成块，每个块都有唯一标识符。服务器通过这些标识符来读取或写入特定的数据块。
• 并行访问：多个节点可同时访问SAN存储中的不同块，从而实现并行读写操作。
• 共享性：SAN存储可被多个节点共享，使得它们可以同时访问相同的数据块。这对于分布式系统中需要共享数据的场景非常重要。
• 容错性：SAN存储通常会提供数据冗余和故障恢复机制，以确保数据的安全性和可靠性。
• 扩展性：SAN存储可通过添加更多存储节点来扩展容量和性能。
• 性能优化：SAN存储通常会采取各种技术来优化性能，例如缓存、负载均衡等。

关于SAN存储架构的说明。在集中式存储上映射一个卷到主机上，根据存储控制器的连接方式，在主机上多路径服务会自动把多个具有相同WWID的SCSI设备聚合成多路径设备。ZStack ZSphere会去检测集群内所有主机上拥有相同WWID的多路径设备，然后针对用户选定的卷创建出集群内的共享卷组（VG）。ZStack ZSphere基于卷组创建逻辑卷（LV），逻辑卷实际上对应了ZStack ZSphere中的硬盘、快照等资源。同时为维护存储集群的一致性，ZStack ZSphere也提供共享存储锁管理机制（Sanlock），用于维护存储心跳、节点管理、元数据管理等功能。

如图 2所示：

Sanlock + Lvmlockd

Sanlock（Shared storage lock manager），共享存储锁管理机制。实际上，它是基于Lamport的几个算法：Delta Paxos、Disk Paxos，而形成的一套租约管理机制，并且在这几个租约管理机制上实现了集群成员管理、心跳维护、仲裁和信息传递，下一步则是将这里的租约机制转换为能让LVM使用的锁：Lvmlockd。

引入Sanlock + Lvmlockd后，服务器执行的大部分LVM命令，均会先将请求送到Lvmlockd。Lvmlockd会将LVM的操作翻译为Sanlock所能识别的锁操作。

针对不同资源的操作需获取不同的锁权限，只有在获取锁权限后，才能对相应资源执行操作，从而确保元数据和数据的安全性。此外，整个过程无需任何中间节点协调或集中操作，是一个全分布式架构。

如图 3所示：

ZStack ZSphere支持对接多种分布式存储。这里主要介绍自研分布式存储。该存储支持丰富的资源管理功能，包括对服务器、硬盘、数据盘、块存储卷、存储池、存储桶等多种资源的管理。用户可通过这些功能实现拥有不同数据冗余类型的存储池、指定存储策略和访问权限的存储桶，从而快速、低成本地构建简单、稳定、安全高效的存储基础设施。

如图 1所示：

缓存加速方案一般是指使用SSD类的缓存设备，为数据盘的核心设备HDD进行加速的方案。自研分布式存储通过自研缓存加速技术（ZAS缓存模块）使用高速SSD设备为传统HDD设备进行I/O缓存，将经常访问的热数据缓存到高速SSD设备中并返回给应用程序，可以显著提升I/O性能，尤其是在具有热数据访问特征的场景下尤为明显。

ZAS缓存模块支持写透（Writethrough）和写回（Writeback）两种缓存策略。在写透模式下，数据同时写入缓存和后端存储设备，确保数据一致性；而在写回模式下，会将大部分缓存用于缓冲写入的数据，确保将脏数据顺序写入后端存储设备。系统默认关闭写回策略，支持在运行时切换缓存策略。

在数据写入逻辑卷之前，即可为上层应用程序提供比实际物理存储设备更多的虚拟存储空间，具有方便的可伸缩性，可有效利用存储空间。

QoS (Quality of Service) 是用于解决I/O资源分配问题的一种技术，可以用来帮助用户对I/O读写进行限速，帮助实现资源的合理分配。

在数据节点中，存在op_shardedwq队列处理各种来自上级的I/O，并且这是一个复合队列，通常包含若干子队列。I/O请求从队列出列后，通过ObjectStore接口与磁盘交互。I/O类型主要包括两大类，一类是来自客户端的业务读写I/O请求，一类是存储系统内部活动产生的I/O，包括数据节点之间的I/O请求，SnapTrim，Scrub和Recovery等。

自研分布式存储采用基于权重的优先级队列 (wpq)，按照上述的I/O分类，分别存入子队列，每个prior队列在其第一个请求入队时被创建。出队时，采用权重概率的方式确定prior级别，每个队列的优先级prior作为其权重，该prior队列被选中的概率即为其权重占总权重的比例。被选中的prior队列也并不一定能出队请求，还需要根据将要出队的请求大小来确定。

自研分布式存储支持为块存储卷设置业务QoS，包括最大IOPS、最大读写带宽。用户可通过设置业务QoS，对不同块存储卷的性能进行管控，进而满足多样化的业务性能需求。

如图 1所示：

快照是自研分布式存储中一种重要的数据保护机制，允许用户在特定时间点创建块存储卷的完整状态副本，而无需中断服务或影响生产环境。

快照创建

自研分布式存储采用COW (Copy-On-Write) 快照技术。当创建COW快照后，系统会在存储集群中创建一个原始块设备的只读副本，只有在原始块设备或快照中的数据发生变化时，才会复制被修改的数据块，这样既保留了原始数据在快照中的状态，又避免了不必要的数据冗余。同时，系统会记录原始块设备和快照之间的关系，以及每个快照的元数据信息，包括创建时间、大小、父快照等。记录这些元数据使得系统在恢复数据时可以准确定位到特定的快照状态。

如图 1所示：

如图 1、图 2和图 3所示：

通过故障域隔离技术，可将故障对业务的影响限制在某个范围内，避免出现“牵一发而动全身”的情况发生，从而提高业务连续性。

通过基于故障域的扩容技术，配合合理的存储策略，可以将新扩容的节点独立成一个硬盘池，避免了数据的迁移。这种方式能够实现业务的无感扩容，向应用屏蔽了底层存储的变更细节，避免了传统存储变更时需要业务系统同时变更的情况。这样一来，运维人员及业务人员的工作量大大减少，同时也能提高系统的可靠性和性能。

集群拓扑是对集群物理资源实际部署方式的可视化展示，其中包含了数据中心、机房、机架、服务器等对象的逻辑实体，通过树状图的方式逐层放置，从而描述出从机房到服务器的分布关系。其中每一个树状图都有一个根节点，同时集群拓扑允许多个根节点存在。用户可在拓扑规划完成后，在创建存储池时选择对应级别的数据冗余策略。

如图 1所示：

自研分布式存储支持多资源池特性，帮助用户实现不同性能存储介质的使用和故障隔离。

每个资源池可以具有不同的属性和性能，包括副本数、数据冗余级别、存储介质等。用户可根据实际需求灵活进行资源划分和管理，提高存储效率和存储性能。

各资源池之间相互隔离，用户可基于多个资源池实现数据隔离管理。同时，单一资源池故障不会对其他资源池产生影响，有效保障数据安全和存储可靠性。

自研分布式存储支持可视化界面点灯和硬盘快速定位。当用户需对某块硬盘进行维护或更换时，可在UI上点击硬盘点灯，物理环境中该硬盘的LED灯就会亮起，指引用户快速、准确进行设备定位，提高运维效率。

自研分布式存储支持S.M.A.R.T.检测技术，监测硬盘的健康状态、温度、固件，和硬盘写入量总计。上层业务会根据Smart Data返回的相关I/O错误和磁盘状态信息， 触发相应的告警。

自研分布式存储支持数据盘维护模式，进行服务器或硬盘维护时，可先在UI界面使对应数据盘进入维护模式，该模式下的数据盘将停止服务和数据访问，其上的数据不会进行重平衡。

自研分布式存储支持自动故障监测和报警机制。该机制监控存储平台系统和各个存储服务器，检测到故障时将自动向平台发送告警消息。用户可另外添加邮箱报警器接收告警消息，以及时采取措施进行故障修复。

同时，检测到故障发生时，支持自动服务重启和数据迁移，最大程度上保障了数据的可靠、可用，从而形成高可靠、高可用的分布式存储系统。

自研分布式存储支持数据重平衡，即使存储集群中的数据均衡分布在各个存储服务器下的数据盘上，从而提高存储系统的性能和可靠性。

手动数据重平衡：

同时支持手动数据重平衡功能，用户可根据实际的数据分布情况，手动进行数据重平衡操作。

网络虚拟化是一种通过软件技术将网络资源进行抽象及重组的虚拟网络方法。 底层硬件仅需提供基础的数据包转发服务，网络虚拟化可提供多种网络服务，包括数据交换、路由和安全组等，使网络体验同物理网络一样。

ZStack ZSphere将网络模型抽象为分布式交换机和分布式端口组。分布式交换机在数据中心中横跨多台主机，在整个数据中心范围内提供部署，管理和监控虚拟网络的能力。分布式端口组是分布式交换机上的一组虚拟端口的集合，同一端口组下的虚拟机具有统一的网络配置，以满足虚拟机可以在不同主机间迁移。另外平台在分布式端口组上还提供分布式DHCP服务，同时支持为虚拟机配置DNS，以满足数据中心中不同网络场景的需求。

交换机通过主机的MAC地址或IP地址标识主机，以实现主机之间、主机与外部网络之间的网络流量转发和流量控制。在传统数据中心中，主机位置是固定的，交换机和主机的位置关系也是固定的，这意味着交换机的配置不需要经常变化。

ZStack ZSphere引入分布式交换机，提供虚拟机之间、虚拟机和外部网络之间的流量转发和流量控制功能，为用户提供方便灵活、功能丰富的网络功能。

在传统数据中心，网络可分为：信任区域、DMZ区域、非信任区域，通过边界防火墙进行流量控制，保障网络安全。在虚拟化数据中心，边界防火墙可能力不从心，例如：不同用户之间需要实现网络隔离，同一用户的不同业务之间需要访问控制，边界防火墙很难灵活处理这些场景。因此，ZStack ZSphere引入新组件：安全组。安全组是一种分布式防火墙，专注东西向流量管控，支持虚拟机网卡级别的出入流量控制。

虚拟机调度策略可为虚拟机分配主机资源编排策略，用于保障业务高性能和高可用。支持将虚拟机加入一个虚拟机调度组，通过为该虚拟机调度组绑定调度策略实现虚拟机调度。

功能原理

ZStack ZSphere支持将虚拟机加入一个虚拟机调度组，通过为该虚拟机调度组绑定调度策略实现虚拟机调度。

• 若绑定互斥虚拟机或聚集虚拟机策略，无需指定主机调度组，虚拟机按照策略及其执行机制分配主机。
• 若绑定虚拟机亲和主机或虚拟机互斥主机调度策略，需指定对应的主机调度组，虚拟机按照策略及其执行机制分配主机。

下文通过四个场景说明四类调度策略的工作原理：

场景1：假定数据中心内有三台主机Host1、Host2、和Host3。虚拟机调度组A已绑定互斥虚拟机调度策略，且虚拟机VM1和VM2已加入该调度组，并分别运行在主机Host1和Host2上。此时将虚拟机VM3加入该调度组，不同执行机制下虚拟机VM3行为如下：

• 强制机制下，虚拟机VM3遵循与组内其他虚拟机强制互斥原则：
  • 若主机Host3资源充足，可正常在Host3上启动并运行。
  • 若主机Host3资源不足，无法在Host3上启动。
• 优先机制下，虚拟机VM3遵循与组内其他虚拟机尽量互斥原则，优先在Host3上启动：
  • 若主机Host3资源充足，可正常在Host3上启动并运行。
  • 若主机Host3资源不足，VM3可尝试在其他资源充足的主机上启动。在该场景下，VM3在Host2上启动并运行。

如图 1所示：

场景2：假定数据中心内有两台主机Host1和Host2。虚拟机调度组A已绑定聚集虚拟机调度策略，且虚拟机VM1和VM2已加入该调度组，并运行在主机Host1上。此时将虚拟机VM3加入该调度组，不同执行机制下虚拟机VM3行为如下：

• 强制机制下，虚拟机VM3遵循与组内其他虚拟机强制聚集原则：
  • 若主机Host1资源充足，可正常在Host1上启动并运行。
  • 若主机Host1资源不足，无法在Host1上启动。
• 优先机制下，虚拟机VM3遵循与组内其他虚拟机尽量聚集原则，优先在Host1上启动：
  • 若主机Host1资源充足，可正常在Host1上启动并运行。
  • 若主机Host1资源不足，VM3可尝试在其他资源充足的主机上启动。在该场景下，VM3在Host2上启动并运行。

如图 2所示：

场景3：假定数据中心内有三台主机Host1、Host2、和Host3。虚拟机调度组A已绑定虚拟机互斥主机调度策略，且虚拟机VM1和VM2已加入该调度组，并运行在主机Host1上。主机调度组A也已绑定虚拟机互斥主机调度策略，且主机Host2和Host3上已加入该调度组，分别运行两台虚拟机。此时将虚拟机VM3加入虚拟机调度组A，不同执行机制下虚拟机VM3行为如下：

• 强制机制下，虚拟机VM3遵循与主机调度组A内的主机强制互斥原则：
  • 若主机Host1资源充足，可正常在Host1上启动并运行。
  • 若主机Host1资源不足，无法在Host1上启动。
• 优先机制下，虚拟机VM3遵循与主机调度组A内的主机尽量互斥原则，优先在Host1上启动：
  • 若主机Host1资源充足，可正常在Host1上启动并运行。
  • 若主机Host1资源不足，VM3可尝试在其他资源充足的主机上启动。在该场景下，VM3在Host2上启动并运行。

如图 3所示：

场景4：假定数据中心内有三台主机Host1、Host2、和Host3。虚拟机调度组A已绑定虚拟机亲和主机调度策略，且虚拟机VM1~VM5已加入该调度组，并分别运行在主机Host2和Host3上。主机调度组A也已绑定虚拟机亲和主机调度策略，且主机Host2和Host3上已加入该调度组。此时将虚拟机VM6加入虚拟机调度组A，不同执行机制下虚拟机VM6行为如下：

• 强制机制下，虚拟机VM3遵循与主机调度组A内的主机强制聚集原则：
  • 若主机Host2或Host3资源充足，可正常在Host2或Host3上启动并运行。
  • 若主机Host2和Host3资源不足，无法在Host2或Host3上启动。
• 优先机制下，虚拟机VM3遵循与主机调度组A内的主机尽量聚集原则，优先在Host2或Host3上启动：
  • 若主机Host2或Host3资源充足，可正常在Host2或Host3上启动并运行。
  • 若主机Host2和Host3资源不足，VM6可尝试在其他资源充足的主机上启动。在该场景下，VM3在Host1上启动并运行。

如图 4所示：

ZStack ZSphere提供两种虚拟机克隆方式以满足不同业务场景需求：全量克隆、快速全量克隆。

如图 1所示：

裸金属管理核心：硬件信息获取、裸金属设备无人值守部署。