前言 关于bluestore的db应该预留多少空间,网上有很多资料 如果采用默认的 write_buffer_size=268435456 大小的话 那么几个rocksdb的数据等级是 L0: in memory L1: 256MB L2: 2.56 GB L3: 25.6 GB L4: 256 GB 设置L4那么大的ssd可以给一个osd使用有点不划算,那么空间一般计算就是L1+L2+L3将近30GB 这个可以参考下面的文章 https://blog.csdn.net/NewTyun/arti

1,prelight/preface ceph storage clusterceph block deviceceph filesystemceph object storage 此篇记录ceph block device,ceph storage cluster见上一篇 () Realiable Autonomic Distributed Object Store(可扩展自主分布式对象存储)

YY云平台Ceph Block应用实践 http://s3.yyclouds.com/public/YY%E4%BA%91%E5%B9%B3%E5%8F%B0Ceph%E5%AE%9E%E8%B7%B5.ppt 我写的书 <CEPH实战> https://www.gitbook.com/book/forest/ceph-practice/details

1.用tune2fs查看block size大小: 1 2 tune2fs -l /dev/sda1 |grep "Block size" Block size: 1024 2.用stat查看block size大小: 1 2 stat /boot/|grep "IO Block" Size: 1024 Blocks: 2 IO Block: 1024 目录 3.用dumpe2fs查看block size大小: 1 2 dumpe2fs /dev/sda1 |gre

以下内容转自:http://blog.csdn.net/samhacker/article/details/23089157?utm_source=tuicool&utm_medium=referral http://snglw.blog.51cto.com/5832405/1643587 小文件BLOCK占用 [小于块大小的小文件不会占用整个HDFS块空间.也就是说,较多的小文件会占用更多的NAMENODE的内存(记录了文件的位置等信息):再者,在文件处理时,可能会有较大的网络开销.] 一个常

1.collection中的数据大小 db.collection.dataSize() 2.为collection分配的空间大小,包括未使用的空间db.collection.storageSize() 3.collection中索引数据大小db.collection.totalIndexSize() 4.collection中索引+data所占空间db.collection.totalSize()

http://blog.163.com/drachen@126/blog/static/162607494201271435333906/ 查看os系统块的大小 [root]# /sbin/tune2fs -l /dev/sda1 查看os系统页的大小 [oracle@skate-test ~]$ getconf PAGESIZE 4096 修改块的大小: 创 建文件系统时,可以指定块的大小.如果将来在你的文件系统中是一些比较大的文件的话,使用较大的块大小将得到较好的性能.将ext2文件系统的块

这是有疑惑的一个问题,因为在董西成的<Hadoop技术内幕--深入解析MapReduce架构设计与实现原理>中提到这个值是64M,而<Hadoop权威指南>中却说是128M,到底哪个是对的呢? 我觉得应该都是对的,可能是版本不同导致的不一致,后面终于在Stack OverFlow找到了答案: 在Apache Hadoop中默认是64M,Cloudera Hadoop版本中默认是128M. ps:顺便说一下,清华大学出版社出版的<Hadoop权威指南>翻译得特别烂,实际上

  参考文档:CEPH官网集群操作文档   概述 Ceph存储集群是所有Ceph部署的基础. 基于RADOS,Ceph存储集群由两种类型的守护进程组成:Ceph OSD守护进程(OSD)将数据作为对象存储在存储节点上; Ceph Monitor(MON)维护集群映射的主副本. Ceph存储集群可能包含数千个存储节点. 最小系统将至少有一个Ceph Monitor和两个Ceph OSD守护进程用于数据复制.   Ceph文件系统,Ceph对象存储和Ceph块设备从Ceph存储集群读取数据并将数据写

auto loiface lo inet loopbackauto enp50s0f0iface enp50s0f0 inet static address 192.168.1.6 netmask 255.255.255.0 iface enp46s0f1 inet manualiface enp0s20f0u1u6 inet manualiface enp50s0f1 inet manualiface enp50s0f2 inet manualiface enp50s0f3 inet manu

前言 在ceph 14版本里面才加入了bluefs-bdev-migrate,分区迁移相关的命令,那么在12版本里面其实也是可以扩展分区的 测试的版本 [root@lab102 ceph-0]# ceph -v ceph version 12.2.13 (584a20eb0237c657dc0567da126be145106aa47e) luminous (stable) 操作方法 如果db分区之前有做独立独立分区,但是发现db的大小设置小了,想把这个db调大,或者是从ssd设备迁移到nvme的

