Большой двоичный объект Windows Azure

БОЛЬШОЙ ДВОИЧНЫЙ ОБЪЕКТ WINDOWS
AZURE
Бред Калдер, Тони Ванг, Шейн Маинали и Джейсон Ву
Май 2009
Содержание
Введение ................................................................................................................................. 2
Модель данных ...................................................................................................................... 2
REST-интерфейс BLOB-объектов........................................................................................ 4
3.1 Управление версиями .................................................................................................... 5
4 BLOB-объект как список блоков ......................................................................................... 6
4.1 Абстракции данных блоков........................................................................................... 8
4.2 Примеры запросов REST ............................................................................................... 8
1
2
3
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
Примеры REST-запросов PUT Block .................................................................................... 8
Примеры REST-запросов PUT Block List ............................................................................. 9
Примеры REST-запросов GET Blob ..................................................................................... 9
Примеры REST-запросов GET Block List............................................................................ 10
Примеры REST-запросов Copy Blob.................................................................................. 12
4.3 Сценарии передачи блоков.......................................................................................... 13
4.4 Условные операции PUT и GET и оптимистичный параллелизм ........................... 15
4.5 Параллельные операции PUT и GET для одного BLOB-объекта............................ 16
5 Перечисление BLOB-объектов........................................................................................... 16
5.1 Иерархический перечень ............................................................................................. 16
5.2 Разбивка на страницы .................................................................................................. 17
6 Передовые практические методы ...................................................................................... 18
6.1 Время ожидания повторных запросов и ошибки «Connection closed by Host»
(соединение прервано узлом) ................................................................................................ 18
6.2 Настройка приложения при многократном возникновении ошибок превышения
времени ожидания .................................................................................................................. 18
6.3 Обработка ошибок и составление отчетов ................................................................ 19
6.4 Сжатое содержимое ..................................................................................................... 19
6.5 Копирование BLOB-объекта ....................................................................................... 20
6.6 Использование операции GET Block List для неподтвержденных блоков ............ 20
6.7 Устойчивость к сбоям .................................................................................................. 20
6.8 Рекомендации по работе с контейнером BLOB-объекта ......................................... 21
1
1 Введение
Windows Azure является основой облачной платформы Microsoft. Эта «облачная операционная
система» предоставляет разработчикам приложений основные технологические компоненты для
создания масштабируемых служб высокой доступности:
 Виртуализированные вычисления
 Масштабируемое хранилище
 Автоматизированное управление
 Обширный пакет средств разработки
Хранилище Windows Azure позволяет разработчикам приложений хранить данные в облаке.
Приложение получает доступ к данным в любой момент из любой точки и может хранить любой
объем данных в течение неограниченного времени. При этом гарантируется, что данные не будут
повреждены или утеряны. Хранилище Windows Azure поддерживает широкий набор абстракций
данных:
 Служба больших двоичных объектов Windows Azure (Windows Azure Blob) — обеспечивает
хранение больших элементов данных.
 Таблица Windows Azure (Windows Azure Table) — предоставляет структурированное
хранилище для поддержки состояния службы.
 Очередь Windows Azure (Windows Azure Queue) — обеспечивает диспетчеризацию
асинхронных заданий и взаимодействие между службами.
Чтобы использовать хранилище Windows Azure, пользователь должен создать учетную запись при
помощи веб-интерфейса портала Windows Azure. После создания учетной записи пользователь
получает 256-разрядный секретный ключ, предназначенный для проверки подлинности
пользователей и авторизации запросов к системе хранения.С помощью этого секретного ключа
создается подпись HMAC SHA256 для запроса. Эта подпись передается с каждым запросом для
аутентификации запросов пользователя.
В этом документе приведено описание службы больших двоичных объектов Windows Azure.
Служба больших двоичных объектов Windows Azure позволяет приложениям хранить в облаке
большие объекты, до 50 ГБ каждый. Наиболее часто используемые большие двоичные объекты
(BLOB) обслуживаются несколькими серверами. Это обеспечивает масштабирование и обработку
необходимого для работы приложения трафика. Такая система обладает высокой надежностью
благодаря троекратному дублированию данных. Данные доступны в любой момент времени из
любой точки. Кроме того, обеспечивается строгая согласованность. Это гарантирует мгновенную
доступность объекта при его добавлении или обновлении: все внесенные изменения немедленно
становятся доступны для чтения.
2 Модель данных
На рисунке внизу представлено пространство имен Windows Azure Blob.
2

Учетная запись хранения. Доступ к Windows Azure Storage осуществляется через учетную
запись хранения.
o Это самый высокий уровень пространства имен для доступа к BLOB-объектам.
o Учетная запись может иметь множество контейнеров BLOB-объектов.
Учетная
запись
Контейнер
BLOB
IMG001.JPG
Картинки
IMG002.JPG
Мария
Фильмы
MOV1.AVI
Рис. 1. Общее представление хранилища BLOB-объектов


