Экологичная модель развития виртуализации

Кевин Фрэнсис (Kevin Francis), Питер Ричардсон (Peter Richardson)

Краткое содержание.

Сегодня самая главная проблема, стоящая перед окружающей средой, – это глобальное потепление, вызванное выбросами углекислого газа. Согласно докладу Управления по информации в области энергетики (см. раздел «Ресурсы»), около 98 % выбросов СО₂ (или 87 % выбросов всех парниковых газов, эквивалентных СО₂) связаны с ростом потребления электроэнергии. Сегодня многие организации открыто заявляют о своем желании работать «экологично», декларируя принципы природо­охранной деятельности и способы снижения негативного воздействия на окружающую среду на своих корпоративных веб-узлах. Кроме того, многие компании платят (или собираются платить в ближайшем будущем) своего рода налог на выброс угле­кислого газа, потребляемые ресурсы, а также на вредное воздействие на окружающую среду, которое оказывают производимые ими продукты и услуги. Таким образом, снижение потребления электроэнергии означает для предприятия реальную финансовую выгоду.
В этой статье мы делаем акцент на сокращении энергопотребления на протяжении всего жизненного цикла оборудования как на главном факторе, стимулирующем проекти­рование «экологичных» приложений, поскольку сокращение потребления электроэнергии – лучший показатель «экологичности». Наша цель – изучение возможностей снижения энергопотребления, а не исследование экономических аспектов энергоэффективности. Однако очевидно, что эффективное использование электроэнергии позволит сократить экономические затраты, поскольку они представляют собой значительную долю расходов на центр обработки данных в течение всего жизненного цикла. Тем не менее этот приятный бонус к экологичности в данной статье детально не рассматривается.

Содержание

Использование архитектурных принципов

Почему большинство приложений не являются экологичными

Эталонная модель виртуализации

Уровень 0: начать с домашнего компьютера

Уровень 1: совместное использование лучше

Уровень 2: максимальное совместное использование инфраструктуры

Более яркий оттенок зеленого: облачные вычисления

Уровень 3: облачная виртуализация

Удостовериться, что облако зеленое изнутри

Переход на последующие уровни виртуализации

Заключение

Ресурсы

Использование архитектурных принципов

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

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

Почему большинство приложений не являются экологичными

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

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

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

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

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

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

Эталонная модель виртуализации

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

Таблица 1. Уровни развития виртуализации

Развитие виртуализации	Наименование	Приложения	Инфраструктура	Местоположение	Тип собственности
Уровень 0	Локальный	Выделенный	Фиксированная	Распределенное	Внутренняя
Уровень 1	Логический	Общий доступ	Фиксированная	Централизованное	Внутренняя
Уровень 2	Центр обработки данных	Общий доступ	Виртуальный	Централизованное	Внутренняя
Уровень 3	Облачный	ПО как служба	Виртуальный	Виртуальный	Виртуальный

Уровень 0 («Локальный») означает полное отсутствие виртуализации. Приложения постоянно работают на отдельных компьютерах, общий доступ к данным или ресурсам сервера отсутствует.

Уровень 1 («Логическая виртуализация») – это концепция общего доступа к приложениям. Она реализована, например, на серверах отделов, где исполняются приложения, доступные клиентским ПК. Сначала это были большие ЭВМ, затем появилась технология «клиент – сервер», которая позже эволюционировала в сложные многоуровневые структуры. Не являясь виртуализацией в полном смысле этого слова, данная концепция стала, пожалуй, самым важным шагом в развитии виртуализации. В крупных организациях, как правило, имеется множество приложений с большим функциональным перекрытием между ними. Например, многочисленные системы, выполняющие функции управления взаимоотношениями с клиентами (CRM).

