Денис Зельтинг, начальник отдела систем мониторинга и управления, Группа компаний «Компьюлинк»
Движение пользователей в облака продолжается уже несколько лет. По сути, это движение представляет собой перенос корпоративных приложений в ЦОД и предоставление доступа к ним в виде услуги. Чтобы в тумане облаков не потерять управляемость приложений, необходим обновленный подход к организации мониторинга, позволяющий связать воедино контроль оборудования, приложений и сервисов.
В настоящей статье речь пойдет о мониторинге ЦОД. Но прежде чем перейти непосредственно к основной теме, предлагаю вспомнить, что же такое ЦОД и что в нем необходимо мониторить. Согласно распространенному определению, ЦОД – это специализированное здание для размещения (хостинга) серверного и сетевого оборудования и подключения абонентов к каналам сети Интернет. Такое определение плохо подходит для целей данной статьи. Более полезна классификация ЦОД по назначению, согласно которой они подразделяются на корпоративные, обслуживающие конкретную компанию, и коммерческие, предоставляющие услуги всем желающим.
На мой взгляд, ключевое слово здесь – «услуги». ЦОД – это уже не просто здание для хранения серверного и сетевого оборудования с возможностью подключения абонентов к Интернету, а совокупность технических средств для предоставления услуг. Таким образом, имеем два вида центров обработки данных – коммерческие и корпоративные.
Коммерческий ЦОД, как правило, предоставляет клиентам доступ к инфраструктуре. В простейшем случае это будет обеспеченная гарантированным электропитанием стойка для размещения оборудования клиента в помещении, отвечающем определенным требованиям по климатическим параметрам, с возможностью удаленного доступа к оборудованию по сети. В более сложных случаях это может быть определенный объем ресурсов в системе виртуализации серверов или же какой-либо набор типовых приложений (СУБД, веб-серверов и т. д.).
Корпоративный ЦОД также представляет собой специализированные помещения для централизованного размещения серверного и сетевого оборудования, но при этом он оказывает пользователям одной компании или группы компаний услуги не в виде типового набора аппаратных ресурсов или унифицированных приложений, а в виде доступа абонентов к широкому набору корпоративных бизнес-приложений и информационных систем. Именно это разнообразие услуг и представляет наибольшую сложность для мониторинга корпоративного центра обработки данных. Далее рассмотрим основные подходы к мониторингу центров обработки данных.
Традиционный мониторинг центров обработки данных
Традиционный способ мониторинга ЦОД хорошо применим для коммерческих ЦОД. Архитектура системы для такого мониторинга довольно проста и определена структурой самого коммерческого ЦОД. Типовой коммерческий ЦОД составляют:
- инженерная инфраструктура (системы кондиционирования и увлажнения, системы обеспечения бесперебойного питания, системы пожаротушения);
- сетевая инфраструктура (как правило, коммутаторы L3);
- серверная инфраструктура (как правило, шасси серверных «лезвий»);
- системы хранения данных.
Обычно все эти составляющие унифицированы, что позволяет использовать довольно ограниченный набор специализированных средств мониторинга и управления, предлагаемых производителями соответствующего оборудования (элемент-менеджеры). При этом иногда даже не требуется делать единую консоль мониторинга – достаточно повесить несколько панелей, каждая из которых отображает данные от одного из средств мониторинга. В таком случае, при необходимости контролировать сервис клиента, достаточно добавить любую простейшую систему анализа влияния (impact analysis), в которой устанавливается прямая связь между клиентом или услугой и контролируемым ресурсом ЦОД, например портом сетевого коммутатора. То есть на выходе у такой системы мониторинга будет планарный список сообщений о состоянии объектов мониторинга ЦОД, и в лучшем случае у оператора мониторинга будет возможность определения клиента, к которому относится конкретное сообщение.
Сервисно-ориентированный мониторинг ЦОД
В корпоративном ЦОД в качестве услуги предоставляется не оборудование, а бизнес-сервис или приложение. Поэтому и контролировать приходится состояние не элементов инфраструктуры ЦОД, а сервисов.
Мониторинг сервисов в ЦОД служит двум основным целям:
- объективный контроль качества предоставляемых услуг в целях формализации отношений между ИТ и бизнесом (контроль соблюдения SLA);
- улучшение качества услуг за счет более оперативного (в идеале – проактивного) обнаружения и устранения неисправностей, необходимое для обеспечения соблюдения SLA.
Эти цели во многом определяют два принципиально разных подхода к мониторингу сервисов: «сверху вниз» и «снизу вверх».
Подход «сверху вниз» заключается в контроле основных параметров качества сервиса (как минимум, доступность и производительность) с точки зрения конечных пользователей. Для этого существует специализированное программное обеспечение для выполнения синтетических транзакций. Зонды мониторинга устанавливаются в сети пользователей и периодически воспроизводят заранее записанные сценарии, выполняющие типовые действия пользователей в консоли бизнес-приложения. Информация о доступности и времени отклика приложения, собранная таким образом, сохраняется для последующего анализа и используется, в частности, для определения соблюдения SLA между бизнес-подразделениями и ИТ-службой. Несмотря на кажущуюся простоту этого способа мониторинга, реализовать подход «сверху вниз» довольно сложно. Вот только некоторые из трудностей, с которыми придется столкнуться при его реализации:
- клиентские приложения могут иметь веб-интерфейс, либо быть реализованы в виде «толстого клиента», либо вообще запускаться в терминальных сессиях. Это значительно затрудняет запись сценариев действий пользователей;
- в идеале зонд активного мониторинга должен быть установлен максимально близко к клиентским рабочим местам. Часто у клиентов есть только АРМ и нет серверов, на которые можно было бы установить зонд, что заставляет устанавливать зонд в самом ЦОД и, следовательно, снижает объективность получаемых данных и не позволяет контролировать всю цепочку оборудования и приложений между клиентом и сервером;
- не во всех бизнес-приложениях (особенно в банковских и бухгалтерских) есть возможность выполнять тестовый сценарий;
- выполнение сценариев мониторинга не должно создавать значительной дополнительной нагрузки на само бизнес-приложение. При этом сценарий должен выполняться достаточно часто, чтобы обеспечить непрерывный мониторинг, приближенный к реальному времени.
Подход «снизу вверх» в определенном смысле более традиционен, так как является развитием мониторинга коммерческого ЦОД, т. е. состоит из двух этапов: сначала собирается максимальное количество данных со всех объектов ЦОД (инженерное, серверное, сетевое оборудование, системы хранения данных, системы виртуализации, системное и прикладное ПО и т. д.), а потом определяется влияние этих объектов на работу сервисов ЦОД на основе заранее созданной модели влияния. Для реализации такого подхода необходимо решить следующие задачи:
- разработать сервисно-ресурсные модели для услуг ЦОД. Эти модели должны определять влияние одних объектов ЦОД на другие при реализации функционала бизнес-сервисов;
- ввести данные о полученных моделях в базу данных конфигурационных элементов (CMDB);
- максимально автоматизировать процесс актуализации сервисно-ресурсных моделей. Например, при подключении сервера к другому порту коммутатора или при переезде виртуальной машины на новый хост связи модели должны обновляться автоматически без участия оператора;
- для каждого элемента модели определить, какая информация мониторинга должна быть к нему привязана. При этом необходимо определиться со способами получения информации (сообщения, отправляемые самими объектами мониторинга, или числовые метрики, получаемые путем опроса состояния объекта), а также с правилами вычисления статуса элемента на основе полученных данных;
- для каждой пары связанных элементов определить характер влияния состояния одного из них на работу другого. Например, выход из строя одного сервера из фермы терминального доступа окажет влияние только на производительность, а выход из строя базы данных приведет к полной потере работоспособности бизнес-сервиса.
Реализация такой системы мониторинга, где оператор не просто следит за списком сообщений, а видит их влияние на работу конкретных сервисов, позволяет приоритезировать работу инженеров поддержки к зависимости от влияния сбоя на работу бизнес-сервиса, а также в автоматизированном режиме определять корневую причину сбоя. Кроме того, наличие сервисно-ресурсных моделей обеспечивает анализ влияния различных элементов инфраструктуры ЦОД на бизнес-сервисы, что позволяет уменьшить вероятность простоя критических сервисов в ходе регламентных работ.
Сделать всеобъемлющий мониторинг сервисов ЦОД очень сложно. Еще труднее – поддерживать его в актуальном состоянии. Поэтому, прежде чем начинать проект по мониторингу сервисов ЦОД, необходимо четко понимать, какие цели должны быть достигнуты, что важнее в каждом конкретном случае – контроль качества сервисов или ускорение устранения сбоев. Также нужно сразу выбрать перечень наиболее критичных бизнес-систем, мониторинг которых должен быть реализован в первую очередь, и найти баланс между двумя подходами к сервисному мониторингу. Попытки реализовать сразу весь набор функций мониторинга на всем объеме сервисов приведет к значительному увеличению сроков проекта и может поставить под сомнение достоверность информации в системе мониторинга из-за вероятного низкого качества результатов такого проекта, в результате чего полученной системой никто не будет пользоваться и все усилия окажутся потраченными впустую. Качественно реализованный ограниченный набор функций мониторинга для наиболее критичных бизнес-систем позволит быстрее получать выгоды от внедрения системы мониторинга и сделать наработки, которые впоследствии можно будет использовать для тиражирования решения на остальные сервисы ЦОД.
