Добрый день, уважаемые коллеги.
В этом обзоре я постарался максимально просто рассказать о том, как обеспечиваются различные аспекты безопасности на платформе Windows Azure. Обзор состоит из двух частей. В первой части будет раскрыта основная информация — конфиденциальность, управление личностью, изолированность, шифрование, целостность и доступность на самой платформе Windows Azure. Во второй части обзора будет приведена информация об SQL Databases, физической безопасности, средствах обеспечения безопасности, которыми может воспользоваться клиент, сертификации платформы и рекомендациях по обеспечению безопасности.
Безопасность является одной из самых важных тем при обсуждении размещения приложений в «облаке». Растущая популярность облачных вычислений привлекает пристальное внимание к вопросам безопасности, особенно в свете наличия разделения ресурсов и мультитенантности. Аспекты мультитенантности и виртуализации облачных платформ вызывают необходимость в некоторых уникальных методах обеспечения безопасности, особенно учитывая такие типы атак, как side-channel attack (тип атак, базирующийся на получении некоторой информации о физической реализации).
Платформу Windows Azure после 7 июня 2012 года нельзя назвать SaaS, PaaS или какой бы то ни было платформой, теперь это скорее зонтичный термин, объединяющий под собой множество типов услуг. Microsoft предоставляет безопасную среду выполнения, обеспечивает безопасность на уровне операционной системы и инфраструктуры. Некоторые аспекты безопасности, реализованные на уровне поставщика облачной платформы, фактически лучше тех, которые доступны в локальной инфраструктуре. Например, физическая безопасность датацентров, где располагается Windows Azure, существенно надежнее, чем у подавляющего большинства предприятий и организаций. Сетевая защита Windows Azure, изоляция среды выполнения и подходы к обеспечению защищенности операционной системы существенно выше, чем при традиционном . Таким образом, размещение приложений в «облаке» позволяет улучшить безопасность ваших приложений. В ноябре 2011 года платформа Windows Azure и ее система управления информационной безопасностью были признаны British Standards Institute как удовлетворяющие сертификации ISO 27001. В сертифицированную функциональность платформы вошли сервисы вычислений, хранилища, виртуальной сети и виртуальной машины. Следующим шагом будет являться сертификация остальной функциональности Windows Azure: SQL Databases, Service Bus, CDN и др.
В целом, любая облачная платформа должна обеспечивать три основных аспекта безопасности клиентских данных: конфиденциальность, целостность и доступность, и облачная платформа Microsoft не является исключением. В этом обзоре я постараюсь раскрыть максимально подробно все те технологии и методы, которые применяются для обеспечения трех аспектов безопасности платформой Windows Azure.
Конфиденциальность
Обеспечение конфиденциальности позволяет клиенту быть уверенным, что его данные будут доступны только тем объектам, у которых есть соответствующее на то право. На платформе Windows Azure конфиденциальность обеспечивается с помощью следующих средств и методов:
- Управление личностью – определение того, является ли аутентифицировавшийся принципал объектом, имеющим доступ к чему-либо.
- Изолированность – обеспечение изолированности данных с использованием «контейнеров» как физического, так и логического уровня.
- Шифрование – дополнительная защита данных с помощью механизмов шифрования. Шифрование используется на платформе Windows Azure для защиты каналов коммуникаций и применяется для обеспечения более совершенной защиты данных клиентов.
Давайте рассмотрим все три перечисленных технологии подробнее.
Управление личностью
Начнем с того, что доступ к вашей подписке осуществляется с помощью безопасной системы Windows Live ID, которая является одной из самых старых и проверенных систем аутентификации в Интернет. Доступ к уже развернутым сервисам контролируется подпиской.
Развертывание приложений в Windows Azure можно осуществлять двумя способами – с портала Windows Azure и с помощью Service Management API (SMAPI). Service Management API (SMAPI) предоставляет веб-сервисы с помощью протокола Representational State Transfer (REST) и предназначен для разработчиков. Протокол работает поверх SSL.
Аутентификация SMAPI основана на создании пользователем пары публичного и приватного ключей и самоподписанного сертификата, который регистрируется на портале Windows Azure. Таким образом, все критичные действия по управлению приложениями защищены вашими собственными сертификатами. При этом сертификат не привязан к trusted root certificate authority (CA), вместо этого он является самоподписанным, что позволяет с определенной долей точности быть уверенным в том, что к защищенным таким образом сервисам и данным будет иметь доступ только определенные представители клиента.
Хранилище Windows Azure использует собственный механизм аутентификации на основе двух ключей Storage Account Key (SAK), которые ассоциированы с каждым аккаунтом и могут быть сброшены пользователем.
Таким образом, в Windows Azure реализована совершенная комплексная защита и аутентификация, общие данные о которой приведены в таблице.
| Субъекты | Объекты защиты | Механизм аутентификации |
| Клиенты | Подписка | Windows Live ID |
| Разработчики | Портал Windows Azure/SMAPI | Windows Live ID (портал), самоподписанный сертификат (SMAPI) |
| Экземпляры ролей | Хранилище | Ключ |
| Внешние приложения | Хранилище | Ключ |
| Внешние приложения | Приложения | Определяется пользователем |
Необходимо отметить, что в случае с сервисами хранилища для определения прав пользователя можно использовать (для всех сервисов хранилища – с версии 1.7, ранее – только для блобов) Shared Access Signatures. Shared Access Signatures ранее были доступны только для блобов, что позволяло хозяинам аккаунтов хранилища выдавать определенным образом подписанные URL для обеспечения доступа к блобам. Теперь же Shared Access Signature доступны и для таблиц и очередей в добавление к блобам и контейнерам. До момента внедрения этой фичи для того, чтобы совершить что-то из CRUD с таблицей или очередью, необходимо было быть хозяином аккаунта. Теперь же можно предоставить другому человеку ссылку, подписанную Shared Access Signature, и предоставить какие надо права. Функциональность Shared Access Signature в этом и заключается – детальный контроль доступа к ресурсам, определив, какие операции может совершить пользователь над ресурсом, имея Shared Access Signature. К списку доступных для определения Shared Access Signature операций относятся:
- Чтение и запись контента – в случае блобов тут ещё и их свойства и метаданные, а также блок-списки.
- Удаление, лизинг, создание снапшотов блобов.
- Получение списков элементов контента.
- Добавление, удаление, обновление сообщений в очередях.
- Получение метаданных очередей, включая количество сообщений в очереди.
- Чтение, добавление, обновление и вставка сущностей в таблицу.
Параметры Shared Access Signature включают в себя всю информацию, необходимую для выдачи доступа к ресурсам хранилища – параметры запроса в URL определяют временной промежуток, через который Shared Access Signature «протухнет», разрешения, предоставляемые данной Shared Access Signature, ресурсы, к которым предоставляется доступ и, собственно, сигнатуру, с помощью которой происходит аутентификация. Кроме этого в Shared Access Signature URL можно включить ссылку на хранимую политику доступа, с помощью которой можно предоставить ещё один слой контроля.
Естественно, что Shared Access Signature должны распространяться с использованием HTTPS и разрешать доступ на максимально короткий временной промежуток, необходимый для выполнения операций.
Типичным примером для использования Shared Access Signature является сервис адресной книги, одним условием для разработки которого является то, чтобы он мог масштабироваться для большого количества пользователей. Сервис предоставляет пользователю возможность хранить собственную адресную книгу в облаке и получать к ней доступ с любого устройства или приложения. Пользователь подписывается на услуги сервиса и получает адресную книгу. Можно реализовать этот сценарий с помощью ролевой модели Windows Azure, и тогда сервис будет работать как прослойка между клиентским приложением и сервисами хранилища облачной платформы. После аутентификации клиентского приложения оно будет получать доступ к адресной книге через веб-интерфейс сервиса, который будет посылать запросы, инициированные клиентом, в сервис хранилища таблиц облачной платформы. Однако конкретно в этом сценарии отлично смотрится использование Shared Access Signature для сервиса таблиц, и реализуется он довольно просто. SAS для сервиса таблиц можно использовать для предоставления прямого доступа к адресной книге приложению. Подобный подход позволяет увеличить степень масштабируемости системы и уменьшить стоимость решения, удалив прослойку, обрабатывающую запросы, в виде сервиса. Роль сервиса в данном случае будет сведена к обработке подписки клиентов и генерации токенов Shared Access Signature для клиентского приложения.
Подробнее про Shared Access Signatures можно почитать в специально посвящённой этой теме статье.
Дополнительной мерой обеспечения безопасности является принцип наименьших привилегий, который, собственно, является также и общепринятой рекомендуемой практикой. Согласно этому принципу, клиентам запрещен административный доступ к их виртуальным машинам (напомню, что все сервисы в Windows Azure работают на основе виртуализации), а программное обеспечение, запущенное ими, работает под специальным ограниченным аккаунтом. Таким образом тот, кто каким-либо образом хочет получить доступ к системе, должен провести процедуру повышения.
Всё, что передается по сети до Windows Azure и внутри платформы, надёжно защищено с помощью SSL, причем в большинстве случаев SSL-сертификаты являются самоподписанными. Исключение – передача данных вне внутренней сети Windows Azure, например, для сервисов хранилищ или fabric controller, которые используют сертификаты, выданные центром Microsoft.
Windows Azure Access Control Service
Что касается более сложных сценариев управления личностью, например, не просто вход по Live Id, но интеграция механизмов аутентификации Windows Azure и облачного (либо локального) приложения, то Microsoft предлагает собственный сервис Windows Azure Access Control Service. Windows Azure Access Control Service и предоставляет сервис для обеспечения федеративной безопасности и контроля доступа к вашим облачным или локальным приложениями. AD имеет встроенную поддержку AD FS 2.0 и всех провайдеров, которые поддерживают WS-Fed, + преднастроенными провайдерами на портале являются публичные провайдеры LiveID, FB, Google. Кроме этого, AD поддерживает протокол OAuth, OpenId и REST-сервисы.
 |
