Оптимизация работы приложений в глобальной сети

Клиент-серверные приложения являются наиболее важным классом приложений IP, появившихся в корпоративных глобальных сетях в последние годы. Приложения планирования корпоративных ресурсов (Enterprise Resource Planning, ERP), выпускаемые компаниями SAP, PeopleSoft и Oracle, а также доморощенные приложения, разработанные для решения специфических задач, широко используются в современных корпорациях.

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

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

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

Этой безрадостной ситуации можно было бы избежать. Первый шаг состоит в понимании принципов функционирования клиент-серверных приложений в глобальных сетях. Второй — в изучении возможности оптимизации их характеристик. Третий — в проверке факта прохождения приложениями тестирования на готовность к работе в глобальных сетях (WAN Application Readiness Testing, WAN ART) в процессе их разработки и опытной эксплуатации. Это позволяет эффективно управлять такими характеристиками, как приходящаяся на одного пользователя пропускная способность и время реакции, с точки зрения конечного пользователя.

КЛИЕНТ-СЕРВЕРНАЯ АРХИТЕКТУРА

Рисунок 1. При транзакциях по типу пинг-понг клиент и сервер обмениваются между собой сотнями небольших пакетов.

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

В популярных пакетах от SAP и PeopleSoft реализована трехзвенная архитектура. Главное ее преимущество — масштабируемость, но, кроме того, она позволяет значительно сократить сетевой трафик.

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

Последним — но не по своему значению — звеном в этой цепочке является тонкий клиент. Ни одна дискуссия о клиент-серверной архитектуре не обходится без упоминания о тонких клиентах. В последнее время тонкие клиенты привлекают к себе значительное внимание, потому что полнофункциональные ПК и рабочие станции с текстовыми процессорами, электронными таблицами, электронной почтой, эмуляцией терминала и клиент-серверным программным обеспечением оказались слишком дороги в обслуживании и эксплуатации. Архитектура с тонкими клиентами позволяет облегчить это бремя благодаря сокращению затрат на обслуживание, как показывают некоторые оценки, на 80%. Реализации архитектуры с тонкими клиентами опираются на один из трех подходов: удаленная презентация и ее разновидности, примером чему может служить WinFrame/MetaFrame компании Citrix Systems; HTML; сетевые вычисления, как, например, в архитектуре сетевых вычислений (Network Computing Architecture, NCA) компании Oracle.

Рисунок 3. Гибридная транзакция представляет собой комбинацию транзакции по типу пинг-понг и массовой передачи данных в одном направлении.

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

Трафик клиент-серверного приложения генерируется транзакциями конечных пользователей. Транзакция может быть определена как процесс подачи конечным пользователем запроса и получения обновления экрана от сервера. В классическом мире SNA 3270 такая транзакция состоит обычно из двух пакетов: одного небольшого, посылаемого хосту, и одного большого, получаемого от хоста.

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

В случае транзакции по типу пинг-понга клиент и сервер обмениваются сотнями небольших пакетов (см. Рисунок 1). Массовая передача данных в одном направлении состоит из большого числа пакетов от сервера к клиенту и небольшого числа пакетов с подтверждениями от клиента к серверу (см. Рисунок 2). Гибридная транзакция представляет собой комбинацию двух названных типов транзакций (см. Рисунок 3).

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

ЧУВСТВИТЕЛЬНЫЕ К ЗАДЕРЖКЕ ТРАНЗАКЦИИ

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

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

Транзакции по типу пинг-понга чувствительны к задержке. Время получения отклика пользователем удлиняется, потому что пользователю приходится ждать, когда завершится обмен пакетами по глобальной сети, а таких пакетов в одной транзакции сотни. Например, пусть для регистрации пользователя в приложении требуется передать 500 пакетов туда-обратно. Увеличение задержки на 20 мс (вследствие проблем в сети, задержек на клиенте, сервере или маршрутизаторе) приводит к увеличению времени ожидания пользователя на 5 с (250 транзакций * 20 мс).

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

ОЦЕНКА ПРОПУСКНОЙ СПОСОБНОСТИ

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

Для оценки требований к пропускной способности в случае транзакций по типу пинг-понг вам придется учитывать несколько ключевых переменных:

N — число активных пользователей в офисе;

T — время раздумий пользователя (время, необходимое пользователю на размышления между последовательными запросами);

K — число пакетов на одну транзакцию в каком-либо одном направлении;

M — количество байтов в пакете в каком-либо одном направлении;

P — задержка в одну сторону.

С учетом принятых обозначений требуемая пропускная способность в одном направлении выражается формулой:

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