Уровень 2 («Виртуализация центра обработки данных») связан с виртуализацией аппарат­ного обеспечения и инфраструктуры программного обеспечения. Основная предпосылка здесь заключается в том, что отдельные развернутые серверы не должны потреблять аппаратные ресурсы выделенного оборудования; таким образом, эти ресурсы могут использоваться несколькими логическими серверами. Именно этот уровень чаще всего ассоциируется с термином «виртуализация». Его отличие от Уровня 1 состоит в том, что аппаратно-программная инфраструктура, на которой работают приложения или серверы, сама по себе является общей (используемой совместно, виртуализированной). Для сер­верной инфраструктуры эта задача решается с помощью таких платформ, как Microsoft Virtual Server и VMware, позволяющих запускать множество виртуальных серверов на одном физическом. В решениях для хранения данных этого уровня используются технологии, связанные с сетью хранения данных Storage Area Network (SAN). В этой сети физические устройства хранения данных могут быть объединены и разбиты на логические устройства хранения, воспринимаемые серверами как выделенные хранилища, обеспечивающие, однако, более широкие возможности эффективного управления. Похожей концепцией в области сетевых технологий на этом уровне является виртуальная частная сеть (VPN). В этом случае общедоступные сети настраиваются таким образом, чтобы представлять на логическом уровне частную и защищенную сеть. Это намного эффективнее, чем прокладывать выделенную физическую сеть.

Уровень 3 («Облачная виртуализация») расширяет Уровень 2 таким образом, что виртуализируются не только ресурсы, но и местоположение и принадлежность инфраструктуры – посредством облачных вычислений. Это означает, что виртуальная инфраструктура больше не привязана к физическому месту и потенциально может быть переконфигурирована или перемещена в любую точку как внутри, так и вне сети клиента или административного домена. Смысл применения облачных вычислений заключается в том, что мощности центров обработки данных можно объединить в масштабах, недоступных для отдельной организации, и разместить в более выгодных местах (например, с точки зрения предоставления электропитания), чем те, которые могут себе позволить отдельные предприятия. Таким образом, появляется возможность существенно повысить эффективность за счет эффекта масштабирования, связанного с большим количеством организаций, разделяющих одну и ту же инфраструктуру. Серверы и хранилища, виртуализированные до этого уровня, как правило, называют облачными платформами и облачными хранилищами – это, например, Google App Engine, Amazon Elastic Compute Cloud, а также Windows Azure от Microsoft. Доступ к подобной инфраструктуре, как правило, осуществляется через Интернет с помощью безопасных соединений, которые можно рассматривать как своего рода виртуальные дискретные VPN-соединения.

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

Таблица 2. Технические аспекты виртуализации

	Технические аспекты
Развитие виртуализации	Наименование	Сервер	Хранилище	Сеть
Уровень 0	Локальный	Отдельный ПК	Локальные диски	Отсутствует
Уровень 1	Ведомственный	Клиент – сервер, многоуровневый	Файловый сервер, сервер баз данных	Локальная сеть, совместно используемые службы
Уровень 2	Центр обработки данных	Виртуализация серверов	SAN	WAN/VPN
Уровень 3	Облако	Облачная платформа	Облачное хранилище	Интернет

 

Уровень 0: начать с домашнего компьютера

Уровень 0 («Локальный») в модели развития виртуализации означает ее полное отсутствие. Тем не менее даже в этом случае есть множество способов сэкономить энергию. Традиционные подходы к проектированию и разработке ведут к появлению менее эффективных, чем они могли бы быть, приложений. Есть целый ряд проблем проектирования, которые легко распознаются в приложениях, а значит, можно составить список правил и рекомендовать архитекторам и разработчикам любых приложений применять эти правила.

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

Принцип: всегда проектировать вход в спящий режим и выход из него максимально прозрачно.

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

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

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

Принцип: минимизировать объем данных, хранимых приложением, и добавить при раз­работке приложения функцию архивирования данных.

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

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

Уровень 1: совместное использование лучше

Уровень 1 («Логическая виртуализация») воплощает концепцию общего доступа к приложениям. Ее можно реализовать, например, с помощью серверов подразделений, на которых исполняются приложения, доступные клиентским ПК. Сначала эта концепция представляла собой технологию «клиент – сервер», а затем воплотилась в более сложные многоуровневые структуры. Не являясь виртуализацией в полном смысле этого слова, данная концепция стала, пожалуй, самым важным шагом в развитии виртуализации. В крупных организаций, как правило, имеется множество приложений с большим функциональным перекрытием между ними. Например, многочисленные системы, выполняющие функции управления взаимоотношениями с клиентами (CRM).

Переход на Уровень 1 («Логическая виртуализация») заключается в рационализации количества приложений и платформ приложений с перекрывающейся или избыточной функциональностью и в более широком использовании общих служб приложений таким образом, чтобы общие элементы приложения можно было запускать один раз и избегать их дублирования. В крупных организациях отдача от внедрения подобной модели намного превысит выигрыш от любой дальнейшей аппаратной виртуализации. Лучший способ реализовать «Логическую виртуализацию» заключается в том, чтобы использовать всю корпоративную архитектуру, охватывающую и архитектуру приложений, чтобы выявить все точки функционального взаимодействия и перекрытия существующего портфеля приложений. Это необходимо для разработки плана рационализации ненужных или дублирующих функций. Следует обнаружить и отключить функции, которые дублируются без необходимости, либо вынести общие элементы в общие службы. Помимо автоматического решения проблем с целостностью данных и согласованностью процессов, такой подход позволяет уменьшить и размер приложений, и их количество. Следовательно, приложения будут потреблять меньше ресурсов, за счет чего снижается энергопотребление и количество вредных выбросов, уменьшаются эксплуатационные расходы. Более широкое использование общедоступных служб приложений дает возможность централизованно развертывать общие функции и управлять ими, не расходуя ресурсы на каждое приложение, которое их использует.

Эффективность сервера Серверы будут потребляют меньше энергии на единицу выполненной работы, если использовать их более интенсивно. Это происходит потому, что хотя каждый процессор и потребляет больше электроэнергии при повышении нагрузки, существует базовый уровень мощности, не зависящий от степени загруженности ПК. Повышение интенсивности использования не приводит к увеличению потребляемой мощности. Более того, большинство серверов имеют достаточно низкий коэффициент использования. Поэтому, задействовав свободные серверные мощности, можно получить огромные выгоды. Как описано в документе «Энергосбережение в Windows Server 2008» (см. раздел «Ресурсы»), несколько виртуальных машин могут работать на одной физической. При этом потребление электроэнергии возрастет ненамного больше по сравнению с тем, как если бы эта машина работала в качестве выделенного сервера. Это означает, что можно добавлять виртуальные машины на сопоставимые уровни пропускной способности – вплоть до предельной нагрузки оборудования, сохраняя практически тот же объем затрат на электроэнергию. Пока не будет достигнута пиковая мощность процессора, экономия будет расти вместе с количеством серверов, которые можно виртуализировать. Согласно документу «Windows Server 2008», запуск четырех виртуальных машин обеспечивает экономию, равную энергопотреблению трех физических серверов, а запуск десяти виртуальных машин равносилен установке девяти физических серверов.

Кроме того, физические компьютеры занимают больше места (даже при ис­пользовании блейд-серверов) и требуют большего охлаждения, нежели их виртуальные собратья. Дополнительное аппаратное обеспечение, если можно избежать исполь­зования этого оборудования, – всегда значительная потеря энергии и ресурсов. Сравнение потребления электроэнергии в случае стандартной установки Windows Server 2003 и Windows Server 2008

Принцип: сначала разработать план рационализации приложений и существующих платформ.

Один компьютер с загруженным на 50 % процессором будет использовать значительно меньше электроэнергии, чем два аналогичных компьютера, нагружающих процессор на 25 % (см. врезку «Эффективность сервера» на стр. 11). Это означает, что серверы одного приложения неэффективны и в идеале они должны предоставляться как общие ресурсы, чтобы обеспечить более интенсивное использование. При работе над этим вопросом важно провести тестирование на совместимость и удостовериться, что при­ложения действительно могут функционировать вместе. Кроме того, необходимо также протестировать производительность и убедиться, что приложения не мешают друг другу работать эффективно при большой нагрузке на сервер. В сущности, важно гарантировать, что доступные ресурсы процессора успешно распределены между приложениями на сервере с достаточным потенциалом для роста.

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

Принцип: консолидировать приложения на минимальном количестве серверов.

Уровень 2: максимальное совместное использование инфраструктуры

Как мы уже говорили ранее, именно Уровень 2 («Виртуализация центра обработки данных») чаще всего ассоциируется с термином «виртуализация». С помощью таких платформ, как Microsoft Virtual Server, VMware и пр., виртуализация серверов и хранилищ действительно стала эффективным решением для достаточно крупных организаций, имеющих возможность создания виртуальной инфраструктуры. Планка виртуализации довольно низка и опускается все ниже, по мере того как возможности программного обеспечения для виртуализации растут, а управлять этим ПО становится все проще. Цена и производительность серверов сейчас достигли той точки, когда даже небольшие организации, имеющие всего 3–4 ведомственных приложения, могут сократить расходы за счет развертывания этого программного обеспечения в виртуальной среде.

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

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

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

