인스턴스의 고가용성 구성

프로세스

1. 인스턴스 HA 서비스는 Compute 서비스(nova) 데이터베이스를 폴링하여 비우기를 받을 수 있는 실패한 컴퓨팅 노드를 식별합니다. 폴링 간격은 POLL 인스턴스 HA 서비스 매개변수로 지정되며, 기본적으로 45초입니다.

   인스턴스 HA 서비스는 다음 필터링 방법론을 사용합니다.

   • 비우기를 위해 컴퓨팅 노드에는 인스턴스가 포함되어야 합니다.
   • 기본적으로 특정 플레이버 또는 이미지가 태그된 경우 이러한 플레이버 또는 이미지를 사용하는 인스턴스가 포함된 Compute 노드는 비워 둘 수 있습니다. 자세한 내용은 비우기에 대한 태그 이미지, 플레이버 또는 호스트 집계를 참조하십시오.

   • 특정 호스트 집계를 태그한 경우 이러한 호스트 집계의 컴퓨팅 노드는 비워 둘 수 있습니다.

     비우기를 받을 수 없는 모든 컴퓨팅 노드는 무시됩니다.

2. 각 컴퓨팅 노드의 상태는 활성화 되거나 비활성화되어 있습니다. 이 컴퓨팅 노드가 의도적으로 비활성화되었다고 가정하기 때문에 비우기 및 비활성화 상태가 있는 모든 컴퓨팅 노드는 무시됩니다. 자세한 내용은 컴퓨팅 노드 비우기를 참조하십시오.

   참고

   정상적인 컴퓨팅 노드를 의도적으로 비활성화하여 실패한 컴퓨팅 노드 인스턴스를 비우기에 충분한 용량을 제공할 수 있습니다. 자세한 내용은 정상적인 컴퓨팅 노드 예약을 참조하십시오.

3. 각 컴퓨팅 노드의 상태는 up 또는 down 입니다. 상태가 down 인 경우 비워 둘 수 있는 컴퓨팅 노드가 실패했습니다.

   DELTA 인스턴스 HA 서비스 매개변수는 실패한 컴퓨팅 노드를 감지하기 위해 인스턴스 HA 서비스에서 수행한 시간을 줄일 수 있습니다. 이 상태가 지정된 DELTA 기간 내에 업데이트되지 않는 경우 활성화된 상태를 보고하는 비우기를 수행할 수 있는 모든 컴퓨팅 노드도 실패했습니다. 기본적으로 DELTA 기간은 30초입니다. 자세한 내용은 인스턴스 HA 서비스 매개변수 편집을 참조하십시오.

4. 인스턴스 HA 서비스는 실패한 컴퓨팅 노드의 백분율을 계산하고 이 백분율을 THRESHOLD 인스턴스 HA 서비스 매개변수 값과 비교합니다.

   • 백분율이 THRESHOLD 값보다 작거나 같은 경우 인스턴스 HA 서비스는 컴퓨팅 노드를 계속 비웁니다.

   • 백분율이 THRESHOLD 값을 초과하면 인스턴스 HA 서비스에서 로그 메시지에 이 값을 표시하고 컴퓨팅 노드 비우기를 중지합니다.

     참고

     비우기 프로세스가 불가능하게 되기 전에 실패할 수 있는 컴퓨팅 노드 수를 지정하려면 THRESHOLD 매개변수를 설정해야 합니다. 예를 들어 네트워크가 심각하게 손상되었거나 정상 컴퓨팅 노드가 충분하지 않은 경우 실패한 컴퓨팅 노드에서 인스턴스를 비울 수 있습니다.

5. DISABLED Instance HA service 매개변수를 true 로 설정하면 인스턴스 HA 서비스가 실패한 컴퓨팅 노드를 비우지 않습니다. 이 경우 인스턴스 HA 서비스는 컴퓨팅 노드가 다운 되었지만 더 이상 아무 작업도 수행하지 않습니다. DISABLED 매개변수는 기본적으로 false 입니다. 자세한 내용은 컴퓨팅 노드 비우기를 참조하십시오.
6. 정상적인 컴퓨팅 노드를 예약한 경우 인스턴스 HA 서비스는 실패한 컴퓨팅 노드 각각에 대해 하나의 예약된 컴퓨팅 노드를 활성화하려고 합니다. 자세한 내용은 정상적인 컴퓨팅 노드 예약을 참조하십시오.

