クラスターへの Portworx のインストール

IBM Cloud カタログから、Portworx サービス・インスタンスをプロビジョンします。サービス・インスタンスを作成すると、最新の Portworx Enterprise Edition (px-enterprise) が、Helm を使用してクラスターにインストールされます。さらに、 Stork も Red Hat OpenShift on IBM Cloud クラスターにインストールされています。 Stork とは Portworx ストレージのスケジューラーです。 Storkを使用すると、ポッドをそのデータとコロケーションでき、 Portworx ボリュームのスナップショットを作成および復元できます。

Portworx の更新方法と削除方法については、「 Portworx の更新」および「Portworx の削除」を参照してください。

モントリオールリージョンにおけるプライベート専用クラスターでは、 Portworx Enterprise および Portworx バックアップのデフォルトインストール方法は、現時点ではサポートされていません。モントリオールのプライベート専用クラスターに Portworx Enterprise または Portworx バックアップを導入する必要がある場合は、 Portworx サポートまでご連絡ください。詳細については、 Portworx サポートをご覧ください

始める前に

Red Hat OpenShift on IBM Cloud クラスターを作成するための正しい許可があることを確認します。
クラスターを作成するか、既存のクラスターを使用します。
クラシック・クラスター内で非 SDS ワーカー・ノードを使用する場合は、ワーカー・ノードにブロック・ストレージ・デバイスを追加します。
Portworx の構成とメタデータの保管に、内部 Portworx キー/値データベース (KVDB) を使用するか、それとも Databases for etcd サービス・インスタンスを作成するかを選択します。
Portworx ボリュームを暗号化するかどうかを決定します。ボリュームを暗号化するには、IBM Key Protect インスタンスまたは Hyper Protect Crypto Services インスタンスをセットアップして、サービス情報を Kubernetes シークレットに保管する必要があります。
default から kube-system プロジェクトにイメージ・プル・シークレットをコピーして、Container Registry からイメージをプルできるようにします。プロジェクトの Kubernetes サービス・アカウントにイメージ・プル・シークレットを追加しますkube-system。
クラスターを Portworx 災害復旧構成に含めるかどうかを決定します。詳しくは、Portworx を使用した災害復旧のセットアップを参照してください。
Portworx ジャーナル用に別のデバイスを接続した場合は、ワーカー・ノードにログインしているときにlsblkを実行してデバイス・パスを取得するようにしてください。
Portworx KVDB 用に別個のデバイスを接続した場合は、ワーカー・ノードにログインしているときにlsblkを実行してデバイス・パスを取得するようにしてください。
Red Hat OpenShift クラスターにアクセスします。

Portworx をインストールするには、次のようにします。

「IBM Cloud 」カタログから「 Portworx 」サービスを開き、以下の通りフィールドを完了してください：
1. Red Hat OpenShift on IBM Cloud クラスターが配置されているリージョンを選択します。
2. Portworx の料金情報を確認します。
3. Portworx サービス・インスタンスの名前を入力します。
4. クラスターが含まれるリソース・グループを選択します。
5. **「タグ (Tag)」**フィールドに、Portworx をインストールするクラスターの名前を入力します。 Portworxサービス・インスタンスを作成した後、Portworxをインストールしたクラスターを見ることはできません。後でクラスターを見つけやすくするために、クラスターの名前と追加情報をタグとして入力してください。
6. IBM Cloud の API キーを入力して、アクセス可能なクラスターのリストを取得します。 API キーがない場合は、ユーザー API キーの管理を参照してください。 API キーを入力すると、**「Kubernetes または OpenShift クラスター名 (Kubernetes or OpenShift cluster name)」**フィールドが表示されます。
7. 固有の Portworx クラスター名を入力します。
8. **「クラウド・ドライブ」**メニューで、以下のようにします。
  1. Portworx 用に Block Storage for VPC を動的にプロビジョンするには、「クラウド・ドライブの使用」(VPC クラスターのみ) を選択します。 **「クラウド・ドライブの使用」を選択した後、プロビジョンするブロック・ストレージ・ドライブの「ストレージ・クラス名」と「サイズ」**を選択します。
  2. ワーカー・ノードに既に接続されているブロック・ストレージを使用するには、「既に接続されているドライブの使用」(クラシック、VPC、または Satellite) を選択します。