Эффективность центра обработки данных В крупных центрах обработки данных можно добиться более эффективного энергосбережения, чем в небольших. В настоящее время появляются специальные стандарты для из­мерения энергоэффективности, например концепция эффектив­ности использования энергии (Power Usage Effectiveness, PUE). Показатель PUE определяется как отношение суммарной мощности объекта к мощности, потребляемой ИТ-оборудо­ванием. Этот стандарт позволяет определить, какая часть элект­роэнергии, потребляемой объектом, фактически используется для питания непосредственно ИТ-оборудования. Под ИТ-обо­рудованием мы подразумеваем действительно полезное обору­дование: серверы, устройства хранения данных, коммутаторы, маршрутизаторы, телекоммуникационное сетевое оборудова­ние, рабочие станции или ПК и т. д. Другие компоненты центра обработки данных также потребляют электроэнергию, однако при этом считается, что они вызывают непроизводительные издержки. К этим компонентам относятся ИБП, трансформа­торы, распределительные стойки, системы освещения, охлаж­дения, устройства пожарной безопасности и пожаротушения, управление помещением и пр. Показатель PUE для типичных ИТ-объектов составляет около 2; лучшим результатом в нас­тоящее время считается показатель PUE, равный примерно 1,2. Разница между двумя этими величинами огромна, потен­циальная экономия составляет около 40 %, однако достигнуть этого можно только с помощью сложного оборудования и в центрах обработки данных с высоким уровнем масштаби­руемости. Для всех предприятий, кроме самых крупных, лучшим способом достижения данных уровней является группировка ИТ-инфраструктур нескольких организаций, что позволит полу­чить необходимый положительный эффект масштаба.

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

Более яркий оттенок зеленого: облачные вычисления

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

• Программное обеспечение как услуга (Software as a Service, SaaS) – суть модели заключается в том, что браузер или клиентское приложение осуществляет доступ к приложению, работающему на серверах в Интернете.
• Прикрепленные службы – относятся к приложению, которое работает на локаль­ном компьютере, однако часть своих функций выполняет с помощью служб, размещенных на сервере в Интернете.
• Облачные платформы – позволяют приложению, созданному разработчиками организации, размещаться на общей платформе в Интернете.

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

Уровень 3: облачная виртуализация

Облачная виртуализация, как этап модели развития виртуализации, способна существенно повысить эффективность за счет эффекта масштабирования, связанного с большим количеством организаций, работающих на общей инфраструктуре. Достижение эффектив­ности использования энергии в центре обработки данных – очень специфическое и капи­талоемкое занятие. Появляются стандартные показатели для измерения эффективности, например эффективность использования энергии (см. врезку «Эффективность центра обработки данных»). Их можно использовать для сравнения полезно затраченной мощности и той, что ушла на непроизводительные элементы. Разрыв между типичными энергозатратами центров обработки данных и результатами, достигнутыми благодаря передовым методикам уменьшения PUE, очень большой.

Возможность разместить инфраструктуру наиболее выгодным образом с точки зрения экономии на электроэнергии – это еще одно важное преимущество Уровня 3.

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

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

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

Удостовериться, что облако зеленое изнутри

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

