Общие сведения о страничных BLOB-объектах в Azure

Служба хранилища Azure предлагает три типа хранилища BLOB-объектов: блочные, добавочные и страничные BLOB-объекты. Блочные BLOB-объекты состоят из блоков и идеально подходят для хранения текстовых или двоичных файлов, а также для эффективной передачи больших файлов. Добавляемые BLOB-объекты также состоят из блоков, но они оптимизированы для операций добавления, что делает их идеальными для сценариев ведения журналов. Страничные BLOB-объекты состоят из 512-байтных страниц, имеют общий размер до 8 ТБ и предназначены для частых операций произвольного чтения и записи. Страничные BLOB-объекты лежат в основе дисков Azure IaaS. В этой статье рассматриваются возможности и преимущества страничных BLOB-объектов.

Страничные BLOB-объекты состоят из страниц размером 512 байт и позволяют читать и записывать произвольные диапазоны байтов. Таким образом, страничные BLOB-объекты идеально подходят для хранения индексированных и разреженных структур данных, например дисков операционной системы и дисков данных виртуальных машин и баз данных. Например, в базе данных SQL Azure страничные BLOB-объекты используются в качестве базового постоянного хранилища для баз данных. Более того, страничные BLOB-объекты также часто используются для файлов с обновлениями на основе диапазонов.

Основные возможности страничных BLOB-объектов Azure: интерфейс REST, устойчивость базового хранилища и возможности эффективной миграции в Azure. Подробнее эти возможности рассматриваются в следующем разделе. Кроме того, страничные BLOB-объекты Azure сейчас поддерживаются в хранилищах двух типов: класса Premium и Standard. Хранилище класса Premium разработано специально для рабочих нагрузок, требующих постоянной высокой производительности и минимальных задержек, благодаря чему страничные BLOB-объекты класса Premium идеально подходят для сценариев с высокими требованиями к производительности хранилища. Учетные записи хранения уровня Standard экономически более выгодны для выполнения рабочих нагрузок, не чувствительных к задержкам.

Ограничения

Страничные BLOB-объекты могут использовать только уровень доступа Hot; они не могут использовать ни уровень Cool, ни уровень Archive. Дополнительные сведения об уровнях доступа см. в статье Горячий, холодный и архивный уровни доступа к данным BLOB.

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

Ниже приведена пара сценариев использования страничных BLOB-объектов, начиная с дисков Azure IaaS. Страничные BLOB-объекты Azure служат основой платформы виртуальных дисков Azure IaaS. Диски ОС и диски данных Azure реализуются как виртуальные диски, где данные надежно хранятся на платформе службы хранилища Azure, а затем доставляются на виртуальные машины для достижения максимальной производительности. Диски Azure сохраняются в формате Hyper-V VHD и хранятся как страничный BLOB-объект в служба хранилища Azure. Помимо использования виртуальных дисков для виртуальных машин IaaS Azure, страничные BLOB-объекты также поддерживают сценарии PaaS и DBaaS, например службу базы данных SQL Azure, в которой сейчас эти объекты используются для хранения данных SQL, обеспечивая выполнение произвольных операций чтения и записи для базы данных. Еще один пример: если у вас есть PaaS-служба для общего доступа к медиаданным в приложениях для совместного редактирования видео, страничные BLOB-объекты позволяют быстро обращаться к произвольным участкам медиаданных. Они также предоставляют возможность нескольким пользователям быстро и эффективно редактировать и объединять одно и то же мультимедиа.

Собственные службы Microsoft, такие как Azure Site Recovery и Azure Backup, а также многие сторонние разработчики внедрили передовые отраслевые инновации с помощью REST-интерфейса страничного BLOB-объекта. Ниже приведены уникальные сценарии, реализованные в Azure.

  • Управление добавочными моментальными снимками, направляемыми приложением. С помощью моментальных снимков страничного BLOB-объекта и интерфейсов REST API приложения могут сохранять контрольные точки приложения без дорогостоящего дублирования данных. Хранилище Azure поддерживает локальные снимки для страничных BLOB-объектов без необходимости копировать весь BLOB-объект. Общедоступные API-интерфейсы этих моментальных снимков также обеспечивают доступ к разностным данным между моментальными снимками и их копирование.
  • Динамическая миграция приложения и данных из локального расположения в облако. Скопируйте локальные данные и запишите их в страничный BLOB-объект Azure через REST API, не прерывая работу виртуальной машины в локальной среде. Когда целевой объект синхронизируется, вы сможете быстро выполнить переключение при отказе на виртуальную машину Azure, используя эти данные. Таким образом, вы можете перенести свои виртуальные машины и виртуальные диски из локальной среды в облако с минимальным временем простоя, поскольку перенос данных происходит в фоновом режиме, пока вы продолжаете использовать виртуальную машину, а время простоя, необходимое для аварийного переключения, будет коротким — всего несколько минут.
  • Общий доступ на базе SAS, который поддерживает такие сценарии, как несколько операций чтения и одна операция записи, с поддержкой управления конкурентным доступом.

