Добрый день, друзья ! Сегодня в данной публикации я коснусь очень важной темы объединения наших приложений, работающих на собственных серверах с приложениями, находящимися в облаке Windows Azure.
Итак, давайте собственно определимся зачем нам это нужно. Зачем нам объединять приложения на наших серверах с приложениями в облаке ? Почему бы собственно не взять готовое решение и не поместить его целиком, включая приложение и данные, в открытое облако ? Иногда такой вариант является вполне пригодным, но зачастую возникает целый ряд проблем, которые накладывают определенные ограничения на процесс переноса. Это могут быть как политические (например, запрет на размещение данных о жителях Европы на серверах, расположенных в Северной Америке) так и технические (например, невозможность физического запуска системы в условиях облачного окружения) ограничения. Для решения подобных проблем в Windows Azure существует целый слой интегрирующих технологий, позволяющих без прикладывания серьезных усилий объединять множество приложений в одно единое целое и не важно будут ли эти приложения функционировать в условиях Windows Azure либо на сторонних внешних серверах.
Как я уже сказал в Windows Azure существует целый интегрирующий стек, который удобно будет представить в послойном виде.
Весь стек представлен 4-мя уровнями, каждый из которых призван решать определенный круг задач. На каждом уровне функционирует соответствующая технология. Хочу отметить, что осветить каждую из них в одной публикации я физически не сумею, поэтому мы лишь поверхностно коснемся предназначения и особенностей реализации каждой из них.
Итак, на нижнем уровне мы видим технологию Windows Azure Connect. Она позволяет объединять наши сервера с виртуальными машинами Windows Azure на наиболее низком уровне. На уровне функционирования протокола IPSec. Это позволяет нам очень легко расширять интранет сеть путем добавления новых машин, работающих в облаке. Также нет никаких проблем с присоединением новых машин к Active Directory домену. Все будет выглядеть, как будто все ваши машины функционируют в рамках одного датацентра. Естественно, хоть это и выглядит очень просто и превосходно, не стоит забывать о времени ожидания, которое растет в случае обращения к «облачным» серверам. Уровнем выше функционирует технология Access Control, позволяющая относительно просто организовывать сценарии Single SignOn и Federated Authentication. Чуть выше расположен уровень, где функционирует технология AppFabric Service Bus. Она очень удобна, когда у нас есть много компонентов, которым необходимо взаимодействовать в обход современных ограничений сетевого ПО и оборудования, таких как NAT-трансляция и файрволлы. Последний уровень представлен технологией SQL Azure Data Sync, которая позволяет в автоматическом режиме синхронизировать SQL Azure базы данных с базами данных, находящимися на наших серверах. Для большего понимания давайте поверхностно коснемся особенностей взаимодействия и использования каждой из названных технологий.
Windows Azure Connect.
Как я уже говорил, данная технология позволяет объединять наши сервера с виртуальными машинами Windows Azure на базе протокола IPSec, что автоматически гарантирует высокую секьюрность решения. Следует отметить, что установка и настройка такого решения чрезвычайно проста. Если Вы когда-нибудь пытались настроить IPSec или VPN вручную, то скорее всего у Вас от этого остались лишь негативные воспоминания, так как этот процесс довольно таки сложный и рутинный. В условиях Windows Azure Connect мы всего лишь навсего настраиваем конфигурацию, тем самым присоединяя свои роли (Web, Worker, VM) к уже существующей сети. Какие могут быть сценарии применения этой технологии? Ну во-первых она очень удобна когда нам необходимо использовать наш собственный SQL Server, работающий во внутренней подсети. При использовании Windows Azure Connect – этот сценарий становится чрезвычайно простым в реализации. Во-вторых при помощи технологии можно удаленно администрировать облачные приложения и выявлять неполадки, например, при помощи PowerShell Remoting. В целом технология очень серьезная и чуть более подробно я постараюсь покрыть ее в последующих публикациях, а пока перейдем к следующей.
Federated Identity and Access Control.
Данную технологию я достаточно подробно описывал в одной из своих предыдущих публикаций. Вот ссылка на нее: http://feschenkoalex.blogspot.com/2011/04/windows-azure-access-control-service.html. Поэтому останавливаться на ней мы не будем, а сразу перейдем к технологии AppFabric Service Bus.
Windows Azure AppFabric Service Bus.
Итак, технология Service Bus. Очень мощная и востребованная на данный момент штуковина, которая позволяет нам делать многие вещи, среди которых стоит отметить :
На примитивном уровне функционирование приложений, объединенных при помощи Service Bus, представлено ниже.
Есть некоторые ключевые особенности этой технологии, которые я непременно хотел бы упомянуть. Во-первых, поддерживаются протоколы как HTTP так и TCP. Во-вторых, защита сервиса базируется на аутентификации, основанной на утверждениях (Claims Based Authentication), кроме того очень сильно упрощен процесс интеграции Service Bus и Access Control Service. Ну и в конце концов, как я уже говорил, технология работает поверх современных файрволлов и NAT-трансляторов.
В ближайших публикациях я подробно постараюсь разобрать эту составляющую часть Windows Azure, а пока перейду к заключительному уровню нашего первого рисунка.
SQL Azure Data Sync.
Очень часто в реальном мире нам необходимо синхронизировать данные наших приложений, поддерживая несколько реплик. Синхронизация может выполняться с различными целями, но главное здесь то, что Windows Azure предлагает нам технологию, позволяющую значительно упростить и ускорить процесс запуска механизма синхронизации между вашими хранилищами данных. Технология называется SQL Azure Data Sync. Я уже поверхностно касался этой технологии в одном из своих предыдущих постов (http://feschenkoalex.blogspot.com/2011/03/windows-azure-3-sql-azure-sql-azure.html).
Данная технология может применяться для большого количества полезных целей. Например, мы хотим использовать облако, но при этом мы также хотим оставить полностью у себя все данные приложения либо по меньшей мере держать копию данных на своих собственных серверах (для этого сценария чуть более реалистичным является вариант синхронизации SQL Azure базы данных с бд на локальном SQL Server ). Кроме того с помощью технологии очень удобно строить чрезвычайно масштабируемые системы, которые могут работать одновременно с несколькими репликами одной и той же SQL Azure базы данных.
Рисунком ниже можно увидеть ключевые особенности организации механизма синхронизации баз данных, находящихся на разных физических серверах.
Процессом синхронизации управляет агент, построенный на базе технологии Microsoft Sync Framework. Все, что требуется от разработчика для организации такой системы – это настройка правил: что синхронизировать, как часто и т.д. и т.п. Центральная консоль управления находится на dev-портале. С ее помощью мы имеем возможность определять кто синхронизируется и с кем, создавать синхронизационные группы, устанавливать направления синхронизации и порядок решения конфликтов. На данный момент эта технология находится с CTP версии, поэтому значительно ограничена. Сейчас пока что мы можем синхронизировать между собой только облачные базы данных .
Итак, сегодня мы с Вами очень обзорно коснулись чрезвычайно обширной и мощной составляющей части Windows Azure – это интеграционной инфраструктуры. В ее рамках на данный момент функционируют 4 технологии: Windows Azure Connect, Windows Azure Access Control Service, Windows Azure Service Bus и SQL Azure Data Sync, каждая из которых применяется для решения соответствующего круга задач. В последующих публикациях я более подробно остановлюсь на каждой из них и мы узнаем как использовать их на полную мощность. Спасибо за внимание !
Итак, давайте собственно определимся зачем нам это нужно. Зачем нам объединять приложения на наших серверах с приложениями в облаке ? Почему бы собственно не взять готовое решение и не поместить его целиком, включая приложение и данные, в открытое облако ? Иногда такой вариант является вполне пригодным, но зачастую возникает целый ряд проблем, которые накладывают определенные ограничения на процесс переноса. Это могут быть как политические (например, запрет на размещение данных о жителях Европы на серверах, расположенных в Северной Америке) так и технические (например, невозможность физического запуска системы в условиях облачного окружения) ограничения. Для решения подобных проблем в Windows Azure существует целый слой интегрирующих технологий, позволяющих без прикладывания серьезных усилий объединять множество приложений в одно единое целое и не важно будут ли эти приложения функционировать в условиях Windows Azure либо на сторонних внешних серверах.
Как я уже сказал в Windows Azure существует целый интегрирующий стек, который удобно будет представить в послойном виде.
Итак, на нижнем уровне мы видим технологию Windows Azure Connect. Она позволяет объединять наши сервера с виртуальными машинами Windows Azure на наиболее низком уровне. На уровне функционирования протокола IPSec. Это позволяет нам очень легко расширять интранет сеть путем добавления новых машин, работающих в облаке. Также нет никаких проблем с присоединением новых машин к Active Directory домену. Все будет выглядеть, как будто все ваши машины функционируют в рамках одного датацентра. Естественно, хоть это и выглядит очень просто и превосходно, не стоит забывать о времени ожидания, которое растет в случае обращения к «облачным» серверам. Уровнем выше функционирует технология Access Control, позволяющая относительно просто организовывать сценарии Single SignOn и Federated Authentication. Чуть выше расположен уровень, где функционирует технология AppFabric Service Bus. Она очень удобна, когда у нас есть много компонентов, которым необходимо взаимодействовать в обход современных ограничений сетевого ПО и оборудования, таких как NAT-трансляция и файрволлы. Последний уровень представлен технологией SQL Azure Data Sync, которая позволяет в автоматическом режиме синхронизировать SQL Azure базы данных с базами данных, находящимися на наших серверах. Для большего понимания давайте поверхностно коснемся особенностей взаимодействия и использования каждой из названных технологий.
Windows Azure Connect.
Federated Identity and Access Control.
Данную технологию я достаточно подробно описывал в одной из своих предыдущих публикаций. Вот ссылка на нее: http://feschenkoalex.blogspot.com/2011/04/windows-azure-access-control-service.html. Поэтому останавливаться на ней мы не будем, а сразу перейдем к технологии AppFabric Service Bus.
Windows Azure AppFabric Service Bus.
Итак, технология Service Bus. Очень мощная и востребованная на данный момент штуковина, которая позволяет нам делать многие вещи, среди которых стоит отметить :
- Чрезвычайное масштабирование приложений, на основе безопасного взаимодействия
- Безопасная консолидация приложений, работающих за ширмой файрволлов и NAT-трансляторов.
- Позволяет насладиться облаком без переписывания самих приложений
- и т.д и т.п
На примитивном уровне функционирование приложений, объединенных при помощи Service Bus, представлено ниже.
В ближайших публикациях я подробно постараюсь разобрать эту составляющую часть Windows Azure, а пока перейду к заключительному уровню нашего первого рисунка.
SQL Azure Data Sync.
Очень часто в реальном мире нам необходимо синхронизировать данные наших приложений, поддерживая несколько реплик. Синхронизация может выполняться с различными целями, но главное здесь то, что Windows Azure предлагает нам технологию, позволяющую значительно упростить и ускорить процесс запуска механизма синхронизации между вашими хранилищами данных. Технология называется SQL Azure Data Sync. Я уже поверхностно касался этой технологии в одном из своих предыдущих постов (http://feschenkoalex.blogspot.com/2011/03/windows-azure-3-sql-azure-sql-azure.html).
Данная технология может применяться для большого количества полезных целей. Например, мы хотим использовать облако, но при этом мы также хотим оставить полностью у себя все данные приложения либо по меньшей мере держать копию данных на своих собственных серверах (для этого сценария чуть более реалистичным является вариант синхронизации SQL Azure базы данных с бд на локальном SQL Server ). Кроме того с помощью технологии очень удобно строить чрезвычайно масштабируемые системы, которые могут работать одновременно с несколькими репликами одной и той же SQL Azure базы данных.
Рисунком ниже можно увидеть ключевые особенности организации механизма синхронизации баз данных, находящихся на разных физических серверах.
Итак, сегодня мы с Вами очень обзорно коснулись чрезвычайно обширной и мощной составляющей части Windows Azure – это интеграционной инфраструктуры. В ее рамках на данный момент функционируют 4 технологии: Windows Azure Connect, Windows Azure Access Control Service, Windows Azure Service Bus и SQL Azure Data Sync, каждая из которых применяется для решения соответствующего круга задач. В последующих публикациях я более подробно остановлюсь на каждой из них и мы узнаем как использовать их на полную мощность. Спасибо за внимание !
Комментариев нет:
Отправить комментарий