第16章 バックアップおよび移行
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 コマンドの使用例
- Red Hat Virtualization Manager を実行しているマシンにログインします。
バックアップを作成します。
例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 つまたは複数のバックアップファイルにアクセスできることを前提としています。
バックアップを新規インストールに復元する
- Manager マシンにログインします。エンジンデータベースをリモートホストに復元する場合は、そのホストにログオンして、関連するアクションを実行する必要があります。同様に、Data Warehouse をリモートホストにも復元する場合は、そのホストにログオンして、関連するアクションを実行する必要があります。
完全バックアップまたはデータベースのみのバックアップを復元します。
完全バックアップを復元します。
# 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.
次のコマンドを実行し、プロンプトに従って復元された Manager を設定します。
# engine-setup
Red Hat Virtualization Manager は、バックアップに保存されているバージョンに復元されました。新しい Red Hat Virtualization システムの完全修飾ドメイン名を変更するには、「oVirt エンジンの名前変更ツール」 を参照してください。
16.1.6. バックアップを復元して既存のインストールを上書き
engine-backup
コマンドを使用すると、Red Hat Virtualization Manager がすでにインストールおよび設定されているマシンにバックアップを復元できます。これは、環境のバックアップを取り、その環境で変更を実行し、バックアップから環境を復元して変更を元に戻したい場合に役立ちます。
ホストの追加や削除など、バックアップの作成後に環境に加えられた変更は、復元された環境には表示されません。これらの変更をやり直す必要があります。
手順
- Manager マシンにログインします。
設定ファイルを削除し、Manager に関連付けられているデータベースをクリーンアップします。
# engine-cleanup
engine-cleanup
コマンドは、Manager データベースのみを削除します。データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。フルバックアップまたはデータベースのみのバックアップを復元します。ユーザーとデータベースがすでに存在しているので、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。
完全バックアップを復元します。
# 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.
Manager を再設定します。
# engine-setup
16.1.7. 異なる認証情報を使用したバックアップの復元
engine-backup
コマンドは、Red Hat Virtualization Manager がすでにインストールされセットアップされているマシンにバックアップを復元することができますが、バックアップ内のデータベースの認証情報は、バックアップを復元するマシン上のデータベースの認証情報とは異なっています。これは、インストールのバックアップを取り、バックアップから別のシステムにインストールを復元する場合に役立ちます。
バックアップを復元して既存のインストールを上書きする場合は、engine-backup
コマンドを使用する前に、engine-cleanup
コマンドを実行して既存のインストールをクリーンアップする必要があります。engine-cleanup
コマンドは、エンジンデータベースをクリーンアップするだけで、データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。したがって、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。ただし、エンジンデータベースの所有者の認証情報がわからない場合は、バックアップを復元する前に認証情報を変更する必要があります。
異なる認証情報を使用したバックアップの復元
- Red Hat Virtualization Manager マシンにログインします。
次のコマンドを実行し、プロンプトに従って Manager の設定ファイルを削除し、Manager のデータベースをクリーンアップします。
# engine-cleanup
engine
データベースの所有者のパスワードがわからない場合は、そのユーザーのパスワードを変更します。postgresql コマンドラインを入力します。
# su - postgres -c 'scl enable rh-postgresql10 -- psql'
engine
データベースを所有するユーザーのパスワードを変更します。postgres=# alter role user_name encrypted password 'new_password';
必要に応じて、
ovirt_engine_history
データベースを所有するユーザーに対してこれを繰り返します。
--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.
次のコマンドを実行し、プロンプトに従ってファイアウォールを再設定し、
ovirt-engine
サービスが正しく設定されていることを確認します。# engine-setup
16.1.8. セルフホスト型エンジンのバックアップおよび復元
セルフホスト型エンジンをバックアップして、新しいセルフホスト環境に復元できます。この手順は、環境を別のストレージタイプの新しいセルフホスト型エンジンストレージドメインに移行するなどのタスクに使用します。
デプロイメント中にバックアップファイルを指定すると、バックアップは、新しいセルフホスト型エンジンストレージドメインを使用して、新しい Manager 仮想マシンに復元されます。古い Manager が削除され、古いセルフホスト型エンジンストレージドメインの名前が変更され、新しい環境が正しく機能していることを確認した後、手動で削除できます。新規ホストにデプロイすることを強く推奨します。デプロイメント用のホストがバックアップ環境に存在している場合は、新しい環境で競合を回避するために、復元されたデータベースから削除されます。
バックアップと復元の操作には、次の主要なアクションが含まれます。
この手順の前提として、移行元の Manager に対するアクセス権があり、変更を加えることできる必要があります。
前提条件
- Manager とホスト用に用意された完全修飾ドメイン名。正引き (フォワードルックアップ) と逆引き (リバースルックアップ) の記録は両方とも DNS で設定する必要があります。新しい Manager は、元の Manager と同じ完全修飾ドメイン名を持っている必要があります。
- 元の Manager を最新のマイナーバージョンに更新する必要があります。バックアップファイルの Manager バージョンは、新しい Manager のバージョンと一致する必要があります。Upgrade Guide の Updating the Red Hat Virtualization Manager を参照してください。
環境内に少なくとも 1 つの通常のホストが存在する必要があります。このホスト (およびその他の通常のホスト) は、SPM ロールおよび実行中の仮想マシンをホストするためにアクティブなままになります。通常のホストがまだ SPM でない場合は、バックアップを作成する前に、通常のホストを選択し、
をクリックして、SPM のロールを移動します。 通常のホストが利用できない場合、1 つを追加する方法は 2 つあります。
- セルフホスト型エンジン設定をノードから削除します (ただし、ノードを環境から削除しないでください)。「セルフホスト型エンジン環境からのホストの削除」 を参照してください。
- 新しい通常のホストを追加します。「Red Hat Virtualization Manager への通常のホストの追加」 を参照してください。
16.1.8.1. 元の Manager のバックアップ
engine-backup
コマンドを使用して元の Manager をバックアップし、バックアップファイルを別の場所にコピーして、処理中にいつでもアクセスできるようにします。
engine-backup --mode=backup
オプションの詳細は、Administration Guide の Backing Up and Restoring the Red Hat Virtualization Manager を参照してください。
手順
セルフホスト型エンジンノードの 1 つにログインし、環境をグローバルメンテナンスモードに移行します。
# hosted-engine --set-maintenance --mode=global
元の Manager にログインし、
ovirt-engine
サービスを停止します。# systemctl stop ovirt-engine # systemctl disable ovirt-engine
注記元の Manager の実行を停止するのは必須ではありませんが、バックアップの作成後に環境を変更しないように推奨しています。さらに、元の Manager と新しい Manager が既存リソースを同時に管理しないようにします。
作成するバックアップファイルの名前と、バックアップログを保存するログファイルの名前を指定して、
engine-backup
コマンドを実行します。# engine-backup --mode=backup --file=file_name --log=log_file_name
ファイルを外部サーバーにコピーします。以下の例では、
storage.example.com
は、必要となるまでバックアップを保存するネットワークストレージサーバーの完全修飾ドメイン名です。/backup/
は指定のフォルダーまたはパスです。# scp -p file_name log_file_name storage.example.com:/backup/
他の目的で Manager マシンが必要ない場合は、Red Hat Subscription Manager から登録を解除します。
# subscription-manager unregister
セルフホスト型エンジンノードの 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 ターゲット) で更新できることに注意してください。
手順
バックアップファイルを新規ホストにコピーします。以下の例では、
host.example.com
はホストの FQDN で、/backup/
は指定されたフォルダーまたはパスです。# scp -p file_name host.example.com:/backup/
新しいホストにログインします。Red Hat Virtualization ホストにデプロイする場合、デフォルトでセルフホストエンジンデプロイメントツールを使用できます。Red Hat Enterprise Linux にデプロイする場合は、以下のパッケージをインストールする必要があります。
# yum install ovirt-hosted-engine-setup
Red Hat は、ネットワークまたはターミナルが中断した場合にセッションが失われないように、
screen
ウィンドウマネージャーを使用してスクリプトを実行することをお勧めします。screen
をインストールして実行します。# yum install screen # screen
セッションのタイムアウトまたは接続の中断が発生した場合は、
screen-d-r
を実行してデプロイメントセッションを復元します。バックアップファイルへのパスを指定して
hosted-engine
スクリプトを実行します。# hosted-engine --deploy --restore-from-file=backup/file_name
任意のタイミングでスクリプトをエスケープするには、CTRL+D を使用してデプロイメントを中止します。
- Yes を選択してデプロイメントを開始します。
- ネットワークを設定します。スクリプトにより、環境の管理ブリッジとして使用する NIC 候補が検出されます。
- 仮想マシンのインストールにカスタムアプライアンスを使用する場合は、OVA アーカイブへのパスを入力します。使用しない場合は、このフィールドを空欄のままにして RHV-M Appliance を使用します。
- Manager 仮想マシンの完全修飾ドメイン名 (FQDN) を指定します。
- Manager の root パスワードを入力します。
- root ユーザーとして Manager にログインできる SSH 公開鍵を入力し、root ユーザーの SSH アクセスを有効にするかどうかを指定します。
- 仮想マシンの CPU およびメモリー設定を入力します。
- Manager 用仮想マシンの MAC アドレスを入力するか、無作為に生成される MAC アドレスを適用します。Manager 用仮想マシンへの IP アドレス割り当てに DHCP を使用するには、この MAC アドレスに有効な DHCP 予約があることを確認してください。デプロイメントスクリプトは、DHCP サーバーの設定は行いません。
仮想マシンのネットワーク情報を入力します。Static を指定する場合には、Manager の IP アドレスを入力します。
重要静的 IP アドレスは、ホストと同じサブネットに属している必要があります。たとえばホストが 10.1.1.0/24 内にある場合、Manager 用仮想マシンの IP は同じサブネット範囲 (10.1.1.1-254/24) になければなりません。
-
Manager 用仮想マシンおよびベースホストのエントリーを仮想マシンの
/etc/hosts
ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。 - SMTP サーバーの名前と TCP ポート番号、メール通知を送信するメールアドレス、メール通知を受信するメールアドレス (複数ある場合はコンマ区切りリスト) を指定します。
管理ポータルにアクセスするための
admin@internal
ユーザーのパスワードを入力します。スクリプトにより仮想マシンが作成されます。RHV-M Appliance をインストールする必要がある場合は、時間がかかる場合があります。
使用するストレージのタイプを選択します。
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 を参照してください。
Manager のディスクサイズを入力します。
スクリプトはデプロイメントが完了するまで続行されます。
-
デプロイメントプロセスでは 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 のリポジトリーを有効にします。
手順
コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
# subscription-manager register
注記IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。
Red Hat Virtualization Manager
のサブスクリプションプールを見つけ、プール ID を記録します。# subscription-manager list --available
上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
# subscription-manager attach --pool=pool_id
注記現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。
# subscription-manager list --consumed
有効なリポジトリーをすべて一覧表示するには、以下のコマンドを実行します。
# yum repolist
リポジトリーを設定します。
# 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 台のホストは使用可能な状態でなければならないので、すべてのホストを同時に再インストールしないでください。
手順
-
をクリックし、ホストを選択します。 -
をクリックします。 -
をクリックして、Install Host ウィンドウを開きます。 - Hosted Engine タブをクリックし、ドロップダウンリストから DEPLOY を選択します。
- OK をクリックして、ホストを再インストールします。
正常に再インストールされると、ホストのステータスが Up と表示されます。ホストから移行された仮想マシンはすべて、ホストに移行できるようになりました。
Red Hat Virtualization Host が Red Hat Virtualization Manager に正常に登録されてから再インストールされると、ステータスが Install Failed の状態で、管理ポータルに誤って表示される可能性があります。
セルフホスト型エンジンノードを再インストールした後に、いずれかのノードで以下のコマンドを実行して、新しい環境のステータスを確認できます。
# hosted-engine --vm-status
復元中に、古いセルフホスト型エンジンのストレージドメインの名前が変更されましたが、復元に問題があった場合に備えて、新しい環境から削除されませんでした。環境が正常に実行されていることを確認したら、古いセルフホスト型エンジンストレージドメインを削除できます。
16.1.8.5. ストレージドメインの削除
データセンターに、仮想化環境から削除するストレージドメインがあります。
手順
-
をクリックします。 ストレージドメインをメンテナンスモードに移動し、デタッチします。
- ストレージドメインの名前をクリックし、詳細ビューを開きます。
- Data Center タブをクリックします。
- Maintenance をクリックしてから OK をクリックします。
- Detach をクリックしてから OK をクリックします。
- Remove をクリックします。
- 任意で Format Domain, i.e. Storage Content will be lost! チェックボックスを選択して、ドメインのコンテンツを消去します。
- OK をクリックします。
ストレージドメインは環境から完全に削除されます。
16.1.9. 既存のバックアップからのセルフホスト型エンジンの復元
修復できない問題のためにセルフホスト型エンジンが使用できない場合は、問題が発生する前に作成したバックアップを使用して、新しいセルフホスト環境でエンジンを復元できます (使用可能な場合)。
デプロイメント中にバックアップファイルを指定すると、バックアップは、新しいセルフホスト型エンジンストレージドメインを使用して、新しい Manager 仮想マシンに復元されます。古い Manager が削除され、古いセルフホスト型エンジンストレージドメインの名前が変更され、新しい環境が正しく機能していることを確認した後、手動で削除できます。新規ホストにデプロイすることを強く推奨します。デプロイメント用のホストがバックアップ環境に存在している場合は、新しい環境で競合を回避するために、復元されたデータベースから削除されます。
セルフホスト型エンジンの復元には、次の主要なアクションが含まれます。
この手順は、元の 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 ターゲット) で更新できることに注意してください。
手順
バックアップファイルを新規ホストにコピーします。以下の例では、
host.example.com
はホストの FQDN で、/backup/
は指定されたフォルダーまたはパスです。# scp -p file_name host.example.com:/backup/
新しいホストにログインします。Red Hat Virtualization ホストにデプロイする場合、デフォルトでセルフホストエンジンデプロイメントツールを使用できます。Red Hat Enterprise Linux にデプロイする場合は、以下のパッケージをインストールする必要があります。
# yum install ovirt-hosted-engine-setup
Red Hat は、ネットワークまたはターミナルが中断した場合にセッションが失われないように、
screen
ウィンドウマネージャーを使用してスクリプトを実行することをお勧めします。screen
をインストールして実行します。# yum install screen # screen
セッションのタイムアウトまたは接続の中断が発生した場合は、
screen-d-r
を実行してデプロイメントセッションを復元します。バックアップファイルへのパスを指定して
hosted-engine
スクリプトを実行します。# hosted-engine --deploy --restore-from-file=backup/file_name
任意のタイミングでスクリプトをエスケープするには、CTRL+D を使用してデプロイメントを中止します。
- Yes を選択してデプロイメントを開始します。
- ネットワークを設定します。スクリプトにより、環境の管理ブリッジとして使用する NIC 候補が検出されます。
- 仮想マシンのインストールにカスタムアプライアンスを使用する場合は、OVA アーカイブへのパスを入力します。使用しない場合は、このフィールドを空欄のままにして RHV-M Appliance を使用します。
- Manager 仮想マシンの完全修飾ドメイン名 (FQDN) を指定します。
- Manager の root パスワードを入力します。
- root ユーザーとして Manager にログインできる SSH 公開鍵を入力し、root ユーザーの SSH アクセスを有効にするかどうかを指定します。
- 仮想マシンの CPU およびメモリー設定を入力します。
- Manager 用仮想マシンの MAC アドレスを入力するか、無作為に生成される MAC アドレスを適用します。Manager 用仮想マシンへの IP アドレス割り当てに DHCP を使用するには、この MAC アドレスに有効な DHCP 予約があることを確認してください。デプロイメントスクリプトは、DHCP サーバーの設定は行いません。
仮想マシンのネットワーク情報を入力します。Static を指定する場合には、Manager の IP アドレスを入力します。
重要静的 IP アドレスは、ホストと同じサブネットに属している必要があります。たとえばホストが 10.1.1.0/24 内にある場合、Manager 用仮想マシンの IP は同じサブネット範囲 (10.1.1.1-254/24) になければなりません。
-
Manager 用仮想マシンおよびベースホストのエントリーを仮想マシンの
/etc/hosts
ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。 - SMTP サーバーの名前と TCP ポート番号、メール通知を送信するメールアドレス、メール通知を受信するメールアドレス (複数ある場合はコンマ区切りリスト) を指定します。
管理ポータルにアクセスするための
admin@internal
ユーザーのパスワードを入力します。スクリプトにより仮想マシンが作成されます。RHV-M Appliance をインストールする必要がある場合は、時間がかかる場合があります。
使用するストレージのタイプを選択します。
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 を参照してください。
Manager のディスクサイズを入力します。
スクリプトはデプロイメントが完了するまで続行されます。
-
デプロイメントプロセスでは 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 のリポジトリーを有効にします。
手順
コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
# subscription-manager register
注記IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。
Red Hat Virtualization Manager
のサブスクリプションプールを見つけ、プール ID を記録します。# subscription-manager list --available
上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
# subscription-manager attach --pool=pool_id
注記現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。
# subscription-manager list --consumed
有効なリポジトリーをすべて一覧表示するには、以下のコマンドを実行します。
# yum repolist
リポジトリーを設定します。
# 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 台のホストは使用可能な状態でなければならないので、すべてのホストを同時に再インストールしないでください。
手順
-
をクリックし、ホストを選択します。 -
をクリックします。 -
をクリックして、Install Host ウィンドウを開きます。 - Hosted Engine タブをクリックし、ドロップダウンリストから DEPLOY を選択します。
- OK をクリックして、ホストを再インストールします。
正常に再インストールされると、ホストのステータスが Up と表示されます。ホストから移行された仮想マシンはすべて、ホストに移行できるようになりました。
Red Hat Virtualization Host が Red Hat Virtualization Manager に正常に登録されてから再インストールされると、ステータスが Install Failed の状態で、管理ポータルに誤って表示される可能性があります。
セルフホスト型エンジンノードを再インストールした後に、いずれかのノードで以下のコマンドを実行して、新しい環境のステータスを確認できます。
# hosted-engine --vm-status
復元中に、古いセルフホスト型エンジンのストレージドメインの名前が変更されましたが、復元に問題があった場合に備えて、新しい環境から削除されませんでした。環境が正常に実行されていることを確認したら、古いセルフホスト型エンジンストレージドメインを削除できます。
16.1.9.4. ストレージドメインの削除
データセンターに、仮想化環境から削除するストレージドメインがあります。
手順
-
をクリックします。 ストレージドメインをメンテナンスモードに移動し、デタッチします。
- ストレージドメインの名前をクリックし、詳細ビューを開きます。
- Data Center タブをクリックします。
- Maintenance をクリックしてから OK をクリックします。
- Detach をクリックしてから OK をクリックします。
- Remove をクリックします。
- 任意で Format Domain, i.e. Storage Content will be lost! チェックボックスを選択して、ドメインのコンテンツを消去します。
- OK をクリックします。
ストレージドメインは環境から完全に削除されます。
16.1.10. 既存のバックアップからのセルフホスト型エンジンの上書き
セルフホスト型エンジンにアクセスできるが、データベースの破損や設定エラーなどロールバックが困難な問題が発生した場合は、問題が発生する前に取ったバックアップがあれば、それを使用して以前の状態に環境を復元することができます。
セルフホスト型エンジンの以前の状態を復元するには、次の手順が必要です。
engine-backup --mode=restore
オプションの詳細は、「Red Hat Virtualization Manager のバックアップおよび復元」 を参照してください。
16.1.10.1. グローバルメンテナーンスモードの有効化
Manager 用仮想マシンの設定またはアップグレード作業を実施する前に、セルフホスト型エンジン環境をグローバルメンテナンスモードに切り替える必要があります。
手順
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。
# hosted-engine --set-maintenance --mode=global
作業を進める前に、環境がメンテナーンスモードにあることを確認します。
# hosted-engine --vm-status
クラスターがメンテナーンスモードにあることを示すメッセージが表示されるはずです。
16.1.10.2. バックアップを復元して既存のインストールを上書き
engine-backup
コマンドを使用すると、Red Hat Virtualization Manager がすでにインストールおよび設定されているマシンにバックアップを復元できます。これは、環境のバックアップを取り、その環境で変更を実行し、バックアップから環境を復元して変更を元に戻したい場合に役立ちます。
ホストの追加や削除など、バックアップの作成後に環境に加えられた変更は、復元された環境には表示されません。これらの変更をやり直す必要があります。
手順
- Manager マシンにログインします。
設定ファイルを削除し、Manager に関連付けられているデータベースをクリーンアップします。
# engine-cleanup
engine-cleanup
コマンドは、Manager データベースのみを削除します。データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。フルバックアップまたはデータベースのみのバックアップを復元します。ユーザーとデータベースがすでに存在しているので、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。
完全バックアップを復元します。
# 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.
Manager を再設定します。
# engine-setup
16.1.10.3. グローバルメンテナーンスモードの無効化
手順
- Manager 用仮想マシンにログインし、シャットダウンします。
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを無効にします。
# hosted-engine --set-maintenance --mode=none
グローバルメンテナンスモードを終了すると、ovirt-ha-agent が Manager 用仮想マシンを起動し、続いて Manager が自動的に起動します。Manager が起動するまでに最大で 10 分程度かかる場合があります。
環境が動作していることを確認します。
# 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"}
このような場合には、数分間待ってからやり直してください。
環境が再び実行している場合は、停止した仮想マシンを起動して、環境内のリソースが期待どおりに動作していることを確認できます。