Автор: Тарас Юшков. Рубрики: Сети и телекоммуникации. Опубликовано: Июнь 22nd, 2009

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

В поисках интерактивности

Современные тенденции в развитии бизнеса, такие как консолидация и централизация ИТ не остались незамеченными предприятиями SMB (конечно, не совсем малых, а той самой средней прослойки, которая стремится стать покрупнее) . Преимущества сосредоточения информационных ресурсов в консолидированных ЦОД и внедрения корпоративных приложений очевидны: такой инфраструктурой легко управлять, проще обеспечить сохранность данных, дешевле обходится эксплуатация. Именно поэтому большинство компаний стремится использовать такую схему построения своей ИС. Между тем, централизованная инфраструктура подразумевает существенное повышение требований по обеспечению надежности ее элементов, информационной безопасности, а также — производительности распределенных сетей (WAN).

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

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

Вариант второй — расширить канальную инфраструктуру предприятия, модернизировать сеть для обеспечения ее работы на более высоких скоростях. Он потребует пересмотра отношений с операторами связи, повлечет за собой переход на более высокоскоростные тарифы и новые классы услуг, а также (почти на 100%) чреват необходимостью замены оборудования. Небольшие фирмы могут и вовсе отказаться от перехода на централизованную инфраструктуру из-за опасений «утонуть» в расходах на услуги связи и каналы передачи данных.

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

Что подлежит оптимизации?

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

Все механизмы оптимизации приложений используют сегментацию сессии, разбивая ее между клиентом и сервером на три сегмента (см. рис.2): периферийную— между устройством оптимизации и рабочей станцией, между устройствами —поверх сети WAN и между устройством оптимизации и ЦОД (сервером). В первом и третьем сегментах сессия работает поверх ЛВС и недоработки протокола TCP не влияют на задержку приложений. Второй сегмент оптимизируется средствами регулировки скорости работы TCP. В результате обеспечиваются необходимые минимумы: по задержке при передаче трафика через WAN и по времени отклика приложений.

Механизмы TCP–оптимизации работаютна транспортном уровне. Транспортный протокол TCP — основа функционирования бизнес-приложений в сетях IP. Разработанный в 1980 г., он и сегодня не претерпел серьезных изменений, тогда как технологии передачи данных серьезно изменились. Решение оптимизации функционирования сетевых приложений увеличивает в первую очередь скорость передачи информации. Дело в том, что при потере пакетов стандартный TCP-протокол резко снижает скорость – практически вдвое, и ее увеличение от этого уровня в дальнейшем происходит линейно и небольшими шагами. Поэтому, даже сравнительно небольшой уровень потери пакетов (2-3% потерь считается нормальным), приводит к частым и резким потерям скорости работы сети. Оптимизированный протокол TCP при возникновении потери снижает скорость не в 2 раза, а всего на несколько процентов, а при одиночной потере пакетов скорость снижается совсем незначительно. Но если потери носят системный характер, то скорость исполнения сессии снижается на действительно необходимую для восстановления пакетов величину.

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

Механизмы компрессии способны намного ускорить передачу данных. Чаще всего, данные, передаваемые по сети, представлены в неоптимальном формате и имеют неоправданно большой объем. Еще лет 5-10 назад разработчики приложений беспокоились о представлении данных и тщательно продумывали каждый бит передаваемой информации. Сейчас, при активном использовании в разработке приложений, например, языка XML или других языков представления информации в текстовой форме, нет нужды заботиться о представлении данных. Конечно, это повышает скорость и простоту самой разработки, но одновременно приводит к тому, что по сети передаются, по сути, неструктурированные данные, внося в трафик большие объемы избыточной информации — ведь данные фактически представляются уже не в бинарных форматах, а в текстовых!

Компрессия трафика позволяет нивелировать этот недостаток. Устройства оптимизации приложений используют алгоритм сжатия данных без потерь (например, Лемпеля–Зива) и алгоритм исключения повторяющихся блоков . Комбинация этих двух алгоритмов позволяет достичь наивысшей степени сжатия информации без потерь, обеспечивая тем самым быструю передачу информации по сравнительно низкоскоростным каналам.

