Что такое windows azure blob

Windows Azure Storage — архитектура

WAS – система облачного хранилища, предоставляющая клиентам возможность хранить практически неограниченные объёмы данных в течение любого периода времени. WAS была представлена в production-версии в ноябре 2008. Ранее она использовалась для внутренних целей Microsoft для таких приложений, как, например, хранение видео, музыки и игр, хранения медицинских записей и др. Статья написана по мотивам работы с сервисами хранилища и посвящена принципам работы этих сервисов.

Клиенты WAS имеют доступ к свои данным отовсюду в любое время и платят только за то, что используют и хранят. Хранящиеся в WAS данные используют как локальную, так и географическую репликацию для реализации восстановления после серьезных сбоев. На данный момент хранилище WAS состоит из трёх абстракций – блобов (файлов), таблиц (структурированного хранилища) и очередей (доставка сообщений). Эти три абстракции данных покрывают необходимость в различных типах хранимых данных для большинства приложений. Обычным сценарием использования является сохранение данных в блобах, с помощью очередей же происходит передача данных в эти блобы, промежуточные же данные, состояние и подобные временные данные сохраняются в таблицах либо блобах.

• Строгая согласованность – множество клиентов хотят иметь строгую согласованность, особенно это касается корпоративных клиентов, переносящих инфраструктуру в облако. Они также хотят иметь возможность совершать операции чтения, записи и удаления согласно некоторым условиям для оптимистичного контроля над строго согласованными данными – для этого Windows Azure Storage предоставляет то, что CAP-теоремой (Consistency, Availability, Partition-tolerance) описывается как сложнодостижимое в один момент времени: строгую согласованность, высокую доступность и Partition Tolerance.
• Глобальные и высокомасштабируемые пространства имён – для упрощения использования хранилища в WAS реализовано глобальное пространство имен, которое позволяет хранить данные и обращаться к ним из любой точки земного шара. Так как одной из главных целей WAS является предоставление возможности хранения больших массивов данных, это глобальное пространство имен должно быть способным адресовать экзабайты данных.
• Восстановление после сбоев – WAS сохраняет данные клиентов в нескольких датацентрах, которые расположены за несколько сотен километров друг от друга, и эта избыточность предоставляет эффективную защиту от потери данных из-за различных ситуаций, таких как землетрясения, пожары, торнадо и так далее.
• Мультитенантность и стоимость хранилища – для сокращения стоимости хранилища множество клиентов обслуживаются из одной разделяемой инфраструктуры хранилища, и WAS с помощью этой модели, когда хранилища множества различных клиентов с различными необходимыми им объёмами хранилища группируются в одном месте, существенно снижает общий необходимый объем предоставляемого хранилища, чем если бы WAS выделял отдельное оборудование каждому клиенту.

AccountName – имя аккаунта хранилища, выбранное клиентом, является частью DNS-имени. Эта часть используется для нахождения главного кластера хранилища и, собственно, датацентра, в котором хранятся необходимые данные и куда необходимо посылать все запросы на данные для этого аккаунта. Клиент в одном приложении может использовать несколько имен аккаунтов и хранить данные в совершенно различных местах.
PartitionName — имя партиции, определяющее расположение данных при получении запроса кластером хранилища. PartitionName используется для вертикального масштабирования доступа к данным по нескольким узлам хранилища в зависимости от трафика.
ObjectName – если в партиции множество объектов, для уникальной идентификации объекта используется ObjectName. Система поддерживает атомарные транзакции для объектов в пределах одной PartitionName. Значение ObjectName опционально, для некоторых типов данных PartitionName может уникально идентифицировать объект внутри аккаунта.
В WAS можно использовать для блобов полное имя блоба в качестве PartitionName. В случае таблиц необходимо учитывать, что каждая сущность в таблице имеет первичный ключ, состоящий из PartitionName и ObjectName, что позволяет группировать сущности в одну партицию для осуществления атомарной транзакции. Для очередей PartitionName является значение имени очереди, каждое сообщение же, помещённое в очередь, имеет собственное ObjectName, уникально идентифицирующее сообщение в пределах очереди.

Архитектура WAS

Fabric-контроллер занимается управлением, мониторингом, обеспечением отказоустойчивости и многими другими задачами в датацентре. Это механизм, который знает обо всём, что происходит в системе, начиная с сетевого подключения и заканчивая состоянием операционных систем на виртуальных машинах. Контроллер постоянно поддерживает связь с собственными агентами, установленными на операционных системах и посылающих полную информацию о том, что происходит с этой операционной системой, включая версию ОС, конфигурации сервиса, пакеты конфигурации и так далее. Что касается хранилища, то Fabric Controller выделяет ресурсы и управляет репликацией и распределением данных по дискам, а также балансировкой нагрузки и трафика. Архитектура Windows Azure Storage представлена на рисунке 1.

Рис. 1. Архитектура Windows Azure Storage

Storage Stamp (SS). Под этим термином подразумевается кластер, состоящий из N реков (rack) узлов хранилища, где каждый рек находится в собственном домене ошибок с избыточной мощностью сети и питания. Кластера обычно имеют в своем составе от 10 до 20 реков с 18 узлами на рек, при этом первое поколение Storage Stamp-ов содержало около 2 петабайт. Следующее – до 30 петабайт. Storage Stamp также стараются делать наиболее используемым, то есть процент использования каждого SS должен быть равен примерно 70 в терминах использования емкости, количества транзакций и пропускной способности, но не более 80, так как должен быть резерв для более эффективного выполнения дисковых операций. Как только использование SS доходит до 70%, Location Service мигрирует аккаунты на другие SS, используя меж-SS-репликацию.
Location Service (LS). Данный сервис управляет всеми SS и пространствами имён для аккаунтов для всех SS. LS распределяет аккаунты по SS и реализует балансировку нагрузки и другие задачи по управлению. Сам же сервис распределён по двум географически разделенным местам для собственной же безопасности.
Stream Layer (SL). Данный слой хранит данные на диске и отвечает за распределение и репликацию данных по серверам для сохранения данных внутри SS. SL можно рассматривать как слой распределенной файловой системы внутри каждого SS, понимающего файлы (“streams”), как хранить эти файлы, реплицировать и так далее. Данные хранятся на SL, но доступны с Partition Layer. SL предоставляет, по сути, некоторый интерфейс, используемый только PL, и файловую систему с API, позволяющую выполнять операции записи только типа Append-Only, что даёт возможность PL открывать, закрывать, удалять, переименовывать, читать, добавлять части и объединять большие файлы “streams”, упорядоченные списки больших кусков данных, называемых “extents” (рис. 2).

Рис. 2. Наглядное изображение Stream, состоящего из экстентов

