Ceph Storage for Oracle Linuxの使用

3 Ceph Storage for Oracle Linuxの使用

この章では、Cephストレージ・プール、ブロック・デバイス、ブロック・デバイス・イメージの設定、およびブロック・デバイスにアクセスするためのCeph iSCSI Gatewayの設定について説明します。この章では、Ceph Object GatewayおよびCephファイル・システムの使用についても説明します。

Cephブロック・デバイスの設定

Cephブロック・デバイスは、シンプロビジョニングされたサイズ変更可能なデバイスであり、Ceph Storage Cluster内の複数のOSDにストライプ化されたデータを格納します。Cephブロック・デバイスでは、スナップショット、レプリケーション、一貫性などのRADOS機能を利用します。CephのRADOSブロック・デバイス(RBD)は、カーネル・モジュールまたはlibrbdライブラリを使用してOSDと対話します。また、カーネル仮想マシン(KVM)を使用してCephブロック・デバイスをホストすることもできます。

この項では、Cephストレージ・プールの作成、およびCephブロック・デバイスのホストに使用するノードの設定について説明します。

この項では、Microsoft Windowsなどのクライアントへのアクセスを有効にするための、Cephブロック・デバイスに対するCeph iSCSI Gatewayの設定および使用について説明します。

Cephブロック・デバイスとストレージ・プールの作成および削除

この項では、Cephストレージ・プールの作成、およびCephブロック・デバイスのホストに使用するノードの設定について説明します。この項で使用するノードは、Cephクライアントと呼ばれます。Cephストレージ・プールとCephブロック・デバイスを作成するには、CephクライアントにCeph CLIがインストールされている必要があります。Ceph CLIのインストールの詳細は、「Ceph Storage Cluster管理ホストの作成」を参照してください。

ブロック・デバイスおよびストレージ・プールの作成

この項では、Cephストレージ・プールおよび関連するCephブロック・デバイスの作成について説明します。ブロック・デバイスを構成する前に、クラスタがアクティブで正常であることを確認します。ここに示すステップは、Cephクライアント・ノード上で実行する必要があります。

ストレージ・プールおよび関連するブロック・デバイスを作成するには:

Cephクライアントで、次のコマンドを使用してストレージ・プールを作成します。
```
# ceph osd pool create pool_name pg_num pgp_num
```
たとえば、datastoreという名前のプールを、ストレージ・プール用に128個の配置グループ(pg_num)およびCRUSHアルゴリズムによる配置で考慮する128個の配置グループ(pgp_num)を使用して作成します。pgp_num値は、pg_num値と同じである必要があります。
```
# ceph osd pool create datastore 128 128
```
データ永続性およびすべてのOSD間での均等な分散には、より多くの配置グループが必要ですが、作成数が多すぎると、CPUとメモリーが不必要に使用される可能性があります。ご使用の環境のOSD数に対する配置グループの適切な値を計算することが重要です。Ceph配置グループの詳細およびストレージ・プールの作成時に必要な値の計算方法は、Cephアップストリームのドキュメントを参照してください。

ヒント:

アップストリームのCeph PGs per Pool Calculatorを使用して、ご使用の環境のOSD数に基づいてプールの配置グループ・サイズを計算できます。
ストレージ・プールをrbdアプリケーションに関連付けます。
```
# ceph osd pool application enable datastore rbd
```
rbdアプリケーションを使用してプールを初期化します。
```
# rbd pool init datastore
```
たとえば次のように、rbdコマンドを使用して、ストレージ・プールにブロック・デバイス・イメージを作成します。
```
# rbd create --size 4096 --pool datastore vol01
```
この例では、vol01という名前の4096MBのボリュームをdatastoreプールに作成します。

ストレージ・プールを指定しない場合、rbdではデフォルトのrbdプールが使用されます。
```
# rbd create --size 4096 vol01
```
ブロック・デバイスで有効または無効にするRBD機能を設定します。object-map、fast-diffおよびdeep-flatten機能は、UEK R5でサポートされていないため、無効にする必要があります。たとえば、次を実行します。
```
# rbd feature disable datastore/vol01 object-map fast-diff deep-flatten
```
たとえば次のように、rbdコマンドを使用して、ブロック・デバイスにイメージをマップします。
```
# rbd map vol01 --pool datastore
```
Cephは、/dev/rbd/pool/volumeの下にブロック・デバイスを作成します。

このコマンドを実行するまで、RBDカーネル・モジュールはロードされません。コマンド実行後、それがロードされていることを確認するには、次のコマンドを実行します。
```
# lsmod|grep rbd
                               rbd      73304   1
 libceph  235751  2  rbd,ceph
```
たとえば次のように、rbd lsコマンドは、ストレージ・プールにマップしたイメージをリストします。
```
# rbd ls -p datastore
                              vol01
```
たとえば次のように、ブロック・デバイスにファイル・システムを作成します。
```
# mkfs.xfs /dev/rbd/datastore/vol01
```
Oracleワークロードのファイル・システム・タイプとして、BtrfsまたはXFSを使用することをお薦めします。
たとえば次のように、このファイル・システムをマウントします。
```
# mkdir /var/vol01
# mount /dev/rbd/datastore/vol01 /var/vol01
```

ブロック・デバイスとそのストレージ・プールの削除

この項では、Cephストレージ・プールおよび関連するCephブロック・デバイスの削除について説明します。ここに示すステップは、Cephクライアント・ノード上で実行する必要があります。

ブロック・デバイスおよびその関連付けられたストレージ・プールを削除するには:

Cephクライアント・ノードで、たとえば次のように、ブロック・デバイスを使用している任意のファイル・システムをアンマウントします。
```
# umount /var/vol01
```
たとえば次のように、ブロック・デバイスをイメージからアンマップします。
```
# rbd unmap /dev/rbd/datastore/vol01
```
たとえば次のように、ブロック・デバイス・イメージを削除します。
```
# rbd rm vol01 -p datastore
```
たとえば次のように、ストレージ・プールを削除します。
```
# ceph osd pool delete datastore datastore --yes-i-really-really-mean-it
```
Ceph構成でストレージ・プールの削除が許可されていない場合は、次のコマンドを使用して一時的に許可し、元の構成に戻すことができます。
```
# ceph tell mon.* injectargs --mon-allow-pool-delete=true
# ceph osd pool delete datastore datastore --yes-i-really-really-mean-it
# ceph tell mon.* injectargs --mon-allow-pool-delete=false
```

Ceph iSCSI Gatewayの設定

この項では、Ceph iSCSI Gatewayの設定および使用について説明します。iSCSIゲートウェイは、Cephブロック・デバイス・イメージをSCSIディスクとしてエクスポートする高可用性iSCSIターゲットを提供します。これにより、Microsoft WindowsなどのクライアントからCeph Storage Clusterにアクセスできるようになります。Ceph iSCSI Gateway高可用性には、2個から4個のiSCSIゲートウェイ・ノードを使用することをお薦めします。

Ceph iSCSI Gatewayノードは、スタンドアロン・ノードにすることも、Ceph OSDノード上の同じ場所に配置することもできます。

Ceph iSCSI Gatewayの詳細は、次のアップストリームのドキュメントを参照してください。

https://docs.ceph.com/en/latest/rbd/iscsi-overview/

Ceph iSCSI Gatewayノードの設定

この項では、1つ以上のCeph iSCSI Gatewayノードを設定する方法について説明します。Ceph iSCSI Gatewayノードは、OSDノード上、またはOSD以外のノード上に設定できます。ここに示すステップは、OSDノードでCeph iSCSI Gatewayノードを設定するためのものです。OSDノード上にないゲートウェイ・ノードの設定については、アップストリームのドキュメントを参照してください。

Ceph iSCSI Gatewayノード(OSDノード上の同じ場所に配置)を設定するには:

各Ceph iSCSI Gatewayノードで、TCPポート3260および5000を開きます。

# firewall-cmd --permanent --zone=public --add-port=3260/tcp --add-port=5000/tcp
# firewall-cmd --reload
# systemctl restart firewalld.service

OSDを検出する際のデフォルト・タイマーの値を下げて、iSCSIイニシエータのタイムアウトの可能性を削減します。これは、クラスタ内のすべてのOSDノードに対して実行する必要があります。構成を変更するには、いくつかの方法があります。
- Ceph構成ファイルで構成を変更します。$CEPH_CONFIG_DIR/ceph.confファイルに、次を追加します。
```
[osd]
osd heartbeat grace = 20
osd heartbeat interval = 5
```
  構成の変更をすべてのOSDノードにプッシュします。複数のノードに構成をプッシュするには、たとえば次のように、それらをスペース区切りのリストに指定します。
```
# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node2 ceph-node3 ceph-node4
```
  各OSDノードで、ceph-osdデーモンを再起動します。
```
# systemctl restart ceph-osd.target
```
- 管理ノードからクラスタ内の各OSDに変更を送信して、実行時に構成を変更します。この方法を使用して行った変更は永続的です。たとえば、次を実行します。
```
# ceph tell osd.0 config set osd_heartbeat_grace 20
# ceph tell osd.0 config set osd_heartbeat_interval 5
```
  0をOSDのIDに置き換えます。管理ノードでceph osd lsコマンドを使用して、クラスタ内のすべてのOSD IDのリストを取得します。
  
  この方法を使用した構成の変更は、osd.0プロセスに対して行われ、すぐに有効になります。この方法を使用する場合、ノードでOSDサービスを再起動する必要はありません。
- 各OSDノードで、実行時に構成を変更します。この方法を使用して行った変更は永続的です。
```
# ceph daemon osd.0 config set osd_heartbeat_grace 20
# ceph daemon osd.0 config set osd_heartbeat_interval 5
```
  0をOSDのIDに置き換えます。管理ノードでceph osd Treeコマンドを使用して、クラスタ内のすべてのOSD IDおよびそれらが存在するノードのリストを取得します。
  
  この方法を使用した構成変更はosd.0プロセスに対して行われますが、OSDサービスを再起動するまで有効にすることはできません。変更を有効にするには、各OSDノードでceph-osdデーモンを再起動します。
