Введение в облачные решения Microsoft

Размещено на http://www.allbest.ru/

1. Введение в Cloud Computing

Прежде чем начать рассматривать облачные вычисления, необходимо охарактеризовать методику распределенной обработки данных.

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

Распределенные вычисления являются способом решения сложных задач, требующих больших вычислительных мощностей, основанном на объединении нескольких компьютеров в параллельную вычислительную систему.

В качестве исторического примера распределенных вычислений можно привести решение французского математика и вычислителя при французском правительстве барона Гаспара де Прони.

Под его руководством была начата работа по уточнению логарифмических и тригонометрических таблиц, в связи с переходом на метрическую систему. Для того времени требовалось осуществление огромного объема вычислений. Де Прони перенес идею о разделении труда на вычислительный процесс, исполнители были распределены по трем уровням:

низший уровень - люди-вычислители (computers), которые должны были только аккуратно складывать и вычитать числа;

средний уровень - "технологи", которые занимались организацией конкретного рутинного вычислительного процесса;

высший уровень - математики, организовывающие подготовку математического обеспечения и обобщения полученных результатов.

Характеристика распределенной обработки данных

Суть распределенной обработки данных заключается в том, что пользователь и прикладное программное обеспечение могут работать с удаленными средствами посредством каналов связи.

Компьютеры, являющиеся частями распределенной среды обработки данных делятся на серверы и клиенты. Первые предоставляют вычислительные ресурсы вторым.

Управление распределенной средой осуществляется сетевой операционной системой. Кроме того, данная среда подразумевает наличие распределенной базы данных и инструментарий для управления этой базой.

Преимущества распределенной системы обработки данных:

возможность обслуживания большого числа пользователей;

снятие пиковых нагрузок с централизованной БД, путем распределения обработки и хранения локальных БД;

обеспечение доступа исполнителей к вычислительным ресурсам всей сети;

обеспечение симметричного обмена данными между пользователями сети.

В зависимости от способа распределения данных, выделяют следующие способы организации обработки данных:

централизованный;

децентрализованный;

смешанный.

Централизованная организация данных. С точки зрения реализации, является наиболее простым вариантом организации. Имеется единственная централизованная база данных, доступ к которой организовывается и регулируется сервером, на котором она находится.Доступ осуществляется при помощи удаленного запроса.

В настоящее время все большую популярность набирает идея добровольного использования для организации вычислений компьютеров обычных пользователей.

Преимуществом данного способа являются: простота реализации и поддержки; недостатком - ограничение на параллельную обработку данных, поскольку все запросы направляются к единственному серверу.

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

Существование копий отдельных частей базы не допускается.

Преимущества данного метода:

большая часть запросов удовлетворяется локальными базами, что снижает временные затраты;

увеличивается доступность данных;

повышенная надежность хранения данных;

частичная работоспособность системы при выходе из строя одного сервера.

Недостатки:

могут возникнуть запросы или транзакции, требующие доступа ко всем серверам, что увеличивает время ожидания;

необходимо наличие информации о хранении данных в БД.

Смешанный подход. Подразумевает объединение двух способов децентрализации: разбиения и дублирования. Возникает необходимость наличия информации о том, где в сети размещены данные. Достигается компромисс между требуемым объемом памяти под базу в целом и объемом памяти, необходимом каждому серверу. При этом легко организуется параллельная обработка данных. Тем не менее остаются такие проблемы как: надежность и выполнение требований к памяти. Данный подход можно реализовывать только при наличии сетевой системы управления базой данных, обеспечивающей хранение, целостность и безопасность хранимых данных.

Термин "облачные" возник из способа представления Интернета, как облака на различных диаграммах, иллюстрациях и схемах.

Найти человека, чья работа или интерес связан со сферой информационных технологий, ничего не слышавшего про "облачные вычисления" будет крайне затруднительно.

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

Такой ажиотаж объясняется просто - появилось решение, способ, позволяющий существенно сократить расходы на ИТ - услуги, отказаться от инвестирования в инфраструктуру и расходов, связанных с ее сопровождением и модернизацией, свести времяразвертывания приложения к минимуму.

Существует три основные модели расположения приложений:

на стороне заказчика;

хостинг;

в "облаке".

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

Основной сложностью данной модели являются существенные затраты на формирование ИТ - инфраструктуры, отвечающей требованиям бизнеса и используемых приложений, а также затраты, связанные с ее сопровождением и модернизацией.

В качестве положительно момента можно отметить, что инфраструктура, аппаратное и программное обеспечение полностью подконтрольны заказчику.

Хостинг. Данная модель развертывания приложений получила развитие в связи с распространением глобальной сети и увеличением ее роли в профессиональной деятельности человека. Ранее такая модель называлась Application Service Provider (ASP), теперь - Software as a service (SaaS).



2. Облачные решения: возможности, преимущества, риски

Особенности проектирования облачных решений

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

Таким образом, при проектировании "облачных" решений необходимо учитывать следующее (на примере платформы Windows Azure ):

Любое приложение, являющееся частью "облака" - удаленный сервис. На этапе планирования решения необходимо учитывать временные задержки, между отправкой запроса и получением результата, а также необходимость контроля статуса соединения и его возобновления.

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