7. 컴퓨팅 노드가 커널 덤프를 캡처하는지 감지하도록 인스턴스 HA 서비스를 구성하는 경우 인스턴스 HA 서비스는 각 컴퓨팅 노드의 펜싱 또는 전원을 끄고 비우기 전에 kdump 서비스가 완료될 때까지 기다립니다. 자세한 내용은 컴퓨팅 노드가 커널 덤프를 캡처하는지 탐지를 참조하십시오.

   비우기를 받을 수 있는 모든 컴퓨팅 노드의 펜싱 에이전트를 구성해야 합니다. 자세한 내용은 컴퓨팅 노드의 펜싱 구성을 참조하십시오.

   참고

   구성된 펜싱 에이전트가 없으면 컴퓨팅 노드를 비울 수 없습니다.

8. 실패한 컴퓨팅 노드를 펜싱한 후 인스턴스 HA 서비스는 Compute 서비스(nova)를 호출하여 다음 작업을 수행합니다.

   • 실패한 이 컴퓨팅 노드의 상태를 disabled 로 설정하고 --disable-reason 인수에 대한 설명이 포함된 타임스탬프 메시지를 제공합니다.

   • 이 컴퓨팅 노드의 forced Down 플래그를 true 로 설정합니다.

     참고

     인스턴스 HA 서비스는 ACTIVE,ERROR 또는 STOPPED 상태인 인스턴스를 비웁니다. Compute 서비스는 다른 상태의 인스턴스를 비우지 않도록 합니다.

9. LEAVE_DISABLED 인스턴스 HA 서비스 매개변수를 true 로 설정하면 비어 있는 컴퓨팅 노드가 비활성화된 상태로 유지됩니다. 이 작업을 수행하는 한 가지 이유는 결함이 있는 하드웨어로 인해 컴퓨팅 노드가 실패하는 경우 컴퓨팅 노드를 간단히 다시 시작하지 않도록 하는 것입니다. 기본적으로 LEAVE_DISABLED 매개변수는 false 로 설정되므로 비활성화된 컴퓨팅 노드를 성공적으로 비우는 후 비활성화됩니다. 이 경우 인스턴스 HA 서비스는 연결된 펜싱 에이전트에 컴퓨팅 노드의 전원을 켭니다.
10. 컴퓨팅 노드를 다시 사용할 때 컴퓨팅 노드를 비우고 성공적으로 재부팅하면 인스턴스 HA 서비스에서 실패한 컴퓨팅 노드의 Forced Down 플래그를 false 로 설정합니다. 컴퓨팅 노드 비우기가 느리거나 실패한 경우 컴퓨팅 노드의 Forced Down 플래그를 false 로 설정할 수 있습니다. 자세한 내용은 Rehabilitating evacuated Compute nodes 를 참조하십시오.

11. 기본적으로 인스턴스 HA 서비스는 실패한 컴퓨팅 노드의 인스턴스 비우기를 모니터링하지 않습니다. 해당 Compute 서비스(nova) API 요청이 수락되면 이러한 요청이 성공한다고 가정합니다. SMART_EVACUATION 인스턴스 HA 서비스 매개변수를 true 로 설정하면 인스턴스 HA 서비스에서 각 인스턴스의 비우기를 모니터링합니다. 이 경우 인스턴스 HA 서비스는 실패하는 경우 최대 5번 인스턴스를 다시 시도합니다. 인스턴스 비우기가 5회 실패하면 인스턴스 HA 서비스에서 다음 작업을 수행합니다.

    • 인스턴스 HA 서비스는 이 컴퓨팅 노드의 모든 인스턴스 비우기를 중지합니다.
    • 인스턴스 HA 서비스는 실패한 컴퓨팅 노드의 상태를 disabled 로 설정하고 --disable-reason 인수에 대한 설명 타임스탬프 메시지를 제공합니다.

    • Instance HA 서비스는 이 컴퓨팅 노드의 Forced Down 플래그를 true 로 설정합니다.

      실패한 컴퓨팅 노드를 복구하려면 다음 작업을 수행해야 합니다.

    • 이 인스턴스를 비울 수 없는 이유를 확인해야 합니다.
    • 이 컴퓨팅 노드의 다른 모든 인스턴스를 비웁니다.
    • 이 컴퓨팅 노드의 Forced Down 플래그를 false 로 설정해야 합니다.
    • 이 컴퓨팅 노드를 활성화해야 합니다.

    • 이 컴퓨팅 노드가 성공적으로 재부팅되었는지 확인해야 합니다.

      SMART_EVACUATION 인스턴스 HA 서비스 매개변수를 true 로 설정하면 WORKERS 인스턴스 HA 서비스 매개변수를 사용하여 인스턴스 HA 서비스가 기본적으로 4인 동시에 비울 수 있는 인스턴스 수를 지정할 수 있습니다. SMART_EVACUATION 매개변수는 기본적으로 false 입니다.

