Обслуживание виртуальных машин Linux в Azure

Применимо к: ✔️ Виртуальные машины Linux ✔️ Виртуальные машины Windows ✔️ Гибкие масштабируемые наборы ✔️ Единообразные масштабируемые наборы

Azure периодически выполняет обновления своей платформы, чтобы повысить надежность, производительность и безопасность инфраструктуры узлов, в которой работают виртуальные машины. Причины этих обновлений разные: от исправлений программных компонентов в среде размещения до обновления сетевых компонентов или вывода оборудования из эксплуатации.

Обновления редко влияют на размещенные виртуальные машины. Когда они все же оказывают определенное воздействие, Azure выбирает для обновлений метод, сводящий его к минимуму.

• Если возможно обновление без перезагрузки, виртуальная машина приостанавливается во время обновления узла или динамически переносится на узел, который уже обновлен.

• Если обновление требует перезагрузки, Azure уведомляет вас о плановом обслуживании. Azure также предоставляет период, в который можно начать обслуживание самостоятельно, когда это будет удобно. Период самостоятельного обслуживания зависит от типа обслуживания:

  • Удаление оборудования: период самостоятельного обслуживания обычно составляет 14 дней.
  • Обслуживание узла: период самостоятельного обслуживания обычно составляет 35 дней, если обслуживание не является срочным.

  Azure инвестирует в технологии, чтобы сократить количество случаев, в которых плановое обслуживание платформы требует перезагрузки виртуальных машин. Инструкции по управлению запланированным обслуживанием см. в разделе "Обработка уведомлений о плановом обслуживании" с помощью Azure CLI, PowerShell или портала.

На этой странице описано, как Azure выполняет обслуживание обоих типов. Дополнительные сведения о внеплановых событиях (простоях) см. в статье Управление доступностью виртуальных машин Windows или соответствующей статье для Linux.

Вы можете получать внутренние уведомления виртуальной машины о предстоящем обслуживании с помощью запланированных событий для Windows или Linux.

Обслуживание, не требующее перезагрузки

Большинство обновлений платформы не влияет на виртуальные машины клиента. Если обновление без такого влияния невозможно, Azure выбирает механизм обновления, который в наименьшей мере затрагивает виртуальные машины клиентов.

Если требуются работы по обслуживанию, влияющие на виртуальную машину, они почти всегда выполняются путём приостановки виртуальной машины менее чем на 10 секунд. В редких случаях не более одного раза каждые 18 месяцев для размеров виртуальных машин общего назначения Azure использует механизм, который приостанавливает виртуальную машину около 30 секунд. После любой операции приостановки часы виртуальной машины автоматически синхронизируются при возобновлении.

Обслуживание с сохранением памяти доступно более чем для 90 % виртуальных машин Azure. Он не работает для серии G, L, N и H. Дополнительные сведения см. в том, какие размеры виртуальных машин поддерживают обслуживание, сохраняющее память. В Azure все чаще используются технологии динамической миграции и вносятся улучшения в механизмы обслуживания с сохранением памяти, необходимые для уменьшения длительности приостановок.

Эти операции обслуживания, для которых не требуется перезагрузка, выполняются поочередно для каждого домена сбоя. Они прекращают работу, если получают предупреждения от средств мониторинга состояния платформы. Операции обслуживания, которые не требуют перезагрузки, могут выполняться одновременно в парных регионах или Зонах доступности. Для конкретного изменения развертывание обычно выполняется последовательно между зонами доступности и парами регионов, но на завершающем этапе возможно некоторое перекрытие.

Эти типы обновлений могут повлиять на некоторые приложения. Когда виртуальная машина динамически перемещается на другой узел, для некоторых чувствительных рабочих нагрузок может наблюдаться небольшое снижение производительности в течение нескольких минут перед приостановкой работы виртуальной машины. При подготовке к обслуживанию виртуальной машины и снижения воздействия обслуживания Azure на такие приложения будет полезно использовать запланированные события для Windows или Linux.

Для более детального контроля за всеми действиями по обслуживанию, включая обновления с нулевым влиянием и без перезагрузки, можно создать функцию конфигурации обслуживания. Создание конфигурации обслуживания дает возможность пропустить все обновления платформы и применить обновления на выбранный момент времени. Дополнительные сведения см. в разделе Управление обновлениями платформы в конфигурациях обслуживания.

