機械翻訳について

7 障害時リカバリ

Oracle Linux Virtualization Managerでは、サイトの停止時に環境をリカバリできるように、アクティブ・アクティブ型およびアクティブ・パッシブ型の障害時リカバリ・ソリューションがサポートされています。 どちらのソリューションも2つのサイトをサポートしており、レプリケートされた記憶域が必要です。

アクティブ・アクティブ型障害時リカバリ

アクティブ・アクティブ型障害時リカバリでは、ストレッチ・クラスタ構成を使用します。 これは、プライマリ・サイトおよびセカンダリ・サイトで必要な仮想マシンを実行できるホストが含まれるクラスタがある、単一のOracle Linux Virtualization Manager環境が存在することを意味します。 停止が発生すると、プライマリ・サイトの仮想マシンはセカンダリ・サイトのホストに自動的に移行されます。 ただし、環境はレイテンシとネットワークの要件を満たす必要があります。

アクティブ・パッシブ型障害時リカバリ

アクティブ・パッシブ型の障害時リカバリは、サイト間フェイルオーバー・ソリューションです。 アクティブなプライマリ環境とパッシブなセカンダリ(バックアップ)環境という、2つの個別のOracle Linux Virtualization Manager環境が構成されています。 アクティブ・パッシブ型の障害時リカバリでは、フェイルオーバーとフェイルバック(必要な場合)の両方を手動で実行する必要があります。どちらもAnsibleを使用して実行されます。

重要:

RAC、Pacemaker/Corosyncなどのクラスタリング・アプリケーションを使用する場合、仮想マシンを再開動作の強制終了に設定します(これは、高可用性の下のVMの編集ダイアログにあります)。 それ以外の場合、クラスタリング・アプリケーションは、一時停止または一時停止された仮想マシンをフェンスしようとします。

アクティブ・アクティブ型障害時リカバリ

Oracle Linux Virtualization Managerでは、両方ともアクティブな2つのサイトにまたがることがある、アクティブ・アクティブ型障害時リカバリ・フェイルオーバー構成がサポートされています。 プライマリ・サイトが使用できなくなった場合、Oracle Linux Virtualization Manager環境はビジネス継続性を確保するためにセカンダリ・サイトにスムーズに移行します。

アクティブ・アクティブ型のフェイルオーバーをサポートするには、クラスタ内のすべての仮想マシンを実行できるホストがプライマリ・サイトとセカンダリ・サイトに配置されている、ストレッチ・クラスタを構成する必要があります。 すべてのホストが同じOracle Linux Virtualization Managerクラスタに属します。 ストレッチ・クラスタ構成は、自己ホスト・エンジン環境またはスタンドアロン・エンジン環境を使用して実装できます。

アクティブ・アクティブ型障害時リカバリでは、両方のサイトで書込み可能なレプリケートされた記憶域も必要です。 これにより、仮想マシンをサイト間で移行し、サイトの記憶域で実行を継続できます。

プライマリ・サイトが使用できなくなった場合、仮想マシンはセカンダリ・サイトに移行します。 プライマリ・サイトが使用可能になり、両方のサイトで記憶域がレプリケートされると、仮想マシンは自動的にフェイルバックします。

仮想マシンのフェイルオーバーおよびフェイルバックを確実に機能させるには、次を構成する必要があります。

  • 高可用性のための仮想マシン。電源管理なしでも仮想マシンを起動できるように、各仮想マシンにはターゲット記憶域ドメインでのリースが必要です。

  • 選択したホストでのみ仮想マシンが起動するように弱く強制された仮想マシンからホストへのアフィニティ。

ネットワークに関する考慮点

ストレッチ・クラスタ内のすべてのホストは、レイヤー2 (L2)ネットワーク上の同じブロードキャスト・ドメインにある必要があります。つまり、2つのサイト間の接続はL2である必要があります。

L2ネットワークにおけるサイト間の最大レイテンシ要件は、スタンドアロン・エンジン環境と自己ホスト・エンジン環境で異なります。

  • スタンドアロンのエンジン環境には最大レイテンシ100ミリ秒が必要です

  • 自己ホスト・エンジン環境には最大レイテンシ7ミリ秒が必要です

記憶域に関する考慮事項

Oracle Linux Virtualization Managerの記憶域ドメインは、ブロック・デバイス(iSCSIまたはFCP)またはファイル・システム(NAS/NFSまたはGlusterFS)のいずれかです。

どちらのサイトでも、仮想マシンをサイト間で移行してサイトの記憶域で実行を継続できるように、共有L2ネットワーク接続で書込み可能で同期レプリケートされた記憶域が必要です。 Oracle Linux 8以降でサポートされているすべての記憶域レプリケーション・オプションは、ストレッチ・クラスタで使用できます。

