Google Cloud を使用した OpenShift Container Storage のデプロイおよび管理
インストールおよび管理方法
概要
前書き
Red Hat OpenShift Container Storage 4.5 では、既存の Red Hat OpenShift Container Platform (OCP) Google Cloud クラスターでのデプロイメントをサポートします。
Google Cloud では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメントの要件についての詳細は、『デプロイメントのプランニング』を参照してください。
内部モードで OpenShift Container Storage をデプロイするには、Google Cloud での OpenShift Container Storage のデプロイのデプロイメントプロセスを実行します。
第1章 Google Cloud での OpenShift Container Storage のデプロイ
Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャー (IPI) によって提供される動的ストレージデバイスを使用して OpenShift Container Storage を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成できます。これにより、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用可能にすることができます。
Google Cloud では、内部の Openshift Container Storage クラスターのみがサポートされます。デプロイメント要件の詳細は、『Planning your deployment』を参照してください。
1.1. Red Hat OpenShift Container Storage Operator のインストール
Red Hat OpenShift Container Storage は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。ハードウェアおよびソフトウェアの要件に関する詳細は、『 デプロイメントのプランニング』を参照してください。
前提条件
- OpenShift Container Platform クラスターにログインしている必要がある。
- OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つ必要です。
OpenShift Container Storage のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、コマンドラインインターフェースで以下のコマンドを使用し、openshift-storage
namespace の空のノードセレクターを指定できます。
$ oc annotate namespace openshift-storage openshift.io/node-selector=
手順
OpenShift Web コンソールの左側のペインで、Operators → OperatorHub をクリックします。
図1.1 Operator Hub の Operator 一覧
OpenShift Container Storage をクリックします。
Filter by keyword テキストボックスまたはフィルター一覧を使用して、Operator の一覧から OpenShift Container Storage を検索できます。
- OpenShift Container Storage Operator ページで、Install をクリックします。
Install Operator ページで、以下のオプションが選択されていることを確認します。
- Channel を stable-4.5として更新します。
- Installation Mode オプションに A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace PR openshift-storage を選択します。namespace
openshift-storage
が存在しない場合、これは Operator のインストール時に作成されます。 承認ストラテジー を Automatic または Manual として選択している。承認ストラテジーはデフォルトで Automatic に設定されます。
Approval Strategy に Automatic を選択します。
注記Approval Strategy を Automatic として選択すると、新規インストール時、または OpenShift Container Storage の最新バージョンへの更新時に承認は必要ありません。
- インストール をクリックします。
- インストールが開始するまで待機します。これには、最長 20 分の時間がかかる可能性があります。
- Operators → Installed Operators をクリックします。
-
Project が
openshift-storage
であることを確認します。デフォルトで、プロジェクト はopenshift-storage
です。 - OpenShift Container Storage の Status が Succeeded に変更するまで待機します。
Approval Strategy に Manual を選択します。
注記Approval Strategy を Manual として選択すると、新規インストール時、または OpenShift Container Storage の最新バージョンへの更新時に承認が必要になります。
- Install をクリックします。
- Installed Operators ページで、ocs-operator をクリックします。
- Subscription Details ページで、Install Plan リンクをクリックします。
- InstallPlan Details ページで、Preview Install Plan をクリックします。
- インストール計画を確認し、Approve をクリックします。
- Components の Status が Unknown から Created または Present のいずれかに変更するまで待機します。
- Operators → Installed Operators をクリックします。
-
Project が
openshift-storage
であることを確認します。デフォルトで、プロジェクト はopenshift-storage
です。 - OpenShift Container Storage の Status が Succeeded に変更するまで待機します。
検証手順
- OpenShift Container Storage Operator の Status が Installed Operators ダッシュボードで Succeeded と表示されることを確認します。
1.2. 内部モードでの OpenShift Container Storage Cluster Service の作成
以下の手順を使用して、OpenShift Container Storage Operator のインストール後に OpenShift Container Storage Cluster Service を作成します。
前提条件
- OpenShift Container Storage は Operator Hub からインストールする必要があります。詳細は、「Installing OpenShift Container Storage Operator using the Operator Hub」を参照してください。
Google Cloud のデフォルトのストレージクラスはハードドライブ (HDD) を使用することに注意してください。パフォーマンスを向上させるためにソリッドステートドライブ (SSD) ベースのディスクを使用するには、以下の
ssd-storeageclass.yaml
の例に示されるようにpd-ssd
を使用してストレージクラスを作成する必要があります。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: faster provisioner: kubernetes.io/gce-pd parameters: type: pd-ssd volumeBindingMode: WaitForFirstConsumer
手順
- OpenShift Web コンソールから Operators → Installed Operators をクリックし、インストールされた Operator を表示します。選択された Project が openshift-storage であることを確認します。
Installed Operators ページで、Openshift Container Storage をクリックします。
図1.2 OpenShift Container Storage Operator ページ
Installed Operators → Operator Details ページで、以下のいずれかを実行して Storage Cluster Service を作成します。
Details タブで Provided APIs → OCS Storage Cluster で、Create Instance をクリックします。
図1.3 Operator Details ページ
または、Storage cluster タブを選択し、Create OCS Cluster Service をクリックします。
図1.4 Storage Cluster タブ
Create Storage Cluster ページで、以下のオプションが選択されていることを確認します。
図1.5 Create Storage Cluster ページ
- デフォルトでは、Select Mode に Internal が選択されています。
Nodes セクションでは、OpenShift Container Storage サービスを使用するには、利用可能な一覧から 3 つ以上のワーカーノードを選択します。
複数のアベイラビリティーゾーンを持つクラウドプラットフォームの場合は、ノードが異なる場所/アベイラビリティーゾーンに分散されていることを確認します。
注記クラスターで特定のワーカーノードを見つけるには、Name または Label に基づいてノードをフィルターできます。
- Name では、ノード名で検索できます。
- Label では、事前に定義されたラベルを選択して検索できます。
ノードの最小要件については、『プランニング』ガイドの「リソース要件」セクションを参照してください。
-
Storage Class は、Google Cloud ではデフォルトで
standard
に設定されます。ただし、パフォーマンスを向上させるために SSD ベースのディスクを使用するようにストレージクラスを作成している場合は、ストレージクラスを選択する必要があります。 ドロップダウンリストから OCS Service Capacity を選択します。
注記初期ストレージ容量を選択すると、クラスターの拡張は、選択された使用可能な容量を使用してのみ実行されます (raw ストレージの 3 倍)。
Create をクリックします。
注記Create ボタンは、最低でも 3 つのワーカーノードを選択した後にのみ有効になります。
デプロイメントに成功すると、3 つのストレージデバイスを持つストレージクラスターが作成されます。これらのデバイスは、選択したノードの 3 つに分散されます。この設定では、3 のレプリケーション係数が使用されます。初期クラスターをスケーリングするには、「 ストレージノードのスケーリング 」を参照してください。
検証手順
- OpenShift Container Storage が正常にインストールされていることを確認するには、「OpenShift Container Storage インストールの確認」を参照してください。
1.3. 新規バッキングストアを作成します。
この手順は必須ではありません。ただし、この手順を実行することは推奨されます。
OpenShift Container Storage を Google Cloud プラットフォームにインストールする場合、noobaa-default-bucket-class
はデータを Google Cloud ストレージではなく noobaa-default-backing-store
に配置します。そのため、Google Cloud ストレージでサポートされる OpenShift Container Storage Multicloud Object Gateway (MCG) 管理オブジェクトストレージを使用するには、以下の手順を実行する必要があります。
作業を開始する前の注意事項
- Google Cloud Web コンソールにログインします。
「Creating storage buckets」ドキュメントに説明されているように、オブジェクトデータを保存するために MCG の Google Cloud ストレージを作成します。Storage Admin ロールを持つサービスアカウントがあることを確認します。
このサービスアカウントが他のデータにアクセスしないように、別の Google Cloud プロジェクトを使用することが推奨されます。
- OpenShift Container Storage 設定に必要な JSON 形式のサービスアカウントキーをダウンロードします。
前提条件
- OpenShift への管理者アクセス。
手順
MCG を Google Cloud ストレージアカウントを使用するように設定するには、以下を実行します。
- OpenShift Container Platform Web コンソールにログインします。
- OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
- OpenShift Container Storage Operator をクリックします。
OpenShift Container Storage Operator ページで右側にスクロールし、Backing Store タブをクリックします。
図1.6 バッキングストアタブのある OpenShift Container Storage Operator ページ
Create Backing Store をクリックします。
図1.7 Create Backing Store ページ
Create New Backing Store ページで、以下を実行します。
- Backing Store Name の名前を入力します。
- Google Cloud Storage を Provider として選択します。
- Secret key にプライベートキー JSON ファイルをアップロードします。
- Target Bucket に Google Cloud ストレージアカウントで作成したストレージバケットの名前を入力します。MCG に対してシステム用にこのバケットを使用できることを通知する接続を作成できます。
- Create Backing Store をクリックします。
- OpenShift Container Platform Web コンソールで、 Installed Operators → OpenShift Container Storage → Bucket Class をクリックします。
-
noobaa-default-bucket-class
YAML 仕様フィールドspec: placementPolicy: tiers: -backingStores:
を、noobaa-default-backing-store
ではなく新規に作成されるバッキングストアを使用するように編集します。
検証手順
(
mcg rpm
パッケージから)MCG コマンドラインツールnoobaa
を使用して以下のコマンドを実行し、作成した Google Cloud ストレージバッキングストアがReady
状態にあることを確認します。$ noobaa status -n openshift-storage
出力にデフォルトのバケットクラスが
Ready
状態で表示され、予想されるバッキングストアを使用することを確認します。. . . ------------------ - Backing Stores - ------------------ NAME TYPE TARGET-BUCKET PHASE AGE gcp-backing-store google-cloud-storage ocs-backing-store Ready 10m27s noobaa-default-backing-store pv-pool Ready 1h58m21s ------------------ - Bucket Classes - ------------------ NAME PLACEMENT PHASE AGE noobaa-default-bucket-class {Tiers:[{Placement: BackingStores:[gcp-backing-store]}]} Ready 1h58m21s
第2章 OpenShift Container Storage デプロイメントの検証
このセクションを使用して、OpenShift Container Storage が正常にデプロイされていることを確認します。
2.1. Pod の状態の確認
OpenShift Container Storage が正常にデプロイされているかどうかを判別するために、Pod の状態が Running
であることを確認できます。
手順
- OpenShift Web コンソールの左側のペインから Workloads → Pods をクリックします。
Project ドロップダウンリストから openshift-storage を選択します。
各コンポーネントについて予想される Pod 数や、これがノード数によってどのように異なるかについての詳細は、表2.1「OpenShift Container Storage クラスターに対応する Pod」 を参照してください。
Running および Completed タブをクリックして、以下の Pod が実行中および完了状態にあることを確認します。
表2.1 OpenShift Container Storage クラスターに対応する Pod
コンポーネント 対応する Pod OpenShift Container Storage Operator
ocs-operator-*
(任意のワーカーノードに 1 Pod)
Rook-ceph Operator
rook-ceph-operator-*
(任意のワーカーノードに 1 Pod)
Multicloud Object Gateway
-
noobaa-operator-*
(任意のワーカーノードに 1 Pod) -
noobaa-core-*
(任意のストレージノードに 1 Pod) -
nooba-db-*
(任意のストレージノードに 1 Pod) -
noobaa-endpoint-*
(任意のストレージノードに 1 Pod) -
noobaa-default-backing-store-noobaa-pod-*
(任意のストレージノードに 1 Pod)
MON
rook-ceph-mon-*
(ストレージノードに分散する 3 Pod)
MGR
rook-ceph-mgr-*
(任意のストレージノードに 1 Pod)
MDS
rook-ceph-mds-ocs-storagecluster-cephfilesystem-*
(ストレージノードに分散する 2 Pod)
CSI
cephfs
-
csi-cephfsplugin-*
(各ワーカーノードに 1 Pod) -
csi-cephfsplugin-provisioner-*
(ストレージノードに分散する 2 Pod)
-
rbd
-
csi-rbdplugin-*
(各ワーカーノードに 1 Pod) -
csi-rbdplugin-provisioner-*
(ストレージノードに分散する 2 Pod)
-
rook-ceph-drain-canary
rook-ceph-drain-canary-*
(各ストレージノードに 1 Pod)
rook-ceph-crashcollector
rook-ceph-crashcollector-*
(各ストレージノードに 1 Pod)
OSD
-
rook-ceph-osd-*
(各デバイス用に 1 Pod) -
rook-ceph-osd-prepare-ocs-deviceset-*
(各デバイス用に 1 Pod)
-
2.2. OpenShift Container Storage クラスターが正常であることの確認
永続ストレージダッシュボードを使用して OpenShift Container Storage クラスターの正常性を確認できます。詳細は、『OpenShift Container Storage のモニタリング』を参照してください。
- OpenShift Web コンソールの左側のペインから Home → Overview をクリックし、Persistent Storage タブをクリックします。
Status カード で、以下の画像のように OCS Cluster に緑色のチェックマークが表示されていることを確認します。
図2.1 Persistent Storage Overview ダッシュボードの Health status カード
Details カード で、以下のようにクラスター情報が適切に表示されていることを確認します。
図2.2 Persistent Storage Overview ダッシュボードの Details カード
2.3. Multicloud Object Gateway が正常であることの確認
オブジェクトサービスダッシュボードを使用して、OpenShift Container Storage クラスターの正常性を確認できます。詳細は、『OpenShift Container Storage のモニタリング』を参照してください。
- OpenShift Web コンソールの左側のペインから Home → Overview をクリックし、Object Service タブをクリックします。
Status カード で、以下のように Multicloud Object Gateway (MCG) ストレージに緑色のチェックマークが表示されていることを確認します。
図2.3 Object Service Overview ダッシュボードの Health status カード
Details カード で、MCG 情報が以下のように適切に表示されることを確認します。
図2.4 Object Service Overview ダッシュボードの Details カード
2.4. OpenShift Container Storage 固有のストレージクラスが存在することの確認
ストレージクラスがクラスターに存在することを確認するには、以下を実行します。
- OpenShift Web コンソールの左側のペインから Storage → Storage Classes をクリックします。
以下のストレージクラスが OpenShift Container Storage クラスターの作成時に作成されることを確認します。
-
ocs-storagecluster-ceph-rbd
-
ocs-storagecluster-cephfs
-
openshift-storage.noobaa.io
-
第3章 OpenShift Container Storage のアンインストール
3.1. 内部モードでの OpenShift Container Storage のアンインストール
このセクションの手順を使用して、ユーザーインターフェースから Uninstall オプションを使用せずに OpenShift Container Storage をアンインストールします。
前提条件
- OpenShift Container Storage クラスターの状態が正常であることを確認します。一部の Pod がリソースまたはノードの不足により正常に終了しないと、削除に失敗する可能性があります。クラスターが状態が正常でない場合は、OpenShift Container Storage をアンインストールする前に Red Hat カスタマーサポートにお問い合わせください。
- アプリケーションが OpenShift Container Storage によって提供されるストレージクラスを使用して Persistent Volume Claim(永続ボリューム要求、PVC)または Object Bucket Claim(オブジェクトバケット要求)を使用していないことを確認します。PVC および OBC はアンインストールプロセスで削除されます。
手順
OpenShift Container Storage ベースのストレージクラスプロビジョナーを使用する PVC および OBC をクエリーします。
以下は例になります。
$ oc get pvc -o=jsonpath='{range .items[?(@.spec.storageClassName=="ocs-storagecluster-ceph-rbd")]}{"Name: "}{@.metadata.name}{" Namespace: "}{@.metadata.namespace}{" Labels: "}{@.metadata.labels}{"\n"}{end}' --all-namespaces|awk '! ( /Namespace: openshift-storage/ && /app:noobaa/ )' | grep -v noobaa-default-backing-store-noobaa-pvc
$ oc get pvc -o=jsonpath='{range .items[?(@.spec.storageClassName=="ocs-storagecluster-cephfs")]}{"Name: "}{@.metadata.name}{" Namespace: "}{@.metadata.namespace}{"\n"}{end}' --all-namespaces
$ oc get obc -o=jsonpath='{range .items[?(@.spec.storageClassName=="openshift-storage.noobaa.io")]}{"Name: "}{@.metadata.name}{" Namespace: "}{@.metadata.namespace}{"\n"}{end}' --all-namespaces
以下の手順に従って、直前の手順に記載されている PVC および OBC が削除されていることを確認します。
モニタリングスタック、クラスターロギング Operator、またはイメージレジストリーの設定の一部として PVC を作成した場合は、必要に応じて以下のセクションで説明されているクリーンアップ手順を実行する必要があります。
- 「OpenShift Container Storage からのモニタリングスタックの削除」
- 「OpenShift Container Storage からの OpenShift Container Platform レジストリーの削除」
「OpenShift Container Storage からのクラスターロギング Operator の削除」
残りの PVC または OBC のそれぞれに、以下の手順を実行します。
- PVC または OBC を使用する Pod を判別します。
Deployment
、StatefulSet
、DaemonSet
、Job
、またはカスタムコントローラーなどの制御する側の API オブジェクトを特定します。各 API オブジェクトには、
OwnerReference
として知られるメタデータフィールドがあります。これは、関連付けられたオブジェクトの一覧です。controller
フィールドが true に設定されたOwnerReference
は、ReplicaSet
、StatefulSet
、DaemonSet
などの制御するオブジェクトを参照します。API オブジェクトが OpenShift Container Storage によって提供される PVC または OBC を使用していないことを確認します。オブジェクトを削除するか、ストレージを置き換える必要があります。プロジェクトオーナーに、オブジェクトを安全に削除または変更できることを確認するよう依頼します。
注記noobaa
Pod は無視できます。OBC を削除します。
$ oc delete obc <obc name> -n <project name>
作成したカスタムバケットクラスを削除します。
$ oc get bucketclass -A | grep -v noobaa-default-bucket-class
$ oc delete bucketclass <bucketclass name> -n <project-name>
カスタム Multi Cloud Gateway バッキングストアを作成している場合は、それらを削除します。
バッキングストアの一覧を表示し、これらをメモします。
for bs in $(oc get backingstore -o name -n openshift-storage | grep -v noobaa-default-backing-store); do echo "Found backingstore $bs"; echo "Its has the following pods running :"; echo "$(oc get pods -o name -n openshift-storage | grep $(echo ${bs} | cut -f2 -d/))"; done
上記の各バッキングストアを削除し、依存するリソースも削除されていることを確認します。
for bs in $(oc get backingstore -o name -n openshift-storage | grep -v noobaa-default-backing-store); do echo "Deleting Backingstore $bs"; oc delete -n openshift-storage $bs; done
上上記のバッキングストアのいずれかが pv-pool をベースとする場合、対応する Pod および PVC も削除してください。
$ oc get pods -n openshift-storage | grep noobaa-pod | grep -v noobaa-default-backing-store-noobaa-pod
$ oc get pvc -n openshift-storage --no-headers | grep -v noobaa-db | grep noobaa-pvc | grep -v noobaa-default-backing-store-noobaa-pvc
手順 1 に記載されている残りの PVC を削除します。
$ oc delete pvc <pvc name> -n <project-name>
StorageCluster
オブジェクトを削除し、関連付けられたリソースが削除されるのを待機します。$ oc delete -n openshift-storage storagecluster --all --wait=true
namespace を削除し、削除が完了するまで待機します。openshift-storage がアクティブなプロジェクトである場合、別のプロジェクトに切り替える必要があります。
openshift-storage がアクティブな namespace の場合に別の namespace に切り替えます。
以下は例になります。
$ oc project default
openshift-storage namespace を削除します。
$ oc delete project openshift-storage --wait=true --timeout=5m
約 5 分間待機し、プロジェクトが正常に削除されたかどうかを確認します。
$ oc get project openshift-storage
出力:
Error from server (NotFound): namespaces "openshift-storage" not found
注記OpenShift Container Storage のアンインストール時に、namespace が完全に削除されず、Terminating 状態のままである場合は、Troubleshooting and deleting remaining resources during Uninstall の記事に記載の手順を実行して namespace の終了をブロックしているオブジェクトを特定します。
各ノードでストレージ Operator アーティファクトをクリーンアップします。
$ for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host rm -rfv /var/lib/rook; done
削除されたディレクトリー
/var/lib/rook
が出力に表示されることを確認します。ディレクトリーが存在しないことを確認します。
$ for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host ls -l /var/lib/rook; done
openshift-storage.noobaa.io
ストレージクラスを削除します。$ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m
ストレージノードのラベルを解除します。
$ oc label nodes --all cluster.ocs.openshift.io/openshift-storage-
$ oc label nodes --all topology.rook.io/rack-
注記label <label> not found のようなラベルが解除されているノードについて表示される警告は無視できます。
すべての PV が削除されていることを確認します。Released 状態のままの PV がある場合は、これを削除します。
# oc get pv | egrep 'ocs-storagecluster-ceph-rbd|ocs-storagecluster-cephfs'
# oc delete pv <pv name>
CustomResourceDefinitions
を削除します。$ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusterinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io --wait=true --timeout=5m
OpenShift Container Platform Web コンソールで、OpenShift Container Storage が完全にアンインストールされていることを確認するには、以下を実行します。
- Home → Overview をクリックし、ダッシュボードにアクセスします。
- Persistent Storage および Object Service タブが Cluster タブの横に表示されないことを確認します。
3.2. OpenShift Container Storage からのモニタリングスタックの削除
このセクションでは、モニタリングスタックを OpenShift Container Storage からクリーンアップします。
モニタリングスタックの設定の一部として作成される PVC は openshift-monitoring
namespace に置かれます。
前提条件
PVC は OpenShift Container Platform モニタリングスタックを使用できるように設定されます。
詳細は、「モニタリングスタックの設定」を参照してください。
手順
openshift-monitoring
namespace で現在実行されている Pod および PVC を一覧表示します。$ oc get pod,pvc -n openshift-monitoring NAME READY STATUS RESTARTS AGE pod/alertmanager-main-0 3/3 Running 0 8d pod/alertmanager-main-1 3/3 Running 0 8d pod/alertmanager-main-2 3/3 Running 0 8d pod/cluster-monitoring- operator-84457656d-pkrxm 1/1 Running 0 8d pod/grafana-79ccf6689f-2ll28 2/2 Running 0 8d pod/kube-state-metrics- 7d86fb966-rvd9w 3/3 Running 0 8d pod/node-exporter-25894 2/2 Running 0 8d pod/node-exporter-4dsd7 2/2 Running 0 8d pod/node-exporter-6p4zc 2/2 Running 0 8d pod/node-exporter-jbjvg 2/2 Running 0 8d pod/node-exporter-jj4t5 2/2 Running 0 6d18h pod/node-exporter-k856s 2/2 Running 0 6d18h pod/node-exporter-rf8gn 2/2 Running 0 8d pod/node-exporter-rmb5m 2/2 Running 0 6d18h pod/node-exporter-zj7kx 2/2 Running 0 8d pod/openshift-state-metrics- 59dbd4f654-4clng 3/3 Running 0 8d pod/prometheus-adapter- 5df5865596-k8dzn 1/1 Running 0 7d23h pod/prometheus-adapter- 5df5865596-n2gj9 1/1 Running 0 7d23h pod/prometheus-k8s-0 6/6 Running 1 8d pod/prometheus-k8s-1 6/6 Running 1 8d pod/prometheus-operator- 55cfb858c9-c4zd9 1/1 Running 0 6d21h pod/telemeter-client- 78fc8fc97d-2rgfp 3/3 Running 0 8d NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0 Bound pvc-0d519c4f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1 Bound pvc-0d5a9825-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2 Bound pvc-0d6413dc-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0 Bound pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1 Bound pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa 40Gi RWO ocs-storagecluster-ceph-rbd 8d
モニタリング
configmap
を編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
以下の例が示すように、OpenShift Container Storage ストレージクラスを参照する
config
セクションを削除し、これを保存します。編集前
. . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .
編集後
. . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .
この例では、
alertmanagerMain
およびprometheusK8s
モニタリングコンポーネントは OpenShift Container Storage PVC を使用しています。関連する PVC を削除します。ストレージクラスを使用するすべての PVC を削除してください。
$ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m
3.3. OpenShift Container Storage からの OpenShift Container Platform レジストリーの削除
このセクションを使用して、OpenShift Container Storage から OpenShift Container Platform レジストリーをクリーンアップします。代替ストレージを設定する必要がある場合は、「イメージレジストリー」を参照してください。
OpenShift Container Platform レジストリーの設定の一部として作成される PVC は openshift-image-registry
namespace に置かれます。
前提条件
- イメージレジストリーは OpenShift Container Storage PVC を使用するように設定されている必要があります。
手順
configs.imageregistry.operator.openshift.io
オブジェクトを編集し、storage セクションのコンテンツを削除します。$ oc edit configs.imageregistry.operator.openshift.io
編集前
. . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .
編集後
. . . storage: . . .
この例では、PVC は
registry-cephfs-rwx-pvc
と呼ばれ、これは安全に削除できます。PVC を削除します。
$ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m
3.4. OpenShift Container Storage からのクラスターロギング Operator の削除
このセクションでは、クラスターロギング Operator を OpenShift Container Storage からクリーンアップします。
クラスターロギング Operator の設定の一部として作成される PVC は openshift-logging
namespace にあります。
前提条件
- クラスターロギングインスタンスは、OpenShift Container Storage PVC を使用するように設定されている必要があります。
手順
namespace の
ClusterLogging
インスタンスを削除します。$ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m
openshift-logging
namespace の PVC は安全に削除できます。PVC を削除します。
$ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m
第4章 OpenShift Container Platform サービスのストレージの設定
OpenShift Container Storage を使用して、イメージレジストリー、モニタリング、およびロギングなどの OpenShift Container Platform サービスのストレージを提供できます。
これらのサービスのストレージを設定するプロセスは、OpenShift Container Storage デプロイメントで使用されるインフラストラクチャーによって異なります。
これらのサービスに十分なストレージ容量があることを常に確認してください。これらの重要なサービスのストレージ領域が不足すると、クラスターは動作しなくなり、復元が非常に困難になります。
Red Hat は、これらのサービスのキュレーションおよび保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントの「Curator スケジュールの設定」および「永続ストレージの設定」の「 Prometheus メトリクスデータの保持時間の変更」サブセクションを参照してください。
これらのサービスのストレージ領域が不足する場合は、Red Hat カスタマーサポートにお問い合わせください。
4.1. OpenShift Container Storage を使用するためのイメージレジストリーの設定
OpenShift Container Platform は、クラスターで標準ワークロードとして実行される、組み込まれたコンテナーイメージレジストリーを提供します。通常、レジストリーはクラスター上にビルドされたイメージの公開ターゲットとして、またクラスター上で実行されるワークロードのイメージのソースとして使用されます。
このセクションの手順に従って、OpenShift Container Storage をコンテナーイメージレジストリーのストレージとして設定します。Google Cloud では、レジストリーのストレージを変更する必要はありません。
このプロセスでは、データを既存イメージレジストリーから新規イメージレジストリーに移行しません。既存のレジストリーにコンテナーイメージがある場合、このプロセスを完了する前にレジストリーのバックアップを作成し、このプロセスの完了時にイメージを再登録します。
前提条件
- OpenShift Web コンソールへの管理者アクセスがある。
-
OpenShift Container Storage Operator が
openshift-storage
namespace にインストールされ、実行されている。OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。 -
イメージレジストリー Operator が
openshift-image-registry
namespace にインストールされ、実行されている。OpenShift Web コンソールで、Administration → Cluster Settings → Cluster Operators をクリックしてクラスター Operator を表示します。 -
プロビジョナー
openshift-storage.cephfs.csi.ceph.com
を持つストレージクラスが利用可能である。OpenShift Web コンソールで、Storage → Storage Classes をクリックし、利用可能なストレージクラスを表示します。
手順
使用するイメージレジストリーの Persistent Volume Claim(永続ボリューム要求、PVC)を作成します。
- OpenShift Web コンソールで、Storage → Persistent Volume Claims をクリックします。
-
Project を
openshift-image-registry
に設定します。 Create Persistent Volume Claim をクリックします。
-
上記で取得した利用可能なストレージクラス一覧から、プロビジョナー
openshift-storage.cephfs.csi.ceph.com
で Storage Class を指定します。 -
Persistent Volume Claim(永続ボリューム要求、PVC)の Name を指定します(例:
ocs4registry
)。 -
Shared Access (RWX)
の Access Mode を指定します。 - 100 GB 以上の Size を指定します。
Create をクリックします。
新規 Persistent Volume Claim(永続ボリューム要求、PVC)のステータスが
Bound
として一覧表示されるまで待機します。
-
上記で取得した利用可能なストレージクラス一覧から、プロビジョナー
クラスターのイメージレジストリーを、新規の Persistent Volume Claim(永続ボリューム要求、PVC)を使用するように設定します。
- Administration →Custom Resource Definitions をクリックします。
-
imageregistry.operator.openshift.io
グループに関連付けられたConfig
カスタムリソース定義をクリックします。 - Instances タブをクリックします。
- クラスターインスタンスの横にある Action メニュー (⋮) → Edit Config をクリックします。
イメージレジストリーの新規 Persistent Volume Claim(永続ボリューム要求、PVC)を追加します。
以下を
spec:
の下に追加し、必要に応じて既存のstorage:
セクションを置き換えます。storage: pvc: claim: <new-pvc-name>
以下に例を示します。
storage: pvc: claim: ocs4registry
- 保存 をクリックします。
新しい設定が使用されていることを確認します。
- Workloads → Pods をクリックします。
-
Project を
openshift-image-registry
に設定します。 -
新規
image-registry-*
Pod がRunning
のステータスと共に表示され、以前のimage-registry-*
Pod が終了していることを確認します。 -
新規の
image-registry-*
Pod をクリックし、Pod の詳細を表示します。 -
Volumes までスクロールダウンし、
registry-storage
ボリュームに新規 Persistent Volume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例:ocs4registry
)。
4.2. OpenShift Container Storage を使用するためのモニタリングの設定
OpenShift Container Storage は、Prometheus および AlertManager で構成されるモニタリングスタックを提供します。
このセクションの手順に従って、OpenShift Container Storage をモニタリングスタックのストレージとして設定します。
ストレージ領域が不足すると、モニタリングは機能しません。モニタリング用に十分なストレージ容量があることを常に確認してください。
Red Hat は、このサービスの保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントの「永続ストレージの設定」の Prometheus メトリクスデータの保持期間の設定 についてのサブセクションを参照してください。
前提条件
- OpenShift Web コンソールへの管理者アクセスがある。
-
OpenShift Container Storage Operator が
openshift-storage
namespace にインストールされ、実行されている。OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。 -
モニタリング Operator が
openshift-monitoring
namespace にインストールされ、実行されている。OpenShift Web コンソールで、Administration → Cluster Settings → Cluster Operators をクリックしてクラスター Operator を表示します。 -
プロビジョナー
openshift-storage.rbd.csi.ceph.com
を持つストレージクラスが利用可能である。OpenShift Web コンソールで、Storage → Storage Classes をクリックし、利用可能なストレージクラスを表示します。
手順
- OpenShift Web コンソールで Workloads → Config Maps に移動します。
-
Project ドロップダウンを
openshift-monitoring
に設定します。 - Create Config Map をクリックします。
以下の例を使用して新規の
cluster-monitoring-config
Config Map を定義します。山括弧 (
<
,>
) 内の内容を独自の値に置き換えます (例:retention: 24h
またはstorage: 40Gi
)。storageClassName、をプロビジョナー
openshift-storage.rbd.csi.ceph.com
を使用するstorageclass
に置き換えます。以下の例では、storageclass の名前はocs-storagecluster-ceph-rbd
です。cluster-monitoring-config
Config Map の例apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: retention: <time to retain monitoring files, e.g. 24h> volumeClaimTemplate: metadata: name: ocs-prometheus-claim spec: storageClassName: ocs-storagecluster-ceph-rbd resources: requests: storage: <size of claim, e.g. 40Gi> alertmanagerMain: volumeClaimTemplate: metadata: name: ocs-alertmanager-claim spec: storageClassName: ocs-storagecluster-ceph-rbd resources: requests: storage: <size of claim, e.g. 40Gi>
- Create をクリックして、設定マップを保存し、作成します。
検証手順
Persistent Volume Claim (永続ボリューム要求、PVC) が Pod にバインドされていることを確認します。
- Storage → Persistent Volume Claims に移動します。
-
Project ドロップダウンを
openshift-monitoring
に設定します。 5 つの Persistent Volume Claim(永続ボリューム要求、PVC)が
Bound
(バインド)の状態で表示され、3 つのalertmanager-main-*
Pod および 2 つのprometheus-k8s-*
Pod に割り当てられていることを確認します。作成済みのバインドされているストレージのモニタリング
新規の
alertmanager-main-*
Pod がRunning
状態で表示されることを確認します。-
新規の
alertmanager-main-*
Pod をクリックし、Pod の詳細を表示します。 Volumes にスクロールダウンし、ボリュームに新規 Persistent Volume Claim(永続ボリューム要求、PVC)のいずれかに一致する Type
ocs-alertmanager-claim
があることを確認します (例:ocs-alertmanager-claim-alertmanager-main-0
)。alertmanager-main-*
Pod に割り当てられた Persistent Volume Claim (永続ボリューム要求、PVC)
-
新規の
新規
prometheus-k8s-*
Pod がRunning
状態で表示されることを確認します。-
新規
prometheus-k8s-*
Pod をクリックし、Pod の詳細を表示します。 Volumes までスクロールダウンし、ボリュームに新規の Persistent Volume Claim (永続ボリューム要求、PVC) のいずれかに一致する Type
ocs-prometheus-claim
があることを確認します (例:ocs-prometheus-claim-prometheus-k8s-0
)。prometheus-k8s-*
Pod に割り当てられた Persistent Volume Claim(永続ボリューム要求、PVC)
-
新規
4.3. OpenShift Container Storage のクラスターロギング
クラスターロギングをデプロイして、各種の OpenShift Container Platform サービスについてのログを集計できます。クラスターロギングのデプロイ方法については、「クラスターロギングのデプロイ」を参照してください。
OpenShift Container Platform の初回のデプロイメントでは、OpenShift Container Storage はデフォルトで設定されず、OpenShift Container Platform クラスターはノードから利用可能なデフォルトストレージのみに依存します。OpenShift ロギング (ElasticSearch) のデフォルト設定を OpenShift Container Storage で対応されるように編集し、OpenShift Container Storage でサポートされるロギング(Elasticsearch) を設定できます。
これらのサービスに十分なストレージ容量があることを常に確認してください。これらの重要なサービスのストレージ領域が不足すると、ロギングアプリケーションは動作しなくなり、復元が非常に困難になります。
Red Hat は、これらのサービスのキュレーションおよび保持期間を短く設定することを推奨します。詳細は、OpenShift Container Platform ドキュメントでクラスターロギング Curator について参照してください。
これらのサービスのストレージ領域が不足している場合は、Red Hat カスタマーポータルにお問い合わせください。
4.3.1. 永続ストレージの設定
ストレージクラス名およびサイズパラメーターを使用して、 Elasticsearch クラスターの永続ストレージクラスおよびサイズを設定できます。Cluster Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについて Persistent Volume Claim (永続ボリューム要求、PVC)を作成します。以下に例を示します。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "ocs-storagecluster-ceph-rbd” size: "200G"
この例では、クラスター内の各データノードが 200GiB
の ocs-storagecluster-ceph-rbd
ストレージを要求する Persistent Volume Claim(永続ボリューム要求、PVC)にバインドされるように指定します。それぞれのプライマリーシャードは単一のレプリカによってサポートされます。シャードのコピーはすべてのノードにレプリケートされ、常に利用可能となり、冗長性ポリシーにより 2 つ以上のノードが存在する場合にコピーを復元できます。Elasticsearch レプリケーションポリシーについての詳細は、「クラスターロギングのデプロイおよび設定について」に記載の Elasticsearch レプリケーションポリシー について参照してください。
ストレージブロックを省略すると、デプロイメントはデフォルトのストレージでサポートされます。以下に例を示します。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
詳細は、「クラスターロギングの設定」を参照してください。
4.3.2. OpenShift Container Storage を使用するためのクラスターロギングの設定
このセクションの手順に従って、OpenShift Container Storage を OpenShift クラスターロギングのストレージとして設定します。
OpenShift Container Storage でロギングを初めて設定する際にすべてのログを取得できます。ただし、ロギングをアンインストールして再インストールすると、古いログが削除され、新しいログのみが処理されます。
前提条件
- OpenShift Web コンソールへの管理者アクセスがある。
-
OpenShift Container Storage Operator が
openshift-storage
namespace にインストールされ、実行されている。 -
Cluster Logging Operator が
openshift-logging
namespace にインストールされ、実行されている。
手順
- OpenShift Web コンソールの左側のペインから Administration → Custom Resource Definitions をクリックします。
- Custom Resource Definitions ページで、ClusterLogging をクリックします。
- Custom Resource Definition Overview ページで、Actions メニューから View Instances を選択するか、または Instances タブをクリックします。
Cluster Logging ページで、Create Cluster Logging をクリックします。
データを読み込むためにページを更新する必要がある場合があります。
YAML において、storageClassName、をプロビジョナー
openshift-storage.rbd.csi.ceph.com
を使用するstorageclass
に置き換えます。以下の例では、storageclass の名前はocs-storagecluster-ceph-rbd
です。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: ocs-storagecluster-ceph-rbd size: 200G redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: replicas: 1 curation: type: "curator" curator: schedule: "30 3 * * *" collection: logs: type: "fluentd" fluentd: {}
- 保存 をクリックします。
検証手順
Persistent Volume Claim(永続ボリューム要求、PVC)が
elasticsearch
Pod にバインドされていることを確認します。- Storage → Persistent Volume Claims に移動します。
-
Project ドロップダウンを
openshift-logging
に設定します。 Persistent Volume Claim(永続ボリューム要求、PVC)が
elasticsearch-
* Pod に割り当てられ、Bound
(バインド) の状態で表示されることを確認します。図4.1 作成済みのバインドされたクラスターロギング
新規クラスターロギングが使用されていることを確認します。
- Workload → Pods をクリックします。
-
プロジェクトを
openshift-logging
に設定します。 -
新規の
elasticsearch-
* Pod がRunning
状態で表示されることを確認します。 -
新規の
elasticsearch-
* Pod をクリックし、Pod の詳細を表示します。 -
Volumes までスクロールダウンし、elasticsearch ボリュームに新規 Persistent Volume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例:
elasticsearch-elasticsearch-cdm-9r624biv-3
)。 - Persistent Volume Claim(永続ボリューム要求、PVC)の名前をクリックし、PersistenVolumeClaim Overview ページでストレージクラス名を確認します。
Elasticsearch Pod に割り当てられる PV の詳細シナリオを回避するために、キュレーターの時間を短くして使用するようにしてください。
Curator を、保持設定に基づいて Elasticsearch データを削除するように設定できます。以下の 5 日間のインデックスデータの保持期間をデフォルトとして設定することが推奨されます。
config.yaml: | openshift-storage: delete: days: 5
詳細は、「Elasticsearch データのキュレーション」を参照してください。
Persistent Volume Claim(永続ボリューム要求、PVC)がサポートするクラスターロギングをアンインストールするには、それぞれのデプロイメントガイドのアンインストールについての章に記載されている、クラスターロギング Operator の OpenShift Container Storage からの削除についての手順を使用します。
第5章 OpenShift Container Storage を使用した OpenShift Container Platform アプリケーションのサポート
OpenShift Container Platform のインストール時に OpenShift Container Storage を直接インストールすることはできません。ただし、Operator Hub を使用して OpenShift Container Platform を既存の OpenShift Container Platform にインストールし、OpenShift Container Platform アプリケーションを OpenShift Container Storage でサポートされるように設定することができます。
前提条件
- OpenShift Container Platform がインストールされ、OpenShift Web コンソールへの管理者アクセスがある。
-
OpenShift Container Storage が
openshift-storage
namespace にインストールされ、実行されている。
手順
OpenShift Web コンソールで、以下のいずれかを実行します。
Workloads → Deployments をクリックします。
Deployments ページで、以下のいずれかを実行できます。
- 既存のデプロイメントを選択し、Action メニュー (⋮) から Add Storage オプションをクリックします。
新規デプロイメントを作成してからストレージを追加します。
- Create Deployment をクリックして新規デプロイメントを作成します。
-
要件に応じて
YAML
を編集し、デプロイメントを作成します。 - Create をクリックします。
- ページ右上の Actions ドロップダウンメニューから Add Storage を選択します。
Workloads → Deployment Configs をクリックします。
Deployment Configs ページで、以下のいずれかを実行できます。
- 既存のデプロイメントを選択し、Action メニュー (⋮) から Add Storage オプションをクリックします。
新規デプロイメントを作成してからストレージを追加します。
- Create Deployment Config をクリックし、新規デプロイメントを作成します。
-
要件に応じて
YAML
を編集し、デプロイメントを作成します。 - Create をクリックします。
- ページ右上の Actions ドロップダウンメニューから Add Storage を選択します。
Add Storage ページで、以下のオプションのいずれかを選択できます。
- Use existing claim オプションをクリックし、ドロップダウンリストから適切な PVC を選択します。
Create new claim オプションをクリックします。
-
Storage Class ドロップダウンリストから適切な
CephFS
またはRBD
ストレージクラスを選択します。 - Persistent Volume Claim (永続ボリューム要求、PVC) の名前を指定します。
ReadWriteOnce (RWO) または ReadWriteMany (RWX) アクセスモードを選択します。
注記ReadOnlyMany (ROX) はサポートされないため、非アクティブになります。
必要なストレージ容量のサイズを選択します。
注記Persistent Volume Claim (永続ボリューム要求、PVC) の作成後にストレージ容量のサイズを変更することはできません。
-
Storage Class ドロップダウンリストから適切な
- コンテナー内のマウントパスボリュームのマウントパスおよびサブパス(必要な場合)を指定します。
- Save をクリックします。
検証手順
設定に応じて、以下のいずれかを実行します。
- Workloads → Deployments をクリックします。
- Workloads → Deployment Configs をクリックします。
- 必要に応じてプロジェクトを設定します。
- ストレージを追加したデプロイメントをクリックして、デプロイメントの詳細を表示します。
- Volumes までスクロールダウンし、デプロイメントに、割り当てた Persistent Volume Claim(永続ボリューム要求、PVC)に一致する Type があることを確認します。
- Persistent Volume Claim(永続ボリューム要求、PVC)の名前をクリックし、PersistenVolumeClaim Overview ページでストレージクラス名を確認します。
第6章 ストレージノードのスケーリング
OpenShift Container Storage のストレージ容量をスケーリングするには、以下のいずれかを実行できます。
- ストレージノードのスケールアップ: 既存の OpenShift Container Storage ワーカーノードに対してストレージ容量を追加します。
- ストレージノードのスケールアウト: ストレージ容量を含む新規ワーカーノードを追加します。
6.1. ストレージノードのスケーリングの要件
ストレージノードをスケーリングする前に、以下のセクションを参照して、特定の Red Hat OpenShift Container Storage インスタンスのノード要件を把握してください。
- プラットフォーム要件
ストレージデバイスの要件
常にストレージ容量が十分にあることを確認してください。
ストレージが完全に一杯になると、容量を追加したり、ストレージからコンテンツを削除したり、コンテンツを移動して領域を解放することはできません。完全なストレージを復元することは非常に困難です。
容量アラートは、クラスターストレージ容量が合計容量の 75% (ほぼ一杯) および 85% (一杯) になると発行されます。容量についての警告に常に迅速に対応し、ストレージを定期的に確認して、ストレージ領域が不足しないようにします。
ストレージ領域が不足する場合は、Red Hat カスタマーポータルにお問い合わせください。
6.2. Google Cloud インフラストラクチャーの OpenShift Container Storage ノードへの容量の追加によるストレージのスケールアップ
以下の手順を使用して、設定された Red Hat OpenShift Container Storage ワーカーノードにストレージ容量を追加し、パフォーマンスを強化します。
前提条件
- 実行中の OpenShift Container Storage Platform
- OpenShift Web コンソールの管理者権限
手順
- OpenShift Web コンソールに移動します。
- 左側のナビゲーションバーの Operators をクリックします。
- Installed Operators を選択します。
ウィンドウで、OpenShift Container Storage Operator をクリックします。
上部のナビゲーションバーで、右にスクロールし、Storage Cluster タブをクリックします。
- 表示されるリストには 1 つの項目のみが含まれます。右端の (⋮) をクリックして、オプションメニューを拡張します。
オプションメニューから Add Capacity を選択します。
ダイアログボックスから、要求される追加容量およびストレージクラスを設定できます。Add capacity には、インストール時に選択された容量が表示され、容量はこの増分値でのみ追加できます。HDD を使用するデフォルトのストレージクラスを使用している場合は、ストレージクラスを
standard
に設定します。ただし、パフォーマンスを向上させるために SSD ベースのディスクを使用するようにストレージクラスを作成している場合は、ストレージクラスを選択する必要があります。注記効果的にプロビジョニングされる容量については、OpenShift Container Storage はレプリカ数の 3 を使用するため、Raw Capacity フィールドに入力する値の 3 倍の値にします。
- 設定が終了したら、Add をクリックします。ストレージクラスターが Ready 状態になるまでに数分待機する必要がある場合があります。
検証手順
Overview → Persistent Storage タブに移動してから、Capacity breakdown カードをチェックします。
- 容量は選択に応じて増大することに注意してください。
OpenShift Container Storage 4.2 の時点では、OSD またはノードの縮小によるクラスターの削減はサポートされていません。
6.3. 新規ノードの追加によるストレージ容量のスケールアウト
ストレージ容量をスケールアウトするには、以下を実行する必要があります。
- 既存のワーカーノードがサポートされる最大 OSD (初期設定で選択される容量の 3 OSD の増分) で実行されている場合には、ストレージの容量を増やすために新規ノードを追加します。
- 新規ノードが正常に追加されたことを確認します。
- ノードが追加された後にストレージ容量をスケールアップします。
6.3.1. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーへのノードの追加
前提条件
- OpenShift Container Platform (OCP) クラスターにログインしている必要があります。
手順
- Compute → Machine Sets に移動します。
- ノードを追加する必要のあるマシンセットで、Edit Machine Count を選択します。
- ノード数を追加し、Save をクリックします。
- Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。
OpenShift Container Storage ラベルを新規ノードに適用します。
- 新規ノードについて、Action menu (⋮) → Edit Labels をクリックします。
- cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。
異なるゾーンのそれぞれに 3 つのノードを追加することが推奨されます。3 つのノードを追加して、それらすべてのノードに対してこの手順を実行する必要があります。
検証手順
新規ノードが追加されたことを確認するには、「新規ノードの追加の確認」 を参照してください。
6.3.2. 新規ノードの追加の確認
以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
6.3.3. ストレージ容量のスケールアップ
新規ノードを OpenShift Container Storage に追加した後に、「容量の追加によるストレージのスケールアップ」に説明されているようにストレージ容量をスケールアップする必要があります。
第7章 Multicloud Object Gateway
7.1. Multicloud Object Gateway について
Multicloud Object Gateway (MCG) は OpenShift の軽量オブジェクトストレージサービスであり、ユーザーは必要に応じて、複数のクラスター、およびクラウドネイティブストレージを使用して、オンプレミスで小規模に開始し、その後にスケーリングできます。
7.2. アプリケーションの使用による Multicloud Object Gateway へのアクセス
AWS S3 を対象とするアプリケーションまたは AWS S3 Software Development Kit(SDK) を使用するコードを使用して、オブジェクトサービスにアクセスできます。アプリケーションは、MCG エンドポイント、アクセスキー、およびシークレットアクセスキーを指定する必要があります。ターミナルまたは MCG CLI を使用して、この情報を取得できます。
前提条件
- 実行中の OpenShift Container Storage Platform
MCG コマンドラインインターフェースをダウンロードして、管理を容易にします。
# subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms # yum install mcg
-
または、
mcg
パッケージを、Download RedHat OpenShift Container Storage ページにある OpenShift Container Storage RPM からインストールできます。
関連するエンドポイント、アクセスキー、およびシークレットアクセスキーには、以下の 2 つの方法でアクセスできます。
7.2.1. ターミナルから Multicloud Object Gateway へのアクセス
手順
describe
コマンドを実行し、アクセスキー (AWS_ACCESS_KEY_ID
値) およびシークレットアクセスキー (AWS_SECRET_ACCESS_KEY
値) を含む MCG エンドポイントについての情報を表示します。
# oc describe noobaa -n openshift-storage
出力は以下のようになります。
Name: noobaa Namespace: openshift-storage Labels: <none> Annotations: <none> API Version: noobaa.io/v1alpha1 Kind: NooBaa Metadata: Creation Timestamp: 2019-07-29T16:22:06Z Generation: 1 Resource Version: 6718822 Self Link: /apis/noobaa.io/v1alpha1/namespaces/openshift-storage/noobaas/noobaa UID: 019cfb4a-b21d-11e9-9a02-06c8de012f9e Spec: Status: Accounts: Admin: Secret Ref: Name: noobaa-admin Namespace: openshift-storage Actual Image: noobaa/noobaa-core:4.0 Observed Generation: 1 Phase: Ready Readme: Welcome to NooBaa! ----------------- Welcome to NooBaa! ----------------- NooBaa Core Version: NooBaa Operator Version: Lets get started: 1. Connect to Management console: Read your mgmt console login information (email & password) from secret: "noobaa-admin". kubectl get secret noobaa-admin -n openshift-storage -o json | jq '.data|map_values(@base64d)' Open the management console service - take External IP/DNS or Node Port or use port forwarding: kubectl port-forward -n openshift-storage service/noobaa-mgmt 11443:443 & open https://localhost:11443 2. Test S3 client: kubectl port-forward -n openshift-storage service/s3 10443:443 & 1 NOOBAA_ACCESS_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d') 2 NOOBAA_SECRET_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d') alias s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY aws --endpoint https://localhost:10443 --no-verify-ssl s3' s3 ls Services: Service Mgmt: External DNS: https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443 Internal DNS: https://noobaa-mgmt.openshift-storage.svc:443 Internal IP: https://172.30.235.12:443 Node Ports: https://10.0.142.103:31385 Pod Ports: https://10.131.0.19:8443 serviceS3: External DNS: 3 https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443 Internal DNS: https://s3.openshift-storage.svc:443 Internal IP: https://172.30.86.41:443 Node Ports: https://10.0.142.103:31011 Pod Ports: https://10.131.0.19:6443
oc describe noobaa
コマンドには、利用可能な内部および外部 DNS 名が一覧表示されます。内部 DNS を使用する場合、トラフィックは無料になります。外部 DNS はロードバランシングを使用してトラフィックを処理するため、1 時間あたりのコストがかかります。
7.2.2. MCG コマンドラインインターフェースからの Multicloud Object Gateway へのアクセス
前提条件
MCG コマンドラインインターフェースをダウンロードします。
# subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms # yum install mcg
手順
status
コマンドを実行して、エンドポイント、アクセスキー、およびシークレットアクセスキーにアクセスします。
noobaa status -n openshift-storage
出力は以下のようになります。
INFO[0000] Namespace: openshift-storage INFO[0000] INFO[0000] CRD Status: INFO[0003] ✅ Exists: CustomResourceDefinition "noobaas.noobaa.io" INFO[0003] ✅ Exists: CustomResourceDefinition "backingstores.noobaa.io" INFO[0003] ✅ Exists: CustomResourceDefinition "bucketclasses.noobaa.io" INFO[0004] ✅ Exists: CustomResourceDefinition "objectbucketclaims.objectbucket.io" INFO[0004] ✅ Exists: CustomResourceDefinition "objectbuckets.objectbucket.io" INFO[0004] INFO[0004] Operator Status: INFO[0004] ✅ Exists: Namespace "openshift-storage" INFO[0004] ✅ Exists: ServiceAccount "noobaa" INFO[0005] ✅ Exists: Role "ocs-operator.v0.0.271-6g45f" INFO[0005] ✅ Exists: RoleBinding "ocs-operator.v0.0.271-6g45f-noobaa-f9vpj" INFO[0006] ✅ Exists: ClusterRole "ocs-operator.v0.0.271-fjhgh" INFO[0006] ✅ Exists: ClusterRoleBinding "ocs-operator.v0.0.271-fjhgh-noobaa-pdxn5" INFO[0006] ✅ Exists: Deployment "noobaa-operator" INFO[0006] INFO[0006] System Status: INFO[0007] ✅ Exists: NooBaa "noobaa" INFO[0007] ✅ Exists: StatefulSet "noobaa-core" INFO[0007] ✅ Exists: Service "noobaa-mgmt" INFO[0008] ✅ Exists: Service "s3" INFO[0008] ✅ Exists: Secret "noobaa-server" INFO[0008] ✅ Exists: Secret "noobaa-operator" INFO[0008] ✅ Exists: Secret "noobaa-admin" INFO[0009] ✅ Exists: StorageClass "openshift-storage.noobaa.io" INFO[0009] ✅ Exists: BucketClass "noobaa-default-bucket-class" INFO[0009] ✅ (Optional) Exists: BackingStore "noobaa-default-backing-store" INFO[0010] ✅ (Optional) Exists: CredentialsRequest "noobaa-cloud-creds" INFO[0010] ✅ (Optional) Exists: PrometheusRule "noobaa-prometheus-rules" INFO[0010] ✅ (Optional) Exists: ServiceMonitor "noobaa-service-monitor" INFO[0011] ✅ (Optional) Exists: Route "noobaa-mgmt" INFO[0011] ✅ (Optional) Exists: Route "s3" INFO[0011] ✅ Exists: PersistentVolumeClaim "db-noobaa-core-0" INFO[0011] ✅ System Phase is "Ready" INFO[0011] ✅ Exists: "noobaa-admin" #------------------# #- Mgmt Addresses -# #------------------# ExternalDNS : [https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443] ExternalIP : [] NodePorts : [https://10.0.142.103:31385] InternalDNS : [https://noobaa-mgmt.openshift-storage.svc:443] InternalIP : [https://172.30.235.12:443] PodPorts : [https://10.131.0.19:8443] #--------------------# #- Mgmt Credentials -# #--------------------# email : admin@noobaa.io password : HKLbH1rSuVU0I/souIkSiA== #----------------# #- S3 Addresses -# #----------------# 1 ExternalDNS : [https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443] ExternalIP : [] NodePorts : [https://10.0.142.103:31011] InternalDNS : [https://s3.openshift-storage.svc:443] InternalIP : [https://172.30.86.41:443] PodPorts : [https://10.131.0.19:6443] #------------------# #- S3 Credentials -# #------------------# 2 AWS_ACCESS_KEY_ID : jVmAsu9FsvRHYmfjTiHV 3 AWS_SECRET_ACCESS_KEY : E//420VNedJfATvVSmDz6FMtsSAzuBv6z180PT5c #------------------# #- Backing Stores -# #------------------# NAME TYPE TARGET-BUCKET PHASE AGE noobaa-default-backing-store aws-s3 noobaa-backing-store-15dc896d-7fe0-4bed-9349-5942211b93c9 Ready 141h35m32s #------------------# #- Bucket Classes -# #------------------# NAME PLACEMENT PHASE AGE noobaa-default-bucket-class {Tiers:[{Placement: BackingStores:[noobaa-default-backing-store]}]} Ready 141h35m33s #-----------------# #- Bucket Claims -# #-----------------# No OBC's found.
これで、アプリケーションに接続するための関連するエンドポイント、アクセスキー、およびシークレットアクセスキーを使用できます。
例7.1 例
AWS S3 CLI がアプリケーションである場合、以下のコマンドは OCS のバケットを一覧表示します。
AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID> AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY> aws --endpoint <ENDPOINT> --no-verify-ssl s3 ls
7.3. ハイブリッドまたはマルチクラウド用のストレージリソースの追加
7.3.1. MCG コマンドラインインターフェースを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加
Multicloud Object Gateway (MCG) は、クラウドプロバイダーおよびクラスター全体にまたがるデータの処理を単純化します。
これを実行するには、MCG で使用できるバッキングストレージを追加します。
前提条件
MCG コマンドラインインターフェースをダウンロードします。
# subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms # yum install mcg
-
または、
mcg
パッケージを、Download RedHat OpenShift Container Storage ページにある OpenShift Container Storage RPM からインストールできます。
手順
MCG コマンドラインインターフェースから、以下のコマンドを実行します。
noobaa backingstore create <backing-store-type> <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
-
<backing-store-type>
を、関連するバッキングストアタイプのaws-s3
、google-cloud-store
、azure-blob
、s3-compatible
、またはibm-cos
に置き換えます。 -
<backingstore_name>
を、バッキングストアの名前に置き換えます。 -
<AWS ACCESS KEY>
および<AWS SECRET ACCESS KEY>
を、作成した AWS アクセスキー ID およびシークレットアクセスキーに置き換えます。 <bucket-name>
を既存の AWS バケット名に置き換えます。この引数は、NooBaa に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。出力は次のようになります。
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "aws-resource" INFO[0002] ✅ Created: Secret "backing-store-secret-aws-resource"
-
YAML を使用してストレージリソースを追加することもできます。
認証情報でシークレットを作成します。
apiVersion: v1 kind: Secret metadata: name: <backingstore-secret-name> type: Opaque data: AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64> AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
-
Base64 を使用して独自の AWS アクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を
<AWS ACCESS KEY ID ENCODED IN BASE64>
および<AWS SECRET ACCESS KEY ENCODED IN BASE64>
に使用する必要があります。 -
<backingstore-secret-name>
を一意の名前に置き換えます。
-
Base64 を使用して独自の AWS アクセスキー ID およびシークレットアクセスキーを指定し、エンコードし、その結果を
特定のバッキングストアについて以下の YAML を適用します。
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: bs namespace: noobaa spec: awsS3: secret: name: <backingstore-secret-name> namespace: noobaa targetBucket: <bucket-name> type: <backing-store-type>
-
<bucket-name>
を既存の AWS バケット名に置き換えます。この引数は、NooBaa に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。 -
<backingstore-secret-name>
を直前の手順で作成したシークレットの名前に置き換えます。 -
<backing-store-type> を、関連するバッキングストアタイプの
aws-s3
、google-cloud-store
、azure-blob
、s3-compatible
、またはibm-cos
に置き換えます。
-
7.3.2. s3 と互換性のある Multicloud Object Gateway バッキングストアの作成
Multicloud Object Gateway は、任意の S3 と互換性のあるオブジェクトストレージをバッキングストアとして使用できます (例: Red Hat Ceph Storage の RADOS Gateway (RGW))。以下の手順では、Red Hat Ceph Storage の RADOS Gateway 用の S3 と互換性のある Multicloud Object Gateway バッキングストアを作成する方法を説明します。RGW がデプロイされると、OpenShift Container Storage Operator は Multicloud Object Gateway の S3 と互換性のあるバッキングストアを自動的に作成することに注意してください。
手順
Multicloud Object Gateway (MCG) コマンドラインインターフェースから、以下の NooBaa コマンドを実行します。
noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=http://rook-ceph-rgw-ocs-storagecluster-cephobjectstore.openshift-storage.svc.cluster.local:80
<RGW ACCESS KEY>
および<RGW SECRET KEY>
を取得するには、RGW ユーザーシークレット名を使用して以下のコマンドを実行します。oc get secret <RGW USER SECRET NAME> -o yaml
- Base64 からアクセスキー ID とアクセスキーをデコードし、それらのキーを保持します。
-
<RGW USER ACCESS KEY>
と<RGW USER SECRET ACCESS KEY>
を、直前の手順でデコードした適切なデータに置き換えます。 <bucket-name>
を既存の RGW バケット名に置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。出力は次のようになります。
INFO[0001] ✅ Exists: NooBaa "noobaa" INFO[0002] ✅ Created: BackingStore "rgw-resource" INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"
YAML を使用してバッキングストアを作成することもできます。
CephObjectStore
ユーザーを作成します。これにより、RGW 認証情報が含まれるシークレットも作成されます。apiVersion: ceph.rook.io/v1 kind: CephObjectStoreUser metadata: name: <RGW-Username> namespace: openshift-storage spec: store: ocs-storagecluster-cephobjectstore displayName: "<Display-name>"
-
<RGW-Username>
と<Display-name>
を、一意のユーザー名および表示名に置き換えます。
-
以下の YAML を S3 と互換性のあるバッキングストアについて適用します。
apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: finalizers: - noobaa.io/finalizer labels: app: noobaa name: <backingstore-name> namespace: openshift-storage spec: s3Compatible: endpoint: http://rook-ceph-rgw-ocs-storagecluster-cephobjectstore.openshift-storage.svc.cluster.local:80 secret: name: <backingstore-secret-name> namespace: openshift-storage signatureVersion: v4 targetBucket: <RGW-bucket-name> type: s3-compatible
-
<backingstore-secret-name>
を、直前の手順でCephObjectStore
で作成したシークレットの名前に置き換えます。 -
<bucket-name>
を既存の RGW バケット名に置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。
-
7.3.3. ユーザーインターフェースを使用したハイブリッドおよびマルチクラウドのストレージリソースの追加
手順
OpenShift Storage コンソールで、Overview → Object Service → に移動し、noobaa リンクを選択します。
以下に強調表示されているように左側にある Resources タブを選択します。設定する一覧から、Add Cloud Resource を選択します。
Add new connection を選択します。
関連するネイティブクラウドプロバイダーまたは S3 互換オプションを選択し、詳細を入力します。
新規に作成された接続を選択し、これを既存バケットにマップします。
- これらの手順を繰り返して、必要な数のバッキングストアを作成します。
NooBaa UI で作成されたリソースは、OpenShift UI または MCG CLI では使用できません。
7.3.4. 新規バケットクラスの作成
バケットクラスは、OBC (Object Bucket Class) の階層ポリシーおよびデータ配置を定義するバケットのクラスを表す CRD です。
以下の手順を使用して、OpenShift Container Storage でバケットクラスを作成します。
手順
- OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
- OpenShift Container Storage Operator をクリックします。
OpenShift Container Storage Operator ページで右側にスクロールし、Bucket Class タブをクリックします。
図7.1 Bucket Class タブのある OpenShift Container Storage Operator ページ
- Create Bucket Class をクリックします。
Create new Bucket Class ページで、以下を実行します。
Bucket Class Name を入力し、Next をクリックします。
図7.2 Create Bucket Class ページ
Placement Policy で Tier 1 - Policy Type を選択し、Next をクリックします。要件に応じて、いずれかのオプションを選択できます。
- Spread により、選択したリソース全体にデータを分散できます。
- Mirror により、選択したリソース全体でデータを完全に複製できます。
Add Tier をクリックし、別のポリシー階層を追加します。
図7.3 階層 1 - Policy Type 選択ページ
「Tier 1 - Policy Type」で「Spread」 を選択した場合、利用可能な一覧から 1 つ以上の Backing Store リソースを選択してから、Next をクリックします。または、新規バッキングストアを作成することもできます。
図7.4 階層 1 - Baking Store 選択ページ
直前の手順で「Policy Type」に「Mirror」を選択する場合、2 つ以上のバッキングストアを選択する必要があります。
Bucket Class 設定を確認し、確認します。
図7.5 バケットクラス設定の確認ページ
- Create Bucket Class をクリックします。
検証手順
- Operators → Installed Operators をクリックします。
- OpenShift Container Storage Operator をクリックします。
- 新しい Bucket Class を検索するか、または Bucket Class タブをクリックし、すべての Bucket Class を表示します。
7.3.5. 新規バッキングストアの作成
以下の手順を使用して、OpenShift Container Storage で新規のバッキングストアを作成します。
前提条件
- OpenShift への管理者アクセス。
手順
- OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
- OpenShift Container Storage Operator をクリックします。
OpenShift Container Storage Operator ページで右側にスクロールし、Backing Store タブをクリックします。
図7.6 バッキングストアタブのある OpenShift Container Storage Operator ページ
Create Backing Store をクリックします。
図7.7 Create Backing Store ページ
Create New Backing Store ページで、以下を実行します。
- Backing Store Name を入力します。
- Provider を選択します。
- Region を選択します。
- Endpoint を入力します。これはオプションです。
ドロップダウンリストから Secret を選択するか、または独自のシークレットを作成します。オプションで、Switch to Credentials ビューを選択すると、必要なシークレットを入力できます。
OCP シークレットの作成に関する詳細は、Openshift Container Platform ドキュメントの「シークレットの作成」を参照してください。
バッキングストアごとに異なるシークレットが必要です。特定のバッキングストアのシークレット作成についての詳細は 「MCG コマンドラインインターフェースを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加」 を参照して、YAML を使用したストレージリソースの追加についての手順を実行します。
注記このメニューは、Google Cloud およびローカル PVC 以外のすべてのプロバイダーに関連します。
- Target bucket を入力します。ターゲットバケットは、リモートクラウドサービスでホストされるコンテナーストレージです。MCG に対してシステム用にこのバケットを使用できることを通知する接続を作成できます。
- Create Backing Store をクリックします。
検証手順
- Operators → Installed Operators をクリックします。
- OpenShift Container Storage Operator をクリックします。
- 新しいバッキングストアを検索するか、または Backing Store タブをクリックし、すべてのバッキングストアを表示します。
7.4. ハイブリッドおよびマルチクラウドバケットのデータのミラーリング
Multicloud Object Gateway (MCG) は、クラウドプロバイダーおよびクラスター全体にまたがるデータの処理を単純化します。
前提条件
- まず、MCG で使用できるバッキングストレージを追加する必要があります。「ハイブリッドまたはマルチクラウド用のストレージリソースの追加」 を参照してください。
次に、データ管理ポリシー(ミラーリング)を反映するバケットクラスを作成します。
手順
ミラーリングデータは、以下の 3 つの方法で設定できます。
7.4.1. MCG コマンドラインインターフェースを使用したデータのミラーリング用のバケットクラスの作成
MCG コマンドラインインターフェースから以下のコマンドを実行し、ミラーリングポリシーでバケットクラスを作成します。
$ noobaa bucketclass create mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
新たに作成されたバケットクラスを新規のバケット要求に設定し、2 つのロケーション間でミラーリングされる新規バケットを生成します。
$ noobaa obc create mirrored-bucket --bucketclass=mirror-to-aws
7.4.2. YAML を使用したデータのミラーリング用のバケットクラスの作成
以下の YAML を適用します。この YAML は、ローカル Ceph ストレージと AWS 間でデータをミラーリングするハイブリッドの例です。
apiVersion: noobaa.io/v1alpha1 kind: BucketClass metadata: name: hybrid-class labels: app: noobaa spec: placementPolicy: tiers: - tier: mirrors: - mirror: spread: - cos-east-us - mirror: spread: - noobaa-test-bucket-for-ocp201907291921-11247_resource
以下の行を標準の Object Bucket Claim (オブジェクトバケット要求、OBC) に追加します。
additionalConfig: bucketclass: mirror-to-aws
OBC についての詳細は、「Object Bucket Claim(オブジェクトバケット要求)」を参照してください。
7.4.3. ユーザーインターフェースを使用したデータミラーリングを行うためのバケットの設定
OpenShift Storage コンソールで、Overview → Object Service → に移動し、noobaa リンクを選択します。
左側の buckets アイコンをクリックします。バケットの一覧が表示されます。
- 更新するバケットをクリックします。
Edit Tier 1 Resources をクリックします。
Mirror を選択し、このバケットに使用する関連リソースを確認します。以下の例では、prem Ceph RGW と AWS 間でデータのミラーリングをします。
- 保存 をクリックします。
NooBaa UI で作成されたリソースは、OpenShift UI または MCG CLI では使用できません。
7.5. Multicloud Object Gateway のバケットポリシー
OpenShift Container Storage は AWS S3 バケットポリシーをサポートします。バケットポリシーにより、ユーザーにバケットとそれらのオブジェクトのアクセスパーミッションを付与することができます。
7.5.1. バケットポリシーについて
バケットポリシーは、AWS S3 バケットおよびオブジェクトにパーミッションを付与するために利用できるアクセスポリシーオプションです。バケットポリシーは JSON ベースのアクセスポリシー言語を使用します。アクセスポリシー言語についての詳細は、「AWS Access Policy Language Overview」を参照してください。
7.5.2. バケットポリシーの使用
前提条件
- 実行中の OpenShift Container Storage Platform
- Multicloud Object Gateway へのアクセス。「アプリケーションの使用による Multicloud Object Gateway へのアクセス」を参照してください。
手順
Multicloud Object Gateway でバケットポリシーを使用するには、以下を実行します。
JSON 形式でバケットポリシーを作成します。以下の例を参照してください。
{ "Version": "NewVersion", "Statement": [ { "Sid": "Example", "Effect": "Allow", "Principal": [ "john.doe@example.com" ], "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::john_bucket" ] } ] }
バケットポリシーには数多くの利用可能な要素があります。それらの構成要素および使用方法についての詳細は、「AWS Access Policy Language Overview」を参照してください。
バケットポリシーの他の例については、「AWS Bucket Policy Examples」を参照してください。
S3 ユーザーの作成方法については、「Multicloud Object Gateway での AWS S3 ユーザーの作成」を参照してください。
AWS S3 クライアントを使用して
put-bucket-policy
コマンドを使用してバケットポリシーを S3 バケットに適用します。# aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy
ENDPOINT
を S3 エンドポイントに置き換えます。MyBucket
を、ポリシーを設定するバケットに置き換えます。BucketPolicy
をバケットポリシー JSON ファイルに置き換えます。デフォルトの自己署名証明書を使用している場合は、
--no-verify-ssl
を追加します。以下に例を示します。
# aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy
put-bucket-policy
コマンドについての詳細は、「AWS CLI Command Reference for put-bucket-policy」を参照してください。
主となる要素では、リソース (バケットなど) へのアクセスを許可または拒否されるユーザーを指定します。現在、NooBaa アカウントのみがプリンシパルとして使用できます。Object Bucket Claim (オブジェクトバケット要求) の場合、NooBaa はアカウント obc-account.<generated bucket name>@noobaa.io
を自動的に作成します。
バケットポリシー条件はサポートされていません。
7.5.3. Multicloud Object Gateway での AWS S3 ユーザーの作成
前提条件
- 実行中の OpenShift Container Storage Platform
- Multicloud Object Gateway へのアクセス。「アプリケーションの使用による Multicloud Object Gateway へのアクセス」を参照してください。
手順
OpenShift Storage コンソールで、Overview → Object Service → に移動し、noobaa リンクを選択します。
Accounts タブで、Create Account をクリックします。
S3 Access Only を選択し、Account Name を指定します (例: john.doe@example.com)。Next をクリックします。
S3 default placement を選択します (例: noobaa-default-backing-store)。Buckets Permissions を選択します。特定のバケットまたはすべてのバケットを選択できます。Create をクリックします。
7.6. Object Bucket Claim(オブジェクトバケット要求)
Object Bucket Claim(オブジェクトバケット要求)は、ワークロードの S3 と互換性のあるバケットバックエンドを要求するために使用できます。
Object Bucket Claim(オブジェクトバケット要求)は 3 つの方法で作成できます。
Object Bucket Claim(オブジェクトバケット要求)は、新しいアクセスキーおよびシークレットアクセスキーを含む、バケットのパーミッションのある NooBaa の新しいバケットとアプリケーションアカウントを作成します。アプリケーションアカウントは単一バケットにのみアクセスでき、デフォルトで新しいバケットを作成することはできません。
7.6.1. 動的 Object Bucket Claim(オブジェクトバケット要求)
永続ボリュームと同様に、Object Bucket Claim (オブジェクトバケット要求) の詳細をアプリケーションの YAML に追加し、設定マップおよびシークレットで利用可能なオブジェクトサービスエンドポイント、アクセスキー、およびシークレットアクセスキーを取得できます。この情報をアプリケーションの環境変数に動的に読み込むことは容易に実行できます。
手順
以下の行をアプリケーション YAML に追加します。
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: <obc-name> spec: generateBucketName: <obc-bucket-name> storageClassName: openshift-storage.noobaa.io
これらの行は Object Bucket Claim(オブジェクトバケット要求)自体になります。
-
<obc-name>
を、一意の Object Bucket Claim(オブジェクトバケット要求)の名前に置き換えます。 -
<obc-bucket-name>
を、Object Bucket Claim(オブジェクトバケット要求)の一意のバケット名に置き換えます。
-
YAML ファイルにさらに行を追加して、Object Bucket Claim(オブジェクトバケット要求)の使用を自動化できます。以下の例はバケット要求の結果のマッピングです。これは、データを含む設定マップおよび認証情報のあるシークレットです。この特定のジョブは NooBaa からオブジェクトバケットを要求し、バケットとアカウントを作成します。
apiVersion: batch/v1 kind: Job metadata: name: testjob spec: template: spec: restartPolicy: OnFailure containers: - image: <your application image> name: test env: - name: BUCKET_NAME valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_NAME - name: BUCKET_HOST valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_HOST - name: BUCKET_PORT valueFrom: configMapKeyRef: name: <obc-name> key: BUCKET_PORT - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: <obc-name> key: AWS_ACCESS_KEY_ID - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: <obc-name> key: AWS_SECRET_ACCESS_KEY
- <obc-name> のすべてのインスタンスを、Object Bucket Claim(オブジェクトバケット要求)の名前に置き換えます。
- <your application image> をアプリケーションイメージに置き換えます。
更新された YAML ファイルを適用します。
# oc apply -f <yaml.file>
-
<yaml.file>
を YAML ファイルの名前に置き換えます。
-
新しい設定マップを表示するには、以下を実行します。
# oc get cm <obc-name> -o yaml
obc-name
を、Object Bucket Claim(オブジェクトバケット要求)の名前に置き換えます。出力には、以下の環境変数が表示されることが予想されます。
-
BUCKET_HOST
: アプリケーションで使用するエンドポイント BUCKET_PORT
: アプリケーションで利用できるポート-
ポートは
BUCKET_HOST
に関連します。たとえば、BUCKET_HOST
が https://my.example.com で、BUCKET_PORT
が 443 の場合、オブジェクトサービスのエンドポイントは https://my.example.com:443 になります。
-
ポートは
-
BUCKET_NAME
: 要求されるか、または生成されるバケット名 -
AWS_ACCESS_KEY_ID
: 認証情報の一部であるアクセスキー -
AWS_SECRET_ACCESS_KEY
: 認証情報の一部であるシークレットのアクセスキー
-
7.6.2. コマンドラインインターフェースを使用した Object Bucket Claim(オブジェクトバケット要求)の作成
コマンドラインインターフェースを使用して Object Bucket Claim(オブジェクトバケット要求)を作成する場合、設定マップとシークレットを取得します。これらには、アプリケーションがオブジェクトストレージサービスを使用するために必要なすべての情報が含まれます。
前提条件
MCG コマンドラインインターフェースをダウンロードします。
# subscription-manager repos --enable=rh-ocs-4-for-rhel-8-x86_64-rpms # yum install mcg
手順
コマンドラインインターフェースを使用して、新規バケットおよび認証情報の詳細を生成します。以下のコマンドを実行します。
# noobaa obc create <obc-name> -n openshift-storage
<obc-name>
を一意の Object Bucket Claim(オブジェクトバケット要求)の名前に置き換えます (例:myappobc
)。さらに、
--app-namespace
オプションを使用して、Object Bucket Claim(オブジェクトバケット要求)設定マップおよびシークレットが作成される namespace を指定できます(例:myapp-namespace
)。出力例:
INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"
MCG コマンドラインインターフェースが必要な設定を作成し、新規 OBC について OpenShift に通知します。
以下のコマンドを実行して Object Bucket Claim(オブジェクトバケット要求)を表示します。
# oc get obc -n openshift-storage
出力例:
NAME STORAGE-CLASS PHASE AGE test21obc openshift-storage.noobaa.io Bound 38s
以下のコマンドを実行して、新規 Object Bucket Claim(オブジェクトバケット要求)の YAML ファイルを表示します。
# oc get obc test21obc -o yaml -n openshift-storage
出力例:
apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer generation: 2 labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage resourceVersion: "40756" selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af spec: ObjectBucketName: obc-openshift-storage-test21obc bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4 generateBucketName: test21obc storageClassName: openshift-storage.noobaa.io status: phase: Bound
openshift-storage
namespace 内で、設定マップおよびシークレットを見つけ、この Object Bucket Claim(オブジェクトバケット要求)を使用することができます。CM とシークレットの名前はこの Object Bucket Claim(オブジェクトバケット要求)の名前と同じです。シークレットを表示するには、以下を実行します。# oc get -n openshift-storage secret test21obc -o yaml
出力例:
Example output: apiVersion: v1 data: AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY= AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ== kind: Secret metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage ownerReferences: - apiVersion: objectbucket.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ObjectBucketClaim name: test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af resourceVersion: "40751" selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc uid: 65117c1c-f662-11e9-9094-0a5305de57bb type: Opaque
シークレットは S3 アクセス認証情報を提供します。
設定マップを表示するには、以下を実行します。
# oc get -n openshift-storage cm test21obc -o yaml
出力例:
apiVersion: v1 data: BUCKET_HOST: 10.0.171.35 BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4 BUCKET_PORT: "31242" BUCKET_REGION: "" BUCKET_SUBREGION: "" kind: ConfigMap metadata: creationTimestamp: "2019-10-24T13:30:07Z" finalizers: - objectbucket.io/finalizer labels: app: noobaa bucket-provisioner: openshift-storage.noobaa.io-obc noobaa-domain: openshift-storage.noobaa.io name: test21obc namespace: openshift-storage ownerReferences: - apiVersion: objectbucket.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ObjectBucketClaim name: test21obc uid: 64f04cba-f662-11e9-bc3c-0295250841af resourceVersion: "40752" selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc uid: 651c6501-f662-11e9-9094-0a5305de57bb
設定マップには、アプリケーションの S3 エンドポイント情報が含まれます。
7.6.3. OpenShift Web コンソールを使用した Object Bucket Claim(オブジェクトバケット要求)の作成
OpenShift Web コンソールを使用して Object Bucket Claim (オブジェクトバケット要求) を作成できます。
前提条件
- OpenShift Web コンソールへの管理者アクセス。
- アプリケーションが OBC と通信できるようにするには、configmap およびシークレットを使用する必要があります。これについての詳細は、「動的 Object Bucket Claim(オブジェクトバケット要求)」 を参照してください。
手順
- OpenShift Web コンソールにログインします。
- 左側のナビゲーションバーで Storage → Object Bucket Claims をクリックします。
Create Object Bucket Claim をクリックします。
Object Bucket Claim(オブジェクトバケット要求)の名前を入力し、ドロップダウンメニューから、内部または外部かのデプロイメントに応じて適切なストレージクラスとバケットクラスを選択します。
内部モード
デプロイメント後に作成された以下のストレージクラスを使用できます。
-
ocs-storagecluster-ceph-rgw
は Ceph Object Gateway (RGW) を使用します。 -
openshift-storage.noobaa.io
は Multicloud Object Gateway を使用します。
外部モード
デプロイメント後に作成された以下のストレージクラスを使用できます。
-
ocs-external-storagecluster-ceph-rgw
は Ceph Object Gateway (RGW) を使用します。 openshift-storage.noobaa.io
は Multicloud Object Gateway を使用します。注記RGW OBC ストレージクラスは、OpenShift Container Storage バージョン 4.5 の新規インストールでのみ利用できます。これは、以前の OpenShift Container Storage リリースからアップグレードされたクラスターには適用されません。
-
Create をクリックします。
OBC を作成すると、その詳細ページにリダイレクトされます。
7.7. エンドポイントの追加による Multicloud Object Gateway パフォーマンスのスケーリング
Multicloud Object Gateway のパフォーマンスは環境によって異なる場合があります。特定のアプリケーションでは、高速なパフォーマンスを必要とする場合があり、これは S3 エンドポイントをスケーリングして簡単に対応できます。
Multicloud Object Gateway リソースプールは、デフォルトで有効にされる 2 種類のサービスを提供する NooBaa デーモンコンテナーのグループです。
- ストレージサービス
- S3 エンドポイントサービス
7.7.1. Multicloud Object Gateway での S3 エンドポイント
S3 エンドポイントは、すべての Multicloud Object Gateway がデフォルトで提供するサービスであり、これは Multicloud Object Gateway で負荷の高いデータ消費タスクの大部分を処理します。エンドポイントサービスは、インラインのデータチャンク、重複排除、圧縮、および暗号化を処理し、Multicloud Object Gateway からのデータ配置の指示を受け入れます。
7.7.2. ストレージノードを使用したスケーリング
前提条件
- Multicloud Object Gateway へのアクセスのある OpenShift Container Platform で実行中の OpenShift Container Storage Platform
Multicloud Object Gateway のストレージノードは 1 つ以上の永続ボリュームに割り当てられた NooBaa デーモンコンテナーであり、ローカルオブジェクトサービスデータストレージに使用されます。NooBaa デーモンは Kubernetes ノードにデプロイできます。これは、StatefulSet Pod で構成される Kubernetes プールを作成して実行できます。
手順
Mult-Cloud Object Gateway ユーザーインターフェースの Overview ページで、 Add Storage Resources をクリックします。
ウィンドウから Deploy Kubernetes Pool をクリックします。
Create Pool 手順で、今後インストールされるノードのターゲットプールを作成します。
Configure 手順で、要求される Pod 数と各 PV のサイズを設定します。新規 Pod ごとに、1 つの PV が作成されます。
- Review 手順で、新規プールの詳細を検索し、ローカルまたは外部デプロイメントのいずれかの使用するデプロイメント方法を選択します。ローカルデプロイメントが選択されている場合、Kubernetes ノードはクラスター内にデプロイされます。外部デプロイメントが選択されている場合、外部で実行するための YAML ファイルが提供されます。
すべてのノードは最初の手順で選択したプールに割り当てられ、Resources → Storage resources → Resource name の下で確認できます。
第8章 永続ボリューム要求の管理
PVC の拡張は OpenShift Container Storage がサポートする PVC ではサポートされません。
8.1. OpenShift Container Platform を使用するためのアプリケーション Pod の設定
このセクションの手順に従って、OpenShift Container Storage をアプリケーション Pod のストレージとして設定します。
前提条件
- OpenShift Web コンソールへの管理者アクセスがある。
-
OpenShift Container Storage Operator が
openshift-storage
namespace にインストールされ、実行されている。OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。 - OpenShift Container Storage が提供するデフォルトのストレージクラスが利用可能である。OpenShift Web コンソールで Storage → Storage Class をクリックし、デフォルトのストレージクラスを表示します。
手順
使用するアプリケーションの Persistent Volume Claim(永続ボリューム要求、PVC)を作成します。
- OpenShift Web コンソールで、Storage → Persistent Volume Claims をクリックします。
- アプリケーション Pod の Project を設定します。
Create Persistent Volume Claim をクリックします。
- OpenShift Container Storage によって提供される Storage Class を指定します。
-
PVC Name (例:
myclaim
) を指定します。 - 必要な Access Mode を選択します。
- アプリケーション要件に応じて Size を指定します。
-
Create をクリックし、PVC のステータスが
Bound
になるまで待機します。
新規または既存のアプリケーション Pod を新規 PVC を使用するように設定します。
新規アプリケーション Pod の場合、以下の手順を実行します。
- Workloads →Pods をクリックします。
- 新規アプリケーション Pod を作成します。
spec:
セクションで、volume:
セクションを追加し、新規 PVC をアプリケーション Pod のボリュームとして追加します。volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>
以下に例を示します。
volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
既存のアプリケーション Pod の場合、以下の手順を実行します。
- Workloads →Deployment Configs をクリックします。
- アプリケーション Pod に関連付けられた必要なデプロイメント設定を検索します。
- Action menu (⋮) → Edit Deployment Config をクリックします。
spec:
セクションで、volume:
セクションを追加し、新規 PVC をアプリケーション Pod のボリュームとして追加し、Save をクリックします。volumes: - name: <volume_name> persistentVolumeClaim: claimName: <pvc_name>
以下に例を示します。
volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
新しい設定が使用されていることを確認します。
- Workloads → Pods をクリックします。
- アプリケーション Pod の Project を設定します。
-
アプリケーション Pod が
Running
ステータスで表示されていることを確認します。 - アプリケーション Pod 名をクリックし、Pod の詳細を表示します。
-
Volumes セクションまでスクロールダウンし、ボリュームに新規 Persistent Vocume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例:
myclaim
)。
8.2. Persistent Volume Claim (永続ボリューム要求、PVC) 要求ステータスの表示
以下の手順を使用して、PVC 要求のステータスを表示します。
前提条件
- OpenShift Container Storage への管理者アクセス。
手順
- OpenShift Web コンソールにログインします。
- Storage → Persistent Volume Claims をクリックします。
- Filter テキストボックスを使用して、必要な PVC 名を検索します。また、一覧を絞り込むために Name または Label で PVC の一覧をフィルターすることもできます。
- 必要な PVC に対応する Status 列を確認します。
- 必要な Name をクリックして PVC の詳細を表示します。
8.3. Persistent Volume Claim (永続ボリューム要求、PVC) 要求イベントの確認
以下の手順を使用して、Persistent Volume Claim(永続ボリューム要求、PVC)要求イベントを確認し、これに対応します。
前提条件
- OpenShift Web コンソールへの管理者アクセス。
手順
- OpenShift Web コンソールにログインします。
- Home → Overview → Persistent Storage をクリックします。
- Inventory カードを見つけ、エラーのある PVC の数を確認します。
- Storage → Persistent Volume Claims をクリックします。
- Filter テキストボックスを使用して、必要な PVC を検索します。
- PVC 名をクリックし、Events に移動します。
- 必要に応じて、または指示に応じてイベントに対応します。
8.4. 動的プロビジョニング
8.4.1. 動的プロビジョニングについて
StorageClass リソースオブジェクトは、要求可能なストレージを記述し、分類するほか、要求に応じて動的にプロビジョニングされるストレージのパラメーターを渡すための手段を提供します。StorageClass オブジェクトは、さまざまなレベルのストレージおよびストレージへのアクセスを制御するための管理メカニズムとしても機能します。クラスター管理者 (cluster-admin
) またはストレージ管理者 (storage-admin
) は、ユーザーが基礎となるストレージボリュームソースに関する詳しい知識なしに要求できる StorageClass オブジェクトを定義し、作成します。
OpenShift Container Platform の永続ボリュームフレームワークはこの機能を有効にし、管理者がクラスターに永続ストレージをプロビジョニングできるようにします。フレームワークにより、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。
OpenShift Container Platform では、数多くのストレージタイプを永続ボリュームとして使用することができます。これらはすべて管理者によって静的にプロビジョニングされますが、一部のストレージタイプは組み込みプロバイダーとプラグイン API を使用して動的に作成できます。
8.4.2. OpenShift Container Storage の動的プロビジョニング
Red Hat OpenShift Container Storage は、コンテナー環境向けに最適化されたソフトウェアで定義されるストレージです。これは OpenShift Container Platform の Operator として実行され、コンテナーの統合され、単純化された永続ストレージの管理を可能にします。
OpenShift Container Storage は、以下を含む各種のストレージタイプをサポートします。
- データベースのブロックストレージ
- 継続的な統合、メッセージングおよびデータ集約のための共有ファイルストレージ
- アーカイブ、バックアップおよびメディアストレージのオブジェクトストレージ
バージョン 4.5 では、Red Hat Ceph Storage を使用して永続ボリュームをサポートするファイル、ブロック、およびオブジェクトストレージを提供し、Rook.io を使用して永続ボリュームおよび要求のプロビジョニングを管理し、オーケストレーションします。NooBaa はオブジェクトストレージを提供し、その Multicloud Gateway は複数のクラウド環境でのオブジェクトのフェデレーションを可能にします (テクノロジープレビューとしてご利用いただけます)。
OpenShift Container Storage 4.5 では、RADOS Block Device (RBD) および Ceph File System (CephFS) の Red Hat Ceph Storage Container Storage Interface (CSI) ドライバーが動的プロビジョニング要求を処理します。PVC 要求が動的に送信される場合、CSI ドライバーでは以下のオプションを使用できます。
-
ボリュームモードが
Block
の Ceph RBD をベースとする PVC (ReadWriteOnce (RWO) および ReadWriteMany (RWX) アクセス) を作成します。 -
ボリュームモードが
Filesystem
の Ceph RBD をベースとする PVC (ReadWriteOnce (RWO) アクセス) を作成します。 -
ボリュームモードが
Filesystem
の CephFS をベースとする PVC (ReadWriteOnce (RWO) および ReadWriteMany (RWX) アクセス) を作成します。
使用するドライバー(RBD または CephFS)の判断は、storageclass.yaml
ファイルのエントリーに基づいて行われます。
8.4.3. 利用可能な動的プロビジョニングプラグイン
OpenShift Container Platform は、以下のプロビジョナープラグインを提供します。 これらには、クラスターの設定済みプロバイダーの API を使用して新規ストレージリソースを作成する動的プロビジョニング用の一般的な実装が含まれます。
ストレージタイプ | プロビジョナープラグインの名前 | 注記 |
---|---|---|
OpenStack Cinder |
| |
AWS Elastic Block Store (EBS) |
|
複数クラスターを複数の異なるゾーンで使用する際の動的プロビジョニングの場合、各ノードに |
AWS Elastic File System (EFS) | 動的プロビジョニングは、EFS プロビジョナー Pod で実行され、プロビジョナープラグインでは実行されません。 | |
Azure Disk |
| |
Azure File |
|
|
GCE Persistent Disk (gcePD) |
| マルチゾーン設定では、GCE プロジェクトごとに OpenShift Container Platform クラスターを実行し、現行クラスターのノードが存在しないゾーンで PV が作成されないようにすることが推奨されます。 |
|
選択したプロビジョナープラグインでは、関連するクラウド、ホスト、またはサードパーティープロバイダーを、関連するドキュメントに従って設定する必要もあります。
第9章 ストレージノードの置き換え
以下のいずれかの手順を選択して、ストレージノードを置き換えることができます。
9.1. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーで動作するノードの置き換え
以下の手順を使用して、Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャー (IPI) で動作するノードを置き換えます。
手順
- OpenShift Web コンソールにログインし、Compute → Nodes をクリックします。
- 置き換える必要のあるノードを特定します。その マシン名 をメモします。
以下のコマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。
$ oc adm cordon <node_name>
以下のコマンドを使用してノードをドレイン (解放) します。
$ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets
重要このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、これが機能すると自動的に解決されます。
- Compute → Machines をクリックします。必要なマシンを検索します。
- 必要なマシンの横にある Action menu (⋮) → Delete Machine をクリックします。
- Delete をクリックしてマシンの削除を確認します。新しいマシンが自動的に作成されます。
新規マシンが起動し、Running 状態に移行するまで待機します。
重要このアクティビティーには少なくとも 5-10 分以上かかる場合があります。
- Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。
以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。
- ユーザーインターフェースを使用する場合
- 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
-
cluster.ocs.openshift.io/openshift-storage
を追加し、Save をクリックします。
- コマンドラインインターフェースの使用
以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
検証手順
以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
- 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
- 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。
9.2. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーでの失敗したノードの置き換え
以下の手順に従って、OpenShift Container Storage の Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャー (IPI) で動作しない障害のあるノードを置き換えます。
手順
- OpenShift Web コンソールにログインし、Compute → Nodes をクリックします。
- 障害のあるノードを特定し、その Machine Name をクリックします。
- Actions → Edit Annotations をクリックし、Add More をクリックします。
-
machine.openshift.io/exclude-node-draining
を追加し、Save をクリックします。 - Actions → Delete Machine をクリックしてから、Delete をクリックします。
新しいマシンが自動的に作成されます。新規マシンが起動するのを待機します。
重要このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、これが機能すると自動的に解決されます。
- Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。
以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。
- ユーザーインターフェースを使用する場合
- 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
-
cluster.ocs.openshift.io/openshift-storage
を追加し、Save をクリックします。
- コマンドラインインターフェースの使用
以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。
$ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""
- [オプション]: 失敗した Google Cloud インスタンスが自動的に削除されない場合、インスタンスを Google Cloud コンソールで終了します。
検証手順
以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。
$ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1
Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。
-
csi-cephfsplugin-*
-
csi-rbdplugin-*
-
- 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
- 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。
第10章 ストレージデバイスの置き換え
10.1. Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーで動作するストレージデバイスまたは失敗したストレージデバイスの置き換え
Google Cloud のインストーラーでプロビジョニングされるインフラストラクチャーの動的に作成されたストレージクラスターのデバイスを置き換える必要がある場合は、ストレージノードを置き換える必要があります。ノードを置き換える方法は、以下を参照してください。