Цель лекции: Ознакомление с новой версией Windows Azure Storage – основной компоненты Windows Azure для управления памятью; с компонентами самой Azure Storage и их возможностями для пользователей.
Презентацию к лекции вы можете скачать здесь.
Windows Azure Storage – компонента для управления памятью в Windows Azure.
Компонента Windows Azure Storage Services обеспечивает устойчивое и надежное хранение информации в облаке.
Для доступа к сервисам Storage необходима учетная запись хранения (storage account), обеспечиваемая через Windows Azure Platform Management Portal .
Основные сервисы памяти включают:
Windows Azure SDK предоставляет REST API (REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов) API и управляемый (managed) API для работы с сервисами памяти (managed API означает, что возможен доступ к Storage из .NET-приложений, см. лекцию 4). Доступ к сервисам Памяти возможен из сервиса, выполняемого в Windows Azure, или непосредственно через Интернет из любого приложения, которое может посылать и принимать данные по протоколам HTTP/HTTPS.
Более подробная информация о REST API для сервисов памяти приведена в документе Windows Azure Storage Services REST API Reference. Информация об управляемом API для сервисов памяти приведена в документе Windows Azure Managed Library Reference.
В новой версии Windows Azure имеется удобная библиотека Azure Client Library с более высокоуровневым API, в частности, для работы с компонентой Storage.
Устойчивость к ошибкам и встроенная сеть CDN
Вся пользовательская информация, хранящаяся в Windows Azure, дублируется три раза. Независимо от того, какую память использует клиент облака, его данные дублируются в нескольких дублирующих областях (fault domains), что обеспечивает большую устойчивость к ошибкам. Windows Azure Content Delivery Network (CDN) обеспечивает интеграцию "в один клик" с сервисами Памяти (Storage). CDN естественным образом улучшает производительность, автоматически размещая информацию пользователя поблизости от того места, где она наиболее часто используется.
REST и Managed API
В дополнение к сервисам Памяти Window Azure для приложений пользователя, выполняемых в Windows Azure, она также может работать с приложениями, выполняемыми на локальной машине или на другой облачной платформе. Скачайте SDK, чтобы получить как REST API (программный интерфейс без состояния), так и управляемый API для работы с сервисами Памяти. Более подробно REST API описан в документации MSDN.
Windows Azure Client Library
В новой версии Azure (2013) разработана библиотека Azure Client Library с более дружественным интерфейсом для создания и обработки элементов Azure Storage.
Объем использованной Памяти в Windows Azure вычисляется на основе Вашего использования ее в среднем (в течение какого-либо оплачиваемого периода какого-либо двоичного объекта, таблицы, очереди, либо Windows Azure Drive storage. Например, если Вы использовали 10 ГБ Памяти за первую половину месяца и ничего не использовали за вторую, Вам предъявят счет на использование (в среднем) 5 ГБ Памяти.
В новой версии Azure предоставляются три сервиса Памяти - таблицы (tables), очереди (queues) и бинарные объекты (blobs).
Каждый сервис имеет программный .NET API и HTTP REST API. REST-узлы сети имеют следующий формат имен:
.[storage,blob,queue].core.windows.net.
Имеются также утилиты командной строки для разработки и сопровождения данных на стадиях их разработки и сопровождения.
Возможности
Таблицы – это структурированные, не требующие описаний в виде схем, масштабируемые хранилища данных, похожие на хранилище данных App Engine. Последняя является распределенной системой, которая по стилю проектирования очень похожа на Bigtable. Она рассчитана на хранение миллиардов объектов и терабайтов данных. Таблица – более эффективный вариант хранения и обработки информации, чем база данных на основе SQL Azure.
Модель сущности в таблице
Каждый объект имеет имя таблицы и набор свойств вида ключ / значение. Явное представление информации о схеме данных не требуется. Ограничения на объекты: максимальный объем – 1 МБайт, максимальное число свойств – 255.
Поддерживаются следующие типы свойств:
Имеется три специальных свойства: ключ раздела (partition key), ключ строки в таблице (row key), и версия (version).
Ключ раздела идентифицирует раздел, т.е. группу объектов, которые должны храниться вместе. Каждый раздел может храниться в отдельной виртуальной машине. Ключ строки идентифицирует объект в разделе. Совокупность (ключ раздела, ключ строки в таблице) является первичным ключом (primary key) для объекта. Ключ раздела и ключ строки оба являются строками размера до 64 КБайт.
Организация таблиц в Windows Azure изображена на рис 6.1.
(рис 6.1) Организация таблиц в Windows Azure
Кроме стандартных операций, таблицы поддерживают некоторую ограниченную форму очередей.
В предыдущей версии поддерживались только отношение равенства для ключей с одним или несколькими свойствами. Результат выдается в лексикографическом порядке, в соответствии с ключом (partition, row). В новой версии поддерживаются вторичные индексы, определяемые пользователем, для сортировки.
API для запросов из программ использует LINQ – упрощенный язык запросов, аналогичный языку запросов GQL, реализованный в Google App Engine. HTTP REST API использует интерфейс Astoria, основанный на использовании URL-адресов для обращения к сервисам для работы с данными ADO.NET.
Таблицы Azure полностью целостны, обращения к одному объекту строго синхронизированы, отсутствуют "dirty reads". Для работы с каждым объектом поддерживаются транзакции в стиле ACID (Asynchronous, Consistent, Isolated, Durable – известная парадигма для описания транзакций).
Таблицы спроектированы аналогично хранилищам данных Bigtable and the App Engine.
Разделы (partitions) аналогичны блокнотам (tablets) Bigtable. Все объекты в разделе хранятся на одном сервере данных.
Транзакции реализованы аналогично App Engine datastore. Используется управление версиями объектов.
Очереди к таблицам аналогичны Amazon SQS. Они позволяют поставить сообщение в очередь и обрабатывать его позже, в слабо связанном виде.
Операции над очередями во время выполнения: enqueue (поставить сообщение в очередь), dequeue (удалить сообщение из очереди), delete (удалить из очереди все сообщения). Сообщения типизированы, из размер – до 8 КБайт.
Операция dequeue использует займы (lease) – средство синхронизации. Займ позволяет в течение определенного заданного интервала времени удерживать сообщение в состоянии, не видимом другим клиентам очереди. По умолчанию время задержки – до 30 секунд.
Сервис blob служит для хранения "непрозрачных" бинарных объектов. Они аналогичны Amazon S3. Бинарные объекты могут создаваться и обрабатываться программным путем. Бинарные объекты идентифицируются уникальными, мнемоничными путями доступа в виде URL-адресов типа:
<account>.blob.core.windows.net
Организация бинарных объектов в Windows Azure изображена на рис 6.2..
(рис 6.2) Организация бинарных объектов в Windows Azure
Бинарные объекты могут быть блочными или страничными. Блоки до 64 МБайт могут обрабатываться непосредственно, большей длины – должны быть разделены на блоки. Каждый блок закачивается на сайт отдельно. В конце операции проверяется, все ли блоки закачаны.
Возможно использование страничных бинарных объектов, размером до 1 TB. Они предназначены для произвольного доступа к памяти.
Пространство имен для бинарных объектов – это иерархический URL-путь вида:
<account>.blob. core.windows.net
Бинарные объекты можно изменять или клонировать, они не являются неизменяемыми.
Память Windows Azure Queue – это сервис для хранения большого числа сообщений, доступ к которому возможен через Web с помощью аутентифицированных вызовов, использующих протоколы HTTP или HTTPS.
Каждое из сообщений в очереди может иметь размер до 64KB.
Очередь может состоять из нескольких миллионов сообщений. Предельный объем учетной записи – 100 TB.
Основные способы использования очередей:
Пример организации очередей в рамках учетной записи Storage приведен на рис 6.3.
(рис 6.3) Пример организации очередей в Windows Azure Storage
Очереди адресуются с использованием следующего URL-формата:
http://<storage account>.queue.core.windows.net/<queue>
В примере на рис 6.3.следующий URL-адрес ссылается на одну из очередей на диаграмме:
http://myaccount.queue.core.windows.net/imagesToDownload
Рассмотрим основы практической работы в Azure Storage в новой версии Windows Azure.
На рис 6.4. показана страница портала управления Azure, визуализирующая информацию об уже существующем Windows Azure Storage account, который был создан автором заранее. Основные операции – создание и удаление учетной записи. Клик на имени учетной записи приведет нас к странице для мониторинга и настройки учетной записи (см. ниже).
(рис 6.4) Информация о существующем Windows Azure Storage account
Попробуем теперь создать еще одну учетную запись. Ресурсы для этого доступны в рамках нашей подписки. На рис 6.5. изображена следующая страница, на которую мы перешли, предлагающая режим быстрого создания учетной записи.
(рис 6.5) Быстрое создание Windows Azure Storage account
Кликнув "Быстро создать", переходим к следующей странице для ввода URL-адреса новой учетной записи (рис 6.6.).
(рис 6.6) Страница для ввода URL-адреса учетной записи Storage
Выбирается имя учетной записи.
Затем выбирается .), где будет осуществляться хранение данных.
(рис 6.7) Выбор территориальной группы для хранения данных
Смысл выбора территориальной группы – выбрать такой центр обработки данных, который территориально наиболее удобен пользователю (например, наиболее географически близок к нему).
В нашем примере территориальная группа уже заранее создана автором, и требуется только ее выбрать. Если территориальной группы нет, ее необходимо создать, выбрав для нее подходящий регион.
Далее, кликнув "Создать учетную запись хранения", к сожалению, убеждаемся, что наша академическая подписка имеет ограничение: вторую учетную запись Storage она создать не позволяет (страница с соответствующим сообщением здесь не показана). Для "чистоты эксперимента" удаляем существующую учетную запись и приходим к состоянию, когда у нас нет ни одной учетной записи. На рис 6.8. показана страница, отображающая это состояние: под надписью ХРАНИЛИЩЕ (Storage) указано число учетных записей, равное нулю. Страница предлагает нам создать учетную запись хранения:
(рис 6.8) Учетных записей хранения нет. Создание новой учетной записи
Кликнув "Создать учетную запись хранения", переходим к следующей странице для ввода URL-адреса учетной записи и выбора для нее территориальной группы (рис 6.9.).
(рис 6.9) Ввод URL-адреса и выбор территориальной группы для учетной записи
Наконец, новая учетная запись хранения создана (рис 6.10.), с тем же именем (saf2), что и раньше:
(рис 6.10) Учетная запись хранения создана
Теперь мы хотели бы создать бинарный объект (BLOB) в новой учетной записи. Поскольку каждый бинарный объект должен содержаться в некотором контейнере, мы должны прежде всего создать контейнер в рамках существующей учетной записи.
Кликнув на имени учетной записи saf2, переходим к странице с меню действий над учетной записью. Выбираем пункт меню "Контейнеры" (сверху справа). Система информирует, что контейнеров в рамках учетной записи пока нет, и проедлагает создать контейнер (рис 6.11.):
(рис 6.11) Создание контейнера для бинарного объекта в учетной записи хранения
Кликнув "Создать контейнер", переходим к странице выбора имени контейнера и режима доступа к нему (рис 6.12.):
(рис 6.12) Выбор имени контейнера и режима доступа к нему
Выбираем имя контейнера safblob1. Предлагаются следующие режимы доступа: "Закрытый", "Общедоступный контейнер", "Общедоступный BLOB-объект". Выбираем последний вариант.
Контейнер для бинарного объекта создан (рис 6.13.):
(рис 6.13) Контейнер для бинарного объекта создан
Обратим внимание на URL-адрес контейнера:
http://saf2.blob.core.windows.net/safblob1
Кликнув на имени контейнера, попытаемся просмотреть его. Система информирует, что контейнер пуст (не содержит бинарного объекта), см. рис 6.14.:
(рис 6.14) Попытка просмотра пустого контейнера
Как уже отмечалось, создать бинарный объект (т.е. наполнить созданный контейнер бинарным объектом) можно программным путем, с помощью REST API, либо с помощью Azure Client Library. Рассмотрение этих возможностей выходит за рамки текущей версии курса.
Далее попытаемся провести мониторинг созданной учетной записи хранения saf2 (рис 6.15.):
(рис 6.15) Переход на страницу мониторинга учетной записи
По умолчанию мониторинг отключен. Чтобы его включить, необходимо перейти на страницу настройки. В нижней части страницы визуализируются URL-адреса конечных точек (endpoints), с помощью которых мы сможем адресовать бинарный объект, таблицу и очередь, когда они будут созданы программным путем в данной учетной записи.
Переходим на страницу настройки учетной записи хранения (рис 6.16.):
(рис 6.16) Настройка учетной записи хранения
Возможна настройка георепликации, т.е. дублирования учетной записи хранения в дополнительном регионе. По умолчанию она включена, что повышает надежность работы с учетными записями хранения.
При попытке включения мониторинга обнаруживаем системную ошибку. Видимо, она связана с тем, что данная учетная запись удалялась и создавалась повторно.
Страница настройки позволяет также настроить ключ доступа к облачной памяти. Кликнув Управление ключами доступа, переходим к соответствующей странице (рис 6.17.):
(рис 6.17) Создание первичного и вторичного ключа доступа
Ключи доступа генерируются по умолчанию. Они служат для защиты облачной памяти. При повторном создании ключей (что рекомендуется делать в целых повышения безопасности) необходимо обновить все облачные виртуальные машины, сервисы и приложения для замены ключей.
Вернувшись к странице с именем учетной записи хранения, получаем трассировочные сообщения (отчеты) о выполнении всех наших операций с учетной записью (рис 6.18.).
(рис 6.18) Отчет о выполнении операций над учетной записью
По личному опыту автора курса, в новой версии Azure достигнут значительный прогресс в реализации Storage. Она стала надежной и полноценной и имеет удобный пользовательский интерфейс.
Для пользователей весьма важно понимать при работе с компонентой Storage, что каждый элемент Памяти Azure – фактически Web-сайт, а не данные в основной памяти компьютера и даже не база данных.
Windows Azure Storage – компонента для управления памятью в Windows Azure.
Windows Azure Client Library – высокоуровневый API в новой версии Windows Azure для создания элементов Storage (бинарных объектов, таблиц, очередей) и их модификации.
Binary Large Object (BLOB) Service, простейший способ хранения бинарных данных в Windows Azure.
REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов
Table Service - поддержка работы с таблицами
Queue Service - поддержка надежного обмена сообщениями между экземплярами Web-ролей и Worker-ролей.
Контейнер – часть учетной записи хранения для размещения бинарного объекта
Подсистема Windows Azure Storage предназначена для управления памятью в Azure. Ее основные компоненты:
Компоненты памяти хранятся в контейнерах, которые можно создать через портал управления Azure.
Для взаимодействия с объектами Памяти (как с Web-сервисами) предоставляется REST API (REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов).
В новой версии Azure имеется также высокоуровневая библиотека Azure Client Library с более удобным программным интерфейсом для управления объектами Памяти.
Для создания учетной записи хранения в Azure (Storage account) необходимо задать ее URL-адрес и использовать подписку на Azure с достаточными квотами.
Возможен мониторинг учетной записи и ее настройка, в частности, георепликация – дублирование учетной записи хранения в дополнительном регионе.
Цель лекции: Ознакомление с новой версией Windows Azure Storage – основной компоненты Windows Azure для управления памятью; с компонентами самой Azure Storage и их возможностями для пользователей.
Презентацию к лекции вы можете скачать здесь.
Windows Azure Storage – компонента для управления памятью в Windows Azure.
Компонента Windows Azure Storage Services обеспечивает устойчивое и надежное хранение информации в облаке.
Для доступа к сервисам Storage необходима учетная запись хранения (storage account), обеспечиваемая через Windows Azure Platform Management Portal .
Основные сервисы памяти включают:
Windows Azure SDK предоставляет REST API (REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов) API и управляемый (managed) API для работы с сервисами памяти (managed API означает, что возможен доступ к Storage из .NET-приложений, см. лекцию 4). Доступ к сервисам Памяти возможен из сервиса, выполняемого в Windows Azure, или непосредственно через Интернет из любого приложения, которое может посылать и принимать данные по протоколам HTTP/HTTPS.
Более подробная информация о REST API для сервисов памяти приведена в документе Windows Azure Storage Services REST API Reference. Информация об управляемом API для сервисов памяти приведена в документе Windows Azure Managed Library Reference.
В новой версии Windows Azure имеется удобная библиотека Azure Client Library с более высокоуровневым API, в частности, для работы с компонентой Storage.
Устойчивость к ошибкам и встроенная сеть CDN
Вся пользовательская информация, хранящаяся в Windows Azure, дублируется три раза. Независимо от того, какую память использует клиент облака, его данные дублируются в нескольких дублирующих областях (fault domains), что обеспечивает большую устойчивость к ошибкам. Windows Azure Content Delivery Network (CDN) обеспечивает интеграцию "в один клик" с сервисами Памяти (Storage). CDN естественным образом улучшает производительность, автоматически размещая информацию пользователя поблизости от того места, где она наиболее часто используется.
REST и Managed API
В дополнение к сервисам Памяти Window Azure для приложений пользователя, выполняемых в Windows Azure, она также может работать с приложениями, выполняемыми на локальной машине или на другой облачной платформе. Скачайте SDK, чтобы получить как REST API (программный интерфейс без состояния), так и управляемый API для работы с сервисами Памяти. Более подробно REST API описан в документации MSDN.
Windows Azure Client Library
В новой версии Azure (2013) разработана библиотека Azure Client Library с более дружественным интерфейсом для создания и обработки элементов Azure Storage.
Объем использованной Памяти в Windows Azure вычисляется на основе Вашего использования ее в среднем (в течение какого-либо оплачиваемого периода какого-либо двоичного объекта, таблицы, очереди, либо Windows Azure Drive storage. Например, если Вы использовали 10 ГБ Памяти за первую половину месяца и ничего не использовали за вторую, Вам предъявят счет на использование (в среднем) 5 ГБ Памяти.
В новой версии Azure предоставляются три сервиса Памяти - таблицы (tables), очереди (queues) и бинарные объекты (blobs).
Каждый сервис имеет программный .NET API и HTTP REST API. REST-узлы сети имеют следующий формат имен:
.[storage,blob,queue].core.windows.net.
Имеются также утилиты командной строки для разработки и сопровождения данных на стадиях их разработки и сопровождения.
Возможности
Таблицы – это структурированные, не требующие описаний в виде схем, масштабируемые хранилища данных, похожие на хранилище данных App Engine. Последняя является распределенной системой, которая по стилю проектирования очень похожа на Bigtable. Она рассчитана на хранение миллиардов объектов и терабайтов данных. Таблица – более эффективный вариант хранения и обработки информации, чем база данных на основе SQL Azure.
Модель сущности в таблице
Каждый объект имеет имя таблицы и набор свойств вида ключ / значение. Явное представление информации о схеме данных не требуется. Ограничения на объекты: максимальный объем – 1 МБайт, максимальное число свойств – 255.
Поддерживаются следующие типы свойств:
Имеется три специальных свойства: ключ раздела (partition key), ключ строки в таблице (row key), и версия (version).
Ключ раздела идентифицирует раздел, т.е. группу объектов, которые должны храниться вместе. Каждый раздел может храниться в отдельной виртуальной машине. Ключ строки идентифицирует объект в разделе. Совокупность (ключ раздела, ключ строки в таблице) является первичным ключом (primary key) для объекта. Ключ раздела и ключ строки оба являются строками размера до 64 КБайт.
Организация таблиц в Windows Azure изображена на рис 6.1.
(рис 6.1) Организация таблиц в Windows Azure
Кроме стандартных операций, таблицы поддерживают некоторую ограниченную форму очередей.
В предыдущей версии поддерживались только отношение равенства для ключей с одним или несколькими свойствами. Результат выдается в лексикографическом порядке, в соответствии с ключом (partition, row). В новой версии поддерживаются вторичные индексы, определяемые пользователем, для сортировки.
API для запросов из программ использует LINQ – упрощенный язык запросов, аналогичный языку запросов GQL, реализованный в Google App Engine. HTTP REST API использует интерфейс Astoria, основанный на использовании URL-адресов для обращения к сервисам для работы с данными ADO.NET.
Таблицы Azure полностью целостны, обращения к одному объекту строго синхронизированы, отсутствуют "dirty reads". Для работы с каждым объектом поддерживаются транзакции в стиле ACID (Asynchronous, Consistent, Isolated, Durable – известная парадигма для описания транзакций).
Таблицы спроектированы аналогично хранилищам данных Bigtable and the App Engine.
Разделы (partitions) аналогичны блокнотам (tablets) Bigtable. Все объекты в разделе хранятся на одном сервере данных.
Транзакции реализованы аналогично App Engine datastore. Используется управление версиями объектов.
Очереди к таблицам аналогичны Amazon SQS. Они позволяют поставить сообщение в очередь и обрабатывать его позже, в слабо связанном виде.
Операции над очередями во время выполнения: enqueue (поставить сообщение в очередь), dequeue (удалить сообщение из очереди), delete (удалить из очереди все сообщения). Сообщения типизированы, из размер – до 8 КБайт.
Операция dequeue использует займы (lease) – средство синхронизации. Займ позволяет в течение определенного заданного интервала времени удерживать сообщение в состоянии, не видимом другим клиентам очереди. По умолчанию время задержки – до 30 секунд.
Сервис blob служит для хранения "непрозрачных" бинарных объектов. Они аналогичны Amazon S3. Бинарные объекты могут создаваться и обрабатываться программным путем. Бинарные объекты идентифицируются уникальными, мнемоничными путями доступа в виде URL-адресов типа:
<account>.blob.core.windows.net
Организация бинарных объектов в Windows Azure изображена на рис 6.2..
(рис 6.2) Организация бинарных объектов в Windows Azure
Бинарные объекты могут быть блочными или страничными. Блоки до 64 МБайт могут обрабатываться непосредственно, большей длины – должны быть разделены на блоки. Каждый блок закачивается на сайт отдельно. В конце операции проверяется, все ли блоки закачаны.
Возможно использование страничных бинарных объектов, размером до 1 TB. Они предназначены для произвольного доступа к памяти.
Пространство имен для бинарных объектов – это иерархический URL-путь вида:
<account>.blob. core.windows.net
Бинарные объекты можно изменять или клонировать, они не являются неизменяемыми.
Память Windows Azure Queue – это сервис для хранения большого числа сообщений, доступ к которому возможен через Web с помощью аутентифицированных вызовов, использующих протоколы HTTP или HTTPS.
Каждое из сообщений в очереди может иметь размер до 64KB.
Очередь может состоять из нескольких миллионов сообщений. Предельный объем учетной записи – 100 TB.
Основные способы использования очередей:
Пример организации очередей в рамках учетной записи Storage приведен на рис 6.3.
(рис 6.3) Пример организации очередей в Windows Azure Storage
Очереди адресуются с использованием следующего URL-формата:
http://<storage account>.queue.core.windows.net/<queue>
В примере на рис 6.3.следующий URL-адрес ссылается на одну из очередей на диаграмме:
http://myaccount.queue.core.windows.net/imagesToDownload
Рассмотрим основы практической работы в Azure Storage в новой версии Windows Azure.
На рис 6.4. показана страница портала управления Azure, визуализирующая информацию об уже существующем Windows Azure Storage account, который был создан автором заранее. Основные операции – создание и удаление учетной записи. Клик на имени учетной записи приведет нас к странице для мониторинга и настройки учетной записи (см. ниже).
(рис 6.4) Информация о существующем Windows Azure Storage account
Попробуем теперь создать еще одну учетную запись. Ресурсы для этого доступны в рамках нашей подписки. На рис 6.5. изображена следующая страница, на которую мы перешли, предлагающая режим быстрого создания учетной записи.
(рис 6.5) Быстрое создание Windows Azure Storage account
Кликнув "Быстро создать", переходим к следующей странице для ввода URL-адреса новой учетной записи (рис 6.6.).
(рис 6.6) Страница для ввода URL-адреса учетной записи Storage
Выбирается имя учетной записи.
Затем выбирается .), где будет осуществляться хранение данных.
(рис 6.7) Выбор территориальной группы для хранения данных
Смысл выбора территориальной группы – выбрать такой центр обработки данных, который территориально наиболее удобен пользователю (например, наиболее географически близок к нему).
В нашем примере территориальная группа уже заранее создана автором, и требуется только ее выбрать. Если территориальной группы нет, ее необходимо создать, выбрав для нее подходящий регион.
Далее, кликнув "Создать учетную запись хранения", к сожалению, убеждаемся, что наша академическая подписка имеет ограничение: вторую учетную запись Storage она создать не позволяет (страница с соответствующим сообщением здесь не показана). Для "чистоты эксперимента" удаляем существующую учетную запись и приходим к состоянию, когда у нас нет ни одной учетной записи. На рис 6.8. показана страница, отображающая это состояние: под надписью ХРАНИЛИЩЕ (Storage) указано число учетных записей, равное нулю. Страница предлагает нам создать учетную запись хранения:
(рис 6.8) Учетных записей хранения нет. Создание новой учетной записи
Кликнув "Создать учетную запись хранения", переходим к следующей странице для ввода URL-адреса учетной записи и выбора для нее территориальной группы (рис 6.9.).
(рис 6.9) Ввод URL-адреса и выбор территориальной группы для учетной записи
Наконец, новая учетная запись хранения создана (рис 6.10.), с тем же именем (saf2), что и раньше:
(рис 6.10) Учетная запись хранения создана
Теперь мы хотели бы создать бинарный объект (BLOB) в новой учетной записи. Поскольку каждый бинарный объект должен содержаться в некотором контейнере, мы должны прежде всего создать контейнер в рамках существующей учетной записи.
Кликнув на имени учетной записи saf2, переходим к странице с меню действий над учетной записью. Выбираем пункт меню "Контейнеры" (сверху справа). Система информирует, что контейнеров в рамках учетной записи пока нет, и проедлагает создать контейнер (рис 6.11.):
(рис 6.11) Создание контейнера для бинарного объекта в учетной записи хранения
Кликнув "Создать контейнер", переходим к странице выбора имени контейнера и режима доступа к нему (рис 6.12.):
(рис 6.12) Выбор имени контейнера и режима доступа к нему
Выбираем имя контейнера safblob1. Предлагаются следующие режимы доступа: "Закрытый", "Общедоступный контейнер", "Общедоступный BLOB-объект". Выбираем последний вариант.
Контейнер для бинарного объекта создан (рис 6.13.):
(рис 6.13) Контейнер для бинарного объекта создан
Обратим внимание на URL-адрес контейнера:
http://saf2.blob.core.windows.net/safblob1
Кликнув на имени контейнера, попытаемся просмотреть его. Система информирует, что контейнер пуст (не содержит бинарного объекта), см. рис 6.14.:
(рис 6.14) Попытка просмотра пустого контейнера
Как уже отмечалось, создать бинарный объект (т.е. наполнить созданный контейнер бинарным объектом) можно программным путем, с помощью REST API, либо с помощью Azure Client Library. Рассмотрение этих возможностей выходит за рамки текущей версии курса.
Далее попытаемся провести мониторинг созданной учетной записи хранения saf2 (рис 6.15.):
(рис 6.15) Переход на страницу мониторинга учетной записи
По умолчанию мониторинг отключен. Чтобы его включить, необходимо перейти на страницу настройки. В нижней части страницы визуализируются URL-адреса конечных точек (endpoints), с помощью которых мы сможем адресовать бинарный объект, таблицу и очередь, когда они будут созданы программным путем в данной учетной записи.
Переходим на страницу настройки учетной записи хранения (рис 6.16.):
(рис 6.16) Настройка учетной записи хранения
Возможна настройка георепликации, т.е. дублирования учетной записи хранения в дополнительном регионе. По умолчанию она включена, что повышает надежность работы с учетными записями хранения.
При попытке включения мониторинга обнаруживаем системную ошибку. Видимо, она связана с тем, что данная учетная запись удалялась и создавалась повторно.
Страница настройки позволяет также настроить ключ доступа к облачной памяти. Кликнув Управление ключами доступа, переходим к соответствующей странице (рис 6.17.):
(рис 6.17) Создание первичного и вторичного ключа доступа
Ключи доступа генерируются по умолчанию. Они служат для защиты облачной памяти. При повторном создании ключей (что рекомендуется делать в целых повышения безопасности) необходимо обновить все облачные виртуальные машины, сервисы и приложения для замены ключей.
Вернувшись к странице с именем учетной записи хранения, получаем трассировочные сообщения (отчеты) о выполнении всех наших операций с учетной записью (рис 6.18.).
(рис 6.18) Отчет о выполнении операций над учетной записью
По личному опыту автора курса, в новой версии Azure достигнут значительный прогресс в реализации Storage. Она стала надежной и полноценной и имеет удобный пользовательский интерфейс.
Для пользователей весьма важно понимать при работе с компонентой Storage, что каждый элемент Памяти Azure – фактически Web-сайт, а не данные в основной памяти компьютера и даже не база данных.
Windows Azure Storage – компонента для управления памятью в Windows Azure.
Windows Azure Client Library – высокоуровневый API в новой версии Windows Azure для создания элементов Storage (бинарных объектов, таблиц, очередей) и их модификации.
Binary Large Object (BLOB) Service, простейший способ хранения бинарных данных в Windows Azure.
REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов
Table Service - поддержка работы с таблицами
Queue Service - поддержка надежного обмена сообщениями между экземплярами Web-ролей и Worker-ролей.
Контейнер – часть учетной записи хранения для размещения бинарного объекта
Подсистема Windows Azure Storage предназначена для управления памятью в Azure. Ее основные компоненты:
Компоненты памяти хранятся в контейнерах, которые можно создать через портал управления Azure.
Для взаимодействия с объектами Памяти (как с Web-сервисами) предоставляется REST API (REST, Representational State Transfer – один из стандартов разработки Web-сервисов, основанный на передаче информации о состоянии через аргументы и результаты методов).
В новой версии Azure имеется также высокоуровневая библиотека Azure Client Library с более удобным программным интерфейсом для управления объектами Памяти.
Для создания учетной записи хранения в Azure (Storage account) необходимо задать ее URL-адрес и использовать подписку на Azure с достаточными квотами.
Возможен мониторинг учетной записи и ее настройка, в частности, георепликация – дублирование учетной записи хранения в дополнительном регионе.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.