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

Azure Backup

Бастион Azure

хранилище BLOB-объектов Azure

Azure Resource Manager

Хранилище Azure

Виртуальные машины Azure

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

Архитектура

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

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

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

Рабочие нагрузки на виртуальной машине не имеют прямого доступа к Интернету. Доступ ограничен ресурсами в одной виртуальной сети или одноранговой виртуальной сети, например в конфигурации концентратора и периферийной сети.
Вы управляете виртуальной машиной с помощью Бастион Azure через Secure Shell (SSH). Прямой доступ из общедоступного Интернета к виртуальной машине для управления отсутствует.
Шлюз преобразования сетевых адресов (NAT) и связанный с ним общедоступный IP-адрес предоставляют исходящий внешний доступ к Интернету.

Components

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

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

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

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

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

Вы можете подготовить виртуальную машину из списка опубликованных образов, пользовательского управляемого образа или виртуального жесткого диска (VHD), отправленного в Хранилище BLOB-объектов Azure. Azure поддерживает популярные дистрибутивы Linux, включая Debian, Red Hat Enterprise Linux (RHEL) и Ubuntu. Дополнительные сведения см. в разделе "Утвержденные дистрибутивы Linux".

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

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

az vm list-sizes --location <location>

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

Диски

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

Примечание.

Диски SSD уровня "Премиум" версии 2 и "Ультра" можно использовать только для дисков данных. Они не поддерживаются для дисков операционной системы (ОС).

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

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

По умолчанию во многих образах Linux пространство подкачки не настраивается. Если для рабочей нагрузки требуется переключение, создайте его на временном диске с помощью cloud-init , а не на диске ОС или на диске данных.

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

При создании диска он неформатирован. Войдите на виртуальную машину, чтобы отформатировать диск. В оболочке Linux диски данных отображаются как /dev/sdc/dev/sddи более поздние буквы в серии. Можно выполнить lsblk , чтобы вывести список блочных устройств, включая диски. Чтобы использовать диск данных, создайте раздел и файловую систему, а затем подключите этот диск. Например:

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

При добавлении диска данных ему назначается идентификатор логического номера устройства (LUN ID). Можно также указать идентификатор LUN, если, например, вы заменяете диск и хотите сохранить тот же идентификатор LUN, или у вас есть приложение, которое ищет конкретный идентификатор LUN. Однако идентификаторы LUN должны быть уникальными для каждого диска.

Для дисков хранилища уровня Premium может потребоваться сменить планировщик ввода-вывода, чтобы оптимизировать производительность SSD. Обычно рекомендуется использовать планировщик задач NOOP для SSD, но для вашей рабочей нагрузки следует использовать такие инструменты, как iostat, чтобы отслеживать производительность ввода-вывода на диске.

Многие виртуальные машины создаются с временным диском, который хранится на физическом диске на хост-компьютере. Он не сохраняется в хранилище и может быть удален во время перезагрузки и других событий жизненного цикла виртуальной машины. Используйте этот диск только для временных данных, таких как данные страниц или файлы подкачки. Для виртуальных машин Linux временный диск /dev/disk/azure/resource-part1 монтируется в /mnt/resource или /mnt.

Сеть

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

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

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

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

Для управления доступом к виртуальной машине используйте Бастион Azure для доступа К SSH на основе браузера или частного подключения через VPN или Azure ExpressRoute.
- Общедоступный IP-адрес может быть динамическим или статическим. По умолчанию используется динамический. Зарезервировать статический IP-адрес , если требуется фиксированный IP-адрес, который не изменяется, например, если необходимо создать запись DNS "A" или добавить IP-адрес в безопасный список.
- Можно также создать полное доменное имя для IP-адреса. Затем вы сможете зарегистрировать в DNS запись CNAME, которая указывает на полное доменное имя. Дополнительные сведения см. в статье "Создание полного доменного имени для виртуальной машины".
NSG: Используйте группы безопасности сети, чтобы разрешать или запрещать сетевой трафик к виртуальным машинам и подсетям. Свяжите их с подсетями или отдельными сетевыми адаптерами, подключенными к виртуальным машинам.

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

Примечание.

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

Операции

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

SSH: Перед созданием виртуальной машины Linux создайте пару открытого закрытого ключа RSA с 2048-разрядной версией. При создании виртуальной машины используйте файл открытого ключа. Дополнительные сведения см. в статье «Создание и использование пары открытого и закрытого ключей SSH».
Диагностики: Включите мониторинг и диагностику, включая базовые метрики работоспособности, журналы инфраструктуры диагностики и диагностику загрузки. Средства диагностики загрузки помогают выявить сбой при загрузке, если виртуальная машина оказывается в незагружаемом состоянии. Храните журналы диагностики в учетной записи хранения. Для журналов диагностики достаточно стандартной учетной записи хранилища с локальной избыточностью (LRS). Дополнительные сведения см. в рекомендациях по мониторингу и диагностике.
Доступность:плановое обслуживание или незапланированное время простоя могут повлиять на виртуальную машину. Журналы перезагрузки виртуальной машины можно использовать для определения причин запланированного обслуживания перезагрузки виртуальной машины. Для повышения доступности разверните несколько виртуальных машин в зонах доступности в пределах региона. Это развертывание обеспечивает более высокое соглашение об уровне обслуживания (SLA). Если зоны доступности не поддерживаются, группы доступности могут помочь обеспечить защиту от сбоев узлов или обновлений узлов. Однако зоны доступности — это рекомендуемый вариант, когда это возможно.
Резервные копии: Чтобы защититься от случайной потери данных, используйте службу Azure Backup для резервного копирования виртуальных машин в хранилище. В зависимости от региона для резервного копирования можно использовать хранилище с географической избыточностью или хранилище с зональной избыточностью. Служба Azure Backup предоставляет резервные копии с согласованностью на уровне приложений. Для рабочих нагрузок, чувствительных к производительности, и специализированных дистрибутивов Linux, которые не поддерживают традиционные агенты резервного копирования, используйте функцию безагентного согласованного после сбоя резервного копирования нескольких дисков, чтобы автоматизировать защиту с помощью резервного копирования без влияния на производительность приложений.
Остановка виртуальной машины: Azure делает различие между остановленными и освобожденными состояниями. Плата взимается при остановке состояния виртуальной машины, но не при освобождении виртуальной машины. На портале Azure кнопка Stop освобождает виртуальную машину. Если вы завершите работу виртуальной машины через ОС во время входа, виртуальная машина остановлена, но не освобождена, поэтому вы по-прежнему платите.
Удаление виртуальной машины: При удалении виртуальной машины можно удалить или сохранить его диски, что позволяет сохранить данные. Однако вы по-прежнему оплачиваете диски. Управляемые диски можно удалить, как любой другой Azure ресурс. Чтобы предотвратить случайное удаление, используйте блокировку ресурсов. Так вы сможете заблокировать всю группу или отдельные ресурсы (например, виртуальную машину).

Alternatives

Azure Virtual Machine Scale Sets обеспечивают возможность распределения рабочих нагрузок по узлам. Рабочие нагрузки, критически важные для бизнес-операций, никогда не должны зависеть от одной виртуальной машины. Вы можете автоматически добавлять или удалять экземпляры виртуальных машин в зависимости от нагрузки, а также увеличивать их количество при росте трафика или уменьшать его при снижении трафика, чтобы минимизировать затраты.
Azure Load Balancer распределяет трафик между несколькими виртуальными машинами или масштабируемым набором виртуальных машин. Он также можно использовать в качестве альтернативы шлюзу NAT, чтобы разрешить доступ к рабочей нагрузке из Интернета, а также поддерживать исходящий доступ.
Шлюз приложений предоставляет Azure Load Balancer возможности балансировки нагрузки для рабочих нагрузок 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).

Обязательно оцените архитектуру на предмет соответствия требованиям HA/DR (высокой доступности и аварийного восстановления) для всех компонентов, а не только для виртуальных машин. Во всех этих решениях следует учитывать такие аспекты, как сеть, удостоверение и данные.

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

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

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

Используйте Microsoft Defender для облака для получения центрального представления о состоянии безопасности Azure ресурсов. Defender для облака отслеживает потенциальные проблемы безопасности и предоставляет исчерпывающую картину работоспособности развертывания. Настройте Defender для облака для каждой подписки Azure и включите сбор данных безопасности. Defender для облака автоматически сканирует виртуальные машины, созданные в этой подписке.
- Управление исправлениями: Если этот параметр включен, Defender для облака идентифицирует отсутствующие обновления безопасности и критически важные обновления.
- Защита от вредоносных программ: При включении Defender для облака проверяет, установлено ли программное обеспечение защиты от вредоносных программ. Вы также можете использовать Defender для облака для установки программного обеспечения защиты от вредоносных программ непосредственно на портале Azure.
Используйте Azure управление доступом на основе ролей (Azure RBAC) для управления доступом к ресурсам Azure. С помощью Azure RBAC вы предоставляете пользователям только необходимые им разрешения. Например, роль «Читатель» может просматривать ресурсы Azure, но не может создавать, изменять или удалять их. Некоторые разрешения относятся к типу ресурса Azure. Например, роль участника виртуальной машины может перезапустить или отменить размещение виртуальной машины, сбросить пароль администратора и создать новую виртуальную машину. Другие встроенные роли , которые могут быть полезны для этой архитектуры, включают пользователя DevTest Labs и участника сети.

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Чтобы отслеживать и диагностировать проблемы, включите журналы диагностики ресурсов и отправьте их в Azure Monitor для анализа и оптимизации. Эти журналы можно использовать для реализации оповещений и уведомлений о критических событиях, а в некоторых случаях — автоматическое исправление или ведение журнала билетов в системе управления ИТ-службами (ITSM).

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

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

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