Azure에서 가상 머신 유지 관리

적용 대상: ✔️ Linux VM ✔️ Windows VM ✔️ 유연한 확장 집합 ✔️ 균일한 확장 집합

Azure에서는 가상 머신에 대한 호스트 인프라의 안정성, 성능 및 보안을 개선하기 위해 주기적으로 플랫폼을 업데이트합니다. 이러한 업데이트의 용도는 호스팅 환경의 소프트웨어 구성 요소 패치에서 네트워킹 구성 요소 업그레이드 또는 하드웨어 서비스 해제에 이르기까지 다양합니다.

업데이트는 호스트된 VM에 거의 영향을 주지 않습니다. 업데이트에 영향을 주는 경우 Azure는 가장 영향이 적은 업데이트 방법을 선택합니다.

  • 다시 부팅하지 않는 업데이트가 가능한 경우, 호스트가 업데이트되는 동안 VM이 일시 중지되거나, 이미 업데이트된 호스트로 실시간 마이그레이션됩니다.

  • 업데이트에 재부팅이 필요한 경우 Azure 계획된 유지 관리를 알립니다. Azure는 사용자가 편리한 시간에 유지 관리를 직접 시작할 수 있는 시간 범위도 제공합니다. 자체 유지 관리 기간은 유지 관리 유형에 따라 달라집니다.

    • 하드웨어 서비스 해제: 자체 유지 관리 기간은 일반적으로 14일입니다.
    • 호스트 유지 관리: 유지 관리가 시급하지 않는 한 자체 유지 관리 기간은 일반적으로 35일입니다.

    Azure 계획된 플랫폼 유지 관리를 위해 VM을 다시 부팅해야 하는 사례 수를 줄이기 위해 기술에 투자하고 있습니다. 계획된 유지 관리 관리에 대한 지침은 Azure CLI, PowerShell 또는 포털을 사용하여 계획된 유지 관리 알림 처리를 참조하세요.

이 페이지에서는 Azure에서 두 가지 유형의 유지 관리를 모두 수행하는 방법을 설명합니다. 계획되지 않은 이벤트(중단)에 대한 자세한 내용은 Windows용 VM의 가용성 관리 또는 Linux에 대한 관련 문서를 참조하세요.

VM 내에서 Linux용 또는 Windows용 Scheduled Events를 사용하여 예정된 유지 관리에 대한 알림을 받을 수 있습니다.

재부팅이 필요 없는 유지 관리

대부분의 플랫폼 업데이트는 고객 VM에 영향을 주지 않습니다. 영향을 주지 않는 업데이트가 불가능한 경우 Azure는 고객 VM에 미치는 영향이 가장 적은 업데이트 메커니즘을 선택합니다.

유지 관리에 영향을 주는 VM이 필요한 경우 거의 항상 10초 이내에 VM 일시 중지를 통해 완료됩니다. 드문 경우지만, 범용 VM 크기에 대해 18개월마다 최대 한 번에 한해 Azure는 VM을 약 30초 동안 일시 중지하는 메커니즘을 사용합니다. 일시 중지 작업 후에 VM 클록은 다시 시작 시 자동으로 동기화됩니다.

메모리 보존 유지 관리는 90%를 초과하는 Azure VM에서 작동합니다. G, L, N 및 H 시리즈에서는 작동하지 않습니다. 자세한 내용은 메모리 유지 관리 유지 관리를 지원하는 VM 크기를 참조하세요. Azure는 실시간 마이그레이션 기술을 점점 더 많이 사용하며 메모리 보존 유지 관리 메커니즘을 개선하여 일시 중지 기간을 줄이고 있습니다.

다시 부팅할 필요가 없는 유지 관리 작업은 한 번에 하나의 장애 도메인에 적용됩니다. 플랫폼 모니터링 도구에서 경고 상태 신호를 수신하면 중지됩니다. 다시 부팅이 필요하지 않은 유지 관리 작업은 쌍을 이루는 지역 또는 가용성 영역에서 동시에 발생할 수 있습니다. 지정된 변경의 경우 배포는 대부분 가용성 영역 및 지역 쌍 간에 순차적으로 진행되지만 꼬리 부분에서 겹칠 수 있습니다.