12. 기본적으로 인스턴스 HA 서비스는 활성화된 각 컴퓨팅 노드를 주기적으로 폴링하지만 forced Down 플래그가 true 로 설정되어 성공적으로 재부팅되었는지 확인합니다. 폴링 간격은 POLL 인스턴스 HA 서비스 매개변수로 지정되며, 기본적으로 45초입니다.

    FORCE_ENABLE Instance HA 서비스 매개변수를 true 로 설정하면 인스턴스 HA 서비스에서 실패한 컴퓨팅 노드의 인스턴스 비우기를 무시합니다. 그러나 SMART_EVACUATION 인스턴스 HA 서비스 매개변수를 true 로 설정하여 이 실패한 비우기를 모니터링 중인 경우에는 적용되지 않습니다. 이 경우 이전 단계에서 설명한 대로 실패한 컴퓨팅 노드가 명시적으로 비활성화되어 이 컴퓨팅 노드를 직접 정리해야 합니다. 기본적으로 FORCE_ENABLE 매개변수는 false 입니다.

프로세스

1. 이 값을 true 로 설정하여 인스턴스 HA 서비스의 RESERVED_HOSTS 매개변수를 활성화합니다. 이 매개변수는 기본적으로 false 입니다. 자세한 내용은 인스턴스 HA 서비스 매개변수 편집을 참조하십시오.

2. 예약할 각 정상 컴퓨팅 노드를 비활성화하고 --disable-reason 인수에 예약된 단어를 지정합니다. 예를 들어 compute-1 을 예약하려면 다음 명령을 지정합니다.

   $ openstack compute service set --disable --disable-reason “reserved” compute-1 nova-compute

3. 예약하려는 모든 컴퓨팅 노드를 비활성화할 때까지 2단계를 반복합니다.

프로세스

1. 컴퓨팅 노드에서 kdump 서비스를 구성하려면 다음 방법 중 하나를 사용합니다.

   • 명령줄을 사용하여 kdump 서비스를 구성할 수 있습니다. 자세한 내용은 RHEL 관리, 모니터링 및 커널 업데이트 의 명령줄에서 kdump 구성 을 참조하십시오.
   • 웹 콘솔을 사용하여 kdump 서비스를 구성할 수 있습니다. 자세한 내용은 RHEL 관리, 모니터링 및 커널 업데이트 의 웹 콘솔에서 kdump 구성 을 참조하십시오.

2. kdump 서비스가 모든 컴퓨팅 노드에서 활성화되어 있는지 확인합니다. 다음 명령의 출력이 활성 상태인지 확인하여 이 작업을 수행할 수 있습니다.

   # systemctl is-active kdump

3. 컴퓨팅 노드에 fence_kdump STONITH 에이전트를 설치합니다.

   # dnf install fence-agents-kdump

