Microsoft AZ-900: Хранилище и базы данных — Руководство по подготовке

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

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

Службы хранилища Azure и управляемые диски

Azure Blob Storage — это основа для хранения неструктурированных данных. Блочные BLOB-объекты (Block blobs) предназначены для больших объектов и поддерживают эффективную потоковую передачу, параллельную загрузку, моментальные снимки, управление версиями и распределение по уровням (tiering). Страничные BLOB-объекты (Page blobs) оптимизированы для операций произвольного чтения/записи (random I/O) страницами по 512 байт и лежат в основе виртуальных жестких дисков (VHD); они используются для дисков и сценариев, требующих стабильно низких задержек и высоких показателей IOPS. Дополняемые BLOB-объекты (Append blobs) созданы для сценариев с интенсивной записью путем добавления данных, например для журналов приложений, где новые блоки эффективно добавляются в конец. Azure Files предлагает полностью управляемые файловые ресурсы, доступные по протоколам SMB или NFS, с поддержкой списков управления доступом (ACL) NTFS, возможностями интеграции с каталогами и службой Azure File Sync для кэширования активных данных на серверах Windows Server. Queue Storage предоставляет легковесную и надежную систему обмена сообщениями для разделения компонентов приложений с семантикой доставки «как минимум один раз» (at-least-once). Table Storage предоставляет бессхемное хранилище типа «ключ-атрибут» для огромных секционированных наборов данных, где вы управляете ключами секций и строк для обеспечения масштабируемости и экономической эффективности. Управляемые диски (Managed disks) предоставляют надежное и постоянное блочное хранилище для виртуальных машин Azure, избавляя от необходимости напрямую управлять учетными записями хранения или страничными BLOB-объектами. Вы можете выбрать диски Standard HDD для рабочих нагрузок, оптимизированных по стоимости и пропускной способности, Standard SSD для сбалансированной производительности, Premium SSD и Premium SSD v2 для высоких показателей IOPS с низкой задержкой, а также Ultra Disk для самых требовательных транзакционных нагрузок с настраиваемыми IOPS и пропускной способностью. Управляемые диски поддерживают моментальные снимки, инкрементное резервное копирование, шифрование дисков и варианты доступности, соответствующие SLA ваших виртуальных машин.

BLOB-объект — блочный (Block blob)
- Модель данных или шаблон ввода-вывода: Большие объекты, последовательный ввод-вывод
- Ключевые возможности: Распределение по уровням (tiering), моментальные снимки, управление версиями, политики жизненного цикла
- Типичные сценарии использования: Изображения, видео, резервные копии, зоны для размещения больших данных (big data)
- Ограничения/примечания: Размер одного BLOB-объекта до ~190 ТиБ; не оптимизирован для произвольного ввода-вывода (random IO)
BLOB-объект — страничный (Page blob)
- Модель данных или шаблон ввода-вывода: Произвольный ввод-вывод (random IO) страницами по 512 байт
- Ключевые возможности: Чтение/запись с низкой задержкой, основа для VHD
- Типичные сценарии использования: Базовое хранилище для дисков и сценариев, требующих произвольного доступа
- Ограничения/примечания: Размер страничного BLOB-объекта до 8 ТиБ; управляемые диски абстрагируют эту сложность
BLOB-объект — дополняемый (Append blob)
- Модель данных или шаблон ввода-вывода: Запись только в режиме добавления (append-only)
- Ключевые возможности: Эффективное добавление в журналы, опции неизменяемости
- Типичные сценарии использования: Телеметрия и журналы приложений
- Ограничения/примечания: Обновление на месте не поддерживается; действуют ограничения на количество блоков
Azure Files
- Модель данных или шаблон ввода-вывода: Файловая семантика POSIX/SMB/NFS
- Ключевые возможности: Доступ по SMB/NFS, списки ACL NTFS, интеграция с AD DS/Azure AD DS, File Sync
- Типичные сценарии использования: Перенос существующих файловых ресурсов (lift-and-shift), конфигурация приложений, домашние каталоги пользователей
- Ограничения/примечания: Уровни Standard и Premium; большие файловые ресурсы до 100 ТиБ
Queue Storage
- Модель данных или шаблон ввода-вывода: Очередь сообщений
- Ключевые возможности: Доставка «как минимум один раз», тайм-ауты видимости, обработка «отравленных» сообщений
- Типичные сценарии использования: Фоновая обработка, разделенные микросервисы
- Ограничения/примечания: Размер сообщения до 64 КБ (для более крупных/сложных сценариев используйте Service Bus)
Table Storage
- Модель данных или шаблон ввода-вывода: NoSQL «ключ-атрибут»
- Ключевые возможности: Масштабируемость, секционирование по PartitionKey, низкая стоимость
- Типичные сценарии использования: Телеметрия, каталоги, профили пользователей
- Ограничения/примечания: Нет соединений (joins) или вторичных индексов; для глобальных сценариев используйте Cosmos DB Table API
Управляемые диски (Managed disks)
- Модель данных или шаблон ввода-вывода: Блочное хранилище для ВМ
- Ключевые возможности: SKU уровней Standard/Premium/Ultra, моментальные снимки, масштабирование, шифрование дисков
- Типичные сценарии использования: Диски ОС/данных для ВМ, базы данных, бизнес-приложения
- Ограничения/примечания: До 32 ТиБ на диск; ZRS доступно для некоторых SKU

