계획 된 유지 관리 알림 처리Handling planned maintenance notifications

Azure에서는 가상 머신에 대한 호스트 인프라의 안정성, 성능 및 보안을 향상시키기 위해 주기적으로 업데이트를 수행합니다.Azure periodically performs updates to improve the reliability, performance, and security of the host infrastructure for virtual machines. 업데이트란 호스팅 환경의 패치 적용 또는 하드웨어의 업그레이드 및 서비스 해제와 같은 변경 내용을 말합니다.Updates are changes like patching the hosting environment or upgrading and decommissioning hardware. 이러한 업데이트 중 대다수는 호스트 된 가상 머신에 영향을 주지 않고 완료 됩니다.A majority of these updates are completed without any impact to the hosted virtual machines. 그러나 업데이트가 다음 항목에 영향을 미치는 경우가 있습니다.However, there are cases where updates do have an impact:

  • 유지 관리를 다시 부팅하지 않아도 되는 경우 Azure에서는 호스트를 업데이트하는 동안 바로 마이그레이션을 사용하여 VM을 일시 중지합니다.If the maintenance does not require a reboot, Azure uses in-place migration to pause the VM while the host is updated. 이러한 유형의 유지 관리 작업은 장애 도메인에 의해 장애 도메인에 적용 됩니다.These types maintenance operations are applied fault domain by fault domain. 경고 상태 신호를 받으면 진행이 중지됩니다.Progress is stopped if any warning health signals are received.

  • 유지 관리를 다시 부팅해야 하는 경우 유지 관리가 계획된 시기에 대해 알림을 받을 수 있습니다.If maintenance requires a reboot, you get a notice of when the maintenance is planned. 사용자에 게 유지 관리를 직접 시작할 수 있는 약 35 일의 기간이 제공 됩니다.You are given a time window of about 35 days where you can start the maintenance yourself, when it works for you.

다시 부팅해야 하는 계획된 유지 관리는 웨이브에서 예약됩니다.Planned maintenance that requires a reboot is scheduled in waves. 각 웨이브는 범위(지역)이 다릅니다.Each wave has different scope (regions).

  • 웨이브는 고객에게 알림을 보내면서 시작합니다.A wave starts with a notification to customers. 기본적으로 알림은 서비스 관리자와 공동 관리자에 게 전송 됩니다.By default, notification is sent to the Service Administrator and Co-Administrators. 활동 로그 경고를 사용 하 여 메일, SMS 및 웹 후크에 같은 받는 사람 및 메시징 옵션을 더 추가할 수 있습니다.You can add more recipients and messaging options like email, SMS, and webhooks, using Activity Log Alerts.
  • 알림이 전달 되 면 셀프 서비스 윈도 를 사용할 수 있습니다.Once a notification goes out, a self-service window is made available. 이 창에서 영향을 받는 가상 컴퓨터를 쿼리하고 사용자의 예약 요구 사항에 따라 유지 관리를 시작할 수 있습니다.During this window, you can query which of your virtual machines are affected and start maintenance based on your own scheduling needs. 셀프 서비스 기간은 일반적으로 약 35 일입니다.The self-service window is typically about 35 days.
  • 셀프 서비스 기간이 끝나면 예약된 유지 관리 기간이 시작됩니다.After the self-service window, a scheduled maintenance window begins. 이 기간 중 어떤 시점에 Azure는 가상 머신에 필요한 유지 관리를 예약하고 적용합니다.At some point during this window, Azure schedules and applies the required maintenance to your virtual machine.

두 기간이 존재하는 이유는 Azure에서 유지 관리를 자동으로 시작하는 시기를 파악하면서 유지 관리를 시작하고 가상 머신을 다시 부팅하는 데 충분한 시간을 제공하기 위한 것입니다.The goal in having two windows is to give you enough time to start maintenance and reboot your virtual machine while knowing when Azure will automatically start maintenance.

Azure Portal, PowerShell, REST API 및 CLI를 사용하여 사용자 VM에 대한 유지 관리 기간을 쿼리하고, 셀프 서비스 유지 관리를 시작할 수 있습니다.You can use the Azure portal, PowerShell, REST API, and CLI to query for the maintenance windows for your VMs and start self-service maintenance.

셀프 서비스 기간 동안 유지 관리를 시작해야 합니까?Should you start maintenance using during the self-service window?

다음 지침은 이 기능을 사용하여 여유 있는 시간에 유지 관리를 시작해야 하는지 결정하는 데 도움이 됩니다.The following guidelines should help you decide whether to use this capability and start maintenance at your own time.

참고

