Антон Мальков
Статья посвящена вопросам повышения надежности работы серверов баз данных и приложений. Особое внимание уделяется системам проактивного мониторинга, позволяющим предсказывать поведение систем на основе исторических данных. В качестве инструмента повышения надежности рассматривается система Cerberus, разработанная (1997) компанией Sats Technologies. В 2001 года российская компания “Лаборатория “НТР” стала принимать участие в проектировании и разработке этой системы, версию 3.0 которой “Лаборатория “НТР” на правах эксклюзивного дистрибьютора в России и СНГ представляет вниманию пользователей.
Обеспечение надежности работы приложений
Если эти вопросы не имеют для вас никакого значения, то читать эту статью дальше нет никакого смысла. Дальнейшее повествование в основном посвящено специфическим прикладным системам мониторинга СУБД. Системам, которые призваны снизить не только сами риски возникновения аварийных ситуаций и сократить период диагностики, но в целом оптимизировать деятельность службы технической поддержки, что, в конечном итоге, позволит сократить совокупную стоимость владения (TCO) информационной системой.
В данный момент на рынке представлено несколько систем мониторинга СУБД, включая Oracle Enterprise Manager. Предметом данной статьи является решение компании SATS Technologies: система проактивного мониторинга баз данных Cerberus, предлагаемая на российском рынке компанией “Лаборатория “НТР”. Cerberus имеет два существенных отличия от других систем данного класса:
- он является в “чистом виде” именно системой мониторинга и не пытается заменить уникальные, зачастую нетривиальные, знания АБД своими “электронными” решениями. Cerberus вообще не привносит никаких управляющих воздействий на БД, возлагая этот труд на “живого” администратора и оставляя за собой лишь обязанности сторожа (отсюда и название), который пристально следит за состоянием подопечной БД;
- Cerberus относится к классу систем проактивного мониторинга, что позволяет не только наблюдать за текущим состоянием БД, но и прогнозировать поведение ее объектов на основе накопленных хронологических данных.
Мониторинг или администрирование?
Большинство средств, которыми пользуются АБД для оптимизации своей работы, являются в большей степени системами администрирования, лишь в той или иной степени выполняя функции мониторинга. Отметим, что набор параметров, предоставляемых администратору, у всех систем более-менее одинаков. Наиболее существенные отличия – в графических средствах отображения этих параметров. Многие интерфейсы сделаны эргономично и профессионально и дают хорошую картину происходящих в БД процессов. АБД действительно может оперативно отреагировать в случае возникновения подозрений на критические ситуации. Хорошо ли, что мониторинг и администрирование в этом случае представлены “в одном флаконе”? С одной стороны, хорошо, что все под рукой, все рядом, и подкрутив в одном месте, сразу видишь результат в другом. С другой стороны, такая интеграция имеет недостатки:
- само по себе администрирование подразумевает наличие постоянной связи с БД, что может быть не совсем удобно, особенно при обеспечении безопасности при работе с удаленными серверами. При этом к сети необходимо предъявлять дополнительные требования;
- как правило, невозможно следить сразу за несколькими, особенно разнородными, базами данных;
- системы, построенные по принципу “два в одном”, зачастую имеют ограниченные возможности по настройке дополнительных параметров мониторинга. Например, включение в контур мониторинга специфических скриптов, созданных администратором за долгие годы работы без применения систем мониторинга. Или включение в мониторинг сбора данных о судьбе и состоянии приложений.
Рассмотрим, как с этих позиций устроен Cerberus, решение SATS Technologies. Повторим, что рассматриваемая система выполняет только функции мониторинга и не предоставляет никаких средств для управления базой данных. Разработчики SATS Technologies и примкнувшие к ним впоследствии специалисты из “Лаборатории “НТР” смогли придать системе некоторые специфические свойства:
- отказ от требования постоянной связи с базой данных;
- возможность вынести данные мониторинга из клиентской базы данных на сервер мониторинга. Таким образом, даже в случае “клинической смерти” базы данных у АБД остается информация для анализа причины “смерти”;
- удалось значительно расширить возможности слежения за пользовательскими приложениями, выйдя за рамки мониторинга исключительно Oracle Applications;
- и, наконец, у АБД появилась возможность встраивать в систему собственные процедуры.
Что такое проактивный мониторинг?
Отличительной чертой систем проактивного мониторинга (СПМ) является их способность предсказывать на основе анализа исторических данных возможные сценарии развития текущей ситуации. Качество прогнозирования зависит от длительности использования системы. Выполняя такой анализ, СПМ способны вырабатывать рекомендации, когда наиболее допустимо проводить регламентные работы, когда наступает “правильное” время для создания резервных копий и пр.
Рисунок 1. График улучшения достоверности прогноза от времени.
На простой вопрос: “Как делается прогноз?”, следует простой ответ: “Секрет!” Ни один производитель СПМ никогда никому не расскажет, как он это делает. В методологии анализа исторических данных и аппроксимации их на текущее состояние заключается, как раз то ноу-хау, за которое разработчик, собственно говоря, и берет деньги. В общем случае алгоритмы строятся на основе накопленного опыта АБД, а также используются документированные и не документированные свойства и параметры баз данных. Сложность заключается в том, чтобы все собранные знания систематизировать и формализовать, превратив их в алгоритмы анализа. Необходимо отметить, что практически всегда в таких системах точность прогнозирования зависит от времени, в течении которого система накапливает статистические данные. Представленный на рис.1 график построен на основании усредненных данных, полученных в результате эксплуатации Cerberus.
Как это работает
В отличие от алгоритмов анализа, архитектура систем мониторинга не является тайной. Более того, именно вокруг преимуществ и недостатков архитектурных решений чаще всего разгорается полемика между приверженцами различных систем. Именно архитектура, в конечном итоге, зачастую определяет возможность или невозможность применения того или иного продукта.
Необходимо отметить, что не бывает абсолютно хороших или безнадежно плохих архитектурных решений (хотя последний вариант, пожалуй, все-таки возможен). Просто область применимости зависит от большого числа условий, и то, что оптимально подходит для решения одних задач, оказывается совершенно неприемлемым в других случаях. В рамках данной статьи мы ограничимся рассмотрением внутреннего устройства только системы Cerberus.
Рисунок 2. Архитектура системы.
В общих чертах Cerberus архитектурно представляет из себя клиент-серверное приложение, где в качестве клиента выступает специализированное приложение-агент, который с некоторой периодичностью собирает параметры функционирования СУБД, необходимые для последующего анализа, и передает их на обработку серверу.
При этом собственно клиентские (пользовательские, обрабатываемые в БД) данные никогда и ни в каком виде не собираются и, тем более, никуда не передаются.
Доступ к пользовательским данным вообще может быть закрыт для Cerberus-агента.
Cerberus-сервер представляет аналитическую систему, которая обрабатывает поступающую информацию, оценивает текущее состояние СУБД и прогнозирует возникновение критических состояний в следующий период. Результаты анализа отображаются в “Cerberus DBA Portal” и, в случае наличия критических состояний, передаются администратору (группе администраторов), используя средства оперативной связи (email, ICQ, пейджер, мобильный телефон).
Агент
У Cerberus-агента есть несколько характерных особенностей, которые отличают его от аналогичных компонентов других систем:
- исключая один небольшой PL/SQL-пакет, Cerberus-агент не создает никаких дополнительных объектов в отслеживаемой БД;
- данные мониторинга передаются и “складируются” на Cerberus-сервере, никак не занимая ресурсы отслеживаемой БД;
- для снижения нагрузки на отслеживаемую БД, вся обработка и анализ параметров мониторинга выполняется на стороне сервера.
Работа агента осуществляется в двух режимах:
- Работа по получению основных параметров. По умолчанию осуществляется один раз в минуту.
- Полная диагностика. По умолчанию проводится один раз в десять минут. Естественно, временные интервалы срабатывания агента можно регулировать.
Сам по себе агент представляет собой программный модуль, который является внешним по отношению к СУБД и никак от нее не зависит. Cerberus-агент настраивается с помощью текстового конфигурационного файла, напоминающего по своей структуре старый добрый config.sys. В Unix- и Linux-системах Cerberus-агент устроен в виде Cron Daemon, а в Windows – в виде системной службы (Service).
Естественно, что если база данных “замолчала”, то агент будет бессилен получить от нее какие-либо параметры. В этом случае Cerberus-серверу будет немедленно отправлено извещение об “умолкании”, а Cerberus-агент будет по прежнему возвращать данные о системных ресурсах [прим. ред.: если только, вероятно, не умолкла одновременно и установка, на которой разворачивалось действо].
Сервер
Cerberus-сервер представляет собой интеллектуальную экспертную систему, построенную на основании опыта и данных, накопленных АБД, а также рекомендаций производителей СУБД. Примечательно, что доступ к “Cerberus DBA Portal” осуществляется через веб-интерфейс, не связывая администратора необходимостью постоянного присутствия в каком-то определенном офисе.
Кроме Oracle, Cerberus может осуществлять мониторинг и других СУБД (в текущей версии реализованы интерфейсы и соответствующие аналитические блоки для DB2, MS SQL и Informix). Также немало важно, что система может работать с несколькими разными СУБД одновременно.
Ранее уже упоминалось, что Cerberus не хранит никаких данных на контролируемых серверах. Таким образом, вся нагрузка, связанная с хранением и обработкой поступающей информации переносится на сервер Cerberus. Не зависимо от того, какая СУБД подвергается мониторингу, на сервере всегда используется ORACLE. Более того, вся обработка данных также в основном производится средствами ORACLE.
Как это выглядит
Представленные в данном разделе картинки дают некоторое общее представление о том, как выглядит система проактивного мониторинга баз данных “в жизни”.
Информация предоставляется АБД через веб-интерфейс, реализованный c помощью модуля PL/SQL. Главное меню выполнено в виде java-апплета.
Рисунок 3. Главное меню.
Для отслеживания критических ситуаций и потенциальных угроз в системе реализован механизм слежения за проблемами. Суть этого механизма заключается в том, что информация, содержащая критические сообщения, заносится в список проблем (рис.4). Каждая проблема имеет описание и указание на время и место возникновения. Кроме того, проблемам присваивается статус. В случае если проблема перестала существовать (в результате действий администратора или по счастливому стечению обстоятельств), статус изменяется на “Закрыт”. АБД может вручную поменять статус.
Рисунок 4. Список проблем.
Возможность просмотра Daily Statistics - статистики за день (рис.5) может оказаться весьма полезной как для целей администрирования БД, так и для бизнес-целей в целом.
Статистика за день (информация о процессах)
“Бизнес-ассистент” - Business assistant - (рис.6) призван не только помочь администратору в ответе на извечный вопрос “почему все так плохо?”, но и “наставить на путь истинный” прикладных программистов и искоренить “кривые” запросы, приводящие базу данных “в клинч”. Основными задачами “Бизнес-ассистента” являются статистическая экстраполяция и агрегирование данных о числе запросов к базе данных, их стоимости, выявление периодов времени для проведения регламентных работ, и отображении другой ценной информации необходимой для планирования ресурсов.
Функции “бизнес-ассистента” (Планирование ресурсов)
“Бизнес-ассистент” включает в себя следующие компоненты:
- Анализ ресурсов (Capacity at a glance). Функция представляет информацию о средней длине запроса, ресурсах, затраченных на обработку запроса и другие параметры, полезные для анализа ресурсов.
- Планировщик ресурсов (Capacity Planer). Функция позволяет рассчитать системные параметры при планируемом расширении нагрузки на приложения, например, при увеличении числа пользователей.
- Планировщик регламентных работ (Maintenance Planer). Функция использует накопленную за несколько предыдущих недель ежедневную статистику для планирования наиболее благоприятных периодов перезагрузки, выполнения резервного копирования и проведения обновлений.
- Определитель стоимости (Cost Analyzer). Весьма интересная возможность системы, которая полезна в наибольшей степени менеджерам компании, нежели администраторам базы данных. Функция позволяет рассчитать примерную стоимость пользовательских запросов. Таким образом, появляется возможность оценить общую экономическую эффективность используемых приложений.
За рамками данной статьи осталось еще достаточно много возможностей системы Cerberus, перечисление и описание которых заняло бы много места. Но о вопросах обеспечения безопасности (следующий раздел) и аутсорсинга (раздел “ASP-модель”), рассказать все же необходимо.
Безопасность
Как угрозы безопасности, так и применяемые средства защиты весьма разнообразны, начиная от широко используемых сетевых экранов, и заканчивая весьма радикальными мерами. Например, в некоторых государственных учреждениях доступ в Интернет вообще закрыт (физически), но использование e-mail возможно, благодаря устройству двойного шлюза между внутренней и внешней сетью с использованием протокола X400. Большинство средств мониторинга и администрирования требуют постоянного подключения к БД. В случае с ORACLE чаще всего используется SQL*Net поверх IP. Таким образом, устройство даже элементарных средств защиты между клиентской базой данных и центром, где находится администратор, значительно осложняют возможность применения средств мониторинга.
По архитектуре Cerberus (рис.2) агент через определенные временные интервалы формирует для сервера сообщения, которые являются файлами определенного формата. Далее задача заключается в том, чтобы любым возможным способом доставить эти файлы на сервер мониторинга. Таким образом, не требуется постоянного подключения не только к БД, но и вообще к серверу. Передача данных происходит по smtp- или http-протоколу, с возможностью использования proxy-сервера, и дополнительного шифрования данных. Следует оговориться, что при тестировании клиентских web-серверов, подключение по http-протоколу все-таки необходимо.
Теперь о том, как агент осуществляет доступ к базе данных. Достаточно тривиально. В отслеживаемой БД создается схема. В ней компилируется пакет хранимых процедур Cerberus, ни одной таблицы не создается. Поскольку все свои параметры Oracle хранит в системных представлениях, то надо дать привилегии по чтению нужных представлений. Исключением являются случаи, когда требуется обследовать (только по желанию Заказчикав этой БД) еще и клиентские приложения. Тогда в зависимости от алгоритмов диагностики необходимо добавить привилегии на доступ к соответствующим объектам.
ASP-модель
А можно ли вообще избавиться от АБД, или, по крайней мере, сократить их количество? Этот вопрос имеет парадоксальный ответ: “Да”. SATS Technologies предлагает поистине новаторское решение в вопросе снижения стоимости технической поддержки. Эффект достигается за счет предложения компаниям на выбор двух вариантов системы.
- Первый, традиционный, заключается в приобретении продукта Cerberus. Это позволит увеличить эффективность службы технической поддержки, особенно в случаях территориально разнесенных баз данных.
- Второй вариант включает в себя покупку услуги, в рамках которой за базой данных клиента будут следить (и ухаживать) администраторы SATS Technologies.
Остановимся несколько подробнее на втором варианте, тем более что он является уникальным, и я не слышал о каких-либо еще поставщиках решений, представляющих подобную услугу. Суть ее заключается в том, что центром сбора и обработки данных является сервер SATS Technologies. Данные мониторинга от различных контролируемых серверов обрабатываются единым обработчиком, но при этом каждый клиент видит результаты мониторинга только свой системы. Используя, некоторую внутреннюю организационную структуру, администраторы SATS Technologies наблюдают за всеми подконтрольными серверами 24 часа в сутки 7 дней в неделю и в случае наступления критических состояний оперативно реагируют на ситуацию вплоть до выезда к клиенту. В случае если у клиента администратор, эксперты SATS Technologies смогут до окончательного устранения аварии руководить его действиями, используя любые доступные каналы связи.
Очевидно, что описанную ASP-модель крупные компании с удаленными филиалами могут организовать внутри себя, собрав в едином месте квалифицированных АБД и устроив там центр управления, оставив в филиалах минимальное число обслуживающего персонала.
Вопросам экономической эффективности систем мониторинга можно посвятить целую отдельную статью [прим. ред.: - и даже не одну, и даже не одну дискуссию и/или многолетнюю полемику]). Ведь, в конце концов, именно этот вопрос является ключевым при создании и функционировании информационных систем.
- Сколько для вашей компании стоит частичная (не дай Бог, полная) потеря данных?
- Какова оценка возможных убытков при временной потере доступа к данным?
- Сколько стоит хороший АБД (администратор базы данных)? Или два?
- Сколько времени проходит с момента возникновении аварии до того как администратор начнет ее устранять?
Оставьте отзыв!