詳細は、管理ガイドおよびアーキテクチャおよびプランニング・ガイドの記憶域に関する項を参照してください。

スタンドアロン・エンジンのストレッチ・クラスタ環境の構成

ストレッチ・クラスタ向けにスタンドアロン・エンジン環境の構成を開始する前に、次の前提条件と制限事項を確認してください。

  • L2ネットワーク接続を使用する、両方のサイトで書込み可能なストレージ・サーバー。

  • 記憶域を複製するリアルタイムの記憶域レプリケーション・サービス。

  • 最大100ミリ秒のサイト間レイテンシ。

    仮想マシンがサイト間でフェイルオーバーおよびフェイルバックするには、エンジンの可用性が高い必要があります。 エンジンがサイトとともに停止した場合、仮想マシンはフェイルオーバーしません。

  • スタンドアロン・エンジンは、外部で管理されている場合にのみ可用性が高くなります。たとえば:

    • 別の仮想化環境での高可用性仮想マシンの場合

    • パブリック・クラウド内の場合

スタンドアロン・エンジンのストレッチ・クラスタを構成するには:

  1. Oracle Linux Virtualization Managerエンジンをインストールして構成します。

    詳細については、「Oracle Linux Virtualization Manager: スタート・ガイド」のインストールおよび構成を参照してください。

  2. 各サイトにホストをインストールし、クラスタに追加します。

    詳細については、「Oracle Linux Virtualization Manager: スタート・ガイド」のKVMホストの構成を参照してください。

  3. プライマリ・サイトのすべてのホストでストレージ・プール・マネージャ(SPM)の優先度が高くなるように構成して、プライマリ・サイトのすべてのホストが使用できない場合にのみセカンダリ・サイトへのSPMフェイルオーバーが行われるようにします。

    詳細については、「Oracle Linux Virtualization Manager: アーキテクチャおよびプランニング・ガイド」のStorage Pool Managerを参照してください。

  4. フェイルオーバーが必要なすべての仮想マシンを高可用性として構成し、仮想マシンにターゲット記憶域ドメインのリースがあることを確認します。

    詳細については、「クラスタ、ホストおよび仮想マシンの最適化」を参照してください。

  5. ソフト・アフィニティをホストするように仮想マシンを構成し、アフィニティ・グループから期待される動作を定義します。

    詳細は、oVirt Virtual Machine Management GuideのAffinity Groupsを参照してください。

    重要:

    VMアフィニティ・ルール「強制」を有効にすると(アフィニティ・グループのリストで「ハード」と表示)、システムは、アフィニティ・グループ内の他の仮想マシンが実行されているホストとは異なるホストに仮想マシンを移行しません。 詳細については、「Oracle Linux Virtualization Manager: リリース・ノート」の仮想マシンに関する問題を参照してください。

アクティブ・アクティブ型のフェイルオーバーは、メイン・サイトのホストをメンテナンス・モードにすることで手動で実行できます。

自己ホスト・エンジンのストレッチ・クラスタ環境の構成

ストレッチ・クラスタ向けに自己ホスト・エンジン環境の構成を開始する前に、次の前提条件と制限事項を確認してください。

  • L2ネットワーク接続を使用する、両方のサイトで書込み可能なストレージ・サーバー

  • 記憶域を複製するリアルタイムの記憶域レプリケーション・サービス

  • 最大7ミリ秒のサイト間レイテンシ

自己ホスト・エンジンのストレッチ・クラスタを構成するには:

  1. Oracle Linux Virtualization Manager自己ホスト・エンジンをデプロイします。

    詳細については、「Oracle Linux Virtualization Manager: スタート・ガイド」の自己ホスト・エンジンのデプロイメントを参照してください。

  2. オプションで、各サイトに追加のホストをインストールし、それらをクラスタに追加します。

    詳細については、「Oracle Linux Virtualization Manager: スタート・ガイド」内のKVMホストの追加を参照してください。

  3. プライマリ・サイトのすべてのホストでストレージ・プール・マネージャ(SPM)の優先度が高くなるように構成して、プライマリ・サイトのすべてのホストが使用できない場合にのみセカンダリ・サイトへのSPMフェイルオーバーが行われるようにします。

    詳細については、「Oracle Linux Virtualization Manager: アーキテクチャおよびプランニング・ガイド」のStorage Pool Managerを参照してください。

  4. フェイルオーバーが必要なすべての仮想マシンを高可用性として構成し、仮想マシンにターゲット記憶域ドメインのリースがあることを確認します。

    詳細については、「クラスタ、ホストおよび仮想マシンの最適化」を参照してください。

  5. ソフト・アフィニティをホストするように仮想マシンを構成し、アフィニティ・グループの動作を定義します。

    詳細は、oVirt Virtual Machine Management GuideのAffinity Groupsを参照してください。

    重要:

    VMアフィニティ・ルール「強制」を有効にすると(アフィニティ・グループのリストで「ハード」と表示)、システムは、アフィニティ・グループ内の他の仮想マシンが実行されているホストとは異なるホストに仮想マシンを移行しません。 詳細については、「Oracle Linux Virtualization Manager: リリース・ノート」の仮想マシンに関する問題を参照してください。

