Могут ли виртуальные машины в Google Compute определять, когда они были перенесены?

Question

Можно ли уведомить приложение, работающее на виртуальной машине Google Compute, когда виртуальная машина мигрирует на другое оборудование?

Я разработчик приложения (HMMER), которое интенсивно использует векторные инструкции (SSE/AVX/AVX-512). Версия, над которой я работаю, проверяет свое оборудование при запуске, чтобы определить, какие векторные инструкции доступны, и выбирает лучший набор.

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

Есть ли способ уведомлять приложения, работающие на виртуальной машине Google Compute, при миграции виртуальной машины? Единственная релевантная информация, которую я нашел, - это то, что вы можете настроить виртуальную машину на выполнение последовательности выключения / перезагрузки при ее переносе, что приведет к уничтожению любых выполняющихся в данный момент программ, но, по крайней мере, позволит пользователю знать, что ему необходимо перезапустить программу.

Answer 1

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

Однако для вашего случая использования вы, вероятно, захотите указать минимальную версию платформы ЦП. Вы можете использовать это, чтобы убедиться, что, например, ваш экземпляр имеет новые инструкции Skylake AVX. Для получения дополнительной информации см. Документацию " Определение минимальной платформы ЦП".

Answer 2

Согласно документам Live Migration:

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

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

Жить мигрировать

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

Когда Google Compute Engine переносит ваш экземпляр, он сообщает о системном событии, опубликованном в списке операций зоны. Вы можете просмотреть это событие, выполнив запрос ZONE - список зон gcloud compute, или просмотрев список операций в консоли Google Cloud Platform, или запрос API. Событие появится со следующим текстом:

compute.instances.migrateOnHostMaintenance

Кроме того, вы можете определить непосредственно на ВМ, когда должно произойти событие обслуживания.

Получение Live Migration Notices

Сервер метаданных предоставляет информацию об опциях и настройках планирования экземпляра через каталог планирования / и атрибут события обслуживания. Вы можете использовать эти атрибуты, чтобы узнать о параметрах планирования экземпляра виртуальной машины, и использовать эти метаданные, чтобы уведомить вас, когда событие обслуживания должно произойти через maintenance-event приписывать. По умолчанию все экземпляры виртуальной машины настроены на динамическую миграцию, поэтому сервер метаданных будет получать уведомления о событиях обслуживания до динамической миграции экземпляра виртуальной машины. Если вы выбрали прерывание экземпляра виртуальной машины во время обслуживания, то Compute Engine автоматически завершит работу и при необходимости перезапустит экземпляр виртуальной машины, если установлен атрибут automaticRestart. Чтобы узнать больше о событиях обслуживания и поведении экземпляра во время событий, прочитайте о параметрах и настройках планирования.

Вы можете узнать, когда произойдет техническое обслуживание, запросив maintenance-event приписывать периодически. Значение этого атрибута изменится за 60 секунд до начала события обслуживания, давая вашему коду приложения способ запускать любые задачи, которые вы хотите выполнить до события обслуживания, например, резервное копирование данных или обновление журналов. Compute Engine также предлагает пример скрипта Python, демонстрирующий, как проверять уведомления о событиях обслуживания.

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

Вы также можете прекратить и при необходимости перезапустить свой экземпляр.

Завершить и (необязательно) перезапустить

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

Посмотрите в разделе Настройка политик доступности для получения дополнительной информации о том, как настроить это.

Если вы используете экземпляр с графическим процессором или вытесняемым экземпляром, имейте в виду, что динамическая миграция не поддерживается:

Живая миграция и графические процессоры

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

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

Живая миграция для приоритетных экземпляров

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

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

Таким образом, когда вы указываете минимальную платформу процессора:

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