Создание рабочих нагрузок на точечных виртуальных машинах

В этой статье описаны рекомендации по созданию Azure Spot Virtual Machines. Точечные виртуальные машины (точечные виртуальные машины) обеспечивают доступ к вычислительной емкости с более низкими ценами, чем обычные виртуальные машины. Эта скидка делает их хорошим вариантом для организаций, которые хотят оптимизировать затраты. Но экономия приходит с компромиссом. Спотовые виртуальные машины могут быть вытеснены в любой момент, что означает потерю доступа к вычислительным ресурсам. Рабочие нагрузки, выполняемые на точечных виртуальных машинах, должны иметь возможность обрабатывать эти прерывания вычислений. Соответствующая рабочая нагрузка и гибкий механизм оркестрации являются ключами к успеху. В следующих рекомендациях описывается, как создать на точечных виртуальных машинах.

Общие сведения о точечных виртуальных машинах

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

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

• Нет гарантии доступности. У точечных виртуальных машин нет гарантий доступности или соглашений об уровне обслуживания (соглашения об уровне обслуживания). Точечные виртуальные машины могут немедленно лишиться доступа к вычислительным ресурсам, а также в любое время после развертывания или вытеснения. Точечные виртуальные машины дешевле, так как их можно вытеснить. Если Azure требуется обратная емкость вычислений, уведомление о вытеснения отправляется и вытесняет точечные виртуальные машины. Azure предоставляет как минимум 30-секундное уведомление заранее до фактического вытеснения. Дополнительные сведения см. в разделе Непрерывное отслеживание вытеснения.

Общие сведения о ценах на точечные виртуальные машины

Виртуальные машины Spot могут быть до 90% дешевле, чем обычные виртуальные машины с оплатой по факту использования. Скидка зависит от спроса, размера виртуальной машины, региона развертывания и операционной системы. Для оценки экономии затрат воспользуйтесь инструментом ценообразования Azure Spot Virtual Machines и обзором цен на Spot Virtual Machines. Вы также можете запросить API розничных цен Azure для программного получения цен по текущей ставке для любого SKU.

Понимание прерываемых рабочих нагрузок

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

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

Понимание вытеснения

Точечные виртуальные машины не имеют соглашения об уровне обслуживания после создания, и они могут потерять доступ к вычислительным ресурсам в любое время. Мы называем эту утрату вычислительных мощностей вытеснения. Баланс вычислительных мощностей и спроса вызывает выселения. Если спрос на определенный размер виртуальной машины превышает определенный уровень, Azure вытесняет спот виртуальные машины, чтобы сделать вычислительные мощности доступными для обычных виртуальных машин. Спрос зависит от конкретного расположения. Например, увеличение спроса в регионе A не влияет на точечные виртуальные машины в регионе B.

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

Тип вытеснения

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

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

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

Политика вытеснения

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

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

Удалить политику: Использовать политику удаления, если рабочая нагрузка может изменить расположение или размер виртуальной машины. Изменение расположения или размера виртуальной машины позволяет виртуальной машине быстрее развертываться. Политика удаления удаляет виртуальную машину и любой диск данных. Виртуальная машина не занимает вычислительные ядра в подписках на виртуальные машины. Дополнительные сведения см. в разделе политика вытеснения. При использовании политики удаления обратите внимание на использование временных дисков ОС для ваших точечных виртуальных машин. Так как виртуальная машина и ее диски удаляются при вытеснении, постоянный диск ОС несет затраты на хранилище для ресурса, который не сохраняется при вытеснении. Временные диски ОС устраняют эти расходы и сокращают время развертывания виртуальных машин, что помогает оркестрации быстрее заменять вытесненные ВМ. Эфемерные диски ОС несовместимы с политикой Stop/Deallocate, так как освобождение ресурсов уничтожает состояние диска ОС.

Проектирование гибкой оркестрации

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

Проектирование для скорости

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

Использование нескольких размеров и расположений виртуальных машин

Чтобы повысить гибкость, создайте оркестрацию для использования нескольких типов и размеров виртуальных машин. Цель — предоставить возможности оркестрации для замены вытеснённой виртуальной машины. Azure имеет разные типы и размеры виртуальных машин, которые предоставляют аналогичные возможности примерно для одной и той же цены. Отфильтруйте минимальные виртуальные ЦП или ядра, минимальную ОЗУ для виртуальных машин и максимальную цену. Этот процесс помогает найти несколько виртуальных машин, которые соответствуют бюджету и имеют достаточно мощности для выполнения рабочей нагрузки.