Ряд сценариев, стоимость которых велика , в случае их реализации на основе локальной инфраструктуры (к примеру обработка больших объемов данных), могут быть реализованы в "облачном" решении в виде платформенных сервисов.

Управление выделением вычислительных ресурсов для приложения, их сопровождение осуществляется платформой.

Стоимость облачного решения. Данное понятие стало актуальным при появлении "облачных решений". Рассмотрим его более детально.

Стоимость "облачного" решения

При использовании "облака" заказчиком оплачивается аренда вычислительных ресурсов, что и является основной статьей расходов, при использовании такого решения.

В первую очередь, на стоимость решения будет влиять трафик - объем переданных, или полученных данных. Для уменьшения стоимостьданной составляющей целесообразно использовать сжатие данных, переход к SOA - архитектуре и размещение кода, активно работающего с данными рядом с их хранилищем (т.е. вычисления не будут выходить за рамки "облака" и влиять на объем передаваемой информации).

Стоимость второй компоненты - вычислительных ресурсов - начинает измеряться с момента начала развертывания приложения и зависит от мощности предоставленных виртуальных машин.

Третьей компонентой является хранилище данных. Стоимость хранения и обработки данных определяется их объемом и количеством операций с ними. Таким образом, для уменьшения стоимость данной компоненты целесообразно подбирать хранилище оптимального размера и минимизировать количество операций с данными.

Мультитенантная архитектура

Мы рассмотрели, из чего складывается стоимость "облачного" решения. Так каким же образом стоит выстраивать архитектуру приложения, чтобы минимизировать затраты не снижая качества предоставляемых услуг?

Таким способом снижения стоимости вычислительных ресурсов и хранилища данных является так называемая мультитенантная архитектура приложения.

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

Отличие данной архитектуры от обычной заключается в том, что, в отличие от общего случая, когда каждая группа пользователейиспользует свой экземпляр приложения и свою изолированную БД, состоит в том, что мультитенантное приложение обладает встроенными возможностями для обслуживания нескольких групп пользователей.

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

Рассмотрим этапы перехода к мультитенантной архитектуре:

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

Настраиваемая архитектура. В данном случае приложение, либо сервис настраивается для каждого конкретного пользователя через конфигурацию. Т.е. каждый пользователь работает со своей копией приложения, не смотря на то, что копии идентичны. Вычислительные мощности не разделяются между различными экземплярами приложения, что также не позволяет добиться повышения эффективности за счет увеличения масштабов.. Разделения же самого приложения может быть как виртуальным, так и физическим.

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

Масштабируемая архитектура. Данная модель поддерживает мультитенатный подход, а также возможность горизонтального масштабирования. При этом новые экземпляры приложений добавляются в общий пул. Общая нагрузка распределяется по всей инфраструктуре. Архитектура настраивается через конфигурацию.

Модели организации мультитенантного хранилища данных

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

Совместно используемые базы данных с разными схемами. Все пользователи работают с одной БД, но имеют различные наборы предопределенных полей. Наиболее полезен данный вариант в случае, если хранение данных разных пользователей в одной таблице допустимо, а также заранее известно какие поля потребуются. Может привести к ситуации разряженного наполнения таблиц.

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

Прежде, чем перейти к рассмотрению преимуществ и рисков для бизнеса, вкратце рассмотрим подход SOA (Service-oriented architecture).

SOA, или сервисно - ориентированная архитектура - подход, суть которого заключается в разработке программного обеспечения, основанной на использовании сервисов со стандартизированными интерфейсами. Иными словами, приложение "собирается" по частям из нескольких модулей - комплектующих, а не пишется "от и до".

Главными целями, к достижению которых стремится SOA, являются:

повышение масштабируемости создаваемых систем;

упрощение процессов контроля и управления созданными системами;

сокращение издержек, связанных с разработкой приложений;

увеличение доли повторного использования кода;

независимость систем от платформ, инструментов разработки и языков программирования.

В основе данного подхода лежат:

многократное использование функциональных элементов;

устранение дублирования функционала;

стандартизация и унификация типовых процессов;

переход компаний на функциональную организацию.

Одним из основных преимуществ SOA является надежность, особенно при реализации, основанной на применении веб - технологий.

При планировании SOA - архитектуры важно помнить о необходимость наличия централизованного репозитория - справочника всех доступных сервисов. Данный справочник должен обеспечивать группировку сервисов по бизнес - функциям, подразделениям, источникам данных и т.п. Классификация сервисов должна быть построена таким образом, чтобы обеспечить быстрый поиск разработчиками необходимых им сервисов для создания новых приложений. Компоненты, из которых собирается приложение представляют собой "черные ящики".

Принципы SOA:

архитектура не должна быть привязана к какой - либо технологии;

система не должна зависеть от используемой платформы;

система не должна зависеть от применяемых языков программирования;

используемые сервисы должны быть независимы от конкретных приложений и обладать стандартизованными интерфейсами доступа к ним;

сервисы должны быть "слабосвязанными" между собой.

SOA - не является продуктом, или спецификацией. Если вы хотите реализовать данный подход, то потребуется тщательное и детальное планирование выстраиваемой архитектуры.

Преимущества SOA, SaaS и облачных решений

Рассмотрим более детально, какие именно преимущества способен извлечь бизнес из применения SOA, SaaS и облачных решений:

Повышение эффективности предоставления услуг. Достигается более глубокое понимание, что же именно необходимо для бизнеса, за счет разработки измеримых компонентов (SOA). Компаниям, реализующим "облачный" подход с использованием SOA и SaaS нет нужны расходовать финансовые, человеческие и ИТ - ресурсы на поддержание собственной инфраструктуры.

Гибкость. Сформированные службы обладают высокой совместимостью. Новые решения образуются за счет объединения служб ранее созданных решений, что повышает скорость реакции ИТ - служб на постоянно возникающие изменения в потребностях целевой аудитории.

Масштабирование. Возможность быстро получить необходимое количество ресурсов обеспечивает гибкое масштабирование без внесения ощутимых организационных изменений.

Доступность. Для доступа к "облачной" платформе необходимо лишь Интернет - соединение.

Производительность. Территориально распределенные центры данных, ресурсы и платформы достигают величин производительности недоступных для инфраструктуры отдельной компании.

Контроль. Возможность сочетания различных вариантов размещения приложений: на собственных серверах, на серверах "облака" или их сочетание, позволяет получить необходимую степень контроля за приложением и объединять имеющиеся ресурсы (локальные и "облачные") для решений текущих задач.

Разумеется, кроме преимуществ у "облачных" подходов есть и ряд рисков.

Риски SOA и SaaS

Существенная прибыль и экономия возможна в случае, если производительность ранее используемого приложения была низка. В ином случае, переход на SaaS - решение может оказаться даже убыточным. Таким образом, не стоит направлять усилия на изменение решения, от которого не зависит прибыль.

Сложности проектирования. Всегда есть риск, что спроектированные и реализованные решения не будет приносить заявленных преимуществ. Это может случиться по разным причинам: от ошибок проектирования, до несоответствия решения предъявляемым к нему требованиям (к примеру, конфиденциальность данных).

Риски, связанные с реализацией решения. Для построения SOA - архитектуры и работы с "облачными" решениями коллектив должен обладать соответствующими компетенциями и опытом, не только в разработке, но и в проектировании решений. Влияние данного риска можно минимизировать, путем прохождения обучения и заключения партнерских соглашений с фирмой - поставщиком.

Риски использования. Переход на новую модель управления и работы требует начальных инвестиций, для реорганизации технологических процессов и методов работы.

Таким образом, прежде чем начать переход на новый стиль работы, или принять решение о необходимости такового, необходимо:

провести анализ бизнес - функций, возможно сначала необходимо перевести на новую основу сравнительно небольшую и автономную часть бизнеса, сравнения эффективности "до" и "после";

сформировать план технологического развития - применение "облачных" решений должно соответствовать нуждам компании и ее клиентов, первоначально имеет смысл только дополнять уже существующие решения там, где это имеет смысл;

поддерживать план технологического развития - риски и проблемы будут возникать всегда, только по мере внедрения станет понятно, где и каким образом SOA, SaaS и "облака" могут быть наиболее полезны, необходимо всегда четкое понимание того, что происходит с бизнесом, какие есть проблемные места и как их можно устранить, либо степень их влияния.

Мифы о SaaS

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

Миф №1. Хранить информацию на сервере сторонней компании небезопасно (или "Организация не может отказаться от услуг SaaS - поставщика, не потеряв данные").

По статистике, как правило утечка данных происходит по внутриорганизационным каналам. Т.е. риск потери данных из-за кражи сотрудниками значительно выше, чем сбои в работе поставщика SaaS - услуг. Риски существуют всегда, необходимо грамотно их соизмерять.

Миф №2. Невозможно принять оперативные меры, в случае некорректной работы арендуемого программного обеспечения.

SaaS -приложение, в настоящий момент, функционально не отличается от аналогичного desktop - приложения. Функции оперативного управления и контроля приложения, как правило, осуществляются самим клиентом, в то время как, сопровождение, обновление и т.п. - функции поставщика услуг.

Миф №3. Организация, оплатившая длительную аренду, переплачивает (или "Экономия при использовании SaaS неочевидна").

Зачастую, при расчете затрат упускают из вида, что в стоимость SaaS включены: ПО, оборудование, плата за электроэнергию, каналы связи, доступ, архивирование, оплата труда персонала.

Миф №4. SaaS подходит только для малого и среднего бизнеса.

Практика мировых поставщиков "облачных" услуг показывает, что доля крупных компаний среди клиентов SaaS увеличивается.

Что и когда нужно переводить в облако

Предыдущая лекция уже содержала положение , что не каждое решение или сервис следует немедленно переводить на "облачную" основу. В помощь проектировщикам решений, приведем некоторые соображения касательно того, в каком случае "облака" будут наиболее выгодными.

Эволюция развития сферы IT - услуг, в частности, концепция "облачных" вычислений позволяют предположить, что рано или поздно, но все компании будут либо формировать свои "облака", либо арендовать облачные платформы. При этом, очевидно, что построением собственных "облаков" займутся крупные компании, особенно те из них, кто уже вложился в формирование собственных центров обработки данных.

Согласно статистике наиболее востребованы следующие SaaS - приложения (см п. 4 списка дополнительных источников):

