Cephダッシュボードにログインするには、ポート番号を含むCephダッシュボードのURLをブラウザに与えます。アドレスを確認するには、次のコマンドを実行します。

cephuser@adm > ceph mgr services | grep dashboard
"dashboard": "https://host:port/",

このコマンドはCephダッシュボードが置かれている場所のURLを返します。このコマンドの使用に関して問題が生じた場合、Book “Troubleshooting Guide”, Chapter 10 “Troubleshooting the Ceph Dashboard”, Section 10.1 “Locating the Ceph Dashboard”を参照してください。

図 2.1: Cephダッシュボードのログイン画面 #

 

クラスタの展開時に作成した資格情報を使用してログインします(Book “導入ガイド”, Chapter 5 “cephadmによる展開”, Section 5.3.2.9 “Cephダッシュボードログインアカウント情報の設定”を参照してください)。

ヒント: カスタムユーザアカウント

Cephダッシュボードへアクセスするのにデフォルトの「admin」アカウントを使用しない場合は、管理者特権を持つカスタムユーザアカウントを作成します。詳細については、第11章 「コマンドラインによるユーザと役割の管理」を参照してください。

ダッシュボードのユーザインタフェースはいくつかの「ブロック」に別れています。すなわち、画面右上の「ユーティリティメニュー」、画面左側の「メインメニュー」、そして、中央の「コンテンツペイン」です。

図 2.2: Cephダッシュボードのホームページ #

 

画面の右上にはユーティリティメニューがあります。ここには、Cephクラスタよりもダッシュボードとの関連性が高い一般的なタスクが含まれます。オプションをクリックすることで、次のトピックにアクセスできます。

ダッシュボードのメインメニューは、画面の左側にあります。これは次のトピックに対応します。

コンテンツペインは、ダッシュボードの画面のメイン部分を占めます。ダッシュボードのホームページには、多数の便利なウィジェットが表示されており、クラスタの現在のステータス、容量、およびパフォーマンス情報について簡潔に通知します。

Cephダッシュボードでは、プールのリスト、OSDノードのリスト、RBDデバイスのリストなど、「リスト」を操作することがよくあります。すべてのリストは、デフォルトでは5秒ごとに自動更新されます。次の共通ウィジェットは、これらのリストを管理または調整する場合に役立ちます。

をクリックして、リストの手動更新をトリガします。

をクリックして、個々のテーブル列の表示/非表示を切り替えます。

をクリックして、1ページに表示する行数を入力(または選択)します。

の内部をクリックし、検索する文字列を入力して行をフィルタします。

リストが複数のページにわたる場合は、 を使用して、現在表示されているページを変更します。

各ダッシュボードウィジェットには、実行中のCephクラスタの特定の側面に関連する特定のステータス情報が表示されます。一部のウィジェットはアクティブなリンクになっており、クリックすると、そのウィジェットが表すトピックに関連する詳細ページにリダイレクトされます。

ヒント: マウスポインタを合わせて詳細を表示

一部のグラフィカルウィジェットでは、マウスポインタを合わせると詳細が表示されます。

2.6.1 ステータスウィジェット #

 

ステータスウィジェットは、クラスタの現在のステータスに関する簡単な概要を提供します。

図 2.3: ステータスウィジェット #

 

クラスタのステータス

クラスタのヘルスに関する基本的な情報が示されます。

ホスト

クラスタノードの合計数が表示されます。

モニター

実行中のモニターとその定数の数が表示されます。

OSD

OSDの合計数と、「up」および「in」のOSDの数が表示されます。

マネージャ

アクティブおよびスタンバイ状態のCeph Managerデーモンの数が表示されます。

Object Gateway

実行中のObject Gatewayの数が表示されます。

メタデータサーバ

メタデータサーバの数が表示されます。

iSCSI Gateway

設定されているiSCSI Gatewayの数が表示されます。

2.6.2 容量のウィジェット #

 

容量ウィジェットには、ストレージ容量に関する簡単な情報が表示されます。

図 2.4: 容量のウィジェット #

 

未フォーマット時の容量

使用済みの容量と使用可能な未フォーマット時のストレージ容量の比率が表示されます。

オブジェクト

クラスタに保存されているデータオブジェクトの数が表示されます。

配置グループのステータス

配置グループのチャートがステータスに従って表示されます。

プール

クラスタのプールの数が表示されます。

OSDあたりの配置グループ数

OSDあたりの配置グループの平均数が表示されます。

2.6.3 パフォーマンスウィジェット #

 

パフォーマンスウィジェットは、Cephクライアントの基本的なパフォーマンスを参照します。

図 2.5: パフォーマンスウィジェット #

 

クライアントの読み取り/書き込み

1秒あたりのクライアントの読み取り/書き込み操作の量。

クライアントのスループット

1秒あたりのCephクライアントとの間で転送されるデータ量(バイト単位)。

回復スループット

1秒あたりに回復されるデータのスループット。

スクラブ

スクラビング(17.4.9項 「配置グループのスクラブ」を参照してください)のステータスを表示します。ステータスは非アクティブ、有効化済み、アクティブのいずれかです。

ユーティリティメニューの をクリックし、ユーザ管理を選択します。

リストに含まれる情報は、各ユーザのユーザ名、フルネーム、メールアドレス、割り当てられた役割の一覧、役割が有効化どうか、および、パスワード失効日です。

図 3.1: ユーザの管理 #

 

新しいユーザを追加するには、テーブル見出しの左上の作成をクリックします。ユーザ名、パスワード、およびオプションで氏名と電子メールを入力します。

図 3.2: ユーザの追加 #

 

事前定義された役割をユーザに割り当てるには、小さいペンのアイコンをクリックします。Create User (ユーザの作成)をクリックして確認します。

ユーザのテーブル行をクリックして選択を強調表示します。編集を選択して、ユーザに関する詳細を編集します。ユーザの編集をクリックして確認します。

ユーザのテーブル行をクリックして選択を強調表示します。編集の横にあるドロップダウンボタンを選択します。リストから削除を選択してユーザアカウントを削除します。はいチェックボックスをオンにし、Delete User (ユーザの削除)をクリックして確認します。

ユーティリティメニューの をクリックし、ユーザ管理を選択します。続いて、役割タブをクリックします。

このリストには、各役割の名前、説明、およびシステム役割であるかどうかが含まれます。

図 3.3: ユーザの役割 #

 

新しいカスタム役割を追加するには、テーブル見出しの左上の作成をクリックします。名前と説明を入力し、許可の横で、適切な許可を選択します。

ヒント: カスタム役割の消去

カスタムユーザ役割を作成し、後でceph-salt purgeコマンドを使ってCephクラスタを削除する場合、まずカスタム役割を消去する必要があります。詳細については、13.9項 「Cephクラスタ全体の削除」を参照してください。

図 3.4: 役割の追加 #

 

ヒント: 複数の有効化

トピック名の前にあるチェックボックスをオンにすると、そのトピックの許可がすべて有効になります。すべてチェックボックスをオンにすると、すべてのトピックの許可がすべて有効になります。

Create Role (役割の作成)をクリックして確認します。

カスタムの役割の説明と許可を編集するには、ユーザのテーブル行をクリックして選択を強調表示し、テーブル見出しの左上の編集を選択します。役割の編集をクリックして確認します。

役割のテーブル行をクリックして選択を強調表示してから、編集の横にあるドロップダウンボタンを選択します。リストから削除を選択して役割を削除します。はいチェックボックスをオンにし、Delete Role (役割の削除)をクリックして確認します。

クラスタノードのリストを表示するには、クラスタ › ホストをクリックします。

図 4.1: ホスト #

 

ノードのパフォーマンスの詳細を表示するには、ホスト名列のノード名の横にあるドロップダウン矢印をクリックします。

サービス列には、関連する各ノードで実行されているすべてのデーモンが一覧にされます。デーモン名をクリックすると、その詳細な設定が表示されます。

デバイスのリストを表示するには、クラスタ › インベントリをクリックします。リストにはデバイスのパス、種類、利用可能かどうか、ベンダー、モデル、サイズ、OSDが含まれます。

ホスト名列のノード名をクリックして選択します。選択した状態で、識別をクリックすると、そのホストを実行しているデバイスが特定されます。このとき、デバイスにLEDを点滅させるよう指示されます。このアクションの時間は、1、2、5、10、15分から選択します。実行をクリックします。

図 4.2: サービス #

 

実行中のCeph Monitorが存在するクラスタノードのリストを表示するには、クラスタ › モニターをクリックします。コンテンツペインは2つのビューに分割されます。1つはステータスビューで、もう1つは定数内と非定数内のビューです。

ステータステーブルには、実行中のCeph Monitorに関する一般的な統計情報が表示されます。内容は次の通りです。

定数内と非定数内のペインには、各Monitorの名前、ランク数、パブリックIPアドレス、開いているセッション数が含まれます。

関連するCeph Monitorの設定を表示するには、名前列のノード名をクリックします。

図 4.3: Ceph Monitor #

 

利用可能な各サービスの詳細を表示するには、クラスタ › サービスをクリックします。サービスの例としては、crash、Ceph Manager、Ceph Monitorなどがあります。リストにはコンテナイメージの名前、コンテナイメージのID、実行中の内容のステータス、サイズ、最後に更新された日時が含まれます。

デーモンの詳細を表示するには、サービス列のサービス名の横にあるドロップダウン矢印をクリックします。詳細リストには、ホスト名、デーモンの種類、デーモンID、コンテナID、コンテナイメージ名、コンテナイメージID、バージョン番号、ステータス、最後に更新された日時が含まれます。

図 4.4: サービス #

 

実行中のOSDデーモンが存在するノードのリストを表示するには、クラスタ › OSDをクリックします。このリストには、各ノードの名前、ID、ステータス、デバイスクラス、配置グループの数、サイズ、使用状況、時間内の読み込み/書き込みチャート、および1秒あたりの読み込み/書き込み操作の速度が含まれます。

図 4.5: Ceph OSD #

 

ポップアップウィンドウを開くには、テーブル見出しのクラスタ全体の設定ドロップダウンメニューから、フラグを選択します。このウィンドウにはクラスタ全体に適用されるフラグの一覧が表示されます。個々のフラグを有効または無効にし、送信をクリックして確認できます。

