높은 가용성

XenServer® 고가용성(HA) 기능은 최소한의 다운타임과 데이터 손상 없이 VM이 계속 실행되도록 보장합니다. 호스트 하드웨어 장애 및 네트워크 중단과 같은 문제가 발생하면 XenServer 풀은 영향을 받는 VM을 풀의 안정적인 호스트에서 다시 시작하여 응답합니다. 이 기능을 통해 하드웨어 문제를 해결할 수 있을 때까지 VM을 계속 실행할 수 있습니다.

XenServer는 다음 방법을 통해 VM 고가용성을 보장합니다.

• 네트워크 하트비트를 사용하여 풀의 호스트 간 연결을 확인합니다.
• 스토리지 하트비트를 사용하여 호스트와 공유 스토리지 간 연결을 확인합니다.
• 호스트가 실패했는지 감지합니다.
• 하나 이상의 호스트에 연결할 수 없게 되었는지 감지합니다.
• 풀에서 가장 큰 호스트 파티션과 통신할 수 없는 호스트를 격리합니다. 격리된 호스트는 즉시 다시 시작되어 해당 호스트에서 실행 중인 모든 VM이 중지됩니다. 다시 시작되면 리소스 풀에 다시 참여하려고 시도합니다. 이 예방 조치는 VM이 두 호스트에서 동시에 실행되어 데이터 손상 위험을 초래하는 것을 방지합니다.
• 실패했거나, 격리되었거나, 연결할 수 없는 호스트를 풀의 활성 호스트 집합에서 더 이상 포함되지 않는 것으로 표시합니다.
• 해당 호스트에서 실행 중이던 모든 VM을 중지된 것으로 표시합니다.
• 실패했거나, 격리되었거나, 연결할 수 없는 호스트가 풀 코디네이터인 경우, 코디네이터 역할을 풀의 다른 호스트에 재할당합니다.
• 구성한 페일오버 계획에 따라 중지된 모든 VM을 다시 시작합니다.
• 구성된 페일오버 계획이 실행될 수 있는지 확인하기 위해 풀 구성의 변경 사항을 모니터링합니다.

HA 기능은 풀의 다른 호스트에서 VM을 자동으로 다시 시작하므로, XenServer는 VM의 원래(실패했거나 연결할 수 없는) 호스트가 더 이상 VM을 실행하고 있지 않은지 확인해야 합니다. 동일한 VM의 두 인스턴스가 동시에 실행되면 VM 데이터 손상이 발생할 수 있습니다. 이러한 가능성을 방지하기 위해 HA가 활성화된 풀의 XenServer 호스트는 동일한 VM의 두 인스턴스가 실행될 수 있는 상황에 처하면 자체 격리를 적극적으로 수행합니다.

HA 기능은 기본 하드웨어 또는 네트워크 문제를 해결할 수 있을 때까지 주요 VM을 계속 실행합니다. HA 이벤트가 발생했음을 인지하면 기본 장애를 조사하고 해결하여 풀을 최대 용량으로 복원하십시오.

이 문서에서는 고가용성 개념, 요구 사항 및 예상되는 동작에 대해 설명합니다. 고가용성 구성 및 관리에 대한 자세한 내용은 고가용성 구성을 참조하십시오.

요구 사항

고가용성 기능을 사용하려면 환경에 다음 항목이 필요합니다.

• XenServer 풀: HA 기능은 단일 리소스 풀 내에서 작동합니다.

  • 풀은 동종(homogenous)인 것이 좋습니다. 풀의 각 호스트는 VM에 동일한 CPU 기능 세트를 노출하며, 이를 통해 VM을 풀 내 어디에서든 더 쉽게 다시 시작할 수 있습니다.
  • 하트비트 메커니즘이 효과적으로 작동하려면 풀에 최소 3개의 호스트가 있는 것이 좋습니다.
  • HA를 활성화하기 전에 풀의 모든 호스트가 온라인 상태인지 확인하십시오.

