9.2. 複数の Prism Element を使用したフォールトトレラントなデプロイメント
デフォルトでは、インストールプログラムは、コントロールプレーンとコンピュートマシンを単一の Nutanix Prism Element (クラスター) にインストールします。OpenShift Container Platform クラスターのフォールトトレランスを向上させるために、これらのマシンを複数の Nutanix クラスターに分散するように指定できます。これを行うには、障害ドメインを設定します。
障害ドメインは、インストール中およびインストール後に OpenShift Container Platform マシンプールで使用できる追加の Prism Element インスタンスを表します。
9.2.1. インストール方法と障害ドメインの設定
OpenShift Container Platform のインストール方法によって、障害ドメインをいつどのように設定するかが決まります。
installer-provisioned infrastructure を使用してデプロイする場合は、クラスターをデプロイする前に、インストール設定ファイルで障害ドメインを設定できます。詳細は、障害ドメインの設定 を参照してください。
クラスターのデプロイ後に障害ドメインを設定することもできます。インストール後の障害ドメインの設定の詳細は、既存の Nutanix クラスターへの障害ドメインの追加 を参照してください。
- お客様が管理するインフラストラクチャー (user-provisioned infrastructure) を使用してデプロイする場合、追加の設定は必要ありません。クラスターをデプロイした後、コントロールプレーンとコンピュートマシンを障害ドメイン全体に手動で分散できます。
9.2.2. 既存の Nutanix クラスターへの障害ドメインの追加
デフォルトでは、インストールプログラムは、コントロールプレーンとコンピュートマシンを単一の Nutanix Prism Element (クラスター) にインストールします。OpenShift Container Platform クラスターをデプロイした後、障害ドメインを使用して追加の Prism Element インスタンスをデプロイメントに追加することで、フォールトトレランスを向上させることができます。
障害ドメインは、新しいコントロールプレーンとコンピュートマシンをデプロイし、既存のコントロールプレーンとコンピュートマシンを分散できる単一の Prism Element インスタンスを表します。
9.2.2.1. 障害ドメインの要件
障害ドメインの使用を計画する場合は、次の要件を考慮してください。
- すべての Nutanix Prism Element インスタンスは、同一の Prism Central インスタンスによって管理する必要があります。複数の Prism Central インスタンスで構成されるデプロイメントはサポートされていません。
- Prism Element クラスターを構成するマシンは、障害ドメインが相互に通信できるように、同じイーサネットネットワーク上に存在する必要があります。
- OpenShift Container Platform クラスターで障害ドメインとして使用する各 Prism Element には、サブネットが必要です。これらのサブネットを定義するときは、共通の IP アドレス接頭辞 (CIDR) を指定する必要があります。また、OpenShift Container Platform クラスターが使用する仮想 IP アドレスをサブネットに含める必要があります。
9.2.2.2. インフラストラクチャー CR への障害ドメインの追加
既存の Nutanix クラスターに障害ドメインを追加するには、そのインフラストラクチャーカスタムリソース (CR) (infrastructures.config.openshift.io) を変更します。
高可用性を確保するには、3 つの障害ドメインを設定することを推奨します。
手順
次のコマンドを実行して、インフラストラクチャー CR を編集します。
$ oc edit infrastructures.config.openshift.io cluster
障害ドメインを設定します。
Nutanix 障害ドメインを使用したインフラストラクチャー CR の例
spec: cloudConfig: key: config name: cloud-provider-config #... platformSpec: nutanix: failureDomains: - cluster: type: UUID uuid: <uuid> name: <failure_domain_name> subnets: - type: UUID uuid: <network_uuid> - cluster: type: UUID uuid: <uuid> name: <failure_domain_name> subnets: - type: UUID uuid: <network_uuid> - cluster: type: UUID uuid: <uuid> name: <failure_domain_name> subnets: - type: UUID uuid: <network_uuid> # ...ここでは、以下のようになります。
<uuid>- Prism Element の汎用一意識別子 (UUID) を指定します。
<failure_domain_name>-
障害ドメインの一意の名前を指定します。名前は 64 文字以下に制限されており、小文字、数字、ダッシュ (
-) を含めることができます。ダッシュを名前の先頭または末尾に含めることはできません。 <network_uuid>- Prism Element サブネットオブジェクトの UUID を指定します。サブネットの IP アドレス接頭辞 (CIDR) には、OpenShift Container Platform クラスターが使用する仮想 IP アドレスを含める必要があります。OpenShift Container Platform クラスター内の障害ドメイン (Prism Element) ごとに 1 つのサブネットのみがサポートされます。
- CR を保存して変更を適用します。
9.2.2.3. 障害ドメイン全体へのコントロールプレーンの分散
コントロールプレーンマシンセットのカスタムリソース (CR) を変更することで、Nutanix 障害ドメイン全体にコントロールプレーンを分散します。
前提条件
- クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
- コントロールプレーンマシンセットのカスタムリソース (CR) がアクティブな状態である。
コントロールプレーンマシンセットのカスタムリソースの状態を確認する方法の詳細は、「関連情報」を参照してください。
手順
次のコマンドを実行して、コントロールプレーンマシンセット CR を編集します。
$ oc edit controlplanemachineset.machine.openshift.io cluster -n openshift-machine-api
spec.template.machines_v1beta1_machine_openshift_io.failureDomainsスタンザを追加して、障害ドメインを使用するようにコントロールプレーンマシンセットを設定します。Nutanix 障害ドメインが設定されたコントロールプレーンマシンの例
apiVersion: machine.openshift.io/v1 kind: ControlPlaneMachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <cluster_name> name: cluster namespace: openshift-machine-api spec: # ... template: machineType: machines_v1beta1_machine_openshift_io machines_v1beta1_machine_openshift_io: failureDomains: platform: Nutanix nutanix: - name: <failure_domain_name_1> - name: <failure_domain_name_2> - name: <failure_domain_name_3> # ...- 変更を保存します。
デフォルトでは、コントロールプレーンマシンセットは、変更をコントロールプレーン設定に自動的に反映します。クラスターが OnDelete 更新ストラテジーを使用するように設定されている場合は、コントロールプレーンを手動で置き換える必要があります。詳細は、「関連情報」を参照してください。
9.2.2.4. 障害ドメイン全体へのコンピュートマシンの分散
次のいずれかの方法で、Nutanix 障害ドメイン全体にコンピュートマシンを分散できます。
- 既存のコンピュートマシンセットを編集 すると、設定更新を最小限に抑えながら、Nutanix 障害ドメイン全体にコンピュートマシンを分散できます。
- 既存のコンピュートマシンセットを置き換える と、仕様をイミュータブルにして、すべてのマシンを確実に同じにすることができます。
9.2.2.4.1. コンピュートマシンセットの編集による障害ドメインの実装
既存のコンピュートマシンセットを使用して Nutanix 障害ドメイン全体にコンピュートマシンを分散するには、設定でコンピュートマシンセットを更新し、スケーリングを使用して既存のコンピュートマシンを置き換えます。
前提条件
- クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
手順
次のコマンドを実行して、クラスターのインフラストラクチャー CR を表示します。
$ oc describe infrastructures.config.openshift.io cluster
-
各障害ドメイン (
platformSpec.nutanix.failureDomains) について、クラスターの UUID、名前、サブネットオブジェクト UUID をメモします。これらの値は、障害ドメインをコンピュートマシンセットに追加するために必要です。 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <machine_set_name_1> 1 1 1 1 55m <machine_set_name_2> 1 1 1 1 55m
次のコマンドを実行して、最初のコンピュートマシンセットを編集します。
$ oc edit machineset <machine_set_name_1> -n openshift-machine-api
spec.template.spec.providerSpec.valueスタンザを次のように更新して、最初の障害ドメインを使用するようにコンピュートマシンセットを設定します。注記clusterおよびsubnetsフィールドに指定する値が、クラスターのインフラストラクチャー CR のfailureDomainsスタンザに設定されている値と一致していることを確認してください。Nutanix 障害ドメインを使用したコンピュートマシンセットの例
apiVersion: machine.openshift.io/v1 kind: MachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <cluster_name> name: <machine_set_name_1> namespace: openshift-machine-api spec: replicas: 2 # ... template: spec: # ... providerSpec: value: apiVersion: machine.openshift.io/v1 failureDomain: name: <failure_domain_name_1> cluster: type: uuid uuid: <prism_element_uuid_1> subnets: - type: uuid uuid: <prism_element_network_uuid_1> # ...-
spec.replicasの値をメモします。この値は、変更を適用するためにコンピュートマシンセットをスケーリングする際に必要になるためです。 - 変更を保存します。
次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。
$ oc get -n openshift-machine-api machines \ -l machine.openshift.io/cluster-api-machineset=<machine_set_name_1>
出力例
NAME PHASE TYPE REGION ZONE AGE <machine_name_original_1> Running AHV Unnamed Development-STS 4h <machine_name_original_2> Running AHV Unnamed Development-STS 4h
次のコマンドを実行して、更新されたコンピュートマシンセットで管理されるマシンごとに
deleteアノテーションを設定します。$ oc annotate machine/<machine_name_original_1> \ -n openshift-machine-api \ machine.openshift.io/delete-machine="true"
代わりとなるマシンを新しい設定で作成するために、次のコマンドを実行して、コンピュートマシンセットをレプリカ数の 2 倍にスケーリングします。
$ oc scale --replicas=<twice_the_number_of_replicas> \1 machineset <machine_set_name_1> \ -n openshift-machine-api- 1
- たとえば、コンピュートマシンセット内のレプリカの元の数が
2の場合、レプリカを4にスケーリングします。
次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。
$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name_1>
新しいマシンが
Runningフェーズにある場合、コンピュートマシンセットを元のレプリカ数にスケーリングできます。古い設定で作成されたマシンを削除するために、次のコマンドを実行して、コンピュートマシンセットを元のレプリカ数にスケーリングします。
$ oc scale --replicas=<original_number_of_replicas> \1 machineset <machine_set_name_1> \ -n openshift-machine-api- 1
- たとえば、コンピュートマシンセット内のレプリカの元の数が
2であった場合、レプリカを2にスケーリングします。
- 必要に応じて、デプロイメントで使用可能な追加の障害ドメインを参照するようにマシンセットの変更を続けます。
関連情報
9.2.2.4.2. コンピュートマシンセットの置き換えによる障害ドメインの実装
コンピュートマシンセットを置き換えることによって、Nutanix 障害ドメイン全体にコンピュートマシンを分散するには、独自の設定で新しいコンピュートマシンセットを作成し、作成されたマシンが起動するのを待ってから、古いコンピュートマシンセットを削除します。
前提条件
- クラスターのインフラストラクチャーカスタムリソース (CR) で障害ドメインを設定している。
手順
次のコマンドを実行して、クラスターのインフラストラクチャー CR を表示します。
$ oc describe infrastructures.config.openshift.io cluster
-
各障害ドメイン (
platformSpec.nutanix.failureDomains) について、クラスターの UUID、名前、サブネットオブジェクト UUID をメモします。これらの値は、障害ドメインをコンピュートマシンセットに追加するために必要です。 以下のコマンドを実行して、クラスター内のコンピュートマシンセットを一覧表示します。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <original_machine_set_name_1> 1 1 1 1 55m <original_machine_set_name_2> 1 1 1 1 55m
- 既存のコンピュートマシンセットの名前に注意してください。
次のいずれかの方法を使用して、新しいコンピュートマシンセットのカスタムリソース (CR) の値を含む YAML ファイルを作成します。
次のコマンドを実行して、既存のコンピュートマシンセット設定を新しいファイルにコピーします。
$ oc get machineset <original_machine_set_name_1> \ -n openshift-machine-api -o yaml > <new_machine_set_name_1>.yaml
この YAML ファイルは、任意のテキストエディターで編集できます。
任意のテキストエディターを使用して
<new_machine_set_name_1>.yamlという名前の空の YAML ファイルを作成し、新しいコンピュートマシンセットに必要な値を含めます。特定のフィールドに設定する値がわからない場合は、次のコマンドを実行して、既存のコンピュートマシンセット CR の値を確認できます。
$ oc get machineset <original_machine_set_name_1> \ -n openshift-machine-api -o yaml
出力例
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1 name: <infrastructure_id>-<role> 2 namespace: openshift-machine-api spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> template: metadata: labels: machine.openshift.io/cluster-api-cluster: <infrastructure_id> machine.openshift.io/cluster-api-machine-role: <role> machine.openshift.io/cluster-api-machine-type: <role> machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role> spec: providerSpec: 3 ...
<new_machine_set_name_1>.yamlファイルのspec.template.spec.providerSpec.valueスタンザを更新または追加して、最初の障害ドメインを使用するように新しいコンピュートマシンセットを設定します。注記clusterおよびsubnetsフィールドに指定する値が、クラスターのインフラストラクチャー CR のfailureDomainsスタンザに設定されている値と一致していることを確認してください。Nutanix 障害ドメインを使用したコンピュートマシンセットの例
apiVersion: machine.openshift.io/v1 kind: MachineSet metadata: creationTimestamp: null labels: machine.openshift.io/cluster-api-cluster: <cluster_name> name: <new_machine_set_name_1> namespace: openshift-machine-api spec: replicas: 2 # ... template: spec: # ... providerSpec: value: apiVersion: machine.openshift.io/v1 failureDomain: name: <failure_domain_name_1> cluster: type: uuid uuid: <prism_element_uuid_1> subnets: - type: uuid uuid: <prism_element_network_uuid_1> # ...- 変更を保存します。
次のコマンドを実行して、コンピュートマシンセット CR を作成します。
$ oc create -f <new_machine_set_name_1>.yaml
- 必要に応じて、デプロイメントで使用可能な追加の障害ドメインを参照するコンピュートマシンセットの作成に進みます。
新しいコンピュートマシンセットごとに次のコマンドを実行して、新しいコンピュートマシンセットによって管理されているマシンをリスト表示します。
$ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<new_machine_set_name_1>
出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Provisioned AHV Unnamed Development-STS 25s <machine_from_new_2> Provisioning AHV Unnamed Development-STS 25s
新しいマシンが
Runningフェーズにある場合、障害ドメイン設定を含まない古いコンピュートマシンセットを削除できます。新しいマシンが
Runningフェーズにあることを確認したら、古いコンピュートマシンセットごとに次のコマンドを実行して削除します。$ oc delete machineset <original_machine_set_name_1> -n openshift-machine-api
検証
設定を更新していないコンピューティングマシンセットが削除されたことを確認するには、次のコマンドを実行して、クラスター内のコンピューティングマシンセットをリスト表示します。
$ oc get machinesets -n openshift-machine-api
出力例
NAME DESIRED CURRENT READY AVAILABLE AGE <new_machine_set_name_1> 1 1 1 1 4m12s <new_machine_set_name_2> 1 1 1 1 4m12s
設定を更新していないコンピュートマシンが削除されたことを確認するには、次のコマンドを実行してクラスター内のマシンをリスト表示します。
$ oc get -n openshift-machine-api machines
削除中の出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Running AHV Unnamed Development-STS 5m41s <machine_from_new_2> Running AHV Unnamed Development-STS 5m41s <machine_from_original_1> Deleting AHV Unnamed Development-STS 4h <machine_from_original_2> Deleting AHV Unnamed Development-STS 4h
削除完了時の出力例
NAME PHASE TYPE REGION ZONE AGE <machine_from_new_1> Running AHV Unnamed Development-STS 6m30s <machine_from_new_2> Running AHV Unnamed Development-STS 6m30s
新しいコンピューティングマシンセットによって作成されたマシンの設定が正しいことを確認するには、次のコマンドを実行して、いずれかの新しいマシンの CR に含まれる関連フィールドを調べます。
$ oc describe machine <machine_from_new_1> -n openshift-machine-api