Каждый тип виртуальной машины имеет частоту вытеснения, выраженную как процентный диапазон, например 0%–5%, 5%–10%, 10%–15%, 15%–20%или 20+%. Ставки вытеснения могут различаться в разных регионах. Вы можете найти более высокую скорость вытеснения для одного типа виртуальной машины в другом регионе. Вы можете найти ставки выселения для каждого типа виртуальной машины на портале на вкладке Основные сведения. Рядом с Размер, выберите Просмотреть историю цен или Просмотреть все размеры. Вы также можете программно получать данные о точечных виртуальных машинах с помощью Azure Resource Graph.

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

Дополнительные сведения см. в следующих ресурсах:

• Ставки вытеснения
• графа ресурсов
• оценка размещения точки

Использование самой гибкой политики вытеснения

Политика вытеснения точечных виртуальных машин влияет на процесс их замены. Например, политика удаления является более гибкой, чем политика Stop/Deallocate.

• Сначала рассмотрите политику удаления: используйте политику удаления, если ваша рабочая нагрузка может ее выдержать. Удаление позволяет оркестрации развертывать точечные виртуальные машины замены в новых зонах и регионах. Эта гибкость развертывания может помочь рабочей нагрузке найти резервную емкость вычислительных ресурсов быстрее, чем остановленная или освобожденная виртуальная машина. Остановленные или освобожденные виртуальные машины должны ожидать свободного вычислительного потенциала в той же зоне, в которую они были созданы. Для политики удаления требуется внешний процесс для отслеживания изъятий и оркестрации развертываний в различных регионах, использования различных SKU виртуальных машин или всего этого вместе.

• Понять политику Stop/Deallocate: политика Stop/Deallocate является более жесткой, чем политика Delete. Точечные виртуальные машины должны оставаться в одном регионе и зоне. Вы не можете переместить остановленную или освобожденную виртуальную машину в другое расположение. Так как виртуальные машины имеют фиксированное расположение, вам потребуется что-то, чтобы перераспределить виртуальную машину, когда вычислительные ресурсы становятся доступными. Нет способа предсказать доступность вычислительной емкости. Поэтому вы должны использовать автоматизированный конвейер расписания для попытки повторного развертывания после вытеснения. Выселение должно активировать поток расписания, а попытки повторного развертывания должны постоянно проверять вычислительные мощности до тех пор, пока они не станут доступными.

Непрерывный мониторинг на предмет вытеснения

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

• использовать запланированные события: использовать службу запланированных событий для каждой виртуальной машины. Azure отправляет сигналы виртуальным машинам, когда обслуживание инфраструктуры повлияет на них. Вытеснения считаются обслуживанием инфраструктуры. Azure отправляет сигнал Preempt всем виртуальным машинам не менее 30 секунд до их вытеснения. Служба запланированных событий позволяет записывать этот сигнал Preempt путем запроса конечной точки на статическом, неизменяемом IP-адресе 169.254.169.254.

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

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

  • Запланированные события
  • Запланированные типы событий
  • частота запросов конечной точки

Создание системы развертывания

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

Для политики удаления рекомендуется создать конвейер, использующий разные размеры виртуальных машин и развертывающийся в разных регионах. Для политики Stop/Deallocate конвейер развертывания должен выполнять два отдельных действия. Для первоначального создания виртуальной машины пайплайн должен развернуть виртуальные машины правильного размера в нужном месте. Для выгнанной виртуальной машины конвейер должен пытаться перезапустить её до тех пор, пока она не заработает. Сочетание оповещений Azure Monitor и функций Azure — один из способов автоматизации системы развертывания. Конвейер может использовать шаблоны Bicep. Они декларативны и идемпотентны и представляют собой передовую практику развертывания инфраструктуры.

Подготовка к немедленному вытеснениям

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

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

Планирование нескольких одновременных вытеснений

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

Проектирование для плавного завершения работы

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

Тестирование оркестрации

Имитация событий освобождения для проверки оркестрации в средах разработки/тестирования. Дополнительные сведения см. в разделе Имитация вытеснения.

Проектирование идемпотентной рабочей нагрузки

Рекомендуется разработать идемпотентную рабочую нагрузку. Результат обработки события должен совпадать с результатом обработки события один раз. Вытеснения могут привести к принудительному завершению работы, несмотря на усилия по обеспечению корректного завершения работы. Принудительное завершение может остановить процессы до их завершения. Идемпотентные рабочие нагрузки могут получать одно и то же сообщение несколько раз, не изменяя результат. Дополнительные сведения см. в разделе Idempotency.

