Red Hat Training

A Red Hat training course is available for Red Hat Virtualization

6.2. セルフホストエンジン環境の復元

本セクションでは、セルフホストエンジン環境をバックアップから新規インストールしたホストに復元する方法について説明します。サポートされている復元方法では engine-backup ツールを使用します。
セルフホストエンジン環境の復元には、主に次のような操作を行う必要があります。
  1. 新規インストールした Red Hat Enterprise Linux ホストを用意し、ホストエンジンのデプロイメントスクリプトを実行します。
  2. Red Hat Virtualization Manager の構成設定およびデータベースの内容を新しい Manager 用仮想マシンに復元します。
  3. ステータスが Non Operational のセルフホストエンジン用ホストを削除して、復元後のセルフホストエンジン環境で再インストールします。

前提条件

  • セルフホストエンジン環境を復元するには、物理ホスト上に新規インストールした Red Hat Enterprise Linux システムを用意する必要があります。
  • 新規ホストおよび Manager のオペレーティングシステムのバージョンは、バックアップしたホストと Manager のバージョンと同じでなければなりません。
  • 新しい環境には、Red Hat サブスクリプション管理のエンタイトルメントが必要です。必要なリポジトリーの一覧については、『インストールガイド』の「必要なエンタイトルメントのサブスクライブ」を参照してください。
  • 新しい Manager の完全修飾ドメイン名と、バックアップした Manager のドメイン名は同じでなければなりません。また、正引き (フォワードルックアップ) と逆引き (リバースルックアップ) の両方を DNS で設定する必要があります。
  • 新規セルフホストエンジン環境で Manager 用仮想マシンの共有ストレージドメインとして使用するストレージを準備する必要があります。このドメインの容量は、少なくとも 60 GB 必要です。デプロイメント用のストレージの準備に関する詳しい情報は、 『管理ガイド』の「ストレージ」の章を参照してください。

6.2.1. 復元環境として使用する新規セルフホストエンジン環境の構築

バックアップした環境で使用したハードウェア上にセルフホストエンジンを復元することはできますが、復元環境のデプロイメントにはフェイルオーバーホストを使用する必要があります。「セルフホストエンジンの Manager 用仮想マシンのバックアップ」で使用したフェイルオーバーホスト Host 1hosted_engine_1 というデフォルトのホスト名を使用します。以下の手順でもこの名称を使用します。セルフホストエンジンの復元プロセスの性質上、フェイルオーバーホストを削除してから、復元したエンジンの最終同期を実行する必要があります。ただし、これは、バックアップ時に、ホスト上に仮想負荷がない場合にしか実行できません。また、バックアップ環境に使用していない別のハードウェアにバックアップを復元することも可能です。その場合には、この問題を考慮する必要はありません。

重要

本手順は、物理ホストへの Red Hat Enterprise Linux の新規インストール、必要なエンタイトルメントへのホストのサブスクリプション登録、ovirt-hosted-engine-setup パッケージのインストールが完了していることが前提となります。詳しい情報は、『インストールガイド』の「必要なエンタイトルメントのサブスクライブ」および「セルフホストエンジン (Self-Hosted Engine) のパッケージのインストール」を参照してください。

