Ceph集概念以及部署
⼀、Ceph基础：
  1、基础概念：
    ceph 是⼀个开源的分布式存储，同时⽀持对象存储、块设备、⽂件系统
    ceph是⼀个对象(object)式存储系统，它把每⼀个待管理的数据流（⽂件等数据）切分伟⼀到多个固定⼤⼩（默认4M）的对象数据，并以其为原⼦单元（原⼦是构成元素的最⼩单元）完成数据的读写
    对象数据的底层存储服务是由多个存储主机（host）组成的存储集，该集也被称之为RADOS（reliable automatic distributed object store）存储集，即可靠的、⾃动化的、分布式的对象存储系统
    librados是RADOS存储集的API，⽀持C/C++/JAVA/Python/ruby/go/php等多种编程语⾔客户端
  2、ceph的设计思想：
    ceph的设计宗旨在实现以下⽬标：
      每⼀组件皆可扩展
      ⽆单点故障
      基于软件（⽽⾮专业设备）并且开源（⽆供应商）
      在现有的廉价硬件上运⾏
      尽可能⾃动管理，减少⽤户⼲预
  3、ceph版本：
leveldb使用
    x.0.z - 开发版
    x.1.z - 候选版
    x.2.z - 稳定、修正版
  4、ceph集⾓⾊定义：
  5、ceph集的组成部分：
    若⼲的Ceph OSD（对象存储守护进程）
    ⾄少需要⼀个Ceph Monitor 监视器（数量最好为奇数1，3，5，7........）
    两个或以上的Ceph管理器 managers，运⾏Ceph⽂件系统客户端时还需要⾼可⽤的Ceph Metadata Server（⽂件系统元数据服务器）
    RADOS Cluster：由多台host存储服务器组成的ceph集
    OSD（Object Storage Daemon）：每台存储服务器的磁盘组成的存储空间
    Mon（Monitor）：Ceph的监视器，维护OSD和PG的集状态，⼀个Ceph集⾄少有⼀个Mon节点，可以是⼀三五七等这样的奇数个
    Mgr（Manager）：负责跟踪运⾏时指标和Ceph集的当前状态，包括存储利⽤率，当前性能指标和系统负载等
  6、Ceph集术语详细介绍：
    6.1 Monitor（ceph-mon）ceph监视器：
      软件包名&进程名：ceph-mon 
      在⼀个主机上运⾏的⼀个守护进程，⽤于维护集状态映射(maintains maps of the cluster state)，⽐如ceph 集中有多少存储池、每个存储池有多少PG 以及存储池和PG的映射关系等， monitor map, manager map, the OSD map, the MDS map, and the CRUSH map，这些映射是Ceph 守护程序相互协调所需的关键集状态，此外监视器还负责管理守护程序和客户端之间的⾝份验证(认证使⽤cephX 协议)。通常⾄少需要三个监视器才能实现冗余和⾼可⽤性。
    6.2 Managers
      软件包&进程名：ceph-mgr   
      在⼀个主机上运⾏的⼀个守护进程，Ceph Manager 守护程序（ceph-mgr）负责跟踪运⾏时指标和Ceph 集的当前状态，包括存储利⽤率，当前性能指标和系统负载。Ceph Manager 守护程序还托管基于python 的模块来管理和公开Ceph 集信息，包括基于Web 的Ceph 仪表板和REST API。⾼可⽤性通常⾄少需要两个管理器。
    6.3 Ceph OSDs（对象存储守护程序ceph-osd）
      软件包名&进程名：ceph-osd
      提供存储数据，操作系统上的⼀个磁盘就是⼀个OSD 守护程序，OSD ⽤于处理ceph集数据复