Механизмы оптимизации функционирования бизнес-приложений тоже подвластны  решению по оптимизации. Причем они способны улучшить работу приложений таких брендов, как SAP и Microsoft. Эксперты утверждают, что от 70 до 90% компаний среднего и малого бизнеса используют программные решения Microsoft. А между тем реализация некоторых протоколов в этих продуктах, к сожалению, далека от совершенства. В частности, протокол CIFS (Common Internet File System), активно использующийся в сетях Microsoft, создает избыточный объем служебных сообщений (подтверждение доставки, готовность устройств и т.п.). В локальной сети эти излишки не вносят существенной задержки во время отклика, но в распределенной сети становятся значимыми. Устройства оптимизации умеют обрабатывать большую часть малозначимых сообщений локально, без передачи через WAN, уменьшая объем трафика и сокращая время отклика ряда функций сетевых приложений, таких как сетевая печать, доступ к файловым сервисам, и т.п.

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

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

Дополнительные «бонусы»

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

Налицо и сохранение инвестиций. Имеющуюся инфраструктуру не нужно «рушить», ее можно с успехом использовать. Нужно только реализовать ее грамотную модернизацию.

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

wx2

Рис.1. Архитектура решения для оптимизации функционирования сетевых приложений.

wx1

Рис.2. Архитектура, обеспечивающая заполнение всей полосы канала передачи данных.

Выбор есть

Решение по оптимизации приложений компании Cisco Systems  — Wide Area Application Services (WAAS) — базируется на на устройствах Wide Area Application Engine (WAAE) и модулях для маршрутизаторов ISR 2800/3800, что позволяет реализовать оптимизацию путем добавления модуля в работающее на сети оборудование.

Решение Juniper тоже использует группу  специальных устройств серии WX™. Его особенность — возможность стекирования (логического объединения) нескольких устройств оптимизации, повышая производительность процесса в целом.

Одним из старейший игроков на рынке данных решения является компания RiverBed. Эти парни лидеры в смысле оптимизации протоколов выского уровня.

Поделиться

Опубликовать в Facebook
Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс

Мы в социальных сетях

Читать ProITClub в TwitterЧитать ProITClub в RSSЧитать ProITClub в п&##1086;чтовой подпискеЧитать ProITClub в Живом ЖурналеЧитать ProITClub в LinkedInЧитать ProITClub в LinkedIn
Вы можете оставить комментарий, или поставить трэкбек со своего сайта.

Есть 5 коммент. к “Оптимизация приложений”

  1. Роман Морнев:

    Если взять этих трех игроков, которых ты упомянул в статье. Я правильно понимаю, что Riverbed и Juniper используют более современные, продвинутые решения в части использования кэша, в то время как Cisco достаточно серьезно отстает по производительности?

    • Тарас Юшков:

      Не совсем. Так как алгоритмы кэширования и компрессии закрыты, то каждый производитель визжит как может, что у них все самое новое и продвинутое. Поэтому полагаться я на их заявления мягко говоря не стал. Испытания проводимые несколько месяцев назад одним моим знакомым показали преимущества Ривербеда, потом Сisco, потом Juniper. С точки зрения функционала, я бы выделили Cisco и Ривербед, над Juniper.
      Нагрузочное тестирование вообще отдельный вопрос. Сейчас тестируем у одного заказчика всех троих как раз под нагрузкой способной разорвать железо — посмотрим на результат.

  2. Роман Морнев:

    Я наверное не совсем правильно спросил. Насколько я понимаю у Cisco на каждую сессию отдельный сегмент в кэше выделяется, а у River и Jun единое кэш-поле на все соединения. В очередной раз жалею, что не знаю как тут вставить картинку, что бы показать что я имею ввиду.
    У меня есть результаты тестирования Cisco vs Riverbed (сделанные нами, не вендорами). River выигрывает за явным преимуществом.

  3. Тарас Юшков:

    Я тебя понял. Отличие в реализации функции кэширования именно такие, как ты сказал. Другой вопрос в их продвинутости и эффективности. Здесь, нет однозначного ответа, и это больше вопрос подачи информации клиенту. Способ кэширования от Cisco просто другой. Что касается тестирования, то тенденция «на лицо» Ривербед побеждает, но вполне возможно не из-за кеширования, а по совокупности приемуществ.

  4. Владимир Мешалкин:

    Тарас, а корректно еще упомянуть об одном устройстве — Citrix NetScaler?

Написать комментарий

Вы должны войти чтобы добавить сообщение.