9. **「Portworx メタデータのキー/値ストア (Portworx metadata key-value store)」ドロップダウンから、Portworx メタデータを保管するために使用するキー/値ストアのタイプを選択します。 Portworx インストール時に自動的にキー/値ストアを作成するには「Portworx KVDB」を選択し、既存の Databases for etcd インスタンスを使用する場合は「Databases for etcd」**を選択します。 **「Databases for etcd」を選択すると、「Etcd API エンドポイント (Etcd API endpoints)」フィールドおよび「Etcd シークレット名 (Etcd secret name)」**フィールドが表示されます。
10. 名前空間: Portworx リソースをデプロイする名前空間を入力します。
11. Databases for etcd を使用する場合のみ必須: Databases for etcd サービス・インスタンスの情報を入力します。
  1. etcd エンドポイント、および Databases for etcd サービス・インスタンス用に作成した Kubernetes シークレットの名前を取得します。
  2. **「Etcd API エンドポイント (Etcd API endpoints)」**フィールドに、前の手順で取得した Databases for etcd サービス・インスタンスの API エンドポイントを入力します。エンドポイントは、必ずetcd:<etcd_endpoint1>;etcd:<etcd_endpoint2>の形式で入力してください。複数のエンドポイントがある場合は、すべてのエンドポイントを追加して、それらをセミコロン (;) で区切ります。
  3. **「Etcd シークレット名 (Etcd secret name)」**フィールドに、Databases for etcd サービスの資格情報を保管するためにクラスター内に作成した Kubernetes シークレットの名前を入力します。
12. **「Kubernetes または OpenShift クラスター名 (Kubernetes or OpenShift cluster name)」**ドロップダウン・リストで、Portworx をインストールするクラスターを選択します。クラスターがリストされていない場合は、正しい IBM Cloud リージョンを選択したことを確認してください。リージョンが正しい場合は、クラスターを表示および使用するための正しい権限があることを確認してください。 Portworx の最小ハードウェア要件を満たすクラスターを選択してください。
13. オプション: Portworx シークレット・ストア・タイプ ドロップダウン・リストから、ボリューム暗号鍵の保管に使用するシークレット・ストア・タイプを選択します。
  - Kubernetes シークレット (Kubernetes Secret): ボリュームを暗号化するための独自のカスタム鍵を、クラスター内の Kubernetes シークレットに保管する場合は、このオプションを選択します。このシークレットは、Portworx をインストールする前に存在していてはいけません。シークレットは、Portworx をインストールした後に作成できます。詳細については、 Portworx のドキュメントを参照してください。
  - IBM Key Protect: ボリュームの暗号化に IBM Key Protect 内のルート鍵を使用する場合は、このオプションを選択します。 Portworx をインストールする前に、手順に従って IBM Key Protect サービス・インスタンスを作成し、portworx プロジェクト内の Kubernetes シークレットに、サービス・インスタンスにアクセスするための資格情報を保管してください。
14. オプション: ジャーナル・デバイスまたは KVDB デバイスをセットアップする場合は、詳細オプションフィールドにデバイスの詳細を入力します。ジャーナル・デバイスの場合は、以下のオプションから選択します。
  - j;autoを入力して、Portworx がジャーナルに使用するブロック・ストレージ・デバイスの 1 つに 3 GB 区画を自動的に作成できるようにします。
  - ジャーナルに特定のデバイスを使用するには、j;</device/path>を入力します。例えば、/dev/vdeにあるディスクを使用するには、j;/dev/vdeと入力します。ジャーナルに使用するデバイスのパスを見つけるには、ワーカー・ノードにログインし、lsblkを実行します。
  - kvdb_dev;<device path>を入力して、内部 KVDB データを保管するデバイスを指定します。例えば、kvdb_dev;/dev/vdd です。使用するデバイスのパスを見つけるには、ワーカー・ノードにログインしてlsblkを実行します。 KVDB データ用に特定のデバイスを使用するには、3GB の使用可能なストレージ・デバイスを用意するか、少なくとも 3 つのワーカー・ノード上にある必要があります。デバイスは、各ワーカー・ノード上の同じパス上にも存在する必要があります。例: /dev/vdd。
