ceph（4）--Ceph 的基础数据结构

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成：

（1）安装和部署

（2）Ceph RBD 接口和工具

（3）Ceph 物理和逻辑结构

（4）Ceph 的基础数据结构

（5）Ceph 与 OpenStack 集成的实现

（6）QEMU-KVM 和 Ceph RBD 的 缓存机制总结

（7）Ceph 的基本操作和常见故障排除方法

（8）关于Ceph PGs

1 Pool（池）

Pool 的概念前面讲过了，Ceph 支持丰富的对 Pool 的操作，主要的包括：

列表、创建和删除 pool
ceph osd pool create {pool-name} {pg-num} [{pgp-num}] [replicated] [crush-ruleset-name]
ceph osd pool create {pool-name} {pg-num} {pgp-num} erasure [erasure-code-profile] [crush-ruleset-name]
ceph osd pool delete {pool-name} [{pool-name} --yes-i-really-really-mean-it]
QoS 支持：
ceph osd pool set-quota {pool-name} [max_objects {obj-count}] [max_bytes {bytes}]
快照创建和删除：
ceph osd pool mksnap {pool-name} {snap-name}
ceph osd pool rmsnap {pool-name} {snap-name}
元数据修改
ceph osd pool set {pool-name} {key} {value}
设置对象拷贝份数（注意该份数包括对象自身）
ceph osd pool set {poolname} size {num-replicas}
在 degraded 模式下的拷贝份数
ceph osd pool set data min_size 2

2 卷（image）

2.1 image 之用户所见

Image 对应于 LVM 的 Logical Volume，它将被条带化为 N 个子数据块，每个数据块将会被以对象（object）形式保存在 RADOS 对象存储中的简单块设备（simple block devicees）。比如：

#创建 100 MB 大小的名字为 ‘myimage’ 的 RBD Image，默认情况下，它被条带化为 4MB 大小的 25 个对象 （注意 rdb create 命令的 size 参数的单位为 MB）
rbd create mypool/myimage --size 100

#同样是 100MB 大小的 RBD Image，但是它被被条带化为 8MB 大小的13 个对象
rbd create mypool/myimage --size 100 --order 23

#将 image mount 到linux 主机称为一个 deivce /dev/rbd1rbd map mypool/myimage

#向 /dev/rbd1 写入数据dd if=/dev/zero of=/dev/rbd1 bs=1047586 count=4

#删除 image
rbd rm mypool/myimage

2.2 image 之 ceph 系统所见

接下来我们来看看 image 的一些内部信息。

（1）创建新的对象

首先在一个空的 pool 中创建一个 100 GB 的 image

[email protected]:~# rbd create -p pool100 image1 --size 102400 --image-format 2
[email protected]:~# rbd list pool100
image1

这时候在 pool 中看到多了一些对象：

[email protected]:~# rados -p pool100 ls
rbd_directory
rbd_id.image1
rbd_header.a89c2ae8944a

从名字也能看出来，这些 object 存放的不是 image 的数据，而是 ID，header 之类的元数据信息。其中，rbd_directory 中保存了pool内所有image的 ID 和 name 信息：

[email protected]:~# rados -p pool100 listomapvals rbd_directory
id_a89c2ae8944a
value: (10 bytes) :
0000 : 06 00 00 00 69 6d 61 67 65 31                   : ....image1

name_image1
value: (16 bytes) :
0000 : 0c 00 00 00 61 38 39 63 32 61 65 38 39 34 34 61 : ....a89c2ae8944a

而 rbd_header 保存的是一个 RBD 镜像的元数据：

[email protected]:~# rados -p pool100 listomapvals rbd_header.a89c2ae8944a
features
value: (8 bytes) :
0000 : 01 00 00 00 00 00 00 00                         : ........

object_prefix
value: (25 bytes) :
0000 : 15 00 00 00 72 62 64 5f 64 61 74 61 2e 61 38 39 : ....rbd_data.a89
0010 : 63 32 61 65 38 39 34 34 61                      : c2ae8944a

order
value: (1 bytes) :
0000 : 16                                              : .

size
value: (8 bytes) :
0000 : 00 00 00 00 19 00 00 00                         : ........

snap_seq
value: (8 bytes) :
0000 : 00 00 00 00 00 00 00 00                         : ........

这些信息正是下面命令的信息来源：

