検索
サポートコンソール開発者トライアルの開始お問い合わせ

第16章 バックアップおよび移行

download PDF

16.1. Red Hat Virtualization Manager のバックアップおよび復元

16.1.1. Red Hat Virtualization Manager のバックアップ - 概要

engine-backup ツールを使用して、Red Hat Virtualization Manager の定期的なバックアップを作成します。このツールは、エンジンデータベースおよび設定ファイルを 1 つのファイルにバックアップし、ovirt-engine サービスを中断することなく実行できます。

16.1.2. engine-backup コマンドの構文

engine-backup コマンドは、次の 2 つの基本モードのいずれかで機能します。 

# engine-backup --mode=backup
# engine-backup --mode=restore

これらの 2 つのモードは、バックアップの範囲とエンジンデータベースのさまざまな認証情報を指定できる一連のパラメーターによってさらに拡張されます。パラメーターとその機能の完全なリストについては、engine-backup --help を実行してください。

Basic Options

--mode
コマンドがバックアップ操作を実行するか、復元操作を実行するかを指定します。backup と restore の 2 つのオプションを使用できます。これは必須パラメーターです。
--file
バックアップモードでバックアップを取得するファイルのパスおよび名前、ならびに復元モードでバックアップデータを読み取るファイルのパスおよび名前を指定します。これは、バックアップモードと復元モードの両方で必須のパラメーターです。
--log
バックアップまたは復元操作のログが書き込まれるファイルのパスおよび名前を指定します。このパラメーターは、バックアップモードと復元モードの両方で必要です。
--scope

バックアップまたは復元操作の範囲を指定します。4 つのオプションがあります。all は、すべてのデータベースおよび設定データをバックアップまたは復元します。files は、システム上のファイルのみをバックアップまたは復元します。db は、Manager データベースのみをバックアップまたは復元します。dwhdb は、Data Warehouse データベースのみをバックアップまたは復元します。デフォルトのスコープは all です。

--scope パラメーターは、同じ engine-backup コマンドで複数回指定できます。

Manager Database Options

次のオプションは、restore モードで engine-backup コマンドを使用する場合にのみ使用できます。以下のオプション構文は、Manager データベースの復元に適用されます。Data Warehouse データベースを復元するための同じオプションがあります。Data Warehouse オプションの構文は、engine-backup --help を参照してください。

--provision-db
復元先の Manager データベースバックアップ用の PostgreSQL データベースを作成します。これは、PostgreSQL データベースがまだ設定されていないリモートホストまたは新規インストールでバックアップを復元する場合に必要なパラメーターです。
--change-db-credentials
バックアップ自体に保存されている認証情報以外の認証情報を使用して、Manager データベースを復元するための代替認証情報を指定できます。このパラメーターで必要な追加パラメーターは、engine-backup --help を参照してください。
--restore-permissions または --no-restore-permissions

データベースユーザーの権限を復元します (または復元しません)。バックアップを復元するときは、これらのパラメーターの 1 つが必要です。

注記

バックアップに追加のデータベースユーザーの許可が含まれている場合、--restore-permissions および --provision-db (または --provision-dwh-db) オプションを使用してバックアップを復元すると、ランダムなパスワードを持つ追加のユーザーが作成されます。追加のユーザーが復元したシステムにアクセスする必要がある場合は、これらのパスワードを手動で変更する必要があります。https://access.redhat.com/articles/2686731 を参照してください。

16.1.3. engine-backup コマンドを使用したバックアップの作成

Red Hat Virtualization Manager は、Manager がアクティブな場合に engine-backup コマンドを使用してバックアップできます。以下のオプションのいずれかを --scope に追加し、実行するバックアップを指定します。

  • all: Manager 上のすべてのデータベースおよび設定ファイルの完全バックアップ
  • files: システム上のファイルのみのバックアップ
  • db: Manager データベースのみのバックアップ
  • dwhdb: データウェアハウスデータベースのみのバックアップ
重要

データベースを Red Hat Virtualization Manager の新規インストールに復元するには、データベースのバックアップだけでは不十分です。Manager では設定ファイルへのアクセスも必要です。デフォルト以外のスコープを指定するバックアップ。all は files スコープまたはファイルシステムのバックアップを一緒に指定する必要があります。

engine-backup コマンドの使用例

  1. Red Hat Virtualization Manager を実行しているマシンにログインします。

  2. バックアップを作成します。

    例16.1 完全バックアップの作成

    # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name

    例16.2 Manager データベースのバックアップの作成

    # engine-backup --scope=files --scope=db --mode=backup --file=file_name --log=log_file_name

    db オプションは、Data Warehouse データベースをバックアップする dwhdb に置き換えます。

    バックアップを含む tar ファイルは、指定したパスとファイル名を使用して作成されます。

バックアップを含む tar ファイルを使用して、環境を復元できるようになりました。

16.1.4. engine-backup コマンドを使用したバックアップの復元

engine-backup コマンドを使用してバックアップを復元するには、復元先によっては、バックアップを作成するよりも多くの手順が必要です。たとえば、engine-backup コマンドを使用して、Red Hat Virtualization の既存のインストールに加えて、ローカルまたはリモートのデータベースを使用して、Red Hat Virtualization の新規インストールにバックアップを復元できます。

重要

バックアップは、バックアップと同じメジャーリリースの環境にのみ復元できます。たとえば、Red Hat Virtualization バージョン 4.2 環境のバックアップは、別の Red Hat Virtualization バージョン 4.2 環境にのみ復元できます。バックアップファイルに含まれている Red Hat Virtualization のバージョンを表示するには、バックアップファイルを解凍し、解凍されたファイルのルートディレクトリーにある version ファイルの値を読み取ります。

16.1.5. バックアップを新規インストールに復元する

engine-backup コマンドを使用して、Red Hat Virtualization Manager の新規インストールにバックアップを復元できます。以下の手順は、ベースオペレーティングシステムがインストールされ、Red Hat Virtualization Manager に必要なパッケージがインストールされているが、engine-setup コマンドがまだ実行されていないマシンで実行する必要があります。この手順は、バックアップを復元するマシンから 1 つまたは複数のバックアップファイルにアクセスできることを前提としています。

バックアップを新規インストールに復元する

  1. Manager マシンにログインします。エンジンデータベースをリモートホストに復元する場合は、そのホストにログオンして、関連するアクションを実行する必要があります。同様に、Data Warehouse をリモートホストにも復元する場合は、そのホストにログオンして、関連するアクションを実行する必要があります。

  2. 完全バックアップまたはデータベースのみのバックアップを復元します。

    • 完全バックアップを復元します。 

      # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions

      完全バックアップの一部として Data Warehouse も復元される場合は、追加のデータベースをプロビジョニングします。 

      engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --provision-dwh-db --restore-permissions

    • 設定ファイルとデータベースバックアップを復元して、データベースのみのバックアップを復元します。 

      # engine-backup --mode=restore --scope=files --scope=db --file=file_name --log=log_file_name --provision-db --restore-permissions

      上記の例では、Manager データベースのバックアップを復元します。 

      # engine-backup --mode=restore --scope=files --scope=dwhdb --file=file_name --log=log_file_name --provision-dwh-db --restore-permissions

      上記の例では、Data Warehouse データベースのバックアップを復元します。

      成功すると、次の出力が表示されます。 

      You should now run engine-setup.
Done.

  3. 次のコマンドを実行し、プロンプトに従って復元された Manager を設定します。 

    # engine-setup

Red Hat Virtualization Manager は、バックアップに保存されているバージョンに復元されました。新しい Red Hat Virtualization システムの完全修飾ドメイン名を変更するには、「oVirt エンジンの名前変更ツール」 を参照してください。

16.1.6. バックアップを復元して既存のインストールを上書き

engine-backup コマンドを使用すると、Red Hat Virtualization Manager がすでにインストールおよび設定されているマシンにバックアップを復元できます。これは、環境のバックアップを取り、その環境で変更を実行し、バックアップから環境を復元して変更を元に戻したい場合に役立ちます。

ホストの追加や削除など、バックアップの作成後に環境に加えられた変更は、復元された環境には表示されません。これらの変更をやり直す必要があります。

手順

  1. Manager マシンにログインします。

  2. 設定ファイルを削除し、Manager に関連付けられているデータベースをクリーンアップします。 

    # engine-cleanup

    engine-cleanup コマンドは、Manager データベースのみを削除します。データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。

  3. フルバックアップまたはデータベースのみのバックアップを復元します。ユーザーとデータベースがすでに存在しているので、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。

    • 完全バックアップを復元します。 

      # engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions

    • 設定ファイルおよびデータベースバックアップを復元して、データベースのみのバックアップを復元します。 

      # engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions
      注記

      Manager データベースのみを復元するには (たとえば、Data Warehouse データベースが別のマシンにある場合)、-scope=dwhdb パラメーターを省略できます。

      成功すると、次の出力が表示されます。 

      You should now run engine-setup.
Done.

  4. Manager を再設定します。 

    # engine-setup

16.1.7. 異なる認証情報を使用したバックアップの復元

engine-backup コマンドは、Red Hat Virtualization Manager がすでにインストールされセットアップされているマシンにバックアップを復元することができますが、バックアップ内のデータベースの認証情報は、バックアップを復元するマシン上のデータベースの認証情報とは異なっています。これは、インストールのバックアップを取り、バックアップから別のシステムにインストールを復元する場合に役立ちます。

重要

バックアップを復元して既存のインストールを上書きする場合は、engine-backup コマンドを使用する前に、engine-cleanup コマンドを実行して既存のインストールをクリーンアップする必要があります。engine-cleanup コマンドは、エンジンデータベースをクリーンアップするだけで、データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。したがって、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。ただし、エンジンデータベースの所有者の認証情報がわからない場合は、バックアップを復元する前に認証情報を変更する必要があります。

異なる認証情報を使用したバックアップの復元

  1. Red Hat Virtualization Manager マシンにログインします。

  2. 次のコマンドを実行し、プロンプトに従って Manager の設定ファイルを削除し、Manager のデータベースをクリーンアップします。 

    # engine-cleanup

  3. engine データベースの所有者のパスワードがわからない場合は、そのユーザーのパスワードを変更します。

    1. postgresql コマンドラインを入力します。 

      # su - postgres -c 'scl enable rh-postgresql10 -- psql'

    2. engine データベースを所有するユーザーのパスワードを変更します。 

      postgres=# alter role user_name encrypted password 'new_password';

      必要に応じて、ovirt_engine_history データベースを所有するユーザーに対してこれを繰り返します。

  4. --change-db-credentials パラメーターを使用して完全バックアップまたはデータベースのみのバックアップを復元し、新しいデータベースの認証情報を渡します。Manager にローカルなデータベースの database_location は localhost です。

    注記

    次の例では、パスワードを指定せずにデータベースごとに --*password オプションを使用します。これにより、データベースごとにパスワードの入力を求められます。または、データベースごとに --*passfile=password_file オプションを使用して、対話型プロンプトを必要とせずに、パスワードを engine-backup ツールに安全に渡すことができます。

    • 完全バックアップを復元します。 

      # engine-backup --mode=restore --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --no-restore-permissions

      Data Warehouse も完全バックアップの一部として復元される場合は、追加のデータベースの改訂された認証情報を含めます。 

      engine-backup --mode=restore --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --change-dwh-db-credentials --dwh-db-host=database_location --dwh-db-name=database_name --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions

    • 設定ファイルおよびデータベースバックアップを復元して、データベースのみのバックアップを復元します。 

      # engine-backup --mode=restore --scope=files --scope=db --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --no-restore-permissions

      上記の例では、Manager データベースのバックアップを復元します。 

      # engine-backup --mode=restore --scope=files --scope=dwhdb --file=file_name --log=log_file_name --change-dwh-db-credentials --dwh-db-host=database_location --dwh-db-name=database_name --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions

      上記の例では、Data Warehouse データベースのバックアップを復元します。

      成功すると、次の出力が表示されます。 

      You should now run engine-setup.
