Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

자동 테이크오버 및 반환의 작동 방식

기여자
PDF

자동 테이크오버 및 반환 작업이 함께 작동하여 클라이언트 중단을 줄이고 방지할 수 있습니다.

기본적으로 HA 쌍의 노드 중 하나가 패닉, 재부팅 또는 중지되면 파트너 노드가 자동으로 작업을 인계받은 다음 해당 노드가 재부팅될 때 스토리지를 반환합니다. 그런 다음 HA 쌍이 정상 운영 상태를 재개합니다.

노드 중 하나가 응답하지 않는 경우에도 자동 테이크오버가 발생할 수 있습니다.

자동 반환은 기본적으로 발생합니다. 반환이 클라이언트에 미치는 영향을 제어하려는 경우 자동 반환을 사용하지 않도록 설정하고 명령을 사용할 수 storage failover modify -auto-giveback false -node <node> 있습니다. 자동 기브백을 수행하기 전에(트리거된 항목에 관계없이) 파트너 노드는 명령의 매개 변수에 storage failover modify 의해 제어되는 고정 시간 동안 대기합니다. -delay- seconds 기본 지연은 600초입니다.

이 프로세스는 다음에 필요한 시간을 포함하여 장기간의 단일 중단을 방지합니다.

  • 테이크오버 작동

  • 반환이 준비가 된 시점까지 부트에 대해 인과된 노드

  • 반환 작업

루트가 아닌 Aggregate에 대해 자동 반환이 실패하면 시스템에서 자동으로 반환 완료를 두 번 시도합니다.

참고 테이크오버 프로세스 중에 파트너 노드가 기브백에 대비하기 전에 자동 반환 프로세스가 시작됩니다. 자동 반환 프로세스의 시간 제한이 만료되고 파트너 노드가 아직 준비되지 않은 경우 타이머가 다시 시작됩니다. 따라서 준비 중인 파트너 노드와 수행 중인 실제 반환 시간 사이의 시간이 자동 반환 시간보다 짧아질 수 있습니다.

테이크오버 중 발생하는 동작

파트너가 노드를 인수하면 파트너 애그리게이트와 볼륨의 데이터가 계속해서 제공 및 업데이트됩니다.

테이크오버 프로세스 중에 다음 단계가 발생합니다.

  1. 협상된 테이크오버가 사용자 시작된 경우 통합된 데이터가 파트너 노드에서 테이크오버 수행 중인 노드로 이동됩니다. 루트 애그리게이트(루트 애그리게이트 제외)를 제외한 각 애그리게이트의 현재 소유자가 테이크오버 노드로 변경되면 간단한 운영 중단이 발생합니다. 이러한 운영 중단은 애그리게이트 재배치를 수행하지 않고 테이크오버 중에 발생하는 중단보다 더 짧은 시간에 수행됩니다.

    참고 패닉이 발생하는 경우 패닉 중에 협상된 테이크오버가 발생할 수 없습니다. 테이크오버 발생하면 패닉이 발생하지 않는 고장이 발생할 수 있습니다. 노드와 파트너 간에 통신이 끊기면 장애가 발생하고 하트비트 손실이라고도 합니다. 장애로 인해 테이크오버가 발생하면 파트너 노드에서 하트비트 손실을 감지할 시간이 필요하므로 중단 시간이 더 길어질 수 있습니다.

    • 명령을 사용하여 진행 상황을 모니터링할 수 storage failover show-takeover 있습니다.

    • 이 테이크오버 인스턴스 중에 매개 변수를 명령과 함께 storage failover takeover 사용하면 애그리게이트 재배치를 방지할 수 -bypass-optimization 있습니다.

      계획된 테이크오버 작업 중에 애그리게이트를 순차적으로 재배치하여 클라이언트 운영 중단을 줄입니다. 애그리게이트 재배치를 무시할 경우 계획된 테이크오버 이벤트 중에 더 긴 클라이언트 중단이 발생합니다.

  2. 사용자 시작 테이크오버가 협상된 테이크오버인 경우 타겟 노드가 정상적으로 종료되고 타겟 노드의 루트 애그리게이트와 첫 번째 단계에서 재배치되지 않은 애그리게이트가 테이크오버됩니다.

  3. 데이터 LIF(논리 인터페이스): LIF 페일오버 규칙에 따라 타겟 노드에서 테이크오버 노드 또는 클러스터의 다른 노드로 마이그레이션합니다. 매개 변수를 명령과 함께 storage failover takeover 사용하면 LIF 마이그레이션을 방지할 수 -skip-lif-migration 있습니다. 사용자가 시작한 테이크오버의 경우 스토리지 테이크오버가 시작되기 전에 데이터 LIF가 마이그레이션됩니다. 패닉 또는 장애가 발생할 경우 구성에 따라 데이터 LIF를 스토리지와 함께 마이그레이션하거나 테이크오버가 완료된 후 마이그레이션할 수 있습니다.

  4. 테이크오버가 발생하면 기존 SMB 세션의 연결이 끊어집니다.

    참고 SMB 프로토콜의 특성 때문에 모든 SMB 세션이 중단됩니다(Continuous Availability 속성 세트가 있는 공유에 연결된 SMB 3.0 세션은 제외). SMB 1.0 및 SMB 2.x 세션에서는 Takeover 이벤트 후에 열려 있는 파일 핸들을 다시 연결할 수 없습니다. 따라서 테이크오버가 중단되고 데이터 손실이 어느 정도 발생할 수 있습니다.

  5. Continuous Availability 속성을 사용하도록 설정된 공유로 설정된 SMB 3.0 세션은 테이크오버 이벤트 후에 연결이 끊긴 공유에 다시 연결될 수 있습니다. 사이트에서 Microsoft Hyper-V에 대한 SMB 3.0 연결을 사용하고 연결된 공유에 대해 Continuous Availability 속성이 설정된 경우 테이크오버는 해당 세션에 대해 무중단 운영을 제공합니다.

