FusionOne HCI-计算虚拟化

创作内容不易,学习的朋友麻烦关注下博主,后面学习不迷路。有不会的问题也可以论坛咨询博主,博主也会及时回复。

博主也创建了一个it知识共享互助群,有兴趣的小伙伴也可以加我微信,博主给你拉进群(xiaotiancaio180)


1.虚拟化

虚拟化将软硬件节藕,将内存,CPU,网卡等计算资源,通过软件抽象后提供给多个虚拟机复用,极大的提升了资源利用率以及灵活度

Hypervisor = 虚拟化管理层

2.hypervisor架构

一般常用两种类型,第一种就是如ESXI一样,裸金属服务器直接部署了虚拟化系统。第二种就是裸金属部署了常用系统,然后基于这个系统安装了对应虚拟化软件

3.CPU虚拟化-CPU指令系统

cpu拥有不同的指令集,它把不同的命令分成不同的指令集。

内核态:操作系统访问硬件(物理内存,IO设备等),关键数据结构,运行中断等

用户态:用户运行应用进程

Ring0内核态指令集里面运行的主要是操作系统访问硬件,关键数据结构,运行中断等

Ring1和ring2两个指令集主要运行的是设备驱动的命令

Ring3指令集运行的是我们用户态的应用的一些命令

Binary translation:将虚拟机内核指令在运行时替换为一系列指令模拟虚拟机内核态指令的执行。由hypervisor来拦截,收集,辨识虚拟机的所有命令,将虚拟机的恶ring0命令进行翻译使得虚拟机内核态的这部分指令可以运行在ring0的环境。hypervisor因为要进行大量的拦截,所以资源消耗会非常大,这种方案也叫全虚拟(第一代全虚拟化技术),全部依靠软件的功能来解决

半虚拟化(超虚拟化):这个技术的重点在于他直接修改了操作系统,图中的linux直接横穿hypervisor,直达hardware。让操作系统即使在ring3上,也可以跑ring0命令。这个方案缺点就是像windows这种闭源的系统是无法做修改的

硬件辅助全虚拟:全虚拟化和半虚拟化都是在软件层面解决问题。而这个方案则是依靠的cpu升级

,升级后的cpu有了两个工作形态,第一个工作形态叫根态,另一种叫非根态。当在物理机上面起了一台虚拟机之后,当虚拟机想要运行的时候,物理cpu会有根态转换为非根态,切换之后,guest os就可以直接访问物理cpu的ring0。这个时候如果物理机也想对cpu进行操作,在由非根态切回成根态

4.内存虚拟化

虚拟内存是操作系统给程序分配的一段连续的内存,当程序往虚拟内存写入东西的时候,需要在虚拟内存和物理内存之间建立一个映射关系,通过映射才能把数据写入到物理内存里。这种映射关系我们称之为页表

HPA:宿主机物理地址

HVA:宿主机上面应用的虚拟地址。hypervisor地址

GPA:虚拟机的物理地址

GVA:虚拟机应用的虚拟地址子

然后会有对应三张映射表

内存虚拟化-MMU虚拟化

负责虚拟机地址映射为物理地址

影子页表(格外创建的第四张表):vmm在宿主机内核中为虚拟机进程维护了一个虚拟机的虚拟机地址到宿主机物理地址的页表,这个页表和虚拟机内核的页表同步更新,适合一次写入频繁读取

硬件虚拟化技术-interl EPT and AMD RVI:在cpu里面新添加了一个硬件,“TLB(translation look-aside buffer)”,转换查找缓冲器。由这个硬件完成三次映射的运算

5.IO虚拟化

IO全虚拟化

GuestOS中运行设备驱动无需任何修改。当执行敏感指令时,VMM截获IO请求,并通知后段进行模拟。模拟完成后重新陷入GuestOS

IO半虚拟化

GuestOS运行了特定的前端驱动,前端驱动与后段驱动协商可以完成减少上下文切换,共享内存减少搬运等目的,提高性能

IO设备透穿

通过硬件的辅助可以让虚拟机直接访问物理设备,而不需要通过VMM活被VMM所截获,使性能接近物理机性能

通过IOMMU可以实现多个虚拟机之间内存空间的隔离

SRIOV

SR-IOV是一种规范,使得单根端口下的PCIe物理设备显示为管理程序或客户机操作系统的多个单独的物理设备,既有直通设备的性能优势,又可以支持多个虚拟机Host通过SR-IOV将包括发送,接收队列在内的物理资源依据VF数据划分成多个子集。

PF驱动将这些资源子集抽象成VF设备,映射给虚拟机使用

PF(physical function)

包括轻量级的PCIe功能,负责管理SR-IOV设备的特殊驱动,其主要功能是为Guest提供设备访问功能和全局贡献资源配置的功能。

VF(virtual function)

包括轻量级的PCIe功能。其功能包括三个方面:向虚拟机擦欧总系统提供的借口;数据的发送,接收功能;与PF进行通信,完成全局相关操作

6.性能优化手段


我们今天的内容到这就结束了,今天的内容到这里就结束了,如果有啥不会的朋友记得论坛里面提问哈~

如果朋友你感觉文章的内容对你有帮助,可以点赞关注文章和专栏以及关注我哈,嘿嘿嘿我会定期更新文章的,谢谢朋友你的支持哈

### 检查名为 `hci-worker` 的节点是否已启动 若需确认 `hci-worker` 是否为 Kubernetes 集群中的一个节点,可使用以下命令查看所有节点的状态: ```bash kubectl get nodes ``` 该命令将列出集群中所有节点的名称、状态、角色等信息。在输出结果中查找 `hci-worker`,其状态若显示为 `Ready`,则表示该节点已正常运行。 若需进一步了解该节点的详细信息,包括事件日志和资源状态,可以执行: ```bash kubectl describe node hci-worker ``` 此命令有助于排查节点未就绪的原因,例如 kubelet 是否运行正常、资源是否充足等[^1]。 --- ### 检查名为 `hci-worker` 的 Pod 是否已启动 若 `hci-worker` 是一个 Pod 名称,则可通过以下命令查看其状态: ```bash kubectl get pods --all-namespaces | grep hci-worker ``` 如果该 Pod 存在,输出结果将显示其所在的命名空间、状态(如 Running、Pending 等)以及重启次数等信息。 为了获取更详细的运行状态和事件日志,可执行: ```bash kubectl describe pod hci-worker -n <namespace> ``` 其中 `<namespace>` 为 Pod 所属的命名空间。该命令将展示 Pod 的调度情况、容器状态及可能发生的错误信息[^1]。 --- ### 若 `hci-worker` 是静态 Pod 或由控制器管理的 Pod 若 `hci-worker` 是由 kubelet 直接管理的静态 Pod,则不会通过 API Server 显示在默认的 `kubectl get pods` 结果中。此时需登录到目标节点并执行: ```bash crictl ps | grep hci-worker ``` 或检查 `/etc/kubernetes/manifests` 目录下的配置文件是否正确加载。 若该 Pod 是由 Deployment、DaemonSet 或 StatefulSet 等控制器管理的,则可以通过控制器的状态来判断其运行状况。例如,查看对应 Deployment 的状态: ```bash kubectl get deployment -A | grep hci-worker ``` 然后使用 `kubectl describe deployment <name>` 来查看其副本集和 Pod 的调度状态[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

是小天才哦

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值