Почта и коммуникации;

Антивирусные системы;

Службы технической поддержки;

Проектный менеджмент;

Дистанционное обучение.

Когда же следует задуматься об использовании "облака"? Самый очевидный ответ - в тот момент, когда нехватка IT - ресурсов станет очевидной и острой. Но, строго говоря, если такая ситуация возникает, то это говорит о том, что задуматься над реорганизацией IT - инфраструктуры следовало много раньше. Отметим, некоторые косвенные признаки, по наличию которых можно судить о назревающей необходимости в "облачном" обеспечении:

Необходимость быстро разворачивать новые версии сред разработки и тестирования.

Необходимость отсутствия ограничений на число экземпляров различных вариантов пользовательских сред.

Необходимость оперативного учета количества и стоимости потребляемых IT - ресурсов.

Сценарии использования облака

Существует два способа использования "облачных" технологий:

1. Размещение приложения в "облаке"

В данном случае, само приложение и данные полностью находятся в рамках "облака". Т.е. клиенту предоставляется полностью готовый к использованию сервис. При этом сам код и данные приложения развертываются либо как PaaS, либо как IaaS. В первом случае, код и данные помещаются в пакет, публикуемый в облаке, во втором - контроль и управление приложением осуществляется на уровне виртуальной машины.

2. Использование сервисов "облака"

Данные сервисы доступны посредством стандартных протоколов передачи данных в сети Интернет и, благодаря этому, не зависят от платформы или устройств. При этом, можно как использовать встроенные сервисы облачных платформ, так и размещать в облаке собственноручно созданные. При этом, могут быть использованы следующие варианты использования сервисов, при которых часть кода остается в рамках локальной инфраструктуры:

перенос данных в "облако", их часть, или все данные остаются в локальной инфраструктуре;

перенос кода приложения в "облако", все данные, или их часть остается в локальной инфраструктуре;

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

Стратегия развертывания облака

Во - первых, перед началом процесса формирования "облака" необходимо убедиться в том, что это именно то, необходимое вам решение. Необходимо четко осознавать стоящие перед вами задачи и перспективы.

Если же вы решили формировать "облако", учитывая все вышесказанное, можно условно представить стратегию перехода на "облачную" основу, как последовательность этапов:

Пробный этап. Переход на облако, это прежде всего смена стратегии, переосмысление роли информационных технологий в организации, в целом. Таким образом, прежде чем менять IT - подход в организации, необходимо сменить "стиль" мышления соответствующим образом. Имеет смысл, предоставить своим сотрудникам возможность работы с публичными "облаками", следует перевести ряд задач на "облачную" основу. Для конечных пользователей "облаков" важно обладание четким пониманием, что такое "облако", какие задачи с помощью него можно решать. Данный этап поможет оценить степень готовности организации в целом к реорганизации IT - инфраструктуры, а также привить основные навыки работы с "облаками".

Формирование требований. После того, как в организации сформируются определенные правила и нормы, по началу скорее неформальные, использования облачных платформ, необходимо задуматься о формировании общеорганизационных требований к предоставляемым внешним поставщиком услугам. К примеру, необходимо определиться с тем, какие именно сервисы и платформы нужны для работы, сколько необходимо систем хранения данных. На данном этапе следует определиться с поставщиками "облачных" услуг, сформировать требования к архитектуре и функционалу используемых решений. Результатом данного этапа должен быть набор формализованных требований к "облакам" организации.

Построение частного облака. Данный этап актуален для крупных компаний. Началом данного этапа можно считать момент, когда большая часть сотрудников активно пользуется "облачными" сервисами в своей работе. При наличии экономической целесообразности, можно начать формирование своего корпоративного вычислительного облака, на базе имеющегося центра обработки данных. В конечном счете, эволюционным развитием подобного центра и является корпоративное "облако". При этом, формирование своего центра облачных вычисление не обязательно означает отказ от услуг внешних поставщиков подобных решений. Вполне может использоваться гибридная схема работы, когда для решения поставленных задач используется как частное, так и внешнее "облако".

Введение в технологии Azure

Платформа Windows Azure - это "облачная" платформа компании Microsoft, реализующая модель PaaS. Инструменты данной платформы предоставляют функционал для создания решения, включающее в себя "облачную" операционную систему и набор сервисов для разработчиков.

Иными словами, платформа Windows Azure представляет собой группу "облачных" технологий, каждая из которых предоставляет определенный набор сервисов.

Платформа Windows Azure является частью "облака" компании Microsoft, которое состоит из следующих категорий сервисов:

"Облачные" приложения (cloud-based applications) - представляют собой набор постоянно доступных, масштабируемых сервисов, размещенных в "облаке" Microsoft, которые потребители могут использовать напрямую. К примеру, к таковым относятся: Bing,Windows Live Hotmail, Office Live и т.д.

Программные сервисы (software services) - представляют собой набор SaaS - сервисов, таких как Exchange Online, SharePoint Online,Office Communications Online и т.д.

Платформенные сервисы ( platform services ) - используются, как платформа, представляющая собой публичное "облако", которую разработчики могут использовать для внедрения решений нового поколения. К данным сервисам, в частности относятся SQL Azure,AppFabric и Windows Azure.

