kvm下的ceph主机启动io请求统计

背景

假如一个主机存储在ceph里面,我们想统计下一次启动过程中的io读取的情况,那么可以通过下面的方法来统计
启动时间也可以通过在宿主机里面去查看,通过日志这边要方便一点,无需登录到虚拟机内部

日志开启


[global]
fsid = 4064c56e-c9ad-4b19-bf74-c4e291be5920
mon_initial_members = lab104
mon_host = 192.168.19.104
auth_cluster_required = none
auth_service_required = none
auth_client_required = none

[client]
admin socket = /var/run/ceph/ceph-client/$cluster-$type.$id.$pid.asok
debug rbd = 20
debug client = 20
debug objectcacher = 20
log file = /var/run/ceph/ceph-client/$cluster-$name.log

通过这个可以看到 这个是开启日志的方法

在kvm的主机上面添加上面的日志,这个写到ceph的配置文件即可

日志处理

[root@lab102 kvm]# cat  ceph-client.admin.log |grep ObjectDispatch|grep read|grep ObjectDispatch|grep -v SimpleSchedule|tail -n 10
2025-02-19T14:54:10.524+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000001 3833856~360448
2025-02-19T14:54:10.524+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 0~155648
2025-02-19T14:54:10.524+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 155648~516096
2025-02-19T14:54:10.524+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 671744~516096
2025-02-19T14:54:10.524+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 1187840~65536
2025-02-19T14:54:10.527+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 1253376~516096
2025-02-19T14:54:10.528+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 1769472~516096
2025-02-19T14:54:10.528+0800 7f3a48873700 20 librbd::io::ObjectDispatch: 0x564ea4735e50 read: rbd_data.3a5db2d07ea.0000000000000002 2285568~516096

可以看到请求的时间,请求的对象名称,请求的起点,请求的长度

rados的请求收到了7617次
[root@lab102 kvm]# cat readnew.txt |wc -l
7617

一次启动在ceph这边的rados请求发起了这么多次

下面是一个系统启动的时候读取的总的数据量

[root@lab102 kvm]# cat  readnew.txt |awk '{print $2}'|awk -F~ '{sum += $2} END{print sum}'
167396352

总的数据读取大小大概在160MB/s左右,主要也就是内核,内核大概也就100M左右,还有其它的一些数据

对象被读取的情况

[root@lab102 kvm]# cat new1.txt |sort  -n -k 2|tail -n 15
rbd_data.3a5db2d07ea.00000000000026d5 3117056
rbd_data.3a5db2d07ea.0000000000000019 3407872
rbd_data.3a5db2d07ea.0000000000000dc5 3436544
rbd_data.3a5db2d07ea.0000000000000080 3542528
rbd_data.3a5db2d07ea.0000000000000003 4194304
rbd_data.3a5db2d07ea.0000000000000004 4194304
rbd_data.3a5db2d07ea.0000000000000005 4194304
rbd_data.3a5db2d07ea.000000000000001a 4194304
rbd_data.3a5db2d07ea.000000000000001b 4194304
rbd_data.3a5db2d07ea.000000000000001c 4194304
rbd_data.3a5db2d07ea.000000000000001d 4194304
rbd_data.3a5db2d07ea.0000000000000000 4820992
rbd_data.3a5db2d07ea.0000000000000100 4821504
rbd_data.3a5db2d07ea.0000000000000001 6348800
rbd_data.3a5db2d07ea.0000000000000002 7798784

可以看到有一部分对象还是比较连续的读取的,这个应该是一些操作系统大文件的,比如内核的,这个经过一层文件系统后的有一部分是连续id

如何利用这些日志信息

我们可以看下,在不同的并发下面,这个启动的区别,理论上是越多并发,单个的时间就会越大,开始可能比一个会好一点,会缓存一点其它主机读取的相同的数据,但是这个到了一定的程度就会成为瓶颈了

我们需要根据这个启动分析来得到一个比较合适的并发启动数目

一些命令记录

并发启动虚拟机

 virsh list --all --name | xargs -P 11 -I {} virsh start  {}

获取虚拟机的ip

[root@lab102 kvm]# cat check.sh
for vm in $(virsh list --all --name); do     virsh domifaddr  $vm; done|grep ipv|awk '{print $4}'|cut -d / -f 1 > ip.list

查看启动时间

for host in `cat ip.list`;do ssh  root@$host  systemd-analyze ;done

启动一个虚拟机的时间

[root@lab102 kvm]# ssh 192.168.122.48  systemd-analyze
Startup finished in 806ms (kernel) + 1.920s (initrd) + 11.502s (userspace) = 14.229s

并发启动10个虚拟机

[root@lab102 kvm]# for host in `cat ip.list`;do ssh  root@$host  systemd-analyze ;done
Startup finished in 880ms (kernel) + 3.479s (initrd) + 19.364s (userspace) = 23.724s
Startup finished in 883ms (kernel) + 3.404s (initrd) + 17.888s (userspace) = 22.176s
Startup finished in 984ms (kernel) + 3.143s (initrd) + 19.173s (userspace) = 23.302s
Startup finished in 862ms (kernel) + 3.512s (initrd) + 19.606s (userspace) = 23.981s
Startup finished in 868ms (kernel) + 2.628s (initrd) + 17.788s (userspace) = 21.285s
Startup finished in 900ms (kernel) + 2.661s (initrd) + 18.296s (userspace) = 21.859s
Startup finished in 880ms (kernel) + 3.479s (initrd) + 19.364s (userspace) = 23.724s
Startup finished in 870ms (kernel) + 3.442s (initrd) + 19.233s (userspace) = 23.546s
Startup finished in 911ms (kernel) + 3.395s (initrd) + 17.976s (userspace) = 22.283s
Startup finished in 901ms (kernel) + 3.309s (initrd) + 19.488s (userspace) = 23.699s
Startup finished in 901ms (kernel) + 2.597s (initrd) + 18.168s (userspace) = 21.667s

可以看到时间增加了7秒左右,大概是1.5倍,这个时间是11个虚拟机并发启动的情况,如果更多的情况可以继续查看

3.97k op/s
3.16k op/s
3.75k op/s
3.68k op/s
3.10k op/s
3.52k op/s
1.52k op/s
1.53k op/s

从ceph的日志看,可以看到启动11个时候的高峰期op大概在3k多

