Шаблоны приложений для «зеленых» ИТ
Дэн Роджерс (Dan Rogers) Ульрих Хоманн (Ulrich Homann) Краткое содержание.Энергия становится все более дефицитным и дорогостоящим ресурсом. Влияние этой тенденции на процессы разработки, развертывания и использования ИТ-решений, в частности на уровне центра обработки данных, будет оставаться значительным. Виртуализация и другие энергосберегающие технологии – это важный шаг на пути к решению данной проблемы, однако виртуализация приложений, не эффективных изначально, имеет очевидные ограничения. В настоящем документе представлена концепция разработки энергосберегающих приложений. Сведение к минимуму необходимых ресурсов не только помогает сэкономить средства компании, снижая потребность в создании новых центров обработки данных, – в дальнейшем это превращается в обязательное условие для роста.
СодержаниеВ чем заключается проблема Теория ограничений Вызовы и реалии Какие ограничения следует оптимизировать? Комментарии к моделям затрат на электроэнергию Тактика Архитектура и проектирование на основе единиц масштаба Виртуализация Перспективы на будущее Инвестиции Microsoft в System Center Заключение Ресурсы В чем заключается проблемаМногие компании по всему миру уже столкнулись с жесткими ограничениями на объем электроэнергии, которую они могут себе позволить – или которую им разрешено – потреблять; для остальных предприятий – это перспектива недалекого будущего. На рисунке 1 показано, что на управление и администрирование серверов приходится большая часть расходов центра обработки данных. Мы будем рассматривать этот фактор в качестве ограничивающего рост центра обработки данных. Однако если ввести лимиты на потребление электроэнергии, то они превратятся в ограничения дальнейшего роста; именно это показано на диаграмме, отражающей результаты исследования (на рисунке справа).
Рис. 1. Затраты в центре обработки данных (щелкните рисунок, чтобы увеличить изображение)Правительства многих стран уделяют пристальное внимание вопросам энергопотребления. Конгресс США рассматривает возможности лимитирования расходов центров обработки данных, чтобы сдерживать рост энергопотребления в национальных масштабах, поэтому доступная мощность и производительность системы охлаждения стали основными ограничениями для дальнейшего развития. В этой ситуации многие организации пытаются лимитировать или сокращать объем потребляемой энергии. Однако общепринятые подходы, связанные прежде всего с оптимизацией инфраструктуры, слишком узко специализированы и не способны сдерживать рост энергопотребления в будущем. Необходимы такие методы, оптимизирующие использование инфраструктуры в рамках всей экосистемы, которые будут охватывать процессы разработки архитектуры и проектирования приложений, управления центрами обработки данных и ИТ-операции. Теория ограниченийПодходящей отправной точкой является «Теория ограничений» (Theory of Constraints, TOC) доктора Голдратта (Dr. Goldratt), знакомая многим читателям. TOC утверждает, что подход, связанный с выявлением и устранением ограничений (или взаимозависимостей) на уровне системы, является более эффективным, чем попытки оптимизации каждой отдельной подсистемы. ТОС возникла в сфере управления производством и затем была расширена; обобщенная теория применима и к концепции «зеленых» ИТ. Наиболее актуальный принцип TOC – оптимизация пропускной способности. Согласно этому подходу, можно достичь максимальной производительности за счет контролирования узких мест в системе, то есть путем их оптимизации таким образом, чтобы обеспечить максимально возможную пропускную способность имеющихся ресурсов. В случае с ИТ ограничениями являются компоненты инфраструктуры – серверы, образы, виртуальные машины, память, пропускная способность и т. д. Эти компоненты влияют на скорость получения ценных для бизнеса результатов. Вызовы и реалииВ настоящее время применяется множество общепринятых шаблонов проектирования и моделей поведения приложений и решений, но они вступают в конфликт с ограничениями уже сегодня, а в будущем проблем станет еще больше. Синхронность мертва.Современные разработчики и архитекторы приложений достигли совершеннолетия в мире, в котором ресурсы были доступны всегда, когда в них возникала потребность. Синхронность потребностей и ресурсов стала одним из основополагающих принципов нашего подхода к продажам сразу после того, как мы покинули рынок мейнфреймов. Дефицит доступной мощности растет, и правительства разных стран начали обсуждать жесткие ограничения на энергопотребление в центрах обработки данных. В будущем разработчики будут вынуждены тратить много времени на оптимизацию энергопотребления приложений просто потому, что такой подход влечет за собой меньше затрат, чем превышение лимитов на потребление электроэнергии. Ожидаемый «успех» с точки зрения использования приложения как принцип проектирования.Большинство современных решений разрабатывается с учетом гипотетического конечного состояния, а не как органичная система, расширяемая по мере необходимости. Например, компания со 150 000 пользователей может развернуть решение SharePoint с 50 ГБ дискового пространства для каждого пользователя. В процессе планирования структуры, производительности и подхода к развертыванию решения специалисты ориентируются на «успех». В данном случае это предполагает немедленную доступность 50 ГБ дискового пространства для каждого пользователя. На рисунке 2 показан типичный профиль нагрузки, характеризующий предполагаемое использование развернутого приложения или решения; нагрузка увеличивается в течение двух лет. Запасы мощности обнадеживают, однако они, как правило, бесполезны: ресурсы – электроэнергия, пространство для хранения данных и т. д. – выделяются с учетом пикового потребления в ходе развертывания решения, вместо того чтобы обеспечить распределение «точно в срок» (последнее гарантировало бы экономию дефицитных ресурсов и способствовало бы снижению затрат).
Рисунок 2. Профиль нагрузки для развернутого решения (щелкните рисунок, чтобы увеличить изображение).Что нужно? Когда это нужно?В середине 90-х годов ИТ-подразделение корпорации Microsoft использовало HR-приложение совместно с отдельным решением для расчета заработной платы; для этого требовалось значительное количество серверов, которые работали всего два дня в месяц, а все остальное время простаивали. Менеджеры по бережливому производству обращали внимание на эту проблему, однако ИТ-персонал не мог предложить подходящий вариант использования систем для решения других задач. Учитывая тот факт, что все любят получать зарплату, ИТ-специалисты каждый раз успешно отстаивали свою позицию. Сегодня все изменилось. Вариант «Мы развернем еще один компьютер или центр обработки данных» уже никого не устраивает. Теперь в порядке вещей подход «Мы сделаем все возможное, чтобы свести к минимуму потребление ресурсов». С этой целью необходимо проанализировать динамику потребления доступных мощностей и ответить на вопросы «Что требуется?» и «Когда это требуется?». Проектирование «по наитию» (Seat Of Your Pants, SOYP). Использование подхода SOYP в процессе планирования – верный способ получить неэффективную систему. Но сегодня даже крупные проекты зачастую основываются на предположениях и расплывчатой информации о потребности в ресурсах. Комбинация входных факторов, как правило, приводит к разработке решения, ориентированного на пиковую нагрузку плюс n % [20 % < n < 50 %]. Алгоритм, который используется для планирования сроков реализации проекта, применяется и к производительности решений, потому что никто не хочет быть «слабым звеном» – единственным человеком, который портит весь проект из-за своей неверной оценки. Подход к проектированию решений «ремень и подтяжки» (Belt-and-Suspenders).Книги по клиент-серверным технологиям учили нас быть максимально осторожными. Наши системные решения были не столь надежны, как требовалось, поэтому мы двигались долгим путем, чтобы избежать рисков, раскрытия конфиденциальной информации или уязвимостей: если пояс порвется, подтяжки по-прежнему будут поддерживать штаны. В процессе разработки приложений мы привлекали партнеров по решениям и инфраструктурам, которые предоставляли несколько методов устранения любой из возможных неисправностей. Выражение «единственная точка отказа» стало оправданием для бесчисленных ненужных расходов: три веб-сервера там, где хватило бы двух, две подсистемы балансировки нагрузки просто потому, что одна из них может однажды выйти из строя, две базы данных в рамках кластеризованных избыточных сетей хранения данных (storage area networks, SAN) и т. д. Потребность в решениях для аварийного восстановления и обеспечения надежности осталась, но связанные с ней задачи необходимо привести в соответствие с экологическими целями организации. Задача уменьшения энергопотребления приобретает все большую важность, поэтому архитекторам приложений придется уделять пристальное внимание сбалансированным проектам. Мы не можем всецело полагаться на виртуализацию или более совершенное оборудование при решении этой задачи. Каждому придется присоединиться к борьбе за более энергоэффективные ИТ. Какие ограничения следует оптимизировать?Гипотеза о синхронности опровергнута ограничениями на энергопотребление, поэтому мы должны разработать такой подход к оптимизации, который позволит организовать требуемое обслуживание, обеспечив при этом минимально возможные затраты на эксплуатацию приложений и систем. Как показано на рисунке 3, рычагами выступают затраченная энергия, а также доступные и использованные единицы обслуживания.
Рисунок 3. Вне зависимости от того, включены серверы или нет, они потребляют ценные ресурсыНа данном рисунке представлен четырехмерный граф (единицей затрат является центр обработки данных. Если ваша шкала основывается на более мелких единицах, требуется соответствующая корректировка). Небольшие блоки представляют собой единицы масштаба – это фиксированная мощность, полученная в результате фиксированных капиталовложений. Нельзя добавлять меньше одной единицы, однако можно изменять размер единиц. Поэтому доступная мощность увеличивается скачкообразно с целью удовлетворения спроса, при этом наблюдается несоответствие между использованными единицами обслуживания и затраченной энергий. Общие затраты – ключевой фактор оптимизации. Вы должны «использовать их по полной» – прямое следствие мантры ИТ‑отдела «отключите их». Обеспечить максимальную эффективность использования энергии можно лишь выполняя больший объем работы без добавления единиц. Комментарии к моделям затрат на электроэнергиюЭлектроэнергия оплачивается по-разному, в зависимости от потребляемого объема. Мелкие заказчики оплачивают по факту. Они, как правило, пытаются уменьшить соотношение объема потребляемой электроэнергии и объема оказываемых услуг, останавливают невостребованные сервисы. Крупные заказчики должны соблюдать определенный уровень и скорость потребления в конкретные периоды времени. Они будут пытаться уменьшить количество энергии, указанное в контракте, или увеличить объем услуг, которые они могут оказать посредством приобретенной энергии. Обычно они не задумываются об отключении ресурсов, поскольку не могут немедленно извлечь из этого пользу. ТактикаТеперь мы имеем представление о факторах оптимизации и препятствиях, стоящих на пути к ней и связанных с разработкой архитектуры и проектированием приложений. Пришло время проанализировать, что можно реально сделать для реализации проектов энергетически эффективных приложений. Измерения, измерения, измеренияВозможности для сбора и анализа данных о поведении систем и их компонентов отсутствуют, поэтому меры, направленные на оптимизацию, приходится строить на предположениях. Следующие рекомендации взяты из внутреннего документа Microsoft, разработанного Джеймсом Гамильтоном (James Hamilton): в нем автор обобщил уроки, извлеченные из наших крупномасштабных интернет-проектов.
Чем проще, тем лучше. Определите, какие результаты нужно измерить, и измеряйте их. Не полагайтесь только на приблизительные значения или статистические выборки. Ключ к успеху – измерение потоков данных, а не взятие образцов в определенные моменты времени. Полезный инструмент присутствует в библиотеке Enterprise Library – это блок для приложений, отвечающих за ведение журнала; он подготовлен группой специалистов по шаблонам и практикам корпорации Microsoft. Этот блок, в частности, защищает ваши инвестиции в разработку инструментальных средств. Композиционные моделиКомпозиция широко применяется в процессе работы над архитектурой приложений. Для наших целей мы просто хотели бы призвать архитекторов и проектировщиков проверять свои предположения о структуре компонентов, сервисов и систем, а не обсуждать относительные достоинства конкретных моделей. Один из методов проверки мы определили ранее – это подход «что требуется и когда». Эта проблема важна с точки зрения как программного кода, так и оборудования. Код, компоненты и модули приложения могут быть развернуты и будут потреблять ресурсы, несмотря на то что необходимость в них возникает лишь изредка, а иногда они вообще не нужны. Даже системы, которые отлично подходят для секционирования, часто выполняются как монолиты. Такой подход влечет за собой наименьший риск с точки зрения доступности, но при этом разработчик делает опасное предположение о том, что ресурсы неограниченны. Известны подходы и методы композиции и факторизации, которые помогают создать дружественные для ресурсов структуры и при этом удовлетворить потребности пользователей. ДетализацияФакторизация и композиция – эффективные средства, позволяющие свести к минимуму использование ресурсов. Эти методы разрешают разбить приложение на минимальные блоки, которые могут выполняться как автономные модули. Тем не менее важно не переусердствовать в процессе оптимизации, нельзя пользоваться слишком ограниченным набором целей. Возможность селективного развертывания функциональных возможностей обеспечивается за счет разделения кода приложения на функциональные группы. Такой подход позволяет задействовать компоненты в определенные моменты времени без ущерба для общей функциональности. Работу затем можно распределить между четко определенными и дружественными к ресурсам модулями. В Windows Server 2008 реализована именно эта модель. На рисунке 4 показана таксономия, которую использовала команда разработчиков ОС Windows Server при реализации подхода, позволяющего оптимизировать системы клиентов с учетом специфических ограничений.
Рисунок 4. Композиция и зависимости для одного сервера или рабочей нагрузки (щелкните рисунок, чтобы увеличить изображение)Windows Server Manager использует роли для развертывания функций и управления ими. Масштаб развертывания регулируется на уровне функций и ролей, которые теперь не имеют тесной взаимосвязи друг с другом в рамках избыточных структур, таких как рабочие нагрузки, решения или продукты (компоненты Windows Server невидимы). Все приложения Windows, которые входят в релиз Windows Server 2008, соответствуют этой таксономии. Другие продукты Microsoft, например Exchange 2007, придерживаются аналогичного подхода к факторизации на основе ролей. Может показаться, что подобная таксономия специфична для Microsoft и Windows, однако она применима и к другим операционным системам и приложениям. На самом деле это общий каркас для композиции программного обеспечения в процессе разработки приложений, операционных систем, баз данных или бизнес-решений (например, систем ERP или CRM). ЗависимостиМодель может быть избыточной для некоторых приложений, но базовая концепция ролей знакома большинству разработчиков. Даже приложения «одной роли», как правило, зависят от других ролей (например, базы данных) или взаимодействуют с другими ролями или приложениями (например, веб-сайт взаимодействует с системой ERP). Однако в традиционных клиент-серверных приложениях отношения скрыты в скомпилированных привязках. В целях обеспечения предсказуемого и автоматизированного управления ресурсами эти зависимости должны быть сформированы в модельные элементы, включаемые в исходный код приложений. Таксономия, представленная на рисунке 4, описывает композицию и зависимости для одного сервера или рабочей нагрузки. Большинство решений в современных центрах обработки данных являются распределенными и включают несколько уровней. На рисунке 5 мы увеличили размерность модели, что позволяет описать зависимости между серверами и уровнями. Сервер/рабочая нагрузка и роль сервера такие же, как в таксономии Windows Server на рисунке 4, что дает возможность легко соединить модели.
Рисунок 5. Размерность модели распределенного приложения
Эта информация позволяет оперативной группе понимать критически важные зависимости между ресурсами, а также особенности их использования. Кроме того, она дает возможность автоматизировать предоставление ресурсов с учетом функциональных и нефункциональных требований и оперативных шаблонов, таких как пользователь или транзакция, в любой момент времени. Работа архитектора заключается в структуризации приложения, которое должно предоставлять возможность развертывать функциональные элементы по требованию и точно в срок для одного или нескольких серверов. Мы считаем, что это позволит операторам гибко оптимизировать общие расходы, независимо от того, какая модель покупки электроэнергии задействована. Операторы будут четко понимать и различать необходимые функциональные возможности и зависимости в приложениях и между различными приложениями. Таким образом, развертывание будет отвечать требованиям пользователей при минимальном потреблении ресурсов. Архитектура и проектирование на основе единиц масштабаРанее мы обсуждали проблему систем, которые разрабатываются с нацеленностью на «успех» – гипотетическое максимальное количество пользователей. Если вы разрабатываете приложение, изначально готовое обслуживать каждого пользователя, который появится в будущем, – это верный путь к перерасходу ресурсов. Избыточная система повышает риск возникновения точки отказа, ее использование нецелесообразно с финансовой точки зрения с самого начала. Простой пример: вы не можете купить устройство для балансировки нагрузки, которое поддерживает динамическое масштабирование. Все подобные инструменты предоставляют фиксированное количество портов. Производительность физического оборудования становится лимитирующим фактором для расширения, этот фактор имеет огромное влияние на стоимость. Можно приобрести устройство для балансировки нагрузки с 500 портами. Однако если вам потребуется только 100 портов в первый год, то такая избыточность сведет на нет экономию от покупки более производительного оборудования. Вы не можете построить стену из одного огромного кирпича, аналогичным образом не стоит развертывать ИТ, ориентируясь на максимальную мощность. Для интеллектуального масштабирования необходимо использовать подход, основанный на единицах масштаба. Единицы масштаба инициируют «управляемый рост», основанный на четко определенных «факторах роста». Сочетание такого подхода с инструментированием и композицией/факторизацией, описанными ранее, позволяет разворачивать функциональность точно в срок, согласовывать использование ресурсов с фактическими потребностями пользователей без ущерба для архитектуры. Такой подход практикуется в рамках крупных интернет-проектов. Планирование основано на единицах масштаба, каждая из которых представляет собой определенный блок ИТ-ресурсов, единицу роста. Учитывается все, что необходимо для следующего шага на пути роста: вычислительная мощь, пропускная способность сети, распределительные щиты питания, площадь помещений, производительность системы охлаждения и пр. Единица масштаба должна соответствовать начальным потребностям в ресурсах, позволяя не выходить за пределы отклонений ключевых факторов роста, будь то транзакции, количество пользователей, порты и т. д. Размер единицы масштаба нужно выбирать с учетом оптимального баланса между ресурсами, которые необходимы немедленно, и ресурсами, которые могут потребоваться в дальнейшем. Факторы роста, как правило, скрыты в документах о планировании мощностей для каждого конкретного продукта. Например, в руководстве по планированию Microsoft SharePoint Server говорится, что планировать ресурсы (серверы, системы хранения, пропускную способность и т. д.) нужно в зависимости от количества и размеров сайтов SharePoint, требуемого количества откликов в секунду и ожидаемого числа активных пользователей. Аналогичные факторы роста используются и для SharePoint Server. В рамках модели «успех как принцип проектирования» прогнозируемая мощность, как правило, сопоставляется с архитектурой, а затем эти предположения определяют запросы ресурсов и развертывание. Наша задача: мы не хотим ориентироваться на «успех» в процессе развертывания. Мы стремимся осуществлять развертывание точно в срок и использовать ресурсы максимально эффективно. Процесс проектирования довольно прост:
Для эффективного развертывания единиц масштаба необходим эффективный мониторинг, развертывание (предоставление) должно быть автоматизированным (или по крайней мере хорошо управляемым). Кроме того, требуется установить четкую причинно-следственную связь между факторами роста драйверов и единицами масштаба. ПримерПриведем пример использования SharePoint. Давайте рассмотрим вымышленное развертывание SharePoint Server в столь любимой нами производственной компании Contoso. Желаемого конечного состояния компания достигнет в 2010 г., когда бизнес-подразделения по всему миру завершат внедрение решения. Единицы масштаба и факторы роста для решения приведены в таблице 1. Таблица 1. Единицы масштаба и факторы роста для примера развертывания SharePoint
На рисунке 6 показаны единицы масштаба, которые влияют на увеличение развертывания с учетом факторов роста, указанных в таблице 1, а также на возможное максимальное развертывание.
Рисунок 6. Рост на базе единиц масштаба (щелкните рисунок, чтобы увеличить изображение)Решение изначально развернуто как комплексное с двумя экземплярами сервера приложений SharePoint и одним экземпляром SQL Server. Казалось бы, на графике показано последовательное срабатывание, факторы роста являются независимыми друг от друга, однако развертывание одной единицы масштаба может повлиять на некоторые аспекты развернутого решения. ОбобщениеЧтобы оценить эффективность такого подхода, давайте сведем воедино некоторые рассмотренные ранее идеи и вернемся к модели, которую мы использовали при обсуждении единиц масштаба и планирования мощностей. Посмотрите на шкалу «Использованные единицы обслуживания», представленную в виде красной линии в правой части графика на рисунке 3. В начальный момент времени Т0 центр обработки данных был построен, но его мощность не используется. Мы начинаем потреблять ресурсы, имеющиеся в центрах обработки данных, и через некоторое время спрос превышает предложение. Область ниже фиолетовой линии – задействованная мощность, выше фиолетовой линии – незадействованная мощность. Эффективное управление неиспользуемыми мощностями обеспечивает реальную экономию электроэнергии. ВиртуализацияАрхитекторы приложений не рассматривают виртуализацию в качестве отправной точки для создания «зеленых» ИТ; для них это инструмент, с помощью которого эффективные приложения потребляют меньше ресурсов. На начальном этапе увеличения мощностей виртуализация позволяет привести аппаратные ресурсы в соответствие с нуждами пользователей. Потребление электроэнергии снижается за счет сокращения предоставленных, но неиспользуемых мощностей оборудования. В будущем виртуализация позволит отключить избыточные ресурсы, которые уже были развернуты. Такое решение требует наличия переключаемой схемы электроснабжения с компьютерным управлением, динамической конфигурации сети. Кроме того, необходимо программное обеспечение с поддержкой масштабирования, элементы которого можно компоновать и разделять по мере необходимости. Решение должно быть подключено и управляться системой мониторинга, которая не только отслеживает его состояние, но и «понимает» факторы мощности и параметры ее потребления. При наличии этих базовых элементов можно будет регулировать вычислительные ресурсы (и, следовательно, энергопотребление) на основе информации о том, насколько хорошо решение соответствует условиям соглашения об уровне обслуживания (SLA). Если решение работает на ожидаемом уровне, избыточные мощности можно отключить. Это основной сценарий, который заставляет представителей отрасли обращаться к виртуализации. Это невероятно сложная задача, требующая очень строгого контроля и более точных моделей (в том числе моделей мощности, моделей потребления, мониторинга нескольких измерений, запаса надежности и схемы управления питанием). Даже если работа измеряется не в единицах центров обработки данных, проблема остается: необходимо сократить потребление ресурсов без ущерба для выполняемой работы. С этой точки зрения архитектурное секционирование приложений становится критически важной задачей. В настоящее время проблема заключается в избыточности ресурсов: «Найдите неиспользуемые мощности и отключите их». Эту проблему могут решить ИТ-специалисты, которые находятся «на передовой». В будущем вариант «больше» уже не подходит. Только проектировщики и архитекторы смогут справиться с этой задачей, и сделать это нужно прежде, чем будет развернуто или даже создано программное обеспечение. Вместо того чтобы разрабатывать приложения, полагающиеся на синхронность (подход «нужно получить больше, чтобы получить больше», когда виртуализация применяется с целью устранить избыточность ресурсов при непиковых нагрузках), мы можем сконцентрироваться на том, чтобы оптимизировать распределение ресурсов между приложениями, используемыми в рамках бизнес-процессов. «Купить много компьютеров» – это не выход. Нужно продумать, как выполнить работу, потребляя треть или четверть того, что считается необходимым. В ближайшие 20 лет наш мир изменится: ценность пяти серверов приравняется к ценности программного обеспечения, установленного на двух компьютерах, ценность которых будет определяться их мощностью. Для этого следует убедиться, что задействованы все невостребованные ранее ресурсы (пространство над фиолетовой линией) – а все доступные ресурсы используются результативно и эффективно. Перспективы на будущееХранение и переадресация, постановка в очередь и возобновлениеАрхитекторы должны проектировать приложения, составные части которых функционируют независимо друг от друга, поддерживая обмен данными и обеспечивая требуемый результат. Возвратимся к примеру с системой начисления заработной платы, которая работает только два дня в месяц: наша задача состоит в том, чтобы найти вариант использования этих ресурсов в течение остальных 28 дней. Вместо того чтобы конфигурировать программное обеспечение на фиксированном оборудовании, нужно разработать приложения, которые могут храниться на виртуальных «полках» в виде отдельных частей, готовых к активации в различных сочетаниях точно в срок. Для этого требуется мощный и гибкий набор программного обеспечения для управления. Программное обеспечение для управления и приложение должны работать совместно, чтобы отслеживать и создавать профили нагрузок для всех функциональных компонентов (например, ролей сервера), а также топологии (например, сайты и группы серверов). Мы должны отслеживать и составлять профили статического и динамического потребления, время при этом рассматривается как ключевое измерение с точки зрения управления ресурсами. На рисунке 7 показан упрощенный профиль нагрузки в течение 24 часов. Использование фактора времени позволяет отойти от принципа синхронности и расширить выпуск услуг, несмотря на фиксированный бюджет и ресурсы.
Рисунок 7. Упрощенный профиль нагрузки в течение 24 часовУправление портфелемУправление отдельными приложениями является важным шагом в правильном направлении. Однако реальную пользу приносит управление статическими и динамическими ресурсами в рамках всего портфеля приложений, которые обеспечивают требуемый выпуск услуг. Программное обеспечение для управления должно отслеживать использование ресурсов, определять единицы масштаба, которыми можно управлять на плановой основе (то есть не все мощности будут задействованы постоянно) или динамически масштабировать на основе управляемых профилей нагрузки для всех приложений. Надлежащим образом факторизованные, документально оформленные и инструментированные приложения – вот ключ к новому измерению в сфере управления. Именно они позволят нам использовать подход к оптимизации ресурсов, недоступный в распределенных средах. Инвестиции Microsoft в System CenterТак же, как мы начали разделять операционную систему на компоненты, корпорация Microsoft реализует стратегии в сфере мониторинга, распространения программного обеспечения, диагностики проблем и виртуализации. Семейство продуктов Microsoft System Center – одна из ключевых инвестиций в инструменты управления, средства управления инфраструктурой и автоматизации операций. Приложения Microsoft Operations Manager, Virtual Machine Manager и Configuration Manager находятся на пути к слиянию и предоставляют динамичную и гибкую систему управления, которая необходима для эффективного использования ресурсов. В будущем ожидается быстрое схождение всех возможностей в рамках комплексных решений для управления системой, которые позволят клиентам оптимизировать инфраструктуру и достигать большего, используя меньше ресурсов – будь то площадь помещения, производительность системы охлаждения или вычислительная мощность. Как это согласуется с подходом на основе стандартных блоков? System Center будет контролировать работу в динамичной рабочей среде. С точки зрения проектирования и разработки программного обеспечения, пакет управления – метаданные управления System Center – будет определять объект поиска (данные мониторинга поступают от инструментария приложений, который предоставляет информацию о ключевых мощностях и потреблении информационных ресурсов) и предоставлять формулы для определения влияния этих мер на работоспособность и производительность критически важных компонентов системы. System Center будет знать, какие компоненты работают и насколько хорошо они это делают, а также балансировать нагрузку с течением времени. Пакеты управления станут ключевым компонентом управления для каждой секции – элемента системы. Архитектура пакета управления проста – это XML-файл, который соответствует определенному набору схем. Данный подход весьма эффективен, поскольку файл содержит метаданные, описывающие состояние и работоспособность факторизованных компонентов. То, что работает для больших синхронных приложений, подходит идля факторизованных. В действительности лучшие из современных пакетов управления – например, для Windows Server 2008, SharePoint и приложений Dynamics – изначально имели несколько слоев и состояли из отдельных компонентов. System Center развивается, и пакеты управления станут ключевыми составляющими бизнес-приложений и инфраструктуры, базовыми элементами в стеке. System Center уже умеет отслеживать состояние и работоспособность серверов под управлением Linux и Unix, поэтому сейчас закладывается фундамент для революционных изменений с точки зрения гибкости приложений. Предприятие будет управлять системой, потребляя значительно меньше вычислительных ресурсов, но при этом по-прежнему сможет выбирать поставщиков операционных систем и программного обеспечения. Независимо от того, на каких технологиях построена система, переход к секционированным приложениям позволит представить слой мониторинга и анализа потребляемых мощностей в виде пакета управления. Это даст возможность управлять приложениями экономично и эффективно; аппаратные ограничения, лимитирующие эффективность современных приложений, утратят свою актуальность. ЗаключениеАрхитекторы приложений могут проектировать распределенные системы с более эффективным управлением ресурсами. Во-первых, можно согласовать четко определенные цели оптимизации с факторизацией. Единицы масштаба позволяют группировать и согласовывать секционированные решения с минимальными развертываниями без ущерба для общей архитектуры развертывания. Единицы масштаба в сочетании с инструментированием позволяют программному обеспечению для управления, такому как System Center, управлять портфелем приложений на основе поставленной цели и утвержденного подхода к оптимизации. Эти возможности очень скоро воплотятся в реальность. В мире, где существуют жесткие ограничения на потребление энергии, скорейшая реализация этих возможностей будет в наших общих интересах. РесурсыMeasuring National Power in the Postindustrial Age, Ashley J. Tellis et. al, RAND Corporation, 2000 http://www.rand.org/pubs/monograph_reports/MR1110/ Wikipedia – Theory of Constraints http://en.wikipedia.org/wiki/Theory_of_constraints Об авторахДэн Роджерс пришел в корпорацию Microsoft в 1998 г., он занимался разработкой ряда продуктов, включая BizTalk, Visual Studio и MSN. В настоящее время входит в состав команды разработчиков System Center и формирует стратегии мониторинга, которые позволяют создавать динамичные ИТ-решения. В MSN Дэн помогал разрабатывать решения для мониторинга в рамках крупномасштабных динамичных проектов, таких как популярные файловые хранилища и почтовые сервисы, а также участвовал во множестве проектов, связанных с комплексной автоматизацией глобального центра обработки данных. Ульрих Хоманн – ведущий архитектор решений в группе стратегических проектов подразделения глобальных услуг Microsoft. Эта группа относится к службе технического директора и отвечает за управление и корпоративные архитектуры в рамках ключевых стратегических проектов по всему миру. |
.png)
.jpg)
.png)
.png)
.png)
.png)
.png)
.png)