Stream может содержать несколько указателей на экстенты, и каждый экстент содержит набор блоков. При этом экстенты могут быть «запечатаны» (sealed), то есть добавлять к ним новые куски данных нельзя. Если происходят попытки чтения данных из Stream, то данные будут получены последовательно от экстента Е1 к экстенту Е4. Каждый stream рассматривается Partition Layer как один большой файл, и содержание Stream может быть изменено или прочтено в random-режиме.
Блок. Минимальная единица данных, доступная для записи и чтения, которая может быть до определенного N байт. Все записываемые данные записываются в экстент в виде одного или более объединённых блоков, при этом блоки не обязаны быть одного размера.
Экстент. Экстентами называются единицы репликации на Stream Layer, и по умолчанию в Storage Stamp хранится три реплики для каждого экстента, хранящегося в NTFS-файле и состоящего из блоков. Размер экстента, используемого Partition Layer, равен 1 гб, меньшие же объекты дополняются Partition Layer к одному экстенту, а порой и к одному блоку. Для хранения очень больших объектов (например, блобов), объект разбивается Partition Layer на несколько экстентов. При этом, разумеется, Partition Layer следит за тем, к каким экстентам и блокам принадлежат какие объекты.

Stream Manager (SM). Stream Manager отслеживает пространство имён stream-ов, управляет состоянием всех активных stream и экстентов и их расположением между Extend Node, следит за здоровьем всех Extend Node, создаёт и распределяет экстенты (но не блоки – о них Stream Manager ничего не знает), а также осуществляет ленивую перерепликацию экстентов, реплики которых были потеряны из-за аппаратных ошибок или просто недоступных и собирает «мусорные экстенты». Stream Manager периодически опрашивает и синхронизирует состояние всех Extend Node и экстенты, которые они хранят. Если SM обнаруживает, что экстент разреплицирован на менее чем ожидаемое количество EN, SM производит перерепликацию. При этом объем состояния, если его так можно назвать, может быть достаточно мал для того, чтобы умещаться в памяти одного Stream Manager. Единственным потребителем и клиентов Stream Layer является Partition Layer, и они так спроектированы, что не могут использовать более 50 миллионов экстентов и не более 100.000 Stream для одного Storage Stamp (блоки не берутся в расчет, так как их может быть совершенно неисчислимое количество), что вполне умещается в 32 гигабайта памяти Stream Manager.
Extent Nodes (EN). Каждый EN управляет хранилищем для набора реплик экстентов, назначенных для них SM. EN имеет N подсоединенных дисков, которые находятся под полным его контролем для сохранения реплик экстентов и их блоков. При этом EN ничего не знает о Stream (в отличие от Stream Manager, который ничего не знает о блоках) и управляет только экстентами и блоками, которые (экстенты) являются, по сути, файлами на дисках, содержащими блоки данных и их контрольные суммы + карту ассоциаций сдвигов в экстентах к соответствующим блокам и их физическому расположению. Каждый EN содержит некоторое представление о своих экстентах и о том, где находятся реплики для конкретных экстентов. Когда на конкретные экстенты более не ссылается ни один из Stream-ов, Stream Manager собирает эти «мусорные» экстенты и уведомляет EN о необходимости освободить пространство. При этом данные в Stream могут быть только добавлены, существующие же данные модифицировать нельзя. Операции добавления атомарны – или весь блок данных добавляется, или не добавляется ничего. В один момент времени может быть добавлено несколько блоков в пределах одной атомарной операции «добавление нескольких блоков». Минимальным размером, который доступен для чтения из Stream, является один блок. Операция же добавления нескольких блоков позволяет клиенту записывать большие объемы последовательных данных в рамках одной операции.

Каждый экстент, как уже было сказано, имеет определенный потолок для размера, и когда он заполняется, экстент запечатывается (sealed) и дальнейшие операции записи оперируют новых экстентом. В запечатанный экстент добавлять данные нельзя, и он является неизменяемым (immutable).

Есть несколько правил относительно экстентов:

1. После добавления записи и подтверждения операции клиенту, все дальнейшие операции чтения этой записи из любой реплики должны возвращать одни и те же данные (данные неизменяемы).
2. После запечатывания экстента все операции чтения из любой запечатанной реплики должны возвращать одно и то же содержание экстента.

Например, когда Stream создаётся, SM назначает первому экстенту три реплики (одну primary и две secondary) для трех Extent Nodes, которые, в свою очередь, выбираются SM для случайного распределения между различными доменами обновлений и ошибок и учитывая возможность балансировку нагрузки. Кроме этого SM решает, какая реплика будет Primary для экстента и все операции записи в экстент совершаются сначала на primary EN, и только после этого с primary EN запись совершается на два secondary EN. Primary EN и расположение трех реплик не изменяется для экстента. Когда SM размещает экстент, информация по экстенту отправляется обратно клиенту, который после этого знает, какие EN содержат три реплики и которая из них является primary. Эта информация становится частью метаданных Stream и кэшируется на клиенте. Когда последний экстент в Stream запечатывается, процесс повторяется. SM размещает еще один экстент, который теперь становится последним экстентом в Stream, и все новые операции записи совершаются на новом последнем экстенте. Для экстента каждая операция добавления реплицируется три раза по всем репликам экстента, и клиент отправляет все запросы на запись на primary EN, но операции чтения могут быть совершены с любой реплики, даже для незапечатанных экстентов. Операция добавления посылается на primary EN, и primary EN ответственна за определение сдвига в экстенте, а также упорядочивании всех операций записи в том случае, если происходит параллельная запись в один экстент, отправку операции добавления с необходимым сдвигом на два secondary EN и посылке подтверждения операции клиенту, которое посылается только в том случае, когда операция добавления была подтверждена на всех трёх репликах. Если же одна из реплик не отвечает или происходит (или произошла) какая-либо аппаратная ошибка, клиенту возвращается ошибка записи. В этом случае клиент связывается с SM и экстент, в который происходила операция записи, запечатывается SM.

SM после этого размещает новый экстент с репликами на других доступных EN и отмечает этот экстент как последний в stream, и информация об этом возвращается клиенту, который продолжает совершать операции добавления в новый экстент. Необходимо упомянуть, что вся последовательность действий по запечатыванию и размещению нового экстента выполняется в среднем всего 20 миллисекунд.
Что касается самого процесса запечатывания. Для того, чтобы запечатать экстент, SM опрашивает все три EN об их текущей длине. В процессе запечатывания два сценария – либо все реплики одного размера, либо какая-то из реплик длиннее или короче других. Вторая ситуация возникает только при ошибке операции добавления, когда какой-то из EN (но не все) не были доступны. При запечатывании экстента SM выбирает самую короткую длину, основываясь на доступных EN. Это позволяет запечатать экстенты так, что все изменения, подтвержденные для клиента, будут запечатаны. После запечатывания подтвержденная длина экстента более не изменяется и, если SM не может связаться с EN во время запечатывания, но затем EN становится доступным, SM принуждает этот EN синхронизироваться к подтвержденной длине, что приводит к идентичному набору бит.

Однако здесь может возникать другая ситуация – SM не может связаться с EN, однако Partition Server, который является клиентом, может. Partition Layer, о котором немного позже, имеет два режима чтения – чтение записей в известных позициях и с помощью итерации по всем записям в stream. Что касается первого — Partition layer использует два типа Stream – запись и блоб. Для этих Stream операции чтения всегда происходят для определенных позиций (экстент+сдвиг, длина). Partition Layer производит операции чтения для этих двух типов, используя информацию о позиции, возвращенную после предыдущей успешной операции добавления на Stream Layer, что случается только тогда, когда все три реплики отрапортовали об успешном выполнении операции добавления. Во втором случае, когда все записи в Stream перебираются последовательно, каждая партиция имеет два отдельных Stream (метаданные и лог подтверждения), которые Partition Layer будет читать последовательно с начала и до конца.