Контейнер BLOB-объектов. Контейнер обеспечивает группировку набора BLOB-объектов.
Область действия имени контейнера ограничена учетной записью.
o Политики совместного использования задаются на уровне контейнера. В
настоящее время поддерживаются «Public READ» («Общедоступное чтение») и
«Private» («Частный»). Если для контейнера определена политика «Public READ»,
все его содержимое доступно для чтения без необходимости аутентификации.
Политика «Private» означает доступ с проверкой подлинности, то есть только
владелец соответствующей учетной записи имеет доступ к BLOB-объектам этого
контейнера.
o Контейнеры могут содержать ассоциированные метаданные, которые задаются в
виде пар <имя, значение>. Максимальный размер метаданных контейнера — 8 КБ.
o Существует возможность получения списка всех BLOB-объектов контейнера.
BLOB-объект. BLOB-объекты хранятся в контейнерах больших двоичных объектов (Blob
Container) и их область действия ограничена этими контейнерами. Размер каждого BLOBобъекта - до 50 ГБ. BLOB-объект имеет уникальное в рамках контейнера строковое имя.
Метаданные BLOB-объекта задаются в виде пар <имя, значение>. Максимальный размер
метаданных — 8 КБ для каждого объекта. Метаданные могут быть получены и присвоены
отдельно от данных BLOB-объекта.
3
Для доступа к Windows Azure Blob используется описанные выше пространства имен. URL BLOBобъекта структурирован следующим образом:
http://<учетная запись>.blob.core.windows.net/<контейнер>/<имя BLOB-объекта>
Имя учетной записи хранения образовано первой частью имени узла, за которой следует
ключевое слово «blob». Это обеспечивает направление запроса в часть Windows Azure Storage,
которая обрабатывает запросы BLOB-объектов. За именем узла идет имя контейнера, символ «/»,
затем имя BLOB-объекта. Существуют ограничения именования учетных записей и контейнеров
(подробнее об этом рассказывается в документе Windows Azure SDK). Например, имя контейнера
не может содержать символ «/».
Несколько замечаний по поводу контейнеров:
 Как говорилось выше, область действия контейнеров ограничена учетной записью,
которой они принадлежат. Контейнеры обрабатываются распределено, что устраняет
вероятность возникновения «узких мест» для трафика при работе с ними. Контейнеры
должны быть постоянно доступны для обработки.
 Возможна задержка при восстановлении недавно удаленного контейнера, особенно если
в нем находилось большое количество BLOB-объектов. Система должна восстановить
BLOB-объекты этого контейнера, прежде чем вновь создать контейнер с таким же именем.
Пока сервер удаляет все BLOB-объекты, попытки создания контейнера с таким же именем
будут оканчиваться неудачей с формированием ошибки, указывающей на то, что
контейнер находится в процессе удаления.
 Команды удаления или создания совершенно нового контейнера быстро передаются на
сервер, и приложению возвращается подтверждение об их выполнении, даже если
операция удаления занимает некоторое время. Поэтому их можно включать в те ветви
кода приложения, от которых требуется высокая доступность.
3 REST-интерфейс BLOB-объектов
Доступ к Windows Azure Blob выполняется при помощи стандартных HTTP-команд PUT/GET/DELETE
интерфейса REST.
К командам HTTP/REST для работы с BLOB-объектами относятся:
 PUT Blob: вставить новый или перезаписать существующий BLOB-объект с заданным
именем.
 GET Blob: получить весь BLOB-объект или диапазон байтов BLOB-объекта, используя
стандартную HTTP-операцию для возвращения диапазона GET.
 DELETE Blob: удалить существующий BLOB-объект.
 Copy Blob: копировать BLOB-объект из исходного BLOB-объекта в заданный BLOB-объект в
рамках одной учетной записи хранения. Копируется весь BLOB-объект, в том числе его
4

метаданные, свойства и список блоков. Команда Copy Blob может использоваться вместе с
командой Delete Blob для переименования BLOB-объекта, перемещения BLOB-объекта из
контейнера в контейнер и для создания резервных копий существующих BLOB-объектов.
GET Block List: извлечь список блоков, переданных как часть BLOB-объекта. Для BLOBобъекта создается два списка блоков. Эта функция позволяет извлекать любой из них или
оба:
o Committed Block List (Список подтвержденных блоков) — это список блоков,
которые были успешно переданы как часть PUT Block List данного BLOB-объекта.
o Uncommitted Block List (Список неподтвержденных блоков) — список блоков,
которые были переданы для BLOB-объекта после выполнения последней команды
PUT Block List. Это временные, еще не подтвержденные блоки.
Для выполнения операций с BLOB-объектом используется следующий URL:
http://<учетная запись>.blob.core.windows.net/<контейнер>/<имя BLOB-объекта>
Один запрос PUT позволяет загрузить в облако BLOB-объект размером до 64 МБ. Для загрузки
BLOB-объекта, размер которого превышает 64 МБ, используется технология загрузки блоками,
описываемая в следующем разделе.
Полное описание API REST представлено в документе Windows Azure SDK.
3.1 Управление версиями
Для всех решений Windows Azure Storage введен новый HTTP-заголовок — x-ms-version. С
помощью этого заголовка все изменения в API хранилища регистрируются в качестве версий. Это
позволяет применять к системе хранения предыдущие версии команд, расширять возможности
существующих команд и создавать новые.
Заголовок x-ms-version должен быть задан для всех запросов к Windows Azure Storage. При
поступлении запроса без указания версии система хранения выполнит команду самой старой из
поддерживаемых версий.
К PDC 2009 планируется сделать x-ms-version обязательным для всех неанонимных команд. До тех
пор, если версия запроса не задана, предполагается использование CTP-версии API Windows Azure
Storage с PDC 2008. Запрос с недействительным x-ms-version будет отклонен.
Текущей версией является «x-ms-version: 2009-04-14». Она может использоваться для всех команд
и запросов к Windows Azure Storage. В этой версии для Windows Azure Blob была введена команда
Copy Blob и новая версия команды GET Block List. Это означает, что команда Copy Blob не может
использоваться без заголовка версии. Кроме того, для применения нового формата и версии
команды GetBlockList должна быть задана версия 2009-04-14. Если версия не задана, будет
использоваться версия CTP 2008 команды GetBlockList, не поддерживающая возвращение списка
неподтвержденных блоков.
5
4 BLOB-объект как список блоков
Один из целевых сценариев Windows Azure Blob — эффективная передача BLOB-объектов
размером в несколько гигабайт. Это выполняется следующим образом:
 Передаваемый BLOB-объект (например, Movie.avi) последовательно разбивается на блоки.