**「作成」**をクリックしてクラスターへの Portworx のインストールを開始します。このプロセスは、完了まで数分かかることがあります。サービスの詳細ページが開き、Portworx のインストールの検証方法、永続ボリューム請求 (PVC) の作成方法、および PVC のアプリへのマウント方法に関する説明が表示されます。
IBM Cloud リソース一覧から、作成した Portworx サービスを探します。
**「状況」**列で、インストールが成功したか失敗したかを確認します。状況が更新されるまで数分かかる場合があります。
**「状況」**がProvision failureに変わった場合は、手順に従って、インストールが失敗した理由のトラブルシューティングを開始します。

**「状況」**がProvisionedに変わった場合は、Portworx のインストールが正常に完了したこと、およびすべてのローカル・ディスクが認識され、Portworx ストレージ層に追加されたことを確認します。

kube-system プロジェクトの Portworx ポッドをリストします。インストールが正常に実行された場合は、portworx、stork、および stork-scheduler というポッドがそれぞれ 1 つ以上表示されます。ポッドの数は、Portworx クラスター内のワーカー・ノードの数と等しくなります。すべてのポッドが Running 状態である必要があります。

oc get pods -n kube-system | grep 'portworx\|stork'

出力例

portworx-594rw                          1/1       Running     0          20h
portworx-rn6wk                          1/1       Running     0          20h
portworx-rx9vf                          1/1       Running     0          20h
stork-6b99cf5579-5q6x4                  1/1       Running     0          20h
stork-6b99cf5579-slqlr                  1/1       Running     0          20h
stork-6b99cf5579-vz9j4                  1/1       Running     0          20h
stork-scheduler-7dd8799cc-bl75b         1/1       Running     0          20h
stork-scheduler-7dd8799cc-j4rc9         1/1       Running     0          20h
stork-scheduler-7dd8799cc-knjwt         1/1       Running     0          20h

いずれかの portworx ポッドにログインして、Portworx クラスターのステータスをリスト表示します。

oc exec <portworx_pod> -it -n kube-system -- /opt/pwx/bin/pxctl status

出力例

Status: PX is operational
License: Trial (expires in 30 days)
Node ID: 10.176.48.67
IP: 10.176.48.67
Local Storage Pool: 1 pool
POOL    IO_PRIORITY    RAID_LEVEL    USABLE    USED    STATUS    ZONE    REGION
  0    LOW        raid0        20 GiB    3.0 GiB    Online    dal10    us-south
Local Storage Devices: 1 device
Device    Path                        Media Type        Size        Last-Scan
    0:1    /dev/mapper/3600a09803830445455244c4a38754c66    STORAGE_MEDIUM_MAGNETIC    20 GiB        17 Sep 18 20:36 UTC
        total                            -            20 GiB
Cluster Summary
Cluster ID: mycluster
    Cluster UUID: a0d287ba-be82-4aac-b81c-7e22ac49faf5
Scheduler: kubernetes
Nodes: 2 node(s) with storage (2 online), 1 node(s) without storage (1 online)
  IP        ID        StorageNode    Used    Capacity    Status    StorageStatus    Version        Kernel            OS
  10.184.58.11    10.184.58.11    Yes        3.0 GiB    20 GiB        Online    Up        1.5.0.0-bc1c580    4.4.0-133-generic    Ubuntu 20.04.5 LTS
  10.176.48.67    10.176.48.67    Yes        3.0 GiB    20 GiB        Online    Up (This node)    1.5.0.0-bc1c580    4.4.0-133-generic    Ubuntu 20.04.5 LTS
  10.176.48.83    10.176.48.83    No        0 B    0 B        Online    No Storage    1.5.0.0-bc1c580    4.4.0-133-generic    Ubuntu 20.04.5 LTS