```
# systemctl restart ceph-osd.target
```
デプロイメント・ノードからCeph CLI (cephコマンド)をインストールし、Ceph iSCSI Gatewayノードにキーリングを追加します。たとえば、次を実行します。
```
# $CEPH_CONFIG_DIR/ceph-deploy admin ceph-node1 ceph-node2
```
ノードへのCeph CLIのインストールの詳細は、「Ceph Storage Cluster管理ホストの作成」を参照してください。
管理ノードから、rbdという名前のストレージ・プールが存在するかどうかを確認します。
```
# ceph osd lspools
```
rbdプールが存在しない場合には作成します。たとえば、次を実行します。
```
# ceph osd pool create rbd 128 128
```
rbdプールをRBDアプリケーションに関連付けます。たとえば、次を実行します。
```
# ceph osd pool application enable rbd rbd
```
RBDアプリケーションを使用してrbdプールを初期化します。たとえば、次を実行します。
```
# rbd pool init rbd
```
各Ceph iSCSI Gatewayノードに、必要なパッケージをインストールします。
```
# yum install ceph-iscsi-cli tcmu-runner
```

Ceph iSCSI Gatewayノードで、/etc/ceph/ディレクトリにiscsi-gateway.cfgという名前のファイルを作成し、ファイルに次を追加します。環境に合わせてファイルの内容を編集します。

[config]
# Name of the Ceph storage cluster. A suitable Ceph configuration file allowing
# access to the Ceph storage cluster from the gateway node is required, if not
# colocated on an OSD node.
cluster_name = ceph

# Place a copy of the ceph cluster's admin keyring in the gateway's /etc/ceph
# directory and reference the filename here
gateway_keyring = ceph.client.admin.keyring

# API settings.
# The API supports a number of options that allow you to tailor it to your
# local environment. If you want to run the API under https, you will need to
# create cert/key files that are compatible for each iSCSI gateway node, that is
# not locked to a specific node. SSL cert and key files *must* be called
# 'iscsi-gateway.crt' and 'iscsi-gateway.key' and placed in the '/etc/ceph/' directory
# on *each* gateway node. With the SSL files in place, you can use 'api_secure = true'
# to switch to https mode.

# To support the API, the bear minimum settings are:
api_secure = false

# Additional API configuration options are as follows, defaults shown.
# api_user = admin
# api_password = admin
# api_port = 5001
trusted_ip_list = 192.168.0.10,192.168.0.11

trusted_ip_listを、各Ceph iSCSI GatewayノードのIPアドレスのカンマ区切りリストに置き換えます。これらのIPアドレスは、ターゲットの作成やLUNのエクスポートなどの管理操作に使用されます。

/etc/ceph/iscsi-gateway.cfgファイルをクラスタ内のすべてのCeph iSCSI Gatewayノードにコピーします。

クラスタ内の各Ceph iSCSI Gatewayノードで、APIサービスを有効にして起動します。
```
# systemctl daemon-reload 
# systemctl enable rbd-target-api 
# systemctl start rbd-target-api
```
次を使用して、ノード上のAPIサービスのステータスを確認できます。
```
# systemctl status rbd-target-api
```

iSCSIターゲットの構成

この項では、Ceph iSCSI Gatewayノード上でiSCSIターゲットを設定および構成する方法について説明します。

iSCSIターゲットを構成するには:

iSCSIゲートウェイ・コマンドライン・インタフェース(gwcli)を使用して、iSCSIターゲットおよびRBDイメージを構成します。Ceph iSCSI Gatewayノードで、gwcliを起動します。
```
# gwcli
```
iscsi-targetディレクトリに移動し、iqn.1988-12.com.oracle.iscsi-gw:iscsi-igwという名前のターゲットを作成します。
```
> /> cd /iscsi-target
> /iscsi-target> create iqn.1988-12.com.oracle.iscsi-gw:iscsi-igw
```
gatewaysディレクトリに移動し、iSCSIゲートウェイを作成します。
```
> /iscsi-target> cd iqn.1988-12.com.oracle.iscsi-gw:iscsi-igw/gateways
> /iscsi-target...-igw/gateways> create gateway_hostname ip_address
```
この例では、gateway_hostnameはゲートウェイ・ノードのホスト名、ip_addressはREADやWRITEコマンドなどのiSCSIデータに使用されるIPです。これらのIPは、iscsi-gateway.cfgファイルのtrusted_ip_listにリストされている管理操作と同じIPを使用できますが、ここで異なるIPアドレスを使用することをお薦めします。

たとえば、2つのiSCSIゲートウェイを作成するには、次を実行します。
```
> /iscsi-target...-igw/gateways> create ceph-node1 203.0.113.150
> /iscsi-target...-igw/gateways> create ceph-node2 203.0.113.151
```
lsコマンドを使用して、ゲートウェイ(および作成する他のオブジェクト)をリストできます。
```
> /iscsi-target...-igw/gateways> ls
```
たとえば次のように、RBDイメージをrbdストレージ・プールに追加します。
```
> /iscsi-target...-igw/gateways>  cd /disks
> /disks> create pool=rbd image=mydisk-1 size=90G
```
クライアント・イニシエータを作成します。この例で使用されているクライアント・イニシエータ名はiqn.1988-12.com.oracle:ol7-clientです。
```
> /disks> cd /iscsi-target/iqn.1988-12.com.oracle.iscsi-gw:iscsi-igw/hosts
> /iscsi-target...csi-igw/hosts> create iqn.1988-12.com.oracle:ol7-client
```
クライアントのCHAPユーザー名とパスワードを設定します。
```
> /iscsi-target...le:ol7-client> auth chap=cephiscsiuser/cephiscsipass
```
クライアントにディスクを追加します。たとえば、次を実行します。
```
> /iscsi-target...le:ol7-client> disk add rbd.mydisk-1
```

iSCSIイニシエータの構成

この項では、Ceph iSCSI Gatewayノード上のiSCSIターゲットにアクセスするようにiSCSIイニシエータを構成する方法について説明します。クライアント・ノードはCeph Storage Clusterに属している必要はありません。Ceph iSCSI Gatewayにアクセスするクラスタ外部のクライアントです。

iSCSIイニシエータを構成するには:

iSCSIクライアントで、iSCSIイニシエータおよびマルチパス・ツールをインストールします。
```
# yum install iscsi-initiator-utils device-mapper-multipath
```
デフォルトの/etc/multipath.confファイルを作成し、multipathdサービスを有効にします。
```
# mpathconf --enable --with_multipathd y
```

/etc/multipath.confファイルに次を追加します。

 devices {
            device {
                    vendor                 "LIO-ORG"
                    hardware_handler       "1 alua"
                    path_grouping_policy   "failover"
                    path_selector          "queue-length 0"
                    failback               60
                    path_checker           tur
                    prio                   alua
                    prio_args              exclusive_pref_bit
                    fast_io_fail_tmo       25
                    no_path_retry          queue
            }
    }

multipathdサービスを再起動します。
```
# systemctl reload multipathd
```
iSCSIターゲットを設定します。たとえば次のように、/etc/iscsi/iscsid.confファイルを編集してCHAPログイン資格証明を追加します。
```
node.session.auth.authmethod = CHAP
node.session.auth.username = cephiscsiuser
node.session.auth.password = cephiscsipass
```
/etc/iscsi/initiatorname.iscsiファイルを編集して、内容をターゲットで作成したクライアント・イニシエータ名に置き換えます。この例では、iqn.1988-12.com.oracle:ol7-clientです。
```
InitiatorName=iqn.1988-12.com.oracle:ol7-client
```
iSCSIクライアント・サービスを有効化して起動します。
```
# systemctl restart iscsid.service
# systemctl enable iscsid.service
```
ターゲット・ポータルを検出します。たとえば、次を実行します。
```
# iscsiadm --mode discovery --type sendtargets --portal 203.0.113.150
```

ターゲットにログインします。

$ iscsiadm -m node -T  iqn.1988-12.com.oracle.iscsi-gw:iscsi-igw -l

マルチパス・デーモン(multipathd)により、/etc/multipath.confファイルの設定に基づいて、デバイスが自動的に設定されます。multipathコマンドを実行すると、フェイルオーバー構成で設定されたデバイスが、各パスの優先度グループとともに表示されます。
```
# multipath -ll
```
これで、他のマルチパスiSCSIディスクと同様にRBDイメージを使用できるようになります。

Ceph Object Gatewayの設定

Ceph Object GatewayはCeph Storage ClusterにRESTインタフェースを提供し、Amazon S3およびOpenStack Swiftのクライアント・アクセスを可能にします。Ceph Object Gatewayの詳細は、アップストリームのドキュメントを参照してください。

Ceph Object Gatewayには、要件に応じて2つのデプロイメント構成オプションがあります。

単純なCeph Object Gateway

単純なCeph Object Gateway構成は、Ceph Object Storageサービスを単一のデータ・センターで実行する場合に使用され、リージョンやゾーンを定義する必要はありません。
マルチサイトCeph Object Gateway

マルチサイトCeph Object Gateway構成は、Ceph Object Storageサービスがフェデレーテッド・アーキテクチャ内で地理的に分散されている場合に使用され、異なるリージョンに対応するストレージを構成して、さらにリージョンごとに個別のゾーンを識別する機能を提供します。データ同期エージェントにより、サービスでは広範囲の分散環境全体でデータの複数のコピーを保持できるので、フェイルオーバー、バックアップおよび障害時リカバリで優れたデータ耐障害性を実現することができます。この機能により、マスター以外のゾーンに書き込んだり、異なるゾーン間でデータ変更の同期を維持することができます。