<think>好的,用户之前问过关于OpenStack无法移除主机的问题,现在又询问创建虚拟机非常慢的情况。我需要先分析可能的原因,然后给出解决方法。用户可能是管理员或开发者,遇到性能问题,影响他们的工作效率或项目进度。他们可能需要快速定位问题,并找到解决方案,可能还希望了解如何预防类似问题。 创建虚拟机慢的原因有很多,首先需要分阶段考虑,比如资源调度阶段、镜像下载、网络配置、虚拟机启动等。每个阶段都可能成为瓶颈。比如资源调度阶段如果计算节点资源不足或调度策略复杂,会导致延迟;镜像下载如果存储后端慢或者镜像缓存未命中,也会耗时;网络方面,DHCP配置慢或安全组规则过多也可能影响速度;计算节点本身的性能,如CPU、内存、磁盘IO不足,或者Hypervisor配置不当,都会导致启动慢。 需要检查的方面包括Nova的配置、Glance的镜像存储、Neutron的网络设置、Cinder的卷服务,以及计算节点的资源使用情况。用户可能没有足够的监控工具,可能需要指导他们查看日志和性能指标。此外,可能还存在并发请求过多导致队列堆积,或者数据库性能问题。 还要考虑是否使用了特定的驱动或后端,比如Ceph、NFS等存储,这些的配置和性能也会影响虚拟机创建速度。另外,镜像格式(如qcow2需要转换)也可能导致延迟。需要建议用户检查这些方面,并提供相应的优化建议,比如启用镜像缓存、调整调度策略、优化网络配置等。 需要确保回答结构清晰,分点列出可能的原因和对应的解决方法,同时给出检查命令和日志位置,帮助用户逐步排查问题。可能还需要提醒用户查看Hypervisor的日志,如Libvirt或KVM的日志,以发现潜在的问题。最后,如果用户无法自行解决,建议他们提供更多日志信息以便进一步分析。</think>在 OpenStack 中创建虚拟机(实例)速度缓慢是一个常见问题,可能由多种因素导致。以下是常见原因及优化方法: --- ### **一、创建虚拟机的核心流程** 在排查问题前,先了解 OpenStack 创建虚拟机的主要阶段: 1. **API 请求接收**:用户通过 Horizon 或 CLI 发送请求。 2. **调度(Scheduler)**:Nova 选择合适的计算节点(基于资源、策略等)。 3. **镜像下载**:从 Glance 下载镜像到计算节点的本地存储或共享存储。 4. **网络配置**:Neutron 分配网络、安全组、浮动 IP 等。 5. **虚拟机启动**:Hypervisor(如 KVM启动实例。 任一环节都可能成为性能瓶颈。 --- ### **二、常见原因与解决方法** #### **1. 资源调度阶段延迟** - **现象**:实例长时间卡在 `Scheduling` 状态。 - **可能原因**: - **计算节点资源不足**:CPU、内存、磁盘空间不足。 - **调度策略复杂**:过滤条件过多(如 `AggregateInstanceExtraSpecsFilter`)或自定义调度器逻辑复杂。 - **Nova Scheduler 服务过载**:高并发请求导致调度延迟。 - **解决方法**: - 检查计算节点资源状态: ```bash openstack hypervisor list openstack hypervisor show <hypervisor- 简化调度策略(`/etc/nova/nova.conf` 中调整 `scheduler_driver` 或 `scheduler_default_filters`)。 - 增加 Nova Scheduler 服务的并行实例。 #### **2. 镜像下载耗时** - **现象**:实例卡在 `Spawning` 状态,且计算节点日志显示下载镜像缓慢。 - **可能原因**: - **镜像存储后端性能差**:例如 Glance 使用缓慢的 NFS 或未启用缓存。 - **镜像格式问题**:RAW 镜像体积大,下载慢;QCOW2 镜像需本地转换。 - **网络带宽不足**:计算节点与 Glance 存储间网络拥堵。 - **解决方法**: - 启用 Glance 的本地缓存(配置 `[glance] use_local_cache = True`)。 - 使用 `qcow2` 镜像格式并启用压缩。 - 将镜像存储迁移到高性能后端(如 Ceph RBD)。 #### **3. 网络配置延迟** - **现象**:实例启动后长时间无法获取 IP 或访问网络。 - **可能原因**: - **Neutron DHCP Agent 响应慢**:DHCP 服务超时或配置错误。 - **安全组规则过多**:大量规则导致 iptables/OVS 性能下降。 - **网络重叠或冲突**:IP 池耗尽或网络配置冲突。 - **解决方法**: - 检查 Neutron DHCP Agent 日志: ```bash journalctl -u neutron-dhcp-agent.service ``` - 合并或简化安全组规则。 - 使用 `dnsmasq` 替代 `neutron-metadata-agent`(需验证兼容性)。 #### **4. 计算节点性能问题** - **现象**:实例启动后长时间处于 `Building` 状态。 - **可能原因**: - **Hypervisor 性能不足**:CPU 负载高、内存交换频繁、磁盘 I/O 瓶颈。 - **Libvirt/KVM 配置不当**:未启用 virtio 驱动或缓存模式。 - **共享存储延迟**:例如 Ceph 集群响应慢或 NFS 锁竞争。 - **解决方法**: - 监控计算节点资源: ```bash top # 查看 CPU/内存 iostat - 优化 Libvirt 配置(`/etc/nova/nova.conf`): ```ini [libvirt] disk_cachemodes = "writeback" cpu_mode = "host-passthrough" ``` - 使用高性能本地存储(如 SSD)或优化 Ceph/NFS 性能。 #### **5. 其他潜在原因** - **数据库性能瓶颈**:Nova 或 Neutron 的数据库响应慢。 - 检查 MySQL/MariaDB 慢查询日志,优化索引或分库分表。 - **消息队列堆积**:RabbitMQ 或 Kafka 处理延迟。 - 监控 RabbitMQ 队列状态: ```bash rabbitmqctl list_queues name messages_ready ``` - **日志级别过高**:DEBUG 日志导致服务负载增加。 - 调整 Nova/Neutron 日志级别为 `INFO` 或 `WARNING`。 --- ### **三、优化建议** 1. **启用镜像预热**: - 提前将常用镜像缓存到计算节点。 2. **使用裸金属(Ironic)或快速启动模板**: - 对性能敏感场景,直接部署裸金属实例或预先生成虚拟机模板。 3. **调整 Nova 并发配置**: - 在 `/etc/nova/nova.conf` 中增加 `workers` 数量: ```ini [api] workers = 8 ``` 4. **升级硬件或组件版本**: - 使用更高性能的 CPU/磁盘,升级 OpenStack 到最新稳定版。 --- ### **四、排查工具** 1. **日志定位**: - Nova API 日志:`/var/log/nova/nova-api.log` - Nova Compute 日志:`/var/log/nova/nova-compute.log` - Neutron 日志:`/var/log/neutron/*.log` 2. **OpenStack CLI 命令**: ```bash openstack server show <instance-id> # 查看实例详细状态 openstack network agent list # 检查网络服务状态 ``` --- 若问题仍无法解决,请提供以下信息以便进一步分析: - OpenStack 版本(如 Victoria、Wallaby)。 - 使用的 Hypervisor 类型(KVM、QEMU、Xen)。 - 关键配置文件片段(如 `nova.conf`、`neutron.conf`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

武汉磨磨

打赏是写出更好教程的鼓励

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

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

打赏作者

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

抵扣说明:

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

余额充值