Обслуживание облачного хоста и живая миграция Cloud host maintenance / live migration
ID причины nic-host-maintenance · Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка сервера, Внешние стороны · Внешние стороны
Во время обслуживания физического сервера (хоста) облачный провайдер переносит виртуальную машину на другой хост (живая миграция) или ненадолго её приостанавливает. На это время замирает весь сервер, а если пауза долгая, соединения рвутся.
Почему Из-за обслуживания хоста или прогноза отказа провайдер переносит виртуальную машину на другой хост или ненадолго приостанавливает её → Следствие Во время переноса CPU, память и сеть работают медленнее, а в конце виртуальная машина ненадолго полностью останавливается (в зависимости от провайдера и способа от меньше 1 с до примерно 30 с) → На экране Фриз у всех на сервере одновременно, затем перемотка и телепортация, а если остановка дольше таймаута, массовые дисконнекты
Основной ответственный Команда инфраструктуры · Серверная инфраструктура · Совместно Команда разработки · Разработка сервера, Внешние стороны · Внешние стороны
Команда разработки: задачи
Таймауты, которые переживают остановку на несколько секунд, ограничение числа догоняющих тиков после остановки, расчёт прошедшего времени по монотонным часам (monotonic clock), процедура, которая по уведомлению об обслуживании сохраняет прогресс и переводит игроков на другой сервер.
Команда инфраструктуры: задачи
Подписаться на уведомления об обслуживании и поставить алерты (Google Cloud maintenance-event, запланированные события AWS и AWS Health, Azure Scheduled Events), получив уведомление, заранее заменить сервер в часы с малым онлайном, если провайдер позволяет, сдвинуть время обслуживания (Azure Maintenance Configuration, для некоторых типов запланированные события AWS), сверять журнал обслуживания с журналом инцидентов.
Внешние стороны: задачи
Уточнить у облачного провайдера график обслуживания и масштаб влияния, если на одном инстансе остановки повторяются, сообщить провайдеру.
Цифры для ориентира
По словам Google Compute Engine, остановка при живой миграции обычно намного короче 1 с, а системные часы за время остановки могут прыгнуть вперёд до 5 с. Значение maintenance-event в метаданных меняется за 60 с до переноса (если до этого его хотя бы раз запрашивали). У Azure при обслуживании без перезагрузки остановка почти всегда короче 10 с, изредка (для обычных размеров не чаще раза в 18 месяцев) около 30 с, а живая миграция обычно не дольше 5 с. Azure Scheduled Events предупреждает о такой остановке (Freeze) минимум за 15 мин. Но если оборудование хоста внезапно отказывает, восстановление начинается сразу, без предупреждения.
На графике
Провал, затем пачка · пакеты сервера на приём и отправку, интервал тика
Где смотреть
Сверить момент остановки с записями провайдера. В Google Cloud это compute.instances.migrateOnHostMaintenance в журнале аудита, в AWS запланированные события в describe-instance-status и AWS Health, в Azure Microsoft.Compute/virtualMachines/liveMigration/action в журнале действий (Activity Log) и момент, когда метрика доступности VM (VmAvailabilityMetric) упала до 0. Внутри сервера посмотреть, есть ли пробел в метриках и логах на время остановки и прыгнули ли часы сразу после неё (журнал синхронизации времени)
Подтверждает
Момент остановки всего сервера совпадает с записанным у провайдера временем обслуживания или миграции, и на эти несколько секунд все метрики и логи внутри сервера пустые
Опровергает
Если в записях провайдера ничего нет, а короткие остановки часто повторяются, это «CPU steal (виртуальная машина)». Если в логе ядра есть записи о сбросе NIC, это «Проблемы драйвера и прошивки NIC»
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
AWS предупреждает об обслуживании через запланированные события (scheduled events). system-reboot означает перезагрузку с переносом на новый хост, system-maintenance означает, что обслуживание сети или питания может ненадолго повлиять на инстанс. Даже если остановка длится несколько секунд, клиенты, не получившие за это время ACK на отправленные серверу пакеты, удваивают ожидание перед каждым повтором, поэтому TCP-соединение может оставаться замершим и после того, как сервер оживёт (см. причину «TCP RTO и экспоненциальный backoff»). После пробуждения часы прыгают (см. причину «Скачок системных часов (шаговая коррекция NTP)»), а health check балансировщика может не пройти, и сервер ненадолго исключат из балансировки. Инстансы, которые нельзя перенести (например, bare metal в Google Cloud), при обслуживании останавливаются или перезапускаются.
Источники
Live migration process during maintenance eventsGoogle Cloud Остановка при живой миграции обычно намного короче 1 с, за время остановки системные часы прыгают вперёд до 5 с, во время переноса ненадолго падает производительность диска, CPU, памяти и сети, VM без живой миграции при обслуживании выключаются (bare metal её не поддерживает)
Query metadata server for maintenance event noticesGoogle Cloud Значение метаданных maintenance-event меняется за 60 с до живой миграции (если VM настроена на живую миграцию и после прошлого обслуживания это значение хотя бы раз запрашивали)
Scheduled events for Amazon EC2 instancesAWS Типы запланированных событий (system-reboot: перезагрузка с переносом на новый хост, system-maintenance: кратковременное влияние из-за обслуживания сети или питания), уведомления по почте и через AWS Health, проверка через describe-instance-status, для некоторых типов время можно сдвинуть
Maintenance and updatesMicrosoft Azure Обслуживание без перезагрузки почти всегда останавливает VM меньше чем на 10 с, изредка (для обычных размеров не чаще раза в 18 месяцев) примерно на 30 с, живая миграция обычно не дольше 5 с, после остановки часы синхронизируются автоматически, долгие TCP-соединения могут рваться, а данные, отправленные остановленной VM, другая сторона повторяет с экспоненциальным backoff, и восстановление затягивается, health check балансировщика примерно за 10 с признаёт VM неисправной, проверка по Microsoft.Compute/virtualMachines/liveMigration/action в журнале действий и по VmAvailabilityMetric, которая на время остановки падает до 0, время применения выбирается через Maintenance Configuration
Scheduled Events for Linux VMs in AzureMicrosoft Azure О Freeze (остановка на несколько секунд, CPU и сеть могут замереть) предупреждают минимум за 15 мин, при отказе оборудования хоста восстановление начинается сразу, без периода уведомления