테이크오버 수행 중인 노드가 패닉 상태인 경우 어떻게 됩니까

테이크오버 시작 후 60초 내에 Takeover를 수행하는 노드가 발생하면 다음 이벤트가 발생합니다.

  • 패닉이 발생하는 노드가 재부팅됩니다.

  • 재부팅 후 노드는 자체 복구 작업을 수행하며 더 이상 테이크오버 모드가 아닙니다.

  • 페일오버가 비활성화되었습니다.

  • 노드에서 여전히 일부 파트너 애그리게이트를 소유하고 있으면 스토리지 페일오버를 활성화한 후 'Storage Failover 반환' 명령을 사용하여 해당 애그리게이트를 파트너에게 반환합니다.

반환 중 발생하는 현상

문제가 해결되거나, 파트너 노드가 부팅될 때 또는 반환이 시작될 때 로컬 노드가 파트너 노드에 소유권을 반환합니다.

정상적인 반환 작업에서 다음 프로세스가 발생합니다. 이 토론에서는 노드 A가 노드 B를 인수했습니다 노드 B의 모든 문제가 해결되었으며 데이터 제공을 재개할 준비가 되었습니다.

  1. 노드 B의 모든 문제가 해결되고 '반환 대기 중' 메시지가 표시됩니다

  2. 반환 작업은 'storage failover 반환' 명령 또는 시스템이 구성된 경우 자동 반환에 의해 시작됩니다. 그러면 노드 B의 애그리게이트 및 볼륨 소유권이 노드 A에서 노드 B로 반환되는 프로세스가 시작됩니다

  3. 노드 A는 루트 애그리게이트의 제어를 먼저 반환합니다.

  4. 노드 B는 정상 작동 상태로 부팅하는 프로세스를 완료합니다.

  5. 노드 B가 부팅 프로세스에서 루트가 아닌 애그리게이트를 수용할 수 있는 지점에 도달하면 노드 A는 반환이 완료될 때까지 한 번에 하나씩 다른 애그리게이트의 소유권을 반환합니다. 'storage failover show -반환' 명령을 사용하여 반환 진행률을 모니터링할 수 있습니다.

    참고 'storage failover show-반환' 명령은 스토리지 페일오버 반환 작업 중에 발생하는 모든 작업에 대한 정보를 표시하지 않습니다(또는 표시하지 않습니다). 'storage failover show' 명령을 사용하면 노드가 완전히 작동하고 테이크오버가 가능하며 반환이 완료된 경우와 같이 노드의 현재 페일오버 상태에 대한 추가 세부 정보를 표시할 수 있습니다.

    해당 애그리게이트에 대해 기브백이 완료된 후 각 애그리게이트의 I/O가 재개되어 전체 운영 중단 기간이 단축됩니다.

HA 정책과 그 영향이 Takeover 및 Giveback에 미치는 영향

ONTAP은 CFO(컨트롤러 페일오버) 및 SFO(스토리지 페일오버)의 HA 정책을 자동으로 Aggregate에 할당합니다. 이 정책은 애그리게이트 및 해당 볼륨에 대해 스토리지 페일오버 작업이 수행되는 방법을 결정합니다.

두 가지 옵션, CFO 및 SFO는 스토리지 페일오버 및 반환 작업 중에 ONTAP이 사용하는 애그리게이트 제어 시퀀스를 결정합니다.

CFO 및 SFO는 종종 비공식적으로 스토리지 페일오버(테이크오버 및 반환) 운영을 지칭하기 위해 사용되기도 하지만, 실제로는 Aggregate에 할당된 HA 정책을 나타냅니다. 예를 들어, SFO 애그리게이트 또는 CFO 애그리게이트는 단순히 애그리게이트의 HA 정책 할당을 참조하기만 하면 됩니다.