Например, ролик размером 10 ГБ может быть разбит на 2500 блоков по 4 МБ; при этом
первый блок будет представлять диапазон байтов данных от 1 до 4 194 304, второй блок —
от 4 194 305 до 8 388 608 и т. д.
 Каждому блоку присваивается уникальное имя и идентификатор (ID). Область действия
этого уникального ID ограничена именем передаваемого BLOB-объекта. Например,
первый блок может быть назван «Block 0001», второй — «Block 0002» и т. д.
 Каждый блок размещается в облаке. Для этого используется операция PUT с указанием
представленного выше URL с запросом, определяющим операцию размещения блока и ID
блока. В нашем примере при размещении первого блока будет указано имя BLOB-объекта
«Movie.avi» и ID блока «Block 0001».
 После помещения всех блоков в хранилище Windows Azure Storage отправляется список
неподтвержденных блоков для представления имени BLOB-объекта, с которым они
ассоциированы. Для этого выполняется операция PUT с указанием представленного выше
URL с запросом, определяющим, что это команда Block List. HTTP-заголовок содержит
список блоков, которые необходимо передать для этого BLOB-объекта. При успешном
выполнении этой операции доступная для чтения версия BLOB-объекта будет
представлена в виде списка блоков. Теперь BLOB-объект может быть считан с помощью
описанной выше команды GET Blob.
На следующем рисунке представлена роль блоков в концепции данных Windows Azure Blob.
6
Учетная
запись
Контейнер
Blob
Блок
IMG001.JPG
Картинки
IMG002.JPG
Мария
Блок 1
Фильмы
MOV1.AVI
Блок 2
Блок 3
Рис. 2. Концепция хранилища BLOB-объектов — добавление блоков
Как было отмечено ранее, доступ к BLOB-объектам может осуществляться при помощи операций
PUT и GET с использованием следующего URL:
http://<учетная запись>.blob.core.windows.net/<контейнер>/<имя BLOB-объекта>
В примере, представленном на рисунке 2, одна операция PUT используется для размещения
изображений, имеющих URL:
http://sally.blob.core.windows.net/pictures/IMG001.JPG
http://sally.blob.core.windows.net/pictures/IMG002.JPG
Те же URL могут использоваться для получения BLOB-объектов. Одна операция PUT может
поместить в хранилище BLOB-объект размером до 64 МБ. Для сохранения BLOB-объектов
размером от 64 МБ до 50 ГБ необходимо сначала разместить все блоки при помощи операций
PUT. Затем нужно передать список блоков с помощью операции PUT, чтобы создать пригодную
для чтения версию BLOB-объекта. Рисунок 2 демонстрирует, что только после размещения всех
блоков и подтверждения их принадлежности при помощи списка блоков BLOB-объект может быть
считан с использованием следующего URL:
http://sally.blob.core.windows.net/pictures/MOV1.AVI
Операции GET всегда выполняются на уровне BLOB-объекта и не используют блоки.
7
4.1 Абстракции данных блоков
Идентификация блока осуществляется при помощи ID размером до 64 байт. Область действия
идентификатора блока ограничена именем BLOB-объекта, поэтому разные BLOB-объекты могут
иметь блоки с одинаковыми ID. Блоки неизменны. Каждый блок имеет размер до 4 МБ. BLOBобъект может содержать блоки разного размера. Windows Azure Blob поддерживает следующие
операции уровня блока:
 PUT Вlock — загрузить блок BLOB-объекта. Обратите внимание: блок, успешно переданный
посредством операции PUT Вlock, не является частью BLOB-объекта до тех пор, пока это не
будет подтверждено списком блоков, загружаемым операцией PUT Block List.
 PUT Block List — подтвердить BLOB-объект, предоставив список ID составляющих его
блоков. Блоки, указанные в этом списке, должны уже быть успешно переданы при помощи
вызовов PUT. Порядок блоков в списке PUT Block List образует пригодную для чтения
версию BLOB-объекта.
 GET Block List — извлечь список блоков, переданный ранее для BLOB-объекта операцией