4. YAML 인스턴스 HA 서비스 매니페스트 파일에서 인스턴스 HA 서비스 포드의 사양을 정의할 때 다음 옵션을 포함합니다.

   • .spec.networkAttachments: fence_kdump STONITH 에이전트의 UDP kdump 알림을 전송하도록 선택한 네트워크를 지정해야 합니다. 예를 들어 networkAttachments: ['internalapi'] 에서는 지정된 네트워크로 internalapi 를 지정합니다.

   • .spec.instanceHaKdumpPort: fence_kdump STONITH 에이전트 7410에 기본 UDP 포트를 사용하지 않는 경우 이 옵션을 사용하여 선택한 UDP 포트를 지정해야 합니다.

     YAML 인스턴스 HA 서비스 매니페스트 파일을 생성하고 사양을 정의하는 방법에 대한 자세한 내용은 인스턴스 HA 서비스 Pod 사양 구성을 참조하십시오.

5. 인스턴스 HA 서비스를 배포합니다. 자세한 내용은 인스턴스 HA 서비스 배포를 참조하십시오.

6. CHECK_KDUMP 인스턴스 HA 서비스 매개변수를 true 로 설정합니다. 자세한 내용은 인스턴스 HA 서비스 매개변수 편집을 참조하십시오.

   주의

   내부 CHECK_KDUMP 시간 제한을 30초로 수용하도록 POLL 인스턴스 HA 서비스 매개변수를 기본 설정인 45초 이상으로 설정해야 합니다. POLL 매개변수 값이 45초 미만이면 인스턴스를 비울 때 오류가 발생할 수 있습니다.

7. 배포된 인스턴스 HA 서비스 포드의 IP 주소를 검색합니다. 예를 들어 internalapi 가 지정된 네트워크인 경우 다음 명령을 사용합니다.

   $ oc get instanceha -o json |jq -r '.items[0].status.networkAttachments["openstack/internalapi"][0]'

8. 배포된 인스턴스 HA 서비스 Pod의 IP 주소를 지정하도록 컴퓨팅 노드에서 fence_kdump STONITH 에이전트를 구성합니다. 예를 들어 172.16.0.178이 Instance HA 서비스 Pod의 IP 주소인 경우:

   # echo "fence_kdump_nodes 172.16.0.178 >> /etc/kdump.conf

9. 컴퓨팅 노드에서 fence_kdump STONITH 에이전트를 구성하여 UDP 포트, 프레임, 알림 메시지 수 및 해당 간격을 지정합니다. 예를 들어 다음 구성은 기본 7410 UDP 포트를 사용하고, 5초 간격으로 필요한 만큼 메시지를 전송하며 kdump 프로세스가 완료될 때까지 계속 메시지를 보냅니다.

   # echo 'fence_kdump_args -p 7410 -f auto -c 0 -i 5' >> /etc/kdump.conf

10. kdump 서비스를 다시 시작하여 컴퓨팅 노드에서 initrd 이미지를 다시 생성합니다.

    # systemctl restart kdump

검증

1. 컴퓨팅 노드 중 하나를 충돌하여 Instance HA 서비스 Pod 및 fence_kdump 에이전트가 올바르게 구성되었는지 확인합니다.

   # echo c > /proc/sysrq-trigger

2. 충돌한 컴퓨팅 노드에서 관련 콘솔을 열고 kdump 프로세스의 진행 상황을 확인할 수 있는지 확인합니다.
3. 인스턴스 HA 서비스 포드 로그 파일을 열고 이 로그 파일이 이 메시지를 수신하는지 확인합니다. 즉, 충돌한 컴퓨팅 노드를 지정하는 다음 compute(s)가 kdump입니다. 로그 파일을 보는 방법에 대한 자세한 내용은 인스턴스 HA 서비스 문제 해결을 참조하십시오.

프로세스

1. YAML 인스턴스 HA 서비스 매니페스트 파일을 생성합니다(예: Instance-HA-service-0.yaml ):

   • 인스턴스 HA 서비스 Pod의 사양 .spec 및 name .metadata.name 을 정의합니다. 자세한 내용은 Instance HA 서비스 Pod 사양 구성을 참조하십시오.
   • 비워 둘 수 있는 모든 컴퓨팅 노드의 펜싱 에이전트를 구성한 YAML 파일의 이름을 지정하도록 .spec.fencingSecret 을 구성합니다. 이 예에서는 파일을 fencing-0 이라고 합니다. 자세한 내용은 컴퓨팅 노드의 펜싱 구성을 참조하십시오.