Миграция в реальном времени

Динамическая миграция — это операция, которая не требует перезагрузки и сохраняет содержимое памяти виртуальной машины. Она вызывает паузу или замораживание, обычно не превышающие 5 секунд. Кроме серии G, L, N и H, все виртуальные машины инфраструктуры как услуги (IaaS) имеют право на динамическую миграцию. Большинство SKU серии M поддерживает живую миграцию. Подходящие виртуальные машины составляют более 90 процентов виртуальных машин IaaS, развернутых в парке Azure.

Платформа Azure активирует динамическую миграцию в следующих сценариях:

• Плановое техническое обслуживание
• Аппаратный сбой
• Оптимизация распределения

В некоторых сценариях планового обслуживания используется динамическая миграция. Они позволяют использовать Запланированные события, чтобы заранее получить сведения о начале операций динамической миграции.

Динамическая миграция также может использоваться для перемещения виртуальных машин, когда алгоритмы машинного обучения Azure прогнозируют сбой оборудования или оптимизацию распределения виртуальных машин. Дополнительные сведения о прогнозном моделировании, которое обнаруживает случаи понижения функциональности оборудования, см. в статье Улучшение устойчивости виртуальной машины Azure с помощью прогнозного машинного обучения и динамической миграции. Уведомления о миграции в реальном времени отображаются на портале Azure в журналах Monitor и Service Health, а также в Scheduled Events, если вы используете эти службы.

Устойчивость tcp-подключения во время динамической миграции

Приложения, поддерживающие длительные TCP-подключения, такие как серверы базы данных, брокеры сообщений и уровни кэширования, могут столкнуться с нарушением подключения во время динамической миграции. Хотя приостановка виртуальной машины обычно составляет менее 5 секунд, поведение стека TCP во время и после приостановки может расширить время восстановления на уровне приложения, если не устранено.

Как динамическая миграция влияет на TCP-подключения:

• Во время приостановки передаваемые сегменты TCP не подтверждаются мигрирующей виртуальной машиной.
• Отправляющая сторона (проба работоспособности клиента или подсистемы балансировки нагрузки) начинает повторную передачу TCP с экспоненциальной обратной передачой.
• Azure Load Balancer (цен. категория "Стандартный") отправляет TCP RST в неактивные подключения, превышающие настроенное время ожидания простоя. Однако для активных подключений с данными, находящимися в процессе передачи, балансировщик нагрузки не отправляет TCP RST во время паузы миграции. Подключение остается открытым, но не отвечает, и клиент не имеет немедленного сигнала о сбое.
• Без настройки на уровне приложения поведение повторной передачи TCP по умолчанию (tcp_retries2 = 15 в Linux) может отложить обнаружение сбоев подключения примерно на 15 минут.

Сократите область воздействия с помощью многоэкземплярных развертываний:

Прежде чем применять способы устранения рисков на уровне TCP, рассмотрите архитектурную базовую базу. Миграция в реальном времени затрагивает только одну виртуальную машину одновременно в пределах группы доступности или набора масштабирования виртуальных машин. Распределение подключений между несколькими экземплярами серверной части ограничивает влияние любого отдельного события миграции:

• Масштабируемый набор с тремя экземплярами означает, что каждое событие миграции затрагивает не более одной трети активных подключений.
• Развертывание в нескольких зонах доступности гарантирует, что миграции в разных зонах не выполняются одновременно.
• Клиенты, чьи пулы подключений распределены между несколькими серверами, восстанавливаются быстрее, поскольку незатронутые подключения сразу продолжают обслуживать запросы.

Во время приостановки виртуальной машины Azure Load Balancer (цен. категория "Стандартный") пробы работоспособности на приостановленную серверную часть также завершаются ошибкой. Подсистема балансировки нагрузки помечает серверную часть как неработоспособную в течение примерно 10 секунд (две последовательные сбои пробы по умолчанию через 5 секунд) и останавливает маршрутизацию новых подключений к нему. Это условие означает, что новые подключения естественным образом защищены. Способы устранения рисков TCP, описанные в этой статье, касались существующих подключений, которые уже были установлены до начала миграции.

Рекомендуемые меры по устранению проблем:

Следующие способы устранения рисков являются взаимодополняющими. При реализации вместе они снижают влияние события динамической миграции с минут потенциального простоя до секунд автоматического восстановления.