Овеществленная энергия Овеществленная энергия – это количество электроэнергии, необходимое для производства и доставки продуктов, материа­лов или услуг до места использования. Оценивая затраты электроэнергии или количества выбросов от конкретного ИТ-оборудования, следует учитывать количество овеществлен­ной энергии каждого элемента, а также потребление электроэнергии в ходе эксплуатации этого оборудования. Овеществленная энергия имеет важное значение. Около 80 % объема выбросов в течение всего жизненного цикла продукта (или ноутбука) связано с овеществленной энергией, и только 20 % относится к потреблению энергии в ходе эксплуатации. Величина овеществленной энергии для настольного ПК и монитора составляет около 70 %. У сервера этот показатель ниже – около 25 % выбросов в течение жизненного цикла. Тем не менее это значительная величина, и сбрасывать ее со счетов нельзя. Мы утверждаем, что крупные серверы являются более эффективными с точки зрения овеществленной энергии на единицу мощности по сравнению с эквивалентным количеством небольших серверов. Таким образом, кроме непосредственной экономии от снижения энергопотребления за счет уменьшения количества серверов, снижение числа виртуальных серверов влечет за собой и сокращение объема овеществленной энергии. Овеществленная энергия означает, что развертывание приложения в центре обработки данных может привести к убыткам при последующей миграции в облако (то есть овеществленная энергия первоначального оборудования, где было развернуто приложение, будет просто «выброшена на ветер»). Движущим фактором при переходе от одного уровня виртуализации к другому, с точки зрения экономии электроэнергии, является расчет овеществленной энергии. Если для перехода с одного уровня на другой необходимо приобрести большое количество нового оборудования, овеществленная энергия, затраченная на дополнительное оборудование, может свести на нет весь выигрыш в эксплуата­ционных расходах. Именно поэтому очень важно рассматривать овеществленную энергию как часть потребления энергии в течение всего жизненного цикла разработки приложения, а также при выборе архитектуры развертывания.

В облачных вычислениях следует учитывать три аспекта эффективности:

• Расположение и архитектуру облачного центра обработки данных.
• Архитектуру облачной платформы.
• Архитектуру и подход к разработке размещенных приложений.

Когда клиент решает приобрести электроэнергию у какого-либо поставщика, в боль­шинстве случаев он может выбрать экологически чистую электроэнергию. Сделав это, можно убедиться, насколько экологично приобретаемое электричество. Допустим, ваша организация приняла решение приобретать экологичную электроэнергию.

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

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

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

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

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

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

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

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

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

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

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

Обеспечение рентабельности расходов на овеществленную энергию при покупке нового сервера виртуализации Мы предлагаем следующее: N – количество серверов для виртуализации на одном новом физическом сервере. B – коэффициент овеществленной энергии (отношение овеществленной энергии нового сервера к энергопотреблению этого сервера в течение его жизненного цикла). E – коэффициент полезного действия (отношение энергопо­требления одного нового сервера с мощностью, эквивалентной исходному количеству серверов N, к энергопотреблению N исходных серверов; предполагается, что используются одни и те же технологии и нагрузка в течение прогнозируемого жизненного цикла). T – технологический фактор (отношение энергопотребления новых серверов на единицу мощности ЦП к энергопотреблению исходных серверов на единицу мощности ЦП) U – коэффициент использования (отношение интенсивности использования исходных серверов к интенсивности использо­вания нового сервера). Чтобы окупить затраты на овеществленную энергию и получить чистую прибыль, необходимо соблюдение следующего неравенства: E x U x T < (1 – B) Если типичное значение B составляет 25 %, то общие коэффициенты повышения должны быть больше 0,75. Добиться этого легко, ведь даже если технологии исходных и новых серверов аналогичны (Т = 1) и повышение эффективности отсутствует (E = 1), то U, скорее всего, будет меньше 0,5, при условии что N больше 2, поскольку почти все серверы серьезно недозагружены. Таким образом, как только будет виртуализировано свыше двух серверов, овеществленная энергия, затраченная на покупку нового сервера, будет оправданна на весь его жизненный цикл, с точки зрения затрат на электроэнергию.

Переход на последующие уровни виртуализации

Согласно модели, представленной в таблице 1, большинство ИТ-сред организаций в настоящее время находятся на Уровне 1, а в некоторых более развитых предприятиях – на Уровне 2 (в целом или частично). Лишь небольшая доля организаций достигла Уровня 3. Хотя мы и утверждаем, что более высокие уровни виртуализации соответствуют меньшему количеству вредных выбросов, связанных с электропитанием, заметим, что Уровень 3 вовсе не обязательно является самоцелью развития виртуализации на всех предприятиях; в некоторых случаях имеются веские экономические причины вовсе не переходить на Уровень 3.

Мы опускаем описание перехода с Уровня 0 до Уровня 1, поскольку подавляющее большинство средних и крупных предприятий уже сделали этот шаг.

