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

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

Провайдеры услуг благодаря IP и многопротокольной коммутации меток (Multi-Protocol Label Switching, MPLS) способны предлагать надежные виртуальные частные сети (Virtual Private Network, VPN). Критичный для компании трафик обрабатывается в приоритетном порядке в соответствии с заданным качеством услуг (Quality of Service, QoS); можно сказать, что для важных данных в глобальных сетях всегда зеленый свет. «Пропускная способность по мере надобности» — этот слоган сегодня пользуется большой популярностью и у многих сетевых администраторов порождает твердую веру в то, что при помощи нужной дозы дополнительной производительности можно без особого труда «отмасштабировать» любую проблему.

ВНИМАНИЕ: ЗАДЕРЖКИ!

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

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

В других случаях, напротив, экономичные решения для тонких клиентов, например Citrix MetaFrame или Windows Terminal Services, оказываются очень чувствительными к задержкам. Они справедливо пользуются успехом при централизованном использовании старых приложений, которые в противном случае потребляли бы значительную пропускную способность: применение тонких клиентов позволяет ограничиться небольшими объемами передаваемых данных — содержимое экрана и вводимые с клавиатуры данные. Одновременно это является причиной высокой чувствительности к задержкам: как только временной интервал между нажатием клавиши и реакцией экрана становится заметным, все решение может потерять свою ценность для пользователя. При консолидации и централизации недостаточная производительность становится главным препятствием — с разрушительными последствиями для успешной реализации задуманного. Достаточно часто последующие попытки настройки не укладываются в поставленные сроки и предоставленные средства и тем самым заметно снижают запланированный коэффициент окупаемости инвестиций (Return on Investment, ROI).

ОТ СЛОЖНОГО К ПРОСТОМУ

Эта проблематика не ограничивается однократной централизацией сервера. Под давлением конкуренции предприятия должны в короткие сроки вводить новые деловые процессы. Как следствие, спросом пользуется быстрое распространение нового программного обеспечения, поскольку все процессы строятся на его основе. Так называемое «быстрое развертывание приложений» (Rapid Application Deployment) предлагает многообещающий подход. Основная идея заключается в систематическом применении — с различных точек зрения — интеллектуальной комбинации измерений и прогнозирования. Подход нацелен на упрощение чрезвычайной сложности оптимизации функционирующей глобальной сети до приемлемого уровня. Исходным пунктом являются пользователи, целевым параметром — реальная производительность конкретного приложения, а граничным условием — экономное потребление пропускной способности. При этом реализация должна проходить как можно быстрее.

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

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

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

ФОРМИРОВАНИЕ УСЛУГ В ГЛОБАЛЬНЫХ СЕТЯХ

Методы планирования в глобальных сетях в большинстве своем базируются на сложном, а потому дорогом моделировании, требующем много времени.

В противовес этому в области быстрого развертывания приложений активно используется понятие «формирование услуг в глобальной сети». Метод нацелен на быстрое предоставление справок о том, где именно — на уровне приложений, сервера или сетевом уровне — и какие действия необходимо предпринять (см. врезку «Формирование услуг глобальной сети в двух словах»). Различным точкам зрения соответствуют четыре профиля: к названному уже профилю приложений добавляются профили пользователя, развертывания и инфраструктуры (см. Рисунок 1).

Рисунок 1. Формирование услуг в глобальных сетях базируется на комбинации различных профилей требований.

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

Профиль развертывания или реализации указывает количество клиентов и серверов, упорядочивает профили пользователей по филиалам и времени использования, а потому тесно связан с планом развертывания приложения. И наконец, профиль инфраструктуры описывает, как распределенные в пространстве филиалы подключаются к серверному центру. К нему относятся логические и физические каналы глобальной сети, включая всю доступную информацию о пропускной способности, фоновой нагрузке и задержке (см. Рисунок 2). Поскольку акцент делается на оптимизацию структур глобальных сетей, сложные топологии локальных сетей не рассматриваются.

Рисунок 2. Географическое представление нагрузки на глобальную сеть с предупреждениями.

ИНТЕРАКТИВНЫЕ СЦЕНАРИИ «ЧТО БЫЛО БЫ, ЕСЛИ...»

Планирование производительности должно поддерживать реализации для небольшого количества пользователей точно так же, как и для тысяч клиентов. Поэтому формирование услуг в глобальных сетях используется на различных уровнях: транзакций, филиалов и предприятия. Для всех трех случаев при помощи специальных инструментов генерируется соответствующий профиль приложения в качестве ввода для формирования глобальной услуги. На уровне транзакций так называемый предсказатель времени задержки (Response Time Predictor, RTP) оценивает информацию от профилей пользователей, развертывания и инфраструктуры. Весьма полезно рассматривать каналы глобальной сети не с точ-ки зрения пропускной способности, а как провайдера выделенного качества услуг. Тем самым подход RTP учитывает и чувствительные к задержке приложения, производительность которых растет не пропорционально росту пропускной способности (см. Рисунок 3).

Рисунок 3. Предсказатель времени реакции сравнивает время реакции при различной нагрузке глобальной сети и заданной задержке и пропускной способности.

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

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

ЗАКЛЮЧЕНИЕ

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

Андреас Хунцикер — менеджер по решениям управления производительностью в центральном регионе EMEA компании Compuware. С ним можно связаться по адресу: wg@lanline.awi.de.

Формирование услуг глобальной сети в двух словах

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

? AWi Verlag