図 4.6: OSDフラグ #

 

ポップアップウィンドウを開くには、テーブル見出しのクラスタ全体の設定ドロップダウンメニューから、回復優先度を選択します。このウィンドウにはクラスタ全体に適用されるOSDの回復優先度の一覧が表示されます。希望する優先度プロファイルを有効にし、その下の個々の値を微調整できます。送信をクリックして確認します。

図 4.7: OSD回復優先度 #

 

デバイスの設定とパフォーマンスに関する詳細が含まれる拡張テーブルを表示するには、ホスト列のノード名の横にあるドロップダウン矢印をクリックします。複数のタブを参照すると、属性、メタデータ、デバイスヘルス、パフォーマンスカウンタ、読み込みと書き込みをグラフィカルに表示するヒストグラム、およびパフォーマンスの詳細の各リストを確認できます。

図 4.8: OSDの詳細 #

 

ヒント: OSDでの固有のタスクの実行

OSDノード名をクリックすると、テーブルの行が強調表示されます。これは、そのノードでタスクを実行できることを表すものです。以下のアクションのいずれかを選択して実行できます。編集、作成、スクラブ、ディープスクラブ、再重みづけ、アウトとしてマーク、インとしてマーク、ダウンとしてマーク、喪失としてマーク、消去、破棄、削除。

作成ボタン隣のテーブル見出しの左上にある下矢印をクリックし、実行したいタスクを選択します。

Cephクラスタ設定オプションの完全なリストを表示するには、クラスタ › 設定をクリックします。リストにはオプション名、簡単な説明、現在値とデフォルト値、およびオプションを編集可能かどうかが含まれます。

図 4.14: クラスタの設定 #

 

オプションに関する詳細情報が含まれる拡張テーブルを表示するには、名前列の設定オプションの隣にあるドロップダウン矢印をクリックします。詳細情報としては、値の種類、最小許容値と最大許容値、実行中に更新可能か、などが含まれます。

特定のオプションを強調表示した後で、テーブル見出しの左上の編集ボタンをクリックして、その値を編集できます。保存をクリックして変更を確定します。

クラスタのCRUSHマップを表示するには、クラスタ › CRUSHマップをクリックします。CRUSHマップの全般的な情報については、17.5項 「CRUSHマップの操作」を参照してください。

ルート、ノード、または個々のOSDをクリックすると、CRUSHの重み、マップツリー内での深さ、OSDのデバイスクラスなどの詳細情報が表示されます。

図 4.15: CRUSHマップ #

 

使用可能なCeph Managerモジュールのリストを表示するには、クラスタ › マネージャモジュールをクリックします。各行は、モジュール名と、そのモジュールが現在有効かどうかに関する情報で構成されます。

図 4.16: マネージャモジュール #

 

詳細設定を含む拡張テーブルを、下の詳細テーブルに表示するには、名前列のモジュールの隣にあるドロップダウン矢印をクリックします。設定を編集するには、テーブル見出しの左上の編集ボタンをクリックします。更新をクリックして変更を確定します。

モジュールを有効化または無効化するには、テーブル見出しの左上にある編集ボタンの隣のドロップダウン矢印をクリックします。

クラスタの最近のログエントリのリストを表示するには、クラスタ › ログをクリックします。各行は、タイムスタンプ、ログエントリのタイプ、およびログに記録されたメッセージ自体で構成されます。

監査サブシステムのログエントリを表示するには、監査ログタブをクリックします。監査を有効または無効にするためのコマンドについては、11.5項 「API要求の監査」を参照してください。

図 4.17: ログ #

 

Prometheusアラートの詳細の管理と表示を行うには、クラスタ › 監視をクリックします。

アクティブなPrometheusが存在するなら、このコンテンツペインの有効なアラート、すべてのアラート、またはサイレンスから詳細な情報を表示できます。

注記

Prometheusが展開されていない場合、表示される情報バナーから関連するドキュメントを表示できます。

新しいプールを追加するには、プールテーブルの左上の作成をクリックします。プールフォームには、プール名、タイプ、アプリケーション、圧縮モード、最大バイト数と最大オブジェクト数のクオータを入力できます。この特定のプールに最適な配置グループの数は、プールのフォームそのものによって事前に計算されます。この計算は、クラスタ内のOSDの量、および選択したプールタイプとその特定の設定に基づきます。配置グループ数を手動で設定すると、すぐに計算された数に置き換えられます。プールの作成をクリックして確認します。

図 5.2: 新しいプールの追加 #

 

プールを削除するには、そのテーブル行のプールを選択します。作成ボタンの横にあるドロップダウン矢印をクリックして、削除をクリックします。

プールのオプションを編集するには、そのテーブル行を選択してプールテーブルの左上の編集をクリックします。

プールの名前を変更したり、配置グループの数を増やしたり、プールのアプリケーションのリストや圧縮設定を変更したりできます。プールの編集をクリックして確認します。

デバイスに関する詳細情報を表示するには、テーブルでそのデバイスの行をクリックします。

図 6.2: RBDの詳細 #

 

デバイスの詳細な設定を表示するには、テーブルでそのデバイスの行をクリックし、続いてその下のテーブルで設定タブをクリックします。

図 6.3: RBD設定 #

 

新しいデバイスを追加するには、テーブル見出しの左上の作成をクリックして、RBDの作成画面で次の操作を行います。

図 6.4: 新しいRBDの追加 #

 

デバイスを削除するには、そのテーブル行を選択します。作成ボタンの横にあるドロップダウン矢印をクリックして、削除をクリックします。Delete RBD (RBDの削除)をクリックして削除を確認します。

ヒント: RBDのごみ箱への移動

RBDの削除は元に戻せないアクションです。代わりにごみ箱に移動するを実行すると、後でメインテーブルのごみ箱タブでデバイスを選択し、テーブル見出しの左上の復元をクリックしてデバイスを復元できます。

RADOS Block Deviceのスナップショットを作成するには、そのテーブル行を選択してください。設定内容ペインが表示されます。スナップショットタブを選択し、テーブル見出しの左上にある作成をクリックします。スナップショットの名前を入力し、RBDスナップショットの作成をクリックして確認します。

スナップショットを選択した後で、デバイスの名前の変更、保護、複製、コピー、削除などの追加のアクションを実行できます。ロールバックは、現在のスナップショットからデバイスの状態を復元します。

図 6.5: RBDのスナップショット #

 

RADOS Block Deviceイメージを2つのCephクラスタ間で非同期にミラーリングできます。Cephダッシュボードを使用して、2つ以上のクラスタ間でRBDイメージを複製するよう設定できます。この機能には2つのモードがあります。

ジャーナルベースのミラーリングだけを使用している場合、ミラーリングはピアクラスタ内のプールごとに設定されます。また、プール内の特定のイメージサブセットに設定することや、プール内のすべてのイメージを自動的にミラーリングするように設定することもできます。

ミラーリングはrbdコマンドを使用して設定します。rbdはデフォルトでSUSE Enterprise Storage 7にインストール済みです。rbd-mirrorデーモンは、リモートのピアクラスタからイメージの更新を取得して、ローカルクラスタ内のイメージに適用する処理を受け持ちます。rbd-mirrorデーモンの有効化の詳細については、6.6.2項 「rbd-mirrorデーモンの有効化」を参照してください。

レプリケーションに対する要望に応じて、RADOS Block Deviceのミラーリングは単方向レプリケーション用または双方向レプリケーション用に設定できます。

重要

rbd-mirrorデーモンの各インスタンスは、ローカルとリモート両方のCephクラスタを同時に接続できなければなりません。たとえば、すべてのMonitorホストとOSDホストを接続できる必要があります。さらに、ミラーリングのワークロードを扱うため、ネットワークの2つのデータセンター間には十分な帯域幅が必要です。

ヒント: 一般情報

RADOS Block Deviceのミラーリングの一般情報とコマンドラインによるアプローチについては、20.4項 「RBDイメージのミラーリング」を参照してください。

6.6.1 プライマリクラスタとセカンダリクラスタの設定 #

 

「プライマリ」クラスタは、イメージを含む元のプールが作成される場所です。「セカンダリ」クラスタは、「プライマリ」クラスタからプールやイメージが複製される場所です。

注記: 相対命名

「プライマリ」および「セカンダリ」という用語は、クラスタよりも個々のプールとの関連性が高いため、レプリケーションのコンテキストでは相対的に使用できます。たとえば、双方向レプリケーションにおいて、あるプールを「プライマリ」クラスタから「セカンダリ」クラスタにミラーリングし、別のプールを「セカンダリ」クラスタから「プライマリ」クラスタにミラーリングできます。

cephuser@adm > rbd mirror pool disable POOL_NAME

cephuser@adm > rbd mirror pool peer bootstrap create [--site-name local-site-name] pool-name

cephuser@adm > rbd --cluster primary mirror pool peer bootstrap create --site-name primary
  image-pool eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkL \
  W1pcnJvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
  joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==

cephuser@adm > rbd mirror pool peer bootstrap import [--site-name local-site-name] \
[--direction rx-only or rx-tx] pool-name token-path

cephuser@adm > cat >>EOF < token
eyJmc2lkIjoiOWY1MjgyZGItYjg5OS00NTk2LTgwOTgtMzIwYzFmYzM5NmYzIiwiY2xpZW50X2lkIjoicmJkLW1pcn \
Jvci1wZWVyIiwia2V5IjoiQVFBUnczOWQwdkhvQmhBQVlMM1I4RmR5dHNJQU50bkFTZ0lOTVE9PSIsIm1vbl9ob3N0I \
joiW3YyOjE5Mi4xNjguMS4zOjY4MjAsdjE6MTkyLjE2OC4xLjM6NjgyMV0ifQ==
EOF
cephuser@adm > rbd --cluster secondary mirror pool peer bootstrap import --site-name secondary image-pool token

cephuser@adm > rbd mirror pool peer remove pool-name peer-uuid

ヒント: iSCSI Gatewayについての詳細

iSCSI Gatewayの全般的な情報については、第22章 「Ceph iSCSI Gateway」を参照してください。

利用可能なすべてのゲートウェイとマップ済みイメージを一覧にするには、メインメニューからブロック › iSCSIをクリックします。概要タブを開くと、現在設定されているiSCSI Gatewayとマップ済みのRBDイメージが一覧にされます。

ゲートウェイテーブルには、各ゲートウェイの状態、iSCSIターゲットの数、およびセッションの数が一覧にされます。イメージテーブルには、各マップ済みイメージの名前、関連するプール名のバックストアタイプ、および他の統計情報の詳細が一覧にされます。

ターゲットタブには、現在設定されているiSCSIターゲットが一覧にされます。

図 6.14: iSCSIターゲットのリスト #

 

ターゲットのより詳細な情報を表示するには、そのテーブル行のドロップダウン矢印をクリックしてください。ツリー構造のスキーマが開き、ディスク、ポータル、イニシエータ、およびグループが一覧にされます。項目をクリックして展開し、その詳細コンテンツを表示します。オプションで右側の表に関連する設定が表示されます。

図 6.15: iSCSIターゲット詳細 #

 

6.7.1 iSCSIターゲットの追加 #

 

新しいiSCSIターゲットを追加するには、ターゲットテーブルの左上の作成をクリックして、必要な情報を入力します。

図 6.16: 新しいターゲットの追加 #

 

1. 新しいゲートウェイのターゲットアドレスを入力します。

2. Add portal (ポータルの追加)をクリックして、リストから1つまたは複数のiSCSIポータルを選択します。

3. Add image (イメージの追加)をクリックして、ゲートウェイのRBDイメージを1つまたは複数選択します。

4. 認証を使用してゲートウェイにアクセスする必要がある場合は、ACL認証チェックボックスをオンにして資格情報を入力します。Mutual authentication (相互認証)およびDiscovery authentication (ディスカバリ認証)を有効にすると、より高度な認証オプションが表示されます。

5. Create Target (ターゲットの作成)をクリックして確認します。

ヒント: 詳細の参照先

RBD QoS設定オプションの全般的な情報と説明については、20.6項 「QoS設定」を参照してください。

QoSオプションは次の複数のレベルで設定できます。

「グローバル」の設定はリストの一番上にあり、新しく作成されたすべてのRBDイメージと、プールまたはRBDイメージ層でこれらの値を上書きしないイメージに使用されます。グローバルに指定されたオプション値をプールごとまたはイメージごとに上書きできます。プールに対して指定されたオプションは、そのプールのすべてのRBDイメージに適用されます。ただし、イメージに対して設定された設定オプションが優先される場合を除きます。イメージに対して指定されたオプションは、プールに対して指定されたオプションを上書きし、グローバルに指定されたオプションを上書きします。

このようにして、デフォルトをグローバルに定義して、特定のプールのすべてのRBDイメージに適合させ、個々のRBDイメージのプール設定を上書きできます。

6.8.2 新しいプールでのオプションの設定 #

 

新しいプールを作成し、そのプールにRBD設定オプションを設定するには、プール › 作成をクリックします。プールタイプとしてreplicated (複製)を選択します。RBD QoSオプションを設定できるようにするには、プールにrbdアプリケーションタグを追加する必要があります。

注記

イレージャコーディングプールにRBD QoS設定オプションを設定することはできません。イレージャコーディングプールにRBD QoSオプションを設定するには、RBDイメージの複製されたメタデータプールを編集する必要があります。これにより、そのイメージのイレージャコーディングデータプールに設定が適用されます。

6.8.3 既存のプールでのオプションの設定 #

 

既存のプールにRBD QoSオプションを設定するには、プールをクリックし、プールのテーブル行をクリックして、テーブルの左上の編集を選択します。

ダイアログにRBD設定セクションが表示され、その後にサービス品質セクションが表示されます。

注記

RBD設定セクションもサービス品質セクションも表示されない場合は、RBD設定オプションの設定に使用できない「イレージャコーディング」プールを編集しているか、RBDイメージで使用するようにプールが設定されていない可能性があります。後者の場合は、RBDアプリケーションタグをプールに割り当てます。これにより、対応する設定セクションが表示されます。

新しいNFSエクスポートを追加するには、エクスポートテーブルの左上にある作成をクリックして、必要な情報を入力します。

図 7.3: 新しいNFSエクスポートの追加 #

 

エクスポートを削除するには、そのテーブル行でエクスポートを選択して強調表示します。編集ボタンの横にあるドロップダウン矢印をクリックして、削除を選択します。はいチェックボックスをオンにし、NFSエクスポートの削除をクリックして確認します。

既存のエクスポートを編集するには、そのテーブル行でエクスポートを選択して強調表示し、エクスポートテーブルの左上にある編集をクリックします。

その後、NFSエクスポートのすべての詳細を調整できます。

図 7.4: NFSエクスポートの編集 #

 

設定されているファイルシステムの概要を表示するには、メインメニューからファイルシステムをクリックします。メインテーブルには、各ファイルシステムの名前、作成日、および有効かどうか表示されます。

ファイルシステムのテーブル行をクリックすると、そのランクと、ファイルシステムに追加されたプールの詳細が表示されます。

図 8.1: CephFSの詳細 #

 

画面の下部に、関連するMDS iノードとクライアント要求の数をリアルタイムで収集した統計情報カウントが表示されます。

図 8.2: CephFSの詳細 #

 

設定されているObject Gatewayのリストを表示するには、オブジェクトゲートウェイ › デーモンをクリックします。このリストには、ゲートウェイのID、ゲートウェイデーモンが実行されているクラスタノードのホスト名、およびゲートウェイのバージョン番号が含まれます。

ゲートウェイの詳細情報を表示するには、ゲートウェイ名の横にあるドロップダウン矢印をクリックします。パフォーマンスカウンタタブには、読み込み/書き込み操作とキャッシュ統計情報の詳細が表示されます。

図 9.1: ゲートウェイの詳細 #

 

既存のObject Gatewayユーザのリストを表示するには、オブジェクトゲートウェイ › ユーザをクリックします。

ユーザアカウントの詳細を表示するには、ユーザ名の横にあるドロップダウン矢印をクリックします。表示される情報は、ステータス情報やユーザとバケットクォータの詳細などです。

図 9.2: ゲートウェイユーザ #

 

9.2.1 新しいゲートウェイユーザの追加 #

 

新しいゲートウェイユーザを追加するには、テーブル見出しの左上の作成をクリックします。資格情報、S3キー、ユーザとバケットクォータの詳細を入力し、ユーザの作成をクリックして確認します。

図 9.3: 新しいゲートウェイユーザの追加 #

 

OGW (Object Gateway)バケットは、OpenStack Swiftコンテナの機能を実装しています。Object Gatewayバケットは、データオブジェクトを保存するためのコンテナとして機能します。

オブジェクトゲートウェイ › バケットをクリックして、オブジェクトゲートウェイバケットのリストを表示します。

9.3.1 新しいバケットの追加 #

 

新しいオブジェクトゲートウェイバケットを追加するには、テーブル見出しの左上の作成をクリックします。バケット名を入力し、所有者を選択し、配置ターゲットを設定します。バケットの作成をクリックして確認します。

注記

この時点で有効化済みを選択してロックを有効化できますが、作成後にも設定可能です。詳細については、9.3.3項 「バケットの編集」を参照してください。

9.3.2 バケットの詳細の表示 #

 

Object Gatewayバケットの詳細情報を表示するには、バケット名の隣にあるドロップダウン矢印をクリックします。

図 9.4: ゲートウェイバケットの詳細 #

 

ヒント: バケットクォータ

詳細テーブルの下で、バケットクォータとロック設定の詳細を確認できます。

9.3.3 バケットの編集 #

 

バケットを選択して強調表示してから、テーブル見出しの左上にある編集をクリックします。

バケットの所有者の更新と、バージョニング、多要素認証、ロックの有効化ができます。変更後、バケットの編集をクリックして確認します。

図 9.5: バケットの詳細の編集 #

 

ダッシュボードとのすべてのHTTP接続は、デフォルトでTLS/SSLによって保護されています。セキュア接続にはSSL証明書が必要です。自己署名証明書を使用することも、証明書を生成して既知のCA (認証局)で署名することもできます。

ヒント: SSLの無効化

特定の理由がある場合、SSLのサポートを無効にできます。たとえば、SSLをサポートしないプロキシの後方でダッシュボードを実行する場合などです。

SSLを無効にする場合は注意してください。「ユーザ名とパスワード」は「暗号化されずに」ダッシュボードに送信されます。

SSLを無効にするには、次のコマンドを実行します。

cephuser@adm > ceph config set mgr mgr/dashboard/ssl false

ヒント: Ceph Managerプロセスの再起動

SSL証明書とキーを変更した後で、Ceph Managerプロセスを手動で再起動する必要があります。このためには、次のコマンドを実行します。

cephuser@adm > ceph mgr fail ACTIVE-MANAGER-NAME

または、ダッシュボードモジュールを無効化して再度有効化することもできます。この場合、マネージャが自身を再起動します。

cephuser@adm > ceph mgr module disable dashboard
cephuser@adm > ceph mgr module enable dashboard

10.1.1 自己署名証明書の作成 #

 

セキュア通信用の自己署名証明書の作成は簡単です。これにより、ダッシュボードの実行を高速化できます。

注記: Webブラウザの警告

ほとんどのWebブラウザでは、自己署名証明書を使用すると警告が表示され、ダッシュボードへのセキュアな接続を確立するには明示的に確認する必要があります。

自己署名証明書を生成してインストールするには、次の組み込みコマンドを使用します。

cephuser@adm > ceph dashboard create-self-signed-cert

10.1.2 CA署名証明書の使用 #

 

ダッシュボードへの接続を適切に保護し、Webブラウザで自己署名証明書に関する警告が表示されないようにするため、CAによって署名された証明書を使用することをお勧めします。

次のようなコマンドを使用して証明書キーペアを生成できます。

root # openssl req -new -nodes -x509 \
  -subj "/O=IT/CN=ceph-mgr-dashboard" -days 3650 \
  -keyout dashboard.key -out dashboard.crt -extensions v3_ca

上のコマンドは、dashboard.keyファイルとdashboard.crtファイルを出力します。dashboard.crtファイルがCAによって署名されたら、次のコマンドを実行して、すべてのCeph Managerインスタンスに対してその証明書を有効にします。

cephuser@adm > ceph config-key set mgr/dashboard/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/key -i dashboard.key

ヒント: 各マネージャインスタンスに対して異なる証明書が必要な場合

Ceph Managerの各インスタンスに対して異なる証明書が必要な場合は、次のようにコマンドを変更してインスタンスの名前を含めます。NAMEは、Ceph Managerインスタンスの名前(通常は関連するホスト名)で置き換えます。

cephuser@adm > ceph config-key set mgr/dashboard/NAME/crt -i dashboard.crt
cephuser@adm > ceph config-key set mgr/dashboard/NAME/key -i dashboard.key

Cephダッシュボードは特定のTCP/IPアドレスとTCPポートにバインドされます。デフォルトでは、ダッシュボードをホストする現在アクティブなCeph Managerは、TCPポート8443 (SSLが無効な場合は8080)にバインドされます。

注記

Ceph Manager(および、Cephダッシュボード)を実行しているホストでファイアウォールが有効化されている場合、ポートにアクセスできるように設定変更が必要な場合があります。Ceph向けファイアウォール設定の詳細については、Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”を参照してください。

Cephダッシュボードは、デフォルトで「::」にバインドされます。これは、使用可能なすべてのIPv4およびIPv6アドレスに対応します。次のコマンドを使用すると、すべてのCeph Managerインスタンスに適用されるようにWebアプリケーションのIPアドレスとポート番号を変更できます。

cephuser@adm > ceph config set mgr mgr/dashboard/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/server_port PORT_NUMBER

ヒント: Ceph Managerインスタンスの個別の設定

各ceph-mgrデーモンは専用のダッシュボードインスタンスをホストするため、インスタンスを個別に設定しなければならない場合があります。次のコマンドを使用して、特定のマネージャインスタンスのIPアドレスとポート番号を変更します(NAMEをceph-mgrのIDで置き換えます)。

cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_addr IP_ADDRESS
cephuser@adm > ceph config set mgr mgr/dashboard/NAME/server_port PORT_NUMBER

ヒント: 設定済みエンドポイントの一覧

ceph mgr servicesコマンドは、現在設定されているすべてのエンドポイントを表示します。dashboardキーを検索して、ダッシュボードにアクセスするためのURLを取得します。

デフォルトの管理者アカウントを使用しない場合は、別のユーザアカウントを作成して、それを少なくとも1つの役割に関連付けます。事前定義済みの一連のシステム役割が用意されており、これらの役割を使用できます。詳細については、第11章 「コマンドラインによるユーザと役割の管理」を参照してください。

管理者特権を持つユーザを作成するには、次のコマンドを使用します。

cephuser@adm > ceph dashboard ac-user-create USER_NAME PASSWORD administrator

ダッシュボードのObject Gateway管理機能を使用するには、systemフラグが有効なユーザのログインアカウント情報を指定する必要があります。

注記

SUSE Linux Enterprise Server 15 SP2では、デフォルトでファイアウォールが有効です。ファイアウォール設定の詳細については、Book “Troubleshooting Guide”, Chapter 13 “Hints and tips”, Section 13.7 “Firewall settings for Ceph”を参照してください。

考慮すべき点がいくつかあります。

Cephダッシュボードは、iSCSIターゲットを管理します。これには、Ceph iSCSIゲートウェイのrbd-target-apiサービスが提供するREST APIを使用します。REST APIがインストール済みで、iSCSIゲートウェイ上で有効化されていることを確認します。

注記

CephダッシュボードのiSCSI管理機能は、ceph-iscsiプロジェクトの最新版であるバージョン3に依存しています。使用しているオペレーティングシステムが適切なバージョンであることを確認してください。さもなければ、CephダッシュボードはiSCSI管理機能を使用できません。

ceph-iscsi REST APIがHTTPSモードに設定されており、自己署名証明書を使用している場合、ceph-iscsi APIにアクセスした際のSSL証明書の検証を回避するようにダッシュボードを設定します。

API SSL検証を無効化します。

cephuser@adm > ceph dashboard set-iscsi-api-ssl-verification false

利用可能なiSCSIゲートウェイを定義します。

cephuser@adm > ceph dashboard iscsi-gateway-list
cephuser@adm > ceph dashboard iscsi-gateway-add scheme://username:password@host[:port]
cephuser@adm > ceph dashboard iscsi-gateway-rm gateway_name

SSO (「シングルサインオン」)は、ユーザが複数のアプリケーションに1つのIDとパスワードで同時にログインできるアクセス制御方法です。

Cephダッシュボードは、SAML 2.0プロトコルを介したユーザの外部認証をサポートしています。「権限付与」は引き続きダッシュボードによって実行されるため、まずユーザアカウントを作成し、それを目的の役割に関連付ける必要があります。ただし、「認証」プロセスは、既存のIdP (「Identity Provider」)によって実行できます。

シングルサインオンを設定するには、次のコマンドを使用します。

cephuser@adm > ceph dashboard sso setup saml2 CEPH_DASHBOARD_BASE_URL \
 IDP_METADATA IDP_USERNAME_ATTRIBUTE \
 IDP_ENTITY_ID SP_X_509_CERT \
 SP_PRIVATE_KEY

パラメータは次の通りです。

注記: SAML要求

SAML要求の発行者の値は次のパターンに従います。

CEPH_DASHBOARD_BASE_URL/auth/saml2/metadata

SAML 2.0の現在の設定を表示するには、次のコマンドを実行します。

cephuser@adm > ceph dashboard sso show saml2

シングルサインオンを無効にするには、次のコマンドを実行します。

cephuser@adm > ceph dashboard sso disable

SSOが有効かどうかを確認するには、次のコマンドを実行します。

cephuser@adm > ceph dashboard sso status

SSOを有効にするには、次のコマンドを実行します。

cephuser@adm > ceph dashboard sso enable saml2

デフォルトでは、次のチェックを含むパスワードポリシー機能が有効になっています。

次のコマンドにより、パスワードポリシー機能全体をON/OFFに切り替えることができます。

cephuser@adm > ceph dashboard set-pwd-policy-enabled true|false

次のチェック項目を個別にON/OFFに切り替えることも可能です。

cephuser@adm > ceph dashboard set-pwd-policy-check-length-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-oldpwd-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-username-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-exclusion-list-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-complexity-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-sequential-chars-enabled true|false
cephuser@adm > ceph dashboard set-pwd-policy-check-repetitive-chars-enabled true|false

また、パスワードポリシーの動作設定に次のオプションを利用できます。

Cephダッシュボードは、複数のユーザアカウントの管理をサポートしています。各ユーザアカウントは、ユーザ名、パスワード(bcryptを使用して暗号化された形式で保存)、オプションの名前、およびオプションの電子メールアドレスで構成されます。

ユーザアカウントはCeph Monitorの設定データベースに保存され、すべてのCeph Managerインスタンス間でグローバルに共有されます。

ユーザアカウントを管理するには、次のコマンドを使用します。

このセクションでは、ユーザの役割に割り当てることができるセキュリティスコープ、ユーザの役割を管理する方法、およびユーザの役割をユーザアカウントに割り当てる方法について説明します。

11.3.2 ユーザの役割の指定 #

 

「役割」は、「セキュリティスコープ」と一連の「許可」との間の一連のマッピングを指定するものです。許可には、「read」、「create」、「update」、および「delete」の4つのタイプがあります。

次の例では、ユーザがプールの管理に関連する機能に対して「read」許可と「create」許可を持ち、RBDイメージの管理に関連する機能に対して完全な許可を持つ役割を指定します。

{
  'role': 'my_new_role',
  'description': 'My new role',
  'scopes_permissions': {
    'pool': ['read', 'create'],
    'rbd-image': ['read', 'create', 'update', 'delete']
  }
}

ダッシュボードには、「システム役割」と呼ばれる、事前定義済みの一連の役割があらかじめ用意されています。これらの役割は、Cephダッシュボードを新規インストールした後ですぐに使用できます。

管理者

すべてのセキュリティスコープに対する完全な許可を提供します。

読み込み専用

ダッシュボード設定を除くすべてのセキュリティスコープの読み込み許可を提供します。

block-manager

「rbd-image」、「rbd-mirroring」、および「iscsi」のスコープに対する完全な許可を提供します。

rgw-manager

「rgw」スコープに対する完全な許可を提供します。

cluster-manager

「hosts」、「osd」、「monitor」、「manager」、および「config-opt」のスコープに対する完全な許可を提供します。

pool-manager

「pool」スコープに対する完全な許可を提供します。

cephfs-manager

「cephfs」スコープに対する完全な許可を提供します。

11.3.2.1 カスタム役割の管理 #

 

次のコマンドを使用して、新しいユーザの役割を作成できます。

新規ロール(役割)を作成します:

cephuser@adm > ceph dashboard ac-role-create ROLENAME [DESCRIPTION]

役割の削除:

cephuser@adm > ceph dashboard ac-role-delete ROLENAME

役割へのスコープ許可の追加

cephuser@adm > ceph dashboard ac-role-add-scope-perms ROLENAME SCOPENAME PERMISSION [PERMISSION...]

役割からのスコープ許可の削除

cephuser@adm > ceph dashboard ac-role-del-perms ROLENAME SCOPENAME

11.3.2.2 ユーザアカウントへの役割の割り当て #

 

役割をユーザに割り当てるには、次のコマンドを使用します。

ユーザの役割の設定

cephuser@adm > ceph dashboard ac-user-set-roles USERNAME ROLENAME [ROLENAME ...]

ユーザへの追加の役割の追加

cephuser@adm > ceph dashboard ac-user-add-roles USERNAME ROLENAME [ROLENAME ...]

ユーザからの役割の削除

cephuser@adm > ceph dashboard ac-user-del-roles USERNAME ROLENAME [ROLENAME ...]

ヒント: カスタム役割の消去

カスタム役割を作成し、後でceph.purgeランナを使ってCephクラスタを削除する場合、まずカスタム役割を消去する必要があります。詳細については、13.9項 「Cephクラスタ全体の削除」を参照してください。

11.3.2.3 例: ユーザとカスタム役割の作成 #

 

このセクションでは、RBDイメージの管理、Cephプールの表示と作成、および他のスコープへの読み込み専用アクセスを行うことができるユーザアカウントの作成手順について説明します。

1. tuxという名前の新しいユーザを作成します。

    cephuser@adm > ceph dashboard ac-user-create tux PASSWORD

2. 役割を作成し、スコープ許可を指定します。

   cephuser@adm > ceph dashboard ac-role-create rbd/pool-manager
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager \
    rbd-image read create update delete
   cephuser@adm > ceph dashboard ac-role-add-scope-perms rbd/pool-manager pool read create

3. 役割をtuxユーザに関連付けます。

   cephuser@adm > ceph dashboard ac-user-set-roles tux rbd/pool-manager read-only

Cephダッシュボードへの固定URLを定めたい場合や、管理ノードへの直接接続を許可したくない場合は、プロキシを設定できます。このプロキシは受け取った要求現在をアクティブなceph-mgrインスタンスへ自動的に転送します。

  cephuser@adm > ceph config set mgr mgr/dashboard/url_prefix URL_PREFIX

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "error"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_behaviour "redirect"

cephuser@adm > ceph config set mgr mgr/dashboard/standby_error_status_code 503

11.4.4 HAProxyの設定例 #

 

以下に示す設定は、HAProxyを使用したTLS/SSLパススルーの例です。

注記

この設定が効果を発揮する状況は次の通りです。ダッシュボードがフェールオーバーした際に、フロントエンドのクライアントはHTTPリダイレクト応答(303)を受け取る可能性があります。この場合、クライアントは解決不能ホストにリダイレクトされてしまいます。

このような状況は、HAProxyの2つのヘルスチェック中にフェールオーバーが発生した場合に生じます。これは、それまでアクティブだったダッシュボードが、新しいアクティブノードをリダイレクト先とする303エラーで応答してしまうためです。このような状況を避けるため、スタンバイノードのリダイレクション動作を無効化することを検討する必要があります。

  defaults
    log global
    option log-health-checks
    timeout connect 5s
    timeout client 50s
    timeout server 450s

  frontend dashboard_front
    mode http
    bind *:80
    option httplog
    redirect scheme https code 301 if !{ ssl_fc }

  frontend dashboard_front_ssl
    mode tcp
    bind *:443
    option tcplog
    default_backend dashboard_back_ssl

  backend dashboard_back_ssl
    mode tcp
    option httpchk GET /
    http-check expect status 200
    server x HOST:PORT ssl check verify none
    server y HOST:PORT ssl check verify none
    server z HOST:PORT ssl check verify none

CephダッシュボードのREST APIは、PUT、POST、およびDELETEの各要求をCeph監査ログに記録できます。ログはデフォルトでは無効ですが、次のコマンドで有効にできます。

cephuser@adm > ceph dashboard set-audit-api-enabled true

ログが有効な場合、要求ごとに次のパラメータがログに記録されます。

次に、ログエントリの例を示します。

2019-02-06 10:33:01.302514 mgr.x [INF] [DASHBOARD] \
 from='https://[::ffff:127.0.0.1]:37022' path='/api/rgw/user/exu' method='PUT' \
 user='admin' params='{"max_buckets": "1000", "display_name": "Example User", "uid": "exu", "suspended": "0", "email": "user@example.com"}'

ヒント: 要求ペイロードのログの無効化

要求ペイロード(引数とその値のリスト)のログは、デフォルトで有効になっています。これは、次のコマンドを使用して無効にできます。

cephuser@adm > ceph dashboard set-audit-api-log-payload false

Cephダッシュボードは、CephFSまたはObject Gatewayをバックストアとして使用するNFS Ganeshaエクスポートを管理できます。ダッシュボードはCephFSクラスタのRADOSオブジェクトに保存されたNFS Ganeshaの設定ファイルを管理します。NFS Ganeshaは設定の一部をCephクラスタに保存する必要があります。

NFS Ganeshaの設定オブジェクトの場所を設定するには、次のコマンドを実行します。

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace pool_name[/namespace]

これで、Cephダッシュボードを使用してNFS Ganeshaのエクスポートを管理できます。

cephuser@adm > ceph dashboard set-ganesha-clusters-rados-pool-namespace cluster_id:pool_name[/namespace](,cluster_id:pool_name[/namespace])*

Cephダッシュボードのプラグインはダッシュボードの機能を拡張します。デバッグプラグインを使用すると、デバッグモードによってダッシュボードの動作をカスタマイズできるようになります。次のコマンドによって、デバッグモードの有効化、無効化、確認ができます。

cephuser@adm > ceph dashboard debug status
Debug: 'disabled'
cephuser@adm > ceph dashboard debug enable
Debug: 'enabled'
cephuser@adm > dashboard debug disable
Debug: 'disabled'

デフォルトでは、この機能は無効です。このモードは運用環境の展開に推奨される設定です。必要に応じて、再起動せずにデバッグモードを有効化できます。

ceph statusかceph -sを使用して、クラスタの直近の状態を確認できます。

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

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

ヒント: Cephによるデータ使用量の計算方法

usedの値は、未加工ストレージの実際の使用量を反映します。xxx GB / xxx GBの値は、クラスタの全体的なストレージ容量の利用可能な量(より少ない数)を意味します。名目上の数は、複製、クローン作成、またはスナップショット作成前の保存データのサイズを反映します。したがって、実際の保存データの量は名目上の量より大きくなるのが一般的です。Cephは、データのレプリカを作成し、クローンやスナップショットの作成にもストレージ容量を使用することがあるためです。

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

リアルタイムに更新された情報を取得するには、次のコマンドのいずれか(ceph -sを含む)をwatchコマンドの引数として実行します。

root # watch -n 10 'ceph -s'

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

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

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

ヒント

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

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

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

ヒント

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

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

クラスタのデータ使用量とプール間での分散を確認するには、ceph dfコマンドを使用します。詳細を取得するには、ceph df detailを使用します。

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

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

出力のPOOLSセクションには、プールのリストと各プールの名目上の使用量が表示されます。このセクションの出力には、レプリカ、クローン、またはスナップショットは反映されて「いません」。たとえば、1MBのデータを持つオブジェクトを保存した場合、名目上の使用量は1MBですが、実際の使用量は、レプリカ、クローン、およびスナップショットの数によっては2MB以上になることがあります。

注記

POOLSセクションの数字は名目上の数字です。レプリカ、スナップショット、またはクローンの数は含まれません。そのため、USEDの量や%USEDの量を合計しても、出力のRAW STORAGEセクションのRAW USEDの量や%RAW USEDの量にはなりません。

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

cephuser@adm > ceph osd stat

あるいは、

cephuser@adm > ceph osd dump

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

ceph osd treeコマンドを実行すると、CRUSHツリーと共に、ホスト、そのOSD、動作中かどうか、および重みが出力されます。

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

Cephでは、データが失われないようにするため、満杯のOSDに書き込むことはできません。運用クラスタでは、クラスタが満杯率に近付くと警告が表示されます。mon osd full ratioのデフォルトは0.95です。すなわち、容量の95%に達すると、クライアントによるデータの書き込みが停止されます。mon osd nearfull ratioのデフォルトは0.85です。すなわち、容量の85%に達するとヘルス警告が生成されます。

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

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

あるいは、

cephuser@adm > 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が満杯になると(ディスク領域の100%を使用すると)、通常は警告なしにすぐにクラッシュします。次に、OSDノードを管理する際に覚えておくべきヒントをいくつか示します。

• 各OSDのディスク領域(通常は/var/lib/ceph/osd/osd-{1,2..}にマウント)は、基礎となる専用のディスクまたはパーティションに配置する必要があります。

• Ceph設定ファイルを確認して、CephがOSD専用のディスク/パーティションにログファイルを保存しないようにします。

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

クラスタの起動後、最初にデータを読み書きする前に、Ceph Monitorの定数のステータスを確認します。クラスタがすでに要求を処理している場合は、Ceph Monitorのステータスを定期的に確認して、それらが実行されていることを確認します。

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

cephuser@adm > ceph mon stat

あるいは、

cephuser@adm > ceph mon dump

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

cephuser@adm > 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": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

配置グループはオブジェクトをOSDにマップします。配置グループを監視する場合、配置グループがactiveおよびcleanである必要があります。詳細については、12.9項 「OSDと配置グループの監視」を参照してください。

Cephストレージクラスタがその最大容量に近付くと、Cephは、データ損失を防止するための安全対策として、Ceph OSDに対して書き込みや読み込みを行えないようにします。したがって、運用クラスタをその満杯率に近付けることは、高可用性が犠牲になるため、適切な方法ではありません。デフォルトの満杯率は0.95、つまり容量の95%に設定されています。これは、OSDの数が少ないテストクラスタでは非常に積極的な設定です。

ヒント: ストレージ容量の増加

クラスタを監視する際には、nearfullの比率に関連する警告に注意してください。これは、1つ以上のOSDに障害が発生している場合に、複数のOSDに障害が発生すると、サービスが一時的に中断する可能性があることを意味します。OSDを追加してストレージ容量を増やすことを検討してください。

テストクラスタの一般的なシナリオには、システム管理者がCephストレージクラスタからCeph OSDを1つ削除して、クラスタの再バランスを監視することが含まれます。次に、別のCeph OSDを削除し、最終的にクラスタが満杯率に達してロックするまで削除を続けます。テストクラスタでも、何らかの容量計画を立てることをお勧めします。計画を立てることにより、高可用性を維持するために必要なスペア容量を見積もることができます。理想的には、Ceph OSDに一連の障害が発生した場合に、これらのCeph OSDをすぐに交換しなくてもクラスタがactive + cleanの状態に回復できるような計画を立てます。active + degradedの状態でクラスタを実行することはできますが、これは通常の動作条件には適しません。

次の図は、ホストあたり1つのCeph OSDが存在する33個のCephノードで構成されるシンプルなCephストレージクラスタを表していて、各ノードは3TBドライブに対して読み書きを行います。この例で使用するクラスタの実際の最大容量は99TBです。mon osd full ratioオプションは0.95に設定されています。クラスタの残り容量が5TBまで低下すると、クライアントはデータを読み書きできなくなります。したがって、このストレージクラスタの動作容量は、99TBではなく95TBです。

