kolla-ceph 5: 一個ceph容器化部署編排項目

系列鏈接

  1. http://www.lxweimin.com/p/f18a1b3a4920 如何用kolla來部署容器化ceph集群
  2. http://www.lxweimin.com/p/a39f226d5dfb 修復一些部署中遇到的問題
  3. http://www.lxweimin.com/p/d520fed237c0 在kolla ceph中引入device classes特性
  4. http://www.lxweimin.com/p/d6e047e1ad06 支持bcache設備和iscsi及多路徑設備
  5. http://www.lxweimin.com/p/ab8251fc991a 一個ceph容器化部署編排項目

kolla-ceph : 一個ceph容器化部署編排項目

github地址: https://github.com/wangw-david/kolla-ceph

起源

這個項目中的部分代碼來自于kolla和kolla-ansible, 而kolla和kolla-ansible是openstack的容器化部署項目, 包含了ceph和其他openstack組件的部署, 但是因為ceph部署的復雜性, 社區決定不再開發ceph部署和管理的相關的大的feature, 只對現有的部署進行維護, 并逐漸廢棄對ceph部署的支持.

Support for deploying Ceph via Kolla Ansible is deprecated. In a future
release support for deploying Ceph will be removed from Kolla Ansible. Prior
to this we will ensure a migration path to another tool such as Ceph
Ansible (http://docs.ceph.com/ceph-ansible/master/>) is available. For new
deployments it is recommended to use another tool to deploy Ceph to avoid a
future migration. This can be integrated with OpenStack by following the
external Ceph guide
(https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-ceph-guide.html).

但是作為一個一直使用kolla來部署ceph集群的人, 我覺得放棄對ceph部署的支持太可惜了, 在容器特別是類似于ceph和openstack這樣的進程容器的編排部署上, kolla有一套很成熟的體系:

  1. 鏡像的構建很方便
  2. 與docker的交互很方便, 社區自己開發的ansible腳本可以方便的操作docker容器, 包括比較, 刪除, 創建等.
  3. 使用ansible可以方便流程化部署和定制化部署
  4. 在ceph的部署上, 社區設計的流程是給磁盤打上標簽, 然后osd初始化過程中先bootstrap, 再啟用osd, 不同的osd容器掛載獨立的磁盤, 部署和維護都特別方便.

基于以上的優點, 我決定在社區版本的基礎上進行二次開發, 將我在日常使用中遇到的一些問題, 和一些新特性的支持, 提交上去, 于是有了這個kolla-ceph的項目.

主要改進如下:

1. 精簡代碼只保留與ceph相關的, 并用shell腳本進行操作, 簡化流程
2. 修復了一些bug(之前已經提交了一些bug修復到社區版本)
3. 添加了一些新的特性, 比如指定ceph daemon進行部署, 設置device class并根據device class 自動創建pool等
4. 添加了對lvm方式部署ceph osd的支持(類似于ceph-volume)
5. 添加了對多路徑磁盤和bcache磁盤的部署支持
6. 對之前的osd 的初始化過程進行了重寫, 改用uuid的形式, 與ceph-disk保持一致
7. 對ceph容器的ansible部署進行了重構, 使用了ansible handler, 對部署和升級不同場景的下的流程進行了區別, 更安全的部署和升級及配置.

注: kolla-ceph可用于管理社區版本的bluestore osd, 但是不可用于社區版本的filestore, 因為社區的filestore太古老了..., 當前只限定于centos 7, 其他系統并不支持

使用

整個kolla-ceph的文件夾結構如下:

.
├── ansible # 部署相關ansible任務
├── build.sh # 構建鏡像的shell腳本
├── ceph-build.conf # 構建相關配置
├── ceph-env # 要部署的集群的相關配置
├── docker # dockerfile文件等
├── kolla  # kolla的構建鏡像的python腳本
├── LICENSE
├── manage.sh # 部署及修復, 升級的shell腳本
├── NOTICE
├── README.md
└── requirements.txt

構建鏡像

  • 構建鏡像需要修改ceph-build.conf
[DEFAULT]
base = centos
type = binary

profile = image_ceph

registry =
username =
password =
email =

namespace = kolla-ceph
retries = 1
push_threads = 4
maintainer = Kolla Ceph Project
ceph_version = nautilus
ceph_release = 14.2.2

[profiles]
image_ceph = fluentd,cron,kolla-toolbox,ceph

需要配置的地方主要就是docker registry的相關信息, 然后ceph的version和release, version的選項有luminous, mimic, nautilus, release對應的每個version的release號. 配置后安裝的ceph版本和指定的版本一致.

  • 構建記錄

利用build.sh可以自動構建鏡像, 不過build.sh會需要一個文件路徑來存儲相關的構建信息, 默認是以下路徑:

BUILD_DATA_PATH="/home/kolla-ceph"

該路徑下保存以下文件:

.
├── BUILD_CEPH_RECORD
├── log
│   ├── build-nautilus-14.2.2.0001.log
│   ├── build-nautilus-14.2.2.0002.log
│   └── build-test.0001.log
└── TAG_CEPH_NUMBER

BUILD_CEPH_RECORD保存的是構建每個鏡像的時間

2019-10-23 19:22.58 build ceph | tag : [ nautilus-14.2.2.0001 ]
2019-10-25 11:53.38 build ceph | tag : [ nautilus-14.2.2.0002 ]

TAG_CEPH_NUMBER 保存的是上一次構建成功的序列號, 下一次自動構建會在此基礎上加1.

log中是每次構建的輸出日志.

  • 構建腳本

可以指定tag, 也可以不指定, 默認是(ceph version)-(ceph release).(serial number), 比如 nautilus-14.2.2.0001

Usage: sh build.sh [options]

Options:
    --tag, -t <image_tag>              (Optional) Specify tag for docker images
    --help, -h                         (Optional) Show this usage information

自動構建

sh build.sh

指定tag構建

sh build.sh --tag test.0001

部署和管理集群

磁盤初始化

目前kolla-ceph中支持兩種模式的osd初始化, disk模式(類似于ceph-disk, 也是社區現有的版本, 本項目對這部門代碼進行了重寫)和lvm模式(類似于ceph-volume, 本項目后添加該功能代碼), 每種模式都支持bulestore和filestore的部署, 以下會詳細講解如何初始化磁盤.

disk模式
  • bluestore

bluestore如果用disk模式的話, 一個osd最多有四個磁盤分區, 100M左右的osd data分區, 用來保存osd啟動所需要的數據; block分區, 承載數據的分區; db分區, 用來保存rocksdb的數據和元數據; wal分區, 用來保存rocksdb的日志文件.
在kolla-ceph中, 所有分區以后綴來區別, bluestore DISK模式前綴中有個_BS:

KOLLA_CEPH_OSD_BOOTSTRAP_BS_${OSD_NAME}_${OSD_DISK_SUFFIXES}

例如:
KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_B(FOO1代表同一個osd,B代表block分區)
KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_D(FOO1代表同一個osd,D代表db分區)
KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_W(FOO1代表同一個osd,W代表wal分區)
KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1(FOO1代表同一個osd,無后綴代表osd data分區)
KOLLA_CEPH_OSD_BOOTSTRAP_BS(沒有osd名和后綴, 默認代表一個osd, 會被自動分為osd data分區和block分區)

以下是后綴意義:
(B) : OSD Block Partition
(D) : OSD DB Partition
(W) : OSD WAL Partition
(null) : 在kolla ceph中, 如果一個分區沒有后綴, 有兩種情況: 1. 沒有對應的block分區, 那么這個分區會被自動初始化為兩個分區, osd data分區和block分區; 2. 如果這個osd已經有_B后綴的block分區, 那這個沒有后綴的分區會被用來做osd data分區.

初始化磁盤

# 清除原有分區
sudo sgdisk --zap-all -- /dev/sdb
sudo sgdisk --zap-all -- /dev/sdc
sudo sgdisk --zap-all -- /dev/sdd

# 簡單初始化, 無后綴
sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1  1 -1

# 自定義多個分區
sudo /sbin/parted /dev/sdb -s -- mklabel  gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1 1 100
sudo /sbin/parted /dev/sdb -s mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_B 101 100%
sudo /sbin/parted /dev/sdc -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_D 1 2000
sudo /sbin/parted /dev/sdd -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_W 1 2000
  • filestore

disk模式下filestore一個osd有兩個磁盤分區, osd data分區(保存osd啟動數據和存儲數據), journal(日志分區)

KOLLA_CEPH_OSD_BOOTSTRAP_${OSD_NAME}_${OSD_DISK_SUFFIXES}

例如:
KOLLA_CEPH_OSD_BOOTSTRAP_FOO1_J(日志分區)
KOLLA_CEPH_OSD_BOOTSTRAP_FOO1(data分區)
KOLLA_CEPH_OSD_BOOTSTRAP(無后綴會默認劃分為data分區和5G的日志分區)

以下是后綴意義:
(J) : OSD Journal Partition
(null) : 如果無后綴, 當osd有對應的journal分區的時候, 該分區只代表data分區, 如果沒有額外的journal分區, 那么該分區會自動劃分為data分區和5G的日志分區

初始化磁盤:

# 清除舊的分區
sudo sgdisk --zap-all -- /dev/sdb
sudo sgdisk --zap-all -- /dev/sdc

# 簡易初始化, 無后綴
sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_FOO1  1 -1

# 自定義磁盤分區
parted  /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_FOO1  1  -1
parted  /dev/sdc -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_FOO1_J  1  5000
LVM模式
  • bluestore

LVM模式跟DISK模式的不同在于, LVM模式下, osd data分區是從tmpfs中掛載出來的一個分區, 而block分區則是一個虛擬卷, wal分區和db分區則依舊可以是原始分區. bluestore LVM模式前綴中有個_BSL:

KOLLA_CEPH_OSD_BOOTSTRAP_BSL_${OSD_NAME}_${OSD_DISK_SUFFIXES}

例如:
KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1_B
KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1_D
KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1_W
KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1 (無后綴代表block分區, 會被初始化成虛擬卷)
KOLLA_CEPH_OSD_BOOTSTRAP_BSL(無osd名, 無后綴代表一個osd)

后綴代表:
(B) : OSD Block Partition
(D) : OSD DB Partition
(W) : OSD WAL Partition
(null) : 在lvm模式下, 無后綴整個分區會被用于block分區的虛擬卷

初始化磁盤

sudo sgdisk --zap-all -- /dev/sdb
sudo sgdisk --zap-all -- /dev/sdc
sudo sgdisk --zap-all -- /dev/sdd

# 簡易初始化
sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1  1 -1

# 自定義磁盤分區
# 以下兩種都代表block分區
sudo /sbin/parted /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1 1 100%
或者
sudo /sbin/parted /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1_B 1 100%

sudo /sbin/parted /dev/sdc -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1_D 1 2000
sudo /sbin/parted /dev/sdd -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL_FOO1_W 1 2000
Filestore

LVM模式下filestore的osd data分區會被初始化成虛擬卷, 而journal盤依舊可以是原始分區.

KOLLA_CEPH_OSD_BOOTSTRAP_L_${OSD_NAME}_${OSD_DISK_SUFFIXES}

例如:
KOLLA_CEPH_OSD_BOOTSTRAP_L_FOO1_J
KOLLA_CEPH_OSD_BOOTSTRAP_L_FOO1(無后綴代表osd data分區)
KOLLA_CEPH_OSD_BOOTSTRAP_L(簡易初始化, 整個磁盤會被分為5G的journal分區和osd data分區)
以下是后綴意義:
(J) : OSD Journal Partition
(null) : 當沒有單獨的journal分區的時候, 這個分區會被初始化成5G的journal分區. 當有journal分區的時候, 這個分區只是代表osd data分區, 與disk模式最大的不同在于, osd data分區會被創建成虛擬卷.

磁盤初始化

sudo sgdisk --zap-all -- /dev/sdb
sudo sgdisk --zap-all -- /dev/sdc

# 簡易初始化
sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_L_FOO1  1 -1

# 自定義初始化
parted  /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_L_FOO1  1  -1
parted  /dev/sdc -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP_L_FOO1_J  1  5000

部署新的集群

舉例如下:

node usage disk
ceph-node1 mon, mgr, osd, rgw sdb, sdc, sdd
ceph-node2 mon, mgr, mds, osd sdb, sdc, sdd
ceph-node3 mds, osd sdb, sdc, sdd
創建配置文件

當我們要部署一個新的集群, 我們需要在ceph-env路徑下創建一個文件夾, 文件夾名代表集群的名字, 比如test:

.
└── test
    ├── ceph.conf
    ├── globals.yml
    └── inventory

其中, ceph.conf是ceph配置中需要自定義的部分; globals.yml是該集群部署需要的配置, 默認使用all.yml中的配置; inventory是該集群的節點配置.

  • 例如ceph.conf
[global]
rbd_default_features = 1
public_network = 192.168.10.0/24 (必須)
cluster_network = 192.168.10.0/24 (必須)
osd_pool_default_size = 2
osd_pool_default_min_size = 1
osd_class_update_on_start = false
mon_max_pg_per_osd = 500
mon_allow_pool_delete = true

[mon]
mon_warn_on_legacy_crush_tunables = false
mon_keyvaluedb = rocksdb
mon_health_preluminous_compat = false
mon_health_preluminous_compat_warning = false

[client]
rbd_cache = True
rbd_cache_writethrough_until_flush = True
  • globals.yml
---
####################
# Docker options
####################
### Example: Private repository with authentication

docker_registry: "192.168.10.11:4000" (必須)
docker_namespace: "kolla-ceph" (必須) # 與 ceph-build.conf 中的配置一致

# Valid options are [ never, on-failure, always, unless-stopped ]
docker_restart_policy: "always"
docker_registry_username: ""
docker_registry_password: ""

###################
# Ceph options
###################
ceph_pool_pg_num: 32
ceph_pool_pgp_num: 32

osd_initial_weight: "auto"
ceph_cluster_fsid: "4a9e463a-4853-4237-a5c5-9ae9d25bacda" (必須)
  • inventory
# api_interface: NIC used by other services
# storage_interface: NIC used by ceph public_network
# cluster_interface: NIC used by ceph cluster_network
# device_class: Specify device-class corresponding to osd, one node supports one device-class
[mons]
ceph-node1 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0
ceph-node2 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0

[osds]
ceph-node1 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0 device_class=hdd
ceph-node2 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0 device_class=hdd
ceph-node3 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0 device_class=hdd

[rgws]
ceph-node1 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0

[mgrs]
ceph-node1 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0
ceph-node2 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0

[mdss]
ceph-node2 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0
ceph-node3 ansible_user=root api_interface=eth0 storage_interface=eth0 cluster_interface=eth0

[nfss]

[ceph-mon:children]
mons

[ceph-rgw:children]
rgws

[ceph-osd:children]
osds

[ceph-mgr:children]
mgrs

[ceph-mds:children]
mdss

[ceph-nfs:children]
nfss

初始化磁盤示例:
sudo sgdisk --zap-all -- /dev/sdb
sudo sgdisk --zap-all -- /dev/sdc
sudo sgdisk --zap-all -- /dev/sdd

# bluestore disk 模式簡易初始化
#sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS  1 -1
#sudo /sbin/parted  /dev/sdc  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS  1 -1
#sudo /sbin/parted  /dev/sdd  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS  1 -1

# bulestore lvm 模式簡易初始化
sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL  1 -1
sudo /sbin/parted  /dev/sdc  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL  1 -1
sudo /sbin/parted  /dev/sdd  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BSL  1 -1

# bluestore disk 模式自定義
#sudo /sbin/parted  /dev/sdb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1  1 1000
#sudo /sbin/parted  /dev/sdb  -s  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_B  1001 100%
#sudo /sbin/parted  /dev/sdc  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_W  1  25000
#sudo /sbin/parted  /dev/sdc  -s  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1_D  25001 100%

# 多路徑磁盤初始化
#sudo sgdisk --zap-all -- /dev/mapper/mpathc
#sudo sgdisk --zap-all -- /dev/mapper/mpathb

#sudo /sbin/parted  /dev/mapper/mpathb  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1  1 -1
#sudo /sbin/parted  /dev/mapper/mpathc  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO2  1 -1

# bcache 磁盤初始化
#sudo sgdisk --zap-all -- /dev/bcache0
#sudo sgdisk --zap-all -- /dev/bcache1
#sudo /sbin/parted  /dev/bcache0  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO1  1 -1
#sudo /sbin/parted  /dev/bcache1  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS_FOO2  1 -1

部署腳本
Usage: sh manage.sh COMMAND [options]

Options:
    --help, -h                         (Optional) Show this usage information
    --image, <images tag>              (Required) Specify images tag to be deployed
    --limit <host>                     (Optional) Specify host to run plays
    --forks <forks>                    (Optional) Number of forks to run Ansible with
    --daemon <ceph-daemon>             (Optional) Specify ceph daemon to be installed, default is all,[ceph-mon,ceph-mgr,ceph-osd,ceph-rgw,ceph-mds]
    --cluster <ceph-cluster-name>      (Required) Specifies the name of the ceph cluster to deploy, which should be placed in the ceph-env folder
    --skip-pull                        (Optional) Whether to skip pulling the image
    --verbose, -v                      (Optional) Increase verbosity of ansible-playbook

Commands:
    deploy              Deploy Ceph cluster, also to fix daemons and update configurations
    reconfigure         Reconfigure Ceph service
    stop                Stop Ceph containers
    upgrade             Upgrades existing Ceph Environment(Upgrades are limited to one by one, but there can be multiple daemons on a node,
                        so please specify some daemons name, it is recommended to upgrade only one daemon at a time.)

下面根據一些場景說一下具體如何使用部署腳本.

  • 部署新的ceph集群

需要指定鏡像的tag和集群的名稱

sh manage.sh deploy --cluster test --image nautilus-14.2.2.0001
  • 修復損壞的osd

比如osd.0損壞, 首先清除舊的磁盤

# docker stop ceph_osd_0 && docker rm ceph_osd_0

# fdisk -l

Disk /dev/sdd: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 3EB2FAA8-2270-48A4-841E-1E857700D28F


#         Start          End    Size  Type            Name
 1         2048       206847    100M  unknown         KOLLA_CEPH_DATA_BS_0
 2       206848    104857566   49.9G  unknown         KOLLA_CEPH_DATA_BS_0_B

# df -h
/dev/sdd1                 97M  5.4M   92M   6% /var/lib/ceph/osd/81493f61-ce76-49bb-a27c-fa2c09d9d6c7

# umount /var/lib/ceph/osd/81493f61-ce76-49bb-a27c-fa2c09d9d6c

# sudo sgdisk --zap-all -- /dev/sdd

# sudo /sbin/parted  /dev/sdd  -s  -- mklabel  gpt  mkpart KOLLA_CEPH_OSD_BOOTSTRAP_BS  1 -1

添加以下在globals.yml中, 這樣就不會影響到正在運行的容器, 當配置或者鏡像改變時, 依舊不會影響正在運行的容器.

ceph_container_running_restart: "no"

損壞的osd在node1, 所以我們只需要在ceph-node運行(--limit ceph-node1); 然后只需要部署osd, 不需要其他的ceph組件(--daemon ceph-osd); 也不需要再拉取鏡像, 跳過pull來節省時間(--skip-pull):

sh manage.sh deploy --cluster test --image nautilus-14.2.2.0001 --daemon ceph-osd --limit ceph-node1 --skip-pull

其他的組件修改也是一樣, 可以用--daemon來限定

  • 升級ceph的鏡像或者版本

用容器部署的ceph集群, 最方便的就是升級版本, 我們可以一個容器一個容器的進行升級. 我們再構建一個鏡像nautilus-14.2.2.0002, 然后模擬版本升級.

整個升級流程是串行的, 串行是腳本在upgrade action時自動設置的, 即先升級一個節點上的容器, 再升級下一個節點, 如果你想讓同一組件先升級, 需要用--daemon來限定升級的組件.

下面這個參數可以打開ceph狀態檢測, 當升級下一個容器時, 會先檢測集群狀態, 當狀態為health_ok時進行升級. 當然, 需要在升級之前讓ceph集群狀態為health_ok.

enable_upgrade_health_check: "no"
  1. 首先我們需要升級mon, mon只能單獨指定升級, 不能和其他組件一起升級
sh manage.sh upgrade  --cluster test --image nautilus-14.2.2.0002 --daemon ceph-mon

  1. 升級其他組件可以一起升級, 也可以單獨升級
sh manage.sh upgrade  --cluster test --image nautilus-14.2.2.0020 --daemon ceph-osd,ceph-mgr
  • 創建pool

可以在globals.yml中重新定義要創建的pool, 可直接在rule中指定device class, 就會限定pool所在的osd:

定義一個pool需要以下的項, 一般只需要必填項就可以了:

 +----------------------+---------------------------------------------------+
 | item name            | required                                          |
 +======================+===================================================+
 | pool_name            | Required                                          |
 +----------------------+---------------------------------------------------+
 | pool_type            | Required                                          |
 +----------------------+---------------------------------------------------+
 | pool_pg_num          | Required                                          |
 +----------------------+---------------------------------------------------+
 | pool_pgp_num         | Required                                          |
 +----------------------+---------------------------------------------------+
 | pool_erasure_name    | Optional, required when pool_type is erasure      |
 +----------------------+---------------------------------------------------+
 | pool_erasure_profile | Optional, required when pool_type is erasure      |
 +----------------------+---------------------------------------------------+
 | pool_rule_name       | Optional, required when pool_type is replicated   |
 +----------------------+---------------------------------------------------+
 | pool_rule            | Optional, required when pool_type is replicated   |
 +----------------------+---------------------------------------------------+
 | pool_cache_enable    | Optional, default is false                        |
 +----------------------+---------------------------------------------------+
 | pool_cache_mode      | Optional, required when pool_cache_enable is true |
 +----------------------+---------------------------------------------------+
 | pool_cache_rule_name | Optional, required when pool_cache_enable is true |
 +----------------------+---------------------------------------------------+
 | pool_cache_rule      | Optional, required when pool_cache_enable is true |
 +----------------------+---------------------------------------------------+
 | pool_cache_pg_num    | Optional, required when pool_cache_enable is true |
 +----------------------+---------------------------------------------------+
 | pool_cache_pgp_num   | Optional, required when pool_cache_enable is true |
 +----------------------+---------------------------------------------------+
 | pool_application     | Required                                          |
 +----------------------+---------------------------------------------------+

例如:

ceph_pools:
  - pool_name: "rbd"
    pool_type: "replicated"
    pool_rule_name: "hdd-rep"
    pool_rule: "default host hdd"
    pool_pg_num: 32
    pool_pgp_num: 32
    pool_application: "rbd"
    create: "yes"
  - pool_name: "rbd-ec"
    pool_type: "erasure"
    pool_erasure_name: "hdd-ec"
    pool_erasure_profile: "k=2 m=1 crush-failure-domain=osd crush-device-class=hdd"
    pool_pg_num: 32
    pool_pgp_num: 32
    pool_application: "rbd"
    create: "yes"

在ceph的部署中會自動創建對應的規則和pool.

  • 修改ceph的配置

啟用以下參數, 然后自動以one by one的方式去更新配置文件并重啟容器. 流程與升級一樣.

ceph_conf_change_restart: "yes"

執行命令

sh manage.sh reconfigure --cluster test --image nautilus-14.2.2.0001

reconfigure和upgrade不同之處在于, reconfigure只有在配置改變時才會重啟容器, 當鏡像或容器的環境變量改變時會跳過, 不會重新創建新的容器.reconfigure不需要強制指定daemon.

清除舊的集群
#!/bin/bash
docker stop $(docker ps -a -q) && docker rm $(docker ps -a -q)
sudo rm  -rf  /etc/kolla-ceph/*

sudo docker  volume  rm  ceph_mon  ceph_mon_config kolla_ceph_logs

sudo  umount -l  /var/lib/ceph/osd/*

sudo sed -i '/\/var\/lib\/ceph\/osd/d' /etc/fstab
sudo  rm  -rf  /var/lib/ceph

systemctl daemon-reload
# disk mode
sudo sgdisk --zap-all -- /dev/sdb
sudo sgdisk --zap-all -- /dev/sdc
sudo sgdisk --zap-all -- /dev/sdd

# lvm mode
vgremove -y $(vgs | grep "ceph-" | awk '{print $1}')
pvremove /dev/sdb1 /dev/sdc1 /dev/sdd1
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。