単純なCeph Object Gatewayの設定

Ceph Object GatewayはCeph Storage Clusterのクライアントですが、必要に応じてクラスタ内のノード上でホストされる場合があります。Ceph Object Gatewayには次の要件があります。

稼働中のCeph Storage Cluster
HTTPまたはHTTPSリクエストの処理に使用するネットワーク・ポート(デフォルトは7480)上でトラフィックを許可する外部に面したネットワーク・インタフェース
Ceph Object Gatewayインスタンスの名前
キーリング内に適切な権限があるユーザー名
データを格納するためのプール
ゲートウェイ・インスタンス用のデータ・ディレクトリ
Ceph構成ファイル内のインスタンス・エントリ

次の項では、Ceph Object Gatewayの使用を開始するためのインストールおよびデプロイメントのステップについて説明します。

単純なCeph Object Gatewayのインストール

Ceph Object GatewayソフトウェアをCeph Storage Cluster内のノードにインストールするには、環境内のデプロイメント・ノードから次のコマンドを実行します。

# $CEPH_CONFIG_DIR/ceph-deploy install --rgw ceph-node1

ceph-node1を、ソフトウェアをインストールするノードの解決可能なホスト名に置き換えます。「Ceph Storage for Oracle Linuxパッケージへのアクセスの有効化」で説明されているように、ターゲット・ノードに適切なYumチャネルが構成されている必要があることに注意してください。

Ceph構成内にCeph Object Gatewayを作成するには、次のコマンドを使用します。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf rgw create ceph-node1

ファイアウォールの要件の更新

ファイアウォール・サービスが実行中の場合は、Ceph Object Gatewayを実行しているポートが開いていることを確認してください。たとえば、次を実行します。

# firewall-cmd --zone=public --add-port 7480/tcp --permanent
# firewall-cmd --reload

Ceph Object Gatewayのデフォルト・ポートを後で変更する場合は、このファイアウォール・ルールを無効にして、新しいポート番号用の新しいルールの追加が必要になることがあります。

ユーザーおよびキーの作成

Ceph Object Gatewayを使用するには、事前にユーザーを作成し、ゲートウェイによって公開されている様々なAPIへのアクセスを許可する必要があります。

S3アクセス用のユーザーを作成するには、ゲートウェイ・ノード上で次のコマンドを実行します。

# radosgw-admin user create --uid="testuser" --display-name="First User"

このコマンドでは、新規作成されたユーザーを示すJSON形式の出力が戻されます。この出力には、新規ユーザーの作成時に自動的に生成されるキーのリストが含まれています。作成したユーザーのaccess_keyおよびsecret_keyをノートにとります。これらは、S3クライアント・アプリケーションからゲートウェイに接続する際に必要です。

Swift APIへのアクセスを提供する場合は、元のユーザーに対してサブユーザーを作成できます。Swiftアクセス用のユーザーを作成するには、ゲートウェイ・ホスト上で次のコマンドを実行します。

# radosgw-admin subuser create --uid=testuser --subuser=testuser:swift \
    --access=full --access-key=$SYSTEM_ACCESS_KEY --secret=$SWIFT_KEY --default --key-type=swift

ユーザーの詳細が表示されます。JSON出力のswift_keysキーに、Swiftのアクセス検証に使用可能なuserおよびsecret_keyが表示されます。

任意の時点で、このユーザー情報をもう一度表示して、キーを取得したり、アクセス権などの情報を確認する必要が生じた場合は、radosgw-admin user infoコマンドを使用できます。たとえば、次を実行します。

# radosgw-admin user info --uid=testuser

radosgw-admin user listコマンドを使用して、ユーザーをリストできます。

アクセスのテスト

S3アクセスをテストするにはpython-botoパッケージを必要とし、新しいバケットの作成に使用できる簡単なPythonスクリプトを作成する必要があります。Amazon S3 APIでは、データ・コンテナを示すためにバケットという用語を使用します。バケットという用語は、コンテナという用語に相当します。バケットには、データ・オブジェクトのコレクションを保持できます。

python-botoパッケージがまだインストールされていない場合はインストールします。
```
# yum install python-boto
```

S3アクセスのテストに使用可能なPythonスクリプトを作成します。テキスト・エディタを使用してs3test.pyという名前のファイルを作成し、次のコードを挿入します。

#!/usr/bin/env python
import boto
import boto.s3.connection

access_key = 'SZUP3NC5P7452N1HQT4B'
secret_key = 'v0Ok4YK0MtcSZURk6vwCwRtQnB3vAW2G8TjrAlIj'
conn = boto.connect_s3(
        aws_access_key_id = access_key,
        aws_secret_access_key = secret_key,
        host = 'ceph-node1.example.com', port = 7480,
        is_secure=False, calling_format = boto.s3.connection.OrdinaryCallingFormat(),
        )

bucket = conn.create_bucket('my-bucket')
for bucket in conn.get_all_buckets():
            print "{name} {created}".format(
                    name = bucket.name,
                    created = bucket.creation_date,
            )

access_key値SZUP3NC5P7452N1HQT4Bを、S3アクセス用に作成したtestuserユーザーのアクセス・キーに置き換えます。secret_key値v0Ok4YK0MtcSZURk6vwCwRtQnB3vAW2G8TjrAlIjを、S3アクセス用に作成したtestuserユーザーに対して生成された秘密キーに置き換えます。ceph-node1.example.comを、ゲートウェイ・ホストが配置されているホスト名または完全修飾ドメイン名に置き換えます。デフォルトとは別のポートを構成している場合は、ポート番号7480を置き換えます。

このスクリプトに複数のバケットを作成する場合は、たとえば次のように、バケット配列に追加します。

...

bucket = conn.create_bucket('my-bucket-1')
bucket = conn.create_bucket('my-bucket-2')
bucket = conn.create_bucket('my-bucket-3')
bucket = conn.create_bucket('my-bucket-4')
for bucket in conn.get_all_buckets():
            print "{name} {created}".format(
                    name = bucket.name,
                    created = bucket.creation_date,
            )

スクリプトを実行できるようにスクリプトの権限を変更します。
```
# chmod 776 ./s3test.py
```
次のスクリプトを実行します。
```
# ./s3test.py my-bucket 2018-06-05T04:05:10.130Z
```
このスクリプトは、新しいバケットの名前と、その作成日およびタイムスタンプを戻します。

すべてのバケットをリストする場合は、radosgw-admin bucket listコマンドを使用します。

Swiftアクセスをテストする必要がある場合は、Swiftコマンドライン・クライアントをインストールして、このために作成したサブユーザー用に生成された秘密キーを使用します。

python-swiftclientパッケージとそれに依存するファイルをインストールします。
```
# yum install python-swiftclient
```

コマンドラインで、適切な資格証明と接続情報を指定してクライアントを実行します。

# swift -A http://ceph-node1.example.com:7480/auth/1.0 -U testuser:swift \
   -K '2DHaQknPsc5XsYEmHQ0mWCGLnoGnaCr4VUd62czm' list my-bucket

ceph-node1.example.comを、ゲートウェイ・ホストが配置されているホスト名または完全修飾ドメイン名に置き換えます。デフォルトとは別のポートを構成している場合は、ポート番号7480を置き換えます。testuser:swiftを、testuserユーザーのSwiftアクセス用に作成したサブユーザーに置き換えます。2DHaQknPsc5XsYEmHQ0mWCGLnoGnaCr4VUd62czmを、Swiftサブユーザー用に生成されたSwiftの秘密キーに置き換えます。このコマンドと使用可能なオプションの詳細は、man swiftを実行してください。

このコマンドでは、S3アクセスのテスト時に作成されたバケットを含む、Ceph内の既存のバケットがすべてリストされます。

ポート番号の変更

Ceph Object GatewayのHTTPインタフェース用に使用されるポート番号は、デプロイメント・ノードのCeph構成ファイルで更新または変更できます。Ceph Object Gatewayで使用するポート番号を変更するには、デプロイメント・ノードで$CEPH_CONFIG_DIR/ceph.confファイルを編集します。構成ファイルの最後に次の行を追加します。

[client.rgw.ceph-node1]
rgw_frontends = "civetweb port=80"

ceph-node1を、ゲートウェイのデプロイ時に使用した解決可能なホスト名に置き換えます。80を、HTTPポート用に使用するポート番号に置き換えます。

構成変更をゲートウェイ・ノードとクラスタ内の他のノードにプッシュするには、次のコマンドを実行します。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node2

複数のノードに構成をプッシュするには、たとえば次のように、それらをスペース区切りのリストに指定します。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node2 ceph-node3 ceph-node4

ゲートウェイ・ノードでCeph Object Gatewayを再起動して、設定を有効にします。

# systemctl restart ceph-radosgw@*

Transport Layer Securityの有効化

本番環境で認識された認証局(CA)によって署名された証明書を使用することをお薦めします。テスト環境では、自己署名証明書を作成して使用できます。証明書はPEM形式(X.509v3)である必要があります。

自己署名証明書を作成するには:

Ceph Object GatewayサービスでTransport Layer Security (TLS)を有効にするには、ゲートウェイ・ホストにOpenSSLパッケージをインストールする必要があります(まだインストールされていない場合)。
```
# yum install -y openssl mod_ssl
```
キーと証明書を生成する作業ディレクトリで、テンプレートのOpenSSL構成ファイルのコピーを作成します。
```
# cp /etc/pki/tls/openssl.cnf ./
```
./openssl.cnfの構成ファイル・テンプレートを修正し、次の変更を行います。
1. [ req ]セクションで、次の行が非コメント化されていることと、先頭に#文字が付いていないことを確認します。
```
req_extensions = v3_req # The extensions to add to a certificate request
```
2. [ v3_req ]セクションで、このセクションのパラメータの最後に、次の行を追加します。
```
subjectAltName = @alt_names
```
3. 構成ファイルの最後にセクションを追加します。
```
[ alt_names ]
DNS.1 = hostname.example.com
```
  hostname.example.comを、証明書を作成するホストの完全修飾ドメイン名に置き換えます。