アクティブ・アクティブ型のフェイルオーバーは、メイン・サイトのホストをメンテナンス・モードにすることで手動で実行できます。

アクティブ・パッシブ型障害時リカバリ

Oracle Linux Virtualization Managerのアクティブ・パッシブ型障害時リカバリ・ソリューションは、2つのサイトにまたがることができます。 プライマリ・サイトが使用できなくなった場合、Oracle Linux Virtualization Manager環境を強制的にセカンダリ(バックアップ)サイトにフェイルオーバーできます。

フェイルオーバーを実現するには、セカンダリ・サイトを次のように構成します。

  • アクティブなOracle Linux Virtualization Managerエンジン。

  • データ・センターおよびクラスタ。

  • プライマリ・サイトと同じ一般接続を持つネットワーク。

  • フェイルオーバー後に重要な仮想マシンを実行できるアクティブなホスト。

重要:

フェイルオーバーされた仮想マシンを実行するのに十分なリソースがセカンダリ環境にあること、およびプライマリ環境とセカンダリ環境の両方でエンジン・バージョン、データ・センターとクラスタの互換性レベルおよびPostgreSQLバージョンが同じであることを確認する必要があります。

プライマリ・サイトに仮想マシン・ディスクおよびテンプレートを含む記憶域ドメインをレプリケートする必要があります。 これらのレプリケートされた記憶域ドメインをセカンダリ・サイトにアタッチしないでください。

フェイルオーバー・プロセスとフェイルバック・プロセスは、サイト間でエンティティのマップ、およびフェイルオーバー・プロセスとフェイルバック・プロセスの管理を行うAnsibleプレイブックを使用して手動で実行されます。 マッピング・ファイルでは、フェイルオーバー先またはフェイルバック先をOracle Linux Virtualization Managerコンポーネントに指示します。

ネットワークに関する考慮点

プライマリ・サイトとセカンダリ・サイトに同じ一般接続が存在することを確認する必要があります。 複数のネットワークまたは複数のデータ・センターがある場合は、マッピング・ファイルで空のネットワーク・マッピングを使用して、フェイルオーバー時にすべてのエンティティがターゲットに登録されるようにする必要があります。

記憶域に関する考慮事項

Oracle Linux Virtualization Managerの記憶域ドメインは、ブロック・デバイス(iSCSIまたはFCP)またはファイル・システム(NAS/NFSまたはGlusterFS)のいずれかで構成できます。 ローカル記憶域ドメインは障害時リカバリではサポートされていません。

環境には、プライマリおよびセカンダリ記憶域のレプリカが必要です。 仮想マシンのディスクまたはテンプレートを含むプライマリ記憶域ドメインのブロック・デバイスまたは共有をレプリケートする必要があります。 セカンダリ記憶域はどのデータ・センターにもアタッチしないでください。フェイルオーバー時にバックアップ・サイトのデータ・センターに追加されます。

自己ホスト・エンジンを使用して障害時リカバリを実装する場合は、記憶域ドメインがフェイルオーバーしないため、自己ホスト・エンジンのエンジン仮想マシンで使用される記憶域ドメインに仮想マシン・ディスクが含まれていないことを確認してください。

Oracle Linux 8以降でサポートされているレプリケーション・オプションを持つ記憶域ソリューションを使用できます。

重要:

すべての仮想マシンおよびディスクのメタデータは、OVF_STOREディスク・イメージとして記憶域データ・ドメインに存在します。 このメタデータは、記憶域データ・ドメインがフェイルオーバーまたはフェイルバックによって同じ環境または別の環境の別のデータ・センターに移動された場合に使用されます。

デフォルトでは、メタデータは60分間隔でエンジンによって自動的に更新されます。 これは、間隔中に完了したすべてのデータおよび処理が失われる可能性があることを意味します。 このような損失を回避するために、記憶域ドメイン・セクションに移動し、OVFの更新をクリックすることで、管理ポータルからメタデータを手動で更新できます。 または、エンジン・パラメータを変更して、更新頻度を変更できます。たとえば:

# engine-config -s OvfUpdateIntervalInMinutes=30 && systemctl restart ovirt-engine

詳細は、「Oracle Linux Virtualization Manager: 管理ガイド」および「Oracle Linux Virtualization Manager: アーキテクチャおよびプランニング・ガイド」の記憶域のトピックを参照してください。

Ansibleプレイブックの作成