PUT Block List. В возвращаемом списке блоков указывается ID и размер каждого блока. Эта
функция также может использоваться для извлечения списка неподтвержденных блоков, в
который входят блоки, переданные для BLOB-объекта при помощи вызовов PUT Block, но
до сих пор не подтвержденный командой PUT Block List.
Обратите внимание, что идентификатор блока (Block ID) является частью метаданных, которые
можно отслеживать для каждого блока. Один из примеров применения Block ID — использование
идентификаторов блока в качестве хеша содержимого блока. Это позволяет контролировать
целостность данных для каждого блока, извлекаемого из системы.
4.2 Примеры запросов REST
Во всех рассматриваемых далее примерах используется BLOB-объект «MOV1.avi»,
располагающийся в контейнере «movies» (ролики) учетной записи «sally».
4.2.1 Примеры REST-запросов PUT Block
Ниже приведен пример REST-запроса для размещения блока размером 4 МБ при помощи
операции PUT Вlock. Обратите внимание, что используется HTTP-команда PUT. Параметр запроса
«?comp=block» указывает на то, что это операция PUT Вlock. Затем задается BlockID. Параметр
Content-MD5 может быть задан для обеспечения целостности данных и защиты от ошибок при
передаче по сети. В данном случае Content-MD5 — это контрольная сумма MD5 данных блока в
запросе. Контрольная сумма проверяется на сервере, в случае несовпадения возвращается
ошибка. Параметр Content-Length (длина содержимого) определяет размер содержимого блока.
Заголовок HTTP-запроса содержит заголовок авторизации, как показано ниже.
PUT http://sally.blob.core.windows.net/movies/MOV1.avi
?comp=block &blockid=BlockId1 &timeout=60
HTTP/1.1 Content-Length: 4194304
Content-MD5: HUXZLQLMuI/KZ5KDcJPcOA==
8
Authorization: SharedKey sally: F5a+dUDvef+PfMb4T8Rc2jHcwfK58KecSZY+l2naIao=
x-ms-date: Mon, 6 Apr 2009 17:00:25 GMT
x-ms-version: 2009-04-14
……… Block Data Contents ………
4.2.2 Примеры REST-запросов PUT Block List
Ниже приведен пример REST-запроса для операции PUT Block List. Обратите внимание, что
используется HTTP-команда PUT. Параметр запроса «?comp=blocklist» указывает на то, что это
операция PUT Block List. Список блоков задается в тексте HTTP-запроса в формате XML, как
показано ниже. Обратите внимание, что значение поля Content-Length в заголовке запроса
соответствует размеру текста запроса, а не размеру создаваемого BLOB-объекта. Заголовок HTTPзапроса содержит заголовок авторизации, как показано ниже.
PUT http://sally.blob.core.windows.net/movies/MOV1.avi
?comp=blocklist &timeout=120
HTTP/1.1 Content-Length: 161213
Authorization: SharedKey sally: QrmowAF72IsFEs0GaNCtRU143JpkflIgRTcOdKZaYxw=
x-ms-date: Mon, 6 Apr 2009 17:00:25 GMT
x-ms-version: 2009-04-14
<?xml version=“1.0” encoding=“utf-8”?>
<BlockList>
<Block>BlockId1</Block>
<Block>BlockId2</Block>
………………
</BlockList>
4.2.3 Примеры REST-запросов GET Blob
Ниже приведен пример REST-запроса для операции GET Вlob. В данном случае используется HTTPкоманда GET. Этот запрос предназначен для извлечения всего содержимого заданного BLOBобъекта. Если для контейнера, которому принадлежит BLOB-объект (в данном примере «movies»),
задана политика совместного использования «Private» («Частный»), то для получения BLOBобъекта необходимо пройти проверку подлинности. Если задана политика совместного
использования «Public-Read» («Общедоступное чтение»), проверка подлинности не требуется и
заголовок авторизации в заголовке запроса не нужен.
GET http://sally.blob.core.windows.net/movies/MOV1.avi
HTTP/1.1
Authorization: SharedKey sally: RGllHMtzKMi4y/nedSk5Vn74IU6/fRMwiPsL+uYSDjY=
x-ms-date: Mon, 6 Apr 2009 17:00:25 GMT
x-ms-version: 2009-04-14
9
Приведенный ниже пример демонстрирует, что операция Range GET позволяет извлекать
диапазон байт заданного BLOB-объекта. Обратите внимание: для запросов GET blob указывать
заголовок версии не обязательно. В приведенном ниже примере заголовок версии отсутствует.
GET http://sally.blob.core.windows.net/movies/MOV1.avi
HTTP/1.1
Range: bytes=1024000-2048000
4.2.4 Примеры REST-запросов Get Block List
Ниже приведен пример REST-запроса для операции GET Block List, обеспечивающей извлечение
списка подтвержденных блоков. Обратите внимание, что используется HTTP-команда GET.
Параметр запроса «?comp=blocklist» определяет, что это операция GET Block List. Параметр
«blocklisttype=committed» указывает, что должен быть извлечен список подтвержденных блоков.
Если этот параметр не задан, список подтвержденных блоков будет возвращен по умолчанию.
GET http://sally.blob.core.windows.net/movies/MOV1.avi
? comp=blocklist&blocklisttype=committed
HTTP/1.1
x-ms-date: Wed, 08 Apr 2009 00:31:26 GMT
x-ms-version: 2009-04-14
Authorization: SharedKey sally:TOfGagLfokWXYXlGJ+R2neNr1+lIeKbURzlRfZR5fso=
Заголовок ответа выглядит следующим образом:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/xml
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0Date: Wed, 08 Apr 2009 00:33:19 GMT
Текст ответа содержит список подтвержденных блоков:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks>
<Block>
<Name>BlockId001</Name>
<Size>4194304</Size>
</Block>
<Block>
<Name>BlockId002</Name>
<Size>4194304</Size>
</Block>
............
</CommittedBlocks>
10
</BlockList>
Рассмотрим пример REST-запроса для извлечения списка неподтвержденных блоков:
GET http://sally.blob.core.windows.net/movies/MOV1.avi
&comp=blocklist&blocklisttype=uncommitted
HTTP/1.1
x-ms-date: Wed, 08 Apr 2009 00:42:36 GMT
x-ms-version: 2009-04-14
Authorization: SharedKey sally:JoqnL0VayI4+wxIGeCVgr85Vm3diHD+Cfe37re3PQqo=
Вызов GET Block List может возвращать список как подтвержденных, так и неподтвержденных
блоков. Пример такого запроса:
GET http://sally.blob.core.windows.net/movies/MOV1.avi
&comp=blocklist&blocklisttype=all
HTTP/1.1
x-ms-date: Wed, 08 Apr 2009 00:42:36 GMT
x-ms-version: 2009-04-14
Authorization: SharedKey sally:JoqnL0VayI4+wxIGeCVgr85Vm3diHD+Cfe37re3PQqo=
Ответ на запрос включает в себя список подтвержденных и неподтвержденных блоков, как
показано в приведенном ниже примере. Обратите внимание, что в этом примере блоки
содержатся как в списке подтвержденных, так и в списке неподтвержденных блоков.
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks>
<Block>
<Name>BlockId001</Name>
<Size>4194304</Size>
</Block>
<Block>
<Name>BlockId002</Name>
<Size>4194304</Size>
</Block>
............
</CommittedBlocks>
<UncommittedBlocks>
<Block>
<Name>BlockId003</Name>
<Size>4194304</Size>
</Block>
<Block>
<Name>BlockId004</Name>
11
<Size>1024000</Size>
</Block>
............
</UncommittedBlocks>
</BlockList>
Порядок следования блоков в полученном списке такой же, как и в списке подтверждения BLOBобъекта, включая возможные дубликаты блоков.
Ассоциированные с BLOB-объектом неподтвержденные блоки возвращаются в порядке, начиная с
переданного последним до переданного первым. ID переданных дубликатов блоков удаляются из
списка. Для данного ID в списке будет указан блок, загруженный последним, и его размер.
4.2.5 Примеры REST-запросов Copy Blob
Рассмотрим пример REST-запроса для операции Copy Blob.
Операция Copy Blob предназначена для копирования содержимого исходного BLOB-объекта A в
целевой BLOB-объект Б. При этом копируются все биты данных, в том числе свойства, метаданные
и список подтвержденных блоков. Список неподтвержденных блоков не копируется и не
затрагивается. После успешного завершения копирования неподтвержденные блоки целевого
BLOB-объекта удаляются. При копировании можно создать новый набор пользовательских
метаданных для целевого BLOB-объекта.
В следующем примере BLOB-объект копируется из контейнера «movies» учетной записи Sally в
другой контейнер, «media». Имя целевого BLOB-объекта задается в URL, указанном в запросе PUT.
Имя исходного BLOB-объекта задано в заголовке запроса «x-ms-copy-source», как показано в
следующем примере.
PUT http://sally.blob.core.windows.net/media/MOV1.avi
HTTP/1.1
x-ms-date: Wed, 08 Apr 2009 00:36:19 GMT
x-ms-copy-source: /sally/movies/MOV1.avi
x-ms-version: 2009-04-14
Authorization: SharedKey sally:KLUKJBAn2WGPSbt8Hg61JjCRFnalLUgOw1vG9kq2/tA=
Операция Copy Blob может также задавать условия для исходного и целевого BLOB-объекта. В
приведенном ниже примере операция копирования выполняется при условии, если исходный
BLOB-объект был изменен после 00:37:02, 8 апреля 2009 г., а целевой объект не менялся с этого
момента.
PUT http://sally.blob.core.windows.net/media/MOV1.avi
12
HTTP/1.1
x-ms-date: Wed, 08 Apr 2009 00:36:19 GMT
x-ms-copy-source: /sally/movies/MOV1.avi
x-ms-meta-comment: birthday party video
x-ms-meta-datetaken: April 5th 2009
x-ms-version: 2009-04-14
x-ms-source-if-modified-since: Wed, 08 Apr 2009 00:37:02 GMT
If-Unmodified-Since: Wed, 08 Apr 2009 00:37:02 GMT
Authorization: SharedKey sally:KLUKJBAn2WGPSbt8Hg61JjCRFnalLUgOw1vG9kq2/tA=
Обратите внимание, что в приведенном примере теги «x-ms-meta-<xxx>» («x-ms-meta-comment» и
«x-ms-datetaken») заменяют метаданные приложения целевого BLOB-объекта новыми
метаданными. В данном случае метаданными приложения целевого BLOB-объекта будут пары
имя-значение <"comment", "birthday party video"> и <"datetaken", "April 5th 2009">.
Если теги «x-ms-meta-<xxx>» не заданы, целевой BLOB-объект полностью скопирует метаданные
приложения из исходного BLOB-объекта.
4.3 Сценарии передачи блоков
Передача BLOB-объекта в виде списка блоков обладает следующими преимуществами:
 Возможность продолжения. Для каждого отдельного блока можно проверить, успешно ли
