Portworx セットアップの計画
クラスターを作成して Portworx をインストールする前に、以下の計画ステップを確認します。
- Portworx メタデータを保管する場所を決定します。 KVDB または外部データベース・インスタンスを使用できます。 詳しくは、 キー/値ストアについて を参照してください。 キー値の機能について詳しくは、 Portworx の資料を参照してください。
- 暗号化するかどうかを決定します。 Hyper Protect Crypto Services または IBM Key Protectを使用できます。 詳しくは、 Understanding encryption for Portworx を参照してください。
- ジャーナル装置を使用するかどうかを決定します。 ジャーナル・デバイスを使用すると、 Portworx は、ワーカー・ノード上のローカル・ディスクに直接ログを書き込むことができます。
- VPC クラスターまたは Satellite クラスターのみ-クラウド・ドライブを使用するかどうかを決定します。 クラウド・ドライブを使用すると、 Portworx ボリュームを動的にプロビジョンできます。 クラウド・ドライブを使用しない場合は、ボリュームをワーカー・ノードに手動で接続する必要があります。
- 制限 を確認します。
制限
以下の Portworx 制限を確認します。
制限 | 説明 |
---|---|
モントリオールの私設クラスター | Portworx Enterprise および Portworx Backup のデフォルトのインストール方法は、モントリオール地域のプライベート専用クラスタではまだサポートされていません。 モントリオールのプライベート専用クラスタに Portworx Enterprise または Portworx Backup をインストールする必要がある場合は、 Portworx サポートにお問い合わせください。 詳しくは、 Portworx サポートを ご覧ください。 |
クラシック・クラスター ワーカー・ノードを追加する際にはポッドの再始動が必要です。 | Portworx はクラスター内で DaemonSet として実行されるため、Portworx をデプロイすると、既存のワーカー・ノードがロー・ブロック・ストレージについて自動的に検査され、Portworx データ層に追加されます。 クラスターにワーカー・ノードを追加または更新し、それらのワーカーにロー・ブロック・ストレージを追加した場合は、新しいワーカー・ノードまたは更新されたワーカー・ノード上の Portworx ポッドを再始動して、ストレージ・ボリュームが DaemonSet によって検出されるようにします。 |
VPC クラスター ワーカー・ノードを更新する際にはストレージ・ボリュームの再接続が必要です。 | VPC クラスター内のワーカー・ノードを更新すると、そのワーカー・ノードがクラスターから削除され、新しいワーカー・ノードに置き換えられます。 置換されるワーカー・ノードに Portworx ボリュームが接続されている場合は、そのボリュームを新しいワーカー・ノードに接続する必要があります。 ストレージ・ボリュームは、API または CLI を使用して接続できます。 この制限は、クラウド・ドライブを使用する Portworx デプロイメントには適用されないことに注意してください。 |
Portworx 試験版 InitializerConfiguration 機能はサポートされていません |
Red Hat OpenShift on IBM Cloud は、 Portworx 試験用 InitializerConfiguration アドミッション・コントローラーをサポートしていません。 |
プライベート・クラスター | VRF またはプライベート・クラウド・サービス・エンドポイント(CSE)へのアクセスを持たないクラスターに Portworx をインストールするには、デフォルトのセキュリティ・グループに、以下の IP アドレスのインバウンドおよびアウトバウンド・トラフィックを許可するルールを作成する必要があります: 166.9.24.81 166.9.22.100 および 166.9.20.178 。 詳細については、
デフォルトのセキュリティー・グループの更新を参照してください。 |
portworx バックアップ | Portworx バックアップは、 Satellite クラスターではサポートされていません。 |
Portworx ライフサイクルの概要
- マルチゾーン・クラスターを作成します。
- インフラストラクチャー・プロバイダー: Satellite クラスターの場合、ホストをロケーションに接続する前に、必ずブロック・ストレージ・ボリュームをホストに追加してください。 クラシック・インフラストラクチャーを使用する場合は、ワーカー・ノードに対してベアメタル・フレーバーを選択する必要があります。 クラシック・クラスターの場合、仮想マシンのネットワーキング速度はわずか 1000 Mbps であり、この速度は Portworx で実動ワークロードを実行するには不十分です。 代わりに、パフォーマンスを最大化するために、ベアメタル・マシンに Portworx をプロビジョンします。
- ワーカー・ノード・フレーバー: SDS またはベアメタル・フレーバーを選択します。 仮想マシンを使用する場合は、8 vCPU と 8 GB 以上のメモリを搭載したワーカーノードを使用してください。
- 最小ワーカー数: 3 つのゾーン全体でゾーンごとに 2 つのワーカー・ノード。つまり、最小ワーカー・ノード数の合計は 6 になります。
- VPC および非 SDS クラシック・ワーカー・ノードのみ: マウントされていない未フォーマットのロー・ブロック・ストレージを作成します。
- 実動ワークロードの場合は、Portworx メタデータのキー/値ストアに対して外部 Databases for etcd インスタンスを作成します。
- オプション 暗号化をセットアップします。
- Portworxをインストールします。
- クラスターの Portworx デプロイメントのライフサイクルを管理します。
- VPC クラスターのワーカー・ノードを更新するときには、Portworx ボリュームを再接続するための追加の手順を実行する必要があります。 API または CLI を使用して、ストレージ・ボリュームを接続できます。
- Portworx ボリューム、ストレージ・ノード、または Portworx クラスター全体を削除するには、Portworx のクリーンアップを参照してください。
KMS の資格情報を保管するシークレットの作成
始める前に: 暗号化をセットアップします
- 前のセクションで取得した資格情報を base64 でエンコードして、すべての base64 エンコード値をメモします。 パラメーターごとにこのコマンドを繰り返して、base64 エンコード値を取得します。
echo -n "<value>" | base64
- クラスター内に
portworx
というプロジェクトを作成します。oc create ns portworx
- IBM Key Protect 情報を保管するため、クラスターの
portworx
プロジェクトにpx-ibm
という名前の Kubernetes シークレットを作成します。-
次の内容からなる Kubernetes シークレットの構成ファイルを作成します。
apiVersion: v1 kind: Secret metadata: name: px-ibm namespace: portworx type: Opaque data: IBM_SERVICE_API_KEY: <base64_apikey> IBM_INSTANCE_ID: <base64_guid> IBM_CUSTOMER_ROOT_KEY: <base64_rootkey> IBM_BASE_URL: <base64_endpoint>
metadata.name
- Kubernetes シークレットの名前として
px-ibm
を入力します。 異なる名前を使用した場合は、インストール時にこのシークレットが Portworx によって認識されません。 data.IBM_SERVICE_API_KEY
- 既に取得した base64 エンコードされた IBM Key Protect または Hyper Protect Crypto Services API キーを入力します。
data.IBM_INSTANCE_ID
- 既に取得した base64 エンコードされたサービス・インスタンス GUID を入力します。
data.IBM_CUSTOMER_ROOT_KEY
- 既に取得した base64 エンコードされたルート鍵を入力します。
data.IBM_BASE_URL
-
- IBM Key Protect: サービス・インスタンスの base64 エンコード API エンドポイントを入力します。
- Hyper Protect Crypto Services: base64 エンコードの鍵管理パブリック・エンドポイントを入力します。
-
クラスターの
portworx
プロジェクト内にシークレットを作成します。oc apply -f secret.yaml
-
このシークレットが正常に作成されたことを確認します。
oc get secrets -n portworx
-
- Portworx をインストールする前に暗号化をセットアップした場合は、この時点で Portworx をクラスターにインストールできます。 Portworx をインストールした後にクラスタに暗号化を追加するには、 Portworx DaemonSet を更新して、 Portworx コンテナ定義に追加オプションとして
"-secret_type"
と"ibm-kp"
を追加します。-
Portworx DaemonSet を更新します。
oc edit daemonset portworx -n kube-system
更新された DaemonSet の例
containers: - args: - -c - testclusterid - -s - /dev/sdb - -x - kubernetes - -secret_type - ibm-kp name: portworx
DaemonSet を編集すると、Portworx ポッドが再始動され、その変更を反映するためにワーカー・ノード上の
config.json
ファイルが自動的に更新されます。 -
kube-system
プロジェクト内の Portworx ポッドをリスト表示します。oc get pods -n kube-system | grep portworx
-
いずれかの Portworx ポッドにログインします。
oc exec -it <pod_name> -it -n kube-system
-
pwx
ディレクトリーに移動します。cd etc/pwx
-
config.json
ファイルを参照して、"secret_type": "ibm-kp"
が CLI 出力の secret セクションに追加されていることを確認します。cat config.json
出力例
{ "alertingurl": "", "clusterid": "px-kp-test", "dataiface": "", "kvdb": [ "etcd:https://portal-ssl748-34.bmix-dal-yp-12a2312v5-123a-44ac-b8f7-5d8ce1d123456.123456789.composedb.com:56963", "etcd:https://portal-ssl735-35.bmix-dal-yp-12a2312v5-123a-44ac-b8f7-5d8ce1d123456.12345678.composedb.com:56963" ], "mgtiface": "", "password": "ABCDEFGHIJK", "scheduler": "kubernetes", "secret": { "cluster_secret_key": "", "secret_type": "ibm-kp" }, "storage": { "devices": [ "/dev/sdc1" ], "journal_dev": "", "max_storage_nodes_per_zone": 0, "system_metadata_dev": "" }, "username": "root", "version": "1.0" }
-
ポッドを終了します。
-
クラスター内のシークレットを暗号化する方法を確認してください (Portworx ストレージ・クラスター用の Key Protect CRK を保管したシークレットを含む)。