Ansibleを使用すると、作成したAnsibleプレイブックを介してアクティブ・パッシブ型障害時リカバリのフェイルオーバーおよびフェイルバックを開始および管理します。 Ansibleプレイブックの詳細は、Ansibleドキュメントを参照してください。

Ansibleプレイブックの作成を開始する前に、次の前提条件と制限事項を確認してください。

  • プライマリ・サイトに、完全に機能するOracle Linux Virtualization Manager環境があります。

  • プライマリ環境と同じデータ・センターおよびクラスタの互換性レベルを持つ、セカンダリ・サイトのバックアップ環境。 バックアップ環境には次のものが必要です。

    • Oracle Linux Virtualization Managerエンジン

    • 仮想マシンを実行し、レプリケートされた記憶域ドメインに接続できるアクティブなホスト

    • データ・センターおよびクラスタ

    • プライマリ・サイトと同じ一般接続を持つネットワーク

  • セカンダリ・サイトにアタッチされていない仮想マシンおよびテンプレートを含むレプリケートされた記憶域。

  • フェイルオーバーおよびフェイルバックを自動化するには、ovirt-ansible-collectionパッケージを高可用性Ansibleエンジン・マシンにインストールする必要があります。

  • Ansible Engineを実行しているマシンは、SSHを使用してプライマリ・サイトおよびセカンダリ・サイトのエンジンに接続できる必要があります。

ノート:

アフィニティ・グループ、アフィニティ・ラベル、ユーザーなど、プライマリ・サイトに存在する環境プロパティをセカンダリ・サイトに作成することをお薦めします。 Ansibleプレイブックのデフォルトの動作は、/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/disaster_recovery/defaults/main.ymlファイルで構成できます。

次の必要なAnsibleプレイブックを作成する必要があります。

  • プライマリ・サイトとセカンダリ・サイトのエンティティをマップするファイルを作成するプレイブック

  • フェイルオーバー・プレイブック

  • フェイルバック・プレイブック

作成するプレイブックおよび関連ファイルは、フェイルオーバーおよびフェイルバックを管理するAnsibleマシンの/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/disaster_recoveryに存在する必要があります。 これを管理できるAnsibleマシンが複数ある場合は、すべてのマシンにファイルをコピーしてください。

アクティブ・パッシブ型障害時リカバリを構成したら、構成をテストして検証する必要があります。 「アクティブ/パッシブ構成のテスト」を参照してください。

ovirt-drスクリプトを使用したAnsibleタスクの簡略化

/usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/disaster_recoveryにあるovirt-drスクリプトを使用して、次のAnsibleタスクを簡略化できます:

  • フェイルオーバーおよびフォールバック用にプライマリ・サイトとセカンダリ・サイトのvarマッピング・ファイルを生成する

  • varマッピング・ファイルを検証する

  • ターゲット・サイトでフェイルオーバーを実行する

  • ターゲット・サイトからソース・サイトへのフェイルバックを実行する

ovirt-drスクリプトの例を次に示します。

# ./ovirt-dr generate/validate/failover/failback

[--conf-file=dr.conf]
[--log-file=ovirt-dr-log_number.log]
[--log-level=DEBUG/INFO/WARNING/ERROR]

オプションで、次のカスタマイズを行うことができます。

  • 構成ファイル内のスクリプト・アクションのパラメータを設定: /usr/share/ansible/collections/ansible_collections/ovirt/ovirt/roles/disaster_recovery/files/dr.conf

  • --conf-fileオプションを使用して、構成ファイルの場所を変更します

  • --log-fileオプションを使用してログ・ファイルの場所を設定します

  • --log-levelオプションを使用してロギングの詳細レベルを設定します

Ansibleプレイブックを使用したマッピング・ファイルの生成

マッピング・ファイルの生成に使用されるAnsibleプレイブックによって、ファイルにプライマリ・サイトのエンティティが事前移入されます。 その後、バックアップ・サイトのエンティティ(IPアドレス、クラスタ、アフィニティ・グループ、アフィニティ・ラベル、外部LUNディスク、承認ドメイン、ロール、vNICプロファイルなど)をファイルに手動で追加する必要があります。

重要:

自己ホスト・エンジンの記憶域ドメインに仮想マシン・ディスクがある場合、マッピング・ファイルの生成は失敗します。 また、この記憶域ドメインはフェイルオーバーが禁止されているため、生成されたマッピング・ファイルにはこの記憶域ドメインの属性が含まれません。

