IBM Cloud Docs
高可用性 (HA) と VRRP の作業

高可用性 (HA) と VRRP の作業

IBM Cloud® Virtual Router Appliance (VRA) では、高可用性プロトコルとして Virtual Router Redundancy Protocol (VRRP) をサポートしています。 デバイスのデプロイメントは、アクティブ/パッシブ方式で行われます。つまり、一方のマシンがマスターになり、他方がバックアップになります。 両方のマシン上のすべてのインターフェースが同じ「同期グループ (sync-group)」のメンバーになるため、1 つのインターフェースに障害が発生すると、同じグループ内の他の各インターフェースにも障害が発生し、そのデバイスはマスターであることを停止します。 現在のバックアップは、マスターがキープアライブ・メッセージまたはハートビート・メッセージをブロードキャストしなくなったことを検出し、VRRP 仮想 IP の制御を引き受けて、マスターになります。

VRRP は、ゲートウェイのプロビジョニング時の構成の最も重要な部分です。 高可用性機能は、ハートビート・メッセージに依存するため、メッセージがブロックされないようにすることが重要です。

VRRP 仮想 IP (VIP) アドレス

dp0bond1 または dp0bond0 の VRRP 仮想 IP (VIP) は、フェイルオーバーの発生時にマスター・デバイスからバックアップ・デバイスに変更される浮動 IP アドレスです。 VRA は、デプロイすると、パブリックおよびプライベートの結合されたネットワーク接続を持ち、各インターフェースに実 IP が割り当てられます。 デバイスがスタンドアロンであるか HA ペアであるかに関係なく、VIP も両方のインターフェースに割り当てられます。 トラフィックの宛先 IP が VRA に関連付けられた VLAN のサブネットにある場合、そのトラフィックは、FCR/BCR 上の静的ルートを介してこれらの VRRP VIP に直接送信されます。

ゲートウェイ・グループの VRRP 仮想 IP アドレスは変更しないでください。また VRRP インターフェースを無効にしないでください。 これらの IP アドレスは、VLAN が関連付けられているときにトラフィックをゲートウェイに経路指定する手段です。 そのため、それらの IP アドレスが使用できない場合、トラフィックも停止します。 IP アドレスが存在しないと、トラフィックを BCR/FCR から VRA 自体に転送できません。 この時点では、この仮想アドレス、つまり VIP は変更できません。 この制限は将来変更される可能性がありますが、現時点では、POD/FCR/BCR 間での VRA のマイグレーションも VIP の変更もサポートされていません。

以下は、特定の VRA の dp0bond0 と dp0bond1 の VIP のデフォルト構成の例です。 ご使用の IP アドレスと vrrp-groups は、この例とは異なる場合があることに注意してください。

set interfaces bonding dp0bond0 vrrp vrrp-group 2 virtual-address '10.127.170.1/26'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 virtual-address '159.8.98.209/29'

詳しくは、VRRP を使用する関連 VLAN サブネットを参照してください。

デフォルトでは、VRRP は無効に設定されています。 これにより、新たなプロビジョンおよび再ロードによりマスター・デバイスで障害が発生することがなくなります。 VLAN トラフィックが機能するためには、プロビジョニングまたは再ロードの完了後に VRRP を再度有効にする必要があります。 次の例では、デフォルト構成の詳細を指定します。

set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

プロビジョンまたは再ロードの後に、これら 2 つのインターフェースで VRRP を有効にするには、(この有効化は、スタンドアロンと HA ペアの両方で必要です) 次のコマンドを実行します。 この後、その変更をコミットします。

delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

VRRP グループ

VRRP グループは、グループ内の 1 次 (つまりマスター) インターフェースに冗長性を提供する、インターフェースまたは仮想インターフェースのクラスターで構成されます。 VRRP グループは、キープアライブ構成に virtual_router_id を定義します。 VRRP プロトコル自体では、それは VRID と呼ばれます。 VRRP グループには、固有の数値 ID があり、最大 20 個の仮想 IP アドレスを割り当てることができます。