Используйте период прогрева приложения

Большинство прерванных рабочих нагрузок запускают приложения. Приложениям требуется время для установки и запуска. Кроме того, им нужно время для подключения к внешнему хранилищу и сбора информации из контрольных точек. У вас есть период прогрева приложения, прежде чем разрешить его начать обработку. В течение периода прогрева приложение должно запускаться, устанавливать подключения и готовиться к работе. Только разрешите приложению начать обработку данных после проверки работоспособности приложения.

Настройка управляемых удостоверений, назначаемых пользователями

Назначьте управляемые удостоверения, назначаемые пользователем, чтобы упростить процесс проверки подлинности и авторизации. Назначаемые пользователем управляемые удостоверения позволяют избежать размещения учетных данных в коде и не привязаны к одному ресурсу, например управляемым удостоверениям, назначаемым системой. Управляемые удостоверения, назначаемые пользователем, содержат разрешения и маркеры доступа из Microsoft Entra ID, которые можно повторно использовать и назначать для точечных виртуальных машин во время оркестрации. Согласованность токенов между точечными виртуальными машинами помогает упростить оркестрацию и доступ к ресурсам рабочей нагрузки точечных виртуальных машин.

При использовании управляемых удостоверений, назначенных системой, новая точечная виртуальная машина может получить другой токен доступа от Microsoft Entra ID. Если вам необходимо использовать управляемые удостоверения, назначаемые системой, сделайте так, чтобы рабочие нагрузки были устойчивыми к 403 Forbidden Error ответам. Ваша оркестрация должна получить токены из Microsoft Entra ID с правильными разрешениями. Для получения дополнительной информации см. Управляемые удостоверения.

Пример сценария

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

Скачать Visio-файл этой схемы.

Следующий рабочий процесс соответствует предыдущей схеме:

1. VM application definition: Определение приложения виртуальной машины создается в коллекции вычислений Azure. Он определяет имя приложения, расположение, операционную систему и метаданные. Версия приложения — это нумерованная версия определения приложения виртуальной машины. Версия приложения представляет приложение виртуальной машины. Он должен находиться в том же регионе, что и точечные виртуальные машины. Версия приложения ссылается на пакет исходного приложения в учетной записи хранения.

2. учетная запись хранения: учетная запись хранения хранит пакет исходного приложения. В этой архитектуре это сжатый tar-файл с именем worker-0.1.0.tar.gz. Он содержит два файла. Один из файлов — это скрипт orchestrate.sh bash, который устанавливает .NET-рабочее приложение.

3. Спотовые виртуальные машины: развёртываются спотовые виртуальные машины. Он должен находиться в том же регионе, что и версия приложения. Он загружает worker-0.1.0.tar.gz на виртуальную машину после развертывания. Шаблон bicep развертывает образ Ubuntu на стандартной семейной виртуальной машине. Эти конфигурации соответствуют потребностям этого приложения и не являются общими рекомендациями для приложений.

4. Storage queue: Другая служба, которая запускается в .NET worker, содержит логику очереди сообщений. Microsoft Entra ID предоставляет точечный доступ виртуальной машины к очереди хранилища в Azure Queue Storage с удостоверением, назначаемым пользователем, с помощью управления доступом на основе ролей.

5. .NET рабочее приложение: Скрипт orchestrate.sh устанавливает .NET рабочее приложение, которое выполняет две фоновые службы. Первая служба запрашивает конечную точку запланированных событий, ищет сигнал Preempt и отправляет этот сигнал второй службе. Вторая служба обрабатывает сообщения из очереди хранилища и прослушивает сигнал Preempt от первой службы. Когда вторая служба получает сигнал, она прерывает обработку очередей хранилища и начинает завершать работу.

6. Конечная точка запланированных событий запроса : запрос API отправляется в статический неуправляемый IP-адрес 169.254.169.254. Запрос API запрашивает конечную точку запланированных событий для сигналов обслуживания инфраструктуры.

7. Application Insights: архитектура использует Application Insights только для целей обучения. Это не является основным компонентом оркестрации прерываемых нагрузок, но позволяет проверить телеметрические данные из приложения-работника .NET. Приложение .NET рабочего приложения отправляет данные телеметрии в Application Insights через дистрибутив Azure Monitor OpenTelemetry. Дополнительные сведения см. в разделе Включение динамических метрик в приложении .NET.

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

Связанные ресурсы

• Архитектурные подходы для управления затратами и их распределения в мультитенантном решении
• Запуск виртуальной машины Windows на Azure
• Запуск виртуальной машины Linux на Azure