В Windows Azure Storage введён механизм, позволяющий сэкономить на занятом дисковом пространстве и трафике, не снижая при этом уровень доступности данных, и называется он erasure codes. Суть этого механизма заключается в том, что экстент разбивается на N примерно равных по размеру фрагментов (на практике это опять же файлы), после чего по алгоритму Рида-Соломона добавляется M фрагментов кодов, корректирующих ошибку. Что это значит? Любые X из N фрагментов равны по размеру оригинальному файлу, для восстановления же первоначального файла достаточно собрать X любых фрагментов и декодировать, остальные же N-X фрагментов могут быть удалены, нарушены и так далее. До тех пор, пока в системе хранится больше чем M фрагментов кодов, корректирующих ошибку, система может полностью восстановить оригинальный экстент.

Подобная оптимизация запечатанных экстентов очень важна при гигантских объемах данных, хранящихся в облачном хранилища, так как позволяет сократить стоимость хранения данных с трёх полных реплик исходных данных до 1.3-1.5 исходных данных в зависимости от количества используемых фрагментов, а также позволяет увеличить «устойчивость» данных по сравнению с хранением трех реплик внутри Storage Stamp.

При совершении операций записи для экстента, у которого есть три реплики, все операции ставятся на исполнение с определенным значением времени и, если операция не выполнена за это время, эта операция не должна быть выполнена. Если EN определяет, что операция чтения не может быть полностью выполнена за определенное время, он сразу же сообщает об этом клиенту. Этот механизм позволяет клиенту обратиться с операцией чтения к другому EN.
Аналогично с данными, для которых применяется erasure coding – когда операция чтения не успевает выполниться за временной промежуток из-за большой нагрузки, эта операция может не применяться для чтения полного фрагмента данных, но может воспользоваться возможностью реконструкции данных и в этом случае операция чтения обращается ко всем фрагментам экстента с erasure code, и первые N ответов будут использованы для реконструкции необходимого фрагмента.
Обращая внимание на то, что система WAS может обслуживать очень большие Streams, может возникать следующая ситуация: некоторые физические диски обслуживают и замыкаются на обслуживании больших операций чтения или записи, начиная обрезать пропускную способность для других операций. Для предотвращения подобной ситуации WAS не назначает диску новые I/O-операции тогда, когда ему уже назначены операции, которые могут выполняться более 100 миллисекунд или тогда, когда уже назначенные операции были назначены, но не выполнились за 200 миллисекунд.

Когда данные определяются Stream Layer как записываемые, используется дополнительный целый диск либо SSD в качестве хранилища для журнала всех операций записи на EN. Диск журналирования полностью отведен под один журнал, в который последовательно логируются все операции записи. Когда каждый EN совершает операцию добавления, он записывает все данные на диск журналирования и начинает записывать данные на диск. Если диск журналирования возвратит код успешной операции раньше, данные будут буферизованы в памяти и до тех пор, пока все данные не будут записаны на диск данных, все операции чтения будут обслуживаться из памяти. Использование диска журналирования предоставляет важные преимущества, так как, например, операции добавления не должны «соревноваться» с операциями чтения с дисков данных с целью подтвердить операцию для клиента. Журнал позволяет операциям добавления с Partition Layer быть более согласованными и иметь меньшие задержки.

Partition Layer (PL). Данный слой содержит специальные Partition Servers (процессы-демоны) и предназначен для управления собственно абстракциями хранилища (блобами, таблицами, очередями), пространством имён, порядком транзакций, строгой согласованностью объектов, хранением данных на SL и кэшированием данных для снижения количества I/O операций на диск. Также PL занимаются партиционированием объектов данных внутри SS согласно PartitionName и дальнейшей балансировкой нагрузки между серверами партиций. Partition Layer предоставляет внутреннюю структуру данных под названием Object Table (OT), которая является большой таблицей, способной разрастаться до нескольких петабайт. OT в зависимости от нагрузки динамически разбивается на RangePartitions и распределяется по всем Partition Server внутри Storage Stamp. RangePartition представляет из себя диапазон записей в OT, начинающихся с предоставленного наименьшего ключа до наибольшего ключа.

Есть несколько различных типов OT:
• Account Table хранит метаданные и конфигурацию для каждого аккаунта хранилища, ассоциированные с Storage Stamp.
• Blob Table хранит все объекты блобов для всех аккаунтов, ассоциированных со Storage Stamp.
• Entity Table хранит все записи сущностей для всех аккаунта хранилища, ассоциированных со Storage Stamp и используется для сервиса хранилища таблиц Windows Azure.
• Message Table хранит все сообщения для всех очередей для всех аккаунтов хранилища, ассоциированных со Storage Stamp.
• Schema Table отслеживает схемы для всех OT.
• Partition Map Table отслеживает все текущие RangePartitions для всех Object Table и то, какие Partition Server обслуживают какие RangePartition. Эта таблица используется FE-серверами для перенаправления запросов к необходимым Partition Server.

Таблицы всех типов имеют фиксированные схемы, которые хранятся в Schema Table.
Для всех схем OT имеется стандартный набор типов свойств — bool, binary, string, DateTime, double, GUID, int32 и int64, кроме этого, система поддерживает два специальных свойства DictionaryType и BlobType, первый из которых позволяет реализовать добавление свойств без определенной схемы как запись. Эти свойства хранятся внутри типа словаря в виде
(имя, тип, значение). Второе же специальное свойство используется для хранения больших объемов данных и на данный момент используется только для Blob Table, при этом данные блобов хранятся не в общем потоке записей, а в отдельном потоке для данных блоба, в сущности же хранится только ссылка на данные блоба (список ссылок «экстент+сдвиг, длина»). OT поддерживают стандартные операции – вставку, обновление, удаление и чтение, а также пакетные транзакции для записей с одним значением PartitionName. Операции в одном пакете подтверждаются как одна транзакция. OT также поддерживают режим snapshot isolation для того, чтобы позволить операциям чтения осуществляться параллельно операциям записи.

Архитектура Partition Layer

Рис. 4. Архитектура и Workflow Partition Layer

Partition Manager (PM) отслеживает и разделяет большие OT на N RangePartition в пределах Storage Stamp и назначает RangePartition определенным Partition Server. Информация о том, что где хранится, сохраняется в Partition Map Table. Одна RangePartition назначается одному активному Partition Server, что гарантирует что две RangePartition не будут пересекаться.
Каждый Storage Stamp имеет несколько экземпляров PM и все они «соревнуются» за один Leader Lock, хранящийся в Lock Service.

Partition Server (PS) обслуживает запросы для RangePartitions, назначенных этому серверу PM и хранит все состояние партиций в Streams и управляет кэшем в памяти. PS способен обслуживать несколько RangePartition из нескольких OT, возможно, в среднем до десятка. PS обслуживает следующие компоненты, храня их в памяти:
• Memory Table, версию лога подтверждений для RangePartition, содержащую все недавние изменения, которые ещё не были подтверждены контрольной точкой.
• Index Cache, кэш, содержащий позиции контрольной точкой потока данных записей.
• Row Data Cache, кэш в памяти для страниц данных записей для контрольной точки. Этот кэш существует только для чтения. Когда происходит доступ к кэшу, проверяются Row Data Cache и Memory Table с предпочтением ко второму.
• Bloom Filters – если данные не найдены в Row Data Cache и Memory Table, то осматриваются позиции и контрольные точки в потоке данных, причем грубый их перебор будет неэффективным, поэтому для каждой контрольной точки используются специальные bloom-фильтры, которые указывают, может ли быть осуществлен доступ к записи в контрольной точки.