VRRP グループ ID は、IBM Cloud によって割り当てられるもので、変更してはなりません。 新規ゲートウェイ・グループが初めて Frontend Customer Router (FCR)/Backend Customer Router (BCR) の背後にプロビジョンされると、VRRP グループ 1 を受け取ります。 後続のゲートウェイ・グループ・プロビジョンでは、競合を避けるためにこの値が増分されます。 例えば、次のグループはグループ 2、その次はグループ 3 というようになります。 次に、それはプロビジョニング・プロセスによって計算され、割り当てられます。 この値を変更すると、他のアクティブ・グループと衝突して、マスター/マスターの競合が発生するリスクがあり、その結果、両方のゲートウェイ・グループが停止する可能性があります。

前の構成からマイグレーションする場合は、構成コードを入念にチェックして、VRRP グループ ID が静的に割り当てられていないことを確認することをお勧めします。

VRRP グループ ID は、データベース内に保持されるため、OS の再ロード時やアップグレード時には同じグループ ID 値が使用されます。 ユーザーが変更した VRRP グループ ID は、OS の再ロード中にシステム割り当て値で上書きされます。

VRRP 優先度

ゲートウェイ・グループの最初のマシンの優先度は 254 になります。この値は、次にプロビジョンされるデバイスでは減分されます。 決して優先度を 255 に設定しないでください。この値は VIP 「アドレス所有者」を定義するため、実行中のアクティブ・マスターとは異なる構成を使用してマシンをオンラインにすると、意図しない動作が生じることがあります。

VRRP 優先使用

優先使用は、すべての VRRP インターフェースで常に無効に設定し、新規デバイスまたは OS 再ロード中のデバイスが、クラスターの引き継ぎを試みないようにしてください。

VRRP 通知間隔

マスター・インターフェースまたは VIF は、まだサービス中であることをシグナル通知するために、IANA 割り当ての VRRP 用のマルチキャスト・アドレス (IPv4 の場合は 224.0.0.18、IPv6 の場合は FF02:0:0:0:0:0:0:12) を使用して、「アドバタイズメント」と呼ばれる「ハートビート」パケットを LAN セグメントに送信します。

デフォルトでは、間隔は 1 に設定されています。 この値は増やすことができますが、5 を超える値を設定することは推奨されません。 トラフィックの多いネットワークでは、すべての VRRP 通知がマスターからバックアップ・デバイスに到着するまでに 1 秒以上かかる場合があるため、トラフィックが多いネットワークの場合は 2 の値を使用する必要があります。

VRRP 同期 (同期グループ)

VRRP 同期グループ (「同期グループ」) 内のインターフェースは、グループ内のいずれかのインターフェースがバックアップにフェイルオーバーした場合、そのグループ内のすべてのインターフェースがバックアップにフェイルオーバーするように同期化されています。 例えば、マスター・ルーター上の 1 つのインターフェースに障害が起こると、ルーター全体がバックアップ・ルーターにフェイルオーバーします。

この値は、VRRP グループの場合とは異なり、そのグループ内のいずれかのインターフェースが障害を検知した場合にデバイス上のどのインターフェースがフェイルオーバーするのかを定義します。 すべてのインターフェースが同じ同期グループに属するようにすることをお勧めします。そうしないと、一部のインターフェースはマスターとなってゲートウェイ IP を持ち、他のインターフェースはバックアップとなるため、トラフィックが正常に転送されなくなります。 アクティブ/アクティブ構成はサポートされません。

VRRP rfc-互換性

rfc-互換性は、インターフェース上の VRRP の RFC 3768 MAC アドレスを有効または無効にします。 これは、ネイティブ・インターフェースでは有効にする必要がありますが、構成された VIF では有効にしてはなりません。 一部の仮想スイッチ (大抵は、vmware) では、これが有効になっていると問題が生じ、トラフィックが除去されて、ハイパーバイザー・ホスト・マシンからゲートウェイ IP に送信されません。 この設定はそのままにして、どの VIF にもこの設定を構成しないでください。

VRRP 認証

VRRP 認証用のパスワードを設定する場合、認証タイプも定義する必要があります。 パスワードが設定されていて、認証タイプが定義されていない場合、構成をコミットしようとすると、システムはエラーを生成します。

同様に、VRRP パスワードを削除するときは、必ず VRRP 認証タイプも削除する必要があります。 パスワードだけを削除した場合、構成をコミットしようとすると、システムはエラーを生成します。 VRRP 認証パスワードと認証タイプの両方を削除すると、VRRP 認証は無効になります。