[email protected]:~# rbd -p pool100 info image1
rbd image ‘image1‘:
    size 102400 MB in 25600 objects
    order 22 (4096 kB objects)
    block_name_prefix: rbd_data.a89c2ae8944a
    format: 2
    features: layering

同时还能看出来，该 image 的数据对象的名称前缀是 rbd_header.a89c2ae8944a。而对于一个新建的 image，因为没有数据对象，其实际占用的存储空间只是元数据对象所占的非常小的空间。

（2）向该对象中写入数据 8MB 的数据（该 pool 中一个 object 是 4MB）

[email protected]:~# rbd map pool100/image1
[email protected]:~# rbd showmapped
id pool    image  snap device
1  pool100 image1 -    /dev/rbd1 
[email protected]:~# dd if=/dev/zero of=/dev/rbd1 bs=1048576 count=8
8+0 records in
8+0 records out
8388608 bytes (8.4 MB) copied, 0.316369 s, 26.5 MB/s

在来看看 pool 中的对象：

[email protected]:~# rados -p pool100 ls
rbd_directory
rbd_id.image1
rbd_data.a89c2ae8944a.0000000000000000
rbd_data.a89c2ae8944a.0000000000000001
rbd_header.a89c2ae8944a

可以看出来多了 2 个 4MB 的 object。继续看第一个对象所在的 OSD：

[email protected]:~# ceph osd map pool100 rbd_data.a89c2ae8944a.0000000000000000
osdmap e81 pool ‘pool100‘ (7) object ‘rbd_data.a89c2ae8944a.0000000000000000‘ -> pg 7.df059252 (7.52) -> up ([8,6,7], p8) acting ([8,6,7], p8)

PG 的 ID 是 7.52，主 OSD 是 8，从 OSD 是 6 和 7。从 OSD 树中可以获知 OSD 8 所在的节点为 ceph3：

[email protected]:/data/osd2/current/7.52_head# ceph osd tree
# id    weight    type name    up/down    reweight
-1    0.1399    root default
-4    0.03998        host ceph3
5    0.01999            osd.5    up    1
8    0.01999            osd.8    up    1

登录 ceph3，查看 /var/lib/ceph/osd 目录，能看到 ceph-8 目录：

[email protected]:/var/lib/ceph/osd# ls -l
total 0
lrwxrwxrwx 1 root root  9 Sep 18 02:59 ceph-5 -> /data/osd
lrwxrwxrwx 1 root root 10 Sep 18 08:22 ceph-8 -> /data/osd2

查看 7.52 开头的目录，可以看到两个数据文件：

[email protected]:/data/osd2/current# find . -name ‘*a89c2ae8944a*‘
./7.5c_head/rbd\uheader.a89c2ae8944a__head_36B2DADC__7
./7.52_head/rbd\udata.a89c2ae8944a.0000000000000001__head_9C6139D2__7
./7.52_head/rbd\udata.a89c2ae8944a.0000000000000000__head_DF059252__7

可见：

（1）RBD image 是简单的块设备，可以直接被 mount 到主机，成为一个 device，用户可以直接写入二进制数据。

（2）image 的数据被保存为若干在 RADOS 对象存储中的对象。

（3）image 的数据空间是 thin provision 的，意味着ceph 不预分配空间，而是等到实际写入数据时按照 object 分配空间。

（4）每个 data object 被保存为多份。

（5）pool 将 RBD 镜像的ID和name等基本信息保存在 rbd_directory 中，这样，rbd ls 命令就可以快速返回一个pool中所有的 RBD 镜像了。

（6）每个 RBD 镜像的元数据将保存在一个对象中，命名为 rbd_header.<image id>。

（7）RBD 镜像保存在多个对象中，这些对象的命名为 rbd_data.<image id>.<顺序编号序列>。

（8）RADOS 对象以 OSD 文件系统上的文件形式被保存，其文件名为 udata<image id>.<顺序编号序列>.<其它字符串>。

3 快照 （snapshot）

3.1 snapshot 之用户所见

RBD image 的快照（snapshot）是该 image 在特定时刻的状态的一份只读拷贝 （A snapshot is a read-only copy of the state of an image at a particular point in time.）。需要注意的是，在做 snapshot 之前，需要停止 I/O；如果 image 中包含文件系统，系统确保文件系统是处于连续状态。

用户可以使用 rbd 工具或者其它 API 操作 snapshot：