Варианты избыточности и устойчивости

Модели избыточности определяют, где и сколько синхронных и асинхронных реплик ваших данных хранит Azure. Локально избыточное хранилище (LRS) хранит три копии в одном центре обработки данных в одном регионе, обеспечивая защиту от сбоев дисков и стоек по самой низкой цене. Зонально-избыточное хранилище (ZRS) распределяет три синхронные копии по отдельным зонам доступности в одном регионе, обеспечивая устойчивость к сбою зоны без необходимости отработки отказа на уровне приложения. Геоизбыточное хранилище (GRS) расширяет LRS, асинхронно реплицируя ваши данные в парный регион, что в сумме дает шесть копий в двух регионах; после того как Microsoft инициирует отработку отказа учетной записи, вторичный регион становится новым основным. Геоизбыточное хранилище с доступом на чтение (RA-GRS) добавляет активную вторичную конечную точку только для чтения, чтобы приложения могли считывать данные из вторичного региона даже до отработки отказа, что позволяет распределять нагрузку на чтение по всему миру и выносить аналитику. Геозонально-избыточное хранилище (GZRS) сочетает ZRS в основном регионе с асинхронной репликацией в LRS в парном регионе, защищая как от сбоев зон, так и от сбоев регионов; вариант с доступом на чтение (RA-GZRS) предоставляет конечные точки для чтения во вторичном регионе. Выбор зависит от целевых показателей восстановления, ожидаемой задержки и бюджета. В пределах одного региона ZRS защищает от сбоев зон, сохраняя при этом низкую задержку записи. Для аварийного восстановления и сценариев межрегионального чтения предпочтительны GRS/RA-GRS и GZRS. В геоизбыточных вариантах согласованность данных во вторичном регионе по своей природе асинхронна, поэтому приложения должны быть рассчитаны на итоговую согласованность (eventual consistency) до завершения отработки отказа.

LRS
- Схема репликации: 3 копии в одном центре обработки данных (регион)
- Доступ на чтение ко вторичной реплике: Нет
- Устойчивость к сбоям региона/зоны: Защищает от локальных сбоев оборудования/стоек
- Типичные рабочие нагрузки: Разработка/тестирование, недорогое хранилище, некритичные данные
ZRS
- Схема репликации: 3 копии синхронно в 3 зонах доступности (регион)
- Доступ на чтение ко вторичной реплике: Нет
- Устойчивость к сбоям региона/зоны: Переживает сбои зон без отработки отказа на уровне приложения
- Типичные рабочие нагрузки: Продакшн-контент веб-сайтов/приложений, требующий высокой региональной доступности
GRS
- Схема репликации: LRS в основном регионе + асинхронный LRS в парном регионе (всего ~6 копий)
- Доступ на чтение ко вторичной реплике: Нет
- Устойчивость к сбоям региона/зоны: Региональное аварийное восстановление через отработку отказа учетной записи; нет зональной защиты в основном регионе
- Типичные рабочие нагрузки: Резервное копирование/архивация с возможностью регионального аварийного восстановления
RA-GRS
- Схема репликации: GRS + конечная точка для чтения во вторичном регионе
- Доступ на чтение ко вторичной реплике: Да
- Устойчивость к сбоям региона/зоны: Как у GRS; позволяет глобально распределять нагрузку на чтение
- Типичные рабочие нагрузки: Чтение контента по всему миру, вынос аналитики/отчетности на вторичную реплику
GZRS
- Схема репликации: ZRS в основном регионе + асинхронный LRS в парном регионе
- Доступ на чтение ко вторичной реплике: Нет (используйте RA-GZRS)
- Устойчивость к сбоям региона/зоны: Защищает от сбоев зон и региональных катастроф
- Типичные рабочие нагрузки: Критически важные приложения, требующие зональной и геоизбыточной устойчивости

Уровни доступа и управление жизненным циклом

