关于cloudstack的Dashboard的显示存储空间容量的问题

简介:

说明:下面是我们在cloudstack的Dashboard显示的磁盘容量信息

blob.png

如图上我们可以发现,主存储的空间为12T,已使用空间为1.70T,但实际存储空间是否是12T,实际使用空间是否也为1.58T了?

这个时候,我们需要关注一个全局参数,storage.overprovisioning.factor(默认这个值为2

参数说明:Used for storage overprovisioning calculation; available storage will be (actualStorageSize * storage.overprovisioning.factor)

说白了,就是一个超配的概念,这个在虚拟化和私有云中应该还蛮常见,我们看下系统真实使用空间:

1
2
3
4
5
6
7
8
9
10
11
12
13
# df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/centos-root        50G  8.2G   42G  17% /
devtmpfs                     126G     0  126G   0%  /dev
tmpfs                        126G     0  126G   0%  /dev/shm
tmpfs                        126G   50M  126G   1%  /run
tmpfs                        126G     0  126G   0%  /sys/fs/cgroup
/dev/sda2                     497M  134M  364M  27%  /boot
/dev/sda1                     200M  9.8M  191M   5%  /boot/efi
/dev/mapper/centos-home       504G   33M  504G   1%  /home
/dev/mapper/mpathb            2.0T  2.7G  2.0T   1%  /mnt/primary
/dev/mapper/mpatha            1.0T   17G 1008G   2%  /mnt/secondary
192.168.108.4: /mnt/primary    2.0T  2.7G  2.0T   1%  /mnt/a8cb4113-f833-3430-b0c3-1f41

说明:我将这个全局变量值调整为3,所以在系统中显示的空间为(2+2*3=12T,如下可知实际存储占用的空间仅为13.7G,但在系统中显示的为1.58T(虚拟机创建的时候,系统已经把磁盘空间进行了预分配)。

1
2
3
4
[root@appcloudstack2 ~] # du -sh /mnt/primary2
11G       /mnt/primary2
[root@appcloudstack2 ~] # du -sh /mnt/primary
2.7G      /mnt/primary










本文转自 冰冻vs西瓜 51CTO博客,原文链接:http://blog.51cto.com/molewan/2053611,如需转载请自行联系原作者
目录
相关文章
|
11月前
|
存储 5G KVM
KVM存储池扩容
KVM存储池扩容
112 0
|
Kubernetes API 调度
使用 Kubernetes 扩展专用游戏服务器:第4部分-缩减节点
使用 Kubernetes 扩展专用游戏服务器:第4部分-缩减节点
131 0
使用 Kubernetes 扩展专用游戏服务器:第4部分-缩减节点
|
Kubernetes 算法 应用服务中间件
Kubernetes:应用自动扩容、收缩与稳定更新
Kubernetes:应用自动扩容、收缩与稳定更新
426 0
|
4月前
|
开发框架 Prometheus 监控
Windows监控:基于Prometheus+Grafana监控CPU、内存、磁盘、网络、GPU信息
Windows监控:基于Prometheus+Grafana监控CPU、内存、磁盘、网络、GPU信息
2614 0
Windows监控:基于Prometheus+Grafana监控CPU、内存、磁盘、网络、GPU信息
|
存储 Kubernetes Cloud Native
实现 Kubernetes 动态LocalVolume挂载本地磁盘
在 Kubernetes 体系中,存在大量的存储插件用于实现基于网络的存储系统挂载,比如NFS、GFS、Ceph和云厂商的云盘设备。但在某些用户的环境中,可能无法或没有必要搭建复杂的网络存储系统,需要一个更简单的存储方案。另外网络存储系统避免不了性能的损耗,然而对于一些分布式数据库,其在应用层已经实现了数据同步和冗余,在存储层只需要一个高性能的存储方案。 在这些情况下如何实现Kubernetes 应用的数据持久化呢?
1480 0
|
存储 Shell Perl
使用阿里云Flexvolume插件实现云盘数据卷动态扩容
云盘扩容方案文章列表: 基于Flexvolume插件的云盘动态存储卷扩容方案(本文); 基于CSI插件的云盘动态存储卷扩容方案:参考; 不适合动态扩容的场景,可以使用手动扩容云盘存储卷方案:参考; 数据卷扩容说明: 符合以下要求的集群环境可以进行动态扩容操作: Kubernetes从1.
2340 0
使用阿里云Flexvolume插件实现云盘数据卷动态扩容
|
Perl 容器 存储
使用阿里云CSI Plugin实现LVM数据卷动态扩容
概要 LVM存储类型为本地存储,并非可随着Pod迁移的可插拔的分布式存储方案,如果Pod期望在多个节点上使用相同的lvm卷,则需要在每个节点上都创建相同名字的lvm卷,这样Pod调度的时候可以继续使用相同的lvm卷名进行挂载。
11506 0
|
存储 Perl 应用服务中间件
NFS动态存储供应
        相对于静态存储, 动态存储的优势:                 ● 管理员无需预先创建大量的PV作为存储资源;                 ● 静态存储需要用户申请PVC时保证容量和读写类型与预置PV的容量及读写类型完全匹配, 而动态存储则无需如此.
14548 0