IETF は、VRRP バージョン 3 では認証を使用しないことを決定しました。 詳しくは、RFC 5798 VRRP を参照してください。

バージョン 2/3 サポート

VRA は、VRRP バージョン 2 (デフォルト) とバージョン 3 の両方のプロトコルをサポートします。 バージョン 2 では、IPv4 と IPv6 を一緒に使用できません。しかし、バージョン 3 では、IPv4 と IPv6 を同時に使用できます。

VRRP を使用した高可用性 VPN

VRA は、VRRP を使用する IBM Cloud® Virtual Router Appliance のペアを使用して、1 つの IPsec トンネルを介して接続を維持する機能を提供します。 1 つのルーターで障害が発生した場合、または保守のためのサービス停止が発生した場合、新規 VRRP マスター・ルーターが、ローカル・ネットワークとリモート・ネットワーク間の IPsec 接続を復元します。

VRRP を使用して HA VPN を構成する場合、VRRP 仮想アドレスが VRA インターフェースに追加されるたびに、IPsec デーモンを再初期化する必要があります。IPsec サービスは、Internet Key Exchange (IKE) サービス・デーモンの初期化時に VRA 上に存在したアドレスへの接続のみを listen するためです。

マスター・ルーターとバックアップ・ルーターで以下のコマンドを実行して、フェイルオーバーが発生した場合、以下の例に示されるように、VIP の移行後に新規マスター・デバイス上で IPsec デーモンが再始動されるようにします。

vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

VRRP を使用した高可用性ファイアウォール

2 つのデバイスが HA ペアになっている場合、マスター・デバイスでは、他方のデバイスからのアクセスをブロックしないように注意する必要があります。 config-sync が機能するためには、両方のデバイス間で TCP ポート 830 (netconf) が許可されている必要があります。また、 224.0.0.0/24 のマルチキャスト範囲を含めて、VRRP の送受信が許可されている必要があります。

VRRP を使用する関連 VLAN サブネット

VRRP を使用する VIF 構成では、仮想 IP アドレス (サブネット内の最初の使用可能 IP、そのサブネット内のすべての経路指定先であるゲートウェイ IP) が必要であり、さらに両方のデバイス上の VIF の実インターフェース IP アドレスも必要です。 使用可能な IP を節約するために、実インターフェース IP では 192.168.0.0/30 などのアウト・オブ・バンドの範囲を使用することをお勧めします。この範囲の場合、一方のデバイスでは .1 アドレスを使用し、他方のデバイスでは .2 アドレスを使用します。 複数の VRRP 仮想 IP を使用できますが、各 VIF で必要な実アドレスは 1 つだけです。

以下に、2 つのプライベート VLAN と 3 つのサブネットを持つ VRRP 構成の例を示します。

