Skip to content
June 18, 2012 / ahriman hpc mode

Пояснения по нововведениям в Windows Azure: сервисы хранилища. Ч.2.

Сервисы хранилища. Ч. 1

Продолжаем разбирать нововведения.

В этой части: снижение цен, Shared Access Signatures для таблиц и очередей, кросс-аккаунтовое копирование и усовершенствованный механизм лизинга блобов, изменение в API.

В следующих частях: подробно про Shared Access Signatures, подробно и с кодом про копирование блобов между несколькими аккаунтами.

Новые фичи

С выходом новой версии REST API “2012-02-12” были соответствующим образом, во-первых, обновлена клиентская библиотека для Java и выпущен CTP клиентской библиотеки .NET (исходники библиотеки). К новым фичам, внедренным в платформу, относятся:

  • Копирование блобов между аккаунтами – теперь блобы можно асинхронно (раньше это была синхронная операция) копировать между аккаунтами хранилища, однако есть ограничение – работать это будет только если аккаунт хранилища, куда копируется блоб, создан после 7 июня 2012 года. В предыдущей версии блоб можно было копировать из одного контейнера в другой в пределах одного аккаунта хранилища.
    • Примечание: для того, чтобы с помощью REST API скопировать блоб, нужно указать полный URL блоба-источника (http[s]://аккаунтхранилища.имяконтейнераблобов.имяблоба[?snapshop=значениеснапшота]). Раньше можно было указать просто имяконтейнераблобов/имяблоба[?snapshot=значениеснапшота]”.
    • Примечание: для кросс-аккаунтового копирования блоб-источник должен иметь права как public access, то есть должен быть расположен в контейнере блобов с ACL, установленным в public, либо, если всё же необходимо перенести блоб, находящийся в контейнере с ACL, установленным в private, придется в URL блоба использовать подписанный URL (Shared Access Signature), предоставляющий права на чтение блоба.
    • Примечание: условия того, что блоб-источник должен размещен в хранилищзе Windows Azure, НЕТ. То есть, если у вас блоб лежит где-нибудь в Amazon S3 и публично доступен или доступен с подписанным URL, его можно скопировать в Windows Azure без скачивания. Таким образом, появляется отличный сценарий резервирования данных в Windows Azure, если основные данные находятся у другого провайдера.
    • Примечание: за траффик производится оплата в том случае, если аккаунты хранилища находятся в разных датацентрах.
    • Примечание: операция копирования между аккаунтами сохраняет тип блоба – блочный остается блочным, страничный – страничным, если же типы различаются (если блоб уже существует), возвращается ошибка 400 (Bad Request). Если блоб в месте назначения существует, он перезаписывается.
    • Примечание: с введением асинхронности операции теперь сервис блобов работает по механизму планировщика – возвращает ответ успеха 202 (Accepted), который означает, что операция встала в план, но не означает, что она была завершена (в отличие от ранней версии, когда код успешного завершения возвращался только после окончания копирования и был равен 201 Created). Сначала же, при инициировании процесса копирования система сначала проверяет существование блоба-источника и наличие доступа к нему. При отсутствии одного из условий возвращается ошибка 400 (Bad Request), при успехе происходит проверка, которая в случае ошибки возвращает ошибку 412 (Precondition Failed). При этом необходимо отметить, что в один момент времени для конкретного URL блоба может быть только одна запланированная операция копирования, но для блоба-источника – несколько. Если при проверке наличия запланированной операции обнаруживается, что таковая имеется, возвращается ошибка 409 (Conflict). После проверок происходит запуск процесса копирования и постановка его в планировщик.
      • Примечание к процессу асинхронного копирования: блочные блобы-источники забираются кусками по 4 мегабайта и асинхронно копируются в контейнер назначения, страничные же загружаются по диапазонам. Если во время копирования произошла ошибка типа обрыва соединения, ошибка будет записана в свойство x-ms-copy-status-description.
    • Примечание: SLA в этом контексте нет, поэтому доподлинно неизвестно, насколько быстро будет скопирован блоб.
    • Примечание: запланированная операция копирования "живет" две недели, после чего отменяется.
    • Примечание: при запланированной на блобе операции копирования любая попытка модификации, создания снапшота или лизинга его блоба-копии назначения возвратит ошибку.
    • Операция копирования имеет несколько специфичных для нее свойств, которые можно получить, используя функции Get Blob Properties, Get Blob или List Blobs.

x-s-copy-status (или CopyStatus)

Текущий статус операции копирования: pending (поставлено в план), success (завершена успешно), aborted (аварийно завершена клиентом), failed (не завершена из-за возникшей ошибки)

x-ms-copy-id (CopyId)

ID операции копирования, который можно использовать для мониторинга процесса копирования или его отмены

x-ms-copy-status-description (CopyStatusDescription)

Расширенная информация об ошибках

x-ms-copy-progress (CopyProgress)

Прогресс копирования блоба в формате X/Y, где X – количество скопированных байт, Y – всего байт

x-ms-copy-completion-time (CopyCompletionTime)

Время завершения последней операции копирования

  • Лизинг блобов – теперь лизинг доступен и для контейнеров блобов (ранее – только для блобов) и позволяет выставить как неограниченный период лизинга, так и период от 15 до 60 секунд. Можно также менять ID активного лизинга и использовать этот ID при попытке получения лизинга. Поясню, что имеется в виду под всеми этими словами. Функциональность лизинга подразумевает под собой получение эксклюзивного лока на блобе и, таким образом, ограничения его модификации или удаления другим клиентом. Кроме этого, Steve Marx написал отличный пост о том, как с помощью лизинга красиво реализовать concurrency: http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases. Что касается длительности лизинга – ранее можно было ставить длительность лизинга максимум в 1 минуту, при этом этот лимит был хуком в системе (насколько я понимаю, чуть ли не хард-кодом).
    • Примечание: при попытке получения лизинга на блобе нужно указать длительность лизинга, если же она не указана, будет возвращена ошибка 400 (Bad Request) – до нововведений длительность лизинга была зафиксирована на 60 секундах и указывать ее при получении лизинга не было необходимости.
    • Примечание: после освобождения лизинга он не может быть прерван или обновлен – будет возвращена ошибка 409 (Conflict) – до нововведений это делать можно было.
    • Примечание: теперь операцию Break Lease можно вызывать на прерывающимся или уже прерванном лизинге – до нововведений, если лизинг уже был прерван, новая операция Break Lease на этом лизинге возвратила бы ошибку 409 (Conflict).
    • Примечание: при попытке получения лизинга, если предоставляемый ID лизинга совпадает с существующим лизингом на блобе, лизинг будет получен. Если при указанном ID лизинга операция получения лизинга выполнится на сервере, но в результате какой-нибудь ошибки ответ не будет передан клиенту (то есть клиент не будет знать, получил ли он лизинг или нет), тогда клиент сможет снова выполнить операцию получения лизинга с указанным ID лизинга и получить ответ, зная, что лизинг всё ещё активен.

А теперь немного кода от команды разработки. В коде ниже получается лизинг с указанным ID лизинга, на 30 секунд, после чего в этом же коде снова получается лизинг, понижающий длительность лизинга до 15 секунд

CloudBlobClient client = storageAccount.CreateCloudBlobClient();

CloudBlobContainer container = client.GetContainerReference(containerName);

CloudBlockBlob blob = container.GetBlockBlobReference(blobName);

// получение лизинга на 30 секунд с указанием определенного

// ID лизинга. Если мы укажем null вместо длительности, лизинг не будет иметь

// временных ограничений. 

blob.AcquireLease(TimeSpan.FromSeconds(30), leaseId);

// получение лизинга ещё раз, но переопределение

// длительности лизинга на 15 секунд 

blob.AcquireLease(TimeSpan.FromSeconds(15), leaseId); 

Как уже упоминалось в примечаниях, теперь можно менять ID лизинга, передав существующий ID операции Change Lease и указав новый ID. Нужно это, как пишет команда разработки, в тех ситуациях, когда необходимо перевести лизинг во владение из одного компонента в другой вашей системы. Например, первый компонент владеет лизингом на блобе, но нужно сделать так, чтобы второй компонент мог получать доступ к этому блобу. Второй компонент может использовать текущий ID лизинга первого компонента, поменять его на новый ID, выполнить необходимые операции, потом сменить ID лизинга на старый, что позволит второму компоненту временно получить эксклюзивный доступ на блоб, модифицировать его и передать эксклюзивный доступ обратно.

Ниже приведен код смены ID лизинга.

string newLeaseId = Guid.NewGuid().ToString();

blob.ChangeLease(
// новый ID лизинга
newLeaseId, 
// leaseId - ID, полученный от первого компонента 

AccessCondition.GenerateLeaseCondition(leaseId));

// переопределение длительности лизинга на период, нужный второму компоненту

// для выполнения своих операций

blob.AcquireLease(TimeSpan.FromSeconds(30), newLeaseId);

Перейдем к прерыванию лизинга. Эта операция используется для освобождения активного лизинга, знать же ID активного лизинга необязательно – до нововведений операция Break Lease позволяла додержать лизинг до момента окончания длительности лизинга, сейчас же это до сих пор так в стандартной ситуации, но можно также указать момент, когда лизинг будет прекращен. Момент-период прекращения лизинга может быть равен от 0 до 60 секунд.

// Если длительность лизинга указана как null, это значит, что лизинг будет активен

// всё оставшееся ему время 

blob.BreakLease(TimeSpan.FromSeconds(20)); 

В новой версии можно задавать лизинг, не ограниченный по времени, указав длительность лизинга как -1 либо null.

blob.AcquireLease(null /* бесконечный лизинг */, leaseId);

// Примечание: можно снова вызвать функцию получения лизинга,

// указав новое значение длительности лизинга

Лизинг для контейнера был добавлен в новой версии, при этом удерживание лизинга контейнера не предотвращает выполнения операций добавления, удаления или обновления блобов в контейнере другими клиентами, но защищает контейнер от удаления его самого. С лизингом контейнера можно выполнять те же операции, что и с лизингом блобов – получение лизинга, изменение лизинга, обновление, освобождение и прерывание.

Лизинг контейнеров можно использовать в ситуации миграции данных из одного контейнера в другой, позволяя выполнять процесс передачи данных одному клиенту, но не нескольким.

CloudBlobClient client = storageAccount.CreateCloudBlobClient();

// каждому клиенту(задаче) миграции назначается

// ID определенного экземпляра, который будет использоваться как ID лизинга

string leaseId = instanceId; 

IEnumerable<CloudBlobContainer> containerList = client.ListContainers();

foreach (CloudBlobContainer container in containerList)

{

try

{

container.AcquireLease(null /* Infinite lease */, leaseId);
// если ОК - запустить процесс миграции, который по завершению миграции

//удалит контейнер 

…

}

catch (Exception e)

{

// обработка исключений, связанных с лизингом

}

}

Каждый лизинг имеет собственный набор свойств, который возвращается при использовании функций List Containers, List Blobs, Get Container Properties, Get Blob Properties и Get Blob.

x-ms-lease-status (или LeaseStatus)

статус лизинга блоба или контейнера – locked/unlocked

x-ms-lease-state (или LeaseState)

состояние лизинга блоба или контейнера – available,leased,expired,breaking,broken

x-ms-lease-duration (или LeaseDuration)

тип лизинга – неограниченный либо ограниченный по времени

  • Shared Access Signatures для таблиц и очередей. Shared Access Signatures (подписанные ссылки) для таблиц и очередей – ранее SAS были доступны только для блобов, что позволяло хозяинам аккаунтов хранилища выдавать определенным образом подписанные URL для обеспечения доступа к блобам. Теперь же SAS доступны и для таблиц и очередей в добавление к блобам и контейнерам. До момента внедрения этой фичи для того, чтобы совершить что-то из CRUD с таблицей или очередью, необходимо было быть хозяином аккаунта. Теперь же можно предоставить другому человеку ссылку, подписанную SAS, и предоставить какие надо права. Функциональность SAS в этом и заключается – детальный контроль доступа к ресурсам.
    • Примечание: можно дать доступ ко всем данным таблицы либо диапазону данных, что полезно, если у вас многопользовательское приложение и данные каждого пользователя хранятся в отдельной таблице (можно дать пользователю сгенерированный SAS-токен, выданный на диапазон таблицы) и если у вас опять же многопользовательское приложение, но данные хранятся в одной таблице – тогда SAS замечательно подходит для выдачи прав каждому пользователю на соответствующий диапазон данных. При этом, естественно, права разделены на основные операции – чтение (r), добавление (a), обновление (u) и удаление данных и комбинировать их в пределах одной SAS можно как угодно.
    • Примечание: можно определить период действия токена доступа.
    • Примечание: можно сгенерировать SAS-токен с политикой доступа либо без оной.
    • Всё вышеперечисленное относится и к очередям.
  • Shared Access Signatures для блобов. В дополнение к уже описанным выше фичам, связанным с SAS, команда разработки внесла изменения и в уже имеющийся механизм SAS для блобов. Теперь токен SAS, который создан без политики доступа, не имеет ограничения на время валидности (раньше оно было равным одному часу).

Что касается изменений в части Storage API, то они сведены в таблицу ниже.

Название функции

Назначение

Ссылка на MSDN

Copy Blob

Копирует блоб из одного контейнера блобов в другой в пределах одного аккаунта хранилища или во внешний

Тут

Lease Blob

Предоставляет эксклюзивный лок на блобе, ограничивая операции записи или удаления

Тут

Abort Copy Blob

Отменяет текущую операцию копирования блоба (Copy Blob), оставляя блоб в месте назначения с нулевой длиной и полный набором метаданных

Тут

Lease Container

Предоставляет эксклюзивный лок на контейнере блобов, ограничивая операции записи или удаления

Тут

Get Table ACL

Возвращает информацию о политиках доступа, определенных для таблицы и которые можно использовать для генерации токенов SAS

Тут

Set Table ACL

Определяет политики доступа для таблицы

Тут

Get Queue ACL

Возвращает информацию о политиках доступа, определенных для очереди и которые можно использовать для генерации токенов SAS

Тут

Set Queue ACL

Определяет политики доступа для очереди

Тут

Снижение цен

Особо комментировать нечего – произошло снижение цен за транзакции хранилища с $0.01 за 10.000 транзакция до $0.01 за 100.000 транзакций (на 90%).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: