ИТ-портал компании «Инфосистемы Джет»

Как решать проблемы с производительностью бизнес-приложения

Как решать проблемы с производительностью бизнес-приложения

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

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

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

Рис. 1. Многослойная архитектура бизнес-приложения

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

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

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

Через месяц продуктивной работы от системы мониторинга поступил «тревожный звонок» о достижении первых порогов предупреждения заполнения файловых систем на новом оборудовании. Это было несколько неожиданно, так как сайзинг системы с учетом возможного роста был рассчитан на год. Еще через несколько недель стало понятно, что системы прибавляют не только в объеме. Требования к производительности аппаратного комплекса и системы хранения данных росли так же линейно, как и объем. И если с местом проблема еще решалась, то с производительностью все было не так просто. Таких нагрузок проектное решение, сформированное нами на основе сайзинга, не предполагало. Судя по тенденции роста нагрузки, полученной из системы мониторинга, к концу квартала можно было ожидать сильную деградацию производительности части бизнес-приложений вплоть до полной остановки сервиса. Проведенный нами экспресс-аудит СХД и базы данных позволил сформировать новое проектное решение, которое основывалось уже на реальных, а не на предполагаемых значениях. Систему модернизировали и в течение полугода мигрировали на оборудование другого класса.

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

У другого нашего заказчика благодаря аудиту мы диагностировали негативно влияющие на производительность проблемы с оборудованием еще до ввода в эксплуатацию. За последние несколько лет его ИТ-инфраструктура выросла из нескольких стоек до нескольких серверных в разных ЦОД Москвы, не считая удаленных офисов и филиалов по стране. На очередном этапе модернизации компания расширила свою инфраструктуру на полтора десятка шасси и High-End массивов.

Когда часть оборудования планировали вводить в эксплуатацию, мы совместно с заказчиком решили при аудите по приемке новой системы провести нагрузочное тестирование СХД. Проектное решение предполагало использование на массивах гибридных пулов с несколькими уровнями хранения на FMD, SAS и SATA дисках. По расчетным данным, скорость IO должна была быть примерно как у самолёта. На практике самолёт взлетел, но «низенько». Причем скорость операций записи была еще приемлемой, а вот чтение оставляло желать лучшего. В результате тестирования мы пришли к выводу, что проблема воспроизводится на разных шасси одной модели, разных операционных системах, версиях FW (Firmware) оборудования. Аналогичные тесты на сервере другого вендора и той же СХД дали прекрасный результат. Таким образом, проблема была локализована, мы воспроизвели ее производителю СХД. Вместе с вендором мы выяснили, что из-за бага в FW лезвий операционные системы неэффективно использовали память и CPU для процессов операционной системы, что косвенно влияло на производительность IO.

Наиболее трудно диагностировать те проблемы, которые либо не воспроизводятся, либо имеют «плавающий» характер. Не так давно мы столкнулись с подобной на одном из проектов. В системе ERP, реализованной на SAP, часть запросов стала отрабатывать гораздо медленнее, чем раньше. Со стороны системы мониторинга проблем с оборудованием и его производительностью не наблюдалось. Нагрузка на СХД и серверы даже несколько снизилась. Первичная диагностика со стороны SAP проблем не выявила, было принято решение о комплексной проверке со стороны HW, ОС, СХД. Пока проверяли оборудование, проблема перестала воспроизводиться. Диагностику завершили, ошибки обнаружились только со стороны SAP при взаимодействии между компонентами ERP-системы. Как раз во время медленной работы приложения были зафиксированы ошибки «Communication error», которые заказчик интерпретировал как проблемы с сетью. При этом ошибки на интерфейсах сетевого и серверного оборудования отсутствовали, проблем в других системах из той же сети не было, и только часть новых запросов со стороны приложения работала медленно. Оставалось вооружиться tcpdump'ами, подготовить для сравнения всю диагностическую информацию и ждать воспроизведения сложившейся ситуации. Мы составили список первоочередных проверок, которые помогли бы выявить источник проблемы. Ждать пришлось недолго, через несколько дней ситуация повторилась. Первая же проверка показала отсутствие записей в DNS для одной из диалоговых инстанций в прямой зоне и для другой в обратной. После добавления заказчиком записей проблема ушла. Причины таинственного исчезновения записей из DNS и не менее загадочного их появления во время первого инцидента мы не установили, поскольку этот сервис поддерживался силами заказчика.

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

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su