Done.

  5. 次のコマンドを実行し、プロンプトに従ってファイアウォールを再設定し、ovirt-engine サービスが正しく設定されていることを確認します。 

    # engine-setup

16.1.8. セルフホスト型エンジンのバックアップおよび復元

セルフホスト型エンジンをバックアップして、新しいセルフホスト環境に復元できます。この手順は、環境を別のストレージタイプの新しいセルフホスト型エンジンストレージドメインに移行するなどのタスクに使用します。

デプロイメント中にバックアップファイルを指定すると、バックアップは、新しいセルフホスト型エンジンストレージドメインを使用して、新しい Manager 仮想マシンに復元されます。古い Manager が削除され、古いセルフホスト型エンジンストレージドメインの名前が変更され、新しい環境が正しく機能していることを確認した後、手動で削除できます。新規ホストにデプロイすることを強く推奨します。デプロイメント用のホストがバックアップ環境に存在している場合は、新しい環境で競合を回避するために、復元されたデータベースから削除されます。

バックアップと復元の操作には、次の主要なアクションが含まれます。

  1. engine-backup ツールを使用して元の Manager をバックアップします。
  2. 新しいセルフホスト型エンジンをデプロイし、バックアップを復元します。
  3. 新しい Manager 用仮想マシンで Manager のリポジトリーを有効にします。
  4. セルフホスト型エンジンノードを再インストールして、設定を更新します。
  5. 古いセルフホスト型エンジンストレージドメインを削除します。

この手順の前提として、移行元の Manager に対するアクセス権があり、変更を加えることできる必要があります。

前提条件

  • Manager とホスト用に用意された完全修飾ドメイン名。正引き (フォワードルックアップ) と逆引き (リバースルックアップ) の記録は両方とも DNS で設定する必要があります。新しい Manager は、元の Manager と同じ完全修飾ドメイン名を持っている必要があります。
  • 元の Manager を最新のマイナーバージョンに更新する必要があります。バックアップファイルの Manager バージョンは、新しい Manager のバージョンと一致する必要があります。Upgrade Guide の Updating the Red Hat Virtualization Manager を参照してください。

  • 環境内に少なくとも 1 つの通常のホストが存在する必要があります。このホスト (およびその他の通常のホスト) は、SPM ロールおよび実行中の仮想マシンをホストするためにアクティブなままになります。通常のホストがまだ SPM でない場合は、バックアップを作成する前に、通常のホストを選択し、Management Select as SPM をクリックして、SPM のロールを移動します。

    通常のホストが利用できない場合、1 つを追加する方法は 2 つあります。

16.1.8.1. 元の Manager のバックアップ

engine-backup コマンドを使用して元の Manager をバックアップし、バックアップファイルを別の場所にコピーして、処理中にいつでもアクセスできるようにします。

engine-backup --mode=backup オプションの詳細は、Administration Guide の Backing Up and Restoring the Red Hat Virtualization Manager を参照してください。

手順

  1. セルフホスト型エンジンノードの 1 つにログインし、環境をグローバルメンテナンスモードに移行します。 

    # hosted-engine --set-maintenance --mode=global

  2. 元の Manager にログインし、ovirt-engine サービスを停止します。 

    # systemctl stop ovirt-engine
# systemctl disable ovirt-engine
    注記

    元の Manager の実行を停止するのは必須ではありませんが、バックアップの作成後に環境を変更しないように推奨しています。さらに、元の Manager と新しい Manager が既存リソースを同時に管理しないようにします。

  3. 作成するバックアップファイルの名前と、バックアップログを保存するログファイルの名前を指定して、engine-backup コマンドを実行します。 

    # engine-backup --mode=backup --file=file_name --log=log_file_name

  4. ファイルを外部サーバーにコピーします。以下の例では、storage.example.com は、必要となるまでバックアップを保存するネットワークストレージサーバーの完全修飾ドメイン名です。/backup/ は指定のフォルダーまたはパスです。 

    # scp -p file_name log_file_name storage.example.com:/backup/

  5. 他の目的で Manager マシンが必要ない場合は、Red Hat Subscription Manager から登録を解除します。 

    # subscription-manager unregister

  6. セルフホスト型エンジンノードの 1 つにログインし、元の Manager 仮想マシンをシャットダウンします。 

    # hosted-engine --vm-shutdown

Manager のバックアップ後に、新しいセルフホスト型エンジンをデプロイし、新しい仮想マシンにバックアップを復元します。

16.1.8.2. 新しいセルフホスト型エンジンでのバックアップの復元