이러한 종류의 업데이트는 일부 애플리케이션에 영향을 줄 수 있습니다. VM을 다른 호스트로 실시간 마이그레이션하는 경우 일부 중요한 워크로드는 VM 일시 중지까지 몇 분간 성능이 약간 저하될 수 있습니다. VM 유지 관리를 준비하고 Azure 유지 관리 중 영향을 줄이려면 해당 애플리케이션에 Linux 또는 Windows용 Scheduled Events를 사용해보십시오.

무영향 업데이트 및 다시 부팅 없는 업데이트를 포함한 모든 유지 관리 작업에 대한 제어를 강화하기 위해 유지 관리 구성 기능을 만들 수 있습니다. 유지 관리 구성을 만들면 모든 플랫폼 업데이트를 건너뛰고 원하는 시간에 업데이트를 적용할 수 있는 옵션이 제공됩니다. 자세한 내용은 유지 관리 구성으로 플랫폼 업데이트 관리를 참조하세요.

실시간 마이그레이션

실시간 마이그레이션은 다시 부팅이 필요하지 않으며 VM에 대한 메모리를 보존하는 작업입니다. 일시 정지 또는 멈춤이 발생하며, 일반적으로 5초를 넘지 않습니다. G, L, N, H 시리즈를 제외하고 모든 IaaS(infrastructure as a service) VM은 실시간 마이그레이션에 적합합니다. 실시간 마이그레이션은 대부분의 M 시리즈 SKU에서 사용할 수 있습니다. 적합한 VM은 Azure 집합에 배포된 IaaS VM의 90%를 초과합니다.

참고

시도되었거나 다시 부팅할 필요가 없는 실시간 마이그레이션 작업에 대한 알림은 Azure Portal에서 수신되지 않습니다. 다시 부팅할 필요가 없는 실시간 마이그레이션 목록을 보려면 예약된 이벤트를 쿼리합니다.

실시간 마이그레이션은 최상의 노력으로 수행됩니다. 경우에 따라 실시간 마이그레이션이 성공하지 못할 수 있으며, 필요한 경우 알림 전에 VM이 서비스 복구로 예약됩니다. 실시간 마이그레이션은 보장된 작업이 아닙니다.

Azure 플랫폼은 다음 시나리오에서 실시간 마이그레이션을 트리거합니다.

  • 계획된 유지 관리
  • 하드웨어 오류
  • 할당 최적화

일부 계획된 유지 관리 시나리오는 실시간 마이그레이션을 사용하며, 실시간 마이그레이션 작업이 시작되는 시기는 Scheduled Events를 사용하여 미리 알 수 있습니다.

Azure Machine Learning 알고리즘에서 임박한 하드웨어 오류 또는 VM 할당 최적화를 예측할 때 실시간 마이그레이션을 사용하여 VM을 이동할 수도 있습니다. 성능이 저하된 하드웨어 인스턴스를 감지하는 예측 모델링에 대한 자세한 내용은 예측 기계 학습 및 실시간 마이그레이션을 사용하여 Azure VM 복원력 향상을 참조하세요. 실시간 마이그레이션 알림은 Azure Portal에서 모니터 및 Service Health 로그 및 Scheduled Events에 나타납니다(해당 서비스를 사용하는 경우).

실시간 마이그레이션 중 TCP 연결 복원력

데이터베이스 서버, 메시지 브로커 및 캐싱 계층과 같은 수명이 긴 TCP 연결을 유지하는 애플리케이션은 실시간 마이그레이션 중에 연결이 중단되는 것을 경험할 수 있습니다. VM 일시 중지는 일반적으로 5초 미만이지만 일시 중지 중 및 이후의 TCP 스택 동작은 주소가 지정되지 않은 경우 애플리케이션 수준 복구 시간을 연장할 수 있습니다.

실시간 마이그레이션이 TCP 연결에 미치는 영향:

  • 일시 중지 동안 마이그레이션 중인 VM은 전송 중인 TCP 세그먼트에 대해 ACK를 보내지 않습니다.
  • 보내는 쪽(클라이언트 또는 부하 분산 장치 상태 프로브)은 지수 백오프를 사용하여 TCP 재전송을 시작합니다.
  • Azure 표준 Load Balancer 구성된 유휴 시간 제한을 초과하는 유휴 연결에 TCP RST를 보냅니다. 그러나 전송 중인 데이터가 있는 활성 연결의 경우, 로드 밸런서는 마이그레이션 일시 중지 동안 TCP RST를 보내지 않습니다. 연결은 열려 있지만 응답하지 않는 상태로 유지되며 클라이언트에는 즉각적인 실패 신호가 없습니다.
  • 애플리케이션 수준 튜닝이 없으면 Linux에서 기본 TCP 재전송 동작tcp_retries2 = 15 이 연결 오류 검색을 약 15분 지연할 수 있습니다.