rbd create -p pool101 --size 102400 image1 --format 2 #创建 imagerbd snap create pool101/[email protected] #创建snapshot
rbd snap ls pool101/image1 #列表
rbd snap protect pool101/[email protected] #保护
rbd snap unprotect pool101/[email protected] #去保护
rbd snap rollback pool101/[email protected] #回滚snapshot 到 image。注意这是个耗时操作，rbd 会显示进度条
rbd snap rm pool101/[email protected] #删除rbd snap purge pool101/image1 #删除 image 的所有snapshotrbd clone pool101/[email protected] image1snap1clone1 #创建 clonerbd children pool101/[email protected] #列表它的所有 clone

3.2 snapshot 之 Ceph 系统所见

我们也来看看 snapshot 的内部原理。

（1）创建 image1，写入 4MB 的数据，然后创建一个 snapshot: rbd snap create pool100/[email protected]

（2）Ceph 在该 pool 中没有创建新的的对象，也就是说这时候并没有分配存储空间来给 snap1 创建 data objects。

[email protected]:~# rbd map pool101/image1
[email protected]:~# rbd showmapped
id pool image snap device
1 pool100 image1 - /dev/rbd1
2 pool101 image1 - /dev/rbd2

[email protected]:~# dd if=/dev/sda1 of=/dev/rbd2 bs=1048576 count=4
4+0 records in
4+0 records out
4194304 bytes (4.2 MB) copied, 0.123617 s, 33.9 MB/s
[email protected]:~# rados -p pool101 ls
rbd_directory
rb.0.fc9d.238e1f29.000000000000
image1.rbd

[email protected]:~# rbd snap create pool101/[email protected]

[email protected]:~# rbd snap ls pool101/image1
SNAPID NAME SIZE
10 snap1 102400 MB

[email protected]:~# rados -p pool101 ls
rbd_directory
rb.0.fc9d.238e1f29.000000000000
image1.rbd

（3）Ceph 而是将 snapshot 的信息增加到了 rbd_header.{image_id} 对象中

[email protected]:~# rados -p pool101 listomapvals rbd_header.a9262ae8944a
snapshot_0000000000000006

value: (74 bytes) :
0000 : 03 01 44 00 00 00 06 00 00 00 00 00 00 00 05 00 : ..D.............
0010 : 00 00 73 6e 61 70 31 00 00 00 00 19 00 00 00 01 : ..snap1.........
0020 : 00 00 00 00 00 00 00 01 01 1c 00 00 00 ff ff ff : ................
0030 : ff ff ff ff ff 00 00 00 00 fe ff ff ff ff ff ff : ................
0040 : ff 00 00 00 00 00 00 00 00 00 : ..........

（4）再向 image1 中写入 4MB 数据（其实是覆盖第一个 object 中的数据），发现数据目录中多了一个 4MB 的文件：

[email protected]:/data/osd2/current/8.2c_head# ls /data/osd/current/8.3e_head/ -l
total 8200
-rw-r--r-- 1 root root 4194304 Sep 28 03:25 rb.0.fc9d.238e1f29.000000000000__a_AE14D5BE__8
-rw-r--r-- 1 root root 4194304 Sep 28 03:25 rb.0.fc9d.238e1f29.000000000000__head_AE14D5BE__8

可见 Ceph 使用 COW （copy on write）方式实现 snapshot：在写入object 之前，将其拷贝出来，作为 snapshot 的 data object，然后继续修改 object 中的数据。