hosted-engine スクリプトを新規ホストで実行し、デプロイメント中に --restore-from-file=path/to/file_name オプションを使用して Manager バックアップを復元します。

重要

iSCSI ストレージを使用し、イニシエーターの ACL に従い、iSCSI ターゲットフィルターを使用して接続をフィルターする場合に、デプロイメントは STORAGE_DOMAIN_UNREACHABLE エラーで失敗する可能性があります。これを回避するには、セルフホスト型エンジンのデプロイメントを開始する前に iSCSI 設定を更新する必要があります。

  • 既存のホストに再デプロイする場合には、/etc/iscsi/initiatorname.iscsi でホストの iSCSI イニシエーター設定を更新する必要があります。イニシエーター IQN は、iSCSI ターゲットで以前にマッピングされていたものと同じか、または 必要に応じて新しい IQN に更新する必要があります。
  • 新規ホストにデプロイする場合は、iSCSI ターゲット設定を更新して、ホストからの接続を受け入れる必要があります。

IQN はホスト側 (iSCSI イニシエーター) またはストレージ側 (iSCSI ターゲット) で更新できることに注意してください。

手順

  1. バックアップファイルを新規ホストにコピーします。以下の例では、host.example.com はホストの FQDN で、/backup/ は指定されたフォルダーまたはパスです。 

    # scp -p file_name host.example.com:/backup/

  2. 新しいホストにログインします。Red Hat Virtualization ホストにデプロイする場合、デフォルトでセルフホストエンジンデプロイメントツールを使用できます。Red Hat Enterprise Linux にデプロイする場合は、以下のパッケージをインストールする必要があります。 

    # yum install ovirt-hosted-engine-setup

  3. Red Hat は、ネットワークまたはターミナルが中断した場合にセッションが失われないように、screen ウィンドウマネージャーを使用してスクリプトを実行することをお勧めします。screen をインストールして実行します。 

    # yum install screen
# screen

    セッションのタイムアウトまたは接続の中断が発生した場合は、screen-d-r を実行してデプロイメントセッションを復元します。

  4. バックアップファイルへのパスを指定して hosted-engine スクリプトを実行します。 

    # hosted-engine --deploy --restore-from-file=backup/file_name

    任意のタイミングでスクリプトをエスケープするには、CTRL+D を使用してデプロイメントを中止します。

  5. Yes を選択してデプロイメントを開始します。
  6. ネットワークを設定します。スクリプトにより、環境の管理ブリッジとして使用する NIC 候補が検出されます。
  7. 仮想マシンのインストールにカスタムアプライアンスを使用する場合は、OVA アーカイブへのパスを入力します。使用しない場合は、このフィールドを空欄のままにして RHV-M Appliance を使用します。
  8. Manager 仮想マシンの完全修飾ドメイン名 (FQDN) を指定します。
  9. Manager の root パスワードを入力します。
  10. root ユーザーとして Manager にログインできる SSH 公開鍵を入力し、root ユーザーの SSH アクセスを有効にするかどうかを指定します。
  11. 仮想マシンの CPU およびメモリー設定を入力します。
  12. Manager 用仮想マシンの MAC アドレスを入力するか、無作為に生成される MAC アドレスを適用します。Manager 用仮想マシンへの IP アドレス割り当てに DHCP を使用するには、この MAC アドレスに有効な DHCP 予約があることを確認してください。デプロイメントスクリプトは、DHCP サーバーの設定は行いません。

  13. 仮想マシンのネットワーク情報を入力します。Static を指定する場合には、Manager の IP アドレスを入力します。

    重要

    静的 IP アドレスは、ホストと同じサブネットに属している必要があります。たとえばホストが 10.1.1.0/24 内にある場合、Manager 用仮想マシンの IP は同じサブネット範囲 (10.1.1.1-254/24) になければなりません。

  14. Manager 用仮想マシンおよびベースホストのエントリーを仮想マシンの /etc/hosts ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。
  15. SMTP サーバーの名前と TCP ポート番号、メール通知を送信するメールアドレス、メール通知を受信するメールアドレス (複数ある場合はコンマ区切りリスト) を指定します。

  16. 管理ポータルにアクセスするための admin@internal ユーザーのパスワードを入力します。

    スクリプトにより仮想マシンが作成されます。RHV-M Appliance をインストールする必要がある場合は、時間がかかる場合があります。

  17. 使用するストレージのタイプを選択します。

    • NFS の場合は、バージョン、完全なアドレス、およびストレージへのパスならびにマウントオプションを入力します。

      警告

      仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。

    • iSCSI の場合は、ポータルの詳細を入力し、自動検出された一覧からターゲットおよび LUN を選択します。デプロイメント時に選択できる iSCSI ターゲットは 1 つだけですが、マルチパスがサポートされているので、同じポータルグループのポータルをすべて接続することができます。

      注記

      複数の iSCSI ターゲットを指定するには、セルフホスト型エンジンをデプロイする前にマルチパスを有効にする必要があります。詳細は、Red Hat Enterprise Linux DM Multipath を参照してください。Multipath Helper ツールを使用して、さまざまなオプションでマルチパスをインストールおよび設定するスクリプトを生成することもできます。

    • Gluster ストレージの場合は、完全なアドレスおよびストレージへのパスならびにマウントオプションを入力します。

      警告

      仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。

      重要

      レプリカ 3 Gluster ストレージのみがサポートされています。次の設定になっていることを確認してください。

      • 3 つの Gluster サーバーすべての/etc/glusterfs/glusterd.vol ファイルで、rpc-auth-allow-insecure を on に設定します。 

        option rpc-auth-allow-insecure on

      • 次のようにボリュームを設定します。 

        gluster volume set _volume_ cluster.quorum-type auto