通常どおり証明書キーを生成します。

# openssl genrsa -out hostname.example.com.key 2048

証明書キーと新しいopenssl.cnfファイルを使用して証明書署名リクエスト(CSR)を作成します。

# openssl req -new -key hostname.example.com.key \
-out hostname.example.com.csr -extensions v3_req -config openssl.cnf

生成されたCSRを使用して、信頼できる認証局(CA)から署名証明書を取得することもできます。または、テスト目的で、次のようにこれを使用して自己署名証明書を生成することもできます。
1. v3要件の情報をホストできる新しい構成ファイルv3.cnfを作成します。これを編集して、次の行を追加します。
```
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = hostname.example.com
```
2. 次のOpenSSLコマンドを実行し、CSRとローカル・キーを使用して自己署名証明書を生成します。
```
# openssl x509 -req -days 365 -in hostname.example.com.csr -signkey hostname.example.com.key \
-out hostname.example.com.crt -extensions v3_req -extfile v3.cnf
```

キー、CSRおよび証明書をホスト上の使用可能な場所にコピーします。

# cp -f hostname.example.com.crt /etc/pki/tls/certs/
# cp -f hostname.example.com.csr /etc/pki/tls/private/
# cp -f hostname.example.com.key /etc/pki/tls/private/

Ceph Object Gatewayが起動時に使用可能な、キーと証明書の両方を含む単一のPEMファイルを作成します。

# cp hostname.example.com.crt hostname.example.com.pem
# cat hostname.example.com.key >> hostname.example.com.pem
# cp hostname.example.com.pem /etc/pki/tls/

自己署名証明書を使用する場合、TLSモードでサービスにアクセスしようとすると(特にこのドキュメントのサンプルPythonスクリプトを使用すると)、TLS証明書の検証エラーが発生する可能性があります。

自己署名証明書を使用する場合は、CA証明書をクライアント・システムの証明書バンドルにコピーすることで、エラーを回避できます。たとえば、次を実行します。
```
# cat custom.crt >> /etc/pki/tls/certs/ca-bundle.crt
```
あるいは、クライアント・プログラムまたはスクリプトの環境を使用して、その他の信頼できるCA証明書(PEM形式)へのパスを指定します。その他の信頼できるCA証明書を指定するには、環境変数SSL_CERT_FILEおよびSSL_CERT_DIRを使用できます。たとえば、次を実行します。
```
# SSL_CERT_FILE=/root/ceph/custom.pem python script.py
```
ノート:

本番環境で自己署名証明書を使用することはお薦めしません。

PEM形式の証明書は、クラスタ内の各ノードの/etc/pki/tls/ディレクトリにコピーする必要があります。

クラスタのデプロイメント・ノードで$CEPH_CONFIG_DIR/ceph.confファイルを更新します。[client.rgw.gateway]に既存のエントリがある場合は、次の例のように変更します。または、次のようなエントリを追加します。

[client.rgw.ceph-node1]
rgw_frontends = "civetweb port=443s ssl_certificate=/etc/pki/tls/ceph-node1.example.com.pem

ceph-node1を、ゲートウェイのデプロイ時に使用した解決可能なホスト名に置き換えます。443を、HTTPSポート用に使用するポート番号に置き換えます。ポート番号に文字sを添付して、このポートではHTTPSを使用する必要があることを埋込みCivetweb Webサーバーに指示します。/etc/pki/tls/ceph-node1.example.com.pemを、証明書とキー・ファイルの両方が格納されているPEM形式ファイルのパスで置き換えます。

構成変更をゲートウェイ・ノードとクラスタ内の他のノードにプッシュするには、次のコマンドを実行します。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node2

複数のノードに構成をプッシュするには、たとえば次のように、それらをスペース区切りのリストに指定します。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node2 ceph-node3 ceph-node4

ゲートウェイ・ノードでCeph Object Gatewayを再起動して、設定を有効にします。

# systemctl restart ceph-radosgw@*

ゲートウェイ・ノード上でファイアウォール・ソフトウェアが動作している場合は、構成ファイルに定義されているポート上でトラフィックを許可するルールが存在することを確認してください。次に例を示します。

 # firewall-cmd --zone=public --add-port=443/tcp --permanent

マルチサイトCeph Object Gatewayの設定

マルチサイト構成のCeph Object Gatewayをデプロイすると、1つのゾーン・グループ内の異なるゾーン間で同期を行うことができます。マルチサイト構成は、以前のリリースのCephで説明されていたフェデレーテッド構成のCeph Object Gatewayに置き換わるものです。

オラクル社では、異なるCeph Storage Clusterに分散された複数のゾーンが含まれる単一のゾーン・グループで構成されるマルチサイト構成をテストしています。ゲートウェイ間でデータ変更をミラー化する同期エージェント(より単純なアクティブ-アクティブ構成が可能)は構成されていません。すべてのメタデータ操作(新規ユーザーの作成など)は、マスター・ゾーン経由で作成する必要がありますが、データ操作(バケットやオブジェクトの作成など)は、デプロイメント内のどのゾーンでも処理できます。

次の構成ステップでは、ゾーン間でアクティブにデータを同期する3つの異なるゾーンが含まれる単一のゾーン・グループで構成された2つのCeph Storage Clusterからなる基本のマルチサイト構成について説明します。このサンプル設定は、ローカル・ストレージが使用可能な3つのサーバー上にデプロイされます。ここでは、システムに既存のCeph構成がないことと、システムがCephパッケージとそれに依存するファイルにアクセスできることを前提としています(「Ceph Storage for Oracle Linuxパッケージへのアクセスの有効化」を参照)。

このサンプル構成では、次のネーミング規則が使用されています。

レルム: gold
マスター・ゾーン・グループ: us
マスター・ゾーン: us-east-1
セカンダリ・ゾーン: us-east-2
セカンダリ・ゾーン: us-west

ゾーンus-east-1およびus-east-2は、同じCeph Storage Clusterに属しています。ゾーンus-westは、第2 Ceph Storage Clusterにインストールされています。

第1 Ceph Storage Clusterの設定

ceph-deployツールを、第1クラスタに属するシステムのいずれかにインストールします。
```
# yum install ceph-deploy
```
このシステムは、この手順の残りの部分で、「第1クラスタ・デプロイメント・ノード」と呼ばれています。
たとえば次のように、Ceph Storage Clusterの空の作業用Ceph構成ディレクトリを作成し、このディレクトリに変更します。
```
# rm -rf /var/mydom_ceph
# mkdir /var/mydom_ceph
# cd /var/mydom_ceph
```
ここで作成される/var/mydom_cephディレクトリは、この例の残りのコマンドで$CEPH_CONFIG_DIRとして参照されます。
システムに既存のCeph構成情報またはデータがある場合は、それをクリアします。
```
# $CEPH_CONFIG_DIR/ceph-deploy purge ceph-node1 ceph-node2 
# $CEPH_CONFIG_DIR/ceph-deploy purgedata ceph-node1 ceph-node2
```
ノード名を、Ceph Storage Clusterに参加しているシステムのホスト名に置き換えます。
Ceph Storage Cluster構成をデプロイします。
```
# $CEPH_CONFIG_DIR/ceph-deploy new ceph-node1 ceph-node2
```
ノード名を、Ceph Storage Clusterに参加しているシステムのホスト名に置き換えます。
必要な構成変数を使用して、構成テンプレートを更新します。たとえば、次を実行します。
```
# echo "osd pool default size = 2" >> ceph.conf
```
各ノードにCephパッケージをインストールします。
```
# $CEPH_CONFIG_DIR/ceph-deploy install ceph-node1 ceph-node2
```
ノード名を、Ceph Storage Clusterに参加しているシステムのホスト名に置き換えます。
1つ以上のノードにCephモニターをデプロイします。
```
# $CEPH_CONFIG_DIR/ceph-deploy mon create-initial 
# $CEPH_CONFIG_DIR/ceph-deploy mon create ceph-node1 ceph-node2
# $CEPH_CONFIG_DIR/ceph-deploy gatherkeys ceph-node1
```
ノード名を、Cephモニター・ノードとして指定するノードのホスト名に置き換えます。
Cephモニターを実行しているノードにCephマネージャをデプロイします。
```
# $CEPH_CONFIG_DIR/ceph-deploy mgr create ceph-node1 ceph-node2
```
ノード名を、Cephマネージャ・ノードとして指定するノードのホスト名に置き換えます。
各ノードの使用可能なディスクをオブジェクト・ストレージ・デバイス(OSD)として機能するように準備します。
```
# $CEPH_CONFIG_DIR/ceph-deploy disk zap ceph-node1 /dev/sdb
# $CEPH_CONFIG_DIR/ceph-deploy osd create --data /dev/sdb ceph-node1
# $CEPH_CONFIG_DIR/ceph-deploy disk zap ceph-node2 /dev/sdc
# $CEPH_CONFIG_DIR/ceph-deploy osd create --data /dev/sdc ceph-node2
```
ノード名を、Ceph Storage Clusterに参加しているシステムのホスト名に置き換えます。sdbおよびsdcを、各ホスト上で使用可能なディスクの適切なデバイス名に置き換えます。これらのディスクでは、再パーティション化とフォーマットが行われ、ディスク上の既存のデータは破棄されます。

OSDノードの作成の詳細は、「オブジェクト・ストレージ・デバイス(OSD)ノードの作成」を参照してください。
Cephクラスタのステータスをチェックして、Ceph Storage Clusterが正常であること、およびOSDが使用可能であることを確認します。管理ノードで、次のように入力します。
```
# ceph status
```