マッピング・ファイルを作成するには、次のステップを実行します。

  1. yamlファイル(dr-olvm-setup.ymlなど)を使用してAnsibleプレイブックを作成し、マッピング・ファイルを生成します。 たとえば:

    ---
    - name: Setup oVirt environment
      hosts: localhost
      connection: local
      vars:
         site: https://manager1.mycompany.com/ovirt-engine/api
         username: admin@internal
         password: Mysecret1
         ca: /etc/pki/ovirt-engine/ca.pem
         var_file: disaster_recovery_vars.yml
      roles:
         - disaster_recovery
      collections:
         - ovirt.ovirt

    セキュリティを強化するために、エンジンのパスワードを.ymlファイル内で暗号化できます。

  2. Ansibleコマンドを実行してマッピング・ファイルを生成します。 プライマリ・サイトの構成が事前移入されます。

    # ansible-playbook dr-olvm-setup.yml --tags "generate_mapping"
  3. バックアップ・サイトの構成で、生成されたマッピング.ymlファイルを構成します。 詳細については、「マッピング・ファイル属性」を参照してください。

フェイルオーバーおよびフェイルバックを実行できるAnsibleマシンが複数ある場合は、関連するすべてのマシンにマッピング・ファイルをコピーします。

フェイルオーバーおよびフェイルバック・プレイブックの作成

フェイルオーバーおよびフェイルバック・プレイブックを作成する前に、マッピング・ファイルを作成して設定し、プレイブックに追加しておく必要があります。

フェイルオーバーおよびフェイルバック・プレイブックを作成するには、次のステップを実行します。

  1. オプションで、プライマリ・サイトとセカンダリ・サイトのエンジン・パスワードを格納するためのパスワード・ファイル(passwords.ymlなど)を定義します。次に例を示します。

    ---
    # This file is in plain text, if you want to
    # encrypt this file, please execute following command:
    #
    # $ ansible-vault encrypt passwords.yml
    #
    # It will ask you for a password, which you must then pass to
    # ansible interactively when executing the playbook.
    #
    # $ ansible-playbook myplaybook.yml --ask-vault-pass
    #
    dr_sites_primary_password: primary_password
    dr_sites_secondary_password: secondary_password

    セキュリティを強化するために、パスワード・ファイルを暗号化できます。 ただし、プレイブックの実行時には--ask-vault-passパラメータを使用する必要があります。

  2. フェイルオーバーyamlファイル(dr-olvm-failover.ymlなど)を使用してAnsibleプレイブックを作成し、環境をフェイルオーバーします。次に例を示します:

    ---
    - name: oVirt Failover
      hosts: localhost
      connection: local
      vars:
         dr_target_host: secondary
         dr_source_map: primary
      vars_files:
         - disaster_recovery_vars.yml
      roles:
         - disaster_recovery
      collections:
         - ovirt.ovirt
  3. フェイルバックyamlファイル(dr-olvm-failback.ymlなど)を使用してAnsibleプレイブックを作成し、環境をフェイルバックします。次に例を示します:

    ---
    - name: oVirt Failback
      hosts: localhost
      connection: local
      vars:
         dr_target_host: primary
         dr_source_map: secondary
      vars_files:
         - disaster_recovery_vars.yml
      roles:
         - disaster_recovery
      collections:
         - ovirt.ovirt

フェイルオーバーの実行

フェイルオーバーを実行する前に、「ネットワークに関する考慮事項」および「記憶域に関する考慮事項」を読んで理解していることを確認してください。 次の点も確認する必要があります:

  • セカンダリ・サイトのエンジンおよびホストが実行されている。

  • レプリケートされた記憶域ドメインが読取り/書込みモードである。

  • レプリケートされた記憶域ドメインがセカンダリ・サイトにアタッチされていない。

  • SSHを介してプライマリ・サイトおよびセカンダリ・サイトのエンジンに接続できるAnsible Engineを実行しているマシン。このマシンに必要なパッケージおよびファイルは次のとおりです。

    • ovirt-ansible-collectionパッケージ。

    • マッピング・ファイルとフェイルオーバー・プレイブック。

Sanlockは、フェイルオーバー・プロセスを開始する前に、レプリケートされた記憶域ドメインからすべてのストレージ・ロックを解除する必要があります。 これらのロックは、障害が発生してから約80秒後に自動的に解除されます。

フェイルオーバーを実行するには、次のコマンドを使用してエンジン・ホストでフェイルオーバー・プレイブックを実行します。

# ansible-playbook dr-olvm-failover.yml --tags "fail_over"

プライマリ・サイトがアクティブになったら、フェイルバックする前に環境をクリーン・アップしてください。 詳細については、「プライマリ・サイトの消去」を参照してください。

プライマリ・サイトのクリーニング

フェイルオーバー後、プライマリ・サイトにフェイルバックする前にプライマリ・サイトの環境をクリーン・アップする必要があります。 プライマリ・サイトの環境のクリーニング:

  • プライマリ・サイトのすべてのホストを再起動します。

  • セカンダリ・サイトの記憶域ドメインが読取り/書込みモードで、プライマリ・サイトの記憶域ドメインが読取り専用モードであることを確認します。

  • セカンダリ・サイトの記憶域ドメインからプライマリ・サイトの記憶域ドメインにレプリケーションを同期します。

  • インポートするすべての記憶域ドメインのプライマリ・サイトをクリーニングします。 これはエンジンで手動で行うことができます。 詳細は、データ・センターからの記憶域ドメインのデタッチを参照してください。

