ceph 存储BlueStore的OSD创建与启动

admin · 发表于 2021-12-8 15:16:54

为什么需要BlueStore

Ceph作为软件定义存储(SDS)解决方案，其首要目标是保障存储数据的安全。为了达到数据安全的目的，Ceph使用了WAL的方式（Write-Ahead-Log)，这就是我们日常最熟悉的journal.

但是写前记录日志这种技术有一个主要缺陷就是它把你的硬盘性能降低到原来的二分之一（仅当日志和OSD数据共享同一个硬盘时），因为filestore在写数据前需要先写journal，所以有一倍的写放大。

filestore设计初衷就是就是为了充分发挥普通机械盘的性能，没有对SSD进行优化考虑。但随着SSD全面普及(主要性价比越来越实惠，也是新技术不断推陈出新的结果）,Ceph应用在SSD之上案例越来越多，对于性能的需求是更加迫切。基于以上现实，社区推出了Bluestore的存储引擎，剔除journal方案，缩减写放大，优化SSD写入，同时数据直写裸盘。

BlueStore架构

整体架构

内部组件

RocksDB: 存储预写式日志、数据对象元数据、Ceph的omap数据信息、以及分配器的元数据（分配器负责决定真正的数据应在什么地方存储）
BlueRocksEnv: 与RocksDB交互的接口
BlueFS: 迷你的文件系统（相对于xfs，ext2/3/4系列而言)，解决元数据、文件空间及磁盘空间的分配和管理。因为rocksdb一般是直接存储在POSIX兼容的文件系统（如ext3/xfs等）之上，但BlueStore引擎是直接面向裸盘管理，没有直接兼容POSIX的文件接口。但幸运的是，rocksdb的开发者充分考虑了适配性，只要实现了rocksdb::Env 接口，就能持久化rocksdb的数据存储(包含RocksDB日志和sst文件)。BlueStore就是为此而设计开发的，它只包含了最小的功能，用来承接rocksdb。在osd启动的时候，它会被"mount"起来，并完全载入内存
Allocator: 用来从空闲空间分配block（block是可分配的最小单位)( U) f; i8 E$ ^/ a+ r

说明：
4 u3 `+ m, B: w$ Z1.对象数据存储部分即osd指定的data设备(可以是裸盘分区，或者lvm卷，下同)* P! x; E: s* O% { z8 [
2.RocksDB日志即osd指定的wal设备0 y: p H0 M5 v e K4 }7 f. x
3.RocksDB数据部分即osd指定的db设备/ s8 N1 S% @7 B( U
4.以上设备可以共用同一物理盘设备，也可以分开在不同的物理设备,这充分体现了ceph的灵活性

以上只是本人粗糙的理解(未必完全正确或者跟实际有出入)，希望有大师出来指点一二。

部署实战基础环境

1
2
3

[root@compute ~]# ceph -v
ceph version 13.2.0 (79a10589f1f80dfe21e8f9794365ed98143071c4) mimic (stable)

在创建osd之前，集群已经初始化完毕（即已经有Mon节点）。先熟悉下ceph-volume,可以看到当前支持lvm和simple两类子命令集。lvm用来创建osd，simple则是管理已经创建的osd。

1
2
3
4
5
6
7

ceph-volume -h

... <中间省略>
Available subcommands:

lvm Use LVM and LVM-based technologies like dmcache to deploy OSDs
simple Manage already deployed OSDs with ceph-volume

预先创建好需要的lvm卷,如果没有独立的盘来单独存放wal和db,不推荐再在设备上面创建lvm卷分配给db和wal。默认只需要指定数据路径(–data)即可。Bluestore会自动管理所有的空间（包括data、db、wal)。

注意
2 N, N6 _8 R+ u如果有独立的盘来存放db，官方推荐db的空间不应小于数据空间的4%,以1T的数据空间为例，db的大小不应该小于40G.官方连接

创建lvm卷

以下创建的lvm卷只做演示用，data、db、wal分别创建独立的卷

1
2
3
4
5
6
7
8
9
10
11

[root@compute osd]# vgcreate osd.3  /dev/sde
  Volume group "osd.3" successfully created

[root@compute osd]# lvcreate  -L 1G  -n  osd.3.db osd.3
  Logical volume "osd.3.db" created.

[root@compute osd]# lvcreate  -L 1G  -n  osd.3.wal osd.3
  Logical volume "osd.3.wal" created.

[root@compute osd]# lvcreate  -l 100%FREE -n osd.3.data osd.3
  Logical volume "osd.3.data" created.

创建osd

image_1cn618mlp1eskvqdeov12o1vgj19.png-232.8kB

从上面的截图其实可以把整个create流程分解为prepare和activate阶段，下面就开始庖丁解牛。

prepare 阶段

收集keyring
1& L) Y3 }: l/ Y" m$ ]- R& P- {4 g

Running command: /bin/ceph-authtool --gen-print-key" L4 j2 o+ j" M) o) _0 o' d6 j' J

创建新的osd id

1

Running command: /bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new 9501a491-625f-4c2c-bf8e-a1a27cc0e6e5

挂载tmpfs目录，这不同于旧版本使用本地文件系统。BlueStore把这些依赖的文件信息都写入到了裸盘里（在osd启动之前，会重新生成）
1) S/ Y. y9 d$ i2 ?8 j

Running command: /bin/mount -t tmpfs tmpfs
6 C+ o0 b# b, M" c! w" b+ O
data对应设备创建软链
1
* ?! o; ~2 \) S9 r
Running command: /bin/ln -s /dev/osd.3/osd.3.data /var/lib/ceph/osd/ceph-3/block
0 r+ G0 r9 k9 w

获取当前集群的monmap

1

Running command: /bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring mon getmap -o /var/lib/ceph/osd/ceph-3/activate.monmap

写入keyring文件并在集群注册
1
8 F0 W1 e' g$ X! Y
Running command: /bin/ceph-authtool /var/lib/ceph/osd/ceph-3/keyring --create-keyring --name osd.3 --add-key AQCy/Zdb4rTZIRAApGGe5QENqb/UPUHVRzI5Dw==
, L; u0 H; Q# \" `

keyring文件和工作目录以及设备的权限设置

1
2
3
4

Running command: /bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-3/keyring
Running command: /bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-3/
Running command: /bin/chown -R ceph:ceph /dev/dm-16
Running command: /bin/chown -R ceph:ceph /dev/dm-15

mkfs初始化bluestore

1

Running command: /bin/ceph-osd --cluster ceph --osd-objectstore bluestore --mkfs -i 3 --monmap /var/lib/ceph/osd/ceph-3/activate.monmap --keyfile - --bluestore-block-wal-path /dev/osd.3/osd.3.wal --bluestore-block-db-path /dev/osd.3/osd.3.db --osd-data /var/lib/ceph/osd/ceph-3/ --osd-uuid 9501a491-625f-4c2c-bf8e-a1a27cc0e6e5 --setuser ceph --setgroup ceph

以上就是prepare的过程中涉及到的相关操作。

acitivate 阶段

从裸设备里直接获取启动OSD需要的相关元数据信息并写入到工作目录里(这些信息都存储在BlueStore的label里)
1
. d. n7 H4 u* ?! v( D Z2 m' @
Running command: /bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/osd.3/osd.3.data --path /var/lib/ceph/osd/ceph-3
( h! w( {2 k; p2 z! ~

可以通过以下命令获取label信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

ceph-bluestore-tool  show-label --path /var/lib/ceph/osd/ceph-3
{
"/var/lib/ceph/osd/ceph-3/block": {
      "osd_uuid": "9501a491-625f-4c2c-bf8e-a1a27cc0e6e5",
      "size": 2997882978304,
      "btime": "2018-09-11 17:39:00.380028",
      "description": "main",
      "bluefs": "1",
      "ceph_fsid": "a02fbd16-0db7-477d-8f16-a7d3cbfd8d73",
      "kv_backend": "rocksdb",
      "magic": "ceph osd volume v026",
      "mkfs_done": "yes",
      "osd_key": "AQCy/Zdb4rTZIRAApGGe5QENqb/UPUHVRzI5Dw==",
      "path_block.db": "/dev/osd.3/osd.3.db",
      "path_block.wal": "/dev/osd.3/osd.3.wal",
      "ready": "ready",
      "whoami": "3"
},
"/var/lib/ceph/osd/ceph-3/block.wal": {
      "osd_uuid": "9501a491-625f-4c2c-bf8e-a1a27cc0e6e5",
      "size": 1073741824,
      "btime": "2018-09-11 17:39:00.381666",
      "description": "bluefs wal"
},
"/var/lib/ceph/osd/ceph-3/block.db": {
      "osd_uuid": "9501a491-625f-4c2c-bf8e-a1a27cc0e6e5",
      "size": 1073741824,
      "btime": "2018-09-11 17:39:00.380983",
      "description": "bluefs db"
}
}

创建设备文件软链并变更设备的所有者和组

1
2
3
4
5
6
7

Running command: /bin/ln -snf /dev/osd.3/osd.3.data /var/lib/ceph/osd/ceph-3/block
Running command: /bin/chown -R ceph:ceph /dev/dm-17
Running command: /bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-3
Running command: /bin/ln -snf /dev/osd.3/osd.3.db /var/lib/ceph/osd/ceph-3/block.db
Running command: /bin/chown -R ceph:ceph /dev/dm-15
Running command: /bin/ln -snf /dev/osd.3/osd.3.wal /var/lib/ceph/osd/ceph-3/block.wal
Running command: /bin/chown -R ceph:ceph /dev/dm-16

注册系统服务(稍后分析，继续往下看）

1
2

Running command: /bin/systemctl enable ceph-volume@lvm-3-9501a491-625f-4c2c-bf8e-a1a27cc0e6e5
stderr: Created symlink from /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-3-9501a491-625f-4c2c-bf8e-a1a27cc0e6e5.service to /usr/lib/systemd/system/ceph-volume@.service.

启动osd
1
( l, S& R6 B6 K' L2
3 \: Z9 Y/ O% r( d. }
Running command: /bin/systemctl start ceph-osd@32 ]4 t" z6 q: w$ Q; N5 `
--> ceph-volume lvm activate successful for osd ID: 37 n6 Y* |6 l( A. j3 `6 C) v3 \

acitivate阶段结束，osd进程就起来了

7 H) t- C* R) J$ n

小结：
! r! Z+ K- F0 E. ^以上分解的osd创建步骤，为后续使用ansible来自动化部署Ceph集群至关重要。后续打算写个简单部署ceph的playbook，在此先mark下。

启动分析

BlueStore的OSD启动不同于老版本基于udev规则触发ceph-disk相关命令来启动，它依赖于ceph-volume相关服务与命令。

ceph-volume 系统服务

上面可以看到，在创建osd的过程中有注册一个系统服务ceph-volume@lvm-3-9501a491-625f-4c2c-bf8e-a1a27cc0e6e5,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#cat /usr/lib/systemd/system/ceph-volume@.service
[Unit]
Description=Ceph Volume activation: %i
After=local-fs.target
Wants=local-fs.target

[Service]
Type=oneshot
KillMode=none
Environment=CEPH_VOLUME_TIMEOUT=10000
ExecStart=/bin/sh -c 'timeout $CEPH_VOLUME_TIMEOUT /usr/sbin/ceph-volume-systemd %i'
TimeoutSec=0

[Install]
WantedBy=multi-user.target

这个系统服务是在local-fs之后就执行了，优先级别是比较高的。这个服务传入的参数是lvm-3-9501a491-625f-4c2c-bf8e-a1a27cc0e6e5。其时可以分解为lvm、3、9501a491-625f-4c2c-bf8e-a1a27cc0e6e5.见明知意，分别是是lvm标签，osd的id,osd的uuid。
系统服务只有一个简单的脚本。

1
2
3
4
5
6
7

# cat /usr/sbin/ceph-volume-systemd
#!/usr/bin/python2.7

from ceph_volume.systemd import main

if __name__ == '__main__':
main.main()

从上面看，已经开始进入ceph-volume项目了。
项目路径是ceph/src/ceph-volume

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

## ceph/src/ceph-volume/systemd/main
def main(args=None):
"""
... < 中间省略>
      ## 转换为ceph-volume lvm 命令继续执行 ##
      ceph-volume lvm trigger 0-8715BEB4-15C5-49DE-BA6F-401086EC7B41

"""
log.setup(name='ceph-volume-systemd.log', log_path='/var/log/ceph/ceph-volume-systemd.log')
logger = logging.getLogger('systemd')
   ... < 中间省略>
   ## 参数解析
sub_command = parse_subcommand(suffix)
extra_data = parse_extra_data(suffix)
... < 中间省略>
## 构造成为['ceph-volume','lvm','trigger','id-uuid']的格式
command = ['ceph-volume', sub_command, 'trigger', extra_data]
tries = os.environ.get('CEPH_VOLUME_SYSTEMD_TRIES', 30)
interval = os.environ.get('CEPH_VOLUME_SYSTEMD_INTERVAL', 5)
... < 中间省略>
         process.run(command, terminal_logging=False) ##下一步执行入口##

这里只是对传入的参数进行处理，最后调用ceph-volume lvm trigger

ceph-volume lvm trigger 处理

1
2
3
4
5
6
7

#cat /usr/sbin/ceph-volume
#!/usr/bin/python2.7

from ceph_volume import main

if __name__ == '__main__':
main.Volume()

下面进入ceph/src/ceph-volume/main，找到入口函数main()

1
2
3
4
5
6
7
8
9
10

def main(self, argv):
# these need to be available for the help, which gets parsed super
# early
## 一些预备处理，比如日志，ceph配置路径等
self.load_ceph_conf_path()
self.load_log_path()
self.enable_plugins()
main_args, subcommand_args = self._get_split_args()
...<中间省略>
terminal.dispatch(self.mapper, subcommand_args)

最终进入的是terminal.dispatch，核心是传入的参数。
以下是pdb的结果，其实这是一个工厂模式的设计实现，根据subcommand_args里类型，创建对应的实例，通过实例方法实现功能处理。
image_1cn6k8a3e1f754eu15armjhcgj9.png-25.6kB

1
2
3
4
5
6
7
8
9
10
11

## ceph/src/ceph-volume/ceph_volume/terminal.py
def dispatch(mapper, argv=None):
argv = argv or sys.argv
for count, arg in enumerate(argv, 1):
      if arg in mapper.keys():
         ## 创建实例
         instance = mapper.get(arg)(argv[count:])
         if hasattr(instance, 'main'):
            ## 实例main方法
            instance.main()
            raise SystemExit(0)

显然根据传入的参数创建了LVM的实例，然后进入实例的main方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

## ceph/src/ceph-volume/ceph_volume/devices/lvm/main.py
class LVM(object):
   mapper = {
   'activate': activate.Activate,
   'batch': batch.Batch,
   'prepare': prepare.Prepare,
   'create': create.Create,
   'trigger': trigger.Trigger,  ### 关注这里###
   'list': listing.List,
   'zap': zap.Zap,
}
def main(self):
   terminal.dispatch(self.mapper, self.argv)
   ...<中间省略>

跟前面如出一辙，根据传入的参数对应进入trigger.Trigger实例的main方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

## ceph/src/ceph-volume/ceph_volume/devices/lvm/trigger.py
class Trigger(object):

help = 'systemd helper to activate an OSD'

def __init__(self, argv):
      self.argv = argv

@decorators.needs_root
def main(self):
      ... <中间省略>
      ## 解析参数
      args = parser.parse_args(self.argv)
      ## 检验osd id
      osd_id = parse_osd_id(args.systemd_data)
      ## 检验uuid
      osd_uuid = parse_osd_uuid(args.systemd_data)
      ## 再次跳转到Activate实例main方法
      Activate(['--auto-detect-objectstore', osd_id, osd_uuid]).main()

以下是Activate类的main方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

##ceph/src/ceph-volume/ceph_volume/devices/lvm/activate.py
def main(self):
sub_command_help = dedent("""
...<中间省略>
)
## 参数解析
args = parser.parse_args(self.argv)
## 如果不指定是bluestore或者filestore,默认按bluestore来处理
if not args.bluestore and not args.filestore:
      args.bluestore = True
if args.activate_all:
      self.activate_all(args)
else:
      self.activate(args)

最后通过实例的activate方法来激活

1
2
3
4
5
6
7
8
9
10
11
12
13
14

##ceph/src/ceph-volume/ceph_volume/devices/lvm/activate.py
def activate(self, args, osd_id=None, osd_fsid=None):
      ...<中间省略>
   ## 获取本地所有的lvm卷信息
   lvs = api.Volumes()
   ...<中间省略>
         for lv in lvs:
               ....
   ## 通过lvm的tags来判断传入的osd id跟uuid是否已经存在，这些tags是在创建osd的时候写入（请继续往下看^_^）
         return activate_bluestore(lvs)
   if args.bluestore:
         activate_bluestore(lvs, no_systemd=args.no_systemd)
   elif args.filestore:
         activate_filestore(lvs, no_systemd=args.no_systemd)

BlueStore的osd则继续跳转到activate_bluestore

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

##ceph/src/ceph-volume/ceph_volume/devices/lvm/activate.py
def activate_bluestore(lvs, no_systemd=False):
# 从tags里找osd相关id、fsid、cluster_name等信息
osd_lv = lvs.get(lv_tags={'ceph.type': 'block'})
if not osd_lv:
      raise RuntimeError('could not find a bluestore OSD to activate')
is_encrypted = osd_lv.tags.get('ceph.encrypted', '0') == '1'
dmcrypt_secret = None
osd_id = osd_lv.tags['ceph.osd_id']
conf.cluster = osd_lv.tags['ceph.cluster_name']
osd_fsid = osd_lv.tags['ceph.osd_fsid']

osd_path = '/var/lib/ceph/osd/%s-%s' % (conf.cluster, osd_id)
### 有没有很熟悉，其时就是前面分析的activate阶段的相关命令###
if not system.path_is_mounted(osd_path):
      # ## 创建工作目录并挂载tmpfs
      prepare_utils.create_osd_path(osd_id, tmpfs=True)
## 构建data、db、wal的软链路径
for link_name in ['block', 'block.db', 'block.wal']:
      link_path = os.path.join(osd_path, link_name)
      if os.path.exists(link_path):
         os.unlink(os.path.join(osd_path, link_name))
## 获取设备路径 ##
db_device_path = get_osd_device_path(osd_lv, lvs, 'db', dmcrypt_secret=dmcrypt_secret)
wal_device_path = get_osd_device_path(osd_lv, lvs, 'wal', dmcrypt_secret=dmcrypt_secret)

### 看这里！看这里！看这里！重要的事情说三遍，就是调用ceph-bluestore-tool工具读出元数据并写入工作目录，一模一样，下面都一样了。很熟悉了吧  ^__^
process.run([
      'ceph-bluestore-tool', '--cluster=%s' % conf.cluster,
      'prime-osd-dir', '--dev', osd_lv_path,
      '--path', osd_path])

process.run(['ln', '-snf', osd_lv_path, os.path.join(osd_path, 'block')])
## 所有者修改以及创建软连
system.chown(os.path.join(osd_path, 'block'))
system.chown(osd_path)
if db_device_path:
      destination = os.path.join(osd_path, 'block.db')
      process.run(['ln', '-snf', db_device_path, destination])
      system.chown(db_device_path)
if wal_device_path:
      destination = os.path.join(osd_path, 'block.wal')
      process.run(['ln', '-snf', wal_device_path, destination])
      system.chown(wal_device_path)

if no_systemd is False:
      # enable the ceph-volume unit for this OSD
      systemctl.enable_volume(osd_id, osd_fsid, 'lvm')

      # 启动osd进程
      systemctl.start_osd(osd_id)
terminal.success("ceph-volume lvm activate successful for osd ID: %s" % osd_id)

到此，相信大部分读者已经豁然开朗了。ceph-volume系统服务会触发ceph-volume lvm trigger，再进入activate阶段，最后一系列的系统命令调用，完成osd启动。

整个启动流程大致如下图所示：
image_1cn8kcnnbh521niu16djegnqhb4d.png-40.8kB

创建分析

osd的创建跟启动代码入口是一样的,都是从ceph/src/ceph-volume/main的main()开始

image_1cn8melrej3a5glk0c1cpqeqv4q.png-21.5kB
根据传入的mapper和argv，再次回看下terminal.py里的dispatch

1
2
3
4
5
6
7
8
9
10
11

## ceph/src/ceph-volume/ceph_volume/terminal.py
def dispatch(mapper, argv=None):
argv = argv or sys.argv
for count, arg in enumerate(argv, 1):
      if arg in mapper.keys():
         ## 创建实例
         instance = mapper.get(arg)(argv[count:])
         if hasattr(instance, 'main'):
            ## 实例main方法
            instance.main()
            raise SystemExit(0)

如下图所示的LVM的类变量mapper,结合上面内容，实例instacne实际上就是create.Create(),然后执行实例的main()方法
image_1cn8i7f3l12b61ap1i0a1u1h124440.png-65.5kB

1
2
3
4
5
6
7
8
9
10
11
12
13
14

## ceph/src/ceph-volume/ceph_volume/devices/lvm/create.py
def main(self):
   ... <中间省略>
   ## 解析参数
   if len(self.argv) == 0:
      print(sub_command_help)
      return
   exclude_group_options(parser, groups=['filestore', 'bluestore'], argv=self.argv)
   args = parser.parse_args(self.argv)
   ## 判断是bluestore还是filestore,默认为bluestore
   if not args.bluestore and not args.filestore:
      args.bluestore = True
   ## 调用create()方法
   self.create(args)

进入create()方法，重点关注它里包含了创建Prepare实例，然后进入Activate().activate(),这在前面启动阶段已经分析了。下面重点分析下Prepare里具体做了哪些处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

## ceph/src/ceph-volume/ceph_volume/devices/lvm/create.py
@decorators.needs_root
def create(self, args):
if not args.osd_fsid:
      args.osd_fsid = system.generate_uuid()
### 注意看这里!! 包含了prepare ###
prepare_step = Prepare([])
prepare_step.safe_prepare(args)
osd_id = prepare_step.osd_id
try:
      Activate([]).activate(args)
except Exception:
      logger.error('lvm activate was unable to complete, while creating the OSD')
      logger.info('will rollback OSD ID creation')
      ## 创建失败，就回滚，删除osd，其实就是调用ceph osd purge 相关命令 ##
      rollback_osd(args, osd_id)
      raise
terminal.success("ceph-volume lvm create successful for: %s" % args.data)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

##ceph/src/ceph-volume/ceph_volume/devices/lvm/prepare.py
@decorators.needs_root
def prepare(self, args):

...<中间省略>

### 创建osd的一些准备工作，比如keyring，osd id，osd uuid等
cluster_fsid = conf.ceph.get('global', 'fsid')
osd_fsid = args.osd_fsid or system.generate_uuid()
crush_device_class = args.crush_device_class
if crush_device_class:
      secrets['crush_device_class'] = crush_device_class
self.osd_id = prepare_utils.create_id(osd_fsid, json.dumps(secrets), osd_id=args.osd_id)
## 这些元数据打包到tags里
tags = {
      'ceph.osd_fsid': osd_fsid,
      'ceph.osd_id': self.osd_id,
      'ceph.cluster_fsid': cluster_fsid,
      'ceph.cluster_name': conf.cluster,
      'ceph.crush_device_class': crush_device_class,
}
   ...<中间省略>
      #### 看重点！！！根据传入的数据先去扫描本地所有lvm卷信息，是否已经存在，如果没有，就把这些tags写入lvm的tags里
      data_lv = self.get_lv(args.data)
      if not data_lv:
         ### prepare_device方法里会把tags写入到lvm卷的tags
         data_lv = self.prepare_device(args.data, 'data', cluster_fsid, osd_fsid)

      ...<中间省略>

      #### bluestore 初始化准备，跳转进入preabluestore继续处理
      prepare_bluestore(
         block_lv.lv_path,
         wal_device,
         db_device,
         secrets,
         tags,
         self.osd_id,
         osd_fsid,
      )

1
2
3
4
5
6
7
8
9
10

### ceph/src/ceph-volume/ceph_volume/devices/lvm/prepare.py
def prepare_bluestore(block, wal, db, secrets, tags, osd_id, fsid):
...<中间省略>
### 其中都是一些准备工作，核心就是这个初始化了,也就是前面出面过的初始化
prepare_utils.osd_mkfs_bluestore(
      osd_id, fsid,
      keyring=cephx_secret,
      wal=wal,
      db=db
)

至此，bluestore已经初始化完毕了，然后接着走启动流程就可以了。
image_1cn8n9740i5nilf19jgjl1l1264.png-45.7kB

小结

通过阅读学习ceph-volume的代码，可以清楚地理解整个osd的创建与启动流程

admin · 发表于 2021-12-8 15:24:42

1.集群硬件配置

典型硬件资源配置建议：

组件CPU内存网络存储空间
Monitor1vCore2GB1x 1GbE+ NICs单个Mon 10GB+
OSD1vCoreBlueStore后端，单个OSD 至少3 GB。裸容量每增加1 TB，则内存相应增加1 GB1x 1GbE+ NICs (建议10GbE+)一个OSD 对应一块独立的硬盘

public network和cluster network 分开。
操作系统、OSD data、OSD 日志分别使用独立的硬盘，使整体吞吐量最大化。
一般，建议单OSD 分配4GB以上的内存，多小对象或有大对象场景下对性能有提升。不建议低于2GB。
对于OSD 除显式分配的内存外，还会多约20%的额外内存开销，需要考虑到。
4 s5 C7 m V& j, F C1 B

对于采用的BlueStore的Ceph，将SSD 用在合适的地方一般可以显著提升性能：

OSD 日志建议使用SSD。如果采用bluestore，则建议裸容量配比—— block : block.db : block.wal = 100:1:1，后两者建议采用SSD或NVMe SSD。
采用cache-tiering，其中cache pool 采用SSD。
CephFS 的metadata pool 采用SSD。
RGW index pool 采用SSD。 Y7 g* i' _: ?$ _5 G& Z ]4 h$ e

2.常见性能影响因素集群性能评估

根据采用的硬件和集群规模，应当对集群有个大致的性能估算。集群性能影响因素主要有：硬盘（单个硬盘的性能和硬盘总数）、网络性能、内存和CPU。其中前两个是估算集群整体性能的主要因素，而根据场景，性能主要是IOPS和带宽。
一般：

集群读取性能：
* v9 p5 Y. \9 k

集群读取性能：W*n*μ，无论在FileStore还是BlueStore下其中，W: 单块裸盘读带宽n: OSD数量μ: 损耗系数一般为0.7~0.8

集群写入性能：
# J: N& X; j2 S1 z9 h

集群写入性能：[(W*n)/WAF]*μW: 单块裸盘写入带宽n: OSD数量WAF: 写放大系数μ: 损耗系数X: 写入数据块大小(KiB)N: 多副本Size大小K: 纠删码K值M: 纠删码M值FileStore 5: 5KiB, FileStore中transaction元数据的数据量大小（推测值）BlueStore 5: 5KiB, BlueStore中RocksDB的WAL数据大小（推测值）BlueStore 20: 20KiB, BlueStore小文件写入时产生的Zero-filled数据块大小性能瓶颈定位

经过对集群的性能评估，结合主要的影响因素，试着找出性能瓶颈的大方向。
准确的性能评估需要进行严格的性能测试：

首先是基准测试，包括硬盘基线测试（如dd）和网络基线测试（如iperf），测试前应当drop cache。
然后分别对于集群做性能测试：rados bench
RBD 性能测试：rbd bench
RGW 性能测试：cosbench
: y: A, \& u$ c

通过ceph osd perf可以看出整个集群所有OSDs 的时延数据。
更详细的时延信息可以通过perf dump调查，如

1.ceph daemon osd.15 perf reset all2.rados bench WRITE3.ceph daemon osd.15 perf dump常见性能优化点

排除硬件瓶颈的可能，则可以从常见的几项对照排查修改。

存储池的PG 数是否合理：一般，集群PGs总数 = (OSD总数 * 100 / 最大副本数)，具体可参考pgcal
monitor 采用3或5个即可。由于需要再monitor之间做数据同步，过多的monitor 会影响性能。
建议Ceph 集群和其他系统独立部署，以免资源抢占影响性能，且混合部署影响troubleshooting。
: i0 C8 W% a1 H) C# ?

3.使用Cache-tiering

使用缓存分层，可以根据需求在热层和冷层之间自动迁移数据，从而提高群集的性能。
采用的cache-tiering的前提是要搞清业务场景，因为cache-tiering 是工作负载相关的，不合适的场景匹配不合适的缓存模式（cache mode）反而会让整体性能下降。

write-back：Ceph 客户端写数据至cache tier，随后会将数据迁移至storage tier。客户端读取数据也是直接读取cache tier，若cache tier 没有会从storage tier 中获取并迁移至cache tier。客户端的读写始终不直接跟storage tier 关联。这种模式适用于可变数据的存储访问。
readproxy：使用已存在与cache tier 内的对象, 如果cache tier 内无该对象则会将请求代理至storage tier。
readonly：cache tier 仅接受读操作，写操作都会指向storage tier，预读取的对象会被迁移至cache tier，一定条件下会被迁移出cache tier。这种模式不保证一致性，读取的数据可能是过期的，适用于不变数据的存储访问。
none：完全disable cache tiering。
; R: s2 L2 \3 F7 }* [+ ^. z

cache-tiering 配置流程

首先，除storage pool 外，需要创建一个全SSD 的cache pool（通过修改 crushmap）。
根据实际场景：

数据对象是更偏向不变对象还是可变对象，决定采用什么缓存模式（cache-mode）；
根据客户端负载情况，设置和调整缓存池的参数（大小、数量等）；
其他诸如cache age、target size 等参数。
' e0 Z1 ~4 k$ U$ e# ]/ e7 Y% h

必要操作步骤：
1）关联cache pool 和后端存储池：ceph osd tier add

2）设置cache-mode：ceph osd tier cache-mode writeback

3）将原storage pool的流量指向cache pool：ceph osd tier set-overlay

4）必要的缓存阈值设置，所有的请求在达到target_max_bytes 或target_max_objects 设定值时会被阻塞

ceph osd pool set target_max_bytes {#bytes}ceph osd pool set target_max_objects {#objects}4.Damons 相关配置优化

常见配置优化项及建议值，根据实际场景可再做调整。
默认应将RGW Cache 和RBD cache打开。

OSDosd_scrub_begin_hour = 1 #根据业务实际设置在非业务时间scrubosd_scrub_end_hour = 5osd_recovery_op_priority = 3osd_client_op_priority = 63osd_recovery_max_active = 10osd_recovery_sleep = 0osd_max_backfills = 10RGW（对象存储）rgw_cache_enabled = true # 开启RGW cachergw_thread_pool_size = 2000rgw_cache_lru_size = 20000rgw_num_rados_handles = 128RBD（块存储）rbd_cache_enabled = true # 开启RBD cacherbd_cache_size = 268435456rbd_cache_max_dirty = 134217728rbd_cache_max_dirty_age = 5

admin · 发表于 2021-12-8 15:25:02

1.集群硬件配置
典型硬件资源配置建议：
组件 CPU 内存网络存储空间
Monitor 1vCore 2GB 1x 1GbE+ NICs 单个Mon 10GB+
OSD 1vCore BlueStore后端，单个OSD 至少3 GB。裸容量每增加1 TB，则内存相应增加1 GB 1x 1GbE+ NICs (建议10GbE+) 一个OSD 对应一块独立的硬盘
public network和cluster network 分开。
操作系统、OSD data、OSD 日志分别使用独立的硬盘，使整体吞吐量最大化。
一般，建议单OSD 分配4GB以上的内存，多小对象或有大对象场景下对性能有提升。不建议低于2GB。
对于OSD 除显式分配的内存外，还会多约20%的额外内存开销，需要考虑到。
对于采用的BlueStore的Ceph，将SSD 用在合适的地方一般可以显著提升性能：
OSD 日志建议使用SSD。如果采用bluestore，则建议裸容量配比—— block : block.db : block.wal = 100:1:1，后两者建议采用SSD或NVMe SSD。
采用cache-tiering，其中cache pool 采用SSD。
CephFS 的metadata pool 采用SSD。
RGW index pool 采用SSD。
2.常见性能影响因素
集群性能评估
根据采用的硬件和集群规模，应当对集群有个大致的性能估算。集群性能影响因素主要有：硬盘（单个硬盘的性能和硬盘总数）、网络性能、内存和CPU。其中前两个是估算集群整体性能的主要因素，而根据场景，性能主要是IOPS和带宽。
一般：
集群读取性能：
集群读取性能：W*n*μ，无论在FileStore还是BlueStore下
其中，
W: 单块裸盘读带宽
n: OSD数量
μ: 损耗系数一般为0.7~0.8
集群写入性能：
集群写入性能：[(W*n)/WAF]*μ
W: 单块裸盘写入带宽
n: OSD数量
WAF: 写放大系数
μ: 损耗系数
X: 写入数据块大小(KiB)
N: 多副本Size大小
K: 纠删码K值
M: 纠删码M值
FileStore 5: 5KiB, FileStore中transaction元数据的数据量大小（推测值）
BlueStore 5: 5KiB, BlueStore中RocksDB的WAL数据大小（推测值）
BlueStore 20: 20KiB, BlueStore小文件写入时产生的Zero-filled数据块大小
性能瓶颈定位
经过对集群的性能评估，结合主要的影响因素，试着找出性能瓶颈的大方向。
准确的性能评估需要进行严格的性能测试：
首先是基准测试，包括硬盘基线测试（如dd）和网络基线测试（如iperf），测试前应当drop cache。
然后分别对于集群做性能测试：rados bench
RBD 性能测试：rbd bench
RGW 性能测试：cosbench
通过ceph osd perf可以看出整个集群所有OSDs 的时延数据。
更详细的时延信息可以通过perf dump调查，如
1.ceph daemon osd.15 perf reset all
2.rados bench WRITE
3.ceph daemon osd.15 perf dump
常见性能优化点
排除硬件瓶颈的可能，则可以从常见的几项对照排查修改。
存储池的PG 数是否合理：一般，集群PGs总数 = (OSD总数 * 100 / 最大副本数)，具体可参考pgcal
monitor 采用3或5个即可。由于需要再monitor之间做数据同步，过多的monitor 会影响性能。
建议Ceph 集群和其他系统独立部署，以免资源抢占影响性能，且混合部署影响troubleshooting。
3.使用Cache-tiering
使用缓存分层，可以根据需求在热层和冷层之间自动迁移数据，从而提高群集的性能。
采用的cache-tiering的前提是要搞清业务场景，因为cache-tiering 是工作负载相关的，不合适的场景匹配不合适的缓存模式（cache mode）反而会让整体性能下降。
write-back：Ceph 客户端写数据至cache tier，随后会将数据迁移至storage tier。客户端读取数据也是直接读取cache tier，若cache tier 没有会从storage tier 中获取并迁移至cache tier。客户端的读写始终不直接跟storage tier 关联。这种模式适用于可变数据的存储访问。
readproxy：使用已存在与cache tier 内的对象, 如果cache tier 内无该对象则会将请求代理至storage tier。
readonly：cache tier 仅接受读操作，写操作都会指向storage tier，预读取的对象会被迁移至cache tier，一定条件下会被迁移出cache tier。这种模式不保证一致性，读取的数据可能是过期的，适用于不变数据的存储访问。
none：完全disable cache tiering。
cache-tiering 配置流程
首先，除storage pool 外，需要创建一个全SSD 的cache pool（通过修改 crushmap）。
根据实际场景：
数据对象是更偏向不变对象还是可变对象，决定采用什么缓存模式（cache-mode）；
根据客户端负载情况，设置和调整缓存池的参数（大小、数量等）；
其他诸如cache age、target size 等参数。
必要操作步骤：
1）关联cache pool 和后端存储池：ceph osd tier add
2）设置cache-mode：ceph osd tier cache-mode writeback
3）将原storage pool的流量指向cache pool：ceph osd tier set-overlay
4）必要的缓存阈值设置，所有的请求在达到target_max_bytes 或target_max_objects 设定值时会被阻塞
ceph osd pool set target_max_bytes {#bytes}
ceph osd pool set target_max_objects {#objects}
4.Damons 相关配置优化
常见配置优化项及建议值，根据实际场景可再做调整。
默认应将RGW Cache 和RBD cache打开。
OSD
osd_scrub_begin_hour = 1 #根据业务实际设置在非业务时间scrub
osd_scrub_end_hour = 5
osd_recovery_op_priority = 3
osd_client_op_priority = 63
osd_recovery_max_active = 10
osd_recovery_sleep = 0
osd_max_backfills = 10
RGW（对象存储）
rgw_cache_enabled = true # 开启RGW cache
rgw_thread_pool_size = 2000
rgw_cache_lru_size = 20000
rgw_num_rados_handles = 128
RBD（块存储）
rbd_cache_enabled = true # 开启RBD cache
rbd_cache_size = 268435456
rbd_cache_max_dirty = 134217728
rbd_cache_max_dirty_age = 5

admin · 发表于 2021-12-8 15:27:54

将OSD转换为Bluestore
请按照以下步骤操作，安全的清理回收磁盘，然后重新部署为类型的。
# Stop the OSD process
systemctl stop ceph-osd@.service
# Unmount the OSD
umount /dev/
# Zap the disk
ceph-disk zap
# Mark the OSD as destroyed
ceph osd destroy --yes-i-really-mean-it
# Prepare the disk as Bluestore
ceph-disk prepare --bluestore /dev/ --osd-id

admin · 发表于 2021-12-8 15:50:43

下一代对象存储引擎BlueStore

相比于目前FileStore，BlueStore拥有无与伦比的优势：

充分考虑下一代全SSD以及NVMe SSD闪存阵列的适配。例如将高效索引元数据的引擎由LevelDB替换为RocksDB。
传统的基于POSIX接口的FileStore需要通过操作系统自带的文件系统间接管理磁盘。BlueStore选择绕开文件系统，从而使得I/O路径大大减小。
在设计中将元素据和用户数据严格分离，因此元素据可以单独采用高速固态存储设备，诸如NVMe SSD，以实现性能加速。
与传统机械硬盘相比，SSD普遍采用4k 或者更大的块大小，因此采用位图进行管理可以获得更高的空间收益。

1 设计理念

在存储系统中，所有读操作都是同步的，即除非在缓存命中，否则必须从磁盘中读到指定内容才向客户端返回。而写操作则不一样，一般处于效率考虑，所有写操作都会在内存中进行缓存，由文件系统进行组织后再批量写入磁盘。

数据可靠性：我们考虑写的期间发生断电的情况，因为内存是易失性的，所有数据会丢失。针对这个问题，有人提出用一个掉电不丢失的中间设备作为过渡设备，等数据写入普通磁盘后再释放中间设备上的空间，这个写中间设备的过程被称为写日志。中间设备被称为日志设备。但这样会消耗额外硬件资源。

数据一致性：数据修改要么全部完成，要么没有变化（All or nothing）. 具体而言，我们用ACID（A: Atomicity, C: Consistency, I:Isolation, D:Durability）来描述这种系统，即事务型系统。

术语

块大小：指对磁盘进行操作的最小粒度。对普通机械硬盘为512字节，而SSD为4KB。

RMW：覆盖写。如果本次改写的内容不足一个块，那么需要将对应的块读进来，将待修改的内容与原先内容进行合并。它的问题在于：额外的读惩罚，以及潜在的数据丢失风险。

COW：写时重定向。在磁盘分配新的空间，再写入，写完成后再释放旧数据。

2 BlueStore写策略

BlueStore综合运用了RMW和COW，任何一个写请求，根据磁盘块大小，分为三个部分，即首尾非块大小对齐部分和中间块大小对齐部分，针对两边RMW，针对中间采用COW。

BlueStore提供的读写访问接口都是基于PG粒度的。

3 缓存替换机制

LRU算法：最近最少使用，时间局部性原理。

LFU算法：最近不经常使用，SDD访问模型。

ARC算法，同时考虑了LRU和LFU的长处，同时使用两个队列对缓存中页面进行管理：

MRU (Most Recently Used) 队列保存最近访问过的页面
MFU（Most Frequently Used）队列保存最近一段时间至少被访问过两次的界面。
两个队列的长度是可变的，会根据请求队列的特征自动进行调整，取LRU和LFU共同之所长。
- 当系统中请求序列呈现明显的时间局部性，MFU队列长度变为0，从而退化为LRU。
- 当系统中请求序列呈现明显的空间局部性，MRU队列长度变为0，从而退化为LFU。
  - l0 ^5 p3 { e
* j$ |/ G& f' l8 P+ o& a/ B

2Q算法：双队列热点算法，一种针对数据库特别是关系数据库系统优化的缓存淘汰算法：

数据库系统由于需要保证每个操作的原子性，所以经常存在多个事务操作同一块热点数据的场景，因此针对数据库系统的缓存淘汰算法主要关注如何识别多个并发事务之间的数据相关性。

与ARC类似，2Q也使用了多个队列来管理整个缓存空间，分布称为<span tabindex="0" class="mjx-chtml MathJax_CHTML" id="MathJax-Element-1-Frame" role="presentation" style="margin: 0px; padding: 1px 0px; border: 0px currentColor; border-image: none; text-align: left; text-transform: none; line-height: 0; text-indent: 0px; letter-spacing: normal; font-size: 19.52px; font-style: normal; font-weight: normal; word-spacing: normal; float: none; display: inline-block; white-space: nowrap; position: relative; direction: ltr; min-height: 0px; max-height: none; min-width: 0px; max-width: none; box-sizing: border-box; overflow-wrap: normal;" data-mathml='A1in,A1out,Am'>A1in,A1out,AmA1in,A1out,Am。这些队列都是LRU队列，其中<span tabindex="0" class="mjx-chtml MathJax_CHTML" id="MathJax-Element-2-Frame" role="presentation" style="margin: 0px; padding: 1px 0px; border: 0px currentColor; border-image: none; text-align: left; text-transform: none; line-height: 0; text-indent: 0px; letter-spacing: normal; font-size: 19.52px; font-style: normal; font-weight: normal; word-spacing: normal; float: none; display: inline-block; white-space: nowrap; position: relative; direction: ltr; min-height: 0px; max-height: none; min-width: 0px; max-width: none; box-sizing: border-box; overflow-wrap: normal;" data-mathml='A1in'>A1inA1in与<span tabindex="0" class="mjx-chtml MathJax_CHTML" id="MathJax-Element-3-Frame" role="presentation" style="margin: 0px; padding: 1px 0px; border: 0px currentColor; border-image: none; text-align: left; text-transform: none; line-height: 0; text-indent: 0px; letter-spacing: normal; font-size: 19.52px; font-style: normal; font-weight: normal; word-spacing: normal; float: none; display: inline-block; white-space: nowrap; position: relative; direction: ltr; min-height: 0px; max-height: none; min-width: 0px; max-width: none; box-sizing: border-box; overflow-wrap: normal;" data-mathml='Am'>AmAm是真正的缓存队列，<span tabindex="0" class="mjx-chtml MathJax_CHTML" id="MathJax-Element-4-Frame" role="presentation" style="margin: 0px; padding: 1px 0px; border: 0px currentColor; border-image: none; text-align: left; text-transform: none; line-height: 0; text-indent: 0px; letter-spacing: normal; font-size: 19.52px; font-style: normal; font-weight: normal; word-spacing: normal; float: none; display: inline-block; white-space: nowrap; position: relative; direction: ltr; min-height: 0px; max-height: none; min-width: 0px; max-width: none; box-sizing: border-box; overflow-wrap: normal;" data-mathml='A1out'>A1outA1out是影子队列，i.e.只保存相关页面的管理结构。

新的页面一开始总是被加入A1in，当某个页面被频繁访问，2Q认为这些访问是相关的，不会针对该页面执行任何热度提升的操作，直到其被正常淘汰至Aout。这个时间间隔被称为“相关时间间隔”。
当A1out中某个页面被再次访问时，2Q认为这些访问不再相关，此时执行页面热度提升，将其加入Am头部。Am队列中的页面再次被命中时，同样将其加入Am队列头部进行页面热度提升。从Am中淘汰的页面也进入A1out。这个时间间隔被称为“热度保留间隔”。/ u, w3 I6 ~5 d% J

4 缓存管理

BlueStore 目前采用了LRU和2Q两种算法。

参考Theodore和Dennis的测试结论，推荐A1in和Am队列的容量配比1:1.

BlueStore的cache既可以用于缓存用户数据，也可以用于缓存元数据。bluestore中默认元数据的比重位90%。

BlueStore中元素据分为两类：Collection和Onode. Collection是PG在BlueStore中内存管理结构。每个OSD最多承载100个PG而且Collection管理结构本身比较小，故被设计成常驻内存。而Onode的数量和其管理的磁盘空间成正比，因而不可能常驻内存，需要引入淘汰机制。Onode采用LRU。

5 BlueFS

诞生于2011年的LevelDB是基于Google的BigTable数据库系统发展而来。然而随着SSD普及，LevelDB无法发挥SSD全部性能，因而诞生了RocksDB。

RocksDB适合存储小型或者中型键值对；性能随着键值对长度上升下降很快。
性能随CPU核数以及后端存储设备的I/O能力呈线性扩展。
7 l2 T. P# f5 ^+ |

传统的本地文件系统（XFS，ext4，ZFS）等不能与RocksDB完全兼容，因而专门为其量身打造一款本地文件系统——BlueFS。在逻辑空间上分为三个层次

（1）慢速空间

主要用于存储对象数据，可由大容量机械硬盘担任存储。

（2）高速空间（DB）

主要存储BlueStore内部的元素据，比如Onode。可以由SSD提供。

（3）超高速（WAL）

WAL(Write Ahead Log)指日志。可以由NVMe SSD或NVRAM等高速设备充当。

BlueFS上的磁盘数据包括文件、目录、日志三种类型。其定位文件分为两步：1. 通过dir_map找到文件的最底层文件夹 2.通过file_map找到对应的文件。其磁盘数据结构如下：

成员

含义

ino

唯一标识一个fnode

size

文件大小

mtime

文件上一次被修改时间

prefer_bdev

存储该文件优先使用的设备

extents

磁盘上物理段集合包括{bdev，offset，length}

6 ObjectStore(OS)

Ceph是一个指导原则是所有存储的不管是块设备、对象存储、文件存储最后都转化成了底层的对象object，这个object包含3个元素data，xattr，omap。data是保存对象的数据；xattr是保存对象的扩展属性，每个对象文件都可以设置文件的属性，这个属性是一个key/value值对，这类操作的特征是kv对并且与某一个Object关联，但是受到文件系统的限制，key/value对的个数和每个value的大小都进行了限制。如果要设置的对象的key/value不能存储在文件的扩展属性中；还存在另外一种方式保存omap(在Ceph中称为omap)，omap实际上是保存到了key/vaule 值对的RocksDB中，在这里value的值限制要比xattr中好的多。

对于FileStore实现，每个Object在FileStore层会被看成是一个文件，Object的属性(xattr)会利用文件的xattr属性存取，因为有些文件系统(如Ext4)对xattr的长度有限制，因此超出长度的Metadata会被存储在DBObjectMap里。而Object的omap则直接利用DBObjectMap实现。因此，可以看出xattr和omap操作是互通的，在用户角度来说，前者可以看作是受限的长度，后者更宽泛(API没有对这些做出硬性要求)。目前纠删码还不支持omap。

而在BlueStore则没有这种限制。

部署和操作BlueStoreBLUESTORE迁移

每个OSD都可以运行BlueStore或FileStore，并且单个Ceph集群可以包含两者的混合。先前已部署FileStore的用户可能希望过渡到BlueStore，以利用改进的性能和健壮性。有几种策略可以实现这种过渡。

单个OSD不能单独进行原地转换，但是：BlueStore和FileStore根本不同，以致于无法实用。“转换”将依靠群集的正常复制和修复支持，或者依靠将OSD内容从旧的（FileStore）设备复制到新的（BlueStore）设备的工具和策略。

部署新的OSD与BLUESTORE

可以使用BlueStore部署任何新的OSD（例如，在扩展群集时）。这是默认行为，因此不需要进行特定更改。

同样，更换故障驱动器后重新配置的任何OSD都可以使用BlueStore。

将现有的OSD标记并替换

最简单的方法是依次标记每个设备，等待数据在群集中复制，重新配置OSD，然后再次将其标记回。它很容易实现自动化。但是，它需要的数据迁移量超出了必要，因此不是最佳选择。

确定要替换的FileStore OSD：
ID=<osd-id-number>DEVICE=<disk-device>Copy
您可以使用以下命令判断给定的OSD是FileStore还是BlueStore：
ceph osd metadata $ID | grep osd_objectstoreCopy
您可以使用以下命令获取文件存储与bluestore的当前计数：
ceph osd count-metadata osd_objectstoreCopy
将文件存储OSD标记为：
ceph osd out $IDCopy
等待数据从有问题的OSD迁移：
while ! ceph osd safe-to-destroy $ID ; do sleep 60 ; doneCopy
停止OSD：
systemctl kill ceph-osd@$IDCopy
记下此OSD使用的设备：
mount | grep /var/lib/ceph/osd/ceph-$IDCopy
卸载OSD：
umount /var/lib/ceph/osd/ceph-$IDCopy
销毁OSD数据。请格外小心，因为这会破坏设备的内容；在继续操作之前，请确保不需要设备上的数据（即，群集运行状况良好）。
ceph-volume lvm zap $DEVICECopy
告诉集群OSD已被破坏（并且可以使用相同的ID重新配置新的OSD）：
ceph osd destroy $ID --yes-i-really-mean-itCopy
使用相同的OSD ID在其位置重新配置BlueStore OSD。这要求您确实根据上面看到的内容确定要擦除的设备。小心！
ceph-volume lvm create --bluestore --data $DEVICE --osd-id $IDCopy
重复。
" c3 B) ^- j5 L i0 Q1 }8 O Q3 ?; D

您可以允许替换OSD的重新填充与下一个OSD的排空同时进行，或者对多个OSD并行执行相同的步骤，只要确保在销毁群集之前群集是完全干净的（所有数据具有所有副本）即可。任何OSD。否则，将减少数据的冗余，并增加（甚至可能导致）数据丢失的风险。

优点：

简单。
可以逐个设备完成。
不需要备用设备或主机。
" g8 Z8 e) b1 l

缺点：

数据通过网络复制了两次：一次复制到集群中的其他OSD（以保持所需的副本数），然后再次返回到重新配置的BlueStore OSD。" j0 a; X6 ~3 k+ _

整个主机更换

如果集群中有一个备用主机，或者有足够的可用空间来疏散整个主机以用作备用主机，则可以在每个主机的基础上使用存储的每个数据副本进行转换仅迁移一次。

首先，您需要有一个没有数据的空主机。有两种方法可以执行此操作：从尚未包含在群集中的新的空主机开始，或者从群集中现有主机上卸载数据。

使用新的，空的主机

理想情况下，主机应具有与将要转换的其他主机大致相同的容量（尽管并不严格）。

NEWHOST=<empty-host-name>Copy

将主机添加到CRUSH层次结构，但不要将其附加到根目录：

ceph osd crush add-bucket $NEWHOST hostCopy

确保已安装ceph软件包。

使用现有的主机

如果要使用已经是群集一部分的现有主机，并且该主机上有足够的可用空间，以便可以迁移其所有数据，则可以执行以下操作：

OLDHOST=<existing-cluster-host-to-offload>ceph osd crush unlink $OLDHOST defaultCopy

其中“默认”是CRUSH地图中的直接祖先。（对于具有未修改配置的较小群集，通常将是“默认”，但也可能是机架名称。）现在，您应该在OSD树输出的顶部看到没有父节点的主机：

$ bin/ceph osd treeID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF-5 0 host oldhost10 ssd 1.00000 osd.10 up 1.00000 1.0000011 ssd 1.00000 osd.11 up 1.00000 1.0000012 ssd 1.00000 osd.12 up 1.00000 1.00000-1 3.00000 root default-2 3.00000 host foo 0 ssd 1.00000 osd.0 up 1.00000 1.00000 1 ssd 1.00000 osd.1 up 1.00000 1.00000 2 ssd 1.00000 osd.2 up 1.00000 1.00000...Copy

如果一切正常，请直接跳到下面的“等待数据迁移完成”步骤，然后从那里继续进行操作以清理旧的OSD。

迁移过程

如果您使用的是新主机，请从步骤1开始。对于现有主机，请跳至下面的步骤5。

为所有设备配置新的BlueStore OSD：
ceph-volume lvm create --bluestore --data /dev/$DEVICECopy
验证OSD通过以下方式加入集群：
ceph osd treeCopy
您应该看到新主机$NEWHOST与它下面的所有的OSD的，但主机应该不被嵌套任何其他节点下的层次结构（像）。例如，如果是空主机，则可能会看到以下内容：root default``newhost
$ bin/ceph osd treeID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF-5 0 host newhost10 ssd 1.00000 osd.10 up 1.00000 1.0000011 ssd 1.00000 osd.11 up 1.00000 1.0000012 ssd 1.00000 osd.12 up 1.00000 1.00000-1 3.00000 root default-2 3.00000 host oldhost1 0 ssd 1.00000 osd.0 up 1.00000 1.00000 1 ssd 1.00000 osd.1 up 1.00000 1.00000 2 ssd 1.00000 osd.2 up 1.00000 1.00000...Copy
确定要转换的第一个目标主机
OLDHOST=<existing-cluster-host-to-convert>Copy
将新主机交换到群集中旧主机的位置：
ceph osd crush swap-bucket $NEWHOST $OLDHOSTCopy
此时，所有数据$OLDHOST将开始迁移到上的OSD $NEWHOST。如果新旧主机的总容量不同，您可能还会看到一些数据迁移到集群中的其他节点或从集群的其他节点迁移，但是只要这些主机的大小相同，这将是相对少量的数据。
等待数据迁移完成：
while ! ceph osd safe-to-destroy $(ceph osd ls-tree $OLDHOST); do sleep 60 ; doneCopy
停止所有空的旧OSD $OLDHOST：
ssh $OLDHOSTsystemctl kill ceph-osd.targetumount /var/lib/ceph/osd/ceph-*Copy
销毁并清除旧的OSD：
for osd in `ceph osd ls-tree $OLDHOST`; do ceph osd purge $osd --yes-i-really-mean-itdoneCopy
擦拭旧的OSD设备。这要求您确定要手动擦除哪些设备（请小心！）。对于每个设备：
ceph-volume lvm zap $DEVICECopy
将现在为空的主机用作新主机，然后重复：
NEWHOST=$OLDHOSTCopy3 a, M) P( Z/ x1 M4 G8 F A F6 ^

优点：

数据只能通过网络复制一次。
一次转换整个主机的OSD。
可以并行转换为一次转换多个主机。
每个主机上都不需要备用设备。5 J) s! p' l! c' Y5 \ k. Z% Y: V

缺点：

需要备用主机。
整个主机的OSD值将同时迁移数据。这很可能会影响整个群集的性能。
所有迁移的数据仍然在网络上进行了一整跳。! M' Q0 f+ Q2 a u a

每OSD设备副本

可以使用的copy功能转换单个逻辑OSD ceph-objectstore-tool。这要求主机具有一个或多个空闲设备来供应新的空BlueStore OSD。例如，如果群集中的每个主机都有12个OSD，则需要第13个可用设备，以便可以依次转换每个OSD，然后再收回旧设备以转换下一个OSD。

注意事项：

此策略要求准备一个空白的BlueStore OSD，而无需分配该ceph-volume 工具不支持的新OSD ID 。更重要的是，dmcrypt的设置与OSD身份紧密相关，这意味着该方法不适用于加密的OSD。
设备必须手动分区。
工具未实现！
没有记录！
$ v6 J5 g8 k9 Z6 q

优点：

在转换期间，很少或没有数据在网络上迁移。
3 h! Z9 n7 @+ ^

缺点：

工具尚未完全实现。
流程未记录。
每个主机必须具有备用或空设备。
OSD在转换过程中处于脱机状态，这意味着新的写入操作将仅写入OSD的一部分。这会增加由于后续故障而导致数据丢失的风险。（但是，如果在转换完成之前出现故障，则可以启动原始FileStore OSD来提供对其原始数据的访问。）
2 V* P5 y9 ?' |

		自动登录	找回密码
密码			注册

ceph 存储BlueStore的OSD创建与启动

浏览过的版块