завершена передача. В случае сбоя можно повторить попытку и продолжить передачу с
этого момента.
 Параллельная передача. Можно передавать блоки параллельно для сокращения времени
загрузки очень больших BLOB-объектов.
 Передача блоков в произвольном порядке. Имеет значение лишь порядок следования
блоков в списке операции PUT Block List. Список блоков PUT Block List определяет порядок
следования блоков, образующий пригодную для чтения версию BLOB-объекта.
 Ассоциация BlockID в качестве метаданных с каждым блоком. При передаче BLOB-объекта
при помощи блоков для подтвержденных блоков сохраняются ID и размеры. Эти данные
могут быть извлечены позже операцией GET Block List. Они могут обрабатываться как
метаданные, ассоциированные с каждым блоком BLOB-объекта. Таким образом, в
качестве части ID блока можно сохранить контрольную сумму MD5 содержимого блока.
Чтобы проверить контрольную сумму MD5 для заданных диапазонов байт, возвращенных
командой GET Вlob, можно получить список блоков при помощи команды GET; затем
получить блоки из заданных диапазонов и проверить MD5 для каждого блока,
полученного с помощью команды GET Вlob для заданных диапазонов.
13
Block Id 2
Block Id 4
Block Id 3
Block Id 4
Block Id 2
Block Id 3
Block Id 4
Block Id 1
PutBlock(BlockId1);
PutBlock(BlockId3);
PutBlock(BlockId4);
PutBlock(BlockId2);
PutBlock(BlockId4);
PutBlockList(BlockId2, BlockId3, BlockId4);
Рис. 3. Сценарий передачи блоков
Используя представленный на рисунке 4 пример, опишем сценарии использования блоков для
передачи BLOB-объектов.