gluster volume set _volume_ network.ping-timeout 10
gluster volume set _volume_ auth.allow \*
gluster volume set _volume_ group virt
gluster volume set _volume_ storage.owner-uid 36
gluster volume set _volume_ storage.owner-gid 36
gluster volume set _volume_ server.allow-insecure on
    • ファイバーチャネルの場合は、自動検出された一覧から LUN を選択します。ホストのバスアダプターが設定、接続されている必要があります。また、LUN には既存のデータが含まれないようにする必要があります。既存の LUN を再利用するには、Administration Guide の Reusing LUNs を参照してください。

  18. Manager のディスクサイズを入力します。

    スクリプトはデプロイメントが完了するまで続行されます。

  19. デプロイメントプロセスでは Manager の SSH キーが変更されます。クライアントマシンが SSH エラーなしで新規の Manager にアクセスできるようにするには、元の Manager にアクセスするクライアントマシンの .ssh/known_hosts ファイルから元の Manager のエントリーを削除します。

デプロイメントが完了したら、新しい Manager 仮想マシンにログインし、必要なリポジトリーを有効にします。

16.1.8.3. Red Hat Virtualization Manager リポジトリーの有効化

システムを Red Hat Subscription Manager に登録し、Red Hat Virtualization Manager のサブスクリプションをアタッチして Manager のリポジトリーを有効にします。

手順

  1. コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。 

    # subscription-manager register
    注記

    IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。

  2. Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。 

    # subscription-manager list --available

  3. 上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。 

    # subscription-manager attach --pool=pool_id
    注記

    現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。 

    # subscription-manager list --consumed

    有効なリポジトリーをすべて一覧表示するには、以下のコマンドを実行します。 

    # yum repolist

  4. リポジトリーを設定します。 

    # subscription-manager repos \
    --disable='*' \
    --enable=rhel-7-server-rpms \
    --enable=rhel-7-server-supplementary-rpms \
    --enable=rhel-7-server-rhv-4.3-manager-rpms \
    --enable=rhel-7-server-rhv-4-manager-tools-rpms \
    --enable=rhel-7-server-ansible-2.9-rpms \
    --enable=jb-eap-7.2-for-rhel-7-server-rpms

Manager とそのリソースは、新しいセルフホスト環境で実行されています。セルフホスト型エンジンノードは、セルフホスト型エンジン設定を更新するために Manager に再インストールする必要があります。標準ホストは影響を受けません。セルフホスト型エンジンノードごとに次の手順を実行します。

16.1.8.4. ホストの再インストール

管理ポータルから Red Hat Virtualization Host (RHVH) および Red Hat Enterprise Linux ホストを再インストールします。この手順には、ホストの停止および再起動が含まれます。

前提条件

  • 移行がクラスターレベルで有効にされる場合に、仮想マシンはクラスター内の別のホストに自動的に移行されので、ホストの使用が比較的低くなる場合にはホストを再インストールことをおすすめします。
  • ホストによるメンテナーンス実行に十分なメモリーがクラスターに予約されていることを確認します。クラスターに十分なメモリーがない場合には、仮想マシンの移行操作がハングしてから失敗します。一部またはすべての仮想マシンをシャットダウンしてから、ホストをメンテナーンスに移行すると、この操作のメモリー使用量を減らすことができます。
  • 再インストールを実行する前に、クラスターに複数のホストが含まれていることを確認してください。Storage Pool Manager (SPM) のタスクを実行するには、1 台のホストは使用可能な状態でなければならないので、すべてのホストを同時に再インストールしないでください。

手順

  1. Compute Hosts をクリックし、ホストを選択します。
  2. 管理 メンテナンス をクリックします。
  3. Installation Reinstall をクリックして、Install Host ウィンドウを開きます。
  4. Hosted Engine タブをクリックし、ドロップダウンリストから DEPLOY を選択します。
  5. OK をクリックして、ホストを再インストールします。

正常に再インストールされると、ホストのステータスが Up と表示されます。ホストから移行された仮想マシンはすべて、ホストに移行できるようになりました。

重要

Red Hat Virtualization Host が Red Hat Virtualization Manager に正常に登録されてから再インストールされると、ステータスが Install Failed の状態で、管理ポータルに誤って表示される可能性があります。Management アクティブ化 をクリックすると、ホストが Up ステータスに変わり、使用できるようになります。

セルフホスト型エンジンノードを再インストールした後に、いずれかのノードで以下のコマンドを実行して、新しい環境のステータスを確認できます。 

# hosted-engine --vm-status

復元中に、古いセルフホスト型エンジンのストレージドメインの名前が変更されましたが、復元に問題があった場合に備えて、新しい環境から削除されませんでした。環境が正常に実行されていることを確認したら、古いセルフホスト型エンジンストレージドメインを削除できます。

16.1.8.5. ストレージドメインの削除

データセンターに、仮想化環境から削除するストレージドメインがあります。

手順

  1. Storage Domains をクリックします。

  2. ストレージドメインをメンテナンスモードに移動し、デタッチします。

    1. ストレージドメインの名前をクリックし、詳細ビューを開きます。
    2. Data Center タブをクリックします。
    3. Maintenance をクリックしてから OK をクリックします。
    4. Detach をクリックしてから OK をクリックします。
  3. Remove をクリックします。
  4. 任意で Format Domain, i.e. Storage Content will be lost! チェックボックスを選択して、ドメインのコンテンツを消去します。
  5. OK をクリックします。