図 12.1: Cephクラスタ #

 

このようなクラスタで、1つまたは2つのOSDに障害が発生することはよくあります。それほど頻繁ではないものの妥当なシナリオとして、ラックのルータまたは電源装置に障害が発生して、同時に複数のOSD (OSD 7～12など)がダウンする状況があります。このようなシナリオでは、たとえ数台のホストと追加のOSDを早急に追加することになるとしても、稼働状態を維持してactive + clean状態を達成できるクラスタを目指す必要があります。容量使用率が高すぎても、データが失われることはありません。ただし、クラスタの容量使用率が満杯率を超える場合は、障害ドメイン内の停止を解決しても、データ可用性が犠牲になる可能性が依然としてあります。この理由のため、少なくとも大まかな容量計画を立てることをお勧めします。

クラスタの次の2つ数量を特定します。

クラスタの合計容量をクラスタのOSDの数で割ると、クラスタ内のOSDの平均容量がわかります。この平均容量に、通常の操作時に同時に障害が発生すると予想するODSの数(比較的少数)を掛けることを検討してください。最後に、クラスタの容量に満杯率を掛ると、最大動作容量が得られます。次に、妥当な満杯率に達しないと予想されるOSDのデータの量を引きます。OSD障害(OSDのラック)の数を増やして上の手順を繰り返し、ほぼ満杯率に近い妥当な数を得ます。

次の設定はクラスタの作成時にのみ適用され、その後OSDマップに保存されます。

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

ヒント

これらの設定はクラスタの作成中にのみ適用されます。後で、ceph osd set-nearfull-ratioコマンドとceph osd set-full-ratioコマンドを使用して、OSDマップで変更する必要があります。

ヒント: OSDの重みの確認

一部のOSDはnearfullであるのに他のOSDには十分な容量がある場合、nearfullのOSDのCRUSHの重みに問題がある可能性があります。

高可用性と高信頼性を実現するには、ハードウェアとソフトウェアの問題を管理する耐障害性を持つアプローチが必要です。Cephには単一障害点がなく、データに対する要求を「degraded」モードで処理できます。Cephのデータ配置には、データが特定のOSDアドレスに直接バインドされないようにする間接層が導入されています。つまり、システム障害を追跡するには、問題の根本にある配置グループとその基礎となるOSDを見つける必要があります。

ヒント: 障害が発生した場合のアクセス

クラスタの一部に障害が発生すると、特定のオブジェクトにアクセスできなくなる場合があります。これは、他のオブジェクトにアクセスできないという意味ではありません。障害が発生したら、OSDおよび配置グループを監視するための手順に従います。次にトラブルシューティングを開始します。

Cephは通常、自己修復します。ただし、問題が続く場合は、OSDと配置グループを監視すると問題を特定するのに役立ちます。

12.9.1 OSDの監視 #

 

OSDのステータスは、「クラスタ内」(「in」)または「クラスタ外」(「out」)のいずれかです。それと同時に、「稼働中」(「up」)または「ダウンしていて実行中でない」(「down」)のいずれかにもなります。OSDが「up」の場合、クラスタ内(データを読み書きできる)またはクラスタ外のいずれかの可能性があります。OSDがクラスタ内に存在していて、最近クラスタ外に移動した場合、Cephは配置グループを他のOSDに移行します。OSDがクラスタ外の場合、CRUSHは配置グループをOSDに割り当てません。OSDは、「down」の場合、「out」にもなります。

注記: 正常でない状態

OSDが「down」で「in」の場合は問題があり、クラスタは正常な状態ではありません。

ceph health、ceph -s、ceph -wなどのコマンドを実行する場合、クラスタは常にHEALTH OKをエコーバックするわけではないことに気付くことがあります。OSDに関しては、次の状況ではクラスタがHEALTH OKをエコーしないことを予期する必要があります。

• まだクラスタを起動していない(クラスタは応答しない)。

• クラスタを起動または再起動したが、配置グループは作成中で、OSDはピアリングプロセス中であるため、まだ準備ができていない。

• OSDを追加または削除した。

• クラスタマップを変更した。

OSDの監視の重要な側面は、クラスタが稼働中であるときに、クラスタ内のすべてのOSDも稼働中であることを確認することです。すべてのOSDが実行中であるかどうかを確認するには、次のコマンドを実行します。

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

この結果から、OSDの合計数(x)、「up」のOSDの数(y)、「in」のOSDの数(z)、およびマップのエポック(eNNNN)がわかります。クラスタ内にある「in」のOSDの数が「up」であるOSDの数より多い場合は、次のコマンドを実行して、実行中でないceph-osdデーモンを特定します。

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

たとえば、IDが1のOSDがdownしている場合は、次のコマンドを実行して起動します。

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

停止しているOSDや再起動しないOSDに関連する問題については、Book “Troubleshooting Guide”, Chapter 4 “Troubleshooting OSDs”, Section 4.3 “OSDs not running”を参照してください。

12.9.2 配置グループセットの割り当て #

 

CRUSHが配置グループをOSDに割り当てる場合、CRUSHはプールのレプリカの数を確認し、配置グループの各レプリカが異なるOSDに割り当てられるように配置グループをOSDに割り当てます。たとえば、プールに配置グループのレプリカが3つ必要な場合、CRUSHはこれらをそれぞれosd.1、osd.2、osd.3に割り当てることがあります。CRUSHは実際には、CRUSHマップで設定した障害ドメインを考慮した擬似的にランダムな配置にしようとします。そのため、大規模なクラスタで複数の配置グループが最も近隣にあるOSDに割り当てられることはほとんどありません。特定の配置グループのレプリカを含む必要があるOSDのセットを「動作セット」と呼びます。動作セットのOSDがダウンしているか、または他の理由で配置グループのオブジェクトの要求を処理できない場合があります。このような状況が生じた場合は、次のシナリオの1つに一致する可能性があります。

• OSDを追加または削除した。これにより、CRUSHが配置グループを他のOSDに再割り当てしたため、「動作セット」の構成が変更され、「バックフィル」プロセスによってデータのマイグレーションが実行された。

• OSDが「down」状態であったため再起動され、現在回復中である。

• 「動作セット」のOSDが「down」状態であるか、要求を処理できないため、別のOSDが一時的にその権限を引き継いだ。

  Cephは、要求を実際に処理するOSDのセットである「アップセット」を使用してクライアント要求を処理します。ほとんどの場合、「アップセット」と「動作セット」は事実上同一です。これらが同一ではない場合、Cephがデータを移行中であるか、OSDが回復中であるか、または問題があることを示している場合があります(たとえば、このようなシナリオでは、Cephでは通常HEALTH WARN状態と「stuck stale」メッセージをエコーします)。

配置グループのリストを取得するには、次のコマンドを実行します。

cephuser@adm > ceph pg dump

指定した配置グループの「動作セット」または「アップセット」内にあるOSDを表示するには、次のコマンドを実行します。

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

この結果から、osdmapエポック(eNNN)、配置グループの数(PG_NUM)、「アップセット」(「up」)のOSD、および「動作セット」(「acting」)のOSDがわかります。

ヒント: クラスタの問題の指標

「アップセット」と「動作セット」が一致しない場合、これはクラスタの再バランスそのものか、クラスタの潜在的な問題の指標である可能性があります。

12.9.3 ピアリング #

 

配置グループにデータを書き込む場合、データの状態はactiveでなければならず、さらにclean状態である必要があります。Cephが配置グループの現在の状態を判断するために、配置グループのプライマリOSD (「動作セット」の最初のOSD)は、セカンダリおよび3番目のOSDとピアリングして、配置グループの現在の状態に関する合意を確立します(PGの3つのレプリカがプールにあることを想定)。

図 12.2: ピアリングスキーマ #

 

12.9.4 配置グループの状態の監視 #

 

ceph health、ceph -s、ceph -wなどのコマンドを実行する場合、クラスタは常にHEALTH OKメッセージをエコーバックするわけでないことに気付くことがあります。OSDが実行中であるかどうかを確認した後で、配置グループの状態も確認する必要があります。

配置グループのピアリングに関係する次のような多くの状況では、クラスタはHEALTH OKをエコー「しない」ことを予期してください。

• プールを作成したが、配置グループはまだピアリングされていない。

• 配置グループが回復中である。

• クラスタにOSDを追加したか、クラスタからOSDを削除した。

• CRUSHマップを変更したが、配置グループは移行中である。

• 配置グループの異なるレプリカに整合性のないデータがある。

• Cephが配置グループのレプリカをスクラブしている。

• Cephにバックフィル操作を完了するための十分なストレージ容量がない。

上のいずれかの状況でCephがHEALTH WARNをエコーしても慌てないでください。多くの場合、クラスタは単独で回復します。場合によっては、対処が必要です。配置グループの監視の重要な側面は、クラスタが稼働しているときに、すべての配置グループが「active」であり、できれば「clean」状態であることを確認することです。すべての配置グループのステータスを確認するには、次のコマンドを実行します。

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

この結果から、配置グループの合計数(x)、特定の状態(「active+clean」など)である配置グループの数(y)、および保存データの量(z)がわかります。

配置グループの状態に加えて、Cephでは、使用済みのストレージ容量(aa)、残りのストレージ容量(bb)、および配置グループの合計ストレージ容量もエコーバックされます。次のようないくつかのケースでは、これらの数値が重要になる可能性があります。

• near full ratioまたはfull ratioに達しつつある。

• CRUSH設定のエラーのため、データがクラスタ間で分散されている。

ヒント: 配置グループID

配置グループIDは、プール番号(プール名ではない)、それに続くピリオド(.)、および配置グループID (16進数)で構成されます。プール番号とプールの名前は、ceph osd lspoolsの出力で参照できます。たとえば、デフォルトのプールrbdはプール番号0に対応します。完全修飾形式の配置グループIDは次の形式です。

POOL_NUM.PG_ID

これは通常、次のようになります。

0.1f

配置グループのリストを取得するには、次のコマンドを実行します。

cephuser@adm > ceph pg dump

出力をJSON形式でフォーマットしてファイルに保存することもできます。

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

特定の配置グループに対してクエリを実行するには、次のコマンドを実行します。

cephuser@adm > ceph pg POOL_NUM.PG_ID query

