VMware vSphere 上での OpenShift Data Foundation のデプロイ
VMware vSphere インフラストラクチャーを使用した OpenShift Data Foundation のデプロイ手順
概要
多様性を受け入れるオープンソースの強化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、用語の置き換えは、今後の複数のリリースにわたって段階的に実施されます。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があれば、ぜひお知らせください。
フィードバックを送信するには、Bugzilla チケットを作成します。
- Bugzilla の Web サイトに移動します。
- Component セクションで、documentation を選択します。
- Description フィールドに、ドキュメントの改善に向けたご提案を記入してください。ドキュメントの該当部分へのリンクも記載してください。
- Submit Bug をクリックします。
はじめに リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Data Foundation は、接続環境または非接続環境での既存の Red Hat OpenShift Container Platform (RHOCP) vSphere クラスターへのデプロイメントをサポートし、プロキシー環境に対する追加設定なしのサポートを提供します。
VMware vSphere では、内部と外部の両方の OpenShift Data Foundation クラスターがサポートされます。デプロイメントの要件の詳細は、デプロイメントのプランニング および OpenShift Data Foundation のデプロイの準備 を参照してください。
OpenShift Data Foundation をデプロイするには、OpenShift Data Foundation のデプロイの準備 の章の要件を確認し、環境についての以下のデプロイメントプロセスのいずれかを実行します。
第1章 OpenShift Data Foundation のデプロイの準備 リンクのコピーリンクがクリップボードにコピーされました!
動的またはローカルストレージデバイスを使用して OpenShift Data Foundation を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成するオプションが提供されます。これにより、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用できるようになります。
動的またはローカルストレージを使用して Red Hat OpenShift Data Foundation のデプロイメントを開始する前に、リソース要件を満たしていることを確認してください。デプロイメントのプランニング を参照してください。
オプション: 外部の鍵管理システム (KMS) HashiCorp Vault を使用してクラスター全体の暗号化を有効にする場合は、次の手順に従います。
- 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプションがあることを確認してください。OpenShift Data Foundation のサブスクリプションの仕組みを確認するには、OpenShift Data Foundation subscriptions に関するナレッジベースの記事 を参照してください。
- 暗号化にトークン認証方法が選択されている場合は、Enabling cluster-wide encryption with the Token authentication using KMS を参照してください。
- 暗号化に Kubernetes 認証方式が選択されている場合は、KMS を使用した Kubernetes 認証によるクラスター全体の暗号化の有効化 を参照してください。
- Vault サーバーで署名済みの証明書を使用していることを確認します。
オプション: 外部の鍵管理システム (KMS) Thales CipherTrust Manager を使用してクラスター全体の暗号化を有効にする場合は、まず Key Management Interoperability Protocol (KMIP) を有効にして、サーバーで署名付き証明書を使用する必要があります。以下の手順に従ってください。
KMIP クライアントが存在しない場合は作成します。ユーザーインターフェイスから、KMIP → Client Profile → Add Profile を選択します。
-
プロファイルの作成中に、
CipherTrustのユーザー名を Common Name フィールドに追加します。
-
プロファイルの作成中に、
- KMIP → Registration Token → New Registration Token に移動してトークンを作成します。次のステップのためにトークンをコピーしておきます。
- クライアントを登録するために、KMIP → Registered Clients → Add Client に移動します。Name を指定します。前のステップの Registration Token を貼り付けて、Save をクリックします。
- Save Private Key と Save Certificate をクリックして、それぞれ秘密鍵とクライアント証明書をダウンロードします。
新しい KMIP インターフェイスを作成するために、Admin Settings → Interfaces → Add Interface に移動します。
- KMIP Key Management Interoperability Protocol を選択し、Next をクリックします。
- 空いている Port を選択します。
- Network Interface は all を選択します。
- Interface Mode は TLS, verify client cert, user name taken from client cert, auth request is optional を選択します。
- (オプション) 物理削除を有効にして、鍵が削除されたときにメタデータとマテリアルの両方を削除することができます。これはデフォルトでは無効になっています。
- 使用する CA を選択し、Save をクリックします。
- サーバー CA 証明書を取得するために、新しく作成されたインターフェイスの右側にあるアクションメニュー (⋮) をクリックし、Download Certificate をクリックします。
オプション: デプロイ時に StorageClass 暗号化を有効にする場合は、キー暗号化キー (KEK) として機能するキーを作成します。
- Keys → Add Key に移動します。
- Key Name を入力します。
- Algorithm と Size をそれぞれ AES と 256 に設定します。
- Create a key in Pre-Active state を有効にして、アクティベーションの日時を設定します。
- Key Usage で Encrypt と Decrypt が有効になっていることを確認します。
- 新しく作成した鍵の ID をコピーして、デプロイメント中に一意の識別子として使用します。
ノードの最小要件
OpenShift Data Foundation クラスターは、標準のデプロイメントリソース要件を満たしていない場合に、最小の設定でデプロイされます。プランニングガイドの リソース要件 セクションを参照してください。
障害復旧の要件 [テクノロジープレビュー]
Red Hat OpenShift Data Foundation でサポートされる障害復旧機能では、障害復旧ソリューションを正常に実装するために以下の前提条件をすべて満たす必要があります。
- 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプション
有効な Red Hat Advanced Cluster Management for Kubernetes サブスクリプション
OpenShift Data Foundation のサブスクリプションの仕組みを確認するには、OpenShift Data Foundation subscriptions に関するナレッジベースの記事 を参照してください。
詳細な要件については、OpenShift ワークロード用の OpenShift Data Foundation Disaster Recovery の設定 ガイド、および Red Hat Advanced Cluster Management for Kubernetes ドキュメントの インストールガイド の 要件と推奨事項 のセクションを参照してください。
- ローカルストレージデバイスを使用したデプロイは、ローカルストレージデバイスを使用して OpenShift Data Foundation をインストールするための要件 を確認します。これらは、動的ストレージデバイスを使用するデプロイメントには該当しません。
1.1. ローカルストレージデバイスを使用して OpenShift Data Foundation をインストールするための要件 リンクのコピーリンクがクリップボードにコピーされました!
ノードの要件
クラスターは少なくとも 3 つの OpenShift Container Platform ワーカーノードで設定されており、ノードごとにローカルに接続されたストレージデバイスを備えている。
- 選択した 3 つのノードのそれぞれで、少なくとも 1 つの raw ブロックデバイスが使用できる。OpenShift Data Foundation は、1 つ以上の使用可能な raw ブロックデバイスを使用します。
- 使用するデバイスが空である。ディスクには物理ボリューム (PV)、ボリュームグループ (VG)、または論理ボリューム (LV) を含めないでください。
詳細は、プランニングガイド の リソース要件 セクションを参照してください。
ディザスタリカバリーの要件 テクノロジープレビュー
Red Hat OpenShift Data Foundation でサポートされる障害復旧機能では、障害復旧ソリューションを正常に実装するために以下の前提条件をすべて満たす必要があります。
- 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプション。
- 有効な Red Hat Advanced Cluster Management (RHACM) for Kubernetes サブスクリプション。
OpenShift Data Foundation のサブスクリプションの仕組みを確認するには、OpenShift Data Foundation subscriptions に関するナレッジベースの記事 を参照してください。
詳細な障害復旧の要件は、OpenShift ワークロード用の OpenShift Data Foundation Disaster Recovery の設定 ガイド、および Red Hat Advanced Cluster Management for Kubernetes ドキュメントの インストールガイド の 要件と推奨事項 のセクションを参照してください。
Arbiter ストレッチクラスターの要件 [テクノロジープレビュー]
この例では、3 番目のゾーンを Arbiter の場所とした上で、単一クラスターが 2 つのゾーンにデプロイメントされます。これはテクノロジープレビュー機能であり、現時点では OpenShift Container Platform オンプレミスおよび同じデータセンターでのデプロイメントを目的としています。このソリューションは、複数のデータセンターにまたがる展開には推奨できません。代わりに、Metro-DR を、低遅延ネットワークを備えた複数のデータセンターに展開されたデータ損失のない DR ソリューションの最初のオプションとして検討してください。
詳細な要件と手順については、ストレッチクラスター用の OpenShift Data Foundation の設定に関する ナレッジベースの記事 を参照してください。
OpenShift Data Foundation のサブスクリプションがどのように機能するかを知るには、OpenShift Data Foundation subscriptions に関するナレッジベースの記事 を参照してください。
スケーリングロジックが競合しているため、フレキシブルスケーリングと Arbiter の両方を同時に有効にすることはできません。フレキシブルスケーリングを使用すると、一度に 1 つのノードを OpenShift Data Foundation クラスターに追加することができます。Arbiter クラスターでは、2 つのデータゾーンごとに 1 つ以上のノードを追加する必要があります。
ノードの最小要件
OpenShift Data Foundation クラスターは、標準のデプロイメントリソース要件を満たしていない場合に、最小の設定でデプロイされます。
詳細は、プランニングガイド の リソース要件 セクションを参照してください。
第2章 動的ストレージデバイスを使用したデプロイ リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere (ディスク形式: thin) で提供される動的ストレージデバイスを使用して OpenShift Data Foundation を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成するオプションが提供されます。これにより、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用できるようになります。
VMware vSphere では、内部と外部の両方の OpenShift Data Foundation クラスターがサポートされます。デプロイメント要件の詳細は、Planning your deploymentを参照してください。
また、OpenShift Data Foundation のデプロイの準備 の章にある要件に対応していることを確認してから、動的ストレージデバイスを使用したデプロイについて以下の手順を実行してください。
2.1. Red Hat OpenShift Data Foundation Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Data Foundation Operator は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。
前提条件
-
cluster-adminおよび operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - Red Hat OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。各ノードには 1 つのディスクが含まれ、3 つのディスク(PV)が必要です。ただし、1 つの PV はデフォルトで最終的に使用されません。これは想定される動作です。
- その他のリソース要件は、デプロイメントのプランニング ガイドを参照してください。
OpenShift Data Foundation のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、以下のコマンドを使用して、
openshift-storagenamespace の空のノードセレクターを指定できます (この場合はopenshift-storageを作成します)。oc annotate namespace openshift-storage openshift.io/node-selector=
$ oc annotate namespace openshift-storage openshift.io/node-selector=Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように
infraのテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当て ガイドの Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 を参照してください。
手順
- OpenShift Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
スクロールするか、
OpenShift Data Foundationを Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。 - Install をクリックします。
Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.12 として更新します。
- Installation Mode オプションで A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace
openshift-storageが存在しない場合は、Operator のインストール時に作成されます。 承認ストラテジーを Automatic または Manual として選択します。
Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- Console プラグイン に Enable オプションが選択されていることを確認します。
- Install をクリックします。
検証手順
-
Operator が正常にインストールされると、
Web console update is availableメッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。 Web コンソールに移動します。
- Installed Operators に移動し、OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
- Storage に移動し、Data Foundation ダッシュボードが使用可能かどうかを確認します。
2.2. トークン認証方式を使用した KMS でのクラスター全体の暗号化の有効化 リンクのコピーリンクがクリップボードにコピーされました!
トークン認証のために、Vault でキーと値のバックエンドパスおよびポリシーを有効にできます。
前提条件
- Vault への管理者アクセス。
- 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプション。詳細は、OpenShift Data Foundation サブスクリプションに関するナレッジベースの記事 を参照してください。
-
後で変更できないため、命名規則に従って一意のパス名をバックエンド
pathとして慎重に選択してください。
手順
Vault で Key/Value (KV) バックエンドパスを有効にします。
Vault KV シークレットエンジン API の場合は、バージョン 1 です。
vault secrets enable -path=odf kv
$ vault secrets enable -path=odf kvCopy to Clipboard Copied! Toggle word wrap Toggle overflow Vault KV シークレットエンジン API の場合は、バージョン 2 を使用します。
vault secrets enable -path=odf kv-v2
$ vault secrets enable -path=odf kv-v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットに対して書き込み操作または削除操作を実行するようにユーザーを制限するポリシーを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のポリシーに一致するトークンを作成します。
vault token create -policy=odf -format json
$ vault token create -policy=odf -format jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. Kubernetes 認証方式を使用した KMS でのクラスター全体の暗号化の有効化 リンクのコピーリンクがクリップボードにコピーされました!
キー管理システム (KMS) を使用して、クラスター全体の暗号化に対して Kubernetes 認証方式を有効にできます。
前提条件
- Vault への管理者アクセス。
- 有効な Red Hat OpenShift Data Foundation Advanced サブスクリプション。詳細は、OpenShift Data Foundation サブスクリプションに関するナレッジベースの記事 を参照してください。
- OpenShift Data Foundation Operator が Operator Hub からインストールされている。
-
バックエンド
pathとして一意のパス名を選択する。これは命名規則に厳密に準拠する必要があります。このパス名は後で変更できません。
手順
サービスアカウントを作成します。
oc -n openshift-storage create serviceaccount <serviceaccount_name>
$ oc -n openshift-storage create serviceaccount <serviceaccount_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<serviceaccount_name>はサービスアカウントの名前を指定します。以下に例を示します。
oc -n openshift-storage create serviceaccount odf-vault-auth
$ oc -n openshift-storage create serviceaccount odf-vault-authCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusterrolebindingsとclusterrolesを作成します。oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:_<serviceaccount_name>_
$ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:_<serviceaccount_name>_Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:odf-vault-auth
$ oc -n openshift-storage create clusterrolebinding vault-tokenreview-binding --clusterrole=system:auth-delegator --serviceaccount=openshift-storage:odf-vault-authCopy to Clipboard Copied! Toggle word wrap Toggle overflow serviceaccountトークンおよび CA 証明書のシークレットを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<serviceaccount_name>は、前の手順で作成したサービスアカウントです。シークレットからトークンと CA 証明書を取得します。
SA_JWT_TOKEN=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['token']}" | base64 --decode; echo) SA_CA_CRT=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)$ SA_JWT_TOKEN=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['token']}" | base64 --decode; echo) $ SA_CA_CRT=$(oc -n openshift-storage get secret odf-vault-auth-token -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)Copy to Clipboard Copied! Toggle word wrap Toggle overflow OCP クラスターエンドポイントを取得します。
OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")$ OCP_HOST=$(oc config view --minify --flatten -o jsonpath="{.clusters[0].cluster.server}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントの発行者を取得します。
oc proxy & proxy_pid=$! issuer="$( curl --silent http://127.0.0.1:8001/.well-known/openid-configuration | jq -r .issuer)" kill $proxy_pid
$ oc proxy & $ proxy_pid=$! $ issuer="$( curl --silent http://127.0.0.1:8001/.well-known/openid-configuration | jq -r .issuer)" $ kill $proxy_pidCopy to Clipboard Copied! Toggle word wrap Toggle overflow 前の手順で収集した情報を使用して、Vault で Kubernetes 認証方法を設定します。
vault auth enable kubernetes
$ vault auth enable kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow vault write auth/kubernetes/config \ token_reviewer_jwt="$SA_JWT_TOKEN" \ kubernetes_host="$OCP_HOST" \ kubernetes_ca_cert="$SA_CA_CRT" \ issuer="$issuer"$ vault write auth/kubernetes/config \ token_reviewer_jwt="$SA_JWT_TOKEN" \ kubernetes_host="$OCP_HOST" \ kubernetes_ca_cert="$SA_CA_CRT" \ issuer="$issuer"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要発行者が空の場合は Vault で Kubernetes 認証方法を設定します。
vault write auth/kubernetes/config \ token_reviewer_jwt="$SA_JWT_TOKEN" \ kubernetes_host="$OCP_HOST" \ kubernetes_ca_cert="$SA_CA_CRT"$ vault write auth/kubernetes/config \ token_reviewer_jwt="$SA_JWT_TOKEN" \ kubernetes_host="$OCP_HOST" \ kubernetes_ca_cert="$SA_CA_CRT"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vault で Key/Value (KV) バックエンドパスを有効にします。
Vault KV シークレットエンジン API の場合は、バージョン 1 を使用します。
vault secrets enable -path=odf kv
$ vault secrets enable -path=odf kvCopy to Clipboard Copied! Toggle word wrap Toggle overflow Vault KV シークレットエンジン API の場合は、バージョン 2 を使用します。
vault secrets enable -path=odf kv-v2
$ vault secrets enable -path=odf kv-v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットに対して
writeまたはdelete操作を実行するようにユーザーを制限するポリシーを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ロールを作成します。
vault write auth/kubernetes/role/odf-rook-ceph-op \ bound_service_account_names=rook-ceph-system,rook-ceph-osd,noobaa \ bound_service_account_namespaces=openshift-storage \ policies=odf \ ttl=1440h$ vault write auth/kubernetes/role/odf-rook-ceph-op \ bound_service_account_names=rook-ceph-system,rook-ceph-osd,noobaa \ bound_service_account_namespaces=openshift-storage \ policies=odf \ ttl=1440hCopy to Clipboard Copied! Toggle word wrap Toggle overflow ロール
odf-rook-ceph-opは、後でストレージシステムの作成中に KMS 接続の詳細を設定するときに使用されます。vault write auth/kubernetes/role/odf-rook-ceph-osd \ bound_service_account_names=rook-ceph-osd \ bound_service_account_namespaces=openshift-storage \ policies=odf \ ttl=1440h$ vault write auth/kubernetes/role/odf-rook-ceph-osd \ bound_service_account_names=rook-ceph-osd \ bound_service_account_namespaces=openshift-storage \ policies=odf \ ttl=1440hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. Multus ネットワークの作成 [テクノロジープレビュー] リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール中にデフォルトの Pod ネットワークを設定できます。デフォルトのネットワークは、クラスターの通常のネットワークトラフィックをすべて処理します。
利用可能な CNI プラグインに基づいて追加のネットワークを定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。追加のネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。
NetworkAttachmentDefinition (NAD) カスタムリソース (CR) を使用して、各インターフェイスを指定します。それぞれの NetworkAttachmentDefinition 内の CNI 設定は、インターフェイスの作成方法を定義します。
OpenShift Data Foundation は、macvlan と呼ばれる CNI プラグインを使用します。macvlan ベースの追加ネットワークを作成することで、ホスト上の Pod が物理ネットワークインターフェイスを使用して他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加ネットワークに割り当てられる各 Pod には固有の MAC アドレスが割り当てられます。
Multus のサポートはテクノロジープレビュー機能としてのみサポートされ、ベアメタルおよび VMWare デプロイメントでテストされます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
2.4.1. ネットワーク接続定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
Multus を使用するには、正しいネットワーク設定ですでに機能するクラスターが必要です。Recommended network configuration and requirements for a Multus configurationを参照してください。新規に作成された NetworkAttachmentDefinition (NAD) は、Storage Cluster のインストール時に選択できます。これは、Storage Cluster の前に作成する必要のある理由です。
Storage Cluster のインストール中に、新しく作成された NetworkAttachmentDefinition (NAD) を選択できます。これが、Storage Cluster を作成する前に NAD を作成する必要がある理由です。
プランニングガイドで説明されているように、作成する Multus ネットワークは、OpenShift Data Foundation トラフィックで利用可能なネットワークインターフェイスの数によって異なります。すべてのストレージトラフィックを 2 つのインターフェイス (デフォルトの OpenShift SDN に使用されるインターフェイス 1 つ) に分割するか、ストレージストレージトラフィック (パブリック) およびストレージレプリケーショントラフィック (プライベートまたはクラスター) にさらに分割することもできます。
以下は、同じインターフェイス上のすべてのストレージトラフィック (パブリックおよびクラスター) の NetworkAttachmentDefinition の例です。すべてのスケジュール可能なノードに 1 つの追加インターフェイスが必要です (別のネットワークインターフェイス上の OpenShift デフォルト SDN)。
すべてのネットワークインターフェイス名は、Multus ネットワークに接続されているすべてのノードで同じである必要があります (例: ocs-public-cluster の場合は ens2)。
以下は、個別の Multus ネットワーク上のストレージトラフィックの NetworkAttachmentDefinition の例になります。これは、クライアントストレージトラフィックのパブリックおよびレプリケーショントラフィック用のクラスターです。Object Storage Device (OSD) Pod をホストする OpenShift ノードに 2 つの追加インターフェイスと、他のスケジュール可能なすべてのノードで 1 つの追加インターフェイス (OpenShift デフォルト SDN) が必要です。
NetworkAttachmentDefinition の例:
すべてのネットワークインターフェイス名は、Multus ネットワークにアタッチされたすべてのノードで同じである必要があります (つまり、ocs-public の場合は ens2、ocs-clusterの場合は ens3 です)。
2.5. OpenShift Data Foundation クラスターの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Data Foundation Operator のインストール後に OpenShift Data Foundation クラスターを作成します。
前提条件
- OpenShift Data Foundation Operator が Operator Hub からインストールされている。詳細は、Installing OpenShift Data Foundation Operatorを参照してください。
-
VMware の仮想マシンでは、
disk.EnableUUIDオプションがTRUEに設定されていることを確認してください。仮想マシンを設定するには、vCenter アカウントの権限が必要です。詳細は、必要な vCenter アカウント権限 を参照してください。disk.EnableUUIDオプションを設定するには、Customize hardware タブの VM Options の Advanced オプションを使用します。詳細は、vSphere へのインストール を参照してください。 -
オプション: 柔軟性を高めるためにシックプロビジョニングのストレージを使用する場合は、
zeroedthickまたはeagerzeroedthickのディスク形式でストレージクラスを作成する必要があります。詳細は、VMware vSphere オブジェクトの定義 を参照してください。 - multus サポートのテクノロジープレビュー機能を使用する必要がある場合には、デプロイメントの前に、後でクラスターにアタッチされるネットワーク接続定義 (NAD) を作成する必要があります。詳細は、ネットワークアタッチメント定義の作成 を参照してください。
手順
OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
選択された Project が
openshift-storageであることを確認します。- OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
Backing storage ページで、以下を選択します。
- Deployment type オプションで Full Deployment を選択します。
- Use an existing StorageClass オプションを選択します。
Storage Class を選択します。
デフォルトでは
thinに設定されます。シックプロビジョニングのストレージ用に、zeroedthickまたはeagerzeroedthickディスクフォーマットでストレージクラスを作成した場合は、そのストレージクラスがデフォルトのthinストレージクラスに加えて表示されます。- Next をクリックします。
Capacity and nodes ページで、必要な情報を提供します。
ドロップダウンリストから Requested Capacity の値を選択します。デフォルトで、これは
2 TiBに設定されます。注記初期ストレージ容量を選択すると、クラスターの拡張は、選択された使用可能な容量を使用してのみ実行されます (raw ストレージの 3 倍)。
- Select Nodes セクションで、少なくとも 3 つの利用可能なノードを選択します。
オプション: 選択したノードを OpenShift Data Foundation 専用にする場合は、Taint nodes チェックボックスを選択します。
高可用性を確保するために、ワーカーノードは 3 つの異なる物理ノード、ラック、障害ドメインに分散します。
vCenter の非アフィニティーを使用して OpenShift Data Foundation のラックラベルをデータセンターの物理ノードおよびラックラベルに合わせて調整し、同じ物理シャーシに 2 つのワーカーノードがスケジュールされないようにします。
選択したノードが集約された 30 CPU および 72 GiB の RAM の OpenShift Data Foundation クラスターの要件と一致しない場合は、最小クラスターがデプロイされます。ノードの最小要件については、プランニングガイドの リソース要件 セクションを参照してください。
Taint nodes チェックボックスを選択して、選択したノードを OpenShift Data Foundation 専用にします。
- Next をクリックします。
オプション: Security and network ページで、要件に応じて以下を設定します。
- 暗号化を有効にするには、Enable data encryption for block and file storage を選択します。
暗号化レベルのいずれかまたは両方を選択します。
クラスター全体の暗号化
クラスター全体を暗号化します (ブロックおよびファイル)。
StorageClass の暗号化
暗号化対応のストレージクラスを使用して、暗号化された永続ボリューム (ブロックのみ) を作成します。
オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。
- Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。
Authentication Method を選択します。
- トークン認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
- Kubernetes 認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- 該当する場合は、TLS Server Name および Authentication Path を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。
- プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。
- Address: 123.34.3.2
- Port: 5696
- Client Certificate、CA certificate、および Client Private Key をアップロードします。
- StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
-
TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、
kmip_all_<port>.ciphertrustmanager.localなどです。
- Network を選択します。
単一のネットワークを使用する場合は Default (SDN) を選択し、複数のネットワークインターフェイスを使用する場合は Custom (Multus) ネットワークを選択します。
- ドロップダウンメニューから Public Network Interface を選択します。
ドロップダウンメニューから Cluster Network Interface を選択します。
注記追加のネットワークインターフェイスを 1 つだけ使用している場合は、単一の
NetworkAttachementDefinition(Public Network Interfaceにはocs-public-cluster) を選択し、Cluster Network Interfaceは空白のままにします。- Next をクリックします。
Review and create ページで、設定の詳細を確認します。
設定を変更するには、Back をクリックします。
- Create StorageSystem をクリックします。
検証手順
インストールされたストレージクラスターの最終ステータスを確認するには、以下を実行します。
- OpenShift Web コンソールで、Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources の順に移動します。
StorageClusterのStatusがReadyになっており、それの横に緑色のチェックマークが表示されていることを確認します。- OpenShift Data Foundation のすべてのコンポーネントが正常にインストールされていることを確認するには、Verifying your OpenShift Data Foundation deployment を参照してください。
- マルチネットワーク (Multus) を確認するには、Verifying the Multus networkingを参照してください。
関連情報
Overprovision Control アラートを有効にするには、モニタリングガイドの アラート を参照してください。
第3章 ローカルストレージデバイスを使用したデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ローカルストレージデバイスを使用して OpenShift Data Foundation を OpenShift Container Platform にデプロイすると、内部クラスターリソースを作成するオプションが提供されます。これにより、ベースサービスの内部プロビジョニングが可能になり、追加のストレージクラスをアプリケーションで使用できるようになります。
このセクションを使用して、OpenShift Container Platform がすでにインストールされている VMware インフラストラクチャーに OpenShift Data Foundation をインストールします。
また、OpenShift Data Foundation のデプロイの準備 の章にある要件に対応していることを確認してから、以下の手順に進んでください。
3.1. Local Storage Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
ローカルストレージデバイス上に Red Hat OpenShift Data Foundation クラスターを作成する前に、Operator Hub から Local Storage Operator をインストールします。
手順
- OpenShift Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
Filter by keyword ボックスに
local storageを入力し、Operator の一覧から Local Storage Operator を見つけ、これをクリックします。 Install Operator ページで、以下のオプションを設定します。
-
チャンネルを
4.12またはstableのいずれかにして更新します。 - Installation Mode オプションに A specific namespace on the cluster を選択します。
- Installed Namespace で Operator recommended namespace openshift-local-storage を選択します。
- 承認を Automatic として更新します。
-
チャンネルを
- Install をクリックします。
検証手順
- Local Storage Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
3.2. Red Hat OpenShift Data Foundation Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Data Foundation Operator は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。
前提条件
-
cluster-adminおよび operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - Red Hat OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。各ノードには 1 つのディスクが含まれ、3 つのディスク(PV)が必要です。ただし、1 つの PV はデフォルトで最終的に使用されません。これは想定される動作です。
- その他のリソース要件は、デプロイメントのプランニング ガイドを参照してください。
OpenShift Data Foundation のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、以下のコマンドを使用して、
openshift-storagenamespace の空のノードセレクターを指定できます (この場合はopenshift-storageを作成します)。oc annotate namespace openshift-storage openshift.io/node-selector=
$ oc annotate namespace openshift-storage openshift.io/node-selector=Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように
infraのテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当て ガイドの Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 を参照してください。
手順
- OpenShift Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
スクロールするか、
OpenShift Data Foundationを Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。 - Install をクリックします。
Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.12 として更新します。
- Installation Mode オプションで A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace
openshift-storageが存在しない場合は、Operator のインストール時に作成されます。 承認ストラテジーを Automatic または Manual として選択します。
Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- Console プラグイン に Enable オプションが選択されていることを確認します。
- Install をクリックします。
検証手順
-
Operator が正常にインストールされると、
Web console update is availableメッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。 Web コンソールに移動します。
- Installed Operators に移動し、OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
- Storage に移動し、Data Foundation ダッシュボードが使用可能かどうかを確認します。
3.3. Multus ネットワークの作成 [テクノロジープレビュー] リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、Multus CNI プラグインを使用して CNI プラグインのチェーンを許可します。クラスターのインストール中にデフォルトの Pod ネットワークを設定できます。デフォルトのネットワークは、クラスターの通常のネットワークトラフィックをすべて処理します。
利用可能な CNI プラグインに基づいて追加のネットワークを定義し、1 つまたは複数のネットワークを Pod に割り当てることができます。追加のネットワークを Pod に割り当てるには、インターフェイスの割り当て方法を定義する設定を作成する必要があります。
NetworkAttachmentDefinition (NAD) カスタムリソース (CR) を使用して、各インターフェイスを指定します。それぞれの NetworkAttachmentDefinition 内の CNI 設定は、インターフェイスの作成方法を定義します。
OpenShift Data Foundation は、macvlan と呼ばれる CNI プラグインを使用します。macvlan ベースの追加ネットワークを作成することで、ホスト上の Pod が物理ネットワークインターフェイスを使用して他のホストやそれらのホストの Pod と通信できます。macvlan ベースの追加ネットワークに割り当てられる各 Pod には固有の MAC アドレスが割り当てられます。
Multus のサポートはテクノロジープレビュー機能としてのみサポートされ、ベアメタルおよび VMWare デプロイメントでテストされます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.3.1. ネットワーク接続定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
Multus を使用するには、正しいネットワーク設定ですでに機能するクラスターが必要です。Recommended network configuration and requirements for a Multus configurationを参照してください。新規に作成された NetworkAttachmentDefinition (NAD) は、Storage Cluster のインストール時に選択できます。これは、Storage Cluster の前に作成する必要のある理由です。
Storage Cluster のインストール中に、新しく作成された NetworkAttachmentDefinition (NAD) を選択できます。これが、Storage Cluster を作成する前に NAD を作成する必要がある理由です。
プランニングガイドで説明されているように、作成する Multus ネットワークは、OpenShift Data Foundation トラフィックで利用可能なネットワークインターフェイスの数によって異なります。すべてのストレージトラフィックを 2 つのインターフェイス (デフォルトの OpenShift SDN に使用されるインターフェイス 1 つ) に分割するか、ストレージストレージトラフィック (パブリック) およびストレージレプリケーショントラフィック (プライベートまたはクラスター) にさらに分割することもできます。
以下は、同じインターフェイス上のすべてのストレージトラフィック (パブリックおよびクラスター) の NetworkAttachmentDefinition の例です。すべてのスケジュール可能なノードに 1 つの追加インターフェイスが必要です (別のネットワークインターフェイス上の OpenShift デフォルト SDN)。
すべてのネットワークインターフェイス名は、Multus ネットワークに接続されているすべてのノードで同じである必要があります (例: ocs-public-cluster の場合は ens2)。
以下は、個別の Multus ネットワーク上のストレージトラフィックの NetworkAttachmentDefinition の例になります。これは、クライアントストレージトラフィックのパブリックおよびレプリケーショントラフィック用のクラスターです。Object Storage Device (OSD) Pod をホストする OpenShift ノードに 2 つの追加インターフェイスと、他のスケジュール可能なすべてのノードで 1 つの追加インターフェイス (OpenShift デフォルト SDN) が必要です。
NetworkAttachmentDefinition の例:
すべてのネットワークインターフェイス名は、Multus ネットワークにアタッチされたすべてのノードで同じである必要があります (つまり、ocs-public の場合は ens2、ocs-clusterの場合は ens3 です)。
3.4. VMware vSphere での OpenShift Data Foundation クラスターの作成 リンクのコピーリンクがクリップボードにコピーされました!
VMware vSphere は、以下の 3 つのタイプのローカルストレージをサポートします。
- 仮想マシンディスク (VMDK)
- raw デバイスマッピング (RDM)
- VMDirectPath I/O
前提条件
- ローカルストレージデバイスを使用して OpenShift Data Foundation をインストールするための要件 セクションにあるすべての要件を満たしていることを確認します。
- VMware でローカルストレージデバイスを使用するために、各ノードに同じストレージタイプおよびサイズが割り当てられたワーカーノードが最低でも 3 つある。
-
VMware vSphere の仮想マシンでは、
disk.EnableUUIDオプションがTRUEに設定されている。仮想マシンを設定するには、vCenter アカウントの権限が必要です。詳細は、必要な vCenter アカウント権限 を参照してください。disk.EnableUUIDオプションを設定するには、Customize hardware タブで VM Options の Advanced オプションを使用します。詳細は、vSphere へのインストール を参照してください。 - multus サポートのテクノロジープレビュー機能を使用する必要がある場合には、デプロイメントの前に、後でクラスターにアタッチされるネットワーク接続定義 (NAD) を作成する必要があります。詳細は、マルチネットワークプラグイン (Multus) のサポート および ネットワーク接続定義の作成 を参照してください。
手順
OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
選択された Project が
openshift-storageであることを確認します。- OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
Backing storage ページで、以下を実行します。
- Deployment type オプションで Full Deployment を選択します。
- Create a new StorageClass using the local storage devices オプションを選択します。
Next をクリックします。
注記Local Storage Operator がまだインストールされていない場合は、インストールするように求められます。Install をクリックし、ローカルストレージ Operator のインストール で説明されているように手順に従います。
Create local volume set ページで、以下の情報を提供します。
LocalVolumeSet および StorageClass の名前を入力します。
デフォルトでは、ストレージクラス名としてローカルボリュームセット名が表示されます。名前を変更できます。
以下のいずれかを選択します。
- Disks on all nodes: すべてのノードにある選択したフィルターに一致する利用可能なディスクを使用します。
Disks on selected nodes: 選択したノードにある選択したフィルターに一致する利用可能なディスクを使用します。
重要フレキシブルスケーリング機能は、3 つ以上のノードで作成したストレージクラスターが 3 つ以上のアベイラビリティーゾーンの最低要件未満に分散されている場合にのみ有効になります。
フレキシブルスケーリングの詳細は、フレキシブルスケーリングが有効な場合に YAML を使用した OpenShift Data Foundation クラスターのスケーリング に関する ナレッジベースの記事 を参照してください。
- フレキシブルスケーリング機能はデプロイ時に有効になり、後で有効または無効にすることはできません。
選択したノードが集約された 30 CPU および 72 GiB の RAM の OpenShift Data Foundation クラスターの要件と一致しない場合は、最小クラスターがデプロイされます。
ノードの最小要件については、プランニングガイドの リソース要件 セクションを参照してください。
-
Disk Type の利用可能なリストから、
SSD/NVMeを選択します。 Advanced セクションを拡張し、以下のオプションを設定します。
ボリュームモード
デフォルトではブロックが選択されます。
デバイスタイプ
ドロップダウンリストから 1 つ以上のデバイスタイプを選択します。
ディスクサイズ
デバイスの最小サイズ 100GB と、含める必要のあるデバイスの最大サイズを設定します。
ディスクの最大数の制限
これは、ノードで作成できる PV の最大数を示します。このフィールドが空のままの場合、PV は一致するノードで利用可能なすべてのディスクに作成されます。
Next をクリックします。
LocalVolumeSet の作成を確認するポップアップが表示されます。
- Yes をクリックして続行します。
Capacity and nodes ページで、以下を設定します。
- Available raw capacity には、ストレージクラスに関連付けられた割り当てられたすべてのディスクに基づいて容量の値が設定されます。これには少し時間がかかります。Selected nodes リストには、ストレージクラスに基づくノードが表示されます。
- オプション: 選択したノードを OpenShift Data Foundation 専用にする場合は、Taint nodes チェックボックスを選択します。
- Next をクリックします。
オプション: Security and network ページで、要件に応じて以下を設定します。
- 暗号化を有効にするには、Enable data encryption for block and file storage を選択します。
以下の Encryption level (暗号化レベル) のいずれかを選択します。
- Cluster-wide encryption: クラスター全体 (ブロックおよびファイル) を暗号化します。
- StorageClass encryption: 暗号化対応のストレージクラスを使用して暗号化された永続ボリューム (ブロックのみ) を作成します。
オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。
- Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。
Authentication Method を選択します。
- トークン認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
- Kubernetes 認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- 該当する場合は、TLS Server Name および Authentication Path を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。
- プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。
- Address: 123.34.3.2
- Port: 5696
- Client Certificate、CA certificate、および Client Private Key をアップロードします。
- StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
-
TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、
kmip_all_<port>.ciphertrustmanager.localなどです。
- Network を選択します。
以下のいずれかを選択します。
- 単一のネットワークを使用している場合は、Default (SDN) を選択します。
複数のネットワークインターフェイスを使用している場合は、Custom (Multus) を選択します。
- ドロップダウンメニューから Public Network Interface を選択します。
ドロップダウンメニューから Cluster Network Interface を選択します。
注記追加のネットワークインターフェイスを 1 つだけ使用している場合は、単一の
NetworkAttachementDefinition(Public Network Interface にはocs-public-cluster) を選択し、Cluster Network Interface は空白のままにします。
- Next をクリックします。
Review and create ページで、設定の詳細を確認します。
- 設定を変更するには、Back をクリックして前の設定ページに戻ります。
- Create StorageSystem をクリックします。
検証手順
インストールされたストレージクラスターの最終ステータスを確認するには、以下を実行します。
- OpenShift Web コンソールで、Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources の順に移動します。
-
StorageClusterのStatusがReadyになっており、それの横に緑色のチェックマークが表示されていることを確認します。
フレキシブルスケーリングがストレージクラスターで有効にされているかどうかを確認するには、以下の手順を実行します (arbiter モードの場合、フレキシブルスケーリングが無効になります)。
- OpenShift Web コンソールで、Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources の順に移動します。
YAML タブで、
specセクションのキーflexibleScalingとstatusセクションのflexibleScalingを検索します。flexible scalingが true であり、failureDomainが host に設定されている場合、フレキシブルスケーリング機能が有効になります。spec: flexibleScaling: true […] status: failureDomain: host
spec: flexibleScaling: true […] status: failureDomain: hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- OpenShift Data Foundation のすべてのコンポーネントが正常にインストールされていることを確認するには、Verifying your OpenShift Data Foundation deployment を参照してください。
- マルチネットワーク (Multus) を確認するには、Verifying the Multus networkingを参照してください。
関連情報
- 初期クラスターの容量を拡張するには、ストレージのスケーリング ガイドを参照してください。
第4章 OpenShift Data Foundation デプロイメントの確認 リンクのコピーリンクがクリップボードにコピーされました!
このセクションを使用して、OpenShift Data Foundation が正しくデプロイされていることを確認します。
4.1. Pod の状態の確認 リンクのコピーリンクがクリップボードにコピーされました!
手順
- OpenShift Web コンソールから Workloads → Pods をクリックします。
Project ドロップダウンリストから
openshift-storageを選択します。注記Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトをリスト表示します。
コンポーネントごとに想定される Pod 数や、ノード数に合わせてこの数値がどのように変化するかなどの詳細は、表4.1「OpenShift Data Foundation クラスターに対応する Pod」 を参照してください。
実行中および完了した Pod のフィルターを設定して、次の Pod が
RunningおよびCompleted状態であることを確認します。Expand 表4.1 OpenShift Data Foundation クラスターに対応する Pod コンポーネント 対応する Pod OpenShift Data Foundation Operator
-
ocs-operator-*(任意のストレージノードに 1 Pod) -
ocs-metrics-exporter-*(任意のストレージノードに 1 Pod) -
odf-operator-controller-manager-*(任意のストレージノードに 1 Pod) -
odf-console-*(任意のストレージノードに 1 Pod) -
csi-addons-controller-manager-*(任意のストレージノードに 1 Pod)
Rook-ceph Operator
rook-ceph-operator-*(任意のストレージノードに 1 Pod)
Multicloud Object Gateway
-
noobaa-operator-*(任意のストレージノードに 1 Pod) -
noobaa-core-*(任意のストレージノードに 1 Pod) -
noobaa-db-pg-*(任意のストレージノードに 1 Pod) -
noobaa-endpoint-*(任意のストレージノードに 1 Pod)
MON
rook-ceph-mon-*(ストレージノードに分散する 3 Pod)
MGR
rook-ceph-mgr-*(任意のストレージノードに 1 Pod)
MDS
rook-ceph-mds-ocs-storagecluster-cephfilesystem-*(ストレージノードに分散する 2 Pod)
RGW
rook-ceph-rgw-ocs-storagecluster-cephobjectstore-*(任意のストレージノードに 1 Pod)CSI
cephfs-
csi-cephfsplugin-*(各ストレージノードに 1 Pod) -
csi-cephfsplugin-provisioner-*(ストレージノードに分散する 2 Pod)
-
rbd-
csi-rbdplugin-*(各ストレージノードに 1 Pod) -
csi-rbdplugin-provisioner-*(ストレージノードに分散する 2 Pod)
-
rook-ceph-crashcollector
rook-ceph-crashcollector-*(各ストレージノードに 1 Pod)
OSD
-
rook-ceph-osd-*(各デバイス用に 1 Pod) -
rook-ceph-osd-prepare-ocs-deviceset-*(各デバイス用に 1 Pod)
-
4.2. OpenShift Data Foundation クラスターが正常であることを確認 リンクのコピーリンクがクリップボードにコピーされました!
手順
- OpenShift Web コンソールで、Storage → Data Foundation をクリックします。
- Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Block and File タブの Status カードで、Storage Cluster に緑色のチェックマークが表示されていることを確認します。
- Details カードで、クラスター情報が表示されていることを確認します。
ブロックおよびファイルダッシュボードを使用した OpenShift Data Foundation クラスターの正常性については、Monitoring OpenShift Data Foundationを参照してください。
4.3. Multicloud Object Gateway が正常であることを確認 リンクのコピーリンクがクリップボードにコピーされました!
手順
- OpenShift Web コンソールで、Storage → Data Foundation をクリックします。
Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Object タブの Status card で、Object Service と Data Resiliency の両方に緑色のチェックマークが表示されていることを確認します。
- Details カードで、MCG 情報が表示されることを確認します。
ブロックおよびファイルダッシュボードを使用した OpenShift Data Foundation クラスターの正常性は、OpenShift Data Foundation の監視 を参照してください。
Multicloud Object Gateway には、データベースのコピー (NooBaa DB) が 1 つだけあります。つまり、NooBaa DB PVC が破損し、回復できない場合は、Multicloud Object Gateway に存在するアプリケーションデータが完全に失われる可能性があります。このため、Red Hat では NooBaa DB PVC のバックアップを定期的に取ることを推奨しています。NooBaa DB に障害が発生して回復できない場合は、最新のバックアップバージョンに戻すことができます。NooBaa DB をバックアップする手順は、こちらのナレッジベースの記事 の手順に従ってください。
4.4. 特定のストレージクラスが存在することを確認 リンクのコピーリンクがクリップボードにコピーされました!
手順
- OpenShift Web コンソールの左側のペインから Storage → Storage Classes をクリックします。
以下のストレージクラスが OpenShift Data Foundation クラスターの作成時に作成されることを確認します。
-
ocs-storagecluster-ceph-rbd -
ocs-storagecluster-cephfs -
openshift-storage.noobaa.io -
ocs-storagecluster-ceph-rgw
-
4.5. Multus ネットワークの確認 リンクのコピーリンクがクリップボードにコピーされました!
Multus がクラスターで機能しているかどうかを判別するには、Multus ネットワークを確認します。
手順
ネットワーク設定の選択に応じて、OpenShift Data Foundation Operator は以下の 1 つを行います。
-
単一の NetworkAttachmentDefinition (例:
ocs-public-cluster) のみが Public Network Interface に対して選択される場合、アプリケーション Pod と OpenShift Data Foundation クラスター間のトラフィックはこのネットワークで生じます。さらに、クラスターは、このネットワークを OSD 間のレプリケーションに使用し、OSD 間のトラフィックを再リバランスするように自己設定します。 -
NetworkAttachmentDefinitions (例:
ocs-publicおよびocs-cluster) が Public Network Interface にそれぞれ選択されており、Storage Cluster のインストール時に Cluster Network Interface にそれぞれ選択される場合、クライアントストレージトラフィックは OSD 間でのレプリケーションおよびクラスターネットワークのパブリックネットワークおよびクラスターネットワークに置かれます。
ネットワーク設定が正しいことを確認するには、以下の手順を実施します。
OpenShift コンソールで、Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources → ocs-storagecluster の順に移動します。
YAML タブで、spec セクションで network を検索し、設定がネットワークインターフェイスの選択に適したことを確認します。この例では、クライアントストレージトラフィックをストレージレプリケーショントラフィックから分離するためのものです。
出力サンプル
コマンドラインインターフェイスを使用してネットワーク設定が正しいことを確認するには、以下のコマンドを実行します。
oc get storagecluster ocs-storagecluster \
-n openshift-storage \
-o=jsonpath='{.spec.network}{"\n"}'
$ oc get storagecluster ocs-storagecluster \
-n openshift-storage \
-o=jsonpath='{.spec.network}{"\n"}'
出力サンプル
{"ipFamily":"IPv4","provider":"multus","selectors":{"cluster":"openshift-storage/ocs-cluster","public":"openshift-storage/ocs-public"}}
{"ipFamily":"IPv4","provider":"multus","selectors":{"cluster":"openshift-storage/ocs-cluster","public":"openshift-storage/ocs-public"}}
OSD Pod が正しいネットワークを使用していることの確認
openshift-storage namespace は OSD Pod の 1 つを使用して、Pod が正しいネットワークに接続されていることを確認します。この例では、クライアントストレージトラフィックをストレージレプリケーショントラフィックから分離するためのものです。
両方が作成されると、OSD Pod のみが Multus パブリックおよびクラスターネットワークの両方に接続します。他のすべての OCS Pod は Multus パブリックネットワークに接続されます。
oc get -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-osd | grep 'osd-0') -o=jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}{"\n"}'
$ oc get -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-osd | grep 'osd-0') -o=jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}{"\n"}'
出力サンプル
コマンドラインインターフェイスを使用して OSD Pod が正しいネットワークを使用していることを確認するには、以下のコマンドを実行します (jq ユーティリティーが必要です)。
oc get -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-osd | grep 'osd-0') -o=jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}{"\n"}' | jq -r '.[].name'
$ oc get -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-osd | grep 'osd-0') -o=jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}{"\n"}' | jq -r '.[].name'
出力サンプル
openshift-sdn openshift-storage/ocs-cluster openshift-storage/ocs-public
openshift-sdn
openshift-storage/ocs-cluster
openshift-storage/ocs-public
第5章 スタンドアロンの Multicloud Object Gateway のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Data Foundation で Multicloud Object Gateway コンポーネントのみをデプロイすると、デプロイメントで柔軟性が高まり、リソース消費を減らすことができます。Multicloud Object Gateway コンポーネントは、動的ストレージデバイスを使用するか、ローカルストレージデバイスを使用してデプロイできます。
5.1. 動的ストレージデバイスを使用したスタンドアロン Multicloud Object Gateway のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
このセクションには、次の手順が含まれており、スタンドアロンの Multicloud Object Gateway コンポーネントのみをデプロイする場合に使用します。
- Red Hat OpenShift Data Foundation Operator のインストール
- スタンドアロンの Multicloud Object Gateway の作成
5.1.1. Red Hat OpenShift Data Foundation Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Data Foundation Operator は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。
前提条件
-
cluster-adminおよび operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - Red Hat OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。各ノードには 1 つのディスクが含まれ、3 つのディスク(PV)が必要です。ただし、1 つの PV はデフォルトで最終的に使用されません。これは想定される動作です。
- その他のリソース要件は、デプロイメントのプランニング ガイドを参照してください。
OpenShift Data Foundation のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、以下のコマンドを使用して、
openshift-storagenamespace の空のノードセレクターを指定できます (この場合はopenshift-storageを作成します)。oc annotate namespace openshift-storage openshift.io/node-selector=
$ oc annotate namespace openshift-storage openshift.io/node-selector=Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように
infraのテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当て ガイドの Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 を参照してください。
手順
- OpenShift Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
スクロールするか、
OpenShift Data Foundationを Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。 - Install をクリックします。
Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.12 として更新します。
- Installation Mode オプションで A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace
openshift-storageが存在しない場合は、Operator のインストール時に作成されます。 承認ストラテジーを Automatic または Manual として選択します。
Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- Console プラグイン に Enable オプションが選択されていることを確認します。
- Install をクリックします。
検証手順
-
Operator が正常にインストールされると、
Web console update is availableメッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。 Web コンソールに移動します。
- Installed Operators に移動し、OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
- Storage に移動し、Data Foundation ダッシュボードが使用可能かどうかを確認します。
5.1.2. スタンドアロンの Multicloud Object Gateway の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Data Foundation のデプロイ中には、スタンドアロンの Multicloud Object Gateway コンポーネントのみを作成できます。
前提条件
- OpenShift Data Foundation Operator がインストールされている。
手順
OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
選択された Project が
openshift-storageであることを確認します。- OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
Backing storage ページで、以下を選択します。
- Deployment type の Multicloud Object Gateway を選択します。
- Use an existing StorageClass オプションを選択します。
- Next をクリックします。
オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。
- Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。
Authentication Method を選択します。
- トークン認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
- Kubernetes 認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- 該当する場合は、TLS Server Name および Authentication Path を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。
- プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。
- Address: 123.34.3.2
- Port: 5696
- Client Certificate、CA certificate、および Client Private Key をアップロードします。
- StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
-
TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、
kmip_all_<port>.ciphertrustmanager.localなどです。
- Network を選択します。
- Next をクリックします。
Review and create ページで、設定の詳細を確認します。
設定を変更するには、Back をクリックします。
- Create StorageSystem をクリックします。
検証手順
- OpenShift Data Foundation クラスターが正常であることの確認
- OpenShift Web コンソールで、Storage → Data Foundation をクリックします。
Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Object タブの Status card で、Object Service と Data Resiliency の両方に緑色のチェックマークが表示されていることを確認します。
- Details カードで、MCG 情報が表示されることを確認します。
- Pod の状態の確認
- OpenShift Web コンソールから Workloads → Pods をクリックします。
Project ドロップダウンリストから
openshift-storageを選択し、以下の Pod がRunning状態にあることを確認します。注記Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトをリスト表示します。
Expand コンポーネント 対応する Pod OpenShift Data Foundation Operator
-
ocs-operator-*(任意のストレージノードに 1 Pod) -
ocs-metrics-exporter-*(任意のストレージノードに 1 Pod) -
odf-operator-controller-manager-*(任意のストレージノードに 1 Pod) -
odf-console-*(任意のストレージノードに 1 Pod) -
csi-addons-controller-manager-*(任意のストレージノードに 1 Pod)
Rook-ceph Operator
rook-ceph-operator-*(任意のストレージノードに 1 Pod)
Multicloud Object Gateway
-
noobaa-operator-*(任意のストレージノードに 1 Pod) -
noobaa-core-*(任意のストレージノードに 1 Pod) -
noobaa-db-pg-*(任意のストレージノードに 1 Pod) -
noobaa-endpoint-*(任意のストレージノードに 1 Pod)
-
5.2. ローカルストレージデバイスを使用したスタンドアロン Multicloud Object Gateway のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
このセクションには、次の手順が含まれており、スタンドアロンの Multicloud Object Gateway コンポーネントのみをデプロイする場合に使用します。
- Local Storage Operator のインストール
- Red Hat OpenShift Data Foundation Operator のインストール
- スタンドアロンの Multicloud Object Gateway の作成
5.2.1. Local Storage Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
ローカルストレージデバイス上に Red Hat OpenShift Data Foundation クラスターを作成する前に、Operator Hub から Local Storage Operator をインストールします。
手順
- OpenShift Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
Filter by keyword ボックスに
local storageを入力し、Operator の一覧から Local Storage Operator を見つけ、これをクリックします。 Install Operator ページで、以下のオプションを設定します。
-
チャンネルを
4.12またはstableのいずれかにして更新します。 - Installation Mode オプションに A specific namespace on the cluster を選択します。
- Installed Namespace で Operator recommended namespace openshift-local-storage を選択します。
- 承認を Automatic として更新します。
-
チャンネルを
- Install をクリックします。
検証手順
- Local Storage Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
5.2.2. Red Hat OpenShift Data Foundation Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Data Foundation Operator は、Red Hat OpenShift Container Platform Operator Hub を使用してインストールできます。
前提条件
-
cluster-adminおよび operator インストールのパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - Red Hat OpenShift Container Platform クラスターにワーカーノードが少なくとも 3 つある。各ノードには 1 つのディスクが含まれ、3 つのディスク(PV)が必要です。ただし、1 つの PV はデフォルトで最終的に使用されません。これは想定される動作です。
- その他のリソース要件は、デプロイメントのプランニング ガイドを参照してください。
OpenShift Data Foundation のクラスター全体でのデフォルトノードセレクターを上書きする必要がある場合は、以下のコマンドを使用して、
openshift-storagenamespace の空のノードセレクターを指定できます (この場合はopenshift-storageを作成します)。oc annotate namespace openshift-storage openshift.io/node-selector=
$ oc annotate namespace openshift-storage openshift.io/node-selector=Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ノードに Red Hat OpenShift Data Foundation リソースのみがスケジュールされるように
infraのテイントを設定します。これにより、サブスクリプションコストを節約できます。詳細は、ストレージリソースの管理および割り当て ガイドの Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 を参照してください。
手順
- OpenShift Web コンソールにログインします。
- Operators → OperatorHub をクリックします。
-
スクロールするか、
OpenShift Data Foundationを Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。 - Install をクリックします。
Install Operator ページで、以下のオプションを設定します。
- Channel を stable-4.12 として更新します。
- Installation Mode オプションで A specific namespace on the cluster を選択します。
-
Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace
openshift-storageが存在しない場合は、Operator のインストール時に作成されます。 承認ストラテジーを Automatic または Manual として選択します。
Automatic (自動) 更新を選択すると、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
Manual 更新を選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。
- Console プラグイン に Enable オプションが選択されていることを確認します。
- Install をクリックします。
検証手順
-
Operator が正常にインストールされると、
Web console update is availableメッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。 Web コンソールに移動します。
- Installed Operators に移動し、OpenShift Data Foundation Operator に、インストールが正常に実行されたことを示す緑色のチェックマークが表示されていることを確認します。
- Storage に移動し、Data Foundation ダッシュボードが使用可能かどうかを確認します。
5.2.3. スタンドアロンの Multicloud Object Gateway の作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Data Foundation のデプロイ中には、スタンドアロンの Multicloud Object Gateway コンポーネントのみを作成できます。
前提条件
- OpenShift Data Foundation Operator がインストールされている。
手順
OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
選択された Project が
openshift-storageであることを確認します。- OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
Backing storage ページで、以下を選択します。
- Deployment type の Multicloud Object Gateway を選択します。
- Create a new StorageClass using the local storage devices オプションを選択します。
Next をクリックします。
注記Local Storage Operator がまだインストールされていない場合は、インストールするように求められます。Install をクリックし、ローカルストレージ Operator のインストールで説明されているように手順に従います。
Create local volume set ページで、以下の情報を提供します。
LocalVolumeSet および StorageClass の名前を入力します。
デフォルトでは、ストレージクラス名としてローカルボリュームセット名が表示されます。名前を変更できます。
以下のいずれかを選択します。
Disks on all nodes
すべてのノードにある選択したフィルターに一致する利用可能なディスクを使用します。
Disks on selected nodes
選択したノードにある選択したフィルターにのみ一致する利用可能なディスクを使用します。
-
Disk Type の利用可能なリストから、
SSD/NVMeを選択します。 Advanced セクションを拡張し、以下のオプションを設定します。
ボリュームモード
デフォルトではファイルシステムが選択されています。Volume Mode でファイルシステムが選択されていることを常に確認してください。
デバイスタイプ
ドロップダウンリストから 1 つ以上のデバイスタイプを選択します。
ディスクサイズ
デバイスの最小サイズ 100GB と、含める必要のあるデバイスの最大サイズを設定します。
ディスクの最大数の制限
これは、ノードで作成できる PV の最大数を示します。このフィールドが空のままの場合、PV は一致するノードで利用可能なすべてのディスクに作成されます。
Next をクリックします。
LocalVolumeSet の作成を確認するポップアップが表示されます。
- Yes をクリックして続行します。
Capacity and nodes ページで、以下を設定します。
- Available raw capacity には、ストレージクラスに関連付けられた割り当てられたすべてのディスクに基づいて容量の値が設定されます。これには少し時間がかかります。Selected nodes リストには、ストレージクラスに基づくノードが表示されます。
- Next をクリックします。
オプション: Connect to an external key management service チェックボックスを選択します。これはクラスター全体の暗号化の場合はオプションになります。
- Key Management Service Provider ドロップダウンリストから、Vault または Thales CipherTrust Manager (using KMIP) を選択します。Vault を選択した場合は、次の手順に進みます。Thales CipherTrust Manager (using KMIP) を選択した場合は、手順 iii に進みます。
Authentication Method を選択します。
- トークン認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
- Kubernetes 認証方式の使用
- Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号、および Role 名を入力します。
Advanced Settings をデプロイメントして、
Vault設定に基づいて追加の設定および証明書の詳細を入力します。- OpenShift Data Foundation 専用かつ特有のキーと値のシークレットパスを Backend Path に入力します。
- 該当する場合は、TLS Server Name および Authentication Path を入力します。
- PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA Certificate、Client Certificate、および Client Private Key を指定します。
- Save をクリックして、手順 iv に進みます。
Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。
- プロジェクト内のキー管理サービスの一意の Connection Name を入力します。
Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。
- Address: 123.34.3.2
- Port: 5696
- Client Certificate、CA certificate、および Client Private Key をアップロードします。
- StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
-
TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、
kmip_all_<port>.ciphertrustmanager.localなどです。
- Network を選択します。
- Next をクリックします。
Review and create ページで、設定の詳細を確認します。
設定を変更するには、Back をクリックします。
- Create StorageSystem をクリックします。
検証手順
- OpenShift Data Foundation クラスターが正常であることの確認
- OpenShift Web コンソールで、Storage → Data Foundation をクリックします。
Overview タブの Status カードで Storage System をクリックし、表示されたポップアップからストレージシステムリンクをクリックします。
- Object タブの Status card で、Object Service と Data Resiliency の両方に緑色のチェックマークが表示されていることを確認します。
- Details カードで、MCG 情報が表示されることを確認します。
- Pod の状態の確認
- OpenShift Web コンソールから Workloads → Pods をクリックします。
Project ドロップダウンリストから
openshift-storageを選択し、以下の Pod がRunning状態にあることを確認します。注記Show default projects オプションが無効になっている場合は、切り替えボタンを使用して、すべてのデフォルトプロジェクトをリスト表示します。
Expand コンポーネント 対応する Pod OpenShift Data Foundation Operator
-
ocs-operator-*(任意のストレージノードに 1 Pod) -
ocs-metrics-exporter-*(任意のストレージノードに 1 Pod) -
odf-operator-controller-manager-*(任意のストレージノードに 1 Pod) -
odf-console-*(任意のストレージノードに 1 Pod) -
csi-addons-controller-manager-*(任意のストレージノードに 1 Pod)
Rook-ceph Operator
rook-ceph-operator-*(任意のストレージノードに 1 Pod)
Multicloud Object Gateway
-
noobaa-operator-*(任意のストレージノードに 1 Pod) -
noobaa-core-*(任意のストレージノードに 1 Pod) -
noobaa-db-pg-*(任意のストレージノードに 1 Pod) -
noobaa-endpoint-*(任意のストレージノードに 1 Pod)
-
第6章 OpenShift Data Foundation のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
6.1. 内部モードでの OpenShift Data Foundation のアンインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Data Foundation を内部モードでアンインストールするには、Uninstalling OpenShift Data Foundation のナレッジベース記事を参照してください。