たとえば、クリーンアップymlファイル(dr_cleanup_primary_site.ymlなど)を作成します:

---
- name: oVirt Cleanup Primary Site
  hosts: localhost
  connection: local
  vars:
     dr_source_map: primary
  vars_files:
     - disaster_recovery_vars.yml
  roles:
     - disaster_recovery
  collections:
     - ovirt.ovirt

プライマリ・サイトをクリーン・アップしたら、環境をプライマリ・サイトにフェイルバックできます。 詳細については、「フェイルバックの実行」を参照してください。

フェイルバックの実行

フェイルオーバー後、プライマリ・サイトがアクティブで、環境をクリーン・アップするために必要なステップを実行すると、プライマリ・サイトにフェイルバックできます。必要なステップとして、次のことを確認してください。

  • プライマリ・サイトの環境が実行中であり、クリーン・アップされている。 詳細については、「プライマリ・サイトの消去」を参照してください。

  • セカンダリ・サイトの環境が実行中であり、アクティブな記憶域ドメインがある。

  • SSHを介してプライマリ・サイトおよびセカンダリ・サイトのエンジンに接続できるAnsible Engineを実行しているマシン。このマシンに必要なパッケージおよびファイルは次のとおりです。

    • ovirt-ansible-collectionパッケージ。

    • マッピング・ファイルと必要なフェイルバック・プレイブック。

フェイルバックを実行するには、次のステップを実行します。

  1. 次のコマンドを使用して、エンジン・ホストでフェイルバック・プレイブックを実行します。

    #  ansible-playbook dr-olvm-failback.yml --tags "fail_back"
  2. プライマリ記憶域ドメインからセカンダリ記憶域ドメインへのレプリケーションを有効にします。

アクティブ・パッシブ構成のテスト

障害時リカバリ・ソリューションは、構成した後に、次のいずれかのオプションを使用してテストする必要があります。

  1. プライマリ・サイトがアクティブなままで、プライマリ・サイトの記憶域ドメイン上の仮想マシンに干渉せずにフェイルオーバーをテストします。 「分離フェイルオーバー・テスト」を参照してください。

  2. プライマリ・サイトにアタッチされた特定の記憶域ドメインを使用してフェイルオーバーおよびフェイルバックをテストします。これにより、プライマリ・サイトはアクティブなままになります。 「フェイルオーバーおよびフェイルバック・テストのクリーティング」を参照してください。

  3. セカンダリ・サイトへのフェイルオーバーに猶予期間があるプライマリ・サイトの計画外停止または差し迫った障害に備えて、フェイルオーバーおよびフェイルバックをテストします。 「完全フェイルオーバーおよびフェイルバック・テスト」を参照してください。

重要:

これらのテストを実行する前に、アクティブ・パッシブ型障害時リカバリを構成するすべてのステップが完了していることを確認してください。

 ディスクリート・フェイルオーバー・テスト

ディスクリート・フェイルオーバー・テストでは、フェイルオーバーのシミュレート中にプライマリ・サイトとそのすべての記憶域ドメインがアクティブなままであるため、ユーザーはプライマリ・サイトで作業を続行できます。 このテストを実行するには、プライマリ記憶域ドメインとレプリケートされた(セカンダリ)記憶域ドメイン間のレプリケーションを無効にする必要があります。 このテスト中、プライマリ・サイトはセカンダリ・サイトのフェイルオーバー・アクティビティを認識しません。

このテストでは、フェイルバック機能をテストできません。

重要:

フェイルオーバー後に本番タスクが実行されないようにしてください。 たとえば、電子メール・システムで実際のユーザーへの電子メールの送信や他の場所への電子メールのリダイレクトがブロックされていることを確認します。 システムを使用して他のシステムを直接管理する場合は、システムへのアクセスを禁止するか、セカンダリ・サイトのパラレル・システムにアクセスするようにします。

ディスクリート・フェイルオーバー・テストを実行するには、次のステップを実行します。

  1. プライマリ記憶域ドメインとレプリケートされた記憶域ドメイン間の記憶域レプリケーションを無効にし、レプリケートされたすべての記憶域ドメインが読取り/書込みモードであることを確認します。

  2. 次のコマンドを実行して、セカンダリ・サイトにフェイルオーバーします。

    # ansible-playbook playbook --tags "fail_over"
  3. 関連するすべての記憶域ドメイン、仮想マシンおよびテンプレートが登録され、セカンダリ・サイトで正常に実行されていることを確認します。