次のリストでは、配置グループの一般的な状態について詳しく説明します。

作成中

プールを作成すると、指定した数の配置グループが作成されます。Cephは、1つ以上の配置グループを作成している場合に「creating」をエコーします。配置グループが作成されると、その配置グループの「動作セット」に属するOSDがピアリングされます。ピアリングが完了したら、配置グループのステータスは「active+clean」になります。これは、Cephクライアントがその配置グループへの書き込みを開始できることを意味します。

図 12.3: 配置グループのステータス #

 

ピアリング

Cephは、配置グループのピアリング中に、配置グループのレプリカを保存するOSDを、その配置グループ内にあるオブジェクトとメタデータの状態について合意状態にします。つまり、Cephがピアリングを完了すると、その配置グループを保存するOSDは配置グループの現在の状態に関して合意したことになります。ただし、ピアリングプロセスが完了しても、各レプリカの内容が最新であるという意味には「なりません」。

注記: 信頼できる履歴

Cephでは、「動作セット」のすべてのOSDが書き込み操作を永続化するまで、クライアントへの書き込み操作を確認「しません」。この動作により、ピアリング操作が最後に正常に完了した後に確認されたすべての書き込み操作のレコードが、「動作セット」の少なくとも1つのメンバーに確実に存在するようになります。

確認された書き込み操作それぞれの正確なレコードにより、Cephは、配置グループの信頼できる新しい履歴を構築および拡張できます。この履歴には、一連の操作の順序が完全かつ全面的に記録されているため、この履歴を実行すれば、配置グループのOSDのコピーを最新の状態にすることができます。

アクティブ

Cephがピアリングプロセスを完了すると、配置グループはactiveになります。active状態とは、プライマリ配置グループとレプリカで配置グループのデータを読み込み操作と書き込み操作に一般的に使用できることを意味します。

クリーン

配置グループがclean状態である場合、プライマリOSDとレプリカOSDは正常にピアリングされていて、その配置グループに未処理のレプリカは存在しません。配置グループ内のすべてのオブジェクトは、Cephによって正確な回数複製されています。

DEGRADED

クライアントがプライマリOSDにオブジェクトを書き込む場合、プライマリOSDが、レプリカをレプリカOSDに書き込む責任を持ちます。プライマリOSDがオブジェクトをストレージに書き込んだ後も、配置グループは「degraded」状態のままです。この状態は、Cephがレプリカオブジェクトを正常に作成したという確認をプライマリOSDがレプリカOSDから受け取るまで続きます。

配置グループが「active+degraded」になる可能性がある理由は、OSDにまだオブジェクトがすべて格納されていなくてもOSDが「active」になる可能性があるためです。OSDがダウンした場合、CephはそのOSDに割り当てられた各配置グループを「degraded」としてマークします。OSDが稼働状態に戻ったら、OSDをもう一度ピアリングする必要があります。ただし、「degraded」状態の配置グループが「active」であれば、クライアントは引き続きその配置グループに新しいオブジェクトを書き込むことができます。

OSDが「down」で、「degraded」状態が解決しない場合、Cephは、ダウンしているOSをクラスタの「out」としてマークし、「down」状態のOSDから別のOSDにデータを再マップします。「down」とマークされてから「out」とマークされるまでの時間は、mon osd down out intervalオプションで制御します。デフォルトでは600秒に設定されています。

配置グループに含める必要がある1つ以上のオブジェクトをCephが見つけることができないという理由で、配置グループが「degraded」状態になる可能性もあります。見つからないオブジェクトに対して読み書きを行うことはできませんが、「degraded」状態の配置グループ内にある他のすべてのオブジェクトには今までどおりアクセスできます。

回復中

Cephは、ハードウェアやソフトウェアの問題が継続している場合に大規模な耐障害性を実現するように設計されています。OSDが「down」になった場合、その内容が、配置グループ内にある他のレプリカの現在の状態よりも遅れることがあります。OSDが「up」に戻ったら、現在の状態を反映するように配置グループの内容を更新する必要があります。その間、OSDに「recovering」状態が反映される場合があります。

ハードウェアの障害によって複数のOSDのカスケード障害が発生する可能性があるため、回復は常に簡単であるとは限りません。たとえば、ラックまたはキャビネットのネットワークスイッチに障害が発生することがあります。これにより、多数のホストマシンのOSDがクラスタの現在の状態より遅れる可能性があります。障害が解決されたら、各OSDを回復する必要があります。

Cephには、新しいサービス要求と、データオブジェクトを回復して配置グループを現在の状態に復元する必要性との間のリソース競合のバランスを取るための設定が多数用意されています。osd recovery delay start設定を使用すると、回復プロセスを開始する前に、OSDを再起動して再ピアリングを行い、さらに一部の再生要求を処理することもできます。osd recovery thread timeoutは、スレッドのタイムアウトを設定します。これは、複数のOSDが失敗した場合に、時間差で再起動および再ピアリングするためです。osd recovery max active設定は、OSDが同時に処理する回復要求の数を制限して、OSDが要求を処理できなくなるのを防ぎます。osd recovery max chunk設定は、回復されたデータチャンクのサイズを制限し、ネットワークの輻輳を防ぎます。

バックフィル

新しいOSDがクラスタに参加すると、CRUSHは、クラスタ内のOSDから、新しく追加されたOSDに配置グループを再割り当てします。再割り当てされた配置グループをただちに受け入れるよう新しいOSDに強制すると、新しいOSDに過度な負荷がかかる可能性があります。OSDに配置グループをバックフィルすることで、このプロセスをバックグラウンドで開始できます。バックフィルが完了して準備が整ったら、新しいOSDは処理を開始します。

バックフィル操作中に、次のいずれかの状態が表示されることがあります。「backfill_wait」は、バックフィル操作が保留中で、まだ進行中ではないことを示します。「backfill」は、バックフィル操作が進行中であることを示します。「backfill_too_full」は、バックフィル操作が要求されたものの、ストレージ容量が十分でないため完了できなかったことを示します。配置グループをバックフィルできない場合、「incomplete」と見なされることがあります。

Cephには、配置グループをOSD (特に新しいOSD)に再割り当てすることに伴う負荷を管理するための設定が多数用意されています。デフォルトでは、osd max backfillsは、OSDに対する同時バックフィルの最大数を10に設定します。backfill full ratioを使用すると、OSDがその満杯率(デフォルトでは90%)に近付いている場合にバックフィル要求を拒否できます。変更するには、ceph osd set-backfillfull-ratioコマンドを使用します。OSDがバックフィル要求を拒否する場合、osd backfill retry intervalを使用すると、OSDは要求を再試行できます(デフォルトでは10秒後)。OSDにosd backfill scan minおよびosd backfill scan maxを設定して、スキャン間隔を管理することもできます(デフォルトでは64と512)。

REMAPPED (再マップ)

配置グループの変更を処理する「動作セット」が変更されると、古い「動作セット」から新しい「動作セット」にデータが移行されます。新しいプライマリOSDが要求を処理するまでにしばらく時間がかかる場合があります。そのため、配置グループのマイグレーションが完了するまで、古いプライマリに対して引き続き要求を処理するよう求めることができます。データマイグレーションが完了したら、新しい「動作セット」のプライマリOSDがマッピングで使用されます。

STALE

Cephは、ハートビートを使用して、ホストとデーモンが確実に実行されるようにしていますが、ceph-osdデーモンが「stuck」状態になり、統計情報がタイムリーにレポートされないこともあります(たとえば、一時的なネットワーク障害)。デフォルトでは、OSDデーモンはその配置グループ、およびブートと障害の統計情報を0.5秒ごとにレポートします。これは、ハートビートのしきい値よりも高い頻度です。配置グループの「動作セット」のプライマリOSDがモニターにレポートしない場合、または他のOSDが、プライマリOSDが「down」しているとレポートした場合、モニターは配置グループを「stale」としてマークします。

クラスタの起動時には、ピアリングプロセスが完了するまで「stale」状態が表示されることがよくあります。クラスタがしばらく動作した後で配置グループが「stale」状態になっている場合は、その配置グループのプライマリOSDがダウンしているか、配置グループの統計情報をモニターにレポートしていないことを示します。

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

cephuser@adm > rados -p data ls

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

cephuser@adm > rados rm test-object-1 --pool=data

既存のCephクラスタの設定を変更するには、次の手順に従います。

Cephクラスタに新しいノードを追加するには、次の手順に従います。

ヒント: OSDの削除

削除しようとしているノードがOSDを実行している場合、まずOSDを削除してからそのノード上でOSDが実行されていないことを確認してください。OSDを削除する方法の詳細については、13.4.4項 「OSDの削除」を参照してください。

クラスタからノードを削除するには、次の手順に従います。

重要

障害イベント中で、削除しようとしているミニオンが永続的な電源オフ状態である場合、Salt Masterからノードを削除する必要があります。

root@master # salt-key -d minion_id

その後、pillar_root/ceph-salt.slsからノードを手動で削除します。このファイルは通常、/srv/pillar/ceph-salt.slsに置かれています。

このセクションではCephクラスタにOSDを追加、消去、削除する方法を説明します。

cephuser@adm > ceph orch device ls
HOST       PATH      TYPE SIZE  DEVICE  AVAIL REJECT REASONS
ses-master /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vda  hdd  42.0G         False locked
ses-min1   /dev/vdb  hdd  8192M  387836 False locked, LVM detected, Insufficient space (<5GB) on vgs
ses-min2   /dev/vdc  hdd  8192M  450575 True

13.4.2 ディスクデバイスの消去 #

 

ディスクデバイスを再利用するには、まず内容を消去する必要があります。

ceph orch device zap HOST_NAME DISK_DEVICE

例:

cephuser@adm > ceph orch device zap ses-min2 /dev/vdc

注記

unmanagedフラグが設定されておらず、以前OSDを展開した際にDriveGroupsまたは--all-available-devicesオプションを使用していた場合、消去後にcephadmが自動的にこれらのOSDを展開します。

13.4.3 DriveGroups仕様を用いたOSDの追加 #

 

「DriveGroups」では、CephクラスタのOSDのレイアウトを指定します。レイアウトは単独のYAMLファイルで定義します。このセクションでは、例としてdrive_groups.ymlを使用します。

