ceph问题解决运维记录
1、如何导出导入osdmap
11先停掉坏的osd,以及一个好的osd(因为ceph-objectstore-tool执行时需要停止osd),然后执行导出导入即可
命令例子:其中84是好的osd,85是有问题的osd
ceph-objectstore-tool --op get-osdmap --epoch 145039 --data-path /data1/ceph-osd/ --journal-path /var/log/ceph/ceph-84/journal --type filestore --file osdmap145039
ceph-objectstore-tool --op set-osdmap --epoch 145039 --data-path /data2/ceph-osd/ --journal-path /var/log/ceph/ceph-85/journal --type filestore --file osdmap145039
PS:其中145039为对应的版本号,data-path与journal-path填写自己osd对应的路径
2、找到正确的epoch版本
这个要通过报错的osd日志查看,在启动的时候,osd会加载一个epoch版本A,这个版本是它正在执行的,缺少的epoch版本在它之前。然后在 dump of recent events中发现已经执行的epoch版本B,以及ecoch版本C。将在max(B,C)到A之间的版本都导入一遍(也可以导入一个版本,启动一次观察,就是太麻烦了)。我日志中A=145068,B=145011,C=145012,所以我把145013到145067之间所有的ecoph版本都导入进去了,结果正常启动了。我的日志入下图
1、产生原因 :
2个osd之间的osdmap版本如果相差过大(相差可能在50左右),会导致2个osd通讯的时候报wrong node。如果偶尔出现一次wrong node,那么问题不大,因为osd某个操作卡主了,然后恢复获取了最新版本的osdmap。如果osd日志一直在报,说明有osd同步osdmap出现问题,会导致osd down掉,心跳超时(可能),甚至出现osd大量吃内存,导致服务器挂掉。日志如下:
2、查看osd的osdmap版本
通过命令查看:ceph daemon osdxx status ——xx标记对应的osd编号
命令结果例子:
{
"cluster_fsid": "df181181-2154-4816-a2b7-d6eae79980fb",
"osd_fsid": "d5edacd3-cee7-45eb-90df-e381d8684dfb",
"whoami": 15,
"state": "active",
"oldest_map": 92570,
"newest_map": 158146,
"num_pgs": 2105
}
其中newest_map表示osd的最新版本号
3、查看集群的osdmap版本号
命令:ceph -s
这里:178170时最新版本号
4、确定osd版本是否有问题
多次间隔执行命令ceph daemon osdxx status 查看osd版本号,正确状态如下:
41、查询出来的版本号一直保持跟集群版本号一致
42、小于集群版本号,但是在不停增大,最终会达到集群版本号
5、出现osd不更新osdmap解决办法
到目前为止,我没有找到osd不更新osdmap的根本原因,我使用过ceph daemon osdxx dump_blocked_ops 查看是否有阻塞的操作并解决阻塞,但是依然不行,即使返回没有阻塞,还是不更新。可能可以让osd重新更新的方式:
1、将对应的osd out出集群(osd还是up的),过一阵观察一下版本号(我的就是这样回复的)
2、重启osd
1、问题日志
2、解决方式:
1、检查服务器时间是否一致
2、检查集群中的keyring与本地osd的keyring是否一致:
使用命令:
ceph auth list从mon中获取所有osd的keyring,
cat /var/lib/ceph/osd/ceph-xx/keyring获取本地osd的keyring
3、去掉验证 ,重启所有的mon、osd,修改cephconf中的如下参数为
auth_cluster_required = none
auth_service_required = none
auth_client_required = none
1、问题日志
2、解决方式
1、查看服务器时间与服务器网络(我的不是这个问题)
2、一般心跳超时是其他问题引起的,这里可以先调大心跳超时时间(我调大了心跳超时,解决了其他问题之后,就没有心跳超时了),修改配合文件cephconf的参数
mon_osd_report_timeout = 1800
filestore_op_thread_suicide_timeout = 1800
filestore_op_thread_timeout = 600
osd_heartbeat_grace = 600
osd_op_thread_suicide_timeout=1800
osd_op_thread_timeout=36000
这个配置可以先放到[global],等解决了问题,在去掉,也可以根据实际情况,自己调整参数
1查看日志查看osd卡在哪里
日志调整级别:修改配置文件cephconf参数,添加debug_osd=10(15/20),数值越高,打印越多。如果已经启动osd,想更改日志级别,可以通过命令:ceph tell osdxx injectargs --debug-osd 5
2、根据日志信息解决问题
我是卡在了load_pgs上,因为整个集群状态不对,而pg数量又很多,加载很慢,这时候需要考虑服务器压力,可以一个一个慢慢启动,不要一下子启动完。
1、问题原因
incomplete状态表示:Peering过程中由于无法选出权威日志或者通过choos_acting选出的acting不足以完成数据恢复,(例如针对纠删码,存活的副本数小于k值)等,导致Peering无法正常完成。即pg元数据丢失,无法恢复pg状态
2、解决问题
1、使用ceph-objectstore-tool工具将incomplete状态的pg标记为complete
2、操作步骤:
操作前提:设置集群flag:noout nodown noup noin PS:这里的目的是为了不让pg分布变化,我因为osd都起来了,只设置了noout nodown
第一步:通过命令ceph pg dump_stuck |grepincomplete >incompletetxt 从集群中导出incomplete状态的所有pg
第二步:通过第一步知道了pg所在的2个osd在哪里,stop这2个osd
第三步:对这2个osd上的pg通过命令做标记,命令如下
ceph-objectstore-tool --data-path /data4/ceph-osd/ --journal-path /var/log/ceph/ceph-15/journal --type filestore --pgid 9ea8 --op mark-complete
ceph-objectstore-tool --data-path /data8/ceph-osd/ --journal-path /var/log/ceph/ceph-91/journal --type filestore --pgid 9ea8 --op mark-complete
第四步:启动这2个osd(启动顺序没有关系)
第五步:观察集群中incomplete是否少了
第六步:重复第二步以及之后的操作,直到incomplete没有
3、特别说明
31、标记complete的过程,可能给导致集群degraded、misplaced增加,这是正常的
32、原因:因为我在标记的过程中,缺少了导入导出pg步骤。我这里没操作导入导出是因为pg数量有点多,而且pg比较大,导入导出会让2个osd停太久了,而且我觉得让集群自己恢复比较好
33、导入导出pg命令:
ceph-objectstore-tool --data-path /data3/ceph-osd/ --journal-path /var/log/ceph/ceph-2/journal --type filestore --pgid 415d5 --op export --file /data10/55/pg415d5
ceph-objectstore-tool --data-path /data8/ceph-osd/ --journal-path /var/log/ceph/ceph-5/journal --type filestore --pgid 415d5--op import --file /data10/55/pg415d5
选择一个osd为主,另一个为副,将一个导入到另外一个pg,导入导出需要停止osd。以上是将osd2中的415d5导入到osd5中
1、如果能重启对应pg的osd,那是最好的,问题自然解决
2、如果osd对应的数据盘损毁或者其他原因无法启动这个osd
第一步:将这个osd删除,命令
ceph osd crush reweight osdxx 0
ceph osd out osdxx
ceph osd crush remove osdxx
ceph osd rm osdxx
ceph auth del osdxx
第二步:清理当前osd的硬盘或者新加一个硬盘
第三步:新启动一个编号相同的osd
第四部:重复上面的操作,处理掉所有有问题的osd,如果还有down,没事,等集群自己恢复处理(我就是启动了一个新的osd,有pg处理incomlepte+down,我标记完了incomlepte,down就自己消失了)
1、原因
这个状态的PG没有被 ceph-osd 更新,表明存储这个 PG 的所有节点可能都 down 了。拥有 PG 拷贝的 OSD 可能会全部失败,这种情况下,那一部分的对象存储不可用, monitor 也就不会收到那些 PG 的状态更新了,这些pg就被标记为stale
2、解决方法
第一种:osd down了之后能正常起来,那只要启动
第二种:
1使用命令ceph pg dump |grep stale找出stale的pg
2使用命令ceph pg force_create_pg $pg_id,这时pg状态变为creating
3重启集群中所有的osd
3、特殊说明
我当时是第二种情况,然后我按上面的步骤操作了。结果所有的osd启动都卡主了。我猜测可能原因:当时我force_create_pg的数量有3000个,这个数量有点多,所以osd就大量卡住了,很久很久才能启动,可能有几个小时。所以这个操作要慎重,建议如下
1、这个stale的pg最后处理
2、一次不要force_create_pg太多,osd重启时,一个重启成功之后,在重启另一个
这个比较简单,直接执行命令:ceph pg repair $pg_id 修复
说明集群中osd有问题,需要解决osd问题,我就是有3个osd问题,我out了这3个osd,这2个状态就很快消失了
1、问题发现 :ceph -s 或者mon进程死掉看到日志
2、产生原因
产生了大量的epoch,导致mon的storedb的数据极速膨胀。这个是我集群出现问题之后才出现的。我之前集群正常时没有这个现象。不知道等集群正常之后,会不会自己恢复正常。
3、解决方法
第一种:对数据进行压缩,使用命令 ceph tell monceph163 compact (ceph163是我mon的名称) 。
第二种:使用ceph-mon -i HOST --compact进行压缩启动 ,这里的host我使用的是ceph163,主机名称
说明:不管使用哪一种,都要注意一点:操作压缩时,硬盘都会先扩大然后再缩小的,所以要留足空间。第二种的优势在于可以使修改cephconf中的参数mon_data=/data10/ceph153路径生效。我后来的mon数据太大了,我就更新路径到了数据盘:只要把对应的mon数据存数据mv到其他目录即可
第三种:等集群正常了,修改mon的配置参数试试(未验证,参数可以调小一些)
mon_min_osdmap_epochs=500
mon_max_pgmap_epochs=500
mon_max_mdsmap_epochs=500
4、特别注意:
默认当mon所在存储应硬盘剩余5%空闲时,mon进程会自杀。
将对应osd节点设置为out即可(osd进程依然存在),它会自动移除数据并把对应数据盘的数据删除,等到数据移除完毕,正常关闭删除osd即可
命令:ceph osd out osdxx
当需要迁移服务器,需要关闭集群时,先设置ceph osd set nodown ceph osd set noup ceph osd set noout ceph osd set nobackfill ceph osd set norecover 保持集群不变,然后关闭各个osd,关闭mon,关闭rgw。
ceph osd set norebalance
——禁止集群pg做从均衡,当出现问题时,可以设置,用于排查问题
ceph osd set nobackfill
——禁止修复数据 backfill,当出现问题时,我们暂时不想修复数据,可以使用,配合nobackfill 一起使用
ceph osd set norecover
——禁止修复数据 recover,当出现问题时,我们暂时不想修复数据,可以使用,配合nobackfill 一起使用
ceph osd set nodown
——当集群出现问题,osd一会儿up,一个down的时候,可以使用这个命令,禁止osd down
ceph osd set noup
——当集群出现问题,osd一会儿up,一个down的时候,可以使用这个命令,禁止osd up
ceph osd set noout
——禁止集群中的osd自动因为长时间down,而out
ceph osd set nodeeep-scrub
——不做深度处理取消使用对应的unset即可,比如ceph osd unset noout
ceph osd out osdxx 设置单个osd的状态为out
ceph osd in osdxx 设置单个osd的状态为in
ceph osd down osdxx 设置单个osd的状态为down
ceph tell osdxx injectargs --debug-osd 20 实时修改osdxx的日志级别,不需要重启osd
ceph tell monxx injectargs --debug-mon 20 实时修改mon的日志级别,不需要重启mon
ceph tell osd injectargs --osd_recovery_sleep 1 单位秒,刚开始设置为1,怕服务器有压力,观察之后可以去掉设置为0
ceph tell osd injectargs --osd_max_backfills 1 调整恢复线程数,可以根据实际情况调整
ceph tell osd injectargs --osd_recovery_op_priority 60 调整恢复线程的级别
ceph daemon osdxx status 查看osdxx的状态,主要看osdmap版本号
ceph pg dump 查看所有的pg信息
ceph pg dump_stuck stale 查看pg状态为stale的数据
ceph pg dump_stuck inactive查看pg状态为inactive的数据
ceph pg dump_stuck unclean查看pg状态为unclean的数据
ceph -s 查看集群情况
ceph osd tree 查看osd状态树
ceph health detail 查看集群健康详情
ceph pg pg_id query 查看某个pg信息
ceph osd getmap -o osdmapbin查看osdmap图
ceph-dencoder type OSDMap import osdmap_197 decode dump_json 将osdmap导出成json格式
描述对象存储,与文件存储,块存储的区别, MaxLeap数据存储和文件存储的区别
先说说块存储吧,典型代表--SAN。对于用户来说,SAN好比是一块大磁盘,用户可以根据需要随意将SAN格式化成想要的文件系统来使用。SAN在网络中通过iSCSI(IPSAN)协议连接,属block及存储,但可扩展性较差。
再说说文件集存储,典型代表--NAS。对于用户来说,NAS好比是一个共享文件夹,文件系统已经存在,用户可以直接将自己的数据存放在NAS上。NAS以文件为传输协议,开销很大,不利于在高性能集群中使用。
而所谓对象存储,就是每个数据对应着一个唯一的id,在面向对象存储中,不再有类似文件系统的目录层级结构,完全扁平化存储,即可以根据对象的id直接定位到数据的位置,这一点类似SAN,而每个数据对象即包含元数据又包括存储数据,含有文件的概念,这一点类似NAS。除此之外,用户不必关系数据对象的安全性,数据恢复,自动负载平衡等等问题,这些均由对象存储系统自身完成。而且,面向对象存储还解决了SAN面临的有限扩充和NAS传输性能开销大问题,能够实现海量数据存储。
块储存,对象存储,文件存储的区别和联系通常来讲,磁盘阵列都是基于Block块的存储,而所有的NAS产品都是文件级存储。
1 块存储:DAS SAN
a) DAS(Direct Attach Storage): 是直接连接于主机服务器的一种存储方式,每台服务器有独立的存储设备,每台主机服务器的存储设备无法互通,需要跨主机存取资料室,必须经过相对复杂的设定,若主机分属不同的操作系统,则更复杂。
应用:单一网络环境下且数据交换量不大,性能要求不高的环境,技术实现较早。
b) SAN(Storage Area Neork): 是一种高速(光纤)网络联接专业主机服务器的一种存储方式,此系统会位于主机群的后端,它使用高速I/O联接方式,如:SCSI,ESCON及Fibre-Channels特点是,代价高、性能好。但是由于SAN系统的价格较高,且可扩展性较差,已不能满足成千上万个CPU规模的系统。
应用:对网速要求高、对数据可靠性和安全性要求高、对数据共享的性能要求高的应用环境中。
2 文件存储
通常NAS产品都是文件级存储。
NAS(Neork Attached Storage):是一套网络存储设备,通常直接连在网络上并提供资料存取服务,一套NAS储存设备就如同一个提供数据文件服务的系统,特点是性价比高。
它采用NFS或CIFS命令集访问数据,以文件为传输协议,可扩展性好、价格便宜、用户易管理。目前在集群计算中应用较多的NFS文件系统,但由于NAS的协议开销高、带宽低、延迟大,不利于在高性能集群中应用。
3 对象存储:
总体上讲,对象存储同时兼具SAN高级直接访问磁盘特点及NAS的分布式共享特点。
核心是将数据通路(数据读或写)和控制通路(元数据)分离,并且基于对象存储设备(OSD),构建存储系统,每个对象存储设备具备一定的职能,能够自动管理其上的数据分布。
对象储存结构组成部分(对象、对象存储设备、元数据服务器、对象存储系统的客户端)
31 对象
一个对象实际就是文件的数据和一组属性信息的组合。
32 对象存储设备(OSD)
OSD具有一定的智能,它有自己的CPU、内存、网络和磁盘系统。
OSD提供三个主要功能:包括数据存储和安全访问
(1)数据存储 (2)智能分布 (3)每个对象元数据的管理
33 元数据服务器(Metadata Server , MDS)
MDS控制Client与OSD对象的交互,主要提供以下几个功能:
(1) 对象存储访问
允许Client直接访问对象,OSD接收到请求时先验证该能力,再访问。
(2) 文件和目录访问管理
MDS在存储系统上构建一个文件结构,限额控制、包括目录、文件的创建、访问控制等
(3) Client Cache 一致性
为提高性能,在对象存储系统设计时通常支持Client的Cache。因此带来了Cache一致性的问题,当Cache文件发生改变时,将通知Client刷新Cache,以防Cache不一致引发的问题。
对象存储:
一个文件包含了属性(术语叫matadata元数据,例如该文件的大小、修改时间、存储路径等)以及内容(简称数据)。
以往的文件系统,存储过程将文件按文件系统的最小块来打散,再写进硬盘,过程中没有区分元数据(metadata)和数据。而在每个块最后才会告知下一个块的地址,因此只能一个一个读,速度慢。
而对象存储则将元数据独立出来,控制节点叫元数据服务器(服务器+对象存储管理软件),里面主要存储对象的属性(主要是对象的数据被打散存放到了那几台分布式服务器中的信息),而其他负责存储数据的分布式服务器叫做OSD,主要负责存储文件的数据部分。当用户访问对象时,会先访问元数据服务器,元数据服务器只负责反馈对象存储在那些OSD。假设反馈文件A存储在B,C,D三台OSD,那么用户就会再次访问三台OSD服务器去读取数据。
这时三台OSD同时对外传输数据,因此传输的速度就加快了。OSD服务器数量越多,这种读写速度的提升就越大。
另一方面,对象存储软件有专门的文件系统,所以OSD对外又相当于文件服务器,那么就不存在文件共享方面的困难了,也解决了文件共享方面的问题。
因此对象存储的出现,很好的结合了块存储与文件存储的优点。
为什么还要使用块存储和文件存储:
1有一类应用是需要存储直接裸盘映射的,比如数据库。因为数据库需要存储裸盘映射给自己后,再根据自己的数据库文件系统来对了裸盘进行格式化,因此不能采用其他已经被格式化为某种文件系统的存储。此类更适合块存储。
2对象存储的成本比普通的文件存储还是较高,需要购买专门的对象存储软件以及大容量硬盘。如果对数据量要求不是海量,只是为了作文件共享的时候,直接用文件存储的形式就好了,性价比高。
有对象存储了为什么还要有文件存储和块存储?目前而言,三种存储方式不能说谁更好,针对场景不同,不同存储能发挥的功效也不同。对象存储主要运用在文件归档,云服务,备份,视频应用等;块存储主要应用在数据库、中间件、云桌面等;文件存储主要应用在文件共享,影视非编等。元核云三种存储方式都支持,可以进行自由选择。
有块 存储 文件存储 为什么 还要 对象存储块存储是传统存储模式,对象存储是新提出的概念,比传统存储更具优势。
描述NFS存储与iSCSI存储的区别先说说块存储吧,典型代表--SAN。对于用户来说,SAN好比是一块大磁盘,用户可以根据需要随意将SAN格式化成想要的文件系统来使用。SAN在网络中通过iSCSI(IPSAN)协议连接,属block及存储,但可扩展性较差。 再说说文件集存储,典型代表--NAS。
集群NAS和对象存储的区别
如果是集群NAS用的硬盘大都是Serial Attached SCSI 就是SAS,当然SATA也是可以的,SATA廉价!你的数据是如果非结构的可以用NAS,如果是结构化的数据那就是用对象存储吧!好好看一看块访问、对象访问和文件访问吧!
对象存储oss和redis的区别为了支持云服务,MySQL的备份做了极大地改进,比如Global Transaction Identifiers (GTIDs) GTIDs可以轻松地跟踪和比较master和slave服务器之间的进度状态。
在2013年4月,Oracle发布了针对Hadoop的MySQL Applier。Nokia首先将MySQL应用于大数据环境中,包括集中的Hadoop集群等等。
ps中的文件存储和文件存储为?如果你打开的JPG只是单纯的调色,没有添加图层的话 你点存储 是直接就存储了的,如果你添加图层或者文字层的话,就只能用存储为了。 存储只能存储为打开文件的格式,一旦你添加图层了,就必须变成PSD格式,或者存储为JPG了
a 裸设备和文件存储的区别1 unix/linux ls -al|grep db2
2 如果从 lv 的名字上看不出来…… 就连上数据库,然后看表空间容器
配置故障或网络问题导致。fusionstorageosd进程无法启动是因为配置故障或网络问题导致,fusionstorageosd进程无法启动可以修改Ceph配置文件的osd选项或重新连接网络,fusionstorageosd进程无法启动OSDObjectStorageDevice是FusionStorage的对象存储设备,业务IO进程,执行具体的IO操作。
CRUSH算法通过每个设备的权重来计算数据对象的分布。对象分布是由cluster map和data distribution policy决定的。cluster map描述了可用存储资源和层级结构(比如有多少个机架,每个机架上有多少个服务器,每个服务器上有多少个磁盘)。data distribution policy由placement rules组成。rule决定了每个数据对象有多少个副本,这些副本存储的限制条件(比如3个副本放在不同的机架中)。CRUSH算出x到一组OSD集合(OSD是对象存储设备):(osd0, osd1, osd2 … osdn) = CRUSH(x)CRUSH利用多参数HASH函数,HASH函数中的参数包括x,使得从x到OSD集合是确定性的和独立的。CRUSH只使用了cluster map、placement rules、x。CRUSH是伪随机算法,相似输入的结果之间没有相关性。
0条评论