• 풀의 모든 호스트를 위한 공유 스토리지: 장애 발생 후 풀의 모든 VM이 풀의 모든 호스트에서 다시 시작될 수 있도록 하려면, 풀의 모든 호스트는 VM 디스크가 저장된 SR에 액세스할 수 있어야 합니다.

• 하트비트 SR: 이 SR은 VM 디스크가 저장된 SR과 동일할 수 있습니다. 풀은 장애 발생 시 장애 감지 및 복구를 조정할 수 있도록 정보를 저장합니다.

  • 하트비트 SR은 iSCSI, NFS 또는 Fibre Channel LUN에 있어야 합니다. CHAP를 사용하여 인증된 SMB 또는 iSCSI를 통해 연결된 스토리지는 하트비트 SR로 사용할 수 없습니다. 이 SR은 낮은 지연 시간으로 높은 신뢰성을 갖는 것이 좋습니다.

  • XenServer 8.4는 하트비트 SR에 4GB를 필요로 합니다.

    하트비트 SR에 저장된 정보는 다음과 같습니다.

    • 4MB 하트비트 볼륨: 스토리지 하트비트를 제공하여 풀의 호스트가 스토리지에 액세스할 수 있는지 확인합니다.
    • 메타데이터 볼륨: 풀 코디네이터의 페일오버가 발생할 경우 사용될 풀 코디네이터 메타데이터를 저장합니다. 이 볼륨은 나머지 필요한 공간을 차지합니다.

• 하트비트 SR을 위한 안정적이고 이중화된 스토리지 통신: HA 기능이 공유 스토리지에 액세스할 수 있는 호스트에 대한 가장 정확한 보기를 가지려면, 스토리지 트래픽이 안정적인지 확인하도록 환경을 구성하십시오. iSCSI 및 Fibre Channel SR의 경우 멀티패싱을 구성하십시오. NFS SR의 경우 복원력 있는 본딩된 네트워크를 스토리지 네트워크로 사용하십시오.

• 모든 호스트에 대한 고정 IP 주소: HA는 호스트 IP 주소 변경을 호스트 연결 손실로 간주하고 호스트의 네트워크가 실패했다고 가정합니다. 그 결과, 호스트는 펜싱될 수 있습니다. 풀에서 고정 IP만 사용하여 이를 방지하십시오.

• 관리 네트워크의 전용 본딩 인터페이스: HA 기능이 풀 상태에 대한 가장 정확한 보기를 가지려면 호스트 간에 안정적이고 이중화된 네트워크 통신이 필요합니다.

• 관리 네트워크는 포트 694를 통한 네트워크 하트비트 UDP 트래픽을 허용합니다: 네트워크 하트비트는 풀의 호스트가 활성 상태이며 서로 통신할 수 있는지 확인합니다.

고가용성 풀에서 실행되는 VM을 보호하려면 다음 구성으로 VM을 설정하십시오.

• VM 디스크를 풀의 모든 호스트에서 사용할 수 있는 공유 스토리지에 저장합니다.
• 가상 네트워크 인터페이스를 풀 전체 네트워크에 설정합니다.
• VM이 라이브 마이그레이션을 사용할 수 있는지 확인하십시오. 자세한 내용은 마이그레이션 호환성 요구 사항을 참조하십시오.
• VM을 로컬 DVD 드라이브에 연결하지 마십시오.

이 모든 기준을 충족하는 VM을 애자일(agile)이라고 합니다.

NVIDIA vGPU 또는 GPU 패스스루를 사용하는 VM은 HA로 보호할 수 없습니다. 그러나 HA 메커니즘은 최선을 다해 이 VM을 다시 시작하려고 시도할 수 있습니다.

GFS2 클러스터형 풀 요구 사항