ストレージドメインは環境から完全に削除されます。

16.1.9. 既存のバックアップからのセルフホスト型エンジンの復元

修復できない問題のためにセルフホスト型エンジンが使用できない場合は、問題が発生する前に作成したバックアップを使用して、新しいセルフホスト環境でエンジンを復元できます (使用可能な場合)。

デプロイメント中にバックアップファイルを指定すると、バックアップは、新しいセルフホスト型エンジンストレージドメインを使用して、新しい Manager 仮想マシンに復元されます。古い Manager が削除され、古いセルフホスト型エンジンストレージドメインの名前が変更され、新しい環境が正しく機能していることを確認した後、手動で削除できます。新規ホストにデプロイすることを強く推奨します。デプロイメント用のホストがバックアップ環境に存在している場合は、新しい環境で競合を回避するために、復元されたデータベースから削除されます。

セルフホスト型エンジンの復元には、次の主要なアクションが含まれます。

  1. 新しいセルフホスト型エンジンをデプロイし、バックアップを復元します。
  2. 新しい Manager 用仮想マシンで Manager のリポジトリーを有効にします。
  3. セルフホスト型エンジンノードを再インストールして、設定を更新します。
  4. 古いセルフホスト型エンジンストレージドメインを削除します。

この手順は、元の Manager にアクセスできず、新しいホストがバックアップファイルにアクセスできることを前提としています。

前提条件

  • Manager とホスト用に用意された完全修飾ドメイン名。正引き (フォワードルックアップ) と逆引き (リバースルックアップ) の記録は両方とも DNS で設定する必要があります。新しい Manager は、元の Manager と同じ完全修飾ドメイン名を持っている必要があります。

16.1.9.1. 新しいセルフホスト型エンジンでのバックアップの復元

hosted-engine スクリプトを新規ホストで実行し、デプロイメント中に --restore-from-file=path/to/file_name オプションを使用して Manager バックアップを復元します。

重要

iSCSI ストレージを使用し、イニシエーターの ACL に従い、iSCSI ターゲットフィルターを使用して接続をフィルターする場合に、デプロイメントは STORAGE_DOMAIN_UNREACHABLE エラーで失敗する可能性があります。これを回避するには、セルフホスト型エンジンのデプロイメントを開始する前に iSCSI 設定を更新する必要があります。

  • 既存のホストに再デプロイする場合には、/etc/iscsi/initiatorname.iscsi でホストの iSCSI イニシエーター設定を更新する必要があります。イニシエーター IQN は、iSCSI ターゲットで以前にマッピングされていたものと同じか、または 必要に応じて新しい IQN に更新する必要があります。
  • 新規ホストにデプロイする場合は、iSCSI ターゲット設定を更新して、ホストからの接続を受け入れる必要があります。

IQN はホスト側 (iSCSI イニシエーター) またはストレージ側 (iSCSI ターゲット) で更新できることに注意してください。

手順

  1. バックアップファイルを新規ホストにコピーします。以下の例では、host.example.com はホストの FQDN で、/backup/ は指定されたフォルダーまたはパスです。 

    # scp -p file_name host.example.com:/backup/

  2. 新しいホストにログインします。Red Hat Virtualization ホストにデプロイする場合、デフォルトでセルフホストエンジンデプロイメントツールを使用できます。Red Hat Enterprise Linux にデプロイする場合は、以下のパッケージをインストールする必要があります。 

    # yum install ovirt-hosted-engine-setup

  3. Red Hat は、ネットワークまたはターミナルが中断した場合にセッションが失われないように、screen ウィンドウマネージャーを使用してスクリプトを実行することをお勧めします。screen をインストールして実行します。 

    # yum install screen
