Запуск виртуальной машины Windows на Azure

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

Архитектура

Скачайте файл в формате Visio этой архитектуры.

Рабочий процесс

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

• Рабочие нагрузки на виртуальной машине не имеют прямого доступа к Интернету. Доступ ограничен ресурсами в одной виртуальной сети или одноранговой виртуальной сети, например в конфигурации концентратора и периферийной сети.

• Управление виртуальной машиной осуществляется с помощью Бастион Azure с помощью протокола Remote Desktop (RDP). Прямой доступ из общедоступного Интернета к виртуальной машине для управления отсутствует.

• Шлюз преобразования сетевых адресов (NAT) и связанный с ним общедоступный IP-адрес предоставляют исходящий внешний доступ к Интернету.

Components

Эта архитектура использует следующие компоненты.

Группа ресурсов

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

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

Виртуальная машина

Вы можете подготовить виртуальную машину из списка опубликованных образов, пользовательского управляемого образа или виртуального жесткого диска (VHD), отправленного в Хранилище BLOB-объектов Azure.

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

Выберите Azure регион, который ближе всего к вашим внутренним пользователям или клиентам. Не во всех регионах доступны виртуальные машины всех размеров. Дополнительные сведения см. в статье Географические области Azure. Чтобы получить список размеров виртуальных машин, доступных в определенном регионе, выполните следующую команду из Azure CLI:

az vm list-sizes --location <location>

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

Диски

Для оптимальной производительности входных данных диска (ввода-вывода) рекомендуется использовать диски SSD класса Premium, которые хранят данные на твердотельных накопителях (SSD). Емкость подготовленного диска определяет затраты, операции ввода-вывода в секунду и пропускную способность (скорость передачи данных). При выборе размера диска учитывайте все три фактора. Твердотельные накопители уровня «Премиум» включают бесплатную возможность кратковременного повышения производительности, что помогает справляться с пиковым спросом без избыточного резервирования ресурсов и снижает затраты на неиспользуемый объем, если учитывать характер рабочих нагрузок.

Managed disks упрощают управление дисками, управляя хранением для вас. Для управляемых дисков не требуется учетная запись хранения. Вы указываете размер и тип диска, а Azure развертывает его как ресурс с высоким уровнем доступности. Управляемые диски также снижают затраты, обеспечивая необходимую производительность без избыточного выделения ресурсов, что позволяет не платить за неиспользуемую выделенную емкость.

По умолчанию диск ОС — это управляемый диск, хранящийся в Хранилище дисков Azure, поэтому он сохраняется даже при отключении хост-компьютера. Для рабочих нагрузок без сохранения состояния, где желательны быстрое развертывание и отсутствие постоянного хранения ОС, используйте временные диски ОС. Эти диски размещают образ ОС на локальном хранилище узла виртуальной машины вместо удаленного служба хранилища Azure, что снижает задержку чтения, ускоряет повторное копирование и устраняет затраты на управляемый диск. Однако все данные на эфемерном диске ОС теряются при остановке (деактивации), переобразовании или операциях восстановления узла в ходе обслуживания. Эфемерные диски ОС не поддерживают моментальные снимки или Azure Backup. Используйте временные диски ОС только тогда, когда виртуальные машины могут быть полностью повторно развернуты с помощью автоматизации.

В зависимости от выбранного номера SKU виртуальная машина может использовать временный диск, хранящийся на физическом диске на хост-компьютере (D:диск на Windows). Временный диск не сохраняется в хранилище и может быть удален во время перезагрузки и других событий жизненного цикла виртуальной машины. Используйте временный диск только для временных данных, которые не нужно сохранять после перезагрузки, например временных файлов, создаваемых приложением, или пространства подкачки.

Windows требуется файл страницы для управления виртуальной памятью. На размерах виртуальных машин на основе небольших компьютеров (SCSI) (версии 5 и более ранних версий) образы Marketplace по умолчанию помещает файл страницы на временный диск. В размерах виртуальных машин на основе NVMe (v6 и более поздней версии) файл страницы по умолчанию используется для диска ОС, так как временные диски NVMe требуют инициализации после каждой загрузки. Для временных виртуальных машин диска ОС файл страницы также находится на диске ОС.

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