Инфраструктурные сервисы (infrastructure services) - набор компонент платформы Windows Azure, обеспечивающих поддержку "облачных" инфраструктурных ресурсов.

Платформа Windows Azure включает в себя:

Windows Azure - операционная система в "облаке", предоставляет вычислительные ресурсы, средства хранения данных и инструменты управления сервисами.

SQL Azure - реляционная база данных, предоставляет основные возможности MS SQL Server по хранению данных, предоставляется как сервис.

Windows Azure AppFabric - программные модули, обеспечивающие коммуникации ( Service Bus ) и контроль доступа ( Access Control ). Используются для обеспечения взаимодействий между приложениями потребителя и приложениями облака.

Введение в Windows Azure

По своей сути, Windows Azure представляет собой платформу для запуска windows - приложений и хранения данных в облаке.

Возможность использования различных экземпляров Windows Azure позволяет пользователям запускать разнообразные сервисы. При этом эластичность, безопасность, доступность и масштабируемость обеспечиваются самой платформой, предоставленной в виде сервиса.

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

Windows Azure работает на базе машин, расположенных в дата - центрах компании Microsoft, доступ к платформе обеспечивается посредством Интернета.

Платформа Windows Azure создана на основе технологий виртуализации. В отличие от обычного предоставления мощностей виртуальных машин для удаленных пользователей, платформа azure управляется с помощью специального инфраструктурного слояWindows Azure Fabric Controller, или "фабрики".

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

Сервисы выполнения Windows Azure, естественно, основаны на Windows - технологиях. Создавать и запускать на Windows Azure можно только приложения основанные на .Net Framework, к примеру, это могут быть ASP.Net или WCF - приложения. Не стоит восприниматьWindows Azure только как платформу, для веб - приложений, платформа также поддерживает фоновые процессы, не зависящие от веб - приложений.

Также стоит отметить, что сервисы хранения данных, предоставляемые Windows Azure могут использоваться, как локальными приложениями пользователя, так и приложениями, размещенными непосредственно на Azure - платформе.

Клиент может контролировать свое azure - приложение, редактируя вручную, или программно, его конфигурационный файл, имеющийся у каждого приложения.

Доступ к возможностям конфигурации и мониторинга состояния приложения осуществляется через соответствующий портал, при предоставлении клиентского Windows Live ID.

Примеры применения Windows Azure

Подведем итог, для чего именно может быть использована Windows Azure:

Размещение в "облаке" веб - приложения. При этом инфраструктура "облака" направляет запрос клиента к одному из экземпляров веб - роли виртуальной машины. Виртуальный веб - сервер данной роли, получив запрос активирует соответствующий код.

Параллельная обработка данных. В данном случае, при обработке больших массивов данных, клиент, к примеру, с помощью WPF-приложения обращается к веб-сервису, запрос на обработку данных помещается в очередь Azure Queue. Обработка осуществляется в асинхронном режиме. Результат помещается в Azure Table.

Объединение локальных вычислительных мощностей и ресурсов облака.

Однако, кроме вопроса "как использовать" есть и "когда целесообразно". Приведем ряд типовых ситуаций для ответа на второй вопрос:

Реализация нового проекта (стартап). Основное преимущество использования технологий Windows Azure в данном случае заключается в том, что для реализации стартапа не требуется наличие масштабной IT - инфраструктуры. Разработчики будут платить только за фактически потребленные ресурсы. Приложение будет масштабироваться Windows Azure в зависимости от числа его пользователей, избавляя, таким образом, от риска переплаты за поддержание и сопровождение инфраструктуры при изначально малом количестве пользователей.

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

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

.Net Services компоненты, примеры использования

.Net Services представляют собой набор сервисов для решения задач доступа к облачным приложениям и коммуникациям.

Компоненты .Net Services:

Access Control - способ идентификации, при котором пользователь предоставляет приложению набор утверждений, в зависимости от этих утверждений приложение решает что именно позволено пользователю.

Service Bus. Целью данной шины является обеспечение доступа к сервисам приложения извне. Также она обеспечивает прохождение файерволла без открытия нового порта, если приложение должно быть доступным извне.

Workflow - данный компонент позволяет создавать композитные приложения для интеграции enterprise - приложений.

.Net Services могут быть использованы для реализации WF - приложений, на основе сервисов Workflow, организации доступа клиентов к приложению с различными технологиями идентификации(Access Control), для обеспечения доступа сторонних пользователей к одному из внутренних корпоративных приложений ( Service Bus ).

3. Azure Services Platform. Microsoft SQL Services, Live Services

Группа облачных технологий SQL Service

Рассматривая возможности облачных вычислений, сложно не заметить, что одной из наиболее привлекательных и очевидных функций, которые можно перенести в облако, является хранение и работа с данными.

Группа технологий, объединенных общим названием SQL Services включает в себя разные сервисы, связанные с данными, включая хранение, анализ, создание отчетов. Общей целью данной группы является предоставление набора облачных сервисов для хранения и работы с разнообразными видами данных.

При этом, главной задачей SQL Services является доступность. Интерфейсы сервисов доступны через SOAP и REST, что позволяет работать с данными не только на Windows - системах.