制，恢复，重新平衡，并通过检查其他Ceph OSD 守护程序的⼼跳来向Ceph监视器和管理器提供⼀些监视信息。通常⾄少需要3 个Ceph OSD 才能实现冗余和⾼可⽤性。
    6.4 MDS（ceph元数据服务器ceph-mds）
      软件包名&进程名：ceph-mds
      代表ceph⽂件系统（NFS/CIFS）存储元数据（即Ceph块设备和Ceph对象存储不使⽤MDS）
    6.5 Ceph的客户端管理⼯具
      例如：rados、ceph、rbd  推荐使⽤部署专⽤节点对ceph进⾏管理、升级和后期维护，⽅便权限管理，避免⼀些不必要的误操作发⽣
  7、Ceph逻辑组织架构：
    7.1 Pool：存储池，分区、存储池的⼤⼩取决于底层的存储空间
    7.2 PG（Placement group）：⼀个pool内部可以有多个PG存在，pool和PG都是抽象的逻辑概念，⼀个pool中有多少个PG可以通过公式计算
    7.3 OSD（Object Storage Daemon，对象存储设备）：每⼀块磁盘都是⼀个osd，⼀个主机由⼀个或多个osd组成
  8、向Ceph写⼊数据的⼤致流程：
    Ceph集部署好了之后，要先创建存储池才能向ceph写⼊数据，⽂件在向ceph保存之前要先进⾏⼀致性hash计算，计算后会把⽂件保存在某个对应的PG中，此⽂件⼀定属于某个pool的⼀个PG，再通过PG保存在OSD上。数据对象在写到主OSD之后再同步到从OSD以实现数据的⾼可⽤
  根据上图总结⼀下存储⽂件到Ceph的流程：
    1、计算⽂件到对象的映射：假设file为客户端要读写的⽂件，得到oid（object id）= ino + ono （其中ino：inode number ，file的元数据序列号，file的唯⼀ID；ono：object number，file切分产⽣的某个object的序号，默认以4M切分⼀个块的⼤⼩）
    2、通过hash算法计算出⽂件对应的pool中的PG：通过⼀致性hash计算Object到PG，Object-》PG映射hash（oid）&mask-》pgid
    3、通过CRUSH把对象映射到PG中的OSD：通过CRUSH算法计算PG到OSD，PG——》OSD映射：[CRUSH(pgid)——》(osd1，osd2，osd3)]
    4、PG中的主OSD将对象写⼊到硬盘
    5、主OSD将数据同步给备份OSD即从OSD，并等待备份OSD返回确认
    6、主OSD将写⼊完成返回给客户端
  9、Ceph元数据保存⽅式：
    9.1　xattrs（扩展属性）：是将元数据保存在对象对应⽂件的扩展属性中并保存到系统盘上，这要求⽀持对象存储的本地⽂件系统（⼀般是XFS）⽀持扩展属性
    9.2　omap（object map：对象映射）：是将元数据保存在本地⽂件系统之外的独⽴key-value存储系统中，在使⽤filestore时是leveldb；在使⽤bluestore时是rocksdb
    9.3　filestore与leveldb
      Ceph早期基于filestore使⽤google的leveldb保存对象元数据。Leveldb是⼀个持久化存储的KV系统，与Redis不同的
是，leveldb不会像Redis⼀样将数据放在内存中从⽽占据打两的内存空间，⽽是将⼤部分数据存储到磁盘上，但是需要把磁盘格式化为⽂件系统（XFS）
      Filestore将数据保存到与Posix兼容的⽂件系统（Btrfs，XFS，Ext4），缺点：性能、对象属性与磁盘本地的⽂件系统属性匹配存在限制
    9.4　bluestore与rocksdb
      RocksDB通过中间层BlueRocksDB访问⽂件系统接⼝，这个⽂件系统与传统的Linux⽂件系统（例如Ext4，XFS）不同，它不是VFS下⾯的通⽤⽂件系统，⽽是⼀个⽤户态的逻辑。BlueFS通过函数接⼝（API，⾮POSIX）的⽅式为BlueRocksDB提供类似⽂件系统的能⼒
      以上各模块的作⽤：
        Allocator：负责裸设备的空间管理分配
        RocksDB：基于leveldb的开发的⼀款KV数据库，BlueStore将元数据全部存放⾄RocksDB中，这些元数据包括存储预写⽇志、数据对象元数据、Ceph的omap数据信息、以及分配器的元数据
        BlueRocksEnv：这是RocksDB与BlueFS的交互接⼝，RocksDB提供了⽂件操作的接⼝EnvWrapper（Env封装器），可以通过继承实现该接⼝来定义底层的读写操作，BlueRocksEnv就是继承EnvWrapper实现对BlueFS的读写
        BlueFS：BlueFS是BlueStore针对RocksDB开发的轻量级⽂件系统，⽤于存放RocksDB产⽣的.sst和.log⽂件
        BlockDevice：BlueStore抛弃了传统的ext4、xfs⽂件系统，使⽤直接管理裸盘的⽅式；BlueStore⽀持同时使⽤多种不同类型的设备，在逻辑上BlueStore将存储空间划分为三层：慢速（Slow）空间，⾼速（DB）空间，超⾼速（WAL）空间，不同空间可以指定不同的设备类型，当然也可使⽤同⼀块设备
      BlueStore的优势：BlueStore的设计考虑了FileStore中存在的⼀些硬伤，抛弃了传统的⽂件系统直接管理裸设备，缩短了IO路径，同时采⽤ROW的⽅式，避免了⽇志双写的问题，在写⼊性能上有了极⼤的提⾼
  10、CRUSH算法简介：
    CRUSH：Controllers replication under scalable hashing：可控的、可复制的、可伸缩的⼀致性hash算法，CRUSH是⼀种分布式算法，类似于⼀致性hash算法，⽤于为RADOS存储集控制数据的分配
    Ceph使⽤CRUSH算法来存放和管理数据，它是Ceph的智能数据分发机制。Ceph使⽤CRUSH算法
来准确计算数据应该被保存到哪⾥，以及应该从哪⾥读取。和保存元数据不同的是，CRUSH按需计算出元数据，因此它就消除了对中⼼式服务器/⽹关的需求，它使得Ceph客户端能够计算出元数据，该过程也称为CRUSH查，然后和OSD直接通信
    这⾥就会有⼀个问题，为什么要这么设计CRUSH算法？如果是把对象直接映射到OSD之上会导致对象与OSD的对应关系过于紧密和耦合，当OSD由于故障发⽣变更时将会对整个Ceph集产⽣影响。于是Ceph将⼀个对象映射到RADOS集的时候分两步⾛：⾸先使⽤⼀致性hash算法将对象名称映射到PG ，然后将PG ID基于CRUSH算法映射到OSD即可查到对象。
    以上两个过程都是以”实时计算“的⽅式完成，⽽没有使⽤传统的查询数据与块设备的对应表的⽅式，这样有效的避免了组件的”中⼼化“问题，也解决了查询性能和冗余问题，使得Ceph集扩展不再受查询的性能限制
⼆、Ceph集部署
  1、环境准备
    系统版本：ubuntu-18.04-lts 
    内存： 3G
    CPU：1C
    磁盘：每台主机挂载5块数据盘
    ip        hostname      role
    192.168.199.22  ubuntu-node02  　ceph-deploy、ceph-mgr、ceph-mon、ceph-node
    192.168.199.23  ubuntu-node03  　ceph-node
    192.168.199.24  ubuntu-node04  　ceph-node
  　2、配置国内ubuntu源
    vim /etc/apt/sources.list
# 默认注释了源码镜像以提⾼ apt update 速度，如有需要可⾃⾏取消注释
deb mirrors.tuna.tsinghua.edu/ubuntu/ bionic main restricted universe multiverse
# deb-src mirrors.tuna.tsinghua.edu/ubuntu/ bionic main restricted universe multiverse
deb mirrors.tuna.tsinghua.edu/ubuntu/ bionic-updates main restricted universe multiverse
# deb-src mirrors.tuna.tsinghua.edu/ubuntu/ bionic-updates main restricted universe multiverse
deb mirrors.tuna.tsinghua.edu/ubuntu/ bionic-backports main restricted universe multiverse
# deb-src mirrors.tuna.tsinghua.edu/ubuntu/ bionic-backports main restricted universe multiverse
deb mirrors.tuna.tsinghua.edu/ubuntu/ bionic-security main restricted universe multiverse
# deb-src mirrors.tuna.tsinghua.edu/ubuntu/ bionic-security main restricted universe multiverse
  3、配置时间同步：
    apt install ntpdate -y
    ntpdate ntp1.aliyun
  4、配置本地hosts⽂件
    vim /etc/hosts
    192.168.199.22  ubuntu-node02
    192.168.199.23  ubuntu-node03
    192.168.199.24  ubuntu-node04
  5、导⼊ceph的校验码，添加国内的ceph源
  6、配置双⽹卡：
    ens33：桥接
    ens38：nat
    注：另外两台机器只需将IP修改⼀下就可以了
    vim /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: no
dhcp6: no
addresses: [ 192.168.199.22/24 ]
gateway4: 192.168.199.1
nameservers:
search: [ ubuntu-node02 ]
addresses:
- "192.168.199.1"
ens38:
dhcp4: no
dhcp6: no
addresses: [ 172.16.1.22/24 ]
  7、创建ceph⽤户并配置可免密登录其他节点
    groupadd -r -g 2022 ceph && useradd -r -m -s /bin/bash -u 2022 -g 2022 ceph && echo ceph:123456 | chpasswd    　ssh-keygen -t rsa
    ssh-copy-id ceph@192.168.199.22
    ssh-copy-id ceph@192.168.199.23
    ssh-copy-id ceph@192.168.199.24
    允许ceph⽤户执⾏sudo命令：  echo "ceph ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
  8、安装ceph部署⼯具ceph-deploy：
    apt-cache madison ceph-deploy    　# 列出ceph-deploy的版本信息
    apt install ceph-deploy -y
  9、初始化mon节点：
    切换到ceph⽤户的家⽬录创建ceph集初始化⽬录：
      su - ceph
      mkdir ceph-cluster
      各节点安装python2并创建软链接
        apt install python2.7 -y
        ln -sv /usr/bin/python2.7 /usr/bin/python2
      ceph-deploy new --cluster-network 172.16.1.0/24 --public-network 192.168.199.0/24 ubuntu-node02
      注：
        --cluster-network：指定ceph集内部通信的⽹段
        --public-network：指定外部访问的⽹段地址
  10、初始化node节点：
    注意：确保ceph⽤户的家⽬录在/var/lib/ceph并且将原来/home/ceph/⽬录下⾯的ceph-cluster⽬录下⾯的⽂件拷贝
到/var/lib/ceph/ceph-cluster⽬录下
    ceph-deploy install --no-adjust-repos --nogpgcheck ubuntu-node02 ubuntu-node03 ubuntu-node04    　# 根据情况输⼊yes和主机密码
  11、配置mon节点并同步⽣成秘钥：
    　apt install ceph-mon -y
    　ceph-deploy mon create-initial    　# 初始化mon节点
    验证mon节点：
    分发admin秘钥：
      apt-get install ceph-common -y
      ceph-deploy admin ubuntu-node02
  12、ceph节点验证秘钥：
    修改/etc/ceph/ceph.client.admin.keyring⽂件的属主：
      sudo chown -R ceph. /etc/ceph/
  13、配置manager节点：
    sudo apt install ceph-mgr -y    　# 安装ceph-mgr
    ceph-deploy mgr create ubuntu-node02    # 创建管理节点
    验证mgr节点：
  14、使⽤ceph-deploy管理ceph集：
  15、验证ceph命令：
    注意：因为重新推送了admin秘钥，所以/etc/ceph/ceph.client.admin.keyring⽂件的属主改变了需要重新修改属主
      sudo chown -R ceph. /etc/ceph/
  16、集调整：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。