Important

그 영향은 운영 체제 기본값에 따라 크게 달라집니다. Linux에서는 tcp_retries2의 기본값이 15이며, 그 결과 끊어진 연결을 감지하기까지 약 15분이 걸립니다. Windows TcpMaxDataRetransmissions 기본값은 5로, 검색 시간을 튜닝 없이 약 25-50초로 제한합니다. 이 문서에 설명된 완화 방법은 Linux 기반 워크로드에 가장 중요합니다.

참고

HTTP/1.1 워크로드의 경우 일반적으로 영향이 제한됩니다. 마이그레이션 시 진행 중인 요청만 영향을 받으며, HTTP/1.1 클라이언트는 연결 유지 연결을 통해 파이프라인되지 않으므로 다음 요청에 대한 새 연결을 열어 빠르게 복구합니다. HTTP/2의 경우 여러 동시 스트림이 단일 TCP 연결을 공유하기 때문에 폭발 반경이 더 넓습니다.

부하 분산 장치가 L4 TLS 통과 모드에서 작동하는 경우 암호화된 스트림에 오류 응답을 검사, 재시도 또는 삽입할 수 없습니다. 이 구성에서 클라이언트는 중단된 연결에서 검색 및 복구를 전적으로 담당합니다.

다중 인스턴스 배포를 사용하여 폭발 반경을 줄입니다.

TCP 수준 완화를 적용하기 전에 아키텍처 기준을 고려합니다. 실시간 마이그레이션은 가용성 집합 또는 가상 머신 확장 집합 내에서 한 번에 하나의 VM에 영향을 줍니다. 여러 백 엔드 인스턴스에 연결을 분산하면 단일 마이그레이션 이벤트의 영향이 제한됩니다.

  • 인스턴스가 3개인 확장 집합은 각 마이그레이션 이벤트가 활성 연결의 최대 1/3에 영향을 줍니다.
  • 여러 가용 영역에 걸쳐 배포하면 서로 다른 가용 영역에서의 마이그레이션이 겹치지 않도록 보장합니다.
  • 여러 백 엔드에 분산된 연결 풀이 있는 클라이언트는 영향을 받지 않는 연결이 요청을 즉시 계속 제공하므로 더 빠르게 복구됩니다.

VM이 일시 중지되는 동안 일시 중지된 백엔드에 대한 Azure 표준 Load Balancer 상태 프로브도 실패합니다. 부하 분산 장치는 약 10초 내에 백 엔드를 비정상으로 표시하고(기본 5초 간격으로 두 번의 연속 프로브 오류) 새 연결 라우팅을 중지합니다. 이 조건은 새 연결이 자연스럽게 보호됨을 의미합니다. 이 문서에 설명된 TCP 완화는 마이그레이션이 시작되기 전에 이미 설정된 기존 연결을 해결합니다.

권장되는 완화 방법:

다음 완화는 보완적입니다. 함께 구현하면 실시간 마이그레이션 이벤트의 영향을 잠재적 가동 중지 시간(분)에서 자동 복구(초)로 줄입니다.

우선 순위 완화 방법 노력 영향
1 소켓 수준에서 TCP_USER_TIMEOUT을(를) 설정합니다 낮음 끊긴 연결 감지 시간을 약 15분에서 30초로 줄입니다.
2 예약된 이벤트 구독 중간 중지가 발생하기 전에 연결 드레이닝을 사전에 수행할 수 있습니다
3 TCP keepalive 매개변수 조정 낮음 마이그레이션 후 부실한 유휴 연결을 검색합니다.
4 클라이언트 쪽 재시도 논리 구현 중간 근본 원인에 관계없이 복원력을 제공합니다.

완화 방법 1: TCP_USER_TIMEOUT (가장 빠른 감지)

TCP_USER_TIMEOUT 는 커널이 전송된 데이터의 승인을 기다리는 동안 연결이 멸망되었음을 선언하는 시간을 제어합니다. 이를 소켓당 30초(30000ms)로 설정하면 검색 시간이 크게 줄어듭니다.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