GFS2 클러스터형 풀의 고가용성 동작은 다른 기본 메커니즘을 사용하므로 몇 가지 다른 요구 사항과 동작을 가집니다. 자세한 내용은 GFS2 클러스터형 풀을 참조하십시오.

HA 페일오버 계획

HA 메커니즘은 다음 기준에 따라 풀 전체 페일오버 계획을 계산합니다.

• VM 복구 요구 사항: 각 VM은 다시 시작 우선순위와 시작 순서를 정의할 수 있습니다.
• 사용 가능한 풀 리소스: 고려되는 주요 리소스는 호스트 메모리입니다.
• 허용할 호스트 장애 수: 풀에서 HA를 활성화하면 XenServer는 보호된 VM을 다시 시작할 수 없게 되기 전에 풀에서 장애가 발생할 수 있는 최대 호스트 수를 계산할 수 있습니다. 허용할 호스트 장애 수를 이 값보다 작거나 같게 설정할 수 있습니다.

이러한 기준을 충족하는 페일오버 계획을 계산할 수 없는 경우, 풀은 과도하게 커밋된 것으로 간주됩니다. 보호된 VM을 풀에서 다시 시작할 수 없는 경우, XenServer는 시스템 경고를 발생시킵니다. 이 경고는 XenCenter® 알림 패널에도 표시됩니다.

풀의 모든 VM에 대해 복구 동작을 정의할 수 있습니다.

다시 시작 우선순위

VM에 다음 다시 시작 우선순위 중 하나를 할당할 수 있습니다.

• 보호됨: VM 또는 해당 호스트가 예기치 않게 오프라인 상태가 되면 HA는 다른 호스트에서 VM을 다시 시작합니다. 풀이 과도하게 커밋되지 않고 VM이 민첩한 경우 이 다시 시작은 보장됩니다. VM 다시 시작에 실패하면 HA는 풀에 추가 용량이 있을 때 VM을 시작하려고 시도합니다. 이 값은 xe CLI에서는 restart이고 XenCenter에서는 다시 시작입니다.
• 최대 노력: VM을 실행하는 호스트가 예기치 않게 오프라인 상태가 되면 HA는 다른 호스트에서 VM을 다시 시작하려고 시도합니다. 이 시도는 모든 보호된 VM이 성공적으로 다시 시작된 후에만 이루어집니다. 고가용성은 최대 노력 VM을 다시 시작하기 위해 한 번만 시도합니다. 이 시도가 실패하면 고가용성은 VM을 다시 시작하기 위한 추가 시도를 하지 않습니다. 이 값은 xe CLI에서는 best-effort이고 XenCenter에서는 가능하면 다시 시작입니다.
• 보호되지 않음: VM 또는 해당 호스트가 예기치 않게 오프라인 상태가 되면 HA는 VM을 다시 시작하려고 시도하지 않습니다. 이것이 기본 설정입니다. 이 값은 xe CLI에서는 빈 문자열이고 XenCenter에서는 다시 시작 안 함입니다.

고가용성은 더 높은 다시 시작 우선순위를 가진 VM을 다시 시작하기 위해 리소스를 확보하기 위해 실행 중인 VM을 중지하거나 마이그레이션하지 않습니다.

시작 순서

시작 순서는 장애 발생 시 XenServer 고가용성이 보호된 VM을 다시 시작하려고 시도하는 순서입니다. 이 값은 보호된 VM에만 사용됩니다. 기본값은 0이며, 이는 가장 높은 우선순위입니다. 시작 순서 값이 0인 보호된 VM이 먼저 다시 시작됩니다. 시작 순서 값이 높을수록 VM은 시퀀스에서 나중에 다시 시작됩니다.

풀 동작

XenServer 풀에서 HA를 활성화하면 풀은 다음 동작을 보입니다.

설정 중 동작

풀에서 HA를 활성화하면 풀 코디네이터가 다음 설정을 수행합니다:

• 초기 페일오버 계획을 계산합니다.
• 하트비트 SR에 업데이트를 기록하도록 데이터베이스를 구성합니다. 이 설정은 호스트가 실패할 때 VM 구성 변경 사항이 손실되지 않도록 보장합니다.
• 하트비트 SR에 풀 코디네이터 메타데이터를 설정합니다.

모든 풀 멤버는 다음을 수행합니다:

• 서로 네트워크 하트비트를 보냅니다. 그 결과, 풀의 호스트들이 서로 통신할 수 있는지 확인하면서 관리 네트워크 트래픽이 약간 증가합니다. 이 네트워크 트래픽은 HA가 활성화되어 있는 동안 계속됩니다.

정상 작동 중 동작

정상 작동 중에 HA 풀의 풀 코디네이터는 (일반적인 기능 외에) 다음 작업을 수행합니다:

• 페일오버 계획을 동적으로 유지 관리합니다. 이 계획은 특정 시점에 풀의 호스트 세트가 실패할 경우 수행할 작업을 자세히 설명합니다. 이 계획은 허용 가능한 최대 호스트 실패 수를 고려하고 모든 보호된 VM을 다시 시작할 수 있도록 보장합니다. 이 계획은 VM 수명 주기 작업 및 이동에 따라 동적으로 다시 계산됩니다. 변경 사항(예: 풀에 새 VM 추가)으로 인해 최대 호스트 실패 후 모든 보호된 VM을 더 이상 다시 시작할 수 없는 경우, 계획을 계산할 수 없으며 풀은 오버커밋됩니다. 풀이 오버커밋되면 XenServer는 XenCenter, 이메일, SNMP 트랩 또는 NRPE 경고를 통해 경고를 발생시킵니다.

정상 작동 중에 HA 풀의 각 멤버는 (일반적인 기능 외에) 다음 작업을 수행합니다:

• 풀 코디네이터가 활성 상태인지 확인합니다. 호스트는 공유 스토리지에서 “마스터 잠금”을 획득하려고 시도하여 이를 수행합니다. 풀 코디네이터가 이미 존재하는 경우 이 시도는 실패합니다.
• 네트워크 하트비트를 보냅니다. 이 네트워크 하트비트는 관리 네트워크의 694번 포트를 통해 UDP를 사용하여 풀의 다른 모든 호스트로 전송됩니다.
• 풀에 있는 호스트의 라이브셋 기록을 유지 관리합니다. 각 개별 호스트에 따른 호스트의 라이브셋은 해당 호스트가 활성 상태라고 믿는 다른 호스트들의 집합입니다. 호스트가 HA 타임아웃(기본적으로 60초)으로 지정된 기간 내에 다른 호스트로부터 네트워크 하트비트를 받지 못한 경우, 풀의 다른 호스트와 통신하여 라이브셋을 업데이트해야 하는지 여부를 합의합니다.
• 스토리지 하트비트 볼륨의 상태 파일에 기록합니다. 이 작업은 호스트가 스토리지에 계속 액세스할 수 있는지 확인합니다. 또한 (네트워크 하트비트 통신 외에) 호스트들이 서로 상태를 통신할 수 있도록 합니다.
• 하트비트 SR의 데이터베이스를 업데이트합니다. 호스트는 호스팅하는 VM의 VM 구성 변경 사항을 기록합니다.

HA가 활성화된 경우 일부 풀 작업이 차단되거나 권장되지 않습니다. 이러한 작업을 수행하려면 고가용성을 일시적으로 비활성화하십시오.

• 풀에 호스트 추가.
• 풀에서 호스트 제거. 이 작업으로 인해 풀이 과도하게 커밋될 수 있는 경우 차단됩니다.
• 풀의 호스트 종료. 이 작업으로 인해 풀이 과도하게 커밋될 수 있는 경우 차단됩니다.
• 관리 네트워크 변경.
• 풀에 연결된 SR 변경.
• 클러스터링 활성화. 클러스터된 풀의 경우 일부 고가용성 동작 및 요구 사항이 다릅니다. 자세한 내용은 클러스터된 풀을 참조하십시오.