手順6.4 復元環境として使用するために新規セルフホスト環境を構築する方法

  1. DNS の更新

    Red Hat Virtualization 環境の完全修飾ドメイン名と新規 Manager の IP アドレスが相関するように、DNS を更新してください。以下の手順では、完全修飾ドメイン名は Manager.example.com に設定されています。engine に指定する完全修飾ドメイン名は、バックアップ元の engine を設定する際に指定したものと同一の名前を使用する必要があります。
  2. ホストエンジンデプロイメントの開始

    新規インストールされた Red Hat Enterprise Linux ホストで hosted-engine デプロイメントスクリプトを実行します。CTRL+D のキーの組み合わせを使用してデプロイメントを中断すると、スクリプトを随時終了することができます。ネットワーク経由で hosted-engine デプロイメントスクリプトを実行する場合には、ネットワークまたはターミナルの中断が発生した場合にセッションが失われないように screen ウィンドウマネージャーを使用することを推奨します。screen がインストールされていない場合には、先にインストールしてください。
    # screen
    # hosted-engine --deploy
  3. 初期化の準備

    このスクリプトは最初に、セルフホストエンジン環境で対象のホストをハイパーバイザーとして使用することについての確認を要求します。
    Continuing will configure this host for serving as hypervisor and create a VM where you have to install oVirt Engine afterwards. 
    Are you sure you want to continue? (Yes, No)[Yes]:
  4. ストレージの設定

    使用するストレージのタイプを選択します。
    During customization use CTRL-D to abort.
    Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs3, nfs4)[nfs3]:
    • NFS ストレージタイプの場合には、完全修飾ドメイン名または IP アドレスを使用した完全なアドレスと、共有ストレージドメインのパス名を指定します。
      Please specify the full shared storage connection path to use (example: host:/path): storage.example.com:/hosted_engine/nfs
    • iSCSI の場合には、iSCSI ポータルの IP アドレス、ユーザー名、およびパスワードを指定して、自動検出されたリストからターゲット名を選択します。デプロイメント時に選択できる iSCSI ターゲットは 1 つのみです。
      Please specify the iSCSI portal IP address:           
      Please specify the iSCSI portal port [3260]:           
      Please specify the iSCSI portal user:           
      Please specify the iSCSI portal password:
      Please specify the target name (auto-detected values) [default]:
    • Gluster ストレージタイプの場合には、完全修飾ドメイン名または IP アドレスを使用した完全なアドレスと、共有ストレージドメインのパス名を指定します。

      重要

      サポートされるストレージは、レプリカ 3 の Gluster ストレージのみです。以下の設定を完了しておいてください。
      • Gluster サーバー 3 つすべての /etc/glusterfs/glusterd.vol ファイルで、rpc-auth-allow-insecureon に設定してください。
        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
      Please specify the full shared storage connection path to use (example: host:/path): storage.example.com:/hosted_engine/gluster_volume
    • Fiber Channel については、ホストのバスアダプターが設定、接続されている必要があります。設定/接続がされている場合には hosted-engine により、利用可能な LUN が自動で検出されます。LUN には既存のデータが含まれないようにする必要があります。
      The following luns have been found on the requested target:
      [1]     3514f0c5447600351       30GiB   XtremIO XtremApp
                              status: used, paths: 2 active
                
      [2]     3514f0c5447600352       30GiB   XtremIO XtremApp
                              status: used, paths: 2 active
      
      Please select the destination LUN (1, 2) [1]:
  5. ネットワークの設定

    このスクリプトは、環境の管理ブリッジとして使用可能なネットワークインターフェースコントローラー (NIC) を検出し、次にファイアウォールの設定を確認して、その設定を Manager 用仮想マシンにコンソールで (SPICE または VNC) アクセスできるように変更するかどうかを確認します。ovirt-ha-agent で使用できる、ping 送信可能なゲートウェイの IP アドレスを提供すると、Manager 用仮想マシンを実行するのに適したホストであるかどうかを判断しやすくなります。
    Please indicate a nic to set ovirtmgmt bridge on: (eth1, eth0) [eth1]:
    iptables was detected on your computer, do you wish setup to configure it? (Yes, No)[Yes]: 
    Please indicate a pingable gateway IP address [X.X.X.X]:
    
  6. 新しい Manager 用仮想マシンの設定

    このスクリプトにより、新しい Manager 用仮想マシンとして設定される仮想マシンが作成されます。ブートデバイス (該当する場合)、インストールメディアのパス名、イメージのエイリアス、CPU タイプ、仮想 CPU の数、ディスクサイズを指定します。Manager の MAC アドレスを指定するか、ランダムに生成された Mac アドレスを適用します。MAC アドレスは、Manager 用仮想マシンにオペレーティングシステムをインストール前に DHCP サーバーを更新するのに使用することができます。Manager 用仮想マシンの作成に必要なメモリーサイズとコンソールの接続タイプも指定します。
    Please specify the device to boot the VM from (cdrom, disk, pxe) [cdrom]: 
    Please specify an alias for the Hosted Engine image [hosted_engine]:  
    The following CPU types are supported by this host:
              - model_Penryn: Intel Penryn Family
              - model_Conroe: Intel Conroe Family
    Please specify the CPU type to be used by the VM [model_Penryn]: 
    Please specify the number of virtual CPUs for the VM [Defaults to minimum requirement: 2]: 
    Please specify the disk size of the VM in GB [Defaults to minimum requirement: 25]: 
    You may specify a MAC address for the VM or accept a randomly generated default [00:16:3e:77:b2:a4]: 
    Please specify the memory size of the VM in MB [Defaults to minimum requirement: 4096]: 
    Please specify the console type you want to use to connect to the VM (vnc, spice) [vnc]:
    
  7. ホスト名の特定

    admin@internal ユーザーが管理ポータルにアクセスするためのパスワードを指定します。
    ホスト名には一意の名前を指定して、engine をバックアップから復元した時点で存在する他のリソースと競合しないようにします。本手順では、対象のホストは環境がバックアップされる前にメンテナンスモードに設定され、engine を復元してからホストと engine を同期するまでの間に、このホストを削除することができるため、hosted_engine_1 という名前を使用することができます。
    Enter engine admin password: 
    Confirm engine admin password:
    Enter the name which will be used to identify this host inside the Administration Portal [hosted_engine_1]:
  8. ホストエンジンの設定

    新規の Manager 用仮想マシンの完全修飾ドメイン名を設定します。本手順では、Manager.example.com という完全修飾ドメイン名を使用します。次に、SMTP サーバーの名前と TCP ポート番号、メール通知の送信先に使用するメールアドレス、これらの通知を受信するメールアドレス (コンマ区切りの一覧) を指定してください。

    重要

    engine に指定した完全修飾ドメイン名 (Manager.example.com) は、元の Manager の初期設定時に指定した名前と同じ完全修飾ドメイン名でなければなりません。
    Please provide the FQDN for the engine you would like to use.
    This needs to match the FQDN that you will use for the engine installation within the VM.
     Note: This will be the FQDN of the VM you are now going to create,
     it should not point to the base host or to any other existing machine.
     Engine FQDN: Manager.example.com
    Please provide the name of the SMTP server through which we will send notifications [localhost]: 
    Please provide the TCP port number of the SMTP server [25]: 
    Please provide the email address from which notifications will be sent [root@localhost]: 
    Please provide a comma-separated list of email addresses which will get notifications [root@localhost]:
  9. 設定のプレビュー

    先に進む前に、hosted-engine デプロイメントスクリプトは、入力された設定値を表示して、これらの値で設定を続行するかどうかを尋ねます。
    Bridge interface                   : eth1
    Engine FQDN                        : Manager.example.com
    Bridge name                        : ovirtmgmt
    SSH daemon port                    : 22
    Firewall manager                   : iptables
    Gateway address                    : X.X.X.X
    Host name for web application      : hosted_engine_1
    Host ID                            : 1
    Image alias                        : hosted_engine
    Image size GB                      : 25
    Storage connection                 : storage.example.com:/hosted_engine/nfs
    Console type                       : vnc
    Memory size MB                     : 4096
    MAC address                        : 00:16:3e:77:b2:a4
    Boot type                          : pxe
    Number of CPUs                     : 2
    CPU Type                           : model_Penryn
    
    Please confirm installation settings (Yes, No)[Yes]:
    
  10. 新しい Manager 用仮想マシンの作成

    次にこのスクリプトは、Manager 用仮想マシンとして設定する仮想マシンを作成して、接続情報を表示します。hosted-engine スクリプトがホストエンジンの設定に進む前に、仮想マシンにオペレーティングシステムをインストールする必要があります。
    [ INFO  ] Stage: Transaction setup
    [ INFO  ] Stage: Misc configuration
    [ INFO  ] Stage: Package installation
    [ INFO  ] Stage: Misc configuration
    [ INFO  ] Configuring libvirt
    [ INFO  ] Configuring VDSM
    [ INFO  ] Starting vdsmd
    [ INFO  ] Waiting for VDSM hardware info
    [ INFO  ] Waiting for VDSM hardware info
    [ INFO  ] Configuring the management bridge
    [ INFO  ] Creating Storage Domain
    [ INFO  ] Creating Storage Pool
    [ INFO  ] Connecting Storage Pool
    [ INFO  ] Verifying sanlock lockspace initialization
    [ INFO  ] Creating VM Image
    [ INFO  ] Disconnecting Storage Pool
    [ INFO  ] Start monitoring domain
    [ INFO  ] Configuring VM
    [ INFO  ] Updating hosted-engine configuration
    [ INFO  ] Stage: Transaction commit
    [ INFO  ] Stage: Closing up
    [ INFO  ] Creating VM
    You can now connect to the VM with the following command:
          /usr/bin/remote-viewer vnc://localhost:5900
    Use temporary password "3477XXAM" to connect to vnc console.
    Please note that in order to use remote-viewer you need to be able to run graphical applications.
    This means that if you are using ssh you have to supply the -Y flag (enables trusted X11 forwarding).
    Otherwise you can run the command from a terminal in your preferred desktop environment.
    If you cannot run graphical applications you can connect to the graphic console from another host or connect to the console using the following command:
    virsh -c qemu+tls://Test/system console HostedEngine
    If you need to reboot the VM you will need to start it manually using the command:
    hosted-engine --vm-start
    You can then set a temporary password using the command:
    hosted-engine --add-console-password
    The VM has been started.  Install the OS and shut down or reboot it.  To continue please make a selection:
             
      (1) Continue setup - VM installation is complete
      (2) Reboot the VM and restart installation
      (3) Abort setup
      (4) Destroy VM and abort setup
             
      (1, 2, 3, 4)[1]:
    本手順の命名規則を使用して、以下のコマンドで VNC を使って仮想マシンに接続します。
    /usr/bin/remote-viewer vnc://hosted_engine_1.example.com:5900
  11. 仮想マシンのオペレーティングシステムのインストール

    Manager 用仮想マシンに接続して、Red Hat Enterprise Linux 7 のオペレーティングシステムをインストールします。
  12. ホストと Manager の同期

    ホストに戻り、オプション 1 を選択して hosted-engine デプロイメントスクリプトを続行します。
    (1) Continue setup - VM installation is complete
    Waiting for VM to shut down...
    [ INFO  ] Creating VM
    You can now connect to the VM with the following command:
          /usr/bin/remote-viewer vnc://localhost:5900
    Use temporary password "3477XXAM" to connect to vnc console.
    Please note that in order to use remote-viewer you need to be able to run graphical applications.
    This means that if you are using ssh you have to supply the -Y flag (enables trusted X11 forwarding).
    Otherwise you can run the command from a terminal in your preferred desktop environment.
    If you cannot run graphical applications you can connect to the graphic console from another host or connect to the console using the following command:
    virsh -c qemu+tls://Test/system console HostedEngine
    If you need to reboot the VM you will need to start it manually using the command:
    hosted-engine --vm-start
    You can then set a temporary password using the command:
    hosted-engine --add-console-password
    Please install and setup the engine in the VM.
    You may also be interested in subscribing to "agent" RHN/Satellite channel and installing rhevm-guest-agent-common package in the VM.
    To continue make a selection from the options below:
      (1) Continue setup - engine installation is complete
      (2) Power off and restart the VM
      (3) Abort setup
      (4) Destroy VM and abort setup
             
      (1, 2, 3, 4)[1]:
  13. Manager のインストール

    新しい Manager 用仮想マシンに接続し、インストールしたパッケージがすべて最新版を使用していることを確認してから、rhevm パッケージをインストールします。
    # yum update

    注記

    カーネル関連のパッケージを更新した場合には、マシンを再起動してください。
    # yum install rhevm