Windows Azure и Access Control Service (в том числе Windows Azure Active Directory) используют аутентификацию на основе утверждений. Эти утверждения могут включать любые сведения об объекте, которые позволяет провайдер идентификации, предоставляющий эти данные. Использование аутентификации на основе утверждений – один из наиболее эффективных методов решения сложных сценариев аутентификации. Так, многие веб-проекты используют утверждения – Google, Yahoo, Facebook и так далее. После аутентификации с использованием выбранного провайдера идентификации клиент получает уверждения с использованием WS-Federation либо Security Assertion Markup Language (SAML), которые затем в токене безопасности (контейнере, содержащем утверждения) передаются куда необходимо. Утверждения позволяют эффективно реализовать принцип единого входа (Single Sign-On), когда пользователи, войдя в систему, например, под своими учетными данными организации, автоматически получают доступ ко всем ресурсам.
Например, у клиента есть приложение, которое использует для аутентификации некое хранилище информации о пользователе, расположенное в локальном датацентре. Для этого используется специальный модуль аутентификации, реализующий определенный стандарт. В определенный момент становится необходимо реализовать не только отказоустойчивый механизм аутентификации с одним провайдером, но предоставить возможность пользователям аутентифицироваться через публичных провайдеров идентификации, например, Windows Live Id, Facebook и так далее. В модуль аутентификации добавляется логика работы с этими провайдерами идентификации. Но в том случае, если произойдет какое-либо, даже самое несерьезное, изменение в логике аутентификации, стандарте или синтаксисе у провайдера идентификации – разработчику необходимо будет вручную закодировать это изменение, что является неэффективным подходом к делу. Проблема приобретает ещё более серьёзный характер в случае миграции этого приложения в облако. Windows Azure Access Control Service позволяет решить именно этот сценарий, предлагая элегантно выстроенную инфраструктуру – пользователь при входе на страницу веб-приложения переводится сначала на Windows Azure Access Control Service, где выбирает необходимого провайдера идентификации, затем аутентифицируется с его помощью и входит в систему. Разработчик же в этом случае может полностью абстрагироваться от внутренних механизмов аутентификации, токенов, утверждений и так далее – за него всю работу будет делать Microsoft и Windows Azure Access Control Service. Таким образом можно реализовать распространённый сценарий, когда необходимо обеспечить управление личностью в ситуации с готовым приложением, мигрировавшим в облако.
Частым вопросом также бывает «что делать, если есть готовое приложение, аутентифицирующее пользователей с использованием их доменных учетных данных?». На этот вопрос есть ответ – достаточно добавить в связку приложение+AD+Windows Azure элемент Active Directory Federation Services 2.0, чтобы получить работающий сценарий по интеграции приложения, находящегося в облаке, и локальной инфраструктуры Active Directory. Для пользователя в данном случае аутентификация продолжает быть прозрачным процессом. Кроме этого, никакие учетные данные не передаются в облако – AD FS 2.0 выступает как провайдер идентификации, получающий утверждения о пользователе с некоторыми учетными данными, формирующий из этих утверждений токен безопасности и передающий его по защищенному каналу Access Control Service. Приложение же продолжает доверять только Windows Azure Access Control Service и получать только от него утверждения, тогда как эти утверждения могут исходить из совершенно разных источников.Разработчик может также создать собственного провайдера утверждений и реализовать любую необходимую логику по управлению списками пользователей и паролей, который будет принимать запросы на утверждения, создавать токены и др., либо использовать в качестве собственного провайдера утверждений ASP.NET Membership Provider.
Windows Azure Active Directory
Новейшим сервисом для осуществления сценариев аутентификации в Windows Azure является Windows Azure Active Directory. Сразу же стоит оговориться – этот сервис не является полным аналогом локального Active Directory, скорее он расширяет локальный каталог в облако, его «зеркалом».
Windows Azure Active Directory состоит из трех основных компонентов: REST-сервиса, с помощью которого можно создавать, получать, обновлять и удалять информацию из каталога, а также использовать SSO (в случае интеграции с Office 365, Dynamics, Windows Intune, например); интеграции с различными провайдерами идентификации типа Facebook и Google, а также библиотеки, упрощающей доступ к функциональности Windows Azure Active Directory. Изначально Windows Azure Active Directory использовался для Office 365. Сейчас Windows Azure Active Directory предоставляет удобный доступ к следующей информации:
Пользователи: пароли, политики безопасности, роли.
Группы: Security/Distribution-группы.
И другой основной информации (например, о сервисах). Всё это предоставляется с помощью Windows Azure AD Graph —инновационного социального корпоративного графа с интерфейсом, поддерживающим REST, с представлением проводника для легкого обнаружения информации и связей.
Как и в случае с Access Control Service, когда вы хотите интегрироваться с локальной инфраструктурой под управлением AD, вам необходимо установить и настроить Active Directory Federation Services Version 2.
Таким образом, с помощью Windows Azure Active можно создавать приложения как внутреннего, так и публичного плана, которые используют, например, Office 365, а также реализовывать сценарии федеративной аутентификации и синхронизации между локальной инфраструктурой Active Directory и Windows Azure.
Изолированность
В зависимости от количества экземпляров роли, определенного клиентом, Windows Azure создает равное этому числу количество виртуальных машин, которые называются экземплярами роли (для Cloud Services), после чего запускает развернутое приложение на этих виртуальных машинах. Эти виртуальные машины в свою очередь запускаются в гипервизоре, специально созданном для работы в облаке (гипервизор Windows Azure).
Разумеется, для того, чтобы реализовать эффективный механизм безопасности, необходимо соответствующим образом изолировать друг от друга экземпляры сервисов, обслуживающих отдельных клиентов, и данные, которые будут храниться в сервисах хранилища.
.
Учитывая виртуальное «происхождение» всего и вся на платформе, критичным является обеспечение изоляции так называемой Root VM (защищённая система, где Fabric Controller размещает собственных Fabric Agent, которые, в свою очередь, управляют Guest Agent, размещаемыми на клиентских виртуальных машинах) от гостевых виртуальных машин и гостевых виртуальных машин друг от друга. Windows Azure использует свой собственный гипервизор, слой виртуализации, разработанный на основе Hyper-V. Он запущен непосредственно на оборудовании и разделяет каждый узел на определенное количество виртуальных машин. Каждый узел имеет Root VM, на которой запущена хостовая операционная система. Windows Azure использует в качестве этой операционной системы сильно обрезанную версию Windows Server, на которой установлены исключительно необходимые сервисы для обслуживания хостовых виртуальных машин, что сделано как для увеличения производительности, так и уменьшения «поверхности» атаки. Кроме этого, виртуализация в облаке привела к появлению новых типов угроз, например:
• Повышение привилегий за счет атаки из виртуальной машины на физический хост либо на другую виртуальную машин
• Выход за пределы виртуальных машин и выполнение кода в контексте ОС физического хоста с захватом управления ОС (Jailbreaking, Hyperjacking)
Все операции доступа к сети и дисковые операции управляются операционной системой на Root VM. Фильтры на виртуальной сети гипервизора управляют трафиком в и из виртуальных машин, предотвращая также различные атаки на основе снифинга. Кроме этого установлены другие фильтры, блокирующие броадкасты и мультикасты (кроме, разумеется, DHCP lease). При этом правила подключения кумулятивны – например, если экземпляры ролей А и Б принадлежат разным приложениям, то А может инициировать открытие подключения к Б только в том случае, если А может открывать подключения в Интернет (что необходимо настраивать), а Б может принимать подключения из Интернет.
Что касается фильтров пакетов, то контроллер, имея список ролей, берет этот список и транслирует его в список экземпляров этих ролей, после чего транслирует полученный список в список IP-адресов, который далее используется агентом для настройки фильтров пакетов, разрешающим intra-application подключения к этим IP-адресам.
Необходимо отметить, что сам Fabric Controller максимально защищён от потенциально взломанных Fabric Agent-ов на хостах. Канал связи между контроллером и агентами двунаправленный, при этом агент реализует сервис, защищенный SSL, который используется контроллером и может отвечать только на запросу, но не может инициировать создание подключения к контроллеру. Кроме этого, если такое получается, что существует контроллер или устройство, которое не умеет SSL, оно располагается в отдельном VLAN-е.
VLAN-ы в Windows Azure используются достаточно активно. Прежде всего, они используются для обеспечения изолированности контроллеров и других устройств. VLAN-ы делят сеть таким образом, что между двумя VLAN-ами не может возникнуть «разговора» иначе кроме как через маршрутизатор, что предотвращает вредоносную работу скомпрометированного узла – например, подмену трафика или его просмотр. На каждом кластере есть три VLAN-а:
1) Основной VLAN соединяет недоверенные клиентские узлы.
2) VLAN контроллера – доверенные контроллеры и поддерживаемые системы.
3) VLAN устройств – доверенные устройства инфраструктуры (например, сетевые).
Примечание: коммуникации между VLAN-ом контроллера и основным VLAN-ом возможны, но инициировать подключение может только контроллер к основному, но никак не наоборот. Аналогично коммуникации заблокированы от основного VLAN-а к VLAN-у устройств.
Шифрование
Эффективным средством обеспечения безопасности является, конечно же, шифрование данных. Как уже не раз писалось выше, всё, что только можно, защищается SSL. Клиент может использовать Windows Azure SDK, расширяющий базовые .NET библиотеки возможностями интеграции .NET Cryptographic Service Providers (CSP) в Windows Azure, например:
1) Полный набор функциональности, связанной с криптографией, например, MD5 и SHA-2.
2) RNGCryptoServiceProvider – класс для генерации случайных чисел, достаточных для реализации достаточного для криптографии энтропии.
3) Алгоритмы шифрования (например, AES), проверенные годами реального использования.
4) И т.д.
Все управляющие сообщения, передающиеся по каналам связи внутри платформы, защищаются протоколом TLS с криптографическими ключами длиной минимум 128 разрядов.
Все вызовы операций к Windows Azure делаются с использованием стандартных протоколов SOAP, XML, REST-based. Канал коммуникации может быть зашифрован либо не зашифрован в зависимости от настроек.
Что также необходимо учитывать при работе с данными в Windows Azure – на уровне сервисов хранилища данные клиента по умолчанию не шифруются – то есть как положены они в хранилище блобов или таблиц, в таком виде они и хранятся. В том случае, если необходимо шифровать данные, можно сделать это либо на стороне клиента, либо воспользоваться функциональностью Trust Services (http://www.microsoft.com/en-us/sqlazurelabs/labs/trust-services.aspx), необходимой для шифрования на стороне сервера. В случае использования Trust Services данные могут быть расшифрованы только авторизованными пользователями.
Microsoft Codename «Trust Services» – это фреймворк для шифрования, который используется на уровне приложения для защиты важных данных внутри ваших облачных приложений, хранимых в Windows Azure. Зашифрованные фреймворком данные могут быть расшифрованы только авторизованными клиентами, что позволяет распространять зашифрованные данные. При этом поддерживается поиск по зашифрованным данным, шифрование потоков, а также разделение ролей для администрирования данных и их публикации.
Для особенно критичных данных можно использовать гибридное решение, когда важные данные хранятся локально, некритичные же в хранилище Windows Azure либо SQL Databases.
Целостность
Когда клиент использует данные в электронном виде, он вполне закономерно ожидает, что эти данные будут защищены от изменения как намеренного, так и случайного. На Windows Azure обеспечение целостности гарантируется, во-первых, тем, что клиенты не имеют административных привилегий на виртуальные машины на вычислительных узлах, во-вторых — код выполняется под Windows-аккаунтом с минимальными привилегиями. Долговечного хранилища на ВМ нет. Каждая ВМ соединена с тремя локальными виртуальными дисками (VHD):
* Диск D: содержит одну из нескольких версий Windows. WA предоставляет различные образы и своевременно обновляет их. Клиент выбирает наиболее подходящую версию и, как только становится доступна новая версия Windows, клиент может переключиться на неё.
* Диск E: содержит образ, созданный контроллером, с содержимым, предоставленным клиентом – например, приложением.
* Диск C: содержит конфигурационную информацию, файлы подкачки и прочие служебные данные.
Диски D: и E: являются, разумеется, виртуальными дисками, и являются read-only (ACL, списки доступа, содержат определенные права на запрет доступа от клиентских процессов). Однако для операционной системы оставлена «лазейка» — эти виртуальные диски реализованы в виде VHD + дельта-файлы. Например, когда платформа обновляет VHD D:, содержащий операционную систему, дельта-файл этого диска очищается и заполняется новым образом. Так же с другими дисками. Все диски возвращаются к исходному состоянию в том случае, если экземпляр роли переносится на другую физическую машину.
Доступность
Любому бизнес-клиенту или простому физическому лицу, выкладывающему сервис в облако, критически важна максимально возможная его доступность как для потребителей, так, собственно, и для клиента. Облачная платформа Microsoft предоставляет определённый слой функциональности, реализующей избыточность и, тем самым, максимально возможную доступность данных клиента.
Самым важным понятием, раскрывающим основной механизм обеспечения доступности на Windows Azure, является репликация. Давайте рассмотрим новые механизмы (а они действительно новые – официальный анонс произошел 7 июня 2012 года) подробнее.
Locally Redundant Storage (LRS) предоставляет хранилище с высокой степенью долговечности и доступности внутри одной географической локации (региона). Платформа хранит три реплики каждого элемента данных в одной главной географической локации, что гарантирует, что эти данные можно будет восстановить после сбоя общего характера (например, выхода из строя диска, узла, корзины и так далее) без простоя аккаунта хранилища и, соответственно, не влияя на доступность и долговечность хранилища. Все операции записи в хранилище выполняются синхронно в три реплики в трех различных доменах ошибок (fault domain), и только после успешного завершения всех трех операций возвращается код об успешном завершении транзакции. В случае использования локального избыточного хранилища, если датацентр, в котором размещены реплики данных, будет по какой-либо причине выведен из строя полностью, Microsoft свяжется с клиентом и сообщит о возможной потере информации и данных, используя контакты, приведенные в подписке клиента.
Geo Redundant Storage (GRS) предоставляет гораздо более высокую степень долговечности и безопасности, размещая реплики данных не только в главной географической локации, но и в какой-либо дополнительной в том же регионе, но за сотни километров. Все данные в сервисах хранилища блобов и таблиц географически реплицируются (но очереди – нет). С географически избыточным хранилищем платформа сохраняет опять же три реплики, но в двух локациях. Таким образом, если датацентр перестанет работать, данные будут доступны из второй локации. Как и в случае первой опции избыточности, операции записи данных в главной географической локации должны быть подтверждены перед тем, как система вернет код успешного завершения операции. По подтверждению операции в асинхронном режиме происходит репликация в другую географическую локацию. Давайте посмотрим подробнее то, как происходит географическая репликация.
Когда вы совершаете операции создания, удаления, обновления и так далее в хранилище данных, транзакция полностью реплицируется в три совершенно разных узла хранилища в трех разных доменах ошибок и обновлений в главной географической локации, после чего клиенту возвращается код успешного завершения операции и в асинхронном режиме подтвержденная транзакция реплицируется во вторую локацию, где полностью реплицируется в три совершенно различных узла хранилища в разных доменах ошибок и обновлений. Общая производительность при этом не падает, так как всё совершается асинхронно.
Что касается географической отказоустойчивости и того, как все восстанавливается в случае серьезных сбоев. Если серьезный сбой возник в главной географической локации, естественно что корпорация пытается по максимуму сгладить последствия. Однако, если всё совсем плохо и данные потеряны, может возникнуть необходимость в применении правил географической отказоустойчивости – клиент оповещается о возникшей катастрофе в главной локации, после чего соответствующие DNS-записи перезаписываются с главной локации на вторую (account.service.core.windows.net). Разумеется, в процессе перевода DNS-записей вряд ли что-то будет работать, но по его завершению существующие блобы и таблицы становятся доступными по их URL. После завершения процесса перевода вторая географическая локация повышается в статусе до главной (до тех пор, пока не случится очередной выход из строя датацентра). Также сразу по завершению процесса повышения статуса датацентра инициируется процесс создания новой второй географической локации в этом же регионе и дальнейшей репликации данных.
Всё это контролируется Fabric Controller. В том случае, если установленные на виртуальные машины гостевые агенты (GA) перестают отвечать, контроллер переносит всё на другой узел и перепрограммирует сетевую конфигурацию для обеспечения полной доступности.
Также на платформе Windows Azure есть такие механизмы, как домены обновлений и домены ошибок, с помощью которых также гарантируется постоянная доступность развернутого сервиса даже во время обновления операционной системы либо аппаратных ошибок.
Домены ошибок — это некий физический юнит, контейнер развертывания, и обычно он ограничивается реком (rack). Почему он ограничен реком? Потому что, если домены расположить в разных реках, то получится, что экземпляры будут расположены так, что не будет достаточной вероятности их общего выхода из строя. Кроме этого, ошибка в одном домене ошибок не должна приводить к возникновению ошибок в других доменах. Таким образом, если что-то ломается в домене ошибки, весь домен помечается как сломанный и развертывание переносится в другой домен ошибок. На данный момент контролировать количество доменов ошибок нельзя — этим занимается Fabric Controller.
Домены обновлений представляют из себя сущность более контролируемую. Над доменами обновлений есть определенный уровень контроля, и пользователь может совершать инкрементальные или rolling-обновления группы экземпляров своего сервиса в один момент времени. Отличаются домены обновлений от доменов ошибок еще и тем, что являются логической сущностью, тогда как домены ошибок — физической. Так как домен обновлений логически группирует роли, одно приложение может быть расположено в нескольких доменах обновлений и в то же время только в двух доменах ошибок. В этом случае обновления могут быть осуществлены сначала в домене обновлений №1, затем в домене обновлений №2 и так далее.
Каждый центр обработки данных имеет как минимум два источника электроэнергии, в том числе автономный источник электропитания. Элементы управления средой автономны и будут функционировать до тех пор, пока системы подключены к сети Интернет.
Автор: ahriman