Global Storage Pool
  Total Used        :  6.0 GiB
  Total Capacity    :  40 GiB

Portworx ストレージ層に含めようとしていたすべてのワーカー・ノードが含まれていることを確認します。そのためには、CLI 出力の Cluster Summary セクションの StorageNode 列を確認します。ストレージ層にあるワーカー・ノードは、ストレージ・ノード列にYesと表示されます。

Portworx はクラスター内で DaemonSet として実行されるため、Portworx をデプロイすると、既存のワーカー・ノードがロー・ブロック・ストレージについて自動的に検査され、Portworx データ層に追加されます。クラスターにワーカー・ノードを追加し、それらのワーカーにロー・ブロック・ストレージを追加した場合は、新しいワーカー・ノードで Portworx ポッドを再始動して、ストレージ・ボリュームが DaemonSet によって検出されるようにします。
リスト表示されている各ストレージ・ノードについて、ロー・ブロック・ストレージの正しい容量が表示されていることを確認します。そのためには、CLI 出力の Cluster Summary セクションの Capacity 列を確認します。
Portworx クラスターの一部であるディスクに割り当てられた Portworx 入出力分類を確認します。 Portworx クラスターのセットアップ時に、すべてのディスクが検査されて、そのデバイスのパフォーマンス・プロファイルが決定されます。このプロファイル分類は、ワーカー・ノードが接続されているネットワークの速度と、使用しているストレージ・デバイスのタイプによって決まります。 SDS ワーカー・ノードのディスクは、high として分類されます。仮想ワーカー・ノードに手動でディスクを接続すると、仮想ワーカー・ノードが原因でネットワーク速度が遅くなるため、そのディスクは low として分類されます。
```
oc exec -it <portworx_pod> -n kube-system -- /opt/pwx/bin/pxctl cluster provision-status
```
出力例
```
NODE        NODE STATUS    POOL    POOL STATUS    IO_PRIORITY    SIZE    AVAILABLE    USED    PROVISIONED    RESERVEFACTOR    ZONE    REGION        RACK
10.184.58.11    Up        0    Online        LOW        20 GiB    17 GiB        3.0 GiB    0 B        0        dal12    us-south    default
10.176.48.67    Up        0    Online        LOW        20 GiB    17 GiB        3.0 GiB    0 B        0        dal10    us-south    default
10.176.48.83    Up        0    Online        HIGH        3.5 TiB    3.5 TiB        10 GiB    0 B        0        dal10    us-south    default
```

Portworx ボリュームの作成

Kubernetes の動的プロビジョニングを使用して、 Portworx ボリュームの作成を開始します。

クラスター内の使用可能なストレージ・クラスをリスト表示して、Portworx のインストール時にセットアップした既存の Portworx ストレージ・クラスを使用できるかどうかを確認します。事前定義ストレージ・クラスは、データベースの使用とポッド間でのデータ共有のために最適化されています。
```
oc get sc | grep portworx
```
ストレージ・クラスの詳細を表示するには、 oc describe storageclass <storageclass_name>を実行します。
既存のストレージ・クラスを使用しない場合は、カスタマイズしたストレージ・クラスを作成します。ストレージクラスで指定可能なサポートされているオプションの完全な一覧については、「動的プロビジョニングの使用」を参照してください。
1. ストレージ・クラスの構成ファイルを作成します。
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storageclass_name>
provisioner: kubernetes.io/portworx-volume
parameters:
  repl: "<replication_factor>"
  secure: "<true_or_false>"
  priority_io: "<io_priority>"
  shared: "<true_or_false>"
```
  metadata.name
  
  ストレージ・クラスの名前を入力します。
  
  parameters.repl
  
  複数のワーカー・ノードにまたがって保管するデータのレプリカの数を入力します。許可される番号は、1、2、または3です。例えば、3と入力すると、Portworx クラスター内の 3 つの異なるワーカー・ノードにデータが複製されます。保管するデータの高可用性を確保するには、複数ゾーン・クラスターを使用して、別々のゾーン内にある 3 つのワーカー・ノードにまたがってデータを複製してください。複製要件を満たすために十分なワーカー・ノードが必要です。例えば、2 つのワーカー・ノードしかない場合に、3 つのレプリカを指定した場合は、このストレージ・クラスを使用して PVC を作成できません。
  
  parameters.secure
  IBM Key Protect を使用してボリューム内のデータを暗号化するかどうかを指定します。次のいずれかのオプションを選択します。
  - true: true を入力すると、Portworx ボリュームの暗号化が有効になります。ボリュームを暗号化するには、IBM Key Protect サービス・インスタンスと、カスタマー・ルート鍵を保管する Kubernetes シークレットが必要です。 Portworx ボリュームの暗号化をセットアップする方法について詳しくは、Portworx ボリュームの暗号化を参照してください。
  - false: false を入力すると、Portworx ボリュームは暗号化されません。このオプションを指定しない場合、Portworx ボリュームはデフォルトでは暗号化されません。ストレージ・クラス内で暗号化を無効にした場合でも、PVC 内でボリュームの暗号化を有効にすることができます。 PVC 内の設定は、ストレージ・クラス内の設定よりも優先されます。
  parameters.priority_io
  
  データについて要求する Portworx の入出力優先度を入力します。指定可能な値は、high、medium、および low です。 Portworx クラスターのセットアップ時に、すべてのディスクが検査されて、そのデバイスのパフォーマンス・プロファイルが決定されます。プロファイルの分類は、ワーカー・ノードのネットワーク帯域幅とストレージ・デバイスのタイプによって異なります。 SDS ワーカー・ノードのディスクは、high として分類されます。仮想ワーカー・ノードに手動でディスクを接続すると、仮想ワーカー・ノードが原因でネットワーク速度が遅くなるため、そのディスクは low として分類されます。
  
  ストレージ・クラスを使用して PVC を作成すると、parameters/repl で指定したレプリカの数が入出力優先順位をオーバーライドします。例えば、高速ディスクに保管するレプリカの数として 3 を指定した場合に、高速ディスクを備えたワーカー・ノードがクラスター内に 1 つしかない場合でも、PVC は正常に作成されます。データは高速ディスクと低速ディスクの両方にまたがって複製されます。
  
  parameters.shared
  複数のポッドが同じボリュームにアクセスすることを許可するかどうかを定義します。次のいずれかのオプションを選択します。
  - True: このオプションを true に設定した場合は、別々のゾーンに存在する複数のワーカー・ノードに分散された複数のポッドから、この同じボリュームにアクセスすることができます。
  - False: このオプションを false に設定した場合に、複数のポッドからこのボリュームにアクセスするためには、このボリュームの基盤である物理ディスクに接続されたワーカー・ノードに、それらのポッドがデプロイされている必要があります。ポッドが別のワーカー・ノードにデプロイされている場合、ポッドはボリュームにアクセスできません。
2. ストレージ・クラスを作成します。
```
oc apply -f storageclass.yaml
```
3. ストレージ・クラスが作成されていることを確認します。
```
oc get sc
```
永続ボリューム請求 (PVC) を作成します。
1. PVC の構成ファイルを作成します。
```
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mypvc
spec:
  accessModes:
    - <access_mode>
  resources:
    requests:
      storage: <size>
  storageClassName: portworx-shared-sc