パッケージのインストールの完了後には、セルフホストエンジンの Manager の復元を続行することができます。

6.2.2. セルフホストエンジン Manager の復元

以下の手順では、engine-backup ツールを使用して、バックアップしたセルフホストエンジンの Manager 用仮想マシン、Data Warehouse の構成設定とデータベースコンテンツを自動的に復元する方法を説明します。この手順は、engine-setup の初回実行時に自動的に設定したコンポーネントのみが対象です。engine-setup 時にデータベースを手動で設定した場合は、「セルフホストエンジン Manager の手動での復元」の説明に従って、バックアップ環境を手動で復元してください。

手順6.5 セルフホストエンジン Manager の復元

  1. バックアップファイルを新しい Manager 用仮想マシンにセキュアコピーします。この例では、「セルフホストエンジンの Manager 用仮想マシンのバックアップ」でファイルをコピーしたネットワークストレージサーバーからファイルをコピーします。このコマンドで、Storage.example.com はストレージサーバーの完全修飾ドメイン名、/backup/EngineBackupFiles はストレージサーバーのバックアップファイルへの指定ファイルパス、/backup/ は新規 Manager 上にバックアップファイルをコピーするファイルへのパスに置き換えます。
    # scp -p Storage.example.com:/backup/EngineBackupFiles /backup/
  2. engine-backup ツールを使用して完全なバックアップを復元します。
    • Manager のみを復元する場合は、以下を実行します。
      # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions
    • Manager と Data Warehouse を復元する場合には、以下を実行します。
      # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --provision-dwh-db --restore-permissions
    正常に終了すると、以下のような出力が表示されます。
    You should now run engine-setup.
    Done.
  3. 復元した 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]:
  4. 復元した環境からのホストの削除

    バックアップしたエンジンに存在しない一意名が指定されている新規ハードウェアに、復元したセルフホストエンジンをデプロイする場合には、このステップは省略してください。このステップは、フェイルオーバーホスト (hosted_engine_1) でデプロイメントを行う場合にのみ適用されます。このホストは、バックアップ作成時に環境に存在していたため、復元したエンジンにも存在しています。最終的な同期を行う前には、このホストを環境から削除する必要があります。
    1. 管理ポータルにログインします。
    2. ホスト タブをクリックします。フェイルオーバーホスト hosted_engine_1 は、バックアップ時に準備したように、仮想負荷のない状態でメンテナンスモードに入っているはずです。
    3. 削除 をクリックします。
    4. OK をクリックします。

    注記

    削除するホストが non-operational になった場合には、「復元したセルフホストエンジン環境からの非稼働状態のホストの削除」から、ホストの強制削除の方法を参照してください。
  5. ホストと 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.
  6. 新しい Manager 用仮想マシンをシャットダウンします。
    # shutdown -h now
  7. ホストに戻り、Manager 用仮想マシンのリブートが検出されていることを確認します。
    [ INFO  ] Enabling and starting HA services
              Hosted Engine successfully set up
    [ INFO  ] Stage: Clean up
    [ INFO  ] Stage: Pre-termination
    [ INFO  ] Stage: Termination
  8. ホストをアクティブ化します。
    1. 管理ポータルにログインします。
    2. ホストタブをクリックします。
    3. hosted_engine_1 を選択して、メンテナンス ボタンをクリックします。ホストがメンテナンスモードに入るまで、数分かかる場合があります。
    4. アクティブ化 ボタンをクリックします。
    アクティブ化の後には、hosted_engine_1 はアクティブ化されると即時に SPM の候補となり、ストレージドメインとデータセンターがアクティブになります。
  9. Non Responsive なホストを手動でフェンシングして、仮想マシンをアクティブなホストに移行します。管理ポータルで、対象のホストを右クリックして、ホストがリブートされていることを確認 を選択します。
    バックアップ時にホストで実行中だった仮想マシンは、この時点でホストから削除され、Unknown から Down のステータスに切り替わります。これらの仮想マシンは、hosted_engine_1 で実行できるようになりました。フェンスされたホストは、REST API を使用して強制的に削除することができます。
