Microsoft AZ-104: Виртуальные машины Azure и вычислительные ресурсы — Руководство по подготовке

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Часть Microsoft Azure Administrator Associate AZ-104 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

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

Варианты вычислений и размеры

Семейства размеров VM нацелены на различные профили рабочих нагрузок. Общего назначения (Dv, Ev, B-series с возможностью увеличения производительности) обеспечивают сбалансированное соотношение vCPU к памяти для веб-серверов, небольших баз данных и серверов приложений. Оптимизированные для вычислений (Fsv2, HB/HBv2 для высокопроизводительных вычислений, ограниченных CPU) максимизируют количество vCPU на ГБ и настроены на высокую тактовую частоту, что выгодно для stateless API, пакетных обработчиков и игровых серверов. Оптимизированные для памяти (Ev5, Mv2/Mv3) предлагают больше памяти на vCPU и поддерживают кэши в памяти, аналитические движки и большие базы данных. VM с GPU (NV, NVv4 для визуализации; NC/ND для обучения и инференса CUDA/AI) включают графические процессоры NVIDIA с разделением vGPU на некоторых SKU для повышения плотности и экономической эффективности; совместимость драйверов и фреймворков следует проверять и закреплять с помощью расширений.

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

Azure Dedicated Hosts размещают ваши VM на физических серверах для одного клиента для изоляции на уровне узла, соответствия требованиям и предсказуемости. Группы узлов определяют коллекцию узлов в регионе и могут охватывать зоны доступности и домены сбоя узлов для распределения рисков сбоя узла и обслуживания. Домены сбоя узлов в группе узлов гарантируют, что VM распределены по разным физическим стойкам. Преимущества лицензирования включают перенос лицензий Windows Server/SQL Server с Software Assurance или использование Azure Hybrid Benefit, а также возможность лицензирования на уровне узла (полезно для SQL Enterprise/Windows Datacenter), а не для каждой VM, что потенциально снижает затраты при плотной консолидации.

Доступность, масштабирование и оптимизация затрат

Группы доступности (Availability sets) защищают от сбоев оборудования и планового обслуживания в пределах одного центра обработки данных. VM распределяются по доменам сбоя (отдельное питание/стойка) и доменам обновления (волны обслуживания). Типичные ограничения — до 3 доменов сбоя и 20 доменов обновления; разверните как минимум два экземпляра, чтобы получить SLA 99,95%. Зоны доступности (Availability zones) обеспечивают более высокую отказоустойчивость за счет размещения ресурсов в физически разделенных зданиях ЦОД в пределах одного региона; развертывание двух или более VM в разных зонах обеспечивает SLA для VM на уровне 99,99%. Зоны требуют ресурсов, поддерживающих зоны, а межзоновый трафик использует балансировщик нагрузки или шлюз приложений SKU Standard; планируйте затраты на исходящий трафик данных в пределах региона.

Масштабируемые наборы виртуальных машин (Virtual Machine Scale Sets, VMSS) управляют парком идентичных или гетерогенных VM с интегрированным автомасштабированием и управлением работоспособностью. Единая оркестрация (Uniform orchestration) использует модель масштабируемого набора с единым профилем VM и нативно интегрируется с Azure Load Balancer или Application Gateway. Гибкая оркестрация (Flexible orchestration) поддерживает различные SKU VM и индивидуальность экземпляров, сочетается с группами/зонами доступности и подходит для stateful-приложений или смешанных ролей. Режимы обновления определяют поведение при развертывании: ручной (Manual) (администратор запускает обновления), автоматический (Automatic) (платформа обновляет все экземпляры при изменении модели) и последовательный (Rolling) (обновление пакетами с пробами работоспособности, паузой между пакетами и порогами сбоя). Политики автомасштабирования реагируют на метрики (CPU, память через AMA, длина очереди, пользовательские метрики), расписания или и то, и другое; определите минимальную/максимальную/желаемую емкость, периоды ожидания (cooldowns) и политики сжатия (scale-in) (например, сначала самая новая VM), чтобы контролировать текучесть. Для входящего управления в масштабе используйте пулы входящих NAT-правил (inbound NAT pools) на публичном или внутреннем Standard Load Balancer. Пробы работоспособности должны быть нацелены на фактический порт и протокол службы; для SQL Always On с внутренним балансировщиком нагрузки используйте пробу TCP на порту прослушивателя, а не HTTP.

Спотовые VM Azure (Azure Spot VMs) используют незадействованные мощности Azure со значительными скидками, но без гарантий доступности. Вытеснение (eviction) происходит, когда емкость требуется обратно или рыночная цена превышает вашу максимальную цену; можно установить политику вытеснения: освободить (Deallocate) (сохранить диск для последующего перезапуска, когда ресурсы станут доступны) или удалить (Delete) (полностью удалить при вытеснении). Они интегрируются с VMSS и Standard Load Balancer для масштабирования stateless-приложений. Подходящие сценарии использования включают пакетную обработку, исполнители CI/CD, рендеринг, фаззинг и крупные stateless-веб-фермы, которые могут переносить прерывания. Избегайте использования Spot для производственных сред с одним экземпляром или для stateful-уровней без механизма контрольных точек. Ограничения цены не позволяют платить больше вашего порога; при всплесках спроса ожидайте более высоких показателей вытеснения.

Практическое применение конструкций доступности и SLA

Выбирайте группы доступности, когда вам нужна избыточность в пределах одного центра обработки данных с общими серверными хранилищами и не требуется размещение по зонам. Выбирайте зоны доступности для критически важных сервисов, требующих изоляции от сбоев на уровне здания и более высокого SLA. Для горизонтально масштабируемых сервисов объединяйте VMSS с зонами для равномерного распределения и автоматического восстановления; привязывайте пробы работоспособности к портам рабочей нагрузки и используйте последовательные обновления для снижения рисков. Помните, что отдельные ВМ, даже с Premium SSD, предлагают более низкий SLA, чем развертывания с несколькими экземплярами. Для чувствительных к стоимости уровней без сохранения состояния (stateless) включите пул спотовых ВМ за Standard Load Balancer и установите консервативные политики вытеснения и горизонтального сжатия для защиты базовой емкости.

Практический сценарий

Компания Contoso Ltd. использует многоуровневое веб-приложение с API без сохранения состояния (stateless), кэшем Redis с сохранением состояния (stateful) и группой доступности SQL Server Always On. Им необходимо повысить устойчивость к сбоям на уровне зон, сократить затраты на вычисления для уровня API, обеспечить безопасный административный доступ без публичных IP-адресов и стандартизировать мониторинг и резервное копирование.

Создайте три подсети в топологии «звезда» (hub-spoke): общую подсеть управления (hub), подсеть для веб-серверов/API (spoke) и подсеть данных (spoke). Разверните Azure Bastion Standard в подсети AzureBastionSubnet (/26) в центральной сети (hub) со стандартным публичным IP-адресом. Обоснование: Bastion позволяет выполнять подключения по RDP/SSH через TLS, не открывая публичные IP-адреса на какой-либо ВМ, а SKU Standard поддерживает подключения на основе IP-адресов между пиринговыми виртуальными сетями, централизуя административный доступ.
Разверните уровень API в виде VM Scale Set (режим Uniform) в зонах доступности 1, 2 и 3 со Standard Load Balancer. Включите ускоренную сеть (accelerated networking) и настройте правила автомасштабирования для добавления экземпляров при средней загрузке ЦП > 65% в течение 10 минут и удаления при < 35% с периодом охлаждения (cooldown). Добавьте вторичный пул спотовых ВМ в тот же масштабируемый набор, используя режим Flexible orchestration, или в виде сопутствующего масштабируемого набора, настроив максимальную цену и политику вытеснения Deallocate. Обоснование: VMSS в сочетании с зонами обеспечивает SLA 99,99% и автоматическое восстановление; спотовые мощности сокращают затраты при пиковых нагрузках, а политика Deallocate сохраняет диски для быстрого повторного использования.
Разверните ВМ для кэша Redis в группе доступности с 2+ экземплярами и Premium SSD. Задайте 2 домена сбоя (fault domains) и положитесь на 20 доменов обновления (update domains) платформы. Обоснование: Кэш имеет состояние, но может реплицироваться; группы доступности обеспечивают изоляцию на уровне стоек и обслуживания без задержек, характерных для межзонного взаимодействия.
Разверните по две ВМ с SQL Server в каждой зоне (зоны 1 и 2), участвующие в группе доступности Always On. Разместите их на выделенных узлах Azure (Azure Dedicated Hosts) в группе узлов, охватывающей две зоны и два домена сбоя узлов. Настройте внутренний Standard Load Balancer с TCP-пробой на порту прослушивателя (например, 1433) для прослушивателя группы доступности (AG listener). Обоснование: Dedicated Hosts обеспечивают изоляцию на уровне физического узла и эффективность лицензирования (лицензирование SQL на узел), а размещение по зонам и пробы работоспособности по TCP соответствуют требованиям прослушивателя SQL.
Стандартизируйте образы с помощью Azure Compute Gallery, содержащей защищенные (hardened) образы ОС. Используйте расширение Custom Script Extension для установки необходимых компонентов приложения и расширение DSC для принудительного применения состояния компонентов Windows и базовых конфигураций реестра. Обоснование: Образы из Gallery обеспечивают единообразное развертывание; расширения позволяют выполнять повторяемую настройку и контролировать отклонения от конфигурации (drift control).
Настройте Azure Monitor Agent с помощью правил сбора данных (Data Collection Rules) для отправки гостевых метрик и журналов в рабочую область Log Analytics. При необходимости включите мониторинг подключений и карты зависимостей. Обоснование: AMA — это актуальный агент, он поддерживает гранулярную маршрутизацию и необходим для современных функций мониторинга и автомасштабирования VMSS по метрикам, отличным от загрузки ЦП.
Защитите все ВМ с помощью Azure Backup в хранилище Recovery Services, используя две политики: политика Tier-1 с ежедневными резервными копиями и хранением в течение 30 дней для API/кэша, и политика Tier-0 с ежедневным, а также еженедельным/ежемесячным хранением для SQL со снимками, согласованными на уровне приложений. Протестируйте восстановление, выполнив восстановление на уровне файлов на промежуточную ВМ (jump VM) и полное восстановление ВМ в промежуточную сеть. Обоснование: Раздельные политики соответствуют критичности данных и требованиям RPO/RTO; восстановление на уровне файлов и полное восстановление ВМ покрывают сценарии атак программ-вымогателей и аварийного восстановления.
Назначьте статические частные IP-адреса сетевым интерфейсам (NIC) SQL и Redis на уровне Azure NIC; оставьте экземпляры API с динамическими адресами за балансировщиком нагрузки. Примените единую NSG к каждой подсети для обеспечения единообразных правил. Включите ускоренную сеть (accelerated networking) на высоконагруженных уровнях. Обоснование: Статическое назначение на уровне NIC сохраняет адресацию для уровней с состоянием; NSG на уровне подсети минимизируют разрастание правил; ускоренная сеть снижает задержки и нагрузку на ЦП.

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

← Подписки Azure · Все домены · Виртуальные сети Azure →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →