管理ガイド - suse enterprise storage 5€¦ · 7.4 プールのスナップショット 82...

管理ガイド

SUSE Enterprise Storage 5

管理ガイドSUSE Enterprise Storage 5著者: Tomáš Bažant、Jana Haláčková、Sven Seeberg

発行日: 03/09/2020

SUSE LLC

1800 South Novell Place

Provo, UT 84606

USA

https://documentation.suse.com

著作権 © 2020 SUSE LLC

Copyright © 2016, RedHat, Inc, and contributors.

本ドキュメントのテキストと図はCreative Commons Attribution-Share Alike 4.0 International (「CC-BY-

SA」)に従ってライセンスされています。CC-BY-SAの説明については、http://creativecommons.org/licenses/

by-sa/4.0/legalcode で参照できます。CC-BY-SAに従い、本ドキュメントまたはその翻案を配布する場合は、

オリジナルバージョンのURLを明記する必要があります。

Red Hat、Red Hat Enterprise Linux、Shadowmanロゴ、JBoss、MetaMatrix、Fedora、Infinityロゴ、および

RHCEは、米国ならびに他の国で登録済みのRed Hat, Inc.の商標です。Linux®は、Linus Torvaldsの米国な

らびに他の国における登録商標です。Java®は、Oracleまたはその関連会社、あるいはその両方の登録商標で

す。XFS®は、Silicon Graphics International Corp.またはその子会社の米国または他の国、あるいはその両

方における商標です。MySQL®は、MySQL ABの米国、欧州連合、および他の国における登録商標です。その他

すべての商標は、それぞれの所有者の所有物です。

SUSEの商標については、http://www.suse.com/company/legal/ を参照してください。その他の製品名およ

び会社名は、各社の商標または登録商標です。商標記号(®、#など)は、SUSEおよび関連会社の商標を示します。

アスタリスク(*)は、第三者の商標を示します。

https://documentation.suse.com

http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://creativecommons.org/licenses/by-sa/4.0/legalcode

http://www.suse.com/company/legal/

本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証す

るものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任

を負いかねます。

目次

このガイドについて xiv

I クラスタ管理 1

1 Saltクラスタの管理 21.1 新しいクラスタノードの追加 2

1.2 ノードへの新しい役割の追加 3

1.3 クラスタノードの削除と再インストール 4

1.4 Monitorノードの再展開 6

1.5 ノードへのOSDの追加 7

1.6 OSDの削除 8

壊れたOSDの強制削除 8

1.7 再インストールしたOSDノードの回復 9

1.8 Saltを使用したインストールの自動化 10

1.9 クラスタノードの更新 10

1.10 クラスタの停止または再起動 12

1.11 カスタムのceph.confファイル 13

デフォルト値の上書き 14 • 設定ファイルのインクルード 14

1.12 Cephランタイム設定 15

iv 管理ガイド

II クラスタの運用 16

2 はじめに 17

3 Cephのサービスの操作 18

3.1 systemdを使用したCephのサービスの操作 18

ターゲットを使用したサービスの起動、停止、および再起動 18 • 個々のサービス

の起動、停止、および再起動 18 • 個々のサービスの識別 19 • サービスの

状態 19

3.2 DeepSeaを使用したCephのサービスの再起動 19

すべてのサービスの再起動 20 • 特定のサービスの再起動 20

4 クラスタの状態の判断 22

4.1 クラスタのヘルスの確認 22

4.2 クラスタの監視 30

4.3 クラスタの使用量統計の確認 32

4.4 クラスタの状態の確認 33

4.5 OSDの状態の確認 34

4.6 満杯のOSDの確認 34

4.7 Monitorの状態の確認 35

4.8 配置グループの状態の確認 36

4.9 管理ソケットの使用 36

5 cephxを使用した認証 38

5.1 認証アーキテクチャ 38

5.2 キー管理 41

予備知識 41 • ユーザの管理 44 • キーリングの管理 48 • コマンドラ

インの使用法 50

6 保存データの管理 52

6.1 デバイス 53

v 管理ガイド

6.2 バケット 53

6.3 ルールセット 56

ノードツリー全体の反復処理 58 • firstnとindep 60

6.4 CRUSHマップの操作 61

CRUSHマップの編集 61 • OSDの追加/移動 62 • OSDのCRUSHの重

みの調整 63 • OSDの削除 63 • バケットの移動 63

6.5 スクラブ 64

6.6 同一ノードでのSSDとHDDの混在 65

7 ストレージプールの管理 68

7.1 プールとアプリケーションの関連付け 68

7.2 プールの操作 69

プールの一覧 69 • プールの作成 69 • プールクォータの設

定 71 • プールの削除 71 • プールの名前変更 72 • プール統計の

表示 72 • プールの値の設定 73 • プールの値の取得 76 • オブジェ

クトレプリカの数の設定 76 • オブジェクトレプリカの数の取得 77 • 配置グ

ループの数の増加 78 • プールの追加 78

7.3 プールのマイグレーション 79

キャッシュ層を使用した移行 79

7.4 プールのスナップショット 81

プールのスナップショットの作成 81 • プールのスナップショットの削除 81

7.5 データ圧縮 82

圧縮の有効化 82 • プール圧縮オプション 82 • グローバル圧縮オプショ

ン 83

8 RADOS Block Device 85

8.1 Block Deviceのコマンド 85

Block Deviceイメージの作成 85 • イレージャコーディングプールでのBlock

Deviceイメージの作成 86 • Block Deviceイメージの一覧 87 • イメー

ジ情報の取得 87 • Block Deviceイメージのサイズの変更 87 • Block

Deviceイメージの削除 87

8.2 RBDイメージのマウントとアンマウント 88

vi 管理ガイド

8.3 Block Deviceのスナップショット 90

Cephxに関する注意事項 90 • スナップショットの基本 90 • 階層

化 93

8.4 rbdmap: ブート時のRBDデバイスのマップ 96

8.5 RADOS Block Deviceのミラーリング 97

rbd-mirrorデーモン 98 • プールの設定 98 • イメージ設定 100 • ミ

ラーの状態 103

9 イレージャコーディングプール 104

9.1 サンプルのイレージャコーディングプールの作成 104

9.2 イレージャコードプロファイル 105

9.3 イレージャコーディングプールとキャッシュ階層化 107

9.4 イレージャコーディングプールとRADOS Block Device 108

10 キャッシュ階層化 109

10.1 階層化ストレージの用語 109

10.2 考慮すべきポイント 109

10.3 キャッシュ階層化を使用する状況 110

10.4 キャッシュモード 110

10.5 ヒットセット 111

概要 111 • 例 113

10.6 サンプル階層化ストレージの設定 113

キャッシュ層の設定 116

III クラスタデータへのアクセス 120

11 Ceph Object Gateway 12111.1 Object Gatewayの制約と命名の制限 121

バケットの制限 121 • 保存オブジェクトの制限 121 • HTTPヘッダの制

限 122

11.2 Object Gatewayの展開 122

vii 管理ガイド

11.3 Object Gatewayサービスの操作 122

11.4 設定パラメータ 123

追加の注意事項 123

11.5 Object Gatewayのアクセスの管理 123

Object Gatewayへのアクセス 124 • S3およびSwiftアカウントの管理 126

11.6 Object GatewayでのHTTPS/SSLの有効化 129

自己署名証明書の作成 130 • 簡単なHTTPS設定 130 • 高度なHTTPS設

定 131

11.7 同期モジュール 131

ゾーンの同期 132 • Elasticsearchでのメタデータの保存 133

11.8 LDAP認証 136

認証メカニズム 136 • 要件 136 • LDAP認証を使用するためのObject

Gatewayの設定 137 • カスタム検索フィルタを使用したユーザアクセスの制

限 138 • LDAP認証用アクセストークンの生成 139

11.9 バケットインデックスのシャーディング 139

バケットインデックスのリシャーディング 139 • 新しいバケットのバケットインデック

スシャーディング 142

11.10 OpenStack Keystoneの統合 144

OpenStackの設定 144 • Ceph Object Gatewayの設定 145

11.11 マルチサイトObject Gateway 147

用語集 148 • クラスタセットアップの例 148 • システムキー 148 • 命名

規則 149 • デフォルトプール 149 • レルムの作成 150 • デフォルトの

ゾーングループの削除 150 • マスタゾーングループの作成 150 • マスタゾー

ンの作成 151 • セカンダリゾーンの作成 154 • 2つ目のクラスタへのObject

Gatewayの追加 157 • フェールオーバーと障害復旧 161

11.12 HAProxyによるObject Gatewayサーバの負荷分散 163

12 Ceph iSCSI Gateway 164

12.1 lrbd管理対象ターゲットへの接続 164

Linux (open-iscsi) 164 • Microsoft Windows (Microsoft iSCSIイニシエー

ター) 167 • VMware 175

12.2 結論 180

viii 管理ガイド

13 クラスタ化ファイルシステム 181

13.1 CephFSのマウント 181

クライアントの準備 181 • シークレットファイル 181 • CephFSのマウン

ト 182

13.2 CephFSのアンマウント 183

13.3 /etc/fstabでのCephFSの指定 183

13.4 複数のアクティブMDSデーモン(アクティブ-アクティブMDS) 184

アクティブ-アクティブMDSを使用する状況 184 • MDSのアクティブクラスタサイ

ズの増加 184 • ランク数の減少 185 • ランクへのディレクトリツリーの手動

固定 186

13.5 フェールオーバーの管理 187

スタンバイデーモンの設定 187 • 例 188

14 NFS Ganesha: NFS経由でのCephデータのエクスポート 189

14.1 インストール 189

14.2 設定 189

Exportセクション 190 • RGWセクション 191 • NFS Ganeshaのデフォルト

ポートの変更 192

14.3 NFS Ganeshaのカスタムの役割 192

NFS Ganesha用の異なるObject Gatewayユーザ 192 • CephFSとObject

GatewayのFSALの分離 194

14.4 NFS Ganeshaの起動または再起動 195

14.5 ログレベルの設定 196

14.6 エクスポートされたNFS共有の検証 196

14.7 エクスポートされたNFS共有のマウント 196

14.8 その他の資料 196

ix 管理ガイド

IV GUIツールを使用したクラスタの管理 197

15 openATTIC 19815.1 openATTICの展開と設定 198

SSLを使用したopenATTICへの安全なアクセスの有効化 198 • openATTIC

の展開 199 • openATTICの初期セットアップ 199 • openATTICでの

DeepSea統合 200 • Object Gateway管理 200 • iSCSI Gateway管

理 201

15.2 openATTIC Webユーザインタフェース 201

15.3 ダッシュボード 202

15.4 Ceph関連タスク 204

Web UIの共通機能 204 • OSDノードの一覧 205 • RADOS RBD

(RADOS Block Device)の管理 205 • プールの管理 208 • ノードの一

覧 210 • NFS Ganeshaの管理 211 • iSCSI Gatewayの管理 215 • ク

ラスタのCRUSHマップの表示 218 • Object Gatewayのユーザとバケットの管

理 219

V 仮想化ツールとの統合 226

16 Cephでのlibvirtの使用 22716.1 Cephの設定 227

16.2 VMマネージャの準備 228

16.3 VMの作成 229

16.4 VMの設定 229

16.5 概要 231

17 QEMU KVMインスタンスのバックエンドとしてのCephの使用 233

17.1 インストール 233

17.2 使用法 233

17.3 QEMUでのイメージの作成 234

17.4 QEMUでのイメージのサイズ変更 234

x 管理ガイド

17.5 QEMUでのイメージ情報の取得 234

17.6 RBDでのQEMUの実行 235

17.7 Discard/TRIMの有効化 235

17.8 QEMUのキャッシュオプション 236

VI FAQ (よくある質問と答え)、ヒント、およびトラブルシューティング 237

18 ヒント 23818.1 スクラブの調整 238

18.2 リバランスなしでのOSDの停止 238

18.3 ノードの時刻同期 239

18.4 不均衡なデータ書き込みの確認 241

18.5 /var/lib/cephのBtrfsサブボリューム 241

新規インストールの要件 242 • 既存のインストールの要件 242 • 自動セット

アップ 242 • 手動セットアップ 243

18.6 ファイル記述子の増加 244

18.7 OSDジャーナルを含むOSDに既存のパーティションを使用する方法 244

18.8 仮想化ソフトウェアとの統合 245

CephクラスタへのKVMディスクの保存 245 • Cephクラスタへのlibvirtディス

クの保存 245 • CephクラスタへのXenディスクの保存 246

18.9 Cephのファイアウォール設定 247

18.10 ネットワークパフォーマンスのテスト 248

18.11 ストレージディスクの交換 249

19 FAQ (よくある質問と答え) 250

19.1 配置グループの数はクラスタのパフォーマンスにどのように影響しますか? 250

19.2 同じクラスタでSSDとハードディスクを使用できますか? 250

xi 管理ガイド

19.3 ジャーナルをSSDで使用することにはどのようなトレードオフがありますか? 251

19.4 ディスクに障害が発生すると、どうなりますか? 251

19.5 ジャーナルディスクに障害が発生すると、どうなりますか? 252

20 トラブルシューティング 253

20.1 ソフトウェアの問題のレポート 253

20.2 満杯のOSDにおいてradosを使用した大容量オブジェクトの送信に失敗する 253

20.3 XFSファイルシステムの破損 254

20.4 状態メッセージ「Too Many PGs per OSD」 254

20.5 状態メッセージ「nn pg stuck inactive」 255

20.6 OSDの重みが0 255

20.7 OSDがダウンしている 256

20.8 低速なOSDの特定 256

20.9 クロックスキュー警告の修復 257

20.10 ネットワークの問題によるクラスタの低パフォーマンス 257

20.11 /varの領域不足 259

用語集 261

A Cephの手動インストールの手順例 263

B マニュアルの更新 266

B.1 2018年9月(SUSE Enterprise Storage 5.5のリリース) 266

B.2 2017年11月(マニュアル保守更新) 268

B.3 2017年10月(SUSE Enterprise Storage 5のリリース) 269

B.4 2017年2月(SUSE Enterprise Storage 4 Maintenance Update 1のリリース) 274

xii 管理ガイド



B.7 2016年1月(SUSE Enterprise Storage 2.1のリリース) 278


xiii 管理ガイド

このガイドについて

SUSE Enterprise StorageはSUSE Linux Enterpriseの拡張機能です。Ceph (http://

ceph.com/ )ストレージプロジェクトの機能に、SUSEのエンタープライズエンジニアリングとサポー

トが組み合わされています。SUSE Enterprise Storageにより、IT組織は、コモディティハードウェアプ

ラットフォームを使用して多様な使用事例に対応できる分散ストレージアーキテクチャを展開できます。

このガイドは、主にCephインフラストラクチャの管理に焦点を当てており、読者がSUSE Enterprise

Storageの概念を理解するのに役立ちます。さらに、CephをOpenStack、KVMなどの他の関連ソ

リューションと共に使用する方法についても実例を交えて説明します。

このマニュアル中の多くの章に、他の資料やリソースへのリンクが記載されています。それらは、システ

ム上で参照できる追加ドキュメントやインターネットから入手できるドキュメントなどです。

ご使用製品の利用可能なマニュアルと最新のドキュメントアップデートの概要については、http://

www.suse.com/documentation を参照してください。

1 利用可能なマニュアルこの製品の次のマニュアルを入手できます。

管理ガイド

このガイドは、一般的にインストール後に実行するさまざまな管理タスクについて説明します。さら

に、Cephを libvirt 、Xen、KVMなどの仮想化ソリューションと統合する手順や、クラスタに保

存されているオブジェクトにiSCSIやRADOSゲートウェイ経由でアクセスする方法についても紹

介します。

『導入ガイド』

Cephクラスタと、すべてのCeph関連サービスのインストール手順を、順を追って説明します。さ

らに、Cephクラスタの基本構造と、関連する用語についても説明します。

これらの製品マニュアルのHTMLバージョンは、インストールしたシステムの /usr/share/doc/

manualにあります。マニュアルの最新の更新版はhttp://www.suse.com/documentation に掲

載されており、ここからご使用の製品のマニュアルを複数のフォーマットでダウンロードできます。

2 フィードバック次のフィードバックチャネルがあります。

xiv 利用可能なマニュアル SES 5

http://ceph.com/

http://ceph.com/

http://www.suse.com/documentation



バグと機能拡張の要求

ご使用の製品に利用できるサービスとサポートのオプションについては、http://

www.suse.com/support/ を参照してください。

製品コンポーネントのバグを報告するには、http://www.suse.com/support/ からNovell

Customer Centerにログインし、［マイサポート］［サービス要求］の順に選択します。

ユーザからのコメント

本マニュアルおよびこの製品に含まれているその他のマニュアルについて、皆様のご意見やご要

望をお寄せください。オンラインドキュメントの各ページの下にあるユーザコメント機能を使用する

か、またはhttp://www.suse.com/documentation/feedback.html にアクセスして、コメント

を入力してください。

メール

この製品のドキュメントについてのフィードバックは、 [email protected]宛のメールでも送信で

きます。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を明記してくださ

い。エラーの報告または機能拡張の提案では、問題について簡潔に説明し、対応するセクション

番号とページ(またはURL)をお知らせください。

3 マニュアルの表記規則本書では、次の書体を使用しています。

/etc/passwd : ディレクトリ名とファイル名

placeholder : placeholderは、実際の値で置き換えられます

PATH :環境変数PATH

ls 、 --help :コマンド、オプション、およびパラメータ

user :ユーザまたはグループ

Alt 、 Alt – F1 :使用するキーまたはキーの組み合わせ、キーはキーボード上と同様、大文字で

表示される

［ファイル］、［ファイル］［名前を付けて保存］: メニュー項目、ボタン

Dancing Penguins (「Penguins」の章、↑他のマニュアル):他のマニュアルの章への参照で

す。

xv マニュアルの表記規則 SES 5

http://www.suse.com/support/



http://www.suse.com/documentation/feedback.html

4 本マニュアルの作成について本書は、DocBook(http://www.docbook.org を参照)のサブセットであるGeekoDocで作成され

ています。XMLソースファイルは xmllintによって検証され、 xsltprocによって処理され、Norman

Walshによるスタイルシートのカスタマイズ版を使用してXSL-FOに変換されました。最終的なPDF

は、ApacheのFOPまたはRenderXのXEPでフォーマットされている可能性があります。本書の生成

に使用されたオーサリングおよび発行ツールは、 dapsパッケージで利用可能です。DocBook DAPS

(Authoring and Publishing Suite)はオープンソースソフトウェアとして開発されています。詳細につ

いては、http://daps.sf.net/ を参照してください。

5 Ceph 貢献者Ceph プロジェクトと関連するドキュメントは、何百人もの貢献者と組織の成果です。詳細は https://

ceph.com/contributors/ を参照してください。

xvi 本マニュアルの作成について SES 5

http://www.docbook.org

http://daps.sf.net/

https://ceph.com/contributors/

https://ceph.com/contributors/

I クラスタ管理

1 Saltクラスタの管理 2

1 Saltクラスタの管理

Cephクラスタの展開後、いくつか変更を行わなければならない場合があります。新しいノード、ディス

ク、またはサービスの追加や削除などです。この章では、これらの管理タスクを実行する方法について

説明します。

1.1 新しいクラスタノードの追加クラスタに新しいノードを追加する手順は、『導入ガイド』、第4章「DeepSea/Saltを使用した展開」で

説明されているクラスタノードの初期展開手順とほぼ同じです。

1. SUSE Linux Enterprise Server 12 SP3を新しいノードにインストールし、Salt Masterのホ

スト名が正しく解決されるようにネットワークを設定してから、 salt-minionパッケージをインス

トールします。

root@minion > zypper in salt-minion

Salt Masterのホスト名が saltと異なる場合は、 /etc/salt/minionを編集して次の内容を

追加します。

master: DNS_name_of_your_salt_master

上で説明した設定ファイルを変更した場合は、 salt.minionサービスを再起動します。

root@minion > systemctl restart salt-minion.service

2. Salt Master上のすべてのSaltキーを受諾します。

root@master # salt-key --accept-all

3. /srv/pillar/ceph/deepsea_minions.slsで新しいSalt Minionもターゲットに設定され

ていることを確認します。詳細については、『導入ガイド』、第4章「DeepSea/Saltを使用した展

開」、4.3項「クラスタの展開」、展開ステージの実行の『導入ガイド』、第4章「DeepSea/Saltを

使用した展開」、4.2.2.1項「ミニオン名の一致」を参照してください。

4. 準備ステージを実行します。モジュールとグレインが同期され、新しいMinionがDeepSeaに必

要なすべての情報を提供できるようになります。

root@master # salt-run state.orch ceph.stage.0

2 新しいクラスタノードの追加 SES 5

5. ディスカバリステージを実行します。 /srv/pillar/ceph/proposalsディレクトリに新しいファ

イルエントリが書き込まれます。このディレクトリで、関連する.ymlファイルを編集できます。


6. オプションで、新しく追加したホストが既存の命名スキームに一致しない場合は、 /srv/

pillar/ceph/proposals/policy.cfgを変更します。詳細については、『導入ガイド』、第4章

「DeepSea/Saltを使用した展開」、4.5.1項「policy.cfgファイル」を参照してください。

7. 設定ステージを実行します。 /srv/pillar/cephにあるすべてのファイルが読み込まれ、それに

従ってPillarが更新されます。


Pillarに保存されているデータには次のコマンドでアクセスできます。

root@master # salt target pillar.items

8. 設定および展開のステージで、新しく追加したノードを組み込みます。

root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

1.2 ノードへの新しい役割の追加DeepSeaを使用して、サポートされているすべてのタイプの役割を展開できます。サポートされている

役割のタイプの詳細と、それらに合う例については、『導入ガイド』、第4章「DeepSea/Saltを使用した

展開」、4.5.1.2項「役割割り当て」を参照してください。

ヒント: 必須およびオプションの役割とステージ一般的に、クラスタノードに新しい役割を追加する場合、0〜5のすべての展開ステージを実行す

ることをお勧めします。時間を若干節約するには、展開予定の役割のタイプに応じてステージ3

〜4をスキップできます。OSDおよびMONの役割にはコアサービスが含まれるためCephで必

要ですが、Object Gatewayなどその他の役割はオプションです。DeepSeaの展開ステージは

階層状になっており、ステージ3はコアサービスを展開し、ステージ4はオプションのサービスを

展開します。

したがって、既存のOSDノードにMONなどのコアの役割を展開する場合は、ステージ3を実行

する必要があり、ステージ4はスキップできます。

3 ノードへの新しい役割の追加 SES 5

同様に、Object Gatewayなどのオプションのサービスを展開する場合、ステージ3はスキップ

できますが、ステージ4は実行する必要があります。

既存のノードに新しいサービスを追加するには、次の手順に従います。

1. 既存のホストが新しい役割に一致するように、 /srv/pillar/ceph/proposals/

policy.cfgを変更します。詳細については、『導入ガイド』、第4章「DeepSea/Saltを使用し

た展開」、4.5.1項「policy.cfgファイル」を参照してください。たとえば、MONノードでObject

Gatewayを実行する必要がある場合、次のような行になります。

role-rgw/xx/x/example.mon-1.sls

2. ステージ2を実行してPillarを更新します。


3. ステージ3を実行してコアサービスを展開するか、ステージ4を実行してオプションのサービスを

展開します。両方のステージを実行しても問題はありません。

ヒント既存のクラスタにOSDを追加すると、後でしばらくの時間、クラスタがリバランスを実行すること

に注意してください。リバランス期間を最小限に抑えるには、追加予定のOSDをすべて同時に追

加することをお勧めします。

1.3 クラスタノードの削除と再インストールクラスタから役割を削除するには、 /srv/pillar/ceph/proposals/policy.cfgを編集して、対応

する行を削除します。その後、『導入ガイド』、第4章「DeepSea/Saltを使用した展開」、4.3項「クラスタ

の展開」の説明に従ってステージ2と5を実行します。

注記: クラスタからのOSDの削除クラスタから特定のOSDノードを削除する必要がある場合、削除予定のディスクよりも多くの

ディスク領域がクラスタにあることを確認してください。OSDを削除すると、クラスタ全体のリバ

ランスが発生することに注意してください。

4 クラスタノードの削除と再インストール SES 5

Minionから役割を削除する場合、その役割に関連する変更をすべて元に戻すことが目的です。ほとん

どの役割では、これは簡単なタスクですが、パッケージ依存関係の問題が発生する可能性があります。

パッケージをアンインストールしても、その依存関係は削除されません。

削除されたOSDは空のドライブとして表示されます。関連するタスクによってファイルシステムの先頭

が上書きされ、パーティションテーブルが消去されるほか、バックアップパーティションも削除されます。

注記: 他の方法で作成されたパーティションの維持以前に他の方法( ceph-deployなど)で設定されたディスクドライブには、引き続きパーティショ

ンが含まれています。DeepSeaはこれらを自動的には破棄しません。管理者がこれらのドライブ

を解放する必要があります。

例 1.1: クラスタからのSALT MINIONの削除

ストレージMinionに「data1.ceph」「data2.ceph」...「data6.ceph」のように名前が付けられて

いる場合、 policy.cfgの関連する行は次のようになります。

[...]# Hardware Profileprofile-default/cluster/data*.slsprofile-default/stack/default/ceph/minions/data*.yml[...]

この場合にSalt Minion「data2.ceph」を削除するには、これらの行を次のように変更します。

[...]# Hardware Profileprofile-default/cluster/data[1,3-6]*.slsprofile-default/stack/default/ceph/minions/data[1,3-6]*.yml[...]

その後、ステージ2と5を実行します。


例 1.2: ノードの移行

次のような状況を想定します。クラスタの新規インストール中に、ゲートウェイ用のハードウェアが

到着するまでの間、管理者がストレージノードの1つをスタンドアロンのObject Gatewayとして

割り当てました。ゲートウェイ用の常設ハードウェアが到着したので、ようやく目的の役割をバック

アップストレージノードに割り当てて、ゲートウェイの役割を削除できます。

5 クラスタノードの削除と再インストール SES 5

新しいハードウェアに対してステージ0と1 (『導入ガイド』、第4章「DeepSea/Saltを使用した展

開」、4.3項「クラスタの展開」、展開ステージの実行を参照)を実行した後、この新しいゲートウェ

イに rgw1という名前を付けました。ノード data8でObject Gatewayの役割を削除し、ストレー

ジの役割を追加する必要があります。現在の policy.cfgは次のようになっています。

# Hardware Profileprofile-default/cluster/data[1-7]*.slsprofile-default/stack/default/ceph/minions/data[1-7]*.sls

# Rolesrole-rgw/cluster/data8*.sls

これを次のように変更します。

# Hardware Profileprofile-default/cluster/data[1-8]*.slsprofile-default/stack/default/ceph/minions/data[1-8]*.sls

# Rolesrole-rgw/cluster/rgw1*.sls

ステージ2〜5を実行します。ステージ3で data8をストレージノードとして追加します。しばらくの

間、 data8は両方の役割を持ちます。ステージ4で rgw1にObject Gatewayの役割を追加し、

ステージ5で data8からObject Gatewayの役割を削除します。

1.4 Monitorノードの再展開1つ以上のMonitorノードに障害が発生し、応答していない場合、障害が発生したMonitorをクラスタ

から削除してから、可能であればクラスタに再度追加する必要があります。

重要: 3つのMonitorノードが最小Monitorノードの数を3つ未満にすることはできません。1つのMonitorに障害が発生し、その結

果クラスタのMonitorノードの数が1つまたは2つのみになった場合、障害が発生したMonitor

ノードを再展開する前に、そのMonitorノードを一時的に他のMonitorノードに割り当てる必要

があります。障害が発生したMonitorノードを再展開した後、一時的なMonitorノードをアンイン

ストールできます。

Cephクラスタへの新しいノード/役割の追加の詳細については、1.1項「新しいクラスタノード

の追加」および1.2項「ノードへの新しい役割の追加」を参照してください。

クラスタノードの削除の詳細については、1.3項「クラスタノードの削除と再インストール」を参照

してください。

6 Monitorノードの再展開 SES 5

Cephノードの障害の程度には、基本的に次の2つがあります。

Salt Minionホストが物理的にまたはOSレベルで壊れ、 salt 'minion_name' test.pingの

呼び出しに応答しない。この場合、『導入ガイド』、第4章「DeepSea/Saltを使用した展開」、4.3

項「クラスタの展開」の関連する手順に従って、サーバを完全に再展開する必要があります。

Monitor関連サービスに障害が発生して回復できないものの、ホストは salt 'minion_name'

test.pingの呼び出しに応答する。この場合は、次の手順に従います。

1. Salt Masterの /srv/pillar/ceph/proposals/policy.cfgを編集して、障害が発生した

Monitorノードに対応する行を削除または更新し、動作中のMonitorノードを指すようにします。

2. DeepSeaステージ2〜5を実行して変更を適用します。

root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3root@master # deepsea stage run ceph.stage.4root@master # deepsea stage run ceph.stage.5

1.5 ノードへのOSDの追加既存のOSDノードにディスクを追加するには、ディスク上のパーティションを削除および消去する必要

があります。詳細については、『導入ガイド』、第4章「DeepSea/Saltを使用した展開」、4.3項「クラスタ

の展開」のステップ 13を参照してください。ディスクが空になったら、そのディスクをノードのYAMLファ

イルに追加します。ファイルのパスは、 /srv/pillar/ceph/proposals/profile-default/stack/

default/ceph/minions/node_name.ymlです。ファイルを保存した後、DeepSeaステージ2と3を実

行します。

root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3

ヒント: ファイルの自動更新YAMLファイルを手動で編集する代わりに、DeepSeaで新しいプロファイルを作成できま

す。DeepSeaが新しいプロファイルを作成できるようにするには、既存のプロファイルを削除す

る必要があります。

root@master # old /srv/pillar/ceph/proposals/profile-default/root@master # deepsea stage run ceph.stage.1root@master # deepsea stage run ceph.stage.2root@master # deepsea stage run ceph.stage.3

7 ノードへのOSDの追加 SES 5

1.6 OSDの削除次のコマンドを実行することによって、クラスタからCeph OSDを削除できます。

root@master # salt-run disengage.safetyroot@master # salt-run remove.osd OSD_ID

OSD_IDは、 osdという用語を除く、OSDの番号にする必要があります。たとえば、 osd.3の場合、数

字 3のみを使用します。

ヒント: 複数のOSDの削除salt-run remove.osdコマンドで複数のOSDを並行して削除することはできません。複数の

OSDの削除を自動化するには、次のループを使用できます(5、21、33、19は、削除するOSDの

ID番号です)。

for i in 5 21 33 19do echo $i salt-run disengage.safety salt-run remove.osd $idone

1.6.1 壊れたOSDの強制削除

OSDを正常に削除できない場合があります(1.6項「OSDの削除」を参照してください)。これは、たとえ

ば、OSDまたはそのキャッシュが壊れた場合、I/O操作がハングする問題が発生している場合、OSD

ディスクをアンマウントできない場合などに発生することがあります。このような場合、OSDを強制的に

削除する必要があります。

root@master # target osd.remove OSD_ID force=True

このコマンドは、データパーティションと、ジャーナルまたはWAL/DBパーティションの両方を削除しま

す。

孤立している可能性があるジャーナル/WAL/DBデバイスを特定するには、次の手順に従います。

1. 孤立パーティションが存在する可能性があるデバイスを選択して、そのパーティションのリストを

ファイルに保存します。

root@minion > ls /dev/sdd?* > /tmp/partitions

8 OSDの削除 SES 5

2. block.wal、block.db、およびjournalのすべてのデバイスに対して readlinkを実行し、その出

力を、先ほど保存したパーティションリストと比較します。

root@minion > readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \ | sort | comm -23 /tmp/partitions -

この出力は、Cephによって使用されて「いない」パーティションのリストです。

3. 好みのコマンド(たとえば、 fdisk 、または parted 、 sgdisk )を使用して、Cephに属していない

孤立パーティションを削除します。

1.7 再インストールしたOSDノードの回復OSDノードの1つでオペレーティングシステムが壊れて回復不可能な場合、クラスタデータを変更せず

にノードを回復してそのOSDの役割を再展開するには、次の手順に従います。

1. ノードにオペレーティングシステムを再インストールします。

2. OSDノードに salt-minion パッケージをインストールして、Salt Master上にある古いSalt

Minionキーを削除し、新しいSalt MinionのキーをSalt Masterに登録します。Salt Minionの

展開の詳細については、『導入ガイド』、第4章「DeepSea/Saltを使用した展開」、4.3項「クラス

タの展開」を参照してください。

3. ステージ0全体を実行するのではなく、次の部分を実行します。

root@master # salt 'osd_node' state.apply ceph.syncroot@master # salt 'osd_node' state.apply ceph.packages.commonroot@master # salt 'osd_node' state.apply ceph.minesroot@master # salt 'osd_node' state.apply ceph.updates

4. DeepSeaステージ1〜5を実行します。

root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4root@master # salt-run state.orch ceph.stage.5

5. DeepSeaステージ0を実行します。


6. 関連するOSDノードを再起動します。すべてのOSDディスクが再検出されて再使用されます。

9 再インストールしたOSDノードの回復 SES 5

1.8 Saltを使用したインストールの自動化Salt Reactorを使用することにより、インストールを自動化できます。仮想環境または一貫性のある

ハードウェア環境では、この設定により、指定した動作でCephクラスタを作成できます。

警告Saltは、Reactorのイベントに基づいて依存関係の確認を実行することはできません。Salt

Masterが過負荷になり、応答しなくなる現実の危険があります。

自動インストールには以下が必要です。

適切に作成された /srv/pillar/ceph/proposals/policy.cfg 。

/srv/pillar/ceph/stackディレクトリに配置された、準備済みのカスタム設定。

Reactorのデフォルトの設定では、ステージ0と1のみが実行されます。このため、以降のステージが完

了するまで待つことなくReactorをテストできます。

最初のSalt Minionが起動すると、ステージ0が開始されます。ロックされるため、複数のインスタンス

が起動することはありません。すべてのMinionがステージ0を完了すると、ステージ1が開始されます。

操作が適切に実行されたら、 /etc/salt/master.d/reactor.confの最後の行を変更します。

- /srv/salt/ceph/reactor/discovery.sls

変更後:

- /srv/salt/ceph/reactor/all_stages.sls

1.9 クラスタノードの更新クラスタのノードに定期的にローリング更新を適用することをお勧めします。更新を適用するには、ス

テージ0を実行します。


実行中のCephクラスタが検出されると、DeepSeaは各ノードに順次更新を適用してノードを再起動し

ます。DeepSeaは、Cephの公式な推奨に従って、最初にMonitor、次にOSD、最後に追加のサービス

(MDS、Object Gateway、iSCSI Gateway、NFS Ganeshaなど)の順に更新します。クラスタで問題

が検出された場合、DeepSeaは更新プロセスを停止します。そのトリガになる可能性がある条件は次

のとおりです。

10 Saltを使用したインストールの自動化 SES 5

Cephが300秒以上「HEALTH_ERR」をレポートする。

割り当てられているサービスが更新後も引き続き稼働中かどうかをSalt Minionに問い合わせ

る。サービスが900秒以上ダウンしている場合、更新は失敗します。

これらの手段を講じておくことにより、更新が壊れていたり更新に失敗したりしても、Cephクラスタが継

続して動作するようにします。

DeepSeaステージ0は、 zypper updateによってシステムを更新し、カーネルが更新されている場合、

システムを再起動します。すべてのノードが強制的に再起動される可能性を排除するには、DeepSea

ステージ0を開始する前に、最新のカーネルがインストールおよび実行されていることを確認します。

ヒント: zypper patchzypper patchコマンドを使用してシステムを更新する場合は、 /srv/pillar/ceph/stack/

global.ymlを編集して次の行を追加します。

update_method_init: zypper-patch

/srv/pillar/ceph/stack/global.ymlに次の行を追加することによって、DeepSeaステージ0で

デフォルトで再起動される動作を変更できます。

stage_prep_master: default-update-no-rebootstage_prep_minion: default-update-no-reboot

stage_prep_masterはSalt Masterのステージ0の動作を設定し、 stage_prep_minionはすべて

のMinionの動作を設定します。利用可能なすべてのパラメータは次のとおりです。

default

更新をインストールして、更新後に再起動します。

default-update-no-reboot

再起動せずに更新をインストールします。

default-no-update-reboot

更新をインストールせずに再起動します。

default-no-update-no-reboot

更新のインストールまたは再起動を行いません。

11 クラスタノードの更新 SES 5

1.10 クラスタの停止または再起動場合によっては、クラスタ全体を停止または再起動しなければならないことがあります。実行中のサービ

スの依存関係を入念に確認することをお勧めします。次の手順では、クラスタの停止と起動の概要を説

明します。

1. OSDにoutのマークを付けないようCephクラスタに指示します。

root # ceph osd set noout

2. 次の順序でデーモンとノードを停止します。

1. ストレージクライアント

2. ゲートウェイ(たとえば、NFS Ganesha、Object Gateway)

3. Metadata Server

4. Ceph OSD

5. Ceph Manager

6. Ceph Monitor

3. 必要に応じて、保守タスクを実行します。

4. ノードとサーバをシャットダウンプロセスの逆の順序で起動します。

1. Ceph Monitor

2. Ceph Manager

3. Ceph OSD

4. Metadata Server

5. ゲートウェイ(たとえば、NFS Ganesha、Object Gateway)

6. ストレージクライアント

5. nooutフラグを削除します。

root # ceph osd unset noout

12 クラスタの停止または再起動 SES 5

1.11 カスタムのceph.confファイル

ceph.confファイルにカスタム設定を挿入する必要がある場合、 /srv/salt/ceph/

configuration/files/ceph.conf.dディレクトリにある次の設定ファイルを変更できます。

global.conf

mon.conf

mgr.conf

mds.conf

osd.conf

client.conf

rgw.conf

注記: 固有のrgw.confObject Gatewayは非常に柔軟で、他の ceph.confセクションと比較して独特です。他のす

べてのCephコンポーネントには、 [mon]や [osd]のような静的なヘッダがあります。Object

Gatewayには、 [client.rgw.rgw1]のような固有のヘッダがあります。つまり、 rgw.confファ

イルにはヘッダエントリが必要です。例については、 /srv/salt/ceph/configuration/

files/rgw.confを参照してください。

重要: ステージ3を実行します。上で説明されている設定ファイルにカスタムの変更を加えた後、ステージ3を実行し、これらの

変更をクラスタノードに適用します。


これらのファイルは、 /srv/salt/ceph/configuration/files/ceph.conf.j2テンプレートファイ

ルからインクルードされ、Ceph設定ファイルで使用できるさまざまなセクションに対応します。設定スニ

ペットを正しいファイルに配置することにより、DeepSeaはその設定を正しいセクションに配置できま

す。セクションヘッダを追加する必要はありません。

13 カスタムのceph.confファイル SES 5

ヒント設定オプションをデーモンの特定のインスタンスにのみ適用するには、 [osd.1]のようなヘッダ

を追加します。そのヘッダより後の設定オプションは、IDが1のOSDデーモンにのみ適用されま

す。

1.11.1 デフォルト値の上書き

セクションの後にあるステートメントの方が前にあるステートメントよりも優先されます。したがって、 /

srv/salt/ceph/configuration/files/ceph.conf.j2テンプレートで指定されているデフォルト

設定を上書きできます。たとえば、cephx認証をオフにするには、 /srv/salt/ceph/configuration/

files/ceph.conf.d/global.confファイルに次の3行を追加します。

auth cluster required = noneauth service required = noneauth client required = none

1.11.2 設定ファイルのインクルード

大量のカスタム設定を適用する必要がある場合、カスタム設定ファイル内で次のincludeステートメン

トを使用すると、ファイル管理が容易になります。次に、 osd.confファイルの例を示します。

[osd.1]{% include "ceph/configuration/files/ceph.conf.d/osd1.conf" ignore missing %}[osd.2]{% include "ceph/configuration/files/ceph.conf.d/osd2.conf" ignore missing %}[osd.3]{% include "ceph/configuration/files/ceph.conf.d/osd3.conf" ignore missing %}[osd.4]{% include "ceph/configuration/files/ceph.conf.d/osd4.conf" ignore missing %}

上の例では、 osd1.conf 、 osd2.conf 、 osd3.conf 、および osd4.confの各ファイルに、関連する

OSDに固有の設定ファイルが含まれています。

ヒント: ランタイム設定Ceph設定ファイルに加えた変更は、関連するCephデーモンの再起動後に有効になりま

す。Cephランタイム設定の変更の詳細については、1.12項「Cephランタイム設定」を参照して

ください。

14 デフォルト値の上書き SES 5

1.12 Cephランタイム設定1.11項「カスタムのceph.confファイル」は、Ceph設定ファイル ceph.confに変更を加える方法につ

いて説明しています。しかし、クラスタの実際の動作は、 ceph.confファイルの現在の状態ではなく、メ

モリに格納されている、実行中のCephデーモンの設定によって決まります。

デーモンが実行されているノードで「admin socket」を使用して、特定の設定をCephの個々のデー

モンに問い合わせることができます。たとえば、次のコマンドは、 osd.0という名前のデーモンか

ら osd_max_write_size設定パラメータの値を取得します。

root # ceph --admin-daemon /var/run/ceph/ceph-osd.0.asok \config get osd_max_write_size{ "osd_max_write_size": "90"}

デーモンの設定をランタイム時に「変更」することもできます。この変更は一時的で、デーモンを次回再

起動すると失われることに注意してください。たとえば、次のコマンドは、クラスタ内にあるすべてのOSD

の osd_max_write_sizeパラメータを「50」に変更します。

root # ceph tell osd.* injectargs --osd_max_write_size 50

警告: injectargsは信頼性が低い残念ながら、 injectargsコマンドでのクラスタ設定の変更は完全には信頼できません。変更し

たパラメータを確実にアクティブにする必要がある場合は、設定ファイルでパラメータを変更し

て、クラスタ内のすべてのデーモンを再起動してください。

15 Cephランタイム設定 SES 5

II クラスタの運用

2 はじめに 17

3 Cephのサービスの操作 18

4 クラスタの状態の判断 22

5 cephxを使用した認証 38

6 保存データの管理 52

7 ストレージプールの管理 68

8 RADOS Block Device 85

9 イレージャコーディングプール 104

10 キャッシュ階層化 109

2 はじめに

本マニュアルのこの部分では、Cephサービスの起動または停止、クラスタの状態の監視、CRUSH

マップの使用と変更、またはストレージプールの管理の方法を学びます。

さらに、ユーザと認証の全般的な管理方法や、プールとRADOSデバイスのスナップショットの管理方

法、イレージャコーディングプールの設定方法、キャッシュ階層化によるクラスタのパフォーマンスの向

上などの高度なトピックについても説明します。

17 SES 5

3 Cephのサービスの操作

Cephのサービスは、 systemdまたはDeepSeaを使用して操作できます。

3.1 systemdを使用したCephのサービスの操作すべてのCeph関連サービスを操作するには、 systemctlコマンドを使用します。操作は、現在ログイ

ンしているノードに対して実行されます。Cephのサービスを操作できるようにするには、 root特権が必

要です。

3.1.1 ターゲットを使用したサービスの起動、停止、および再起動ノード上の特定タイプの全サービス(たとえば、すべてのCephサービス、すべてのMON、すべての

OSD)の起動、停止、および再起動を簡素化するため、Cephでは、次の systemdユニットファイルが提

供されています。

root # ls /usr/lib/systemd/system/ceph*.targetceph.targetceph-osd.targetceph-mon.targetceph-mgr.targetceph-mds.targetceph-radosgw.targetceph-rbd-mirror.target

ノード上のすべてのCephサービスを起動/停止/再起動するには、次のコマンドを実行します。

root # systemctl stop ceph.targetroot # systemctl start ceph.targetroot # systemctl restart ceph.target

ノード上のすべてのOSDを起動/停止/再起動するには、次のコマンドを実行します。

root # systemctl stop ceph-osd.targetroot # systemctl start ceph-osd.targetroot # systemctl restart ceph-osd.target

他のターゲット用のコマンドも同様です。

3.1.2 個々のサービスの起動、停止、および再起動次のパラメータ化された systemdユニットファイルを使用して、個々のサービスを操作できます。

18 systemdを使用したCephのサービスの操作 SES 5

[email protected]@[email protected]@[email protected]

これらのコマンドを使用するには、最初に、操作するサービスの名前を識別する必要があります。サービ

スの識別の詳細については、3.1.3項「個々のサービスの識別」を参照してください。

osd.1サービスを起動/停止/再起動するには、次のコマンドを実行します。

root # systemctl stop [email protected] # systemctl start [email protected] # systemctl restart [email protected]

他のサービスタイプ用のコマンドも同様です。

3.1.3 個々のサービスの識別

systemctlを実行して結果を grepコマンドでフィルタリングすることにより、特定のタイプのサービス

の名前/番号を確認できます。次に例を示します。

root # systemctl | grep -i 'ceph-osd.*service'root # systemctl | grep -i 'ceph-mon.*service'[...]

3.1.4 サービスの状態

サービスの状態を systemdに問い合わせることができます。次に例を示します。

root # systemctl status [email protected] # systemctl status [email protected]

HOSTNAMEは、デーモンが実行されているホスト名に置き換えてください。

サービスの正確な名前/番号がわからない場合は、3.1.3項「個々のサービスの識別」を参照してくださ

い。

3.2 DeepSeaを使用したCephのサービスの再起動クラスタノードに更新を適用した後に、最近インストールしたバージョンを利用するには、割り当てられて

いるサービスを再起動する必要があります。

19 個々のサービスの識別 SES 5

注記: 再起動の監視クラスタの再起動プロセスには時間がかかることがあります。次のコマンドを実行することによ

り、Saltイベントバスを使用してイベントを監視できます。

root@master # salt-run state.event pretty=True

3.2.1 すべてのサービスの再起動

クラスタ上の「すべて」のサービスを再起動するには、次のコマンドを実行します。

root@master # salt-run state.orch ceph.restart

個々の役割の再起動順序は、DeepSeaのバージョン( rpm -q deepsea )によって異なります。

バージョン0.8.4より前のDeepSeaでは、Metadata Server、iSCSI Gateway、Object

Gateway、およびNFS Ganeshaサービスは並行して再起動されます。

DeepSea 0.8.4以上では、設定されているすべての役割は、Ceph Monitor、Ceph

Manager、Ceph OSD、Metadata Server、Object Gateway、iSCSI Gateway、NFS

Ganeshaの順に再起動されます。ダウンタイムを短く抑え、潜在的な問題をできる限り早期に見

つけるため、各ノードは順番に再起動されます。たとえば、モニタリングノードは一度に1つずつ起

動されます。

クラスタが機能低下した正常でない状態の場合、このコマンドはクラスタが回復するまで待機します。

3.2.2 特定のサービスの再起動

クラスタ上の特定のサービスを再起動するには、次のコマンドを実行します。

root@master # salt-run state.orch ceph.restart.service_name

たとえば、すべてのObject Gatewayを再起動するには、次のコマンドを実行します。

root@master # salt-run state.orch ceph.restart.rgw

次のターゲットを使用できます。

root@master # salt-run state.orch ceph.restart.mon

root@master # salt-run state.orch ceph.restart.mgr

20 すべてのサービスの再起動 SES 5

root@master # salt-run state.orch ceph.restart.osd

root@master # salt-run state.orch ceph.restart.mds

root@master # salt-run state.orch ceph.restart.rgw

root@master # salt-run state.orch ceph.restart.igw

root@master # salt-run state.orch ceph.restart.ganesha

21 特定のサービスの再起動 SES 5

4 クラスタの状態の判断

実行中のクラスタがある場合、 cephツールを使用してクラスタを監視できます。一般的に、クラスタの

状態の判断には、OSD、Monitor、配置グループ、およびMetadata Serverの状態を確認することが

含まれます。

ヒント: インタラクティブモードcephツールをインタラクティブモードで実行するには、コマンドラインで引数を付けずに

「 ceph 」と入力します。インタラクティブモードは、1行に多くの cephコマンドを入力する場合に

便利です。次に例を示します。

cephadm > cephceph> healthceph> statusceph> quorum_statusceph> mon_status

4.1 クラスタのヘルスの確認クラスタの起動後、データの読み込みや書き込みを開始する前に、クラスタのヘルスを確認します。

root # ceph healthHEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \node-1,node-2,node-3

Cephクラスタは、次のいずれかのヘルスコードを返します。

OSD_DOWN

1つ以上のOSDにダウン状態を示すマークが付いています。OSDデーモンが停止されているか、

ピアOSDがネットワーク経由でOSDに接続できない可能性があります。一般的な原因として、

デーモンの停止またはクラッシュ、ホストのダウン、ネットワークの停止などがあります。

ホストが正常である場合、デーモンは起動していて、ネットワークは機能しています。デーモンがク

ラッシュした場合は、そのデーモンのログファイル( /var/log/ceph/ceph-osd.* )にデバッグ情

報が記述されていることがあります。

OSD_ crush type _DOWN (例: OSD_HOST_DOWN)

特定のCRUSHサブツリー内のすべてのOSD (たとえば、特定のホスト上のすべてのOSD)にダ

ウン状態を示すマークが付いています。

22 クラスタのヘルスの確認 SES 5

OSD_ORPHAN

OSDがCRUSHマップ階層で参照されていますが、存在しません。次のコマンドを使用して、OSD

をCRUSH階層から削除できます。

root # ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

backfillfull、nearfull、full、またはfailsafe_full、あるいはこれらすべての使用量のしきい値が

昇順になっていません。特に、backfillfull < nearfull、nearfull < full、full < failsafe_fullと

なっている必要があります。次のコマンドを使用してしきい値を調整できます。

root # ceph osd set-backfillfull-ratio ratioroot # ceph osd set-nearfull-ratio ratioroot # ceph osd set-full-ratio ratio

OSD_FULL

1つ以上のOSDがfullのしきい値を超えており、クラスタは書き込みを実行できません。次のコマ

ンドを使用して、プールごとの使用量を確認できます。

root # ceph df

次のコマンドを使用して、現在定義されているfullの比率を確認できます。

root # ceph osd dump | grep full_ratio

書き込み可用性を復元するための短期的な回避策は、fullのしきい値を少し高くすることです。

root # ceph osd set-full-ratio ratio

さらにOSDを展開してクラスタに新しいストレージを追加するか、既存のデータを削除して領域を

解放します。

OSD_BACKFILLFULL

1つ以上のOSDがbackfillfullのしきい値を超えており、データをこのデバイスにリバランスできま

せん。これは、リバランスを完了できないこと、およびクラスタが満杯に近付いていることを示す早

期警告です。次のコマンドを使用して、プールごとの使用量を確認できます。

root # ceph df

OSD_NEARFULL

1つ以上のOSDがnearfullのしきい値を超えています。これは、クラスタが満杯に近付いているこ

とを示す早期警告です。次のコマンドを使用して、プールごとの使用量を確認できます。

root # ceph df

OSDMAP_FLAGS


関心のあるクラスタフラグが1つ以上設定されています。「full」を除き、これらのフラグは次のコマ

ンドを使用して設定またはクリアできます。

root # ceph osd set flagroot # ceph osd unset flag

次のようなフラグがあります。

full

クラスタにfullのフラグが付いており、書き込みを実行できません。

pauserd、pausewr

読み込みまたは書き込みを一時停止しました。

noup

OSDの起動が許可されていません。

nodown

OSD障害レポートが無視されているため、MonitorはOSDに「down」のマークを付けませ

ん。

noin

以前に「out」のマークが付けられているOSDには、起動時に「in」のマークは付けられませ

ん。

noout

設定した間隔が経過した後、「down」状態のOSDに自動的に「out」のマークは付けられま

せん。

nobackfill、norecover、norebalance

回復またはデータリバランスは中断されます。

noscrub、nodeep_scrub

スクラブ(6.5項「スクラブ」を参照)は無効化されます。

notieragent

キャッシュ階層化アクティビティは中断されます。

OSD_FLAGS

1つ以上のOSDに、関心のあるOSDごとのフラグが付いています。次のようなフラグがあります。

noup

OSDの起動が許可されていません。

nodown

このOSD障害レポートは無視されます。


noin

障害後に、このOSDにすでに自動的に「out」のマークが付けられている場合、起動時に

「in」のマークは付けられません。

noout

このOSDがダウンしている場合、設定した間隔が経過した後に自動的に「out」のマークは

付けられません。

次のコマンドを使用して、OSDごとのフラグを設定およびクリアできます。

root # ceph osd add-flag osd-IDroot # ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

CRUSHマップは非常に古い設定を使用しており、更新する必要があります。このヘルス警告をト

リガさせることなく使用できる最も古い調整可能パラメータ(すなわち、クラスタに接続できる最も

古いクライアントバージョン)は、 mon_crush_min_required_version設定オプションで指定し

ます。

OLD_CRUSH_STRAW_CALC_VERSION

CRUSHマップは、strawバケットの中間重み値の計算に、最適ではない古い手法を

使用しています。新しい手法を使用するようCRUSHマップを更新する必要があります

( straw_calc_version=1)。

CACHE_POOL_NO_HIT_SET

使用量を追跡するためのヒットセットが1つ以上のキャッシュプールに設定されておらず、階層化

エージェントはキャッシュからフラッシュまたは削除するコールドオブジェクトを識別できません。

次のコマンドを使用して、キャッシュプールにヒットセットを設定できます。

root # ceph osd pool set poolname hit_set_type typeroot # ceph osd pool set poolname hit_set_period period-in-secondsroot # ceph osd pool set poolname hit_set_count number-of-hitsetsroot # ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

Luminous v12より前のOSDは実行されていませんが、 sortbitwiseフラグが付いていませ

ん。Luminous v12以上のOSDを起動する前に、 sortbitwiseフラグを設定する必要がありま

す。

root # ceph osd set sortbitwise

POOL_FULL

1つ以上のプールがクォータに達しており、書き込みをこれ以上許可していません。次のコマンド

を使用して、プールのクォータと使用量を設定できます。


root # ceph df detail

次のコマンドを使用して、プールのクォータを増加できます。

root # ceph osd pool set-quota poolname max_objects num-objectsroot # ceph osd pool set-quota poolname max_bytes num-bytes

または、既存のデータを削除して使用量を削減できます。

PG_AVAILABILITY

データ可用性が低下しています。つまり、クラスタは、クラスタ内の一部のデータに対する潜在的

な読み込みまたは書き込み要求を実行できません。具体的には、1つ以上のPGがIO要求の実行

を許可していない状態です。問題があるPGの状態には、「peering」、「stale」、「incomplete」、

および「active」の欠如などがあります(これらの状態がすぐにはクリアされない場合)。影響を受

けるPGについての詳しい情報は、次のコマンドを使用して参照できます。

root # ceph health detail

ほとんどの場合、根本原因は、現在1つ以上のOSDがダウンしていることです。次のコマンドを使

用して、問題がある特定のPGの状態を問い合わせることができます。

root # ceph tell pgid query

PG_DEGRADED

一部のデータのデータ冗長性が低下しています。つまり、一部のデータについて必要な数のレプ

リカがクラスタにないか(複製プールの場合)、イレージャコードのフラグメントがクラスタにありま

せん(イレージャコーディングプールの場合)。具体的には、1つ以上のPGに「degraded」または

「undersized」のフラグが付いているか(クラスタ内にその配置グループの十分なインスタンスが

ありません)、またはしばらくの間「clean」フラグが付いていません。影響を受けるPGについての

詳しい情報は、次のコマンドを使用して参照できます。

root # ceph health detail

ほとんどの場合、根本原因は、現在1つ以上のOSDがダウンしていることです。次のコマンドを使

用して、問題がある特定のPGの状態を問い合わせることができます。


PG_DEGRADED_FULL

クラスタに空き領域がないため、一部のデータのデータ冗長性が低下しているか、危険な

状態である可能性があります。具体的には、1つ以上のPGに「backfill_toofull」または

「recovery_toofull」のフラグが付いています。つまり、1つ以上のOSDがbackfillfullのしきい値

を超えているため、クラスタはデータを移行または回復できません。


PG_DAMAGED

データスクラブ(6.5項「スクラブ」を参照)によってクラスタのデータ整合性に問題が検出されま

した。具体的には、1つ以上のPGに「inconsistent」または「snaptrim_error」のフラグが付いて

います。これは、前のスクラブ操作で問題が見つかったか、「repair」フラグが設定されていること

を示しており、現在その不整合の修復が進行中であることを意味します。

OSD_SCRUB_ERRORS

最近のOSDスクラブで不整合が発見されました。

CACHE_POOL_NEAR_FULL

キャッシュ層プールがほぼ満杯です。このコンテキストにおける「満杯」は、キャッシュプールの

「target_max_bytes」および「target_max_objects」のプロパティによって判断されます。プール

がターゲットしきい値に達した場合、データがキャッシュからフラッシュまたは削除される間、プー

ルへの書き込み要求がブロックされることがあり、通常はレイテンシが非常に高くなり、パフォーマ

ンスが低下する状態になります。次のコマンドを使用して、キャッシュプールのターゲットサイズを

調整できます。

root # ceph osd pool set cache-pool-name target_max_bytes bytesroot # ceph osd pool set cache-pool-name target_max_objects objects

通常のキャッシュフラッシュおよび削除アクティビティは、基本層の可用性またはパフォーマンス

の低下、あるいはクラスタ全体の負荷によっても低速になることがあります。

TOO_FEW_PGS

使用中のPGの数が、設定可能なしきい値である、OSDあたり

の mon_pg_warn_min_per_osdのPG数未満です。このため、クラスタ内のOSDへのデータの分

散とバランスが最適ではなくなり、全体的なパフォーマンスが低下します。

TOO_MANY_PGS

使用中のPGの数が、設定可能なしきい値である、OSDあたり

の mon_pg_warn_max_per_osdのPG数を超えています。このため、OSDデーモンのメモリ使用

量が増加する、クラスタの状態が変化(たとえば、OSDの再起動、追加、削除)した後にピアリング

の速度が低下する、Ceph ManagerとCeph Monitorの負荷が増加するなどの可能性がありま

す。

既存のプールの pg_numの値を下げることはできませんが、 pgp_numの値は下げることができま

す。これによって、同じOSDセットの複数のPGを効果的に一緒に配置して、前に説明した悪影響

を多少緩和できます。次のコマンドを使用して、 pgp_numの値を調整できます。

root # ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM


1つ以上のプールの pgp_numの値が pg_num未満です。これは通常、配置動作を同時に増やさ

ずにPG数を増やしたことを示します。通常は、次のコマンドを使用して、 pgp_numを pg_numに一

致するよう設定し、データマイグレーションをトリガすることによって解決します。

ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

1つ以上のプールで、PGあたりの平均オブジェクト数がクラスタの全体の平均を大幅に超過して

います。具体的なしきい値は、 mon_pg_warn_max_object_skewの設定値で制御します。これ

は通常、クラスタ内のほとんどのデータを含むプールのPGが少なすぎるか、それほど多くのデー

タを含まない他のプールのPGが多すぎるか、またはその両方であることを示します。Monitor

の mon_pg_warn_max_object_skew設定オプションを調整することによって、しきい値を上げて

ヘルス警告を停止できます。

POOL_APP_NOT_ENABLED

1つ以上のオブジェクトが含まれるプールが存在しますが、特定のアプリケーション用のタグが付

けられていません。この警告を解決するには、プールにアプリケーション用のラベルを付けます。た

とえば、プールがRBDによって使用される場合は、次のコマンドを実行します。

root # rbd pool init pool_name

プールがカスタムアプリケーション「foo」によって使用されている場合、次の低レベルのコマンド

を使用してラベルを付けることもできます。

root # ceph osd pool application enable foo

POOL_FULL

1つ以上のプールがクォータに達しています(またはクォータに非常に近付いています)。このエ

ラー条件をトリガするためのしきい値は、 mon_pool_quota_crit_threshold設定オプション

で制御します。次のコマンドを使用して、プールクォータを増減(または削除)できます。

root # ceph osd pool set-quota pool max_bytes bytesroot # ceph osd pool set-quota pool max_objects objects

クォータの値を0に設定すると、クォータは無効になります。

POOL_NEAR_FULL

1つ以上のプールがクォータに近付いています。この警告条件をトリガするためのしきい値

は、 mon_pool_quota_warn_threshold設定オプションで制御します。次のコマンドを使用し

て、プールクォータを増減(または削除)できます。

root # ceph osd osd pool set-quota pool max_bytes bytesroot # ceph osd osd pool set-quota pool max_objects objects


クォータの値を0に設定すると、クォータは無効になります。

OBJECT_MISPLACED

クラスタ内の1つ以上のオブジェクトが、クラスタで保存場所に指定されているノードに保存され

ていません。これは、クラスタに最近加えられた変更によるデータマイグレーションがまだ完了して

いないことを示します。データの誤配置そのものは危険な状態ではありません。データ整合性は

危険な状態ではなく、必要な数の新しいコピーが(必要な場所に)存在する限り、オブジェクトの

古いコピーが削除されることはありません。

OBJECT_UNFOUND

クラスタ内の1つ以上のオブジェクトが見つかりません。具体的には、OSDはオブジェクトの新し

いコピーまたはアップロードコピーが存在していることを認識していますが、現在オンラインである

OSD上にオブジェクトのそのバージョンのコピーが見つかりません。「見つからない」オブジェクト

に対する読み込みまたは書き込み要求はブロックされます。理想的には、見つからないオブジェ

クトの最新のコピーがある、ダウン中のOSDをオンラインに戻すことができます。見つからないオ

ブジェクトを受け持っているPGのピアリング状態から、候補のOSDを特定できます。


REQUEST_SLOW

OSDの1つ以上の要求の処理に長い時間がかかっています。これは、極端な負荷、低速なスト

レージデバイス、またはソフトウェアのバグを示している可能性があります。OSDホストから次のコ

マンドを実行して、対象のOSDの要求キューを問い合わせることができます。

root # ceph daemon osd.id ops

最も低速な最近の要求のサマリが表示されます。

root # ceph daemon osd.id dump_historic_ops

次のコマンドを使用して、OSDの場所を特定できます。

root # ceph osd find osd.id

REQUEST_STUCK

OSDの1つ以上の要求がきわめて長時間ブロックされています。これは、クラスタが長時間にわ

たって正常でないか(たとえば、十分な数のOSDが実行されていない)、OSDに何らかの内部的

な問題があることを示します。

PG_NOT_SCRUBBED

最近、1つ以上のPGがスクラブ(6.5項「スクラブ」を参照)されていません。PG

は通常、 mon_scrub_intervalの秒数ごとにスクラブされ、スクラブなし

に mon_warn_not_scrubbedの間隔が経過した場合、この警告がトリガされます。cleanフラグ


が付いていない場合、PGはスクラブされません。これは、PGが誤配置されているか機能が低下

している場合に発生することがあります(前のPG_AVAILABILITYおよびPG_DEGRADEDを

参照してください)。次のコマンドを使用して、クリーンなPGのスクラブを手動で開始できます。

root # ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

最近、1つ以上のPGが詳細スクラブ(6.5項「スクラブ」を参照)されていません。PG

は通常、 osd_deep_mon_scrub_intervalの秒数ごとにスクラブされ、スクラブなし

に mon_warn_not_deep_scrubbedの間隔が経過した場合、この警告がトリガされます。clean

フラグが付いていない場合、PGは詳細スクラブされません。これは、PGが誤配置されてい

るか機能が低下している場合に発生することがあります(前のPG_AVAILABILITYおよび

PG_DEGRADEDを参照してください)。次のコマンドを使用して、クリーンなPGのスクラブを手動

で開始できます。

root # ceph pg deep-scrub pgid

ヒント設定またはキーリングにデフォルト以外の場所を指定した場合、その場所を指定できます。

root # ceph -c /path/to/conf -k /path/to/keyring health

4.2 クラスタの監視ceph -sを使用して、クラスタの直近の状態を確認できます。たとえば、1つのMonitorと2つのOSDで

構成される小規模なCephクラスタでは、ワークロードが実行中の場合、次の内容が出力される場合が

あります。

cluster: id: 6586341d-4565-3755-a4fd-b50f51bee248 health: HEALTH_OK

services: mon: 3 daemons, quorum blueshark1,blueshark2,blueshark3 mgr: blueshark3(active), standbys: blueshark2, blueshark1 osd: 15 osds: 15 up, 15 in

data: pools: 8 pools, 340 pgs objects: 537 objects, 1985 MB

30 クラスタの監視 SES 5

usage: 23881 MB used, 5571 GB / 5595 GB avail pgs: 340 active+clean

io: client: 100 MB/s rd, 26256 op/s rd, 0 op/s wr

出力に表示される情報は、次のとおりです。

クラスタID

クラスタのヘルス状態

Monitorマップのエポック、およびMonitor定数の状態

Monitorマップのエポック、およびOSDの状態

配置グループのマップバージョン

配置グループとプールの数

保存データの「名目上」の量と、保存オブジェクトの数

保存データの合計量

ヒント: Cephによるデータ使用量の計算方法usedの値は、未加工ストレージの実際の使用量を反映します。 xxx GB / xxx GBの値は、

クラスタの全体的なストレージ容量の利用可能な量(より少ない数)を意味します。名目上の数

は、複製、クローン作成、またはスナップショット作成前の保存データのサイズを反映します。した

がって、実際の保存データの量は名目上の量より大きくなるのが一般的です。Cephは、データ

のレプリカを作成し、クローンやスナップショットの作成にもストレージ容量を使用することがある

ためです。

直近の状態を表示するその他のコマンドは次のとおりです。

ceph pg stat

ceph osd pool stats

ceph df

ceph df detail

情報をリアルタイムで更新するには、これらの任意のコマンド( ceph -sを含む)を待ちループに入れま

す。次に例を示します。

31 クラスタの監視 SES 5

rootwhile true ; do ceph -s ; sleep 10 ; done

監視を終了する場合は、 Ctrl – C キーを押します。

4.3 クラスタの使用量統計の確認クラスタのデータ使用量とプール間でのデータの分散を確認するには、 dfオプションを使用できます。

これはLinuxの dfと同様です。次のコマンドを実行します。

root # ceph dfGLOBAL: SIZE AVAIL RAW USED %RAW USED 55886G 55826G 61731M 0.11POOLS: NAME ID USED %USED MAX AVAIL OBJECTS testpool 1 0 0 17676G 0 ecpool 2 4077M 0.01 35352G 2102 test1 3 0 0 17676G 0 rbd 4 16 0 17676G 3 rbd1 5 16 0 17676G 3 ecpool1 6 5708M 0.02 35352G 2871

出力の GLOBALセクションには、クラスタがデータに使用しているストレージの量の概要が表示されま

す。

SIZE : クラスタの全体的なストレージ容量。

AVAIL : クラスタで利用可能な空き領域の量。

RAW USED : 使用済みの未加工ストレージの量。

% RAW USED : 使用済みの未加工ストレージの割合。この数字を full ratioおよび near

full ratioと組み合わせて使用して、クラスタの容量に達していないことを確認します。

詳細については、「Storage Capacity (http://docs.ceph.com/docs/master/rados/

configuration/mon-config-ref#storage-capacit) 」を参照してください。

注記: クラスタの充足レベル未加工ストレージの充足レベルが70〜80%になった場合、新しいストレージをクラスタに

追加する必要があることを示しています。使用量がさらに多くなると、1つのOSDが満杯に

なり、クラスタのヘルスに問題が発生することがあります。

すべてのOSDの充足レベルを一覧にするには、コマンド ceph osd df treeを使用しま

す。

32 クラスタの使用量統計の確認 SES 5

http://docs.ceph.com/docs/master/rados/configuration/mon-config-ref#storage-capacit

http://docs.ceph.com/docs/master/rados/configuration/mon-config-ref#storage-capacit

出力の POOLSセクションには、プールのリストと各プールの名目上の使用量が表示されます。このセク

ションの出力には、レプリカ、クローン、またはスナップショットは反映されて「いません」。たとえば、1MB

のデータを持つオブジェクトを保存した場合、名目上の使用量は1MBですが、実際の使用量は、レプリ

カ、クローン、およびスナップショットの数によっては2MB以上になることがあります。

NAME : プールの名前。

ID : プールのID。

USED : 保存データの名目上の量(キロバイト単位)。ただし、メガバイトを表す場合はM、ギガバイ

トを表す場合はGがそれぞれ付加されます。

%USED : プールごとの使用済みストレージの名目上の割合。

MAX AVAIL : 特定のプールで利用可能な最大領域。

OBJECTS : プールごとの保存オブジェクトの名目上の数。

注記POOLSセクションの数字は名目上の数字です。レプリカ、スナップショット、またはクローンの数

は含まれません。そのため、USEDの量や%USEDの量を合計しても、出力の%GLOBALセク

ションのRAW USEDの量や%RAW USEDの量にはなりません。

4.4 クラスタの状態の確認クラスタの状態を確認するには、次のコマンドを実行します。

root # ceph status

または

root # ceph -s

インタラクティブモードで、「 status 」と入力して Enter キーを押します。

ceph> status

クラスタの状態が出力されます。たとえば、1つのMonitorと2つのOSDで構成される小規模なCephク

ラスタでは、次の内容が出力される場合があります。

cluster b370a29d-9287-4ca3-ab57-3d824f65e339

33 クラスタの状態の確認 SES 5

health HEALTH_OK monmap e1: 1 mons at {ceph1=10.0.0.8:6789/0}, election epoch 2, quorum 0 ceph1 osdmap e63: 2 osds: 2 up, 2 in pgmap v41332: 952 pgs, 20 pools, 17130 MB data, 2199 objects 115 GB used, 167 GB / 297 GB avail 1 active+clean+scrubbing+deep 951 active+clean

4.5 OSDの状態の確認次のコマンドを実行して、OSDが動作中であることを確認します。

root # ceph osd stat

または

root # ceph osd dump

CRUSHマップ内での位置に従ってOSDを表示することもできます。

root # ceph osd tree

CRUSHツリーと共に、ホスト、そのOSD、動作中かどうか、および重みが出力されます。

# id weight type name up/down reweight-1 3 pool default-3 3 rack mainrack-2 3 host osd-host0 1 osd.0 up 11 1 osd.1 up 12 1 osd.2 up 1

4.6 満杯のOSDの確認Cephでは、データが失われないようにするため、満杯のOSDに書き込むことはできません。運用ク

ラスタでは、クラスタが満杯率に近付くと警告が表示されます。 mon osd full ratioのデフォル

トは0.95です。すなわち、容量の95%に達すると、クライアントによるデータの書き込みが停止されま

す。 mon osd nearfull ratioのデフォルトは0.85です。すなわち、容量の85%に達するとヘルス警

告が生成されます。

満杯のOSDノードは ceph healthでレポートされます。

ceph health

34 OSDの状態の確認 SES 5

HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%

または

ceph health HEALTH_ERR 1 nearfull osds, 1 full osds osd.2 is near full at 85% osd.3 is full at 97%

満杯のクラスタへの最適な対応方法は、新しいOSDノードを追加して、クラスタが新しく利用可能に

なったストレージにデータを再分散できるようにする方法です。

満杯のためにOSDを起動できない場合は、満杯のOSDにある配置グループのディレクトリをいくつか

削除することによって、一部のデータを削除できます。

ヒント: 満杯のOSDの防止OSDが満杯になると(ディスク領域の100%を使用すると)、通常は警告なしにすぐにクラッシュ

します。次に、OSDノードを管理する際に覚えておくべきヒントをいくつか示します。

各OSDのディスク領域(通常は /var/lib/ceph/osd/osd-{1,2..}にマウント)は、基

礎となる専用のディスクまたはパーティションに配置する必要があります。

Ceph設定ファイルを確認して、CephがOSD専用のディスク/パーティションにログファイ

ルを保存しないようにします。

他のプロセスがOSD専用のディスク/パーティションに書き込まないようにします。

4.7 Monitorの状態の確認クラスタに複数のMonitorがある場合(ほとんどの場合に当てはまります)、クラスタの起動後、データを

読み書きする前に、Monitorの定数の状態を確認する必要があります。複数のMonitorが実行されて

いる場合、定数が存在する必要があります。また、Monitorの状態を定期的にチェックして、Monitorが

実行されていることを確認する必要もあります。

Monitorマップを表示するには、次のコマンドを実行します。

root # ceph mon stat

または

root # ceph mon dump

35 Monitorの状態の確認 SES 5

Monitorクラスタの定数の状態を確認するには、次のコマンドを実行します。

root # ceph quorum_status

定数の状態が返されます。たとえば、3つのMonitorで構成されるCephクラスタは、次の状態を返す場

合があります。

{ "election_epoch": 10, "quorum": [ 0, 1, 2], "monmap": { "epoch": 1, "fsid": "444b489c-4f16-4b75-83f0-cb8097468898", "modified": "2011-12-12 13:28:27.505520", "created": "2011-12-12 13:28:27.505520", "mons": [ { "rank": 0, "name": "a", "addr": "127.0.0.1:6789\/0"}, { "rank": 1, "name": "b", "addr": "127.0.0.1:6790\/0"}, { "rank": 2, "name": "c", "addr": "127.0.0.1:6791\/0"} ] }}

4.8 配置グループの状態の確認配置グループはオブジェクトをOSDにマップします。配置グループを監視する場合、配置グルー

プが activeおよび cleanである必要があります。詳細については、「Monitoring OSDs and

Placement Groups (http://docs.ceph.com/docs/master/rados/operations/monitoring-

osd-pg) 」を参照してください。

4.9 管理ソケットの使用Ceph管理ソケットを使用すると、ソケットインタフェース経由でデーモンに問い合わせることができま

す。デフォルトでは、Cephソケットは /var/run/cephにあります。管理ソケット経由でデーモンにアクセ

スするには、デーモンが実行されているホストにログインして、次のコマンドを使用します。

36 配置グループの状態の確認 SES 5

http://docs.ceph.com/docs/master/rados/operations/monitoring-osd-pg



root # ceph --admin-daemon /var/run/ceph/socket-name

利用可能な管理ソケットコマンドを表示するには、次のコマンドを実行します。

root # ceph --admin-daemon /var/run/ceph/socket-name help

管理ソケットコマンドでは、ランタイム時に設定を表示および設定できます。詳細については、「Viewing

a Configuration at Runtime (http://docs.ceph.com/docs/master/rados/configuration/

ceph-conf#ceph-runtime-config) 」を参照してください。

さらに、ランタイム時に設定値を直接設定することもできます(管理ソケットは、 ceph tell daemon-

type . id injectargsとは異なり、Monitorをバイパスします。これは、Monitorに依存しますが、対象の

ホストに直接ログインする必要はありません)。

37 管理ソケットの使用 SES 5

http://docs.ceph.com/docs/master/rados/configuration/ceph-conf#ceph-runtime-config



5 cephxを使用した認証

クライアントを識別して中間者攻撃を防御するため、Cephは cephx認証システムを提供します。このコ

ンテキストの「クライアント」とは、人間のユーザ(管理者ユーザなど)またはCeph関連サービス/デーモ

ン(たとえば、OSD、Monitor、Object Gateway)のどちらかです。

注記cephxプロトコルは、TLS/SSLと異なり、転送中のデータ暗号化には対応していません。

5.1 認証アーキテクチャcephxは、認証に共有秘密鍵を使用します。つまり、クライアントとMonitorクラスタの両方がクライア

ントの秘密鍵のコピーを持ちます。この認証プロトコルでは、実際に鍵を公開することなく、両者が鍵の

コピーを持っていることをお互いに証明できます。これによって相互認証が提供されます。つまり、クラス

タはユーザが秘密鍵を所有していることを信頼し、ユーザはクラスタが秘密鍵を持っていることを信頼

します。

Cephの重要なスケーラビリティ機能は、Ceph Object Storeへの中央インタフェースの必要がな

いところです。つまり、CephクライアントはOSDと直接対話できます。データを保護するため、Ceph

は cephx認証システムを備えており、これによってCephクライアントを認証します。

各Monitorでクライアントを認証して鍵を配布することができ、この結果 cephxの使用時にSPOF

(single point of failure)やボトルネックがなくなります。Monitorは、Cephサービスを利用する際

に使用するセッションキーが含まれる認証データ構造を返します。このセッションキー自体がクライア

ントの永続的な秘密鍵で暗号化されているため、そのクライアントのみがCeph Monitorにサービス

を要求できます。その後、クライアントはセッションキーを使用して必要なサービスをMonitorに要求

し、Monitorは、データを実際に処理するOSDに対してクライアントを認証するチケットをクライアントに

提供します。CephのMonitorとOSDは秘密を共有するので、クライアントは、Monitorが提供するチ

ケットをクラスタ内の任意のOSDまたはMetadata Serverで使用できます。 cephxチケットは期限切

れになるため、攻撃者が不正に入手した期限切れのチケットやセッションキーを使用することはできま

せん。このような認証形態により、クライアントの秘密鍵が期限切れ前に公開されていない限り、通信メ

ディアへのアクセスを持つ攻撃者が別のクライアントのIDで偽のメッセージを作成したり、別のクライア

ントの正当なメッセージを改変したりできなくなります。

38 認証アーキテクチャ SES 5

cephxを使用するには、まず管理者がクライアント/ユーザをセットアップする必要があります。次の図

では、 client.adminユーザがコマンドラインから ceph auth get-or-create-keyを呼び出して、

ユーザ名と秘密鍵を生成します。Cephの authサブシステムは、ユーザ名と鍵を生成してMonitorにコ

ピーを保存し、ユーザの秘密を client.adminユーザに戻します。つまり、クライアントとMonitorが秘

密鍵を共有します。

図 5.1: 基本的なcephx認証

Monitorで認証する場合、クライアントはMonitorにユーザ名を渡します。Monitorは、セッションキー

を生成して、それをユーザ名に関連付けられている秘密鍵で暗号化し、暗号化されたチケットをクライ

アントに戻します。その後、クライアントは共有秘密鍵でデータを復号化して、セッションキーを取得しま

す。このセッションキーは、現在のセッション中、ユーザを識別します。次にクライアントは、このセッショ

ンキーによって署名された、ユーザに関連するチケットを要求します。Monitorはチケットを生成し、ユー

ザの秘密鍵で暗号化してクライアントに戻します。クライアントはチケットを復号化し、そのチケットを使

用して、クラスタ全体のOSDとMetadata Serverに対する要求に署名します。


図 5.2: cephx認証

cephxプロトコルは、クライアントマシンとCephサーバとの間で進行中の通信を認証します。初期認

証後にクライアントとサーバとの間で送信される各メッセージは、Monitor、OSD、およびMetadata

Serverがその共有秘密で検証できるチケットを使用して署名されます。

図 5.3: cephx認証 - MDSとOSD


重要この認証は、CephクライアントとCephクラスタホストとの間の保護を提供します。Cephクライ

アントより先は認証されません。ユーザがリモートホストからCephクライアントにアクセスする場

合、ユーザのホストとクライアントホストとの間の接続にはCeph認証は適用されません。

5.2 キー管理このセクションでは、Cephクライアントユーザ、およびCeph Storage Clusterでの認証と権限付与に

ついて説明します。「ユーザ」とは、個人、またはCephクライアントを使用してCeph Storage Cluster

デーモンと対話するシステムアクタ(アプリケーションなど)のいずれかです。

認証と権限付与を有効にして(デフォルトで有効)Cephを実行している場合、ユーザ名と、指定した

ユーザの秘密鍵が含まれるキーリングを指定する必要があります(通常はコマンドラインを使用)。ユー

ザ名を指定しない場合、 client.adminがデフォルトのユーザ名として使用されます。キーリングを指

定しない場合、Ceph設定ファイルのキーリング設定を使用してキーリングが検索されます。たとえば、

ユーザ名またはキーリングを指定せずに ceph healthコマンドを実行すると、Cephはコマンドを次の

ように解釈します。

ceph -n client.admin --keyring=/etc/ceph/ceph.client.admin.keyring health

または、 CEPH_ARGS環境変数を使用して、ユーザ名と秘密の再入力を避けることができます。

5.2.1 予備知識Cephクライアントのタイプ(たとえば、Block Device、Object Storage、File System、ネイティブAPI)

に関係なく、Cephはすべてのデータを「プール」内にオブジェクトとして保存します。Cephユーザが

データを読み書きするには、プールに対するアクセスが必要です。さらに、Cephの管理コマンドを使用

するための実行許可も必要です。Cephのユーザ管理を理解するには、次の概念が役立ちます。

5.2.1.1 ユーザ

ユーザとは、個人またはシステムアクタ(アプリケーションなど)のいずれかです。ユーザを作成すること

によって、誰が(または何が)Ceph Storage Cluster、そのプール、およびプール内のデータにアクセス

できるかを制御できます。

Cephでは、ユーザの「タイプ」を使用します。ユーザ管理の目的では、タイプは常に clientで

す。Cephは、ユーザタイプとユーザIDで構成される、ピリオド(.)区切り形式でユーザを識別します。た

とえば、 TYPE.ID 、 client.admin 、 client.user1などです。ユーザタイプを使用する理由は、Ceph

41 キー管理 SES 5

Monitor、OSD、およびMetadata Serverもcephxプロトコルを使用しますが、これらはクライアントで

はないためです。ユーザタイプを区別すると、クライアントユーザと他のユーザを容易に区別でき、アク

セス制御、ユーザのモニタリング、および追跡可能性が効率化されます。

注記Ceph Storage Clusterユーザは、Ceph Object StorageユーザやCeph File Systemユー

ザと同じではありません。Ceph Object Gatewayは、ゲートウェイデーモンとStorage Cluster

との間の通信にCeph Storage Clusterユーザを使用しますが、ゲートウェイにはエンドユーザ

向けの独自のユーザ管理機能があります。Ceph File SystemはPOSIXセマンティクスを使用

します。そこに関連付けられているユーザスペースは、Ceph Storage Clusterユーザと同じで

ありません。

5.2.1.2 権限付与とケーパビリティ

Cephでは、認証ユーザにMonitor、OSD、およびMetadata Serverの機能を実行する権限を付与す

ることを説明するために、「ケーパビリティ(cap)」という用語を使用します。ケーパビリティは、プール内

のデータまたはプール内のネームスペースへのアクセスを制限することもできます。ユーザの作成また

は更新時にCeph管理者ユーザがユーザのケーパビリティを設定します。

ケーパビリティの構文は次の形式に従います。

daemon-type 'allow capability' [...]

次に、各サービスタイプのケーパビリティのリストを示します。

Monitorのケーパビリティ

r 、 w 、 x 、および allow profile capを含めます。

mon 'allow rwx'mon 'allow profile osd'

OSDのケーパビリティ

r 、 w 、 x 、 class-read 、 class-write 、および profile osdを含めます。さらに、プールとネー

ムスペースも設定できます。

osd 'allow capability' [pool=poolname] [namespace=namespace-name]

MDSのケーパビリティ

allowまたは空白のみが必要です。

42 予備知識 SES 5

mds 'allow'

次のエントリで各ケーパビリティについて説明します。

allow

デーモンのアクセス設定の前に付けます。MDSの場合にのみ、暗黙的に rwを示します。

r

ユーザに読み込みアクセスを付与します。CRUSHマップを取得するためにMonitorで必要で

す。

w

ユーザにオブジェクトへの書き込みアクセスを付与します。

x

クラスメソッドを呼び出すためのケーパビリティ(読み込みと書き込みの両方)、およびMonitor

で auth操作を実行するためのケーパビリティをユーザに付与します。

class-read

クラス読み込みメソッドを呼び出すためのケーパビリティをユーザに付与します。 xのサブセットで

す。

class-write

クラス書き込みメソッドを呼び出すためのケーパビリティをユーザに付与します。 xのサブセットで

す。

*

特定のデーモン/プールに対する読み込み、書き込み、および実行の許可と、管理コマンドの実行

機能をユーザに付与します。

profile osd

他のOSDまたはMonitorにOSDとして接続するための許可をユーザに付与します。OSDがレプ

リケーションハートビートトラフィックと状態レポートを処理できるようにするために、OSDに付与さ

れます。

profile mds

他のMDSまたはMonitorにMDSとして接続するための許可をユーザに付与します。

profile bootstrap-osd

OSDをブートするための許可をユーザに付与します。展開ツールに対して委任され、OSDのブー

ト時にキーを追加するための許可を展開ツールに付与します。

profile bootstrap-mds

43 予備知識 SES 5

Metadata Serverをブートするための許可をユーザに付与します。展開ツールに対して委任さ

れ、Metadata Serverのブート時にキーを追加するための許可を展開ツールに付与します。

5.2.1.3 プール

プールは、ユーザがデータを保存する論理パーティションです。Cephの展開環境では、一般的に、類

似するデータタイプ用の論理パーティションとしてプールを作成します。たとえば、CephをOpenStack

のバックエンドとして展開する場合、標準的な展開には、ボリューム、イメージ、バックアップ、および仮

想マシン用のプールと、 client.glanceや client.cinderなどのユーザが存在します。

5.2.2 ユーザの管理

ユーザ管理機能により、Cephクラスタ管理者は、Cephクラスタ内でユーザを直接作成、更新、および

削除できます。

Cephクラスタ内でユーザを作成または削除する場合、キーをクライアントに配布して、キーリングに追

加できるようにする必要があります。詳細については、5.2.3項「キーリングの管理」を参照してくださ

い。

5.2.2.1 ユーザの一覧

クラスタ内のユーザを一覧にするには、次のコマンドを実行します。

ceph auth list

クラスタ内のすべてのユーザが一覧にされます。たとえば、2ノードのクラスタでは、 ceph auth

listの出力は次のようになります。

installed auth entries:

osd.0 key: AQCvCbtToC6MDhAATtuT70Sl+DymPCfDSsyV4w== caps: [mon] allow profile osd caps: [osd] allow *osd.1 key: AQC4CbtTCFJBChAAVq5spj0ff4eHZICxIOVZeA== caps: [mon] allow profile osd caps: [osd] allow *client.admin key: AQBHCbtT6APDHhAA5W00cBchwkQjh3dkKsyPjw== caps: [mds] allow caps: [mon] allow *

44 ユーザの管理 SES 5

caps: [osd] allow *client.bootstrap-mds key: AQBICbtTOK9uGBAAdbe5zcIGHZL3T/u2g6EBww== caps: [mon] allow profile bootstrap-mdsclient.bootstrap-osd key: AQBHCbtT4GxqORAADE5u7RkpCN/oo4e5W0uBtw== caps: [mon] allow profile bootstrap-osd

注記: TYPE.ID表記ユーザの TYPE.ID表記は、 osd.0の場合、タイプが osdのユーザを指定し、そのIDが 0になる

ように適用されることに注意してください。 client.adminの場合は、タイプが clientのユー

ザで、そのIDは adminです。さらに、各エントリに key: valueのエントリと1つ以上の caps:エ

ントリもあることにも注意してください。

-o filenameオプションと ceph auth listを使用して、出力をファイルに保存できます。

5.2.2.2 ユーザに関する情報の取得

特定のユーザ、キー、およびケーパビリティを取得するには、次のコマンドを実行します。

ceph auth get TYPE.ID

次に例を示します。

ceph auth get client.adminexported keyring for client.admin[client.admin] key = AQA19uZUqIwkHxAAFuUwvq0eJD4S173oFRxe0g== caps mds = "allow" caps mon = "allow *" caps osd = "allow *"

開発者の場合は次のコマンドを実行することもできます。

ceph auth export TYPE.ID

auth exportコマンドは auth getと同じですが、内部の認証IDも出力します。

5.2.2.3 ユーザの追加

ユーザを追加すると、ユーザの作成に使用するコマンドで指定したユーザ名( TYPE.ID )、秘密鍵、およ

びケーパビリティが作成されます。


ユーザのキーにより、ユーザはCeph Storage Clusterで認証できます。ユーザのケーパビリティ

は、Ceph Monitor (mon)、Ceph OSD (osd)、またはCeph Metadata Server (mds)に対する読み

込み、書き込み、および実行の各権限をユーザに付与します。

次のように、ユーザを追加する場合、いくつかのコマンドを利用できます。

ceph auth add

ユーザを追加する場合の標準の方法です。ユーザを作成してキーを生成し、指定したケーパビリ

ティを追加します。

ceph auth get-or-create

このコマンドはユーザ名(かっこ内)とキーが含まれるキーファイルフォーマットを返すため、多くの

場合、ユーザを作成する場合に最も便利な方法です。ユーザがすでに存在する場合は、単にユー

ザ名とキーをキーファイルフォーマットで返します。 -o filenameオプションを使用して、出力を

ファイルに保存できます。

ceph auth get-or-create-key

ユーザを作成して、そのユーザのキー(のみ)を返す場合に便利です。キーのみが必要なクライア

ント(たとえば、 libvirt )で役立ちます。ユーザがすでに存在する場合は、単にキーを返します。 -

o filenameオプションを使用して、出力をファイルに保存できます。

クライアントユーザを作成する際に、ケーパビリティを持たないユーザを作成できます。ケーパビリティ

を持たないユーザは、認証はできますが、それ以上の操作は実行できません。このようなクライアント

はMonitorからクラスタマップを取得できません。ただし、ケーパビリティの追加を延期する場合、後

で ceph auth capsコマンドを使用して、ケーパビリティを持たないユーザを作成できます。

通常のユーザは、少なくともCeph Monitorに対する読み込みケーパビリティと、Ceph OSDに対する

読み込みおよび書き込みのケーパビリティを持ちます。さらに、ほとんどの場合、ユーザのOSD許可は

特定のプールへのアクセスに制限されます。

root # ceph auth add client.john mon 'allow r' osd \ 'allow rw pool=liverpool'root # ceph auth get-or-create client.paul mon 'allow r' osd \ 'allow rw pool=liverpool'root # ceph auth get-or-create client.george mon 'allow r' osd \ 'allow rw pool=liverpool' -o george.keyringroot # ceph auth get-or-create-key client.ringo mon 'allow r' osd \ 'allow rw pool=liverpool' -o ringo.key

重要OSDに対するケーパビリティをユーザに提供しながら、特定のプールにアクセスを制限「しな

い」場合、そのユーザはクラスタ内の「すべて」のプールへのアクセスを持ちます。


5.2.2.4 ユーザのケーパビリティの変更

ceph auth capsコマンドを使用して、ユーザを指定してそのユーザのケーパビリティを変更できます。

新しいケーパビリティを設定すると、現在のケーパビリティは上書きされます。現在のケーパビリティを

表示するには、 ceph auth get USERTYPE.USERIDを実行します。ケーパビリティを追加するには、次

の形式を使用する際に既存のケーパビリティを指定する必要もあります。

root # ceph auth caps USERTYPE.USERID daemon 'allow [r|w|x|*|...] \ [pool=pool-name] [namespace=namespace-name]' [daemon 'allow [r|w|x|*|...] \ [pool=pool-name] [namespace=namespace-name]']


root # ceph auth get client.johnroot # ceph auth caps client.john mon 'allow r' osd 'allow rw pool=prague'root # ceph auth caps client.paul mon 'allow rw' osd 'allow rwx pool=prague'root # ceph auth caps client.brian-manager mon 'allow *' osd 'allow *'

ケーパビリティを削除する場合、ケーパビリティをリセットできます。すでに設定されている、特定のデー

モンへのアクセスをユーザに付与しない場合、空の文字列を指定します。

root # ceph auth caps client.ringo mon ' ' osd ' '

5.2.2.5 ユーザの削除

ユーザを削除するには、 ceph auth delを使用します。

root # ceph auth del TYPE.ID

ここで、 TYPEは client 、 osd 、 mon 、または mdsのいずれかで、 IDはデーモンのユーザ名またはID

です。

5.2.2.6 ユーザのキーの出力

ユーザの認証キーを標準出力に出力するには、次のコマンドを実行します。

root # ceph auth print-key TYPE.ID

ここで、 TYPEは client 、 osd 、 mon 、または mdsのいずれかで、 IDはデーモンのユーザ名またはID

です。

ユーザのキーを出力すると、クライアントソフトウェアにユーザのキー( libvirtなど)を入力する必要が

ある場合に便利です。次に例を示します。

cephadm > sudo mount -t ceph host:/ mount_point \-o name=client.user,secret=`ceph auth print-key client.user`


5.2.2.7 ユーザのインポート

1人以上のユーザをインポートするには、 ceph auth importを使用し、キーリングを指定します。

cephadm > sudo ceph auth import -i /etc/ceph/ceph.keyring

注記Ceph Storage Clusterは、新しいユーザ、キー、およびケーパビリティを追加し、既存のユーザ、

キー、およびケーパビリティを更新します。

5.2.3 キーリングの管理

CephクライアントでCephにアクセスすると、クライアントはローカルキーリングを検索します。Cephに

より、デフォルトで次の4つのキーリング名を使用してキーリング設定が事前設定されるため、デフォルト

を上書きする場合を除き、ユーザがCeph設定ファイルでキーリングを設定する必要はありません。

/etc/ceph/cluster.name.keyring/etc/ceph/cluster.keyring/etc/ceph/keyring/etc/ceph/keyring.bin

clusterメタ変数は、Ceph設定ファイルの名前で定義されているCephクラスタ名で

す。 ceph.confは、クラスタ名が cephであるため、 ceph.keyringになることを意味し

ます。 nameメタ変数は、ユーザタイプとユーザID(たとえば、 client.admin )であるた

め、 ceph.client.admin.keyringになります。

ユーザ(たとえば、 client.ringo )を変更した後、キーを取得してCephクライアント上のキーリングに

追加し、ユーザがCeph Storage Clusterにアクセスできるようにする必要があります。

Ceph Storage Cluster内でユーザを直接一覧、取得、追加、変更、および削除する方法の詳細につい

ては、5.2項「キー管理」を参照してください。ただし、Cephには、Cephクライアントからキーリングを管

理できる ceph-authtoolユーティリティも用意されています。

5.2.3.1 キーリングの作成

5.2項「キー管理」の手順を使用してユーザを作成した場合、ユーザのキーをCephクライアントに提供

し、クライアントが指定のユーザのキーを取得してCeph Storage Clusterで認証できるようにする必

要があります。Cephクライアントは、キーリングにアクセスしてユーザ名を検索し、ユーザのキーを取得

します。

48 キーリングの管理 SES 5

cephadm > sudo ceph-authtool --create-keyring /path/to/keyring

複数のユーザが含まれるキーリングを作成する場合は、キーリングのファイル名にクラスタ名(たとえ

ば、 cluster .keyring)を使用して、 /etc/cephディレクトリに保存することをお勧めします。これによ

り、Ceph設定ファイルのローカルコピーで指定しなくても、キーリング設定のデフォルト設定でこのファ

イル名が選択されます。たとえば、次のコマンドを実行して、 ceph.keyringを作成します。

cephadm > sudo ceph-authtool -C /etc/ceph/ceph.keyring

1人のユーザが含まれるキーリングを作成する場合は、クラスタ名、ユーザタイプ、およびユーザ名を指

定して、 /etc/cephディレクトリに保存することをお勧めします。たとえば、ユーザが client.adminの

場合は、 ceph.client.admin.keyringとします。

5.2.3.2 キーリングへのユーザの追加

Ceph Storage Clusterにユーザを追加する場合(5.2.2.3項「ユーザの追加」を参照)、ユーザ、キー、

およびケーパビリティを取得して、そのユーザをキーリングに保存できます。

1つのキーリングにつき1人のユーザのみを使用する場合は、 ceph auth getコマンドを -oオプション

と共に使用して、出力をキーリングファイルフォーマットで保存します。たとえば、 client.adminユーザ

のキーリングを作成するには、次のコマンドを実行します。

root # ceph auth get client.admin -o /etc/ceph/ceph.client.admin.keyring

キーリングにユーザをインポートする場合は、 ceph-authtoolを使用して、インポート先のキーリングと

インポート元のキーリングを指定します。

cephadm > sudo ceph-authtool /etc/ceph/ceph.keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring

5.2.3.3 ユーザの作成

Cephでは、Ceph Storage Cluster内でユーザを直接作成するための ceph auth addコマンドが提

供されています。ただし、Cephクライアントのキーリング上でユーザ、キー、およびケーパビリティを直接

作成することもできます。その後、ユーザをCeph Storage Clusterにインポートできます。

cephadm > sudo ceph-authtool -n client.ringo --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.keyring

キーリングの作成と、そのキーリングに新しいユーザを追加する操作を同時に行うこともできます。

cephadm > sudo ceph-authtool -C /etc/ceph/ceph.keyring -n client.ringo \

49 キーリングの管理 SES 5

--cap osd 'allow rwx' --cap mon 'allow rwx' --gen-key

前のシナリオでは、新しいユーザ client.ringoはキーリング内にのみ存在します。新しいユーザを

Ceph Storage Clusterに追加するには、同じようにクラスタに新しいユーザを追加する必要がありま

す。

cephadm > sudo ceph auth add client.ringo -i /etc/ceph/ceph.keyring

5.2.3.4 ユーザの変更

キーリング内のユーザレコードのケーパビリティを変更するには、キーリングとユーザ、およびその後に

ケーパビリティを指定します。

cephadm > sudo ceph-authtool /etc/ceph/ceph.keyring -n client.ringo \ --cap osd 'allow rwx' --cap mon 'allow rwx'

変更したユーザをCephクラスタ環境内で更新するには、Cephクラスタ内でキーリングからユーザエン

トリに変更をインポートする必要があります。

root # ceph auth import -i /etc/ceph/ceph.keyring

キーリングからCeph Storage Clusterユーザを更新する方法の詳細については、5.2.2.7項「ユーザ

のインポート」を参照してください。

5.2.4 コマンドラインの使用法

cephコマンドは、ユーザ名と秘密の操作に関連する次のオプションをサポートします。

--idまたは --user

Cephは、ユーザをタイプとIDで識別します( TYPE . ID 。たとえ

ば、 client.adminや client.user1 )。 id 、 name 、および -nのオプションを使用して、ユーザ

名のID部分を指定できます(たとえば、 adminや user1 )。--idでユーザを指定して、タイプを省略

できます。たとえば、ユーザclient.fooを指定するには、次のコマンドを入力します。

root # ceph --id foo --keyring /path/to/keyring healthroot # ceph --user foo --keyring /path/to/keyring health

--nameまたは -n

Cephは、ユーザをタイプとIDで識別します( TYPE . ID 。たとえ

ば、 client.adminや client.user1 )。 --nameおよび -nのオプションを使用して、完全修飾

ユーザ名を指定できます。ユーザタイプ(通常は client )とユーザIDを指定する必要があります。

50 コマンドラインの使用法 SES 5

root # ceph --name client.foo --keyring /path/to/keyring healthroot # ceph -n client.foo --keyring /path/to/keyring health

--keyring

1つ以上のユーザ名と秘密が含まれるキーリングのパス。 --secretオプションも同じ機能を提

供しますが、Object Gatewayでは動作しません。Object Gatewayでは、 --secretは別の目

的で使用されます。 ceph auth get-or-createを使用してキーリングを取得し、ローカルに保

存できます。キーリングのパスを切り替えずにユーザ名を切り替えることができるため、お勧めの

方法です。

cephadm > sudo rbd map --id foo --keyring /path/to/keyring mypool/myimage

51 コマンドラインの使用法 SES 5

6 保存データの管理

CRUSHアルゴリズムは、データの保存場所を計算することによって、データの保存と取得の方法を決

定します。CRUSHにより、Cephクライアントは、中央サーバやブローカ経由ではなく直接OSDと通信

できるようになります。アルゴリズムで決定されるデータの保存と取得の方法を使用することで、Ceph

は、SPOF (single point of failure)、パフォーマンスのボトルネック、およびスケーラビリティの物理的

な制限を解消します。

CRUSHはクラスタのマップを必要とし、そのCRUSHマップを使用して、クラスタ全体に均等に分散し

たデータを擬似ランダムにOSDに保存および取得します。

CRUSHマップには、OSDのリスト、デバイスを物理的な場所に集約するための「バケット」のリスト、お

よびCephクラスタのプール内でデータをどのように複製するかをCRUSHに指示するルールのリストが

含まれます。インストールの基礎になっている物理的な組織を反映することで、CRUSHは、相関するデ

バイス障害の潜在的な原因をモデル化し、これによってその原因に対応できます。原因としては、物理

的な距離の近さ、共有電源、共有ネットワークなどが代表的です。この情報をクラスタマップにエンコー

ドすることにより、CRUSHの配置ポリシーは、オブジェクトのレプリカを異なる障害ドメインに分離しな

がら、必要な分散を維持できます。たとえば、発生する可能性がある同時障害に対応するため、データレ

プリカを、異なるシェルフ、ラック、電源、コントローラ、または物理的な場所を使用するデバイスに配置す

ることが望ましい場合があります。

Cephクラスタの展開後、デフォルトのCRUSHマップが生成されます。Cephサンドボックス環境にはこ

れで十分です。ただし、大規模なデータクラスタを展開する場合は、カスタムCRUSHマップの作成を積

極的に検討する必要があります。カスタムCRUSHマップは、Cephクラスタの管理、パフォーマンスの

向上、およびデータの安全性の確保に役立つためです。

たとえば、OSDがダウンしてオンサイトでのサポートやハードウェアの交換が必要になった場

合、CRUSHマップがあれば、ホストの物理的なデータセンター、ルーム、列、およびラックの場所を容易

に特定できます。

同様に、障害の特定の迅速化にも役立つことがあります。たとえば、特定のラックのOSDすべてが同時

にダウンした場合、OSD自体の障害ではなく、ネットワークスイッチ、あるいはラックまたはネットワーク

スイッチの電源の障害であることがあります。

カスタムCRUSHマップは、障害が発生したホストに関連付けられた配置グループが機能低下状態に

なった場合に、Cephによってデータの冗長コピーが保存される物理的な場所を特定するのにも役立ち

ます。

CRUSHマップには主なセクションが3つあります。

52 SES 5

デバイスは、Object Storageデバイス、つまり ceph-osdデーモンに対応するハードディスクで構

成されます。

バケットは、ストレージの場所の階層的な集約構造(列、ラック、ホストなど)と、それらに割り当てら

れている重みで構成されます。

ルールセットは、バケットの選択方法で構成されます。

6.1 デバイス配置グループをOSDにマップするため、CRUSHマップにはOSDデバイスのリスト(OSDデーモンの名

前)が必要です。デバイスのリストはCRUSHマップの先頭に記述されます。

#devicesdevice num osd.name


#devicesdevice 0 osd.0device 1 osd.1device 2 osd.2device 3 osd.3

一般的な規則として、OSDデーモンは1つのディスクにマップされます。

6.2 バケットCRUSHマップにはOSDのリストが含まれており、これを「バケット」に編成してデバイスを物理的な場

所に集約できます。

0 OSD OSDデーモン(osd.1、osd.2など)。

1 ホスト 1つ以上のOSDが含まれるホストの名前。

2 シャーシラックを構成するシャーシ。

3 ラックコンピュータラック。デフォルトは unknownrackです。

4 列一連のラックの列。

5 Pdu 配電ユニット。

53 デバイス SES 5

6 ポッド

7 ルームラックとホストの列が含まれるルーム。

8 データセンタールームが含まれる物理的なデータセンター。

9 地域

10 ルート

ヒントこれらのタイプを削除して独自のバケットタイプを作成できます。

Cephの展開ツールは、各ホストのバケットが含まれるCRUSHマップと、デフォルトの rbdプールで役

立つ「default」という名前のプールを生成します。残りのバケットタイプは、ノード/バケットの物理的な

場所の情報を保存するための手段を提供します。OSD、ホスト、またはネットワークハードウェアが正常

に機能しておらず、管理者が物理的なハードウェアにアクセスする必要がある場合、これによってクラス

タ管理が大幅に容易になります。

バケットには、タイプ、固有の名前(文字列)、負の整数で表される固有のID、項目の合計容量/機能

を基準にした相対的な重み、バケットアルゴリズム(デフォルトは straw )、およびハッシュ(デフォル

ト 0で、CRUSHハッシュ rjenkins1を反映)が含まれます。1つのバケットには1つ以上の項目を含め

ることができます。項目は他のバケットやOSDで構成できます。また、項目には、その項目の相対的な

重みを反映した重みを設定できます。

[bucket-type] [bucket-name] { id [a unique negative numeric ID] weight [the relative capacity/capability of the item(s)] alg [the bucket type: uniform | list | tree | straw ] hash [the hash type: 0 by default] item [item-name] weight [weight]}

次の例は、バケットを使用して、プールと、データセンター、ルーム、ラック、列などの物理的な場所をどの

ように集約できるかを示しています。

host ceph-osd-server-1 { id -17 alg straw hash 0 item osd.0 weight 1.00 item osd.1 weight 1.00}

54 バケット SES 5

row rack-1-row-1 { id -16 alg straw hash 0 item ceph-osd-server-1 weight 2.00}

rack rack-3 { id -15 alg straw hash 0 item rack-3-row-1 weight 2.00 item rack-3-row-2 weight 2.00 item rack-3-row-3 weight 2.00 item rack-3-row-4 weight 2.00 item rack-3-row-5 weight 2.00}



room server-room-1 { id -12 alg straw hash 0 item rack-1 weight 10.00 item rack-2 weight 10.00 item rack-3 weight 10.00}

datacenter dc-1 {

55 バケット SES 5

id -11 alg straw hash 0 item server-room-1 weight 30.00 item server-room-2 weight 30.00}

pool data { id -10 alg straw hash 0 item dc-1 weight 60.00 item dc-2 weight 60.00}

6.3 ルールセットCRUSHマップは、プールのデータ配置を決定するルールである「CRUSHルール」の概念をサポート

しています。大規模クラスタでは、ほとんどの場合、プールを大量に作成し、各プールが専用のCRUSH

ルールセットとルールを持つようにします。デフォルトのCRUSHマップには、各プールに1つのルール

と、各デフォルトプールに割り当てられた1つのルールセットがあります。

注記ほとんどの場合、デフォルトのルールを変更する必要はありません。新しいプールを作成する場

合、そのデフォルトのルールセットは0です。

ルールは次の形式を取ります。

rule rulename {

ruleset ruleset type type min_size min-size max_size max-size step step

}

ruleset

整数。ルールを、ルールのセットに属しているものとして分類します。プールでルールセットを設定

することによって有効にします。このオプションは必須です。デフォルトは 0です。

56 ルールセット SES 5

重要ルールセット番号はデフォルトの0から連続的に増やしていく必要があります。そうしない

と、関連するMonitorがクラッシュする場合があります。

type

文字列。ハードディスク(replicated)またはRAIDのルールを記述します。このオプションは必須

です。デフォルトは replicatedです。

min_size

整数。配置グループが作成するレプリカがこの数より少ない場合、CRUSHはこのルールを「選択

しません」。このオプションは必須です。デフォルトは 2です。

max_size

整数。配置グループが作成するレプリカがこの数より多い場合、CRUSHはこのルールを「選択し

ません」。このオプションは必須です。デフォルトは 10です。

step take bucket

バケット名を取ります。ツリーの下方へ反復処理を開始します。このオプションは必須です。ツリー

全体の反復処理の詳細については、6.3.1項「ノードツリー全体の反復処理」を参照してくださ

い。

step target mode num type bucket-type

targetは chooseまたは chooseleafのいずれかにできます。 chooseに設定すると、大量の

バケットが選択されます。 chooseleafは、バケットセット内の各バケットのサブツリーからOSD

(リーフノード)を直接選択します。

modeは firstnまたは indepのいずれかにできます。詳細については、6.3.2項「firstnと

indep」を参照してください。

特定のタイプのバケットの数を指定します。Nを利用可能なオプションの数とすると、 num > 0

&& < Nの場合、それと同じ数のバケットを選択します。 num < 0の場合、N - numを意味しま

す。 num == 0の場合、N個のバケット(利用可能なものすべて)を選択します。 step takeまた

は step chooseに従います。

step emit

現在の値を出力してスタックを空にします。一般的にはルールの最後で使用しますが、同じルー

ル内の別のツリーを形成する場合にも使用できます。 step chooseに従います。

57 ルールセット SES 5

重要1つのプールに共通するルールセット番号を持つ1つ以上のルールを有効にするには、ルール

セット番号をそのプールに指定します。

6.3.1 ノードツリー全体の反復処理

バケットで定義された構造はノードツリーと見なすことができます。このツリーのバケットがノード

で、OSDがリーフに当たります。

CRUSHマップのルールは、このツリーからどのような方法でOSDを選択するかを定義します。ルール

は特定のノードから処理を始めて、ツリーの下方へと反復処理を行い、OSDのセットを返します。どのブ

ランチを選択する必要があるかを定義することはできません。その代わりに、CRUSHアルゴリズムによ

り、OSDのセットがレプリケーション要件を満足し、データを均等に分散するよう保証されます。

step take bucketを使用すると、ノードツリー全体の反復処理は、指定したバケット(バケットタイプ

ではありません)から始まります。ツリー内のすべてのブランチのOSDを返す場合は、指定したバケット

がルートバケットである必要があります。そうしないと、以降の手順はサブツリーでのみ反復処理されま

す。

ルール定義の step takeの後には step chooseエントリが1つ以上続きます。それぞれの step

chooseは、直前に選択されていた上位ノードから、定義された数のノード(またはブランチ)を選択しま

す。

最後に、 step emitで、選択されたOSDが返されます。

step chooseleafは、指定したバケットのブランチからOSDを直接選択する便利な機能です。

図6.1「ツリーの例」に、 stepを使用してツリー全体で反復処理を行う例を示します。次のルール定義で

は、オレンジ色の矢印と番号は example1aと example1bに対応し、青色は example2に対応します。

58 ノードツリー全体の反復処理 SES 5

図 6.1: ツリーの例

# orange arrowsrule example1a { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) step choose firstn 0 host # orange (3) step choose firstn 1 osd step emit}

rule example1b { ruleset 0 type replicated min_size 2 max_size 10 # orange (1) step take rack1 # orange (2) + (3) step chooseleaf firstn 0 host step emit}

# blue arrowsrule example2 {

59 ノードツリー全体の反復処理 SES 5

ruleset 0 type replicated min_size 2 max_size 10 # blue (1) step take room1 # blue (2) step chooseleaf firstn 0 rack step emit}

6.3.2 firstnとindep

CRUSHルールは、障害ノードまたはOSDの置換を定義します(6.3項「ルールセット」を参照してくださ

い)。キーワード stepには、パラメータとして firstnまたは indepが必要です。図6.2「ノードの置換方

法」に例を示します。

firstnは、アクティブノードのリストの最後に置換ノードを追加します。障害ノードの場合、以降の正常

なノードが左側に移動されて、障害ノードの隙間を埋めます。これは、「複製プール」に対するデフォルト

かつ適切な方法です。2つ目のノードにはすでにすべてのデータがあるため、プライマリノードの権限を

ただちに引き継ぐことができるからです。

indepは、各アクティブノードに対して修復済みの置換ノードを選択します。障害ノードを置換する際

に、残りのノードの順序は変更されません。これは「イレージャコーディングプール」にとって適切です。

イレージャコーディングプールでは、ノードに保存されるデータは、ノード選択時の位置によって異なりま

す。ノードの順序が変更されると、影響を受けるノードのすべてのデータを再配置しなければなりません。

注記: イレージャプール必ず、「イレージャコーディングプール」それぞれに対して、 indepを使用するルールを設定して

ください。

60 firstnとindep SES 5

osd.b

osd.b

図 6.2: ノードの置換方法

6.4 CRUSHマップの操作このセクションでは、CRUSHマップの編集やパラメータの変更、OSDの追加/移動/削除な

ど、CRUSHマップの基本的な操作方法を紹介します。

6.4.1 CRUSHマップの編集

既存のCRUSHマップを編集するには、次の手順に従います。

1. CRUSHマップを取得します。クラスタのCRUSHマップを取得するには、次のコマンドを実行しま

す。

root # ceph osd getcrushmap -o compiled-crushmap-filename

Cephにより、指定したファイル名に、コンパイル済みのCRUSHマップが出力( -o )されま

す。CRUSHマップはコンパイル済み形式なので、編集する前に逆コンパイルする必要がありま

す。

2. CRUSHマップを逆コンパイルします。CRUSHマップを逆コンパイルするには、次のコマンドを実

行します。

61 CRUSHマップの操作 SES 5

cephadm > crushtool -d compiled-crushmap-filename \ -o decompiled-crushmap-filename

Cephにより、コンパイル済みのCRUSHマップが逆コンパイル( -d )されて、指定したファイル名

に出力( -o )されます。

3. デバイス、バケット、およびルールのパラメータを少なくとも1つ編集します。

4. CRUSHマップをコンパイルします。CRUSHマップをコンパイルするには、次のコマンドを実行し

ます。

cephadm > crushtool -c decompiled-crush-map-filename \ -o compiled-crush-map-filename

Cephにより、指定したファイル名に、コンパイル済みのCRUSHマップが保存されます。

5. CRUSHマップを設定します。クラスタのCRUSHマップを設定するには、次のコマンドを実行しま

す。

root # ceph osd setcrushmap -i compiled-crushmap-filename

Cephにより、指定したファイル名のコンパイル済みCRUSHマップがクラスタのCRUSHマップと

して入力されます。

6.4.2 OSDの追加/移動実行中のクラスタのCRUSHマップでOSDを追加または移動するには、次のコマンドを実行します。

root # ceph osd crush set id_or_name weight root=pool-namebucket-type=bucket-name ...

id

整数。OSDの数値ID。このオプションは必須です。

name

文字列。OSDの完全な名前。このオプションは必須です。

weight

倍精度。OSDのCRUSHの重み。このオプションは必須です。

pool

キー/値のペア。CRUSH階層には、デフォルトでそのルートとしてプールが含まれます。このオプ

ションは必須です。

62 OSDの追加/移動 SES 5

bucket-type

キー/値のペア。CRUSH階層におけるOSDの場所を指定できます。

次の例は、 osd.0を階層に追加するか、前の場所からそのOSDを移動します。

root # ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \row=foo rack=bar host=foo-bar-1

6.4.3 OSDのCRUSHの重みの調整

実行中のクラスタのCRUSHマップでOSDのCRUSHの重みを調整するには、次のコマンドを実行しま

す。

root # ceph osd crush reweight name weight

name


weight

倍精度。OSDのCRUSHの重み。このオプションは必須です。

6.4.4 OSDの削除

実行中のクラスタのCRUSHマップからOSDを削除するには、次のコマンドを実行します。

root # ceph osd crush remove name

name


6.4.5 バケットの移動

CRUSHマップ階層の別の場所または位置へバケットを移動するには、次のコマンドを実行します。

root # ceph osd crush move bucket-name bucket-type=bucket-name, ...

bucket-name

文字列。移動/位置変更するバケットの名前。このオプションは必須です。

63 OSDのCRUSHの重みの調整 SES 5

bucket-type

キー/値のペア。CRUSH階層におけるバケットの場所を指定できます。

6.5 スクラブオブジェクトの複数のコピーを作成するほかに、Cephは、配置グループを「スクラブ」することによって

データの整合性を保証します。Cephのスクラブは、Object Storage層に対して fsckを実行すること

に似ています。各配置グループについて、Cephは、すべてのオブジェクトのカタログを生成し、各プライ

マリオブジェクトとそのレプリカを比較して、オブジェクトの欠落や不一致がないことを確認します。日次

の軽量スクラブではオブジェクトのサイズと属性を確認するのに対し、週次の詳細スクラブではデータ

を読み込み、チェックサムを使用してデータの整合性を保証します。

スクラブはデータの整合性を維持するために重要ですが、パフォーマンスを低下させる可能性がありま

す。次の設定を調整して、スクラブ操作を増減できます。

osd max scrubs

Ceph OSDの同時スクラブ操作の最大数。デフォルトは1です。

osd scrub begin hour 、 osd scrub end hour

スクラブを実行可能な時間枠を定義する時間(0〜24)。デフォルトでは、0から始まり24に終了し

ます。

重要配置グループのスクラブ間隔が osd scrub max intervalの設定を超えている場合、

スクラブは、定義した時間枠とは関係なく実行されます。

osd scrub during recovery

回復時のスクラブを許可します。「false」に設定すると、アクティブな回復がある間は、新しいス

クラブのスケジューリングが無効になります。すでに実行中のスクラブは続行されます。このオプ

ションは、高負荷のクラスタの負荷を下げる場合に役立ちます。デフォルトは「true」です。

osd scrub thread timeout

スクラブスレッドがタイムアウトするまでの最大時間(秒単位)。デフォルトは60です。

osd scrub finalize thread timeout

スクラブ最終処理スレッドがタイムアウトするまでの最大時間(秒単位)。デフォルトは60*10です。

osd scrub load threshold

64 スクラブ SES 5

正規化された最大負荷。システム負荷( getloadavg() / online cpusの数の比率で定義)が

この数字を超えた場合、Cephはスクラブを実行しません。デフォルトは0.5です。

osd scrub min interval

Cephクラスタの負荷が低い場合にCeph OSDをスクラブする最小間隔(秒単位)。デフォルトは

60*60*24 (1日1回)です。

osd scrub max interval

クラスタの負荷に関係なくCeph OSDをスクラブする最大間隔(秒単位)。7*60*60*24 (週1回)。

osd scrub chunk min

1回の操作でスクラブするObject Storeチャンクの最小数。スクラブ中、Cephは1つのチャンク

への書き込みをブロックします。デフォルトは5です。

osd scrub chunk max

1回の操作でスクラブするObject Storeチャンクの最大数。デフォルトは25です。

osd scrub sleep

チャンクの次のグループをスクラブするまでのスリープ時間。この値を増やすとスクラブ操作全体

の速度が低下しますが、クライアントの操作への影響は少なくなります。デフォルトは0です。

osd deep scrub interval

「詳細」スクラブ(すべてのデータを完全に読み込み)の間隔。 osd scrub load thresholdオ

プションはこの設定に影響しません。デフォルトは60*60*24*7 (週1回)です。

osd scrub interval randomize ratio

配置グループに対して次のスクラブジョブをスケジューリングする際に、 osd scrub min

intervalの値にランダムな遅延を追加します。この遅延は、 osd scrub min interval * osd

scrub interval randomized ratioの結果よりも小さいランダムな値です。したがって、デ

フォルト設定では、許可された時間枠である[1, 1.5] * osd scrub min intervalの中で実質

的にランダムにスクラブが分散されます。デフォルトは0.5です。

osd deep scrub stride

詳細スクラブ実行時の読み込みサイズ。デフォルトは524288 (512KB)です。

6.6 同一ノードでのSSDとHDDの混在各ノードにSSDとHDDを混在させて、一方のストレージプールを高速なSSDに、もう一方を低速な

HDDに配置するようCephクラスタを設定することが適切な場合があります。このためには、CRUSH

マップを編集する必要があります。

65 同一ノードでのSSDとHDDの混在 SES 5

デフォルトのCRUSHマップは単純な階層になっていて、デフォルトのルートにホストが含まれ、それら

のホストにOSDが含まれます。次に例を示します。

root # ceph osd tree ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 83.17899 root default -4 23.86200 host cpach 2 hdd 1.81898 osd.2 up 1.00000 1.00000 3 hdd 1.81898 osd.3 up 1.00000 1.00000 4 hdd 1.81898 osd.4 up 1.00000 1.00000 5 hdd 1.81898 osd.5 up 1.00000 1.00000 6 hdd 1.81898 osd.6 up 1.00000 1.00000 7 hdd 1.81898 osd.7 up 1.00000 1.00000 8 hdd 1.81898 osd.8 up 1.00000 1.00000 15 hdd 1.81898 osd.15 up 1.00000 1.00000 10 nvme 0.93100 osd.10 up 1.00000 1.00000 0 ssd 0.93100 osd.0 up 1.00000 1.00000 9 ssd 0.93100 osd.9 up 1.00000 1.00000

ここではディスクタイプは区別されていません。OSDをSSDとHDDに分割するには、CRUSHマップに

2つ目の階層を作成する必要があります。

root # ceph osd crush add-bucket ssd root

SSD用の新しいルートを作成したら、そこにホストを追加する必要があります。つまり、新しいホストエ

ントリを作成します。1つのCRUSHマップに同じホスト名を複数回記述することはできないため、ここ

では偽のホスト名を使用します。これらの偽のホスト名は、DNSで解決可能である必要はありませ

ん。CRUSHでは、ホスト名が何であっても問題ありません。ホスト名は適切な階層を作成するためにの

み必要です。偽のホスト名をサポートするために変更する「必要がある」のは、次の設定です。

osd crush update on start = false

これを /srv/salt/ceph/configuration/files/ceph.conf.d/global.confファイルで設定して

から、DeepSeaステージ3を実行して変更を配布する必要があります(詳細については、1.11項「カス

タムのceph.confファイル」を参照してください)。


そうしないと、移動したOSDが後でデフォルトのルートにある元の場所にリセットされ、クラスタが予期し

たとおりには動作しなくなります。

この設定を変更したら、新しい偽のホストをSSDのルートに追加します。

root # ceph osd crush add-bucket node1-ssd hostroot # ceph osd crush move node1-ssd root=ssdroot # ceph osd crush add-bucket node2-ssd host


root # ceph osd crush move node2-ssd root=ssdroot # ceph osd crush add-bucket node3-ssd hostroot # ceph osd crush move node3-ssd root=ssd

最後に、各SSD OSDについて、OSDをSSDのルートに移動します。この例では、osd.0、osd.1、および

osd.2が物理的にSSDでホストされていることを想定しています。

root # ceph osd crush add osd.0 1 root=ssdroot # ceph osd crush set osd.0 1 root=ssd host=node1-ssdroot # ceph osd crush add osd.1 1 root=ssdroot # ceph osd crush set osd.1 1 root=ssd host=node2-ssdroot # ceph osd crush add osd.2 1 root=ssdroot # ceph osd crush set osd.2 1 root=ssd host=node3-ssd

CRUSH階層は次のようになるはずです。

root # ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-5 3.00000 root ssd-6 1.00000 host node1-ssd 0 1.00000 osd.0 up 1.00000 1.00000-7 1.00000 host node2-ssd 1 1.00000 osd.1 up 1.00000 1.00000-8 1.00000 host node3-ssd 2 1.00000 osd.2 up 1.00000 1.00000-1 0.11096 root default-2 0.03699 host node1 3 0.01849 osd.3 up 1.00000 1.00000 6 0.01849 osd.6 up 1.00000 1.00000-3 0.03699 host node2 4 0.01849 osd.4 up 1.00000 1.00000 7 0.01849 osd.7 up 1.00000 1.00000-4 0.03699 host node3 5 0.01849 osd.5 up 1.00000 1.00000 8 0.01849 osd.8 up 1.00000 1.00000

続いて、SSDのルートをターゲットにするCRUSHルールを作成します。

root # ceph osd crush rule create-simple ssd_replicated_ruleset ssd host

元のデフォルトの replicated_ruleset (ID 0)はHDDをターゲットにします。新し

い ssd_replicated_ruleset (ID 1)はSSDをターゲットにします。

既存のプールはCRUSHマップのデフォルト階層にあるため、引き続きHDDを使用します。SSDのみを

使用する新しいプールを作成できます。

root # ceph osd pool create ssd-pool 64 64root # ceph osd pool set ssd-pool crush_rule ssd_replicated_ruleset


7 ストレージプールの管理

Cephはデータをプール内に保存します。プールは、オブジェクトを保存するための論理グループです。

プールを作成せずに初めてクラスタを展開した場合、Cephはデフォルトのプールを使用してデータを

保存します。プールは次の機能を提供します。

「災害耐性」: いくつのOSDに障害が発生してもデータが失われないようにするかを設定できま

す。複製プールの場合、これはオブジェクトに必要なコピー/レプリカの数になります。新しいプー

ルは、デフォルトのレプリカ数が3に設定された状態で作成されます。一般的な設定では1つの

オブジェクトと1つの追加コピーが保存されるため、レプリカ数を2に設定する必要があります。イ

レージャコーディングプールの場合、これはコーディングチャンクの数になります(すなわち、イレー

ジャコードプロファイルでm=2)。

「配置グループ」: 複数のOSDにわたるプールにデータを保存するための内部的なデータ構造で

す。CephがデータをPGに保存する方法はCRUSHマップで定義します。プールの配置グループ

の数を設定できます。一般的な設定では、OSDあたり約100個の配置グループを使用し、大量の

コンピューティングリソースを使用することなく最適なバランスを提供します。複数のプールを設

定する場合は、プールとクラスタ全体の両方にとって適切な数の配置グループを設定するよう注

意してください。

「CRUSHルール」: データをプールに保存する際、そのプールにマップされたCRUSHルール

セットにより、CRUSHは、クラスタ内にオブジェクトとそのレプリカ(イレージャコーディングプール

の場合はチャンク)を配置するためのルールを識別できます。ご使用のプールに対してカスタム

CRUSHルールを作成できます。

「スナップショット」: ceph osd pool mksnapを使用してスナップショットを作成すると、特定の

プールのスナップショットが効果的に作成されます。

「所有権の設定」: 特定のユーザIDをプールの所有者として設定できます。

データをプールに編成するために、プールを一覧、作成、および削除できます。各プールの使用量統計

を表示することもできます。

7.1 プールとアプリケーションの関連付けプールを使用する前に、プールをアプリケーションに関連付ける必要があります。CephFSで使用され

るプール、またはObject Gatewayによって自動的に作成されるプールは自動的に関連付けられま

す。RBDで使用する予定のプールは、 rbdツールを使用して初期化する必要があります(詳細について

は、8.1項「Block Deviceのコマンド」を参照してください)。

68 プールとアプリケーションの関連付け SES 5

それ以外の場合は、自由な形式のアプリケーション名を手動でプールに関連付けることができます。

root # ceph osd pool application enable pool_name application_name

ヒント: デフォルトのアプリケーション名アプリケーション名として、CephFSは cephfs 、RADOS Block Deviceは rbd 、Object

Gatewayは rgwをそれぞれ使用します。

1つのプールを複数のアプリケーションに関連付けて、各アプリケーションで専用のメタデータを使用で

きます。次のコマンドを使用して、指定したプールのアプリケーションのメタデータを表示できます。

root # ceph osd pool application get pool_name

7.2 プールの操作このセクションでは、プールで基本的なタスクを実行するための実用的な情報を紹介します。プールの

一覧、作成、削除の方法と、プールの統計の表示方法、プールのスナップショットの管理方法を理解で

きます。

7.2.1 プールの一覧

クラスタのプールを一覧にするには、次のコマンドを実行します。

root # ceph osd lspools0 rbd, 1 photo_collection, 2 foo_pool,

7.2.2 プールの作成

複製プールを作成するには、次のコマンドを実行します。

root # ceph osd pool create pool_name pg_num pgp_num replicated crush_ruleset_name \expected_num_objects

イレージャコーディングプールを作成するには、次のコマンドを実行します。

root # ceph osd pool create pool_name pg_num pgp_num erasure erasure_code_profile \

69 プールの操作 SES 5

crush_ruleset_name expected_num_objects

OSDあたりの配置グループの制限を超える場合、 ceph osd pool createは失敗する可能性があり

ます。この制限はオプション mon_max_pg_per_osdで設定します。

pool_name

プールの名前。固有である必要があります。このオプションは必須です。

pg_num

プールの配置グループの合計数。このオプションは必須です。デフォルト値は8です。

pgp_num

配置目的の配置グループの合計数。配置グループ分割シナリオ以外では、配置グループの合計

数と等しい必要があります。このオプションは必須です。デフォルト値は8です。

pgp_type

プールタイプ。オブジェクトのコピーを複数保持することによってOSDの損失から回復するには

「replicated」、一種の汎用RAID5機能を利用するには「erasure」を指定できます。複製プール

の場合、必要な未加工ストレージが増えますが、Cephのすべての操作が実装されます。イレー

ジャコーディングプールの場合、必要な未加工ストレージは減りますが、利用可能な操作のサブ

セットのみが実装されます。デフォルトは「replicated」です。

crush_ruleset_name

このプールのCRUSHルールセットの名前。指定したルールセットが存在しない場

合、複製プールの作成は-ENOENTで失敗します。ただし、複製プールは、指定した

名前を持つ新しいイレージャルールセットを作成します。イレージャコーディングプー

ルのデフォルト値は「erasure-code」です。複製プールに対しては、Ceph設定変

数 osd_pool_default_crush_replicated_rulesetを選択します。

erasure_code_profile=profile

イレージャコーディングプール専用。イレージャコードプロファイルを使用します。 osd erasure-

code-profile setで定義した既存のプロファイルである必要があります。

プールを作成する際、配置グループの数を適切な値(たとえば100)に設定します。OSDあたりの

配置グループの合計数も考慮してください。配置グループは計算コストが高いため、多数の配置

グループが含まれるプールが大量にあると(たとえば、50個のプールと、それぞれに100個の配

置グループ)、パフォーマンスが低下します。増加に応じた効果が得られなくなるポイントは、OSD

ホストの能力によって異なります。

プールに適した配置グループ数の計算の詳細については、「Placement Groups (http://

docs.ceph.com/docs/master/rados/operations/placement-groups/) 」を参照してくだ

さい。

70 プールの作成 SES 5

http://docs.ceph.com/docs/master/rados/operations/placement-groups/

http://docs.ceph.com/docs/master/rados/operations/placement-groups/

expected_num_objects

このプールの想定オブジェクト数。この値を設定すると、プールの作成時にPGフォルダが分割さ

れます。これにより、ランタイム時のフォルダ分割によるレイテンシの影響が避けられます。

7.2.3 プールクォータの設定

最大バイト数、またはプールあたりのオブジェクトの最大数に対してプールクォータを設定できます。

root # ceph osd pool set-quota pool-name max_objects obj-count max_bytes bytes


root # ceph osd pool set-quota data max_objects 10000

クォータを削除するには、値を0に設定します。

7.2.4 プールの削除

警告: プールの削除は元に戻せないプールには重要なデータが収められている場合があります。プールを削除すると、プール内のす

べてのデータが消え、回復する方法はありません。

誤ってプールを削除することはきわめて危険であるため、Cephには、プールの削除を防止するメカニ

ズムが2つ実装されています。プールを削除するには、両方のメカニズムを無効にする必要があります。

1つ目のメカニズムは NODELETEフラグです。各プールにこのフラグがあり、デフォルト値は「false」で

す。プールのこのフラグのデフォルト値を確認するには、次のコマンドを実行します。

root # ceph osd pool get pool_name nodelete

nodelete: trueが出力される場合、次のコマンドを使用してフラグを変更しない限り、プールを削除

できません。

ceph osd pool set pool_name nodelete false

2つ目のメカニズムは、クラスタ全体の設定パラメータ mon allow pool deleteで、デフォルトは

「false」です。つまり、デフォルトではプールを削除できません。表示されるエラーメッセージは次のとお

りです。

71 プールクォータの設定 SES 5

Error EPERM: pool deletion is disabled; you must first set themon_allow_pool_delete config option to true before you can destroy a pool

この安全設定に関係なくプールを削除するには、 mon allow pool deleteを一時的に「true」に設

定してプールを削除し、その後、パラメータを「false」に戻します。

root # ceph tell mon.* injectargs --mon-allow-pool-delete=trueroot # ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-itroot # ceph tell mon.* injectargs --mon-allow-pool-delete=false

injectargsコマンドを実行すると、次のメッセージが表示されます。

injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

これは単にコマンドが正常に実行されたことを確認するものです。エラーではありません。

作成したプール用に独自のルールセットとルールを作成した場合、プールが必要なくなったらルール

セットとルールを削除することをお勧めします。存在しなくなったプール専用の許可を持つユーザを作成

した場合は、それらのユーザの削除も検討することをお勧めします。

7.2.5 プールの名前変更

プールの名前を変更するには、次のコマンドを実行します。

root # ceph osd pool rename current-pool-name new-pool-name

プールの名前を変更する場合に、認証ユーザ用のプールごとのケーパビリティがあるときは、そのユー

ザのケーパビリティを新しいプール名で更新する必要があります。

7.2.6 プール統計の表示

プールの使用量統計を表示するには、次のコマンドを実行します。

root # rados dfpool name category KB objects lones degraded unfound rd rd KB wr wr KBcold-storage - 228 1 0 0 0 0 0 1 228data - 1 4 0 0 0 0 0 4 4hot-storage - 1 2 0 0 0 15 10 5 231metadata - 0 0 0 0 0 0 0 0 0pool1 - 0 0 0 0 0 0 0 0 0rbd - 0 0 0 0 0 0 0 0 0total used 266268 7total avail 27966296

72 プールの名前変更 SES 5

total space 28232564

7.2.7 プールの値の設定

プールに値を設定するには、次のコマンドを実行します。

root # ceph osd pool set pool-name key value

次のキーの値を設定できます。

size

プール内のオブジェクトのレプリカ数を設定します。詳細については、7.2.9項「オブジェクトレプ

リカの数の設定」を参照してください。複製プール専用です。

min_size

I/Oに必要なレプリカの最小数を設定します。詳細については、7.2.9項「オブジェクトレプリカの

数の設定」を参照してください。複製プール専用です。

crash_replay_interval

確認済みであるもののコミットされていない要求の再生をクライアントに許可する秒数。

pg_num

プールの配置グループの数。OSDをクラスタに追加する場合、配置グループの値を増やす必要

があります。詳細については、7.2.11項「配置グループの数の増加」を参照してください。

pgp_num

データ配置を計算する際に使用する配置グループの有効数。

crush_ruleset

クラスタ内のオブジェクト配置のマッピングに使用するルールセット。

hashpspool

指定したプールに対してHASHPSPOOLフラグを設定(1)または設定解除(0)します。この

フラグを有効にすると、PGをOSDに効率的に分散するためにアルゴリズムが変更されま

す。HASHPSPOOLフラグが0に設定されたプールでこのフラグを有効にすると、クラスタは、す

べてのPGをもう一度正しく配置するためにバックフィルを開始します。これはクラスタに多大な

I/O負荷をかける可能性があるので、非常に負荷が高い運用クラスタでは適切な計画が必要で

す。

nodelete

プールの削除を防止します。

73 プールの値の設定 SES 5

nopgchange

プールの pg_numおよび pgp_numの変更を防止します。

nosizechange

プールのサイズの変更を防止します。

write_fadvise_dontneed

指定したプールに対して WRITE_FADVISE_DONTNEEDフラグを設定/設定解除します。

noscrub、nodeep-scrub

I/Oの一時的な高負荷を解決するため、特定のプールに対してデータの(詳細)スクラブを無効に

します。

hit_set_type

キャッシュプールのヒットセットの追跡を有効にします。詳細については、「Bloom Filter (http://

en.wikipedia.org/wiki/Bloom_filter) 」を参照してください。このオプションに設定できる値

は、 bloom 、 explicit_hash 、または explicit_objectです。デフォルトは bloomで、他の値

はテスト専用です。

hit_set_count

キャッシュプールに関して保存するヒットセットの数。値を増やすほど、 ceph-osdデーモンの

RAM消費量が増えます。デフォルトは 0です。

hit_set_period

キャッシュプールのヒットセットの期間(秒単位)。値を増やすほど、 ceph-osdデーモンのRAM消

費量が増えます。

hit_set_fpp

bloomヒットセットタイプの誤検知確率。詳細については、「Bloom Filter (http://

en.wikipedia.org/wiki/Bloom_filter) 」を参照してください。有効な範囲は0.0〜1.0で、デ

フォルトは 0.05です。

use_gmt_hitset

キャッシュ階層化のヒットセットを作成する際に、GMT (グリニッジ標準時)のタイムスタンプを使

用するようOSDに強制します。これにより、異なるタイムゾーンにあるノードが同じ結果を返すよう

にします。デフォルトは 1です。この値は変更できません。

cache_target_dirty_ratio

キャッシュプールに含まれる変更済みオブジェクトの割合で、この割合を超えると、キャッシュ階

層化エージェントは変更済み(ダーティ)オブジェクトをバッキングストレージプールにフラッシュし

ます。デフォルトは .4です。


http://en.wikipedia.org/wiki/Bloom_filter




cache_target_dirty_high_ratio

キャッシュプールに含まれる変更済みオブジェクトの割合で、この割合を超えると、キャッシュ階

層化エージェントは変更済み(ダーティ)オブジェクトをより高速なバッキングストレージプールに

フラッシュします。デフォルトは .6です。

cache_target_full_ratio

キャッシュプールに含まれる未変更オブジェクトの割合で、この割合を超えると、キャッシュ階層

化エージェントは未変更(クリーン)オブジェクトをキャッシュプールから削除します。デフォルト

は .8です。

target_max_bytes

max_bytesのしきい値がトリガされた場合、Cephはオブジェクトのフラッシュまたは削除を開始

します。

target_max_objects

max_objectsのしきい値がトリガされた場合、Cephはオブジェクトのフラッシュまたは削除を開

始します。

hit_set_grade_decay_rate

連続する2つの hit_set間の温度減衰率。デフォルトは 20です。

hit_set_search_last_n

温度を計算するために、 hit_set内で最大 N個の出現をカウントします。デフォルトは 1です。

cache_min_flush_age

キャッシュ階層化エージェントがオブジェクトをキャッシュプールからストレージプールへフラッ

シュするまでの時間(秒単位)。

cache_min_evict_age

キャッシュ階層化エージェントがオブジェクトをキャッシュプールから削除するまでの時間(秒単

位)。

fast_read

イレージャコーディングプールでこのフラグが有効な場合、読み込み要求は、すべてのシャードに

対してサブ読み込みを発行し、クライアントの要求を実行するためにデコードする十分なシャード

を受け取るまで待機します。イレージャプラグインがjerasureおよびisaの場合、最初の K個の応

答が返された時点で、これらの応答からデコードされたデータを使用してただちにクライアントの

要求が実行されます。これは、パフォーマンスを向上させるために若干のリソースを取得するのに

役立ちます。現在のところ、このフラグはイレージャコーディングプールでのみサポートされます。

デフォルトは 0です。


scrub_min_interval

クラスタの負荷が低い場合にプールをスクラブする最小間隔(秒単位)。デフォルトの 0は、Ceph

設定ファイルの osd_scrub_min_intervalの値が使用されることを意味します。

scrub_max_interval

クラスタの負荷に関係なくプールをスクラブする最大間隔(秒単位)。デフォルトの 0は、Ceph設

定ファイルの osd_scrub_max_intervalの値が使用されることを意味します。

deep_scrub_interval

プールの「詳細」スクラブの間隔(秒単位)。デフォルトの 0は、Ceph設定ファイル

の osd_deep_scrubの値が使用されることを意味します。

7.2.8 プールの値の取得

プールから値を取得するには、次のコマンドを実行します。

root # ceph osd pool get pool-name key

7.2.7項「プールの値の設定」に示すキーと、次のキーの値を取得できます。

pg_num

プールの配置グループの数。

pgp_num

データ配置を計算する際に使用する配置グループの有効数。有効な範囲は pg_num以下です。

7.2.9 オブジェクトレプリカの数の設定

複製プール上のオブジェクトレプリカの数を設定するには、次のコマンドを実行します。

root # ceph osd pool set poolname size num-replicas

num-replicasにはオブジェクトそのものも含まれます。たとえば、オブジェクトとそのオブジェクトの2

つのコピーで合計3つのオブジェクトインスタンスが必要な場合、3を指定します。

num-replicasを2に設定した場合、データのコピーは「1つ」だけになります。1つのオブジェクトイ

ンスタンスが失われた場合、たとえば回復中の前回のスクラブ (http://ceph.com/docs/master/

rados/configuration/osd-config-ref/#scrubbing) 以降に、他のコピーが壊れていないことを信

頼する必要があります。

76 プールの値の取得 SES 5

http://ceph.com/docs/master/rados/configuration/osd-config-ref/#scrubbing

http://ceph.com/docs/master/rados/configuration/osd-config-ref/#scrubbing

プールを1つのレプリカに設定することは、プール内にデータオブジェクトのインスタンスが「1つ」だけ

存在することを意味します。OSDに障害発生すると、データは失われます。レプリカが1つのプールの使

用法としては、一時データを短時間保存することが考えられます。

1つのプールにレプリカを4つ以上設定しても信頼性の向上はごくわずかで、まれな事例にしか適さな

い場合があります。レプリカを増やすほど、オブジェクトのコピーを保存するために必要なディスク領域

が増えることを覚えておいてください。最高のデータセキュリティが必要な場合は、イレージャコーディン

グプールを使用することをお勧めします。詳細については、第9章「イレージャコーディングプール」を参

照してください。

警告: 3つ以上のレプリカを推奨2つだけのレプリカは使用しないことを強くお勧めします。一方のOSDに障害が発生した場合、

回復中の高いワークロードによって2つ目のOSDにもほぼ確実に障害が発生します。


root # ceph osd pool set data size 3

各プールに対してこのコマンドを実行できます。

注記1つのオブジェクトが、機能低下モードにおいてレプリカが pool size未満の状態でI/Oを受け

付ける場合があります。I/Oに必要なレプリカの最小数を設定するには、 min_size設定を使用

する必要があります。次に例を示します。

root # ceph osd pool set data min_size 2

これにより、データプール内のオブジェクトはレプリカが min_size未満の場合、I/Oを受け取ら

なくなります。

7.2.10 オブジェクトレプリカの数の取得

オブジェクトレプリカの数を取得するには、次のコマンドを実行します。

root # ceph osd dump | grep 'replicated size'

replicated size属性が強調表示された状態でプールが一覧にされます。デフォルトでは、Cephは

オブジェクトのレプリカを2つ作成します(合計で3つのコピー、またはサイズ3)。

77 オブジェクトレプリカの数の取得 SES 5

7.2.11 配置グループの数の増加

新しいプールを作成する際、プールの配置グループの数を指定します(7.2.2項「プールの作成」を参

照してください)。パフォーマンスおよびデータの持続性の理由から、通常、クラスタに別のOSDを追加

した後、配置グループの数も増やす必要があります。OSDおよびMonitorノードには、配置グループご

とに常にメモリ、ネットワーク、およびCPUが必要で、回復時にはそれ以上の量が必要です。したがって、

配置グループの数を最小限に抑えると、リソースの量を大幅に節約できます。

警告: 高すぎるpg_numの値プールの pg_numの値を変更すると、配置グループの新しい数が許可されている制限を超える

ことがあります。次に例を示します。

root # ceph osd pool set rbd pg_num 4096 Error E2BIG: specified pg_num 3500 is too large (creating 4096 new PGs \ on ~64 OSDs exceeds per-OSD max of 32)

この制限は、配置グループが極端に分割されるのを防ぐもの

で、 mon_osd_max_split_countの値から派生されます。

サイズを変更したクラスタの配置グループに適した新しい数を判断するのは複雑なタスクです。1つの

方法は、クラスタのパフォーマンスが最適な状態になるまで、配置グループの数を連続的に増やしてい

く方法です。新しく増やした配置グループ数を判断するには、 mon_osd_max_split_countパラメータ

の値を取得して、それを配置グループの現在の数に追加する必要があります。基本的な考え方を理解

するため、次のスクリプトを見てください。

cephadm > max_inc=`ceph daemon mon.a config get mon_osd_max_split_count 2>&1 \ | tr -d '\n ' | sed 's/.*"$[[:digit:]]\+$".*/\1/'`cephadm > pg_num=`ceph osd pool get rbd pg_num | cut -f2 -d: | tr -d ' '`cephadm > echo "current pg_num value: $pg_num, max increment: $max_inc"cephadm > next_pg_num="$(($pg_num+$max_inc))"cephadm > echo "allowed increment of pg_num: $next_pg_num"

配置グループの次の数がわかったら、次のコマンドを使用して数を増やします。

root # ceph osd pool set pool_name pg_num next_pg_num

7.2.12 プールの追加

初めてクラスタを展開した後、Cephはデフォルトのプールを使用してデータを保存します。後で、次のコ

マンドを使用して新しいプールを作成できます。

78 配置グループの数の増加 SES 5

root # ceph osd pool create

クラスタプールの作成の詳細については、7.2.2項「プールの作成」を参照してください。

7.3 プールのマイグレーションプールを作成する際(7.2.2項「プールの作成」を参照)、プールのタイプや配置グループの数など、初

期パラメータを指定する必要があります。後日、プールをデータに配置した後にこれらのパラメータを変

更する場合、プールのデータを、ご使用の展開環境に適したパラメータが設定された別のプールに移

行する必要があります。

プールのマイグレーションには複数の方法があります。「キャッシュ層」を使用することをお勧めします。

この方法は透過的で、クラスタのダウンタイムを短縮し、すべてのプールのデータが重複するのを避け

られます。

7.3.1 キャッシュ層を使用した移行原理は単純で、移行する必要があるプールを逆の順番でキャッシュ層に含めます。キャッシュ層の詳細

については、第10章「キャッシュ階層化」を参照してください。たとえば、「testpool」という名前の複製

プールをイレージャコーディングプールに移行するには、次の手順に従います。

手順 7.1: 複製プールからイレージャコーディングプールへの移行

1. 「newpool」という名前の新しいイレージャコーディングプールを作成します。

root@minion > ceph osd pool create newpool 4096 4096 erasure default

これでプールが2つできました。データが入った元の複製プール「testpool」と、新しい空のイレー

ジャコーディングプール「newpool」です。

図 7.1: マイグレーション前のプール

2. キャッシュ層をセットアップして、複製プール「testpool」をキャッシュプールとしてセットアップし

ます。

root@minion > ceph osd tier add newpool testpool --force-nonempty

79 プールのマイグレーション SES 5

root@minion > ceph osd cache-mode testpool forward

これ以降、新しいオブジェクトはすべて新しいプールに作成されます。

図 7.2: キャッシュ層のセットアップ

3. キャッシュプールからすべてのオブジェクトを新しいプールに強制的に移動します。

root@minion > rados -p testpool cache-flush-evict-all

図 7.3: データのフラッシュ

4. すべてのクライアントを新しいプールに切り替えます。すべてのデータが新しいイレージャコー

ディングプールにフラッシュされるまでは、オーバーレイを指定してオブジェクトが古いプールで

検索されるようにする必要があります。

root@minion > ceph osd tier set-overlay newpool testpool

このオーバーレイにより、すべての操作が古い複製プール「testpool」に転送されます。

図 7.4: オーバーレイの設定

これで、新しいプールのオブジェクトにアクセスするようすべてのクライアントを切り替えることが

できます。

5. すべてのデータがイレージャコーディングプール「newpool」に移行されたら、オーバーレイと古

いキャッシュプール「testpool」を削除します。

80 キャッシュ層を使用した移行 SES 5

root@minion > ceph osd tier remove-overlay newpoolroot@minion > ceph osd tier remove newpool testpool

図 7.5: マイグレーションの完了

7.4 プールのスナップショットプールのスナップショットは、Cephのプール全体の状態のスナップショットです。プールのスナップ

ショットにより、プールの状態の履歴を保持できます。プールのサイズによっては、プールのスナップ

ショットの作成に大量のストレージ領域が必要になる場合があります。プールのスナップショットを作成

する前に、必ず関連するストレージに十分なディスク領域があることを確認してください。

7.4.1 プールのスナップショットの作成

プールのスナップショットを作成するには、次のコマンドを実行します。

root # ceph osd pool mksnap pool-name snap-name


root # ceph osd pool mksnap pool1 snapshot1created pool pool1 snap snapshot1

7.4.2 プールのスナップショットの削除

プールのスナップショットを削除するには、次のコマンドを実行します。

root # ceph osd pool rmsnap pool-name snap-name

81 プールのスナップショット SES 5

7.5 データ圧縮SUSE Enterprise Storage 5から、BlueStoreはディスク領域の節約のためにオンザフライのデータ

圧縮を提供しています。

7.5.1 圧縮の有効化次のコマンドを使用して、プールのデータ圧縮を有効にできます。

root # ceph osd pool set POOL_NAME ompression_algorithm snappyroot # ceph osd pool set POOL_NAME compression_mode aggressive

POOL_NAMEは、圧縮を有効にするプールに置き換えてください。

7.5.2 プール圧縮オプション次に、すべての圧縮設定のリストを示します。

compression_algorithm

値: none 、 zstd 、 snappy 。デフォルト: snappy 。

どの圧縮アルゴリズムを使用するかは、特定の使用事例によって異なります。次に推奨事項をい

くつか示します。

zlibは使用しないでください。他のアルゴリズムの方が効率的です。

高い圧縮率が必要な場合は、 zstdを使用します。小容量データを圧縮する際のCPUオー

バーヘッドが高いため、BlueStoreでは zstdは推奨されないことに注意してください。

低いCPU使用量が必要な場合は、 lz4または snappyを使用します。

クラスタのCPUとメモリの使用量に注意しながら、実際のデータのサンプルに対してこれら

のアルゴリズムのベンチマークを実行します。

compression_mode

値: none 、 aggressive 、 passive 、 force 。デフォルト: none 。

none : 圧縮しません。

passive : COMPRESSIBLEと表示されている場合、圧縮します。

aggressive : INCOMPRESSIBLEと表示されている場合以外、圧縮します。

force : 常に圧縮します。

82 データ圧縮 SES 5

COMPRESSIBLEまたは INCOMPRESSIBLEのフラグを設定する方法の詳細について

は、http://docs.ceph.com/docs/doc-12.2.0-major-changes/rados/api/librados/

#rados_set_alloc_hint を参照してください。

compression_required_ratio

値: 倍精度、比率= SIZE_COMPRESSED / SIZE_ORIGINAL。デフォルト: .875 。

この率を上回るオブジェクトは、圧縮効果が低いため圧縮状態では保存されません。

compression_max_blob_size

値: 符号なし整数、バイト単位のサイズ。デフォルト: 0 。

圧縮されるオブジェクトの最大サイズ。

compression_min_blob_size


圧縮されるオブジェクトの最小サイズ。

7.5.3 グローバル圧縮オプション

次の設定オプションはCeph設定で指定でき、1つのプールだけでなくすべてのOSDに適用されま

す。7.5.2項「プール圧縮オプション」に一覧にされているプール固有の設定が優先されます。

bluestore_compression_algorithm

値: none 、 zstd 、 snappy 、 zlib 。デフォルト: snappy 。

どの圧縮アルゴリズムを使用するかは、特定の使用事例によって異なります。次に推奨事項をい

くつか示します。

zlibは使用しないでください。他のアルゴリズムの方が効率的です。

高い圧縮率が必要な場合は、 zstdを使用します。小容量データを圧縮する際のCPUオー

バーヘッドが高いため、BlueStoreでは zstdは推奨されないことに注意してください。

低いCPU使用量が必要な場合は、 lz4または snappyを使用します。

クラスタのCPUとメモリの使用量に注意しながら、実際のデータのサンプルに対してこれら

のアルゴリズムのベンチマークを実行します。

bluestore_compression_mode

値: none 、 aggressive 、 passive 、 force 。デフォルト: none 。

none : 圧縮しません。

passive : COMPRESSIBLEと表示されている場合、圧縮します。

83 グローバル圧縮オプション SES 5

http://docs.ceph.com/docs/doc-12.2.0-major-changes/rados/api/librados/#rados_set_alloc_hint


aggressive : INCOMPRESSIBLEと表示されている場合以外、圧縮します。

force : 常に圧縮します。

COMPRESSIBLEまたは INCOMPRESSIBLEのフラグを設定する方法の詳細について

は、http://docs.ceph.com/docs/doc-12.2.0-major-changes/rados/api/librados/

#rados_set_alloc_hint を参照してください。

bluestore_compression_required_ratio

値: 倍精度、比率= SIZE_COMPRESSED / SIZE_ORIGINAL。デフォルト: .875 。

この率を上回るオブジェクトは、圧縮効果が低いため圧縮状態では保存されません。

bluestore_compression_min_blob_size


圧縮されるオブジェクトの最小サイズ。

bluestore_compression_max_blob_size


圧縮されるオブジェクトの最大サイズ。

bluestore_compression_min_blob_size_ssd

値: 符号なし整数、バイト単位のサイズ。デフォルト: 8K 。

圧縮してソリッドステートドライブに保存されるオブジェクトの最小サイズ。

bluestore_compression_max_blob_size_ssd


圧縮してソリッドステートドライブに保存されるオブジェクトの最大サイズ。

bluestore_compression_min_blob_size_hdd


圧縮してハードディスクに保存されるオブジェクトの最小サイズ。

bluestore_compression_max_blob_size_hdd


圧縮してハードディスクに保存されるオブジェクトの最大サイズ。

84 グローバル圧縮オプション SES 5



8 RADOS Block Device

ブロックとは連続するバイトのことで、たとえば512バイトブロックのデータなどです。ブロックベースの

ストレージインタフェースは、ハードディスク、CD、フロッピーディスクなどの回転型媒体にデータを保存

する最も一般的な方法です。Block Deviceインタフェースはあらゆるところで利用されているため、仮

想ブロックデバイスは、Cephのような大容量データストレージシステムを操作するための理想的な候

補です。

Ceph Block Deviceは物理リソースを共有でき、サイズの変更が可能です。データはCephクラス

タ内の複数のOSD上にストライプされて保存されます。Ceph Block Deviceは、スナップショットの

作成、レプリケーション、整合性などのRADOSの機能を利用します。CephのRBD (RADOS Block

Device)は、カーネルモジュールまたは librbdライブラリを使用してOSDと対話します。

図 8.1: RADOSプロトコル

Cephのブロックデバイスは、高いパフォーマンスと無限のスケーラビリティをカーネルモジュールに

提供します。これらは、QEMUなどの仮想化ソリューションや、OpenStackなど、 libvirtに依存

するクラウドベースのコンピューティングシステムをサポートします。同じクラスタを使用して、Object

Gateway、CephFS、およびRADOS Block Deviceを同時に運用できます。

8.1 Block Deviceのコマンドrbdコマンドを使用して、Block Deviceイメージを作成、一覧、イントロスペクト、および削除できます。

さらに、イメージのクローン作成、スナップショットの作成、スナップショットへのイメージのロールバック、

スナップショットの表示などの操作にも使用できます。

ヒント: クラスタへのアクセスRADOS Block Deviceのコマンドを使用するには、実行中のCephクラスタにアクセスできる

必要があります。

8.1.1 Block Deviceイメージの作成Block Deviceをノードに追加する前に、クラスタ内にそのイメージを作成する必要があります。Block

Deviceイメージを作成するには、次のコマンドを実行します。

85 Block Deviceのコマンド SES 5

root # rbd create --size megabytes pool-name/image-name

たとえば、「swimmingpool」という名前のプールに情報を保存する「bar」という名前の1GBのイメー

ジを作成するには、次のコマンドを実行します。

root # rbd create --size 1024 swimmingpool/bar

ヒント: デフォルトのプールイメージの作成時にプールを指定しなかった場合、イメージはデフォルトのプール「rbd」に保存

されます。

注記: プールを最初に作成プールをソースとして指定する前に、まずプールを作成する必要があります。詳細については、第

7章「ストレージプールの管理」を参照してください。

8.1.2 イレージャコーディングプールでのBlock Deviceイメージの作成

SUSE Enterprise Storage 5から、Block Deviceイメージのデータをイレージャコーディングプール

に保存できます。イレージャコーディングプールに保存できるのは、RBDイメージの「データ」部分のみ

です。さらに、イレージャコーディングプールで「overwrite」フラグが「true」に設定されている必要があ

ります。このフラグを「true」に設定できるのは、すべてのOSDがBlueStoreを使用している場合だけで

す。

イメージのメタデータをイレージャコーディングプールに存在させることはできません。メタデータは、デ

フォルトの「rbd」プールか、ユーザがパラメータ --pool= を rbd createコマンドで明示的に指定し

たプールにのみ存在できます。

注記: BlueStoreが必須Block Deviceイメージにイレージャコーディングプールを使用するには、すべてのノードに

BlueStoreが必要です。

イレージャコーディングプール内にRBDイメージを作成するには、次の手順を使用します。

root # ceph osd pool create POOL_NAME 12 12 erasureroot # ceph osd pool set POOL_NAME allow_ec_overwrites true

86 イレージャコーディングプールでのBlock Deviceイメージの作成 SES 5

# Metadata will reside in pool "rbd", and data in pool "POOL_NAME"root # rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME

#Metadata will reside in pool "OTHER_POOL", and data in pool "POOL_NAME"root # rbd create IMAGE_NAME --size=1G --data-pool POOL_NAME --pool=OTHER_POOL

8.1.3 Block Deviceイメージの一覧

「rbd」プール内のBlock Deviceを一覧にするには、次のコマンドを実行します(「rbd」はデフォルトの

プール名です)。

root # rbd ls

「swimmingpool」という名前のプール内のBlock Deviceを一覧にするには、次のコマンドを実行しま

す。

root # rbd ls swimmingpool

8.1.4 イメージ情報の取得

「swimmingpool」という名前のプール内のイメージ「bar」から情報を取得するには、次のコマンドを実

行します。

root # rbd info swimmingpool/bar

8.1.5 Block Deviceイメージのサイズの変更

RADOS Block Deviceイメージはシンプロビジョニングされます。つまり、そこにデータを保存し始め

るまでは、実際に物理ストレージを使用しません。ただし、 --sizeオプションで設定する最大容量があ

ります。イメージの最大サイズを増やす(または減らす)場合、次のコマンドを実行します。

root # rbd resize --size 2048 foo # to increaserbd resize --size 2048 foo --allow-shrink # to decrease

8.1.6 Block Deviceイメージの削除

「swimmingpool」という名前のプール内にあるイメージ「bar」に対応するBlock Deviceを削除する

には、次のコマンドを実行します。

87 Block Deviceイメージの一覧 SES 5

root # rbd rm swimmingpool/bar

8.2 RBDイメージのマウントとアンマウントRADOS Block Deviceを作成した後、デバイスをフォーマットし、マウントしてファイルを交換できるよう

にし、完了したらアンマウントできます。

1. Cephクラスタに、マウントするディスクイメージが存在するプールが含まれることを確認します。

プールは mypool 、イメージは myimageという名前であると想定します。

rbd list mypool

2. イメージを新しいBlock Deviceにマップします。

root # rbd map --pool mypool myimage

ヒント: ユーザ名と認証ユーザ名を指定するには、 --id user-nameを使用します。さらに、 cephx認証を使用す

る場合は、秘密も指定する必要があります。秘密は、キーリング、または秘密が含まれる

ファイルから取得できます。

root # rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

または

root # rbd map --pool rbd myimage --id admin --keyfile /path/to/file

3. すべてのマップ済みデバイスを一覧にします。

root # rbd showmapped id pool image snap device 0 mypool myimage - /dev/rbd0

作業対象のデバイスは /dev/rbd0です。

4. /dev/rbd0デバイス上にXFSファイルシステムを作成します。

root # mkfs.xfs /dev/rbd0 log stripe unit (4194304 bytes) is too large (maximum is 256KiB) log stripe unit adjusted to 32KiB meta-data=/dev/rbd0 isize=256 agcount=9, agsize=261120 blks

88 RBDイメージのマウントとアンマウント SES 5

= sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=2097152, imaxpct=25 = sunit=1024 swidth=1024 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=8 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

5. デバイスをマウントして、正しくマウントされていることを確認します。 /mntは、使用するマウントポ

イントに置き換えてください。

root # mount /dev/rbd0 /mntroot # mount | grep rbd0/dev/rbd0 on /mnt type xfs (rw,relatime,attr2,inode64,sunit=8192,...

これで、ローカルディレクトリと同じように、このデバイスとの間でデータを移動できます。

ヒント: RBDデバイスのサイズの増加RBDデバイスのサイズが十分ではなくなった場合、簡単にサイズを増やすことができま

す。

1. RBDイメージのサイズを、たとえば10GBに増やします。

root # rbd resize --size 10000 mypool/myimage Resizing image: 100% complete...done.

2. デバイスの新しいサイズ全体を使用するようファイルシステムを拡張します。

root # xfs_growfs /mnt [...] data blocks changed from 2097152 to 2560000

6. デバイスへのアクセスが終わったら、デバイスをアンマウントできます。

root # unmount /mnt

ヒント: 手動でのマウントとアンマウントブート後にRBDイメージを手動でマップしてマウントし、シャットダウン前にアンマウントしてマッ

プ解除するのは煩雑であるため、 rbdmapスクリプトと systemdユニットが提供されていま

す。8.4項「rbdmap: ブート時のRBDデバイスのマップ」を参照してください。

89 RBDイメージのマウントとアンマウント SES 5

8.3 Block DeviceのスナップショットRBDのスナップショットは、RADOS Block Deviceイメージのスナップショットです。スナップショット

により、イメージの状態の履歴を保持します。Cephはスナップショットの階層化もサポートしており、VM

イメージのクローンを素早く簡単に作成できます。 rbdコマンド、およびさまざまな高レベルのインタ

フェース(QEMU、 libvirt 、OpenStack、CloudStackなど)を使用したBlock Deviceのスナップ

ショットをサポートしています。

注記イメージのスナップショットを作成する前に、入出力操作を停止してください。イメージにファイル

システムが含まれる場合、スナップショットを作成する「前」に、そのファイルシステムが整合性の

ある状態である必要があります。

8.3.1 Cephxに関する注意事項

cephxが有効な場合(詳細については、http://ceph.com/docs/master/rados/configuration/

auth-config-ref/ を参照)、ユーザ名またはIDと、そのユーザに対応する鍵が含まれるキーリングの

パスを指定する必要があります。詳細については、「User Management (http://ceph.com/docs/

master/rados/operations/user-management/) 」を参照してください。以降のパラメータを再入

力せずに済むよう、 CEPH_ARGS環境変数を追加することもできます。

root # rbd --id user-ID --keyring=/path/to/secret commandsroot # rbd --name username --keyring=/path/to/secret commands


root # rbd --id admin --keyring=/etc/ceph/ceph.keyring commandsroot # rbd --name client.admin --keyring=/etc/ceph/ceph.keyring commands

ヒントCEPH_ARGS環境変数にユーザと秘密を追加して、毎回入力しなくて済むようにします。

8.3.2 スナップショットの基本

次の手順では、コマンドラインで rbdを使用して、スナップショットを作成、一覧、および削除する方法を

説明します。

90 Block Deviceのスナップショット SES 5

http://ceph.com/docs/master/rados/configuration/auth-config-ref/

http://ceph.com/docs/master/rados/configuration/auth-config-ref/

http://ceph.com/docs/master/rados/operations/user-management/

http://ceph.com/docs/master/rados/operations/user-management/

8.3.2.1 スナップショットの作成

rbdを使用してスナップショットを作成するには、 snap createオプション、プール名、およびイメージ

名を指定します。

root # rbd --pool pool-name snap create --snap snap-name image-nameroot # rbd snap create pool-name/image-name@snap-name


root # rbd --pool rbd snap create --snap snapshot1 image1root # rbd snap create rbd/image1@snapshot1

8.3.2.2 スナップショットの一覧

イメージのスナップショットを一覧にするには、プール名とイメージ名を指定します。

root # rbd --pool pool-name snap ls image-nameroot # rbd snap ls pool-name/image-name


root # rbd --pool rbd snap ls image1root # rbd snap ls rbd/image1

8.3.2.3 スナップショットのロールバック

rbdを使用して特定のスナップショットにロールバックするには、 snap rollbackオプション、プール

名、イメージ名、およびスナップショット名を指定します。

root # rbd --pool pool-name snap rollback --snap snap-name image-nameroot # rbd snap rollback pool-name/image-name@snap-name


root # rbd --pool pool1 snap rollback --snap snapshot1 image1root # rbd snap rollback pool1/image1@snapshot1

91 スナップショットの基本 SES 5

注記イメージをスナップショットにロールバックすることは、イメージの現在のバージョンをスナップ

ショットのデータで上書きすることを意味します。ロールバックの実行にかかる時間は、イメージ

のサイズに応じて長くなります。イメージをスナップショットに「ロールバック」するよりもスナップ

ショットから「クローンを作成する方が高速」であり、以前の状態に戻す場合はこの方法をお勧め

します。

8.3.2.4 スナップショットの削除

rbdを使用してスナップショットを削除するには、 snap rmオプション、プール名、イメージ名、および

ユーザ名を指定します。

root # rbd --pool pool-name snap rm --snap snap-name image-nameroot # rbd snap rm pool-name/image-name@snap-name


root # rbd --pool pool1 snap rm --snap snapshot1 image1root # rbd snap rm pool1/image1@snapshot1

注記Ceph OSDはデータを非同期で削除するので、スナップショットを削除してもディスク領域はす

ぐには解放されません。

8.3.2.5 スナップショットのパージ

rbdを使用してイメージのすべてのスナップショットを削除するには、 snap purgeオプションとイメー

ジ名を指定します。

root # rbd --pool pool-name snap purge image-nameroot # rbd snap purge pool-name/image-name


root # rbd --pool pool1 snap purge image1root # rbd snap purge pool1/image1

92 スナップショットの基本 SES 5

8.3.3 階層化

Cephでは、Block DeviceスナップショットのCOW (コピーオンライト)クローンを複数作成できます。

スナップショットの階層化により、Ceph Block Deviceのクライアントはイメージを非常に素早く作成

できます。たとえば、Linux VMが書き込まれたBlock Deviceイメージを作成してから、そのイメージ

のスナップショットを作成し、スナップショットを保護して、コピーオンライトクローンを必要な数だけ作成

できます。スナップショットは読み込み専用なので、スナップショットのクローンを作成することでセマン

ティクスが簡素化され、クローンを素早く作成できます。

注記次のコマンドラインの例で使われている「親」および「子」という用語は、Ceph Block Deviceの

スナップショット(親)と、そのスナップショットから作成された対応するクローンイメージ(子)を意

味します。

クローンイメージ(子)にはその親イメージへの参照が保存されており、これによってクローンイメージか

ら親のスナップショットを開いて読み込むことができます。

スナップショットのCOWクローンは、他のCeph Block Deviceイメージとまったく同じように動作しま

す。クローンイメージに対して読み書きを行ったり、クローンを作成したり、サイズを変更したりできます。

クローンイメージに特別な制約はありません。ただし、スナップショットのコピーオンライトクローンはス

ナップショットを参照するので、クローンを作成する前に「必ず」スナップショットを保護する必要があり

ます。

注記Cephは、「フォーマット2」イメージ( rbd create --image-format 2で作成されたイメージ)

のクローンの作成のみをサポートしています。

8.3.3.1 階層化の基本事項

Ceph Block Deviceの階層化は簡単なプロセスです。まずイメージを用意する必要があります。続い

て、イメージのスナップショットを作成し、スナップショットを保護する必要があります。これらの手順を実

行した後、スナップショットのクローンの作成を開始できます。

クローンイメージは親スナップショットへの参照を持ち、プールID、イメージID、およびスナップショット

IDを含みます。プールIDが含まれることは、あるプールから別のプール内のイメージへスナップショット

のクローンを作成できることを意味します。

93 階層化 SES 5

「イメージテンプレート」: Block Deviceの階層化の一般的な使用事例は、マスタイメージと、ク

ローンのテンプレートとして機能するスナップショットを作成することです。たとえば、Linux配布

パッケージ(たとえば、SUSE Linux Enterprise Server)のイメージを作成して、そのスナップ

ショットを作成できます。定期的にイメージを更新して新しいスナップショットを作成できます(たと

えば、 zypper ref && zypper patchの後に rbd snap createを実行します)。イメージが完

成したら、いずれかのスナップショットのクローンを作成できます。

「拡張テンプレート」: より高度な使用事例として、ベースイメージより多くの情報を提供するテン

プレートイメージを拡張することがあります。たとえば、イメージ(VMテンプレート)のクローンを作

成して、他のソフトウェア(たとえば、データベース、コンテンツ管理システム、分析システム)をイ

ンストールしてから、拡張イメージのスナップショットを作成でき、このスナップショットそのものを

ベースイメージと同じ方法で更新できます。

「テンプレートプール」: Block Deviceの階層化を使用する方法の1つが、テンプレートとして機

能するマスタイメージと、それらのテンプレートの各スナップショットが含まれるプールを作成する

ことです。その後、読み込み専用特権をユーザに拡張し、プール内での書き込みまたは実行の能

力を持たなくても、スナップショットのクローンを作成できるようにします。

「イメージのマイグレーション/回復」: Block Deviceの階層化を使用する方法の1つが、ある

プールから別のプールへデータを移行または回復することです。

8.3.3.2 スナップショットの保護

クローンは親スナップショットにアクセスします。ユーザが誤って親スナップショットを削除すると、すべ

てのクローンが壊れます。データの損失を防ぐため、クローンを作成する前に、スナップショットを保護す

る必要があります。

root # rbd --pool pool-name snap protect \ --image image-name --snap snapshot-nameroot # rbd snap protect pool-name/image-name@snapshot-name


root # rbd --pool pool1 snap protect --image image1 --snap snapshot1root # rbd snap protect pool1/image1@snapshot1

注記保護されたスナップショットは削除できません。

94 階層化 SES 5

8.3.3.3 スナップショットのクローンの作成

スナップショットのクローンを作成するには、親プール、イメージ、スナップショット、子プール、およびイ

メージ名を指定する必要があります。クローンを作成する前に、スナップショットを保護する必要がありま

す。

root # rbd --pool pool-name --image parent-image \ --snap snap-name --dest-pool pool-name \ --dest child-imageroot # rbd clone pool-name/parent-image@snap-name \pool-name/child-image-name


root # rbd clone pool1/image1@snapshot1 pool1/image2

注記あるプールから別のプール内のイメージへスナップショットのクローンを作成できます。たとえ

ば、一方のプール内に読み込み専用のイメージとスナップショットをテンプレートとして維持して

おき、別のプール内に書き込み可能クローンを維持できます。

8.3.3.4 スナップショットの保護の解除

スナップショットを削除するには、まず保護を解除する必要があります。また、クローンから参照されてい

るスナップショットは削除「できません」。スナップショットを削除する前に、スナップショットの各クローン

をフラット化する必要があります。

root # rbd --pool pool-name snap unprotect --image image-name \ --snap snapshot-nameroot # rbd snap unprotect pool-name/image-name@snapshot-name


root # rbd --pool pool1 snap unprotect --image image1 --snap snapshot1root # rbd snap unprotect pool1/image1@snapshot1

8.3.3.5 スナップショットの子の一覧

スナップショットの子を一覧にするには、次のコマンドを実行します。

root # rbd --pool pool-name children --image image-name --snap snap-nameroot # rbd children pool-name/image-name@snapshot-name

95 階層化 SES 5


root # rbd --pool pool1 children --image image1 --snap snapshot1root # rbd children pool1/image1@snapshot1

8.3.3.6 クローンイメージのフラット化

クローンイメージは親スナップショットへの参照を保持しています。子クローンから親スナップショットへ

の参照を削除する場合、スナップショットからクローンへ情報をコピーすることによって効果的にイメー

ジを「フラット化」します。クローンのフラット化にかかる時間は、スナップショットのサイズに応じて長くな

ります。スナップショットを削除するには、まず子イメージをフラット化する必要があります。

root # rbd --pool pool-name flatten --image image-nameroot # rbd flatten pool-name/image-name


root # rbd --pool pool1 flatten --image image1root # rbd flatten pool1/image1

注記フラット化されたイメージにはスナップショットからの情報がすべて含まれるため、階層化された

クローンよりも多くのストレージ領域を使用します。

8.4 rbdmap: ブート時のRBDデバイスのマップrbdmapは、1つ以上のRADOS Block Deviceイメージに対する rbd mapおよび rbd unmapの操作

を自動化するシェルスクリプトです。このスクリプトはいつでも手動で実行できますが、ブート時にRBD

イメージを自動的にマップしてマウント(シャットダウン時にはアンマウントしてマップ解除)するのが主

な使用事例です。これはInitシステムによってトリガされます。このために、 ceph-commonパッケージ

に systemdのユニットファイルである rbdmap.serviceが含まれています。

このスクリプトは引数を1つ取り、 mapまたは unmapのどちらかを指定できます。どちらの場合も、スクリ

プトは設定ファイルを解析します。デフォルトは /etc/ceph/rbdmapですが、環境変数 RBDMAPFILEで

上書きできます。設定ファイルの各行が、マップまたはマップ解除する1つのRBDイメージに対応しま

す。

設定ファイルは次のような形式になっています。

image_specification rbd_options

96 rbdmap: ブート時のRBDデバイスのマップ SES 5

image_specification

プール内のイメージのパス。 pool_name / image_nameとして指定します。 pool_nameを省略す

ると、デフォルトの「rbd」が想定されます。

rbd_options

基礎となる rbd mapコマンドに渡されるパラメータのオプションのリスト。これらのパラメータとそ

の値をコンマ区切り文字列として指定する必要があります。次に例を示します。

PARAM1=VAL1,PARAM2=VAL2,...

次の例では、 rbdmapスクリプトで次のコマンドを実行します。

rbd map pool_name/image_name --PARAM1 VAL1 --PARAM2 VAL2

rbdmap mapとして実行すると、設定ファイルを解析し、指定されているRBDイメージそれぞれに対し

て、最初にイメージをマップし( rbd mapを使用)、次にイメージをマウントしようと試みます。

rbdmap unmapとして実行すると、設定ファイルに一覧にされているイメージがアンマウントされてマッ

プ解除されます。

rbdmap unmap-allは、設定ファイルに一覧にされているかどうかに関係なく、現在マップされている

RBDイメージをすべてアンマウントし、その後マップ解除しようと試みます。

成功した場合、イメージはrbd map操作によって/dev/rbdXデバイスにマップされます。この時点で

udevルールがトリガされ、実際にマップされたデバイスを指すフレンドリデバイス名のシンボリックリン

ク /dev/rbd/pool_name/image_nameが作成されます。

正常にマウントおよびアンマウントするには、 /etc/fstabに「フレンドリ」デバイス名に対応するエントリ

が必要です。RBDイメージの /etc/fstabエントリを記述する場合、「noauto」(または「nofail」)マウン

トオプションを指定します。 rbdmap.serviceは一般的にブートシーケンスのかなり遅い段階でトリガ

されるため、このオプションを指定することによって、Initシステムが、対象デバイスがまだ存在しない早

すぎるタイミングでデバイスをマウントしないようにします。

rbdオプションの完全なリストについては、 rbdのマニュアルページ( man 8 rbd )を参照してくださ

い。

rbdmapの使用法の例については、 rbdmapのマニュアルページ( man 8 rbdmap )を参照してくださ

い。

8.5 RADOS Block DeviceのミラーリングRBDイメージを2つのCephクラスタ間で非同期でミラーリングできます。この機能は、RBDイメージの

ジャーナリング機能を使用して、クラスタ間でのクラッシュコンシステントなレプリケーションを保証しま

す。ミラーリングはピアクラスタ内でプールごとに設定します。また、プール内のすべてのイメージ、また

97 RADOS Block Deviceのミラーリング SES 5

はイメージの特定のサブセットを自動的にミラーリングするよう設定できます。ミラーリングは rbdコマン

ドを使用して設定します。 rbd-mirrorデーモンは、リモートのピアクラスタからイメージの更新を取得

して、ローカルクラスタ内のイメージに適用する処理を受け持ちます。

重要: rbd-mirrorデーモンRBDミラーリングを使用するには、それぞれが rbd-mirrorデーモンを実行する2つのCephク

ラスタが必要です。

8.5.1 rbd-mirrorデーモン

2つの rbd-mirrorデーモンは、リモートのピアクラスタ上のイメージのジャーナルを監視し、その

ジャーナルイベントをローカルクラスタに対して再生する処理を受け持ちます。RBDイメージのジャーナ

リング機能は、イメージに対するすべての変更を発生順に記録します。これにより、リモートイメージのク

ラッシュコンシステントなミラーをローカルで確実に利用できるようにします。

rbd-mirrorデーモンは rbd-mirrorパッケージで提供されています。このデーモンをクラスタノード

の1つにインストールし、有効にして起動します。

root@minion > zypper install rbd-mirrorroot@minion > systemctl enable ceph-rbd-mirror@server_name.serviceroot@minion > systemctl start ceph-rbd-mirror@server_name.service

重要各 rbd-mirrorデーモンは、両方のクラスタに同時に接続できる必要があります。

8.5.2 プールの設定

次の手順では、 rbdコマンドを使用してミラーリングを設定するための基本的な管理タスクを実行する

方法を説明します。ミラーリングは、Cephクラスタ内のプールごとに設定します。

これらのプール設定手順は、両方のピアクラスタで実行する必要があります。これらの手順では、わか

りやすくするため、「local」および「remote」という名前の2つのクラスタが1つのホストからアクセス可

能であることを想定しています。

異なるCephクラスタに接続する方法の詳細については、 rbdのマニュアルページ( man 8 rbd )を参


98 rbd-mirrorデーモン SES 5

ヒント: 複数のクラスタ次の例のクラスタ名は、同じ名前のCeph設定ファイル /etc/ceph/remote.confに対応して

います。複数のクラスタの設定方法については、ceph-conf (http://docs.ceph.com/docs/

master/rados/configuration/ceph-conf/#running-multiple-clusters) のドキュメントを

参照してください。

8.5.2.1 ミラーリングの有効化

プールのミラーリングを有効にするには、 mirror pool enableサブコマンド、プール名、およびミラー

リングモードを指定します。ミラーリングモードはpoolまたはimageにすることができます。

pool

ジャーナリング機能が有効な、プール内のすべてのイメージをミラーリングします。

image

各イメージに対して明示的にミラーリングを有効にする必要があります。詳細については、8.5.3.2

項「イメージのミラーリングの有効化」を参照してください。


root # rbd --cluster local mirror pool enable image-pool poolroot # rbd --cluster remote mirror pool enable image-pool pool

8.5.2.2 ミラーリングの無効化

プールのミラーリングを無効にするには、 mirror pool disableサブコマンドとプール名を指定しま

す。この方法でプールのミラーリングを無効にした場合、ミラーリングを明示的に有効にしたイメージ

(プール内)のミラーリングも無効になります。

root # rbd --cluster local mirror pool disable image-poolroot # rbd --cluster remote mirror pool disable image-pool

8.5.2.3 クラスタピアの追加

rbd-mirrorデーモンがピアクラスタを検出するには、そのピアがプールに登録されている必要があり

ます。ミラーリングピアクラスタを追加するには、 mirror pool peer addサブコマンド、プール名、およ

びクラスタの仕様を指定します。

99 プールの設定 SES 5

http://docs.ceph.com/docs/master/rados/configuration/ceph-conf/#running-multiple-clusters

http://docs.ceph.com/docs/master/rados/configuration/ceph-conf/#running-multiple-clusters

root # rbd --cluster local mirror pool peer add image-pool client.remote@remoteroot # rbd --cluster remote mirror pool peer add image-pool client.local@local

8.5.2.4 クラスタピアの削除

ミラーリングピアクラスタを削除するには、 mirror pool peer removeサブコマンド、プール名、およ

びピアのUUID ( rbd mirror pool infoコマンドで参照可能)を指定します。

root # rbd --cluster local mirror pool peer remove image-pool \ 55672766-c02b-4729-8567-f13a66893445root # rbd --cluster remote mirror pool peer remove image-pool \ 60c0e299-b38f-4234-91f6-eed0a367be08

8.5.3 イメージ設定

プール設定と異なり、イメージ設定はミラーリングピアの1つのCephクラスタのみで実行する必要があ

ります。

ミラーリングされたRBDイメージは、「プライマリ」または「非プライマリ」のいずれかとして指定されま

す。これはイメージのプロパティであり、プールのプロパティではありません。非プライマリとして指定さ

れたイメージは変更できません。

イメージに対して初めてミラーリングを有効にすると、イメージは自動的にプライマリに昇格します(プー

ルのミラーモードが「pool」で、イメージのジャーナリング機能が有効な場合、ミラーリングは暗黙的に

有効になります。または、 rbdコマンドによって明示的に有効にします(8.5.3.2項「イメージのミラーリン

グの有効化」を参照してください))。

8.5.3.1 イメージのジャーナリングのサポートの有効化

RBDのミラーリングは、RBDのジャーナリング機能を使用して、複製イメージが常にクラッシュコンシ

ステントな状態を保つようにします。イメージをピアクラスタにミラーリングするには、ジャーナリング機

能が有効である必要があります。この機能は、イメージの作成時に rbdコマンドで --image-feature

exclusive-lock,journalingオプションを指定することによって有効にできます。

または、既存のRBDイメージに対して動的にジャーナリング機能を有効にすることもできます。ジャーナ

リングを有効にするには、 feature enableサブコマンド、プール名、イメージ名、および機能名を指定

します。

root # rbd --cluster local feature enable image-pool/image-1 journaling

100 イメージ設定 SES 5

注記: オプションの依存関係journaling機能は exclusive-lock機能に依存します。 exclusive-lock機能がまだ有効

になっていない場合は、有効にしてから journaling機能を有効にする必要があります。

ヒント: すべての新規イメージのジャーナリングCeph設定ファイルに次の行を追加することにより、すべての新規イメージに対してデフォルトで

ジャーナリングを有効にできます。

rbd default features = 125

8.5.3.2 イメージのミラーリングの有効化

ミラーリングがイメージのプールに「image」モードで設定されている場合、プール内の各イメージに対

して明示的にミラーリングを有効にする必要があります。特定のイメージのミラーリングを有効にするに

は、 mirror image enableサブコマンドと共にプール名とイメージ名を指定します。

root # rbd --cluster local mirror image enable image-pool/image-1

8.5.3.3 イメージのミラーリングの無効化

特定のイメージのミラーリングを無効にするには、 mirror image disableサブコマンドと共にプール

名とイメージ名を指定します。

root # rbd --cluster local mirror image disable image-pool/image-1

8.5.3.4 イメージの昇格と降格

プライマリ指定をピアクラスタ内のイメージに移動する必要があるフェールオーバーシナリオの場合、

プライマリイメージへのアクセスを停止し、現在のプライマリイメージを降格してから、新しいプライマリイ

メージを昇格し、代替クラスタ上のイメージへのアクセスを再開する必要があります。

特定のイメージを非プライマリに降格するには、 mirror image demoteサブコマンドと共にプール名

とイメージ名を指定します。

root # rbd --cluster local mirror image demote image-pool/image-1


プール内のすべてのプライマリイメージを非プライマリに降格するには、 mirror pool demoteサブコ

マンドと共にプール名を指定します。

root # rbd --cluster local mirror pool demote image-pool

特定のイメージをプライマリに昇格するには、 mirror image promoteサブコマンドと共にプール名と

イメージ名を指定します。

root # rbd --cluster remote mirror image promote image-pool/image-1

プール内のすべての非プライマリイメージをプライマリに昇格するには、 mirror pool promoteサブ

コマンドと共にプール名を指定します。

root # rbd --cluster local mirror pool promote image-pool

ヒント: I/O負荷の分割プライマリまたは非プライマリの状態はイメージごとなので、2つのクラスタでIO負荷を分割した

り、フェールオーバーまたはフェールバックを実行したりできます。

注記: 強制昇格--forceオプションを使用して昇格を強制できます。強制昇格は、降格をピアクラスタに伝搬で

きない場合(たとえば、クラスタ障害や通信停止が発生した場合)に必要です。この結果、2つの

ピア間でスプリットブレインシナリオが発生し、 resyncサブコマンドを発行するまでイメージは

同期されなくなります。

8.5.3.5 イメージの再同期の強制

rbd-mirrorデーモンがスプリットブレインイベントを検出した場合、このデーモンは、イベントが修正

されるまで、影響を受けるイメージのミラーリングを試行しません。イメージのミラーリングを再開するに

は、まず、古いと判定されたイメージを降格してから、プライマリイメージへの再同期を要求します。イ

メージの再同期を要求するには、 mirror image resyncサブコマンドと共にプール名とイメージ名を

指定します。

root # rbd mirror image resync image-pool/image-1


8.5.4 ミラーの状態

ピアクラスタのレプリケーションの状態は、ミラーリングされたすべてのプライマリイメージについて保存

されます。この状態は、 mirror image statusおよび mirror pool statusの各サブコマンドを使

用して取得できます。

ミラーイメージの状態を要求するには、 mirror image statusサブコマンドと共にプール名とイメー

ジ名を指定します。

root # rbd mirror image status image-pool/image-1

ミラープールのサマリ状態を要求するには、 mirror pool statusサブコマンドと共にプール名を指

定します。

root # rbd mirror pool status image-pool

ヒント:mirror pool statusサブコマンドに --verboseオプションを追加すると、プール内にあるす

べてのミラーリングイメージについて状態の詳細も出力されます。

103 ミラーの状態 SES 5

9 イレージャコーディングプール

Cephでは、プール内のデータの通常のレプリケーションに代わる代替手段が提供されています。これ

を「イレージャ」または「イレージャコーディング」プールと呼びます。イレージャプールは「複製」プールの

一部の機能を備えていませんが、必要な未加工ストレージが少なくて済みます。デフォルトのイレージャ

プールは1TBのデータを保存でき、1.5TBの未加工ストレージを必要とします。複製プールでは同じ量

のデータに対して2TBの未加工ストレージが必要であるため、比較しても遜色ありません。

イレージャコードの背景情報については、https://en.wikipedia.org/wiki/Erasure_code を参照し

てください。

注記FileStoreを使用する場合、キャッシュ層が設定されていない限り、RBDインタフェースでイレー

ジャコーディングプールにアクセスすることはできません。詳細を確認する、またはBlueStoreを

使用するには、9.3項「イレージャコーディングプールとキャッシュ階層化」を参照してください。

注記「イレージャプール」のCRUSHルールでは stepに indepを使用するようにしてください。詳細

については、6.3.2項「firstnとindep」を参照してください。

9.1 サンプルのイレージャコーディングプールの作成最もシンプルなイレージャコーディングプールはRAID5と同等で、少なくとも3つのホストを必要としま

す。この手順では、テスト用のプールを作成する方法について説明します。

1. コマンド ceph osd pool createを使用して、タイプが「erasure」のプールを作成しま

す。 12は、配置グループの数を表します。デフォルトのパラメータの場合、このプールは1つの

OSDの障害に対応できます。

root # ceph osd pool create ecpool 12 12 erasurepool 'ecpool' created

2. 文字列 ABCDEFGHIを NYANという名前のオブジェクトに書き込みます。

cephadm > echo ABCDEFGHI | rados --pool ecpool put NYAN -

3. これで、テストのためにOSDを無効にできます。たとえば、OSDをネットワークから接続解除しま

す。

104 サンプルのイレージャコーディングプールの作成 SES 5

https://en.wikipedia.org/wiki/Erasure_code

4. プールがデバイスの障害に対応できるかどうかをテストするため、 radosコマンドを使用してファ

イルの内容にアクセスできます。

root # rados --pool ecpool get NYAN -ABCDEFGHI

9.2 イレージャコードプロファイルceph osd pool createコマンドを起動して「イレージャプール」を作成する場合、別のプロファイルを

指定しない限り、デフォルトのプロファイルが使用されます。プロファイルはデータの冗長性を定義しま

す。このためには、任意に kおよび mという名前が付けられた2つのパラメータを定義します。kおよびm

は、1つのデータを何個の chunks (チャンク)に分割するかと、何個のコーディングチャンクを作成する

かを定義します。これにより、冗長チャンクは異なるOSDに保存されます。

イレージャプールプロファイルに必要な定義は次のとおりです。

chunk

エンコーディング関数を呼び出すと、同じサイズの複数のチャンクが返されます。連結して元のオ

ブジェクトを再構成できるデータチャンクと、失われたチャンクの再構築に使用できるコーディン

グチャンクです。

k

データチャンクの数。これは、元のオブジェクトが分割されるチャンクの数です。たとえば、 k =

2の場合、10KBのオブジェクトはそれぞれが5KBの k個のオブジェクトに分割されます。

m

コーディングチャンクの数。これは、エンコーディング関数によって計算される追加チャンクの数で

す。コーディングチャンクが2つある場合、2つのOSDに障害が発生してもデータが失われないこ

とを意味します。

crush-failure-domain

チャンクの分散先のデバイスを定義します。値としてバケットタイプを設定する必要があります。す

べてのバケットタイプについては、6.2項「バケット」を参照してください。障害ドメインが rackの

場合、ラック障害時の災害耐性を向上させるため、チャンクは別のラックに保存されます。

9.1項「サンプルのイレージャコーディングプールの作成」で使用されているデフォルトのイレージャ

コードプロファイルでは、1つのOSDに障害が発生した場合は、クラスタデータは失われません。した

がって、1TBのデータを保存するには、さらに0.5TBの未加工ストレージが必要です。つまり、1TBの

データに対し、1.5TBの未加工ストレージが必要です。これは、一般的なRAID 5設定と同等です。比

較すると、複製プールでは1TBのデータを保存するのに2TBの未加工ストレージが必要です。

105 イレージャコードプロファイル SES 5

デフォルトのプロファイルの設定は次のコマンドで表示できます。

root # ceph osd erasure-code-profile get defaultdirectory=.libsk=2m=1plugin=jerasurecrush-failure-domain=hosttechnique=reed_sol_van

プール作成後はプロファイルを変更できないため、適切なプロファイルを選択することが重要です。異

なるプロファイルを持つ新しいプールを作成し、前のプールにあるオブジェクトをすべて新しいプールに

移動する必要があります。

k 、 m 、および crush-failure-domainのパラメータは、ストレージのオーバーヘッドとデータの持続

性を定義するので、プロファイルの中で最も重要なパラメータです。たとえば、目的のアーキテクチャが

66%のストレージオーバーヘッドでラック2台分の損失に耐える必要がある場合、次のプロファイルを定

義できます。

root # ceph osd erasure-code-profile set myprofile \ k=3 \ m=2 \ crush-failure-domain=rack

この新しいプロファイルで、9.1項「サンプルのイレージャコーディングプールの作成」の例をもう一度使

用できます。

root # ceph osd pool create ecpool 12 12 erasure myprofilecephadm > echo ABCDEFGHI | rados --pool ecpool put NYAN -root # rados --pool ecpool get NYAN -ABCDEFGHI

NYANオブジェクトは3つ( k=3 )に分割され、2つの追加チャンク( m=2 )が作成されます。 mの値は、

データを失うことなく何個のOSDが同時に失われても構わないかを定義します。 crush-failure-

domain=rackは、2つのチャンクが同じラックに保存されないようにするCRUSHルールセットを作成し

ます。

106 イレージャコードプロファイル SES 5

イレージャコードプロファイルの詳細については、http://docs.ceph.com/docs/master/rados/

operations/erasure-code-profile を参照してください。

9.3 イレージャコーディングプールとキャッシュ階層化イレージャコーディングプールには複製プールよりも多くのリソースが必要で、部分書き込みなど一部

の機能がありません。これらの制限を解決するには、イレージャコーディングプールの前にキャッシュ層

を設定することをお勧めします。

たとえば、「hot-storage」プールが高速なストレージで構成されている場合、9.2項「イレージャコードプ

ロファイル」で作成した「ecpool」を次のコマンドによって高速化できます。

root # ceph osd tier add ecpool hot-storageroot # ceph osd tier cache-mode hot-storage writebackroot # ceph osd tier set-overlay ecpool hot-storage

107 イレージャコーディングプールとキャッシュ階層化 SES 5

http://docs.ceph.com/docs/master/rados/operations/erasure-code-profile

http://docs.ceph.com/docs/master/rados/operations/erasure-code-profile

これは、「hot-storage」プールをecpoolの層としてライトバックモードで配置します。これによっ

て、ecpoolに対するすべての読み書きは実際にはhot-storageを使用し、その柔軟性と速度を利用で

きるようになります。

FileStoreを使用する場合、イレージャコーディングプール上にRBDイメージを作成することはできませ

ん。RBDには部分書き込みが必要であるためです。ただし、複製プール層でキャッシュ層が設定されて

いる場合は、イレージャコーディングプール上にRBDイメージを作成できます。

root # rbd --pool ecpool create --size 10 myvolume

キャッシュ階層化の詳細については、第10章「キャッシュ階層化」を参照してください。

9.4 イレージャコーディングプールとRADOS BlockDeviceECプールにRBDプールとしてマークを付けるには、適切にタグを付けます。

root # ceph osd pool application enable rbd ec_pool_name

RBDはECプールにイメージの「データ」を保存できます。ただし、イメージのヘッダとメタデータは引き

続き複製プールに保存する必要があります。このための「rbd」という名前のプールがあると想定した場

合、次のコマンドを使用します。

root # rbd create rbd/image_name --size 1T --data-pool ec_pool_name

このイメージは他のイメージと同じように通常の方法で使用できますが、すべてのデータは「rbd」プー

ルではなく ec_pool_nameプールに保存される点が異なります。

108 イレージャコーディングプールとRADOS Block Device SES 5

10 キャッシュ階層化

「キャッシュ層」とは、クライアントと標準ストレージとの間に実装される追加のストレージ層です。これ

は、低速なハードディスクやイレージャコーディングプールに保存されているプールへのアクセスを高速

化するために設計されています。

一般的に、キャッシュ階層化では、キャッシュ層として機能するように設定された比較的高速/高価なス

トレージデバイス(たとえば、SSDドライブ)と、ストレージ層として機能するように設定された低速で安価

なデバイスのバッキングプールを作成する必要があります。

10.1 階層化ストレージの用語キャッシュ階層化では、「キャッシュプール」および「ストレージプール」という2種類のプールを区別しま

す。

ヒントプールの全般的な情報については、第7章「ストレージプールの管理」を参照してください。

ストレージプール

Ceph Storage Cluster内にあるオブジェクトの複数のコピーを保存する標準の複製プール、ま

たはイレージャコーディングプール(第9章「イレージャコーディングプール」を参照してください)。

ストレージプールは、「バッキング」ストレージまたは「コールド」ストレージと呼ばれることもありま

す。

キャッシュプール

容量は比較的小さいものの高速なストレージデバイス上に保存され、CRUSHマップに専用の

ルールセットを持つ標準の複製プール。

キャッシュプールは、「ホット」ストレージとも呼ばれます。

10.2 考慮すべきポイントキャッシュ階層化により、特定のワークロードのクラスタのパフォーマンスが「低下」することがあります。

次のポイントは、考慮が必要な側面をいくつか示しています。

109 階層化ストレージの用語 SES 5

「ワークロード依存」: キャッシュによってパフォーマンスが向上するかどうかはワークロードによ

ります。キャッシュへのオブジェクトの出し入れはコストを伴うため、大多数の要求が少数のオブ

ジェクトを操作する場合に、効果が高くなる可能性があります。キャッシュプールは、ワークロー

ドのワーキングセットをキャプチャし、スラッシングを避けるのに十分な大きさである必要がありま

す。

「ベンチマークが困難」: キャッシュ階層化を使用すると、ほとんどのパフォーマンスベンチマーク

で低いパフォーマンスが示されることがあります。その理由は、ベンチマークでは大容量のオブ

ジェクトセットが要求されることと、キャッシュが「ウォームアップ」するまでにしばらく時間がかか

るためです。

「パフォーマンスが低い可能性」: キャッシュ階層化に適さないワークロードでは、キャッシュ階層

化が有効になっていない通常の複製プールよりパフォーマンスが低くなります。

「 libradosオブジェクト列挙」: アプリケーションが libradosを直接使用していて、オブジェク

ト列挙に依存している場合、キャッシュ階層化が期待どおりには動作しないことがあります(これ

は、Object Gateway、RBD、またはCephFSでは問題になりません)。

10.3 キャッシュ階層化を使用する状況次の場合、キャッシュ階層化の使用を検討します。

イレージャコーディングプールにRBD (RADOS Block Device)経由でアクセスする必要がある

場合。

イレージャコーディングプールにiSCSI経由でアクセスする必要がある場合。これは、iSCSIが

RBDの制限を継承するためです。iSCSIの詳細については、第12章「Ceph iSCSI Gateway」を

参照してください。

パフォーマンスが高いストレージの数が限られていて、パフォーマンスが低いストレージが大量に

ある状況で、保存データへのアクセスを高速化する必要がある場合。

10.4 キャッシュモードキャッシュ階層化エージェントは、キャッシュ層とバッキングストレージ層との間でのデータのマイグ

レーションを扱います。管理者は、このマイグレーションの実行方法を設定できます。主なシナリオは2つ

あります。

ライトバックモード

110 キャッシュ階層化を使用する状況 SES 5

ライトバックモードでは、Cephクライアントはデータをキャッシュ層に書き込み、キャッシュ層から

ACKを受信します。時間が経つと、キャッシュ層に書き込まれたデータはストレージ層に移行さ

れ、キャッシュ層からフラッシュされます。概念的には、キャッシュ層はバッキングストレージ層の

「前」にオーバーレイされています。Cephクライアントでストレージ層に存在するデータが必要に

なった場合、キャッシュ階層化エージェントが読み込み時にデータをキャッシュ層に移行し、その

後Cephクライアントにデータが送信されます。それ以降、Cephクライアントは、データが非アク

ティブになるまで、キャッシュ層を使用してI/Oを実行できます。これは、写真やビデオの編集など

の可変データや、トランザクションデータにとって理想的です。

読み込み専用モード

読み込み専用モードでは、Cephクライアントはデータをバッキング層に直接書き込みます。読み

込み時に、Cephは要求されたオブジェクトをバッキング層からキャッシュ層にコピーします。古い

オブジェクトは、定義されたポリシーに基づいてキャッシュ層から削除されます。このアプローチ

は、ソーシャルネットワークでの写真やビデオの表示、DNAデータ、X線撮像など、不変データに

最適です。その理由は、キャッシュプールからのデータの読み込みでは古いデータが含まれる可

能性があり、整合性が弱いためです。読み込み専用モードは、可変データには使用しないでくだ

さい。

10.5 ヒットセット

10.5.1 概要

「ヒットセット」パラメータを使用して「キャッシュプール」を調整できます。Cephにおけるヒットセットとは

通常、ブルームフィルタで、キャッシュプールにすでに存在するオブジェクトを追跡する、メモリ効率の良

い方法を提供します。

ヒットセットは、オブジェクト名に適用される一連のハッシュ関数の結果を保存するために使用される

ビット配列です。初期状態では、すべてのビットが 0に設定されています。オブジェクトがヒットセットに

追加されると、オブジェクトの名前がハッシュされて、結果がヒットセット内の異なる位置にマップされ、

そこでビットの値が 1に設定されます。

オブジェクトがキャッシュに存在するかどうかを判断するため、オブジェクト名がもう一度ハッシュされ

ます。いずれかのビットが 0である場合、そのオブジェクトは間違いなくキャッシュに存在せず、コールド

ストレージから取得する必要があります。

ヒットセットの同じ場所に複数の異なるオブジェクトの結果が保存される可能性があります。また、オブ

ジェクトがキャッシュ内に存在しないのに、すべてのビットが偶然 1に設定される可能性もあります。し

たがって、ブルームフィルタで動作するヒットセットで判断できるのは、オブジェクトが間違いなくキャッ

シュに存在せず、コールドストレージから取得する必要があるかどうかだけです。

111 ヒットセット SES 5

時間の経過と共に、1つのキャッシュプールが複数のヒットセット追跡ファイルを持つ可能性があり

ます。 hit_set_count設定は、使用するヒットセットの数を定義し、 hit_set_periodは、各ヒット

セットの使用期間を定義します。この期間を過ぎると、次のヒットセットが使用されます。ヒットセット

の数を使い尽くすと、最も古いヒットセットのメモリが解放されて、新しいヒットセットが作成されま

す。 hit_set_countと hit_set_periodを相互に掛けた値によって、オブジェクトへのアクセスが追

跡されている全体的なタイムフレームが定義されます。

図 10.1: 3つの保存オブジェクトによるブルームフィルタ

ブルームフィルタに基づくヒットセットは、ハッシュオブジェクトの数と比較して非常にメモリ効率が高

くなっています。誤検知確率を1%未満に下げるのに必要なビット数は10ビット未満です。誤検知確率

は、 hit_set_fppで定義できます。Cephは、配置グループ内のオブジェクトの数と誤検知確率に基

づいて、ヒットセットのサイズを自動的に計算します。

min_write_recency_for_promoteおよび min_read_recency_for_promoteを使用して、キャッ

シュプールで必要なストレージを制限できます。値を 0に設定すると、すべてのオブジェクトが読み書

きと同時にキャッシュプールに昇格され、オブジェクトが削除されるまで保持されます。 0より大きい値

は、オブジェクトが検索された存続期間ごとに順序付けされたヒットセットの数を定義します。オブジェ

クトがヒットセットで見つかった場合、そのオブジェクトはキャッシュプールに昇格されます。

112 概要 SES 5

10.5.2 例

10.5.2.1 大容量のキャッシュプールと小容量のメモリ

大量のストレージがあり、利用可能なRAMの量がきわめて少ない場合、すべてのオブジェクトをアクセ

スと同時にキャッシュプールに昇格できます。ヒットセットが小さく抑えられます。次に、一連の設定値の

例を示します。

hit_set_count = 1hit_set_period = 3600hit_set_fpp = 0.05min_write_recency_for_promote = 0min_read_recency_for_promote = 0

10.5.2.2 小容量のキャッシュプールと大容量のメモリ

ストレージの容量が少ないものの比較的大容量のメモリが利用可能な場合、限られた数のオブジェク

トをキャッシュプールに昇格するようキャッシュ層を設定できます。12個のヒットセットがあり、そのそれ

ぞれを14,400秒の期間使用すると、合計48時間の追跡が提供されます。過去8時間以内にオブジェ

クトがアクセスされた場合、そのオブジェクトはキャッシュプールに昇格されます。次に、一連の設定値

の例を示します。

hit_set_count = 12hit_set_period = 14400hit_set_fpp = 0.01min_write_recency_for_promote = 2min_read_recency_for_promote = 2

10.6 サンプル階層化ストレージの設定このセクションでは、高速なSSDキャッシュ層(ホットストレージ)を標準のハードディスク(コールドスト

レージ)の前に設定する方法を説明します。

ヒント次の例は説明のみを目的としており、1つのCephノード上に存在するSSD部分用の1つのルー

トと1つのルールで構成されるセットアップが含まれます。

通常、運用環境のクラスタ設定には、ホットストレージ用のより多くのルートエントリとルールエ

ントリ、およびSSDディスクとSATAディスクの両方が存在する混在ノードも含まれます。

113 例 SES 5

1. SSDなどの高速なドライブを搭載したホストマシンを準備します。このクラスタノードは、高速な

キャッシュ層として機能します。

2. DeepSeaを使用して、このマシンをCephノードに変換します。1.1項「新しいクラスタノードの追

加」の説明に従って、ソフトウェアをインストールしてホストマシンを設定します。ホストマシンの名

前は node-4であると想定します。このノードにOSDディスクが4台必要です。

この場合、CRUSHマップのエントリは次のようになります。

[...]host node-4 { id -5 # do not change unnecessarily # weight 0.012 alg straw hash 0 # rjenkins1 item osd.6 weight 0.003 item osd.7 weight 0.003 item osd.8 weight 0.003 item osd.9 weight 0.003}[...]

3. 高速なSSDドライブを利用するOSDにマップされたホットストレージプールのCRUSHマップを

編集します。SSD用のルートノードが含まれる2つ目の階層を(「root ssd」として)定義します。

さらに、SSDの重みとCRUSHルールを変更します。CRUSHマップの詳細については、http://

docs.ceph.com/docs/master/rados/operations/crush-map/ を参照してください。

getcrushmapや crushtoolなどのコマンドラインツールを使用して、CRUSHマップを直接編

集します。

a. 現在のマップを取得して、 c.mapとして保存します。

cephadm > sudo ceph osd getcrushmap -o c.map

b. c.mapをデコンパイルして、 c.txtとして保存します。

cephadm > crushtool -d c.map -o c.txt

c. c.txtを編集します。

[...]host node-4 { id -5 # do not change unnecessarily # weight 4.000 alg straw hash 0 # rjenkins1 item osd.6 weight 1.000 item osd.7 weight 1.000

114 サンプル階層化ストレージの設定 SES 5

http://docs.ceph.com/docs/master/rados/operations/crush-map/

http://docs.ceph.com/docs/master/rados/operations/crush-map/

item osd.8 weight 1.000 item osd.9 weight 1.000}root ssd { # newly added root for the SSD hot-storage id -6 alg straw hash 0 item node-4 weight 4.00}rule ssd { ruleset 4 type replicated min_size 0 max_size 4 step take ssd step chooseleaf firstn 0 type host step emit}[...]

d. 編集した c.txtファイルをコンパイルして、 ssd.mapとして保存します。

cephadm > crushtool -c c.txt -o ssd.map

e. 最後に、 ssd.mapを新しいCRUSHマップとしてインストールします。

cephadm > sudo ceph osd setcrushmap -i ssd.map

4. キャッシュ階層化に使用するホットストレージプールを作成します。このプールには新しい「ssd」

ルールを使用します。

cephadm > sudo ceph osd pool create hot-storage 100 100 replicated ssd

5. デフォルトの「replicated_ruleset」ルールを使用するコールドストレージプールを作成します。

cephadm > sudo ceph osd pool create cold-storage 100 100 replicated replicated_ruleset

6. 続いて、キャッシュ層を設定するために、バッキングストレージプールをキャッシュプールに関連

付ける必要があります。この場合は、コールドストレージ(=ストレージプール)をホットストレージ(=

キャッシュプール)に関連付けます。

cephadm > sudo ceph osd tier add cold-storage hot-storage

7. キャッシュモードを「writeback」に設定するため、次のコマンドを実行します。

cephadm > sudo ceph osd tier cache-mode hot-storage writeback

115 サンプル階層化ストレージの設定 SES 5

キャッシュモードの詳細については、10.4項「キャッシュモード」を参照してください。

ライトバックキャッシュ層はバッキングストレージ層をオーバーレイするので、追加手順が1つ必

要です。つまり、すべてのクライアントトラフィックをストレージプールからキャッシュプールに送信

する必要があります。クライアントトラフィックをキャッシュプールに直接送信するには、たとえば、

次のコマンドを実行します。

cephadm > sudo ceph osd tier set-overlay cold-storage hot-storage

10.6.1 キャッシュ層の設定

キャッシュ層の設定に使用できるオプションは複数あります。使用する構文は次のとおりです。

cephadm > sudo ceph osd pool set cachepool key value

10.6.1.1 ターゲットのサイズとタイプ

次の手順では、10.5.2.2項「小容量のキャッシュプールと大容量のメモリ」で指定した値を使って

「キャッシュプール」を設定する方法を説明します。

Cephの運用キャッシュ層は、 hit_set_typeにブルームフィルタを使用します。

cephadm > sudo ceph osd pool set cachepool hit_set_type bloom

hit_set_countおよび hit_set_periodは、保存するヒットセットの数と、各ヒットセットが対応する

時間の長さを定義します。

cephadm > sudo ceph osd pool set cachepool hit_set_count 12cephadm > sudo ceph osd pool set cachepool hit_set_period 14400cephadm > sudo ceph osd pool set cachepool target_max_bytes 1000000000000

注記hit_set_countを大きくすると、 ceph-osdプロセスのRAM消費量が増えます。

min_read_recency_for_promoteは、読み込み操作を処理する際にオブジェクトが存在するかど

うかを確認するヒットセットの数を定義します。この確認結果を使用して、オブジェクトを非同期で昇格

させるかどうかが決定されます。値は0〜 hit_set_countの範囲である必要があります。0に設定す

ると、オブジェクトは常に昇格されます。1に設定すると、現在のヒットセットが確認されます。さらに、こ

116 キャッシュ層の設定 SES 5

のオブジェクトが現在のヒットセット内にある場合、オブジェクトが昇格されます。そうでない場合、オブ

ジェクトは昇格されません。他の値の場合は、アーカイブヒットセットの正確な数が確認されます。オブ

ジェクトが最新の min_read_recency_for_promoteのいずれかで見つかった場合、そのオブジェク

トは昇格されます。

書き込み操作に対しても同様のパラメータ min_write_recency_for_promoteを設定できます。

cephadm > sudo ceph osd pool set cachepool min_read_recency_for_promote 2cephadm > sudo ceph osd pool set cachepool min_write_recency_for_promote 2

注記期間が長くなるほど、 min_read_recency_for_promoteおよ

び min_write_recency_for_promoteの値が大きくなり、 ceph-osdデーモンのRAM消費量

が増えます。特に、キャッシュオブジェクトをフラッシュまたは削除するためにエージェントがアク

ティブである場合、すべての hit_set_countヒットセットがRAMにロードされます。

10.6.1.2 キャッシュサイズ

キャッシュ階層化エージェントは、主に次の2つの機能を実行します。

フラッシュ

エージェントは、変更済み(ダーティ)オブジェクトを識別し、長期間保存するためにストレージ

プールに転送します。

削除

エージェントは、未変更(クリーン)オブジェクトを識別し、最近の使用頻度が最も低いものを

キャッシュから削除します。

10.6.1.2.1 絶対サイズ

キャッシュ階層化エージェントは、バイトの合計数またはオブジェクトの合計数に基づいてオブジェクト

をフラッシュまたは削除できます。バイトの最大数を指定するには、次のコマンドを実行します。

cephadm > sudo ceph osd pool set cachepool target_max_bytes num_of_bytes

オブジェクトの最大数を指定するには、次のコマンドを実行します。

cephadm > sudo ceph osd pool set cachepool target_max_objects num_of_objects


注記Cephはキャッシュプールのサイズを自動的に決定することはできないため、ここで絶対サイズ

の設定が必要です。そうしないと、フラッシュと削除が機能しません。両方の制限を指定した場

合、キャッシュ階層化エージェントは、どちらかのしきい値がトリガされるとフラッシュまたは削除

を開始します。

注記すべてのクライアント要求がブロックされるのは、 target_max_bytesまた

は target_max_objectsに達した場合だけです。

10.6.1.2.2 相対サイズ

キャッシュ階層化エージェントは、キャッシュプールのサイズを基準にした相対サイズでオブジェ

クトをフラッシュまたは削除できます(10.6.1.2.1項「絶対サイズ」の target_max_bytesまた

は target_max_objectsで指定します)。キャッシュプールが一定の割合の変更済み(ダーティ)オブ

ジェクトで構成される場合、キャッシュ階層化エージェントはそれらのオブジェクトをストレージプール

にフラッシュします。 cache_target_dirty_ratioを設定するには、次のコマンドを実行します。

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_ratio 0.0...1.0

たとえば、この値を0.4に設定した場合、変更済み(ダーティ)オブジェクトがキャッシュプールの容量の

40%に達すると、フラッシュが開始されます。

cephadm > sudo ceph osd pool set hot-storage cache_target_dirty_ratio 0.4

ダーティオブジェクトが容量の一定の割合に達した場合、より高速にフラッシュしま

す。 cache_target_dirty_high_ratioを使用します。

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_high_ratio 0.0..1.0

キャッシュプールが容量の一定の割合に達した場合、キャッシュ階層化エージェントはオブジェクトを

削除して空き容量を維持します。 cache_target_full_ratioを設定するには、次のコマンドを実行し

ます。

cephadm > sudo ceph osd pool set cachepool cache_target_full_ratio 0.0..1.0


10.6.1.3 キャッシュ存続期間

キャッシュ階層化エージェントが最近変更された(ダーティ)オブジェクトをバッキングストレージプール

にフラッシュするまでの、オブジェクトの最小存続期間を指定できます。

cephadm > sudo ceph osd pool set cachepool cache_min_flush_age num_of_seconds

オブジェクトがキャッシュ層から削除されるまでの、オブジェクトの最小存続期間を指定できます。

cephadm > sudo ceph osd pool set cachepool cache_min_evict_age num_of_seconds

10.6.1.4 ヒットセットでのGMTの使用

キャッシュ層のセットアップには、「ヒットセット」と呼ばれるブルームフィルタがあります。このフィルタ

は、オブジェクトがホットまたはコールドのどちらのオブジェクトセットに属するかをテストします。オブ

ジェクトは、その名前に追加されたタイムスタンプを使用してヒットセットに追加されます。

複数のクラスタマシンがそれぞれ異なるゾーンに配置されていて、タイムスタンプがローカル時刻から

派生している場合、ヒットセット内のオブジェクトに、未来や過去のタイムスタンプで構成される、誤解を

招きやすい名前が付く可能性があります。最悪の場合、ヒットセットにオブジェクトがまったく存在しなく

なるおそれもあります。

これを防ぐため、新しく作成されたキャッシュ層セットアップの use_gmt_hitsetは、デフォルトで「1」

に設定されます。これにより、ヒットセットのオブジェクト名を作成する際に、OSDで強制的にGMT (グリ

ニッジ標準時)タイムスタンプを使用します。

警告: デフォルト値を変更しないuse_gmt_hitsetのデフォルト値「1」を変更しないでください。ご使用のクラスタセットアップで

このオプションに関連するエラーが発生していない場合は、デフォルト値を手動で変更しないで

ください。変更すると、クラスタの動作が予測不能になることがあります。


III クラスタデータへのアクセス

11 Ceph Object Gateway 121

12 Ceph iSCSI Gateway 164

13 クラスタ化ファイルシステム 181

14 NFS Ganesha: NFS経由でのCephデータのエクスポート 189

11 Ceph Object Gateway

この章では、サービスの状態の確認、アカウントの管理、マルチサイトゲートウェイ、LDAP認証な

ど、Object Gatewayに関連する管理タスクについて詳しく説明します。

11.1 Object Gatewayの制約と命名の制限次に、Object Gatewayの重要な制限のリストを示します。

11.1.1 バケットの制限

S3 API経由でObject Gatewayに接続する場合、バケット名はDNSに準拠した名前(ダッシュ文字

「-」は使用可能)に制限されます。Swift API経由でObject Gatewayに接続する場合は、UTF-8でサ

ポートされている文字(スラッシュ文字「/」を除く)を自由に組み合わせて使用できます。バケット名の最

大長は255文字です。バケット名は固有でなければなりません。

ヒント: DNSに準拠したバケット名Swift API経由ではUTF-8ベースのバケット名を使用できますが、同じバケットにS3 API経由

でアクセスする際に問題が起きないよう、バケットにはS3の命名制限に従った名前を付けること

をお勧めします。

11.1.2 保存オブジェクトの制限

ユーザあたりのオブジェクトの最大数

デフォルトでは制限はありません(最大2^63に制限)。

バケットあたりのオブジェクトの最大数

デフォルトでは制限はありません(最大2^63に制限)。

アップロード/保存するオブジェクトの最大サイズ

1回のアップロードは5GBに制限されます。これより大きいオブジェクトサイズにはマルチパートを

使用してください。マルチパートチャンクの最大数は10000です。

121 Object Gatewayの制約と命名の制限 SES 5

11.1.3 HTTPヘッダの制限HTTPヘッダと要求の制限は、使用するWebフロントエンドによって異なります。デフォルトの

CivetWebでは、HTTPヘッダの数は64ヘッダに、HTTPヘッダのサイズは16KBにそれぞれ制限され

ています。

11.2 Object Gatewayの展開DeepSeaインフラストラクチャを使用してCeph Object Gatewayを展開する場合に推奨する方法は、

関連する role-rgw [...]の行をSalt Masterの policy.cfgファイルに追加して、必要なDeepSea

ステージを実行する方法です。

クラスタ展開プロセス中にObject Gatewayを組み込むには、『導入ガイド』、第4章「DeepSea/

Saltを使用した展開」、4.3項「クラスタの展開」および『導入ガイド』、第4章「DeepSea/Saltを使

用した展開」、4.5.1項「policy.cfgファイル」を参照してください。

展開済みのクラスタにObject Gatewayの役割を追加するには、1.2項「ノードへの新しい役割

の追加」を参照してください。

11.3 Object Gatewayサービスの操作Object Gatewayサービスは、 systemctlコマンドで操作します。Object Gatewayサービスを操作す

るには、 root特権が必要です。 gateway_hostは、操作する必要があるObject Gatewayインスタン

スが存在するサーバのホスト名であることに注意してください。

Object Gatewayサービスでは、次のサブコマンドがサポートされています。

systemctl status ceph-radosgw@rgw. gateway_host

サービスの状態情報を出力します。

systemctl start ceph-radosgw@rgw. gateway_host

サービスがまだ実行中でない場合に起動します。

systemctl restart ceph-radosgw@rgw. gateway_host

サービスを再起動します。

systemctl stop ceph-radosgw@rgw. gateway_host

実行中のサービスを停止します。

systemctl enable ceph-radosgw@rgw. gateway_host

サービスを有効にして、システム起動時に自動的に起動するようにします。

122 HTTPヘッダの制限 SES 5

systemctl disable ceph-radosgw@rgw. gateway_host

サービスを無効にして、システム起動時に自動的に起動しないようにします。

11.4 設定パラメータObject Gatewayの動作は、 ceph.confファイルのさまざまなオプションで制御できます。次に、最

も一般的なオプションを一覧にしました。完全なリストについては、http://docs.ceph.com/docs/

master/radosgw/config-ref/ を参照してください。

rgw_thread_pool_size

CivetWebサーバのスレッドの数。より多くの要求を実行する必要がある場合は、値を増やしま

す。デフォルトは100スレッドです。

rgw_num_rados_handles

Object Gateway用のRADOSクラスタハンドルの数(http://docs.ceph.com/docs/master/

rados/api/librados-intro/#step-2-configuring-a-cluster-handle を参照してくださ

い)。RADOSハンドルの数を設定することにより、すべてのタイプのワークロードのパフォーマンス

が大きく向上します。Object Gatewayの各ワーカスレッドは、その有効期間中、RADOSハンド

ルを選択します。デフォルトは1です。

rgw_max_chunk_size

1回の操作で読み込むデータチャンクの最大サイズ。値を4MB (4194304)に増やすと、大容量

オブジェクトの処理時にパフォーマンスが向上します。デフォルトは128KB (131072)です。

11.4.1 追加の注意事項

rgw dns name

ceph.confにパラメータ rgw dns nameを追加する場合、 rgw dns nameで指定されたエンド

ポイントで要求を転送するようS3クライアントを設定してください。

11.5 Object Gatewayのアクセスの管理S3またはSwiftと互換性のあるインタフェースを使用してObject Gatewayと通信できます。S3インタ

フェースは、Amazon S3 RESTful APIの大規模なサブセットと互換性があります。Swiftインタフェー

スは、OpenStack Swift APIの大規模なサブセットと互換性があります。

どちらのインタフェースも、ユーザの秘密鍵を使用してゲートウェイと通信するには、特定のユーザを作

成し、関連するクライアントソフトウェアをインストールする必要があります。

123 設定パラメータ SES 5

http://docs.ceph.com/docs/master/radosgw/config-ref/

http://docs.ceph.com/docs/master/radosgw/config-ref/

http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle

http://docs.ceph.com/docs/master/rados/api/librados-intro/#step-2-configuring-a-cluster-handle

11.5.1 Object Gatewayへのアクセス

11.5.1.1 S3インタフェースへのアクセス

S3インタフェースにアクセスするには、RESTクライアントが必要です。 S3cmdはコマンドラインのS3ク

ライアントです。これは、OpenSUSEビルドサービス (https://build.opensuse.org/package/show/

Cloud:Tools/s3cmd) にあります。このリポジトリには、SUSE Linux Enterpriseベースおよび

openSUSEベースの両方の配布パッケージ用のバージョンがあります。

S3インタフェースへのアクセスをテストする場合、簡単なPythonスクリプトを作成することもできます。

このスクリプトは、Object Gatewayに接続して新しいバケットを作成し、すべてのバケットを一覧にし

ます。 aws_access_key_idおよび aws_secret_access_keyの値は、11.5.2.1項「S3およびSwift

ユーザの追加」の radosgw_adminコマンドによって返される access_keyおよび secret_keyの値か

ら取得されます。

1. python-botoパッケージをインストールします。

sudo zypper in python-boto

2. 次の内容で、 s3test.pyという名前の新しいPythonスクリプトを作成します。

import botoimport boto.s3.connectionaccess_key = '11BS02LGFB6AL6H1ADMW'secret_key = 'vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY'conn = boto.connect_s3(aws_access_key_id = access_key,aws_secret_access_key = secret_key,host = '{hostname}',is_secure=False,calling_format = boto.s3.connection.OrdinaryCallingFormat(),)bucket = conn.create_bucket('my-new-bucket')for bucket in conn.get_all_buckets(): print "{name}\t{created}".format( name = bucket.name, created = bucket.creation_date, )

{hostname}は、Object Gatewayサービスを設定したホストのホスト名に置き換えてください。

たとえば、 gateway_hostです。

3. スクリプトを実行します。

124 Object Gatewayへのアクセス SES 5

https://build.opensuse.org/package/show/Cloud:Tools/s3cmd

https://build.opensuse.org/package/show/Cloud:Tools/s3cmd

python s3test.py

次のような内容が出力されます。

my-new-bucket 2015-07-22T15:37:42.000Z

11.5.1.2 Swiftインタフェースへのアクセス

SwiftインタフェースでObject Gatewayにアクセスするには、 swiftコマンドラインクライアントが必要

です。コマンドラインオプションについては、マニュアルページ man 1 swiftを参照してください。

このパッケージはSUSE Linux Enterprise 12 SP3の「Public Cloud」モジュールに含まれていま

す。パッケージをインストールする前に、このモジュールを有効にしてソフトウェアリポジトリを更新する

必要があります。

sudo SUSEConnect -p sle-module-public-cloud/12/x86_64sudo zypper refresh

swiftコマンドをインストールするには、次のコマンドを実行します。

sudo zypper in python-swiftclient

Swiftにアクセスするには、次の構文を使用します。

swift -A http://IP_ADDRESS/auth/1.0 \-U example_user:swift -K 'swift_secret_key' list

IP_ADDRESSは、ゲートウェイサーバのIPアドレスに置き換えてくださ

い。 swift_secret_keyは、11.5.2.1項「S3およびSwiftユーザの追加」で swiftユーザを対象に実

行した radosgw-admin key createコマンドの出力の値に置き換えてください。


swift -A http://gateway.example.com/auth/1.0 -U example_user:swift \-K 'r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h' list

出力は次のとおりです。

my-new-bucket

125 Object Gatewayへのアクセス SES 5

11.5.2 S3およびSwiftアカウントの管理

11.5.2.1 S3およびSwiftユーザの追加

エンドユーザがゲートウェイを操作できるようにするには、ユーザ、アクセスキー、および秘密を作成す

る必要があります。ユーザには、「ユーザ」と「サブユーザ」の2種類があります。「ユーザ」はS3インタ

フェースを操作する場合に使用し、「サブユーザ」はSwiftインタフェースのユーザです。各サブユーザ

は特定のユーザに関連付けられます。

DeepSeaファイル rgw.slsを使用してユーザを追加することもできます。例については、14.3.1項

「NFS Ganesha用の異なるObject Gatewayユーザ」を参照してください。

Swiftユーザを作成するには、次の手順に従います。

1. Swiftユーザ(ここでの用語では「サブユーザ」)を作成するために、まず関連付けられた「ユー

ザ」を作成する必要があります。

sudo radosgw-admin user create --uid=username \ --display-name="display-name" --email=email


sudo radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ [email protected]

2. このユーザのサブユーザ(Swiftインタフェース)を作成するために、ユーザID (--

uid= username )、サブユーザID、およびサブユーザのアクセスレベルを指定する必要がありま

す。

sudo radosgw-admin subuser create --uid=uid \ --subuser=uid \ --access=[ read | write | readwrite | full ]


sudo radosgw-admin subuser create --uid=example_user \ --subuser=example_user:swift --access=full

3. ユーザの秘密鍵を生成します。

sudo radosgw-admin key create \ --gen-secret \

126 S3およびSwiftアカウントの管理 SES 5

--subuser=example_user:swift \ --key-type=swift

4. どちらのコマンドでも、ユーザの状態を示すJSON形式のデータが出力されます。次の行に注意

し、 secret_keyの値を覚えます。

"swift_keys": [ { "user": "example_user:swift", "secret_key": "r5wWIxjOCeEO7DixD1FjTLmNYIViaC6JVhi3013h"}],

S3インタフェースを介してObject Gatewayにアクセスする場合、次のコマンドを実行してS3ユーザを

作成する必要があります。

sudo radosgw-admin user create --uid=username \ --display-name="display-name" --email=email


sudo radosgw-admin user create \ --uid=example_user \ --display-name="Example User" \ [email protected]

このコマンドは、ユーザのアクセスキーと秘密鍵も生成します。 access_keyおよび secret_keyの

キーワードの出力とそれらの値を確認します。

[...] "keys": [ { "user": "example_user", "access_key": "11BS02LGFB6AL6H1ADMW", "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}], [...]

11.5.2.2 S3およびSwiftユーザの削除

ユーザを削除する手順は、S3ユーザでもSwiftユーザでも同様です。ただし、Swiftユーザの場合、その

サブユーザを含むユーザを削除する必要があります。

S3またはSwiftユーザ(その全サブユーザを含む)を削除するには、次のコマンドで user rmとユーザ

IDを指定します。

sudo radosgw-admin user rm --uid=example_user

サブユーザを削除するには、 subuser rmとサブユーザIDを指定します。


sudo radosgw-admin subuser rm --uid=example_user:swift

次のオプションを利用できます。

--purge-data

ユーザIDに関連付けられたすべてのデータをパージします。

--purge-keys

ユーザIDに関連付けられたすべてのキーをパージします。

ヒント: サブユーザの削除サブユーザを削除すると、Swiftインタフェースへのアクセスも削除されます。そのユーザはシス

テムに残ります。

11.5.2.3 S3およびSwiftユーザのアクセスキーと秘密鍵の変更

access_keyおよび secret_keyのパラメータは、ゲートウェイにアクセスする際にObject Gateway

ユーザを識別します。既存のユーザのキーを削除すると、古いキーは上書きされます。そのため、これは

新しいユーザを作成することと同じです。

S3ユーザの場合、次のコマンドを実行します。

sudo radosgw-admin key create --uid=example_user --key-type=s3 --gen-access-key --gen-secret

Swiftユーザの場合、次のコマンドを実行します。

sudo radosgw-admin key create --subuser=example_user:swift --key-type=swift --gen-secret

--key-type=type

キーのタイプを指定します。 swiftまたは s3です。

--gen-access-key

ランダムなアクセスキーを生成します(デフォルトではS3ユーザ用)。

--gen-secret

ランダムな秘密鍵を生成します。

--secret=key

秘密鍵を指定します。たとえば、手動で生成した秘密鍵を指定します。


11.5.2.4 ユーザクォータの管理

Ceph Object Gatewayでは、ユーザと、ユーザが所有するバケットにクォータを設定できます。バケッ

ト内のオブジェクトの最大数や、最大ストレージサイズ(メガバイト単位)などのクォータがあります。

ユーザクォータを有効にする前に、まずそのパラメータを設定する必要があります。

sudo radosgw-admin quota set --quota-scope=user --uid=example_user \ --max-objects=1024 --max-size=1024

--max-objects

オブジェクトの最大数を指定します。負の値を指定すると、クォータの確認が無効になります。

--max-size

最大バイト数を指定します。負の値を指定すると、クォータの確認が無効になります。

--quota-scope

クォータのスコープを設定します。オプションは bucketおよび userです。バケットクォータは、

ユーザが所有するバケットに適用されます。ユーザクォータはユーザに適用されます。

ユーザクォータを選択したら、そのクォータを有効にできます。

sudo radosgw-admin quota enable --quota-scope=user --uid=example_user

クォータを無効にするには、次のコマンドを実行します。

sudo radosgw-admin quota disable --quota-scope=user --uid=example_user

クォータの設定を一覧にするには、次のコマンドを実行します。

sudo radosgw-admin user info --uid=example_user

クォータの統計を更新するには、次のコマンドを実行します。

sudo radosgw-admin user stats --uid=example_user --sync-stats

11.6 Object GatewayでのHTTPS/SSLの有効化デフォルトのObject Gatewayの役割を有効にしてSSLで安全に通信するには、CAによって発行され

た証明書を持っているか、自己署名証明書を作成する必要があります。HTTPSを有効にしてObject

Gatewayを設定する方法には、デフォルト設定を利用する簡単な方法と、HTTPS関連の設定を微調

整できる高度な方法の2つがあります。

129 Object GatewayでのHTTPS/SSLの有効化 SES 5

11.6.1 自己署名証明書の作成

ヒントCAによって署名された有効な証明書をすでに持っている場合、このセクションはスキップしてく

ださい。

デフォルトでは、DeepSeaは、Salt Masterの /srv/salt/ceph/rgw/cert/rgw.pemにある証明

書ファイルを必要とします。その後、Object Gatewayの役割を持つSalt Minionの /etc/ceph/

rgw.pemにその証明書を配布し、Cephがその証明書を読み込みます。

次の手順では、Salt Masterノード上で自己署名SSL証明書を生成する方法について説明します。

1. Object Gatewayに認識させるすべてのホスト名について、 /etc/ssl/openssl.cnfファイル

の [v3_req]セクションに subjectAltNameオプションを追加します。

[...][ v3_req ]subjectAltName = ${ENV::SAN}[...]

2. opensslを使用して、キーと証明書を作成します。 opensslにプレフィックス env

SAN=DNS:fqdnを付けます。証明書に含める必要があるデータをすべて入力します。FQDNを一

般名として入力することをお勧めします。証明書に署名する前に、「Requested Extensions」

に「X509v3 Subject Alternative Name:」が含まれていること、および生成された証明書に

「X509v3 Subject Alternative Name:」が設定されていることを確認します。

root@master # env SAN=DNS:fqdn openssl req -x509 -nodes -days 1095 \ -newkey rsa:4096 -keyout rgw.key -out /srv/salt/ceph/rgw/cert/rgw.pem

11.6.2 簡単なHTTPS設定

デフォルトでは、Object Gatewayノード上のCephは、 /etc/ceph/rgw.pem証明書を読み込み、ポー

ト443を使用してセキュアなSSL通信を行います。これらの値を変更する必要がない場合は、次の手順

に従います。

1. /srv/pillar/ceph/stack/global.ymlを編集して次の行を追加します。

rgw_configurations: rgw-sslrgw_init: default-ssl

130 自己署名証明書の作成 SES 5

2. DeepSeaステージ2、3、および4を実行して変更を適用します。

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

11.6.3 高度なHTTPS設定

Object GatewayのSSL設定のデフォルト値を変更する必要がある場合は、次の手順に従います。

1. Object GatewayのデフォルトのSSL設定を ceph.conf.dサブディレクトリにコピーします。

root@master # cp /srv/salt/ceph/configuration/files/rgw-ssl.conf \ /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.conf

2. /srv/salt/ceph/configuration/files/ceph.conf.d/rgw.confを編集し、ご使用のセッ

トアップを反映するようにデフォルトのオプション(ポート番号やSSL証明書のパスなど)を変更し

ます。

3. DeepSeaステージ3および4を実行して変更を適用します。


ヒント: 複数のポートへのバインドCivetWebサーバは複数のポートにバインドできます。これは、1つのObject Gatewayインスタ

ンスにSSL接続と非SSL接続の両方でアクセスする必要がある場合に便利です。ポートを指定

する場合、各番号をプラス記号「+」で区切ります。次に、2ポート設定の行の例を示します。

[client.{{ client }}]rgw_frontends = civetweb port=80+443s ssl_certificate=/etc/ceph/rgw.pem

11.7 同期モジュールJewelで導入されたObject Gatewayの「マルチサイト」機能は、複数のゾーンを作成して、それらの

ゾーン間でデータとメタデータをミラーリングできるようにします。「同期モジュール」は、データとメタ

データを別の外部層へ転送できるようにするマルチサイトフレームワーク上に構築されています。同期

モジュールにより、データの変更が発生した場合に一連のアクションを実行できます(バケットやユーザ

131 高度なHTTPS設定 SES 5

の作成などのメタデータの操作もデータの変更と見なされます)。マルチサイトでのrgwの変更は最終

的にリモートサイトで一貫性が保たれるので、変更は非同期で伝搬されます。これにより、外部のクラウ

ドクラスタへのObject Storageのバックアップ、テープドライブを使用するカスタムバックアップソリュー

ション、Elasticsearchでのメタデータのインデックス作成といった使用事例が可能になります。

11.7.1 ゾーンの同期同期モジュール設定はゾーンにローカルです。同期モジュールは、ゾーンがデータをエクスポートする

のか、それとも別のゾーンで変更されたデータを使用できるだけかを判断します。Luminousの時点で

サポートされている同期プラグインは、 elasticsearch 、 rgw (ゾーン間でデータを同期するデフォル

トの同期プラグイン)、および log (リモートゾーンで実行されるメタデータ操作を記録する単純な同期

プラグイン)です。以降のセクションでは、 elasticsearch同期モジュールを使用するゾーンを例にし

て説明します。他の同期プラグインでもプロセスは同様です。

注記: デフォルトの同期プラグインrgwはデフォルトの同期プラグインで、明示的な設定は必要はありません。

11.7.1.1 要件と前提

11.11項「マルチサイトObject Gateway」で説明されているような、2つのゾーン us-eastと us-

westで構成される単純なマルチサイト設定を前提にしましょう。ここでは、他のサイトからのメタデータ

のみを処理するゾーンである3つ目のゾーン us-east-esを追加します。このゾーンは、 us-eastと同

じCephクラスタにあっても、別のクラスタにあっても構いません。このゾーンは他のゾーンからのメタ

データのみを使用し、このゾーンのObject Gatewayはエンドユーザの要求を直接実行することはあり

ません。

11.7.1.2 同期モジュールの設定

1. 11.11項「マルチサイトObject Gateway」で説明されているものと同様の3つ目のゾーンを作

成します。次に例を示します。

root # radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-es \--access-key={system-key} --secret={secret} --endpoints=http://rgw-es:80

2. 次のコマンドを使用して、このゾーンに対して同期モジュールを設定できます。

root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type={tier-type} \

132 ゾーンの同期 SES 5

--tier-config={set of key=value pairs}

3. たとえば、 elasticsearch同期モジュールでは、次のコマンドを実行します。

root # radosgw-admin zone modify --rgw-zone={zone-name} --tier-type=elasticsearch \--tier-config=endpoint=http://localhost:9200,num_shards=10,num_replicas=1

サポートされているさまざまなtier-configオプションについては、11.7.2項「Elasticsearchでの

メタデータの保存」を参照してください。

4. 最後にピリオドを更新します。

root # radosgw-admin period update --commit

5. 続いて、ゾーンでradosgwを起動します。

root # systemctl start ceph-radosgw@rgw.`hostname -s`root # systemctl enable ceph-radosgw@rgw.`hostname -s`

11.7.2 Elasticsearchでのメタデータの保存

この同期モジュールは他のゾーンからElasticsearchにメタデータを書き込みます。Luminousの時点

では、これは、現在Elasticsearchに保存しているJSON形式のデータフィールドです。

{ "_index" : "rgw-gold-ee5863d6", "_type" : "object", "_id" : "34137443-8592-48d9-8ca7-160255d52ade.34137.1:object1:null", "_score" : 1.0, "_source" : { "bucket" : "testbucket123", "name" : "object1", "instance" : "null", "versioned_epoch" : 0, "owner" : { "id" : "user1", "display_name" : "user1" }, "permissions" : [ "user1" ], "meta" : { "size" : 712354, "mtime" : "2017-05-04T12:54:16.462Z", "etag" : "7ac66c0f148de9519b8bd264312c4d64" }

133 Elasticsearchでのメタデータの保存 SES 5

}}

11.7.2.1 Elasticsearchの層タイプの設定パラメータ

endpoint

アクセスするElasticsearchサーバエンドポイントを指定します。

num_shards

(整数)データ同期初期化時にElasticsearchに設定するシャードの数。初期化後は変更できな

いことに注意してください。ここで変更を行った場合、Elasticsearchのインデックスの再構築と、

データ同期プロセスの再初期化が必要になります。

num_replicas

(整数)データ同期初期化時にElasticsearchに設定するレプリカの数。

explicit_custom_meta

(true | false)すべてのユーザカスタムメタデータのインデックスを作成するか、それともカスタム

メタデータエントリのインデックスを作成する対象をユーザが(バケットレベルで)設定する必要が

あるかを指定します。デフォルトではfalseになっています。

index_buckets_list

(文字列のコンマ区切りリスト)空の場合、すべてのバケットのインデックスが作成されます。空で

ない場合、ここで指定したバケットのインデックスのみが作成されます。バケットのプレフィックス

(「foo*」など)またはサフィックス(「*bar」など)を指定できます。

approved_owners_list

(文字列のコンマ区切りリスト)空の場合、すべての所有者のバケットのインデックスが作成されま

す(他の制約に依存)。空でない場合、指定した所有者が所有するバケットのインデックスのみが

作成されます。サフィックスとプレフィックスを指定することもできます。

override_index_path

(文字列)空でない場合、この文字列がElasticsearchのインデックスパスとして使用されます。空

の場合、インデックスパスは同期初期化時に決定されて生成されます。

11.7.2.2 メタデータクエリ

Elasticsearchクラスタにオブジェクトメタデータが保存されるようになったので、Elasticsearchエンド

ポイントを一般に公開しないようにし、エンドポイントにはクラスタ管理者のみがアクセスできるようにす

ることが重要です。ユーザが自身のメタデータのみを問い合わせ、他のユーザのメタデータは問い合わ


せないようにする必要があるため、メタデータクエリをエンドユーザそのものに公開すると、問題が発生

します。このためには、ElasticsearchクラスタでもRGWと同様の方法でユーザを認証する必要があり

ますが、これが問題になります。

Luminousから、メタデータマスタゾーンのRGWでエンドユーザの要求を実行できるようになりました。

これにより、Elasticsearchエンドポイントを一般に公開しないようにできると同時に、RGWそのものが

エンドユーザの要求を認証できるので、認証と権限付与の問題も解決します。このために、RGWでは、

バケットAPIにElasticsearchの要求を実行できる新しいクエリが導入されています。これらの要求は

すべてメタデータマスタゾーンに送信する必要があります。

Elasticsearchクエリの取得

GET /BUCKET?query={query-expr}

要求パラメータ:

max-keys: 返されるエントリの最大数

marker: ページ分割マーカ

expression := [(]<arg> <op> <value> [)][<and|or> ...]

演算子は、<、<=、==、>=、>の1つです。


GET /?query=name==foo

ユーザが読み込み許可を持つ、「foo」という名前のインデックス作成済みキーをすべて返します。

出力は、S3のバケット一覧の応答に似たXML形式のキーのリストになります。

カスタムメタデータフィールドの設定

インデックスの作成が必要なカスタムメタデータエントリ(指定したバケットの下層)と、これらの

キーのタイプを定義します。カスタムメタデータのインデックス作成が明示的に設定されている場

合、rgwによって指定のカスタムメタデータ値のインデックスが作成されるようにするため、これが

必要になります。それ以外の場合は、インデックスが作成されるメタデータキーのタイプが文字列

以外のときに必要です。

POST /BUCKET?mdsearchx-amz-meta-search: <key [; type]> [, ...]

複数のメタデータフィールドはコンマで区切る必要があります。「;」を使用して、フィールドに対して

タイプを強制的に適用できます。現在使用できるタイプは、文字列(デフォルト)、整数、および日付

です。たとえば、カスタムオブジェクトメタデータx-amz-meta-yearを整数、x-amz-meta-dateを

日付タイプ、およびx-amz-meta-titleを文字列としてインデックスを作成する場合、次のように指

定します。


POST /mybooks?mdsearchx-amz-meta-search: x-amz-meta-year;int, x-amz-meta-release-date;date, x-amz-meta-title;string

カスタムメタデータ設定の削除

カスタムメタデータのバケット設定を削除します。

DELETE /BUCKET?mdsearch

カスタムメタデータ設定の取得

カスタムメタデータのバケット設定を取得します。

GET /BUCKET?mdsearch

11.8 LDAP認証デフォルトのローカルユーザ認証とは別に、Object GatewayでLDAPサーバのサービスを使用して

ユーザを認証することもできます。

11.8.1 認証メカニズム

Object GatewayがトークンからユーザのLDAP資格情報を抽出します。ユーザ名から検索フィルタが

構成されます。Object Gatewayは、設定済みのユーザアカウントを使用して、一致するエントリをディ

レクトリで検索します。エントリが見つかった場合、Object Gatewayは、トークンから抽出したパスワー

ドを使用して、見つかった識別名へのバインドを試みます。資格情報が有効であれば、バインドが成功

し、Object Gatewayはアクセスを許可します。

許可するユーザを制限するには、検索ベースを特定の部門に設定するか、カスタム検索フィルタを指定

します。たとえば、特定のグループメンバーシップ、カスタムオブジェクトクラス、またはカスタム属性を要

求できます。

11.8.2 要件

「LDAPまたはActive Directory」: Object Gatewayがアクセス可能な動作中のLDAPインス

タンス。

「サービスアカウント」: Object Gatewayが検索許可と共に使用するLDAP資格情報。

「ユーザアカウント」: LDAPディレクトリ内の1つ以上のユーザアカウント。

136 LDAP認証 SES 5

重要: LDAPユーザとローカルユーザを重複させないローカルユーザの名前と、LDAPを使用して認証するユーザの名前に同じユーザ名を使用する

ことはできません。Object Gatewayはこれらのユーザを区別できず、同じユーザとして扱いま

す。

ヒント: 正常性チェックサービスアカウントまたはLDAP接続を確認するには、 ldapsearchユーティリティを使用しま

す。次に例を示します。

ldapsearch -x -D "uid=ceph,ou=system,dc=example,dc=com" -W \-H ldaps://example.com -b "ou=users,dc=example,dc=com" 'uid=*' dn

想定される問題を排除するため、必ずCephの設定ファイルと同じLDAPパラメータを使用して

ください。

11.8.3 LDAP認証を使用するためのObject Gatewayの設定

/etc/ceph/ceph.conf設定ファイルでLDAP認証に関連するパラメータは次のとおりです。

rgw_ldap_uri

使用するLDAPサーバを指定します。プレーンテキストの資格情報がオープンに転送されるのを

避けるため、必ず ldaps://fqdn:portパラメータを使用してください。

rgw_ldap_binddn

Object Gatewayが使用するサービスアカウントの識別名(DN)。

rgw_ldap_secret

サービスアカウントのパスワード。

rgw_ldap_searchdn

ユーザを検索するための、ディレクトリ情報ツリーのベースを指定します。users部門または具体

的なOU(部門)にすることができます。

rgw_ldap_dnattr

ユーザ名を照合するために、構成された検索フィルタで使用される属性。DIT (ディレクトリ情報

ツリー)に応じて、 uidまたは cnになります。

rgw_search_filter

137 LDAP認証を使用するためのObject Gatewayの設定 SES 5

指定されていない場合、Object Gatewayは自動的に rgw_ldap_dnattr設定を使用して検索

フィルタを構成します。このパラメータは、許可するユーザのリストを非常に柔軟な方法で絞り込

む場合に使用します。詳細については、11.8.4項「カスタム検索フィルタを使用したユーザアクセ

スの制限」を参照してください。

11.8.4 カスタム検索フィルタを使用したユーザアクセスの制限

rgw_search_filterパラメータは2つの方法で使用できます。

11.8.4.1 構成された検索フィルタをさらに制限するための部分フィルタ

次に、部分フィルタの例を示します。

"objectclass=inetorgperson"

Object Gatewayは、トークンから抽出したユーザ名と値 rgw_ldap_dnattrを使用して通常の方法

で検索フィルタを生成します。続いて、構成されたフィルタが rgw_search_filter属性の部分フィル

タと結合されます。ユーザ名と設定によっては、最終的な検索フィルタは次のようになります。

"(&(uid=hari)(objectclass=inetorgperson))"

この場合、ユーザ「hari」がLDAPディレクトリで見つかり、オブジェクトクラス「inetorgperson」を持っ

ていて、有効なパスワードを指定したときにのみ、このユーザにアクセスが許可されます。

11.8.4.2 完全なフィルタ

完全なフィルタには、認証試行中にユーザ名に置き換えられる USERNAMEトークンが含まれる必要があ

ります。この場合、 rgw_ldap_dnattrパラメータは使用されなくなります。たとえば、有効なユーザを特

定のグループに制限するには、次のフィルタを使用します。

"(&(uid=USERNAME)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

注記: memberOf属性LDAP検索で memberOf属性を使用するには、特定のLDAPサーバ実装からのサーバサイドの

サポートが必要です。

138 カスタム検索フィルタを使用したユーザアクセスの制限 SES 5

11.8.5 LDAP認証用アクセストークンの生成

radosgw-tokenユーティリティは、LDAPユーザ名とパスワードに基づいてアクセストークンを生成し

ます。実際のアクセストークンであるBase-64エンコード文字列を出力します。好みのS3クライアント

(11.5.1項「Object Gatewayへのアクセス」を参照)を使用し、このトークンをアクセスキーとして指定

し、空の秘密鍵を使用します。

root@minion > export RGW_ACCESS_KEY_ID="username"root@minion > export RGW_SECRET_ACCESS_KEY="password"root@minion > radosgw-token --encode --ttype=ldap

重要: クリアテキスト資格情報アクセストークンはBase-64エンコードのJSON構造で、LDAP資格情報がクリアテキストで含

まれます。

注記: Active DirectoryActive Directoryでは、 --ttype=adパラメータを使用します。

11.9 バケットインデックスのシャーディングObject Gatewayは、バケットインデックスデータをインデックスプール(デフォルトで

は .rgw.buckets.index )に保存します。1つのバケットに配置するオブジェクトが多すぎる(数十

万個)場合、バケットあたりのオブジェクトの最大数のクォータ( rgw bucket default quota max

objects )を設定しないと、インデックスプールのパフォーマンスが低下することがあります。「バケットイ

ンデックスのシャーディング」は、このようなパフォーマンス低下を防止し、各バケットで大量のオブジェ

クトを使用できるようになります。

11.9.1 バケットインデックスのリシャーディング

バケットが大容量になり、初期設定が十分ではなくなった場合、バケットのインデックスプールをリシャー

ディングする必要があります。オンラインの自動バケットインデックスリシャーディングを使用することも

(11.9.1.1項「動的リシャーディング」を参照)、バケットインデックスをオフラインで手動でリシャーディ

ングすることもできます(11.9.1.2項「手動リシャーディング」を参照)。

139 LDAP認証用アクセストークンの生成 SES 5

11.9.1.1 動的リシャーディング

SUSE Enterprise Storage 5から、オンラインのバケットリシャーディングがサポートされています。こ

れは、バケットあたりのオブジェクト数が一定のしきい値に達しているかどうかを検出し、バケットイン

デックスで使用されるシャードの数を自動的に増やします。このプロセスにより、各バケットインデックス

シャードのエントリの数が減ります。

検出プロセスは次の条件で実行されます。

バケットに新しいオブジェクトが追加された場合。

すべてのバケットを定期的にスキャンするバックグラウンドプロセス内。これは、更新されない既存

のバケットに対応するために必要です。

リシャーディングが必要なバケットは reshard_logキューに追加され、後でリシャーディングするようス

ケジュールされます。リシャードスレッドはバックグラウンドで動作し、スケジュールされたリシャーディン

グを一度に1つずつ実行します。

動的リシャーディングの設定

rgw_dynamic_resharding

動的バケットインデックスリシャーディングを有効/無効にします。設定可能な値は「true」または

「false」です。デフォルトは「true」です。

rgw_reshard_num_logs

リシャーディングログの対象にするシャードの数。デフォルトは16です。

rgw_reshard_bucket_lock_duration

リシャーディング中のバケットオブジェクトに対するロック期間。デフォルトは120秒です。

rgw_max_objs_per_shard

バケットインデックスシャードあたりのオブジェクトの最大数。デフォルトは100000オブジェクト

です。

rgw_reshard_thread_interval

リシャードスレッド処理のラウンド間の最大時間。デフォルトは600秒です。

重要: マルチサイト設定動的シャーディングはマルチサイト環境ではサポートされません。Ceph 12.2.2以降ではデフォ

ルトで無効になっていますが、設定の再確認をお勧めします。

リシャーディングプロセスを管理するためのコマンド

リシャーディングキューへのバケットの追加

140 バケットインデックスのリシャーディング SES 5

root@minion > radosgw-admin reshard add \ --bucket BUCKET_NAME \ --num-shards NEW_NUMBER_OF_SHARDS

リシャーディングキューの一覧

root@minion > radosgw-admin reshard list

バケットリシャーディングの処理/スケジュール

root@minion > radosgw-admin reshard process

バケットリシャーディングの状態の表示

root@minion > radosgw-admin reshard status --bucket BUCKET_NAME

保留中のバケットリシャーディングのキャンセル

root@minion > radosgw-admin reshard cancel --bucket BUCKET_NAME

11.9.1.2 手動リシャーディング

11.9.1.1項「動的リシャーディング」で説明されている動的リシャーディングは、単純なObject

Gateway設定でのみサポートされます。マルチサイト設定の場合は、このセクションで説明する手動リ

シャーディングを使用します。

バケットインデックスをオフラインで手動でリシャーディングするには、次のコマンドを使用します。

root@minion > radosgw-admin bucket reshard

bucket reshardコマンドは次の処理を実行します。

指定したオブジェクトに対してバケットインデックスオブジェクトの新しいセットを作成する

これらのインデックスオブジェクトのすべてのオブジェクトエントリを分散する

新しいバケットインスタンスを作成する

新しいバケットインスタンスをバケットにリンクし、すべての新規インデックス操作が新しいバケット

インデックスを経由するようにする

新旧のバケットIDを標準出力に出力する

141 バケットインデックスのリシャーディング SES 5

手順 11.1: バケットインデックスプールのリシャーディング

1. バケットに対するすべての操作が停止していることを確認します。

2. 元のバケットインデックスをバックアップします。

root@minion > radosgw-admin bi list \ --bucket=BUCKET_NAME \ > BUCKET_NAME.list.backup

3. バケットインデックスをリシャーディングします。

root@minion > radosgw-admin reshard \ --bucket=BUCKET_NAME \ --num-shards=NEW_SHARDS_NUMBER

ヒント: 古いバケットIDこのコマンドは、出力の一部として新旧のバケットIDも出力します。古いバケットIDを記録

しておいてください。古いバケットインデックスオブジェクトをパージする場合に必要にな

ります。

4. 新旧のバケットインデックスのリストを比較して、オブジェクトが正しく一覧にされていることを確

認します。その後、古いバケットインデックスオブジェクトをパージします。

root@minion > radosgw-admin bi purge --bucket=BUCKET_NAME --bucket-id=OLD_BUCKET_ID

11.9.2 新しいバケットのバケットインデックスシャーディングバケットインデックスシャーディングを制御するオプションは2つあります。

単純な設定の場合は、 rgw_override_bucket_index_max_shardsオプションを使用します。

マルチサイト設定の場合は、 bucket_index_max_shardsオプションを使用します。

これらのオプションを 0に設定すると、バケットインデックスシャーディングが無効になります。 0より大き

い値にすると、バケットインデックスシャーディングが有効になり、シャードの最大数が設定されます。

シャードの推奨数を計算するには、次の式が役立ちます。

number_of_objects_expected_in_a_bucket / 100000

シャードの最大数は7877であることに注意してください。

142 新しいバケットのバケットインデックスシャーディング SES 5

11.9.2.1 単純な設定

1. Ceph設定ファイルを開き、次のオプションを追加または変更します。

rgw_override_bucket_index_max_shards = 12

ヒント: すべてまたは1つのObject GatewayインスタンスObject Gatewayのすべてのインスタンスに対してバケットイン

デックスシャーディングを設定するには、 [global]セクション

に rgw_override_bucket_index_max_shardsを追加します。

Object Gatewayの特定のインスタンスに対してのみバケットインデッ

クスシャーディングを設定するには、関連するインスタンスのセクション

に rgw_override_bucket_index_max_shardsを追加します。

2. Object Gatewayを再起動します。詳細については、11.3項「Object Gatewayサービスの操

作」を参照してください。

11.9.2.2 マルチサイト設定

マルチサイト設定では、フェールオーバーを管理するために別のインデックスプールを設定できます。1

つのゾーングループ内のゾーン全体に一貫したシャード数を設定するには、ゾーングループの設定

で bucket_index_max_shardsオプションを設定します。

1. ゾーングループの設定を zonegroup.jsonファイルにエクスポートします。

root@minion > radosgw-admin zonegroup get > zonegroup.json

2. zonegroup.jsonファイルを編集して、指定した各ゾーンに対し

て bucket_index_max_shardsオプションを設定します。

3. ゾーングループをリセットします。

root@minion > radosgw-admin zonegroup set < zonegroup.json

4. ピリオドを更新します。

root@minion > radosgw-admin period update --commit

143 新しいバケットのバケットインデックスシャーディング SES 5

11.10 OpenStack Keystoneの統合OpenStack Keystoneは、OpenStack製品の識別情報サービスです。Object Gatewayを

Keystoneと統合して、Keystoneの認証トークンを受け付けるゲートウェイを設定できます。Keystone

によってゲートウェイにアクセスする権限が付与されたユーザは、Ceph Object Gateway側で確認さ

れ、必要であれば自動的に作成されます。Object Gatewayは、取り消されたトークンのリストを定期的

にKeystoneに問い合わせます。

11.10.1 OpenStackの設定

Ceph Object Gatewayを設定する前に、Swiftサービスを有効にしてCeph Object Gatewayを指す

ようにOpenStack Keystoneを設定する必要があります。

1. Swiftサービスを設定します。OpenStackを使用してSwiftユーザを検証するには、まずSwift

サービスを作成します。

root # openstack service create \ --name=swift \ --description="Swift Service" \ object-store

2. エンドポイントを設定します。Swiftサービスを作成した後、Ceph Object Gatewayを指すように

します。 REGION_NAMEは、ゲートウェイのゾーングループ名またはリージョン名に置き換えます。

root # openstack endpoint create --region REGION_NAME \ --publicurl "http://radosgw.example.com:8080/swift/v1" \ --adminurl "http://radosgw.example.com:8080/swift/v1" \ --internalurl "http://radosgw.example.com:8080/swift/v1" \ swift

3. 設定を確認します。Swiftサービスを作成してエンドポイントを設定した後、エンドポイントを表示

して、すべての設定が正しいことを確認します。

root # openstack endpoint show object-store

144 OpenStack Keystoneの統合 SES 5

11.10.2 Ceph Object Gatewayの設定

11.10.2.1 SSL証明書の設定

Ceph Object Gatewayは、取り消されたトークンのリストを定期的にKeystoneに問い合わせます。こ

れらの要求はエンコードおよび署名されています。同様にエンコードおよび署名された自己署名トーク

ンを提供するようKeystoneを設定することもできます。これらの署名されたメッセージをデコードして検

証できるようゲートウェイを設定する必要があります。したがって、Keystoneが要求を作成するために

使用するOpenSSL証明書を「nss db」フォーマットに変換する必要があります。

root # mkdir /var/ceph/nssroot # openssl x509 -in /etc/keystone/ssl/certs/ca.pem \ -pubkey | certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"rootopenssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem \ -pubkey | certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

Ceph Object GatewayがOpenStack Keystoneと対話できるようにするため、OpenStack

Keystoneで自己署名SSL証明書を使用できます。Ceph Object Gatewayが実行されているノー

ドにKeystoneのSSL証明書をインストールするか、オプション rgw keystone verify sslの値を

「false」に設定します。 rgw keystone verify sslを「false」に設定すると、ゲートウェイが証明書の

検証を試行しないことを意味します。

11.10.2.2 Object Gatewayのオプションの設定

次のオプションを使用してKeystone統合を設定できます。

rgw keystone api version

Keystone APIのバージョン。有効なオプションは2または3です。デフォルトは2です。

rgw keystone url

Keystoneサーバの管理RESTful APIのURLとポート番号。 SERVER_URL:PORT_NUMBERとい

うパターンに従います。

rgw keystone admin token

管理要求に対してKeystone内部で設定されるトークンと共有シークレット。

rgw keystone accepted roles

要求を実行するために必要な役割。デフォルトは「Member, admin」です。

rgw keystone accepted admin roles

145 Ceph Object Gatewayの設定 SES 5

ユーザが管理特権を得られるようにする役割のリスト。

rgw keystone token cache size

Keystoneトークンキャッシュのエントリの最大数。

rgw keystone revocation interval

拒否されたトークンを確認するまでの秒数。デフォルトは15 * 60です。

rgw keystone implicit tenants

新しいユーザを同じ名前の専用のテナント内に作成します。デフォルトは「false」です。

rgw s3 auth use keystone

「true」に設定すると、Ceph Object GatewayはKeystoneを使用してユーザを認証します。デ

フォルトは「false」です。

nss db path

NSSデータベースのパス。

OpenStackサービスの設定と同様の方法で、Keystoneサービステナント、Keystoneのユーザと

パスワード(OpenStack Identity APIのv2.0バージョンの場合)を設定することもできます。これに

より、設定ファイルで共有シークレット rgw keystone admin tokenを設定するのを避けることが

できます。このような設定は運用環境では無効にする必要があります。サービステナントの資格情報

には管理特権が必要です。詳細については、OpenStack Keystoneの公式ドキュメント (https://

docs.openstack.org/keystone/latest/#setting-up-projects-users-and-roles) を参照してくだ

さい。関連する設定オプションは次のとおりです。

rgw keystone admin user

Keystone管理者ユーザの名前。

rgw keystone admin password

Keystone管理者ユーザのパスワード。

rgw keystone admin tenant

Keystoneバージョン2.0の管理者ユーザのテナント。

Ceph Object GatewayのユーザはKeystoneテナントにマップされます。Keystoneユーザには、多

くの場合、複数のテナントで複数の役割が割り当てられます。Ceph Object Gatewayは、チケット

を取得すると、そのチケットに割り当てられているテナントとユーザの役割を確認し、 rgw keystone

accepted rolesオプションの設定に従って要求を受け入れるか拒否します。

146 Ceph Object Gatewayの設定 SES 5

https://docs.openstack.org/keystone/latest/#setting-up-projects-users-and-roles

https://docs.openstack.org/keystone/latest/#setting-up-projects-users-and-roles

ヒント: OpenStackテナントのマッピングSwiftテナントはデフォルトでObject Gatewayユーザにマップされますが、 rgw keystone

implicit tenantsオプションを使用してOpenStackテナントにマップすることもできます。こ

れにより、コンテナは、Object GatewayのデフォルトであるS3同様のグローバルネームスペー

スではなく、テナントのネームスペースを使用するようになります。混乱を避けるため、計画段階

でマッピング方法を決定することをお勧めします。その理由は、後でこのオプションを切り替えた

場合、テナント下にマッピングされた新しい要求のみが対象となり、前に作成された古いバケッ

トはグローバルネームスペースに存在し続けるためです。

OpenStack Identity APIのバージョン3では、 rgw keystone admin tenantオプションを次の内

容に置き換える必要があります。

rgw keystone admin domain

Keystone管理者ユーザのドメイン。

rgw keystone admin project

Keystone管理者ユーザのプロジェクト。

11.11 マルチサイトObject Gateway

ゾーン

1つ以上のObject Gatewayインスタンスを論理的にグループ化したもの。1つの「ゾーングルー

プ」に「マスタ」ゾーンとして指定されたゾーンが1つ存在する必要があります。このゾーンがバ

ケットとユーザの作成をすべて処理します。

ゾーングループ

ゾーングループは複数のゾーンで構成されます。システム設定の変更を処理するマスタゾーング

ループが1つ存在する必要があります。

ゾーングループマップ

システム全体のマップを保持する設定構造。たとえば、どのゾーングループがマスタであるか、異

なるゾーングループ間の関係、特定の設定オプション(ストレージポリシーなど)です。

レルム

ゾーングループのコンテナ。これによりクラスタ間でゾーングループを分離できます。複数のレル

ムを作成すると、同じクラスタ内でまったく異なる複数の設定を簡単に実行できます。

ピリオド

147 マルチサイトObject Gateway SES 5

ピリオドは、レルムの現在の状態の設定構造を格納します。すべてのピリオドに固有のIDとエポッ

クが含まれます。すべてのレルムには関連する現在のピリオドがあり、ゾーングループとストレージ

ポリシーの設定の現在の状態が格納されます。非マスタゾーンの設定を変更すると、ピリオドの

エポックが増加します。マスタゾーンを別のゾーンに変更すると、次の変更がトリガされます。

新しいピリオドIDとエポック1で新しいピリオドが生成される。

レルムの現在のピリオドが、新しく生成されたピリオドIDを指すように更新される。

レルムのエポックが増加する。

フェデレーションアーキテクチャに参加するよう各Object Gatewayを設定し、アクティブなゾーン設定

で動作しながら、非マスタゾーンへの書き込みを許可できます。

11.11.1 用語集

次に、フェデレーションアーキテクチャに固有の用語について説明します。

11.11.2 クラスタセットアップの例

この例では、アクティブにデータを同期する3つの別個のゾーンを持つゾーングループの作成に焦点を

当てて説明します。2つのゾーンは同じクラスタに属しているのに対し、3つ目のゾーンは別のクラスタに

属しています。Object Gateway間でのデータ変更のミラーリングに同期エージェントは関係していま

せん。これにより、設定スキームとアクティブ-アクティブ設定を大幅に簡素化できます。メタデータ操作

(新規ユーザの作成など)は引き続きマスタゾーンを経由する必要があることに注意してください。ただ

し、データ操作(バケットやオブジェクトの作成など)はどのゾーンでも処理できます。

11.11.3 システムキー

ゾーンの設定中に、Object Gatewayは、S3互換のシステムユーザ、およびそのアクセスキーと秘密鍵

を作成することを想定します。これにより、別のObject Gatewayインスタンスがそのアクセスキーと秘

密鍵を使用してリモートで設定を取得できます。S3ユーザの作成の詳細については、11.5.2.1項「S3

およびSwiftユーザの追加」を参照してください。

ヒントゾーンの作成そのものの前にアクセスキーと秘密鍵を生成しておくと、後でスクリプト作成や設

定管理ツールを使用するのが容易になるため、便利です。

148 用語集 SES 5

この例では、アクセスキーと秘密鍵が環境変数で次のように設定されていると想定しましょう。

# SYSTEM_ACCESS_KEY=1555b35654ad1656d805# SYSTEM_SECRET_KEY=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==

一般的に、アクセスキーは20文字の英数字で構成されるのに対し、秘密鍵は40文字の英数字で構成

されます(+/=の各文字も使用できます)。これらのキーは次のコマンドラインで生成できます。

# SYSTEM_ACCESS_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1)# SYSTEM_SECRET_KEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1)

11.11.4 命名規則この例では、マスタゾーンの設定プロセスについて説明します。米国全体を対象とする usという名前の

ゾーングループを想定します。これはマスタゾーングループになります。ここには、 zonegroup - zoneの

フォーマットで記述された2つのゾーンが含まれます。これはここだけの規則で、好きなフォーマットを選

択できます。まとめると次のようになります。

マスタゾーングループ: 米国 us

マスタゾーン: 米国東部1: us-east-1

セカンダリゾーン: 米国東部2: us-east-2

セカンダリゾーン: 米国西部: us-west

これは、 goldという名前のより大きいレルムの一部になります。 us-east-1および us-east-2のゾー

ンは同じCephクラスタの一部で、 us-east-1はプライマリゾーンです。 us-westは別のCephクラス

タにあります。

11.11.5 デフォルトプール適切な許可を使用して設定されている場合、Object Gatewayは単独でデフォルトプールを作成しま

す。 pg_numおよび pgp_numの値は、 ceph.conf設定ファイルから取得されます。ゾーンに関係する

プールはデフォルトで zone-name . pool-nameの規則に従います。たとえば、 us-east-1ゾーンでは、

次のプールになります。

.rgw.rootus-east-1.rgw.controlus-east-1.rgw.data.rootus-east-1.rgw.gcus-east-1.rgw.logus-east-1.rgw.intent-log

149 命名規則 SES 5

us-east-1.rgw.usageus-east-1.rgw.users.keysus-east-1.rgw.users.emailus-east-1.rgw.users.swiftus-east-1.rgw.users.uidus-east-1.rgw.buckets.indexus-east-1.rgw.buckets.dataus-east-1.rgw.meta

us-east-1を適切なゾーン名に置き換えれば、他のゾーンでもこれらのプールを作成できます。

11.11.6 レルムの作成goldというレルムを作成して、デフォルトのレルムにします。

cephadm > radosgw-admin realm create --rgw-realm=gold --default{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1}

すべてのレルムにIDがあることに注意してください。これによって、後から必要に応じてレルムの名前を

変更するなど、柔軟な操作が可能になります。 current_periodは、マスタゾーンで変更を行うたびに

変更されます。マスタゾーンの設定に変更がある場合、 epochが増加し、その結果、現在のピリオドが

変更されます。

11.11.7 デフォルトのゾーングループの削除Object Gatewayをデフォルトインストールすると、 defaultという名前のデフォルトのゾーングループ

が作成されます。デフォルトのゾーングループはもう必要ないので、削除します。

cephadm > radosgw-admin zonegroup delete --rgw-zonegroup=default

11.11.8 マスタゾーングループの作成usという名前のマスタゾーングループを作成します。このゾーングループは、ゾーングループマップを

管理し、システムの残りに変更を伝搬します。このゾーングループをデフォルトとしてマークすることによ

り、後のコマンドに対して明示的にrgw-zonegroupスイッチを指定できます。

cephadm > radosgw-admin zonegroup create --rgw-zonegroup=us \--endpoints=http://rgw1:80 --master --default

150 レルムの作成 SES 5

{ "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "", "zones": [], "placement_targets": [], "default_placement": "", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

または、次のコマンドを使用してゾーングループをデフォルトとしてマークできます。

cephadm > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.9 マスタゾーンの作成

続いて、デフォルトのゾーンを作成してデフォルトのゾーングループに追加します。ユーザの作成などの

メタデータ操作にはこのゾーンを使用することに注意してください。

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \--endpoints=http://rgw1:80 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "domain_root": "us-east-1/gc.rgw.data.root", "control_pool": "us-east-1/gc.rgw.control", "gc_pool": "us-east-1/gc.rgw.gc", "log_pool": "us-east-1/gc.rgw.log", "intent_log_pool": "us-east-1/gc.rgw.intent-log", "usage_log_pool": "us-east-1/gc.rgw.usage", "user_keys_pool": "us-east-1/gc.rgw.users.keys", "user_email_pool": "us-east-1/gc.rgw.users.email", "user_swift_pool": "us-east-1/gc.rgw.users.swift", "user_uid_pool": "us-east-1/gc.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement",

151 マスタゾーンの作成 SES 5

"val": { "index_pool": "us-east-1/gc.rgw.buckets.index", "data_pool": "us-east-1/gc.rgw.buckets.data", "data_extra_pool": "us-east-1/gc.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-east-1/gc.rgw.meta", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

--rgw-zonegroupおよび --defaultのスイッチは、ゾーンをゾーングループに追加して、そのゾーン

をデフォルトのゾーンにすることに注意してください。または、次のコマンドでも同じ操作を実行できま

す。

cephadm > radosgw-admin zone default --rgw-zone=us-east-1cephadm > radosgw-admin zonegroup add --rgw-zonegroup=us --rgw-zone=us-east-1

11.11.9.1 システムユーザの作成

ゾーンプールにアクセスするには、システムユーザを作成する必要があります。これらのキーは、セカン

ダリゾーンを設定するときにも必要になるので注意してください。

cephadm > radosgw-admin user create --uid=zone.user \--display-name="Zone User" --access-key=$SYSTEM_ACCESS_KEY \--secret=$SYSTEM_SECRET_KEY --system

11.11.9.2 ピリオドの更新

マスタゾーンの設定を変更したので、変更をコミットしてレルム設定構造で有効にする必要があります。

最初、ピリオドは次のようになっています。

cephadm > radosgw-admin period get{ "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "epoch": 1, "predecessor_uuid": "", "sync_status": [], "period_map": { "id": "09559832-67a4-4101-8b3f-10dfcd6b2707", "zonegroups": [], "short_zone_ids": [] }, "master_zonegroup": "", "master_zone": "", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }


}, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 1}

ピリオドを更新して変更をコミットします。

cephadm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 1, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]" ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" } ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [


{ "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 } ] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

11.11.9.3 Object Gatewayの起動

Object Gatewayを起動する前に、設定ファイルでObject Gatewayのゾーンとポートのオプションを

指定する必要があります。Object Gatewayとその設定の詳細については、第11章「Ceph Object

Gateway」を参照してください。Object Gatewayの設定セクションは次のようになっているはずです。

[client.rgw.us-east-1]rgw_frontends="civetweb port=80"rgw_zone=us-east-1

Object Gatewayを起動します。

sudo systemctl start [email protected]

11.11.10 セカンダリゾーンの作成同じクラスタ内に、 us-east-2という名前のセカンダリゾーンを作成して設定します。次のコマンドはす

べて、マスタゾーンそのものをホストするノードで実行できます。

セカンダリゾーンを作成するには、プライマリゾーンの作成時と同じコマンドを使用します。ただし、マス

タフラグは削除してください。

154 セカンダリゾーンの作成 SES 5

cephadm > radosgw-admin zone create --rgw-zonegroup=us --endpoints=http://rgw2:80 \--rgw-zone=us-east-2 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "domain_root": "us-east-2.rgw.data.root", "control_pool": "us-east-2.rgw.control", "gc_pool": "us-east-2.rgw.gc", "log_pool": "us-east-2.rgw.log", "intent_log_pool": "us-east-2.rgw.intent-log", "usage_log_pool": "us-east-2.rgw.usage", "user_keys_pool": "us-east-2.rgw.users.keys", "user_email_pool": "us-east-2.rgw.users.email", "user_swift_pool": "us-east-2.rgw.users.swift", "user_uid_pool": "us-east-2.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "us-east-2.rgw.buckets.index", "data_pool": "us-east-2.rgw.buckets.data", "data_extra_pool": "us-east-2.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-east-2.rgw.meta", "realm_id": "815d74c2-80d6-4e63-8cfc-232037f7ff5c"}

11.11.10.1 ピリオドの更新

ピリオドを更新して変更をコミットすることにより、システムマップの新しい変更内容をすべてのゲート

ウェイに通知します。

cephadm > radosgw-admin period update --commit{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "[...]" ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1",


"zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "false", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }

], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044


}, { "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }

] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e", "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}


セカンダリゾーンのObject Gatewayの設定を調整して、Object Gatewayを起動します。

[client.rgw.us-east-2]rgw_frontends="civetweb port=80"rgw_zone=us-east-2

cephadm > sudo systemctl start [email protected]

11.11.11 2つ目のクラスタへのObject Gatewayの追加

2つ目のCephクラスタは最初のクラスタと同じゾーングループに属しますが、地理的に別の場所に配

置できます。

157 2つ目のクラスタへのObject Gatewayの追加 SES 5

11.11.11.1 デフォルトのレルムとゾーングループ

すでに1つ目のゲートウェイのレルムを作成したので、そのレルムをここに移動してデフォルトにします。

cephadm > radosgw-admin realm pull --url=http://rgw1:80 \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY{ "id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "name": "gold", "current_period": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 2}cephadm > radosgw-admin realm default --rgw-realm=gold

ピリオドを取得してマスタゾーンから設定を取得します。

cephadm > radosgw-admin period pull --url=http://rgw1:80 \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

デフォルトのゾーングループを、すでに作成済みの usゾーングループに設定します。

cephadm > radosgw-admin zonegroup default --rgw-zonegroup=us

11.11.11.2 2つ目のゾーンの設定

us-westという名前の新しいゾーンを同じシステムキーで作成します。

cephadm > radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-west \--access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY \--endpoints=http://rgw3:80 --default{ "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-west", "domain_root": "us-west.rgw.data.root", "control_pool": "us-west.rgw.control", "gc_pool": "us-west.rgw.gc", "log_pool": "us-west.rgw.log", "intent_log_pool": "us-west.rgw.intent-log", "usage_log_pool": "us-west.rgw.usage", "user_keys_pool": "us-west.rgw.users.keys", "user_email_pool": "us-west.rgw.users.email", "user_swift_pool": "us-west.rgw.users.swift", "user_uid_pool": "us-west.rgw.users.uid", "system_key": { "access_key": "1555b35654ad1656d804", "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r\/2EI4ngqJxD7iBdBYLhwluN30JaT3Q==" }, "placement_pools": [ {


"key": "default-placement", "val": { "index_pool": "us-west.rgw.buckets.index", "data_pool": "us-west.rgw.buckets.data", "data_extra_pool": "us-west.rgw.buckets.non-ec", "index_type": 0 } } ], "metadata_heap": "us-west.rgw.meta", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7"}

11.11.11.3 ピリオドの更新

ゾーングループマップの変更を伝搬するため、ピリオドを更新してコミットします。

cephadm > radosgw-admin period update --commit --rgw-zone=us-west{ "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "epoch": 3, "predecessor_uuid": "09559832-67a4-4101-8b3f-10dfcd6b2707", "sync_status": [ "", # truncated ], "period_map": { "id": "b5e4d3ec-2a62-4746-b479-4b2bc14b27d1", "zonegroups": [ { "id": "d4018b8d-8c0d-4072-8919-608726fa369e", "name": "us", "api_name": "us", "is_master": "true", "endpoints": [ "http:\/\/rgw1:80" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "zones": [ { "id": "83859a9a-9901-4f00-aa6d-285c777e10f0", "name": "us-east-1", "endpoints": [ "http:\/\/rgw1:80" ], "log_meta": "true", "log_data": "true", "bucket_index_max_shards": 0,


"read_only": "false" }, { "id": "950c1a43-6836-41a2-a161-64777e07e8b8", "name": "us-east-2", "endpoints": [ "http:\/\/rgw2:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" }, { "id": "d9522067-cb7b-4129-8751-591e45815b16", "name": "us-west", "endpoints": [ "http:\/\/rgw3:80" ], "log_meta": "false", "log_data": "true", "bucket_index_max_shards": 0, "read_only": "false" } ], "placement_targets": [ { "name": "default-placement", "tags": [] } ], "default_placement": "default-placement", "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7" } ], "short_zone_ids": [ { "key": "83859a9a-9901-4f00-aa6d-285c777e10f0", "val": 630926044 }, { "key": "950c1a43-6836-41a2-a161-64777e07e8b8", "val": 4276257543 }, { "key": "d9522067-cb7b-4129-8751-591e45815b16", "val": 329470157 } ] }, "master_zonegroup": "d4018b8d-8c0d-4072-8919-608726fa369e",


"master_zone": "83859a9a-9901-4f00-aa6d-285c777e10f0", "period_config": { "bucket_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 }, "user_quota": { "enabled": false, "max_size_kb": -1, "max_objects": -1 } }, "realm_id": "4a367026-bd8f-40ee-b486-8212482ddcd7", "realm_name": "gold", "realm_epoch": 2}

ピリオドのエポックの数字が増加して、設定の変更を示していることに注意してください。


これは、1つ目のゾーンでObject Gatewayを起動する方法と同様です。唯一異なるのは、Object

Gatewayのゾーン設定に us-westというゾーン名を反映させる必要がある点です。

[client.rgw.us-west]rgw_frontends="civetweb port=80"rgw_zone=us-west

2つ目のObject Gatewayを起動します。


11.11.12 フェールオーバーと障害復旧マスタゾーンに障害が発生した場合、障害復旧のためにセカンダリゾーンにフェールオーバーします。

1. セカンダリゾーンをマスタおよびデフォルトのゾーンにします。次に例を示します。

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

デフォルトでは、Ceph Object Gatewayはアクティブ-アクティブ設定で動作します。クラスタが

アクティブ-パッシブ設定で動作するように設定されていた場合、セカンダリゾーンは読み込み専

用ゾーンになっています。--read-only statusを削除して、このゾーンが書き込み操作を受け付け

ることができるようにします。次に例を示します。

161 フェールオーバーと障害復旧 SES 5

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default \--read-only=False

2. ピリオドを更新して変更を有効にします。


3. 最後に、Ceph Object Gatewayを再起動します。

root # systemctl restart ceph-radosgw@rgw.`hostname -s`

前のマスタゾーンが復旧したら、操作を元に戻します。

1. 復旧したゾーンで、現在のマスタゾーンからピリオドを取得します。

root # radosgw-admin period pull --url={url-to-master-zone-gateway} \--access-key={access-key} --secret={secret}

2. 復旧したゾーンをマスタおよびデフォルトのゾーンにします。

root # radosgw-admin zone modify --rgw-zone={zone-name} --master --default



4. その後、復旧したゾーンでCeph Object Gatewayを再起動します。


5. セカンダリゾーンを読み込み専用設定にする必要がある場合、セカンダリゾーンを更新します。

root # radosgw-admin zone modify --rgw-zone={zone-name} --read-only



7. 最後に、セカンダリゾーンでCeph Object Gatewayを再起動します。


162 フェールオーバーと障害復旧 SES 5

11.12 HAProxyによるObject Gatewayサーバの負荷分散HAProxyロードバランサを使用して、すべての要求を複数のObject Gatewayバックエンドサーバに

分散できます。HAProxyの設定の詳細については、https://www.suse.com/documentation/sle-

ha-12/book_sleha/data/sec_ha_lb_haproxy.html を参照してください。

次に、分散アルゴリズムとしてラウンドロビンを使用してObject Gatewayノードを分散するための

HAProxyの単純な設定を示します。

root # cat /etc/haproxy/haproxy.cfg[...]frontend https_frontendbind *:443 crt path-to-cert.pem [ciphers: ... ]default_backend rgw

backend rgwmode httpbalance roundrobinserver rgw_server1 rgw-endpoint1 weight 1 maxconn 100 checkserver rgw_server2 rgw-endpoint2 weight 1 maxconn 100 check[...]

163 HAProxyによるObject Gatewayサーバの負荷分散 SES 5

https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_lb_haproxy.html

https://www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_lb_haproxy.html

12 Ceph iSCSI Gateway

この章では、iSCSI Gatewayに関連する管理タスクに焦点を当てて説明します。展開手順について

は、『導入ガイド』、第10章「iSCSI Gatewayのインストール」を参照してください。

12.1 lrbd管理対象ターゲットへの接続この章では、Linux、Microsoft Windows、またはVMwareが実行されているクライアントからlrbd管

理対象ターゲットに接続する方法について説明します。

12.1.1 Linux (open-iscsi)

lrbdを利用するiSCSIターゲットに open-iscsiで接続するのは、2段階のプロセスです。まず、イニシ

エータがゲートウェイホスト上で利用可能なiSCSIターゲットを検出し、ログインして、利用可能なLU

(論理ユニット)をマップする必要があります。

どちらの手順でも open-iscsiデーモンが実行されている必要があります。 open-iscsiデーモンの

起動方法はLinux配布パッケージによって異なります。

SLES (SUSE Linux Enterprise Server)およびRHEL (Red Hat Enterprise Linux)のホ

ストでは、 systemctl start iscsid (または、 systemctlが利用できない場合は service

iscsid start )を実行します。

DebianおよびUbuntuのホストでは、 systemctl start open-iscsi (または service

open-iscsi start )を実行します。

イニシエータホストでSUSE Linux Enterprise Serverが実行されている場合、iSCSIターゲットへ

の接続方法については、https://www.suse.com/documentation/sles-12/stor_admin/data/

sec_iscsi_initiator.html またはhttps://www.suse.com/documentation/sles11/stor_admin/

data/sec_inst_system_iscsi_initiator.html を参照してください。

open-iscsiをサポートするその他のLinux配布パッケージでは、次に進んで lrbdゲートウェイ上で

ターゲットを検出します(この例では、iscsi1.example.comをポータルアドレスとして使用します。マル

チパスアクセスの場合は、iscsi2.example.comでこれらの手順を繰り返します)。

iscsiadm -m discovery -t sendtargets -p iscsi1.example.com192.168.124.104:3260,1 iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

続いて、ポータルにログインします。ログインが正常に完了した場合、ポータル上でRBDを利用する論

理ユニットは、ただちにシステムSCSIバス上で利用可能になります。

164 lrbd管理対象ターゲットへの接続 SES 5

https://www.suse.com/documentation/sles-12/stor_admin/data/sec_iscsi_initiator.html

https://www.suse.com/documentation/sles-12/stor_admin/data/sec_iscsi_initiator.html

https://www.suse.com/documentation/sles11/stor_admin/data/sec_inst_system_iscsi_initiator.html

https://www.suse.com/documentation/sles11/stor_admin/data/sec_inst_system_iscsi_initiator.html

iscsiadm -m node -p iscsi1.example.com --loginLogging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] (multiple)Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] successful.

他のポータルIPアドレスまたはホストに対して、このプロセスを繰り返します。

システムに lsscsiユーティリティがインストールされている場合は、そのユーティリティを使用して、シ

ステムで利用可能なSCSIデバイスを列挙します。

lsscsi[8:0:0:0] disk SUSE RBD 4.0 /dev/sde[9:0:0:0] disk SUSE RBD 4.0 /dev/sdf

マルチパス設定(接続されている2台のiSCSIデバイスが1台の同一のLUを表す)で

は、 multipathユーティリティでマルチパスデバイスの状態を調べることもできます。

multipath -ll360014050cf9dcfcb2603933ac3298dca dm-9 SUSE,RBDsize=49G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 8:0:0:0 sde 8:64 active ready running`-+- policy='service-time 0' prio=1 status=enabled`- 9:0:0:0 sdf 8:80 active ready running

これで、このマルチパスデバイスをBlock Deviceと同じように使用できます。たとえば、デバイスを

Linux LVM (論理ボリューム管理)の物理ボリュームとして使用したり、単にデバイス上にファイルシス

テムを作成したりできます。次の例は、新しく接続されたマルチパスiSCSIボリューム上にXFSファイル

システムを作成する方法を示しています。

mkfs -t xfs /dev/mapper/360014050cf9dcfcb2603933ac3298dcalog stripe unit (4194304 bytes) is too large (maximum is 256KiB)log stripe unit adjusted to 32KiBmeta-data=/dev/mapper/360014050cf9dcfcb2603933ac3298dca isize=256 agcount=17, agsize=799744 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0data = bsize=4096 blocks=12800000, imaxpct=25 = sunit=1024 swidth=1024 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=0log =internal log bsize=4096 blocks=6256, version=2 = sectsz=512 sunit=8 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0

XFSは非クラスタ化ファイルシステムであるため、特定の時点で1つのiSCSIイニシエータノードにのみ

マウントできます。

165 Linux (open-iscsi) SES 5

特定のターゲットに関連付けられているiSCSI LUの使用を中止したい場合は、次のコマンドを実行し

ます。

iscsiadm -m node -p iscsi1.example.com --logoutLogging out of session [sid: 18, iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260]Logout of [sid: 18, target: iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol, portal: 192.168.124.104,3260] successful.

ディスカバリおよびログインの場合と同様に、ポータルのすべてのIPアドレスまたはホスト名に対してロ

グアウト手順を繰り返す必要があります。

12.1.1.1 マルチパス設定

マルチパス設定はクライアントまたはイニシエータ上で管理され、 lrbd設定とは無関係です。ブロック

ストレージを使用する前にストラテジーを選択します。 /etc/multipath.confを編集した後、次のコマ

ンドを使用して multipathdを再起動します。

sudo systemctl restart multipathd

フレンドリ名を使用するアクティブ-パッシブ設定では、次の記述を設定ファイルに追加します。

defaults { user_friendly_names yes}

追加先のファイルは /etc/multipath.confです。ターゲットに正常に接続したら、次のコマンドを実

行します。

multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-0 SUSE,RBDsize=2.0G features='0' hwhandler='0' wp=rw|-+- policy='service-time 0' prio=1 status=active| `- 2:0:0:3 sdl 8:176 active ready running|-+- policy='service-time 0' prio=1 status=enabled| `- 3:0:0:3 sdj 8:144 active ready running`-+- policy='service-time 0' prio=1 status=enabled `- 4:0:0:3 sdk 8:160 active ready running

各リンクの状態に注意してください。アクティブ-アクティブ設定の場合は、次の記述を設定ファイルに

追加します。

defaults {

166 Linux (open-iscsi) SES 5

user_friendly_names yes}

devices { device { vendor "(LIO-ORG|SUSE)" product "RBD" path_grouping_policy "multibus" path_checker "tur" features "0" hardware_handler "1 alua" prio "alua" failback "immediate" rr_weight "uniform" no_path_retry 12 rr_min_io 100 }}

追加先のファイルは /etc/multipath.confです。 multipathdを再起動して、次のコマンドを実行し

ます。

multipath -llmpathd (36001405dbb561b2b5e439f0aed2f8e1e) dm-3 SUSE,RBDsize=2.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw`-+- policy='service-time 0' prio=50 status=active |- 4:0:0:3 sdj 8:144 active ready running |- 3:0:0:3 sdk 8:160 active ready running `- 2:0:0:3 sdl 8:176 active ready running

12.1.2 Microsoft Windows (Microsoft iSCSIイニシエーター)

Windows 2012サーバからSUSE Enterprise StorageのiSCSIターゲットに接続するには、次の手

順に従います。

1. Windowsサーバーマネージャーを開きます。ダッシュボードから、［ツール］［iSCSI イニシ

エーター］を選択します。［iSCSI イニシエーターのプロパティ］ダイアログが表示されます。［探

索］タブを選択します。

167 Microsoft Windows (Microsoft iSCSIイニシエーター) SES 5

図 12.1: ISCSIイニシエータのプロパティ

2. ［ターゲットポータルの探索］ダイアログで、［ターゲット］フィールドにターゲットのホスト名また

はIPアドレスを入力して、［OK］をクリックします。


図 12.2: ターゲットポータルの探索

3. 他のすべてのゲートウェイホストの名前またはIPアドレスに対して、このプロセスを繰り返します。

完了したら、［ターゲットポータル］リストを確認します。


図 12.3: ターゲットポータル

4. 次に、［ターゲット］タブに切り替えて、検出されたターゲットを確認します。


図 12.4: ターゲット

5. ［ターゲット］タブで［接続］をクリックします。［ターゲットへの接続］ダイアログが表示されます。

［複数パスを有効にする］チェックボックスをオンにしてMPIO (マルチパスI/O)を有効にして、

［OK］をクリックします。

6. ［ターゲットへの接続］ダイアログが閉じたら、［プロパティ］を選択して、ターゲットのプロパティを

確認します。


図 12.5: ISCSIターゲットのプロパティ

7. ［デバイス］を選択し、［MPIO］をクリックしてマルチパスI/Oの設定を確認します。


図 12.6: デバイスの詳細

デフォルトの［負荷分散ポリシー］は［Round Robin With Subset (サブセット付きラウンドロ

ビン)］です。純粋なフェールオーバー設定が必要な場合は、［Fail Over Only (フェールオー

バーのみ)］に変更します。

これでiSCSIイニシエータの設定は終了です。iSCSIボリュームを他のSCSIデバイスと同じように利用

できるようになり、初期化してボリュームやドライブとして使用できます。［OK］をクリックして［iSCSI イ

ニシエーターのプロパティ］ダイアログを閉じて、［サーバーマネージャー］ダッシュボードから［ファイル

サービスと記憶域サービス］の役割に進みます。

新しく接続されたボリュームを確認します。これはiSCSIバス上で「SUSE RBD SCSI Multi-Path

Drive (SUSE RBD SCSIマルチパスデバイス)」として識別されており、初期状態では、状態に「オフラ

イン」、パーティションテーブルタイプに「不明」のマークが付いています。新しいボリュームがすぐに表

示されない場合は、［タスク］ドロップダウンボックスから［記憶域の再スキャン］を選択して、iSCSIバス

を再スキャンします。


1. iSCSIボリュームを右クリックして、コンテキストメニューから［ボリュームの新規作成］を選択し

ます。［新しいボリュームウィザード］が表示されます。［次へ］をクリックして、新しく接続された

iSCSIボリュームを強調表示し、［次へ］をクリックして開始します。

図 12.7: 新しいボリュームウィザード

2. 初期状態では、デバイスは空でパーティションテーブルを含みません。プロンプトが表示された

ら、ボリュームがGPTパーティションテーブルで初期化されることを示すダイアログを確認しま

す。

図 12.8: オフラインディスクのプロンプト

3. ボリュームサイズを選択します。通常は、デバイスの全容量を使用します。続いて、新しく作成さ

れたボリュームを利用できるドライブ文字またはディレクトリ名を割り当てます。次に、新しいボ

リューム上に作成するファイルシステムを選択します。最後に、選択内容を確認して［作成］をク

リックし、ボリュームの作成を完了します。


図 12.9: ボリュームの選択内容の確認

プロセスが完了したら、結果を確認し、［閉じる］をクリックしてドライブの初期化を完了します。初

期化が完了すると、このボリューム(およびそのNTFSファイルシステム)は、新しく初期化された

ローカルドライブと同じように利用可能になります。

12.1.3 VMware

1. lrbd管理対象のiSCSIボリュームに接続するには、設定済みのiSCSIソフトウェアアダプタが必

要です。現在のvSphere設定でこのアダプタが利用できない場合は、［構成］［ストレージア

ダプタ］［追加］［iSCSI Software initiator (iSCSIソフトウェアイニシエータ)］の順に選択

して作成します。

2. アダプタが利用可能になったら、アダプタを右クリックしてコンテキストメニューから［プロパティ］

を選択し、アダプタのプロパティを選択します。

175 VMware SES 5

図 12.10: ISCSIイニシエータのプロパティ

3. ［iSCSI Software Initiator (iSCSIソフトウェアイニシエータ)］ダイアログで、［構成］ボタンを

クリックします。続いて、［動的検出］タブに移動して、［追加］を選択します。

4. lrbd iSCSI GatewayのIPアドレスまたはホスト名を入力します。複数のiSCSI Gatewayを

フェールオーバー設定で実行する場合は、運用するゲートウェイの数だけこの手順を繰り返しま

す。

176 VMware SES 5

図 12.11: ターゲットサーバの追加

すべてのiSCSI Gatewayを入力したら、ダイアログで［OK］をクリックして、iSCSIアダプタの再

スキャンを開始します。

5. 再スキャンが完了すると、新しいiSCSIデバイスが［詳細］ペインの［ストレージアダプタ］リス

トの下に表示されます。マルチパスデバイスの場合は、アダプタを右クリックして、コンテキストメ

ニューから［パスの管理］を選択します。

図 12.12: マルチパスデバイスの管理

177 VMware SES 5

これで、［ステータス］にすべてのパスが緑色のマークで表示されます。パスの1つに［有効 (I/

O)］のマークが付いていて、他のすべてには単に［アクティブ］のマークが付いている必要があり

ます。

図 12.13: マルチパスのパスの一覧

6. ［ストレージアダプタ］から［ステータス］というラベルの項目に切り替えることができます。この

ペインの右上隅にある［ストレージの追加...］を選択して、［Add Storage (ストレージの追加)］ダ

イアログを表示します。続いて、［ディスク/LUN］を選択して、［次へ］をクリックします。新しく追加

されたiSCSIデバイスが［ディスクまたはLUNの選択］リストに表示されます。デバイスを選択し、

［次へ］をクリックして続行します。

178 VMware SES 5

図 12.14: ストレージの追加ダイアログ

［次へ］をクリックして、デフォルトのディスクレイアウトをそのまま使用します。

7. ［プロパティ］ペインで、新しいデータストアに名前を割り当てて、［次へ］をクリックします。ボ

リュームの全領域をこのデータストアに使用する場合はデフォルト設定をそのまま使用し、データ

ストアの領域を減らす場合は［カスタム領域設定］を選択します。

図 12.15: カスタム領域設定

179 VMware SES 5

［終了］をクリックしてデータストアの作成を完了します。

新しいデータストアがデータストアのリストに表示され、そのデータストアを選択して詳細を取得

できます。これで、vSphereの他のデータストアと同じように、 lrbdを利用するiSCSIボリューム

を使用できるようになります。

図 12.16: ISCSIデータストアの概要

12.2 結論lrbdはSUSE Enterprise Storageにおいて鍵となるコンポーネントで、iSCSIプロトコルに対応した

任意のサーバやクライアントから分散型の高可用性ブロックストレージへのアクセスを可能にします。1

つ以上のiSCSI Gatewayホストで lrbdを使用することにより、Ceph RBDイメージはiSCSIターゲッ

トに関連付けられたLU (論理ユニット)として利用可能になります。オプションで、負荷分散された可用

性が高い方法でアクセスすることもできます。

lrbdのすべての設定はCeph RADOS Object Storeに保存されるので、 lrbdゲートウェイホス

トは本質的に永続状態を持ちません。したがって、自由に置換、増強、または縮小できます。その結

果、SUSE Enterprise Storageにより、SUSEのお客様は、コモディティハードウェアと完全なオープン

ソースプラットフォーム上で、真に分散化され、高い可用性、災害耐性、自己修復機能を併せ持つエン

タープライズストレージ技術を運用できます。

180 結論 SES 5

13 クラスタ化ファイルシステム

この章では、通常はクラスタの設定とCephFSのエクスポート後に実行する管理タスクについて説明し

ます。CephFSの設定の詳細については、『導入ガイド』、第11章「CephFSのインストール」を参照して

ください。

13.1 CephFSのマウントファイルシステムが作成されてMDSがアクティブになったら、クライアントホストからファイルシステムを

マウントできます。

13.1.1 クライアントの準備

クライアントホストがSUSE Linux Enterprise 12 SP2またはSP3を実行している場合、システムは

CephFSを「設定なしで」すぐにマウントできるため、このセクションはスキップして構いません。

クライアントホストがSUSE Linux Enterprise 12 SP1を実行している場合は、CephFSをマウントす

る前にすべての最新パッチを適用する必要があります。

いずれの場合も、CephFSをマウントするのに必要なものはすべてSUSE Linux Enterpriseに付属し

ています。SUSE Enterprise Storage製品は必要ありません。

完全な mount構文をサポートするには、CephFSのマウントを試みる前に、 ceph-common パッケージ

(SUSE Linux Enterpriseに付属)をインストールする必要があります。

13.1.2 シークレットファイル

Cephクラスタは、デフォルトで認証がオンの状態で動作します。秘密鍵(キーリングそのものではない)

を保存するファイルを作成する必要があります。特定のユーザの秘密鍵を入手してファイルを作成する

には、次の操作を行います。

手順 13.1: 秘密鍵の作成

1. キーリングファイル内の特定のユーザの鍵を表示します。

cat /etc/ceph/ceph.client.admin.keyring

2. マウントしたCephFS (Ceph File System)を使用するユーザの鍵をコピーします。通常、鍵は次

のような形式です。

181 CephFSのマウント SES 5

AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==

3. ファイル名の部分にユーザ名を使用してファイルを作成します。たとえば、ユーザadminの場合

は、 /etc/ceph/admin.secretのようになります。

4. 前の手順で作成したファイルに鍵の値を貼り付けます。

5. ファイルに適切なアクセス権を設定します。このユーザは、ファイルを読み込める唯一のユーザで

ある必要があります。ほかのユーザは一切アクセス権を持つことはできません。

13.1.3 CephFSのマウント

mountコマンドでCephFSをマウントできます。Monitorのホスト名またはIPアドレスを指定する必要が

あります。SUSE Enterprise Storageでは cephx認証がデフォルトで有効になっているため、ユーザ

名とその関連シークレットも指定する必要があります。

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

以前のコマンドはシェルの履歴に残るため、ファイルからシークレットを読み込むアプローチの方が安全

です。

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

シークレットファイルには実際のキーリングシークレットだけが含まれる必要があることに注意してくださ

い。この例では、ファイルに含まれるのは次の行だけです。

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

ヒント: 複数のMonitorの指定マウント時に特定のMonitorがダウンしている事態に備え、 mountコマンドラインで複

数のMonitorをコンマで区切って指定することをお勧めします。各Monitorのアドレス

は host[:port]という形式です。ポートを指定しない場合は、デフォルトで6789が使用されま

す。

ローカルホストでマウントポイントを作成します。

sudo mkdir /mnt/cephfs

CephFSをマウントします。

182 CephFSのマウント SES 5

sudo mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

ファイルシステムのサブセットをマウントする場合は、サブディレクトリ subdirを指定できます。

sudo mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

mountコマンドで複数のMonitorホストを指定できます。

sudo mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \ -o name=admin,secretfile=/etc/ceph/admin.secret

重要: ルートディレクトリに対する読み込みアクセスパス制約付きのクライアントを使用する場合は、MDSのケーパビリティにルートディレクトリに対

する読み込みアクセスを含める必要があります。たとえば、キーリングは次のようになります。

client.bar key: supersecretkey caps: [mds] allow rw path=/barjail, allow r path=/ caps: [mon] allow r caps: [osd] allow rwx

allow r path=/の部分は、パス制約付きのクライアントは、ルートボリュームを表示できても

書き込みはできないことを意味します。これは、完全な分離が要件である使用事例で問題にな

ることがあります。

13.2 CephFSのアンマウントCephFSをアンマウントするには、 umountコマンドを使用します。

sudo umount /mnt/cephfs

13.3 /etc/fstabでのCephFSの指定クライアントの起動時にCephFSを自動的にマウントするには、対応する行をファイルシステムテーブ

ル /etc/fstabに挿入します。

mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2

183 CephFSのアンマウント SES 5

13.4 複数のアクティブMDSデーモン(アクティブ-アクティブMDS)CephFSは、デフォルトでは単一のアクティブMDSデーモン用に設定されています。大規模システム用

にメタデータのパフォーマンスを拡張する場合、複数のアクティブMDSデーモンを有効にできます。こ

れにより、各デーモンがお互いにメタデータワークロードを共有します。

13.4.1 アクティブ-アクティブMDSを使用する状況デフォルトの単一のMDSではメタデータのパフォーマンスがボトルネックになる場合、複数のアクティ

ブMDSデーモンの使用を検討します。

デーモンを追加しても、すべてのワークロードタイプのパフォーマンスが向上するわけではありません。

たとえば、単一のクライアント上で動作している単一のアプリケーションの場合、そのアプリケーション

が大量のメタデータ操作を並列で実行していない限り、MDSデーモンの数を増やしてもメリットはあり

ません。

一般的に大量のアクティブMDSデーモンのメリットを受けられるワークロードは、クライアントが複数あ

り、多数の別個のディレクトリを操作する可能性が高いワークロードです。

13.4.2 MDSのアクティブクラスタサイズの増加各CephFSファイルシステムには、作成するランクの数を制御する max_mds設定があります。ファイル

システム内の実際のランク数は、新しいランクを引き受けるスペアデーモンが利用可能な場合にのみ

増やされます。たとえば、実行中のMDSデーモンが1つだけで、 max_mdsが2に設定されている場合、2

番目のランクは作成されません。

次の例では、 max_mdsオプションを2に設定して、デフォルトのランクとは別の新しいランクを作成しま

す。変更を確認するには、 max_mdsの設定前と設定後に ceph statusを実行し、 fsmapが含まれる

行を確認します。

root@master # ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]root@master # ceph mds set max_mds 2root@master # ceph status [...] services: [...]

184 複数のアクティブMDSデーモン(アクティブ-アクティブMDS) SES 5

mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]

新しく作成されたランク(1)は、「creating (作成中)」状態を経由して「active (アクティブ)」状態になり

ます。

重要: スタンバイデーモン複数のアクティブMDSデーモンを使用していても、高可用性システムには、アクティブデーモン

を実行するサーバに障害が発生した場合に処理を引き継ぐスタンバイデーモンも必要です。

そのため、高可用性システムの max_mdsの実用的な最大数は、システムのMDSサーバの合計

数から1を引いた数になります。複数のサーバ障害時に可用性を維持するには、切り抜ける必要

があるサーバ障害の数に一致するようにシステムのスタンバイデーモンの数を増やします。

13.4.3 ランク数の減少

最初に、すべてのランク(削除するランクを含む)がアクティブになっている必要があります。つまり、少な

くとも max_mds MDSデーモンが利用可能である必要があります。

最初に、 max_mdsをより低い数字に設定します。たとえば、単一のアクティブMDSに戻します。

root@master # ceph status [...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]root@master # ceph mds set max_mds 1root@master # ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]

これでもまだアクティブMDSが2つあることに注意してください。 max_mdsが制限するのは新しいラン

クの作成だけなので、 max_mdsを減らしても、これらのランクはまだ存在しています。

次に、 ceph mds deactivate rankコマンドを使用して、不要なランクを削除します。

root@master # ceph status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:active}

185 ランク数の減少 SES 5

root@master # ceph mds deactivate 1telling mds.1:1 192.168.58.101:6805/2799214375 to deactivate

root@master # ceph status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:stopping}

root@master # ceph status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby

無効にしたランクは、共有しているメタデータを残りのアクティブデーモンに引き渡す間、まず一定時間

「stopping (停止中)」状態になります。このフェーズには数秒から数分かかる可能性があります。MDS

が「stopping (停止中)」状態で止まっているように見える場合は、バグの可能性があるので調査が必

要です。

「stopping (停止中)」状態の間にMDSデーモンがクラッシュまたは終了した場合、スタンバイが処理

を引き継ぎ、ランクが「active (アクティブ)」に戻ります。デーモンが復帰したら、もう一度無効にしてみる

ことができます。

停止を完了すると、デーモンはもう一度起動してスタンバイに戻ります。

13.4.4 ランクへのディレクトリツリーの手動固定

複数のアクティブMetadata Server設定では、バランサが動作し、メタデータの負荷をクラスタに均等

に分散します。これは通常、ほとんどのユーザにとって十分有効に機能しますが、メタデータを特定のラ

ンクに明示的にマッピングして動的バランサを無効にした方が良い場合もあります。これにより、管理者

やユーザは、アプリケーションの負荷を均等に分散したり、ユーザのメタデータ要求によるクラスタ全体

への影響を抑えたりできます。

このために提供されているメカニズムを「エクスポートピン」と呼びます。これはディレクトリの拡張属性

です。この拡張属性の名前は ceph.dir.pinです。標準のコマンドを使用して、この属性を設定できま

す。

setfattr -n ceph.dir.pin -v 2 /path/to/dir

拡張属性の値( -v )は、ディレクトリサブツリーの割り当て先となるランクです。デフォルト値-1は、ディレ

クトリが固定されないことを示します。

ディレクトリのエクスポートピンは、設定されているエクスポートピンを持つ最も近い親から継承されま

す。したがって、ディレクトリにエクスポートピンを設定すると、そのすべての子に影響します。ただし、子

ディレクトリのエクスポートピンを設定して親のピンを上書きできます。次に例を示します。

186 ランクへのディレクトリツリーの手動固定 SES 5

mkdir -p a/b # "a" and "a/b" start with no export pin set.setfattr -n ceph.dir.pin -v 1 a/ # "a" and "b" are now pinned to rank 1.setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0 # and "a/" and the rest of its children # are still pinned to rank 1.

13.5 フェールオーバーの管理MDSデーモンがMonitorとの通信を停止した場合、そのMonitorは mds_beacon_graceの秒数(デ

フォルトは15秒)待機してから、デーモンを「遅延」としてマークします。MDSデーモンのフェールオー

バー中に処理を引き継ぐ「スタンバイ」デーモンを1つ以上設定できます。

13.5.1 スタンバイデーモンの設定

スタンバイ中のデーモンの動作を制御する設定は複数あります。これらの設定は、MDSデーモン

が実行されるホストの ceph.confで指定できます。デーモンは起動時にこれらの設定をロードして

Monitorに送信します。

どの設定も使用されていない場合、デフォルトで、ランクを保有していないすべてのMDSデーモンがす

べてのランクに対して「スタンバイ」として使用されます。

スタンバイデーモンを特定の名前またはランクに関連付ける設定は、デーモンがそのランクにのみ使用

されることを保証するものでありません。複数のスタンバイが利用可能な場合、関連付けられたスタン

バイデーモンが使用されることを意味します。ランクが失敗した場合、利用可能なスタンバイがあれば、

別のランクや特定のデーモンに関連付けられていても、そのスタンバイが使用されます。

mds_standby_replay

trueに設定すると、スタンバイデーモンは継続的に上のランクのメタデータジャーナルを読み込

みます。これによってウォームメタデータキャッシュが作成され、そのランクにサービスを提供する

デーモンに障害が発生した場合のフェールオーバー処理が高速化されます。

上のランクには、スタンバイ再生デーモンを1つだけ割り当てることができます。2つのデーモンが

両方ともスタンバイ再生に割り当てられている場合、その一方が任意に勝利し、もう一方は通常

の非再生スタンバイになります。

スタンバイ再生状態になったデーモンは、そのデーモンが追跡しているランクのスタンバイとして

のみ使用されます。別のランクが失敗し、利用可能な他のスタンバイがない場合であっても、この

スタンバイ再生デーモンは代わりとして使用されません。

mds_standby_for_name

障害が発生したランクを保有する最後のデーモンがこの名前に一致した場合、スタンバイデーモ

ンがこのランクのみを引き継ぐようにする場合に設定します。

187 フェールオーバーの管理 SES 5

mds_standby_for_rank

スタンバイデーモンが指定ランクのみを引き継ぐようにする場合に設定します。別のランクに障害

が発生した場合、このデーモンはランクを置き換えるために使用されません。

複数のファイルシステムが存在する環境で、対象にするファイルシステムのランクを具体的に指

定する場合は、 mds_standby_for_fscidと組み合わせて使用します。

mds_standby_for_fscid

mds_standby_for_rankが設定されている場合、これは単に、参照されるファイルシステムのラ

ンクを示す修飾子です。

mds_standby_for_rankが設定されていない場合、FSCIDを設定すると、このデーモンは指定

されたFSCIDのすべてのランクを対象にします。特定のファイルシステム内だけですべてのラン

クに対して使用したいデーモンがある場合に使用します。

mon_force_standby_active

Monitorホストで使用します。デフォルトはtrueです。

falseの場合、 standby_replay=trueが設定されたデーモンは、追跡対象として設定されてい

るランク/名前に障害が発生した場合にのみアクティブになります。一方、この設定がtrueの場

合、 standby_replay=trueが設定されたデーモンは他のランクに割り当てられることがありま

す。

13.5.2 例

次に、 ceph.confの設定例をいくつか示します。すべてのデーモンの設定が含まれる ceph.confをす

べてのサーバにコピーすることも、特定のサーバのデーモン設定が含まれるサーバ別のファイルを使用

することもできます。

13.5.2.1 単純なペア

2つのMDSデーモン「a」と「b」がペアとして機能しています。現在ランクが割り当てられていない方が、

もう一方のスタンバイ再生のフォロワになります。

[mds.a]mds standby replay = truemds standby for rank = 0

[mds.b]mds standby replay = truemds standby for rank = 0

188 例 SES 5

14 NFS Ganesha: NFS経由でのCephデータのエクスポート

NFS Ganeshaは、オペレーティングシステムカーネルの一部としてではなく、ユーザアドレススペー

スで動作するNFSサーバです(「Sharing File Systems with NFS (https://www.suse.com/

documentation/sles-12/book_sle_admin/data/cha_nfs.html) 」を参照してください)。NFS

Ganeshaを使用することで、Cephなど独自のストレージメカニズムをプラグインして、任意のNFSクラ

イアントからアクセスできます。

S3バケットはユーザごとにNFSにエクスポートされます。たとえば、パ

ス GANESHA_NODE:/USERNAME/BUCKETNAMEを使用してエクスポートされます。

CephFSは、デフォルトではパス GANESHA_NODE:/cephfsを介してエクスポートされます。

14.1 インストール詳細については、『導入ガイド』、第12章「NFS Ganeshaのインストール」を参照してください。

14.2 設定設定ファイルで利用可能なすべてのパラメータのリストについては、次のマニュアルページを参照してく

ださい。

man ganesha-config

man ganesha-ceph-config (CephFS FSAL (File System Abstraction Layer)のオプ

ション)

man ganesha-rgw-config (Object GatewayのFSALのオプション)

このセクションには、Object GatewayとCephFSを介してアクセス可能なクラスタデータをエクスポー

トするようNFS Ganeshaサーバを設定する際に役立つ情報が記載されています。

NFS Ganeshaの設定は /etc/ganesha/ganesha.confで制御します。DeepSeaステージ4を実

行すると、このファイルへの変更が上書きされることに注意してください。設定を永続的に変更するに

は、Salt Master上にあるファイル /srv/salt/ceph/ganesha/files/ganesha.conf.j2を編集し

ます。

189 インストール SES 5

https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_nfs.html

https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_nfs.html

14.2.1 Exportセクション

このセクションでは、 ganesha.confの EXPORTの各セクションを設定する方法について説明します。

EXPORT{ Export_Id = 1; Path = "/"; Pseudo = "/"; Access_Type = RW; Squash = No_Root_Squash; [...] FSAL { Name = CEPH; }}

14.2.1.1 Exportの主要セクション

Export_Id

各エクスポートには固有の「Export_Id」が必要です(必須)。

Path

関連するCephFSプール内のエクスポートパス(必須)。これにより、CephFSからサブディレクトリ

をエクスポートできます。

Pseudo

ターゲットNFSのエクスポートパス(NFSv4では必須)。エクスポートデータを利用可能なNFSの

エクスポートパスを定義します。

例: 値 /cephfs/を使用して、次のコマンドを実行したとします。

root # mount GANESHA_IP:/cephfs/ /mnt/

これにより、CephFSのデータがクライアントのディレクトリ /mnt/cephfs/で利用可能になりま

す。

Access_Type

読み込み専用の場合は「RO」、デフォルトは「None」です。

Squash

NFSのsquash (ルート権限無効化)オプション。

FSAL

190 Exportセクション SES 5

「File System Abstraction Layer」をエクスポートします。詳細については、14.2.1.2項「FSAL

サブセクション」を参照してください。

14.2.1.2 FSALサブセクション

EXPORT{ [...] FSAL { Name = CEPH; }}

Name

NFS Ganeshaが使用するバックエンドを定義します。使用できる値は、CephFSの場合

は CEPH 、Object Gatewayの場合は RGWです。選択した値に応じて、 policy.cfgで role-

mdsまたは role-rgwを定義する必要があります。

14.2.2 RGWセクション

RGW { ceph_conf = "/etc/ceph/ceph.conf"; name = "name"; cluster = "ceph";}

ceph_conf

ceph.confファイルを指します。DeepSeaを使用して展開する場合は、この値を変更する必要

はありません。

name

NFS Ganeshaによって使用されるCephクライアントユーザの名前。

cluster

Cephクラスタの名前。SUSE Enterprise Storage 5で現在サポートされているクラスタ名は1

つだけです(デフォルトは ceph )。

191 RGWセクション SES 5

14.2.3 NFS Ganeshaのデフォルトポートの変更

NFS Ganeshaは、NFSにポート2049、rquotaサポートに875をデフォルトで使用します。デフォルト

のポート番号を変更するには、 NFS_CORE_PARAMセクション内で NFS_Portおよび RQUOTA_Portのオ

プションを使用します。次に例を示します。

NFS_CORE_PARAM{ NFS_Port = 2060; RQUOTA_Port = 876;}

14.3 NFS Ganeshaのカスタムの役割クラスタノード用にNFS Ganeshaのカスタムの役割を定義できます。その後、これらの役割

を policy.cfgでノードに割り当てます。これらの役割により、以下が可能になります。

Object GatewayとCephFSにアクセスするために別々のNFS Ganeshaノードを使用する。

複数のNFS Ganeshaノードに異なるObject Gatewayユーザを割り当てる。

複数のObject Gatewayユーザを使用することで、複数のNFS Ganeshaノードから異なるS3バケット

にアクセスできます。S3バケットをアクセス制御に使用できます。注: S3バケットを、CRUSHマップで使

用されるCephのバケットと混同しないでください。

14.3.1 NFS Ganesha用の異なるObject Gatewayユーザ

次に示すSalt Master用の手順の例では、異なるObject Gatewayユーザを持つ2つのNFS

Ganeshaの役割を作成する方法について説明します。この例では、役割 goldと silverを使用しま

す。これらの役割には、DeepSeaによってサンプル設定ファイルがすでに用意されています。

1. ファイル /srv/pillar/ceph/stack/global.ymlを好みのエディタで開きます。ファイルが存

在しない場合は作成します。

2. このファイルには次の行が含まれる必要があります。

rgw_configurations: - rgw - silver - goldganesha_configurations:

192 NFS Ganeshaのデフォルトポートの変更 SES 5

- silver - gold

後で、これらの役割を policy.cfgで割り当てることができます。

3. ファイル /srv/salt/ceph/rgw/users/users.d/gold.ymlを作成して、次の内容を追加しま

す。

- { uid: "gold1", name: "gold1", email: "[email protected]" }

ファイル /srv/salt/ceph/rgw/users/users.d/silver.ymlを作成して、次の内容を追加し

ます。

- { uid: "silver1", name: "silver1", email: "[email protected]" }

4. ここで、各役割に対して ganesha.confのテンプレートを作成する必要があります。DeepSeaの

元のテンプレートを利用するのが便利です。コピーを2つ作成します。

root # cd /srv/salt/ceph/ganesha/files/root # cp ganesha.conf.j2 silver.conf.j2root # cp ganesha.conf.j2 gold.conf.j2

5. 新しい役割には、クラスタにアクセスするためのキーリングが必要です。アクセスを提供するた

め、 ganesha.j2をコピーします。

root # cp ganesha.j2 silver.j2root # cp ganesha.j2 gold.j2

6. Object Gatewayのキーリングをコピーします。

root # cd /srv/salt/ceph/rgw/files/root # cp rgw.j2 silver.j2root # cp rgw.j2 gold.j2

7. Object Gatewayに、異なる役割用の設定も必要です。

root # cd /srv/salt/ceph/configuration/files/root # cp ceph.conf.rgw silver.confroot # cp ceph.conf.rgw gold.conf

8. /srv/pillar/ceph/proposals/policy.cfgで、新しく作成した役割をクラスタノードに割り

当てます。

role-silver/cluster/NODE1.slsrole-gold/cluster/NODE2.sls

193 NFS Ganesha用の異なるObject Gatewayユーザ SES 5

NODE1および NODE2は、役割の割り当て先にするノードの名前に置き換えてください。


14.3.2 CephFSとObject GatewayのFSALの分離

次に示すSalt Master用の手順の例では、CephFSとObject Gatewayを使用する2つの異なる役割

を新しく作成する方法について説明します。

1. ファイル /srv/pillar/ceph/rgw.slsを好みのエディタで開きます。ファイルが存在しない場

合は作成します。

2. このファイルには次の行が含まれる必要があります。

rgw_configurations: ganesha_cfs: users: - { uid: "demo", name: "Demo", email: "[email protected]" } ganesha_rgw: users: - { uid: "demo", name: "Demo", email: "[email protected]" }

ganesha_configurations: - ganesha_cfs - ganesha_rgw

後で、これらの役割を policy.cfgで割り当てることができます。

3. ここで、各役割に対して ganesha.confのテンプレートを作成する必要があります。DeepSeaの

元のテンプレートを利用するのが便利です。コピーを2つ作成します。

root # cd /srv/salt/ceph/ganesha/files/root # cp ganesha.conf.j2 ganesha_rgw.conf.j2root # cp ganesha.conf.j2 ganesha_cfs.conf.j2

4. ganesha_rgw.conf.j2を編集して次のセクションを削除します。

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles='mds') != [] %} [...]{% endif %}

5. ganesha_cfs.conf.j2を編集して次のセクションを削除します。

{% if salt.saltutil.runner('select.minions', cluster='ceph', roles=role) != [] %} [...]

194 CephFSとObject GatewayのFSALの分離 SES 5

{% endif %}

6. 新しい役割には、クラスタにアクセスするためのキーリングが必要です。アクセスを提供するた

め、 ganesha.j2をコピーします。

root # cp ganesha.j2 ganesha_rgw.j2root # cp ganesha.j2 ganesha_cfs.j2

行 caps mds = "allow *"は ganesha_rgw.j2から削除できます。

7. Object Gatewayのキーリングをコピーします。

root # cp /srv/salt/ceph/rgw/files/rgw.j2 \/srv/salt/ceph/rgw/files/ganesha_rgw.j2

8. Object Gatewayに、新しい役割用の設定が必要です。

root # cp /srv/salt/ceph/configuration/files/ceph.conf.rgw \/srv/salt/ceph/configuration/files/ceph.conf.ganesha_rgw

9. /srv/pillar/ceph/proposals/policy.cfgで、新しく作成した役割をクラスタノードに割り

当てます。

role-ganesha_rgw/cluster/NODE1.slsrole-ganesha_cfs/cluster/NODE1.sls

NODE1および NODE2は、役割の割り当て先にするノードの名前に置き換えてください。


14.4 NFS Ganeshaの起動または再起動NFS Ganeshaサービスを有効にして起動するには、次のコマンドを実行します。

root # systemctl enable nfs-ganesharoot # systemctl start nfs-ganesha

次のコマンドを使用して、NFS Ganeshaを再起動します。

root # systemctl restart nfs-ganesha

NFS Ganeshaが起動または再起動した時点では、NFS v4に90秒の猶予タイムアウトが設定されて

います。猶予期間中、クライアントからの新しい要求はアクティブに拒否されます。したがって、NFSが

猶予状態の場合、クライアントで要求の低速化が発生することがあります。

195 NFS Ganeshaの起動または再起動 SES 5

14.5 ログレベルの設定デフォルトのデバッグレベル NIV_EVENTを変更するには、ファイル /etc/sysconfig/nfs-

ganeshaを編集します。 NIV_EVENTを NIV_DEBUGまたは NIV_FULL_DEBUGに置き換えます。ログの

詳細度を上げると、ログファイル内に大量のデータが生成される可能性があります。

OPTIONS="-L /var/log/ganesha/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT"

ログレベルを変更した場合、サービスの再起動が必要です。

14.6 エクスポートされたNFS共有の検証NFS v3を使用する場合、NFS共有がNFS Ganeshaサーバノード上にエクスポートされているかどう

かを検証できます。

root # showmount -e/ (everything)

14.7 エクスポートされたNFS共有のマウントエクスポートされたNFS共有(14.2項「設定」で設定)をクライアントホストにマウントするには、次のコ

マンドを実行します。

root # mount -t nfs -o rw,noatime,sync \ nfs_ganesha_server_hostname:/ /path/to/local/mountpoint

14.8 その他の資料NFS Ganeshaの元のドキュメントは、https://github.com/nfs-ganesha/nfs-ganesha/wiki/

Docs に掲載されています。

196 ログレベルの設定 SES 5

https://github.com/nfs-ganesha/nfs-ganesha/wiki/Docs

https://github.com/nfs-ganesha/nfs-ganesha/wiki/Docs

IV GUIツールを使用したクラスタの管理

15 openATTIC 198

15 openATTIC

ヒント: Calamariは削除Calamariはこれまで、Cephクラスタを管理および監視するための推奨Web UIアプリケー

ションでした。SUSE Enterprise Storage 5から、Calamariは削除され、代わってより高度な

openATTICが推奨されるようになりました。

openATTICは、Ceph Storage Clusterをサポートする中央ストレージ管理システムで

す。openATTICにより、中央管理インタフェースからあらゆる機能を制御できます。Cephストレージ

ツールの内部動作を熟知する必要はなくなりました。openATTICの直感的なWebインタフェースを使

用するか、そのREST APIを経由することによってクラスタ管理タスクを実行できます。

15.1 openATTICの展開と設定このセクションでは、openATTICとそのサポート機能を展開して設定し、ユーザフレンドリなWebインタ

フェースを使用してCephクラスタを管理できるようにする手順を説明します。

15.1.1 SSLを使用したopenATTICへの安全なアクセスの有効化

デフォルトでは、openATTIC Webアプリケーションへのアクセスには、安全ではないHTTPプロトコル

が使用されます。openATTICに安全にアクセスできるようにするには、Apache Webサーバを手動で

設定する必要があります。

1. 既知のCA (認証局)によって署名されたSSL証明書がない場合は、自己署名SSL証明書を作成

して、そのファイルをWebサーバで要求されるディレクトリにコピーします。次に例を示します。

root # openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 \ -keyout key.pem -out cert.pemroot # cp cert.pem /etc/ssl/certs/servercert.pemroot # cp key.pem /etc/ssl/certs/serverkey.pem

SSL証明書の作成の詳細については、https://www.suse.com/documentation/sles-12/

book_sle_admin/data/sec_apache2_ssl.html を参照してください。

2. /etc/sysconfig/apache2設定ファイルの APACHE_SERVER_FLAGSオプションに「SSL」を追

加します。手動で追加することも、次のコマンドを実行して追加することもできます。

root # a2enmod ssl

198 openATTICの展開と設定 SES 5

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_apache2_ssl.html

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_apache2_ssl.html

root # a2enflag SSL

3. 次の内容で、新しいApache仮想ホストの /etc/apache2/vhosts.d/vhost-ssl.confを作

成します。

<IfDefine SSL><IfDefine !NOSSL><VirtualHost *:80> ServerName OA_HOST_NAME Redirect "/" "https://OA_HOST_NAME/"</VirtualHost><VirtualHost _default_:443> ServerName OA_HOST_NAME DocumentRoot "/srv/www/htdocs" ErrorLog /var/log/apache2/error_log TransferLog /var/log/apache2/access_log SSLEngine on SSLCertificateFile /etc/ssl/certs/servercert.pem SSLCertificateKeyFile /etc/ssl/certs/serverkey.pem CustomLog /var/log/apache2/ssl_request_log ssl_combined</VirtualHost></IfDefine></IfDefine>

4. Webサーバを再起動して、新しい仮想ホスト定義を証明書ファイルと共に再ロードします。

root # systemctl restart apache2.service

15.1.2 openATTICの展開SUSE Enterprise Storage 5から、openATTICはDeepSeaの役割として展開されます。全般的な

手順については、第1章「Saltクラスタの管理」を参照してください。

15.1.3 openATTICの初期セットアップデフォルトでは、 oaconfigは管理者ユーザアカウント openatticを作成します。パスワードはユーザ

名と同じです。セキュリティの予防措置として、このパスワードをすぐに変更することを強くお勧めしま

す。

root@minion > oaconfig changepassword openatticChanging password for user 'openattic'Password: <enter password>Password (again): <re-enter password>Password changed successfully for user 'openattic'

199 openATTICの展開 SES 5

15.1.4 openATTICでのDeepSea統合iSCSI GatewayやObject Gateway管理など、openATTICの一部の機能はDeepSea REST API

を利用します。これはデフォルトで有効化および設定されています。デバッグのためにデフォルト設定を

上書きする必要がある場合は、 /etc/sysconfig/openatticを編集して次の行を追加または変更し

ます。

SALT_API_HOST="salt_api_host"SALT_API_PORT=8001SALT_API_USERNAME="example_user"SALT_API_PASSWORD="password"

重要: oaconfig restart/etc/sysconfig/openatticファイルを変更した後は、必ず oaconfig restartを実行して

ください。

重要: ファイルの構文PythonおよびBashでは、 /etc/sysconfig/openatticが使用されます。したがって、ファイ

ルはBashが理解できるフォーマットでなければならず、「等号」記号の前後にスペースを入れる

ことはできません。

15.1.5 Object Gateway管理openATTICのObject Gateway管理機能は、デフォルトで有効になっています。DeepSeaから検

出されたObject Gateway APIのデフォルト値を上書きする必要がある場合は、 /etc/sysconfig/

openatticに次のオプションと関連する値を含めます。次に例を示します。

RGW_API_HOST="rgw_api_host"RGW_API_PORT=80RGW_API_SCHEME="http"RGW_API_ACCESS_KEY="VFEG733GBY0DJCIV6NK0"RGW_API_SECRET_KEY="lJzPbZYZTv8FzmJS5eiiZPHxlT2LMGOMW8ZAeOAq"

注記: Object GatewayのデフォルトのリソースObject Gatewayの管理リソースが、「http://rgw_host:80/admin」で使用されるデフォルト

値「admin」を使用するよう設定されていない場合は、 RGW_API_ADMIN_RESOURCEオプション

を適切に設定する必要もあります。

200 openATTICでのDeepSea統合 SES 5

Object Gatewayの資格情報を入手するには、 radosgw-adminコマンドを使用します。

root@minion > radosgw-admin user info --uid=admin

15.1.6 iSCSI Gateway管理

iSCSI Gateway管理機能は、デフォルトで有効になっています。Salt APIのデフォルトのホス

ト名を上書きする必要がある場合、15.1.4項「openATTICでのDeepSea統合」の説明に従っ

て SALT_API_HOSTの値を変更します。

15.2 openATTIC WebユーザインタフェースopenATTICはWebユーザインタフェースを使用して管理できます。Webブラウザを開い

て、http:// SERVER_HOST /openatticに移動します。ログインするには、デフォルトのユーザ

名openatticと、対応するパスワードを使用します。

図 15.1: OPENATTICのログイン画面

openATTICのユーザインタフェースは、グラフィックによって上部のメニューペインとコンテンツペイン

に分かれています。

201 iSCSI Gateway管理 SES 5

上部ペインの右側部分には、現在のユーザ設定へのリンク、［Logout (ログアウト)］リンク、既存のバッ

クグラウンドタスクのリストへのリンクを示す［Background tasks (バックグラウンドタスク)］、およびシ

ステム通知を示す［Notifications (通知)］があります。上部ペインの残りの部分には、openATTICの

メインメニューがあります。

コンテンツペインは、どの項目のメニューを有効にしたかによって変わります。デフォルトでは、

［Dashboard (ダッシュボード)］が表示され、クラスタの状態を通知するさまざまなウィジェットが表示

されます。

図 15.2: OPENATTICダッシュボード

15.3 ダッシュボード［Dashboard (ダッシュボード)］ウィジェットには、実行中のCephクラスタに関連する具体的な状態情

報が表示されます。ウィジェットのタイトルをクリックすると、ウィジェットがコンテンツペイン全体に拡大

され、場合によっては詳細が表示されます。次に、さまざまなウィジェットのリストを示します。

［Status (状態)］ウィジェットは、クラスタが正常に動作しているかどうかを通知します。問題が検出さ

れた場合は、ウィジェット内のサブタイトルをクリックすると、詳しいエラーメッセージを参照できます。

［Monitors in Quorum (定数のMonitor)］、［Pools (プール)］、［OSDs In (参加中のOSD)］、

［OSDs Out (除外中のOSD)］、［OSDs Up (稼働中のOSD)］、［OSDs Down (ダウン中のOSD)］、

および［Average PGs per OSD (OSDあたりの平均PG数)］の各ウィジェットには、単に関連する数

値が表示されます。

202 ダッシュボード SES 5

図 15.3: 基本ウィジェット

ストレージの合計容量と利用可能な容量を扱うウィジェットは、［Cluster Capacity (クラスタの容

量)］、［Available Capacity (利用可能な容量)］、［Used Capacity (使用済み容量)］、および

［Capacity (容量)］です。

図 15.4: 容量のウィジェット

OSDとMonitorノードのレイテンシを扱うウィジェットは、［Average OSD Apply Latency (OSDの

平均適用レイテンシ)］、［Average OSD Commit Latency (OSDの平均コミットレイテンシ)］、および

［Average Monitor Latency (Monitorの平均レイテンシ)］です。

図 15.5: レイテンシのウィジェット

［Throughput (スループット)］ウィジェットには、1秒あたりの読み込みと書き込みの統計が適切なタ

イミングで表示されます。

203 ダッシュボード SES 5

図 15.6: スループット

ヒント: マウスポインタを合わせて詳細を表示表示されているチャートにマウスポインタを合わせると、ポイントした時点の日時に関連する詳

細がポップアップウィンドウに表示されます。

チャート領域をクリックし、時間軸に沿ってマウスポインタを左右にドラッグすると、軸の時間間隔

が、マウスを移動してマークを付けた間隔へズームインします。ズームアウトして元の倍率に戻す

には、チャートをダブルクリックします。

15.4 Ceph関連タスクopenATTICのメインメニューには、Ceph関連タスクが一覧にされます。現在のところ、関係するタス

クは、［OSDs (OSD)］、［RBDs (RBD)］、［Pools (プール)］、［Nodes (ノード)］、［iSCSI］、［NFS］、

［CRUSH Map (CRUSHマップ)］、および［Object Gateway］です。

15.4.1 Web UIの共通機能

openATTICでは、プールのリスト、OSDノードのリスト、RBDデバイスのリストなど、「リスト」を操作する

ことがよくあります。次の共通ウィジェットは、これらのリストを管理または調整する場合に役立ちます。

をクリックして、項目のリストを更新します。

をクリックして、個々のテーブル列の表示/非表示を切り替えます。

をクリックして、1ページに表示する行数を選択します。

の内部をクリックし、検索する文字列を入力して行をフィルタします。

リストが複数のページにわたる場合は、を使用して、現在表示されているページを変更

します。

204 Ceph関連タスク SES 5

15.4.2 OSDノードの一覧

利用可能なすべてのOSDノードを一覧にするには、メインメニューから［OSDs (OSD)］をクリックしま

す。

各OSDの名前、ホスト名、状態、重み、およびストレージバックエンドがリストに表示されます。

図 15.7: OSDノードのリスト

15.4.3 RADOS RBD (RADOS Block Device)の管理

利用可能なすべてのRADOS Block Deviceを一覧にするには、メインメニューから［RBD (RBD)］を

クリックします。

各デバイスの名前、関連するプール名、デバイスのサイズ、RADOS Block Deviceの作成中に「fast-

diff」が有効になっていたかどうか、およびすでに使用済みの割合がリストに表示されます。

図 15.8: RBDのリスト

205 OSDノードの一覧 SES 5

15.4.3.1 状態情報

デバイスの詳細を表示するには、左端の列にあるチェックボックスをオンにします。

図 15.9: RBDの詳細

15.4.3.2 統計

転送されたデータの統計を表示するには、RADOS Block Deviceの［Statistics (統計)］タグをクリッ

クします。マウスで時間範囲を強調表示するか、タブの左上隅にある日付をクリックしてから時間範囲を

選択することにより、時間間隔をズームイン/ズームアウトできます。

15.4.3.3 RADOS Block Deviceのスナップショット

RADOS Block Deviceのスナップショットを作成するには、［Snapshots (スナップショット)］タブをク

リックして、左上のドロップダウンボックスから［Create (作成)］を選択します。

スナップショットを選択した後、スナップショットの名前変更、保護、クローンの作成、または削除を行うこ

とができます。複数のスナップショットを選択して削除することもできます。［Rollback (ロールバック)］

は、現在のスナップショットからデバイスの状態を復元します。

図 15.10: RBDのスナップショット

206 RADOS RBD (RADOS Block Device)の管理 SES 5

15.4.3.4 RBDの削除

1つのデバイスまたは複数のデバイスのグループを削除するには、左端の列にあるチェックボックスを

オンにして、RBDテーブルの左上で［Delete (削除)］をクリックします。

図 15.11: RBDの削除

15.4.3.5 RBDの追加

新しいデバイスを追加するには、RBDテーブルの左上で［Add (追加)］をクリックして、［Create RBD

(RBDの作成)］画面で次の操作を行います。

図 15.12: 新しいRBDの追加

1. 新しいデバイスの名前を入力します。命名の制限については、『導入ガイド』、第2章「ハードウェ

ア要件と推奨事項」、2.8項「命名の制限」を参照してください。

207 RADOS RBD (RADOS Block Device)の管理 SES 5

2. 新しいプールを保存するクラスタを選択します。

3. 新しいRBDデバイスの作成元となるプールを選択します。

4. 新しいデバイスのサイズを指定します。上の［use max (最大限使用)］リンクをクリックすると、

プールの最大サイズにデータが入力されます。

5. デバイスのパラメータを微調整するには、［Expert settings (エキスパート設定)］をクリックして、

表示されるオプションを有効/無効にします。

6. ［Create (作成)］をクリックして確認します。

15.4.4 プールの管理

ヒント: プールについての詳細Cephのプールの全般的な情報については、第7章「ストレージプールの管理」を参照してくだ

さい。イレージャコーディングプールに固有の情報については、第9章「イレージャコーディング

プール」を参照してください。

利用可能なすべてのプールを一覧にするには、メインメニューから［Pools (プール)］をクリックします。

各プールの名前、ID、使用済み領域の割合、配置グループの数、レプリカのサイズ、タイプ

(「replicated (複製)」または「erasure (イレージャ)」)、イレージャコードプロファイル、およびCRUSH

ルールセットがリストに表示されます。

図 15.13: プールのリスト

208 プールの管理 SES 5

プールの詳細を表示するには、左端の列にあるチェックボックスをオンにします。

図 15.14: プールの詳細

15.4.4.1 プールの削除

1つのプールまたは複数のプールのグループを削除するには、左端の列にあるチェックボックスをオン

にして、プールテーブルの左上で［Delete (削除)］をクリックします。

図 15.15: プールの削除

15.4.4.2 プールの追加

新しいプールを追加するには、プールテーブルの左上で［Add (追加)］をクリックして、［Create Ceph

pool (Cephプールの作成)］画面で次の操作を行います。

209 プールの管理 SES 5

図 15.16: 新しいプールの追加

1. 新しいプールの名前を入力します。命名の制限については、『導入ガイド』、第2章「ハードウェア

要件と推奨事項」、2.8項「命名の制限」を参照してください。

2. 新しいプールを保存するクラスタを選択します。

3. プールタイプを選択します。プールは複製またはイレージャコーディングのいずれかにできます。

4. a. 複製プールの場合、レプリカのサイズと配置グループの数を指定します。

b. イレージャコーディングプールの場合、配置グループの数とイレージャコードプロファイルを

指定します。カスタムプロファイルを追加するには、プラス［+］記号をクリックして、プロファ

イル名、データ、コーディングチャンク、およびルールセットの障害ドメインを指定します。

5. ［Create (作成)］をクリックして確認します。

15.4.5 ノードの一覧クラスタで利用可能なノードのリストを表示するには、メインメニューから［Nodes (ノード)］をクリックし

ます。

図 15.17: ノードのリスト

210 ノードの一覧 SES 5

各ノードは、そのホスト名、パブリックIPアドレス、所属先のクラスタID、ノードの役割(たとえば、

「admin」、「storage」、または「master」)、および鍵の受領状態によって表されます。

15.4.6 NFS Ganeshaの管理

ヒント: NFS Ganeshaについての詳細NFS Ganeshaの全般的な情報については、第14章「NFS Ganesha: NFS経由でのCeph

データのエクスポート」を参照してください。

利用可能なすべてのNFSエクスポートを一覧にするには、メインメニューから［NFS］をクリックします。

各エクスポートのディレクトリ、ホスト名、状態、ストレージバックエンドのタイプ、およびアクセスタイプが

リストに表示されます。

図 15.18: NFSエクスポートのリスト

NFSエクスポートの詳細を表示するには、左端の列にあるチェックボックスをオンにします。

211 NFS Ganeshaの管理 SES 5

図 15.19: NFSエクスポートの詳細

ヒント: NFSマウントコマンドエクスポートの詳細ビューの下部にはマウントコマンドがあり、これを使用すると、関連するNFS

エクスポートをクライアントマシンから簡単にマウントできます。

15.4.6.1 NFSエクスポートの追加

新しいNFSエクスポートを追加するには、エクスポートテーブルの左上で［Add (追加)］をクリックして、

必要な情報を入力します。


図 15.20: 新しいNFSエクスポートの追加

1. NFSエクスポートのサーバホストを選択します。

2. ストレージバックエンドを選択します。［CephFS］または［Object Gateway］のいずれかを選択

します。

3. NFSエクスポートのディレクトリパスを入力します。指定したディレクトリがサーバ上に存在しない

場合、新しく作成されます。

4. 他のNFS関連オプションを指定します。たとえば、サポートされるNFSプロトコルのバージョン、ア

クセスタイプ、squash (ルート権限無効化)、またはトランスポートプロトコルなどです。

5. アクセスを特定のクライアントだけに制限する必要がある場合、［Add clients (クライアントの追

加)］をクリックして、クライアントのIPアドレスと共に、アクセスタイプとsquash (ルート権限無効

化)オプションを指定します。


6. ［Submit (送信)］をクリックして確認します。

15.4.6.2 NFSエクスポートのクローン作成と削除

1つのエクスポートまたは複数のエクスポートのグループを削除するには、左端の列にあるチェックボッ

クスをオンにして、エクスポートテーブルの左上で［Delete (削除)］を選択します。

同様に、［Clone (クローンの作成)］を選択して、有効なゲートウェイのクローンを作成することもできま

す。

15.4.6.3 NFSエクスポートの編集

既存のエクスポートを編集するには、エクスポートテーブルでエクスポートの名前をクリックするか、該

当するチェックボックスをオンにして、エクスポートテーブルの左上で［Edit (編集)］をクリックします。

その後、NFSエクスポートのすべての詳細を調整できます。


図 15.21: NFSエクスポートの編集

15.4.7 iSCSI Gatewayの管理

ヒント: iSCSI Gatewayについての詳細iSCSIの全般的な情報については、『導入ガイド』、第10章「iSCSI Gatewayのインストール」お

よび第12章「Ceph iSCSI Gateway」を参照してください。

利用可能なすべてのゲートウェイを一覧にするには、メインメニューから［iSCSI］をクリックします。

各ゲートウェイのターゲット、状態、および関連するポータルとRBDイメージがリストに表示されます。

215 iSCSI Gatewayの管理 SES 5

図 15.22: ISCSI GATEWAYのリスト

ゲートウェイの詳細を表示するには、左端の列にあるチェックボックスをオンにします。

図 15.23: ゲートウェイの詳細

15.4.7.1 iSCSI Gatewayの追加

新しいiSCSI Gatewayを追加するには、ゲートウェイテーブルの左上で［Add (追加)］をクリックして、

必要な情報を入力します。


図 15.24: 新しいISCSI GATEWAYの追加

1. 新しいゲートウェイのターゲットアドレスを入力します。

2. ［Add portal (ポータルの追加)］をクリックして、リストから1つまたは複数のiSCSIポータルを選

択します。

3. ［Add image (イメージの追加)］をクリックして、ゲートウェイのRBDイメージを1つまたは複数選

択します。

4. 認証を使用してゲートウェイにアクセスする必要がある場合は、［Authentication (認証)］

チェックボックスをオンにして資格情報を入力します。［Mutual authentication (相互認証)］

および［Discovery authentication (ディスカバリ認証)］を有効にすると、より高度な認証オプ

ションが表示されます。



15.4.7.2 iSCSI Gatewayの編集

既存のiSCSI Gatewayを編集するには、ゲートウェイテーブルでゲートウェイの名前をクリックするか、

該当するチェックボックスをオンにして、ゲートウェイテーブルの左上で［Edit (編集)］をクリックします。

その後、iSCSIターゲットの追加、ポータルの追加または削除、および関連するRBDイメージの追加ま

たは削除を行うことができます。ゲートウェイの認証情報を調整することもできます。

15.4.7.3 iSCSI Gatewayのクローン作成と削除

1つのゲートウェイまたは複数のゲートウェイのグループを削除するには、左端の列にあるチェックボッ

クスをオンにして、ゲートウェイテーブルの左上で［Delete (削除)］を選択します。

同様に、［Clone (クローンの作成)］を選択して、有効なゲートウェイのクローンを作成することもできま

す。

15.4.7.4 iSCSI Gatewayの起動と停止

すべてのゲートウェイを起動するには、ゲートウェイテーブルの左上で［Start all (すべて起動)］を選択

します。すべてのゲートウェイを停止するには、［Stop all (すべて停止)］を選択します。

15.4.8 クラスタのCRUSHマップの表示クラスタのCRUSHマップを表示するには、メインメニューから［CRUSH Map (CRUSHマップ)］をク

リックします。

図 15.25: CRUSHマップ

［Physical setup (物理セットアップ)］ペインで、CRUSHマップに記述されているクラスタの構造を参

照できます。

218 クラスタのCRUSHマップの表示 SES 5

［Replication rules (レプリケーションルール)］ペインで、［Content (内容)］ドロップダウンボックスか

らルールセットを1つ選択した後、個々のルールセットを参照できます。

図 15.26: レプリケーションルール

15.4.9 Object Gatewayのユーザとバケットの管理

ヒント: Object Gatewayについての詳細Object Gatewayの全般的な情報については、第11章「Ceph Object Gateway」を参照して

ください。

Object Gatewayユーザを一覧にするには、メインメニューから［Object Gateway］［Users (ユー

ザ)］を選択します。

各ユーザのID、表示名、電子メールアドレス、ユーザが一時停止されているかどうか、およびユーザの

バケットの最大数がリストに表示されます。

図 15.27: OBJECT GATEWAYユーザのリスト

219 Object Gatewayのユーザとバケットの管理 SES 5

15.4.9.1 新しいObject Gatewayユーザの追加

新しいObject Gatewayユーザを追加するには、ユーザテーブルの左上で［Add (追加)］をクリックし

て、関連する情報を入力します。

ヒント: 詳細情報Object Gatewayのユーザアカウントの詳細については、11.5.2項「S3およびSwiftアカウント

の管理」を参照してください。

図 15.28: 新しいOBJECT GATEWAYユーザの追加

1. ユーザ名、フルネーム、およびオプションで電子メールアドレスとユーザのバケットの最大数を入

力します。

2. ユーザを初期状態で一時停止する必要がある場合、［Suspended (一時停止)］チェックボック

スをオンにします。

3. S3認証用のアクセスキーと秘密鍵を指定します。openATTICでキーを生成する場合は、

［Generate key (キーの生成)］をオンにします。


4. ［User quota (ユーザクォータ)］セクションで、現在のユーザのクォータ制限を設定します。

ユーザクォータ制限を有効にするには、［Enabled (有効)］をオンにします。［Maximum size

(最大サイズ)］で、クラスタ内でユーザが使用できるディスク領域の最大サイズを指定できます。

サイズ制限を設定しない場合は、［Unlimited size (サイズ無制限)］をオンにできます。

同様に、［Maximum objects (最大オブジェクト数)］で、ユーザがクラスタストレージに保存

できる最大オブジェクト数を指定します。ユーザがいくつでもオブジェクトを保存できる場合は、

［Unlimited objects (オブジェクト数無制限)］を指定します。

図 15.29: ユーザクォータ

5. ［Bucket Quota (バケットクォータ)］セクションで、現在のユーザのバケットクォータ制限を設定

します。

図 15.30: バケットクォータ


15.4.9.2 Object Gatewayユーザの削除

1人以上のObject Gatewayユーザを削除するには、左端の列にあるチェックボックスをオンにして、

ユーザテーブルの左上で［Delete (削除)］を選択します。


15.4.9.3 Object Gatewayユーザの編集

1人のObject Gatewayユーザのユーザ情報を編集するには、左端の列にあるチェックボックスをオン

にして、ユーザテーブルの左上で［Edit (編集)］を選択するか、ユーザのIDをクリックします。15.4.9.1

項「新しいObject Gatewayユーザの追加」でユーザを追加したときに入力した情報のほかに、次の追

加の情報を変更できます。

サブユーザ

現在編集中のユーザのサブユーザを追加、削除、または編集します。

図 15.31: サブユーザの追加

キー

現在編集中のユーザのアクセスキーと秘密鍵を追加、削除、または表示します。

現在編集中のユーザのS3キーを追加したり、そのサブユーザのSwiftキーを表示したりできます。

図 15.32: S3キーの表示

ケーパビリティ


ユーザのケーパビリティを追加または削除します。ケーパビリティは、［buckets (バケット)］、

［zone (ゾーン)］、［users (ユーザ)］、［metadata (メタデータ)］、および［usage (使用量)］に適

用されます。各ケーパビリティの値は、［read (読み込み)］または［write (書き込み)］、あるいは

［*］ (読み込みと書き込みの特権の場合)にできます。

図 15.33: ケーパビリティ

15.4.9.4 Object Gatewayユーザのバケットの一覧

ヒントバケットは、データオブジェクトを保存するためのメカニズムです。1つのユーザアカウントが

複数のバケットを持つことができますが、各バケット名は固有である必要があります。「バケッ

ト」という用語は通常、Amazon S3 API内で使用されるのに対し、「コンテナ」という用語は

OpenStack Swift APIのコンテキストで使用されます。

利用可能なすべてのObject Gatewayのバケットを一覧にするには、［Object

Gateway］［Buckets (バケット)］をクリックします。

図 15.34: OBJECT GATEWAYのバケット

15.4.9.5 Object Gatewayユーザのバケットの追加

新しいバケットを追加するには、バケットテーブルの左上で［Add (追加)］をクリックして、新しいバケッ

トの名前と、関連するObject Gatewayユーザを入力します。［Submit (送信)］をクリックして確認しま

す。


図 15.35: 新しいバケットの追加

15.4.9.6 バケットの詳細の表示

Object Gatewayのバケットの詳細を表示するには、バケットテーブルの左端の列にあるチェックボッ

クスをオンにします。

図 15.36: バケットの詳細

15.4.9.7 バケットの編集

バケットを編集するには、左端の列にあるチェックボックスをオンにして、バケットテーブルの左上で

［Edit (編集)］を選択するか、バケットの名前をクリックします。


図 15.37: OBJECT GATEWAYのバケットの編集

編集画面で、バケットが属するユーザを変更できます。

15.4.9.8 バケットの削除

1つまたは複数のObject Gatewayのバケットを削除するには、バケットテーブルの左端の列にある

チェックボックスをオンにして、テーブルの左上で［Delete (削除)］を選択します。

図 15.38: バケットの削除

削除を確認するには、［Delete buckets (バケットの削除)］ポップアップウィンドウで「yes」と入力し

て、［Delete (削除)］をクリックします。

警告: 削除は慎重にObject Gatewayのバケットを削除する場合、バケットが実際に使用中かどうか(たとえば、その

バケットがNFS GaneshaやS3ストレージバックエンドによって使用中かどうかなど)は現在のと

ころ検証されません。


V 仮想化ツールとの統合

16 Cephでのlibvirtの使用 227

17 QEMU KVMインスタンスのバックエンドとしてのCephの使用 233

16 Cephでのlibvirtの使用

libvirtライブラリは、ハイパーバイザーインタフェースと、それらを使用するソフトウェアアプリケー

ションとの間に仮想マシン抽象化層を作成します。 libvirtを使用することにより、開発者やシステム

管理者は、QEMU/KVM、Xen、LXC、VirtualBoxなど、さまざまなハイパーバイザーに対する共通管

理フレームワーク、共通API、および共通シェルインタフェース( virsh )に集中できます。

Ceph Block DeviceはQEMU/KVMをサポートします。 libvirtと連動するソフトウェアでCeph

Block Deviceを使用できます。クラウドソリューションは libvirtを使用してQEMU/KVMと対話

し、QEMU/KVMは librbdを介してCeph Block Deviceと対話します。

Ceph Block Deviceを使用するVMを作成するには、以降のセクションの手順を使用します。これら

の例では、プール名に libvirt-pool 、ユーザ名に client.libvirt 、イメージ名に new-libvirt-

imageをそれぞれ使用しています。好きな値を使用できますが、後続の手順でコマンドを実行する際に

値を置き換えるようにしてください。

16.1 Cephの設定libvirtで使用するためにCephを設定するには、次の手順を実行します。

1. プールを作成します。次の例では、プール名 libvirt-poolと128の配置グループを使用して

います。

ceph osd pool create libvirt-pool 128 128

プールが存在することを確認します。

ceph osd lspools

2. Cephユーザを作成します。次の例では、Cephユーザ名 client.libvirtを使用し、 libvirt-

poolを参照しています。

ceph auth get-or-create client.libvirt mon 'allow r' osd \ 'allow class-read object_prefix rbd_children, allow rwx pool=libvirt-pool'

名前が存在することを確認します。

ceph auth list

227 Cephの設定 SES 5

注記libvirtは、Cephユーザ名 client.libvirtではなくID libvirtを使用してCeph

にアクセスします。IDと名前の違いの詳細については、http://docs.ceph.com/docs/

master/rados/operations/user-management/#user を参照してください。

3. QEMUを使用してRBDプール内にイメージを作成します。次の例では、イメージ名 new-

libvirt-imageを使用し、 libvirt-poolを参照しています。

ヒント: キーリングファイルの場所「libvirt」ユーザのキーリングのパスが［/etc/ceph/ceph.conf］で指定されていること

を確認します。次に例を示します。

keyring = /etc/ceph/client.libvirt.keyring

キーリングが存在しない場合は、次のコマンドで作成します。

root # ceph auth get client.libvirt > /etc/ceph/client.libvirt.keyring

qemu-img create -f raw rbd:libvirt-pool/new-libvirt-image:id=libvirt 2G

イメージが存在することを確認します。

rbd -p libvirt-pool ls

16.2 VMマネージャの準備libvirtはVMマネージャなしでも使用できますが、最初のドメインは virt-managerで作成する方

が簡単です。

1. 仮想マシンマネージャをインストールします。

sudo zypper in virt-manager

2. 仮想化して実行するシステムのOSイメージを準備/ダウンロードします。

3. 仮想マシンマネージャを起動します。

228 VMマネージャの準備 SES 5

http://docs.ceph.com/docs/master/rados/operations/user-management/#user

http://docs.ceph.com/docs/master/rados/operations/user-management/#user

virt-manager

16.3 VMの作成virt-managerでVMを作成するには、次の手順を実行します。

1. リストから接続を選択し、右クリックして［New (新規作成)］を選択します。

2. ［Import existing disk image (既存のディスクイメージのインポート)］を選択し、既存のスト

レージのパスを入力して、既存のディスクイメージをインポートします。OSタイプとメモリ設定を指

定し、［名前］に仮想マシンの名前を入力します。たとえば、 libvirt-virtual-machineです。

3. 設定を完了してVMを起動します。

4. sudo virsh listを使用して、新しく作成したドメインが存在することを確認します。必要に応

じて、次のように接続文字列を指定します。

virsh -c qemu+ssh://root@vm_host_hostname/system listId Name State-----------------------------------------------[...] 9 libvirt-virtual-machine running

5. VMにログインし、Cephで使用するために設定する前にVMを停止します。

16.4 VMの設定この章では、 virshを使用してCephとの統合用にVMを設定する方法に焦点を当てて説明します。

多くの場合、 virshコマンドにはルート特権( sudo )が必要で、ルート特権がないと適切な結果が返さ

れません。また、ルート特権が必要なことは通知されません。 virshコマンドのリファレンスについては、

「Virsh Command Reference (http://www.libvirt.org/virshcmdref.html) 」を参照してくださ

い。

1. virsh edit vm-domain-nameを使用して、設定ファイルを開きます。

sudo virsh edit libvirt-virtual-machine

2. <devices>の下位に<disk>エントリが存在する必要があります。

<devices>

229 VMの作成 SES 5

http://www.libvirt.org/virshcmdref.html

<emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/image/recent-linux.img'/> <target dev='vda' bus='virtio'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk>

/path/to/image/recent-linux.imgは、OSイメージのパスに置き換えてください。

重要テキストエディタではなく、 sudo virsh editを使用してください。 /etc/libvirt/

qemuにある設定ファイルをテキストエディタで編集した場合、 libvirtが変更を認識し

ないことがあります。 /etc/libvirt/qemuにあるXMLファイルの内容と sudo virsh

dumpxml vm-domain-nameの結果に違いがある場合、VMが適切に動作しないことが

あります。

3. 前に作成したCeph RBDイメージを<disk>エントリとして追加します。

<disk type='network' device='disk'> <source protocol='rbd' name='libvirt-pool/new-libvirt-image'> <host name='monitor-host' port='6789'/> </source> <target dev='vda' bus='virtio'/></disk>

monitor-hostを実際のホスト名に置き換え、必要に応じてプールまたはイメージ、あるいはそ

の両方の名前を置き換えてください。Ceph Monitor用に複数の<host>エントリを追加できま

す。 dev属性は、VMの /devディレクトリに表示される論理デバイス名です。オプションのbus属

性は、エミュレートするディスクデバイスのタイプを示します。有効な設定はドライバ固有です(た

とえば、ide、scsi、virtio、xen、usb、sataなど)。<disk>要素、およびその子要素と属性の詳細に

ついては、「ディスク (http://www.libvirt.org/formatdomain.html#elementsDisks) 」を参


4. ファイルを保存します。

5. Cephクラスタで認証が有効になっている場合(デフォルト)、秘密を生成する必要があります。好

みのエディタを開き、次の内容で secret.xmlという名前のファイルを作成します。

<secret ephemeral='no' private='no'> <usage type='ceph'> <name>client.libvirt secret</name> </usage>

230 VMの設定 SES 5

http://www.libvirt.org/formatdomain.html#elementsDisks

</secret>

6. 秘密を定義します。

sudo virsh secret-define --file secret.xml<uuid of secret is output here>

7. client.libvirtの鍵を取得して、鍵の文字列をファイルに保存します。

ceph auth get-key client.libvirt | sudo tee client.libvirt.key

8. 秘密のUUIDを設定します。

sudo virsh secret-set-value --secret uuid of secret \--base64 $(cat client.libvirt.key) && rm client.libvirt.key secret.xml

さらに、前に入力した <disk>要素に次の <auth>エントリを追加することにより、秘密を手動で

設定する必要もあります(uuidの値は、上のコマンドライン例の結果に置き換えます)。

sudo virsh edit libvirt-virtual-machine

続いて、ドメイン設定ファイルに <auth></auth>要素を追加します。

...</source><auth username='libvirt'> <secret type='ceph' uuid='9ec59067-fdbc-a6c0-03ff-df165c0587b8'/></auth><target ...

注記この例で使用しているIDは libvirtで、16.1項「Cephの設定」の手順2で生成した

Cephユーザ名 client.libvirtではありません。生成したCephユーザ名のID部分

を使用するようにしてください。何らかの理由で秘密を再生成する必要がある場合は、

もう一度 sudo virsh secret-set-valueを実行する前に、 sudo virsh secret-

undefine uuidを実行する必要があります。

16.5 概要Cephで使用するためにVMを設定したら、VMを起動できます。VMとCephが通信していることを確認

するには、次の手順を実行できます。

231 概要 SES 5

1. Cephが動作しているかどうかを確認します。

ceph health

2. VMが動作しているかどうかを確認します。

sudo virsh list

3. VMがCephと通信しているかどうかを確認します。 vm-domain-nameはVMドメインの名前に置

き換えてください。

sudo virsh qemu-monitor-command --hmp vm-domain-name 'info block'

4. &target dev='hdb' bus='ide'/>のデバイスが /devまたは /proc/partitionsに表示さ

れるかどうかを確認します。

ls /devcat /proc/partitions

232 概要 SES 5

17 QEMU KVMインスタンスのバックエンドとしてのCephの使用

Cephの最も一般的な使用事例として、仮想マシンにBlock Deviceイメージを提供することがありま

す。たとえば、理想的な設定のOSと関連ソフトウェアを使用して「ゴールデン」イメージを作成できます。

続いて、そのイメージのスナップショットを作成します。最後に、スナップショットのクローンを作成します

(通常は複数回。詳細については、8.3項「Block Deviceのスナップショット」を参照してください)。ス

ナップショットのコピーオンライトクローンを作成できるということは、新しい仮想マシンを起動するたび

にクライアントがイメージ全体をダウンロードしないで済むため、CephはBlock Deviceイメージを仮想

マシンに素早くプロビジョニングできることを意味します。

Ceph Block DeviceをQEMU仮想マシンと統合できます。QEMU KVMの詳細に

ついては、https://www.suse.com/documentation/sles-12/book_virt/data/

part_virt_qemu.html を参照してください。

17.1 インストールCeph Block Deviceを使用するには、QEMUに適切なドライバがインストールされている必要があり

ます。 qemu-block-rbdパッケージがインストールされているかどうかを確認し、必要に応じてインス

トールします。

sudo zypper install qemu-block-rbd

17.2 使用法QEMUのコマンドラインで、プール名とイメージ名を指定する必要があります。スナップショット名も指

定できます。

qemu-img command options \rbd:pool-name/image-name@snapshot-name:option1=value1:option2=value2...

たとえば、 idおよび confのオプションを指定すると、次のようになります。

qemu-img command options \rbd:pool_name/image_name:id=glance:conf=/etc/ceph/ceph.conf

233 インストール SES 5

https://www.suse.com/documentation/sles-12/book_virt/data/part_virt_qemu.html

https://www.suse.com/documentation/sles-12/book_virt/data/part_virt_qemu.html

17.3 QEMUでのイメージの作成QEMUからBlock Deviceイメージを作成できます。 rbd 、プール名、および作成するイメージの名前を

指定する必要があります。イメージのサイズも指定する必要があります。

qemu-img create -f raw rbd:pool-name/image-name size


qemu-img create -f raw rbd:pool1/image1 10GFormatting 'rbd:pool1/image1', fmt=raw size=10737418240 nocow=off cluster_size=0

重要RBDで使用するフォーマットオプションとして実用的なものは、実際のところ rawデータフォー

マットだけです。技術的には、 qcow2などQEMUでサポートされている他のフォーマットを使用

できますが、そうするとオーバーヘッドが追加されるほか、キャッシングが有効な場合に、仮想マ

シンのライブマイグレーションにおいてボリュームが不安定になります。

17.4 QEMUでのイメージのサイズ変更QEMUからBlock Deviceイメージのサイズを変更できます。 rbd 、プール名、およびサイズを変更する

イメージの名前を指定する必要があります。イメージのサイズも指定する必要があります。

qemu-img resize rbd:pool-name/image-name size


qemu-img resize rbd:pool1/image1 9GImage resized.

17.5 QEMUでのイメージ情報の取得QEMUからBlock Deviceイメージの情報を取得できます。 rbd 、プール名、およびイメージの名前を

指定する必要があります。

qemu-img info rbd:pool-name/image-name


qemu-img info rbd:pool1/image1

234 QEMUでのイメージの作成 SES 5

image: rbd:pool1/image1file format: rawvirtual size: 9.0G (9663676416 bytes)disk size: unavailablecluster_size: 4194304

17.6 RBDでのQEMUの実行QEMUは、 librbdを介して仮想Block Deviceとしてイメージに直接アクセスできます。これにより、

追加のコンテキストスイッチを避け、RBDキャッシングを利用できます。

qemu-imgを使用して、既存の仮想マシンイメージをCeph Block Deviceイメージに変換できます。た

とえば、qcow2イメージがある場合、次のコマンドを実行できます。

qemu-img convert -f qcow2 -O raw sles12.qcow2 rbd:pool1/sles12

そのイメージから仮想マシンの起動を実行するには、次のコマンドを実行できます。

qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12

RBDキャッシング (http://ceph.com/docs/master/rbd/rbd-config-ref/#cache-settings) はパ

フォーマンスを大幅に向上できます。QEMUのキャッシュオプションで librbdのキャッシングを制御し

ます。

qemu -m 1024 -drive format=rbd,file=rbd:pool1/sles12,cache=writeback

17.7 Discard/TRIMの有効化Ceph Block Deviceはdiscard操作をサポートしています。つまり、ゲストはTRIM要求を送信し

てCeph Block Deviceに未使用領域を解放させることができます。ゲストでこれを有効にするに

は、discardオプションを指定して XFSをマウントします。

ゲストがこれを利用できるようにするには、Block Deviceに対して明示的に有効にする必要がありま

す。このためには、ドライブに関連付けられている discard_granularityを指定する必要があります。

qemu -m 1024 -drive format=raw,file=rbd:pool1/sles12,id=drive1,if=none \-device driver=ide-hd,drive=drive1,discard_granularity=512

注記上の例では、IDEドライバを使用しています。virtioドライブはdiscardをサポートしません。

235 RBDでのQEMUの実行 SES 5

http://ceph.com/docs/master/rbd/rbd-config-ref/#cache-settings

libvirtを使用する場合、 virsh editを使用してlibvirtドメインの設定ファイルを編集

し、 xmlns:qemuの値を含めます。その後、 qemu:commandline blockをそのドメインの子として追加

します。次の例に、 qemu id=を使用して2台のデバイスを異なる discard_granularityの値に設定

する方法を示します。

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-0.discard_granularity=4096'/> <qemu:arg value='-set'/> <qemu:arg value='block.scsi0-0-1.discard_granularity=65536'/> </qemu:commandline></domain>

17.8 QEMUのキャッシュオプションQEMUのキャッシュオプションは、次のCeph RBDキャッシュ設定に対応します。

ライトバック:

rbd_cache = true

ライトスルー:

rbd_cache = truerbd_cache_max_dirty = 0

なし:

rbd_cache = false

QEMUのキャッシュ設定は、Cephのデフォルト設定(Cephの設定ファイルで明示的に設定されてい

ない設定)を上書きします。Cephの設定ファイルでRBDキャッシュ (http://ceph.com/docs/master/

rbd/rbd-config-ref/#cache-settings) 設定を明示的に設定した場合、Cephの設定がQEMUの

キャッシュ設定を上書きします。QEMUのコマンドラインでキャッシュ設定を行った場合、QEMUのコマ

ンドラインの設定がCephの設定ファイルの設定を上書きします。

236 QEMUのキャッシュオプション SES 5



VI FAQ (よくある質問と答え)、ヒント、およびトラブルシューティング

18 ヒント 238

19 FAQ (よくある質問と答え) 250

20 トラブルシューティング 253

18 ヒント

この章には、Cephクラスタのパフォーマンス向上に役立つ情報と、クラスタの設定方法のヒントが記載

されています。

18.1 スクラブの調整デフォルトでは、Cephは軽量スクラブ(詳細については、6.5項「スクラブ」を参照)を毎日、詳細スクラ

ブを週1回実行します。「軽量」スクラブは、オブジェクトのサイズとチェックサムを調べて、配置グループ

が同じオブジェクトデータを保存していることを確認します。「詳細」スクラブは、オブジェクトの内容とレ

プリカの内容を調べて、実際の内容が同じであることを確認します。データ整合性チェックには、スクラ

ブ手順中にクラスタのI/O負荷が増加するという代償があります。

デフォルト設定では、Ceph OSDは負荷が高い時間帯など不適切な時間にもスクラブを開始できま

す。スクラブ操作が顧客の操作と衝突すると、顧客においてレイテンシやパフォーマンスの低下が発生

する場合があります。Cephには、低負荷の期間またはピーク時以外の時間帯にスクラブを制限できる

スクラブ設定が複数用意されています。

クラスタの負荷が日中に高く夜間に低い場合は、スクラブを夜間の時間帯(午後11時〜午前6時など)

に制限することを検討します。

[osd]osd_scrub_begin_hour = 23osd_scrub_end_hour = 6

時間制限ではスクラブスケジュールを効果的に決定できない場合

は、 osd_scrub_load_thresholdオプションの使用を検討します。デフォルト値は0.5ですが、低負荷

の条件に合わせて変更できます。

[osd]osd_scrub_load_threshold = 0.25

18.2 リバランスなしでのOSDの停止保守のために定期的にOSDを停止しなければならないことがあります。大量のデータ転送を避けるた

め、CRUSHが自動的にクラスタをリバランスしないようにする場合、まずクラスタを nooutに設定しま

す。

root@minion > ceph osd set noout

238 スクラブの調整 SES 5

クラスタが nooutに設定されたら、保守作業が必要な障害ドメイン内にあるOSDの停止を開始できま

す。

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

詳細情報については、3.1.2項「個々のサービスの起動、停止、および再起動」を参照してください。

保守が完了したら、OSDをもう一度起動します。

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

OSDサービスが起動したら、クラスタの nooutを設定解除します。

root@minion > ceph osd unset noout

18.3 ノードの時刻同期Cephでは、特定のノード間で時刻が正確に同期している必要があります。独自のNTPサーバを使用し

てノードを設定する必要があります。すべてのntpdインスタンスがリモートのパブリックタイムサーバを

指すことはできますが、Cephではお勧めしません。このような設定にすると、クラスタ内の各ノードが専

用のNTPデーモンを持ち、そのデーモンが相当なホップ数離れた3〜4台の一連のタイムサーバとイン

ターネット上で継続的に通信することになります。このソリューションでは多大なレイテンシ変動が発生

し、そのためにクロックの誤差を0.05秒未満(Ceph Monitorで必要)に抑えることは困難または不可

能です。

したがって、クラスタ全体で1台のマシンをNTPサーバとして使用します。そうすれば、NTPサーバの

ntpdインスタンスはリモートの(パブリック)NTPサーバを指すことも、独自のタイムソースを使用す

ることもできます。そのうえで、すべてのノードのntpdインスタンスがこのローカルサーバを指します。

このソリューションには、不要なネットワークトラフィックやクロックスキューが解消される、パブリック

NTPサーバの負荷が減少するといった複数の利点があります。NTPサーバの設定方法の詳細に

ついては、『SUSE Linux Enterprise Server Administration Guide (https://www.suse.com/

documentation/sled11/book_sle_admin/data/cha_netz_xntp.html) 』を参照してください。

その後、クラスタの時刻を変更するため、次の操作を行います。

重要: 時刻の設定たとえば夏時間から標準時間に変わった場合など、時刻を戻さなければならない状況が発生す

ることがあります。クラスタのダウン時間より長く時刻を戻すことはお勧めしません。時刻を進め

ても問題は発生しません。

239 ノードの時刻同期 SES 5

https://www.suse.com/documentation/sled11/book_sle_admin/data/cha_netz_xntp.html

https://www.suse.com/documentation/sled11/book_sle_admin/data/cha_netz_xntp.html

手順 18.1: クラスタの時刻同期

1. Cephクラスタにアクセスするすべてのクライアントを停止します。特にiSCSIを使用しているクラ

イアントは必ず停止します。

2. Cephクラスタをシャットダウンします。各ノードで、次のコマンドを実行します。

systemctl stop ceph.target

注記CephとSUSE OpenStack Cloudを使用する場合は、SUSE OpenStack Cloudも停

止します。

3. NTPサーバが正しく設定されていて、すべてのntpdデーモンがローカルネットワーク内の1つ以

上のソースから時刻を取得していることを確認します。

4. NTPサーバに正しい時刻を設定します。

5. NTPが適切に稼働および動作していることを確認し、すべてのノードで次のコマンドを実行しま

す。

status ntpd.service

または

ntpq -p

6. すべてのモニタリングノードを起動して、クロックスキューがないことを確認します。

systemctl start target

7. すべてのOSDノードを起動します。

8. Cephのその他のサービスを起動します。

9. SUSE OpenStack Cloudを使用している場合は起動します。

240 ノードの時刻同期 SES 5

18.4 不均衡なデータ書き込みの確認データが各OSDに均等に書き込まれている場合、クラスタは均衡状態と見なされます。クラスタ内の各

OSDには「重み」が割り当てられます。重みは相対的な数字で、関連するOSDに書き込む必要がある

データの量をCephに指示します。重みが大きいほど、多くのデータが書き込まれます。OSDの重みが0

の場合、そのOSDにデータは書き込まれません。あるOSDの重みが他のOSDと比べて比較的大きい

場合、大部分のデータがそのOSDに書き込まれ、クラスタが不均衡になります。

不均衡なクラスタはパフォーマンスが低く、大きい重みを持つOSDが突然クラッシュした場合、大量の

データを他のOSDに移動しなければならず、これによってクラスタの速度も低下します。

これを避けるには、OSDでデータ書き込みの量を定期的に確認する必要があります。この量が特定の

ルールセットで指定されたOSDグループの容量の30〜50%である場合、OSDの重みを変更する必要

があります。個々のディスクを確認して、他のディスクより満杯になるのが早い(または一般的に低速で

ある)ディスクを確認し、その重みを減らします。十分なデータが書き込まれていないOSDでも同じこと

が有効で、この場合は、重みを増やしてCephが書き込むデータを増やします。次の例では、ID 13の

OSDの重みを確認して、重みを3から3.05に変更します。

$ ceph osd tree | grep osd.13 13 3 osd.13 up 1

$ ceph osd crush reweight osd.13 3.05 reweighted item id 13 name 'osd.13' to 3.05 in crush map

$ ceph osd tree | grep osd.13 13 3.05 osd.13 up 1

ヒント: 使用率によるOSDの重みの変更ceph osd reweight-by-utilization thresholdコマンドは、きわめて過剰に使用されて

いるOSDの重みを下げるプロセスを自動化します。デフォルトでは、平均使用量が120%に達し

たOSDの重みが下方に調整されますが、しきい値が指定されている場合は、代わりにその割合

が使用されます。

18.5 /var/lib/cephのBtrfsサブボリュームSUSE Linux Enterpriseは、デフォルトでBtrfsパーティションにインストールされます。ディレクトリ /

var/lib/cephはBtrfsスナップショットおよびロールバックから除外する必要があります。これは特に

ノードでMONが実行されている場合に該当します。DeepSeaでは、このパスにサブボリュームを設定

できる fsランナが提供されています。

241 不均衡なデータ書き込みの確認 SES 5

18.5.1 新規インストールの要件

初めてクラスタを設定する場合、このDeepSeaランナを使用する前に、次の要件を満たす必要がありま

す。

SaltとDeepSeaがこのマニュアルに従って適切にインストールされていて動作している。

salt-run state.orch ceph.stage.0を起動して、SaltおよびDeepSeaのすべてのモジュー

ルをMinionに同期済みである。

Cephがまだインストールされておらず、そのためceph.stage.3がまだ実行されておらず、 /var/

lib/cephがまだ存在しない。

18.5.2 既存のインストールの要件

クラスタがすでにインストール済みの場合、このDeepSeaランナを使用する前に、次の要件を満たす必

要があります。

ノードがSUSE Enterprise Storageにアップグレードされていて、クラスタがDeepSeaによって

制御されている。

Cephクラスタが動作していて正常な状態である。

アップグレードプロセスによってSaltおよびDeepSeaのモジュールがすべてのMinionノードに同

期済みである。

18.5.3 自動セットアップ

Salt Masterで次のコマンドを実行します。

root@master # salt-run state.orch ceph.migrate.subvolume

このコマンドは、既存の /var/lib/cephディレクトリがないノードでは、次の処理を一度に1ノー

ドずつ実行します。

/var/lib/cephを @/var/lib/ceph Btrfsサブボリュームとして作成する。

新しいサブボリュームをマウントし、 /etc/fstabを適切に更新する。

/var/lib/cephのコピーオンライトを無効にする。

242 新規インストールの要件 SES 5

このコマンドは、Cephがすでにインストール済みのノードでは、次の処理を一度に1ノードずつ実

行します。

実行中のCephプロセスを終了する。

ノードのOSDをアンマウントする。

@/var/lib/ceph Btrfsサブボリュームを作成して、 /var/lib/cephの既存のデータを

移行する。

新しいサブボリュームをマウントし、 /etc/fstabを適切に更新する。

/var/lib/ceph/*のコピーオンライトを、 /var/lib/ceph/osd/*を除いて無効にする。

OSDを再マウントする。

Cephデーモンを再起動する。

18.5.4 手動セットアップ

これには新しい fsランナを使用します。

1. すべてのノードで /var/lib/cephの状態を検査し、どのように操作を続行するかについての提

案を出力します。

root@master # salt-run fs.inspect_var

次のいずれかのコマンドが返されます。

salt-run fs.create_varsalt-run fs.migrate_varsalt-run fs.correct_var_attrs

2. 前の手順で返されたコマンドを実行します。

いずれかのノードでエラーが発生した場合、他のノードに対する実行は停止され、ランナは実行

した手順を元に戻そうとします。問題があるMinionのログファイルを参照して、問題を判断しま

す。問題が解決したら、ランナを再実行できます。

コマンド salt-run fs.helpは、 fsモジュール用のランナおよびモジュールの全コマンドのリストを表

示します。

243 手動セットアップ SES 5

18.6 ファイル記述子の増加OSDデーモンでは、Cephクラスタの均衡を維持するために読み込み/書き込み操作が重要です。ほと

んどの場合、OSDデーモンは、読み込みおよび書き込み対象のファイルを同時に複数開いておく必要

があります。OSレベルでは、同時に開いているファイルの最大数を「ファイル記述子の最大数」と呼びま

す。

OSDでファイル記述子が不足するのを防ぐには、OSのデフォルト値を上書きして、 /etc/ceph/

ceph.confで数値を指定できます。次に例を示します。

max_open_files = 131072

max_open_filesを変更した後、関連するCephノードでOSDサービスを再起動する必要があります。

18.7 OSDジャーナルを含むOSDに既存のパーティションを使用する方法

重要このセクションでは、ストレージのエキスパートと開発者のみが検討する必要がある高度なト

ピックについて説明します。これは通常、標準のサイズではないOSDジャーナルを使用している

ときに必要になります。OSDパーティションのサイズが10GB未満の場合、その初期重みは0に

丸められます。これではデータが配置されないため、重みを増やす必要があります。満杯を超え

たジャーナルについては一切責任を負いません。

既存のディスクパーティションをOSDノードとして使用する必要がある場合、OSDジャーナルとデータ

パーティションはGPTパーティションテーブルに存在する必要があります。

OSDパーティションに正しいパーティションタイプを設定する必要があります。これは、 udevがパー

ティションを正しく認識して、所有権を ceph:cephに設定するようにするためです。

たとえば、ジャーナルパーティション /dev/vdb1およびデータパーティション /dev/vdb2のパーティ

ションタイプを設定するには、次のコマンドを実行します。

sudo sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/vdbsudo sgdisk --typecode=2:4fbd7e29-9d25-41b8-afd0-062c0ceff05d /dev/vdb

ヒントCephのパーティションテーブルのタイプは、 /usr/lib/udev/rules.d/95-ceph-

osd.rulesに一覧にされています。

244 ファイル記述子の増加 SES 5

cat /usr/lib/udev/rules.d/95-ceph-osd.rules# OSD_UUIDACTION=="add", SUBSYSTEM=="block", \ ENV{DEVTYPE}=="partition", \ ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \ OWNER:="ceph", GROUP:="ceph", MODE:="660", \ RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"ACTION=="change", SUBSYSTEM=="block", \ ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \ OWNER="ceph", GROUP="ceph", MODE="660"

# JOURNAL_UUIDACTION=="add", SUBSYSTEM=="block", \ ENV{DEVTYPE}=="partition", \ ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \ OWNER:="ceph", GROUP:="ceph", MODE:="660", \ RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"ACTION=="change", SUBSYSTEM=="block", \ ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \ OWNER="ceph", GROUP="ceph", MODE="660"[...]

18.8 仮想化ソフトウェアとの統合

18.8.1 CephクラスタへのKVMディスクの保存

KVMで動作する仮想マシンのディスクイメージを作成してCephプール内に保存し、オプションで既

存のイメージの内容をそのディスクイメージに変換できます。その後、 qemu-kvmを使用して、クラスタ

に保存したディスクイメージを利用して仮想マシンを実行できます。詳細については、第17章「QEMU

KVMインスタンスのバックエンドとしてのCephの使用」を参照してください。

18.8.2 Cephクラスタへのlibvirtディスクの保存

KVMの場合と同様に(18.8.1項「CephクラスタへのKVMディスクの保存」を参照)、Cephを使用し

て、 libvirtで動作する仮想マシンを保存できます。これには、KVM、Xen、LXCなど、 libvirtで

サポートされているあらゆる仮想化ソリューションを実行できるという利点があります。詳細について

は、第16章「Cephでのlibvirtの使用」を参照してください。

245 仮想化ソフトウェアとの統合 SES 5

18.8.3 CephクラスタへのXenディスクの保存

Cephを使用してXenディスクを保存する方法の1つは、第16章「Cephでのlibvirtの使用」で説明

されているように libvirtを利用する方法です。

Xenが rbd Block Deviceドライバと直接通信するようにするオプションもあります。

1. Xen用に準備されたディスクイメージがない場合は、新規に作成します。

rbd create myimage --size 8000 --pool mypool

2. プール mypool内のイメージを一覧にして、新しいイメージがそこに存在するかどうかを確認しま

す。

rbd list mypool

3. myimageイメージを rbdカーネルモジュールにマップすることにより、新しいBlock Deviceを作

成します。

sudo rbd map --pool mypool myimage

ヒント: ユーザ名と認証ユーザ名を指定するには、 --id user-nameを使用します。さらに、 cephx認証を使用す

る場合は、秘密も指定する必要があります。秘密は、キーリング、または秘密が含まれる

ファイルから取得できます。

sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

または

sudo rbd map --pool rbd myimage --id admin --keyfile /path/to/file

4. すべてのマップ済みデバイスを一覧にします。

rbd showmapped id pool image snap device 0 mypool myimage - /dev/rbd0

5. これで、このデバイスを仮想マシンとして実行するためのディスクとして使用するようXenを設定

できます。たとえば、 xl形式のドメイン設定ファイルに次の行を追加できます。

disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

246 CephクラスタへのXenディスクの保存 SES 5

18.9 Cephのファイアウォール設定

警告: ファイアウォールがアクティブな場合、DeepSeaのステージが失敗するファイアウォールがアクティブな場合(設定されていても)、DeepSeaの展開ステージが失敗しま

す。ステージを正しく実行するには、次のコマンドを実行してファイアウォールをオフにします。

root@master # systemctl stop SuSEfirewall2.service

または、 /srv/pillar/ceph/stack/global.ymlの FAIL_ON_WARNINGオプションを

「False」に設定します。

FAIL_ON_WARNING: False

ネットワーククラスタの通信をSUSE Firewallで保護することをお勧めします。この設定ファイルを編

集するには、［YaST］［Security and Users (セキュリティとユーザ)］［Firewall (ファイアウォー

ル)］［Allowed Services (許可するサービス)］を選択します。

次に、Ceph関連サービスと通常使用されるポートの番号のリストを示します。

Ceph Monitor

［Ceph MON］サービスまたはポート6789 (TCP)を有効にします。

Ceph OSDまたはMetadata Server

［Ceph OSD/MDS］サービスまたはポート6800〜7300 (TCP)を有効にします。

iSCSI Gateway

ポート3260 (TCP)を開きます。

Object Gateway

Object Gatewayが通信するポートを開きます。これは、 /etc/ceph.confの rgw frontends

=から始まる行で設定されています。デフォルトはHTTPの場合は80、HTTPSの場合は443

(TCP)です。

NFS Ganesha

デフォルトでは、NFS Ganeshaはポート2049 (NFSサービス、TCP)と875 (rquotaサポー

ト、TCP)を使用します。NFS Ganeshaのデフォルトポートの変更の詳細については、14.2.3項

「NFS Ganeshaのデフォルトポートの変更」を参照してください。

Apacheベースのサービス(openATTIC、SMT、SUSE Managerなど)

247 Cephのファイアウォール設定 SES 5

HTTPの場合はポート80、HTTPSの場合はポート443 (TCP)を開きます。

SSH


NTP

ポート123 (UDP)を開きます。

Salt

ポート4505および4506 (TCP)を開きます。

Grafana


Prometheus


18.10 ネットワークパフォーマンスのテストネットワークパフォーマンスをテストするために、DeepSeaの netランナは次のコマンドを提供していま

す。

すべてのノードに対する単純なping:

root@master # salt-run net.pingSucceeded: 9 addresses from 9 minions average rtt 1.35 ms

すべてのノードに対するジャンボping:

root@master # salt-run net.jumbo_pingSucceeded: 9 addresses from 9 minions average rtt 2.13 ms

帯域幅のテスト:

root@master # salt-run net.iperfFastest 2 hosts: |_ - 192.168.58.106 - 2981 Mbits/sec |_ - 192.168.58.107 - 2967 Mbits/secSlowest 2 hosts: |_

248 ネットワークパフォーマンスのテスト SES 5

- 192.168.58.102 - 2857 Mbits/sec |_ - 192.168.58.103 - 2842 Mbits/sec

18.11 ストレージディスクの交換Cephクラスタ内のストレージディスクを交換する必要がある場合、クラスタの完全な動作中に交換で

きます。交換を行うと、データ転送が一時的に増加します。

ディスクが完全に故障した場合、Cephは少なくとも、障害が発生したディスクの容量と同じ量のデータ

を再書き込みする必要があります。このプロセス中に冗長性が失われるのを避けるためにディスクを適

切に退避させて再追加する場合、再書き込みされるデータの量は2倍の大きさになります。新しいディ

スクと交換用ディスクのサイズが異なる場合、すべてのOSDの使用量を均一にするため、一部のデー

タが追加で再分散されます。

249 ストレージディスクの交換 SES 5

19 FAQ (よくある質問と答え)

19.1 配置グループの数はクラスタのパフォーマンスにどのように影響しますか?クラスタの使用率が70〜80%になったら、OSDを追加するタイミングです。OSDの数を増やす際には、

配置グループの数も増やすことを検討できます。

警告PGの数を変更すると、クラスタ内で大量のデータ転送が発生します。

新しくサイズ調整したクラスタに最適な値を計算するのは複雑なタスクです。

PGの数が多いと、小さいデータチャンクが作成されます。この場合、OSD障害後の回復は速くなります

が、データの場所の計算を担当するMonitorノードに多大な負荷がかかります。

一方、PGの数が少ないと、OSD障害からの回復にかかる時間とデータ転送は増加しますが、Monitor

ノードにそれほど負荷はかかりません。これは、Monitorノードが計算する必要があるデータチャンクの

場所の数が少ないためです(ただしデータチャンクの容量は大きくなります)。

オンライン計算ツール (http://ceph.com/pgcalc/) を使用して、クラスタに最適なPG数を特定して

ください。

19.2 同じクラスタでSSDとハードディスクを使用できますか?ソリッドステートドライブ(SSD)は一般にハードディスクより高速です。同じ書き込み操作に対して2種類

のディスクを混在させると、ハードディスクのパフォーマンスのためにSSDディスクへのデータ書き込み

速度が低下します。したがって、「同じルール」に従うデータ書き込みでは「SSDとハードディスクを混在

させない」でください(データの保存ルールの詳細については、6.3項「ルールセット」を参照してくださ

い)。

一般的に次の2つのケースでは、同じクラスタでSSDとハードディスクを使用することに意味がありま

す。

250 配置グループの数はクラスタのパフォーマンスにどのように影響しますか? SES 5

http://ceph.com/pgcalc/

1. 各ディスクタイプを異なるルールに従うデータ書き込みに使用する場合。この場合、SSDディスク

用の別個のルールを1つと、ハードディスク用のルールをもう1つ用意する必要があります。

2. 各ディスクタイプを特定の目的に使用する場合。たとえば、SSDディスクをジャーナルに使用し、

ハードディスクをデータの保存に使用する場合などです。

19.3 ジャーナルをSSDで使用することにはどのようなトレードオフがありますか?通常、ハードディスクのみのOSDではジャーナルがボトルネックになるため、OSDジャーナルにSSDを

使用するとパフォーマンスが向上します。SSDは、複数のOSDのジャーナルを共有するために使用さ

れることがよくあります。

次に、OSDジャーナルにSSDを使用することの潜在的な欠点のリストを示します。

SSDディスクはハードディスクより高価である。ただし、1つのOSDジャーナルに必要なディスク領

域は最大6GB程度なので、価格はそれほど問題にならない可能性があります。

本来であれば大容量ハードディスクで使用してクラスタ容量を拡張できるストレージスロットが

SSDディスクによって消費されてしまう。

SSDディスクはハードディスクと比べて書き込みサイクルが短いが、この問題は最新技術によっ

て解消され始めている。

同じSSDディスク上で共有するジャーナルを増やすと、SSDディスクの障害発生後にすべての関

連OSDが失われる危険があります。この場合、クラスタを再バランスするために大量のデータを

移動する必要があります。

障害が発生したOSDとジャーナルディスクのデータマッピングが1:1ではないため、ディスクの

ホットプラグが複雑になる。

19.4 ディスクに障害が発生すると、どうなりますか?クラスタデータが保存されているディスクがハードウェアの問題で動作しなくなった場合、次のような流

れになります。

251 ジャーナルをSSDで使用することにはどのようなトレードオフがありますか? SES 5

関連するOSDがクラッシュして、自動的にクラスタから削除されます。

障害ディスクのデータが、他のOSDに保存されている同じデータの別のコピーからクラスタ内の

別のOSDに複製されます。

その後、ディスクをクラスタのCRUSHマップから削除し、ホストハードウェアから物理的に取り外

す必要があります。

19.5 ジャーナルディスクに障害が発生すると、どうなりますか?ジャーナルや先書きログをOSDとは別のデバイスに保存するようCephを設定できます。ジャーナル専

用ディスクに障害が発生した場合、関連するOSDにも障害が発生します(19.4項「ディスクに障害が

発生すると、どうなりますか?」を参照してください)。

警告: 1台のディスクでの複数ジャーナルのホストパフォーマンスを向上させるため、高速なディスク(SSDなど)を使用して、複数のOSDのジャー

ナルパーティションを保存できます。1台のディスクで5つ以上のOSDのジャーナルをホストする

ことはお勧めしません。なぜなら、ジャーナルのディスクに障害が発生した場合、関連するOSD

の全ディスクの保存データが失われる危険があるためです。

252 ジャーナルディスクに障害が発生すると、どうなりますか? SES 5

20 トラブルシューティング

この章では、Cephクラスタの操作時に発生する可能性があるいくかの問題について説明します。

20.1 ソフトウェアの問題のレポートSUSE Enterprise Storageの実行中に、CephやObject Gatewayなど、そのコンポーネントに

関連する問題が発生した場合は、SUSEテクニカルサポートに問題をレポートしてください。その

際、 supportconfigユーティリティを使用する方法をお勧めします。

ヒントsupportconfigはモジュラソフトウェアであるため、 supportutils-plugin-sesパッケージ

がインストールされていることを確認してください。

rpm -q supportutils-plugin-ses

これがCephサーバにインストールされていない場合は、次のコマンドを使用してインストールし

ます。

zypper ref && zypper in supportutils-plugin-ses

supportconfigはコマンドラインで使用できますが、関連するYaSTモジュールを使用することをお勧

めします。 supportconfigの詳細については、https://www.suse.com/documentation/sles-12/

singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig を参照


20.2 満杯のOSDにおいてradosを使用した大容量オブジェクトの送信に失敗するradosは、RADOS Object Storageを管理するためのコマンドラインユーティリティです。詳細につい

ては、 man 8 radosを参照してください。

次のように、 radosユーティリティを使用して、大容量オブジェクトをCephクラスタに送信するとしま

す。

253 ソフトウェアの問題のレポート SES 5

https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig

https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig

rados -p mypool put myobject /file/to/send

これによって、関連するOSDの全領域がいっぱいになり、クラスタのパフォーマンスに深刻な問題が発

生する可能性があります。

20.3 XFSファイルシステムの破損カーネルのバグやハードウェアの破損/設定ミスなどのまれな状況では、OSDがデータを保存する基礎

となるファイルシステム(XFS)が損傷したりアンマウント不能になったりすることがあります。

ハードウェアに問題がなく、システムが適切に設定されていることがわかっている場合は、SUSE

Linux Enterprise ServerカーネルのXFSサブシステムに対してバグを発生させて、該当する特定の

OSDにダウン状態を示すマークを付けることができます。

ceph osd down OSD identification

警告: 損傷したデバイスが変更されるため、フォーマットはしないxfs_repairを使用してファイルシステムの問題を修復するのが適切に思われるかもしれませ

んが、このコマンドはファイルシステムを変更するので使用しないでください。OSDは起動します

が、その機能が影響を受ける場合があります。

続いて、基礎となるディスクを消去し、次のコマンドを実行してOSDを再作成します。

ceph-disk prepare --zap $OSD_DISK_DEVICE $OSD_JOURNAL_DEVICE"


ceph-disk prepare --zap /dev/sdb /dev/sdd2

20.4 状態メッセージ「Too Many PGs per OSD」ceph statusの実行後に「 Too Many PGs per OSD 」というメッセージが表示される場

合、 mon_pg_warn_max_per_osdの値(デフォルトは300)を超えていることを意味します。この値

は、OSDあたりのPG数の比率と比較されています。つまり、クラスタセットアップが最適ではありませ

ん。

プールの作成後にPGの数を減らすことはできません。まだデータが含まれていないプールは削除して

も問題なく、その後、より少ない数のPGで再作成できます。プールにすでにデータが含まれる場合、唯

一の解決策は、クラスタにOSDを追加し、OSDあたりのPGの比率を下げることです。

254 XFSファイルシステムの破損 SES 5

20.5 状態メッセージ「nn pg stuck inactive」ceph statusの実行後に状態メッセージ「 stuck inactive 」が表示される場合、Cephが保存デー

タを複製する場所を認識できないため、レプリケーションルールを満足できないことを意味します。これ

は、Cephの初期セットアップ直後に発生し、自動的に自動修復される可能性があります。その他の場

合、壊れたOSDをオンラインに戻す、新しいOSDをクラスタに追加するなどの手動操作が必要になるこ

とがあります。きわめてまれなケースでは、レプリケーションレベルを下げると有効な場合があります。

配置グループが完全にスタックしている場合は、 ceph osd treeの出力を確認する必要があります。

この出力は、20.7項「OSDがダウンしている」の例のようなツリー構造で表示される必要があります。

ceph osd treeの出力が次の例のようにフラットな場合があります。

ceph osd treeID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY-1 0 root default 0 0 osd.0 up 1.00000 1.00000 1 0 osd.1 up 1.00000 1.00000 2 0 osd.2 up 1.00000 1.00000

この場合、関連するCRUSHマップがツリー構造になっていることを確認する必要があります。これもフ

ラットである場合、または上の例のようにホストがない場合、クラスタ全体でホスト名解決が正しく機能

していないことを意味することがあります。

たとえば、ルートにホストが含まれているにもかかわらず、OSDが最上位レベルに存在していてホストが

割り当てられていないなど、階層が間違っている場合、OSDを階層内の正しい場所に移動する必要が

あります。これを実行するには、 ceph osd crush moveまたは ceph osd crush set 、あるいはその

両方のコマンドを使用します。詳細については、6.4項「CRUSHマップの操作」を参照してください。

20.6 OSDの重みが0OSDには起動時に重みが割り当てられます。重みが大きいほど、クラスタがそのOSDに書き込む可能

性が高くなります。重みは、クラスタのCRUSHマップで指定するか、OSDの起動スクリプトによって計

算されます。

場合によっては、OSDの重みの計算値がゼロに切り捨てられることがあります。つまり、そのOSDは

データを保存するようスケジュールされておらず、データは一切書き込まれません。一般的には、ディス

クが小さすぎて(15GB未満)、より容量の大きいディスクに交換する必要があることがその理由です。

255 状態メッセージ「nn pg stuck inactive」 SES 5

20.7 OSDがダウンしているOSDデーモンは、実行中か、停止/ダウンのいずれかです。OSDがダウンしている理由は、一般的に次

の3つです。

ハードディスクの障害。

OSDがクラッシュした。

サーバがクラッシュした。

次のコマンドを実行することによって、OSDの詳しい状態を確認できます。

ceph osd tree# id weight type name up/down reweight -1 0.02998 root default -2 0.009995 host doc-ceph1 0 0.009995 osd.0 up 1 -3 0.009995 host doc-ceph2 1 0.009995 osd.1 up 1 -4 0.009995 host doc-ceph3 2 0.009995 osd.2 down 1

このリストの例は、 osd.2がダウンしていることを示しています。これに従って、そのOSDが配置されて

いるディスクがマウントされているかどうかを確認できます。

lsblk -f [...] vdb ├─vdb1 /var/lib/ceph/osd/ceph-2 └─vdb2

ログファイル /var/log/ceph/ceph-osd.2.logを調べることにより、OSDがダウンしている理由を追

跡できます。OSDが動作していない理由を特定して修復したら、次のコマンドを使用してOSDを起動し

ます。


2は必ず、停止しているOSDの実際の番号に置き換えてください。

20.8 低速なOSDの特定クラスタのパフォーマンスを調整する場合、クラスタ内の低速なストレージ/OSDを特定することが非常

に重要です。その理由は、(最も)低速なディスクにデータが書き込まれた場合、すべての関連ディスクで

操作が完了するまで常に書き込み操作が待機することになり、書き込み操作全体が低速化するためで

す。

256 OSDがダウンしている SES 5

ストレージのボトルネックの特定は容易ではありません。すべてのOSDを調べて、書き込みプロセスを

低速化させているOSDを特定する必要があります。1つのOSDでベンチマークを実行するには、次のコ

マンドを実行します。

ceph tell osd.OSD_ID_NUMBER bench


root # ceph tell osd.0 bench { "bytes_written": 1073741824, "blocksize": 4194304, "bytes_per_sec": "19377779.000000"}

その後、各OSDでこのコマンドを実行し、 bytes_per_secの値を比較して、(最も)低速なOSDを把握

する必要があります。

20.9 クロックスキュー警告の修復すべてのクラスタノードの時刻情報が同期されている必要があります。ノードの時刻が完全には同期し

ていない場合、クラスタの状態を確認するとクロックスキューの警告が表示されることがあります。

時刻同期はNTPで管理します(http://en.wikipedia.org/wiki/Network_Time_Protocol を参照

してください)。1つ以上のNTPサーバ、できれば同じグループの複数のNTPサーバと時刻を同期する

ように各ノードを設定します。これでもまだノードで時間スキューが発生する場合は、次の手順に従って

修復します。

systemctl stop ntpd.servicesystemctl stop ceph-mon.targetsystemctl start ntpd.servicesystemctl start ceph-mon.target

その後、NTPピアに問い合わせて、 sudo ntpq -pを使用してタイムオフセットを確認できます。

Ceph Monitorでは、クロックがお互いに0.05秒未満に同期されている必要があります。詳細について

は、18.3項「ノードの時刻同期」を参照してください。

20.10 ネットワークの問題によるクラスタの低パフォーマンスクラスタのパフォーマンスの低下には、さまざまな理由があります。その1つとして考えられるのがネット

ワークの問題です。このような場合、クラスタが定数に達している、OSDおよびMonitorノードがオフラ

インになっている、データ転送に長時間かかる、大量の再接続試行といった症状が発生している可能

性があります。

257 クロックスキュー警告の修復 SES 5

http://en.wikipedia.org/wiki/Network_Time_Protocol

クラスタのパフォーマンスがネットワークの問題が原因で低下しているかどうかを確認するには、 /var/

log/cephディレクトリにあるCephのログファイルを調べます。

クラスタのネットワークの問題を修復するには、次の点に焦点を当てます。

基本的なネットワーク診断。DeepSeaの診断ツールランナ net.pingを実行してクラスタノード間

でpingを送信し、個々のインタフェースが特定のインタフェースに接続できるかどうかと、その平

均応答時間を確認します。平均よりも大幅に遅い特定の応答時間もレポートされます。次に例を

示します。

root@master # salt-run net.ping Succeeded: 8 addresses from 7 minions average rtt 0.15 ms

ジャンボフレームを有効にして、すべてのインタフェースを検証します。

root@master # salt-run net.jumbo_ping Succeeded: 8 addresses from 7 minions average rtt 0.26 ms

ネットワークパフォーマンスのベンチマーク。DeepSeaのネットワークパフォーマンスラン

ナ net.iperfを実行して、ノード間のネットワーク帯域幅をテストします。指定したクラスタノード

上で、多数の iperfプロセス(CPUコアの数による)がサーバとして起動されます。残りのクラスタ

ノードは、ネットワークトラフィックを生成するためのクライアントとして使用されます。各ノードのす

べての iperfプロセスの累積帯域幅がレポートされます。これには、すべてのクラスタノード上で

達成可能な最大ネットワークスループットが反映されています。次に例を示します。

root@master # salt-run net.iperf cluster=ceph output=full192.168.128.1: 8644.0 Mbits/sec192.168.128.2: 10360.0 Mbits/sec192.168.128.3: 9336.0 Mbits/sec192.168.128.4: 9588.56 Mbits/sec192.168.128.5: 10187.0 Mbits/sec192.168.128.6: 10465.0 Mbits/sec

クラスタノードのファイアウォール設定を確認します。Cephの操作に必要なポート/プロトコルが

ファイアウォールによってブロックされていないことを確認します。ファイアウォール設定の詳細に

ついては、18.9項「Cephのファイアウォール設定」を参照してください。

ネットワークカード、ケーブル、スイッチなどのネットワーキングハードウェアが適切に動作している

ことを確認します。

258 ネットワークの問題によるクラスタの低パフォーマンス SES 5

ヒント: 別個のネットワーククラスタノード間で高速かつ安全にネットワーク通信を行うには、クラスタのOSDノードおよび

Monitorノード専用の別個のネットワークを設定します。

20.11 /varの領域不足デフォルトでは、Salt Masterは、すべてのジョブに対するすべてのMinionの戻り値を「ジョブキャッ

シュ」に保存します。これにより、後でこのキャッシュを使用して、前のジョブの結果を検索できます。

キャッシュディレクトリは、デフォルトでは /var/cache/salt/master/jobs/です。

すべてのMinionからの各ジョブ戻り値が1つのファイルに保存されます。発行されるジョブの数と、 /

etc/salt/masterファイルの keep_jobsオプションの値によっては、時間が経つに連れてこのディレ

クトリが非常に大きくなる可能性があります。 keep_jobsは、Minionの過去のジョブに関する情報を

保持する時間数(デフォルトは24)を設定します。

keep_jobs: 24

重要: keep_jobs: 0は設定しないkeep_jobsを「0」に設定すると、ジョブキャッシュクリーナが「実行されない」ため、パーティショ

ンが満杯になる可能性があります。

ジョブキャッシュを無効にする場合は、 job_cacheを「False」に設定します。

job_cache: False

ヒント: ジョブキャッシュが原因で満杯になったパーティションの復元間違った keep_jobs設定のために、ジョブキャッシュファイルが含まれるパーティションが満杯

になった場合、次の手順に従ってディスク領域を解放し、ジョブキャッシュ設定を改善します。

1. Salt Masterサービスを停止します。

root@master # systemctl stop salt-master

2. /etc/salt/masterを変更することによって、ジョブキャッシュに関連するSalt Master

設定を変更します。

259 /varの領域不足 SES 5

job_cache: Falsekeep_jobs: 1

3. Salt Masterのジョブキャッシュを消去します。

rm -rfv /var/cache/salt/master/jobs/*

4. Salt Masterサービスを起動します。

root@master # systemctl start salt-master

260 /varの領域不足 SES 5

用語集

全般

CRUSH、CRUSHマップデータの保存場所を計算することによって、データの保存と取得の方法を決定するアルゴリズ

ム。CRUSHは、クラスタ全体に均等に分散したデータを擬似ランダムにOSDで保存および取得す

るために、クラスタのマップを必要とします。

Monitorノード、MONクラスタの状態のマップ(Monitorマップを含む)またはOSDマップを維持するクラスタノード。

OSDノードデータの保存、データレプリケーションの処理、回復、バックフィル、およびリバランスを実行し、他の

Ceph OSDデーモンを確認することによってCeph Monitorにモニタリング情報を提供するクラス

タノード。

ノードCephクラスタ内の1つのマシンまたはサーバ。

バケット他のノードを物理的な場所の階層に集約するポイント。

プールディスクイメージなどのオブジェクトを保存するための論理パーティション。

ルールセットプールのデータ配置を決定するためのルール。

管理ノードOSDノードにCephを展開するために ceph-deployユーティリティを実行するノード。

261 SES 5

Ceph固有の用語

Ceph Storage Clusterユーザのデータを保存するストレージソフトウェアのコアセット。1つのセットは複数のCeph

Monitorと複数のOSDで構成されます。

「Ceph Object Store」とも呼ばれます。

Object GatewayCeph Object Store用のS3/Swiftゲートウェイコンポーネント。

262 SES 5

A Cephの手動インストールの手順例

次の手順では、Ceph Storage Clusterを手動でインストールする場合に必要なコマンドについて説明

します。

1. 実行する予定のCephサービスに対してキーの秘密を生成します。これは次のコマンドを使用し

て生成できます。

python -c "import os ; import struct ; import time; import base64 ; \ key = os.urandom(16) ; header = struct.pack('<hiih',1,int(time.time()),0,len(key)) ; \ print base64.b64encode(header + key)"

2. 関連するキーリングにキーを追加します。最初に client.admin 、次にMonitor、その後で他の

関連サービス(OSD、Object Gateway、MDSなど)の順に追加します。

ceph-authtool -n client.admin \ --create-keyring /etc/ceph/ceph.client.admin.keyring \ --cap mds 'allow *' --cap mon 'allow *' --cap osd 'allow *'ceph-authtool -n mon. \ --create-keyring /var/lib/ceph/bootstrap-mon/ceph-osceph-03.keyring \ --set-uid=0 --cap mon 'allow *'ceph-authtool -n client.bootstrap-osd \ --create-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring \ --cap mon 'allow profile bootstrap-osd'ceph-authtool -n client.bootstrap-rgw \ --create-keyring /var/lib/ceph/bootstrap-rgw/ceph.keyring \ --cap mon 'allow profile bootstrap-rgw'ceph-authtool -n client.bootstrap-mds \ --create-keyring /var/lib/ceph/bootstrap-mds/ceph.keyring \ --cap mon 'allow profile bootstrap-mds'

3. monmap (クラスタ内にあるすべてのMonitorのデータベース)を作成します。

monmaptool --create --fsid eaac9695-4265-4ca8-ac2a-f3a479c559b1 \ /tmp/tmpuuhxm3/monmapmonmaptool --add osceph-02 192.168.43.60 /tmp/tmpuuhxm3/monmapmonmaptool --add osceph-03 192.168.43.96 /tmp/tmpuuhxm3/monmapmonmaptool --add osceph-04 192.168.43.80 /tmp/tmpuuhxm3/monmap

4. 新しいキーリングを作成し、そこに管理者およびMonitorのキーリングからキーをインポートしま

す。続いて、それらのキーを使用してMonitorを起動します。

ceph-authtool --create-keyring /tmp/tmpuuhxm3/keyring \ --import-keyring /var/lib/ceph/bootstrap-mon/ceph-osceph-03.keyringceph-authtool /tmp/tmpuuhxm3/keyring \

263 SES 5

--import-keyring /etc/ceph/ceph.client.admin.keyringsudo -u ceph ceph-mon --mkfs -i osceph-03 \ --monmap /tmp/tmpuuhxm3/monmap --keyring /tmp/tmpuuhxm3/keyringsystemctl restart ceph-mon@osceph-03

5. systemdでMonitorの状態を確認します。

systemctl show --property ActiveState ceph-mon@osceph-03

6. Cephが実行されていて、Monitorの状態をレポートするかどうかを確認します。

ceph --cluster=ceph \ --admin-daemon /var/run/ceph/ceph-mon.osceph-03.asok mon_status

7. 既存のキーを使用して、特定のサービスの状態を確認します。

ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin -f json-pretty status[...]ceph --connect-timeout 5 \ --keyring /var/lib/ceph/bootstrap-mon/ceph-osceph-03.keyring \ --name mon. -f json-pretty status

8. 既存のCephサービスからキーリングをインポートして、状態を確認します。

ceph auth import -i /var/lib/ceph/bootstrap-osd/ceph.keyringceph auth import -i /var/lib/ceph/bootstrap-rgw/ceph.keyringceph auth import -i /var/lib/ceph/bootstrap-mds/ceph.keyringceph --cluster=ceph \ --admin-daemon /var/run/ceph/ceph-mon.osceph-03.asok mon_statusceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin -f json-pretty status

9. XFSファイルシステムを使用して、OSD用のディスク/パーティションを準備します。

ceph-disk -v prepare --fs-type xfs --data-dev --cluster ceph \ --cluster-uuid eaac9695-4265-4ca8-ac2a-f3a479c559b1 /dev/vdbceph-disk -v prepare --fs-type xfs --data-dev --cluster ceph \ --cluster-uuid eaac9695-4265-4ca8-ac2a-f3a479c559b1 /dev/vdc[...]

10. パーティションを有効にします。

ceph-disk -v activate --mark-init systemd --mount /dev/vdb1ceph-disk -v activate --mark-init systemd --mount /dev/vdc1

11. SUSE Enterprise Storageバージョン2.1以前では、デフォルトのプールを作成します。

264 SES 5

ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .users.swift 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .intent-log 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .rgw.gc 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .users.uid 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .rgw.control 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .users 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .usage 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .log 16 16ceph --connect-timeout 5 --keyring /etc/ceph/ceph.client.admin.keyring \ --name client.admin osd pool create .rgw 16 16

12. ブートストラップキーからObject Gatewayのインスタンスを作成します。

ceph --connect-timeout 5 --cluster ceph --name client.bootstrap-rgw \ --keyring /var/lib/ceph/bootstrap-rgw/ceph.keyring auth get-or-create \ client.rgw.0dc1e13033d2467eace46270f0048b39 osd 'allow rwx' mon 'allow rw' \ -o /var/lib/ceph/radosgw/ceph-rgw.rgw_name/keyring

13. Object Gatewayを有効にして起動します。

systemctl enable [email protected]_namesystemctl start [email protected]_name

14. オプションで、ブートストラップキーからMDSインスタンスキーを作成し、有効にして起動します。

ceph --connect-timeout 5 --cluster ceph --name client.bootstrap-mds \ --keyring /var/lib/ceph/bootstrap-mds/ceph.keyring auth get-or-create \ mds.mds.rgw_name osd 'allow rwx' mds allow mon \ 'allow profile mds' \ -o /var/lib/ceph/mds/ceph-mds.rgw_name/keyringsystemctl enable [email protected]_namesystemctl start [email protected]_name

265 SES 5

B マニュアルの更新

この章では、SUSE Enterprise Storage 1の初期リリース以降に、このドキュメントの内容に加えられ

た変更点を一覧にします。

このドキュメントは次の日付に更新されました。

B.1項「2018年9月(SUSE Enterprise Storage 5.5のリリース)」

B.2項「2017年11月(マニュアル保守更新)」

B.3項「2017年10月(SUSE Enterprise Storage 5のリリース)」

B.4項「2017年2月(SUSE Enterprise Storage 4 Maintenance Update 1のリリース)」



B.7項「2016年1月(SUSE Enterprise Storage 2.1のリリース)」


B.1 2018年9月(SUSE Enterprise Storage 5.5のリリース)

全般的な更新

15.4.3項「RADOS RBD (RADOS Block Device)の管理」を拡張し、主にスナップショット

に関するセクションを追加しました(Fate#325642)。

7.3項「プールのマイグレーション」を追加しました(Fate#322006)。

3.2項「DeepSeaを使用したCephのサービスの再起動」を第3章「Cephのサービスの操

作」に挿入しました。

バグ修正

1.7項「再インストールしたOSDノードの回復」 https://bugzilla.suse.com/

show_bug.cgi?id=1095937 で、 saltに state.applyの部分を追加しました。

15.1.1項「SSLを使用したopenATTICへの安全なアクセスの有効化」 https://

bugzilla.suse.com/show_bug.cgi?id=1083216 を追加しました。

266 2018年9月(SUSE Enterprise Storage 5.5のリリース) SES 5

https://bugzilla.suse.com/show_bug.cgi?id=1095937




11.12項「HAProxyによるObject Gatewayサーバの負荷分散」 https://

bugzilla.suse.com/show_bug.cgi?id=1093513 を追加しました。

6.6項「同一ノードでのSSDとHDDの混在」 https://bugzilla.suse.com/

show_bug.cgi?id=1093583 で、 ceph.confのカスタマイズに関する情報を更新しま

した。

6.5項「スクラブ」 https://bugzilla.suse.com/show_bug.cgi?id=1079256 を追加

しました。

18.9項「Cephのファイアウォール設定」 https://bugzilla.suse.com/show_bug.cgi?

id=1070087 で、ファイアウォール設定のポートリストを強化しました。

3.2.2項「特定のサービスの再起動」 https://bugzilla.suse.com/show_bug.cgi?

id=1091075 に、DeepSeaのバージョンによって起動される役割が異なることの説明を

追加しました。

1.4項「Monitorノードの再展開」 https://bugzilla.suse.com/show_bug.cgi?

id=1038731 を追加しました。

11.9.1.1項「動的リシャーディング」 https://bugzilla.suse.com/show_bug.cgi?

id=1076001 を追加しました。

11.9項「バケットインデックスのシャーディング」 https://bugzilla.suse.com/

show_bug.cgi?id=1076000 を追加しました。

11.6項「Object GatewayでのHTTPS/SSLの有効化」で、Object Gatewayの

SSLをDeepSea形式に更新しました(https://bugzilla.suse.com/show_bug.cgi?

id=1083756 およびhttps://bugzilla.suse.com/show_bug.cgi?id=1077809 )。

DeepSeaの変更により、NFS GaneshaとObject Gatewayの展開を変更する必要があ

ります。14.3.1項「NFS Ganesha用の異なるObject Gatewayユーザ」を参照してくだ

さい(https://bugzilla.suse.com/show_bug.cgi?id=1058821 )。OSDあたりの配

置グループ数の制限を超えている場合、 ceph osd pool createは失敗します。7.2.2

項「プールの作成」を参照してください(https://bugzilla.suse.com/show_bug.cgi?

id=1076509 )。

1.7項「再インストールしたOSDノードの回復」を追加しました(https://

bugzilla.suse.com/show_bug.cgi?id=1057764 )。

1.12項「Cephランタイム設定」に信頼性の警告を追加しました(https://


11.2項「Object Gatewayの展開」を追加しました(https://bugzilla.suse.com/

show_bug.cgi?id=1088895 )。





























7.5.3項「グローバル圧縮オプション」で、圧縮アルゴリズムのリストから lz4を削除しまし

た(https://bugzilla.suse.com/show_bug.cgi?id=1088450 )。

1.6項「OSDの削除」に、複数のOSDを削除する場合のヒントを追加しました(https://


18.2項「リバランスなしでのOSDの停止」を追加しました(https://bugzilla.suse.com/


『導入ガイド』、第11章「CephFSのインストール」、11.2.2項「Metadata Serverの設

定」に、MDSキャッシュサイズの設定可能値を追加しました(https://bugzilla.suse.com/


11.10項「OpenStack Keystoneの統合」を追加しました(https://bugzilla.suse.com/


『導入ガイド』、第10章「iSCSI Gatewayのインストール」、10.4.3項「iSCSI経由でのRBD

イメージのエクスポート」に、iSCSI Gateway設定の同期に関するヒントを追加しました

(https://bugzilla.suse.com/show_bug.cgi?id=1073327 )。

DeepSeaの変更により、NFS GaneshaとObject Gatewayの展開を変更する必要があり

ます。14.3.1項「NFS Ganesha用の異なるObject Gatewayユーザ」を参照してください


B.2 2017年11月(マニュアル保守更新)

全般的な更新

18.11項「ストレージディスクの交換」を追加しました(Fate#321032)。

バグ修正

9.4項「イレージャコーディングプールとRADOS Block Device」を追加しました(https://


OSDノードへのディスクの追加に関するセクションを追加しました。1.5項「ノードへ

のOSDの追加」を参照してください(https://bugzilla.suse.com/show_bug.cgi?

id=1066005 )。

salt-run remove.osdには、OSD_IDの数字を、先行の osd.を除いて指定する必要が

あります。詳細については、1.6項「OSDの削除」を参照してください。

268 2017年11月(マニュアル保守更新) SES 5
















ceph tellには、OSD_IDの数字と先行の osd.を指定する必要があります。詳細につい

ては、20.8項「低速なOSDの特定」を参照してください。

20.11項「/varの領域不足」を追加しました(https://bugzilla.suse.com/


11.1項「Object Gatewayの制約と命名の制限」を追加しました(https://


8.5.1項「rbd-mirrorデーモン」で、rbd-mirrorの起動および停止のコマンドを修正しまし


B.3 2017年10月(SUSE Enterprise Storage 5のリリース)

全般的な更新

Calamariを削除して、代わりにopenATTICを推奨するようにしました。

15.4.6項「NFS Ganeshaの管理」を追加しました(Fate#321620)。

8.4項「rbdmap: ブート時のRBDデバイスのマップ」を追加しました。

第8章「RADOS Block Device」を追加しました(Fate#321061)。

15.4.9項「Object Gatewayのユーザとバケットの管理」を追加しました

(Fate#320318)。

11.8項「LDAP認証」を追加しました(Fate#321631)。

13.4項「複数のアクティブMDSデーモン(アクティブ-アクティブMDS)」を追加しました

(Fate#322976)。

15.4.7項「iSCSI Gatewayの管理」を追加しました(Fate#321370)。

iSCSI GatewayおよびObject GatewayのopenATTIC用の設定を追加しまし

た。15.1.5項「Object Gateway管理」および15.1.6項「iSCSI Gateway管理」を参照し

てください(Fate#320318および#321370)。

第14章「NFS Ganesha: NFS経由でのCephデータのエクスポート」を更新しま

した(https://bugzilla.suse.com/show_bug.cgi?id=1036495 、https://


269 2017年10月(SUSE Enterprise Storage 5のリリース) SES 5









RBDイメージをECプールに保存できるようになりました。8.1.2項「イレージャコー

ディングプールでのBlock Deviceイメージの作成」を参照してください(https://


DeepSea設定のバックアップに関するセクションを追加しました。『導入ガイド』、第6

章「クラスタ設定のバックアップ」を参照してください(https://bugzilla.suse.com/


Object Gatewayのフェールオーバーと障害復旧。11.11.12項「フェールオーバー

と障害復旧」を参照してください(https://bugzilla.suse.com/show_bug.cgi?

id=1036084 )。

BlueStoreではプールのデータ圧縮が可能です。7.5項「データ圧縮」を参照してください

(FATE#318582)。

CephFSのCIFSエクスポートが可能です。『導入ガイド』、第13章「Sambaを介した

CephFSのエクスポート」を参照してください(FATE#321622)。

クラスタの再起動手順を追加しました。1.10項「クラスタの停止または再起動」を参照して

ください(https://bugzilla.suse.com/show_bug.cgi?id=1047638 )。

DeepSeaステージ0は再起動なしで更新できます。1.9項「クラスタノードの更新」を参照


ceph fsを置き換えました。13.4.3項「ランク数の減少」および13.4.2項「MDSの

アクティブクラスタサイズの増加」を参照してください(https://bugzilla.suse.com/


セクション18.10項「ネットワークパフォーマンスのテスト」を追加しました

(FATE#321031)。

バグ修正

6.6項「同一ノードでのSSDとHDDの混在」で、コマンド出力を更新してストレージクラスを

反映しました(https://bugzilla.suse.com/show_bug.cgi?id=1061299 )。

11.5.1項「Object Gatewayへのアクセス」に、swiftクライアントパッケージが

「Public Cloud」モジュールの一部になったことの説明を追加しました(https://


1.12項「Cephランタイム設定」を追加しました(https://bugzilla.suse.com/


6.6項「同一ノードでのSSDとHDDの混在」で、コマンドを設定オプションに変更しました


















6.6項「同一ノードでのSSDとHDDの混在」で、 ceph osd pool setコマンド

を、Luminousの構文に一致するように更新しました(https://bugzilla.suse.com/


ヒント: 複数のポートへのバインドに、CivetWebは複数のポートにバインドされることの説

明を追加しました(https://bugzilla.suse.com/show_bug.cgi?id=1055181 )。

11.4項「設定パラメータ」に、パフォーマンスに影響する3つObject Gatewayオプション

を追加しました(https://bugzilla.suse.com/show_bug.cgi?id=1052983 )。

1.11項「カスタムのceph.confファイル」をインポートし、ステージ3が必要であることの説

明を追加しました(https://bugzilla.suse.com/show_bug.cgi?id=1057273 )。

16.1項「Cephの設定」に、libvirtのキーリングの作成を追加しました(https://


例1.1「クラスタからのSalt Minionの削除」を追加しました(https://bugzilla.suse.com/


4.2項「クラスタの監視」を更新しました(https://bugzilla.suse.com/show_bug.cgi?

id=1053638 )。

15.1項「openATTICの展開と設定」で、Salt REST API変数をオプションに変更しま

した(https://bugzilla.suse.com/show_bug.cgi?id=1054748 およびhttps://


15.1.3項「openATTICの初期セットアップ」で、 oaconfig installを削除しました


7.1項「プールとアプリケーションの関連付け」に、プールのメタデータの表示に関するセク

ションを追加しました(https://bugzilla.suse.com/show_bug.cgi?id=1053327 )。

4.1項「クラスタのヘルスの確認」に、ヘルスコードのリストをインポートしました(https://


15.4.9.1項「新しいObject Gatewayユーザの追加」および15.4.9.3項「Object

Gatewayユーザの編集」で、スクリーンショットと関連テキストを更新しました

(https://bugzilla.suse.com/show_bug.cgi?id=1051814 およびhttps://


15.4.9項「Object Gatewayのユーザとバケットの管理」に、Object Gatewayのバケット

を追加しました(https://bugzilla.suse.com/show_bug.cgi?id=1051800 )。

13.1.3項「CephFSのマウント」で、マウントの例にcephxを含めました(https://



























7.2.4項「プールの削除」で、プールの削除の説明を更新および向上しました(https://


7.5.2項「プール圧縮オプション」に、圧縮アルゴリズムの説明を追加しました(https://


20.10項「ネットワークの問題によるクラスタの低パフォーマンス」で、ネットワーク診

断とベンチマークを置き換えました(https://bugzilla.suse.com/show_bug.cgi?

id=1050190 )。

20.5項「状態メッセージ「nn pg stuck inactive」」を拡張しました(https://


20.4項「状態メッセージ「Too Many PGs per OSD」」に、プールの再作成について記載

しました(https://bugzilla.suse.com/show_bug.cgi?id=1050178 )。

『導入ガイド』、第9章「Ceph Object Gateway」、9.1項「Object Gatewayの手

動インストール」で、 ceph.confのRGWのセクション名を修正しました(https://


4.3項「クラスタの使用量統計の確認」および4.2項「クラスタの監視」で、コマンド出力を

更新しました(https://bugzilla.suse.com/show_bug.cgi?id=1050175 )。

4.1項「クラスタのヘルスの確認」で、予防に関するHEALTCH_WARNセクションを削除

しました(https://bugzilla.suse.com/show_bug.cgi?id=1050174 )。

11.5.2.1項「S3およびSwiftユーザの追加」で、sudoを修正しました(https://


20.2項「満杯のOSDにおいてradosを使用した大容量オブジェクトの送信に失敗

する」で、RADOS striperへの参照を削除しました(https://bugzilla.suse.com/


19.5項「ジャーナルディスクに障害が発生すると、どうなりますか?」で、ジャーナル障

害によるOSD障害に関するセクションを向上しました(https://bugzilla.suse.com/


1.9項「クラスタノードの更新」に、ステージ0中の zypper patchに関するヒントを追加し

ました(https://bugzilla.suse.com/show_bug.cgi?id=1050165 )。

7.1項「プールとアプリケーションの関連付け」を追加しました(https://


20.9項「クロックスキュー警告の修復」で、時刻同期情報を向上しました(https://



























「イレージャプール」を正しい「イレージャコーディングプール」に置き換えました(https://


rccephを systemctlに置き換えました(https://bugzilla.suse.com/show_bug.cgi?

id=1050111 )。

13.1.1項「クライアントの準備」で、CephFSのマウント準備を更新しました(https://


16.1項「Cephの設定」で、 qemu-imgコマンドを修正しました(https://


1.3項「クラスタノードの削除と再インストール」で、役割を削除する際に実行する

DeepSeaステージを指定しました(https://bugzilla.suse.com/show_bug.cgi?

id=1047430 )。

DeepSeaの新しい役割であるCeph Managerを追加しました(https://


13.1.1項「クライアントの準備」で、12 SP3に合わせて導入部を調整しました(https://


16.4項「VMの設定」で、XMLエンティティのタイプミスを修正しました(https://


1.3項「クラスタノードの削除と再インストール」に、役割を削除するためにDeepSea

ステージ2〜5を再実行する場合の情報を追加しました(https://bugzilla.suse.com/


18.9項「Cephのファイアウォール設定」に、SUSE Firewallで開く必要があるObject

Gateway、iSCSI Gateway、およびNFS Ganeshaのポート番号を追加しました(https://


CRUSHマップのツリーの反復処理に関する説明を追加しました。6.3.1項「ノードツリー全

体の反復処理」を参照してください。

CRUSHルールに「indep」パラメータを追加しました。6.3.2項「firstnとindep」を参照して

ください(https://bugzilla.suse.com/show_bug.cgi?id=1025189 )。

/etc/fstabでCephFSをマウントするには、 _netdevパラメータが必要です。13.3項

「/etc/fstabでのCephFSの指定」を参照してください(https://bugzilla.suse.com/


8.2項「RBDイメージのマウントとアンマウント」に、既存の rbdmap systemdサービス

ファイルに関するヒントを追加しました(https://bugzilla.suse.com/show_bug.cgi?

id=1015748 )。



























10.6.1.4項「ヒットセットでのGMTの使用」に、 use_gmt_hitsetオプションの説明を追

加しました(https://bugzilla.suse.com/show_bug.cgi?id=1024522 )。

13.1.1項「クライアントの準備」で、CephFSのマウントの説明を管理ガイドに戻し、

クライアントの準備に関するセクションを追加しました(https://bugzilla.suse.com/


B.4 2017年2月(SUSE Enterprise Storage 4Maintenance Update 1のリリース)

全般的な更新

第14章「NFS Ganesha: NFS経由でのCephデータのエクスポート」を追加しました。

バグ修正

『導入ガイド』、第5章「古いリリースからのアップグレード」、5.4項「SUSE Enterprise

Storage 4 (DeepSeaによる展開)から5へのアップグレード」に、CRUSHの調整可能パラ

メータを追加しました(https://bugzilla.suse.com/show_bug.cgi?id=1024718 )。

『導入ガイド』、第4章「DeepSea/Saltを使用した展開」、4.3項「クラスタの展

開」に、 systemdサービスが有効で起動していることの確認に関する説明を追加しました


13.1.3項「CephFSのマウント」で、ルートMDSディレクトリでは読み込みアクセスが必

要であることをユーザに通知しました(https://bugzilla.suse.com/show_bug.cgi?

id=1014051 )。

iSCSI Gatewayのアップグレードに関する参照を『導入ガイド』、第5章「古いリリース

からのアップグレード」、5.2項「一般的なアップグレード手順」に移動しました(https://


『導入ガイド』、第5章「古いリリースからのアップグレード」、5.2項「一般的なアップ

グレード手順」で、アップグレードワークフローに管理ノードを追加しました(https://


サービスのグロブ展開を避けるため、第3章「Cephのサービスの操作」を書き直しました


Saltのslsファイルを説明する付録を削除しました(https://bugzilla.suse.com/


274 2017年2月(SUSE Enterprise Storage 4 Maintenance … SES 5















XFSファイルシステムの破損に関する20.3項「XFSファイルシステムの破損」を追加しまし


時刻同期に関する18.3項「ノードの時刻同期」を追加しました(https://


ディスクの消去が必要であることを説明する情報で『導入ガイド』、第4章「DeepSea/Salt

を使用した展開」、4.3項「クラスタの展開」を更新しました(https://bugzilla.suse.com/



全般的な更新

DocBookの「パート」を含むドキュメント全体を再構成して、関連する章をまとめました。

第15章「openATTIC」を導入しました(Fate#321085)。

『導入ガイド』、第5章「古いリリースからのアップグレード」

古いアップグレード手順を『導入ガイド』、第5章「古いリリースからのアップグレード」、5.4

項「SUSE Enterprise Storage 4 (DeepSeaによる展開)から5へのアップグレード」に置き

換えました。

バグ修正

『導入ガイド』、第2章「ハードウェア要件と推奨事項」、2.1.1項「最小要件」で、OSDのメモ

リ要件を増やしました(https://bugzilla.suse.com/show_bug.cgi?id=982496 )。

『導入ガイド』、第4章「DeepSea/Saltを使用した展開」を向上しました(https://


20.9項「クロックスキュー警告の修復」を向上しました(https://bugzilla.suse.com/


『導入ガイド』、第11章「CephFSのインストール」、11.2.1項「Metadata Serverの追加」を

向上しました(https://bugzilla.suse.com/show_bug.cgi?id=992769 )。














全般的な更新

付録A Cephの手動インストールの手順例を追加しました。

第5章「cephxを使用した認証」を追加しました。

11.11項「マルチサイトObject Gateway」を追加しました(Fate#320602)。

『導入ガイド』、第4章「DeepSea/Saltを使用した展開」を追加しました。

第13章「クラスタ化ファイルシステム」を追加しました(Fate#318586)。

第12章「Ceph iSCSI Gateway」

『導入ガイド』、第10章「iSCSI Gatewayのインストール」、10.4.4項「オプション設定」を追

加しました。

12.1.1.1項「マルチパス設定」を追加しました。

バグ修正

10.6項「サンプル階層化ストレージの設定」で、ホットストレージとコールドストレー

ジの設定手順を向上し、10.6.1項「キャッシュ層の設定」を追加しました(https://


『導入ガイド』、第11章「CephFSのインストール」、11.2.1項「Metadata Serverの追

加」に、MDSサーバにCephをインストールするためのコマンドを追加しました(https://


『導入ガイド』、第10章「iSCSI Gatewayのインストール」、10.4項「インストールと環境設

定」に、RBDボリュームの作成時にフォーマット1がデフォルトでなくなった(代わりにフォー

マット2を推奨)ことの説明を追加しました(https://bugzilla.suse.com/show_bug.cgi?

id=987992 )。

6.3項「ルールセット」に、ルールセット番号を増やすことに関する注を追加しました


最適な調整可能パラメータに移行できるクライアントを記述しました(https://












『導入ガイド』、第10章「iSCSI Gatewayのインストール」、10.4.4項「オプション設

定」を『導入ガイド』、第10章「iSCSI Gatewayのインストール」、10.4.5項「詳細設

定」に分割し、設定オプションの説明を追加しました(https://bugzilla.suse.com/


6.6項「同一ノードでのSSDとHDDの混在」を追加しました(https://bugzilla.suse.com/


『導入ガイド』、第2章「ハードウェア要件と推奨事項」、2.1.1項「最小要件」で、最小推奨事

項を更新しました(https://bugzilla.suse.com/show_bug.cgi?id=981642 )。

8.3.3項「階層化」で、スナップショットのクローン作成に関するサポート情報を修正しまし


6.2項「バケット」で、「バケット」の説明を向上しました(https://bugzilla.suse.com/


『導入ガイド』、第2章「ハードウェア要件と推奨事項」、2.2項「モニタノード」で、非混在

ワークロードの語句を明確化しました(https://bugzilla.suse.com/show_bug.cgi?

id=982497 )。

『導入ガイド』、第2章「ハードウェア要件と推奨事項」、2.1.1項「最小要件」で、OSDの

RAM要件を更新しました(https://bugzilla.suse.com/show_bug.cgi?id=982496 )。

7.2.7項「プールの値の設定」で hit_set_countのデフォルト値を修正し、10.6項

「サンプル階層化ストレージの設定」に外部リンク付きの注を追加しました(https://


6.4.2項「OSDの追加/移動」、6.3項「ルールセット」、および6.2項「バケット」で、Ceph

の現行リリースに合わせて複数の箇所を更新しました(https://bugzilla.suse.com/


7.2.7項「プールの値の設定」に、プールのパラメー

タとその説明を追加しました。追加されたパラメータ

は、 hashpspool 、 expected_num_objects 、 cache_target_dirty_high_ratio 、

hit_set_grade_decay_rate 、 hit_set_grade_search_last_n 、 fast_read 、

scrub_min_interval 、 scrub_max_interval 、 deep_scrub_interval 、

nodelete 、 nopgchange 、 nosizechange 、 noscrub 、 nodeep-scrubです(https://


18.7項「OSDジャーナルを含むOSDに既存のパーティションを使用する方法」を追加しま

した(https://bugzilla.suse.com/show_bug.cgi?id=970104 )。




















『導入ガイド』、第2章「ハードウェア要件と推奨事項」、2.1.1項「最小要件」および6.1項

「デバイス」で、OSDディスクの配置にRAIDを推奨する部分を削除しました(https://


6.2項「バケット」で、CRUSHマップのデフォルトのバケットセットを更新しました(https://


「データ」および「メタデータ」のプールはデフォルトではなくなったため、削除しました


第12章「Ceph iSCSI Gateway」で、商品登録済みのサードパーティ製品名を修

正し、エンティティを置き換えました(https://bugzilla.suse.com/show_bug.cgi?

id=983018 )。

影響するセクション全体で、Object Gatewayのサービス名を ceph-

[email protected]_nameに更新しました(https://bugzilla.suse.com/


10.2項「考慮すべきポイント」を追加しました(https://bugzilla.suse.com/


6.3項「ルールセット」で、 min_sizeのデフォルト値を変更しました(https://


『導入ガイド』、第4章「DeepSea/Saltを使用した展

開」で、 master:dns_name_of_salt_masterオプションを修正しました(https://


Object Gatewayホストにプレフィックス rgw.を付けました(https://bugzilla.suse.com/


20.5項「状態メッセージ「nn pg stuck inactive」」に、完全にスタックしているPGに関す

る情報を追加しました(https://bugzilla.suse.com/show_bug.cgi?id=968067 )。

B.7 2016年1月(SUSE Enterprise Storage 2.1のリリース)

全般的な更新




















BtrfsはSUSE Enterprise Storage 2からサポートされなくなったため、削除しました。

9.3項「イレージャコーディングプールとキャッシュ階層化」を第10章「キャッシュ階層化」か

ら第9章「イレージャコーディングプール」へ移動し、提供されている情報が正しい順序に従

うようにしました。

第12章「Ceph iSCSI Gateway」を追加しました。

第2章「はじめに」

第4章「クラスタの状態の判断」で、「MDSの状態の確認」のセクションを削除しました。こ

れは、MDSはまだ説明されていないためです。

第17章「QEMU KVMインスタンスのバックエンドとしてのCephの使用」

17.1項「インストール」を追加しました。

バグ修正

古いクラスタを消去する場合に使用する systemctl stop cthulhu.serviceを追加し

ました(https://bugzilla.suse.com/show_bug.cgi?id=967849 )。

タイプミスを修正しました(https://bugzilla.suse.com/show_bug.cgi?id=967937 )。

ceph-deploy rgwコマンド構文のタイプミスを修正しました(https://


第11章「Ceph Object Gateway」全体を再構成し、11.3項「Object Gateway

サービスの操作」、11.5項「Object Gatewayのアクセスの管理」、および11.5.2.3

項「S3およびSwiftユーザのアクセスキーと秘密鍵の変更」を追加しました(https://


第4章「クラスタの状態の判断」で、「クラスタのモニタリング」の名前を「クラスタの状態の

判断」に変更しました(https://bugzilla.suse.com/show_bug.cgi?id=958302 )。

20.4項「状態メッセージ「Too Many PGs per OSD」」を追加しました(https://


異なるポート番号を使用したい場合は、Apacheがデフォルトのポート80をリスン

しないよう手動で変更することを顧客に勧めるアドバイスを追加しました(https://


第11章「Ceph Object Gateway」で、FastCGIの出現箇所とファイル参照を削除しまし















ceph-deployによるObject Gatewayインスタンスのインストール/移行方法を追加しま

した(https://bugzilla.suse.com/show_bug.cgi?id=946771 )。

Apacheのサポート情報を修正しました(https://bugzilla.suse.com/show_bug.cgi?

id=946769 )。


全般

『導入ガイド』、第5章「古いリリースからのアップグレード」を追加しました。

第16章「Cephでのlibvirtの使用」を追加しました。

第17章「QEMU KVMインスタンスのバックエンドとしてのCephの使用」を追加しました。

第11章「Ceph Object Gateway」

『導入ガイド』、第9章「Ceph Object Gateway」、9.1.1項「Object Gatewayの設

定」で、 systemctl radosgwコマンドを修正しました(https://bugzilla.suse.com/


Apacheを埋め込みのCivetWebに置き換えました。







管理ガイド - suse enterprise storage 5€¦ · 7.4 プールのスナップショット 82...

Documents