このドキュメントで説明されているソフトウェアはサポートされていないか、拡張サポートが提供されています。
現在サポートされているリリースにアップグレードすることをお薦めします。
マルチサイト構成のCeph Object Gatewayをデプロイすると、1つのゾーングループ内の異なるゾーン間で同期を行うことができます。 マルチサイト構成は、以前のリリースのCephで説明されていたフェデレーテッド構成のCeph Object Gatewayに置き換わるものです。
オラクル社では、異なるストレージ・クラスタに分散された複数のゾーンが含まれる単一のゾーングループで構成されるマルチサイト構成をテストしています。 ゲートウェイ間でデータ変更をミラー化する同期エージェント(より単純なアクティブ-アクティブ構成が可能)は構成されていません。 すべてのメタデータ操作(新規ユーザーの作成など)は、マスター・ゾーン経由で作成する必要がありますが、データ操作(バケットやオブジェクトの作成など)は、デプロイメント内のどのゾーンでも処理できます。
次の構成手順では、ゾーン間でアクティブにデータを同期する3つの異なるゾーンが含まれる単一のゾーングループで構成された2つのCeph Storage Clusterからなる基本のマルチサイト構成について説明します。 このサンプル設定は、ローカル・ストレージが使用可能な3つのサーバー上にデプロイされます。 ここでは、システムに既存のCeph構成がないことと、システムがCephパッケージとそれに依存するファイルにアクセスできることを前提としています(1.2項 「Cephパッケージへのアクセスの有効化」を参照)。
このサンプル構成では、次のネーミング規則が使用されています。
レルム:
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にインストールされています。
ceph-deployツールを、第1クラスタに属するシステムのいずれかにインストールします。
#
yum install ceph-deployこのシステムは、この手順の残りの部分で、「第1クラスタ・デプロイメント・ノード」と呼ばれています。
たとえば次のように、ストレージ・クラスタの空の作業用Ceph構成ディレクトリを作成し、このディレクトリに変更します。
#
rm -rf /var/mydom_ceph#mkdir /var/mydom_ceph#cd /var/mydom_cephシステムに既存のCeph構成情報またはデータがある場合は、それを消去します。
#
ceph deploy purge#ceph-node1ceph-node2ceph deploy purgedataceph-node1ceph-node2ceph-node1およびceph-node2を、クラスタに参加しているシステムのホスト名に置き換えます。Cephクラスタ構成をデプロイします。
#
ceph-deploy newceph-node1ceph-node2ceph-node1およびceph-node2を、クラスタに参加しているシステムのホスト名に置き換えます。必要な構成変数を使用して、構成テンプレートを更新します。
#
echo "osd pool default size = 2" >> ceph.conf#echo "rbd default features = 3" >> ceph.conf各ノードにCephクラスタ・パッケージをインストールします。
#
ceph-deploy installceph-node1ceph-node2ceph-node1およびceph-node2を、クラスタに参加しているシステムのホスト名に置き換えます。いずれかのノード上でクラスタ・モニターを作成します。
#
ceph-deploy mon create-initial#ceph-deploy mon create#ceph-node1ceph-deploy gatherkeysceph-node1ceph-node1を、クラスタ・モニターとして指定するノードのホスト名に置き換えます。各ノードの使用可能なディスクをオブジェクト・ストレージ・デバイス(OSD)として機能するように準備します。
#
ceph-deploy osd create --zap-disk --fs-type#xfsceph-node1:sdbceph-deploy osd create --zap-disk --fs-typexfsceph-node2:sdcceph-node1およびceph-node2を、クラスタに参加しているシステムのホスト名に置き換えます。xfsを、優先するファイルシステム・タイプ(xfsまたはbtrfs)に置き換えます。sdbおよびsdcを、各ホスト上で使用可能なディスクの適切なデバイス名に置き換えます。 これらのディスクでは、再パーティション化とフォーマットが行われ、既存のデータは破棄されます。Cephのステータスをチェックして、クラスタが正常であることと、OSDが使用可能であることを確認します。
#
ceph status
第1クラスタ・デプロイメント・ノードから、クラスタ内の各ノードにCeph Object Gatewayソフトウェアをインストールします。
#
ceph-deploy install --rgw#ceph-node1ceph-node2ceph-deploy rgw createceph-node1ceph-node2ceph-node1およびceph-node2を、Ceph Object Gatewayソフトウェアをインストールするクラスタに参加しているシステムのホスト名に置き換えます。第1クラスタ・デプロイメント・ノードで
/var/mydom_ceph/ceph.confのテンプレート構成を編集し、構成ファイルの最後に次の行を追加します。osd pool default pg num = 100 osd pool default pgp num = 100 mon pg warn max per osd = 2100 [client.rgw.
ceph-node1] rgw_frontends = "civetweb port=80" [client.rgw.ceph-node2] rgw_frontends = "civetweb port=80"ceph-node1およびceph-node2を、ゲートウェイ・システムのホスト名に置き換えます。クラスタ内の各ノードに構成をプッシュします。
#
ceph-deploy --overwrite-conf config pushceph-node1ceph-node2各ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
#
systemctl restart ceph-radosgw@*#systemctl status ceph-radosgw@*
Ceph Object Gatewayには、ゲートウェイ関連データを格納するための複数のプールが必要です。 ゲートウェイがゾーンとして構成されている場合は、通常、ネーミング規則zone.pool-name
第1クラスタ・デプロイメント・ノード上で次のコマンドを実行し、このクラスタでホストされている各ゾーンに必要なすべてのプールを作成します。
#ceph osd pool create#ceph-us-east-1.rgw.control 16 16ceph osd pool create#ceph-us-east-1.rgw.data.root 16 16ceph osd pool create#ceph-us-east-1.rgw.gc 16 16ceph osd pool create#ceph-us-east-1.rgw.log 16 16ceph osd pool create#ceph-us-east-1.rgw.intent-log 16 16ceph osd pool create#ceph-us-east-1.rgw.usage 16 16ceph osd pool create#ceph-us-east-1.rgw.users.keys 16 16ceph osd pool create#ceph-us-east-1.rgw.users.email 16 16ceph osd pool create#ceph-us-east-1.rgw.users.swift 16 16ceph osd pool create#ceph-us-east-1.rgw.users.uid 16 16ceph osd pool create#ceph-us-east-1.rgw.buckets.index 32 32ceph osd pool create#ceph-us-east-1.rgw.buckets.data 32 32ceph osd pool create#ceph-us-east-1.rgw.meta 16 16ceph osd pool create#ceph-us-east-2.rgw.control 16 16ceph osd pool create#ceph-us-east-2.rgw.data.root 16 16ceph osd pool create#ceph-us-east-2.rgw.gc 16 16ceph osd pool create#ceph-us-east-2.rgw.log 16 16ceph osd pool create#ceph-us-east-2.rgw.intent-log 16 16ceph osd pool create#ceph-us-east-2.rgw.usage 16 16ceph osd pool create#ceph-us-east-2.rgw.users.keys 16 16ceph osd pool create#ceph-us-east-2.rgw.users.email 16 16ceph osd pool create#ceph-us-east-2.rgw.users.swift 16 16ceph osd pool create#ceph-us-east-2.rgw.users.uid 16 16ceph osd pool create#ceph-us-east-2.rgw.buckets.index 32 32ceph osd pool create#ceph-us-east-2.rgw.buckets.data 32 32ceph osd pool createceph-us-east-2.rgw.meta 16 16
ゾーンの構成時、各ゲートウェイ・インスタンスには、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クラスタと、ここに配置されているセカンダリ・ゾーンを設定する際は、同じ環境変数をエクスポートする必要があります。
マルチサイト構成を、goldという名前の単一レルムを中心に構築し、usと呼ばれる単一のゾーングループを設定します。 このゾーングループにはceph-us-east-1という名前のマスター・ゾーンがあります。 次の手順では、これらのコンポーネントを作成して構成する方法を説明します。
レルムを作成し、これをデフォルトに設定します。
#
radosgw-admin realm create --rgw-realm=gold--defaultCeph 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クラスタ・デプロイメント・ノード上で実行できますが、ゾーングループとレルム構成を更新して、クラスタ内の他のノード上でホストされるセカンダリ・ゾーンを追加するために使用します。
セカンダリ・ゾーンを作成し、マスター・ゾーンで使用されているものと同じアクセス鍵と秘密鍵を必ず指定します。
#
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
第1クラスタ・デプロイメント・ノードで作業ディレクトリのテンプレート構成を編集し、ゾーン名を各ゲートウェイ構成にマップします。 これを行うには、各ノードのゲートウェイ構成エントリに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-deploy --overwrite-conf config push ceph-node1 ceph-node2各ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
#systemctl restart ceph-radosgw@*#systemctl status ceph-radosgw@*
第1クラスタとほぼ同じ方法で、第2クラスタをインストールしてデプロイします。 この例では、第2クラスタは単一ノードで構成されますが、必要に応じてノードを追加することもできます。 このノードは、最終的にceph-us-westゾーンのゲートウェイをホストします。
次のコマンドは、クラスタをデプロイする手順と、ストレージ用に使用可能なOSDを構成する手順をまとめたものです。 これらのコマンドは、第1クラスタの外部の新規サーバーceph-node3
#mkdir -p /var/mydom_ceph; cd /var/mydom_ceph#yum install ceph-deploy#ceph-deploy new#ceph-node3echo "osd pool default size = 2" >> ceph.conf#echo "rbd default features = 3" >> ceph.conf#ceph-deploy install#ceph-node3ceph-deploy mon create-initial#ceph-deploy mon create#ceph-node3ceph-deploy gatherkeys#ceph-node3ceph-deploy osd create --zap-disk --fs-typexfsceph-node3:sdb
クラスタ内に新しくデプロイされたノードに、Ceph Object Gatewayソフトウェアをインストールします。
#
ceph-deploy install --rgw#ceph-node3ceph-deploy rgw createceph-node3ceph-node3を、Ceph Object Gatewayソフトウェアをインストールするノードのホスト名に置き換えます。第2クラスタ・デプロイメント・ノードで
/var/mydom_ceph/ceph.confのテンプレート構成を編集し、構成ファイルの最後に次の行を追加します。osd pool default pg num = 100 osd pool default pgp num = 100 mon pg warn max per osd = 2100 [client.rgw.
ceph-node3] rgw_frontends = "civetweb port=80"ceph-node3を、ゲートウェイ・システムのホスト名に置き換えます。クラスタ内の各ノードに構成をプッシュします。
#
ceph-deploy --overwrite-conf config pushceph-node3ゲートウェイ・ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
#
systemctl restart ceph-radosgw@*#systemctl status ceph-radosgw@*
次のコマンドを実行し、第2クラスタ上でCeph Object Gatewayに必要なプールを作成します。
#ceph osd pool create#ceph-us-west.rgw.control 16 16ceph osd pool create#ceph-us-west.rgw.data.root 16 16ceph osd pool create#ceph-us-west.rgw.gc 16 16ceph osd pool create#ceph-us-west.rgw.log 16 16ceph osd pool create#ceph-us-west.rgw.intent-log 16 16ceph osd pool create#ceph-us-west.rgw.usage 16 16ceph osd pool create#ceph-us-west.rgw.users.keys 16 16ceph osd pool create#ceph-us-west.rgw.users.email 16 16ceph osd pool create#ceph-us-west.rgw.users.swift 16 16ceph osd pool create#ceph-us-west.rgw.users.uid 16 16ceph osd pool create#ceph-us-west.rgw.buckets.index 32 32ceph osd pool create#ceph-us-west.rgw.buckets.data 32 32ceph osd pool createceph-us-west.rgw.meta 16 16
第1クラスタで設定したものと同じ
SYSTEM_ACCESS_KEYおよびSYSTEM_SECRET_KEY環境変数をエクスポートします。 次に例を示します。#
SYSTEM_ACCESS_KEY=#OJywnXPrAA4uSCgv1UUsSYSTEM_SECRET_KEY=dIpf1FRPwUYcXfswYx6qjC0eSuHEeHy0I2f9vHFfこれらの鍵を使用し、次のコマンドを発行して、マスター・ゾーンが実行されているノード経由で、第1クラスタからレルム構成を直接プルします。
#
radosgw-admin realm pull --url=http://ceph-node1.example.com:80\ --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEYマスター・ゾーンが実行されているノード経由で、第1クラスタから期間の状態を直接プルします。
#
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クラスタの元の構成で使用したものと同じアクセス鍵と秘密鍵を必ず使用してください。#
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作業ディレクトリで
/var/mydom_ceph/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-deploy --overwrite-conf config pushceph-node3Ceph 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 --hostceph-node1-cmy-bucket-east-1my-bucket-east-1 2016-09-21T09:16:14.894Z
ここで、他の2つのノードをチェックして、新しいバケットが同期されていることを確認します。
#~/s3zone_test.py --hostceph-node2my-bucket-east-1 2016-09-21T09:16:16.932Z#~/s3zone_test.py --hostceph-node3my-bucket-east-1 2016-09-21T09:16:15.145Z
データの同期に要した時間により、それぞれのタイムスタンプは異なります。 第2クラスタに配置されているゾーンでのバケットの作成もテストできます。
#~/s3zone_test.py --hostceph-node3-cmy-bucket-west-1my-bucket-east-1 2016-09-21T09:16:15.145Z my-bucket-west-1 2016-09-21T09:22:15.456Z
このバケットが他のゾーンに同期されていることを確認します。
#~/s3zone_test.py --hostceph-node1my-bucket-east-1 2016-09-21T09:16:14.894Z my-bucket-west-1 2016-09-21T09:22:15.428Z#~/s3zone_test.py --hostceph-node2my-bucket-east-1 2016-09-21T09:16:16.932Z my-bucket-west-1 2016-09-21T09:22:17.488Z
マルチサイトCeph Object GatewayのデプロイメントでSSLを構成する場合は、各ゾーンでSSL証明書を検証できることが非常に重要です。 つまり、自己署名証明書を使用する場合は、各ゾーンで、信頼できるCAバンドル内にすべての証明書のコピーがすでに保持されている必要があります。 あるいは、信頼できる認証局による署名付きの証明書を使用するようにしてください。
証明書を作成する際は、1.8.5項 「SSLセキュリティ警告: Certificate has no subjectAltName (証明書にsubjectAltNameがありません)」で説明している回避策の手順を使用して、警告メッセージが表示されないようにすることをお薦めします。
この例で示した手順では、各ゲートウェイ・ノードの自己署名証明書を作成する方法、生成された証明書をノード間で共有して検証できるようにする方法、および既存のマルチサイト構成を変更してSSLを有効にする方法を示しています。
デプロイメント内の各ゲートウェイ・ノードの証明書を作成します。
各ゲートウェイ・ノードで、次のコマンドを実行します。
#
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-deploy --overwrite-conf rgw createceph-node1.example.comceph-node2.example.comceph-node1.example.comおよびceph-node2.example.comを、ゲートウェイ・ソフトウェアが動作しているノードの完全ホスト名に置き換えて、それぞれの証明書で使用されているCNと一致するようにします。第2クラスタ・デプロイメント・ノードから次のコマンドを実行します。
#
ceph-deploy --overwrite-conf rgw createceph-node3.example.comceph-node3.example.comを、ゲートウェイ・ソフトウェアが動作しているノードの完全ホスト名に置き換えて、このノード用に生成した証明書で使用されているCNと一致するようにします。この時点で、すべてのゲートウェイ・サービスがデフォルト・ポート7480上で実行を再開しているはずです。
各クラスタのデプロイメント・ノードでテンプレート構成を編集し、ポート番号を変更して、各ゲートウェイのSSL証明書(PEMファイル)の場所を指定します。
ceph-node1の場合の例:#
cd /var/mydom_cephceph.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.comrgw_frontends = "civetweb port=443s ssl_certificate=rgw_zone=ceph-us-east-1 [/etc/pki/tls/ceph-node1.example.com.pem"client.rgw.]ceph-node2.example.comrgw_frontends = "civetweb port=443s ssl_certificate=rgw_zone=ceph-us-east-2/etc/pki/tls/ceph-node2.example.com.pem"変更された構成を各ゲートウェイ・ノードにプッシュします。
#
ceph-deploy --overwrite-conf config pushceph-node1ceph-node2各ノード上でCeph Object Gatewayサービスを再起動し、そのステータスをチェックして正常に動作していることを確認します。
#
systemctl restart ceph-radosgw@*#systemctl status ceph-radosgw@*第2クラスタ・デプロイメント・ノードでこの手順を繰り返し、
ceph-node3.example.comの構成を更新します。この時点で、各ゲートウェイ・エントリはSSLを使用するように構成されているはずです。 ゾーンで引き続き同期が正しく実行されていることと、SSLが使用されていることをテストするには、テスト・スクリプト
~/s3zone_test.pyを使用し、忘れずに-sスイッチを使用してSSLを有効にします。次に例を示します。
#
~/s3zone_test.py -s --hostceph-node2.example.com-cmy-bucket-east-2my-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 --hostceph-node3.example.commy-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上でSSLを使用せずに接続しようとして失敗し、最終的にはソケット・エラーで終了します。socket.error: [Errno 111] Connection refused