Управление ИТ: новая эпоха — новые задачи

Привычное развитие ИТ по закону Мура вступило в противоречие с возможностями классической архитектуры. Рост производительности отдельно взятого процессора закончился на Itanium, и неожиданно началось движение в обратную сторону (достаточно назвать успехи ARM и Atom). Не вызывает сомнения тот факт, что в обозримый период времени будущее за распределенными архитектурами, причем, несмотря на кажущееся разнообразие, все возможные подходы к таким образованиям укладываются в три инфраструктурных решения:

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

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

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

Поколения и волны

Обычно компьютерную историю делят на пять поколений: (1946–1959 годы) — вакуумные лампы, (1959–1965) — дискретные компоненты, (1965–1971) — интегральные микросхемы, (1971–1980) — большие интегральные схемы, нынешнее — на микропроцессорах и сверхбольших интегральных схемах. На пятом поколении качественное развитие остановилось до тех пор, пока не появится что-то радикально новое (например, квантовый компьютер или нечто подобное), осталось только количественное, естественным образом связанное с развитием инфраструктур. И здесь также наблюдается своя смена поколений.

В самом начале 60-х годов один из основоположников искусственного интеллекта Джон Маккарти описал гипотетическое превращение компьютинга в коммунальную услугу, впервые использовав слово utility в приложении к компьютерам. Тогда, в эпоху культового поклонения искусственному интеллекту, эта идея была активно подхвачена и широко обсуждалась, но в то время казалось, что она будет реализована на каких-то невероятных по мощности компьютерных монстрах. Леонард Клейнрок, один из четверых «отцов» Интернета, раньше других (в 1969 году) осознал, что решающая роль принадлежит не отдельным, пусть очень большим компьютерам, а сетям: «Сейчас компьютерные сети находятся в зародышевом состоянии, но со временем, достигнув зрелости, они смогут превратиться в computer utilities, то есть в такие же коммунальные службы, как электричество и телефон, и к ним будут точно так же подключены все дома». Но на этом все снова само собой затихло, и только в конце 90-х компания HP возродила к жизни идею коммунальной услуги. Ее активно подхватили разные аналитики, но дальше разговоров дело опять не пошло — потребовалось еще около 15 лет, за которые успели появиться облачные технологии, чтобы о utility computing можно было бы говорить, как о реальности.

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

Стартовая точка в эволюции инфраструктур — централизованные мэйнфреймы и миникомпьютеры, затем в восьмидесятые последовал взрывной рост интереса к ПК и одновременно заметный инфраструктурный шаг — появление локальных сетей и распределенных вычислений. Однако вскоре стало ясно, что от централизации полностью отказаться нельзя, поэтому возник паллиатив в виде клиент-серверной архитектуры, оказавшейся чрезвычайно удачной и живучей, но не единственной, параллельно с ее существованием наметился переход к архитектуре, ориентированной на Web. И наконец, во втором десятилетии XXI века стал неизбежностью еще один, возможно наиболее радикальный, переворот — переход к распределенным архитектурам: облакам, кластерам и гридам. Каждый из этих переходов выражался не только в смене основной технологической парадигмы, будь то мэйнфрейм, ПК, Unix-серверы, но и в появлении волны качественно новых инфраструктур компьютерных систем, с иными количественными показателями (рис. 1), и, как следствие, увеличивалась роль средств для управления этой инфраструктурой. Без адекватных средств управления ни одна сложная инфраструктура существовать не может.

Рис. 1. Количественный рост показателей информационных систем в текущем десятилетии

IPM

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

В 90-х получили широкое распространение Uniх и клиент-серверные архитектуры, совместно позволившие избавиться от информационной раздробленности, одного из главных недостатков ПК. Данные превратились в общий корпоративный ресурс, соответственно, в этот период наблюдается бурный рост СУБД. Но за это пришлось платить появлением новых задач управления — теперь требовалось обеспечить контроль доступа, хранить данные в управляемых файловых системах, а также управлять конфигурациями и сетями. В итоге сложилось второе направление — управление распределенными системами (Distributed Systems Management, DSM). В более узком смысле DSM определяют как набор средств для управления взаимосвязанными частями компьютерных систем, а компонентами таких систем могут быть приложения, вычислительные узлы и сети. Обычно такое управление ограничено активацией и деактивацией компонентов и настройкой параметров. С переходом в эру WWW задачи управления распределенными системами сохранились и углубились, но теперь преимущественное значение приобрели задачи информационной безопасности и соответствия предъявляемым нормативным требованиям.