Передача блоков с одинаковыми ID. Если для одного BLOB-объекта передаются блоки с
одинаковыми ID, при выполнении операции PUT Block List для подтверждения BLOBобъекта будет использоваться только блок, переданный последним. В предыдущем
примере передаются два блока с идентификатором BlockId4. Только блок, переданный
последним, будет использован в окончательном списке блоков BLOB-объекта.

Передача блоков в произвольном порядке. Блоки могут передаваться в порядке, отличном
от указанного в окончательном списке блоков BLOB-объекта. В предыдущем примере в
окончательном списке блоки располагаются в порядке BlockId2, BlockId3 и BlockId4, но
передавались они в другой последовательности. Операция GET формирует порядок
блоков в списке PUT Вlock List и образует пригодную для чтения версию BLOB-объекта.
Таким образом, если извлечь и прочитать BLOB-объект от начала до конца, будет получено
содержимое блока BlockId2, затем BlockId3 и BlockId4.

Неиспользуемые блоки. Некоторые блоки могут не войти в окончательный список блоков
BLOB-объекта. Эти блоки будут удалены системой в процессе очистки памяти. В
рассматриваемом примере это BlockId1 и первый блок с ID BlockId4. Точнее говоря, после
14
создания нового BLOB-объекта при помощи операции PUT Block List, все загруженные, но
не вошедшие в список PUT Block List блоки будут удалены как мусор.
Загрузка крупного BLOB-объекта может продолжаться довольно долго. При этом переданные, но
не использованные блоки занимают место в хранилище. Некоторые переданные блоки могут не
войти в список PUT Block List. При отсутствии активности для BLOB-объект в течение длительного
времени (в настоящее время этот период составляет неделю) неиспользованные блоки будут
удалены системой в процессе очистки памяти.
Интересен сценарий параллельной загрузки блоков для одного BLOB-объекта. В этом случае
нужно рассмотреть два вопроса:
 ID блоков. Если для загрузки блоков в один BLOB-объект используется несколько
клиентских модулей, во избежание конфликтов идентификаторы блоков должны быть
уникальными для всех модулей записи или представлять содержимое записываемого
блока. Таким образом, если один и тот же блок записывается несколькими клиентами, ID
блока для всех клиентов будет одинаковым, так как он представляет одни и те же данные.
Во избежание ошибок при записи одного BLOB-объекта несколькими модулями в качестве
ID блока рекомендуется использовать хеш (например, MD5-хеш) содержимого блока.
Таким образом, идентификатор блока представляет его содержимое.
 Приоритет имеет первая фиксация. Если несколько клиентов параллельно передают