hosted_engine_1 がアクティブな時点に環境が復元され、復元した環境で仮想マシンを実行できるようになりました。ステータスが Non Operational となっている残りのセルフホストエンジン用ホストは、「復元したセルフホストエンジン環境からの非稼働状態のホストの削除」の手順に従って削除してから、「7章セルフホスト環境に追加のホストをインストールする手順」を参照して環境内に再インストールすることが可能です。

注記

Manager データベースの復元が正常に完了したにもかかわらず、Manager 用仮想マシンのステータスが Down と表示されて、別のセルフホストエンジン用ホストに移行できない場合には、https://access.redhat.com/solutions/1517683 に記載の手順に従って、新規 Manager 用仮想マシンを有効にして、動作しなくなった Manager 用仮想マシンを環境から削除することができます。

6.2.3. セルフホストエンジン Manager の手動での復元

以下の手順では、バックアップしたセルフホストエンジンの Manager 用仮想マシンの構成設定およびデータベースの内容を手動で復元する方法を説明します。

手順6.6 セルフホストエンジン Manager の復元

  1. バックアップに含まれるデータベースのコンテンツの復元先となる、空のデータベースを手動で作成します。以下の手順は、データベースがホストされるマシンで実行する必要があります。
    1. データベースが Manager 用仮想マシン以外のマシンでホストされている場合は、postgresql-server パッケージをインストールする必要があります。データベースが Manager 用仮想マシンでホストされている場合には、rhevm パッケージにこのパッケージが含まれているため、このステップは必要ありません。
      # yum install postgresql-server
    2. postgresql データベースを初期化し、postgresql サービスを起動してから、このサービスがブート時に起動されるように設定します。
      # postgresql-setup initdb
      # systemctl start postgresql.service
      # systemctl enable postgresql.service
    3. postgresql のコマンドラインに入ります。
      # su postgres
      $ psql
    4. engine ユーザーを作成します。
      postgres=# create role engine with login encrypted password 'password';
      Data Warehouse も復元する場合には、対象のホストで ovirt_engine_history ユーザーを作成します。
      postgres=# create role ovirt_engine_history with login encrypted password 'password';
    5. 新規データベースを作成します。
      postgres=# create database database_name owner engine template template0 encoding 'UTF8' lc_collate 'en_US.UTF-8' lc_ctype 'en_US.UTF-8';
      Data Warehouse も復元する場合には、対象のホストでデータベースを作成します。
      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';
    6. postgresql コマンドラインを終了して、postgres ユーザーからログアウトします。
      postgres=# \q
      $ exit
    7. /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
    8. postgresql サービスを再起動します。
      # systemctl restart postgresql.service
  2. バックアップファイルを新しい Manager 用仮想マシンにセキュアコピーします。この例では、「セルフホストエンジンの Manager 用仮想マシンのバックアップ」でファイルをコピーしたネットワークストレージサーバーからファイルをコピーします。このコマンドで、Storage.example.com はストレージサーバーの完全修飾ドメイン名、/backup/EngineBackupFiles はストレージサーバーのバックアップファイルへの指定ファイルパス、/backup/ は新規 Manager 上にバックアップファイルをコピーするファイルへのパスに置き換えます。
    # scp -p Storage.example.com:/backup/EngineBackupFiles /backup/
  3. --change-db-credentials パラメーターを使用して新規データベースの認証情報を渡し、完全なバックアップまたはデータベースのみのバックアップを復元します。Manager のローカルに設定されているデータベースの database_locationlocalhost です。

    注記

    以下の例では、パスワードは指定せずに、各データベースに --*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
      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
    • データベースのみのバックアップを復元する場合 (設定ファイルとデータベースのバックアップを復元):
      # engine-backup --mode=restore --scope=files --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=files --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.
  4. 復元した 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]:
  5. 復元した環境からのホストの削除

    バックアップしたエンジンに存在しない一意名が指定されている新規ハードウェアに、復元したセルフホストエンジンをデプロイする場合には、このステップは省略してください。このステップは、フェイルオーバーホスト (hosted_engine_1) でデプロイメントを行う場合にのみ適用されます。このホストは、バックアップ作成時に環境に存在していたため、復元したエンジンにも存在しています。最終的な同期を行う前には、このホストを環境から削除する必要があります。
    1. 管理ポータルにログインします。
    2. ホスト タブをクリックします。フェイルオーバーホスト hosted_engine_1 は、バックアップ時に準備したように、仮想負荷のない状態でメンテナンスモードに入っているはずです。
    3. 削除 をクリックします。
    4. OK をクリックします。
  6. ホストと 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.
  7. 新しい Manager 用仮想マシンをシャットダウンします。
    # shutdown -h now
  8. ホストに戻り、Manager 用仮想マシンのリブートが検出されていることを確認します。
    [ INFO  ] Enabling and starting HA services
              Hosted Engine successfully set up
    [ INFO  ] Stage: Clean up
    [ INFO  ] Stage: Pre-termination
    [ INFO  ] Stage: Termination
  9. ホストをアクティブ化します。
    1. 管理ポータルにログインします。
    2. ホスト タブをクリックします。
    3. hosted_engine_1 を選択して、メンテナンス ボタンをクリックします。ホストがメンテナンスモードに入るまで、数分かかる場合があります。
    4. アクティブ化 ボタンをクリックします。
    アクティブ化の後には、hosted_engine_1 はアクティブ化されると即時に SPM の候補となり、ストレージドメインとデータセンターがアクティブになります。
  10. Non Responsive なホストを手動でフェンシングして、仮想マシンをアクティブなホストに移行します。管理ポータルで、対象のホストを右クリックして、ホストがリブートされていることを確認 を選択します。
    バックアップ時にホストで実行中だった仮想マシンは、この時点でホストから削除され、Unknown から Down のステータスに切り替わります。これらの仮想マシンは、hosted_engine_1 で実行できるようになりました。フェンスされたホストは、REST API を使用して強制的に削除することができます。