環境をアクティブ・パッシブ状態にリストアするには、次のステップを実行します。

  1. セカンダリ・サイトから記憶域ドメインをデタッチします。

  2. プライマリ記憶域ドメインとセカンダリ記憶域ドメイン間の記憶域レプリケーションを有効にします。

 ディスクリート・フェイルオーバーおよびフェイルバック・テスト

ディスクリート・フェイルオーバーおよびフェイルバック・テストでは、フェイルオーバーおよびフェイルバックのテスト用に特別に定義したテスト可能な記憶域ドメインが使用されます。 これらのストレージ・ドメインは、レプリケートされた記憶域をセカンダリ・サイトにアタッチできるようにレプリケートする必要があります。これにより、ユーザーがプライマリ・サイトで作業を続行しながらフェイルオーバーをテストできます。

ノート:

テスト可能な記憶域ドメインは、プライマリ・サイトで本番用に使用されるプライマリ記憶域ドメインに影響を与えずにオフラインにできる別の記憶域サーバー上に定義する必要があります。

ディスクリート・フェイルオーバー・テストを実行するには、次のステップを実行します。

  1. プライマリ・サイトのテスト記憶域ドメインを停止します。 たとえば、サーバー・ホストを停止するか、ファイアウォール・ルールでブロックします。

  2. テスト可能な記憶域ドメイン間の記憶域レプリケーションを無効にし、テストに使用されるすべてのレプリケートされた記憶域ドメインが読取り/書込みモードであることを確認します。

  3. テスト用プライマリ記憶域ドメインを読取り専用モードにします。

  4. コマンドを実行して、セカンダリ・サイトにフェイルオーバーします。

    # ansible-playbook playbook --tags "fail_over"
  5. 関連するすべての記憶域ドメイン、仮想マシンおよびテンプレートが登録され、セカンダリ・サイトで正常に実行されていることを確認します。

ディスクリート・フェイルバック・テストを実行するには、次のステップを実行します。

  1. プライマリ・サイトをクリーニングし、すべての非アクティブな記憶域ドメインおよび関連する仮想マシンとテンプレートを削除します。 詳細については、「プライマリ・サイトの消去」を参照してください。

  2. コマンドを実行してプライマリ・サイトにフェイルバックします。

    # ansible-playbook playbook --tags "fail_back"
  3. プライマリ記憶域ドメインからセカンダリ記憶域ドメインへのレプリケーションを有効にします。

  4. 関連するすべての記憶域ドメイン、仮想マシンおよびテンプレートが登録され、プライマリ・サイトで正常に実行されていることを確認します。

 完全フェイルオーバーおよびフェイルバック・テスト

完全フェイルオーバーおよびフェイルバック・テストでは、プライマリ・サイトの障害、セカンダリ・サイトへのフェイルオーバーおよびプライマリ・サイトへのフェイルバックをシミュレートできます。 プライマリ・サイトの障害をシミュレートするには、プライマリ・サイトのホストを停止するか、記憶域ドメインへの書込みをブロックするファイアウォール・ルールを追加します。

完全フェイルオーバー・テストを実行するには、次のステップを実行します。

  1. プライマリ記憶域ドメインとレプリケートされた記憶域ドメイン間の記憶域レプリケーションを無効にし、レプリケートされたすべての記憶域ドメインが読取り/書込みモードであることを確認します。

  2. コマンドを実行して、セカンダリ・サイトにフェイルオーバーします。

    # ansible-playbook playbook --tags "fail_over"
  3. 関連するすべての記憶域ドメイン、仮想マシンおよびテンプレートが登録され、セカンダリ・サイトで正常に実行されていることを確認します。

完全フェイルバック・テストを実行するには、次のステップを実行します。

  1. セカンダリ・サイトの記憶域ドメインとプライマリ・サイトの記憶域ドメイン間のレプリケーションを同期します。 セカンダリ・サイトの記憶域ドメインは読取り/書込みモードで、プライマリ・サイトの記憶域ドメインは読取り専用モードである必要があります。

  2. プライマリ・サイトをクリーニングし、すべての非アクティブな記憶域ドメインおよび関連する仮想マシンとテンプレートを削除します。 詳細については、「プライマリ・サイトの消去」を参照してください。

  3. コマンドを実行してプライマリ・サイトにフェイルバックします。

    # ansible-playbook playbook --tags "fail_back"
  4. プライマリ記憶域ドメインからセカンダリ記憶域ドメインへのレプリケーションを有効にします。

  5. 関連するすべての記憶域ドメイン、仮想マシンおよびテンプレートが登録され、プライマリ・サイトで正常に実行されていることを確認します。

ファイル属性のマッピング