При вступлении в эпоху облаков управленческие решения окончательно вышли на первый план, и их стали называть Infrastructure Performance Management (IPM), причем использование слова «менеджмент» здесь, скорее, дань традиции — в этом контексте термин IPM точнее можно перевести как управление характеристиками, поведением, качеством работы инфраструктуры информационной системы. В функции такого управления входят сбор и анализ в реальном времени всех параметров инфраструктуры, обеспечение наиболее эффективного использования и поддержания в работоспособном состоянии ресурсов гетерогенной физической среды, виртуальной и облачной сред. IPM служит для того, чтобы ИТ поддерживали заданный уровень обслуживания, соответствующий требованиям бизнеса.

Основные факторы возникновения потребности в IPM: многократный рост размеров ЦОД и cложности их внутренней инфраструктуры; специфические свойства виртуализации всех видов ресурсов; рост числа пользователей и используемых ими объемов данных; увеличение количества и разнообразия приложений.

За последние несколько лет сформировалось несколько направлений для управления инфраструктурными компонентами — серверами, сетями, приложениями и сетями хранения (рис. 2). Возникновение управления системами предприятия (Enterprise Systems Management, ESM) было вызвано переходом от централизованной модели к децентрализованной как первая попытка справиться со сложностями управления большим количеством слабых компьютеров, распределенных по сети. В область действия ESM включены все основные системные компоненты: компьютерное и сетевое оборудование, операционные системы и приложения. В свою очередь, ESM, существующее последние 10–15 лет, выросло из управления сетями, прежде всего из SNMP (Simple Network Management Protocol), протокола сетевого управления, позволяющего устройствам от разных производителей общаться между собой.

Рис. 2. Гносеология IPM

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

Существует два подхода к автоматизации мониторинга — агентный и безагентный. В первом случае на каждый компьютер устанавливают программу-агент, которая проверяет работоспособность компьютера и при необходимости изменяет параметры конфигурации. В зависимости от степени совершенства, система ESM может быть или реактивной, то есть она ограничена сообщениями о нарушениях, или проактивной, прогнозирующей возможные неприятности. Если в компьютерах и другом оборудовании предусмотрен интерфейс для систем контроля, то можно обойтись без агента, передав эти функции специально выделенному компьютеру, что будет сопряжено с повышенной нагрузкой на сеть. Наиболее известны в области автоматизации мониторинга продукты таких компаний, как HP, IBM, CA и BMC.

Первые разработки в области управления производительностью сетей (Network Performance Management, NPM) относятся к середине 90-х годов, и сегодня это гигантский рынок. Ежегодно в этой области возникает несколько десятков новых производителей, и сегодня их так много, что трудно представить, как они умудряются делить рынок между собой. Стоит посмотреть отчет о рынке сетевых инструментов Network Monitoring Tools, подготовленный в Стэнфордском университете, чтобы получить представление о гигантском объеме работы, выполняемом в этом направлении. В конечном счете инструменты NPM служат для оценки того, как сеть удовлетворяет потребности пользователей, для этого они анализируют параметры и управляют производительностью, определяя уровень ошибок. При этом данные мониторинга переводятся в количественные показатели с последующей подготовкой отчетов и выработкой управляющих воздействий на приложения и составляющие сетевой инфраструктуры. В результате могут быть проверены и оценены характеристики сети в целом и получены данные по каждому отдельному компоненту. Средствами NPM удается узнать, как данные перемещаются от сегмента к сегменту, как физическая топология соответствует трафику, как пропускная способность отвечает запросам пользователей и чем они нагружают сеть. По мере увеличения размеров сетей и объемов передаваемых данных значение инструментов NPM возрастает — проверить и оценить работу отдельного компонента несложно, но гораздо сложнее сделать это для сочетания большого количества компонентов в разветвленной сети. Приходится не просто измерять те или иные показатели, объединять и анализировать полученные значения, а анализировать накопленную историческую информацию для определения трендов и выявления возможных отклонений.

Управление работой приложений (Application Performance Management, APM) — одно из самых молодых направлений области управления ИТ, его появление датируется 2005 годом. Однако этот сегмент весьма активно развивался — и за восемь лет рынок достиг двухмиллиардного рубежа, здесь действуют десятки компаний, от стартапов до IBM, CA, HP, Quest, Compuware и др. Возникновение APM связано с усложнением современных приложений, которые требуют управления в процессе своего исполнения. В качестве основных стимулов к созданию систем APM следует назвать виртуализацию, облака и мобильность.

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

