暂未分类
未读这个已经很久之前已经实践成功了，现在正好有时间就来写一写，目前并没有在其他地方有类似的分享，虽然我们自己的业务并没有涉及到云计算的场景，之前还是对rbd镜像这一块做了一些基本的了解，因为一直比较关注故障恢复这一块，东西并不难，总之一切不要等到出了问题再去想办法，提前准备总是好的，如果你有集群的问题，生产环境需要恢复的欢迎找我
前言rbd的镜像的元数据，这个是什么？这里所提到的元数据信息，是指跟这个image信息有关的元数据信息，就是image的大小名称等等一系列的信息，本篇将讲述怎么去重构这些信息，重构的前提就是做好了信息的记录，然后做重构
记录元数据信息创建一个image1[root@lab8106 ~]# rbd -p rbd create zp --size 40000
这里是在rbd存储池当中创建的一个名称为zp的，大小为40G的image文件
如果没有其他的image的情况下，我们来查看下对象信息
1234[root@lab8106 ~]# rados -p rbd lsrbd_header.60276b8b4567rbd_directoryrbd_id.zp
将这几个镜像下 ...
暂未分类
未读分区提示未对齐12345678910111213141516[root@lab8106 ceph]# parted /dev/sdd GNU Parted 3.1Using /dev/sddWelcome to GNU Parted! Type 'help' to view a list of commands.(parted) p Model: SEAGATE ST3300657SS (scsi)Disk /dev/sdd: 300GBSector size (logical/physical): 512B/512BPartition Table: gptDisk Flags: Number Start End Size File system Name Flags(parted) mkpart primary 0 100% Warning: ...
暂未分类
未读前言快照的功能一般是基于时间点做一个标记，然后在某些需要的时候，将状态恢复到标记的那个点，这个有一个前提是底层的东西没用破坏，举个简单的例子，Vmware 里面对虚拟机做了一个快照，然后做了一些系统的操作，想恢复快照，前提是存储快照的存储系统没用破坏，一旦破坏了是无法恢复的
ceph里面也有快照的功能，同样的，在这里的快照是用来保存存储系统上的状态的，数据的快照能成功恢复的前提是存储系统是好的，而一旦存储系统坏了，快照同时会失效的，本篇文章利用ceph的快照去实现一个增量的备份功能，网上也有很多这个脚本，这里主要是对里面细节做一个实践，具体集成到一套系统里面去，自己去做一个策略就行了，总之多备份一下，以备不时之需，并且也可以实现跨机房的增量备份，这个在某些云计算公司已经实现了，这样一旦发生故障的时候，能够把损失减到最小
快照的创建和数据的导出
上图是一个快照的创建和导出的过程，这里详细的描述下这些操作创建快照
12rbd snap create testimage@v1rbd snap create testimage@v2
这两个命令是在时间点v1和时间点v2分别做了两个快照
1r ...
暂未分类
未读功能介绍关于rgw实现nfs接口这个，刚接触的人可能并不清楚这个是个什么样的服务架构，rgw是ceph里面的对象存储接口，而nfs则是纯正的网络文件系统接口，这二者如何结合在一起,关于这个,有几个相关的链接供大家了解
ceph官方的RGW_NFS项目规划
麦子迈关于RGW_NFS的文章
之所以这个功能能实现这么快，原因是nfs-ganesha的开发者Matt Benjamin加入到了Redhat，而ceph目前的开发是Redhat在主导开发，所以功能的实现是非常快的，但是目前官方并没有提供相关的文档，个人推测是功能并未完全开发完成，一旦未完全开发完成的功能放出来，邮件列表和Bug列表就会有很多相关问题，开发者应该还是希望安静的把功能做好，再提供相关的文档，而这个功能也是在ceph 的jewel版本里面才加入的
功能架构图简单说明一下：集群配置s3接口，nfs-genesha将s3接口转换成nfs，然后nfs客户端挂载后访问的就是s3的bucket里面的数据了
准备工作准备代码，这个是需要从源码编译的，并且需要将模块编译进去才可以的，源码分支地址：
https://github.c ...
我理解的CPU目前对cpu的了解停留在这个水平查看CPU型号：
12cat /proc/cpuinfo |grep model |tail -n 1model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
查看有多少processor：
12cat /proc/cpuinfo |grep processor|tail -n 1processor : 23
然后对性能要求就是主频越高越好，processor越多越好，其它的知道的很少，由于需要做性能相关调优，所以对CPU这一块做一个系统的学习，如果参考网上的一些CEPH性能调优的资料，很多地方都是让关闭numa，以免影响性能，这个从来都是只有人给出答案，至于为什么，对不对，适合不适合你的环境，没有人给出来，没有数据支持的调优都是耍流氓
单核和多核在英文里面，单核（single-core）和多核（multi-core）多称作uniprocessor和multiprocessor，这里先对这些概念做一个说明：
这里所说的core（或processor），是一个泛指，是从使用者（或消费者） ...
在jewel版本下默认开启了rbd的一些属性
12[root@lab8106 ~]# ceph --show-config|grep rbd|grep features rbd_default_features = 61
RBD属性表：61的意思是上面图中的bit码相加得到的值
对rbd进行内核的map操作
12345[root@lab8106 ~]# rbd map mytestrbd: sysfs write failedRBD image feature set mismatch. You can disable features unsupported by the kernel with "rbd feature disable".In some cases useful info is found in syslog - try "dmesg | tail" or so.rbd: map failed: (6) No such device or address
根据提示查询打印的信息
12[root@lab8106 ~]# dm ...
ceph是目前开源分布式存储里面最好的一个，但是在高负载下会有很多异常的情况会发生，有些问题无法完全避免，但是可以进行一定的控制，比如：在虚拟化场景下，重启osd会让虚拟机挂起的情况
重新启动osd会给这个osd进程所在的磁盘带来额外的负载，随着前面业务的需求的增长，会增加对存储的I/O的需求，虽然这个对于整个业务系统来说是好事，但是在某些情况下，会越来越接近存储吞吐量的极限，通常情况下没有异常发生的时候，都是正常的，一旦发生异常，集群超过了临界值，性能会变得剧烈的抖动
对于这种情况，一般会升级硬件来避免集群从一个高负载的集群变成一个过载的集群。本章节的重点在重启osd进程这个问题
问题分析OSD重启是需要重视的，这个地方是ceph的一个设计的弱点。ceph集群有很多的OSD进程，OSD管理对磁盘上的对象的访问，磁盘的对象被分布到PG组当中，对象有相同的分布，副本会在相同的PG当中存在，如果不理解可以看看（ceph概览）
当集群OSD进程出现down的情况，会被mon认为 “OUT” 了，这个 “OUT” 不是触发迁移的那个 “OUT”，是不服务的 “OUT” ,这个OSD上 ...
暂未分类
未读前情介绍SPDKSPDK的全称为Storage Performance Development Kit ，是Intel发起的一个开源驱动项目，这个是一个开发套件，可以让应用程序在用户态去访问存储资源，具体做能做什么可以去官网看一下 SPDK官网
NVMENVMe其实与AHCI一样都是逻辑设备接口标准，NVMe全称Non-Volatile Memory Express，非易失性存储器标准，是使用PCI-E通道的SSD一种规范，NVMe的设计之初就有充分利用到PCI-E SSD的低延时以及并行性，还有当代处理器、平台与应用的并行性。SSD的并行性可以充分被主机的硬件与软件充分利用，相比与现在的AHCI标准，NVMe标准可以带来多方面的性能提升。
BluestoreBlueStore 是用来存储ceph的数据的地方，提供了一种在块设备上直接写入方式的存储。这个是因为之前ceph社区尝试做了一个kvstore，但是性能达不到想要的效果，然后基于rocksdb的原型，重新开发了一套存储系统，BlueStore直接消耗原始分区。还有一个分区是存储元数据的，实际上就是一个RocksDB键/ ...
如果是在做ceph的配置，我们会经常遇到这几个问题
问：ceph需要配置几个mon答：配置一个可以，但是坏了一个就不行了，需要配置只是三个mon，并且需要是奇数个
问：ceph的mon能跟osd放在一起么，需要配置很好么？答：能跟放在一起，但是建议在环境允许的情况下一定独立机器，并且mon的配置能好尽量好，能上ssd就上ssd
这两个问题的答案不能说是错的，但是为什么这么说，这么说有没有问题，这篇文章将根据实际的数据来告诉你，到底mon的极限在哪里，为什么都说要奇数，偶数难道就不行么
前言本篇将从真实的实践中，让你更能够理解mon的故障极限，本次测试的场景数据样本足够大，最大的一个测试使用了10个mon，我想目前就算PB基本的ceph集群里也没有人会超过10个mon，所以足够覆盖大部分的场景，先来一个数据图看下10个mon的集群长什么样
123456789cluster ace3c18f-b4a5-4342-a598-8104a770d4a8 health HEALTH_OK monmap e10: 10 mons at {10=192.168.8.107 ...
jewel版本新增加了一个驱动NBD，允许librbd实现一个内核级别的rbd
NBD相比较于kernel rbd：
rbd-ko是根据内核主线走的，升级kernel
rbd需要升级到相应的内核，改动太大
rbd-ko的开发要慢于librbd，需要很多的时间才能追赶上librbd
rbd-nbd是通过librbd这个用户空间通过nbd的内核模块实现了内核级别的驱动，稳定性和性能都有保障
怎么理解用户态和内核态？
librbd就是用户态，一般的kvm对接的就是librbd的
kernel rbd就是内核态，这个是一个内核模块，是内核直接与osd交互的，一般来说内核态的性能会优于用户态
下面来做下基本的操作：创建一个image1[root@lab8106 ~]# rbd create testnbdrbd -s 10G
映射这个image12[root@lab8106 ~]# rbd-nbd map rbd/testnbdrbd/dev/nbd0
查询已经映射的nbd12[root@lab8106 ~]# rbd-nbd list-mapped/dev/nbd0
上面说了这么多， ...