блоки для одного BLOB-объекта, приоритет имеет первая фиксация BLOB-объекта PUT
Block List (или модуль записи, вызвавший PUT Вlob первым). Все остальные
неиспользованные блоки, загруженные другими модулями, будут удалены в процессе
очистки памяти. Следовательно, для эффективного обновления BLOB-объекта необходима
координация всех клиентов, ведущих запись параллельно.
4.4 Условные операции PUT и GET и оптимистичный параллелизм
Условные операции PUT и GET предназначены для эффективной поддержки параллелизма и
клиентского кэширования.
Условная операция PUT используется, если один BLOB-объект обновляется несколькими
пользователями. Например, BLOB-объекта может быть загружен условно на основании времени
последнего изменения; это гарантирует, что клиент изменяет ту же самую версию BLOB-объекта.
Таким образом реализуется оптимистичный параллелизм. Например, два клиента А и Б
обновляют один и тот же BLOB-объект. Они считывают текущую версии BLOB-объекта, вносят в нее
изменения и вновь загружают в хранилище. При этом сценарии каждый из клиентов записывает
ETag BLOB-объекта, извлеченного из хранилища. Обновленная версия BLOB-объекта загружается
обратно в хранилище при помощи условной операции PUT на основании последнего
извлеченного ETag. Условием выполнения операции PUT является «ЕСЛИ СОВПАДАЕТ <ETag>».
15
Таким образом, если BLOB-объект изменен другим клиентом, операция обновления будет
завершена неудачно и клиент получит уведомление об этом.
Условная операция GET может использоваться для эффективного определения целостности кэша.
Например, в локальном кэше клиента кэшируются BLOB-объекты, чаще всего извлекаемые из
хранилища. Для каждого кэшированного BLOB-объекта записывается время его последнего
изменения. Для обновления клиентским кэшем BLOB-объекта из хранилища используется
условная операция GET на основании времени изменения (с условием «если изменен с момента
Х»). Таким образом, из хранилища будут скачиваться только BLOB-объекты, измененные с
момента Х и отличающиеся от своей кэшированной копии.
4.5 Параллельные операции PUT и GET для одного BLOB-объекта
Если возникает перекрытие операций GET Blob и PUT Blob, система обеспечивает «изоляцию
моментального снимка». Это означает, что для операции GET будет доступна только одна версия
BLOB-объекта. Данные разных версий BLOB-объекта не смешиваются.
Если для изменения данных BLOB-объекта используется слишком длинный запрос GET, операция
GET может дать сбой и возвратить ошибку «соединение прервано». В этом случае, чтобы
возобновить извлечение данных, клиент должен выполнить условную операцию GET на
основании ETag обрабатываемого BLOB-объекта. Это позволит клиенту отличить сбой сети от
разрыва соединения, вызванного изменением данных BLOB-объекта.
5 Перечисление BLOB-объектов
Система предоставляет интерфейс для перечисления BLOB-объектов контейнера. Поддерживается
иерархический перечень BLOB-объектов контейнера и механизм возобновления, позволяющий
перечислять большое количество BLOB-объектов.
5.1 Иерархический перечень
Интерфейс ListBlobs поддерживает параметры «prefix» («префикс») и «delimiter» («разделитель»)
для построения иерархического перечня BLOB-объектов. Например, учетная запись «sally» имеет
контейнер «movies», содержащий BLOB-объекты с именами:
Action/Rocky1.wmv
Action/Rocky2.wmv
Action/Rocky3.wmv
Action/Rocky4.wmv
Action/Rocky5.wmv
Drama/Crime/GodFather1.wmv
Drama/Crime/GodFather2.wmv
Drama/Memento.wmv
16
Horror/TheBlob.wmv
Символ «/» используется в качестве разделителя для создания каталогоподобной иерархии имен
BLOB-объектов. Чтобы получить список всех «каталогов», нужно задать в запросе ListBlobs
«delimiter=/». Запрос и часть ответа выглядят следующим образом:
Запрос:
GET http://sally.blob.windows.net/movies?comp=list&delimiter=/
Ответ:
<BlobPrefix>Action</BlobPrefix>
<BlobPrefix>Drama</BlobPrefix>
<BlobPrefix>Horror</BlobPrefix>
Обратите внимание: тег «BlobPrefix» указывает на то, что это префикс имени, а не полное имя
BLOB-объекта. Один и тот же префикс возвращается только один раз.
Можно сочетать префикс и разделитель для получения списка содержимого «подкаталога».
Например, для получения списка всех подкаталогов и файлов каталога «Drama», нужно задать
«prefix=Drama/» и «delimiter=/»:
Запрос:
GET http://sally.blob.windows.net/movies?comp=list &prefix=Drama/ &delimiter=/
Ответ:
<BlobPrefix>Drama/Crime</BlobPrefix>
<Blob>Drama/Memento.wmv</Blob>
Обратите внимание, что «Drama/Memento.wmv» — это полное имя BLOB-объекта.
5.2 Разбивка на страницы
Интерфейс ListBlobs позволяет задавать «maxresults», то есть максимальное число результатов,
которое должно быть возвращено в этом вызове. Система определяет максимальное число
результатов, возвращаемых одним вызовом (более подробная информация содержится в
документации по SDK). По достижении меньшего из двух предельных значений вызов
возвращается с соответствующим количеством результатов и непрозрачным «NextMarker»
(маркер следующего). Наличие маркера свидетельствует о том, что этот запрос не обеспечил
возвращение всех возможных результатов. Можно использовать «NextMarker» последнего
вызова, чтобы продолжить составление списка для следующей страницы результатов.
Предположим, что нужно составить список всех BLOB-объектов каталога «Action», возвращая
каждый раз максимум по три результата. В этом случае первый набор результатов будет таким:
Запрос:
17
GET http://sally.blob.windows.net/movies?comp=list &prefix=Action &maxresults=3
Ответ:
<Blob>Action/Rocky1.wmv</Blob>
<Blob>Action/Rocky2.wmv</Blob>
<Blob>Action/Rocky3.wmv</Blob>
<NextMarker> OpaqueMarker1</NextMarker>
С первым набором BLOB-объектов возвращается и непрозрачный маркер, который может быть
передан во второй вызов ListBlobs. Тогда второй вызов вернет следующие результаты:
Запрос:
GET http://sally.blob.windows.net/movies?comp=list &prefix=Action &maxresults=3
&marker=OpaqueMarker1
Ответ:
<Blob>Action/Rocky4.wmv</Blob>
<Blob>Action/Rocky5.wmv</Blob>
<NextMarker></NextMarker>
Получены оставшиеся BLOB-объекты каталога; «NextMarker» пуст, это свидетельствует о том, что
получены все результаты.
6 Передовые практические методы
При проектировании приложения для работы с хранилищем Windows Azure важно правильно
организовать обработку ошибок. В этом разделе рассматриваются вопросы, которые необходимо
учесть при разработке приложения.
6.1 Время ожидания повторных запросов и ошибки «Connection closed by
Host» (соединение прервано узлом)
Запросы, завершившиеся ошибками превышения времени ожидания, или «Connection closed by
Host» (соединение прервано узлом), возможно, не были обработаны хранилищем Windows Azure.
Например, если запрос PUT возвращается в результате превышения времени ожидания,
последующий запрос GET возвратит либо старое, либо обновленное значение. При получении
любого из этих ответов повторите запрос с большим временем ожидания.
6.2 Настройка приложения при многократном возникновении ошибок
превышения времени ожидания
Ошибки превышения времени ожидания могут возникать из-за ошибок сети между приложением
и центром обработки данных. Для глобальной сети рекомендуется разбивать операцию по
передаче большого объема данных на несколько мелких операций. Следует предусмотреть,
чтобы после обработки сбоев (превышения времени ожидания) приложение могло продолжить
работу. Например, вместо того чтобы извлекать сразу весь BLOB-объект размером 1 ГБ, можно
18
получать его диапазонами байт и записывать сведения о ходе выполнения, чтобы возобновить
передачу при разрыве соединения или истечении времени ожидания. При обработке больших
запросов GET приложение должно продолжить выполнение запроса с того диапазона байт, на
котором был завершен предыдущий запрос вследствие превышения времени ожидания или
разрыва соединения.
Другой пример: при составлении списка большого количества BLOB-объектов можно использовать
функцию возобновления, предоставляемую Windows Azure Blob, и получать списки постранично
через серии вызовов ListBlobs. Ограничение размера для каждого запроса устанавливается,
исходя из характеристик сетевого соединения.
Система обеспечивает масштабирование и обработку больших объемов трафика. Однако
чрезвычайно высокая частота запросов может стать причиной возникновения ошибок
превышения времени ожидания. Сократить или устранить ошибки такого рода поможет снижение
частоты запросов. Большинство пользователей редко сталкиваются с ошибками превышения
времени ожидания. Тем не менее, если такие ошибки возникают часто или неожиданно,
обратитесь к нам через форумы Windows Azure на MSDN. Мы поможем вам оптимизировать
работу с хранилищем Windows Azure и предотвратить появление этих ошибок в вашем
приложении.
6.3 Обработка ошибок и составление отчетов
API REST выглядит как стандартный HTTP-сервер, взаимодействующий с HTTP-клиентами
(браузерами, клиентскими библиотеками HTTP, прокси, кэшем и т. д.). Для корректной обработки
ошибок HTTP-клиентами каждой ошибке хранилища Windows Azure поставлен в соответствие
определенный HTTP-код состояния.
HTTP-коды состояния менее выразительные, чем коды ошибок Windows Azure Storage, и содержат
меньше информации об ошибке. Тем не менее клиенты, понимающие HTTP и не понимающие
коды ошибок Windows Azure Storage, обычно обрабатывают ошибки правильно.
Поэтому при обработке ошибок или создании сообщений об ошибках хранилища Windows Azure
для конечных пользователей вместо HTTP-кода состояния следует использовать код ошибки
хранилища Windows Azure, так как он содержит больше сведений об ошибке. Кроме того, при
отладке приложения нужно обращать внимание на предназначенный для пользователя элемент
<ExceptionDetails> XML-сообщения об ошибке.
6.4 Сжатое содержимое
В настоящее время Windows Azure не поддерживает автоматическое сжатие данных при передаче
из приложения в облачное хранилище. Однако приложение может сжать данные перед их
размещением в облаке. Это позволяет эффективно использовать полосу пропускания сети и
19
повысить производительность, особенно если данные легко поддаются сжатию. Обратите
внимание: при передаче BLOB-объекта, сжатого gzip, в заголовке Content-Encoding необходимо
указать «gzip». При извлечении этого BLOB-объекта веб-клиенты будут видеть, что содержимое
сжато, и обрабатывать его должным образом.
6.5 Копирование BLOB-объекта
Операция Copy Blob может использоваться для переименования. Например, чтобы изменить имя
BLOB-объекта A и присвоить ему другое имя Б в рамках той же учетной записи, можно сначала
скопировать А в Б, а затем удалить А. Этот способ пригоден для переименования больших BLOBобъектов в учетной записи хранения.
Команда Copy Blob может также использоваться для создания резервной копии BLOB-объекта и
позволяет отслеживать различные «версии» BLOB-объекта, сохраняя «копии» каждой «версии»
перед созданием новой версии BLOB-объекта.
При копировании данные BLOB-объекта дублируются. Поэтому учетная запись хранения
использует дополнительный объем памяти для каждой создаваемой (резервной) копии BLOBобъекта. Дублирование выполняется в фоновом режиме, чтобы обеспечить быстрое выполнение
запроса Copy Blob. После успешного выполнения запроса Copy Blob исходный BLOB-объект и его
копия рассматриваются как отдельные объекты.
6.6 Использование операции GET Block List для неподтвержденных
блоков
Операция GET Block List может использоваться для извлечения текущего списка
неподтвержденных блоков. Это применяется в ряде сценариев.
1. Клиент может запросить текущий список неподтвержденных блоков для определения
момента, с которого необходимо возобновить операцию, если произошел сбой в процессе
передачи большого BLOB-объекта при помощи вызовов PUT Block.
2. BLOB-объект может передаваться параллельно несколькими клиентами. Операция GET
Block List позволяет отслеживать процесс передачи, проводя проверку текущего списка
неподтвержденных блоков.
3. Пир возникновении сбоя операции PUT Block List из-за отсутствия некоторых блоков в
списке можно сравнить текущий список неподтвержденных блоков с ожидаемым и
выявить недостающие блоки.
6.7 Устойчивость к сбоям
Приложения должны иметь встроенную логику для возобновления работы после сбоев.
Необходимо отслеживать выполнение длительных запросов и возобновлять передачу с момента
сбоя. Например, в сценариях передачи GET Block List API позволяет приложению получать данные
20
о текущем состоянии процесса передачи при помощи списка неподтвержденных блоков и
возобновлять передачу после сбоя. В сценариях скачивания приложение отслеживает, какие части
данных успешно загружены, и может возобновить работу после сбоя.
6.8 Рекомендации по работе с контейнером BLOB-объекта
Контейнеры BLOB-объектов обеспечивают управление общим доступом к данным. Например,
контейнер может быть определен как «Public readable» («Общедоступное чтение»), что позволяет
всем читать его содержимое. Контейнер может быть определен как «Private» («Частный»), то есть
доступ к нему имеет только владелец учетной записи.
Другой распространенный вариант применения контейнеров BLOB-объектов — использование
отдельного контейнера для каждой категории пользователей приложения. В этом случае
абстракция контейнера BLOB-объекта обеспечивает механизм группировки для приложений и
позволяет им независимо управлять каждой группой в отдельности.
Размер контейнера ограничен системой и составляет десятки терабайт для коммерческой версии.
Ограничение касается не количества BLOB-объектов, а числа байт в контейнере. Если требуется
хранить большое количество данных и можно сгруппировать их в разные логические множества,
рекомендуется распределять данные приложения в разные контейнеры.
21