Современная программная инженерия использует такие подходы, как «скорая» (agile) методология разработки, или методика быстрого тестирования, основанная на взаимодействии команд. SOA как программная архитектура начинается с описания интерфейсов, создания всей топологии приложений как описания системы вызовов.

С 2001 года SOA претерпела мощнейшие искажения со стороны апологетов веб-сервисов и стала основой современных корпоративных приложений. Миграция поддерживается средствами edge computing («компьютинг на острие»), ее суть — в перемещении всего приложения или его части по инфраструктуре облака или грида к месту нахождения данных и выполнение обработки данных непосредственно на площадке их размещения. В условиях Больших Данных Магомет вынужден идти к горе. Один из первых примеров реализации еdge сomputing — платформа Kaval на базе Android, созданная в Пенсильванской национальной лаборатории.

На нынешнем уровне понимания, задачи APM сводятся к следующему:

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

Управление ресурсами хранения (Storage Resource Management, SRM) преследует своей целью оптимизацию использования ресурсов сети хранения. В функции SRM входят создание резервных копий, виртуализация систем хранения, мониторинг и анализ работы сети, аутентификация пользователей, поддержка регистрационных журналов и сервисных операций.

На рис. 3 представлены все четыре предшествующие IPM направления. Комментария заслуживает ось «утилизация ресурсов — производительность». Сегодня чаще говорят о виртуализации ресурсов, чем об управлении ими. Главная цель любой виртуализации в более рациональном использовании ресурсов путем их консолидации в пулы с последующим перераспределением. Распределение «обобществленных» ресурсов позволяет уменьшить затраты, повысить эффективность и степень использования (утилизацию) ресурсов. Виртуализация, абстрагируя те или иные ресурсы, одновременно привносит еще один уровень в стек технологий, тем самым затрудняя управление физической инфраструктурой. Помимо этого, возникает противоречие между открывающимися возможностями утилизации и требованиями производительности. Это две стороны одной медали — утилизация оценивается коэффициентами использования серверов, систем хранения и т. д., однако эта система оценок не совпадает с требованиями пользователей, для которых существенны готовность, реактивность, задержка и т. п.

IPM в частном облаке

С появлением технологий виртуализации для серверов, систем хранения и сетей появилась возможность создания динамического или эластичного ЦОД, на основе которого возникла концепция частного облака. Однако нередко, обеспечив незначительную функциональность, например развернув Microsoft Cloud OS, считают, что частное облако создано. На самом деле так удается лишь консолидировать ресурсы и получить относительную свободу использования их в форме сервисов, не более того. На пути к частному облаку обнаруживается серьезная ловушка — до тех пор, пока количество виртуализируемых ресурсов мало, ими можно управлять традиционными методами, но при значительных размерах требуются специализированные средства автоматизации управления. В связи с этим Томас Бритман, один из аналитиков Gartner, пессимистично написал: «К 2015 году большинство виртуализированных ЦОД смогут поддерживать лишь ограниченное число облачных функций. Не более 20% из них можно будет назвать настоящими частными облаками, и очень небольшому количеству предприятий удастся создать «достаточно хорошие» частные облака».

Канадская компания Embotics, разработчик пакета для управления виртуализированными средами Embotics V-Commander, обобщила мнение ведущих отраслевых аналитиков Gartner, Forrester, Enterprise Strategy Group, IDC, EMA, 451 Group и построила модель восхождения к облаку (рис. 3). Исследования на ее базе, проведенные в 2012 году, показали, что более 75% компаний, считающих, что им удалось создать частное облако, находятся на первом и частично на втором этапе, и лишь менее 25% перешли на третий, а на четвертом — практически никого нет. Анализ показывает, что для создания полноценного частного облака необходима полноценная программно-определяемая инфраструктура, полная виртуализация и консолидация ресурсов и, наконец, автоматизированная система управления.

Рис. 4. Модель восхождения к облаку