HA 정책은 다음과 같이 Takeover 및 Giveback 작업에 영향을 미칩니다.

  • ONTAP 시스템에서 생성된 애그리게이트(루트 볼륨이 포함된 루트 애그리게이트 제외)에는 SFO의 HA 정책이 있습니다. 수동으로 시작된 테이크오버는 테이크오버 전에 SFO(비루트) 애그리게이트를 순차적으로 파트너에게 재배치함으로써 성능에 최적화되어 있습니다. 반환 프로세스 중에 애그리게이트는 페일오버된 시스템 부팅 후 순차적으로 다시 전달되고 관리 애플리케이션이 온라인 상태가 되어 노드가 애그리게이트를 받을 수 있게 됩니다.

  • 애그리게이트 재배치 작업으로 인해 애그리게이트 디스크 소유권을 재할당하고 제어를 노드에서 파트너로 전환할 수 있기 때문에 SFO의 HA 정책이 적용된 애그리게이트만 애그리게이트 재배치할 수 있습니다.

  • 루트 애그리게이트에는 항상 CFO의 HA 정책이 있고 반환 작업을 시작할 때 이 정책이 제공됩니다. 이는 가져온 시스템이 부팅되도록 하기 위해 필요합니다. 다른 모든 애그리게이트는 페일오버된 시스템이 부팅 프로세스를 완료하고 관리 애플리케이션이 온라인 상태가 된 이후에 순차적으로 다시 제공되므로 노드에서 애그리게이트를 받을 수 있습니다.

참고 애그리게이트의 HA 정책을 SFO에서 CFO로 변경하는 것은 유지 관리 모드 작업입니다. 고객 지원 담당자의 지시가 없는 한 이 설정을 수정하지 마십시오.

백그라운드 업데이트가 Takeover 및 Giveback에 미치는 영향

디스크 펌웨어의 백그라운드 업데이트가 HA 쌍의 테이크오버, 반환 및 애그리게이트 재배치 작업에 영향을 미치는 것은 해당 작업의 시작 방식에 따라 다릅니다.

다음 목록에서는 백그라운드 디스크 펌웨어 업데이트가 테이크오버, 반환 및 애그리게이트 재배치에 미치는 영향을 설명합니다.

  • 두 노드 중 하나의 디스크에서 백그라운드 디스크 펌웨어 업데이트가 발생하는 경우 수동으로 시작된 테이크오버 작업은 해당 디스크에서 디스크 펌웨어 업데이트가 완료될 때까지 지연됩니다. 백그라운드 디스크 펌웨어 업데이트가 120초 이상 걸리는 경우 Takeover 작업이 중단되고 디스크 펌웨어 업데이트가 완료된 후 수동으로 다시 시작해야 합니다. 명령의 매개 변수를 storage failover takeover 로 설정하여 true 테이크오버가 시작되면 -bypass-optimization 타겟 노드에서 발생하는 백그라운드 디스크 펌웨어 업데이트가 테이크오버에 영향을 미치지 않습니다.

  • 소스(또는 테이크오버) 노드의 디스크에서 백그라운드 디스크 펌웨어 업데이트가 진행되고 있고 명령의 매개 변수를 storage failover takeover 로 immediate 설정하여 테이크오버가 수동으로 시작된 경우 테이크오버 -options 작업이 즉시 시작됩니다.

  • 노드의 디스크에서 백그라운드 디스크 펌웨어 업데이트가 수행되고 IT 패닉이 발생하면 패닉이 발생한 노드의 테이크오버가 즉시 시작됩니다.

  • 백그라운드 디스크 펌웨어 업데이트가 두 노드 중 하나의 디스크에서 발생하는 경우, 디스크 펌웨어 업데이트가 해당 디스크에서 완료될 때까지 데이터 애그리게이트의 기브백이 지연됩니다.

  • 백그라운드 디스크 펌웨어 업데이트가 120초 이상 걸리는 경우 반환 작업이 중단되고 디스크 펌웨어 업데이트가 완료된 후 수동으로 다시 시작해야 합니다.

  • 백그라운드 디스크 펌웨어 업데이트가 두 노드 중 하나의 디스크에서 발생하는 경우, 디스크 펌웨어 업데이트가 해당 디스크에서 완료될 때까지 애그리게이트 재배치 작업이 지연됩니다. 백그라운드 디스크 펌웨어 업데이트가 120초 이상 걸리는 경우, 애그리게이트 재배치 작업이 중단되고 디스크 펌웨어 업데이트가 완료된 후 수동으로 다시 시작해야 합니다. 'true'로 설정된 'Storage aggregate relocation' 명령의 '-override-destination-checks'로 애그리게이트 재배치를 시작한 경우, 대상 노드에서 백그라운드 디스크 펌웨어 업데이트가 애그리게이트 재배치에 영향을 미치지 않습니다.