-
고가용성
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
고가용성
XenServer® 고가용성은 기본 하드웨어 오류 또는 서버 손실 발생 시 VM이 자동으로 다시 시작되도록 합니다. 고가용성은 중요한 VM이 리소스 풀에서 항상 실행되도록 하는 것입니다. 고가용성이 활성화된 경우 서버 중 하나에 오류가 발생하면 해당 VM은 동일한 풀의 다른 서버에서 다시 시작됩니다. 이 기능은 시스템 또는 구성 요소 오류 발생 시 최소한의 서비스 중단으로 필수 서비스를 복원할 수 있도록 합니다.
풀 코디네이터 서버에 오류가 발생하면 XenServer 고가용성은 새 서버를 선택하여 풀 코디네이터 역할을 인계받도록 합니다. 풀의 모든 서버는 풀 코디네이터 서버가 될 수 있습니다. XenServer는 모든 노드에 걸쳐 풀 데이터베이스를 지속적으로 복제합니다. 또한 추가 안전을 위해 하트비트 SR의 공유 스토리지에 데이터베이스를 백업합니다.
XenServer 고가용성에는 두 가지 주요 측면이 있습니다.
- 서버 오류 안정적으로 감지
- 신속한 복구를 가능하게 하는 장애 계획 계산
가용성을 위한 하트비트
서버 오류를 안정적으로 감지하는 것은 어렵습니다. 서버가 잠시 사라진 것과 치명적인 오류를 원격으로 구별해야 하기 때문입니다. 고가용성이 풀 코디네이터 서버가 고장났다고 잘못 판단하여 새 풀 코디네이터를 선출하면 원래 서버가 돌아올 경우 예측할 수 없는 결과가 발생할 수 있습니다. 마찬가지로 네트워크 문제로 인해 풀이 두 개의 동일한 절반으로 분할되는 경우, 한 절반만 공유 스토리지에 액세스하고 동시에 둘 다 액세스하지 않도록 해야 합니다. XenServer는 스토리지 하트비트와 네트워크 하트비트라는 두 가지 메커니즘을 사용하여 이러한 모든 문제를 해결합니다.
풀에서 고가용성을 활성화할 때 iSCSI, Fibre Channel 또는 NFS 스토리지 리포지토리를 하트비트 SR로 지정합니다. XenServer는 이 SR에 몇 개의 작은 가상 디스크를 자동으로 생성합니다. 첫 번째 디스크는 리소스 풀의 모든 서버에서 공유 쿼럼 디스크로 사용됩니다. 각 서버는 공유 디스크에서 고유한 블록을 할당하고 해당 블록에 정기적으로 기록하여 자신이 활성 상태임을 나타냅니다. 고가용성이 시작되면 모든 서버는 스토리지 채널과 네트워크 채널을 통해 데이터를 교환합니다. 네트워크 하트비트는 포트 694를 통해 UDP 전송을 사용합니다. 이 작업은 두 채널을 통해 어떤 서버를 볼 수 있는지 나타내고 어떤 I/O 경로가 작동하고 작동하지 않는지 보여줍니다. 이 정보는 고정 지점에 도달하고 풀의 모든 서버가 볼 수 있는 내용에 대해 동의할 때까지 교환됩니다. 이 동의가 이루어지면 고가용성이 활성화되고 풀이 보호됩니다. 이 고가용성 무장 프로세스는 더 큰 풀의 경우 안정화되는 데 몇 분이 걸릴 수 있지만, 고가용성을 처음 활성화할 때만 필요합니다.
고가용성이 활성화된 후 각 서버는 하트비트 가상 디스크에 스토리지 업데이트를 정기적으로 기록하고 관리 인터페이스를 통해 네트워크 패킷을 보냅니다. 복원력을 위해 네트워크 어댑터가 본딩되어 있고, 지원되는 경우 스토리지 인터페이스가 동적 멀티패싱을 사용하고 있는지 확인하십시오. 이 구성은 단일 어댑터 또는 배선 오류가 가용성 문제로 이어지지 않도록 보장합니다.
자세한 내용은 다음을 참조하십시오.
서버 펜싱
고가용성에서 최악의 시나리오는 서버가 오프라인 상태라고 생각되지만 여전히 공유 스토리지에 쓰고 있는 경우입니다. 이 시나리오는 영구 데이터 손상을 초래할 수 있습니다. XenServer는 이 상황을 방지하기 위해 서버 펜싱을 사용합니다. 서버는 자동으로 전원이 꺼지고 풀의 공유 리소스에 액세스하는 것이 격리됩니다. 펜싱은 실패한 서버가 공유 디스크에 쓰는 것을 방지합니다. 이 동작은 보호된 가상 머신이 풀의 다른 서버로 이동되는 자동 장애 조치 중에 저장된 데이터의 손상을 방지합니다.
다음 중 하나라도 해당하지 않는 한, 하트비트 실패 시 서버는 자체 펜싱(즉, 전원 끄기 및 다시 시작)됩니다.
- 모든 서버에 스토리지 하트비트가 존재하지만 네트워크가 분할된 경우(따라서 이제 두 그룹의 서버가 있는 경우). 이 경우, 가장 큰 네트워크 파티션의 구성원인 모든 서버는 계속 실행되고, 더 작은 네트워크 파티션의 서버는 자체 펜싱됩니다. 여기서 가정은 네트워크 중단으로 인해 VM이 격리되었으며, 작동하는 네트워킹이 있는 서버에서 다시 시작되어야 한다는 것입니다. 네트워크 파티션의 크기가 동일한 경우, 안정적인 선택 기능에 따라 그 중 하나만 자체 펜싱됩니다.
- 스토리지 하트비트가 사라지고 네트워크 하트비트가 남아 있는 경우, 서버는 네트워크를 통해 다른 모든 서버를 볼 수 있는지 확인합니다. 이 조건이 참인 경우, 서버는 스토리지 장치가 실패했다고 가정하고 계속 실행됩니다. 이 작업은 VM 안전을 위협하지 않지만, 네트워크 하트비트가 손실되면 두 하트비트 모두 사라졌음을 의미하므로 펜싱이 발생합니다.
장애 대비 용량 계획
하트비트 시스템은 서버 장애에 대한 신뢰할 수 있는 알림을 제공하며, 따라서 고가용성의 두 번째 단계인 장애 대비 용량 계획으로 넘어갑니다.
리소스 풀은 여러 서버(예: 32개)로 구성되며, 각 서버는 잠재적으로 다른 양의 메모리와 다른 수의 실행 중인 VM을 가집니다. XenServer 고가용성은 모든 서버 장애 발생 시 취해야 할 조치를 계산하는 장애 계획을 동적으로 계산합니다. 이 장애 계획은 단일 서버 장애로 인해 다른 서버에서 VM을 다시 시작하는 것이 불가능해지는 일이 없도록 보장합니다(예: 다른 서버의 메모리 부족으로 인해). 단일 서버 장애를 처리하는 것 외에도 XenServer 고가용성은 풀 내에서 여러 서버의 손실을 처리할 수 있습니다. 예를 들어, 고가용성은 네트워크 파티션 장애로 인해 전체 서버 그룹이 중단되는 경우를 처리할 수 있습니다.
취해지는 조치를 계산하는 것 외에도, 장애 계획은 풀에서 허용될 수 있는 서버 장애 수를 고려합니다. 풀에 대한 고가용성 계획을 계산하는 데에는 두 가지 중요한 고려 사항이 있습니다.
-
최대 장애 용량. 이 값은 풀의 모든 보호된 VM을 실행하기에 리소스가 부족해지기 전에 장애가 발생할 수 있는 최대 서버 수입니다. 최대 장애 용량을 계산하기 위해 XenServer는 다음을 고려합니다.
- 풀에 있는 VM의 다시 시작 우선순위
- 풀에 있는 서버 수
- 서버 CPU 및 메모리 용량
-
서버 장애 제한. 이 값은 계획 내에서 풀에서 허용할 서버 장애 수를 지정하는 고가용성 구성의 일부로 정의할 수 있습니다. 예를 들어, 풀의 서버 장애 제한이 3인 경우, XenServer는 3개의 서버가 장애를 일으켜도 모든 보호된 VM이 풀에서 계속 실행될 수 있도록 하는 페일오버 계획을 계산합니다. 서버 장애 제한을 최대 장애 용량보다 낮은 값으로 구성하여 풀이 과도하게 커밋될 가능성을 줄일 수 있습니다. 이 구성은 RBAC가 활성화된 환경에서 유용할 수 있습니다. 예를 들어, 이 설정을 통해 Pool Operator보다 낮은 권한을 가진 RBAC 사용자가 고가용성 계획을 손상시키지 않고 더 많은 VM을 온라인 상태로 전환할 수 있습니다. 자세한 내용은 고가용성 및 역할 기반 액세스 제어(RBAC) 섹션을 참조하십시오.
최대 장애 용량 값이 서버 장애 제한에 지정된 값보다 낮아지면 시스템 경고가 생성됩니다.
오버커밋 보호
풀에서 고가용성이 처음 활성화되면, 당시 사용 가능한 리소스를 기반으로 장애 계획이 계산됩니다. XenServer 고가용성은 풀에 영향을 미칠 수 있는 이벤트(예: 새 VM 시작)에 대응하여 새로운 장애 계획을 동적으로 계산합니다. 풀 전체에 걸쳐 리소스가 부족하여 새 계획을 계산할 수 없는 경우, 풀은 오버커밋됩니다. 리소스 부족의 예로는 충분하지 않은 여유 메모리 또는 어떤 서버에서 어떤 VM이 다시 시작될 수 있는지에 영향을 미치는 가상 디스크 및 네트워크 변경 사항이 있을 수 있습니다.
고가용성 재시작 우선순위는 풀이 과도하게 커밋되었을 때 어떤 VM을 시작할지 결정하는 데 사용됩니다. HA 구성 대화 상자 또는 HA 구성 마법사에서 보호하려는 VM의 재시작 우선순위를 구성하면 풀의 최대 장애 용량이 동적으로 다시 계산됩니다. 이 정보를 통해 비즈니스 요구 사항에 따라 VM 재시작 우선순위의 다양한 조합을 시도할 수 있습니다. 풀에서 중요한 VM에 필요한 보호 수준에 최대 장애 용량이 적절한지 확인할 수 있습니다.
VM을 시작하거나 다시 시작하려고 시도하고 해당 작업으로 인해 풀이 과도하게 커밋되는 경우, XenCenter에 경고가 표시됩니다. 구성된 경우 메시지를 이메일 주소로 보낼 수도 있습니다. 작업을 취소하거나, 풀이 과도하게 커밋되더라도 계속 진행할 수 있는 옵션이 제공됩니다.
HA가 활성화된 풀 작업
고가용성에 대한 모범 사례는 고가용성이 활성화된 동안 풀에 구성 변경을 하지 않는 것입니다. 대신, 이는 주변에 관리자가 없을 때 문제가 발생할 경우 서버를 다시 시작하는 “새벽 2시의 안전장치” 역할을 하도록 고안되었습니다. 소프트웨어 업데이트 적용과 같이 풀에서 구성 변경을 활발하게 수행하는 경우, 이러한 변경 중에는 고가용성을 비활성화하십시오.
- XenCenter에서 보호된 VM을 종료하려고 하면, XenCenter는 장애 계획에서 VM을 제거한 다음 종료하는 옵션을 제공합니다. 이 옵션은 의도치 않은 VM 종료로 인해 다운타임이 발생하지 않도록 보장하지만, 정말로 원하는 경우 보호된 VM을 중지할 수 있도록 합니다.
- 고가용성이 활성화된 상태에서 서버를 재부팅해야 하는 경우, XenCenter는 VM 재시작 우선순위를 자동으로 사용하여 이 재부팅이 풀 장애 계획을 무효화하는지 여부를 결정합니다. 계획에 영향을 미치지 않으면 서버는 정상적으로 종료됩니다. 계획이 위반되었지만 최대 장애 용량이 1보다 큰 경우, XenCenter는 풀의 서버 장애 제한을 1만큼 낮추는 옵션을 제공합니다. 이 작업은 풀의 전반적인 복원력을 감소시키지만, 항상 최소한 하나의 서버 장애는 허용되도록 보장합니다. 서버가 다시 시작되면 계획이 자동으로 다시 계산되고, 적절한 경우 원래 서버 장애 제한이 복원됩니다.
- 업데이트 설치 마법사를 사용하여 소프트웨어 업데이트를 설치할 때, HA 끄기를 선택하여 풀에서 고가용성을 비활성화해야 합니다. 업데이트가 설치된 후 고가용성을 다시 활성화할 수 있습니다. 고가용성을 비활성화하지 않으면 업데이트가 진행되지 않습니다. 업데이트가 설치되는 동안 풀을 수동으로 모니터링하여 서버 장애가 풀 작동을 방해하지 않도록 하십시오.
- 고가용성이 활성화된 경우, 풀에서 서버를 제거하는 것과 같이 VM 재시작 계획을 손상시킬 수 있는 일부 작업이 비활성화될 수 있습니다. 이러한 작업을 수행하려면 고가용성을 일시적으로 비활성화하거나 계속하기 전에 보호된 VM을 종료할 수 있습니다.
고가용성 및 역할 기반 액세스 제어(RBAC)
역할 기반 액세스 제어(RBAC)가 구현된 XenServer 환경에서는 모든 사용자가 풀의 고가용성 구성 설정을 변경할 수 있는 것은 아닙니다. 예를 들어, VM 운영자는 HA가 활성화된 풀의 페일오버 용량을 조정할 충분한 권한이 없습니다. VM을 시작하는 것이 허용되는 최대 서버 장애 수를 현재 값보다 낮은 값으로 줄이는 경우, VM 운영자는 VM을 시작할 수 없습니다. 풀 관리자 또는 풀 운영자 수준 사용자만 허용되는 서버 장애 수를 구성할 수 있습니다.
이 경우 풀 관리자 또는 풀 운영자는 서버 장애 제한을 허용되는 최대 장애 수보다 낮은 숫자로 설정할 수 있습니다. 이 설정은 여유 용량을 생성하여 권한이 낮은 사용자가 새 VM을 시작할 수 있도록 보장합니다. 이는 장애 계획을 위협하지 않으면서 풀의 페일오버 용량을 줄입니다.
관련 설명서
XenServer 현재 릴리스
공유
공유
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.