또는 시스템 전체 재전송 횟수를 줄입니다.

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Tip

시스템 차원이 아닌 SDK 또는 소켓 수준에서 설정합니다 TCP_USER_TIMEOUT . 30초의 값은 좋은 시작점입니다. 10초 미만의 값은 일반적인 네트워크 지터가 발생하는 동안 오탐지를 유발할 수 있습니다.

Windows 고려 사항:

TCP_USER_TIMEOUT 소켓 옵션은 Linux에만 적용됩니다. Windows TCP 재전송 동작은 다르게 제어됩니다.

  • Windows 기본적으로 5개의 재전송(TcpMaxDataRetransmissions)으로 설정되며, 튜닝 없이 약 25~50초의 검색 시간을 이미 제공합니다.
  • Windows 검색 시간을 추가로 줄이려면 레지스트리를 조정합니다.
# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

3으로 설정하면 TcpMaxDataRetransmissions 초기 재전송 시간 제한에 따라 검색 시간이 약 10-20초로 줄어듭니다.

참고

Linux와 달리 Windows는 TCP_USER_TIMEOUT에 해당하는 소켓별 기능을 제공하지 않습니다. 레지스트리 설정은 시스템의 모든 TCP 연결에 적용됩니다. Windows에서 세밀한 제어를 하려면 애플리케이션 수준의 시간 제한과 상태 검사(완화 4)에 의존하세요.

완화 2: 예약된 이벤트(사전 드레이닝)

예약된 이벤트 서비스는 실시간 마이그레이션이 시작되기 전에 사전 알림을 제공합니다. 애플리케이션은 Freeze 이벤트를 수신 대기하고 일시 중지가 발생하기 전에 연결을 미리 드레이닝할 수 있습니다.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

실시간 마이그레이션 이벤트는 다음과 같이 표시됩니다.

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Freeze 이벤트가 검색된 경우:

  1. 영향을 받는 노드에서 새 연결 수락을 중지합니다.
  2. 기존 연결을 드레이닝합니다(클라이언트가 다른 노드에 다시 연결하도록 신호).
  3. 지정된 제한 시간 내에서 진행 중인 작업이 완료될 때까지 기다립니다.
  4. 필요에 따라 EventId를 다시 게시하여 이벤트를 승인합니다.

참고

사전 통지 기간은 일반적으로 15분이지만 드문 경우에서 30초만큼 짧을 수 있습니다. 프로덕션 워크로드에는 초당 한 번 폴링 빈도를 사용하는 것이 좋습니다.

완화 3: TCP 유지 튜닝

TCP keepalive 프로브는 마이그레이션 이벤트 이후 유휴 상태가 되는 연결을 감지합니다.

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

이러한 설정을 사용하면 60초 이내에 유휴 부실 연결이 검색됩니다(30 + 10 x 3). 또한 Keepalive 프로브도 표준 Load Balancer의 유휴 시간 제한 계산 시 활동으로 간주되므로, Load Balancer가 유휴 연결을 별도로 시간 초과 처리하지 않도록 합니다.

완화책 4: 클라이언트 측 재시도 로직

애플리케이션 수준 다시 연결 및 재시도 논리는 오류 검색 방법에 관계없이 복구를 보장합니다.

  1. 연결 오류(시간 제한, RST 또는 연결 거부)를 검색합니다.
  2. 죽은 연결을 닫고 연결 풀에서 제거합니다.
  3. 동일하거나 다른 노드에 대한 새 연결을 엽니다.
  4. 지수 백오프를 사용하여 작업을 다시 시도합니다.

데이터베이스 SDK 및 연결 풀의 경우 정기적인 상태 검사(예: 10-15초마다 간단한 ping)를 사용하도록 설정하여 연결의 유효성을 사전에 검사합니다.

연결 풀 구성:

수명이 긴 연결을 유지하는 연결 풀은 최대 수명 설정의 이점을 누릴 수 있습니다. 이 설정은 주기적인 연결 재활용을 강제하여 단일 연결이 향후 마이그레이션 이벤트에서 무제한 위험을 누적하지 않도록 합니다.

풀링 기술 설정 권장되는 값
HikariCP(Java) maxLifetime 1800000(30분)
PgBouncer server_lifetime 1800(30분)
Go database/sql SetConnMaxLifetime 30 * 시간. 분
Node.js(pg 풀) idleTimeoutMillis 30000 (30초 유휴 시 제거; 최대 수명 제한에는 사용자 지정 로직이 필요함)
.NET SqlConnection 연결 문자열:Connection Lifetime 1800(30분)