Уровни доступа к BLOB-объектам позволяют согласовать стоимость хранения с шаблонами доступа. Уровень Hot оптимизирован для частого доступа с самыми низкими затратами на транзакции чтения и записи, но с более высокой ценой за ГБ хранения. Уровень Cool снижает цену за ГБ хранения, но увеличивает стоимость транзакций и плату за досрочное удаление, что делает его подходящим для наборов данных, к которым обращаются нечасто, например, для ежемесячных отчетов или краткосрочных резервных копий. Уровень Archive предлагает самую низкую стоимость хранения, но требует восстановления (rehydration) перед доступом, при этом имеет самые высокие сборы за доступ и досрочное удаление; он предназначен для долгосрочного хранения и сценариев соответствия нормативным требованиям. Политики управления жизненным циклом автоматизируют перемещение между уровнями и хранение на уровне контейнера или учетной записи. Правила могут перемещать BLOB-объекты между уровнями Hot, Cool и Archive на основе времени последнего изменения, времени последнего доступа или тегов индекса BLOB-объектов, а также удалять версии, моментальные снимки или базовые BLOB-объекты по истечении определенного срока. Политики помогают сократить общую стоимость владения за счет перемещения «холодных» данных из хранилища Hot и удаления устаревших данных без ручного вмешательства. Управление жизненным циклом доступно для учетных записей хранения общего назначения v2 и Blob storage и работает с блочными и добавочными BLOB-объектами; оно не применяется к хранилищу блочных BLOB-объектов уровня “премиум”. Восстановление из архива (rehydration) поддерживает стандартный и высокоприоритетный варианты, позволяя выбирать между стоимостью и скоростью. Планируйте окна извлечения, измеряемые часами для стандартного восстановления и от минут до часов для высокоприоритетного восстановления небольших объектов. Для обеспечения соответствия требованиям сочетайте уровень Archive с политиками неизменяемости (хранение на основе времени или удержание по юридическим причинам), чтобы обеспечить гарантии однократной записи и многократного чтения (WORM) на уровне контейнера или BLOB-объекта.

Hot
- Стоимость хранения: Самая высокая
- Стоимость доступа/транзакций: Самая низкая
- Минимальный срок хранения: Нет
- Задержка извлечения: Миллисекунды (онлайн)
- Типичные данные: Активный контент, часто читаемые/записываемые данные
Cool
- Стоимость хранения: Ниже, чем у Hot
- Стоимость доступа/транзакций: Выше, чем у Hot; взимается плата за досрочное удаление
- Минимальный срок хранения: 30 дней
- Задержка извлечения: Миллисекунды (онлайн)
- Типичные данные: Данные с нечастым доступом, краткосрочные резервные копии
Archive
- Стоимость хранения: Самая низкая
- Стоимость доступа/транзакций: Самая высокая; взимается плата за досрочное удаление
- Минимальный срок хранения: 180 дней
- Задержка извлечения: Часы (требуется восстановление)
- Типичные данные: Долгосрочное хранение, архивы для соответствия требованиям, редко используемые резервные копии

Безопасность, шифрование и контроль доступа

Шифрование неактивных данных (at rest) включено по умолчанию через Storage Service Encryption (SSE). По умолчанию данные прозрачно защищаются ключами, управляемыми Microsoft. Для более строгого контроля и разделения обязанностей можно настроить ключи, управляемые клиентом (CMK), для каждой учетной записи хранения, используя ключи из Azure Key Vault или Managed HSM, что поддерживает рабочие процессы ротации и отзыва ключей. Для чувствительных рабочих нагрузок опции двойного шифрования и конфиденциальных вычислений дополнительно снижают риски раскрытия данных. При передаче данных (in transit) принудительно используйте HTTPS с TLS для всех операций на уровне данных (data plane). Контроль доступа охватывает авторизацию на основе удостоверений и токены с ограниченной областью действия. Azure RBAC интегрируется с Microsoft Entra ID для предоставления доступа на уровне данных с минимальными привилегиями, например, ролей Storage Blob Data Reader/Contributor, пользователям, группам и управляемым удостоверениям. RBAC устраняет необходимость в общих секретах и поддерживает условный доступ, Privileged Identity Management и аудит. Подписанные URL-адреса (Shared Access Signatures, SAS) делегируют ограниченный по времени и разрешениям доступ клиентам, у которых может не быть удостоверения; SAS можно подписывать ключами учетной записи или с помощью делегирования пользователя, используя учетные данные Microsoft Entra, чтобы избежать раскрытия ключей учетной записи. Комбинируйте RBAC для доступа между службами и административного доступа с SAS для сценариев временного клиентского доступа. Защищайте ключи учетной записи и регулярно их ротируйте; по возможности отдавайте предпочтение SAS с делегированием пользователя. Сетевая изоляция с помощью Private Endpoints или конечных точек служб, правила брандмауэра и политики неизменяемого хранилища завершают создание эшелонированной защиты (defense-in-depth) для учетных записей хранения.