第1 Ceph Storage ClusterでのCeph Object Gatewayインスタンスの設定

第1 Ceph Storage Clusterデプロイメント・ノードから、クラスタ内の各ノードにCeph Object Gatewayソフトウェアをインストールします。
```
# $CEPH_CONFIG_DIR/ceph-deploy install --rgw ceph-node1 ceph-node2 
# $CEPH_CONFIG_DIR/ceph-deploy rgw create ceph-node1 ceph-node2
```
Ceph Object Gatewayソフトウェアをインストールするには、ノード名を、Ceph Storage Clusterに参加しているシステムのホスト名に置き換えます。
第1 Ceph Storage Clusterデプロイメント・ノードで$CEPH_CONFIG_DIR/ceph.confのテンプレート構成を編集し、構成ファイルの最後に次の行を追加します。
```
[client.rgw.ceph-node1]
rgw_frontends = "civetweb port=80"

[client.rgw.ceph-node2]
rgw_frontends = "civetweb port=80"
```
ceph-node1およびceph-node2を、ゲートウェイ・システムのホスト名に置き換えます。
たとえば次のように、Ceph Storage Clusterの各ノードに構成をプッシュします。
```
# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node1 ceph-node2
```
各ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
```
# systemctl restart ceph-radosgw@*
# systemctl status ceph-radosgw@*
```

第1 Ceph Storage Clusterでの必要なプールの作成

Ceph Object Gatewayには、ゲートウェイ関連データを格納するための複数のプールが必要です。ゲートウェイがゾーンとして構成されている場合は、通常、ネーミング規則zone.pool-nameを使用してゾーン専用のプールを作成します。そのためには、Ceph Storage Cluster内の各ゾーンで必要なすべてのプールを手動で作成することをお薦めします。

第1 Ceph Storage Clusterデプロイメント・ノード上でコマンドを実行し、このクラスタでホストされている各ゾーンに必要なすべてのプールを作成します。たとえば、次を実行します。

# ceph osd pool create ceph-us-east-1.rgw.control 4 4
# ceph osd pool create ceph-us-east-1.rgw.data.root 4 4
# ceph osd pool create ceph-us-east-1.rgw.gc 4 4
# ceph osd pool create ceph-us-east-1.rgw.log 4 4
# ceph osd pool create ceph-us-east-1.rgw.intent-log 4 4
# ceph osd pool create ceph-us-east-1.rgw.usage 4 4
# ceph osd pool create ceph-us-east-1.rgw.users.keys 4 4
# ceph osd pool create ceph-us-east-1.rgw.users.email 4 4
# ceph osd pool create ceph-us-east-1.rgw.users.swift 4 4
# ceph osd pool create ceph-us-east-1.rgw.users.uid 4 4
# ceph osd pool create ceph-us-east-1.rgw.buckets.index 8 8
# ceph osd pool create ceph-us-east-1.rgw.buckets.data 64 64 
# ceph osd pool create ceph-us-east-1.rgw.meta 4 4

# ceph osd pool create ceph-us-east-2.rgw.control 4 4
# ceph osd pool create ceph-us-east-2.rgw.data.root 4 4
# ceph osd pool create ceph-us-east-2.rgw.gc 4 4
# ceph osd pool create ceph-us-east-2.rgw.log 4 4
# ceph osd pool create ceph-us-east-2.rgw.intent-log 4 4
# ceph osd pool create ceph-us-east-2.rgw.usage 4 4
# ceph osd pool create ceph-us-east-2.rgw.users.keys 4 4
# ceph osd pool create ceph-us-east-2.rgw.users.email 4 4
# ceph osd pool create ceph-us-east-2.rgw.users.swift 4 4
# ceph osd pool create ceph-us-east-2.rgw.users.uid 4 4
# ceph osd pool create ceph-us-east-2.rgw.buckets.index 8 8
# ceph osd pool create ceph-us-east-2.rgw.buckets.data 64 64 
# ceph osd pool create ceph-us-east-2.rgw.meta 4 4

ヒント:

アップストリームのCeph PGs per Pool Calculatorを使用して、ご使用の環境のOSD数に基づいてプールのページ・サイズを計算できます。

システム・キーの作成

ゾーンの構成時、各ゲートウェイ・インスタンスには、S3-likeアクセスを許可するように設定された資格証明を持つシステム・ユーザーが必要です。これにより、各ゲートウェイ・インスタンスは、アクセス・キーと秘密キーを使用して構成をリモートでプルできます。各ゲートウェイ・インスタンスで同じキーが構成されていることを保証するには、これらのキーを事前に定義して、ゾーンおよびユーザーの作成時に手動で設定することをお薦めします。

構成の設定時に、これらを再利用可能な環境変数として設定し、できるかぎりキーをランダムにすることをお薦めします。

# 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)

これらのキーが設定され、適切な情報が含まれていることを、次のようにして確認できます。

# echo SYSTEM_ACCESS_KEY=$SYSTEM_ACCESS_KEY
# echo SYSTEM_SECRET_KEY=$SYSTEM_SECRET_KEY

これらのコマンド出力の記録を保存します。第2 Ceph Storage Clusterと、ここに配置されているセカンダリ・ゾーンを設定する際は、同じ環境変数をエクスポートする必要があります。

レルムおよびマスター・ゾーンの構成

マルチサイト構成を、goldという名前の単一レルムを中心に構築し、usと呼ばれる単一のゾーン・グループを設定します。このゾーン・グループにはceph-us-east-1という名前のマスター・ゾーンがあります。次のステップでは、これらのコンポーネントを作成して構成する方法を説明します。

レルムを作成し、これをデフォルトに設定します。
```
# radosgw-admin realm create --rgw-realm=gold --default
```
Ceph Object Gatewayソフトウェアの簡易インストールの一環として作成されるデフォルトのゾーン・グループを削除します。
```
# radosgw-admin zonegroup delete --rgw-zonegroup=default
```
新しいマスター・ゾーン・グループを作成します。マスター・ゾーン・グループはゾーン・グループ・マップを制御し、システム全体に変更を伝播します。このゾーン・グループをデフォルト・ゾーン・グループとして設定し、今後、--rgw-zonegroupスイッチを使用して明示的に指定することなく、このゾーン・グループに対してコマンドを実行できるようにします。
```
# radosgw-admin zonegroup create --rgw-zonegroup=us \
 --endpoints=http://ceph-node1.example.com:80 --master --default
```
マスター・ゾーンを作成し、これをデフォルト・ゾーンに設定します。メタデータ操作(ユーザーの作成など)では、このゾーンを使用する必要があります。作成時にゾーンをゾーン・グループに追加し、このゾーンに対して使用するアクセス・キーと秘密キーを指定することもできます。
```
# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=ceph-us-east-1 \
 --endpoints=http://ceph-node1.example.com:80 --access-key=$SYSTEM_ACCESS_KEY \
 --secret=$SYSTEM_SECRET_KEY --default --master
```
ゾーン・プールへのアクセスに使用可能なシステム・ユーザーを作成します。このユーザーのキーは、構成対象の各ゾーンで使用されるキーと一致する必要があります。
```
# radosgw-admin user create --uid=zone.user --display-name="ZoneUser" \
  --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY --system
```
レルムの期間には、レルムの現在の状態の構成構造全体が保持されます。レルムの情報(ゾーン・グループやゾーンの構成など)が変更されたときは、期間でその変更内容が更新される必要があります。これを行うには、変更をコミットします。
```
# radosgw-admin period update --commit
```

セカンダリ・ゾーンの構成

次のコマンドは第1 Ceph Storage Clusterデプロイメント・ノード上で実行できますが、ゾーン・グループとレルム構成を更新して、クラスタ内の他のノード上でホストされるセカンダリ・ゾーンを追加するために使用します。

セカンダリ・ゾーンを作成し、マスター・ゾーンで使用されているものと同じアクセス・キーと秘密キーを必ず指定します。

# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=ceph-us-east-2 \
    --endpoints=http://ceph-node2.example.com:80 \
    --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY

レルムの期間を新しい構成情報で更新します。
```
# radosgw-admin period update --commit
```

Ceph構成の更新およびゲートウェイの再起動

第1 Ceph Storage Clusterデプロイメント・ノードで作業ディレクトリのテンプレート構成を編集し、ゾーン名を各ゲートウェイ構成にマップします。これを行うには、各ノードのゲートウェイ構成エントリにrgw_zone変数用の行を追加します。

[client.rgw.ceph-node1]
rgw_frontends = "civetweb port=80"
rgw_zone=ceph-us-east-1

[client.rgw.ceph-node2]
rgw_frontends = "civetweb port=80"
rgw_zone=ceph-us-east-2

テンプレート構成を更新したら、Ceph Storage Cluster内の各ノードに変更をプッシュします。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node1 ceph-node2

各ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。

# systemctl restart ceph-radosgw@*
# systemctl status ceph-radosgw@*

第2 Ceph Storage Clusterの設定

第1とほぼ同じ方法で、第2 Ceph Storage Clusterをインストールしてデプロイします。この例では、第2クラスタは単一ノードで構成されますが、必要に応じてノードを追加することもできます。このノードは、最終的にceph-us-westゾーンのゲートウェイをホストします。

次のコマンドは、Ceph Storage Clusterをデプロイするステップと、ストレージ用に使用可能なOSDを構成するステップをまとめたものです。これらのコマンドは、第1クラスタの外部の新規サーバーceph-node3で発行する必要があります。