set interfaces bonding dp0bond0 address '10.100.11.39/26'
set interfaces bonding dp0bond0 mode 'lacp'
set interfaces bonding dp0bond0 vif 10 address '192.168.255.81/30'
set interfaces bonding dp0bond0 vif 10 description 'VLAN 10 - Two private subnets/VIPs'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.105.177/28'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.38.1/26'
set interfaces bonding dp0bond0 vif 11 address '192.168.255.89/30'
set interfaces bonding dp0bond0 vif 11 description 'VLAN 11 - One private subnet/VIP'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 virtual-address '10.100.212.65/26'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 virtual-address '10.100.11.5/26'
set interfaces bonding dp0bond1 address '169.110.20.28/29'
set interfaces bonding dp0bond1 mode 'lacp'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 virtual-address '169.110.21.26/29'
  • VRRP 同期グループと VRRP グループは違うものです。 同期グループ内のいずれかのインターフェースが状態を変更すると、同じ同期グループの他のすべてのメンバーは同じ状態に遷移します。
  • VLAN インターフェース (VIF) の VRRP グループ番号は、それに対応するネイティブ・インターフェースとほとんどの場合に同一である必要があります。 例えば、dp0bond1.789 と dp0bond1 の VRRP グループ番号は、2 つのインターフェースが同じ同期グループを共有している場合を除き、常に同じ番号である必要があります。 VIF とネイティブ・インターフェースで異なるグループ番号を使用すると、異なる同期グループとペアになったときに「スプリット・ブレーン」状態が発生する可能性があります。 2 つのインターフェースが同じ同期グループを共有している場合、それらが異なる VRRP グループ上にあっても、両方のインターフェースともマスターとバックアップ間を同時に遷移するため、スプリット・ブレーンが回避されます。 一方、ネイティブ・インターフェースが VLAN インターフェースとは異なる VRRP グループ番号と同期グループを使用して設定されている場合、VLAN インターフェース上に設定されているサブネットがネイティブ・インターフェース上の仮想アドレスに静的に経路指定されるため、VLAN インターフェースがバックアップで、ネイティブ・インターフェースがマスターの場合に、ルーターは、VLAN インターフェースが VRA 上の 2 次インターフェースであり、非アクティブになっているにもかかわらず、ネイティブ・インターフェースがマスターである VRA に VLAN インターフェース・トラフィックを引き続き送信します。 この特定の状況は、「スプリット・ブレーン」と機能停止を引き起こします。 同期グループを VRRP グループとともに設定する方法について注意を払うことが重要なのはこのためです。 また、同じトランジット VLAN 内の複数の HA VRA ペア間で同じ VRRP グループ (vrrp-group) 番号を使用しないことも重要です。これは、同じグループを使用する 4 つの Vyatta によって、3 つの VRA が潜在的にバックアップ状態となり、1 つの VRA のみがマスターとなることによって、機能停止が発生するためです。
  • ネイティブ VLAN 上の実際のインターフェース・アドレス (例えば、dp0bond1: 169.110.20.28/29) は、それらの VIP (169.110.21.26/29) と同じサブネットにあるとは限りません。

手動 VRRP フェイルオーバー

VRRP フェイルオーバーを強制する必要がある場合、現在 VRRP マスターであるデバイスで以下を実行することでそれを行うことができます。

vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1

グループ ID は、ネイティブ・インターフェースの VRRP グループ ID であり、前述のとおり、ご使用のペアでは異なる可能性があります。

接続の同期

2 つの VRA デバイスが HA ペアになっている場合、フェイルオーバーの発生時に、障害が発生したデバイス上のすべての接続の現行状態がバックアップ・デバイスに複製されるように、この 2 つのデバイス間のステートフル接続をトラッキングすることが役に立つことがあります。 現在アクティブなすべてのセッション (SSL 接続など) を最初から再作成する必要がありません (この再作成は、結果的にユーザー・エクスペリエンスの中断を招く可能性があります)。

これは、接続トラッキング同期と呼ばれます。

これを構成するには、以下のように、使用するフェイルオーバー方式、接続トラッキング情報の送信に使用するインターフェース、およびリモート・ピアの IP を宣言する必要があります。

set service connsync failover-mechanism vrrp sync-group SYNC1
set service connsync interface dp0bond0
set service connsync remote-peer 10.124.10.4

もう一方の VRA も同じ構成になりますが、remote-peer が異なります。

他のインターフェースに着信する接続が多数ある場合、これによりリンクが飽和状態になる可能性があり、宣言されたリンク上で他のトラフィックとの競合が生じることに注意してください。

VRRP 開始遅延機能

Vyatta OS バージョン 1801p 以上には、新規の vrrp コマンドが含まれています。

vrrp は、LAN 上のいずれかの VRRP ルーターに仮想ルーターの責任を動的に割り当てる選出プロトコルを指定します。 仮想ルーターに関連付けられる IPv4 アドレスまたは IPv6 アドレスを制御する VRRP ルーターは、マスターと呼ばれ、それらの IPv4 アドレスまたは IPv6 アドレスに送信されたパケットを転送します。 選出プロセスは、マスターが使用不可能になった場合の責任の転送において動的なフェイルオーバー機能を提供します。 すべてのプロトコル・メッセージングは、IPv4 または IPv6 のマルチキャスト・データグラムを使用して行われます。結果的に、プロトコルは、IPv4 または IPv6 のマルチキャストをサポートするさまざまなマルチアクセス LAN テクノロジー上で動作することができます。