（5）再执行命令 dd if=/dev/sda1 of=/dev/rdb1 bs=1048576 seek=4 count=4 向 image 写入 [4MB，8MB）的数据。该操作创建了第二个 data object。因为这是在做 snapshot 之后创建的，所有它和 snapshot 没有关系。

（6）再创建一个snapshot，然后修改第二个 data object，这时候第二个 data object 所在的文件夹中多出了 snapshot 的一个 data object 文件：

[email protected]:/data/osd2/current/8.2c_head# ls /data/osd/current/8.a_head/ -l
total 4100
-rw-r--r-- 1 root root 4194304 Sep 28 03:31 rb.0.fc9d.238e1f29.000000000001__head_9C84738A__8
[email protected]:/data/osd2/current/8.2c_head# ls /data/osd/current/8.a_head/ -l
total 8200
-rw-r--r-- 1 root root 4194304 Sep 28 03:35 rb.0.fc9d.238e1f29.000000000001__b_9C84738A__8
-rw-r--r-- 1 root root 4194304 Sep 28 03:35 rb.0.fc9d.238e1f29.000000000001__head_9C84738A__8

因此，

（1）snapshot 的 data objects 是和 image 的 data objects 保存在同一个目录中。

（2）snapshot 的粒度不是整个 image，而是RADOS 中的 data object。

（3）当 snapshot 创建时，只是在 image 的元数据对象中增加少量字节的元数据；当 image 的 data objects 被修改（write）时，变修改的 objects 会被拷贝（copy）出来，作为 snapshot 的 data objects。这就是 COW 的含义。

4 克隆（clone）

创建 Clone 是将 image 的某一个 Snapshot 的状态复制变成一个 image。如 imageA 有一个 Snapshot-1，clone 是根据 ImageA 的 Snapshot-1 克隆得到 imageB。imageB 此时的状态与Snapshot-1完全一致，并且拥有 image 的相应能力，其区别在于 ImageB 此时可写。

4.1 Clone 之 用户所见

从用户角度来看，一个 clone 和别的 RBD image 完全一样。你可以对它做 snapshot、读/写、改变大小 等等，总之从用户角度来说没什么限制。同时，创建速度很快，这是因为 Ceph 只允许从 snapshot 创建 clone，而 snapshot 一直是只读的。

rbd clone pool101/[email protected] image1snap1clon3
[email protected]:~# rbd info image1snap1clon3
rbd image ‘image1snap1clon3‘:
        size 102400 MB in 25600 objects
        order 22 (4096 kB objects)
        block_name_prefix: rbd_data.a8f63d1b58ba
        format: 2
        features: layering
        parent: pool101/[email protected]
        overlap: 102400 MB

4.2 Clone 之 Ceph 系统所见

从系统角度，clone 也是使用 COW 技术，现在来通过下面的步骤具体了解一下：

（1）创建一个 clone （创建之前，需要 protect snapshot）。你会发现 RADOS 中多了三个object：

[email protected]:~# rbd clone pool101/[email protected] pool101/image1snap1clone1
[email protected]:~# rbd ls -p pool101
image1
image1snap1clone1
[email protected]:~# rados -p pool101 ls
rbd_header.89903d1b58ba
rbd_directory
rbd_id.image1snap1clone1
rbd_id.image1
rbd_children
rbd_header.a9532ae8944a
rbd_data.a9532ae8944a.0000000000000000

其中，rbd_children 记录了父子关系：

[email protected]:~# rados -p pool101 listomapvals rbd_children
key: (32 bytes):
0000 : 08 00 00 00 00 00 00 00 0c 00 00 00 61 39 35 33 : ............a953
0010 : 32 61 65 38 39 34 34 61 0e 00 00 00 00 00 00 00 : 2ae8944a........

value: (20 bytes) :
0000 : 01 00 00 00 0c 00 00 00 38 39 39 30 33 64 31 62 : ........89903d1b
0010 : 35 38 62 61 : 58ba

相比 rbd_header.a9532ae8944a，rbd_header.89903d1b58ba 只是多了 partent 信息：

parent
value: (46 bytes) :
0000 : 01 01 28 00 00 00 08 00 00 00 00 00 00 00 0c 00 : ..(.............
0010 : 00 00 61 39 35 33 32 61 65 38 39 34 34 61 0e 00 : ..a9532ae8944a..
0020 : 00 00 00 00 00 00 00 00 00 00 19 00 00 00 : ..............

这里父子关系和 rbd children 结果的来源：

[email protected]:~# rbd children pool101/[email protected]
pool101/image1snap1clone1

可见，Clone 也是对 snapshot 使用 COW 方式实现的。

（2）从 clone 读数据

从本质上是 clone 的 RBD image 中读数据，对于不是它自己的 data objects，ceph 会从它的 parent snapshot 上读，如果它也没有，继续找它的parent image，直到一个 data object 存在。从这个过程也看得出来，该过程是缺乏效率的。

（3）向 clone 中的 object 写数据

Ceph 会首先检查该 clone image 上的 data object 是否存在。如果不存在，则从 parent snapshot 或者 image 上拷贝该 data object，然后执行数据写入操作。这时候，clone 就有自己的 data object 了。

[email protected]:/data/osd3/current/8.32_head# ls -l
total 4100
-rw-r--r-- 1 root root 4194304 Sep 28 05:14 rbd\udata.89903d1b58ba.0000000000000000__head_CEDDC1B2__8

这是增加了 clone 后的各对象之间的关系：

4.3 Flatten clone

从上面的分析我们知道，克隆操作本质上复制了一个 metadata object，而 data objects 是不存在的。因此在每次读操作时会先向本卷可能的 data object 访问。在返回对象不存在错误后会向父卷访问对应的对象最终决定这块数据是否存在。因此当存在多个层级的克隆链后，读操作需要更多的损耗去读上级卷的 data objects。只有当本卷的 data object 存在后(也就是写操作后)，才不需要访问上级卷。

为了防止父子层数过多，Ceph 提供了 flattern 函数将 clone 与 parent snapshot 共享的 data objects 复制到 clone，并删除父子关系。

rbd 工具的 flatten 方法：

rbd flatten <image-name>： fill clone （image-name） with data of parent (make it independent)如果一个 image 是个 clone，从它的 parent snapshot 拷贝所有共享的 blocks （data objects），删除与其 parent 的依赖关系。此时，其 parent snapshot 可以被去保护（unprotected），如果没有其它的 clone 的话，它是允许被删除的。 该功能要求 image 为 format 2 格式。

注意这是一个非常耗时的操作。Flatten 之后，clone 与原来的父 snapshot 之间也不再有关系了，真正成为一个独立的 image：

[email protected]:~# rbd flatten image1snap1clon2
Image flatten: 100% complete...done.
[email protected]:~# rbd info image1snap1clon2
rbd image ‘image1snap1clon2‘:
        size 102400 MB in 25600 objects
        order 22 (4096 kB objects)
        block_name_prefix: rbd_data.fb173d1b58ba
        format: 2
        features: layering

令人奇怪的是，该操作在parent image 和 clone 产生的 image 的目录中产生了大量空的文件：

[email protected]:/data/osd/current# ls /data/osd/current/8.7f_head/ -l
total 788
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.000000000000014f__head_17C7607F__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.0000000000000232__head_96D143FF__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.0000000000000399__head_4D4E557F__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.00000000000003ae__head_CE165DFF__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.00000000000003e1__head_42EA8A7F__8
-rw-r--r-- 1 root root 0 Sep 28 05:33 rbd\udata.89903d1b58ba.0000000000000445__head_701607FF__8

判断父子关系层数，达到一定数目后 flatten clone，在删除 snapshot 的伪代码：

img = self.rbd.Image(client.ioctx, img_name) #根据输入的 img_name 获得其 RBD Image 对象_pool, parent, snap = self._get_clone_info(img_name) #当 name 为 img_name 的 RBD image 是个 clone 时，通过递归，获取它的 parent image 和 parent snapshot
img.flatten() # 将 parent snapshot 的 data 拷贝到该 clone 中
parent_volume = self.rbd.Image(client.ioctx, parent) #获取 parent image
parent_volume.unprotect_snap(snap) #将 snap 去保护
parent_volume.remove_snap(snap) #如果snapshot 没有其它的 clone，将其删除

5. 小结

RBD image 的 head，object，snapshot 以及 与 client 和 parent 之间的关系：

参考链接：

http://www.wzxue.com/ceph-librbd-block-library/

http://docs.ceph.com/docs/master/architecture/

https://www.ustack.com/blog/ceph_infra/

https://hustcat.github.io/rbd-image-internal-in-ceph/

http://www.wzxue.com/category/ceph-2/

原文地址：https://www.cnblogs.com/treasure716/p/9668737.html

时间： 2024-11-07 01:24:07

ceph（4）--Ceph 的基础数据结构的相关文章

理解 OpenStack &amp; Ceph （4）：Ceph 的基础数据结构 [Pool, Image, Snapshot, Clone]

本系列文章会深入研究 Ceph 以及 Ceph 和 OpenStack 的集成: (1)安装和部署 (2)Ceph RBD 接口和工具 (3)Ceph 物理和逻辑结构 (4)Ceph 的基础数据结构 (5)Ceph 与 OpenStack 集成的实现 (6)TBD 1 Pool(池) Pool 的概念前面讲过了,Ceph 支持丰富的对 Pool 的操作,主要的包括: 列表.创建和删除 pool ceph osd pool create {pool-name} {pg-num} [{pgp-num

排序与基础数据结构

6大排序与6大基础数据结构 本文从冒泡排序撩起,对选择.插入.希尔.归并.快排6种经典的数组排序进行了深入分析,并详解其间的关联,让你深刻理解其中的关键点:同时对经典的数据结构Vector.Stack.Queue.树.Map.Set做了归纳总结,对其底层的实现做了解析,分享给大家,作为每一个中高级程序员应该懂得的算法与排序,祝大家早上走上自己的"成金之路". 目录: 1.排序算法 2.数据结构 3.资料参考 1.排序算法: a.起源: 计算机从诞生起,就在模拟人这种智能生物的行为,而排

java 基础数据结构

数据结构, 需要考虑两个方面: 1. 每个元素具体的存储方法 (java中是一个对象) 2. 元素之间的关系如何实现存储 (java中也是一个对象) 另外在java中, 已经可以把跟数据结构有关的一些方法写到一个类里了. 线性表 顺序表 c语言: 借助数组实现 #define INIT_SIZE 100; typedef struct { int elem[INIT_SIZE]; // 用来存储数组元素 int length; // 当前顺序表的长度 } SqList; // 元素之间的关系隐含

【UOJ#228】基础数据结构练习题 线段树

#228. 基础数据结构练习题 题目链接:http://uoj.ac/problem/228 Solution 这题由于有区间+操作,所以和花神还是不一样的. 花神那道题,我们可以考虑每个数最多开根几次就会成1,而这个必须利用开根的性质 我们维护区间最大.最小.和.区间加操作可以直接做. 区间开方操作需要特殊考虑. 首先对于一个区间,如果这个区间的所有数取$x=\left \lfloor \sqrt{x} \right \rfloor$值一样,那么就可以直接区间覆盖. 分析上述过程,一个区间可以

Flink内存管理源码解读之基础数据结构

概述 在分布式实时计算领域,如何让框架/引擎足够高效地在内存中存取.处理海量数据是一个非常棘手的问题.在应对这一问题上Flink无疑是做得非常杰出的,Flink的自主内存管理设计也许比它自身的知名度更高一些.正好最近在研读Flink的源码,所以开两篇文章来谈谈Flink的内存管理设计. Flink的内存管理的亮点体现在作为以Java为主的(部分功能用Scala实现,也是一种遵循JVM规范并依赖JVM解释执行的函数式编程语言)的程序却自主实现内存的管理而不完全依赖于JVM的内存管理机制.它的优势在

OpenCV基础数据结构--基础入门

 图像数据结构 IPL 图像: IplImage |-- int  nChannels;     // 色彩通道数(1,2,3,4) |-- int  depth;         // 象素色深: |                       //   IPL_DEPTH_8U, IPL_DEPTH_8S, |                       //   IPL_DEPTH_16U,IPL_DEPTH_16S, |                       //   IPL_

uva 11997 （基础数据结构）

题意: 有一个k*k 的方阵,让你从当中每一行挑选一个数字相加最后能得到K^K次方的和,输出其中最小的k个. 思路:先对每一行排序然后两两归并,每次取前k个再和下一行再进行归并.在归并的时候用一个优先队列维护最大的k个值每次先放k个进去然后一次每行和队顶比较,若是小则替换否则break最后输出即可. 代码如下: 1 #include <stdio.h> 2 #include <algorithm> 3 #include <iostream> 4 #include <

Ceph存储系统(ceph安装，inkscope安装)--未完

Ceph存储系统 概述 ceph是一个Linux PB级别的分布式存储系统,ceph的目标简单地定义为: 可轻松扩展到PB容量 对多种工作负载的高性能(每秒输入/输出操作[IOPS]和带宽) 高可靠性 与常见的集中式存储不同,分布式存储技术并不是将数据存储在某个或多个特定的节点上,而是通过网络使用多台机器上的磁盘空间,并将这些分散的存储资源构成一个虚拟的存储设备,数据分散地存储在这些机器的各个磁盘上 ceph架构 ceph架构大概可以划分为四部分:客户端(数据用户).元数据服务器(缓存和同步分布

Vlc基础数据结构记录

1．  Vlc基础数据结构 [email protected] 1.1  基础数据结构 struct vlc_object_t,相关文件为src\misc\objects.c. 定义为: struct vlc_object_t { VLC_COMMON_MEMBERS }; 其中的VLC_COMMON_MEMBERS为micro,扩展而下: struct vlc_object_t { const char *psz_object_type; char *psz_header; int  i_fl