hosted_engine_1 がアクティブな時点に環境が復元され、復元した環境で仮想マシンを実行できるようになりました。ステータスが Non Operational となっている残りのセルフホストエンジン用ホストは、「復元したセルフホストエンジン環境からの非稼働状態のホストの削除」の手順に従って削除してから、「7章セルフホスト環境に追加のホストをインストールする手順」を参照して環境内に再インストールすることが可能です。

注記

Manager データベースの復元が正常に完了したにもかかわらず Manager 用仮想マシンのステータスが Down と表示されて、別のセルフホストエンジン用ホストに移行できない場合には、https://access.redhat.com/solutions/1517683 に記載の手順に従って、新規 Manager 用仮想マシンを有効にして、動作しなくなった Manager 用仮想マシンを環境から削除することができます。

6.2.4. 復元したセルフホストエンジン環境からの非稼働状態のホストの削除

管理ポータルでホストをフェンスした後には、REST API の要求で強制的に削除することができます。以下の手順では、HTTP サーバーに要求を送信するためのコマンドラインインターフェース、cURL を使用します。大半の Linux ディストリビューションには cURL が含まれています。本手順では Manager 用仮想マシンに接続して、適切な要求を実行します。
  1. 非稼働状態のホストのフェンシング

    管理ポータルで、ホストの上で右クリックをして ホストがリブートされていることを確認 を選択します。
    バックアップ時にホストで実行中だった仮想マシンは、この時点でホストから削除され、Unknown から Down のステータスに切り替わります。フェンスされたホストは、REST API を使用して強制的に削除することができます。
  2. Manager の認証局の証明書取得

    Manager 用仮想マシンに接続して、コマンドラインを使用して cURL で以下の要求を実行します。
    GET 要求で、今後の API 要求に使用できるようにManager の認証局 (CA) の証明書を取得します。以下の例では、--output オプションを使用して、Manager CA 証明書の出力先に hosted-engine.ca ファイルを指定します。また、--insecure オプションは、このような最初の要求は証明書なしで行うように指定します。
    # curl --output hosted-engine.ca --insecure https://[Manager.example.com]/ca.crt
  3. 削除するホストの GUID の取得

    一連のホストに対して GET 要求を使用して、削除するホストのグローバル一意識別子 (GUID) を取得します。以下の例では、Manager CA 証明書ファイルを含めます。認証には admin@internal ユーザーを使用し、このユーザーに対するパスワードは、コマンドの実行後に求められます。
    # curl --request GET --cacert hosted-engine.ca --user admin@internal https://[Manager.example.com]/api/hosts
    今回の要求では、環境内の全ホストの詳細情報が返されます。ホストの GUID は、ホスト名が関連付けられた 16 進数の文字列です。Red Hat Virtualization REST API についての詳しい情報は、『Red Hat Virtualization REST API Guide』を参照してください。
  4. フェンスされたホストの削除

    DELETE 要求を使用してフェンスされたホストの GUID を指定し、そのホストを環境から削除します。以前に使用したオプションに加え、以下の例では、拡張マークアップ言語 (XML: eXtensible Markup Language) を使用して要求を送受信するように指定するヘッダーと、force アクションを true に設定する XML 形式の本文を記述します。
    curl --request DELETE --cacert hosted-engine.ca --user admin@internal --header "Content-Type: application/xml" --header "Accept: application/xml" --data "<action><force>true</force></action>" https://[Manager.example.com]/api/hosts/ecde42b0-de2f-48fe-aa23-1ebd5196b4a5
    適切な GUID が指定されている場合には、この DELETE 要求を使用して、セルフホストエンジン環境にある、フェンスされたホストをすべて削除することができます。
  5. ホストからのセルフホストエンジン設定の削除

    ホストのセルフホストエンジン設定を削除して、ホストがセルフホストエンジン環境に再インストールされた場合に再度設定できるようにします。
    ホストにログインして、設定ファイルを削除します。
    # rm /etc/ovirt-hosted-engine/hosted-engine.conf
これで、ホストはセルフホストエンジン環境に再インストールできます。