Azure Services Platform. Часть 2

Цель данной лекции – получить представление об архитектуре Windows Azure

Azure Blob Services

Для работы с Windows Azure Storage пользователь должен создать учетную запись хранилища. Выполняется это через веб-интерфейс портала Windows Azure Portal. При создании учетной записи пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса. Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации через проверку достоверности подписи HMAC

Благодаря Windows Azure Blob приложения получают возможность хранения в облаке больших объектов, до 50 ГБ каждый. Он поддерживает высоко масштабируемую систему больших двоичных объектов ( blob ), в которой наиболее часто используемые blob распределяются среди множества серверов для обслуживания необходимых объемов трафика. Более того, эта система характеризуется высокой надежностью и длительностью хранения. Данные доступны в любой момент времени из любой точки планеты и продублированы, по крайней мере, трижды для повышения надежности. Кроме того, обеспечивается строгая согласованность, что гарантирует немедленную доступность объекта при его добавлении или обновлении: все изменения, внесенные в предыдущей операции записи, немедленно видны при последующем чтении.

Рассмотрим модель данных Azure Blob. На рисунке ниже представлено пространство имен Windows Azure Blob.

• Учетная запись хранилища – Любой доступ к Windows Azure Storage осуществляется через учетную запись хранилища
  • Это самый высокий уровень пространства имен для доступа к объектам blob.
  • Учетная запись может иметь множество контейнеров Blob
    

    
    Рис. 7.1. Общее представление хранилища Blob
• Контейнер Blob – Контейнер обеспечивает группировку набора объектов blob. Область действия имени контейнера ограничена учетной записью.
  • Политики совместного использования задаются на уровне контейнера. В настоящее время поддерживаются "Public READ" (Открытое чтение) и "Private" (Закрытый). Если для контейнера определена политика "Public READ", все его содержимое открыто доступно для чтения без необходимости аутентификации. Политика "Private" означает доступ с аутентификацией, т.е. только владелец соответствующей учетной записи имеет доступ к объектам blob этого контейнера.
  • С контейнером могут быть ассоциированы метаданные, которые задаются в виде пар <имя, значение>. Максимальный размер метаданных контейнера – 8КБ.
  • Существует возможность получения списка всех объектов blob контейнера.
• Blob – Объекты blob хранятся в контейнерах Blob Container и их область действия ограничена этими контейнерами. Каждый blob может быть размером до 50ГБ и имеет уникальное в рамках контейнера строковое имя. С blob могут быть ассоциированы метаданные, которые задаются в виде пар <имя, значение> и могут достигать размера 8КБ для blob. Метаданные blob могут быть получены и заданы отдельно от данных blob.

Для доступа к Windows Azure Blob используется приведенные выше подходы. URI конкретного blob структурирован следующим образом:

http://<учетнаязапись>.blob.core.windows.net/<контейнер>/<имяblob>

Первая часть имени хоста образована именем учетной записи хранилища, за которым следует ключевое слово "blob". Это обеспечивает направление запроса в часть Windows Azure Storage, которая обрабатывает запросы blob. За именем хоста идет имя контейнера, "/" и затем имя blob. Существуют ограничения именования учетных записей и контейнеров (подробнее об этом рассказывается в документе Windows Azure SDK). Например, имя контейнера не может включать символ "/".

Еще несколько замечаний по поводу контейнеров:

• Как говорилось выше, область действия контейнеров ограничена учетной записью, которой они принадлежат. Контейнеры хранятся распределено, что устраняет вероятность возникновения "узких мест" для трафика при работе с ними.
• Возможна задержка при воссоздании контейнера, который был недавно удален, особенно если в этом контейнере находилось большое количество объектов blob. Система должна очистить объекты blob этого контейнера, прежде чем контейнер с таким же именем сможет быть создан вновь. Пока сервер удаляет все объекты blob, попытки создания контейнера с таким же именем будут оканчиваться неудачей с формированием ошибки, указывающей на то, что контейнер находится в процессе удаления.
• Команды на удаление или создание совершенно нового контейнера быстро передаются на сервер, и приложению возвращается подтверждение об их выполнении, даже если операция удаления занимает некоторое время.

Рассмотрим интерфейс 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.

Все эти операции с blob – Put, Get и Delete, – могут быть выполнены с использованием следующего URL:

http://<учетнаязапись>.blob.core.windows.net/<контейнер>/<имяblob>

Один запрос PUT обеспечивает возможность загрузки в облако blob размером до 64 МБ. Для загрузки blob, размер которого превышает 64 МБ, используется технология загрузки блоками, описываемый в следующем разделе.

Полное описание всех API REST можно найти в документе Windows Azure SDK.

Один из целевых сценариев Windows Azure Blob – эффективная загрузка объектов blob, размером десятки гигабайт. Windows Azure Blob обеспечивает это следующим образом:

Загружаемый Blob (например, Movie.avi) разбивается на последовательные блоки. Например, ролик размером 10ГБ может быть разбит на 2500 блоков по 4МБ, при этом первый блок будет представлять диапазон байтов данных от 1 до 4194304, второй блок – от 4194305 до 8388608 и т.д.

• Каждому блоку присваивается уникальный ID/имя. Область действия этого уникального ID ограничена именем загружаемого blob. Например, первый блок может быть назван "Block 0001", второй – "Block 0002" и т.д.
• Каждый блок размещается в облаке. Для этого используется операция PUT с указанием представленного выше URL с запросом, определяющим, что это операция размещения блока, и ID блока. Продолжая пример, при размещении первого блока будет указано имя blob "Movie.avi" и ID блока "Block 0001".
• Когда все блоки размещены в Windows Azure Storage, передается список загруженных блоков, чтобы представить blob, с которым они ассоциированы. Выполняется это с помощью операции PUT с указанием представленного выше URL с запросом, определяющим, что это команда blocklist. После этого HTTP-заголовок включает список блоков, которые должны использоваться в этом blob. В случае успешного завершения этой операции получаем список блоков, представляющий пригодную для чтения версию blob. Теперь blob может быть считан с помощью описанной выше команды GET Blob.

На следующем рисунке представлено место блоков в концепции данных Windows Azure Blob.

Рис. 7.2. Общее представление хранилища Blob, добавление блоков

Как описывалось ранее, доступ к объектам blob может осуществляться посредством операций PUT и GET с использованием следующего URL:

http://<учетнаязапись>.blob.core.windows.net/<контейнер>/<имяblob>

В примере, представленном на рисунке 7.2, рисунки со следующими URL могут быть размещены одной операцией PUT:

http://sally.blob.core.windows.net/pictures/IMG001.JPG

http://sally.blob.core.windows.net/pictures/IMG002.JPG