최대 수명을 30분으로 설정하면 능동적 상태 검사가 없더라도 연결이 감지되지 않은 오래된 상태로 장기간 누적되기 전에 자연스럽게 교체됩니다.

모니터링 및 관찰 가능성:

TCP 연결에 대한 실시간 마이그레이션 이벤트의 영향을 감지하고 측정하려면 다음 방법을 사용합니다.

  • Azure Monitor VM 가용성 메트릭(미리 보기): VM 일시 중지 중에 0으로 떨어집니다. 마이그레이션 이벤트를 감지하려면 VmAvailabilityMetric에서 임계값을 1 미만으로 설정한 경고 규칙을 만듭니다.
  • 예약된 이벤트 활동 로그: 라이브 마이그레이션 이벤트는 작업 이름을 Microsoft.Compute 가진 공급자 아래의 Microsoft.Compute/virtualMachines/liveMigration/action 활동 로그에 표시되거나 메타데이터 서비스를 통해 쿼리될 때 이벤트로 Freeze 표시됩니다.
  • 애플리케이션 수준 연결 오류 비율: 애플리케이션 메트릭에서 TCP 연결 재설정, 시간 제한 및 다시 연결 수를 모니터링합니다. VM 가용성 급락과 상관 관계가 있는 연결 오류가 급증하면 마이그레이션 영향이 확인됩니다.
  • TCP 재전송 카운터: Linux에서 필드를 /proc/net/netstat 모니터링 TCPTimeouts 하거나 개별 소켓에서 재전송 횟수를 관찰하는 데 사용합니다ss -ti. 알려진 유지 관리 기간 동안 상승된 재전송은 연결이 영향을 받았다는 것을 나타냅니다.
# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

정상 작업 중에 이러한 메트릭에 대한 기준을 설정하면 마이그레이션 이벤트의 영향을 쉽게 정량화하고 완화가 예상대로 작동하는지 확인할 수 있습니다.

실시간 마이그레이션 중단에 대한 허용 오차가 없는 워크로드

실시간 마이그레이션 중단을 허용할 수 없는 워크로드의 경우 유지 관리 구성에서 Azure 전용 호스트를 사용하는 것이 좋습니다. 전용 호스트는 호스트 수준 유지 관리가 발생하는 시기를 제어하여 놀라운 실시간 마이그레이션 이벤트를 제거합니다.

재부팅이 필요한 유지 관리

드물긴 하지만 계획된 유지 관리를 위해 VM을 다시 부팅해야 하는 경우 미리 알림이 제공됩니다. 계획된 유지 관리에는 셀프 서비스 단계와 예약된 유지 관리 단계라는 두 가지 단계가 있습니다.

일반적으로 4주 동안 지속되는 셀프 서비스 단계에서는 사용자가 VM에 대한 유지 관리를 시작합니다. 셀프 서비스의 일부로 각 VM을 쿼리하여 해당 상태와 마지막 유지 관리 요청의 결과를 확인할 수 있습니다.

참고

실시간 마이그레이션을 지원하지 않는 VM 시리즈의 경우 유지 관리 이벤트 중에 로컬(임시) 디스크 데이터가 손실될 수 있습니다. 실시간 마이그레이션 지원 여부에 대한 정보는 각 개별 VM 시리즈를 참조하세요.

셀프 서비스 유지 관리를 시작하면 VM이 이미 업데이트된 노드에 다시 배포됩니다. VM이 다시 배포되기 때문에 임시 디스크가 손실되고 가상 네트워크 인터페이스와 연결된 공개 동적 IP 주소가 업데이트됩니다.

셀프 서비스 유지 관리 중에 오류가 발생하면 작업이 중지되고 VM이 업데이트되지 않으며 셀프 서비스 유지 관리를 다시 시도할 수 있는 옵션이 제공됩니다.

셀프 서비스 단계가 끝나면 예약된 유지 관리 단계가 시작됩니다. 이 단계 중에도 유지 관리 단계를 계속 쿼리할 수 있지만 직접 유지 관리를 시작할 수는 없습니다.

재부팅이 필요한 유지 관리를 관리하는 방법에 대한 자세한 내용은 Azure CLI, PowerShell 또는 포털을 사용하여 계획된 유지 관리 알림 처리를 참조하세요.

예약된 유지 관리 중 가용성 고려 사항

예약된 유지 관리 단계까지 기다리기로 결정한 경우 VM의 고가용성을 유지 관리하기 위해 고려해야 할 사항이 몇 가지 있습니다.

쌍을 이루는 지역

각 Azure 지역은 같은 지리적 권역 내의 다른 지역과 쌍을 이룹니다. 이 둘이 함께 지역 쌍을 이룹니다. 예약된 유지 관리 단계에서 Azure는 하위 지역 쌍의 단일 하위 지역에서만 VM을 업데이트합니다. 예를 들어 미국 중북부에 있는 VM을 업데이트하는 동안 Azure는 미국 중남부의 VM을 동시에 업데이트하지 않습니다. 그러나 북유럽 등의 다른 지역은 미국 동부와 동시에 유지 관리될 수 있습니다. 지역 쌍의 작동 방식을 이해하면 지역에 VM을 더 잘 배포할 수 있습니다. 자세한 내용은 Azure 지역 쌍을 참조하세요.

가용성 영역

가용성 영역은 Azure 지역 내의 고유한 물리적 위치입니다. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다. 복원력을 보장하려면 활성화된 모든 지역에서 최소한 세 개의 별도 영역이 필요합니다.

가용성 영역은 장애 도메인과 업데이트 도메인의 조합입니다. Azure 지역의 3개 영역에 VM을 3개 이상 만들면 장애 도메인 3개와 업데이트 도메인 3개에 VM이 효과적으로 분산됩니다. Azure 플랫폼은 업데이트 도메인에 분산된 VM을 인식하여 다른 영역에 있는 VM이 동시에 업데이트되지 않게 합니다.

각 인프라 업데이트는 단일 지역 내에서 영역별로 배포됩니다. 하지만 영역 1에서 배포를 진행하고 영역 2에서 다른 배포를 동시에 진행할 수 있습니다. 일부 배포는 직렬화되지 않습니다. 하지만 다시 부팅이 필요한 단일 배포는 한 번에 하나의 영역만 롤아웃하여 위험을 줄입니다. 일반적으로 다시 부팅이 필요한 업데이트는 가능하면 방지되며 Azure는 실시간 마이그레이션을 사용하거나 고객 제어를 제공하려고 시도합니다.

Virtual Machine Scale Sets

유연한 오케스트레이션 모드의 가상 머신 확장 집합은 Azure 컴퓨팅 리소스로 균일 오케스트레이션 모드의 가상 머신 확장 집합의 확장성과 가용성 집합의 지역적 가용성 보장을 결합할 수 있습니다.

유연한 오케스트레이션을 사용하면 인스턴스를 여러 영역에 분산할지 아니면 단일 지역 내의 장애 도메인에 분산할지 선택할 수 있습니다.

가용성 집합 및 균일 확장 집합

Azure VM에서 워크로드를 배포할 때 애플리케이션에 고가용성을 제공하기 위해 가용성 세트 내에 VM을 만들 수 있습니다. 가용성 집합을 사용하면 중단이 발생하거나 재부팅이 필요한 유지 관리 이벤트가 발생하는 동안에도 최소 하나의 VM을 계속 사용할 수 있도록 할 수 있습니다.

가용성 집합 내에서 개별 VM은 최대 20개의 업데이트 도메인에 걸쳐 분산됩니다. 예약된 유지 관리 중에는 한 번에 하나의 업데이트 도메인만 업데이트됩니다. 업데이트 도메인이 반드시 순차적으로 업데이트되는 것은 아닙니다.

균일 오케스트레이션 모드의 가상 머신 확장 집합은 동일한 VM 집합을 단일 리소스로 배포하고 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스입니다. 확장 집합은 가용성 집합의 VM처럼 여러 UD에 걸쳐 자동으로 배포됩니다. 가용성 집합과 마찬가지로 Uniform 확장 집합을 사용하면 예약된 유지 관리 중 주어진 시간에 UD가 하나만 업데이트됩니다.

VM의 고가용성 설정에 대한 자세한 내용은 Windows용 VM의 가용성 관리 또는 Linux용 해당 문서를 참조하세요.

다음 단계

계획된 유지 관리를 관리하려면 Azure CLI, Azure PowerShell 또는 포털을 사용합니다.

  • Last updated on