Процесс перехода от Уровня 1 к Уровню 2 включает в себя замену отдельных выделенных серверов на более широкие платформы, использующие виртуальные серверы. Если требуется свыше одного физического сервера, можно добиться дополнительных преимуществ за счет группировки приложений на физических серверах таким образом, чтобы их профили пиковой нагрузки не совпадали, а были распределены во времени. Благодаря этому появляется возможность статистического усреднения нагрузки, так как обычно определение необходимой мощности сервера производится в зависимости от пиковой, а не от средней нагрузки. Компромиссом здесь являются расходы на овеществленную энергию нового сервера для размещения виртуальных сред (см. врезку «Обеспечение рентабельности расходов на овеществленную энергию при покупке нового сервера виртуализации»). Аналогичным образом можно решить вопрос и с инфраструктурой хранилища.

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

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

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

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

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

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

Компромиссами в этом случае являются:

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

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

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

Заключение

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

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

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

Ресурсы

«Выбросы парниковых газов в США», 2006 г.; Управление по информации в области энергетики, ftp://ftp.eia.doe.gov/pub/oiaf/1605/cdrom/pdf/ggrpt/057306.pdf

«Измерение эффективности центров обработки данных Google, приверженность экологичным информационным технологиям», http://www.google.com/corporate/datacenters/measuring.html

«Измерение энергоэффективности центров обработки данных Green Grid: PUE и DCiE», The Green Grid, http://www.thegreengrid.org/gg_content/TGG_Data_Center_Power_Efficiency_Metrics_PUE_and_DCiE.pdf

«Руководство по энергоэффективным центрам обработки данных», The Green Grid,
http://www.thegreengrid.org/gg_content/Green_Grid_Guidelines_WP.pdf

«Принципы сохранения окружающей среды Microsoft», Corporate Citizenship,
https://www.microsoft.com/About/CorporateCitizenship/US/ResponsibleLeadership/EnvironmentalPrinciples.mspx

«Энергосбережение в Microsoft Windows Server 2008»,
https://www.microsoft.com/downloads/details.aspx?FamilyID=61d493fd-855d-4719-8662-3a40ba3a0a5c&displaylang;=en

«Закон Мура», Википедия,
http://en.wikipedia.org/wiki/Moore%27s_law

Object Consulting
http://www.objectconsulting.com.au/

«Дорога к экологичным ИТ», Майк Гленнон (Mike Glennon),
http://www.fujitsu-siemens.com/ps/itfuture2008/presentations_benefr/GARTNER_Green-IT.ppt

«Профилирование», Википедия,
http://en.wikipedia.org/wiki/Performance_analysis

Telstra Corporation,
http://www.telstra.com.au/abouttelstra/csr/environment.cfm

Об авторах

Кевин Фрэнсис – менеджер по производству и национальным практикам компании Object Group (Мельбурн, Австралия). Его опыт работы в сфере информационных техно­логий в качестве архитектора, архитектора корпоративных систем и менеджера проекта насчитывает 23 года. Кевин является специалистом в сфере сервис-ориентированной архитектуры, архитектуры корпоративных систем, продуктов Microsoft. Кевин имеет опыт работы в качестве руководителя групп размером до 120 человек. Он был архитектором решений со статусом MVP с 2005 по 2008 гг. В настоящее время помогает компании Object выйти на лидирующие позиции на рынке программного обеспечения Австралии. Статья Кевина опубликована в журнале «The Architecture Journal», № 7; кроме того, он ведет блог: http://msmvps.com/blogs/architecture/.

Питер Ричардсон – начальник отдела интеллектуальной собственности компании Object Consulting и исполнительный директор InfoMedix Pty. Ltd. Отвечает за продукты и интеллектуальную собственность Object Group. Он является вдохновителем мероприятий по защите окружающей среды и руководит всеми корпоративными инициативами и решениями по снижению негативного влияния на экологию. Поскольку ранее Питер работал на должности руководителя технологического отдела Object, его опыт в качестве архитектора, в основном крупномасштабных корпоративных систем, насчитывает более 23 лет. В 2000 году Питер основал InfoMedix – дочернюю компанию Object Consulting, занимающуюся разработкой продукции для ведения медицинской документации. С 1996 по 1999 гг. Питер был австралийским партнером Object Management Group. До перехода в компанию Object в 1991 году и основания ее офиса в Мельбурне Питер являлся ведущим инженером компании Telstra Research Labs.