Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第29章 高可用性

29.1. 概要

このトピックでは、OpenShift Container Platform クラスターの Pod およびサービスの高可用性の設定について説明します。

IP フェイルオーバーは、ノードセットの仮想 IP (VIP) アドレスのプールを管理します。セットのすべての VIP はセットから選択されるノードによって提供されます。VIP は単一ノードが利用可能である限り提供されます。ノード上で VIP を明示的に配布する方法がないため、VIP のないノードがある可能性も、多数の VIP を持つノードがある可能性もあります。ノードが 1 つのみ存在する場合は、すべての VIP がそのノードに配置されます。

注記

VIP はクラスター外からルーティングできる必要があります。

IP フェイルオーバーは各 VIP のポートをモニターし、ポートがノードで到達可能かどうかを判別します。ポートが到達不能な場合、VIP はノードに割り当てられません。ポートが 0 に設定されている場合、このチェックは抑制されます。check スクリプトは必要なテストを実行します。

IP フェイルオーバーは Keepalived を使用して一連のホストでの外部からアクセスできる VIP アドレスのセットをホストします。各 VIP は 1 度に 1 つのホストによって提供されます。Keepalived は VRRP プロトコルを使用して (一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や Keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの内の別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。

Keepalived を実行するホストが check スクリプトを渡す場合、ホストはプリエンプションストラテジー に応じて、その優先順位および現在の MASTER の優先順位に基づいて MASTER 状態になります。

管理者は、状態が変更されるたびに呼び出されるスクリプトを --notify-script= オプションを使用して提供できます。Keepalived は VIP を提供する場合は MASTER 状態に、別のノードが VIP を提供する場合は BACKUP 状態に、または check スクリプトが失敗する場合は FAULT 状態になります。notify スクリプトは、状態が変更されるたびに新規の状態で呼び出されます。

OpenShift Container Platform は、oc adm ipfailover コマンドの実行による IP フェイルオーバーのデプロイメント設定の作成をサポートします。IP フェイルオーバーのデプロイメント設定は VIP アドレスのセットを指定し、それらの提供先となるノードのセットを指定します。クラスターには複数の IP フェイルオーバーのデプロイメント設定を持たせることができ、それぞれが固有な VIP アドレスの独自のセットを管理します。IP フェイルオーバー設定の各ノードは IP フェイルオーバー Pod として実行され、この Pod は Keepalived を実行します。

VIP を使用してホストネットワーク (例: ルーター) を持つ Pod にアクセスする場合、アプリケーション Pod は ipfailover Pod を実行しているすべてのノードで実行されている必要があります。これにより、いずれの ipfailover ノードもマスターになり、必要時に VIP を提供することができます。アプリケーション Pod が ipfailover のすべてのノードで実行されていない場合、一部の ipfailoverノードが VIP を提供できないか、または一部のアプリケーション Pod がトラフィックを受信できなくなります。この不一致を防ぐために、ipfailover とアプリケーション Pod の両方に同じセレクターとレプリケーション数を使用します。

VIP を使用してサービスにアクセスする場合には、いずれのノードもノードの ipfailover セットに入れることができます。それは、(アプリケーション Pod が実行されている場所を問わず) サービスはすべてのノードで到達可能であるためです。ipfailover ノードのいずれもいつでもマスターにすることができます。サービスは外部 IP およびサービスポートを使用するか、または nodePort を使用することができます。

サービス定義で外部 IP を使用する場合、VIP は外部 IP に設定され、ipfailover のモニターポートはサービスポートに設定されます。nodePort はクラスターのすべてのノードで開かれ、サービスは VIP をサポートしているいずれのノードからのトラフィックについても負荷分散を行います。この場合、ipfailover のモニターノードはサービス定義で nodePort に設定されます。

重要

nodePort のセットアップは特権付きの操作で実行されます。

重要

サービス VIP の可用性が高い場合でも、パーマンスは依然として影響を受けます。keepalived はそれぞれの VIP が設定内のノードによって提供されるようにし、他のノードに VIP がない場合でも複数の VIP が同じノードに配置されることがあります。ipfailover が複数の VIP を同じノードに配置する場合、外部から一連の VIP 間で負荷分散を行う方法は失敗する可能性があります。

ingressIP を使用する場合は、ipfailover を ingressIP 範囲と同じ VIP 範囲を持つように設定できます。また、モニターポートを無効にすることもできます。この場合、すべての VIP がクラスター内の同じノードに表示されます。すべてのユーザーが ingressIP でサービスをセットアップし、これを高い可用性のあるサービスにすることができます。

重要

クラスター内の VIP の最大数は 255 です。

29.2. IP フェイルオーバーの設定

oc adm ipfailover コマンドを適切なオプションと共に使用し、ipfailover デプロイメント設定を作成します。

重要

現時点で、ipfailover はクラウドインフラストラクチャーと互換性がありません。AWS の場合、AWS コンソールの使用により Elastic Load Balancer (ELB) で OpenShift Container Platform の高可用性を維持することができます。

管理者は、クラスター全体に ipfailover を設定することも、ラベルセレクターの定義に基づいてノードのサブセットに ipfailover を設定することもできます。また、複数の IP フェイルオーバーのデプロイメント設定をクラスター内に設定することもでき、それぞれの設定をクラスター内で相互に切り離すことができます。oc adm ipfailover コマンドは ipfailover デプロイメント設定を作成し、これによりフェイルオーバー Pod が使用される制約またはラベルに一致する各ノードで実行されるようにします。この Pod は、すべての Keepalived デーモン間で VRRP (Virtual Router Redundancy Protocol) を使用する Keepalived を実行し、監視されるポートでサービスが利用可能であることを確認し、利用可能でない場合は Keepalived が仮想 IP (VIP) を自動的に浮動させます。

実稼働環境で使用する場合には、2 つ以上のノードで --selector=<label> を使用してノードを選択するようにします。また、指定のラベルが付けられたセレクターのノード数に一致する --replicas=<n> 値を設定します。

oc adm ipfailover コマンドには、Keepalived を制御する環境変数を設定するコマンドラインオプションが含まれます。環境変数OPENSHIFT_HA_* で開始され、必要に応じて変更できます。

たとえば、以下のコマンドは router=us-west-ha のラベルが付けられたノードのセレクションに対して IP フェイルオーバー設定を作成します (7 仮想 IP を持つ 4 ノードで、ルータープロセスなどのポート 80 でリッスンするサービスをモニタリング)。

$ oc adm ipfailover --selector="router=us-west-ha" \
    --virtual-ips="1.2.3.4,10.1.1.100-104,5.6.7.8" \
    --watch-port=80 --replicas=4 --create

29.2.1. 仮想 IP アドレス

Keepalived は一連の仮想 IP アドレス (VIP) を管理します。管理者はこれらすべてのアドレスについて以下の点を確認する必要があります。

  • 仮想 IP アドレスは設定されたホストでクラスター外からアクセスできる。
  • 仮想 IP アドレスはクラスター内でこれ以外の目的で使用されていない。

各ノードの Keepalived は、必要とされるサービスが実行中であるかどうかを判別します。実行中の場合、VIP がサポートされ、Keepalived はネゴシエーションに参加してそのノードが VIP を提供するかを決定します。これに参加するノードについては、このサービスが VIP の監視 ポートでリッスンしている、またはチェックが無効にされている必要があります。

注記

セット内の各 VIP は最終的に別のノードによって提供される可能性があります。

29.2.2. チェックおよび通知スクリプト

Keepalived は、オプションのユーザー指定のチェックスクリプトを定期的に実行してアプリケーションの正常性をモニターします。たとえば、このスクリプトは要求を発行し、応答を検証することで web サーバーをテストします。

スクリプトは oc adm ipfailover コマンドに --check-script=<script> オプションを指定して実行されます。このスクリプトは PASS の場合は 0 で終了するか、または FAIL の場合は 1 で終了する必要があります。

デフォルトでチェックは 2 秒ごとに実行されますが、--check-interval=<seconds> オプションを使用して頻度を変更することができます。

チェックスクリプトが指定されない場合、TCP 接続をテストする単純なデフォルトスクリプトが実行されます。このデフォルトテストは、モニターポートが 0 の場合は抑制されます。

それぞれの仮想 IP (VIP) について、keepalived はノードの状態を保持します。ノードの VIP は MASTERBACKUP、または FAULT の状態になります。FAULT 状態にないノードのすべての VIP はネゴシエーションに参加し、VIP の MASTER を決定します。選ばれなかったすべてのノードは BACKUP 状態になります。MASTER での check スクリプトが失敗すると、VIP は FAULT 状態になり、再ネゴシエーションがトリガーされます。BACKUP が失敗すると、VIP は FAULT 状態になります。check スクリプトが FAULT 状態の VIP に再度渡されると、その VIP は FAULT 状態を終了して MASTER のネゴシエーションを行います。結果としてその VIP の状態は MASTER または BACKUP のいずれかになります。

管理者はオプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに呼び出されます。Keepalived は以下の 3 つのパラメーターをこのスクリプトに渡します。

  • $1 - "GROUP"|"INSTANCE"
  • $2: グループまたはインスタンスの名前です。
  • $3: 新規の状態 ("MASTER"|"BACKUP"|"FAULT") です。

これらのスクリプトは IP フェイルオーバー Pod で実行され、ホストのファイルシステムではなく Pod のファイルシステムを使用します。オプションにはスクリプトへの完全パスが必要です。管理者は Pod でスクリプトを利用可能にし、notify スクリプトを実行して結果を抽出できるようにする必要があります。スクリプトを提供する方法として、ConfigMap の使用が推奨されます。

check および notify スクリプトの完全パス名は、keepalived 設定ファイル、/etc/keepalived/keepalived.conf に追加されます。これは keepalived が起動するたびに読み込まれます。スクリプトは以下のように ConfigMap を使って Pod に追加できます。

  1. 必要なスクリプトを作成し、これを保持する ConfigMap を作成します。スクリプトには入力引数は指定されず、OK の場合は 0 を、FAIL の場合は 1 を返します。

    check スクリプト mycheckscript.sh:

    #!/bin/bash
        # Whatever tests are needed
        # E.g., send request and verify response
    exit 0
  2. ConfigMap を作成します。

    $ oc create configmap mycustomcheck --from-file=mycheckscript.sh
  3. スクリプトを Pod に追加する方法として、oc コマンドの使用またはデプロイメント設定の編集の 2 つの方法があります。どちらの場合も、マウントされた configMap ファイルの defaultMode は実行を許可する必要があります。通常は、値 0755 (493、10 進数) が使用されます。

    1. oc コマンドの使用:

      $ oc env dc/ipf-ha-router \
          OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
      $ oc set volume dc/ipf-ha-router --add --overwrite \
          --name=config-volume \
          --mount-path=/etc/keepalive \
          --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
    2. ipf-ha-router デプロイメント設定の編集:

      1. oc edit dc ipf-ha-router を使用し、テキストエディターでルーターデプロイメント設定を編集します。

        ...
            spec:
              containers:
              - env:
                - name: OPENSHIFT_HA_CHECK_SCRIPT  1
                  value: /etc/keepalive/mycheckscript.sh
        ...
                volumeMounts: 2
                - mountPath: /etc/keepalive
                  name: config-volume
              dnsPolicy: ClusterFirst
        ...
              volumes: 3
              - configMap:
                  defaultMode: 0755 4
                  name: customrouter
                name: config-volume
        ...
        1
        spec.container.env フィールドで、マウントされたスクリプトファイルを参照する OPENSHIFT_HA_CHECK_SCRIPT 環境変数を追加します。
        2
        spec.container.volumeMounts フィールドを追加してマウントポイントを作成します。
        3
        新規の spec.volumes フィールドを追加して ConfigMap に言及します。
        4
        これはファイルの実行パーミッションを設定します。読み取られる場合は 10 進数 (493) で表示されます。
      2. 変更を保存してエディターを終了します。これにより ipf-ha-router が再起動します。

29.2.3. VRRP プリエンプション

ホストが check スクリプトを渡すことで FAULT 状態を終了する場合、その新規ホストが現在の MASTER 状態にあるホストよりも優先度が低い場合は BACKUP になります。ただしそのホストの優先度が高い場合は、プリエンプションストラテジーがクラスター内でのそのロールを決定します。

nopreempt ストラテジーは MASTER を低優先度のホストから高優先度のホストに移行しません。デフォルトの preempt 300 の場合、keepalived は指定された 300 秒の間待機し、MASTER を優先度の高いホストに移行します。

プリエンプションを指定するには、以下を実行します。

  1. preemption-strategy を使用して ipfailover を作成します。

    $ oc adm ipfailover --preempt-strategy=nopreempt \
      ...
  2. oc set env コマンドを使用して変数を設定します。

    $ oc set env dc/ipf-ha-router \
        --overwrite=true \
        OPENSHIFT_HA_PREEMPTION=nopreempt
  3. oc edit dc ipf-ha-router を使用してルーターデプロイメント設定を編集します。

    ...
        spec:
          containers:
          - env:
            - name: OPENSHIFT_HA_PREEMPTION  1
              value: nopreempt
    ...

29.2.4. Keepalived マルチキャスト

OpenShift Container Platform の IP フェイルオーバーは keepalived を内部で使用します。

重要

前述のラベルが付いたノードで multicast が有効にされており、それらが 224.0.0.18 (VRRP マルチキャスト IP アドレス) のネットワークトラフィックを許可することを確認します。

keepalived デーモンを起動する前に、起動スクリプトは、マルチキャストトラフィックのフローを許可する iptables ルールを検証します。このルールがない場合、起動スクリプトは新規ルールを作成し、これを IP テーブル接続に追加します。この新規ルールが IP テーブルに追加される場所は --iptables-chain= オプションによって異なります。--iptables-chain= オプションが指定される場合、ルールはオプションで指定されるチェーンに追加されます。そうでない場合は、ルールは INPUT チェーンに追加されます。

重要

iptables ルールは、1 つ以上の keepalived デーモンがノードで実行されている場合に存在している必要があります。

iptables ルールは、最後の keepalived デーモンの終了後に削除できます。このルールは自動的に削除されません。

各ノードで iptables ルールを手動で管理できます。(ipfailover が --iptable-chain="" オプションで作成されていない限り) 何も存在しない場合にこのルールが作成されます。

重要

手動で追加されたルールがシステム起動後も保持されることを確認する必要があります。

すべての keepalived デーモンはマルチキャスト 224.0.0.18 で VRRP を使用してそのピアとネゴシエーションするので注意が必要です。それぞれの VIP に異なる VRRP-id (0..255 の範囲) が設定されます。

$ for node in openshift-node-{5,6,7,8,9}; do   ssh $node <<EOF

export interface=${interface:-"eth0"}
echo "Check multicast enabled ... ";
ip addr show $interface | grep -i MULTICAST

echo "Check multicast groups ... "
ip maddr show $interface | grep 224.0.0

EOF
done;

29.2.5. コマンドラインオプションおよび環境変数

表29.1 コマンドラインオプションおよび環境変数

オプション変数名デフォルト備考

--watch-port

OPENSHIFT_HA_MONITOR_PORT

80

ipfailover Pod は、各 VIP のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが 0 に設定される場合、テストは常にパスします。

--interface

OPENSHIFT_HA_NETWORK_INTERFACE

 

使用する ipfailover のインターフェース名で、VRRP トラフィックを送信するために使用されます。デフォルトで eth0 が使用されます。

--replicas

OPENSHIFT_HA_REPLICA_COUNT

2

作成するレプリカの数です。これは、ipfailover デプロイメント設定の spec.replicas 値に一致している必要があります。

--virtual-ips

OPENSHIFT_HA_VIRTUAL_IPS

 

複製する IP アドレス範囲の一覧です。これは指定する必要があります (例: 1.2.3.4-6,1.2.3.9.)。詳細については、こちらを参照してください。

--vrrp-id-offset

OPENSHIFT_HA_VRRP_ID_OFFSET

0

詳細は、VRRP ID オフセットを参照してください。

--virtual-ip-groups

OPENSHIFT_HA_VIP_GROUPS

 

VRRP に作成するグループの数です。これが設定されていない場合、グループは --virtual-ips オプションで指定されている仮想 IP 範囲ごとに作成されます。詳細は、「254 を超えるアドレスについての IP フェイルオーバーの設定」を参照してください。

--iptables-chain

OPENSHIFT_HA_IPTABLES_CHAIN

INPUT

iptables チェーンの名前であり、iptables ルールを自動的に追加し、VRRP トラフィックをオンにすることを許可するために使用されます。この値が設定されていない場合、iptables ルールは追加されません。チェーンが存在しない場合は作成されません。

--check-script

OPENSHIFT_HA_CHECK_SCRIPT

 

Pod のファイルシステム内の、アプリケーションの動作を確認するために定期的に実行されるスクリプトの完全パス名です。詳細は、こちらを参照してください。

--check-interval

OPENSHIFT_HA_CHECK_INTERVAL

2

check スクリプトが実行される期間 (秒単位) です。

--notify-script

OPENSHIFT_HA_NOTIFY_SCRIPT

 

Pod ファイルシステム内の、状態が変更されるたびに実行されるスクリプトの完全パス名です。詳細は、こちらを参照してください。

--preemption-strategy

OPENSHIFT_HA_PREEMPTION

preempt 300

新たな優先度の高いホストを処理するためのストラテジーです。詳細は、「VRRP プリエンプション」のセクションを参照してください。

29.2.6. VRRP ID オフセット

ipfailover デプロイメント設定で管理される各 ipfailover Pod (ノード/レプリカあたり 1 Pod) は keepalived デーモンを実行します。作成される ipfailover デプロイメント設定が多くなると、作成される Pod も多くなり、共通の VRRP ネゴシエーションに参加するデーモンも多くなります。このネゴシエーションはすべての keepalived デーモンによって実行され、これはどのノードがどの仮想 IP (VIP) を提供するかを決定します。

keepalived は内部で固有の vrrp-id を各 VIP に割り当てます。ネゴシエーションはこの vrrp-id セットを使用し、決定後には優先される vrrp-id に対応する VIP が優先されるノードで提供されます。

したがって、ipfailover デプロイメント設定で定義されるすべての VIP について、ipfailover Pod は対応する vrrp-id を割り当てます。これは、--vrrp-id-offsetから開始し、順序に従って vrrp-id を VIP の一覧に割り当てることによって実行されます。vrrp-id には範囲 1..255 の値を設定できます。

複数の ipfailover デプロイメント設定がある場合、デプロイメント設定の VIP 数を増やす余地があることや vrrp-id 範囲のいずれも重複しないことを確認できるよう --vrrp-id-offset を注意して指定する必要があります。

29.2.7. 254 を超えるアドレスについての IP フェイルオーバーの設定

IP フェイルオーバー管理は VIP アドレスの 254 グループに制限されています。デフォルトでは、OpenShift Container Platform は各グループに 1 つの IP アドレスを割り当てます。virtual-ip-groups オプションを使用するとこれを変更でき、IP フェイルオーバーの設定時に複数の IP アドレスをそれぞれのグループに配置し、各 VRRPインスタンスに利用できる VIP グループの数を定義できます。

VIP の作成により、VRRP フェイルオーバーの発生時の広範囲の VRRP の割り当てが作成され、これはクラスター内のすべてのホストがローカルにサービスにアクセスする場合に役立ちます。たとえば、サービスが ExternalIP で公開されている場合などがこれに含まれます。

注記

フェイルオーバーのルールとして、ルーターなどのサービスは特定の 1 つのホストに制限しません。代わりに、サービスは、IP フェイルオーバーの発生時にサービスが新規ホストに再作成されないように各ホストに複製可能な状態にする必要があります。

注記

OpenShift Container Platform のヘルスチェックを使用している場合、IP フェイルオーバーおよびグループの性質上、グループ内のすべてのインスタンスはチェックされません。そのため、Kubernetes ヘルスチェックを使ってサービスが有効であることを確認する必要があります。

# oc adm ipfailover <ipfailover_name> --create \
    ...
    --virtual-ip-groups=<number_of_ipfailover_groups>

たとえば、7 つの VIP のある環境で --virtual-ip-groups3 に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。

注記

--virtual-ip-groups オプションで設定されるグループの数がフェイルオーバーに設定される IP アドレスの数よりも小さい場合、グループには複数の IP アドレスが含まれ、アドレスのすべてが単一のユニットとして移行します。

29.2.8. 高可用サービスの設定

以下の例では、ノードのセットに IP フェイルオーバーを指定して可用性の高い router および geo-cache ネットワークサービスをセットアップする方法について説明します。

  1. サービスに使用されるノードにラベルを付けます。の手順は、OpenShift Container Platform クラスターのすべてのノードでサービスを実行し、クラスターのすべてのノード内で固定されない VIP を使用する場合はオプションになります。

    以下の例では、地理的区分 US west でトラフィックを提供するノードのラベルを定義します (ha-svc-nodes=geo-us-west)。

    $ oc label nodes openshift-node-{5,6,7,8,9} "ha-svc-nodes=geo-us-west"
  2. サービスアカウントを作成します。ipfailover を使用したり、(環境ポリシーによって異なる) ルーターを使用する場合は事前に作成された router サービスアカウントか、または新規の ipfailover サービスアカウントのいずれかを再利用できます。

    以下の例は、デフォルト namespace で ipfailover という名前の新規サービスアカウントを作成します。

    $ oc create serviceaccount ipfailover -n default
  3. デフォルト namespace の ipfailover サービスアカウントを privileged SCC に追加します。

    $ oc adm policy add-scc-to-user privileged system:serviceaccount:default:ipfailover
  4. router および geo-cache サービスを起動します。

    重要

    ipfailover は手順 1 のすべてのノードで実行されるため、手順 1 のすべてのノードでルーター/サービスを実行することも推奨されます。

    1. 最初の手順で使用されるラベルに一致するノードでルーターを起動します。以下の例では、ipfailover サービスアカウントを使用して 5 つのインスタンスを実行します。

      $ oc adm router ha-router-us-west --replicas=5 \
          --selector="ha-svc-nodes=geo-us-west" \
          --labels="ha-svc-nodes=geo-us-west" \
          --service-account=ipfailover
    2. 各ノードでレプリカと共に geo-cache サービスを実行します。geo-cache サービスの実行については、「設定サンプル」を参照してください。

      重要

      ファイルで参照される myimages/geo-cache コンテナーイメージが使用するイメージに置き換えられていることを確認します。レプリカの数を geo-cache ラベルのノード数に変更します。ラベルが最初の手順で使用したものと一致していることを確認します。

      $ oc create -n <namespace> -f ./examples/geo-cache.json
  5. router および geo-cache サービスの ipfailover を設定します。それぞれに独自の VIP があり、いずれも最初の手順の ha-svc-nodes=geo-us-west のラベルが付けられた同じノードを使用します。レプリカの数が最初の手順のラベル設定に一覧表示されているノード数と一致していることを確認してください。

    重要

    routergeo-cache および ipfailover はすべてデプロイメント設定を作成します。それらの名前はすべて異なっている必要があります。

  6. ipfailover が必要なインスタンスでモニターする必要のある VIP およびポート番号を指定します。

    router の ipfailover コマンド:

    $ oc adm ipfailover ipf-ha-router-us-west \
        --replicas=5 --watch-port=80 \
        --selector="ha-svc-nodes=geo-us-west" \
        --virtual-ips="10.245.2.101-105" \
        --iptables-chain="INPUT" \
        --service-account=ipfailover --create

    以下は、ポート 9736 でリッスンする geo-cache サービスの oc adm ipfailover コマンドです。2 つの ipfailover デプロイメント設定があるため、それぞれの VIP が独自のオフセットを取得できるように --vrrp-id-offset を設定する必要があります。この場合 10 の値は、ipf-ha-geo-cache が 10 から開始するために ipf-ha-router-us-west には最大 10 の VIP (0-9)を持たせることができることを意味します。

    $ oc adm ipfailover ipf-ha-geo-cache \
        --replicas=5 --watch-port=9736 \
        --selector="ha-svc-nodes=geo-us-west" \
        --virtual-ips=10.245.3.101-105 \
        --vrrp-id-offset=10 \
        --service-account=ipfailover --create

    上記のコマンドでは、各ノードに ipfailoverrouter、および geo-cache Pod があります。各 ipfailover 設定の VIP のセットは重複してなならず、外部またはクラウド環境の別の場所で使用することはできません。それぞれの例の 5 つの VIP 10.245.{2,3}.101-105 は、2 つの ipfailover デプロイメント設定で提供されます。IP フェイルオーバーはどのアドレスがどのノードで提供されるかを動的に選択します。

    管理者は、すべての router VIP が同じ router を参照し、すべての geo-cache VIP が同じ geo-cache サービスを参照することを前提とした上で VIP アドレスを参照する外部 DNS をセットアップします。1 つのノードが実行中である限り、すべての VIP アドレスが提供されます。

29.2.8.1. IP フェイルオーバー Pod のデプロイ

postgresql-ingress サービスの定義に基づいてノードポート 32439 および外部 IP アドレスでリッスンする postgresql をモニターするために ipfailover ルーターをデプロイします。

$ oc adm ipfailover ipf-ha-postgresql \
    --replicas=1 \ 1
    --selector="app-type=postgresql" \ 2
    --virtual-ips=10.9.54.100 \ 3
    --watch-port=32439 \ 4
    --service-account=ipfailover --create
1 1
デプロイするインスタンスの数を指定します。
2
ipfailover がデプロイされる場所を制限します。
3
モニターする仮想 IP アドレスです。
4
各ノード上の ipfailover がモニターするポートです。

29.2.9. 高可用サービスの仮想 IP の動的更新

IP フェイルオーバーのデフォルトのデプロイメント方法として、デプロイメントを再作成します。高可用のルーティングサービスの動的更新を最小限のダウンタイムまたはダウンタイムなしで実行するには、以下を実行する必要があります。

  • ローリングアップデート (Rolling Update) ストラテジーを使用するように IP フェイルオーバーサービスデプロイメント設定を更新する。
  • 仮想 IP アドレスの更新された一覧またはセットを使用して OPENSHIFT_HA_VIRTUAL_IPS 環境変数を更新します。

以下の例は、デプロイメントストラテジーおよび仮想 IP アドレスを動的に更新する方法について示しています。

  1. 以下を使用して作成された IP フェイルオーバー設定を見てみましょう。

    $ oc adm ipfailover ipf-ha-router-us-west \
        --replicas=5 --watch-port=80 \
        --selector="ha-svc-nodes=geo-us-west" \
        --virtual-ips="10.245.2.101-105" \
        --service-account=ipfailover --create
  2. デプロイメント設定を編集します。

    $ oc edit dc/ipf-ha-router-us-west
  3. spec.strategy.type フィールドを Recreate から Rolling に更新します。

    spec:
      replicas: 5
      selector:
        ha-svc-nodes: geo-us-west
      strategy:
        resources: {}
        rollingParams:
          maxSurge: 0
        type: Rolling 1
    1
    Rolling に設定します。
  4. 追加の仮想 IP アドレスを含めるように OPENSHIFT_HA_VIRTUAL_IPS 環境変数を更新します。

    - name: OPENSHIFT_HA_VIRTUAL_IPS
      value: 10.245.2.101-105,10.245.2.110,10.245.2.201-205 1
    1
    10.245.2.110,10.245.2.201-205 が一覧に追加されます。
  5. VIP のセットに一致するよう外部 DNS を更新します。

29.3. サービスの ExternalIP および NodePort の設定

ユーザーは VIP をサービスの ExternalIP として割り当てることができます。Keepalived は、各 VIP が ipfailover 設定のノードで提供されることを確認します。要求がそのノードに到達すると、クラスター内のすべてのノードで実行されているサービスがサービスのエンドポイント間で要求の負荷の分散を行います。

NodePorts を ipfailover 監視ポートに設定して、keepalived がアプリケーションが実行中であることを確認できるようにします。NodePort はクラスター内のすべてのノードで公開されるため、すべての ipfailover ノードの keepalived で利用可能になります。

29.4. IngressIP の高可用性

クラウド以外のクラスターでは、ipfailover およびサービスへの ingressIP を組み合わせることができます。結果として、ingressIP を使用してサービスを作成するユーザーに高可用サービスが提供されます。

この方法では、まず ingressIPNetworkCIDR 範囲を指定し、次に ipfailover 設定を作成する際に同じ範囲を使用します。

ipfailover はクラスター全体に対して最大 255 の VIP をサポートするため、ingressIPNetworkCIDR/24 以下に設定する必要があります。