架构设计:系统存储(29)——分布式文件系统Ceph(管理)

版权声明:欢迎转载,但是看在我辛勤劳动的份上,请注明来源:http://blog.csdn.net/yinwenjie(未经允许严禁用于商业用途!) https://blog.csdn.net/yinwenjie/article/details/70313823

3-3. Ceph常用命令

Ceph文件系统提供的运维命令主要是按照Ceph中的工作角色/工作职责进行划分的,例如有一套专门对OSD节点进行管理的命令、有一套专门对PG进行管理的命令、有一套专门对MDS角色进行管理的命令……您可以使用ceph –help进行命令列表的查看,本文我们对常用的命令进行描述,这些命令只是Ceph文件系统中的一部分命令,目的是保证在Ceph运行到生产环境后,您有能力定位常见问题,保证Ceph能够正常工作。

这里说明一下,ceph-deploy中的命令主要进行Ceph中各角色的安装、删除。所以对Ceph文件系统的日常维护还是不建议使用ceph-deploy中的命令,而建议尽可能使用Ceph文件系统的原生命令。

而ceph-deploy中的命令只建议在增加、删除节点/角色时使用。另外请注意,以下提到的新增、删除各种Ceph中角色的命令,也不建议在Ceph文件系统有大量I/O操作时进行,毕竟保证线上系统稳定,才是运维工作的重中之重。您可以选择Ceph系统相对空闲的时间进行这些操作,例如凌晨就是一个很好时间选择(加班狗赐予你力量)。

3-3-1. 集群管理相关命令

Ceph文件系统一旦通过ceph-deploy安装成功,在每一个成功安装的节点上Ceph都会作为Linux操作系统的服务被注册,所以要启动Ceph文件系统无非就是启动每个节点上的ceph服务。另外Ceph节点上运行的各种角色,除了MON角色默认会使用6789端口外,其它角色也会使用大量的网络端口,请保证这些网络端口没有被防火墙屏蔽。以下是某个Ceph节点上运行的各种角色所使用的网络端口示例(您和示例中的情况不一定完全一致):

......
tcp        0      0 0.0.0.0:6807            0.0.0.0:*               LISTEN      9135/ceph-osd       
tcp        0      0 0.0.0.0:6808            0.0.0.0:*               LISTEN      9135/ceph-osd       
tcp        0      0 0.0.0.0:6809            0.0.0.0:*               LISTEN      9135/ceph-osd       
tcp        0      0 0.0.0.0:6810            0.0.0.0:*               LISTEN      9135/ceph-osd
tcp        0      0 0.0.0.0:6811            0.0.0.0:*               LISTEN      9281/ceph-mds
tcp        0      0 172.16.71.187:6789      0.0.0.0:*               LISTEN      8724/ceph-mon
tcp        0      0 0.0.0.0:6800            0.0.0.0:*               LISTEN      8887/ceph-osd       
tcp        0      0 0.0.0.0:6804            0.0.0.0:*               LISTEN      8887/ceph-osd       
tcp        0      0 0.0.0.0:6805            0.0.0.0:*               LISTEN      8887/ceph-osd       
tcp        0      0 0.0.0.0:6806            0.0.0.0:*               LISTEN      8887/ceph-osd
......
  • 启动MON、MDS、OSD

你可以通过以下命令启动当前节点下的Ceph角色(前提是您在这个节点下安装/配置了相应角色)

// 启动mon角色
[root@vmnode1 ~]# service ceph start  mon.vmnode1
// 启动msd角色
[root@vmnode1 ~]# service ceph start mds.vmnode1
// 启动osd角色
[root@vmnode1 ~]# service ceph start osd.0

注意启动节点上的OSD角色时,后缀携带的并不是节点的名字,而是一个数字编号,例如以上示例中携带的数字编号就是“0”。这是因为一个操作系统节点可以携带若干个OSD角色,每个Ceph文件系统的OSD角色都有一个唯一的编号信息(编号数字从0开始),这个信息存放于OSD角色挂载的磁盘分区的根目录中,文件名为“whoami”。

例如osd.4角色挂载的分区根目录为 /usr/cephdata2,观察这个目录下的“whoami”文件,显示信息如下:

[root@vmnode2 ~]# cat /usr/cephdata2/whoami 
4
  • 停止MDS、MON、OSD

有启动当然就有停止,您可以通过以下命令停止某个节点上OSD角色、MDS角色或者MON角色的运行,或者干脆停止这个节点上所有正在运行的Ceph文件系统的角色:

// 停止mon角色
[root@vmnode1 ~]# service ceph stop  mon.vmnode1
// 停止msd角色
[root@vmnode1 ~]# service ceph stop mds.vmnode1
// 停止osd角色
[root@vmnode1 ~]# service ceph stop osd.0
// 或者干脆全部停止
[root@vmnode1 ~]# service ceph stop
  • 查看集群状态

涉及到这个功能的多个命令已经进行过说明,这里再次对这个命令列出,不再赘述这几个命令的具体不同:

// ceph集群状态概要
[root@vmnode1 ~]# ceph -s 
// ceph集群事件变化实时监控
[root@vmnode1 ~]# ceph -w
  • 查看集群空间使用情况

以下命令可以查看Ceph文件系统的空间使用情况:

[root@vmnode1 ~]# ceph df
GLOBAL:
    SIZE       AVAIL      RAW USED     %RAW USED 
    XXXXX     XXXXX         XXXXX          XXXXX 
POOLS:
    NAME                ID        USED      %USED      MAX AVAIL      OBJECTS 
    rbd                 0         XXX        XX            XXX           XXX
    cephfs_data         1         XXX        XX            XXX           XXX 
    cephfs_metadata     2         XXX        XX            XXX           XXX

Ceph文件系统的构成单元是OSD Pool,创建一个文件系统需要两个OSD Pool,一个用于存储真实的数据(data pool),另一个用于存储元数据(metadata pool),那么很明显Ceph文件系统就支持多个OSD Pool存在。另外,每个OSD Pool都基于 OSD PG存储数据,OSD PG的工作方式会在后文进行说明。这就是为什么使用以上命令,看到的会是Ceph文件系统中已有的OSD Pool列表,以及每个OSD Pool的空间使用情况。

另外您还可以使用以下命令,查看Ceph文件系统绑定OSD Pool的情况:

[root@vmnode1 ~]# ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

以上命令反馈中,可以看到文件系统的名字为cephfs,用于记录文件系统元数据的OSD Pool名叫cephfs_metadata,用于记录文件系统真实数据的OSD Pool名叫 cephfs_data。

  • 清除整个Ceph集群

这组命令也是在之前的文章中介绍过的,这里只列出命令示例:

// 清除已安装ceph组件的节点,类似于运行yum remove ceph....
[root@vmnode1 ~]# ceph-deploy purge vmnode1 vmnode2
// 命令格式为
ceph-deploy purge {ceph-node} [{ceph-node}] 
// 清楚节点上和ceph相关的数据、配置信息
[root@vmnode1 ~]# ceph-deploy purgedata vmnode1 vmnode2
// 命令格式为
ceph-deploy purgedata {ceph-node} [{ceph-node}] 

3-3-2. MON角色相关命令

  • 添加或删除一个MON角色(使用ceph-deploy)
// 创建一个新的mon节点
[ceph@vmnode1 ~]$ ceph-deploy mon create newnode
// 删除一个mon角色
[ceph@vmnode1 ~]$ ceph-deploy mon destroy vmnode3
// 命令格式为
ceph-deploy mon [-h] {add,create,create-initial,destroy} ...

create-initial参数的意义就不用多说了,初始化整个Ceph文件系统的MON角色,在上一篇介绍Ceph文件系统的安装过程中,我们第一次初始化整个Ceph文件系统的MON角色时,就是用的是create-initial参数。这里请注意add参数和create参数的不同意义,如果将要加入Ceph文件系统的MON节点还没有MON服务角色的配置信息,那么使用create参数(多数情况下是这样)。如果将要加入Ceph文件系统的MON节点上已经有了MON角色的配置,只是没有加入到Ceph系统中,则使用add参数。

  • 查看MON角色状态/选举情况
// 查看MON角色状态
[ceph@vmnode1 ~]$ sudo ceph quorum_status --format json
e2: 2 mons at {vmnode1=172.16.71.186:6789/0,vmnode3=172.16.71.185:6789/0}, election epoch 186, quorum 0,1 vmnode3,vmnode1

// 查看MON角色选举状态
[ceph@vmnode1 ~]$ sudo ceph quorum_status --format json
{
    "election_epoch": 186,
    "quorum": [
        0,
        1
    ],
    "quorum_names": [
        "vmnode3",
        "vmnode1"
    ],
    "quorum_leader_name": "vmnode3",
    "monmap": {
        "epoch": 2,
        "fsid": "f470130e-93c8-4280-8ad6-e5331207451f",
        "modified": "XXXXXXXXXXXXX",
        "created": "0.000000",
        "mons": [
            {
                "rank": 0,
                "name": "vmnode3",
                "addr": "172.16.71.185:6789\/0"
            },
            {
                "rank": 1,
                "name": "vmnode1",
                "addr": "172.16.71.186:6789\/0"
            }
        ]
    }
}

MON角色采用主备模式(leader/follower),也就是说即使系统中有多个MON角色,实际工作的也只有一个MON角色,其它MON角色都处于standby状态。当Ceph系统中失去了Leader MON后,其它MON角色会基于PaxOS算法,投票选出新的Leader MON。既然是这样,那么类似以上示例结果中显示MON节点只有两个的情况,就不再允许Leader MON角色退出了,因为一旦退出,投票决议始终都无法达到参与者的 N / 2 + 1的多数派,也就始终无法选出新的Leader MON(关于PaxOS算法的详细讲解请参看我另外几篇博客文章《系统存储(23)——数据一致性与Paxos算法(上)》、《系统存储(24)——数据一致性与Paxos算法(中)》、《系统存储(25)——数据一致性与Paxos算法(下)》)。而要保证MON角色的持续可用性,就至少需要在Ceph文件系统中,保持三个MON角色节点(这样可以允许最多一个MON角色节点错误离线)。

理解了Leader MON的选举方式,就可以理解以上示例中显示的MON选举状态信息了:quorum_names和quorum 是指代的投票参与者和投票参与者的编号、quorum_leader_name表示当前选举出来的Leader MON,election_epoch代表目前一共经历的投票轮次数量,epoch代表发起投票的次数(一次投票发起后,可能需要多轮投票才能选出新的Leader MON角色);而monmap中除了Ceph文件系统的基本信息外,还有一个rank属性,代表了每个MON角色的权重,权重越小的MON角色,在投票选举中越容易获得多数派支持。最后MON角色中可不只是存储了monmap信息,我们在后文介绍Ceph工作过程时,还会详细讲解。

3-3-3. MDS角色相关命令

  • 添加一个MDS角色(使用ceph-deploy)

可以使用以下命令格式进行MDS的添加

[ceph@vmonde1 ~]# ceph-deploy mds create {hostname}
#例如:
[ceph@vmonde1 ~]# ceph-deploy mds create vmnode4
  • 查看MDS角色状态

请注意一个操作系统节点只能添加一个MDS角色,而不能像添加OSD节点那样:只要有多余的磁盘分区进行独立挂载就可以在一个操作系统节点上添加多个OSD角色。另外Ceph文件系统中的多个MDS角色也是采用主备模式工作,而主备状态的决定、监控和切换完全由MON角色来控制。所以,如果您的Ceph文件系统中有多个MDS角色,并且运行查看MDS角色状态的命令,就会看到类似以下的查询结果:

[root@vmonde1 ~]# ceph mds stat
e48: 1/1/1 up {0=vmnode3=up:active}, 2 up:standby

从以上的执行结果来看,vmnode3节点上的MDS角色处于活动状态,另外两个节点上的MDS角色处于“待命”状态,您还可以使用以下命令,查看更详细的mds角色的工作状态。

[root@vmnode1 ~]# ceph mds dump
......
epoch   48
flags   0
created 2017-04-XX XXXXXX
modified    2017-04-XX XXXXXXX
......
  • 删除一个MDS角色

使用以下命令,可以删除某个节点上的MDS角色

ceph mds rm gid(<int[0-]>) <name (type.id)>
#例如:
[root@vmnode1 ~]# ceph mds rm 0 mds.vmnode1

3-3-4. OSD角色相关命令

上文已经提到,可以通过以下命令在OSD挂载的根路径查看当前OSD角色的编号,如下所示:

[root@vmnode2 ~]# cat /usr/cephdata2/whoami 
4

说明这个挂载点对应的OSD角色编号为4,我们将在维护OSD角色的命令中会使用这个编号,例如在OSD角色的停止/删除命令中。

  • 删除一个OSD角色
// 以下命令停止一个OSD角色的运行,但是并不将其排除到Ceph文件系统之外
[root@vmnode1 ~]# ceph osd down 0
// 以下命令将指定的OSD角色移除Ceph文件系统
[root@vmnode1 ~]# ceph osd rm 0
// 以下命令可以将指定节点上所有的OSD角色全部移除
[root@vmnode1 ~]# ceph osd crush rm vmnode1

以上命令中的参数“0”,代表OSD节点的的编号。另外需要注意,如果需要将指定的OSD角色从Ceph文件系统中移除,那么首先需要停止这个节点(运行之上的osd down命令,或者直接关闭OSD服务都行),否则Ceph文件系统会报类似如下的错误:

[root@vmnode1 ~]# ceph osd rm 0
Error EBUSY: osd.0 is still up; must be down before removal. 
  • 添加一个OSD角色(使用ceph-deploy)

使用ceph-deploy时,通过以下命令可以初始化一个OSD角色,并加入到Ceph文件系统中

// 初始化一个OSD角色
[root@vmnode1 ~]# ceph-deploy osd prepare vmnode4:/fs/osdroot
// 命令格式为
// ceph-deploy osd prepare {ceph-node}:{/path/to/directory}
// 启动这个新的OSD角色
[root@vmnode1 ~]# ceph-deploy osd activate vmnode4:/fs/osdroot
// 命令格式为
// ceph-deploy osd activate {ceph-node}:{/path/to/directory}

以上命令中,ceph-node是指节点名,后续的目录是指这个新的OSD角色所挂载的磁盘分区的根目录。在完成OSD角色初始化后,就会在OSD使用的目录挂载点根部出现准备好的若干目录和文件信息,例如本文之前提到的whoami文件,就是这个时候产生的。除了ceph-deploy osd activate可以启动一个这个新的OSD角色外,Ceph文件系统自生也提供OSD角色初始化启动的命令,如下所示:

[root@vmnode1 ~]# ceph-disk -v activate --mark-init sysvinit --mount /fs/osdroot/
  • 查看OSD角色状态
// 以下命令可以查看Ceph文件系统中OSD角色的概要状态信息
[root@vmnode1 ~]# ceph osd stat
     osdmap e127: 6 osds: 6 up, 6 in
// 如果想查看更详细的状态信息,可以使用以下命令
[root@vmnode1 ~]# ceph osd dump
epoch 127
fsid f470130e-93c8-4280-8ad6-e5331207451f
created 2017-04-XX XXXXXXXX
modified 2017-04-XX XXXXXXXXXX
......
  • 查看OSD角色位置结构

由于Ceph文件系统中,允许一个操作系统节点下添加多个OSD角色,当Ceph文件系统中的节点数量还不多时,技术人员还记得清楚OSD角色和节点的对应关系,但是当Ceph文件系统中的节点数到了一定的数量级后,技术人员就不一定能全记住。Ceph文件系统中提供给技术人员记录这些OSD存在位置的命令:

[root@vmnode1 ~]# ceph osd tree
ID WEIGHT TYPE NAME          UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-1      0 root default                                         
-2      0     host vmnode1                                     
 0      0         osd.0           up  1.00000          1.00000 
 3      0         osd.3           up  1.00000          1.00000 
-3      0     host vmnode2                                     
 1      0         osd.1           up  1.00000          1.00000 
 4      0         osd.4           up  1.00000          1.00000 
-4      0     host vmnode3                                     
 2      0         osd.2           up  1.00000          1.00000 
 5      0         osd.5           up  1.00000          1.00000 
......
  • 更改OSD角色权重

以上命令中所列出的各个列都很好理解,其中有一列名叫REWEIGHT,是指的每个OSD角色的权重值。OSD角色的权重值将会对存储数据的位置产生影响。通过以下命令,技术人员可以更改某个OSD角色的权重,命令如下(注意:以下命令中WEIGHT的值只能设定在0.0到1.0之间。):

[root@ceph-manager ~]# ceph osd reweight 1 0.9
// 命令格式为
ceph osd reweight {OSD.ID} {WEIGHT}

====================================
(接下文)

展开阅读全文

没有更多推荐了,返回首页