일부 VM에는 셀프 서비스 유지 관리를 사용하지 못할 수도 있습니다.Self-service maintenance might not be available for all of your VMs. VM에 사전 예방적 재배포를 사용할 수 있는지 확인하려면 유지 관리 상태에서 지금 시작을 살펴봅니다.To determine if proactive redeploy is available for your VM, look for the Start now in the maintenance status. 현재 셀프 서비스 유지 관리는 Cloud Services(웹/작업자 역할) 및 Service Fabric에서 사용할 수 없습니다.Self-service maintenance is currently not available for Cloud Services (Web/Worker Role) and Service Fabric.

가용성 집합을 사용 하는 배포에는 셀프 서비스 유지 관리를 사용 하지 않는 것이 좋습니다.Self-service maintenance is not recommended for deployments using availability sets. 가용성 집합은 이미 한 번에 하나의 업데이트 도메인만 업데이트 됩니다.Availability sets are already only updated one update domain at a time.

  • Azure에서 유지 관리를 트리거할 수 있습니다.Let Azure trigger the maintenance. 다시 부팅 해야 하는 유지 관리를 위해 업데이트 도메인에서 도메인 업데이트를 유지 관리 합니다.For maintenance that requires reboot, maintenance will be done update domain by update domain. 업데이트 도메인은 유지 관리를 순차적으로 수신 하지 않으며 업데이트 도메인 사이에 30 분의 일시 중지가 있습니다.The update domains do not necessarily receive the maintenance sequentially, and that there is a 30-minute pause between update domains.
  • 일부 용량이 일시적으로 손실 (1 업데이트 도메인) 될 경우 유지 관리 기간 동안 인스턴스를 추가할 수 있습니다.If a temporary loss of some capacity (1 update domain) is a concern, you can add instances during the maintenance period.
  • 다시 부팅이 필요하지 않은 유지 관리의 경우 업데이트는 장애 도메인 수준에서 적용됩니다.For maintenance that does not require reboot, updates are applied at the fault domain level.

다음 시나리오에서는 셀프 서비스 유지 관리를 사용하지 마세요.Don't use self-service maintenance in the following scenarios:

  • 수동으로, DevTest Labs를 사용하여, 자동 종료를 사용하여 또는 일정에 따라 VM을 자주 종료하는 경우 유지 관리 상태를 되돌려서 가동 중지 시간이 추가로 발생할 수 있습니다.If you shut down your VMs frequently, either manually, using DevTest Labs, using auto-shutdown, or following a schedule, it could revert the maintenance status and therefore cause additional downtime.
  • 유지 관리 웨이브가 끝나기 전에 삭제될 것을 알고 있는 단기간용 VM.On short-lived VMs that you know will be deleted before the end of the maintenance wave.
  • 업데이트 시 유지 관리하려는 로컬(임시) 디스크에 대규모 상태가 저장되는 워크로드.For workloads with a large state stored in the local (ephemeral) disk that is desired to be maintained upon update.
  • VM 크기를 자주 조정하는 경우, 유지 관리 상태를 되돌릴 수 있기 때문입니다.For cases where you resize your VM often, as it could revert the maintenance status.
  • 유지 관리 시스템 종료 15분 전에 워크로드의 사전 예방적 장애 조치(failover) 또는 정상 종료가 가능한 예약된 이벤트를 도입한 경우.If you have adopted scheduled events that enable proactive failover or graceful shutdown of your workload, 15 minutes before start of maintenance shutdown

예약된 유지 관리 단계 동안 중단 없이 VM을 실행하고 위에서 언급한 금기 중 어떤 것에도 해당하지 않는 경우 셀프 서비스 유지 관리를 사용합니다.Use self-service maintenance, if you are planning to run your VM uninterrupted during the scheduled maintenance phase and none of the counter-indications mentioned above are applicable.

다음과 같은 경우에는 셀프 서비스 유지 관리를 사용하는 것이 가장 좋습니다.It is best to use self-service maintenance in the following cases:

  • 관리 부서 또는 최종 사용자에게 정확한 유지 관리 기간을 전달해야 합니다.You need to communicate an exact maintenance window to your management or end-customer.
  • 지정된 날짜까지 유지 관리를 완료해야 합니다.You need to complete the maintenance by a given date.
  • 유지 관리의 순서를 제어해야 합니다(예: 안전 복구를 보장하기 위한 다층 계층 애플리케이션).You need to control the sequence of maintenance, for example, multi-tier application to guarantee safe recovery.
  • 두 업데이트 도메인 (Ud) 간에 30 분 넘게 VM 복구 시간이 필요 합니다.More than 30 minutes of VM recovery time is needed between two update domains (UDs). 업데이트 도메인 사이의 시간을 제어하려면 한 번에 하나의 UD(업데이트 도메인)에서 VM 유지 관리를 트리거해야 합니다.To control the time between update domains, you must trigger maintenance on your VMs one update domain (UD) at a time.

FAQFAQ

Q: 왜 내 가상 머신을 지금 다시 부팅해야 하나요?Q: Why do you need to reboot my virtual machines now?

A: Azure 플랫폼에 대한 대부분의 업데이트와 업그레이드는 가상 머신의 가용성에 영향을 주지 않으나, Azure에서 호스팅되는 가상 머신을 불가피하게 다시 부팅해야 하는 경우가 있습니다.A: While the majority of updates and upgrades to the Azure platform do not impact virtual machine's availability, there are cases where we can't avoid rebooting virtual machines hosted in Azure. 서버 재시작이 필요한 여러 변경 사항이 누적되면 가상 머신 다시 부팅이 발생하게 됩니다.We have accumulated several changes that require us to restart our servers that will result in virtual machines reboot.

Q: 가용성 집합을 사용 하 여 고가용성을 위해 권장 사항을 따르는 경우 안전 합니까?Q: If I follow your recommendations for High Availability by using an Availability Set, am I safe?

A: 가용성 집합 또는 가상 머신 확장 집합에 배포된 가상 머신에는 UD(업데이트 도메인) 개념이 있습니다.A: Virtual machines deployed in an availability set or virtual machine scale sets have the notion of Update Domains (UD). 유지 관리를 수행할 때 Azure는 UD 제약 조건을 적용하고 다른 UD(동일한 가용성 집합 내)의 가상 머신을 다시 부팅하지 않습니다.When performing maintenance, Azure honors the UD constraint and will not reboot virtual machines from different UD (within the same availability set). 또 Azure는 다음 가상 머신 그룹으로 이동하기 전에 30분 이상 대기합니다.Azure also waits for at least 30 minutes before moving to the next group of virtual machines.

고가용성에 대 한 자세한 내용은 Azure의 가상 컴퓨터 가용성을 참조 하세요.For more information about high availability, see Availability for virtual machines in Azure.

Q: 계획된 유지 관리에 관한 알림은 어떻게 받나요?Q: How do I get notified about planned maintenance?

A: 계획된 유지 관리 주기는 하나 이상의 Azure 지역에 예약을 설정하는 것에서 출발합니다.A: A planned maintenance wave starts by setting a schedule to one or more Azure regions. 곧 전자 메일 알림이 구독 관리자에 게 전송 됩니다 (구독 당 하나의 전자 메일).Soon after, an email notification is sent to the subscription Admins (one email per subscription). 이 알림에 대한 추가 채널과 받는 사람은 활동 로그 경고를 통해 구성할 수 있습니다.Additional channels and recipients for this notification could be configured using Activity Log Alerts. 계획된 유지 관리가 이미 예약된 지역에 가상 머신을 배포하는 경우 알림이 전달되지 않으므로 VM의 유지 관리 상태를 확인해야 합니다.In case you deploy a virtual machine to a region where planned maintenance is already scheduled, you will not receive the notification but rather need to check the maintenance state of the VM.

Q: 포털, PowerShell 또는 CLI에서 계획 된 유지 관리의 표시가 표시 되지 않습니다. 무슨 문제 있나요?Q: I don't see any indication of planned maintenance in the portal, PowerShell, or CLI. What is wrong?

A: 계획된 유지 관리 관련 정보는 영향을 받게 되는 VM에 대해서만 계획된 유지 관리 주기 중에 제공됩니다.A: Information related to planned maintenance is available during a planned maintenance wave only for the VMs that are going to be impacted by it. 즉 데이터가 표시되지 않는다면 유지 관리 주기가 이미 완료되었거나(또는 시작되지 않음) 가상 머신이 이미 업데이트된 서버에서 호스팅되는 것일 수 있습니다.In other words, if you see not data, it could be that the maintenance wave has already completed (or not started) or that your virtual machine is already hosted in an updated server.

Q: 내 가상 머신이 정확히 언제 영향을 받는지 확인할 수 있나요?Q: Is there a way to know exactly when my virtual machine will be impacted?

A: 예약을 설정할 때 며칠의 시간 창을 정의합니다.A: When setting the schedule, we define a time window of several days. 그러나 이 창 내에서의 정확한 서버(및 VM) 순서는 알 수 없습니다.However, the exact sequencing of servers (and VMs) within this window is unknown. VM에 해당하는 정확한 시간을 알고자 하는 고객은 예약된 이벤트를 사용하고 가상 머신 안에서 쿼리하여 VM이 다시 부팅되기 15분 전에 알림을 수신할 수 있습니다.Customers who would like to know the exact time for their VMs can use scheduled events and query from within the virtual machine and receive a 15-minute notification before a VM reboot.

Q: 가상 머신을 다시 부팅하는 데 얼마나 걸리나요?Q: How long will it take you to reboot my virtual machine?

