Share via

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

  • Статья

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

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

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

Ограничения

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

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

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

Корпорация Майкрософт в своих основных службах, таких как 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-объектов, см. статью Краткое руководство по передаче, скачиванию и составлению списка больших двоичных объектов с помощью .NET. Например, рассмотрим получение доступа к страничным BLOB-объектам с помощью клиентской библиотеки хранилища для .NET.

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

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

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

Сначала получите ссылку на контейнер. Чтобы создать страничный BLOB-объект, вызовите метод GetPageBlobClient, а затем метод PageBlobClient.Create. Передайте в него максимальный размер создаваемого большого двоичного объекта. Этот размер должен быть кратен 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-объектов и реплицируется для обеспечения устойчивости, запись фиксируется и клиенту отправляется уведомление о том, что запись завершена успешно.

На схеме ниже показано 2 отдельных операции записи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранилище уровня "Стандартный" и "Премиум" — это надежное хранилище, в котором данные страничных BLOB-объектов всегда реплицируются для обеспечения устойчивости и высокой доступности. Azure постоянно обеспечивает устойчивость корпоративных уровней для дисков IaaS и страничных BLOB-объектов с ведущим в отрасли нулевым процентом ежегодных сбоев.

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

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

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

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

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