# mkdir -p /var/mydom_ceph; cd /var/mydom_ceph
# yum install ceph-deploy
# $CEPH_CONFIG_DIR/ceph-deploy new ceph-node3 
# $CEPH_CONFIG_DIR/echo "osd pool default size = 2" >> ceph.conf
# $CEPH_CONFIG_DIR/ceph-deploy install ceph-node3
# $CEPH_CONFIG_DIR/ceph-deploy mon create-initial 
# $CEPH_CONFIG_DIR/ceph-deploy mon create ceph-node3 
# $CEPH_CONFIG_DIR/ceph-deploy mgr create ceph-node3 
# $CEPH_CONFIG_DIR/ceph-deploy gatherkeys ceph-node3
# $CEPH_CONFIG_DIR/ceph-deploy disk zap ceph-node3 /dev/sdb
# $CEPH_CONFIG_DIR/ceph-deploy osd create --data /dev/sdb ceph-node3

第2 Ceph Storage ClusterでのCeph Object Gatewayインスタンスの設定

Ceph Storage Cluster内に新しくデプロイされたノードに、Ceph Object Gatewayソフトウェアをインストールします。
```
# $CEPH_CONFIG_DIR/ceph-deploy install --rgw ceph-node3
# $CEPH_CONFIG_DIR/ceph-deploy rgw create ceph-node3
```
ceph-node3を、Ceph Object Gatewayソフトウェアをインストールするノードのホスト名に置き換えます。
第2 Ceph Storage Clusterデプロイメント・ノードで$CEPH_CONFIG_DIR/ceph.confのテンプレート構成を編集し、構成ファイルの最後に次の行を追加します。
```
[client.rgw.ceph-node3]
rgw_frontends = "civetweb port=80"
```
ceph-node3を、ゲートウェイ・システムのホスト名に置き換えます。

Ceph Storage Clusterの各ノードに構成をプッシュします。

# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node3

ゲートウェイ・ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
```
# systemctl restart ceph-radosgw@*
# systemctl status ceph-radosgw@*
```

第2 Ceph Storage Clusterでの必要なプールの作成

次のコマンドを実行し、第2 Ceph Storage Cluster上でCeph Object Gatewayに必要なプールを作成します。

# ceph osd pool create ceph-us-west.rgw.control 4 4
# ceph osd pool create ceph-us-west.rgw.data.root 4 4
# ceph osd pool create ceph-us-west.rgw.gc 4 4
# ceph osd pool create ceph-us-west.rgw.log 4 4
# ceph osd pool create ceph-us-west.rgw.intent-log 4 4
# ceph osd pool create ceph-us-west.rgw.usage 4 4
# ceph osd pool create ceph-us-west.rgw.users.keys 4 4
# ceph osd pool create ceph-us-west.rgw.users.email 4 4
# ceph osd pool create ceph-us-west.rgw.users.swift 4 4
# ceph osd pool create ceph-us-west.rgw.users.uid 4 4
# ceph osd pool create ceph-us-west.rgw.buckets.index 8 8
# ceph osd pool create ceph-us-west.rgw.buckets.data 64 64 
# ceph osd pool create ceph-us-west.rgw.meta 4 4

レルム構成の更新

第1 Ceph Storage Clusterで設定したものと同じSYSTEM_ACCESS_KEYおよびSYSTEM_SECRET_KEY環境変数をエクスポートします。たとえば、次を実行します。
```
# SYSTEM_ACCESS_KEY=OJywnXPrAA4uSCgv1UUs
# SYSTEM_SECRET_KEY=dIpf1FRPwUYcXfswYx6qjC0eSuHEeHy0I2f9vHFf
```
これらのキーを使用し、次のコマンドを発行して、マスター・ゾーンが実行されているノード経由で、第1 Ceph Storage Clusterからレルム構成を直接プルします。
```
# radosgw-admin realm pull --url=http://ceph-node1.example.com:80 \
  --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
```
マスター・ゾーンが実行されているノード経由で、第1 Ceph Storage Clusterから期間の状態を直接プルします。
```
# radosgw-admin period pull --url=http://ceph-node1.example.com:80 \
  --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
```
ゲートウェイ・インスタンスのデフォルト・レルムをgoldに設定します。
```
# radosgw-admin realm default --rgw-realm=gold
```
デフォルトのゾーン・グループをusに設定します。
```
# radosgw-admin zonegroup default --rgw-zonegroup=us
```

セカンダリ・ゾーンの構成

新しいセカンダリ・ゾーンceph-us-westを作成して、usゾーン・グループに追加します。ゾーンの作成時には、第1 Ceph Storage Clusterの元の構成で使用したものと同じアクセス・キーと秘密キーを必ず使用してください。
```
# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=ceph-us-west \ 
 --endpoints=http://ceph-node3.example.com:80 \
 --default --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
```
ゾーン・グループの変更をコミットして、期間の状態を更新します。
```
# radosgw-admin period update --commit --rgw-zone=ceph-us-west
```
作業ディレクトリで$CEPH_CONFIG_DIR/ceph.confのテンプレート構成を編集し、ゾーン名を各ゲートウェイ構成にマップします。これを行うには、ゲートウェイ構成エントリにrgw_zone変数用の行を追加します。
```
[client.rgw.ceph-node3]
rgw_frontends = "civetweb port=80"
rgw_zone=ceph-us-west

[client.rgw.ceph-node2]
rgw_frontends = "civetweb port=80"
rgw_zone=ceph-us-east-2
```
テンプレート構成を更新したら、Ceph Storage Cluster内の各ノードに変更をプッシュします。
```
# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node3
```
Ceph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
```
# systemctl restart ceph-radosgw@*
# systemctl status ceph-radosgw@*
```

ゾーン同期のテスト

この時点で、すべてのゾーンが実行され、同期されているはずです。

同期をテストするには、任意のゾーンにバケットを作成してから、別のゾーンでバケットのリストを表示します。どのゾーンでも新しく作成されたバケットが表示されることがわかります。

このテストは、簡単なPythonスクリプトを使用して実行できます。次に示したサンプル・スクリプトを、ゾーンが実行されている各ノードにアクセス可能な任意のホスト上で~/s3zone_test.pyという名前のファイルにコピーします。

#!/usr/bin/env python

import boto
import boto.s3.connection
from optparse import OptionParser

parser = OptionParser()
parser.add_option("--access_key", dest="access_key", default="OJywnXPrAA4uSCgv1UUs")
parser.add_option("--secret_key", dest="secret_key", default="dIpf1FRPwUYcXfswYx6qjC0eSuHEeHy0I2f9vHFf")
parser.add_option("-H","--host", dest="host", default="ceph-node1.example.com")
parser.add_option("-s","--secure",dest="is_secure", action="store_true", default=False)
parser.add_option("-c","--create", dest="bucket")

(options,args) = parser.parse_args()

conn = boto.connect_s3(
 aws_access_key_id = options.access_key,
 aws_secret_access_key = options.secret_key,
 host = options.host,
 is_secure=options.is_secure,
 calling_format = boto.s3.connection.OrdinaryCallingFormat(),
)
if options.bucket:
    bucket = conn.create_bucket(options.bucket)

for bucket in conn.get_all_buckets():
        print "{name}\t{created}".format(
                name = bucket.name,
                created = bucket.creation_date,
)

スクリプト内のaccess_key、secret_keyおよびhostのデフォルト値を、現在の環境にあわせて置き換えます。

スクリプトをテストするには、スクリプトのアクセス権を変更して、スクリプトを実行できるようにします。

# chmod 775 ~/s3zone_test.py

スクリプトを正常に実行するための適切なライブラリがすべてインストールされていることを確認します。

# yum install python-boto

スクリプトではオプションを使用して、どのゾーン・ホストに対してスクリプトを実行するかなどの様々な変数を設定したり、新しいバケットを作成するかどうかを指定することができます。次のコマンドを実行して、最初のゾーンに新しいバケットを作成します。

# ~/s3zone_test.py --host ceph-node1 -c my-bucket-east-1 
my-bucket-east-1 2016-09-21T09:16:14.894Z

ここで、他の2つのノードをチェックして、新しいバケットが同期されていることを確認します。

# ~/s3zone_test.py --host ceph-node2
my-bucket-east-1        2016-09-21T09:16:16.932Z
# ~/s3zone_test.py --host ceph-node3
my-bucket-east-1        2016-09-21T09:16:15.145Z

データの同期に要した時間により、それぞれのタイムスタンプは異なります。第2 Ceph Storage Clusterに配置されているゾーンでのバケットの作成もテストできます。

# ~/s3zone_test.py --host ceph-node3 -c my-bucket-west-1
my-bucket-east-1        2016-09-21T09:16:15.145Z
my-bucket-west-1        2016-09-21T09:22:15.456Z

このバケットが他のゾーンに同期されていることを確認します。

# ~/s3zone_test.py --host ceph-node1
my-bucket-east-1        2016-09-21T09:16:14.894Z
my-bucket-west-1        2016-09-21T09:22:15.428Z
# ~/s3zone_test.py --host ceph-node2
my-bucket-east-1        2016-09-21T09:16:16.932Z
my-bucket-west-1        2016-09-21T09:22:17.488Z

Transport Layer Securityの構成

マルチサイトCeph Object GatewayのデプロイメントでTransport Layer Security (TLS)を構成する場合は、各ゾーンで証明書を検証できることが非常に重要です。つまり、自己署名証明書を使用する場合は、各ゾーンで、信頼できるCAバンドル内にすべての証明書のコピーがすでに保持されている必要があります。あるいは、信頼できる認証局による署名付きの証明書を使用するようにしてください。

この例で示したステップでは、各ゲートウェイ・ノードの自己署名証明書を作成する方法、生成された証明書をノード間で共有して検証できるようにする方法、および既存のマルチサイト構成を変更してTLSを有効にする方法を示しています。

TLSを設定するには:

デプロイメント内の各ゲートウェイ・ノードの証明書を作成します。

各ゲートウェイ・ノードで、次のコマンドを実行します。

# cd /etc/ceph
# openssl genrsa -out ca.key 2048
# openssl req -new -key ca.key -out ca.csr -subj \
    "/C=US/ST=California/L=RedWoodShore/O=Oracle/OU=Linux/CN=`hostname`"
# openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
# cp -f ca.crt /etc/pki/tls/certs/`hostname`.crt
# cp -f ca.key /etc/pki/tls/private/`hostname`.key
# cp -f ca.csr /etc/pki/tls/private/`hostname`.csr
# cp ca.crt /etc/pki/tls/`hostname`.pem
# cat ca.key >> /etc/pki/tls/`hostname`.pem

証明書のsubject行の値は、所属する組織に適した値に変更できますが、証明書のCommonName (CN)が現在のゾーン構成のエンドポイントURLで使用するホスト名に解決されることを確認してください。

証明書を各ゲートウェイ・ノードから各ノードの/etc/pki/tls/certs/ca-bundle.crtに記述されている信頼できるCAのコレクションにコピーします。

たとえば、ceph-node1で次を実行します。

# cat /etc/ceph/ca.crt >> /etc/pki/tls/certs/ca-bundle.crt
# cat /etc/ceph/ca.crt | ssh root@ceph-node2 "cat >> /etc/pki/tls/certs/ca-bundle.crt"
# cat /etc/ceph/ca.crt | ssh root@ceph-node3 "cat >> /etc/pki/tls/certs/ca-bundle.crt"

ceph-node2の場合:

# cat /etc/ceph/ca.crt >> /etc/pki/tls/certs/ca-bundle.crt
# cat /etc/ceph/ca.crt | ssh root@ceph-node1 "cat >> /etc/pki/tls/certs/ca-bundle.crt"
# cat /etc/ceph/ca.crt | ssh root@ceph-node3 "cat >> /etc/pki/tls/certs/ca-bundle.crt"

ceph-node3の場合:

# cat /etc/ceph/ca.crt >> /etc/pki/tls/certs/ca-bundle.crt
# cat /etc/ceph/ca.crt | ssh root@ceph-node1 "cat >> /etc/pki/tls/certs/ca-bundle.crt"
# cat /etc/ceph/ca.crt | ssh root@ceph-node2 "cat >> /etc/pki/tls/certs/ca-bundle.crt"

環境内の任意のノードでファイアウォール・サービスが動作している場合、ポート443上でトラフィックが許可されていることを確認してください。たとえば、次を実行します。
```
# firewall-cmd --zone=public --add-port=443/tcp --permanent
# systemctl restart firewalld.service
```
ゾーン・エンドポイントへのアクセスにはHTTPSを使用するよう、既存のゾーン・グループ情報を変更します。

これを行うには、次のコマンドを実行します。
```
# radosgw-admin zonegroup get|sed -r 's/http(.*):80/https\1:443/g' >/tmp/zonegroup.json
# radosgw-admin zonegroup set --infile /tmp/zonegroup.json
# radosgw-admin period update --commit
```
環境内の各ノード上でCeph Object Gatewayを再デプロイし、以前の構成をリセットして、証明書に使用されているCNと一致する完全ホスト名を使用してノードがデプロイされるようにします。

第1 Ceph Storage Clusterデプロイメント・ノードから次のコマンドを実行します。
```
# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf rgw create ceph-node1.example.com \
    ceph-node2.example.com
```
ceph-node1.example.comおよびceph-node2.example.comを、ゲートウェイ・ソフトウェアが動作しているノードの完全ホスト名に置き換えて、それぞれの証明書で使用されているCNと一致するようにします。

第2 Ceph Storage Clusterデプロイメント・ノードから次のコマンドを実行します。
```
# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf rgw create ceph-node3.example.com
```
ceph-node3.example.comを、ゲートウェイ・ソフトウェアが動作しているノードの完全ホスト名に置き換えて、このノード用に生成した証明書で使用されているCNと一致するようにします。

この時点で、すべてのゲートウェイ・サービスがデフォルト・ポート7480上で実行を再開しているはずです。
各Ceph Storage Clusterのデプロイメント・ノードでテンプレート構成を編集し、ポート番号を変更して、各ゲートウェイのTLS証明書(PEMファイル)の場所を指定します。

たとえば、ceph-node1で、$CEPH_CONFIG_DIR/ceph.confを編集し、ゲートウェイ構成エントリを変更します。エントリ・ラベルで完全ホスト名が使用されていることと、ポートが変更され、SSL証明書のパスを指しているエントリが追加されていることを確認してください。
```
...
osd pool default pg num = 100
osd pool default pgp num = 100
mon pg warn max per osd = 2100

[client.rgw.ceph-node1.example.com]
rgw_frontends = "civetweb port=443s ssl_certificate=/etc/pki/tls/ceph-node1.example.com.pem"
rgw_zone=ceph-us-east-1

[client.rgw.ceph-node2.example.com]
rgw_frontends = "civetweb port=443s ssl_certificate=/etc/pki/tls/ceph-node2.example.com.pem"
rgw_zone=ceph-us-east-2
```
変更された構成を各ゲートウェイ・ノードにプッシュします。
```
# $CEPH_CONFIG_DIR/ceph-deploy --overwrite-conf config push ceph-node1 ceph-node2
```
各ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
```
# systemctl restart ceph-radosgw@*
# systemctl status ceph-radosgw@*
```
第2 Ceph Storage Clusterデプロイメント・ノードでこのステップを繰り返し、ceph-node3.example.comの構成を更新します。
この時点で、各ゲートウェイ・エントリはTLSを使用するように構成されているはずです。ゾーンで引き続き同期が正しく実行されていることと、TLSが使用されていることをテストするには、テスト・スクリプト~/s3zone_test.pyを使用し、忘れずに-sスイッチを使用してTLSを有効にします。

たとえば、次を実行します。
```
# ~/s3zone_test.py -s --host ceph-node2.example.com -c my-bucket-east-2
my-bucket-east-1        2016-09-21T09:16:16.932Z
my-bucket-east-2        2016-09-21T14:09:51.287Z
my-bucket-west-1        2016-09-21T09:22:17.488Z
# ~/s3zone_test.py -s --host ceph-node3.example.com
my-bucket-east-1        2016-09-21T09:16:15.145Z
my-bucket-east-2        2016-09-21T14:09:58.783Z
my-bucket-west-1        2016-09-21T09:22:15.456Z
```
-sスイッチを設定しないでスクリプトを使用すると、スクリプトはポート80上でTLSを使用せずに接続しようとして失敗し、最終的にはソケット・エラーで終了します。
```
socket.error: [Errno 111] Connection refused
```
自己署名証明書を使用する場合、TLSモードでサービスにアクセスしようとすると(特にこのドキュメントのサンプルPythonスクリプトを使用すると)、TLS証明書の検証エラーが発生する可能性があります。

自己署名証明書を使用する場合は、CA証明書をクライアント・システムの証明書バンドルにコピーすることで、エラーを回避できます。たとえば、次を実行します。
```
# cat custom.crt >> /etc/pki/tls/certs/ca-bundle.crt
```
あるいは、クライアント・プログラムまたはスクリプトの環境を使用して、その他の信頼できるCA証明書(PEM形式)へのパスを指定します。その他の信頼できるCA証明書を指定するには、環境変数SSL_CERT_FILEおよびSSL_CERT_DIRを使用できます。たとえば、次を実行します。
```
# SSL_CERT_FILE=/root/ceph/custom.pem python script.py
```
ノート:

本番環境で自己署名証明書を使用することはお薦めしません。

NFSを介したCeph Object Gatewayのエクスポート

Ceph Object Gatewayネームスペースは、NFSプロトコルをサポートするユーザー空間ファイル・サーバーであるNFS-Ganeshaを使用し、NFSを介してエクスポートできます。Ceph Object GatewayでNFS-Ganeshaを使用する方法の詳細は、次のアップストリームのドキュメントを参照してください。

https://docs.ceph.com/en/latest/radosgw/nfs/

NFSサーバーを設定するには:

NFSサーバー・ホストがCephパブリック・ネットワークに接続され、Ceph Storage Clusterに属していることを確認します。
nfs-ganesha-cephおよびnfs-ganesha-rgwの各パッケージをインストールします。
```
# yum install nfs-ganesha-ceph nfs-ganesha-rgw
```
RPCバインド・サービスを起動します。
```
# systemctl start rpcbind
```

nfs-serverサービスを停止して無効にします。

# systemctl stop nfs-server.service 
# systemctl disable nfs-server.service

要件に合わせて、/etc/ganesha/ganesha.confファイルを編集します。たとえば、次のようになります。

EXPORT 
{ 
# Export Id (mandatory, each EXPORT must have a unique Export_Id) 
Export_Id = 2; 

# Use NFSv4
Protocols = 4;

# NFSv4 does not allow UDP transport
Transports = TCP;

# Path into the cephfs tree. For now, FSAL_CEPH doesn't support
# having more than one filesystem per running ganesha daemon.
#
# Note that FSAL_CEPH does not support subtree checking, so there is
# no way to validate that a filehandle presented by a client is
# reachable via an exported subtree.
#
# For that reason, we just export "/" here.
Path = /; 

# Pseudo Path (required for NFS v4) 
# The pseudoroot path. This is where the export will appear in the
# NFS pseudoroot namespace.
Pseudo = /; 

# Required for access (default is None) 
# Could use CLIENT blocks instead 
Access_Type = RW; 
# Squash = no_root_squash; 
SecType = sys; 

# Exporting FSAL 
FSAL { 
    Name = RGW; 
    User_Id = "user"; 
    Access_Key_Id ="access_key_id"; 
    Secret_Access_Key = "secret_access_key"; 
  } 
} 

RGW { 
    ceph_conf = "/etc/ceph/ceph.conf"; 
    name = "client.rgw.hostname"; 
    cluster = "ceph"; 
    init_args = "-d --debug-rgw=16"; 
}

user、access_key_idおよびsecret_access_keyの値を、「単純なCeph Object Gatewayの設定」で作成したユーザーおよびキーに置き換えます。hostnameを、Ceph Object Gatewayがインストールおよび構成されているCeph Storage Cluster内のノードに置き換えます。たとえば、次のようになります。