Lock Service используется для выбора обслуживающего PM. Каждый PS также управляет лизингом с Lock Service для обслуживания партиций. При ошибке PS все N RangePartitions, обслуживавшие этот PS, переназначаются доступным PS. PM выбирает N PS, основываясь на их нагрузке, затем PM назначает RangePartitions PS и обновляет Partition Map Table соответствующими данными, что позволяет Front-End Layer найти расположение RangePartitions, обратившись к Partition Map Table. RangePartition использует для сохранения данных Log-Structured Merge-Tree, каждая из RangePartition состоит из собственного набора Streams на Stream Layer и Stream относится полностью к определенной RangePartition.

Каждая RangePartition может состоять из одного из следующих Streams:
• Metadata Stream – этот Stream является главным для RangePartition. PM назначает PS партицию, предоставляя имя Metadata Stream этого PS.
• Commit Log Stream – этот Stream предназначен для хранения логов подтвержденных операций вставки, обновления и удаления, применённых к RangePartitions с последней точки, сгенерированной для RangePartition.
• Row Data Stream сохраняет данные записи и позицию для RangePartitions
• Blob Data Stream используется только для Blob Table для сохранения данных блобов.
Все перечисленные Stream являются различными Stream в Stream Layer, управляемой OT RangePartition. Каждая RangePartition в OT имеет только один поток данных, исключая Blob Table – RangePartition в Blob Table имеет поток данных записей для сохранения данных последней контрольной точки для записи (позицию блоба) и отдельный поток данных для блоба для сохранения данных для специального типа BlobType.

Балансировка нагрузки RangePartitions

Для того, чтобы осуществить балансировку нагрузки между Partition Servers и определить общее количество партиций в Storage Stamp, PM проводит три операции:
• Балансировка нагрузки. С помощью этой операции определяется, когда определенный PS испытывает слишком большую нагрузку, и затем одна или более RangePartitions переназначаются на менее нагруженные PS.
• Split. С помощью этой операции определяется, когда определенная RangePartition испытывает слишком большую нагрузку, и эта RangePartition разделяется на две или более более мелких партиций, после чего эти RangePartitions распределяются по двум или более PS. PM посылает команду Split, но решает, где будет разделена партиция, PS, основываясь на AccountName и PartitionName. При этом, например, для разделения RangePartition B в две RangePartitions C и D выполняются следующие операции:
o PM посылает команду PS на разделение B в C и D.
o PS делает контрольную точку для B и перестает принимать трафик.
o PS выполняет специальную команду MultiModify, собирая Streams с B (метаданные, логи подтверждения и данные) и создаёт новые наборы Streams для C и D в том же порядке, что и в B (это происходит быстро, так как создаются, по сути, только указатели на данные). Затем PS добавляет новые диапазоны Partition Key для C и D к метаданным.
o PS возобновляет обслуживание трафика для новых партиций C и D.
o PS уведомляет PM о выполнении разделения, обновляет Partition Map Table и метаданные, затем переносит разделенные партиции на разные PS.
• Merge. С помощью этой операции две «холодных» или малонагруженных RangePartitions объединяются так, чтобы сформировать диапазон ключевых в их OT. Для этого PM выбирает две RangePartitions со смежными диапазонами PartitionName, имеющими малую нагрузку, и выполняет следующую последовательность действий:
o PM переносит C и D таким образом, чтобы они обслуживались одним PS, и сообщает PS команду об объединении C и D в E.
o PS сохраняет контрольную точку для C и D и ненадолго прекращает обслуживание трафика к C и D.
o PS выполняет команду MultiModify для создания нового лога подтверждения и потоков данных Е. Каждый из этих потоков является объединением всех экстентов из соответствующих потоков из C и D.
o PS создаёт поток метаданных Е, содержащий имена лога подтверждения и потока данных, комбинированный диапазон ключей для Е и указатели (экстент+сдвиг) для лога подтверждений (от С и D).
o Начинается обслуживание трафика для RangePartition E.
o PM обновляет Partition Map Table и метаданные.
Для балансировки нагрузки отслеживаются следующие метрики:
• Количество транзакций в секунду.
• Среднее количество незаконченных транзакций.
• Нагрузка CPU.
• Нагрузка на сеть.
• Задержка запросов.
• Размер данных RangePartition.
PM при этом управляет heartbeat-ом каждого из PS, и информация об этом передается обратно к PM в ответ на heartbeat. Если PM видит, что RangePartition испытывает слишком большую нагрузку (исходя из метрик), то он разделяет партицию и отсылает команду PS для осуществления операции Split. Если же сам PS испытывает большую нагрузку, но не RangePartition, то PM переназначает имеющиеся у этого PS RangePartitions на менее нагруженные PS. Для балансировки нагрузки на RangePartition PM посылает команду PS, имеющий RangePartition, на запись текущей контрольной точки, после выполнения чего PS посылает подтверждение PM и PM переопределяет RangePartition на другой PS и обновляет Partition Map Table.

Решение о выборе механизма партиционирования на основе диапазонов (на котором работают RangePartition) вместо индексирования на основе хэшей (когда объекты назначаются серверу по значениям хэшей их ключей) было обосновано тем, что партиционирование на основе диапазонов помогает проще реализовать Performance Isolation, так как объекты определенного аккаунта хранятся рядом в пределах набора RangePartitions, индексирование на основе хэшей же упрощает задачу распределения нагрузки на сервера, но при этом лишает преимущества локальности объектов в целях изоляции и эффективного перечисления. Партиционирование на основе диапазонов позволяет хранить объекты одного клиента вместе в одном наборе партиций, что также предоставляет возможность эффективно ограничивать или изолировать потенциально небезопасные аккаунты. Одним из недостатков же подобного похода является масштабирование в сценариях последовательного доступа – например, если клиент записывает все свои данные в самый конец диапазона ключей таблицы, то все операции записи будут перенаправляться в самую последнюю RangePartition таблицы клиента. В этом случае преимущество партиционирования и балансировки нагрузки в системе не используется. Если же клиент распределяет операции записи по большому количеству PartitionNames, то система быстро разделяет таблицу на набор RangePartitions и распределяет их по нескольким серверам, что позволяет линейно увеличивать эффективность.

Front-End (FE). Слой фронтенда состоит из набора stateless-серверов, принимающих входящие запросы. Получив запрос, FE читает AccountName, аутентифицирует и авторизовывает запрос, после чего переводит его на сервер партиций на PL (основываясь на полученном PartitionName). Сервера, принадлежащие FE, кэшируют так называемую карту партиций (Partition Map), в которой системой управляется некоторый трекинг диапазонов PartitionName и того, какой сервер партиций какие PartitionNames обслуживает.