管理者は、相互に関連するOSDのグループ(HDDとSSDの混成環境に展開されるハイブリッドOSD)を手動で指定するか、同じ展開オプション(たとえば、同じオブジェクトストア、同じ暗号化オプション、スタンドアロンOSDなど)を共有する必要があります。デバイスが明示的に一覧にされないようにするため、DriveGroupsでは、ceph-volumeインベントリレポートで選択した数個のフィールドに対応するフィルタ項目のリストを使用します。cephadmでは、これらのDriveGroupsを実際のデバイスリストに変換してユーザが調べられるようにするコードを提供します。

OSDの仕様をクラスタに適用するには、次のコマンドを実行します。

cephuser@adm > ceph orch apply osd -i drive_groups.yml

アクションのプレビューを確認する場合や、アプリケーションをテストする場合には、--dry-runオプションを付加したceph orch apply osdコマンドを使用できます。次に例を示します。

cephuser@adm > ceph orch apply osd -i drive_groups.yml --dry-run
...
+---------+------+------+----------+----+-----+
|SERVICE  |NAME  |HOST  |DATA      |DB  |WAL  |
+---------+------+------+----------+----+-----+
|osd      |test  |mgr0  |/dev/sda  |-   |-    |
|osd      |test  |mgr0  |/dev/sdb  |-   |-    |
+---------+------+------+----------+----+-----+

--dry-runの出力が想定通りなら、--dry-runオプションを外して再度コマンドを実行するだけです。

13.4.3.1 アンマネージドOSD #

 

DriveGroups仕様と一致する、利用可能なすべてのクリーンディスクデバイスは、クラスタに追加すると自動的にOSDとして使用されます。この動作を「マネージド」モードと呼びます。

「マネージド」モードを無効化するには、unmanaged: true行を関連する仕様に追加してください。次に例を示します。

service_type: osd
service_id: example_drvgrp_name
placement:
 hosts:
 - ses-min2
 - ses-min3
encrypted: true
unmanaged: true

ヒント

すでに展開済みのOSDを「マネージド」モードから「アンマネージド」モードに切り替えるには、13.1項 「クラスタ設定の変更」で説明した手順の中でunmanaged: true行を追加してください。

13.4.3.2 DriveGroups仕様 #

 

DriveGroups仕様ファイルの例を次に示します。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  drive_spec: DEVICE_SPECIFICATION
db_devices:
  drive_spec: DEVICE_SPECIFICATION
wal_devices:
  drive_spec: DEVICE_SPECIFICATION
block_wal_size: '5G'  # (optional, unit suffixes permitted)
block_db_size: '5G'   # (optional, unit suffixes permitted)
encrypted: true       # 'True' or 'False' (defaults to 'False')

注記

かつてのDeepSeaで「encryption」と呼ばれていたオプションは、「encrypted」に名前が変更されました。SUSE Enterprise Storage 7にDriveGroupに適用する場合は、サービス仕様にこの新しい用語が使われているかを確認してください。さもなければ、ceph orch apply操作は失敗します。

13.4.3.3 一致するディスクデバイス #

 

次のフィルタを使用して指定を記述できます。

• ディスクモデル別。

  model: DISK_MODEL_STRING

• ディスクベンダー別。

  vendor: DISK_VENDOR_STRING

  

  ヒント

  DISK_VENDOR_STRINGは必ず小文字で入力してください。

  ディスクモデルとディスクベンダーの詳細を取得するには、次のコマンドの出力を確認してください。

  cephuser@adm > ceph orch device ls
  HOST     PATH     TYPE  SIZE DEVICE_ID                  MODEL            VENDOR
  ses-min1 /dev/sdb ssd  29.8G SATA_SSD_AF34075704240015  SATA SSD         ATA
  ses-min2 /dev/sda ssd   223G Micron_5200_MTFDDAK240TDN  Micron_5200_MTFD ATA
  [...]

• ディスクが回転型かどうか。SSDとNVMeドライブは回転型ではありません。

  rotational: 0

• OSDで使用可能な「すべての」ドライブを使用してノードを展開します。

  data_devices:
    all: true

• また、一致するディスクの数を制限します。

  limit: 10

13.4.3.4 サイズによるデバイスのフィルタリング #

 

ディスクデバイスをサイズでフィルタできます(正確なサイズ、またはサイズの範囲)。size:パラメータには、次の形式の引数を指定できます。

• '10G' -正確にこのサイズのディスクを含めます。

• '10G:40G' - この範囲内のサイズのディスクを含めます。

• ':10G' - サイズが10GB以下のディスクを含めます。

• '40G:' - サイズが40GB以上のディスクを含めます。

例 13.1: ディスクサイズによる一致 #

 

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '40TB:'
db_devices:
  size: ':2TB'

注記: 引用符が必要

区切り文字「:」を使用する場合は、サイズを引用符で囲む必要があります。そうしないと、「:」記号は新しい設定のハッシュであると解釈されます。

ヒント: 単位のショートカット

ギガバイト(G)の代わりに、メガバイト(M)やテラバイト(T)でもサイズを指定できます。

13.4.3.5 DriveGroupsの例 #

 

このセクションでは、さまざまなOSDセットアップの例を示します。

例 13.2: 単純なセットアップ #

 

この例では、同じセットアップを使用する2つのノードについて説明します。

• 20台のHDD

  • ベンダー: Intel

  • モデル: SSD-123-foo

  • サイズ: 4TB

• 2台のSSD

  • ベンダー: Micron

  • モデル: MC-55-44-ZX

  • サイズ: 512GB

対応するdrive_groups.ymlファイルは次のようになります。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: MC-55-44-XZ

このような設定は単純で有効です。問題は、管理者が将来、別のベンダーのディスクを追加することがあっても、それらのディスクが含まれない点です。この設定を向上させるには、ドライブのコアプロパティのフィルタを減らします。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

前の例では、回転型デバイスはすべて「データデバイス」として宣言し、非回転型デバイスはすべて「共有デバイス」(wal、db)として使用します。

2TBを超えるドライブが常に低速のデータデバイスであることがわかっている場合は、サイズでフィルタできます。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  size: '2TB:'
db_devices:
  size: ':2TB'

例 13.3: 詳細セットアップ #

 

この例では、2つの別個のセットアップについて説明します。20台のHDDで2台のSSDを共有するセットアップと、10台のSSDで2台のNVMeを共有するセットアップです。

• 20台のHDD

  • ベンダー: Intel

  • モデル: SSD-123-foo

  • サイズ: 4TB

• 12台のSSD

  • ベンダー: Micron

  • モデル: MC-55-44-ZX

  • サイズ: 512GB

• 2つのNVMe

  • ベンダー: Samsung

  • モデル: NVME-QQQQ-987

  • サイズ: 256GB

このようなセットアップは、次のような2つのレイアウトで定義できます。

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ

service_type: osd
service_id: example_drvgrp_name2
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  vendor: samsung
  size: 256GB

例 13.4: 不均一なノードを使用した詳細セットアップ #

 

前の例では、すべてのノードに同じドライブがあることを想定しています。ただし、常にこれが当てはまるとは限りません。

ノード1～5:

• 20台のHDD

  • ベンダー: Intel

  • モデル: SSD-123-foo

  • サイズ: 4TB

• 2台のSSD

  • ベンダー: Micron

  • モデル: MC-55-44-ZX

  • サイズ: 512GB

ノード6～10:

• 5つのNVMe

  • ベンダー: Intel

  • モデル: SSD-123-foo

  • サイズ: 4TB

• 20台のSSD

  • ベンダー: Micron

  • モデル: MC-55-44-ZX

  • サイズ: 512GB

レイアウトに「target」キーを使用して、特定のノードをターゲットに設定できます。Saltのターゲット表記を使用すると、内容をシンプルに保つことができます。

service_type: osd
service_id: example_drvgrp_one2five
placement:
  host_pattern: 'node[1-5]'
data_devices:
  rotational: 1
db_devices:
  rotational: 0

続いて以下を設定します。

service_type: osd
service_id: example_drvgrp_rest
placement:
  host_pattern: 'node[6-10]'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo

例 13.5: エキスパートセットアップ #

 

前の事例はすべて、WALとDBが同じデバイスを使用することを想定していました。ただし、WALを専用のデバイスに展開することもできます。

• 20台のHDD

  • ベンダー: Intel

  • モデル: SSD-123-foo

  • サイズ: 4TB

• 2台のSSD

  • ベンダー: Micron

  • モデル: MC-55-44-ZX

  • サイズ: 512GB

• 2つのNVMe

  • ベンダー: Samsung

  • モデル: NVME-QQQQ-987

  • サイズ: 256GB

service_type: osd
service_id: example_drvgrp_name
placement:
  host_pattern: '*'
data_devices:
  model: MC-55-44-XZ
db_devices:
  model: SSD-123-foo
wal_devices:
  model: NVME-QQQQ-987

例 13.6: 複雑な(可能性が低い)セットアップ #

 

次のセットアップでは、以下を定義してみます。

• 1つのNVMeを利用する20台のHDD

• 1台のSSD (db)と1つのNVMe (wal)を利用する2台のHDD

• 1つのNVMeを利用する8台のSSD

• 2台SSDスタンドアロン(暗号化)

• 1台のHDDはスペアで、展開しない

使用するドライブの概要は次のとおりです。

• 23台のHDD

  • ベンダー: Intel

  • モデル: SSD-123-foo

  • サイズ: 4TB

• 10台のSSD

  • ベンダー: Micron

  • モデル: MC-55-44-ZX

  • サイズ: 512GB

• 1つのNVMe

  • ベンダー: Samsung

  • モデル: NVME-QQQQ-987

  • サイズ: 256GB

DriveGroupsの定義は次のようになります。

service_type: osd
service_id: example_drvgrp_hdd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_hdd_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  rotational: 0
db_devices:
  model: MC-55-44-XZ
wal_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_ssd_nvme
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
db_devices:
  model: NVME-QQQQ-987

service_type: osd
service_id: example_drvgrp_standalone_encrypted
placement:
  host_pattern: '*'
data_devices:
  model: SSD-123-foo
encrypted: True

ファイルが上から下へ解析されると、HDDが1台残ります。