マッピング・ファイルの属性は、アクティブ・パッシブ型障害時リカバリ・ソリューションで2つのサイト間のフェイルオーバーおよびフェイルバックに使用されます。

  • サイトの詳細

    プライマリ・サイトとセカンダリ・サイトでエンジンの詳細をマップする属性。たとえば:

    dr_sites_primary_url: https://manager1.mycompany.com/ovirt-engine/api
    dr_sites_primary_username: admin@internal
    dr_sites_primary_ca_file: /etc/pki/ovirt-engine/ca.pem
    
    # scp manager2:/etc/pki/ovirt-engine/ca.pem /var/tmp/secondary-ca.pem
    
    # Please fill in the following properties for the secondary site:
    dr_sites_secondary_url: https://manager2.mycompany.com/ovirt-engine/api
    dr_sites_secondary_username: admin@internal
    dr_sites_secondary_ca_file: /var/tmp/secondary-ca.pem
  • 記憶域ドメインの詳細

    プライマリ・サイトとセカンダリ・サイトで記憶域ドメインの詳細をマップする属性。たとえば:

    dr_import_storages:
    - dr_domain_type: nfs
      dr_primary_name: DATA
      dr_master_domain: True
      dr_wipe_after_delete: False
      dr_backup: False
      dr_critical_space_action_blocker: 5
      dr_warning_low_space: 10
      dr_primary_dc_name: Default
      dr_discard_after_delete: False
      dr_primary_path: /storage/data
      dr_primary_address: 10.64.100.xxx
      # Fill in the empty properties related to the secondary site
      dr_secondary_dc_name: Default
      dr_secondary_path: /storage/data2
      dr_secondary_address:10.64.90.xxx
      dr_secondary_name: DATA
  • クラスタの詳細

    プライマリ・サイトとセカンダリ・サイトでクラスタ名をマップする属性。たとえば:

    dr_cluster_mappings:
      - primary_name: cluster_prod
        secondary_name: cluster_recovery
      - primary_name: fc_cluster
        secondary_name: recovery_fc_cluster
  • アフィニティ・グループの詳細

    仮想マシンが属するアフィニティ・グループをマップする属性。たとえば:

    dr_affinity_group_mappings:
    - primary_name: affinity_prod
      secondary_name: affinity_recovery
  • アフィニティ・ラベルの詳細

    仮想マシンが属するアフィニティ・ラベルをマップする属性。たとえば:

    dr_affinity_label_mappings:
    - primary_name: affinity_label_prod
      secondary_name: affinity_label_recovery
  • ドメイン認証、認可およびアカウンティングの詳細

    プライマリ・サイトとセカンダリ・サイトで認可の詳細をマップする属性。たとえば:

    dr_domain_mappings:
    - primary_name: internal-authz
      secondary_name: recovery-authz
    - primary_name: external-authz
      secondary_name: recovery2-authz
  • ロールの詳細

    特定のロールのマッピングを提供する属性。たとえば:

    dr_role_mappings:
    - primary_name: admin
      Secondary_name: newadmin
  • ネットワークの詳細

    プライマリ・サイトとセカンダリ・サイトでvNICの詳細をマップする属性。たとえば:

    dr_network_mappings:
    - primary_network_name: ovirtmgmt
      primary_profile_name: ovirtmgmt
      primary_profile_id: 0000000a-000a-000a-000a-000000000398
      # Fill in the correlated vnic profile properties in the secondary site for profile 'ovirtmgmt'
      secondary_network_name: ovirtmgmt
      secondary_profile_name: ovirtmgmt
      secondary_profile_id:  0000000a-000a-000a-000a-000000000410

    複数のネットワークまたは複数のデータ・センターがある場合は、マッピング・ファイルで空のネットワーク・マッピングを使用して、フェイルオーバー時にすべてのエンティティがターゲットに登録されるようにする必要があります。たとえば:

    dr_network_mappings:
    # No mapping should be here
  • 外部LUNディスクの詳細

    LUN属性を使用すると、フェイルオーバーおよびフェイルバック後に仮想マシンを適切な外部LUNディスクに登録できます。たとえば:

    dr_lun_mappings:
    - primary_logical_unit_id: 460014069b2be431c0fd46c4bdce29b66
      primary_logical_unit_alias: My_Disk
      primary_wipe_after_delete: False
      primary_shareable: False
      primary_logical_unit_description: 2b66
      primary_storage_type: iscsi
      primary_logical_unit_address: 10.35.xx.xxx
      primary_logical_unit_port: 3260
      primary_logical_unit_portal: 1
      primary_logical_unit_target: iqn.2017-12.com.prod.example:444
      secondary_storage_type: iscsi
      secondary_wipe_after_delete: False
      secondary_shareable: False
      secondary_logical_unit_id: 460014069b2be431c0fd46c4bdce29b66
      secondary_logical_unit_address: 10.35.x.xxx
      secondary_logical_unit_port: 3260
      secondary_logical_unit_portal: 1
      secondary_logical_unit_target: iqn.2017-12.com.recovery.example:444