![[PukiWiki]](image/picc.png "[PukiWiki]")
#author("2026-05-05T10:36:12+00:00","default:sysosa","sysosa") #author("2026-05-05T15:58:43+00:00","default:sysosa","sysosa") 本家様 [[https://ceph.io/>+https://ceph.io/]] オブジェクトストレージ(Ceph Object Store), ブロックストレージ(Ceph Block Device), ファイルシステム(Ceph File System)を提供するオープンソースなSoftware-Defined Storage Platform. クラスターファイルシステムです. &size(10){オブジェクトストレージ：Hadoopやamazon S3なストレージ}; &size(10){ブロックストレージ: /dev/vda, /dev/vdbとか提供します, ストレージのdb先}; &size(10){ファイルシステム: posix準拠なファイルシステム, ACLも使えます}; ここではこのうち Ceph を使ったPOSIX互換ファイルシステム CephFS を取り上げます. Cephにはバージョン名があって下記の通りになってます &size(10){ubuntuっぽい}; &size(10){[[https://docs.ceph.com/docs/master/releases/general/>+https://docs.ceph.com/docs/master/releases/general/]], [[https://docs.ceph.com/en/latest/releases/>+https://docs.ceph.com/en/latest/releases/]]}; |BGCOLOR(YELLOW):Release name|BGCOLOR(YELLOW):Initial release|BGCOLOR(YELLOW):Latest|BGCOLOR(YELLOW):End of life(26.3.11時点)|BGCOLOR(YELLOW):備考| |Tentacle|2025-11-18|20.2.0|2027-11-18(estimated)|IBM Storage Ceph 9| |Squid|2024-09-26|19.2.3|2026-09-19(estimated)|IBM Storage Ceph 8| |Reef|2023-08-07|18.2.7|2025-08-01(estimated)|IBM Storage Ceph 7| |Quincy|2022-04-19|17.2.9|2025-01-13|IBM Storage Ceph 6| |Pacific|2021-03-31|16.2.15|2024-03-04|IBM Storage Ceph 5&br;SUSE Enterprise Storage 7.1(Pacific v16.2)| |Octopus|2020-03-23|15.2.17|2022-08-09|SUSE Enterprise Storage 7(Octopus v15.2)| |Nautilus|2019-03-19|14.2.22|2021-06-30| Red Hat Ceph Storage 4| |Mimic|2018-06-01|13.2.10|2020-07-22|| |Luminous|2017-08-01|12.2.13|2020-03-01|Red Hat Ceph Storage 3| &color(red){*};&size(10){毎年メジャーバージョンアップがある}; ここでは「Tentacle」を導入します. OS上に直接アプリをインストールする方法以外に、docker/podmnan の上で構築する方法があります。後者が推奨のようでここではこの方法で構築を進めます。 各マシンに &color(crimson){Manager Daemon};, &color(magenta){Monitor Daemon};, &color(limegreen){Metadata Server Daemon};, &color(orangered){Object Storage Daemon}; らが単独で、あるいは相乗りで存在します。 っで構成はこんな感じで. |BGCOLOR(YELLOW):ホスト名|BGCOLOR(YELLOW):役目|BGCOLOR(YELLOW):IPアドレス[public network]|BGCOLOR(YELLOW):cluster network|BGCOLOR(YELLOW):OS|BGCOLOR(YELLOW):ストレージ|BGCOLOR(YELLOW):osd| |ceph-mgr |&color(crimson){Manager Daemon}; |192.168.0.47/24| |Rockylinux9.7|os(16GB) || |ceph-mon01 |&color(crimson){Manager Daemon}; &br; &color(magenta){Monitor Daemon}; |192.168.0.48/24| |~|os(16GB) &br; /var/lib/ceph(8GB) || |ceph-mon02 | &color(magenta){Monitor Daemon}; &br;&color(limegreen){Metadata Server Daemon}; |192.168.0.49/24| |~|os(16GB) &br; /var/lib/ceph(8GB) || |ceph-mon03 | &color(magenta){Monitor Daemon}; &br;&color(limegreen){Metadata Server Daemon}; |192.168.0.50/24| |~|os(16GB) &br; /var/lib/ceph(8GB) || |ceph-osd01 |&color(orangered){Object Storage Daemon}; |192.168.0.51/24| 10.10.10.51/24 |~|os(16GB) | OSD(50GB:SSD:&color(magenta){meta};)&br;OSD(50GB:HDD:&color(crimson){data};)| |ceph-osd02 |&color(orangered){Object Storage Daemon}; |192.168.0.52/24| 10.10.10.52/24 |~|os(16GB) | OSD(50GB:SSD:&color(magenta){meta};)&br;OSD(50GB:HDD:&color(crimson){data};)| |ceph-osd03 |&color(orangered){Object Storage Daemon}; |192.168.0.53/24| 10.10.10.53/24 |~|os(16GB) | osd(50GB:SSD:&color(magenta){meta};)&br;OSD(50GB:HDD:&color(crimson){data};)| [OSD] cephFSを作る際はmeta向けの高速なSSDとdata向けの大容量のHDDに分けた方がいい。ls, findがめちゃ早くなる. data向け領域はHDDのみでも構わないが、sata SSD/nvme SSDを組み合わせた bluestore機構が使える. SSD(sata,nvme)はエンタープライズ向けで電源喪失保護(PLP: Power Loss Protection)付きでよういすると幸せになれるみたい. [cluster network] &color(orangered){Object Storage Daemon};間の専用通信ネットワークです. 受け取ったデータを他のHDDへのコピー処理(レプリケーション)や障害が発生してHDDが差し替えた際にOSDノード間データ移動を表のpublic networkに影響が及ばないように裏で対処します. あとOSDノード間の死活確認も行います。データの複製やらリカバリ処理は分散ファイルシステムなので結構な通信が発生します。それを表に出させないようにしてます. &size(10){でもすっごい早い表のネットワークなら帯域的にも表だけでいいような気がしますが}; [public network] bonding構成が望ましいようで、bondingでも802.3ad. その場合は高性能なLACP対応なHUBが必要. 分散ファイルシステムなのでファイル転送速度はそのままなのでしょうが、帯域を増やせますからね. ***構築に必要なリソースとか [#b419cf5c] 各デーモンで要求されるスペック。そんなに高性能なCPUは不要. Hzよりもthreadsの数(coreの数)があればいいのかな. OSDノードのmemoryはosd(hdd)の数で決まる感じ. 4GB/1HDDが最低ランクで、12slotなマシンなら48GB+OS用メモリ. ただ耐障害のためにOSDノードの台数も考慮する必要あり. [[Ceph/memo]] ***構築方針 [#ccef5534] cephの構築は cephadm コマンドによるデプロイから始まります。この際cephadmを実行したノードは自動的に &color(crimson){Manager Daemon}; と &color(magenta){Monitor Daemon}; の機能を持つようになります なので初回構築は ceph-mon01 で作り、あとでceph-mgrを追加して管理ノードに仕立てる流れにします. ceph-mon01 -> ceph-mgr -> ceph-mgr(管理ノード化) -> ceph-mon02,ceph-mon03(monitorへ) -> ceph-osd01,ceph-osd02,ceph-osd03(osdへ) -> filesystem作成 各デーモンには必要な数がありまして、&color(crimson){Manager Daemon};は２つ(最低１つ)、&color(magenta){Monitor Daemon};は最低３つで奇数素. &color(limegreen){Metadata Server Daemon};は２つ(最低１つ) &color(orangered){Object Storage Daemon};は最低３つ. だから物理的に３台あれば一応は形はできる. cephでsmb [[Ceph/smb]] cephでnfs [[Ceph/nfs]] 常時監視と通知 [[Ceph/Prometheus]] 簡易な通知[[Ceph/alert]] 障害対応 [[Ceph/Troubleshooting]] 可視化 [[Ceph/Grafana]] ***構築開始. cephadmのインストールとデプロイ [#tc8671c3] rockylinux9.7において、提供されているcephリポジトリは #code(nonumber){{ [root@ceph-mon01 ~]# dnf search centos-release-ceph Last metadata expiration check: 0:00:21 ago on Thu 09 Apr 2026 12:37:38 AM JST. =========================================================== Name Matched: centos-release-ceph ============================================================ centos-release-ceph-pacific.noarch : Ceph Pacific packages from the CentOS Storage SIG repository centos-release-ceph-quincy.noarch : Ceph Quincy packages from the CentOS Storage SIG repository centos-release-ceph-reef.noarch : Ceph Reef packages from the CentOS Storage SIG repository centos-release-ceph-squid.noarch : Ceph Squid packages from the CentOS Storage SIG repository [root@ceph-mon01 ~]# }} と最新のTentacleは提供されていない. なので [[https://docs.ceph.com/en/latest/install/get-packages/>+https://docs.ceph.com/en/latest/install/get-packages/]] を参照して cephadm をダウンロードする. #code(nonumber){{ [root@ceph-mon01 ~]# curl --silent --remote-name --location https://download.ceph.com/rpm-tentacle/el9/noarch/cephadm [root@ceph-mon01 ~]# chmod +x cephadm [root@ceph-mon01 ~]# ./cephadm version cephadm version 20.2.1 (6a49aff47758778a5f5951e731d437c317f72fb2) tentacle (stable) [root@ceph-mon01 ~]# }} cephはpodman(or docker)のコンテナで構築されていきます. なので各物理マシンには podman と lvm2 パッケージが必要で用意出来たら cephadm でデプロイです #code(nonumber){{ [root@ceph-mon01 ~]# dnf install podman lvm2 [root@ceph-mon01 ~]# ./cephadm bootstrap --mon-ip 192.168.0.48 --cluster-network 10.10.10.0/24 --dashboard-password-noupdate --initial-dashboard-password adminpass --skip-monitoring-stack }} [--dashboard-password-noupdate] 初回デプロイが完了するとdashboardが利用可能になるが、パスワード変更が要求される. 面倒なのでこの場でパスワードを決めた [--initial-dashboard-password adminpass] これがdashboardのadminのパスワードとなる [--skip-monitoring-stack] monitoringなサービス(prometheus, grafana, alertmanager, node-exporter)の構築をskip. 使わない機能もあるので. 設定が間違った、再度作り直したい場合は、まずこのデプロイされたcephの fsid を見つける. 「/etc/ceph/ceph.conf」に書かれてます. っで #code(nonumber){{ [root@ceph-mon01 ~]# cat /etc/ceph/ceph.conf # minimal ceph.conf for 1fa24c12-3364-11f1-ac0a-bc241165abf5 [global] fsid = 1fa24c12-3364-11f1-ac0a-bc241165abf5 mon_host = [v2:192.168.0.48:3300/0,v1:192.168.0.48:6789/0] [root@ceph-mon01 ~]# ./cephadm rm-cluster --fsid 1fa24c12-3364-11f1-ac0a-bc241165abf5 --force [root@ceph-mon01 ~]# rm -rf /etc/ceph /var/lib/ceph/* }} これで初期化できます. もし&color(orangered){Object Storage Daemon}; まで進んでいたなら追加で「--zap-osds」を加えて実行すればディスクの内容も消去されます. [閑話] もしcephを構築する環境がproxy環境なら「/etc/containers/containers.conf」にproxy設定を入れる #code(nonumber){{ [engine] env = [ "HTTP_PROXY=http://proxy:3128", "HTTPS_PROXY=http://proxy:3128", "NO_PROXY=localhost,127.0.0.1,192.168.1.0/24,ceph-mgr,ceph-mon01,ceph-mon02,ceph-mon03,ceph-osd01,ceph-osd02,ceph-osd03" ] }} な感じで.[閑話休題] 次にceph関連のコマンドを入れます. #code(nonumber){{ [root@ceph-mon01 ~]# ./cephadm add-repo --release tentacle --> 「/etc/yum.repos.d/ceph.repo」 ができる [root@ceph-mon01 ~]# dnf install ceph-common }} これで「ceph」コマンドが使えるようになります. &size(10){cephリポジトリの中身詳細 [[Ceph/repository]]}; ***Manager Daemonの構築 [#x45a0e4b] 既に ceph-mon01 には&color(crimson){Manager Daemon};のpodman コンテナが立ってます. #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch ps NAME HOST PORTS STATUS REFRESHED AGE MEM USE MEM LIM VERSION IMAGE ID CONTAINER ID crash.ceph-mon01 ceph-mon01 running (8m) 8m ago 8m 7616k - 20.2.1 fb63cba66eea 852c9c9d3f75 mgr.ceph-mon01.dyhfce ceph-mon01 *:9283,8765 running (9m) 8m ago 9m 509M - 20.2.1 fb63cba66eea 8056a4503202 mon.ceph-mon01 ceph-mon01 running (9m) 8m ago 9m 29.8M 2048M 20.2.1 fb63cba66eea b7fe602b5627 [root@ceph-mon01 ~]# }} ここで素直にceph-mgrをcephに参加させると自動的にもれなく&color(crimson){Manager Daemon};と&color(magenta){Monitor Daemon};、 そしてceph-mgrに何も調整されていないストレージがあると&color(orangered){Object Storage Daemon}; も付く. はぁ〜っとため息が出るので 事前に自動登録を停止させる #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch set-unmanaged mon [root@ceph-mon01 ~]# ceph orch set-unmanaged mgr [root@ceph-mon01 ~]# ceph orch apply osd --all-available-devices --unmanaged=true [root@ceph-mon01 ~]# }} その上で「dnf install podman lvm2」が入ったceph-mgrにcephの仲間になってもらう #code(nonumber){{ (ceph-mgrでの事前措置) dnf install podman lvm2 -y ----ここまで---- [root@ceph-mon01 ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mgr [root@ceph-mon01 ~]# ceph orch host add ceph-mgr # ceph-mgrの名前解決が行かない時はipも同時に付けて実行する[ceph orch host add ceph-mgr 192.168.0.47] (確認) [root@ceph-mon01 ~]# ceph orch host ls HOST ADDR LABELS STATUS ceph-mgr 192.168.0.47 ceph-mon01 192.168.0.48 _admin 2 hosts in cluster [root@ceph-mon01 ~]# [root@ceph-mon01 ~]# ceph orch ps NAME HOST PORTS STATUS REFRESHED AGE MEM USE MEM LIM VERSION IMAGE ID CONTAINER ID crash.ceph-mgr ceph-mgr running (57s) 56s ago 57s 7633k - 20.2.1 fb63cba66eea 21c9d9cf2265 crash.ceph-mon01 ceph-mon01 running (27m) 7m ago 27m 7616k - 20.2.1 fb63cba66eea 852c9c9d3f75 mgr.ceph-mon01.dyhfce ceph-mon01 *:9283,8765 running (28m) 7m ago 28m 521M - 20.2.1 fb63cba66eea 8056a4503202 mon.ceph-mon01 ceph-mon01 running (28m) 7m ago 28m 39.8M 2048M 20.2.1 fb63cba66eea b7fe602b5627 [root@ceph-mon01 ~]# }} 「ceph orch host ls」でマシンの登録が完了して、「ceph orch ps」にてceph-mgrでcrashデーモンのみが動ている事が分かる. 「crashデーモン」はデフォで全てのcephマシンで動きます. 情報の自動収集, 管理画面への報告, 警告の発報の任を持ちます. [閑話]もし、何らかの理由で参加させたceph-mgrを取りやめにするには #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch host drain ceph-mgr # サービスの退避. そのホストで稼働しているデーモンらが他のノードに移ります(定義次第だけど) [root@ceph-mon01 ~]# ceph orch ps ceph-mgr # そのホストに残っているサービスがないか確認 [root@ceph-mon01 ~]# ceph orch host rm ceph-mgr # 残ってないなら削除 }} 削除ができたら ceph-mgr の /etc/ceph, /var/lib/ceph/ の中身も削除すれば完了[閑話休題] 次にceph-mgrにラベルを張ります.「ceph orch host ls」で見える「LABELS」の欄の事です ceph-mgrとceph-mon01は&color(crimson){Manager Daemon};のコンテナを持たせるので、mgrのラベルを張ります. managerでも構いません. 一応既に ceph-mon01 は&color(crimson){Manager Daemon};を持ってますが、ホストの定義をしておきます #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch host label add ceph-mon01 mgr [root@ceph-mon01 ~]# ceph orch host label add ceph-mgr mgr #剥がす際は「ceph orch host label rm ceph-mgr mgr」 (確認) [root@ceph-mon01 ~]# ceph orch host ls HOST ADDR LABELS STATUS ceph-mgr 192.168.0.47 mgr ceph-mon01 192.168.0.48 _admin,mgr 2 hosts in cluster [root@ceph-mon01 ~]# }} このラベルを使って&color(crimson){Manager Daemon};を追加してみます #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch ls --service_name=mgr --export > mgr.yaml # mgrの設計書を入手 [root@ceph-mon01 ~]# vi mgr.yaml service_type: mgr service_name: mgr placement: count: 2 label: mgr [root@ceph-mon01 ~]# ceph orch apply -i mgr.yaml --dry-run [root@ceph-mon01 ~]# ceph orch apply -i mgr.yaml }} これでmgrとLABELを付けたノードの内２台で&color(crimson){Manager Daemon};が動きます #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch ps NAME HOST PORTS STATUS REFRESHED AGE MEM USE MEM LIM VERSION IMAGE ID CONTAINER ID crash.ceph-mgr ceph-mgr running (18m) 46s ago 18m 7612k - 20.2.1 fb63cba66eea 0bd112ef9717 crash.ceph-mon01 ceph-mon01 running (57m) 5m ago 57m 7616k - 20.2.1 fb63cba66eea 852c9c9d3f75 mgr.ceph-mgr.gslsdh ceph-mgr *:8443,8765 running (51s) 46s ago 51s 261M - 20.2.1 fb63cba66eea 0510388a015a mgr.ceph-mon01.dyhfce ceph-mon01 *:9283,8765 running (58m) 5m ago 58m 529M - 20.2.1 fb63cba66eea 8056a4503202 mon.ceph-mon01 ceph-mon01 running (58m) 5m ago 58m 45.4M 2048M 20.2.1 fb63cba66eea b7fe602b5627 [root@ceph-mon01 ~]# }} これでceph-mgrでもdashboardが動きます. ただ、稼働していてもactiveとは限らないくて、managerは１つがactive他はstandbysと、１つのactiveが許されます. #code(nonumber){{ [root@ceph-mon01 ~]# ceph -s : mgr: ceph-mon01.dyhfce(active, since 14h), standbys: ceph-mgr.gslsdh : [root@ceph-mon01 ~]# }} ならmanagerはceph-mon01がactive、他のceph-mgrはmanagerにはなれるけどdown状態です。 ***ceph-mgrにも管理権限を渡す [#wa720d48] このままceph-mon01で作業してもいいのですが、ceph-mgrにも権限を移行して以後、ceph-mgrから操作することにします 先ほどの「LABELs」で「_admin」ラベルをceph-mgrにも付けます #code(nonumber){{ [root@ceph-mon01 ~]# ceph orch host label add ceph-mgr _admin [root@ceph-mon01 ~]# ceph orch host ls HOST ADDR LABELS STATUS ceph-mgr 192.168.0.47 mgr,_admin ceph-mon01 192.168.0.48 _admin,mgr 2 hosts in cluster [root@ceph-mon01 ~]# }} これでceph-mgrの「/etc/ceph」に「/etc/ceph/ceph.client.admin.keyring」と「/etc/ceph/ceph.conf」が用意されますが、仲間を増やすときに必要な「/etc/ceph/ceph.pub」はありません。 これは ceph-mgr ノードで「ceph cephadm get-pub-key」を実行すれば得られますが、ceph-mgrにはcephコマンドがないです。なのでceph-mon01同様にcephadmを取得してから ceph-commonを入れます #code(nonumber){{ [root@ceph-mgr ~]# curl --silent --remote-name --location https://download.ceph.com/rpm-tentacle/el9/noarch/cephadm [root@ceph-mgr ~]# chmod +x ./cephadm [root@ceph-mgr ~]# ./cephadm add-repo --release tentacle [root@ceph-mgr ~]# dnf install ceph-common [root@ceph-mgr ~]# ceph cephadm get-pub-key > /etc/ceph/ceph.pub }} ceph-mon01とceph-mgrは&color(crimson){Manager Daemon};が動きますので「_admin」ラベルはそのままにします でもceph -sではまだceph-mon01がactiveでceph-mgrがstandbysです。これを切り替えてceph-mgrをactiveにするには ceph-mon01 のmgr機能を落とすことを行います #code(nonumber){{ [root@ceph-mon01 ~]# ceph mgr fail ceph-mon01.dyhfce <-- デーモン名まで入れる }} これで ceph-mgr がactiveになります。 ***Monitor Daemonの構築 [#i22fbb0b] 基本的にはLABELを付与して設計書を読み込ませてmonをデプロイさせます. まずは追加 #code(nonumber){{ (ceph-mon02, ceph-mon03での事前措置) dnf install podman lvm2 -y ----ここまで---- [root@ceph-mgr ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mon02 [root@ceph-mgr ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-mon03 [root@ceph-mgr ~]# ceph orch host add ceph-mon02 [root@ceph-mgr ~]# ceph orch host add ceph-mon03 (確認) [root@ceph-mgr ~]# ceph orch host ls HOST ADDR LABELS STATUS ceph-mgr 192.168.0.47 mgr,_admin ceph-mon01 192.168.0.48 _admin,mgr ceph-mon02 192.168.0.49 ceph-mon03 192.168.0.50 4 hosts in cluster [root@ceph-mgr ~]# }} そしてceph-mon01、ceph-mon02そしてceph-mon03 にmonのラベルを付けます #code(nonumber){{ [root@ceph-mgr ~]# ceph orch host label add ceph-mon01 mon [root@ceph-mgr ~]# ceph orch host label add ceph-mon02 mon [root@ceph-mgr ~]# ceph orch host label add ceph-mon03 mon (確認) [root@ceph-mgr ~]# ceph orch host ls HOST ADDR LABELS STATUS ceph-mgr 192.168.0.47 mgr,_admin ceph-mon01 192.168.0.48 _admin,mgr,mon ceph-mon02 192.168.0.49 mon ceph-mon03 192.168.0.50 mon 4 hosts in cluster [root@ceph-mgr ~]# }} そしてmonの設計書を作って読み込ませます #code(nonumber){{ [root@ceph-mgr ~]# ceph orch ls --service_name=mon --export > mon.yaml [root@ceph-mgr ~]# vi mon.yaml service_type: mon service_name: mon placement: count: 3 label: mon [root@ceph-mgr ~]# ceph orch apply -i mon.yaml --dry-run [root@ceph-mgr ~]# ceph orch apply -i mon.yaml (確認) [root@ceph-mgr ~]# ceph orch ps NAME HOST PORTS STATUS REFRESHED AGE MEM USE MEM LIM VERSION IMAGE ID CONTAINER ID crash.ceph-mgr ceph-mgr running (2h) 58s ago 2h 7612k - 20.2.1 fb63cba66eea 0bd112ef9717 crash.ceph-mon01 ceph-mon01 running (3h) 4m ago 3h 7616k - 20.2.1 fb63cba66eea 852c9c9d3f75 crash.ceph-mon02 ceph-mon02 running (70m) 35s ago 70m 7638k - 20.2.1 fb63cba66eea 77d592cedcad crash.ceph-mon03 ceph-mon03 running (69m) 35s ago 69m 7633k - 20.2.1 fb63cba66eea 41036976dd33 mgr.ceph-mgr.gslsdh ceph-mgr *:8443,8765 running (2h) 58s ago 2h 496M - 20.2.1 fb63cba66eea 0510388a015a mgr.ceph-mon01.dyhfce ceph-mon01 *:9283,8765 running (3h) 4m ago 3h 543M - 20.2.1 fb63cba66eea 8056a4503202 mon.ceph-mon01 ceph-mon01 running (3h) 4m ago 3h 75.6M 2048M 20.2.1 fb63cba66eea b7fe602b5627 mon.ceph-mon02 ceph-mon02 running (42s) 35s ago 42s 30.9M 2048M 20.2.1 fb63cba66eea aed63561d365 mon.ceph-mon03 ceph-mon03 running (49s) 35s ago 49s 27.9M 2048M 20.2.1 fb63cba66eea 154b576b8891 [root@ceph-mgr ~]# }} ***Object Storage Daemon の構築 [#md719727] まずは全OSDノードを参加させます #code(nonumber){{ (ceph-osd01, ceph-osd02, ceph-osd03での事前措置) dnf install podman lvm2 -y ----ここまで---- [root@ceph-mgr ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd01 [root@ceph-mgr ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd02 [root@ceph-mgr ~]# ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-osd03 [root@ceph-mgr ~]# ceph orch host add ceph-osd01 [root@ceph-mgr ~]# ceph orch host add ceph-osd02 [root@ceph-mgr ~]# ceph orch host add ceph-osd03 }} ここら辺が難しくなる..OSDのストレージとしてHDD/SSD/nvmeデバイスは、それ単体で使う分にはいいのですが、 HDDに対してメタデータをSSDに配置したり書き込みログをnvmeに置いたりと複数のデバイスを噛まして性能向上が図れます(bluestore形式) |BGCOLOR(YELLOW):コンポーネント|BGCOLOR(YELLOW):対象|BGCOLOR(YELLOW):役割|BGCOLOR(YELLOW):設計書での名称| |BGCOLOR(YELLOW):Primary Device|HDD|実際のデータ本体を保存|data_devices| |BGCOLOR(YELLOW):DB (Metadata)|sata SSD or nvme SSD|メタデータを保持します. メタデータが溢れたらプライマリ デバイスに置かれる&br;プライマリ デバイスよりも高速なデバイスで有利になる(パフォーマンス的に)|db_devices| |BGCOLOR(YELLOW):WAL (Write-Ahead Log)|nvme SSD or sata SSD|先行書き込みログ. ジャーナルまたは先行書き込みログを別のデバイスに置ける. 10GBもあれが十分の様子|wal_devices| OSDノードの登録には設計書(yaml)ベースで行うようで、bluestore形式を持たせるならちょっと面倒な記載が必要になります &size(10){以前はストレージ単位で登録できたのですが、最新版はどうもyamlベースでの登録となっている模様}; 一応既に設計書は登録されているが、中身がcephの仲間になったらどのストレージもosd(ストレージデバイス)として登録となっているので 面倒なので冒頭で「ceph orch apply osd --all-available-devices --unmanaged=true」としてその機能を無効化した #code(nonumber){{ [root@ceph-mgr ~]# ceph orch ls NAME PORTS RUNNING REFRESHED AGE PLACEMENT crash 4/4 11s ago 13h * mgr 2/2 11s ago 13h count:2;label:mgr mon 3/3 10s ago 13h count:3;label:mon osd.all-available-devices 0 - 13h <unmanaged> <-- これ [root@ceph-mgr ~]# }} 「osd.all-available-devices」の中身は「ceph orch ls --service_name=osd.all-available-devices --export」にて確認できますが、ここでは使わないので削除してます #code(nonumber){{ [root@ceph-mgr ~]# ceph orch rm osd.all-available-devices --force [root@ceph-mgr ~]# ceph orch ls NAME PORTS RUNNING REFRESHED AGE PLACEMENT crash 7/7 8m ago 14h * mgr 2/2 8m ago 14h count:2;label:mgr mon 3/3 8m ago 13h count:3;label:mon [root@ceph-mgr ~]# }} っでOSD向けの設計書ですが、OSDノードのHDD構成(11本だったり12本だったり), SSD構成(metadata向け、bluestoreのblock.db向け)、vnme(buestoreのblock.wel向け)がOSDノード毎に違っている場合もあり得る. なのでOSDノード単位で service name を用意したいと思う っで、ceph-osd01の場合. (っと言ってもここでは全て同じストレージ構成ですが) #code(nonumber){{ [root@ceph-mgr ~]# vi osd01_custom.yaml service_type: osd service_id: osd01_custom placement: hosts: - ceph-osd01 spec: data_devices: paths: - /dev/sdb <-- 本来ここは「ls -l /dev/disk/by-id」の値を持ってきた方がいい。特にシリアル番号付きがいいみたい 「/dev/disk/by-id/ata-WDC_WUH722020BLE6L4_XXXXXXGE」とか - /dev/sdc filter_logic: AND objectstore: bluestore [root@ceph-mgr ~]# (テストで読み込ませる) [root@ceph-mgr ~]# ceph orch apply -i osd01_custom.yaml --dry-run : ################ OSDSPEC PREVIEWS ################ +---------+--------------+------------+----------+----+-----+ |SERVICE |NAME |HOST |DATA |DB |WAL | +---------+--------------+------------+----------+----+-----+ |osd |osd01_custom |ceph-osd01 |/dev/sdb |- |- | |osd |osd01_custom |ceph-osd01 |/dev/sdc |- |- | +---------+--------------+------------+----------+----+-----+ [root@ceph-mgr ~]# }} この内容でokなら #code(nonumber){{ [root@ceph-mgr ~]# ceph orch apply -i osd01_custom.yaml (暫くすると) [root@ceph-mgr ~]# ceph orch ls NAME PORTS RUNNING REFRESHED AGE PLACEMENT crash 7/7 10m ago 14h * mgr 2/2 5m ago 14h count:2;label:mgr mon 3/3 5m ago 14h count:3;label:mon osd.osd01_custom 2 13s ago 104s ceph-osd01 [root@ceph-mgr ~]# ceph orch ps NAME HOST PORTS STATUS REFRESHED AGE MEM USE MEM LIM VERSION IMAGE ID CONTAINER ID : osd.0 ceph-osd01 running (2m) 41s ago 2m 38.7M 2714M 20.2.1 fb63cba66eea a854a9d99526 osd.1 ceph-osd01 running (116s) 41s ago 116s 56.2M 2714M 20.2.1 fb63cba66eea 6e005794755c [root@ceph-mgr ~]# ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 0.09760 root default -3 0.09760 host ceph-osd01 1 hdd 0.04880 osd.1 up 1.00000 1.00000 0 ssd 0.04880 osd.0 up 1.00000 1.00000 [root@ceph-mgr ~]# ceph osd df ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS 1 hdd 0.04880 1.00000 50 GiB 26 MiB 112 KiB 4 KiB 26 MiB 50 GiB 0.05 1.00 0 up 0 ssd 0.04880 1.00000 50 GiB 26 MiB 112 KiB 6 KiB 26 MiB 50 GiB 0.05 1.00 0 up TOTAL 100 GiB 53 MiB 224 KiB 11 KiB 52 MiB 100 GiB 0.05 MIN/MAX VAR: 1.00/1.00 STDDEV: 0 [root@ceph-mgr ~]# }} って感じで登録が行える 詳しくはこちらで[[Ceph/osd]] ***ファイルシステムの作成（poolの準備） [#g89444b4] ファイルシステムを作成するには、「meta用のpool」と「data用のpool」の２つが必要です。 そのpoolの作成にはデバイス違い -HDD -SSD と冗長性の確保方法としての -replicated 同じデータを複数OSD間ノードで持ちます。何個持つかは既定で３つ。「ceph config get osd osd_pool_default_size」で定義される -erasure-coded 「データチャンク」と「パリティチャンク」に分けてOSDノード間で分散保持します。RAID5/6っぽいもの. 容量効率が高いけどパリティ計算が必須なのでreplicatedより速度は劣る. の組み合わせによるルール(CRUSH配置ルール)を作って、それでプールを作る流れになります ■meta用poolの作成 目下、「meta用のpool」は「replicated」での構築に限定されています。ファイルシステムでのlsやfindの高速化のために「SSD」で構築が望まれます. まずはSSDを使って作るmeta用poolのルールを作ります #code(nonumber){{ [root@ceph-mgr ~]# ceph osd crush rule create-replicated meta-ssd default host ssd (ceph osd crush rule create-replicated NAME ROOT FAILURE_DOMAIN CLASS) *NAME: 名称 *ROOT: CRUSH 階層のルート *FAILURE_DOMAIN: 障害ドメイン, 切り分け. host とか rack とか. *CLASS: ストレージデバイスクラス. hdd とか ssd とか. [root@ceph-mgr ~]# (確認) ceph osd crush rule ls (中身) ceph osd crush rule dump meta-ssd (削除) ceph osd crush rule rm meta-ssd }} 作ったルールでmeta用poolを作ります #code(nonumber){{ [root@ceph-mgr ~]# ceph osd pool create emfs-meta 64 64 replicated meta-ssd [root@ceph-mgr ~]# ceph osd pool application enable emfs-meta cephfs }} 数字はPGと言われるものですが、その値の定義は非常にめんどくさい. 素直にgoogleAIとかに構成と規模を伝えて教えてもらった数字を当てた方がいい. ■data用poolの作成 こちらは「replicated」あるいは「erasure-coded」のいずれかが使えますが、ここでは２つとも作成して「replicated」由来のpoolをデフォルト、「erasure-coded」由来のpoolを追加って形にします。 ファイルシステムを作る際は、どうも「replicated」で用意される必要あるようで、仮に登録して、実際には「erasure-coded」由来のpoolを使うようにします #code(nonumber){{ hddをベースにした「replicated」ルールを追加 [root@ceph-mgr ~]# ceph osd crush rule create-replicated data-hdd default host hdd (ceph osd crush rule create-replicated NAME ROOT FAILURE_DOMAIN CLASS) *NAME: 名称 *ROOT: CRUSH 階層のルート *FAILURE_DOMAIN: 障害ドメイン, 切り分け. host とか rack とか. *CLASS: ストレージデバイスクラス. hdd とか ssd とか. [root@ceph-mgr ~]# (確認) ceph osd crush rule ls (中身) ceph osd crush rule dump data-hdd (削除) ceph osd crush rule rm data-hdd }} hddをターゲットとした「erasure-coded」ルールを作ります. kの値とmの値が非常に重要でOSDノードの台数がkとmの値の合計と同じとかがいいかな. mの値はcephファイルシステムの運用でOSDノードが停止しても大丈夫な数って思えばいいかも. #code(nonumber){{ [root@ceph-mgr ~]# ceph osd erasure-code-profile set k2-m1-profile k=2 m=1 crush-failure-domain=host crush-device-class=hdd (ceph osd erasure-code-profile set NAME k m FAILURE_DOMAIN CLASS) *NAME: 名称 *k: データの分割数 *m: パリティーの数 *FAILURE_DOMAIN: 障害ドメイン, 切り分け. host とか rack とか. *CLASS: ストレージデバイスクラス. hdd とか ssd とか. [root@ceph-mgr ~]# (確認)ceph osd erasure-code-profile ls (中身) ceph osd erasure-code-profile get k2-m1-profile (削除) ceph osd erasure-code-profile rm k2-m1-profile }} っでpoolを作ります #code(nonumber){{ [root@ceph-mgr ~]# ceph osd pool create emfs-data-default 64 64 replicated data-hdd [root@ceph-mgr ~]# ceph osd pool application enable emfs-data-default cephfs [root@ceph-mgr ~]# ceph osd pool create emfs-data-ec 32 32 erasure k2-m1-profile [root@ceph-mgr ~]# ceph osd pool application enable emfs-data-ec cephfs [root@ceph-mgr ~]# ceph osd pool set emfs-data-ec allow_ec_overwrites true [root@ceph-mgr ~]# ceph osd pool set emfs-data-ec bulk true }} ***.mgr プールの rule 変更 [#o00444b7] OSDを３つ以上登録するとceph側で .mgr というpoolが自動的に用意されます。 このpoolは「replicated_rule」を使っていて、これは全デバイスを使うと定義されています。SSDのみHDDのみと定義されたpoolと整合性が取れないので .mgr poolは「replicated_rule」ではなく、SSDあるいはHDD由来のpoolを使うように変更します。これをしないとリバランスに失敗してHDDの使用量偏在が起こります. #code(nonumber){{ [root@ceph-mgr ~]# ceph osd pool get .mgr crush_rule crush_rule: replicated_rule [root@ceph-mgr ~]# ceph osd pool set .mgr crush_rule data-hdd [root@ceph-mgr ~]# ceph osd pool get .mgr crush_rule crush_rule: data-hdd [root@ceph-mgr ~]# }} ***ファイルシステムの作成 [#ge89aee9] いよいよ最終段階. 作ったpoolでファイルシステムを用意します っがその前に metadata server を用意します。 いつものようにノードにラベルを張って #code(nonumber){{ (ラベルを張って) [root@ceph-mgr ~]# ceph orch host label add ceph-mon02 mds [root@ceph-mgr ~]# ceph orch host label add ceph-mon03 mds [root@ceph-mgr ~]# ceph orch host ls HOST ADDR LABELS STATUS ceph-mgr 192.168.0.47 mgr,_admin ceph-mon01 192.168.0.48 _admin,mgr,mon ceph-mon02 192.168.0.49 mon,mds ceph-mon03 192.168.0.50 mon,mds : 7 hosts in cluster [root@ceph-mgr ~]# }} 設計書を用意します #code(nonumber){{ [root@ceph-mgr ~]# vi mds.yaml service_type: mds service_id: emfs <-- 作成するファイルシステム名を記載します placement: count: 2 label: mds [root@ceph-mgr ~]# ceph orch apply -i mds.yaml --dry-run : #################### SERVICESPEC PREVIEWS #################### +---------+----------+-----------------------+-------------+ |SERVICE |NAME |ADD_TO |REMOVE_FROM | +---------+----------+-----------------------+-------------+ |mds |mds.emfs |ceph-mon03 ceph-mon02 | | +---------+----------+-----------------------+-------------+ ################ : [root@ceph-mgr ~]# ceph orch apply -i mds.yaml [root@ceph-mgr ~]# ceph orch ps --daemon_type=mds NAME HOST PORTS STATUS REFRESHED AGE MEM USE MEM LIM VERSION IMAGE ID CONTAINER ID mds.emfs.ceph-mon02.fqwudw ceph-mon02 running (20s) 18s ago 20s 20.5M - 20.2.1 fb63cba66eea a553b27762e1 mds.emfs.ceph-mon03.vhwkrp ceph-mon03 running (22s) 18s ago 22s 17.3M - 20.2.1 fb63cba66eea a7c970d525ab [root@ceph-mgr ~]# }} metadata serverが準備出来てファイルシステムを用意します #code(nonumber){{ [root@ceph-mgr ~]# ceph osd lspools 1 .mgr 2 emfs-meta 3 emfs-data-default 4 emfs-data-ec [root@ceph-mgr ~]# [root@ceph-mgr ~]# ceph fs new emfs emfs-meta emfs-data-default # まずは replicatedなpoolのみで emfs ファイルシステムを作り [root@ceph-mgr ~]# ceph osd pool set emfs-data-default bulk true [root@ceph-mgr ~]# ceph fs ls name: emfs, metadata pool: emfs-meta, data pools: [emfs-data-default ] [root@ceph-mgr ~]# (次に ec のpoolを追加) [root@ceph-mgr ~]# ceph fs add_data_pool emfs emfs-data-ec [root@ceph-mgr ~]# ceph fs ls name: emfs, metadata pool: emfs-meta, data pools: [emfs-data-default emfs-data-ec ] <--- 2つのdata poolが見えます [root@ceph-mgr ~]# }} っでceph -sで様子をみると #code(nonumber){{ [root@ceph-mgr ~]# ceph -s cluster: id: 9ce2eb0a-355d-11f1-a713-bc241165abf5 health: HEALTH_OK services: mon: 3 daemons, quorum ceph-mon01,ceph-mon03,ceph-mon02 (age 17h) [leader: ceph-mon01] mgr: ceph-mon01.oedwwx(active, since 17h), standbys: ceph-mgr.nwgopq mds: 1/1 daemons up, 1 standby osd: 6 osds: 6 up (since 78m), 6 in (since 78m) data: volumes: 1/1 healthy pools: 4 pools, 209 pgs objects: 24 objects, 579 KiB usage: 285 MiB used, 300 GiB / 300 GiB avail pgs: 209 active+clean [root@ceph-mgr ~]# }} これで一応ファイルシステムは構築完了 あとは作ったファイルシステムに subvolumegroup/subvolume を設けてその地点をexportさせる. subvolumegroup/subvolume の場所で「replicated」なpoolか「erasure code」なpoolかを選べます。これが一番大事かな. ***subvolumegroup/subvolume [#nf3b851c] こうして提供される emfs であるが、その配下に /emfs/people とか mkdir で作るのはもったいない. cephでは、subvolumegroup/subvolume で作ったサブフォルダに対しては、個別にクォータ(容量制限),スナップショット,パフォーマンス制御(ec or replicated)を設けられる. |BGCOLOR(YELLOW):項目|BGCOLOR(YELLOW):subvolumegroup|BGCOLOR(YELLOW):subvolume|BGCOLOR(YELLOW):mkdir (通常のディレクトリ)| |役割|グルーピング|実データ領域|単なる整理（フォルダ）| |中身|subvolumeを持つ|ファイル・フォルダを持つ|ファイルやディレクトリを持つ| |クォータ|グループ単位で可能|個別に可能|一応可能| |スナップショット|基本しない|できる|基本できない（単体では不可）| |利用単位|管理者目線|ユーザ/アプリ目線|ユーザー目線（軽い用途）| |LVMに例えると|VolumeGroup|LogicalVolume|単なるmkdir| |分けるもの|project,data,backup|ユーザ領域,プロジェクト領域,長期データ|一時データ,日付ディレクトリ,軽い整理| 例えば下記のようなフォルダ構成なら #code(nonumber){{ /emfs ├ people ← subvolumegroup │ ├ userA (subvolume or mkdir) │ │ ├ documents (mkdir) │ │ ├ download (mkdir) │ │ └ picture (mkdir) │ └ userB (subvolume or mkdir) ├ project ← subvolumegroup │ ├ project001 (subvolume) <--スナップショットで世代管理が可能 │ └ project002 (subvolume) │ └ data ← subvolumegroup └ offloaddata (subvolume or mkdir) }} 作り方： #code(nonumber){{ ceph fs subvolumegroup create emfs people --pool_layout emfs-data-ec # 「--pool_layout」で 使用するpoolが適用できます ceph fs subvolumegroup create emfs project --pool_layout emfs-data-ec # 容量効率が高いECを当てたり ceph fs subvolumegroup create emfs data --pool_layout emfs-data-default # 速度が速い replicated を当てたりします [people配下] ceph fs subvolume create emfs userA --group_name people --pool_layout emfs-data-default # 親のpoolとは違うpoolを割り当てられる ceph fs subvolume create emfs userB --group_name people or mkdir userA userB # 親のpeopleのpool_layoutが適用される [project配下] ceph fs subvolume create emfs project001 --group_name project ceph fs subvolume create emfs project002 --group_name project [data配下] ceph fs subvolume create emfs offloaddata --group_name data or mkdir offloaddata }} だが、ユーザが追加されるたびにsubvolumeで作るのは面倒かな. スナップショットとか作るなら別ですが、mkdirで十分な面もある プロジェクトに関する部分は スナップショット が撮れる subvolumegroup/subvolume はいいかも. offloaddataらは、これもmkdirで十分かな でも管理面からも運用的には/emfsの配下だけは subvolumegrop でフォルダを作るのが大事みたい. subvolumegroup/subvolumeの確認 #code(nonumber){{ [root@ceph-mgr ~]# ceph fs subvolumegroup ls emfs [ { "name": "project" }, { "name": "data" }, { "name": "people" } ] [root@ceph-mgr ~]# [root@ceph-mgr ~]# ceph fs subvolume ls emfs --group_name project [ { "name": "project001" }, { "name": "project002" } ] [root@ceph-mgr ~]# }} 各subvolumegroup/subvolumeのPATHを調べます #code(nonumber){{ [root@ceph-mgr ~]# ceph fs subvolumegroup getpath emfs people /volumes/people [root@ceph-mgr ~]# ceph fs subvolumegroup getpath emfs project /volumes/project [root@ceph-mgr ~]# ceph fs subvolumegroup getpath emfs data /volumes/data [root@ceph-mgr ~]# [root@ceph-mgr ~]# ceph fs subvolume getpath emfs project001 --group_name project /volumes/project/project001/5028b9b8-2ec9-4ffb-8d83-9462866fa146 [root@ceph-mgr ~]# ceph fs subvolume getpath emfs project002 --group_name project /volumes/project/project002/8eda5a0d-7de5-44f9-a63e-cb723559fbae [root@ceph-mgr ~]# }} subvolumeになるとUUIDが入る。これだと「/volume/project」のみmountしてはダメで、autofsとかで隠ぺいして /project/project001 としてmountするように調整が必要 ***ceph client [#kbe4c9ea] 作ったcephストレージをmountしてみます. まずはcephのプログラムを入れます. レポジトリから始めます. #code(nonumber){{ [root@ceph-client ~]# cat <<_EOF_> /etc/yum.repos.d/ceph.repo [Ceph] name=Ceph $basearch baseurl=https://download.ceph.com/rpm-tentacle/el9/\$basearch enabled=1 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.gpg [Ceph-noarch] name=Ceph noarch baseurl=https://download.ceph.com/rpm-tentacle/el9/noarch enabled=1 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.gpg _EOF_ [root@ceph-client ~]# dnf install epel-release -y [root@ceph-client ~]# dnf install ceph-common -y }} そしてsubvolumegroup/subvolume単位でキーリングを作ります #code(nonumber){{ /emfs ├ people -> 「ceph fs subvolumegroup getpath emfs people」-> 「/volumes/people」のキーリングを作る │ ├ userA (mkdir) │ │ ├ documents (mkdir) │ │ ├ download (mkdir) │ │ └ picture (mkdir) │ └ userB (mkdir) ├ project ← subvolumegroup ->「ceph fs subvolumegroup getpath emfs project」-> 「/volumes/project」のキーリングを作る │ ├ project001 (subvolume) ->「ceph fs subvolumegroup getpath emfs project001 --group_name project」->/volumes/project/project001/5028b9b8-2ec9-4ffb-8d83-9462866fa146のキーリング │ └ project002 (subvolume) ->「ceph fs subvolumegroup getpath emfs project002 --group_name project」->/volumes/project/project002/8eda5a0d-7de5-44f9-a63e-cb723559fbaeのキーリング │ └ data ← subvolumegroup ->「ceph fs subvolumegroup getpath emfs data」-> /volumes/data のキーリング └ offloaddata (mkdir) }} その後にマウントする部分のキーリングを管理ノードで作ります #code(nonumber){{ [root@ceph-mgr ~]# ceph fs authorize emfs client.r9-people /volumes/people rwp <-- 読み書きのみなら「rw」でいいがクオータを含めるなら「rwp」とします. [s]ならスナップショット あるいは [root@ceph-mgr ~]# ceph auth get-or-create client.r9-people \ mon 'allow r fsname=emfs' \ mds 'allow rwps fsname=emfs path=/volumes/people' \ osd 'allow rw pool=emfs-data-ec ' [root@ceph-mgr ~]# }} 作ったキーリングは「ceph auth ls」で確認できます #code(nonumber){{ [root@ceph-mgr ~]# ceph auth get client.r9-people [client.r9-people] key = AQCMzu9p3MWhEBAAzSN9nCFRdraJGkM9sGn7VA== caps mds = "allow rwps fsname=emfs path=/volumes/people" caps mon = "allow r fsname=emfs" caps osd = "allow rw pool=emfs-data-ec" [root@ceph-mgr ~]# (削除) ceph auth del client.r9-people }} mountにはこのキーリング「ceph auth get client.r9-people」の出力を client の「/etc/ceph/ceph.client.r9-people.keyring」に貼り付けます #code(nonumber){{ [root@ceph-client ~]# cat <<_EOF_> /etc/ceph/ceph.client.r9-people.keyring [client.r9-people] key = AQCMzu9p3MWhEBAAzSN9nCFRdraJGkM9sGn7VA== caps mds = "allow rwps fsname=emfs path=/volumes/people" caps mon = "allow r fsname=emfs" caps osd = "allow rw pool=emfs-data-ec" _EOF_ [root@ceph-client ~]# }} そしてmountに最低限必要な ceph.conf を用意して #code(nonumber){{ [root@ceph-client ~]# ssh root@ceph-mgr "ceph config generate-minimal-conf" | tee /etc/ceph/ceph.conf }} っでmountを試みます #code(nonumber){{ [root@ceph-client ~]# mount -t ceph ceph-mon01:/volumes/people /home -o name=r9-people,fs=emfs あるいは [root@ceph-client ~]# mount -t ceph :/volumes/people /mnt -o name=r9-people,fs=emfs [root@ceph-client ~]# df -Tht ceph Filesystem Type Size Used Avail Use% Mounted on 192.168.0.48:/volumes/people ceph 300G 224M 300G 1% /home [root@ceph-client ~]# }} 上記は「/etc/ceph/ceph.client.r9-people.keyring」を用意する方法ですが、 keyの文字列を納めたファイルでもいいみたい #code(nonumber){{ [root@ceph-client ~]# cat r9.secret AQCMzu9p3MWhEBAAzSN9nCFRdraJGkM9sGn7VA== [root@ceph-client ~]# [root@ceph-client ~]# mount -t ceph ceph-mon01:/volumes/people /home -o name=r9-people,secretfile=/etc/ceph/r9.secret,fs=emfs }} とsecretfileと渡してもいい。 ただ、 &color(red){2026-04-28T07:19:29.044+0900 7f6473f9c100 -1 auth: unable to find a keyring on /etc/ceph/ceph.client.r9-people.keyring,/etc/ceph/ceph.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin: (2) No such file or directory}; とメッセージが出ます. 先ほどのフォルダ構成でsubvolumegroupの中にsubvolumeが複数ある場合 「/emfs/project/project001」->「/volumes/project/project001/5028b9b8-2ec9-4ffb-8d83-9462866fa146」 「/emfs/project/project002」->「/volumes/project/project002/8eda5a0d-7de5-44f9-a63e-cb723559fbae」 とかの場合です。 この場合はsubvolumegroupの「/emfs/project」部分のキーリングを用意して、それで子供のproject001とproject002をmountできるみたい. 「project001」「project002」と分けて管理、アクセスさせないとかあるなら、子供の所でキーリングを作ってmountさせる. まずは/emfs/project部分のキーリング #code(nonumber){{ [root@ceph-mgr ~]# ceph auth get-or-create client.r9-project \ mon 'allow r fsname=emfs' \ mds 'allow rwps fsname=emfs path=/volumes/project' \ osd 'allow rw pool=emfs-data-ec' [root@ceph-mgr ~]# ceph auth get client.r9-project [client.r9-project] key = AQAs5O9pm3zzNhAAD6gMtRF1IewYgD8rOhjMAQ== caps mds = "allow rwps fsname=emfs path=/volumes/project" caps mon = "allow r fsname=emfs" caps osd = "allow rw pool=emfs-data-ec" [root@ceph-mgr ~]# }} そしてclient側では #code(nonumber){{ [root@ceph-client ~]# echo "AQAs5O9pm3zzNhAAD6gMtRF1IewYgD8rOhjMAQ==" > /etc/ceph/project.secret [root@ceph-client ~]# vi /etc/fstab : : # project001 のマウント ceph-mon01:/volumes/project/project001/5028b9b8-2ec9-4ffb-8d83-9462866fa146 /project/project001 ceph defaults,name=r9-project,secretfile=/etc/ceph/project.secret,fs=emfs,_netdev 0 0 # project002 のマウント ceph-mon01:/volumes/project/project002/8eda5a0d-7de5-44f9-a63e-cb723559fbae /project/project002 ceph defaults,name=r9-project,secretfile=/etc/ceph/project.secret,fs=emfs,_netdev 0 0 [root@ceph-client ~]# [root@ceph-client ~]# mkdir -p /project/{project001,project002} [root@ceph-client ~]# systemctl daemon-reload [root@ceph-client ~]# mount -a }} でmountできます。 autofsでmountなら #code(nonumber){{ [direct map] [root@ceph-client ~]# cat /etc/auto.master /project /etc/auto.home --timeout=60 [root@ceph-client ~]# cat /etc/auto.home # [キー] -fstype=ceph,[オプション] [デバイスパス] project001 -fstype=ceph,name=r9-project,secretfile=/etc/ceph/project.secret,fs=emfs ceph-mon01:/volumes/project/project001/5028b9b8-2ec9-4ffb-8d83-9462866fa146 project002 -fstype=ceph,name=r9-project,secretfile=/etc/ceph/project.secret,fs=emfs ceph-mon01:/volumes/project/project002/8eda5a0d-7de5-44f9-a63e-cb723559fbae [root@ceph-client ~]# }} そして #code(nonumber){{ [root@ceph-client ~]# systemctl enable autofs --now }} と実行する ***cephのshutdown/startup [#dd4fb094] ■shutdown 手順 #code(nonumber){{ [全てのcephクライアントからcephマウントを外す] (ceph fs set emfs max_mds 1) # 複数でmdsが動いているなら. ceph -sで「mds: 1/1 daemons up, 1 standby」ならこれは不要 ceph fs set emfs down true # mdsを正常にシャットダウン状態にする ceph fs set emfs joinable false # mdsの自動起動の停止 ceph fs fail emfs # 現在のMDSを確実に落とす ceph osd set noout ceph osd set norebalance ceph osd set nobackfill ceph osd set norecover ceph osd set noautoscale }} 厳密には「まずルール（joinable false）を決めてから、動作（down true）を止める」 という手順は、 予期せぬ自動昇格を防ぐ意味で非常に安全なアプローチなのですが、まぁ最終的には同じ #code(nonumber){{ ceph fs set emfs joinable false （まず「新しいMDSは参加させない」というルールを敷く） ceph fs set emfs down true （稼働中のMDSを正常終了プロセスに移行させる） ceph fs fail emfs （念のため、完全に停止したことを確定させる） }} そして ■start-up 手順 #code(nonumber){{ monを起動して、クォーラムを成立させる mgrを起動 osdを起動 }} ceph osd stat で全てのosd(hdd/ssd)の起動を確認して、「up」になっているかを確認 ceph -s でHEALTH_OK でありフラグの警告のみであることを確認. active+clean になるのを待つ もし「active+recovering+degraded」でずっと止まっているなら 先行して ceph osd unset norecover ceph osd unset nobackfill を実施します。これですてのpgsが「active+clean」なにのを確認する その後に #code(nonumber){{ ceph osd unset noout ceph osd unset norebalance ceph osd unset nobackfill ceph osd unset norecover ceph osd unset noautoscale ceph fs set emfs joinable true ceph fs set emfs down false }} mdsがactiveであることを確認 ceph mountを実行して完了 あと「ceph health detail」で問題を確認して、もしosd daemonの問題なら その問題のosdに対してコンテナを再生成させます。これはOSD内のデータには影響を与えません ceph orch daemon redeploy osd.4 ceph orch daemon redeploy osd.5