Рекомендуется создать один или несколько дисков данных для данных приложения. Диски данных — это постоянные управляемые диски, поддерживаемые хранилищем.

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

Сеть

Сетевые компоненты включают приведенные ниже ресурсы.

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

• Сетевая интерфейсная карта (NIC): Сетевая интерфейсная карта подключает виртуальную машину к виртуальной сети и обрабатывает весь входящий и исходящий трафик. Если для виртуальной машины требуется несколько сетевых адаптеров, каждый размер виртуальной машины определяет максимальное количество сетевых адаптеров.

• Общедоступный IP-адрес: Общедоступный IP-адрес можно использовать для взаимодействия с виртуальной машиной извне Azure через RDP. Однако этот вариант не рекомендуется, так как это потенциальный риск безопасности.

  Предупреждение

  Избегайте подключения общедоступного IP-адреса непосредственно к виртуальной машине. Это делается только в чрезвычайных обстоятельствах и включает другие меры безопасности, такие как использование групп безопасности сети (NSG) для фильтрации трафика. Для управления доступом к виртуальной машине используйте Бастион Azure или частное подключение через VPN или Azure ExpressRoute.

  • Общедоступный IP-адрес может быть динамическим или статическим. По умолчанию используется динамический. Зарезервировать статический IP-адрес , если требуется фиксированный IP-адрес, который не изменяется, например, если необходимо создать запись DNS "A" или добавить IP-адрес в безопасный список.

  • Можно также создать полное доменное имя для IP-адреса. Затем вы сможете зарегистрировать в DNS запись CNAME, которая указывает на полное доменное имя. Дополнительные сведения см. в разделе Создание полностью квалифицированного доменного имени в портале Azure.

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

  Все NSG содержат набор правил безопасности по умолчанию, в том числе правило, блокирующее весь входящий интернет-трафик. Вы не можете удалить правила по умолчанию, но их можно переопределить другими правилами. Например, можно создать правила, разрешающие входящий интернет-трафик к определенным портам, таким как порт 443 для HTTPS.

• Шлюз трансляции сетевых адресов Azure (NAT):Azure NAT Gateway позволяет всем экземплярам в закрытой подсети устанавливать исходящие подключения к Интернету, оставаясь при этом полностью закрытыми. Только пакеты, поступающие в качестве пакетов ответа для исходящего подключения, могут передаваться через шлюз NAT. Несанкционированные входящие соединения из Интернета не разрешены.

• Бастион Azure:Бастион Azure — это полностью управляемая платформа как услуга (PaaS), которая обеспечивает безопасный доступ к виртуальным машинам через частные IP-адреса. В этой конфигурации виртуальные машины не нуждаются в публичном IP-адресе, который делает их доступными в интернете, что повышает уровень их безопасности. Бастион Azure обеспечивает безопасное подключение RDP или SSH к виртуальным машинам с помощью различных методов, включая портал Azure или собственные клиенты SSH или RDP.

Операции

В этом разделе рассматриваются основные операционные методики управления виртуальной машиной Windows в Azure.

• Диагностики: Включите мониторинг и диагностику, включая базовые метрики работоспособности, журналы инфраструктуры диагностики и диагностику загрузки. Средства диагностики загрузки помогают выявить сбой при загрузке, если виртуальная машина оказывается в незагружаемом состоянии. Храните журналы диагностики в учетной записи хранения. Для журналов диагностики достаточно стандартной учетной записи хранилища с локальной избыточностью (LRS). Дополнительные сведения см. в рекомендациях по мониторингу и диагностике.

• Доступность:плановое обслуживание или незапланированное время простоя могут повлиять на виртуальную машину. Журналы перезагрузки виртуальной машины можно использовать для определения причин запланированного обслуживания перезагрузки виртуальной машины. Для повышения доступности разверните несколько виртуальных машин в зонах доступности в пределах региона. Это развертывание обеспечивает более высокое соглашение об уровне обслуживания (SLA). Если зоны доступности не поддерживаются, группы доступности могут помочь обеспечить защиту от сбоев узлов или обновлений узлов. Однако зоны доступности — это рекомендуемый вариант, когда это возможно.