1.概述 hadoop集群中文件的存储都是以块的形式存储在hdfs中. 2.默认值 从2.7.3版本开始block size的默认大小为128M,之前版本的默认值是64M. 3.如何修改block块的大小? 可以通过修改hdfs-site.xml文件中的dfs.blocksize对应的值. 注意:在修改HDFS的数据块大小时,首先停掉集群hadoop的运行进程,修改完毕后重新启动. 4.block块大小设置规则 在实际应用中,hdfs block块的大小设置为多少合适呢?为什么有的是64M,有的

ceph 寻址过程 1. file --- object映射, 把file分割成N个相同的对象 2. object - PG 映射, 利用静态hash得到objectID的伪随机值,在 "位与" mask 上使得object获取属于自己的PG 3. pg -- osd 映射, 将pg映射到实际的存储单元osd, RADOS 利用 crush 算法, 由pgid得到一组n个osd,再由osd daemon 执行映射到本地的object在本地系统中存储,访问,数据维护, 此次映射功能直接受

一.准备环境 4台adminos7.4 环境,存储节点上两块磁盘(sda操作系统,sdb数据盘) clientadmin storage1storage2storage3 二.配置环境 1.修改主机名(对应节点上执行) # hostnamectl set-hostname client# hostnamectl set-hostname admin# hostnamectl set-hostname storage1# hostnamectl set-hostname storage2# hos

整体架构 bluestore的诞生是为了解决filestore自身维护一套journal并同时还需要基于系统文件系统的写放大问题,并且filestore本身没有对SSD进行优化,因此bluestore相比于filestore主要做了两方面的核心工作: 去掉journal,直接管理裸设备 针对SSD进行单独优化 bluestore的整体架构如下图所示: 通过Allocator实现对裸设备的管理,直接将数据保存到设备上:同时针对metadata使用RocksDB进行保存,底层自行封装了一个BlueF

一.测试环境描述 之前我们已快速部署好一套Ceph集群(3节点),现要测试在现有集群中在线方式增加节点 如下表中可以看到增加节点node004具体配置 主机名 Public网络 管理网络 集群网络 说明 admin 192.168.2.39 172.200.50.39 --- 管理节点 node001 192.168.2.40 172.200.50.40 192.168.3.40 MON,OSD node002 192.168.2.41 172.200.50.41 192.168.3.41 MO

https://blog.51cto.com/99cloud/2119884 Ceph bluestore部署 首先为大家分享Ceph bluestore具体该如何部署,使用环境如下• 单节点• CentOS 7.4• 使用 ceph-deploy 进行部署准备 centos 7.4 系统的机器,并配置好 ssh 的无密码登录. 安装 ceph-deployyum install https://download.ceph.com/rpm-luminous/el7/noarch/ceph-dep

kolla-ceph来源: 项目中的部分代码来自于kolla和kolla-ansible kolla-ceph的介绍: 1.镜像的构建很方便, 基于容器的方式部署,创建.删除方便 2.kolla-ceph的操作幂等,多次执行不会产生副作用 3.使用kolla-ceph(基于ansible)流程化部署 4.通过给磁盘打上相应标签,创建osd非常简单 5.升级便捷,通过构建新的ceph镜像,upgrade既可 6.自动根据osd节点数量来设置故障域: "osd" 或 "host&

kolla-ceph来源: 项目中的部分代码来自于kolla和kolla-ansible kolla-ceph的介绍: 1.镜像的构建很方便, 基于容器的方式部署,创建.删除方便 2.kolla-ceph的操作幂等,多次执行不会产生副作用 3.使用kolla-ceph(基于ansible)流程化部署 4.通过给磁盘打上相应标签,创建osd非常简单 5.升级便捷,通过构建新的ceph镜像,upgrade既可 6.自动根据osd节点数量来设置故障域: "osd" 或 "host&

背景:最近采购了一批新的服务器,底层的存储设备的默认physical sector size从原有的 512B 改为了 4K. 装完系统以后,在做数据库物理备份恢复时xtrabackup报了这么一个错.但是同样的备份在512B sector size的老系统上却可以恢复. 报错如下: InnoDB: Error: tried to read 2048 bytes at offset 0 0.InnoDB: Was only able to read 0.140304 18:48:12  Inno