Обратите внимание, что проект SQL Services 9 июля 2009 был переименован в SQL Azure. В доступной литературе по платформе Azureмогут использоваться оба названия.

SQL Azure:

является первым облачным сервисом полностью поддерживающим реляционную модель баз данных;

предоставляет возможность работы с T-SQL, SQL - запросами, хранимыми процедурами, представлениями данных и т.д.;

совместим со всеми существующими инструментами работы с реляционными БД и интегрированными средами разработки (IDE), такими как SQL Server Management Studio и Visual Studio ;

не требует от IT - персонала принципиально новых навыков и компетенций, все знания и опыт полностью применимы к SQL Azure ;

поддерживает PHP.

SQL Azure базируется на технологиях Microsoft SQL. Работа SQL Azure базируется на Cloud Fabric, управляющем экземплярами баз данных, обеспечивающим их развертывание, обновление, администрирование и мониторинг.

Следует отметить ряд ограничений, которые присутствуют в текущей версии SQL Azure:

невозможно получить доступ к серверу БД на физическом уровне;

невозможно получить доступ к конструкциям уровня сервера, командам DBCC и системным представлениям;

не реализованы полнотекстовый поиск, связанные сервера, отслеживание изменений, распределенные транзакции и т.п.

Целевой аудиторией SQL Azure являются:

независимые поставщики ПО;

поставщики SaaS - программных продуктов, разрабатывающие приложения на основе Windows Azure ;

разработчики корпоративных приложений уровня отделов на базе Windows Azure.

Учитывая вышеизложенной, SQL Azure ориентирован на реализацию следующих сценариев:

создание масштабируемого веб - приложения небольшими организациями, компаниями с веб - приложениями любого уровня;

создание новых продуктов, или расширение существующих решений поставщиками SaaS - услуг;

реализация корпоративного приложения приложение уровня отдела;

реализация проекта консолидации данных - объединение нескольких источников данных в облаке.

Обзор служб Live Service

Основой набора служб под общим названием Live Services является идея использования данных различными приложениями, для которых эти данные не являются "родными".

Иными словами, все мы используем разнообразные Интернет - приложения, число которых постоянно растет, каждое из этих приложений хранит свои данные. К примеру, это могут быть контакты, для приложений обмена сообщениями. Так почему бы не открыть эти данные для других приложений, разумеется в условиях контроля доступа.

Рис. 5.1. Live Services (рисунок взят из статьи "Introducing the Azure Services Platform" Дэвида Чеппела)

Для этой цели компанией Microsoft был собран набор ресурсов в группу - Live Services. К примеру, широко известный набор приложенийWindows Live осуществляет контроль и управление данными при помощи Live Services.

Доступ к данным Live Services осуществляется при помощи Live Framework, основой которого является среда Live Operating Enviroment(функционирующей в облаке) по протоколу HTTP, обеспечивая, таким образом, возможность доступа для приложений на .Net, Java, Java Script, RSS. Следует отметить, что доступ к данным может осуществляться как через облачный экземпляр Live Operating Enviroment, так и локальный, независимо от наличия соединения с облаком; в случае обращения через локальный экземпляр - доступтакже осуществляется через HTTP запросы.

Управление Live Services осуществляется через портал Live Services Developert Portal.

Пользователь может объединить различные устройства на основе Windows (XP, Vista, 7, mobile) и Mas OS X в так называемый mesh (по сути - логическое объединение ряда устройств). При помощи Live Operating Enviroment определенные пользователем данные могут быть синхронизированы в перечисленных устройствах и облаке.

Подводя итог: Live Framework предоставляет инструменты для обеспечения доступа различных приложений к данным Live Services, а также предоставляет возможность синхронизации данных.

4. Платформа Windows Azure

В начале данной лекций мы бы хотели сделать небольшое отступление и упомянуть стратегию Software+Services компании Microsoft. Конечно, было бы уместным начать с ностальгических воспоминаний о вебе, его эволюции и "врастании" его в различные аспекты нашей профессиональной деятельности и понятии "Web 2.0 ", однако о зарождении и становлении Интернета легко можно узнать при помощи него же.

Software+Services объединяет несколько феноменов, таких как SaaS, SOA и Web 2.0. Суть данной стратегии заключается в том, чтобы обеспечить на необходимом пользователю уровне комбинацию Интернет - сервисов и локального программного обеспечения. Иными словами, Software+Services - это предоставление нового уровня услуг, удобства и гибкости, отвечающих пользовательским потребностям.

Платформа Windows Azure является одним из основных компонентов стратегии Software+Services.

Характеристика платформ

Windows Azure - представляет собой Windows-платформу компании Microsoft, предоставляемой, как сервис ( PaaS ), развернутой на серверах и сопутствующей инфраструктуре дата - центров компании и имеющая доступ к Интернет. Т.е., Windows Azure -операционная система, предоставляемая, как сервис.

При использовании Windows Azure пользователи получают возможность запускать различные сервисы, при этом платформа обеспечивает масштабируемость, безопасность и доступность.

Windows Azure:

добавляет возможности веб - служб существующим пакетным приложениям;

позволяет создавать, изменять и распространять приложения через веб при наличии минимальной IT - инфраструктуры;