# screen

    セッションのタイムアウトまたは接続の中断が発生した場合は、screen-d-r を実行してデプロイメントセッションを復元します。

  4. バックアップファイルへのパスを指定して hosted-engine スクリプトを実行します。 

    # hosted-engine --deploy --restore-from-file=backup/file_name

    任意のタイミングでスクリプトをエスケープするには、CTRL+D を使用してデプロイメントを中止します。

  5. Yes を選択してデプロイメントを開始します。
  6. ネットワークを設定します。スクリプトにより、環境の管理ブリッジとして使用する NIC 候補が検出されます。
  7. 仮想マシンのインストールにカスタムアプライアンスを使用する場合は、OVA アーカイブへのパスを入力します。使用しない場合は、このフィールドを空欄のままにして RHV-M Appliance を使用します。
  8. Manager 仮想マシンの完全修飾ドメイン名 (FQDN) を指定します。
  9. Manager の root パスワードを入力します。
  10. root ユーザーとして Manager にログインできる SSH 公開鍵を入力し、root ユーザーの SSH アクセスを有効にするかどうかを指定します。
  11. 仮想マシンの CPU およびメモリー設定を入力します。
  12. Manager 用仮想マシンの MAC アドレスを入力するか、無作為に生成される MAC アドレスを適用します。Manager 用仮想マシンへの IP アドレス割り当てに DHCP を使用するには、この MAC アドレスに有効な DHCP 予約があることを確認してください。デプロイメントスクリプトは、DHCP サーバーの設定は行いません。

  13. 仮想マシンのネットワーク情報を入力します。Static を指定する場合には、Manager の IP アドレスを入力します。

    重要

    静的 IP アドレスは、ホストと同じサブネットに属している必要があります。たとえばホストが 10.1.1.0/24 内にある場合、Manager 用仮想マシンの IP は同じサブネット範囲 (10.1.1.1-254/24) になければなりません。

  14. Manager 用仮想マシンおよびベースホストのエントリーを仮想マシンの /etc/hosts ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。
  15. SMTP サーバーの名前と TCP ポート番号、メール通知を送信するメールアドレス、メール通知を受信するメールアドレス (複数ある場合はコンマ区切りリスト) を指定します。

  16. 管理ポータルにアクセスするための admin@internal ユーザーのパスワードを入力します。

    スクリプトにより仮想マシンが作成されます。RHV-M Appliance をインストールする必要がある場合は、時間がかかる場合があります。

  17. 使用するストレージのタイプを選択します。

    • NFS の場合は、バージョン、完全なアドレス、およびストレージへのパスならびにマウントオプションを入力します。

      警告

      仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。

    • iSCSI の場合は、ポータルの詳細を入力し、自動検出された一覧からターゲットおよび LUN を選択します。デプロイメント時に選択できる iSCSI ターゲットは 1 つだけですが、マルチパスがサポートされているので、同じポータルグループのポータルをすべて接続することができます。

      注記

      複数の iSCSI ターゲットを指定するには、セルフホスト型エンジンをデプロイする前にマルチパスを有効にする必要があります。詳細は、Red Hat Enterprise Linux DM Multipath を参照してください。Multipath Helper ツールを使用して、さまざまなオプションでマルチパスをインストールおよび設定するスクリプトを生成することもできます。

    • Gluster ストレージの場合は、完全なアドレスおよびストレージへのパスならびにマウントオプションを入力します。

      警告

      仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。

      重要

      レプリカ 3 Gluster ストレージのみがサポートされています。次の設定になっていることを確認してください。

      • 3 つの Gluster サーバーすべての/etc/glusterfs/glusterd.vol ファイルで、rpc-auth-allow-insecure を on に設定します。 

        option rpc-auth-allow-insecure on

      • 次のようにボリュームを設定します。 

        gluster volume set _volume_ cluster.quorum-type auto
gluster volume set _volume_ network.ping-timeout 10
gluster volume set _volume_ auth.allow \*
gluster volume set _volume_ group virt
gluster volume set _volume_ storage.owner-uid 36
gluster volume set _volume_ storage.owner-gid 36
gluster volume set _volume_ server.allow-insecure on
    • ファイバーチャネルの場合は、自動検出された一覧から LUN を選択します。ホストのバスアダプターが設定、接続されている必要があります。また、LUN には既存のデータが含まれないようにする必要があります。既存の LUN を再利用するには、Administration Guide の Reusing LUNs を参照してください。

  18. Manager のディスクサイズを入力します。

    スクリプトはデプロイメントが完了するまで続行されます。

  19. デプロイメントプロセスでは Manager の SSH キーが変更されます。クライアントマシンが SSH エラーなしで新規の Manager にアクセスできるようにするには、元の Manager にアクセスするクライアントマシンの .ssh/known_hosts ファイルから元の Manager のエントリーを削除します。

デプロイメントが完了したら、新しい Manager 仮想マシンにログインし、必要なリポジトリーを有効にします。

16.1.9.2. Red Hat Virtualization Manager リポジトリーの有効化

システムを Red Hat Subscription Manager に登録し、Red Hat Virtualization Manager のサブスクリプションをアタッチして Manager のリポジトリーを有効にします。

手順

  1. コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。 

    # subscription-manager register
    注記

    IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。

  2. Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。 

    # subscription-manager list --available

  3. 上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。 

    # subscription-manager attach --pool=pool_id
    注記

    現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。 

    # subscription-manager list --consumed

    有効なリポジトリーをすべて一覧表示するには、以下のコマンドを実行します。 

    # yum repolist

  4. リポジトリーを設定します。 

    # subscription-manager repos \
    --disable='*' \
    --enable=rhel-7-server-rpms \
    --enable=rhel-7-server-supplementary-rpms \
    --enable=rhel-7-server-rhv-4.3-manager-rpms \
    --enable=rhel-7-server-rhv-4-manager-tools-rpms \
    --enable=rhel-7-server-ansible-2.9-rpms \
    --enable=jb-eap-7.2-for-rhel-7-server-rpms

Manager とそのリソースは、新しいセルフホスト環境で実行されています。セルフホスト型エンジンノードは、セルフホスト型エンジン設定を更新するために Manager に再インストールする必要があります。標準ホストは影響を受けません。セルフホスト型エンジンノードごとに次の手順を実行します。

16.1.9.3. ホストの再インストール

管理ポータルから Red Hat Virtualization Host (RHVH) および Red Hat Enterprise Linux ホストを再インストールします。この手順には、ホストの停止および再起動が含まれます。

前提条件

  • 移行がクラスターレベルで有効にされる場合に、仮想マシンはクラスター内の別のホストに自動的に移行されので、ホストの使用が比較的低くなる場合にはホストを再インストールことをおすすめします。
  • ホストによるメンテナーンス実行に十分なメモリーがクラスターに予約されていることを確認します。クラスターに十分なメモリーがない場合には、仮想マシンの移行操作がハングしてから失敗します。一部またはすべての仮想マシンをシャットダウンしてから、ホストをメンテナーンスに移行すると、この操作のメモリー使用量を減らすことができます。
  • 再インストールを実行する前に、クラスターに複数のホストが含まれていることを確認してください。Storage Pool Manager (SPM) のタスクを実行するには、1 台のホストは使用可能な状態でなければならないので、すべてのホストを同時に再インストールしないでください。

手順

  1. Compute Hosts をクリックし、ホストを選択します。
  2. 管理 メンテナンス をクリックします。
  3. Installation Reinstall をクリックして、Install Host ウィンドウを開きます。
  4. Hosted Engine タブをクリックし、ドロップダウンリストから DEPLOY を選択します。
  5. OK をクリックして、ホストを再インストールします。

正常に再インストールされると、ホストのステータスが Up と表示されます。ホストから移行された仮想マシンはすべて、ホストに移行できるようになりました。

重要

Red Hat Virtualization Host が Red Hat Virtualization Manager に正常に登録されてから再インストールされると、ステータスが Install Failed の状態で、管理ポータルに誤って表示される可能性があります。Management アクティブ化 をクリックすると、ホストが Up ステータスに変わり、使用できるようになります。

セルフホスト型エンジンノードを再インストールした後に、いずれかのノードで以下のコマンドを実行して、新しい環境のステータスを確認できます。 

# hosted-engine --vm-status

復元中に、古いセルフホスト型エンジンのストレージドメインの名前が変更されましたが、復元に問題があった場合に備えて、新しい環境から削除されませんでした。環境が正常に実行されていることを確認したら、古いセルフホスト型エンジンストレージドメインを削除できます。

16.1.9.4. ストレージドメインの削除

データセンターに、仮想化環境から削除するストレージドメインがあります。

手順

  1. Storage Domains をクリックします。

  2. ストレージドメインをメンテナンスモードに移動し、デタッチします。

    1. ストレージドメインの名前をクリックし、詳細ビューを開きます。
    2. Data Center タブをクリックします。
    3. Maintenance をクリックしてから OK をクリックします。
    4. Detach をクリックしてから OK をクリックします。
  3. Remove をクリックします。
  4. 任意で Format Domain, i.e. Storage Content will be lost! チェックボックスを選択して、ドメインのコンテンツを消去します。
  5. OK をクリックします。

ストレージドメインは環境から完全に削除されます。

16.1.10. 既存のバックアップからのセルフホスト型エンジンの上書き

セルフホスト型エンジンにアクセスできるが、データベースの破損や設定エラーなどロールバックが困難な問題が発生した場合は、問題が発生する前に取ったバックアップがあれば、それを使用して以前の状態に環境を復元することができます。

セルフホスト型エンジンの以前の状態を復元するには、次の手順が必要です。

  1. 環境をグローバルメンテナンスモードに切り替える
  2. Manager 仮想マシンでバックアップを復元します。
  3. グローバルメンテナーンスモードを無効にする

engine-backup --mode=restore オプションの詳細は、「Red Hat Virtualization Manager のバックアップおよび復元」 を参照してください。

16.1.10.1. グローバルメンテナーンスモードの有効化

Manager 用仮想マシンの設定またはアップグレード作業を実施する前に、セルフホスト型エンジン環境をグローバルメンテナンスモードに切り替える必要があります。

手順

  1. セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。 

    # hosted-engine --set-maintenance --mode=global

  2. 作業を進める前に、環境がメンテナーンスモードにあることを確認します。 

    # hosted-engine --vm-status

    クラスターがメンテナーンスモードにあることを示すメッセージが表示されるはずです。

16.1.10.2. バックアップを復元して既存のインストールを上書き

engine-backup コマンドを使用すると、Red Hat Virtualization Manager がすでにインストールおよび設定されているマシンにバックアップを復元できます。これは、環境のバックアップを取り、その環境で変更を実行し、バックアップから環境を復元して変更を元に戻したい場合に役立ちます。

ホストの追加や削除など、バックアップの作成後に環境に加えられた変更は、復元された環境には表示されません。これらの変更をやり直す必要があります。

手順

  1. Manager マシンにログインします。

  2. 設定ファイルを削除し、Manager に関連付けられているデータベースをクリーンアップします。 

    # engine-cleanup

    engine-cleanup コマンドは、Manager データベースのみを削除します。データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。

  3. フルバックアップまたはデータベースのみのバックアップを復元します。ユーザーとデータベースがすでに存在しているので、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。

    • 完全バックアップを復元します。 

      # engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions

    • 設定ファイルおよびデータベースバックアップを復元して、データベースのみのバックアップを復元します。 

      # engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions
      注記

      Manager データベースのみを復元するには (たとえば、Data Warehouse データベースが別のマシンにある場合)、-scope=dwhdb パラメーターを省略できます。

      成功すると、次の出力が表示されます。 

      You should now run engine-setup.
Done.

  4. Manager を再設定します。 

    # engine-setup

16.1.10.3. グローバルメンテナーンスモードの無効化

手順

  1. Manager 用仮想マシンにログインし、シャットダウンします。

  2. セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを無効にします。 

    # hosted-engine --set-maintenance --mode=none

    グローバルメンテナンスモードを終了すると、ovirt-ha-agent が Manager 用仮想マシンを起動し、続いて Manager が自動的に起動します。Manager が起動するまでに最大で 10 分程度かかる場合があります。

  3. 環境が動作していることを確認します。 

    # hosted-engine --vm-status

    情報の一覧に、Engine status が含まれます。Engine status の値は、以下のようになるはずです。 

    {"health": "good", "vm": "up", "detail": "Up"}
    注記

    仮想マシンが起動中で Manager がまだ動作していない場合、Engine status は以下のようになります。 

    {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

    このような場合には、数分間待ってからやり直してください。

環境が再び実行している場合は、停止した仮想マシンを起動して、環境内のリソースが期待どおりに動作していることを確認できます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.