Неуправляемые диски удаляются. Дополнительные сведения см. в статье "Миграция неуправляемых дисков Azure к 30 сентября 2025 г.".

Цены

Два типа хранилища, предоставляемые для страничных BLOB-объектов, имеют разные модели ценообразования. Страничные BLOB-объекты уровня Premium оплачиваются так же, как управляемые диски, но страничные BLOB-объекты уровня Standard тарифицируются пропорционально используемому размеру и за каждую транзакцию. Дополнительные сведения см. на странице цен на страничные BLOB-объекты Azure.

Возможности страничных BLOB-объектов

REST API

Чтобы приступить к разработке с помощью страничных BLOB-объектов, см. статью "Разработка с помощью страничных BLOB-объектов". Например, посмотрим, как получить доступ к страничным BLOB-объектам с помощью клиентской библиотеки службы хранилища для .NET.

На следующей схеме изображены общие связи между учетной записью, контейнерами и страничными BLOB-объектами.

Снимок экрана, показывающий взаимосвязи между учетной записью, контейнерами и BLOB-объектами страниц

Создание пустого страничного BLOB-объекта указанного размера

Сначала получите ссылку на контейнер. Чтобы создать страничный BLOB-объект, вызовите метод GetPageBlobClient, а затем метод PageBlobClient.Create. Передайте максимальный размер создаваемого BLOB-объекта. Этот размер должен быть кратен 512 байтам.

long OneGigabyteAsBytes = 1024 * 1024 * 1024;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

var blobContainerClient =
    blobServiceClient.GetBlobContainerClient(Constants.containerName);

var pageBlobClient = blobContainerClient.GetPageBlobClient("0s4.vhd");

pageBlobClient.Create(16 * OneGigabyteAsBytes);

Изменение размера blob-объекта страницы

Чтобы изменить размер страничного BLOB-объекта после его создания, используйте метод Resize. Запрошенный размер должен быть кратен 512 байтам.

pageBlobClient.Resize(32 * OneGigabyteAsBytes);

Запись страниц в страничный BLOB-объект

Чтобы записывать страницы, используйте метод PageBlobClient.UploadPages.

pageBlobClient.UploadPages(dataStream, startingOffset);

Это позволит записать последовательный набор страниц размером до 4 МБ. Записываемое смещение должно начинаться на границе 512 байт (startingOffset % 512 == 0), а заканчиваться на границе 512 — 1.

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

На следующей схеме показаны две отдельные операции записи:

Схема: два разных варианта записи.

  1. Операция записи, начинающаяся со смещения 0 длиной 1024 байт
  2. Операция записи длиной 1024 байта, начинающаяся со смещения 4096

Чтение страниц из страничного BLOB-объекта

Чтобы считать страницы, используйте метод PageBlobClient.Download, который получает диапазон байтов из страничного BLOB-объекта.

var pageBlob = pageBlobClient.Download(new HttpRange(bufferOffset, rangeSize));

Это позволяет загрузить весь BLOB-объект или диапазон байтов, начиная с любого смещения в BLOB-объекте. При чтении смещение не обязательно должно быть кратно 512. При чтении байтов со страницы NUL служба возвращает нулевые байты.

На следующем рисунке показана операция чтения со смещением 256 и размером диапазона 4352. Возвращенные данные выделены оранжевым цветом. Для страниц NUL возвращаются нули.

Схема: операция чтения со смещением 256 и размером диапазона 4352

Если у вас частично заполненный BLOB-объект, возможно, вам стоит загружать только области страниц с данными, чтобы не платить за исходящую передачу нулевых байтов и сократить задержку загрузки.

Чтобы определить, какие страницы содержат данные, используйте PageBlobClient.GetPageRanges. Вы можете перечислить возвращаемые диапазоны и загрузить данные в каждом диапазоне.

IEnumerable<HttpRange> pageRanges = pageBlobClient.GetPageRanges().Value.PageRanges;

