The page is temporarily unavailable
nginx error!
The page you are looking for is temporarily unavailable.
Please try again later.
Website Administrator
Something has triggered an error on your
This is the default error page for
nginx that is distributed with
It is located
/usr/share/nginx/html/50x.html
You should customize this error page for your own
site or edit the error_page directive in
the nginx configuration file
/etc/nginx/nginx.conf.请教ceph 监视器时钟偏差问题如何解决_百度知道
请教ceph 监视器时钟偏差问题如何解决
ceph&#47.conf中设置monitor间的允许时钟偏移最大值 [mon] mon data =/ceph/etc/data&#47
知道智能回答机器人
我是知道站内的人工智能，可高效智能地为您解答问题。很高兴为您服务。
其他类似问题
为您推荐：
监视器的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁当前访客身份：游客 [
这个人很懒，啥也没写
：觉得好请点赞，我没积分哦
今日访问：11
昨日访问：36
本周访问：141
本月访问：688
所有访问：8152
ceph体系架构总览
发表于12个月前( 11:05)&&
阅读（365）&|&评论（）
0人收藏此文章,
通过ceph的官方文档说明，主要描述 在使用时加入个人理解说明,心情好时持续更新
一、功能划分
Ceph的提供了一个根据RADOS无限扩展的Ceph存储集群，相关内容你可以参阅REDOS-一个可伸缩的、可靠的存储服务PB级别存储集群。存储集 群客户端和每个Ceph的OSD守护进程使用CRUSH算法有效地计算有关数据位置的信息，而不必依赖于一个查找表。Ceph的高层次功能包括Ceph的 存储集群，通过 librados提供了一个原生接口，在librados基础上建立一些服务接口。
对应的进程Monitors监视器（ceph-mon），OSDs对象存储设备（ceph-osd）,通过读取配置文件ceph.conf实现集群。
1.1 OSD功能
OSD可以被抽象为两个组成部分，即系统部分和守护进程（OSD deamon）部分。OSD的系统部分本质上就是一台安装了操作系统和文件系统的计算机，其硬件部分至少包括一个单核的处理器、一定数量的内存、一块硬盘以及一张网卡。系统部分由操作系统内核实现，为ceph提供接口。
的运行过程中，
cluster map
的更新完全取决于系统的状态变化，而导致这一变化的常见事件只有两种：
出现故障，或者
规模扩大。
Cluster Maps
指包含所有的
OSD map,monitor map,placement group map, metadata server map
1.2 OSD管理的PG
PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个 object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载 大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。
File -& object映射：其映射十分简单，本质上就是按照object的最大size对file进行切分，相当于RAID中的条带化过程。这种切分的好处有二：一是让大小不限的 file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为对多个object实施的并行化处理。
Object -& PG映射：在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。
PG -& OSD映射：第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。
注意：映射过程中使用cluster map中的placement group map，OSDmap。
在 Ceph的现有机制中，一个OSD平时需要和与其共同承载同一个PG的其他OSD交换信息，以确定各自是否工作正常，是否需要进行维护操作。由于一个 OSD上大约承载数百个PG，每个PG内通常有3个OSD，因此，一段时间内，一个OSD大约需要进行数百至数千次OSD信息交换。
1.3 OSD的状态变迁
OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：
A．Up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；
B. Up且out：说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；
C. Down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；
D. Down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。
1.4 OSD的心跳维持
心跳是用于OSD节点间检测对方是否故障的，以便及时发现故障节点进入相应的故障处理流程。故障检测需要在故障的发现时间和心跳带来的负载之间做权衡，如果心跳频率太高则过多的心跳报文会影响系统性能，如果心跳频率过低则会延长发现故障节点的时间，从而影响系统的可用性。
在大规模部署的场景中，如果任意两个OSD节点间都建立心跳连接将带来巨大的负担。尤其，当新加入一个OSD节点时这个负担就会几倍地增加。Ceph中每个OSD只和以下两类节点建立心跳连接： 一类是同个PG下的OSD节点之间，因为属于同个PG的OSD节点会保存同份数据的副本，如若出现故障则会直接影响数据的可用性。另一类是OSD的左右两 个相邻的节点，这两个节点同自己物理上存在比较紧密的联系，例如可能连接在同台交换机。另外，如果建立心跳的Peer数目少于 osd_heartbeat_min_peers，那么OSD会继续同离他较近的几个OSD建立心跳连接。
OSD节点会监听public、cluster、front和back四个端口，其中front和back两个端口都是用于心跳的，cluster 端口用来监听来自OSD Peer的连接，public用来监听来自Monitor和Client的连接。如果启动OSD时没有提供back的IP地址，则back使用 cluster的IP地址；而front不单独提供IP地址，直接使用public的IP地址。另外，OSD单独创建了一个名为hbclient的 Messenger，作为心跳的客户端，单独用来建立连接发送心跳报文。心跳报文优先发送给back连接。
// ceph-osd.cc 启动osd时创建Messengers
OSD::maybe_update_heartbeat_peers() 确定同哪些peer建立心跳连接，剔除已经down掉的节点的心跳连接
OSD::_add_heartbeat_peer()& 同给定的peer建立心跳连接
OSDServeice::get_con_osd_hb()& 获取peer的front和back连接
OPTION(public_network, OPT_STR, "")
OPTION(cluster_network, OPT_STR, "")
OPTION(osd_heartbeat_min_peers, OPT_INT, 10)&&&& // minimum number of peers
OSD使用T_Heartbeat线程定时向Peer OSDs发送心跳报文，发送报文的时间间隔在0.5~6.5之间，由osd_heartbeat_interval配置选项决定。心跳报文会同时向 Peer OSD的front和back端口发送。心跳报文分两种类型一种是Ping类型，另一种是Reply类型。Ping类型的报文是OSD主动发送给Peer OSD的报文，而Reply是Peer OSD回应给自己的报文。两种类型的心跳报文都携带时间戳，但它们的时间戳代表的含义不一样。Ping类型报文的时间戳是发送报文时的时间，而Reply 类型报文的时间戳是从Ping报文中读取出来的，不是代表它自己的发送时间而是代表它对应的Ping报文的发送时间。OSD接收到Reply报文时将记录 报文的时间戳，并以此来判断是否超时。
对每个Peer节点，如果其最近的应答的时间(最近的Reply报文的时间戳)位于cutoff之前(即超时grace秒)，则将其加入到 failure_queue队列。OSD会定时向Monitor汇报自己的状态，在汇报状态时将failure_queue队列中Peer发送给 Monitor，由Monitor将其标记为down状态。Monitor在接收到OSD对Peer的故障报告后，通过PAXOS算法决定是否将Peer OSD标记为Down状态。如果将Peer OSD标记为Down状态，那么将更新OSD MAP，OSD接收到OSD Map更新的消息后，断开和Peer OSD的心跳连接。
如果在向Monitor报告故障之后但在接收到OSD Down消息之前，再次接收到Peer OSD对心跳报文的回应，则将Peer OSD从failure_queue队列中移除，并通知Monitor该节点依旧存活着。
void OSD::heartbeat_entry() // T_Heartbeat线程入口函数，定时向心跳Peers发送心跳报文
void OSD::heartbeat()
map&int,utime_t& failure_ // 检测到peer长时间没心跳时，将peer加入到failure_queue队列
map&int,entity_inst_t& failure_ // 故障报告给Monitor的Peer OSD
void send_failures();
void send_still_alive(epoch_t epoch, const entity_inst_t &i);
void OSD::note_down_osd(int peer)
void OSD::handle_osd_ping(MOSDPing *m) // 处理MOSDPing消息
OPTION(osd_heartbeat_interval, OPT_INT, 6)&&&&&& // (seconds) how often we ping peers
OPTION(osd_heartbeat_grace, OPT_INT, 20)&&&&&&&& // (seconds) how long before we decide a peer has failed
OSD流程概述
Recovery/scrub/peering
更多开发者职位上
1)">1)">1" ng-class="{current:{{currentPage==page}}}" ng-repeat="page in pages"><li class='page' ng-if="(endIndex<li class='page next' ng-if="(currentPage
相关文章阅读