ネットワーク・トラフィックを最少化するために、個々の仮想ルーターのマスターのみが定期的な VRRP アドバタイズメント・メッセージを送信します。 バックアップ・ルーターは、マスターよりも高優先度でない限り、優先使用を試みません。 そうすることによって、より優先的なパスが使用可能にならない限りサービスが中断されることはありません。 すべての優先使用の試みを管理上禁止することもできます。 マスターが使用不可能になった場合、短い遅延の後に、最も高優先度のバックアップがマスターに移行します。これにより、最小限のサービス中断で、仮想ルーターの責任の制御された移行が提供されます。

IBM Cloud プロビジョン済みのデプロイメントにおいては、開始遅延値はデフォルト値に設定されます。 フェイルオーバーおよび高可用性の方式を検証する中で、この値は、必要に応じて変更できます。

「優先使用あり」と「優先使用なし」の比較

vrrp プロトコルは、ネットワーク上のどの VRRP ピアがより高優先度であるか (すなわちマスターの役割を実施するのに最善のピア) を判定するためのロジックを定義します。 デフォルトの構成において、VRRP では、優先使用の実行が有効になっています。つまり、ネットワーク上により高優先度のピアが新たに登場すると、マスターの役割が強制的にフェイルオーバーされます。

優先使用を使用不可にすると、より高優先度のピアによるマスター役割のフェイルオーバーは、優先度のより低いピアがネットワーク上で使用不可になった場合にのみ行われます。 より高優先度のピアが、ピア自体またはいずれかのネットワーク接続の信頼性問題によって定期的に悪化し始めている状況をより適切に処理できるため、現実の世界のシナリオにおいては、優先使用を使用不可にすると有用である場合があります。 新たな高優先度ピアでネットワーク・コンバージェンスが完了する前にフェイルオーバーが時期尚早に時期尚早に実行されることを防ぐためにも有用です。

優先使用の前提条件および制限事項

優先使用を使用不可にするように VRRP ピアを構成した場合、優先使用が実行されているように見えるが、実際のシナリオは単に標準の VRRP フェイルオーバーであるというケースもあります。 上記で説明したように、VRRP では、現在選出されているマスター・ルーターが使用可能であるかを確認するための手段として、IP マルチキャスト・データグラムを使用します。 VRRP ピアの障害を検出するのは、レイヤー 3 プロトコルなので、VRRP とネットワーク・スタックのレイヤー 1 から 2 までが準備され、コンバージェンスが完了するまで、VRRP におけるフェイルオーバーの検出を遅延させることが重要です。 一部のケースでは、VRRP を実行するネットワーク・インターフェースがプロトコルに対しインターフェースの稼働状態を確認しても、スパンニング・ツリーや結合など、基礎となる他のサービスが完了していない場合があります。 その結果、ピア間の IP 接続は確立できません。 このような状況が発生した場合、ネットワーク上の現在のマスター・ピアから送信された VRRP メッセージを検出できないため、新しい高優先度のピア上の VRRP がマスターになります。 コンバージェンスの完了後、短い期間に 2 つのマスター VRRP ピアが存在した場合、VRRP のデュアル・マスター・ロジックが実行されます。 より高優先度のピアはマスターとなり、優先度のより低いピアはバックアップになります。 このシナリオは、「優先使用なし」機能の障害を示しているように見える場合があります。

開始遅延機能

インターフェースの稼働イベントにおける、ネットワーク・スタックの下位レベルによるコンバージェンスの遅延に関連する問題、およびその他影響する要因に対応するために、1801p パッチでは「開始遅延」という新たな機能が導入されました。 この機能は、事前定義された遅延が経過するまで、「再ロード」されたマシン上の VRRP 状態を INIT 状態のまま維持します。この遅延時間は、ネットワーク・オペレーターが構成できます。 この遅延値は柔軟に調整できるので、ネットワーク・オペレーターは、現実の世界の条件下で、ネットワークおよびデバイスの特徴をカスタマイズすることができます。

コマンドの詳細

vrrp {
start-delay <0-600>
}

start-delay の値は、0 (デフォルト) から 600 秒の間で設定できます。

構成の例

interfaces {
  bonding dp0bond1 {
address 161.202.101.206/29 mode balanced
vrrp {
      start-delay 120
      vrrp-group 211 {
preempt false
priority 253
virtual-address 161.202.101.204/29
} }
}