предоставляет сервисы хранения большого количества данных, пакетной обработки и высокопроизводительных вычислений;

обеспечивает возможности оперативного тестирования и распространения веб - служб при минимальных затратах;

уменьшает издержки, связанные с содержанием IT - инфраструктуры;

упрощает процесс управления IT - инфраструктурой.

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

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

Жизненным циклом экземпляров управляет Azure Fabric Controller, пользователь, в свою очередь, может запускать и останавливать экземпляры.

Сервисы Windows Azure

Рассмотрим подробнее категории сервисов, предоставляемых Windows Azure.

1. Сервисы хранения данных

Предоставляют масштабируемую систему хранения данных, с поддержкой таких структур, как таблицы, бинарные объекты, асинхронныеочереди сообщений и обычные файловые системы. Подробнее сервисы хранения данных будут рассмотрены в лекции №7. Также стоит отметить, что данные сервисы поддерживают тройную репликацию в рамках кластера и центра обработки данных. Автоматическое создание копий и балансировка нагрузки между серверами обеспечивают требуемую масштабируемость сервисов хранения данных.

2. Вычислительные сервисы

Представляют собой контейнеры для приложений, с поддержкой .Net, Java, PHP, Python и т.д. С этой точки зрения, Windows Azureпредставляет собой прикладной контейнер, в котором размещаются код и логика "облачного" приложения.

3. Коммуникационные сервисы

Доступны посредством "облачной" сервисной шины, могут быть использованы, как средство мгновенного обмена сообщениями с другими сервисами на стороне, как "облака", так и клиента.

4. Сервисы безопасности

Включают в себя сервисы управления доступом, основывающихся на механизмах федерации (функция единого входа, через Интернет для проверки пользователя и предоставления ему доступа к различным приложениям во время одного сеанса работы), обеспечивая тем самым возможность интеграции с уже имеющимися системами управления идентификацией. Более подробную информацию см в п. №5 списка дополнительных материалов.

5. Прикладные сервисы

Сервисы, используемые при разработке "облачных" приложений и других сервисов.

Роли

Как правило, сервис Windows Azure имеет более одного экземпляра. Каждый экземпляр может выполнять как всю логику приложения, так и ее часть. При этом разработчик контролирует число и типы ролей.

Можно провести аналогию между ролями в Windows Azure и стандартными типами проектов в Visual Studio. В данном случае экземплярWindows Azure представляет собой отдельный проект.

Роли Windows Azure:

Веб - роль ( web role )

Прикладная роль ( worker role )

Основной задачей веб - роли является обеспечение поддержки протоколов HTTP и HTTPS. Размещается роль на базе IIS. Таким образом веб - роль, фактически, соответствует ASP.Net проекту Visual Studio, с учетом отличий в сборках приложений и способе конфигурации.

Прикладная роль отвечает за поддержку внешних точек входа через TCP\IP и ряд портов (кроме 80 и 443). Данная роль не размещается на веб - сервере. Продолжая аналогию, эту роль можно сравнить с Windows - сервисами, также она может быть использована для выполнения фоновых задач.

Таким образом, роли в Windows Azure - это "блоки" из которых строится "облачное" приложение. Экземпляр роли - виртуальная машина с рядом предопределенных характеристик.

Возможности платформ

Нами уже был дан общий обзор возможностей "облачных" приложений, а также SaaS, PaaS и IaaS решений. Но это были концептуальные описания. Подводя итог данной лекции, мы хотим еще раз сделать акцент на практических возможностях Windows Azure.

Windows Azure:

предоставляет "облачную" среду для разработки, хостинга и управления сервисами;

представляет собой контейнер, содержащий код и логику, в рамках которого приложение может быть развернуто;

предоставляет среду, схожую с существующей Windows Server средой;

позволяет разворачивать .Net проекты напрямую, без внесения существенных и трудоемких изменений;

позволяет хранить данные пользователей, поддерживает тройную репликацию.

5. Сервисы хранения данных в Windows Azure. VM - роль

VM - роль в Windows Azure предназначена для облегчения процесса миграции существующих Windows Server приложений в "облачную" структуру.

VM - роль предоставляет сервисы на уровне инфраструктуры ( IaaS ), облегчая процессы контроля и управления инфраструктуры для администраторов и разработчиков.

Отметим, что остальные роли (веб и прикладная) находятся "над" VM -ролью, позволяя тем самым разработчикам, чья деятельностьосуществляется на более высоких уровнях абстракции, концентрироваться непосредственно на приложении, а не на ОС, на котором оно базируется.

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

Таким образом, роль виртуальной машины позволяет создавать пользовательский образ виртуального жесткого диска (на основеWindows Server 2008 R2) и размещать его в "облаке".

Фактически VM - роль это виртуальная машина, но обладающая рядом особенностей:

не поддерживается сохранность образов при аппаратных сбоях;

каждый сервис может иметь только один внешний IP - адрес;

невозможен автоматический мониторинг приложений, функционирующих внутри виртуальной машины;

для обеспечения требуемого уровня доступности требуется наличие двух одинаковых экземпляров виртуальной машины.

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

Каждая виртуальная машина создается при развертывании прикладных сервисов. Все виртуальные машины располагаются в центрах обработки данных Microsoft.

