Skip to content
June 9, 2012 / ahriman hpc mode

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

Итак, начну понемногу пояснять то, что произошло с Windows Azure. Основной пост здесь – http://habrahabr.ru/post/145471/.

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

Также и в Windows Azure – теперь доступно две опции избыточности: Locally Redundant Storage и Geo Redundant Storage.

Locally Redundant Storage (LRS) предоставляет хранилище с высокой степенью долговечности и доступности внутри одной географической локации (региона). Платформа хранит три реплики каждого элемента данных в одной главной географической локации, что гарантирует, что эти данные можно будет восстановить после сбоя общего характера (например, выхода из строя диска, узла, корзины и так далее) без простоя аккаунта хранилища и, соответственно, не влияя на доступность и долговечность хранилища. Все операции записи в хранилище выполняются синхронно в три реплики в трех различных доменах ошибок (fault domain), и только после успешного завершения всех трех операций возвращается код об успешном завершении транзакции. В случае использования локального избыточного хранилища, если датацентр, в котором размещены реплики данных, будет съеден динозавром, Microsoft свяжется с клиентом и сообщит о возможной потере информации и данных, используя контакты, приведенные в подписке клиента.

Geo Redundant Storage (GRS) предоставляет гораздо более высокую степень долговечности и безопасности, размещая реплики данных не только в главной географической локации, но и в какой-либо дополнительной в том же регионе, но за сотни километров. Все данные в сервисах хранилища блобов и таблиц географически реплицируются (но очереди – нет). С географически избыточным хранилищем платформа сохраняет опять же три реплики, но в двух локациях. Таким образом, если датацентр провалится сквозь землю, данные будут доступны из второй локации. Как и в случае первой опции избыточности, операции записи данных в главной географической локации должны быть подтверждены перед тем, как система вернет код успешного завершения операции. По подтверждению операции в асинхронном режиме происходит репликация в другую географическую локацию. Давайте посмотрим подробнее то, как происходит географическая репликация.

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

Что касается географической отказоустойчивости и того, как все восстанавливается в случае серьезных сбоев. Если серьезный сбой возник в главной географической локации, естественно что корпорация пытается по максимуму сгладить последствия. Однако, если всё совсем плохо и данные потеряны, может возникнуть необходимость в применении правил географической отказоустойчивости – клиент оповещается о возникшей катастрофе в главной локации, после чего соответствующие 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 сущности, а не именем блоба).

Итак, на данный момент географически избыточное хранилище включается по умолчанию для всех создающихся в production аккаунтов хранилища (и уже существующих). Можно отключить географическую репликацию на портале управления Windows Azure либо указать эту опцию при создании аккаунта хранилища.

Ценообразование: Стандартной опцией является географически избыточное хранилище, и текущая ее стоимость не изменилась. Стоимость же локально избыточного хранилища рассчитывается исходя из скидки (23%-34% в зависимости от количества хранимых данных) на географически избыточное хранилище. Обратите внимание, что если вы сначала выключите географическую репликацию и по прошествию какого-то времени снова включите ее, это действие будет расцениваться как единовременный пакет развертывания данных из главной географической локации во вторую. Количество трафика, которое будет содержаться в пакете, будет равно количеству данных в аккаунте хранилища, и будет оплачиваться согласно текущим ценам на исходящий трафик.

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

Естественно, что опциями избыточности нововведения не ограничиваются. Из концептуальных моментов необходимо отметить возможность конфигурации Windows Storage Analytics на портале управления Windows Azure. Портал можно использовать как для включения и выключения метрик и логирования, так и для конфигурации сервиса. После настройки метрик можно выбрать те метрики, которые вы хотите видеть на портале, и метрики и графики, которые должны собираться.

Раньше для тех же задач надо было использовать немного кода.

Немного пояснений по тому, что такое Windows Azure Storage Analytics и зачем оно может быть надо. Итак, это сервис, который предоставляет клиенту возможность отслеживать и анализировать использование данных, хранящихся в аккаунте хранилища (блобы, таблицы и очереди), используя эти данные для адаптации приложения к реальным нагрузкам. Аналитические данные состоят из логов (выполнившиеся запросы к аккаунтам хранилища) и метрик (статистика по объему и запросам блобов, таблиц и очередей).

Логи хранятся в виде блочных блобов в специальном контейнере блобов ($logs). Каждая запись-лог в блобе отображает какой-то сделанный запрос и содержит различную информацию (ID запроса, URL запроса. HTTP-статусы, имя аккаунта клиента, имя аккаунта хозяина, IP-адрес клиента и так далее). Логи позволяют выяснить:

  • Сколько анонимных запросов было выполнено от определенного диапазона IP-адресов?
  • К каким контейнерам блобов был наиболее активный доступ?
  • Сколько раз и каким образом был запрошен конкретный URL с Shared Access Signature?
  • Кто запросил удаление контейнера блобов?
  • Куда подевалось время, если запрос выполнялся слишком медленно?
  • Вообще запрос пришел ли на сервер или нет.

Метрики же резюмируют основную статистику для блобов, таблиц и очередей. При этом статистику можно подразделить на два типа – информацию о запросах (количество запросов по часам, средняя задержка на стороне серверов, средняя задержка E2E, средняя полоса пропускания, общее количество успешных и неуспешных запросов и т.д., и эта информация предоставляется на уровне сервиса и API и доступна для блобов, таблиц и очередей) и информацию об объеме (ежедневная статистика потребленного сервисом пространства, количество контейнеров и количество объектов, хранящихся внутри сервиса, доступна только для блобов). Метрики хранятся внутри специальной служебной таблицы в сервисе таблиц.

Все аналитические логи, статистика и данные метрик хранятся внутри вашего пользовательского аккаунта, и получить к ним доступ можно было только через стандартное REST API сервисов хранилища блобов и таблиц, теперь же и с помощью портала управления Windows Azure. Кроме этого, логи и метрики могут быть потреблены из любого сервиса, размещенного как в Windows Azure, так и в интернете или локального приложения, которое умеет работать и обрабатывать HTTP/HTTPS-запросы. Выключить или включить, как уже упоминалось, эти логи и метрики можно как с помощью REST API, так и с помощью портала управления Windows Azure. Также можно настроить срок, после которого данные будут автоматически удаляться.

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: