6.5. セルフホストエンジン Manager の手動での復元
以下の手順では、バックアップしたセルフホストエンジンの Manager 仮想マシンの構成設定およびデータベースの内容を手動で復元する方法を説明します。
手順6.4 セルフホストエンジン Manager の復元
- バックアップに含まれるデータベースのコンテンツの復元先となる、空のデータベースを手動で作成します。以下の手順は、データベースがホストされるマシンで実行する必要があります。
- データベースが Manager 仮想マシン以外のマシンでホストされている場合は、postgresql-server パッケージをインストールする必要があります。データベースが Manager 仮想マシンでホストされている場合には、rhevm パッケージにこのパッケージが含まれているため、このステップは必要ありません。
# yum install postgresql-server
postgresql
データベースを初期化し、postgresql
サービスを起動してから、このサービスがブート時に起動されるように設定します。# service postgresql initdb # service postgresql start # chkconfig postgresql on
- postgresql のコマンドラインに入ります。
# su postgres $ psql
engine
ユーザーを作成します。postgres=# create role engine with login encrypted password 'password';
Reports および Data Warehouse も復元する場合には、対象のホストでovirt_engine_reports
およびovirt_engine_history
のユーザーを作成します。postgres=# create role ovirt_engine_reports with login encrypted password 'password';
postgres=# create role ovirt_engine_history with login encrypted password 'password';
- 新規データベースを作成します。
postgres=# create database database_name owner engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
Reports および Data Warehouse も復元する場合には、対象のホストでデータベースを作成します。postgres=# create database database_name owner ovirt_engine_reports template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
postgres=# create database database_name owner ovirt_engine_history template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
- postgresql コマンドラインを終了して、postgres ユーザーからログアウトします。
postgres=# \q $ exit
/var/lib/pgsql/data/pg_hba.conf
ファイルを以下のように編集します。- ローカルデータベースごとに、ファイルの最下部の
Local
で開始するセクションに記載されている既存のディレクティブを以下のディレクティブに置き換えます。host database_name user_name 0.0.0.0/0 md5 host database_name user_name ::0/0 md5
- リモートデータベースごとに、以下のように設定します。
- ファイルの最下部にある
Local
で始まる行の直下に次の行を追記します。X.X.X.X は Manager の IP アドレスに置き換えてください。host database_name user_name X.X.X.X/32 md5
- データベースへの TCP/IP 接続を許可します。
/var/lib/pgsql/data/pg_hba.conf
ファイルを編集して、以下の行を追加します。listen_addresses='*'
上記の例では、全インターフェースの接続をリッスンするようにpostgresql
を設定しています。IP アドレスを指定して、特定のインターフェースをリッスンするように設定することもできます。 - PostgreSQL データベースの接続に使用するデフォルトのポートを開放して、更新したファイアウォールルールを保存します。
# iptables -I INPUT 5 -p tcp -s Manager_IP_Address --dport 5432 -j ACCEPT # service iptables save
postgresql
サービスを再起動します。# service postgresql restart
- バックアップファイルを新しい Manager 仮想マシンにセキュアコピーします。この例では、「セルフホストエンジンの Manager 仮想マシンのバックアップ」でファイルをコピーしたネットワークストレージサーバーからファイルをコピーします。このコマンドで、Storage.example.com はストレージサーバーの完全修飾ドメイン名、/backup/EngineBackupFiles はストレージサーバーのバックアップファイルへの指定ファイルパス、/backup/ は新規 Manager 上にバックアップファイルをコピーするファイルへのパスに置き換えます。
# scp -p Storage.example.com:/backup/EngineBackupFiles /backup/
--change-db-credentials
パラメーターを使用して新規データベースの認証情報を渡し、完全なバックアップまたはデータベースのみのバックアップを復元します。Manager のローカルに設定されているデータベースの database_location はlocalhost
です。注記
以下の例では、パスワードは指定せずに、各データベースに--*password
オプションを使用するため、このコマンドを実行すると、データベースごとにパスワードを入力するように要求されます。コマンド内でこれらのオプションにパスワードを指定することも可能ですが、パスワードが shell の履歴に保存されてしまうため推奨しません。別の方法として、各データベースに--*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
Reports および 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-reports-db-credentials --reports-db-host=database_location --reports-db-name=database_name --reports-db-user=ovirt_engine_reports --reports-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
- データベースのみのバックアップを復元する場合 (設定ファイルのバックアップを最初に復元してからデータベースのバックアップを復元):
# engine-backup --mode=restore --scope=files --file=file_name --log=log_file_name
# engine-backup --mode=restore --scope=db --file=file_name --log=file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password
上記の例では、Manager データベースのバックアップが復元されます。# engine-backup --mode=restore --scope=reportsdb --file=file_name --log=file_name --change-reports-db-credentials --reports-db-host=database_location --reports-db-name=database_name --reports-db-user=ovirt_engine_reports --reports-db-password
上記の例では、Reports データベースのバックアップが復元されます。# engine-backup --mode=restore --scope=dwhdb --file=file_name --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
上記の例では、Data Warehouse データベースのバックアップが復元されます。
正常に終了すると、以下のような出力が表示されます。You should now run engine-setup. Done.
- 復元した Manager 仮想マシンを設定します。このプロセスにより、既存の構成設定およびデータベースの内容が特定されますので、設定を確認してください。完了すると、この設定で SSH フィンガープリントと内部の証明局のハッシュが提供されます。
# engine-setup
[ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'] Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20140304075238.log Version: otopi-1.1.2 (otopi-1.1.2-1.el6ev) [ INFO ] Stage: Environment packages setup [ INFO ] Yum Downloading: rhel-65-zstream/primary_db 2.8 M(70%) [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ INFO ] Stage: Environment customization --== PACKAGES ==-- [ INFO ] Checking for product updates... [ INFO ] No product updates found --== NETWORK CONFIGURATION ==-- Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]: [ INFO ] iptables will be configured as firewall manager. --== DATABASE CONFIGURATION ==-- --== OVIRT ENGINE CONFIGURATION ==-- Skipping storing options as database already prepared --== PKI CONFIGURATION ==-- PKI is already configured --== APACHE CONFIGURATION ==-- --== SYSTEM CONFIGURATION ==-- --== END OF CONFIGURATION ==-- [ INFO ] Stage: Setup validation [ INFO ] Cleaning stale zombie tasks --== CONFIGURATION PREVIEW ==-- Database name : engine Database secured connection : False Database host : X.X.X.X Database user name : engine Database host name validation : False Database port : 5432 NFS setup : True Firewall manager : iptables Update Firewall : True Configure WebSocket Proxy : True Host FQDN : Manager.example.com NFS mount point : /var/lib/exports/iso Set application as default page : True Configure Apache SSL : True Please confirm installation settings (OK, Cancel) [OK]:
復元した環境からのホストの削除
バックアップしたエンジンに存在しない一意名が指定されている新規ハードウェアに、復元したセルフホストエンジンをデプロイする場合には、このステップは省略してください。このステップは、フェイルオーバーホスト (hosted_engine_1
) でデプロイメントを行う場合にのみ適用されます。このホストは、バックアップ作成時に環境に存在していたため、復元したエンジンにも存在しています。最終的な同期を行う前には、このホストを環境から削除する必要があります。- 管理ポータルにログインします。
- ホスト タブをクリックします。フェイルオーバーホスト
hosted_engine_1
は、バックアップ時に準備したように、仮想負荷のない状態でメンテナンスモードに入っているはずです。 - 削除 をクリックします。
- OK をクリックします。
ホストと Manager の同期
ホストに戻り、オプション 1 を選択してhosted-engine
デプロイメントスクリプトを続行します。(1) Continue setup - engine installation is complete
[ INFO ] Engine replied: DB Up!Welcome to Health Status! [ INFO ] Waiting for the host to become operational in the engine. This may take several minutes... [ INFO ] Still waiting for VDSM host to become operational...
この時点でhosted_engine_1
は管理ポータルに表示されますが、ステータスは Installing および Initializing を経てから Non Operational に切り替わります。ホストは、VDSM ホストが稼動状態になるまで待機し続けますが、最終的に VDSM ホストはタイムアウトになります。これは、環境内の別のホストが Storage Pool Manager (SPM) ロールを維持しており、SPM ホストが Non Responsive の状態にあるためhosted_engine_1
がストレージドメインと対話できなくなるのが原因です。このプロセスがタイムアウトすると、仮想マシンをシャットダウンしてデプロイメントを完了するようにプロンプトが表示されます。デプロイメントが完了したら、ホストを手動でメンテナンスモードに指定して、管理ポータルからアクティブ化することができます。[ INFO ] Still waiting for VDSM host to become operational... [ ERROR ] Timed out while waiting for host to start. Please check the logs. [ ERROR ] Unable to add hosted_engine_2 to the manager Please shutdown the VM allowing the system to launch it as a monitored service. The system will wait until the VM is down.
- 新しい Manager 仮想マシンをシャットダウンします。
# shutdown -h now
- ホストに戻り、Manager 仮想マシンのリブートが検出されていることを確認します。
[ INFO ] Enabling and starting HA services Hosted Engine successfully set up [ INFO ] Stage: Clean up [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination
- ホストをアクティブ化します。
- 管理ポータルにログインします。
- ホスト タブをクリックします。
hosted_engine_1
を選択して、メンテナンス ボタンをクリックします。ホストがメンテナンスモードに入るまで、数分かかる場合があります。- アクティブ化 ボタンをクリックします。
アクティブ化の後には、hosted_engine_1
はアクティブ化されると即時に SPM の候補となり、ストレージドメインとデータセンターがアクティブになります。 - Non Responsive なホストを手動でフェンシングして、仮想マシンをアクティブなホストに移行します。管理ポータルで、対象のホストを右クリックして、ホストがリブートされていることを確認 を選択します。バックアップ時にホストで実行中だった仮想マシンは、この時点でホストから削除され、Unknown から Down のステータスに切り替わります。これらの仮想マシンは、
hosted_engine_1
で実行できるようになりました。フェンスされたホストは、REST API を使用して強制的に削除することができます。
hosted_engine_1
がアクティブな時点に環境が復元され、復元した環境で仮想マシンを実行できるようになりました。ステータスが Non Operational となっている残りのセルフホストエンジンホストは、削除してから環境内に再インストールすることが可能です。