...
# Exporting FSAL 
FSAL { 
    Name = RGW; 
    User_Id = "testuser"; 
    Access_Key_Id ="SZUP3NC5P7452N1HQT4B"; 
    Secret_Access_Key = "v0Ok4YK0MtcSZURk6vwCwRtQnB3vAW2G8TjrAlIj"; 
  } 
} 

RGW { 
    ceph_conf = "/etc/ceph/ceph.conf"; 
    name = "client.rgw.ceph-node1"; 
    cluster = "ceph"; 
    init_args = "-d --debug-rgw=16"; 
}

nfs-ganeshaサービスを再起動します。
```
# systemctl restart nfs-ganesha.service
```
ディレクトリ・マウント・ポイントを作成します(必要な場合)。
```
# mkdir -p /mnt/nfs-ganesha
```

次の構文を使用して、NFS ganeshaファイル・システムをマウントします。

mount -t nfs -o nfsvers=4.1,proto=tcp ganesha-host-name:ganesha-pseudo-path mount-point

たとえば、次を実行します。

# mount -t nfs -o nfsvers=4.1,noauto,soft,sync,proto=tcp ceph-node1:/ /mnt/nfs-ganesha

Ceph Object Gatewayを使用してNFSサーバーを設定した後、最初にバケットを作成せずにマウント・ポイントに書き込むことはできません。テスト・バケットの作成の詳細は、「アクセスのテスト」を参照してください。

バケットが存在する場合は、作成したマウント・ポイントにリストされます(この例では/mnt/nfs-ganesha)。my-bucketという名前のバケットがある場合は、/mnt/nfs-ganesha/my-bucketという名前のディレクトリが表示されます。my-bucketディレクトリで読取り/書込み操作を実行できます。たとえば、次のようになります。

# cd /mnt/nfs-ganesha/my-bucket/
# touch test.txt

Ceph FSの設定および使用

この項では、Cephファイル・システム(Ceph FS)の設定および使用について説明します。この項では、NFSを介してCephファイル・システムをエクスポートする方法についても説明します。Ceph FSの詳細は、次のアップストリームのドキュメントを参照してください。

https://docs.ceph.com/en/latest/cephfs/

Ceph FSの設定

この項では、Ceph FSの設定および使用について説明します。

Ceph FSを設定するには:

Ceph Metadata Server (MDS)をデプロイします。

Ceph FSを使用するには、環境内で1つ以上のMDSがアクティブになっている必要があります。そのための専用サーバーを用意できない場合、MDSサービスでは大容量のリソースを必要としないため、このサービスをCeph Storage Cluster内の既存のモニター・ノードにインストールできます。環境内にMDSをデプロイするには、デプロイメント・ノードから次のコマンドを実行します。
```
# $CEPH_CONFIG_DIR/ceph-deploy mds create ceph-node3
```
Ceph CLIをデプロイします。

Ceph CLIは、Ceph FSをマウントするシステム上にデプロイされている必要があり、そのシステムにはストレージ・クラスタにアクセスするための適切なネットワーク・アクセスと認証キーリングが必要です。Ceph CLIおよびキーリングのデプロイおよび設定の詳細は、「Ceph Storage Cluster管理ホストの作成」を参照してください。
ストレージ・プールと新しいCephファイル・システムを作成します。

Cephファイル・システムが機能するには、2つ以上のストレージ・プールが必要です。1つ目のプールには実際のデータが格納され、2つ目のプールにはメタデータが格納されます。Ceph CLIにはCephファイル・システムを作成および削除するためのコマンドが含まれていますが、同時に存在できるのは1つのファイル・システムのみです。

ストレージ・プールを作成するには、Ceph CLIを使用して次のコマンドを実行します。
```
# ceph osd pool create cephfs_data 1
# ceph osd pool create cephfs_metadata 2
```
新しいCephファイル・システムを作成するには、Ceph CLIを使用して次のコマンドを実行します。
```
# ceph fs new cephfs cephfs_metadata cephfs_data
```
Cephファイル・システムのリストを表示するには、次のコマンドを使用します。
```
# ceph fs ls
```
Ceph MDSのステータスを確認します。

ファイル・システムが作成されると、Ceph MDSはアクティブな状態になります。ファイル・システムをマウントできるのは、MDSがアクティブになってからです。ステータスを確認するには:
```
# ceph mds stat
e5: 1/1/1 up {0=ceph-node3=up:active}
```
管理認証に使用する秘密キーを、Cephファイル・システムのマウントに使用可能なファイルに格納します。

Ceph Storage Clusterの管理キーは、クラスタ内の各ノードの/etc/ceph/ceph.client.admin.keyringと、管理ノードにも格納されています。Cephファイル・システムをマウントする際、マウント要求を認証するために、このキーが必要です。このキーがプロセス・リストに表示されないようにするには、適切な権限で保護されているファイルにキーをコピーして、その情報を保護することをお薦めします。

たとえば、次を実行します。
```
# echo $(sed -n 's/.*key *= *$[^ ]*.*$/\1/p' < /etc/ceph/ceph.client.admin.keyring) > \
    /etc/ceph/admin.secret
# chmod 600 /etc/ceph/admin.secret
# cat /etc/ceph/ceph.client.admin.keyring
[client.admin]
key = AQDIvtZXzBriJBAA+3HmoYkUmPFnKljqhxlYGw==
# cat /etc/ceph/admin.secret
AQDIvtZXzBriJBAA+3HmoYkUmPFnKljqhxlYGw==
```

Ceph FSのマウント

この項では、Cephカーネル・モジュールを使用してCephファイル・システムをマウントする方法について説明します。

ノート:

このリリースでは、FUSEを使用したCephファイル・システムのマウントはサポートされていません。

Ceph FSをマウントするには:

ディレクトリ・マウント・ポイントを作成します(必要な場合)。
```
# mkdir -p /mnt/cephfs
```
ファイル・システムをマウントします。
```
 # mount -t ceph ceph-node2:6789:/ /mnt/cephfs/ \
    -o name=admin,secretfile=/etc/ceph/admin.secret
```
ceph-node2を、Ceph Storage Cluster内のCephモニター・ノードのホスト名またはIPアドレスに置き換えます。ファイル・システムを正常にマウントするために必要なアクティブ・モニターは1つのみですが、複数のモニターのアドレスをカンマで区切って指定できます。使用可能なモニターが不明な場合は、ceph mon statを実行して、使用可能なモニター、それぞれのIPアドレスおよびポート番号のリストを取得できます。

Cephファイル・システムをマウントすると、cephおよびlibcephカーネル・モジュールが自動的にロードされます。
ファイル・システムをアンマウントするには、次のようにします。
```
# umount /mnt/cephfs
```

NFSを介したCeph FSのエクスポート

Ceph FSネームスペースは、NFSプロトコルをサポートするユーザー空間ファイル・サーバーであるNFS-Ganeshaを使用し、NFSを介してエクスポートできます。NFS-Ganeshaを使用するNFSを介したCeph FSのエクスポートの詳細は、次のアップストリームのドキュメントを参照してください。

https://docs.ceph.com/en/latest/cephfs/nfs/

NFSサーバーを設定するには:

NFSサーバー・ホストがCephパブリック・ネットワークに接続され、Ceph Storage Clusterに属していることを確認します。
libcephfs2、nfs-ganeshaおよびnfs-ganesha-cephの各パッケージをインストールします。
```
# yum install libcephfs2 nfs-ganesha nfs-ganesha-ceph
```

たとえば次のように、要件に合わせて/etc/ganesha/ganesha.confファイルを編集します。

EXPORT 
{ 
# Export Id (mandatory, each EXPORT must have a unique Export_Id) 
Export_Id = 1; 

# Use NFSv4
Protocols = 4;

# NFSv4 does not allow UDP transport
Transports = TCP;

# Path into the cephfs tree. For now, FSAL_CEPH doesn't support
# having more than one file system per running ganesha daemon.
#
# Note that FSAL_CEPH does not support subtree checking, so there is
# no way to validate that a filehandle presented by a client is
# reachable via an exported subtree.
#
# For that reason, we just export "/" here.
Path = /; 

# Pseudo Path (required for NFS v4) 
# The pseudoroot path. This is where the export will appear in the
# NFS pseudoroot namespace.
Pseudo = /mnt/cephfs; 

# Required for access (default is None) 
# Could use CLIENT blocks instead 
Access_Type = RW; 
     Squash = no_root_squash; 
SecType = sys; 

# Exporting FSAL 
FSAL { 
  Name = CEPH; 
  } 
}

nfs-ganeshaサービスを再起動します。
```
# systemctl restart nfs-ganesha.service
```
Cephファイル・システムをマウントします。Cephファイル・システムのマウントの詳細は、「Ceph FSのマウント」を参照してください。

NFSを介したCeph FSのマウント

この項では、NFSを使用してOracle LinuxクライアントにCephファイル・システムをマウントする方法について説明します。「NFSを介したCeph FSのエクスポート」のステップに従って、NFSを介したCephファイル・システムを設定してからマウントします。

NFSを介したCeph FSをマウントするには:

インストールされていない場合は、nfs-utilsパッケージをインストールします。
```
# yum install nfs-utils
```
ディレクトリ・マウント・ポイントを作成します(必要な場合)。
```
# mkdir -p /mnt/nfs-ganesha
```

次の構文を使用して、NFS ganeshaファイル・システムをマウントします。

mount -t nfs -o nfsvers=4.1,proto=tcp ganesha-host-name:ganesha-pseudo-path mount-point

たとえば、次を実行します。

# mount -t nfs -o nfsvers=4.1,noauto,soft,sync,proto=tcp ceph-node2:/mnt/cephfs /mnt/nfs-ganesha