О ценах и лицензировании можно узнать из п. №1 списка материалов для самостоятельного изучения.

Сервисы хранения данныx

Хранение данных в Windows Azure обеспечивается набором сервисов под общим названием Windows Azure Storage . Каждый из сервисов подходит для хранения определенного типа данных:

Table - сервис, позволяет хранить структурированные данные в таблице, доступ к которым осуществляется через REST API ;

Queue - сервис, позволяет организовать неограниченное хранилище сообщений;

Blob - сервис, позволяет хранить текстовую и бинарную информацию в специально организованных контейнерах.

Отметим, что Table - хранилище не является аналогом реляционного хранилища данных. В данной концепции, под таблицей понимается коллекция сущностей ( Entities ), подобных кортежам в реляционном подходе. Сущность же представляет собой набор свойств ( Properties). Свойство же является парой "имя (name) - типизированное значение (typed value)". Продолжая аналогию, сущности можно соотнести с полями в таблице в реляционном хранилище.

В Table - хранилище сущности могут содержать различные свойства, находясь в одной таблице. Т.е. таблица в Table - хранилище не задает структуру хранимых сущностей.

Таким образом, таблица состоит из набора объектов, каждый из которых имеет набор названий свойств и их значений. Объект может иметь до 256 свойств.

В табличном хранилище, к примеру, могут храниться состояния веб - приложений, текущее состояние пользовательских объектов (заказ,группа контактов) и т.д.

Для хранения бинарных (blob ) объектов используется интерфейс, позволяющий сохранять именованные файлы вместе с метаданными.

Blob - объекты делятся на:

блочные, оптимизированные для потокового ввода - вывода, размер объекта не может превышать 200 Гб;

страничные, оптимизированные для случайных операций ввода - вывода, размер объекта не может превышать 1 Тб.

Хранилище бинарных объектов больше подходит для хранения резервных копий, изображений, документов и т.д.

Очередь ( Queue ) является хранилищем сообщений, как правило, обеспечивает коммуникации между различными ролями Windows Azure . Сообщения хранятся в очередях, размер сообщений ограничен 8 Кб. При этом возможно использование неограниченного числа очередей, число сообщений в очереди также не имеет ограничений.

Подробнее о table , blob и queue сервисах будет рассказано в лекциях №11-16.

Кроме специализированных сервисов хранения данных Windows Azure поддерживает традиционные файловые операции, за счет поддержки NTFS формата.

NTFS тома хранятся как отформатированные виртуальные диски в страничных бинарных объектах. Работающие приложения могут сохранять состояния на томах. Доступ к диску осуществляется через стандартный NTFS интерфейс .

Каждая учетная запись Windows Azure Storage может хранить до 100 Тб данных.

С точки зрения архитектуры, существует 3 основных уровня доступа к данных в Windows Azure Storage :

Front - End (FE) уровень. Принимает поступающие запросы, авторизация и аутентификация также осуществляются на данном уровне. После аутентификации запросы направляются на сервер ( partition server ), на соответствующем уровне. На FE уровне хранится карта секторов ( partition map ), что позволяет направлять запрос напрямую необходимому серверу.

Уровень секторов ( partition layer ). Данный уровень управляет разделением данных в системе, обеспечивая доступ к необходимым серверам, автоматическую балансировку нагрузки секторов. Единственный partition - сервер может обслуживать множество секторов.

Уровень распределенной файловой системы ( Distributed and replicated file system - DFS ). Уровень, на котором фактически хранится информация, отвечающий за распределение и репликацию данных по всем серверам хранения. Каждый из DFS серверов доступен для любого partition - сервера .

Рис. 7.1. Уровни доступа к данным Windows Azure Storage

6. Описание и характеристики SQL Azure

Характеристики SQL Azurе

В конце июля 2009 года компанией Microsoft был анонсирован SQL Azure.

SQL Azure:

первый "облачный" сервис полностью поддерживающий реляционные модели данных;

поддерживает SQL - запросы, T-SQL, использование хранимых процедур, представлений и т.п.;

поддерживает модель безопасности Windows (пользователь\пароль) ;

совместим практически со всеми инструментами и средами разработки реляционных баз данных ( SQL Server Management Studio,Visual Studio );

поддерживает PHP.

Таким образом, SQL Azure предоставляет масштабируемую, устойчивую базу данных, в качестве сервиса.

Работа SQL Azure базируется на Cloud Fabric, управляющем экземплярами баз данных, обеспечивающим их развертывание и сопровождение на протяжении всего жизненного цикла работы с данными.

Сравнение с MS SQL Server

В приведенной ниже таблице мы обобщили основные отличия MS SQL Server и SQL Azure:

Ограничения

Мы уже отмечали наличие ряда ограничений в SQL Azure, а именно:

невозможно получить доступ к серверу БД на физическом уровне;

невозможно получить доступ к конструкциям уровня сервера, командам DBCC и системным представлениям;

не реализованы полнотекстовый поиск, связанные сервера, отслеживание изменений, распределенные транзакции и т.п.

Механизмы доступа

Как уже упоминалось , SQL Azure поддерживает конструкции языка T-SQL через протокол TDS (Tabular Data Stream), а также обращения по протоколу ODBC.