Обоснование этой формулы достаточно просто. Время, проходящее между последовательными транзакциями, генерируемыми одним активным пользователем, составляет K*P+N, так как K*P — это общая задержка в сети для K пакетов (в предположении обмена один на один), а T — время между транзакциями. В течение этого времени, т. е. K*P+T, пользователь передаст в заданном направлении K*M*8 бит данных. Множитель N соответствует числу активных пользователей.

В качестве иллюстрации предположим, что приложение с сервером в Соединенных Штатах и клиентами в Европе имеет следующие характеристики:

N = 25 активных пользователей в филиале;

T = 120 с;

K = 100 входящих пакетов и 120 исходящих пакетов;

M = 60 байт в случае входящих пакетов и 200 байт в случае исходящих пакетов (плюс 48 байт накладных расходов на глобальную сеть);

P = 150 мс (задержка в одну сторону).

Требуемая пропускная способность для входящего трафика составляет в этом случае 16 Кбит/с, а для исходящего — 43 Кбит/с. Таким образом, 43 Кбит/с будет максимальной потребляемой этим приложением пропускной способностью между Европой и Соединенными Штатами. Однако если физические и логические каналы в сети будут создаваться в расчете на 70-процентную загруженность, то требуемая пропускная способность будет составлять 43 Кбит/с, деленные на 0,7, т. е., приблизительно, 64 Кбит/с.

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

Продолжительность раздумий пользователя можно оценить на основании наблюдений за тем, как пользователь взаимодействует с приложением, или с помощью статистики использования в часы пик. Например, если пользователь подает 10 запросов в течение 15-минутного интервала времени, то продолжительность раздумий не превышает 90 с (15*60/10). Обычно эта величина составляет 1-2 мин.

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

МАССОВАЯ ПЕРЕДАЧА ДАННЫХ

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

Оценить пропускную способность можно с помощью следующей простой формулы:

где F — объем данных для передачи, O — доля накладных расходов на протокол, и R — допустимое, с точки зрения пользователя, время передачи. Доля накладных расходов учитывает накладные расходы на TCP/IP и канальный уровень. В случае сегмента TCP длиной 1024 байт доля накладных расходов на протокол составляет (1024+48)/1024=1,05 (приблизительно), или около 5%. Терпимое время передачи для клиент-серверных приложений не превышает обычно 3-5 с (включая задержки).

Например, предположим, что сервер в Соединенных Штатах передает блоки данных размером 256 Кбайт клиенту в Европе. Клиент хотел бы, чтобы данные появлялись не позднее, чем через 5 с. Требуемая пропускная способность будет составлять 256 000 байт * 1,05 * 8 / 5 сек = 430 Кбит/с. При этом окно приема TCP должно иметь размер по крайней мере в 16 Кбайт (430 Кбит/с *0,3 с). По умолчанию размер окна в Windows NT равен 8 Кбайт. Если размер окна для этого соединения окажется меньше 16 Кбайт, то требуемые характеристики не будут достигнуты.

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

РЕШЕНИЯ С ТОНКИМИ КЛИЕНТАМИ

На данный момент решение на базе тонких клиентов WinFrame/MetaFrame компании Citrix Systems наиболее широко используется на практике. Другие решения, такие, как сетевые вычисления на базе Web, внедряются медленно. Каждый из этих подходов предъявляет свои требования к характеристикам глобальной сети.

Citrix WinFrame/MetaFrame представляет собой сервер приложений на базе Windows NT, находящийся обычно в той же самой локальной сети, что и сервер базы данных. Сервер Citrix выполняет клиентское программное обеспечение и взаимодействует с сервером базы данных в локальной сети. Взаимодействие между удаленным клиентом и сервером Citrix организовано таким образом, что клиенту требуется передавать по глобальной сети только перемещения курсора мыши и нажатия клавиш. Таким образом, клиент не требуется оснащать логикой выполнения приложения.

Рассмотрим в качестве примера двухзвенное клиент-серверное приложение с транзакциями по типу пинг-понг. Предположим, что каждая транзакция состоит из 50 исходящих (размером в среднем 250 байт) пакетов и 50 входящих (размером в среднем 100 байт) и выполняется по каналу глобальной сети с пропускной способностью 56 Кбит/с с задержкой распространения в одном направлении 30 мс. Типичное время обновления экрана будет составлять приблизительно 5,5 с. Если то же самое приложение использует подход Citrix, время обновления экрана сократится до 0,38 с. Такое радикальное ускорение связано в первую очередь с тем, что подход Citrix устраняет обмен 50 пакетами по глобальной сети, предоставляя вместо этого простое обновление экрана.

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

Из-за того, что каждый символ возвращается в эхо-ответе сервера Citrix, задержка в сети должна быть достаточно мала. Если конечный пользователь печатает три или четыре символа в секунду, т. е. интервал между нажатиями клавиш составляет 250-350 мс, то задержка в сети в обе стороны также должна находиться в данном диапазоне. Иначе символы будут появляться на экране с опозданием. (Помните, что это чистая задержка в сети, не учитывающая влияния фонового трафика.)

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

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

Разрешение экрана, количество используемых цветов, перемещения курсора мыши и скорость печати — все это влияет на требования к пропускной способности. Так, простые нажатия клавиш и перемещения курсора мыши дают около 5 Кбит/с на пользователя. Пропускная способность может также потребоваться для совершенно неожиданных источников, таких, как мерцающий курсор. Одно из исследований работы WinFrame показало, что 50 пользователей в удаленном офисе могут породить трафик в 50 Кбит/с через глобальную сеть только в результате использования мерцающего курсора.

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

В целом, при поддержке в удаленных сетях приложений, где используется удаленное представление, таких, как WinFrame/MetaFrame, вы должны помнить о следующих трех моментах.

Во-первых, спутниковые соединения лучше не использовать. Во-вторых, частные линии имеют меньшую и более стабильную задержку, чем сети frame relay. Поэтому задержка и нагрузка в сетях frame relay требует тщательного мониторинга. Кроме того, порты и постоянные виртуальные соединения frame relay лучше приобретать с запасом. Глобальные соединения frame relay лучше вообще не использовать. Для удовлетворительного времени отклика задержка в сети в оба конца должна быть стабильно меньше 350 мс.

Наконец, для удовлетворения требований конечных пользователей к производительности применяйте методы управления трафиком frame relay. Один из методов состоит в формировании трафика и задании приоритетов. Другой — в выделении PVC под трафик для удаленного представления. Для обеспечения надлежащей производительности приложений, где используется удаленное представление, вам может потребоваться реализовать и более сложные схемы обеспечения QoS, такие, как диспетчеры пропускной способности Xedia и Packeteer.

АРХИТЕКТУРА СЕТЕВЫХ ВЫЧИСЛЕНИЙ

По функциональным возможностям NCA представляет собой комбинацию сервера приложений из трехзвенной клиент-серверной архитектуры и модели с тонкими клиентами. Классическим примером этой составной архитектуры может служить Oracle NСA. Прикладное программное обеспечение находится на серверах приложений среднего звена, взаимодействующих по локальной сети с внутренними серверами баз данных. Конечные пользователи с Java-совместимыми браузерами Web загружают апплет с центрального сервера Web в качестве пользовательского интерфейса с приложением.

Подход NCA ставит ряд вопросов в отношении параметров глобальной сети. Апплеты Java могут иметь достаточно большой размер, а передача данных объемом несколько мегабайт не является чем-то необычным. Это приводит к увеличению трафика через глобальную сеть каждый раз при появлении новой версии приложения.

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

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

Документы HTML (формы и т. д.) загружаются с использованием HTTP. В отличие от telnet и ftp, чьи параметры работы через глобальную сеть достаточно ясны, характеристики передачи данных с помощью HTTP имеют гораздо более сложную природу.

Сегодня в Internet используются две версии HTTP — HTTP 1.0 и HTTP 1.1. HTTP 1.0 весьма неэффективен в случае глобальных сетей. Он предполагает открытие отдельного соединения TCP для загрузки каждого изображения из документа HTML. Накладные расходы на установление и завершение сеансов TCP могут быть весьма значительны. Кроме того, дополнительную задержку вносит использование процедуры медленного старта TCP.

Поэтому браузеры обычно открывают несколько (как правило, четыре) параллельных сеанса TCP с серверами HTTP 1.0 для загрузки изображений. Несмотря на то что он решает вопрос задержки, такой подход порождает неравномерный трафик. HTTP 1.1 предполагает установление постоянного сеанса TCP, хотя некоторые браузеры предпочитают открывать несколько сеансов TCP, даже когда они взаимодействуют с серверами HTTP 1.1. Кроме того, пока лишь немногие серверы Web поддерживают HTTP 1.1.

ПРОЕКТИРОВАНИЕ СЕТИ

Проектирование сети с учетом поддержки разнообразных клиент-серверных приложений представляет собой сложную задачу. Трехзвенные приложения лучше подходят для глобальных сетей и обычно обеспечивают меньшее время отклика. Двухзвенные приложения порождают транзакции по типу пинг-понга, массовой передачи или их комбинации. Подходы с тонкими клиентами, такие, как WinFrame/MetaFrame от Citrix Systems и сетевые вычисления на базе Web, имеют гораздо лучшие функциональные характеристики, чем двухзвенные приложения, но ставят другие вопросы в области производительности, в том числе в отношении задержки в сети и дополнительной пропускной способности.

Рави Равашвами — главный консультант в AT&T Solutions Networking Professional Services. Он специализируется в области архитектуры, проектирования и настройки характеристик глобальных сетей. С ним можно связаться по адресу: ravir@att.com.