Не столь быстрое, как хотелось бы, восхождение к частным облакам связано с несколькими основными трудностями. И одна из них вызвана оборотной стороной виртуализации и явлением, которое получило название virtual stall — «виртуальный застой». Проблемы начинают возникать, когда виртуализация переходит с уровня подразделения на уровень предприятия в целом. На предприятиях внедрение виртализации начиналось с наименее значимых и критически важных задач, тогда результаты получались великолепные, но дальше возникали сложности. Вот почему несколько лет назад журнал Network World провел анкетирование руководителей ИТ-подразделений с целью выяснить насущные проблемы виртуализации. Самый массовый ответ (40%) — нехватка персонала для управления. Если не вдаваться в частности и обобщить, то можно однозначно сказать, что технологии управления, которыми они располагают, не отвечают возрастающей сложности.

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

До сих пор все системы управления, в том числе упомянутые ESM, NPM, APM и SRM, строились как системы управления без обратной связи — этого хватало, поскольку объем данных, время запаздывания и другие параметры объекта управления были таковы, что операторы с ними справлялись. В облачную эпоху для динамических информационных сред требуются IPM, отличающиеся включением в контур управления тех или иных компонентов обратной связи. По контуру обратной связи можно собирать, например, такие параметры, как загрузка процессоров, дисков, памяти, сетей, количество VM на процессор, снимки состояния виртуальных машин (содержимое памяти, настройки, содержимое дисков) в определенный момент времени и др. В таком случае система IPM будет выглядеть так, как показано на рис. 4. Используя данные обратной связи, контроллеры могут автоматически развертывать новые VM и выводить из эксплуатации ненужные, изменять конфигурации VM, ограничивать число снимков и периодически выполнять оптимизацию параметров.

Рис. 4. Управление облаком по замкнутой цепи обратной связи

Примером воплощения обратной связи в IPM может служить решение VirtualWisdom, созданное компанией Virtual Instruments. Прежде чем описать его, хочется отметить, что авторы документации вынуждены буквально на пальцах объяснять, как работает механизм обратной связи, что такое устойчивое состояние, какими бывают переходные процессы и другие элементарные истины. VirtualWisdom — решение, созданное в буквальном смысле этого слова с нуля, аналогов пока нет. Оно состоит из сервера, управляющего ПО и датчиков, собирающих данные о работе облака. Сервер обрабатывает входные данные и готовит представление о состоянии системы в реальном времени. На данный момент VirtualWisdom — первое и, возможно, единственное решение, поддерживающее IPM на общесистемном уровне. Решение состоит из следующих компонентов (рис. 5).

Рис. 5. Система управления VirtualWisdom с обратной связью

Сервер и пульт управления VirtualWisdom Server and Dashboard. Выполнен как высоконадежное приложение, созданное на базе СУБД, которое собирает измеренные данные от аппаратных и программных датчиков, распределенных по облачной инфраструктуре. От полноты сбора данных зависит точность анализа состояния и выработка управляющих воздействий по всему аппаратно-программному стеку облака. В реальном времени происходит анализ трендов, оценка сигналов тревоги, принимаются решения на основе моделирования «что если». VirtualWisdom Server поддерживает настраиваемый пользовательский интерфейс Dashboard UI, на котором развертываются все происходящие процессы. Кроме того, сервер служит для интеграции с продуктами других компаний.

Датчик виртуальных серверов VirtualWisdom Virtual Server Probe. Представляет собой программу, интегрированную с VMware vCenter и собирающую более сотни параметров о состоянии продуктов VMware (уровень использования процессора, загрузка памяти, интенсивность запросов ввода-вывода, параметры сети, использование виртуальных машин и т. п.). Анализ эти параметров сочетается с анализом показателей, полученных от других датчиков VirtualWisdom, что обеспечивает целостное представление системных процессов.

Датчик готовности сети хранения VirtualWisdom SAN Availability Probe. Представляет собой программу, получающую данные от управляющих устройств коммутаторов Fibre Channel и FCoE, а также SNMP. Он собирает все данные по каждому активному порту и организует их в соответствии с типом подсоединенного устройства, включая загрузку, объемы в байтах, сведения о чтении и записи, информацию об ошибках, в том числе о потере связи и синхронизации. Объединение этих данных со сведениями об устройстве позволяет выработать необходимые управляющие воздействия.

Датчик производительности сети хранения SAN Performance Probes. Программный датчик, перехватывающий каждый заголовок пакета Fibre Channel и каждую команду SCSI, что дает возможность знать все о трафике приложений и обнаруживать критические ситуации.

Точки доступа к трафику Traffic Access Points. Собирают данные о функционировании сети Fibre Channel.

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

***

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

Леонид Черняк (osmag@osp.ru) — научный редактор, «Открытые системы.СУБД» (Москва).