5 cephadmによる展開 #
SUSE Enterprise Storage 7はSaltベースのceph-saltツールを使用して、参加している各クラスタノードのオペレーティングシステムをcephadmを介した展開用に準備します。cephadmはSSHを介してCeph Managerデーモンからホストに接続してCephクラスタを展開、管理します。cephadmはCephクラスタのライフサイクル全体を管理します。ライフサイクルは単独のノード(1つのMONおよびMGRサービス)に小規模なクラスタをブートストラップすることから始まります。その後、オーケストレーションインターフェイスを使用して、クラスタをすべてのホストを含むように拡張するとともに、Cephサービスをすべてプロビジョニングします。この作業はCeph CLI(コマンドラインインターフェイス)から実施できます。一部はCephダッシュボード(GUI)からも行えます。
Cephコミュニティのドキュメントでは、最初の展開の際にcephadm bootstrapコマンドを使用していることに注意してください。cephadm bootstrapコマンドはceph-saltから呼び出されます。直接実行しないでください。cephadm bootstrapを使用する手動のCephクラスタ展開はサポートされていません。
cephadmを使用してCephクラスタを展開するには、以下のタスクを実行する必要があります。
すべてのクラスタノードで、ベースとなるオペレーティングシステム(SUSE Linux Enterprise Server 15 SP2)のインストールと基本的な設定を行います。
ceph-saltを介した初期展開の準備のために、すべてのクラスタノードにSaltインフラストラクチャを展開します。ceph-salt経由でクラスタの基本的なプロパティを設定し、展開します。cephadmを使用してクラスタに新しいノードと役割を追加し、サービスを展開します。
5.1 SUSE Linux Enterprise Serverのインストールと設定 #
各クラスタノードでSUSE Linux Enterprise Server 15 SP2のインストールと登録を行います。SUSE Enterprise Storageのインストール中にアップデートリポジトリへのアクセスが必要なため、登録は必須です。最低でも、次のモジュールを導入します。
Basesystem Module
Server Applications Module
SUSE Linux Enterprise Serverのインストール方法の詳細については、https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-install.htmlを参照してください。
各クラスタノードに「SUSE Enterprise Storage 7」の拡張機能をインストールします。
ヒント: SUSE Linux Enterprise Serverと共にSUSE Enterprise StorageをインストールするSUSE Enterprise Storage 7の拡張機能は、SUSE Linux Enterprise Server 15 SP2のインストール後に分けてインストールすることも、SUSE Linux Enterprise Server 15 SP2のインストール手順の中で追加することもできます。
拡張機能のインストール方法の詳細については、https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-register-sle.htmlを参照してください。
ネットワークを設定します。各ノードでDNS名が適切に解決されるようにする設定も含まれます。ネットワークの設定の詳細については、https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-network.html#sec-network-yastを参照してください。DNSサーバの設定の詳細については、https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-dns.htmlを参照してください。
5.2 Saltの展開 #
SUSE Enterprise Storageは最初のクラスタの準備にSaltとceph-saltを使用します。Saltを使用すると、「Salt Master」と呼ばれる単独の専用ホストから複数のクラスタノードに対して、同時に設定やコマンドを実行できます。Saltの展開前に、次の重要な点を考慮してください。
「Salt Minion」は、Salt Masterと呼ばれる専用のノードによって制御されるノードです。
仮にSalt MasterホストがCephクラスタの一部である場合は、独自のSalt Minionを実行する必要があります。ただしこれは必須ではありません。
ヒント: 1つのサーバで複数の役割を共有各役割を別個のノードに展開すると、Cephクラスタで最適なパフォーマンスを実現できます。しかし、実際の展開では、1つのノードを複数の役割のために共有しなければならない場合があります。パフォーマンスやアップグレード手順で問題が起きないようにするため、Ceph OSD、メタデータサーバ、またはCeph Monitorの役割は管理ノードに展開しないでください。
Salt Minionは、ネットワークでSalt Masterのホスト名を正しく解決する必要があります。Salt Minionは、デフォルトでは
saltというホスト名を検索しますが、ネットワーク経由でアクセス可能なほかのホスト名を/etc/salt/minionファイルで指定できます。
Salt Masterノードに
salt-masterをインストールします。root@master #zypper in salt-mastersalt-masterサービスが有効になっていて起動していることを確認します。必要であれば、サービスを有効にして起動します。root@master #systemctl enable salt-master.serviceroot@master #systemctl start salt-master.serviceファイアウォールを使用する場合は、Salt Masterノードのポート4505と4506がすべてのSalt Minionノードに対して開いていることを確認します。これらのポートが閉じている場合は、
yast2 firewallコマンドを使用してポートを開き、サービスに適切なゾーンを許可できます。たとえば、publicを許可します。パッケージ
salt-minionをすべてのミニオンノードにインストールします。root@minion >zypper in salt-minion/etc/salt/minionを編集し、次の行のコメントを解除します。#log_level_logfile: warning
warningログレベルをinfoに変更します。
注記:log_level_logfileとlog_levellog_levelは、どのログメッセージが画面に表示されるかを制御します。一方、log_level_logfileは、どのログメッセージが/var/log/salt/minionに書き込まれるかを制御します。注記「すべて」のクラスタ(ミニオン)ノードのログレベルを変更したか確認してください。
すべてのノードが他のノードの「完全修飾ドメイン名」をパブリッククラスタネットワークのIPアドレスに解決できることを確認します。
すべてのミニオンをマスターに接続するように設定します。ホスト名
saltでSalt Masterに接続できない場合は、ファイル/etc/salt/minionを編集するか、次の内容で新しいファイル/etc/salt/minion.d/master.confを作成します。master: host_name_of_salt_master
先に説明した設定ファイルを変更した場合は、すべての関連するSalt MinionのSaltサービスを再起動します。
root@minion >systemctl restart salt-minion.serviceすべてのノードで
salt-minionサービスが有効になっていて起動していることを確認します。必要であれば、次のコマンドを使用して有効にして起動します。root #systemctl enable salt-minion.serviceroot #systemctl start salt-minion.service各Salt Minionの指紋を確認して、指紋が一致する場合、Salt Master上のすべてのSaltキーを受諾します。
注記Salt Minionの指紋が空に戻る場合は、Salt MinionがSalt Masterの設定を持っていて、Salt Masterと通信できることを確認します。
各ミニオンの指紋を表示します。
root@minion >salt-call --local key.finger local: 3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...すべてのSalt Minionの指紋を収集した後、Salt Master上の、受諾されていない全ミニオンキーの指紋を一覧にします。
root@master #salt-key -F [...] Unaccepted Keys: minion1: 3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...ミニオンの指紋が一致する場合は、それらを受諾します。
root@master #salt-key --accept-allキーが受諾されたことを確認します。
root@master #salt-key --list-allすべてのSalt Minionが応答するかテストします。
root@master #salt-run manage.status
5.3 Cephクラスタの展開 #
このセクションでは、基本的なCephクラスタを展開する一連のプロセスを説明します。以下のサブセクションをよく読んで、記載されているコマンドを記載されている順番で実行してください。
5.3.1 ceph-saltのインストール #
ceph-saltはcephadmに管理されるCephクラスタを展開するためのツールを提供します。ceph-saltはSaltインフラストラクチャを使用して、OSの管理(たとえば、ソフトウェアアップデートや時刻の同期)や、Salt Minionの役割の定義を行います。
Salt Master上で ceph-salt パッケージをインストールします。
root@master # zypper install ceph-salt
このコマンドは ceph-salt-formula を依存関係としてインストールします。この依存関係により、/etc/salt/master.dディレクトリに追加のファイルを挿入することで、Salt Masterの設定が変更されます。変更を適用するには、salt-master.serviceを再起動し、Saltモジュールを同期させます。
root@master #systemctl restart salt-master.serviceroot@master #salt \* saltutil.sync_all
5.3.2 クラスタプロパティの設定 #
ceph-salt configコマンドを使用して、クラスタの基本的なプロパティを設定します。
/etc/ceph/ceph.confファイルは、cephadmで管理されており、ユーザは編集しないでください。Cephの設定パラメータは、新しいceph configコマンドを使用して設定する必要があります。詳細については、28.2項 「設定データベース」を参照してください。
5.3.2.1 ceph-saltシェルの使用 #
ceph-salt configをパスやサブコマンドを使わずに実行する場合、インタラクティブなceph-saltシェルを入力します。このシェルは、1つのバッチで複数のプロパティを設定する必要がありますが、完全なコマンド構文を入力したくない場合に便利です。
root@master #ceph-salt config/>ls o- / ............................................................... [...] o- ceph_cluster .................................................. [...] | o- minions .............................................. [no minions] | o- roles ....................................................... [...] | o- admin .............................................. [no minions] | o- bootstrap ........................................... [no minion] | o- cephadm ............................................ [no minions] | o- tuned ..................................................... [...] | o- latency .......................................... [no minions] | o- throughput ....................................... [no minions] o- cephadm_bootstrap ............................................. [...] | o- advanced .................................................... [...] | o- ceph_conf ................................................... [...] | o- ceph_image_path .................................. [ no image path] | o- dashboard ................................................... [...] | | o- force_password_update ................................. [enabled] | | o- password ................................................ [admin] | | o- ssl_certificate ....................................... [not set] | | o- ssl_certificate_key ................................... [not set] | | o- username ................................................ [admin] | o- mon_ip .................................................. [not set] o- containers .................................................... [...] | o- registries_conf ......................................... [enabled] | | o- registries .............................................. [empty] | o- registry_auth ............................................... [...] | o- password .............................................. [not set] | o- registry .............................................. [not set] | o- username .............................................. [not set] o- ssh ............................................... [no key pair set] | o- private_key .................................. [no private key set] | o- public_key .................................... [no public key set] o- time_server ........................... [enabled, no server host set] o- external_servers .......................................... [empty] o- servers ................................................... [empty] o- subnet .................................................. [not set]
ceph-saltのlsコマンドの出力を見るとわかるように、クラスタ構成がツリー構造に整理されます。ceph-saltシェルに含まれる、クラスタの特定のプロパティを設定するには、次の2つのオプションがあります。
現在位置からコマンドを実行し、第1引数としてプロパティへの絶対パスを入力する
/>/cephadm_bootstrap/dashboard ls o- dashboard ....................................................... [...] o- force_password_update ..................................... [enabled] o- password .................................................... [admin] o- ssl_certificate ........................................... [not set] o- ssl_certificate_key ....................................... [not set] o- username .................................................... [admin]/> /cephadm_bootstrap/dashboard/username set ceph-adminValue set.設定する必要があるプロパティへのパスを変更してから、コマンドを実行する
/>cd /cephadm_bootstrap/dashboard//ceph_cluster/minions>ls o- dashboard ....................................................... [...] o- force_password_update ..................................... [enabled] o- password .................................................... [admin] o- ssl_certificate ........................................... [not set] o- ssl_certificate_key ....................................... [not set] o- username ................................................[ceph-admin]
ceph-saltシェルの中では自動補完機能を使用できます。これは、通常のLinuxシェル(Bash)の自動補完と同じようなものです。この機能は設定パス、サブコマンド、またはSalt Minion名を補完します。設定パスを自動補完する場合は、次の2つのオプションがあります。
現在位置からの相対的なパスをシェルに補完させる場合は、TABキー<Tab>を2回押します。
シェルに絶対パスを補完させる場合は、/を入力してからTABキー<Tab>を2回押します。
ceph-saltシェルからパスを使用せずにcdコマンドを入力すると、ツリー構造のクラスタ構成が出力され、現在パスの行がアクティブになります。上下の方向キーを使用して、それぞれの行に移動できます。Enterを押して確定すると、アクティブ行に設定パスが変更されます。
ドキュメントの整合性を維持するため、ceph-saltシェルを入力しない単一のコマンド構文を使用しています。たとえば、次のコマンドを使用してクラスタ構成のツリーを一覧にできます。
root@master # ceph-salt config ls5.3.2.2 Salt Minionの追加 #
5.2項 「Saltの展開」で展開し受諾したSalt Minionの全体またはサブセットをCephクラスタ構成に含めます。Salt Minionはフルネームで指定できます。また、「*」と「?」のグロブ表現を使用することで複数のSalt Minionを同時に含めることもできます。/ceph_cluster/minionsパスでaddサブコマンドを使用します。次のコマンドは受諾済みのSalt Minionをすべて含めます。
root@master # ceph-salt config /ceph_cluster/minions add '*'指定したSalt Minionが追加されたことを確認します。
root@master # ceph-salt config /ceph_cluster/minions ls
o- minions ................................................. [Minions: 5]
o- ses-master.example.com .................................. [no roles]
o- ses-min1.example.com .................................... [no roles]
o- ses-min2.example.com .................................... [no roles]
o- ses-min3.example.com .................................... [no roles]
o- ses-min4.example.com .................................... [no roles]5.3.2.3 cephadmで管理するSalt Minionの指定 #
Cephクラスタに属し、cephadmで管理するノードを指定します。Cephサービスを実行するすべてのノードと、管理ノードを含めます。
root@master # ceph-salt config /ceph_cluster/roles/cephadm add '*'5.3.2.4 管理ノードの指定 #
管理ノードは、ceph.conf設定ファイルとCeph管理キーリングがインストールされるノードです。通常、Ceph関連のコマンドは管理ノードで実行します。
すべての、または、ほとんどのホストがSUSE Enterprise Storageに所属するような均質な環境では、Salt Masterと同じホストに管理ノードを置くことお勧めします。
あるSaltインフラストラクチャが複数のクラスタのホストとなるような異種環境(たとえば、SUSE Enterprise Storageと共にSUSE Managerを使用するような環境)では、Salt Masterと同じホストに管理ノードを置かないでください。
管理ノードを指定するには、次のコマンドを実行します。
root@master #ceph-salt config /ceph_cluster/roles/admin add ses-master.example.com 1 minion added.root@master #ceph-salt config /ceph_cluster/roles/admin ls o- admin ................................................... [Minions: 1] o- ses-master.example.com ...................... [Other roles: cephadm]
ceph.confと管理キーリングを複数のノードにインストールする展開で必要な場合は、Ceph設定ファイルと管理キーリングを複数のノードにインストールすることもできます。セキュリティ上の理由から、すべてのクラスタのノードにインストールすることは避けてください。
5.3.2.5 最初のMON/MGRノードの指定 #
クラスタをブートストラップするSalt Minionをクラスタ内から指定する必要があります。このミニオンはCeph MonitorとCeph Managerサービスを実行する最初のミニオンになります。
root@master #ceph-salt config /ceph_cluster/roles/bootstrap set ses-min1.example.com Value set.root@master #ceph-salt config /ceph_cluster/roles/bootstrap ls o- bootstrap ..................................... [ses-min1.example.com]
さらに、public_networkパラメータが正しく設定されていることを確認するために、パブリックネットワーク上のブートストラップMONのIPアドレスを指定する必要があります。たとえば、次のコマンドを実行します。
root@master # ceph-salt config /cephadm_bootstrap/mon_ip set 192.168.10.205.3.2.6 調整されるプロファイルの指定 #
クラスタの中から、アクティブに調整されるプロファイルを保有するミニオンを指定する必要があります。そのためには、次のコマンドを実行して役割を明示的に追加してください。
1つのミニオンにlatencyとthroughputの両方の役割を持たせることはできません。
root@master #ceph-salt config /ceph_cluster/roles/tuned/latency add ses-min1.example.com Adding ses-min1.example.com... 1 minion added.root@master #ceph-salt config /ceph_cluster/roles/tuned/throughput add ses-min2.example.com Adding ses-min2.example.com... 1 minion added.
5.3.2.7 SSHキーペアの生成 #
cephadmはSSHプロトコルを使用してクラスタノードと通信します。cephadmという名前のユーザアカウントが自動的に作成され、SSH通信に使用されます。
SSHキーペアの公開鍵と秘密鍵を生成する必要があります。
root@master #ceph-salt config /ssh generate Key pair generated.root@master #ceph-salt config /ssh ls o- ssh .................................................. [Key Pair set] o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83] o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
5.3.2.8 タイムサーバの設定 #
すべてのクラスタノードは信頼できるタイムソースと時刻を同期する必要があります。時刻を同期するには、いくつかのシナリオがあります。
最適なNTPサービスを使用して時刻を同期するように、すべてのクラスタノードを設定済みの場合、タイムサーバ処理を完全に無効化します。
root@master #ceph-salt config /time_server disableお使いのサイトに単一のタイムソースがすでに存在する場合は、そのタイムソースのホスト名を指定します。
root@master #ceph-salt config /time_server/servers add time-server.example.com別の方法として、
ceph-saltにはSalt Minionの1つを残りのクラスタのタイムサーバとして機能するように設定する機能があります。この機能は「内部タイムサーバ」と呼ばれることもあります。このシナリオでは、ceph-saltは内部タイムサーバ(Salt Minionの1つであるはず)を、pool.ntp.orgなどの外部のタイムサーバと時刻を同期するように設定します。同時に、それ以外のミニオンを内部タイムサーバから時刻を取得するように設定します。この方法は、次のように実現できます。root@master #ceph-salt config /time_server/servers add ses-master.example.comroot@master #ceph-salt config /time_server/external_servers add pool.ntp.org/time_server/subnetオプションはサブネットを指定します。NTPクライアントはこのサブネットからNTPサーバへのアクセスを許可されます。サブネットは/time_server/serversを指定した際に自動で設定されます。変更や手動指定が必要な場合は、次のコマンドを実行します。root@master #ceph-salt config /time_server/subnet set 10.20.6.0/24
次のコマンドでタイムサーバの設定を確認します。
root@master # ceph-salt config /time_server ls
o- time_server ................................................ [enabled]
o- external_servers ............................................... [1]
| o- pool.ntp.org ............................................... [...]
o- servers ........................................................ [1]
| o- ses-master.example.com ..................................... [...]
o- subnet .............................................. [10.20.6.0/24]時刻同期設定の詳細については、https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-ntp.html#sec-ntp-yastを参照してください。
5.3.2.9 Cephダッシュボードログインアカウント情報の設定 #
基本的なクラスタが展開されると、Cephダッシュボードが使用可能になります。アクセスするには、有効なユーザ名とパスワードを設定する必要があります。次に例を示します。
root@master #ceph-salt config /cephadm_bootstrap/dashboard/username set adminroot@master #ceph-salt config /cephadm_bootstrap/dashboard/password set PWD
デフォルトでは、最初のダッシュボードユーザはダッシュボードに最初にログインの際にパスワードの変更を求められます。機能を無効化するには、次のコマンドを実行します。
root@master # ceph-salt config /cephadm_bootstrap/dashboard/force_password_update disable5.3.2.10 コンテナイメージへのパスの設定 #
cephadmは展開手順で使用されるコンテナイメージへの有効なURIパスを認識する必要があります。デフォルトパスが設定されているかどうかを確認します。
root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path lsデフォルトパスが設定されていない場合や、展開時に特定のパスを必要とする場合は、次のように追加してください。
root@master # ceph-salt config /cephadm_bootstrap/ceph_image_path set registry.suse.com/ses/7/ceph/ceph監視スタックの場合、これ以外にもコンテナイメージが必要です。エアギャップに守られた環境で展開する場合や、ローカルレジストリから展開する場合に、対応するローカルレジストリを準備するために、こうしたコンテナイメージをこの時点で取得したい場合があります。
ceph-saltはこれらのコンテナイメージを展開に使用しないことに注意してください。これは、後の手順で監視コンポーネントの展開と移行のためにcephadmを使用するための準備です。
監視スタックが使用するイメージとそのカスタマイズ方法の詳細については、16.1項 「カスタムイメージまたはローカルイメージの設定」を参照してください。
5.3.2.11 コンテナレジストリの設定 #
必要に応じて、ローカルコンテナレジストリを設定できます。これはregistry.suse.comレジストリのミラーとして機能します。registry.suse.comから更新されたコンテナを新しく入手できるようになった際には、ローカルレジストリを再同期する必要があることに注意してください。
ローカルレジストリを作成すると、以下のようなシナリオで役立ちます。
多数のクラスタノードを使用していて、コンテナイメージのローカルミラーを作成することで、ダウンロード時間と帯域幅を削減したい場合。
クラスタがオンラインのレジストリにアクセスできないため(エアギャップ展開)、コンテナイメージを取得するローカルミラーを必要とする場合。
設定やネットワークの問題により、クラスタがセキュアリンク経由でリモートレジストリにアクセスできないため、ローカルの暗号化されていないレジストリが必要な場合。
PTF(Program Temporary Fix)をサポートされたシステムに展開するには、ローカルコンテナレジストリを展開する必要があります。
アクセス資格情報と共にローカルレジストリのURLを設定するには、以下の手順に従います。
ローカルレジストリのURLを設定します。
cephuser@adm >ceph-salt config /containers/registry_auth/registry set REGISTRY_URLローカルレジストリにアクセスするためのユーザ名とパスワードを設定します。
cephuser@adm >ceph-salt config /containers/registry_auth/username set REGISTRY_USERNAMEcephuser@adm >ceph-salt config /containers/registry_auth/password set REGISTRY_PASSWORDceph-salt applyを実行して、すべてのミニオンのSalt Pillarを更新します。
更新されたコンテナが新しく登場した際にローカルレジストリを再同期しないようにするには、「レジストリキャッシュ」を設定できます。
クラウドネイティブなアプリケーションの開発とデリバリーの手法は、コンテナイメージの開発と作成に、レジストリとCI/CD(継続的インテグレーション/デリバリー)インスタンスを必要とします。このインタンス内でプライベートレジストリを使用できます。
5.3.2.12 データ転送中の暗号化(msgr2)の有効化 #
MSGR2プロトコルは、Cephの通信プロトコルです。このプロトコルは、ネットワークを通過するすべてのデータを暗号化するセキュリティモードを提供し、認証ペイロードをカプセル化し、新しい認証モード(Kerberosなど)を将来的に統合することを可能にします。
現在のところ、CephFSやRADOS Block Deviceなどの、LinuxカーネルのCephFSクライアントはmsgr2をサポートしていません。
Cephデーモンは複数のポートにバインドできるため、古いCephクライアントとv2対応の新しいクライアントが同じクラスタに接続できます。デフォルトでは、MONはIANAが新しく割り当てた3300番ポート(CE4hまたは0xCE4)と、過去のデフォルトポートである6789番ポートにバインドされます。前者は新しいv2プロトコル用で、後者は旧式のv1プロトコル用です。
v2プロトコル(MSGR2)は2つの接続モードに対応しています。
- crcモード
接続確立時の整合性チェックと、CRC32Cによる完全性チェックが行われます。
- セキュアモード
接続確立時の厳重な初回認証と、認証後のすべてのトラフィックの完全な暗号化が行われます。これには、暗号の完全性チェックが含まれます。
ほとんどの接続については、オプションで使用するモードを制御できます。
- ms_cluster_mode
Cephデーモン間のクラスタ内通信に使用される接続モード(または許可モード)。複数のモードが記載されている場合は、先頭に記載されたものが優先されます。
- ms_service_mode
クライアントがクラスタに接続する際に使用する許可モードのリスト。
- ms_client_mode
Cephクラスタと通信する際にクライアントが使用(または許可)する、優先度順の接続モードのリスト。
Monitorだけに適用される、同様のオプションセットが存在します。これにより、管理者がMonitorとの通信に異なる要求(通常はより厳しい要求)を設定することができます。
- ms_mon_cluster_mode
Monitor間の通信に使用される接続モード(または許可モード)。
- ms_mon_service_mode
クライアントや他のCephデーモンがMonitorに接続する際に使用する許可モードのリスト。
- ms_mon_client_mode
Monitorと通信する際にクライアントやMonitor以外のデーモンが使用する、優先度順の接続モードのリスト。
展開中にMSGR2の暗号化モードを有効化するには、ceph-salt設定に設定オプションをいくつか追加してからceph-salt applyを実行します。
secureモードを使用するには、次のコマンドを実行します。
ceph-salt設定ツールのceph_confにグローバルセクションを追加します。
root@master # ceph-salt config /cephadm_bootstrap/ceph_conf add global次のオプションを設定します。
root@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode "secure crc"root@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode "secure crc"root@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode "secure crc"
crcの前にsecureがついているか確認してください。
secureモードを強制するには、次のコマンドを実行します。
root@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_cluster_mode secureroot@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_service_mode secureroot@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set ms_client_mode secure
上記の設定を変更したい場合、Monitor設定の保存先に変更内容を設定します。その手段として、ceph config setコマンドを使用します。
root@master # ceph config set global CONNECTION_OPTION CONNECTION_MODE [--force]例:
root@master # ceph config set global ms_cluster_mode "secure crc"現在値やデフォルト値を確認したい場合は、次のコマンドを実行します。
root@master # ceph config get CEPH_COMPONENT CONNECTION_OPTION
たとえば、OSDのms_cluster_modeを取得するには、次のコマンドを実行します。
root@master # ceph config get osd ms_cluster_mode5.3.2.13 クラスタネットワークの設定 #
必要に応じて分離されたクラスタネットワークを実行する場合は、クラスタのネットワークIPアドレスの末尾にスラッシュ記号で区切ったサブネットマスクを付加したアドレスを設定する必要がある場合があります。たとえば、192.168.10.22/24のようなアドレスです。
cluster_networkを有効化するには、次のコマンドを実行します。
root@master #ceph-salt config /cephadm_bootstrap/ceph_conf add globalroot@master #ceph-salt config /cephadm_bootstrap/ceph_conf/global set cluster_network NETWORK_ADDR
5.3.2.14 クラスタ設定の確認 #
最低限のクラスタ設定が完了しました。明らかな誤りがないか、確認してください。
root@master # ceph-salt config ls
o- / ............................................................... [...]
o- ceph_cluster .................................................. [...]
| o- minions .............................................. [Minions: 5]
| | o- ses-master.example.com .................................. [admin]
| | o- ses-min1.example.com ......................... [bootstrap, admin]
| | o- ses-min2.example.com ................................. [no roles]
| | o- ses-min3.example.com ................................. [no roles]
| | o- ses-min4.example.com ................................. [no roles]
| o- roles ....................................................... [...]
| o- admin .............................................. [Minions: 2]
| | o- ses-master.example.com ....................... [no other roles]
| | o- ses-min1.example.com ................. [other roles: bootstrap]
| o- bootstrap ................................ [ses-min1.example.com]
| o- cephadm ............................................ [Minions: 5]
| o- tuned ..................................................... [...]
| o- latency .......................................... [no minions]
| o- throughput ....................................... [no minions]
o- cephadm_bootstrap ............................................. [...]
| o- advanced .................................................... [...]
| o- ceph_conf ................................................... [...]
| o- ceph_image_path ............... [registry.suse.com/ses/7/ceph/ceph]
| o- dashboard ................................................... [...]
| o- force_password_update ................................. [enabled]
| o- password ................................... [randomly generated]
| o- username ................................................ [admin]
| o- mon_ip ............................................ [192.168.10.20]
o- containers .................................................... [...]
| o- registries_conf ......................................... [enabled]
| | o- registries .............................................. [empty]
| o- registry_auth ............................................... [...]
| o- password .............................................. [not set]
| o- registry .............................................. [not set]
| o- username .............................................. [not set]
o- ssh .................................................. [Key Pair set]
| o- private_key ..... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
| o- public_key ...... [53:b1:eb:65:d2:3a:ff:51:6c:e2:1b:ca:84:8e:0e:83]
o- time_server ............................................... [enabled]
o- external_servers .............................................. [1]
| o- 0.pt.pool.ntp.org ......................................... [...]
o- servers ....................................................... [1]
| o- ses-master.example.com .................................... [...]
o- subnet ............................................. [10.20.6.0/24]次のコマンドを実行することで、クラスタ設定が有効かどうかを確認できます。
root@master # ceph-salt status
cluster: 5 minions, 0 hosts managed by cephadm
config: OK5.3.2.15 クラスタ設定のエクスポート #
基本的なクラスタの設定が完了し、設定が有効であることを確認したら、クラスタ設定をファイルにエクスポートするとよいでしょう。
root@master # ceph-salt export > cluster.json
ceph-salt exportの出力にはSSHの秘密鍵が含まれます。セキュリティ上の不安がある場合は、適切な予防策を講じるまではコマンドを実行しないでください。
クラスタ設定を破棄してバックアップの状態に戻す場合は、次のコマンドを実行します。
root@master # ceph-salt import cluster.json5.3.3 ノードの更新と最小クラスタのブートストラップ #
クラスタを展開する前に、すべてのノードのソフトウェアパッケージをすべて更新してください。
root@master # ceph-salt update
アップデート中にノードがReboot is neededと報告した場合、重要なOSのパッケージ(カーネルなど)が新しいバージョンに更新されているため、ノードを再起動して変更を適用する必要があります。
再起動が必要なノードをすべて再起動するには、--rebootオプションを付加してください。
root@master # ceph-salt update --rebootもしくは、個別に再起動してください。
root@master # ceph-salt reboot
Salt Masterはceph-salt update --rebootやceph-salt rebootコマンドでは再起動されません。Salt Masterの再起動が必要な場合、手動で再起動してください。
ノードの更新後、最小のクラスタをブートストラップします。
root@master # ceph-salt applyブートストラップが完了すると、クラスタにはCeph MonitorとCeph Managerが1つずつ含まれます。
先のコマンドを実行すると、インタラクティブなユーザインターフェイスが開かれ、各ミニオンの現在の進行状況が表示されます。
スクリプトから設定を適用する必要がある場合、非インタラクティブモードで展開することもできます。このモードは、リモートマシンからクラスタを展開する際にも有用です。ネットワーク経由で進捗状況を画面に更新し続けると、煩わしく感じる場合があるためです。
root@master # ceph-salt apply --non-interactive5.3.4 最終ステップの確認 #
ceph-salt applyコマンドが完了すると、Ceph MonitorとCeph Managerが1つずつ存在するはずです。rootに相当するadminの役割を与えられたミニオンか、sudoを使用するcephadmユーザは、ceph statusコマンドを正常に実行できるはずです。
次の手順には、cephadmを使用した追加のCeph Monitor、Ceph Manager、OSD、監視スタック、ゲートウェイの展開が含まれます。
続ける前に新しいクラスタのネットワーク設定を確認してください。この時点では、ceph-salt設定の/cephadm_bootstrap/mon_ipに入力された内容に従って、public_network設定が読み込まれます。しかし、この設定はCeph Monitorにしか適用されません。次のコマンドを使用して、この設定を確認できます。
root@master # ceph config get mon public_network
これがCephの動作に必要な最低限の設定ですが、このpublic_network設定をglobalに設定することをお勧めします。つまり、この設定がMONだけでなく、すべてのタイプのCephデーモンにも適用されます。
root@master # ceph config set global public_network "$(ceph config get mon public_network)"この手順は必須ではありません。しかしながら、この設定を使用しないと、Ceph OSDと(Ceph Monitorを除く)その他のデーモンが「すべてのアドレス」をリスンすることになります。
完全に分離されたネットワークを使用して、OSDどうしを通信させたい場合は、次のコマンドを実行します。
root@master # ceph config set global cluster_network "cluster_network_in_cidr_notation"このコマンドを実行すると、展開中に作成されるOSDは最初から所定のクラスタネットワークを使用するようになります。
クラスタが高密度なノード(ホストあたりのOSDが62個を超える)から構成されるように設定する場合は、Ceph OSDに十分なポートを割り当ててください。デフォルトのポート範囲(6800～7300)のままでは、ホストあたりのOSDは最大62個までです。高密度なノードを含むクラスタの場合、ms_bind_port_maxの設定を適切な値に調整してください。各OSDは追加で8個のポートを使用します。たとえば、96個のOSDを実行するように設定されたホストの場合、768個のポートが必要になります。この場合、次のコマンドを実行して、ms_bind_port_maxを少なくとも7568に設定する必要があります。
root@master # ceph config set osd.* ms_bind_port_max 7568これを動作させるには、設定した値に応じてファイアウォールの設定も調整する必要があります。詳細については、13.7項 「Firewall settings for Ceph」を参照してください。
5.4 サービスとゲートウェイの展開 #
基本的なCephクラスタを展開した後、より多くのクラスタノードにコアサービスを展開します。クライアントからクラスタのデータにアクセスできるようにするには、追加のサービスも展開します。
現時点では、Cephオーケストレータ(ceph orchサブコマンド)を使用したコマンドライン上でのCephサービスの展開がサポートされています。
5.4.1 ceph orchコマンド #
Cephオーケストレータコマンドであるceph orchは、新しいクラスタノード上で、クラスタコンポーネントの一覧とCephサービスの展開を行います。このコマンドはcephadmモジュールのインターフェイスです。
5.4.1.1 オーケストレータステータスの表示 #
次のコマンドは、Cephオーケストレータの現在モードとステータスを表示します。
cephuser@adm > ceph orch status5.4.1.2 デバイス、サービス、デーモンの一覧 #
すべてのディスクデバイスを一覧にするには、次のコマンドを実行します。
cephuser@adm > ceph orch device ls
Hostname Path Type Serial Size Health Ident Fault Available
ses-master /dev/vdb hdd 0d8a... 10.7G Unknown N/A N/A No
ses-min1 /dev/vdc hdd 8304... 10.7G Unknown N/A N/A No
ses-min1 /dev/vdd hdd 7b81... 10.7G Unknown N/A N/A No
[...]「サービス」とは、特定のタイプのCephサービスを指す総称です。たとえば、Ceph Managerなどです。
「デーモン」とは、サービスの特定のインスタンスを指します。たとえば、ses-min1という名前のノードで実行されるmgr.ses-min1.gdlcikプロセスなどです。
cephadmが認識しているすべてのサービスを一覧にするには、次のコマンドを実行します。
cephuser@adm > ceph orch ls
NAME RUNNING REFRESHED AGE PLACEMENT IMAGE NAME IMAGE ID
mgr 1/0 5m ago - <no spec> registry.example.com/[...] 5bf12403d0bd
mon 1/0 5m ago - <no spec> registry.example.com/[...] 5bf12403d0bd
リストに特定のノードのサービスだけを表示するには、オプションの-–hostパラメータを使用します。特定のタイプのサービスだけを表示するには、オプションの--service-typeパラメータを使用します(指定できるタイプはmon、osd、mgr、mds、rgwです)。
cephadmが展開した実行中のすべてのデーモンを一覧にするには、次のコマンドを実行します。
cephuser@adm > ceph orch ps
NAME HOST STATUS REFRESHED AGE VERSION IMAGE ID CONTAINER ID
mgr.ses-min1.gd ses-min1 running) 8m ago 12d 15.2.0.108 5bf12403d0bd b8104e09814c
mon.ses-min1 ses-min1 running) 8m ago 12d 15.2.0.108 5bf12403d0bd a719e0087369
特定のデーモンのステータスを照会するには、--daemon_typeと--daemon_idを使用します。OSDの場合、IDは数字のOSD IDです。MDSの場合、IDはファイルシステム名です。
cephuser@adm >ceph orch ps --daemon_type osd --daemon_id 0cephuser@adm >ceph orch ps --daemon_type mds --daemon_id my_cephfs
5.4.2 サービス仕様と配置仕様 #
Cephサービスの展開内容を指定する方法としては、YAMLフォーマットのファイルを作成して、展開したいサービスの仕様を記載することをお勧めします。
5.4.2.1 サービス仕様の作成 #
サービスタイプごとに個別の仕様ファイルを作成できます。以下に例を示します。
root@master # cat nfs.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
hosts:
- ses-min1
- ses-min2
spec:
pool: EXAMPLE_POOL
namespace: EXAMPLE_NAMESPACE
もしくは、各サービスを実行するノードを記載した単一のファイル(cluster.ymlなど)により、複数の(または、すべての)サービスタイプを指定することもできます。それぞれのサービスタイプを3つのダッシュ記号(---)で区切ることを忘れないでください。
cephuser@adm > cat cluster.yml
service_type: nfs
service_id: EXAMPLE_NFS
placement:
hosts:
- ses-min1
- ses-min2
spec:
pool: EXAMPLE_POOL
namespace: EXAMPLE_NAMESPACE
---
service_type: rgw
service_id: REALM_NAME.ZONE_NAME
placement:
hosts:
- ses-min1
- ses-min2
- ses-min3
---
[...]各プロパティが意味するものは、以下の通りです。
service_typeサービスのタイプです。次のいずれかを指定できます。Cephサービス(
mon、mgr、mds、crash、osd、rbd-mirror)、ゲートウェイ(nfs、rgw)、監視スタックの一部(alertmanager、grafana、node-exporter、prometheus)。service_idサービスの名前です。次のサービスタイプについては、
service_idプロパティは不要です。mon、mgr、alertmanager、grafana、node-exporter、prometheus。placementどのノードがサービスを実行するかを指定します。詳細については、5.4.2.2項 「配置仕様の作成」を参照してください。
specサービスタイプに関連する、追加仕様です。
通常、Cephクラスタのサービスには、いくつかの固有のプロパティがあります。個別のサービス仕様の例と詳細については、5.4.3項 「Cephサービスの展開」を参照してください。
5.4.2.2 配置仕様の作成 #
Cephサービスを展開するには、サービスの展開先ノードをcephadmが認識する必要があります。placementプロパティを使用して、サービスを適用するノードのホスト名の略称を列挙してください。
cephuser@adm > cat cluster.yml
[...]
placement:
hosts:
- host1
- host2
- host3
[...]5.4.2.3 クラスタ仕様の適用 #
すべてのサービス仕様とサービスの配置仕様を記載した完全なcluster.ymlファイルの作成が完了したら、次のコマンドを実行して、クラスタに仕様を適用してください。
cephuser@adm > ceph orch apply -i cluster.yml
クラスタのステータスを確認するには、ceph orch statusコマンドを実行します。詳細については、「5.4.1.1項 「オーケストレータステータスの表示」」を参照してください。
5.4.2.4 実行中のクラスタ仕様のエクスポート #
5.4.2項 「サービス仕様と配置仕様」で説明した仕様ファイルを用いてCephクラスタにサービスを展開したにもかかわらず、運用中にクラスタの設定が元の仕様から変わる場合もあります。また、誤って仕様ファイルを削除してしまうことも考えられます。
実行中のクラスタからすべての仕様を取得するには、次のコマンドを実行してください。
cephuser@adm > ceph orch ls --export
placement:
hosts:
- hostname: ses-min1
name: ''
network: ''
service_id: my_cephfs
service_name: mds.my_cephfs
service_type: mds
---
placement:
count: 2
service_name: mgr
service_type: mgr
---
[...]
--formatオプションを付加することで、デフォルトのyaml出力フォーマットを変更できます。選択できるフォーマットは、json、json-pretty、yamlです。以下に例を示します。
ceph orch ls --export --format json
5.4.3 Cephサービスの展開 #
基本的なクラスタの実行後、他のノードにCephサービスを展開できます。
5.4.3.1 Ceph MonitorとCeph Managerの展開 #
Cephクラスタでは、3個または5個のMONを異なるノードに展開します。クラスタに5個以上のノードが含まれる場合、5個のMONを展開することをお勧めします。MONと同じノードにMGRを展開すると良いでしょう。
MONとMGRを展開する際は、5.3.2.5項 「最初のMON/MGRノードの指定」で基本的なクラスタを構成した際に追加した、最初のMONを忘れずに含めてください。
MONを展開するには、次の仕様を適用してください。
service_type: mon placement: hosts: - ses-min1 - ses-min2 - ses-min3
別のノードを追加する必要がある場合は、同じYAMLリストにホスト名を付加してください。以下に例を示します。
service_type: mon placement: hosts: - ses-min1 - ses-min2 - ses-min3 - ses-min4
同様に、MGRを展開するには次の仕様を適用してください。
展開ごとに、少なくとも3個のCeph Managerが展開されているかを確認してください。
service_type: mgr placement: hosts: - ses-min1 - ses-min2 - ses-min3
MONまたはMGRが同じサブネット上に存在しない場合、サブネットアドレスを付加する必要があります。以下に例を示します。
service_type: mon placement: hosts: - ses-min1:10.1.2.0/24 - ses-min2:10.1.5.0/24 - ses-min3:10.1.10.0/24
5.4.3.2 Ceph OSDの展開 #
以下の条件をすべて満たす場合、ストレージデバイスは「使用可能」とみなされます。
デバイスにパーティションが作成されていない。
デバイスがLVM状態ではない。
デバイスがマウント先になっていない。
デバイスにファイルシステムが含まれない。
デバイスにBlueStore OSDが含まれない。
デバイスのサイズが5GBを超えている。
これらの条件が満たされない場合、CephはそのOSDのプロビジョニングを拒否します。
OSDを展開する方法は2つあります。
「使用可能」とみなされた未使用のストレージデバイスをすべて使用するよう、Cephに指示する方法。
cephuser@adm >ceph orch apply osd --all-available-devicesDriveGroupsを使用してデバイスを記述したOSD仕様を作成し、そのプロパティを基にデバイスを展開する方法(13.4.3項 「DriveGroups仕様を用いたOSDの追加」を参照してください)。プロパティの例としては、デバイスの種類(SSDまたはHDD)、デバイスのモデル名、サイズ、デバイスが存在するノードなどがあります。仕様の作成後、次のコマンドを実行して仕様を適用します。
cephuser@adm >ceph orch apply osd -i drive_groups.yml
5.4.3.3 メタデータサーバの展開 #
CephFSは1つ以上のMDS(メタデータサーバ)サービスを必要とします。CephFSを作成するには、まず以下の仕様を適用して、MDSサーバを作成する必要があります。
最低でも2つのプールを作成してから以下の仕様を適用してください。1つはCephFSのデータ用、もう1つはCephFSのメタデータ用のプールです。
service_type: mds service_id: CEPHFS_NAME placement: hosts: - ses-min1 - ses-min2 - ses-min3
MDSが機能したら、CephFSを作成します。
ceph fs new CEPHFS_NAME metadata_pool data_pool
5.4.3.4 Object Gatewayの展開 #
cephadmはObject Gatewayを、特定の「レルム」と「ゾーン」を管理するデーモンのコレクションとして展開します。
Object Gatewayサービスを既存のレルムとゾーンに関連付けることも(詳細については、21.13項 「マルチサイトObject Gateway」を参照してください)、存在しないREALM_NAMEとZONE_NAMEを指定することもできます。後者の場合、次の設定を適用すると自動的にゾーンとレルムが作成されます。
service_type: rgw service_id: REALM_NAME.ZONE_NAME placement: hosts: - ses-min1 - ses-min2 - ses-min3 spec: rgw_realm: RGW_REALM rgw_zone: RGW_ZONE
5.4.3.4.1 セキュアなSSLアクセスの使用 #
Object Gatewayへの接続にセキュアなSSL接続を使用するには、有効なSSL証明書とキーファイルのペアが必要です(詳細については、21.7項 「Object GatewayでのHTTPS/SSLの有効化」を参照してください)。必要な作業は、SSLの有効化、SSL接続のポート番号の指定、SSL証明書とキーファイルの指定です。
SSLを有効化し、ポート番号を指定するには、仕様に次の内容を記載します。
spec: ssl: true rgw_frontend_port: 443
SSL証明書とキーを指定するには、YAML仕様ファイルに内容を直接ペーストすることができます。行末のパイプ記号(|)は、構文解析の際に複数行にまたがる文字列を1つの値として認識させるためのものです。以下に例を示します。
spec: ssl: true rgw_frontend_port: 443 rgw_frontend_ssl_certificate: | -----BEGIN CERTIFICATE----- MIIFmjCCA4KgAwIBAgIJAIZ2n35bmwXTMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV BAYTAkFVMQwwCgYDVQQIDANOU1cxHTAbBgNVBAoMFEV4YW1wbGUgUkdXIFNTTCBp [...] -----END CERTIFICATE----- rgw_frontend_ssl_key: | -----BEGIN PRIVATE KEY----- MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDLtFwg6LLl2j4Z BDV+iL4AO7VZ9KbmWIt37Ml2W6y2YeKX3Qwf+3eBz7TVHR1dm6iPpCpqpQjXUsT9 [...] -----END PRIVATE KEY-----
SSL証明書とキーファイルの内容をペーストする代わりに、rgw_frontend_ssl_certificate:キーワードとrgw_frontend_ssl_key:キーワードを削除して、設定データベースにSSL証明書とキーファイルをアップロードすることもできます。
cephuser@adm >ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.crt \ -i SSL_CERT_FILEcephuser@adm >ceph config-key set rgw/cert/REALM_NAME/ZONE_NAME.key \ -i SSL_KEY_FILE
5.4.3.4.2 サブクラスタを使用した展開 #
「サブクラスタ」はクラスタ内のノードの整理に役立ちます。これによりワークロードを分離することで、弾力的な拡張が容易になります。サブクラスタを使用して展開する場合は、次の設定を適用します。
service_type: rgw service_id: REALM_NAME.ZONE_NAME.SUBCLUSTER placement: hosts: - ses-min1 - ses-min2 - ses-min3 spec: rgw_realm: RGW_REALM rgw_zone: RGW_ZONE subcluster: SUBCLUSTER
5.4.3.5 iSCSI Gatewayの展開 #
cephadmが展開するiSCSI Gatewayは、クライアント(「イニシエータ」)から、リモートサーバ上のSCSIストレージデバイス(「ターゲット」)にSCSIコマンドを送信できるようにする、SAN(ストレージエリアネットワーク)プロトコルです。
展開するには以下の設定を適用します。trusted_ip_listにすべてのiSCSI GatewayノードとCeph ManagerノードのIPアドレスが含まれているか確認してください(以下の出力例を参照してください)。
以下の仕様を適用する前に、プールが作成されているか確認してください。
service_type: iscsi service_id: EXAMPLE_ISCSI placement: hosts: - ses-min1 - ses-min2 - ses-min3 spec: pool: EXAMPLE_POOL api_user: EXAMPLE_USER api_password: EXAMPLE_PASSWORD trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
trusted_ip_listに列挙されたIPについて、カンマ区切りの後にスペースが入っていないことを確認してください。
5.4.3.5.1 セキュアなSSLの設定 #
セキュアなSSL接続をCephダッシュボードとiSCSIターゲットAPIの間で使用するには、有効なSSL証明書とキーファイルのペアが必要です。証明書とキーファイルは、CAが発行したものか自己署名したものを使用します(10.1.1項 「自己署名証明書の作成」を参照してください)。SSLを有効化するには、仕様ファイルにapi_secure: true設定を含めます。
spec: api_secure: true
SSL証明書とキーを指定するには、YAML仕様ファイルに内容を直接ペーストすることができます。行末のパイプ記号(|)は、構文解析の際に複数行にまたがる文字列を1つの値として認識させるためのものです。以下に例を示します。
spec:
pool: EXAMPLE_POOL
api_user: EXAMPLE_USER
api_password: EXAMPLE_PASSWORD
trusted_ip_list: "IP_ADDRESS_1,IP_ADDRESS_2"
api_secure: true
ssl_cert: |
-----BEGIN CERTIFICATE-----
MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
[...]
-----END CERTIFICATE-----
ssl_key: |
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
/CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
[...]
-----END PRIVATE KEY-----5.4.3.6 NFS Ganeshaの展開 #
cephadmはNFS Ganeshaの展開に、事前定義されたRADOSプールとオプションのネームスペースを使用します。NFS Ganeshaを展開するには、次の仕様を適用してください。
service_type: nfs service_id: EXAMPLE_NFS placement: hosts: - ses-min1 - ses-min2 spec: pool: EXAMPLE_POOL namespace: EXAMPLE_NAMESPACE
EXAMPLE_NFSにはNFSエクスポートを識別する任意の文字列を指定します。
EXAMPLE_POOLにはNFS GaneshaのRADOS設定オブジェクトを保存するプール名を指定します。
EXAMPLE_NAMESPACE(オプション)には、希望するObject GatewayのNFSネームスペースを指定します(
ganeshaなど)。
5.4.3.7 rbd-mirrorの展開 #
rbd-mirrorサービスは2つのCephクラスタ間でRADOS Block Deviceイメージの同期を行います(詳細については20.4項 「RBDイメージのミラーリング」を参照してください)。rbd-mirrorを展開するには、次の仕様を使用してください。
service_type: rbd-mirror service_id: EXAMPLE_RBD_MIRROR placement: hosts: - ses-min3
5.4.3.8 監視スタックの展開 #
監視スタックは、Prometheus、Prometheusエクスポータ、Prometheus Alertmanager、Grafanaから構成されます。Cephダッシュボードはこうしたコンポーネントを利用して、クラスタの使用量やパフォーマンスの詳細なメトリクスの保存と視覚化を行います。
監視スタックを展開するには、以下の手順に従ってください。
Ceph Managerデーモンで
prometheusモジュールを有効化します。これにより、Cephの内部メトリクスが公開され、Prometheusから読み取れるようになります。cephuser@adm >ceph mgr module enable prometheus注記このコマンドはPrometheusの展開前に実行してください。展開前にコマンドを実行していない場合、Prometheusを再展開してPrometheusの設定を更新する必要があります。
cephuser@adm >ceph orch redeploy prometheus次のような内容を含む仕様ファイル(
monitoring.yamlなど)を作成します。service_type: prometheus placement: hosts: - ses-min2 --- service_type: node-exporter --- service_type: alertmanager placement: hosts: - ses-min4 --- service_type: grafana placement: hosts: - ses-min3
次のコマンドを実行して、監視サービスを適用します。
cephuser@adm >ceph orch apply -i monitoring.yaml監視サービスの展開には1、2分かかる場合があります。
Prometheus、Grafana、Cephダッシュボードは、お互いに通信できるようにすべて自動的に設定されます。そのため、この手順で展開されたとき、Cephダッシュボードには完全に機能するGrafanaが統合されています。
このルールの例外は、RBDイメージの監視だけです。詳細については、16.5.4項 「RBDイメージ監視の有効化」を参照してください。