정상 작동 중에는 풀에서 다음 작업을 수행해도 HA 장애 조치 계획이 활성화되지 않습니다.

• XenCenter 또는 xe CLI에서 VM을 정상적으로 종료합니다. HA 메커니즘은 이 VM이 실패했다고 간주하지 않으며 다시 시작을 시도하지 않습니다. 이 작업에 대한 자세한 내용은 고가용성으로 보호되는 VM 종료를 참조하십시오.
• 게스트 OS 내에서 VM 충돌 또는 정상 종료(HA가 내부 종료 시 VM을 자동으로 재부팅하지 않도록 구성된 경우). 이 경우 HA 메커니즘은 VM이 실패했다고 간주하지 않으며 다시 시작을 시도하지 않습니다. 이 설정에 대한 자세한 내용은 내부적으로 종료된 VM의 다시 시작 동작 구성을 참조하십시오.
• XenCenter 또는 xe CLI에서 호스트를 정상적으로 종료합니다. HA 메커니즘은 이 호스트가 실패했다고 간주하지 않으며 해당 호스트에서 호스팅되던 VM을 다시 시작하려고 시도하지 않습니다. 그러나 이 작업으로 인해 풀이 과도하게 커밋되는 경우 XenServer에 의해 차단됩니다. 이 작업에 대한 자세한 내용은 고가용성이 활성화된 경우 호스트 종료를 참조하십시오.

하드웨어 장애 또는 인프라 불안정 시 동작

이 단계에서 풀의 모든 호스트는 자체 연결 상태를 감지하고 풀의 다른 호스트의 연결 상태에 동의할 책임이 있습니다.

XenServer HA는 다음 유형의 장애를 감지하고 처리합니다.

• 실패한 호스트: 이 상황에서 나머지 모든 호스트는 실패한 호스트가 상태 파일 업데이트를 중지하고 네트워크 하트비트를 더 이상 보내지 않는다는 것을 매우 빠르게 감지합니다. 적절한 지연 후 이 호스트는 라이브셋에서 제거됩니다.
• 네트워크 파티션: 이 상황에서 하나 이상의 호스트가 다른 하나 이상의 호스트와 통신할 수 없습니다. 호스트는 정의된 시간 초과 내에 하나 이상의 다른 호스트로부터 네트워크 하트비트를 수신하지 못했음을 감지하고 오류 처리기를 시작합니다. 이 오류 처리기 프로세스는 상태 파일과 작동 중인 네트워크 하트비트를 통해 통신하며, 이 정보를 사용하여 어떤 네트워크 파티션(서로 통신할 수 있는 호스트 그룹)이 존재하는지 결정합니다. 가장 큰 파티션에 있는 호스트가 라이브셋이며 살아남습니다. 크기가 같은 파티션이 있는 경우, 가장 낮은 호스트 UUID를 가진 호스트가 포함된 파티션의 호스트가 살아남습니다.
• 스토리지 연결 실패: 이 상황에서 호스트는 스토리지에 연결할 수 없음을 감지하거나 다른 호스트는 해당 업데이트가 스토리지에 없음을 감지합니다. 호스트는 네트워크 하트비트 통신을 통해 다른 호스트가 스토리지 액세스를 잃었는지 확인합니다.
  • 모든 호스트가 스토리지를 잃었지만 네트워크는 잃지 않은 경우, 이는 일시적인 스토리지 손실로 간주되며 호스트는 스토리지가 복구될 때까지 계속 작동합니다. 추가적인 오류가 발생하면 풀의 모든 호스트가 펜싱됩니다. 이 규칙은 스토리지가 단일 실패 지점이 되는 것을 방지합니다.
  • 일부 호스트만 스토리지 액세스를 잃었지만 모든 호스트가 여전히 네트워크 액세스를 가지고 있는 경우, 이 호스트들은 라이브셋에서 제거됩니다.

호스트가 풀의 대다수에게 실패했거나 연결할 수 없는 것으로 보일 것이라는 것을 알면, 해당 호스트는 자체 펜싱을 수행합니다. 펜싱은 VM 데이터에 대한 보호 조치로 설계된 예상되는 동작입니다. 이는 VM이 동시에 두 곳에서 실행되지 않도록 보장합니다. 호스트는 자체 펜싱이 필요하다고 판단하기 위해 다음 기준을 사용합니다.

• 호스트의 툴스택이 실행 중이 아니며 다시 시작할 수 없는 경우, 호스트는 자체 펜싱을 수행합니다.
• 호스트가 네트워크 및 스토리지 하트비트를 모두 잃은 경우, 호스트는 자신을 연결할 수 없는 상태로 간주하고 자체 펜싱을 수행합니다.
• 호스트가 스토리지 하트비트를 잃었지만 여전히 네트워크 하트비트를 수신하고 있는 경우:
  • 호스트가 다른 모든 풀 멤버와 여전히 통신할 수 있고 해당 멤버들도 스토리지 하트비트를 잃은 경우, 호스트는 계속 작동합니다. 이 경우는 스토리지가 단일 실패 지점 역할을 하여 전체 풀을 펜싱하는 것을 방지합니다.
  • 호스트가 풀의 하나 이상의 다른 호스트와 통신할 수 없는 경우, 자체 펜싱을 수행합니다.
• 호스트가 네트워크 하트비트를 잃었지만 여전히 스토리지 하트비트를 가지고 있는 경우, 가장 큰 네트워크 파티션에 속하는지 여부를 결정합니다. 그렇지 않은 경우, 호스트는 자체 펜싱을 수행합니다.
• 네트워크 통신 실패로 인해 풀이 동일한 크기의 파티션으로 분할될 가능성이 있습니다. 하트비트 SR의 상태 파일 정보를 사용하여 호스트가 그러한 네트워크 파티션에 속해 있음을 아는 경우:
  • 파티션에 가장 낮은 UUID를 가진 호스트가 포함된 경우, 호스트는 계속 작동합니다.
  • 파티션에 가장 낮은 UUID를 가진 호스트가 포함되지 않은 경우, 호스트는 자체 펜싱을 수행합니다.

펜싱 작업이 수행되면 호스트는 즉시 그리고 갑작스럽게 다시 시작되어, 해당 호스트에서 실행 중인 모든 VM이 중지됩니다. 펜싱된 호스트는 재부팅 시퀀스에 들어가고, 다시 시작되면 리소스 풀에 다시 참여하려고 시도합니다.

복구 중 동작

풀 코디네이터 호스트가 실패하거나, 격리되거나, 연결할 수 없게 되면 다른 호스트들이 마스터 잠금을 얻으려고 시도합니다. 성공한 호스트가 새로운 코디네이터가 됩니다.

자체 격리된 호스트는 다시 시작하여 풀에 다시 참여하려고 시도합니다.

호스트가 죽은 것으로 표시되고 해당 VM이 중지되면, 풀 코디네이터는 다음 복구 작업에 대한 책임이 있습니다.

• 페일오버 계획에 따라 모든 보호된 VM을 다시 시작합니다.
• 모든 보호된 VM을 시작할 충분한 리소스가 없는 경우, 풀 코디네이터는 리소스가 사용 가능해질 때까지 (예를 들어, 이전에 격리된 호스트가 풀에 다시 참여하는 경우) 기다린 다음 보호된 VM을 시작하려고 시도합니다.
• 모든 보호된 VM이 성공적으로 시작된 후, 풀 코디네이터는 각 최선 노력 VM을 다시 시작하기 위해 한 번 시도합니다.