• Резервные копии: Чтобы защититься от случайной потери данных, используйте службу Azure Backup для резервного копирования виртуальных машин в хранилище. В зависимости от региона для резервного копирования можно использовать хранилище с географической избыточностью или хранилище с зональной избыточностью. Служба Azure Backup предоставляет резервные копии с согласованностью на уровне приложений. Для нагрузок, критичных к производительности, используйте функцию безагентного согласованного при сбое резервного копирования для нескольких дисков вместо службы теневого копирования томов (VSS), чтобы автоматизировать защиту резервным копированием без влияния на производительность приложений.

• Остановка виртуальной машины: Azure делает различие между остановленными и освобожденными состояниями. Плата взимается при остановке состояния виртуальной машины, но не при освобождении виртуальной машины. На портале Azure кнопка Stop освобождает виртуальную машину. Если вы выключаете через ОС, оставаясь в системе, ВМ останавливается, но не деаллоцируется, поэтому вы всё равно платите.

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

Alternatives

• Azure Virtual Machine Scale Sets позволяет создавать группу экземпляров виртуальных машин с балансировкой нагрузки и управлять ими. Рабочие нагрузки, критически важные для бизнес-операций, никогда не должны зависеть от одной виртуальной машины. Масштабируемые наборы виртуальных машин обеспечивают возможность распределения рабочих нагрузок по узлам. Экземпляры виртуальных машин можно автоматически добавлять или удалять в зависимости от нагрузки; при росте трафика систему можно масштабировать, а при его снижении — сокращать количество экземпляров, чтобы минимизировать затраты.

• Azure Load Balancer распределяет трафик между несколькими виртуальными машинами или масштабируемым набором виртуальных машин. Он также можно использовать в качестве альтернативы шлюзу NAT, чтобы разрешить доступ к рабочей нагрузке из Интернета, а также поддерживать исходящий доступ.

• Шлюз приложений — это альтернативный вариант балансировки нагрузки уровня 7 для трафика HTTP/HTTPS, который обычно развертывается перед несколькими виртуальными машинами или масштабируемым набором виртуальных машин в Azure регионе.

• Сведения о развертывании корпоративного уровня см. в статье Базовая архитектура Виртуальные машины Azure в целевой зоне Azure.

Подробности сценария

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

Потенциальные варианты использования

Эта архитектура подходит для простого приложения, которое не требует публичного доступа из интернета и допускает периодические простои. Базовый внутренний инструмент отчетности — это типичный вариант использования.

Рекомендации

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

Reliability

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

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

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

Высокая доступность и аварийное восстановление (HA/DR)

Чтобы уменьшить область влияния сбоя и повысить отказоустойчивость, разверните рабочую нагрузку в нескольких регионах и используйте рекомендации Azure Landing Zone. Это развертывание может быть выполнено в активно-пассивной конфигурации с переключением на вторичный регион при недоступности основного региона или в архитектуре «активный-активный», где оба региона обслуживают трафик потребителей.

Например, см. Многоуровневое веб-приложение, разработанное для обеспечения высокой доступности и аварийного восстановления. В этом примере используется Azure Site Recovery для репликации дисков отдельных виртуальных машин в дополнительный регион. Вы можете использовать Site Recovery, чтобы переключить эти виртуальные машины во вторичный регион при аварии, обеспечив низкие значения целевой точки восстановления (RPO) и целевого времени восстановления (RTO).

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

Безопасность

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

При разработке архитектуры учитывайте следующие моменты:

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

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

  • Защита от вредоносных программ: При включении Defender для облака проверяет, установлено ли программное обеспечение защиты от вредоносных программ. Вы также можете использовать Defender для облака для установки программного обеспечения защиты от вредоносных программ непосредственно на портале Azure.

