Pankaj_AroraMS
11 Jan 2012 8:59 AM
Привет, меня зовут Pankaj Arora, я старший менеджер группы Microsoft IT глобальных стратегических инициатив.
Когда исполнительный Директор корпорации Майкрософт Стив Ballmer публично объявил в марте 2010 г. «Мы все в облаке компьютеризации»» он вовсе не имел в виду продукты корпорации Майкрософт. Он также не имел мандата от своей ИТ-организации на продвижение облачной компьютеризации. С этого момента я и мои коллеги узнали довольно много об облачной компьютеризации и о том, что требуется для глобального внедрения этой технологии. Теперь мы имеем облако распределений всех общих моделей - SaaS, PaaS и IaaS — и мы начинаем использовать Службу Данных.
Используя наш опыт многочисленных применений как в нашей области, так и вполне обоснованный прогноз ещё более широкого применения облачной модели в 2012 г., я хочу представить компьютерному сообществу книгу, написанную в соавторстве с двумя коллегами и озаглавленную «Технология облака. Облако повышает производительность». Вкратце, в книге излагается Почему, Что и Как повышает производительность внедрение технологии облака. Книга написана на основе на нашем опыте и лучших образцах применения облачной компьютеризации в промышленности и у других пользователей.
Ниже приведен отрывок из главы 4 предварительной версии книги, доступный для распечатки и в электронном виде через Amazon, Barnes & Noble и McGraw Хилл и другие программные инструменты. Можно также посмотреть книгу на веб-сайте здесь.
Не стесняйтесь задавать вопросы, и я надеюсь, что этот отрывок (и сама книга) поможет вам как в вашей практической работе с облачной компьютеризацией так и стратегически.
Pankaj
Архитектурные принципы
Вывод программных приложений и данных из коллективного дата- центра не исключает риск сбоев оборудования, незапланированный запрос на приложения или непредвиденные проблемы, возникающие в реальной работе. Качественно спроектированный метод облачной компьютеризации является более масштабным, отказоустойчивым и позволяет лучше выполнять вычисления по сравнению с методами, используемыми непосредственно в дата-центрах
Виртуализация и облачная технология вычислений, использующие принцип облачной компьютеризации теоретически предоставляют неограниченные возможности пользователям. Это означает, что именно архитектура и уровень автоматизации облачных вычислений ограничивают масштаб применения данной технологии, а не физические возможности оборудования. В этом разделе мы вводим несколько проектных принципов, которые помогут разработчикам приложений и операторам разобраться в особенностях архитектуры широкомасштабных и надёжных технологиях облачной компьютеризации.
Устойчивость
Правильно спроектированное приложение не откажет из-за рядовой неисправности оборудования, в то время как у плохо спроектированного могут возникнуть проблемы с производительностью, потерей данных или сбоем в работе при отказе даже малой части оборудования. Вот почему разработчики облачного программного обеспечения заранее предусматривают возможность отказа оборудования. Имея в виду наихудшие сценарии они разрабатывают приложения, устойчивые к сбоям и отказам оборудования.
Единый проект программного обеспечения, в котором уровень обработки и функциональная логика тесно связаны в одном программном фрагменте, может не обеспечить достаточную эффективность и корректность обработки возникшей ошибки. Для оптимизации программного обеспечения облачных вычислений разработчики вынуждены были отказаться от этой тесной взаимосвязи и разделить логику вычислений и сами вычисления на слабо связанные модули, которые могли бы функционировать независимо. В идеале приложение функционально будет состоять из автономных программных единиц, работающих независимо друг от друга. Для минимизации сложности конструкции программного обеспечения разработчики должны по возможности максимально использовать стандартный программный сервис.
Ранее мы говорили об программном инструменте т.н. on-line аукциона корпорации Микрософт. Один из способов разработки такого приложения мог бы состоять в разделении его на три компонента, каждый из которых имеет свой алгоритм запроса и работает асинхронно: уровень Интерфейса Пользователя, обеспечивающий представление информации Пользователю, блок обработки изображений (изменение размеров) и блок управления «аукционом», устанавливающий «правила торговли» и обновляющий базы данных.
средство изменения размера изображения и бизнес-логику компонента, применяет правила торговли и делает обновления соответствующей базы данных. В начале «аукциона» много «обработчиков изображений» конкурируют между собой, когда пользователи загружают изображения, которые они хотят добавить в свои каталоги. К концу «аукциона», когда пользователи пытаются «победить» других механизм «торгов» работает с наивысшим напряжением. Каждый пользователь наращивает вес своего запроса, если необходимо и позволяет загрузка системы. Если, предположим, обработчик изображений даёт сбой, это не приводит к отказу всего программного инструмента
Можно с оптимизмом заключить, что программная избыточность и автоматизация, лежащие в основе облачной модели делают облачную технологию в целом более надёжной. Зачастую разработчики облачного ПО обеспечивают множественность «зон доступности», в которых выделяются самостоятельные сетевые ресурсы, оборудование и даже энергопитание. Использование множественной шкалы единиц веса запроса единого приложения для всех зон может в дальнейшем уменьшить риск того, что несколько пользователей одновременно запросят это приложение и тем самым гарантировать высокий уровень обслуживания. Главный вопрос при возможном сбое состоит в том, что произойдёт внезапная перезагрузка, отказ или перемещение приложения.
Отказ от ненужных зависимостей делает работу приложений более стабильной. Если сервис, используемый приложением по одному сценарию отказывает, всегда можно переключиться на другой сценарий.
Т.к. некоторые разработчики облачного ПО могут использовать механизм перезагрузки по требованию или прерывание долговременных вычислений на серверах платформ SQL PaaS и других, инженеры должны включать логику повтора. Например, компонент, который запрашивает данные из другого источника может включать логику, которая позволяет запрашивать данные указанное число раз в течение указанного времени, прежде чем запрос будет исключён.
Для выхода из ситуации случайной перезагрузки облачное ПО должно включать постоянный буфер (кэш) памяти позволяющий восстановить транзакцию как элементарной единицы шкалы запроса, так и самого запроса, вызвавшего перезагрузку. Используя постоянный состав запросов, необходимо более тщательно рассмотреть вариант случайного запроса, т.е. иной принцип приложения в облачном ПО.
Случайные запросы
Разработка ПО для случайного запроса очень важно для правильного разбиения приложений на элементарные единицы запроса и с точки зрения устойчивости облачной технологии к сбоям. Является ли нестандартная работа ПО неожиданной или планируемой (как в случае обновления операционной системы), это ведёт к утрате стандартной единицы запроса и включению в обработку другой единицы. При этом пользовате��ь приложения не должен заметить никаких отклонений в работе облачного ПО. Очень важно не столько для масштабирования шкалы запросов, а скорее для большей устойчивости в работе и сохранения высокого уровня доступности для каждого критического сервиса облачного ПО иметь в обработке более одной единицы запроса одновременно.
Разработчики облачного ПО обычно исходят из необходимости непостоянства приложений. В течение одной ��ессии пользователи приложения могут взаимодействовать с одной иле несколькими единицами запроса разных задач, обрабатываемых независимо, что может быть названо терминами «баланс случайных загрузок» или «сессия без взаимосвязей». Разработчики ПО не должны сохранять приложение или состояние сеанса в памяти единиц шкалы запросов, поскольку нет гарантии, что пользователь будет исключительно взаимодействовать с данной единицей. Таким образом без введения принципа непостоянства приложений, многие приложения не будут правильно обработаны в облачном ПО. Большинство поставщиков облачного ПО предлагают алгоритм постоянного хранения адреса, позволяющий приложению сохранить состояние сессии таким образом, чтобы любая единица запроса могла быть возвращена в обработку.
Параллелизации
Использование преимуществ параллелизации и алгоритма многопоточных приложений повышает производительность и является основным принципом облачной технологии. Баланс случайных загрузок и другие сервисы, используемые в облачных платформах, может сравнительно легко распределять загрузки. При сравнительно низкой стоимости ускорения обработки в облаке единицы запросов доступны для параллельной обработки по вызову в пределах нескольких APL звонков и выводятся из обработки так же легко.
Массовое распараллеливание может использоваться также для случаев высокопроизводительных вычислений, таких как анализ данных в режиме реального времени. Многие поставщики облачного ПО предусматривают прямую или косвенную поддержку платформ, позволяющих разделение массива задач для параллельной обработки. Например Microsoft привлекла университет Вашингтона для демонстрации ресурсов Windows Azure при выполнении научных исследований. Результатом стали 2,5 млн вычислительных операций, выполненных на оборудовании, эквивалентном 2000 серверов менее, чем за неделю [1], т.е. вычислительная работа, потребовавшая бы в в противном случае нескольких месяцев.
Задержка
Разработчики программного обеспечения могут применить следующие общие принципы проектирования для уменьшения возможного влияния задержки сети на доступность и производительность облачной обработки:
Автоматическое масштабирование
В облачных ПО, поддерживающих функцию автоматического масштабирования, разработчики могут исследовать существующие интерфейсы API и использовать их для построения такого масштабирования в своих приложениях. Например, рассмотрим утилизационно-ориентированную логику, при которой автоматически добавляется новое приложение, когда трафик неожиданно возрастает или постепенно достигает пороговых значений использования CPU. Эта же процедура может прослушивать сообщения, и заставлять отдельные приложения прерывать запросы на обслуживание, как только интенсивность запросов падает до обычного уровня/
Можно также использовать логику, основанную на стоимостных принципах. Например, разработчики могут при некоторых условиях, в том числе при пиковых нагрузках, увеличить «стоимость» контрольной логики для исключения автоматического масштабирования второстепенных приложений.
Масштабирование данных не менее важно, чем масштабирование приложения и это обязательное условие правильного проектирования. Хотя разработанная специальная архитектура уровней приложений в облачном ПО достаточно сложная и громоздкая, в конечном итоге она приводит к улучшению производительности оборудования и повышению доступности. Например, если есть слишком большие массивы информации для хранения в существующих базах данных с использованием необлачных принципов, то можно рассмотреть вариант разбиения массива данных на отдельные фрагменты и хранения их в виде множества отдельных пакетов. Такой подход называемый «sharding» стал стандартом для многих облачных платформ и встроен в некоторые стандартные платформы, включая SQL Azure. Даже если этот подход не так актуален сейчас, он будет востребован по мере увеличения обрабатываемых объёмов данных.
Ссылка на источник: http://blogs.MSDN.com/b/windowsazure/Archive/2012/01/11/Book-excerpt-quot-to-the-cloud-Powering-an-Enterprise-quot.aspx
MSDN Blogs > Windows Azure > Book Excerpt: "To The Cloud: Cloud Powering an Enterprise"