```
  metadata.name
  
  PVC の名前 (mypvcなど) を入力します。
  
  spec.accessModes
  
  使用する Kubernetes アクセスモードを入力してください。
  
  resources.requests.storage
  
  Portworx クラスターから割り当てるストレージの容量 (GB 単位) を入力します。例えば、Portworx クラスターから 2 GB を割り当てるには、2Gi と入力します。指定できるストレージの容量は、Portworx クラスター内で使用できるストレージの容量によって制限されます。ストレージ・クラスで 1 より大きい複製係数を指定した場合、PVC で指定したストレージの量が複数のワーカー・ノードで予約されます。
  
  spec.storageClassName
  
  PV をプロビジョンするために使用する、既に選択または作成したストレージ・クラスの名前を入力します。サンプルの YAML ファイルでは、portworx-shared-sc というストレージ・クラスを使用しています。
2. PVC を作成します。
```
oc apply -f pvc.yaml
```
3. PVC が作成されて永続ボリューム (PV) にバインドされていることを確認します。このプロセスには数分かかる場合があります。
```
oc get pvc
```

アプリへのボリュームのマウント

アプリからストレージにアクセスするには、PVC をアプリにマウントする必要があります。

PVC をマウントするデプロイメントの構成ファイルを作成します。

Portworx を使用してステートフル・セットをデプロイする方法のヒントについては、ステートフル・セットを参照してください。 Portworx のドキュメントには、 KafkaCassandra のデプロイ方法、 ElasticSearch とKibanaの組み合わせ、 WordPress と MySQL の組み合わせに関する例も含まれています。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: <deployment_name>
  labels:
    app: <deployment_label>
spec:
  selector:
    matchLabels:
      app: <app_name>
  template:
    metadata:
      labels:
        app: <app_name>
    spec:
      schedulerName: stork
      containers:
      - image: <image_name>
        name: <container_name>
      securityContext:
          fsGroup: <group_ID>
        volumeMounts:
        - name: <volume_name>
          mountPath: /<file_path>
      volumes:
      - name: <volume_name>
        persistentVolumeClaim:
          claimName: <pvc_name>
```
metadata.labels.app

デプロイメントのラベル。

spec.selector.matchLabels.app および spec.template.metadata.labels.app

アプリのラベル。

template.metadata.labels.app

デプロイメントのラベル。

spec.schedulerName

Portworx クラスターのスケジューラとして Stork を使用してください。 Storkを使用すると、ポッドをそのデータとコロケーションでき、ストレージエラー発生時のポッドのシームレスな移行を実現し、 Portworx ボリュームのスナップショット作成と復元を容易にします。

spec.containers.image

使用するイメージの名前。 IBM Cloud Container Registry アカウント内の使用可能なイメージをリストするには、ibmcloud cr image-list を実行します。

spec.containers.name

クラスターにデプロイするコンテナーの名前。

spec.containers.securityContext.fsGroup

オプション: ルート以外のユーザーでストレージにアクセスするには、デプロイメント YAML の [security-](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/){: external} context fsGroup セクションでポッドのセキュリティコンテキストを指定し、アクセスを許可するユーザー群を定義します。詳細については、「非rootユーザーによる Portworx ボリュームへのアクセス」を参照してください。

spec.containers.volumeMounts.mountPath

コンテナー内でボリュームがマウントされるディレクトリーの絶対パス。異なるアプリ間でボリュームを共有したい場合、各アプリごとにボリュームのサブパスを指定できます。

spec.containers.volumeMounts.name

ポッドにマウントするボリュームの名前。

volumes.name

ポッドにマウントするボリュームの名前。通常、この名前は volumeMounts/name と同じです。

volumes.persistentVolumeClaim.claimName

使用する PV をバインドする PVC の名前。
デプロイメントを作成します。
```
oc apply -f deployment.yaml
```

PV がアプリに正常にマウントされていることを確認します。

oc describe deployment <deployment_name>

マウント・ポイントは Volume Mounts フィールドにあり、ボリュームは Volumes フィールドにあります。

Volume Mounts:
        /var/run/secrets/kubernetes.io/serviceaccount from default-token-tqp61 (ro)
        /volumemount from myvol (rw)
...
Volumes:
    myvol:
    Type:    PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:    mypvc
    ReadOnly:    false

Portworx クラスターにデータを書き込めることを確認します。
1. PV をマウントするポッドにログインします。
```
oc exec <pod_name> -it bash
```
2. アプリ・デプロイメントで定義したボリューム・マウント・パスにナビゲートします。
3. テキスト・ファイルを作成します。
```
echo "This is a test" > test.txt
```
4. 作成したファイルを参照します。
```
cat test.txt
```