• Используйте Azure управление доступом на основе ролей (Azure RBAC) для управления доступом к ресурсам Azure. С помощью Azure RBAC вы предоставляете пользователям только необходимые им разрешения. Например, роль "Читатель" может просматривать ресурсы Azure, но не может создавать, изменять или удалять их. Некоторые разрешения относятся к типу ресурса Azure. Например, роль участника виртуальной машины может перезапустить или отменить размещение виртуальной машины, сбросить пароль администратора и создать новую виртуальную машину. Другие встроенные роли , которые могут быть полезны для этой архитектуры, включают пользователя DevTest Labs и участника сети.

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

• Включите шифрование на узле для обеспечения сквозного шифрования данных виртуальной машины, включая временные диски и кэши дисков. Шифрование на узле обрабатывает шифрование в инфраструктуре узла виртуальной машины и не использует ресурсы ЦП виртуальной машины, в отличие от гостевого шифрования. Вы можете использовать ключи, управляемые клиентом, с Azure Key Vault для постоянных операционных систем и дисков данных. Временные диски и временные диски ОС шифруются с помощью ключей, управляемых платформой. Убедитесь, что выбранный размер VM поддерживает шифрование на узле перед подготовкой виртуальной машины.

Оптимизация затрат

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

Существуют различные варианты размеров виртуальных машин в зависимости от использования и рабочей нагрузки. Диапазон включает самый экономичный вариант серии Bs до новейших виртуальных машин GPU, оптимизированных для machine learning. Сведения о доступных вариантах см. в разделе цен на виртуальные машины Azure Windows.

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

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

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

Для оценки затрат используйте калькулятор цен Azure.

Операционное превосходство

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

Используйте шаблоны IaC для развертывания ресурсов Azure и их зависимостей. Эти шаблоны можно написать с помощью Bicep, Azure Resource Manager или Terraform. Эти шаблоны можно использовать как часть конвейера непрерывной интеграции и непрерывного развертывания (CI/CD) с помощью автоматического развертывания. Этот подход обеспечивает управление версиями архитектуры, обеспечивает согласованность между средами и обеспечивает воспроизводимость, безопасность и соответствие требованиям.

Чтобы отслеживать и диагностировать проблемы, включите журналы диагностики ресурсов и отправьте их в Azure Monitor для анализа и оптимизации. Эти журналы можно использовать для реализации оповещений и уведомлений о критических событиях. В некоторых случаях они могут разрешить автоматическое исправление или ведение журнала билетов в системе УПРАВЛЕНИЯ ИТ-службами (ITSM).

Эффективность работы

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

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

При разработке архитектуры учитывайте следующие моменты:

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

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

• Если ваша рабочая нагрузка особенно чувствительна к задержкам, используйте группы размещения по близости (PPG), чтобы обеспечить физическое расположение нескольких виртуальных машин близко друг к другу для повышения производительности. Вы также можете использовать PPG вместе с группами доступности, чтобы обеспечить низкую задержку и высокую доступность в пределах одного физического центра обработки данных.

• По возможности включите ускоренную сеть, чтобы свести к минимуму задержку между компонентами.

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

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

Contributors

Корпорация Майкрософт поддерживает эту статью. Первоначальными авторами статьи были следующие лица.

Основной автор:

• Донни Трамповер | Старший архитектор облачных решений и решений ИИ

Чтобы увидеть непубличные профили в LinkedIn, войдите в LinkedIn.

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

• Краткое руководство. Создание виртуальной машины Windows на портале Azure
• Установка драйверов GPU NVIDIA на виртуальных машинах серии N под управлением Windows
• Установка драйверов GPU AMD на виртуальные машины серии N под управлением Windows
• Создание виртуальных машин Windows и управление ими с помощью Azure PowerShell
• Стандартный исходящий доступ в Azure

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

• Запуск виртуальной машины Linux в Azure
• Разработка плана развертывания для обновления виртуальных машин Windows в Azure
• базовая архитектура Виртуальные машины в целевой зоне Azure
• Многоуровневое веб-приложение, созданное для HA/DR