2. 인스턴스 HA 서비스 매니페스트 및 fencingSecret 파일을 적용합니다.

   $ oc apply -f fencing-0.yaml
   $ oc apply -f Instance-HA-service-0.yaml

3. 계속하기 전에 인스턴스 HA 서비스 포드 메시지 필드에 설치 완료 가 표시되는지 확인합니다.

   $ oc get instanceha -w
   NAME        STATUS   MESSAGE
   instanceha-0   True     Setup complete

   참고

   매니페스트 파일에 지정한 .metadata.name 에 고유한 문자열이 추가됩니다.

4. 배포된 인스턴스 HA 서비스 Pod의 정규화된 이름과 상태를 확인합니다.

   $ oc get pods |grep instanceha
   instanceha-0-54f865b6dd-w6h4t                                   1/1     Running     0       10h

   이 예에서 정규화된 이름은 instanceha-0-54f865b6dd-w6h4t 입니다.

   주의

   인스턴스 HA 서비스 포드가 다시 시작될 때마다 새로운 고유한 정규화된 이름이 생성됩니다. 이전 이름과 연결된 모든 로그 항목이 제거됩니다. 자세한 내용은 Instance HA 서비스 문제 해결을 참조하십시오.

프로세스

1. 인스턴스 HA 서비스를 삭제합니다.

   $ oc delete instanceha/<instanceha_service_name>

   • & lt;instanceha_service_name >을 배포된 인스턴스 HA 서비스의 이름으로 바꿉니다(예: instanceha-0 ).

2. Instance HA 서비스 매개변수가 포함된 ConfigMap 을 삭제합니다.

   $ oc delete cm/<config_map_name> instanceha-config

   • & lt;config_map_name& gt;을 ConfigMap 이름으로 바꿉니다. 예를 들어 기본 ConfigMap 을 사용하는 경우 ConfigMap 은 instanceha-config 입니다.

3. 비워 둘 수 있는 컴퓨팅 노드의 펜싱 구성이 포함된 펜싱 보안을 삭제합니다.

   $ oc delete secret/<fencing_secret_name>

   • < fencing_secret_name >을 인스턴스 HA 서비스 Pod의 사양을 정의할 때 지정한 펜싱 시크릿의 이름으로 바꿉니다(예: fencing-0 ).

프로세스

1. 컴퓨팅 노드 목록을 볼 때 --long 인수를 사용하여 Forced Down 플래그의 상태를 표시합니다.

   $ openstack compute service list --long

   이 예에서 compute-fn93pyp7-2.ctlplane.example.com 에는 Status 가 활성화되어 있지만 Forced Down 플래그는 여전히 true 로 설정되어 있으며 이 컴퓨팅 노드를 비우는 동안 문제가 있음을 나타냅니다.

   $ openstack compute service list --long
   +--------------------------------------+----------------+-----------------------------------------+----------+---------+-------+----------------------------+-----------------+-------------+
   | ID                                | Binary        | Host                                  | Zone  | Status  | State | Updated At              | Disabled Reason | Forced Down |
   +--------------------------------------+----------------+-----------------------------------------+----------+---------+-------+----------------------------+-----------------+-------------+
   ...
   | c9590263-7fbd-4782-85d8-7cf7526ed292 | nova-compute   | compute-fn93pyp7-0.ctlplane.example.com | nova    | enabled | up  | 2024-10-08T04:59:23.000000 | None         | False     |
   | 3319da3d-31e8-4877-a9d5-9f407e1356fa | nova-compute   | compute-fn93pyp7-1.ctlplane.example.com | nova    | enabled | up  | 2024-10-08T04:59:18.000000 | None         | False     |
   | 1b89c4b9-bf16-45c0-9517-8f652ea5a129 | nova-compute   | compute-fn93pyp7-2.ctlplane.example.com | nova    | enabled | down  | 2024-10-08T04:59:18.000000 | None           | True      |

2. 컴퓨팅 노드를 강제로 실행합니다.

   $ openstack compute service set --up <Compute_node> nova-compute

   • < Compute_node >를 컴퓨팅 노드의 나열된 이름으로 바꿉니다(예: compute-fn93pyp7-2.ctlplane.example.com ).

     & lt; Compute_node& gt;의 forced Down 플래그는 false 로 설정됩니다.