A: VM의 크기에 따라 다시 부팅은 셀프 서비스 유지 관리 기간 동안 최대 몇 분이 소요될 수 있습니다.A: Depending on the size of your VM, reboot may take up to several minutes during the self-service maintenance window. Azure가 예약된 유지 관리 기간에서 다시 부팅을 시작하는 동안 다시 부팅은 일반적으로 약 25분 정도가 걸립니다.During the Azure initiated reboots in the scheduled maintenance window, the reboot will typically take about 25 minutes. Cloud Services(웹/작업자 역할), Virtual Machine Scale Sets 또는 가용성 집합을 사용하는 경우 예약된 유지 관리 기간 동안 각 VM 그룹(UD) 사이에 30분이 주어집니다.Note that in case you use Cloud Services (Web/Worker Role), Virtual Machine Scale Sets, or availability sets, you will be given 30 minutes between each group of VMs (UD) during the scheduled maintenance window.

Q: Virtual Machine Scale Sets의 경우에 환경이란?Q: What is the experience in the case of Virtual Machine Scale Sets?

A: 이제 계획 된 유지 관리를 Virtual Machine Scale Sets 사용할 수 있습니다.A: Planned maintenance is now available for Virtual Machine Scale Sets. 셀프 서비스 유지 관리를 시작 하는 방법에 대 한 지침은 가상 머신 확장 집합에 대 한 계획 된 유지 관리 문서를 참조 하세요.For instructions on how to initiate self-service maintenance refer planned maintenance for virtual machine scale sets document.

Q: Cloud Services(웹/작업자 역할) 및 Service Fabric의 경우에 환경이란?Q: What is the experience in the case of Cloud Services (Web/Worker Role) and Service Fabric?

A: 이러한 플랫폼은 계획된 유지 관리의 영향을 받지만, 이런 플랫폼을 사용하는 고객은 특정 시간에 단일 UD(업그레이드 도메인)의 VM만 영향을 받는다면 안전하다고 할 수 있습니다.A: While these platforms are impacted by planned maintenance, customers using these platforms are considered safe given that only VMs in a single Upgrade Domain (UD) will be impacted at any given time. 현재 셀프 서비스 유지 관리는 Cloud Services(웹/작업자 역할) 및 Service Fabric에서 사용할 수 없습니다.Self-service maintenance is currently not available for Cloud Services (Web/Worker Role) and Service Fabric.

Q: 내 Vm에 대 한 유지 관리 정보가 표시 되지 않습니다. 무엇이 문제 인가요?Q: I don’t see any maintenance information on my VMs. What went wrong?

A: VM에 대한 유지 관리 정보가 전혀 표시되지 않는 데는 몇 가지 이유가 있습니다.A: There are several reasons why you’re not seeing any maintenance information on your VMs:

  1. Microsoft 내부로 표시된 구독을 사용하고 있습니다.You are using a subscription marked as Microsoft internal.
  2. VM에 유지 관리가 예약되어 있지 않습니다.Your VMs are not scheduled for maintenance. 유지 관리 주기가 종료, 취소 또는 수정되면 VM이 더 이상 해당 주기의 영향을 받지 않습니다.It could be that the maintenance wave has ended, canceled, or modified so that your VMs are no longer impacted by it.
  3. VM 목록 보기에 유지 관리 열을 추가할 필요는 없습니다.You don’t have the Maintenance column added to your VM list view. 기본 보기에 이 열을 추가했지만, 기본이 아는 열을 보도록 구성한 고객은 수동으로 유지 관리 열을 VM 목록 보기에 추가해야 합니다.While we have added this column to the default view, customers who configured to see non-default columns must manually add the Maintenance column to their VM list view.

Q: 내 VM은 두 번째 유지 관리를 위해 예약 됩니다. 굳이?Q: My VM is scheduled for maintenance for the second time. Why?

A: 유지 관리 재배포를 이미 완료한 후에도 VM에 유지 관리가 예약되는 몇 가지 사용 사례가 있습니다.A: There are several use cases where you will see your VM scheduled for maintenance after you have already completed your maintenance-redeploy:

  1. 유지 관리 주기를 취소하고 다른 페이로드에서 다시 시작합니다.We have canceled the maintenance wave and restarted it with a different payload. 오류가 발생한 페이로드를 탐지하여 단순히 추가 페이로드를 배포해야 합니다.It could be that we've detected faulted payload and we simply need to deploy an additional payload.
  2. VM은 하드웨어 오류로 인해 다른 노드에 대해 조정된 서비스입니다.Your VM was service healed to another node due to a hardware fault.
  3. VM을 중지(할당 취소)하고 다시 시작하도록 선택했습니다.You have selected to stop (deallocate) and restart the VM.
  4. VM에 대해 자동 종료를 실행했습니다.You have auto shutdown turned on for the VM.

다음 단계Next steps

Azure CLI, Azure PowerShell 또는 포털을 사용 하 여 계획 된 유지 관리를 처리할 수 있습니다.You can handle planned maintenance using the Azure CLI, Azure PowerShell or portal.