Red Hat Training

A Red Hat training course is available for Red Hat Virtualization

6.2.3. 자체 호스트 엔진 관리자 수동 복원

다음 절차에서는 백업된 자체 호스팅 엔진 관리자 가상 시스템의 구성 설정 및 데이터베이스 콘텐츠를 수동으로 복원하는 방법을 간략하게 설명합니다.

절차 6.6. 자체 호스트 엔진 관리자 복원

  1. 백업의 데이터베이스 콘텐츠를 복원할 수 있는 빈 데이터베이스를 수동으로 생성합니다. 데이터베이스를 호스팅할 시스템에서 다음 단계를 수행해야 합니다.
    1. 데이터베이스가 Manager 가상 머신이 아닌 시스템에서 호스팅되는 경우 postgresql-server 패키지를 설치합니다. 이 패키지가ECDHE 패키지에 포함되어 있으므로 Manager 가상 머신에서 데이터베이스를 호스팅할 때는 이 단계가 필요하지 않습니다.
      # 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';
      데이터도 복원하는 경우 관련 호스트에 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';
      데이터도 복원 중인 경우 관련 호스트에 데이터베이스를 생성합니다.
      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/postgresql.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 가상 머신에 복사합니다. 이 예에서는 6.1절. “자체 호스팅 엔진 관리자 가상 머신 백업” 에서 파일이 복사된 네트워크 스토리지 서버에서 파일을 복사합니다. 이 예에서 Storage.example.com 은 스토리지 서버의 정규화된 도메인 이름으로, /backup/EngineBackupFiles 는 스토리지 서버의 백업 파일에 지정된 파일 경로이며 /backup/ 는 파일을 새 관리자에서 복사할 경로입니다.
    # scp -p Storage.example.com:/backup/EngineBackupFiles /backup/
  3. --change-db-credentials 매개변수를 사용하여 전체 백업 또는 데이터베이스 전용 백업을 복원하여 새 데이터베이스의 인증 정보를 전달합니다. Manager에 로컬인 데이터베이스의 database_locationlocalhost 입니다.
    참고
    다음 예제에서는 각 데이터베이스에 --*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
      전체 백업의 일부로 데이터도 복원되는 경우 추가 데이터베이스에 대한 수정된 자격 증명을 포함합니다.
      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
      위의 예에서는 데이터ECDHE 데이터베이스의 백업을 복원합니다.
    성공하면 다음 출력이 표시됩니다.
    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. 확인을 클릭합니다.
  6. 호스트 및 관리자 동기화

    호스트로 돌아가서 옵션 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 and Initializing 상태를 사용하여 관리 포털에 표시됩니다. 호스트는 결국 시간이 초과될 때까지 VDSM 호스트가 작동할 때까지 계속 기다립니다. 이는 환경의 또 다른 호스트에서SPM(Storage Pool Manager) 역할을 유지 관리하고 hosted_engine_1 이 스토리지 도메인과 상호 작용할 수 없기 때문에 seccomp 호스트가 무응답 상태에 있기 때문입니다. 이 프로세스가 시간 초과되면 배포를 완료하기 위해 가상 머신을 종료하라는 메시지가 표시됩니다. 배포가 완료되면 호스트를 수동으로 유지 관리 모드로 배치하고 관리 포털을 통해 활성화할 수 있습니다.
    [ 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 을 선택하고 Maintenance 버튼을 클릭합니다. 호스트는 유지 관리 모드로 전환되기까지 몇 분이 걸릴 수 있습니다.
    4. 활성화 버튼을 클릭합니다.
    활성 상태가 되면 hosted_engine_1 이 즉시 설정되고 스토리지 도메인과 데이터 센터가 활성화됩니다.
  10. Non Responsive 호스트를 수동으로 펜싱하여 가상 머신을 활성 호스트로 마이그레이션합니다. 관리 포털에서 호스트를 마우스 오른쪽 버튼으로 클릭하고 '호스트 확인'을 선택합니다.
    백업 시 해당 호스트에서 실행 중인 가상 머신은 해당 호스트에서 제거되고 알 수 없는 상태에서 Down 상태로 이동합니다. 이제 이러한 가상 머신을 hosted_engine_1 에서 실행할 수 있습니다. 이제 REST API를 사용하여 펜싱된 호스트를 강제로 제거할 수 있습니다.
이제 환경이 hosted_engine_1 이 활성 상태이고 복원된 환경에서 가상 머신을 실행할 수 있는 시점으로 복원되었습니다. 비작동 상태의 나머지 자체 호스팅 엔진 노드는 이제 6.2.4절. “복원된 자체 호스팅 엔진 환경에서 작동하지 않는 호스트 제거” 의 단계에 따라 7장. 자체 호스트 환경에 추가 호스트 설치 단계에 따라 환경에 다시 설치하여 제거할 수 있습니다.
참고
Manager 데이터베이스를 성공적으로 복원했지만 Manager 가상 머신이 Down 으로 표시되고 다른 자체 호스팅 엔진 노드로 마이그레이션할 수 없는 경우 새 Manager 가상 머신을 활성화하고 에 제공된 https://access.redhat.com/solutions/1517683 단계에 따라 환경에서 dead Manager 가상 머신을 제거할 수 있습니다.