Мера по смягчению последствий 1: TCP_USER_TIMEOUT (наиболее быстрое обнаружение)

TCP_USER_TIMEOUT определяет, сколько времени ядро ожидает подтверждения передаваемых данных, прежде чем объявлять соединение мертвым. Если задать это значение равным 30 секундам (30000 мс) для каждого сокета, время обнаружения значительно сократится.

// 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

Особенности 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

Если TcpMaxDataRetransmissions задано значение 3, время обнаружения сокращается до приблизительно 10–20 секунд в зависимости от времени ожидания повторной передачи.

Мера по снижению риска 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. При необходимости подтвердите событие, разместив идентификатор события.

Снижение рисков 3: Настройка параметров TCP Keepalive

Проверочные пакеты 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 (цен. категория "Стандартный"), что не позволяет балансировщику нагрузки самостоятельно разрывать неактивные соединения по тайм-ауту.

Мера по снижению риска 4: логика повторных попыток на стороне клиента

Логика повторного подключения на уровне приложения и повторных попыток обеспечивает восстановление независимо от метода обнаружения сбоев:

1. Обнаружить ошибку соединения (тайм-аут, RST или отказ в соединении).
2. Закройте мертвое подключение и удалите его из пула подключений.
3. Откройте новое подключение к одному или другому узлу.
4. Повторите операцию с экспоненциальной задержкой.

Для SDK для баз данных и пулов подключений включите периодические проверки работоспособности (например, лёгкий ping-запрос каждые 10–15 секунд), чтобы заблаговременно проверять подключения.

Конфигурация пула подключений:

Для пулов соединений, поддерживающих долгоживущие соединения, полезна настройка максимального времени жизни. Этот параметр принудительно выполняет периодическое пересоздание соединений, гарантируя, что ни одно отдельное соединение не накапливает неограниченный риск в результате будущих событий миграции:

Установка максимального срока жизни в 30 минут означает, что даже без активных проверок состояния соединения естественным образом пересоздаются до того, как они успеют оставаться устаревшими в течение длительного времени без обнаружения.

Мониторинг и наблюдаемость:

Чтобы определить и оценить влияние событий динамической миграции на tcp-подключения, используйте следующие подходы:

• Метрика доступности виртуальной машины в Azure Monitor (предварительная версия): снижается до 0 во время приостановки виртуальной машины. Создайте в VmAvailabilityMetric правило генерации оповещений с пороговым значением менее 1 для обнаружения событий миграции.
• Журнал активности запланированных событий: События оперативной миграции отображаются в журнале действий для поставщика Microsoft.Compute с именем операции Microsoft.Compute/virtualMachines/liveMigration/action или как события Freeze при запросе через службу метаданных.
• Частота ошибок подключения на уровне приложения: Отслеживайте сбросы tcp-подключения, время ожидания и количество повторного подключения в метриках приложения. Пик ошибок подключения, коррелирующих с падением доступности виртуальной машины, подтверждает влияние миграции.
• Счётчики повторных передач TCP: В Linux отслеживайте поле /proc/net/netstatTCPTimeouts или используйте 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 с Конфигурациями обслуживания. Выделенные узлы позволяют контролировать выполнение обслуживания на уровне узла, устраняя неожиданные события динамической миграции.

Обслуживание, требующее перезагрузки

В редких случаях, когда виртуальные машины необходимо перезагрузить при плановом обслуживании, об этом уведомляется заранее. Плановое обслуживание выполняется в два этапа: этап самостоятельного обслуживания и этап запланированного обслуживания.

На этапе самостоятельного обслуживания, который обычно длится четыре недели, вы сами запускаете обслуживание своих виртуальных машин. В рамках самостоятельного обслуживания вы можете отправить запрос на каждую виртуальную машину, чтобы оценить ее состояние и проверить результат последнего запроса на обслуживание.

При запуске самостоятельного обслуживания виртуальная машина повторно развертывается на уже обновленном узле. Так как виртуальная машина повторно развертывается, временный диск теряется и обновляются общедоступные динамические IP-адреса, связанные с виртуальным сетевым интерфейсом.

Если во время самостоятельного обслуживания происходит ошибка, операция приостанавливается, виртуальная машина не обновляется, а вы получаете возможность повторить попытку самостоятельного обслуживания.

После завершения этапа самостоятельного обслуживания начинается этап запланированного обслуживания. В течение этого этапа вы все еще можете запрашивать период обслуживания, но вы не сможете инициировать обслуживание самостоятельно.

Дополнительные сведения по управлению обслуживанием, требующим перезагрузки, см. в статье "Обработка уведомлений о плановом обслуживании с помощью Azure CLI, PowerShell или портала".

Рекомендации по обеспечению доступности во время запланированного обслуживания

Если вы решили дождаться запланированного периода обслуживания, нужно учесть несколько факторов, чтобы обеспечить наивысшую доступность своих виртуальных машин.

Пары регионов

Каждый регион Azure образует пару с другим регионом в пределах одной географической территории. Вместе они образуют пару регионов. Во время этапа запланированного обслуживания Azure обновляет виртуальные машины только в одном регионе из пары. Например, во время обновления виртуальных машин в центрально-северной части США Azure не будет одновременно обновлять виртуальные машины в центрально-южной части США. Однако в других регионах, например в Северной Европе, обслуживание может происходить одновременно с обслуживанием в восточной части США. Чтобы лучше распределить виртуальные машины по регионам, ознакомьтесь с принципами работы пар регионов. Дополнительные сведения см. в статье Парные регионы Azure.

Зоны доступности

Зоны доступности — уникальные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения, охлаждения и сетевого взаимодействия. Чтобы обеспечить отказоустойчивость, во всех включенных регионах используются минимум три отдельные зоны.

Зона доступности — это сочетание домена сбоя и домена обновления. Если вы создаете три или более виртуальных машин в трех зонах региона Azure, виртуальные машины эффективно распределяются между тремя доменами сбоя и тремя доменами обновления. Платформа Azure поддерживает такое распределение между доменами обновления, чтобы виртуальные машины в различных зонах не обновлялись одновременно.

Каждое обновление инфраструктуры разворачивается от зоны к зоне в пределах одного региона. Одно развертывание можно выполнять в зоне 1, а другое развертывание в то же время — в зоне 2. Развертывания не всегда являются сериализованными. Однако одно развертывание, требующее перезагрузки, выполняется только в одной зоне за раз, чтобы снизить риск. Как правило, по возможности избегают обновлений, требующих перезагрузки, а Azure старается использовать оперативную миграцию или предоставить клиентам возможность управлять этим процессом.

Масштабируемые наборы виртуальных машин

Масштабируемые наборы виртуальных машин в режиме оркестрации Flexible — это вычислительный ресурс Azure, который позволяет сочетать масштабируемость масштабируемых наборов виртуальных машин в режиме оркестрации Uniform с региональными гарантиями доступности групп доступности.

С помощью гибкой оркестрации вы можете выбрать, будут ли ваши экземпляры распределены по нескольким зонам или по доменам сбоя в одном регионе.

Группы доступности и унифицированные группы масштабирования

При развертывании рабочей нагрузки на виртуальных машинах Azure вы можете создать виртуальные машины в группе доступности, чтобы обеспечить высокую доступность приложения. С помощью групп доступности можно гарантировать, что во время сбоя или события обслуживания, требующего перезагрузки, останется доступна по крайней мере одна виртуальная машина.

Отдельные виртуальные машины в группе доступности могут быть распределены между максимум 20 доменами обновления. Во время запланированного обслуживания в конкретный момент времени всегда изменяется только один домен обновления. Домены обновления не обязательно обновляются по порядку.

Масштабируемые наборы виртуальных машин в режиме универсальной оркестрации — это вычислительный ресурс Azure, который можно использовать для развертывания набора идентичных виртуальных машин и управления ими как единым ресурсом. Масштабируемый набор автоматически развертывается в доменах обновления, как и виртуальные машины в группе доступности. Как и в случае с группами доступности, при использовании масштабируемых наборов с режимом оркестрации Uniform во время планового обслуживания в любой момент времени обновляется только один домен обновления (UD).

Дополнительные сведения о настройке виртуальных машин для обеспечения высокого уровня доступности см. в статье Управление доступностью виртуальных машин Windows или соответствующей статье для Linux.

Следующие шаги

Для управления запланированным обслуживанием используйте Azure CLI, Azure PowerShell или портал.