foreach (var range in pageRanges)
{
    var pageBlob = pageBlobClient.Download(range);
}

Сдача страничного BLOB-объекта в аренду

Операция аренды BLOB-объекта устанавливает блокировку на BLOB-объекте для операций записи и удаления и управляет ею. Эта операция полезна в сценариях, когда к страничному BLOB-объекту обращаются несколько клиентов, чтобы гарантировать, что в каждый момент времени записывать в BLOB-объект может только один клиент. К примеру, в дисках Azure этот механизм сдачи в аренду используется, чтобы управление диском осуществлялось только с одной виртуальной машины. Длительность блокировки может составлять 15–60 секунд либо быть бесконечной. Дополнительные сведения см. в этой документации.

Помимо разнообразных интерфейсов REST API, страничные BLOB-объекты обеспечивают общий доступ, устойчивость и повышенную безопасность. Мы рассмотрим эти преимущества более подробно в следующих абзацах.

Одновременный доступ

REST API страничного BLOB-объекта и его механизм сдачи в аренду позволяет приложениям получать доступ к страничному BLOB-объекту из нескольких клиентов. Например, предположим, что нужно создать распределенную облачную службу, которая использует объекты хранилища совместно с несколькими пользователями. Это может быть веб-приложение, обслуживающее большую коллекцию изображений для нескольких пользователей. Один из вариантов для реализации — использование виртуальной машины с подключенными дисками. К недостаткам этого относится (а) ограничение подключения диска только к одной виртуальной машине, что уменьшает масштабируемость, гибкость и повышает риски. Если возникнет проблема с виртуальной машиной или со службой, работающей на ней, то из-за аренды образ будет недоступен до тех пор, пока срок аренды не истечёт или пока она не будет снята; и (ii) возникают дополнительные расходы на использование виртуальной машины IaaS.

Альтернативным вариантом является использование страничных BLOB-объектов напрямую через интерфейсы REST API службы хранилища Azure. Этот вариант не требует использования дорогостоящих виртуальных машин IaaS, предоставляет гибкие возможности прямого доступа из нескольких клиентов, упрощает классическую модель развертывания (так как не нужно подключать и отключать диски) и исключает риски возникновения проблем на виртуальной машине. И обеспечивается тот же уровень производительности для произвольных операций чтения и записи, что и на диске.

Высокая доступность и устойчивость

Хранилище уровня "Стандартный" и "Премиум" — это устойчивое хранилище, в котором данные страничного BLOB-объекта всегда реплицируются, чтобы обеспечить устойчивость и высокий уровень доступности. неизменно обеспечивает надёжность корпоративного уровня для дисков IaaS и page-blob’ов, с лучшим в отрасли нулевым показателем Annualized Failure Rate.

Дополнительные сведения об избыточности службы хранилища Azure для учетных записей хранения уровня "Стандартный" и "Премиум" см. в статье Избыточность службы хранилища Azure, а также в следующих двух разделах:

Простая миграция в Azure

Для клиентов и разработчиков, заинтересованных в реализации своего собственного пользовательского решения резервного копирования, Azure также предлагает добавочные моментальные снимки, которые содержат только разностные данные. Эта возможность позволяет избежать затрат на начальную полную копию, что значительно снижает расходы на резервное копирование. Помимо возможности эффективно считывать и копировать разностные данные, это еще одна мощная возможность, которая открывает разработчикам путь к еще большему числу инноваций, обеспечивая лучший в своем классе опыт резервного копирования и аварийного восстановления (DR) в Azure. Вы можете настроить собственное решение для резервного копирования или аварийного восстановления виртуальных машин в Azure, используя Blob Snapshot вместе с API Get Page Ranges и API Incremental Copy Blob, чтобы легко копировать инкрементные данные для аварийного восстановления.

Кроме того, во многих предприятиях важные рабочие нагрузки уже запущены в центрах обработки данных в локальной среде. При переносе рабочей нагрузки в облако одной из основных проблем является время простоя, необходимое для копирования данных, и риск возникновения других непредвиденных проблем после переключения. Во многих случаях простой может стать серьёзным препятствием для миграции в облако. Используя REST API BLOB-объектов страниц, Azure решает эту проблему, обеспечивая миграцию в облако с минимальным влиянием на критически важные рабочие нагрузки.

Примеры того, как создать моментальный снимок и восстановить страничный BLOB-объект из моментального снимка, см. в статье Настройка процесса резервного копирования с помощью инкрементных моментальных снимков.

  • Last updated on