Intra-Stamp Replication (stream layer). Данный механизм управляет синхронной репликацией и сохранностью данных. Он сохраняет достаточно реплик по разным узлам в разных доменах ошибок для того, чтобы сохранить эти данные в случае какой-либо ошибки, и выполняется он полностью на SL. В случае операции записи, поступившей от клиента, она подтверждается только после полной успешной репликации.

Inter-Stamp Replication (partition layer). Данный механизм репликации производит асинхронной репликацией между SS, и проводит он эту репликацию в фоне. Репликация происходит на уровне объектов, то есть либо целый объект реплицируется, либо реплицируется его изменение (delta).
Различаются эти механизмы тем, что intra-stamp предоставляет устойчивость против «железных» ошибок, которые периодически случаются в большого масштаба системах, тогда как inter-stamp предоставляет географическую избыточность против различных катастроф, которые происходят редко. Одним из основных сценариев для этого типа репликации является географическая репликация данных аккаунта хранилища между двумя датацентрами в целях восстановления от природных бедствий.
Все данные в сервисах хранилища блобов и таблиц географически реплицируются (но очереди – нет). С географически избыточным хранилищем платформа сохраняет опять же три реплики, но в двух локациях. При развертывании аккаунта хранилища LS выбирает Storage Stamp в каждой из географических локаций и регистрирует выбранный AccountName во всех Storage Stamp, при этом одна из локаций будет принимать «живой» трафик, тогда как вторые, secondary, будут осуществлять только inter-stamp replication (по сути и есть географическую репликацию). LS затем обновляет DNS для новой записи AccountName.service.core.windows.net, ведущей на VIP главной локации. Таким образом, если с датацентром что-то случится, данные будут доступны из второй локации. Когда операция записи поступает в главную локацию для аккаунта хранилища, изменения полностью реплицируются с использованием intra-stamp replication на Stream Layer, после чего код об успешном завершении операции возвращается клиенту. По подтверждению операции в асинхронном режиме происходит репликация в другую географическую локацию и уже там транзакция применяется на Partition Layer.
Что касается географической отказоустойчивости и того, как все восстанавливается в случае серьезных сбоев. Если серьезный сбой возник в главной географической локации, естественно что корпорация пытается по максимуму сгладить последствия. Однако, если всё совсем плохо и данные потеряны, может возникнуть необходимость в применении правил географической отказоустойчивости – клиент оповещается о возникшей катастрофе в главной локации, после чего соответствующие DNS-записи перебиваются с главной локации на вторую (account.service.core.windows.net). Разумеется, в процессе перевода DNS-записей вряд ли что-то будет работать, но по его завершению существующие блобы и таблицы становятся доступными по их URL. После завершения процесса перевода вторая географическая локация повышается в статусе до главной (до тех пор, пока не случится очередной провал датацентра сквозь землю). Также сразу по завершению процесса повышения статуса датацентра инициируется процесс создания новой второй географической локации в этом же регионе и дальнейшей репликации данных. Командой разработки было анонсировано, что пользователь сможет выбирать, где будет его вторая географическая локация, в том случае, если в одном регионе будет более двух датацентров, но пока я не заметил такой возможности (возможно потому, что не знаю таких регионов).
Процесс географической репликации гораздо более интересен хотя бы потому, что на наши действия он влияет больше и чаще, чем эфемерный динозавр, съевший датацентр, что привело к geo-failover.
Итак, например, в нашем аккаунте хранилища есть несколько блобов (пример из блога разработчиков), foo и bar. Для блобов полное имя блоба равно значению PartitionKey. Мы выполняем две транзакции A и B на блобе foo, после чего выполняем две транзакции X и Y на блобе bar. Система гарантирует, что транзакция А будет географически реплицирована перед транзакцией B, и, соответственно, транзакция X будет географически реплицирована перед транзакцией Y. В остальном же гарантий нет – доподлинно неизвестно, сколько будет затрачено времени на географическую репликацию между транзакциями на foo и транзакциями на bar. Также, если в момент репликации датацентр по какой-то причине сломается, что приведет к невозможности географической репликации недавних транзакций, может случиться так, что реплицируются транзакции A и X, тогда как транзакции B и Y будут потеряны. Либо реплицируются только А и В, а X и Y пропадут. То же самое может произойти и с сервисами таблиц (учитывая то, что партиции в таблицах определяются заданным приложением PartitionKey сущности, а не именем блоба).

Резюме

Сервисы хранилища Windows Azure являются важнейшей составляющей платформы, предоставляющей услуги по хранению данных в облаке и реализующих комбинацию таких характеристик, как строгая согласованность, глобальное пространство имён и высокая отказоустойчивость данных в условиях мультитенантности.

Using shell settings storage

Storing shell settings in Microsoft Azure Blob Storage is useful when running Orchard in server farm where there is no shared file system storage. Microsoft Azure Cloud Services is an example of this. For this reason, when deploying Orchard to a Microsoft Azure Cloud Service using the Orchard.Azure.sln solution, the resulting package is already preconfigured to store shell settings in Microsoft Azure Blob Storage.

The only thing you need to change before deploying is the connection string of the storage account you want to use:

1. Open Orchard.Azure.sln .
2. Navigate to Orchard.Azure.CloudService , double click the role Orchard.Azure.Web to bring up its property page, and navigate to the Settings tab.
3. Set the Orchard.Azure.Settings.StorageConnectionString setting to be the connection string of the storage account you want to use.
4. Deploy the cloud service.

NOTE: It is not necessary to use this feature when running Orchard in a Microsoft Azure Web Site, because in this environment the file system is shared among instances.

It is also possible to use this feature is any other hosting environment where you have a server farm with multiple nodes but no shared file system. To do this you need to do the following:

• Add the Orchard.Azure.Settings.StorageConnectionString setting in the element of your Web.config file and set it to the connection string of the storage account you want to use.
• Configure Autofac to load the AzureBlobShellSettingsManager implementation in your Config\Host.config file.

Here’s an example Config\Host.config configuration:

Using Microsoft Azure Media Storage

The Microsoft Azure Media Storage feature in the Orchard.Azure module configures Orchard to use Microsoft Azure Blob Storage is the underlying file system implementation for storing media:

Orchard.Azure: Name: Microsoft Azure Media Storage Description: Activates an Orchard media storage provider that targets Microsoft Azure Blob Storage. Category: Hosting 

There are two main reasons to use this feature:

• Running Orchard in a server farm configuration. Without using some form of shared storage, media content will become out of sync between the nodes in your farm as users add or remove media files.
• Offloading media requests from the Orchard web server. When Microsoft Azure Media Storage is enabled all end user requests for media content are made directly to the public blob storage endpoint.

Enabling for Microsoft Azure Cloud Services

Before the feature can be enabled you must configure the connection string to the storage account you want to use. When running Orchard in a Microsoft Azure Cloud Service this can be done either before deploying (in the cloud service project) or after deploying (in the Microsoft Azure management portal).

To configure the connection string before deploying:

1. Open Orchard.Azure.sln .
2. Navigate to Orchard.Azure.CloudService , double click the role Orchard.Azure.Web to bring up its property page, and navigate to the Settings tab.
3. Set the Orchard.Azure.Media.StorageConnectionString setting to be the connection string of the storage account in which you want to store media content.
4. Deploy the cloud service.