Azure RBAC (Microsoft Entra ID)
- Область действия: Роли на основе удостоверений на уровне данных и уровне управления хранилища
- Оптимально для: Администраторов, служб и приложений с управляемыми удостоверениями
- Ключевые свойства: Принцип минимальных привилегий, условный доступ, возможность аудита, отсутствие общих секретов
- Факторы риска: Требует интеграции с системой удостоверений; отзыв доступа через изменение ролей
Shared Access Signature (SAS)
- Область действия: Ограниченные по времени и разрешениям токены для конкретных ресурсов
- Оптимально для: Делегирования ограниченного доступа клиентам/партнерам
- Ключевые свойства: Гранулярные разрешения, ограничения по IP/времени; SAS с делегированием пользователя позволяет избежать использования ключей учетной записи
- Факторы риска: Утечка токена предоставляет доступ до истечения срока его действия; защищайте распространение и устанавливайте короткий срок жизни

Реляционные PaaS и глобально распределенные NoSQL

Azure SQL Database предоставляет управляемый реляционный движок с автоматической установкой исправлений, встроенной высокой доступностью, резервным копированием и масштабированием. Развертывайте отдельные базы данных или эластичные пулы для консолидации переменных рабочих нагрузок. Служба поддерживает несколько реплик в пределах региона и поддерживает избыточность между зонами; прозрачное шифрование данных (Transparent Data Encryption, TDE) включено по умолчанию. Автоматизированные резервные копии позволяют выполнять восстановление на определенный момент времени (point-in-time restore), как правило, за 7–35 дней, с возможностью долгосрочного хранения до нескольких лет в хранилище Azure. Для обеспечения отказоустойчивости в нескольких регионах и чтения с низкой задержкой используйте активную георепликацию (до четырех читаемых вторичных реплик) или группы автоматической отработки отказа (Auto-failover groups) для скоординированного аварийного восстановления в масштабе. Azure SQL Managed Instance предлагает почти 100% совместимость с движком SQL Server для функций уровня экземпляра, таких как SQL Agent, межбазовые запросы, Service Broker и CLR, что позволяет легко модернизировать локальные решения без рефакторинга. Он имеет ту же управляемую архитектуру высокой доступности, онлайн-установку исправлений, автоматизированное резервное копирование, TDE по умолчанию и поддерживает группы автоматической отработки отказа между регионами. Сетевая изоляция с помощью частных конечных точек и масштабирование вычислений/хранилища для каждой базы данных или экземпляра обеспечивают предсказуемые границы производительности. Azure Cosmos DB предоставляет полностью управляемую мультимодельную базу данных NoSQL с готовым глобальным распределением и записью в несколько регионов. Она гарантирует задержки в пределах единиц миллисекунд на 99-м процентиле в пределах одного региона и предлагает пять настраиваемых уровней согласованности для баланса между производительностью и корректностью данных между регионами. Выделяйте пропускную способность в RU/s или используйте автомасштабирование, добавляйте или удаляйте регионы без простоя и настраивайте автоматическую отработку отказа. API включают Core (SQL), MongoDB, Cassandra, Gremlin и Table, что упрощает миграцию и интеграцию с различными стеками приложений.

Azure SQL Database
- Модель: Реляционная PaaS (отдельная БД/эластичный пул)
- Совместимость: Новейшие функции SQL; совместимость на уровне приложений
- HA/DR: Встроенные реплики, избыточность между зонами; активная георепликация; группы Auto-failover
- Резервные копии/TDE: Автоматическое PITR на 7–35 дней; LTR до нескольких лет; TDE включено по умолчанию
- Гео-опции: Читаемые вторичные реплики в разных регионах; скоординированные группы отработки отказа
- Оптимально для: SaaS/мультитенантных приложений, новых облачных реляционных рабочих нагрузок
Azure SQL Managed Instance
- Модель: Реляционная PaaS (экземпляр)
- Совместимость: Высокая совместимость с функциями SQL Server, включая SQL Agent, межбазовые запросы
- HA/DR: Встроенная высокая доступность; избыточность между зонами; группы Auto-failover
- Резервные копии/TDE: Автоматическое PITR на 7–35 дней; LTR; TDE включено по умолчанию; поддержка нативного восстановления
- Гео-опции: Несколько регионов с группами отработки отказа и читаемыми вторичными репликами
- Оптимально для: Миграции (lift-and-shift) локальных SQL с минимальными изменениями
Azure Cosmos DB
- Модель: NoSQL, мультимодельная (Core, MongoDB, Cassandra, Gremlin, Table)
- Совместимость: Совместимость на уровне API с популярными стеками NoSQL
- HA/DR: Запись в несколько регионов и с несколькими ведущими узлами (multi-master); SLA 99,99%
- Резервные копии/TDE: Опции автоматического и непрерывного резервного копирования; шифрование неактивных данных
- Гео-опции: Добавление/удаление регионов без простоя; настраиваемая согласованность; автоматическая отработка отказа
- Оптимально для: Глобальных приложений с низкой задержкой, IoT, каталогов, персонализации