To configure the connection string after deploying:

1. Deploy the cloud service.
2. In the management portal, navigate to your cloud service and select the Configure tab.
3. Under Orchard.Azure.Web locate the setting Orchard.Azure.Media.StorageConnectionString .
4. Set it to be the connection string of the storage account in which you want to store media content.
5. Click Save.

You can now enable the feature Microsoft Azure Media Storage in the admin dashboard.

NOTE: For multi-tenancy scenarios the Orchard.Azure.Media.StorageConnectionString setting can optionally be prefixed with a tenant name.

Enabling for Microsoft Azure Web Sites

Before the feature can be enabled you must configure the connection string to the storage account you want to use. When running Orchard in a Microsoft Azure Web Site this can be done either before deploying (in Web.config) or after deploying (in the Microsoft Azure management portal).

To configure the connection string before deploying:

1. Open Orchard.sln .
2. Navigate to Orchard.Web and open the Web.config file.
3. In the element add a setting named Orchard.Azure.Media.StorageConnectionString and set its value to be the connection string of the storage account in which you want to store media content (see example below).
4. Deploy the web site.

Here’s an example configuration:

The storage connections string will look something like the following:

DefaultEndpointsProtocol=http;AccountName=myAccount;AccountKey=myKey; *You can get the account name and key from the Microsoft Azure management portal that you used to create your storage or ask you dev ops admin to provide them for you. 

To configure the connection string after deploying:

1. Deploy the web site.
2. In the management portal, navigate to your web site and select the Configure tab.
3. Under App settings add a setting named Orchard.Azure.Media.StorageConnectionString and set its value to be the connection string of the storage account in which you want to store media content.
4. Click Save.

You can now enable the feature Microsoft Azure Media Storage in the admin dashboard.

NOTE: For multi-tenancy scenarios the Orchard.Azure.Media.StorageConnectionString setting can optionally be prefixed with a tenant name.

Enabling for any other hosting

To enable the feature when running Orchard in any other hosting environment, use the Web.config method described above. Once the connection string has been added to the element, can enable the feature Microsoft Azure Media Storage in the admin dashboard.

Using a custom domain name for blob storage

Microsoft Azure Blob Storage allows the use of your own custom domain instead of the default endpoint hostname [mystorageaccount].blob.core.windows.net .

However, registering and configuring a custom domain in your storage account is not enough to make Orchard use it. Unless you also reconfigure your storage connection string to take advantage of your custom domain, Orchard will continue to generate public URLs for the media files stored in Microsoft Azure Blob Storage based on the default [mystorageaccount].blob.core.windows.net hostname.

To ensure the public URLs for your media files contain your custom domain name, modify your storage account connection string accordingly. See the topic Configuring Connection Strings in the Microsoft Azure Storage documentation for details.

Here’s an example connection string using a custom domain name:

BlobEndpoint=http://blobs.mycustomdomain.com;AccountName=mystorageaccount;AccountKey=KauG3A5f. An3QlW5dA== 

Multi-tenancy configuration

For multi-tenancy scenarios each setting can optionally be prefixed with a tenant name followed by colon, such as SomeTenant:Orchard.Azure.Media.StorageConnectionString . Whenever the media storage provider reads configuration settings it will always first look for a setting specific for the current tenant, and if no such setting exists, fallback to the default non-prefixed setting.

Here’s an example Azure Web Site configuration with two tenants, both using Microsoft Azure Blob Storage is the underlying file system implementation for storing media, but each using its own separate storage account:

Microsoft Azure Storage Types Explained

Microsoft Azure Cloud offers several types of scalable and with high-availability storage. And in many cases, it is not that easy to determine the best solution for your or your client’s company requirements since there are two types of storage accounts, five types of storage, four levels of redundancy, and three tiers for storing your data in Microsoft Azure.

In this article, we outline all Microsoft Azure storage types and use-cases, and also give examples.

Before You Start

To start working with Microsoft Azure Storage, you need to:

• Define the need in the storage
• Get an account in Azure
• Choose your storage account type
• Choose your storage type, depending on the storage account type
• Choose your redundancy level, depending on the storage type

Microsoft Azure Storage Types

One of the most important steps in choosing Microsoft Azure storage type is defining what you want to store, how and which options and features you need to achieve that.

There are five storage types available in Microsoft Azure divided into two groups.

The first group, which includes Queue Storage, Table Storage, and Blob Storage is designed with file storage, scalability, and communication in mind and is accessible via REST API. The other, which includes File Storage and Disk Storage, is for extending the capabilities of the Microsoft Azure Virtual Machine environment and for access exclusively from VMs. (Don’t get distracted by the naming of the File Storage. It does not represent the unstructured storage for files.)

Let’s take a closer look at all five storage types.

Blob Storage

Blob is a file

It all has begun with Blob Storage in Microsoft Azure. BLOB is an acronym and means Binary Large OBject. Or, in plain English, the unstructured files, such as images, video, music files, backup files, etc.

Boost Your Profits with Azure Storage and MSP360

Discover how to use Azure for backup in detail and perform secure, automated and price-effective backups with MSP360 Managed Backup integrated with Azure Blob Storage.

There are three different ways to store Blobs in Microsoft Azure:

Block Blob

Good for file storage, capable of 4.77 TB per file

When you store a file as a block blob, it arrives to the storage in small parts (or, you guessed it, blocks), and only after you complete the upload — the file/blob is merged in one piece. With this architecture, the file cannot be modified without a complete reload. This is the easiest and the cheapest way to store files in Azure.

You can access the files, but you cannot modify them inside the repository without completely rewriting the files. Previously, the size of a single blob (one file) could not exceed 200GB. If in the year 2007, 200 GB per file was acceptable, nowadays it is a way too small of a limitation. Thus, Microsoft has upgraded the technology and now the limit is 4.77 TB per blob.

Append Blobs

Good for storing logs or meta-data, can be updated constantly

As we’ve already stated, you cannot modify a Block Blob without re-uploading it. However, there are times when you need to perform many input/output operations, like in the databases. Append Blobs were created for this very purpose — they are structured in such a way that the user can upload parts of the files from the end.

Page Blobs

Designed for storing disks

Page Blobs are the basis for the Microsoft Azure virtual machine environment. They have been specifically designed with disk limitations in mind — each Page Blob should be multiple of 512 bytes. The architecture of Page Blobs allows data to be written to each part of a blob.

The purpose of Page Blobs is simple — when a VM or your on-prem machine is operating with local storage (HDD or SSD with your disk partitions inside) — it operates various parts of the device — without a linear structure.

In fact, if you are running any sort of disk on a VM in Microsoft Azure — it uses Page Blobs. However, that is not the end with the blobs. They also have the so-called access tiers.

Blobs Access Tiers

Besides three Blob types, there are also Blob access tiers in Microsoft Azure. You may have already heard about hot, cool, and cold storage tiers:

• The hot tier is for the frequently needed data. It’s expensive to store but cheap to access.
• The cool tier is for the less frequently needed data. It’s less expensive to store files than in hot tier, but more expensive to access,
• The cold tier is for your archives. It’s dirt cheap to store files there but highly expensive to access files.

Microsoft has all three access tiers for the Blob Storage named respectively — Hot Tier, Cool Tier and Archive for the cold tier.

For details on the different storage tiers and when to use them, see our guide:
Further reading Azure Blob Storage Tiers Explained

Remember that you cannot change the access tier for Page Blobs. The access tier applies only to Append Blobs and Block Blobs. This limitation is related to the purpose and architecture of these storage types. You can change the access tiers for files, but not for disks.

Table Storage

Cheaper, more scalable storage for your structured data and big data analysis

In Table storage you can store, what a surprise, tables. But not all tables. Microsoft Azure Table Storage was designed to store structured NoSQL data. The storage is hugely scalable and, at the same time, cheap to store data. However, it becomes more expensive if you access files frequently.

This storage is useful if you find Microsoft Azure SQL too expensive and can go without SQL structure and architecture.

Queue Storage

When your services need to communicate with each other

Queue Storage is designed to connect the components of your application. It allows you to build flexible applications with independent components that rely on asynchronous message queuing.

Let’s say you have an on-premises application interacting with a server somewhere in the cloud. Sometimes the server is down, which means that you can no longer send messages to it. If you try, that would normally result in an error. Here are some other issues concerning asynchronous communication that you have to deal with in such case:

• The necessity to have both the receiver and the sender available simultaneously. Needless to say, if one of them goes down, the communication terminates.
• Mandatory implementation of try/retry logic to provide for a possible outage.
• Lack of proper scalability.

However, all of that can be avoided simply by using a mediator that will collect the messages while one of the communication partners is down. With Azure Queues, you have a third player that connects the two components and acts as both a buffer and a mediator.

Azure Queue storage is essentially a service for storing large numbers of messages that can be accessed from anywhere via authenticated HTTP or HTTPS requests. A single queue sizes up to 64 kb.

Azure supports two types of queue mechanisms:

• Storage queues. Being part of the Azure storage infrastructure, they feature a simple REST-based GET/PUT/PEEK interface with reliable and persistent messaging within and between services.
• Service Bus queues are part of a broader Azure messaging infrastructure that supports queuing as well as more advanced integration patterns.

Azure Queue storage is unquestionably a service for advanced users that requires certain know-how. We, therefore, suggest you to read Microsoft documentation to get a clearer picture of how it works in real life.

Disk Storage

Microsoft Azure Disk Storage is based on Page Blobs. It is a service that allows you to create disks for your virtual machines. A disk created in Disk Storage can be accessed from only one virtual machine. In other words — it is your local drive. Yes, it’s that simple.

Here you can have two options for the speed of your disks:

• HDDs that are cheap but slow and called standard storage.
• SSDs that are fast but expensive and called premium storage.

And two options for disk management:

• Unmanaged disk — you should manage the disk storage and corresponding account yourself
• Manageddisk — Azure does everything for you. You need to select only the size of the disk and the desired type — standard or premium

File Storage

Microsoft Azure File storage is the second storage type that was designed to support the needs of the Azure VM environment. That storage is, in essence, a network share. You can store files there that can be accessed from different Virtual Machines. It is similar to Amazon EFS its direct competitor.

Again, quite simple. (Though the naming could be a bit clearer.)

Redundancy

Okay, now you are done with choosing the type of storage for your needs. However, in the IT world, the safety of your data is amongst the most essential and basic things. When you store data in Microsoft Azure, regardless of the type of storage, it is stored somewhere in the datacenters of Microsoft.

However, what if one day you wake up and read the news about the devastating accident that has completely destroyed the data center in question? Kind of a nightmare really.

To prevent that from happening, Microsoft has four options for data replication amongst their data-centers.

Disk Storage redundancy will be described separately, as it cannot be simply added to the following structure

Locally-Redundant Storage

3 copies of each file in one building but 3 different places

That is the most basic and the cheapest way to replicate your data. When you choose Locally-Redundant Storage (LRS), your data is copied within one data-center in 3 different nodes (basically, on different hard drives).

LRS is available for all 5 types of Microsoft Azure Storage.

Geo-Redundant Storage

3 copies in one building, 3 copies in the other

However, if a meteorite strikes the data center, it won’t matter how many different nodes your data is in, it will be still lost!

For this reason, Microsoft created a GRS — Geo-Redundancy Storage. With it, You have 6 copies of your data in 2 different regions, hundreds of miles apart.

Basically, this is LRS times 2.

Read-Access Geo-Redundant Storage

Read-Access Geo-Redundant storage gives you read-only access to your data at the secondary location, in addition to the dual region replication provided by GRS. The secondary endpoint is similar to the primary endpoint but adds a suffix to the account name. For example, myaccount.blob.core.windows.net turns into myaccount-secondary.blob.core.windows.net.

Zone Redundant Storage

Zone-redundant storage (ZRS) asynchronously replicates your data across data centers in one or two regions in addition to storing three replicas similarly to LRS. The data stored in ZRS is durable even if the primary data center is unavailable thus. ZRS is only available for block blobs and cannot be converted to LRS or GRS or vice versa.

Disk Storage Redundancy

Disk storage serves as storage for Azure VMs and hence requires replication to ensure data integrity. The first thing you need to do is to enable Azure VM replication in the Microsoft Azure portal.

The next step is to configure continuous replication for your VMs. Thus data written on the VM disks is continuously transferred to the cache storage account at the target location. Site Recovery processes the data and sends it to the target storage account.

After the data is processed, recovery points are generated in the target storage account every few minutes. If your main setup fails somehow, new virtual machines will be initiated in the target region and the cache storage account will ensure that your data is intact.

Microsoft Azure Storage Accounts

Now that you are aware of storage types, access tiers, and redundancy, it will be quite easy to understand how to enable all of that in your Microsoft Azure account. In Microsoft Azure, you can choose two Storage Account types. They are General-Purpose Account and Blob Storage account. You may think that the Blob Storage account works only with blobs and General-Purpose works with the rest.

And you would be completely wrong.

General-Purpose Storage Account

General-Purpose Account is designed to operate with all types of Microsoft Azure Storage, except Disk Storage. To create disks inside your Azure Storage, you should first create the Microsoft Azure Virtual Machine.

Blob Storage Account

Blob Storage account is designed to work with Block Blobs and Append Blobs. Page Blobs, however, can only be created when you are using a General-Purpose account.

One of the distinctive features of Block and Append Blobs is their ability to be in Hot, Cool, or Archive tiers as they are files. As Page Blobs were designed to be disks, they cannot be put into Cool or Archive tiers.

Microsoft Azure Storage and MSP360 Products

We in MSP360 are working to bring support for each and every cloud storage on the market, bringing you more versatile for backup and storage of your files.

Backup to Microsoft Azure Blob

When you create a backup plan in MSP360 Backup, the first thing you have to do is to indicate the cloud storage of your choice. Microsoft Azure Blob is fully supported and ready for action.

Restore from Block Blob to Azure VM

Aside from backups, MSP360 Backup enables you to restore your image-based backups to Azure VM. The data can be fetched from any cloud storage service, including Azure Block Blob.

Support for Access Tiers

MSP360 Backups also supports different Azure Block Blob storage tiers, enabling you to upload either to Azure Cool Blob Storage or Azure Archive Storage.

Microsoft Azure and Explorer PRO Capabilities

We also have MSP360 Explorer for Azure — the cloud explorer that lets you list, download, upload, and change the access tier of files in Azure. It is available free of charge for the standard version, so be sure to check it out.

Conclusion

Microsoft Azure Storage is not the easiest to understand choice on the market but is definitely one of the most flexible. In fact, it offers more options than Amazon AWS, while substantially outperforming it in the pricing department. If you’re thinking of moving your IT infrastructure to the cloud, definitely take a look at Microsoft Azure.

MSP360 Managed Backup.
Simple. Reliable.

Powerful cross-platform backup and disaster recovery that leverages the public cloud to enable a comprehensive data protection strategy.

Windows Azure Storage

Аннотация: В данной лекции рассмотрены следующие вопросы: архитектура Windows Azure Storage – основной компоненты Windows Azure для управления памятью и хранением информации в облаке.

Цель лекции: Ознакомление с Windows Azure Storage – основной компонентой Windows Azure для управления памятью; с компонентами самой Azure Storage и их возможностями для пользователей.

Презентацию к данной лекции Вы можете скачать здесь.

6.1. Введение

Windows Azure Storage – компонента для управления памятью в Windows Azure.

Компонента Windows Azure Storage Services обеспечивает устойчивое и надежное хранение информации в облаке.

Для доступа к сервисам Storage необходима учетная запись хранения ( storage account ), обеспечиваемая через Windows Azure Platform Management Portal .

Основные сервисы памяти включают:

• Сервис Blob (Binary Large OBjects) для хранения текста или бинарных данных
• Сервис Queue для надежного сохраняемого обмена сообщениями между сервисами
• Сервис Table для работы со структурированной памятью, к которой можно обращаться по запросам.

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 .

6.2. Основные возможности Windows Azure Storage

• — Binary Large Object (BLOB) Service, простейший способ хранения бинарных данных в Windows Azure.
• — Table Service — поддержка работы с таблицами
• — Queue Service -поддержка надежного обмена сообщениями между экземплярами Web-ролей и Worker-ролей.
• — Windows Azure Drive позволяет приложениям для Windows Azure смонтировать Page Blob на отдельный том файловой системы NTFS VHD.

6.3. Преимущества Windows Azure 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.

6.4. Некоторые особенности предоставления сервисов Windows Azure. Storage

Объем использованной Памяти в Windows Azure вычисляется на основе Вашего использования ее в среднем (в течение какого-либо оплачиваемого периода какого-либо двоичного объекта, таблицы, очереди, либо Windows Azure Drive storage . Например, если Вы использовали 10 ГБ Памяти за первую половину месяца и ничего не использовали за вторую, Вам предъявят счет на использование (в среднем) 5 ГБ Памяти.

В СTP-версии Azure предоставляются три сервиса Памяти — таблицы (tables), очереди (queues) и бинарные объекты (blobs). В коммерческой версии они объединены под сервисами блокировки и кэширования. Они функционируют под управлением Azure Fabric .

Каждый сервис имеет программный . NET API и HTTP REST API . REST-узлы сети имеют следующий формат имен:

.[storage,blob,queue].core.windows.net.

Имеются также утилиты командной строки для разработки и сопровождения данных на стадиях их разработки и сопровождения.

6.5. Таблицы

Возможности.

Таблица — это структурированные, не требующие описаний в виде схем, масштабируемые хранилища данных, похожие на хранилище данных App Engine . Последняя является распределенной системой, которая по стилю проектирования очень похожа на Bigtable. Она рассчитана на хранение миллиардов объектов и терабайтов данных.

Модель сущности в таблице

Каждый объект имеет имя таблицы и набор свойств вида ключ / значение. Явное представление информации о схеме данных не требуется. Ограничения на объекты: максимальный объем – 1 МБайт, максимальное число свойств – 255.

Поддерживаются следующие типы свойств:

• строка ( string )
• двоичный объект ( binary )
• целое число ( int )
• длинное целое ( long )
• булевское значение ( bool )
• вещественное двойной точности ( double )
• глобальный идентификатор объекта ( guid )

Имеется три специальных свойства: ключ раздела ( partition key ), ключ строки в таблице ( row key ), и версия ( version ).

Ключ раздела идентифицирует раздел, т.е. группу объектов, которые должны храниться вместе. Ключ строки идентифицирует объект в разделе. Совокупность (ключ раздела, ключ строки в таблице) является первичным ключом (primary key) для объекта. Ключ раздела и ключ строки оба являются строками размера до 64 КБайт.

6.6. Очереди к таблицам

Кроме стандартных операций, таблицы поддерживают некоторую ограниченную форму очередей.

В CTP -версии поддерживается только отношение равенства для ключей с одним или несколькими свойствами. Результат выдается в лексикографическом порядке, в соответствии с ключом (partition, row). В коммерческой версии поддерживаются вторичные индексы, определяемые пользователем, для сортировки.

API для запросов из программ использует LINQ – упрощенный язык запросов, аналогичный языку запросов GQL, реализованный в Google App Engine . HTTP REST API использует интерфейс Astoria, основанный на использовании URL-адресов для обращения к сервисам для работы с данными ADO . NET .

6.7. Целостность и транзакции

Таблицы Azure полностью целостны, обращения к одному объекту строго синхронизированы, отсутствуют » dirty reads «. Для работы с каждым объектом поддерживаются транзакции в стиле ACID ( Asynchronous , Consistent , Isolated, Durable – известная парадигма для описания транзакций).

6.8. Реализация таблиц

Таблицы спроектированы аналогично хранилищам данных Bigtable and the App Engine .

Разделы (partitions) аналогичны блокнотам (tablets) Bigtable. Все объекты в разделе хранятся на одном сервере данных.

Транзакции реализованы аналогично App Engine datastore,. Используется управление версиями объектов.

6.9. Запросы. Возможности

Очереди аналогичны Amazon SQS. Они позволяют поставить сообщение в очередь и обрабатывать его позже, в слабо связанном виде.

Операции над очередями во время выполнения : enqueue (поставить сообщение в очередь), dequeue (удалить сообщение из очереди), delete (удалить из очереди все сообщения). Сообщения типизированы, их размер – до 8 КБайт.

Операция dequeue использует займы (lease) – средство синхронизации . Займ позволяет в течение определенного заданного интервала времени удерживать сообщение в состоянии, не видимом другим клиентам очереди. По умолчанию время завержки – до 30 секунд.

6.10. Бинарные объекты (Blobs)

Сервис blob служит для хранения «непрозрачных» бинарных объектов. Они аналогичны Amazon S3. Бинарные объекты могут создаваться и обрабатываться программным путем. Бинарные объекты идентифицируются уникальными, мнемоничными путями доступа в виде URL-адресов типа:

Размер бинарных объектов можнт быть до 50 ГБайт. Блоки до 64 МБайт могут обрабатываться непосредственно, большей длины – должны быть разделены на блоки. Каждый блок закачивается на сайт отдельно. В конце операции проверяется, все ли блоки закачаны.

Пространство имен для бинарных объектов – это иерархический URL-путь вида:

.blob. core.windows.net

Бинарные объекты можно изменять или клонировать, они не являются неизменяемыми.