ГлавнаяОптимизацияRiverbed оптимизация трафика

КРОК. Riverbed оптимизация трафика


Wan оптимизация Riverbed — ZERDE Business Solutions

Wan оптимизация Riverbed

Компания Zerde Business Solutions сотрудничает с компанией Riverbed на протяжении течении 7 лет.

Мы являемся авторизованными партнёрами, в штате нашей компании 2 сертифицированных инженера RCSA (Riverbed certified solutions associate). Наша компания имеет большой опыт внедрения продукции компании Riverbed в сфере WAN оптимизации.

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

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

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

Steelhead CX — выделенный сервер оптимизации трафика, который разработан для повышения производительности приложений, используемых в удаленных офисах и датацентрах. Легко и бесшовно встраивается в существующую сетевую инфраструктуру, при этом хорошо масштабируется с увеличением количества пользователей и ростом объемов передаваемых данных. Серия продуктов Steelhead CX работает под управлением операционной системы Riverbed Optimization System (RiOS), что позволяет добиться на внешних каналах такой же производительности, как если бы пользователи работали в локальной сети.

Steelhead EX — комбинирует WAN-оптимизацию и виртуализацию. Построенные на базе технологии VMware vSphere, устройства серии Steelhead EX предлагают производительность высокого уровня благодаря использованию ОС RiOS и гибкостьплатформы Riverbed Virtual Services Platform (VSP).  Steelhead EX — это великолепное решение для консолидации серверов филиалов, с одновременным снижением затрат на ИТ.

Steelhead EX + Granite — устанавливает новый архитектурный стандарт за счет расширения виртуального периметра программно определяемых датацентров для полной консолидации и централизации. Эти устройства используют мощную комбинацию ОС Riverbed Optimization System (RiOS) для WAN-оптимизации, платформу Riverbed Virtual Services Platform (VSP) на базе гипервизора VMware vSphere, а также виртуальную серверную архитектура на базе Granite. Благодаря этой уникальной технологии, доступной только у Riverbed, отдельные устройства, которые находятся в офисах филиалов, могут консолидироваться с серверами и СХД, которые размещены в центральном датацентре. Решение Steelhead EX + Granite позволяет ИТ-департаментам внедрять более гибкую архитектуру с высокой скоростью обмена данных. Теперь данные ЦОДа доступны локальным пользователям так, как если бы они не были перемещены в ЦОД.

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

zerdebs.kz

Комплексная оптимизация Riverbed | Сети/Network world

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

Компания «Ай-Теко» представила в России решения своего американского партнера Riverbed Technologies. Центральное место в продуктовой линейке этого поставщика систем для оптимизации приложений, работающих в глобальных сетях Wide-area Data Services (WDS), занимают устройства Steelhead. Они поддерживают множество инструментов повышения производительности приложений, доступных через WAN. С помощью таких инструментов большие корпорации могут создавать рабочие места для удаленных пользователей в стиле «LAN-like», централизуя серверные и телекоммуникационные ресурсы в одной точке, снижая затраты на резервное копирование и экономя на увеличении пропускной способности каналов связи.

Востребованность такой продукции убедительно доказывает финансовый отчет Riverbed за 2006 год. По сравнению с предыдущим отчетным периодом выручка компании увеличилась на 293% и составила 90 млн долл. Разумеется, Riverbed — далеко не единственный игрок на рынке «оптимизаторов» сетевых приложений. Одну из ключевых позиций на нем занимает Cisco Systems с ее продуктовой линейкой на базе архитектуры Wide Area Application Services (WAAS). Соответствующие решения имеют также Juniper, Tacit Networks, F5, Radware и Foundry.

Однако, считает менеджер по развитию бизнеса «Ай-Теко» Максим Матросов, Riverbed заметно выделяется на фоне конкурентов. Riverbed не замыкалась на решении частных проблем, в то время как другие производители начинали с выпуска решений для оптимизации отдельных приложений, например использующих HTTP или протоколы транспортного уровня. Кроме того, многие компании развивали свои линейки за счет покупки перспективных решений сторонних производителей или поглощения разработчиков. Например, Сisco приобрела в 2004 году разработчика WAN-оптимизаторов фирму Actona, а Juniper купила Peribit и Redline вместе с их архитектурными решениями. «Развитие продуктовых линеек за счет приобретений осложняется проблемами интеграции и объединения отдельных продуктов, — отмечает Матросов. — В отличие от ее визави, Riverbed изначально ориентировалась на создание мощных комплексных продуктов со значительным функционалом».

Riverbed Steelhead скорее относятся к категории серверов, нежели к сетевым устройствам, а потому не подлежат сертификации в Мининформсвязи РФ. На аппаратной серверной части устанавливается программная платформа Riverbed Optimization System (RiOS), ядром которой являются алгоритмы блочной оптимизации Transaction Predicition (предсказания пересылки) и Scalable Data Referencing (SDR), предназначенные для оптимизации TCP-трафика. Это обеспечивает значительное увеличение скорости обмена информацией между узлами сети. «RiOS использует модель TCP-proxi, оптимизирующую потоки TCP, а не пакеты, как продукты некоторых других производителей, — подчеркивает Матросов. — Значит, весь корпоративный трафик (электронная почта, ftp, Web и т.д.) оптимизируется для прохождения через WAN-соединения, и нет необходимости приобретать отдельные решения для каждого типа приложений».

Устройства Steelhead «перехватывают» проходящие по внешнему линку TCP-соединения и выполняют с ними несколько операций. Первая нацелена на оптимизацию данных. Смысл ее заключается в том, чтобы, отвечая на запрос удаленного клиента, передавать по сети как можно меньше данных. Это возможно за счет разбиения пересылаемых данных на небольшие сегменты и их локального сохранения. При повторном запросе на передачу информации ее фактическая транспортировка не осуществляется — данные берутся из устройства Steelhead. Разбиение и анализ данных проводятся на блочном уровне, что позволяет добиться независимости от типа приложения, запрашивающего файл.

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

Третий компонент технологии RiOS отвечает за оптимизацию приложений. Устройства Steelhead минимизируют количество служебного трафика, генерируемого приложениями. Анализируя поведение известных приложений (например, файловой системы Windows), Steelhead исключает из обмена многократно повторяющиеся служебные команды и осуществляет упреждающую передачу данных на основе алгоритма предсказания запросов.

За счет объединения трех подсистем в одном продукте запросы могут выполняться сервером еще до их формирования клиентом. А данные, которые чаще всего пересылаются по сети, уже присутствуют в устройстве Steelhead на стороне клиента — в связи с предшествующей активностью приложений.

Riverbed предлагает модельный ряд, состоящий из семи устройств Steelhead. Самая младшая модель, Steelhead 100, имеет 35 Гбайт дискового пространства и ограничение скорости WAN-интерфейса 1 Мбит/с. Старшая модель, Steelhead 5010, располагает 512 Гбайт дисковой памяти и ограничена скоростью WAN-интерфейса 45 Мбит/с. Каждое устройство Steelhead оснащено двухпортовым адаптером Ethernet со встроенным электромеханическим реле, которое формирует прямое проводное соединение в случае выключения питания или проблем с программным обеспечением. В этих случаях данные начинают передаваться по WAN-соединению в обычном, неоптимизированном режиме.

Устройства Steelhead устанавливают в удаленных и центральных офисах, включая их непосредственно в WAN-линки. «Ай-Теко» уже выполнила несколько заказов на установку систем Riverbed в России, в том числе для предприятия ФГУП «Морсвязьспутник», Министерства по налогам и сборам Республики Северная Осетия-Алания, бывшего представительства Lucent в России. Несколько других проектов находятся на этапе тестирования.

www.osp.ru

Оптимизация трафика приложений в публичных облачных инфраструктурах на Riverbed SteelHead for Cloud/SaaS

Дата: 02 августа, вторник

Время: 11.00 - 12.30 GMT+3

Спикер: Богдан Сиротенко, Sales Engineer, BAKOTECH Group

Кому будет интересен вебинар: техническим специалистам и ИТ-менеджерам

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

О чем будет идти речь:

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

Участие бесплатное, предварительная регистрация обязательна.

cis.bakotech.com

Оптимизация каналов связи для добычи полезных ископаемых на севере России / Блог компании КРОК / Хабр

Когда мы ехали на монтаж, рядом доставали трактор из оврага

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

Связь там сделана через спутник. Соответственно, требования по каналу растут, но расширяться очень больно и дорого — спутниковый ресурс не самый масштабируемый, и гигабайты через него гонять не получится.

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

Вводная
Есть канал на спутнике, и расширять его дорого. Есть решения Riverbed, которые позволяют сжимать трафик, оптимизировать обмен на уровне протокола (чтобы не передавались избыточные данные), плюс кэшировать куски словаря сжатия на себе. Всё это в целом может дать от 20% до 80% выигрыша по полосе в зависимости от того, что за данные и как летают.

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

Обследование
Архитектура обмена — несколько «колёс со спицами» с хабами в крупных городах. Например, в Иркутске, Магадане и Москве. На хабы подходит оптика или медь. На удалённых точках на добывающих предприятиях в 90% случаев используется станция спутниковой связи, есть буквально пара радиорелейных линий и ещё на нескольких точках оптикой делятся те, кто так или иначе тащил её мимо ради магистрали.

Поставили систему диагностики, собирающую данные.

Приложений много, а пользователей мало, основной обмен — технический. Вот пример того, что может работать на одном из предприятий где-то далеко-далеко за снегами:

Распознанное приложение Интерпретация наблюдаемого трафика
Microsoft-DS Active Directory Обмен файлами средствами операционной системы Windows (SMB Direct).
Microsoft Terminal Server (RDP) Удаленный рабочий стол
HTTPS Outlook Web Access
SMTP Пересылка почты между серверами Exchange
MS SQL Обращения к MS SQL серверу
netview-aix-2 Клиентское подключение 1С
domain Служба доменных имен (DNS)
webcache Доступ в Интернет через прокси-сервер
Всё это, в целом, хорошо сжимается, за исключением DNS и доступа в Интернет. Ещё есть Lync, VoIP и видеоконференцсвязь, которая в силу особенностей не сжимается, зато требует приоритета №1 — особенно, когда главу объекта вызывают на ВКС-совещание.

По большей части обыденный трафик — это передача файлов, real time трафик, так же есть данные контроля добычи, учёта и сырые данные с датчиков. Многие приложения, которые отправляют информацию, «болтливые», то есть отправляют много пакетов там, где можно было бы обойтись одним. Соответственно, такие вещи решаются Riverbed достаточно просто.

Вот, сравните как работают приложения до и после оптимизации:

Например известный всем «болтливый» протокол CIFS, который используется для доступа к файлам. Файл размером 20-40 Мбайт в локальной сети будет загружен за считанные секунды. Если же загрузка файла осуществляется из удаленного офиса по WAN каналу связи, как показано на схеме выше, время загрузки может быть увеличено до 5 и более минут.

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

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

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

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

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

Оптимизатор — самый низ

В итоге была отработана такая схема:

Опять же, романтика Севера — один ЦОД доехал до места на салазках, хорошо хоть не собаками. ЦОД на салазках, да-да.
Продолжение
Итак, мы увидели какой трафик ходит и в каких объемах. С какими задержками, что бизнес-критично, что нет. Что для компании важно разметили, что можно «зарезать» — «зарезали», если в полосе был важный трафик. Выделили 4 класса обслуживания для разных типов информации, согласовали их с операторами связи. Собственно, мы этот трафик «раскрашивали» — а у оператора связи на месте делался шейпинг. Была ещё особенность в том, что на каждом объекте свой оператор связи: где-то нужно было заплатить дополнительно за услугу, где-то просто не было технической возможности шейпить правильно, приходилось укладываться в меньшее количество классов обслуживания и придумывать разные хаки.

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

Пример проведения диагностики у заказчика:

Видим на каком хопе потерялся пакет на пути от сервера к клиенту

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

Какое железо?

Устанавливались разные модели оптимизаторов начиная от младших, заканчивая старшими — в зависимости от ширины канала связи и количества пользователей и информационных ресурсов на площадке. Подробнее про решения Riverbed я писал здесь и вот здесь в теории.

Какая итоговая экономия трафика?
Вот пример с одной из точек:

Total optimization здесь равен 57,05 за неделю для оптимизированного трафика на одном из крупных узлов.

Собственно, вот такая история. Если интересны детали конкретно по вашему проекту — могу примерно посчитать по почте [email protected]. Ну и готов ответить на любые вопросы здесь или в почте.

habr.com

Оптимизация трафика приложений в публичных облачных инфраструктурах на Riverbed SteelHead for Cloud/SaaS

Дата: 02 августа, вторник

Время: 11.00 - 12.30 GMT+3

Спикер: Богдан Сиротенко, Sales Engineer, BAKOTECH Group

Кому будет интересен вебинар: техническим специалистам и ИТ-менеджерам

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

О чем будет идти речь:

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

Участие бесплатное, предварительная регистрация обязательна.

ПОДЕЛИСЬ С ДРУЗЬЯМИ В СОЦ. СЕТЯХ:

bakotech.ua

ищем причины скачков трафика и нагрузки / Блог компании КРОК / Хабр

Предположим, у нас есть вот такая картина загрузки канала связи:

Что вызвало всплеск трафика? Что происходило в канале связи?

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

Если админ не совсем криворукий, а ситуация не очень хитрая, то минут за 10 можно будет выделить конкретные причины, создающие проблемы, и ещё минут за 15–20 проанализировать проблему. Если же ситуация сложнее (мы рассмотрим ещё пример ниже), то искать аномалии в поведении трафика можно сутками. С инструментарием обнаружения таких аномалий у нас на поиск проблемы в этом примере уйдёт 1 минута.

Вот простой пример. Был всплеск трафика в канале связи, из-за чего возникли тормоза работы приложений у юзеров.

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

Ага, понятно… CIFS — 92% от общего объёма трафика.

Выясняем, кто там работал (какие хосты и пользователи).

Первая пара клиент — сервер загрузила канал связи на 99% по CIFS.

Если у нас есть интеграция системы диагностики с Active Directory, мы можем выяснить, кто это. Пробуем.

У нас это некий Джон Смит. У проблемы появилась фамилия. И всё это за 1 минуту.

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

Теперь посмотрим пример посложнее, когда тормозит целая ERP-система.

Итак, есть вот такая картина:

ERP тормозит, пользователи жалуются. Почему? Куда смотреть? Где смотреть?

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

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

Пример для конкретного ЦОДа: установлены все три модуля. Shark Sensor принимает зеркалированные данные с коммутатора серверной фермы, Virtual Shark анализирует взаимодействия между виртуальными машинами — Gateway принимает flow с маршрутизаторов и оптимизаторов. Потом вся статистика идёт на профайлер. Pilot работает с копией трафика, хранящегося на Shark Sensor

Задумчивый сервер
Возвращаемся к ERP с проблемой.

Начинаем разбираться в том, что произошло на сегменте между конечными пользователями и Web-серверами, почему система просигнализировала об этом.

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

Зелёная черта внизу графика — нормальный профиль работы сервера. Такой должен быть при стабильной работе сервера.

На графике реальные значения времени отклика сервера показаны синим цветом. Прокручиваем отчёт ниже.

Смотрим на взаимодействие клиентов и серверов. Видно, что у всех клиентов есть проблемы в той или иной степени. При этом из кластера серверов проблема только у одного сервера.

Рассмотрим статистику проблемного сервера.

Видим MAC-адрес сервера, IP-адрес коммутатора и порт коммутатора, куда подключён сервер. Рассмотрим транзакции проблемного сервера в графической оболочке к Wireshark — Pilot Console. На отчёте времени отклика сервера по объектам видно, что увеличено время предоставления лишь одного объекта.

Вот он, попался: complex.psp

Проверяем. Строим диаграмму взаимодействия по транзакциям. Проверяем:

Да, это оно.

Если кто ещё не верит, пусть проверит — переходим к ручному пакетному анализу в Wireshark той же транзакции.

Итак, мы только что получили исчерпывающую картину взаимодействия пользователей с Web-серверами сервиса ERP, что позволило найти сбойный Web-сервер, а даже точнее, сбойный объект на сервере.

Локализация проблем с многоуровневыми приложениями

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

Совместимость с оптимизаторами трафика

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

Вот эти показатели оптимизации трафика собраны как раз Riverbed Cascade:

Соотношение LAN-трафика (синий график) и WAN-трафика (зелёный график) с оптимизацией. Наглядно видно, насколько уменьшился объём трафика в канале связи

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

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

Можно искать проблемы как в историческом разрезе, так и в реальном времени по факту их появления (и вот здесь вы будете чертовски рады тому, что есть такой мощный помощник).

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

Здесь же Riverbed Cascade обходит всех конкурентов: он снимает десятки метрик и строит профили нормального поведения каждой метрики. Пороговые значения ставить не надо, система соберёт историческую статистику, и на её основе будут сформированы пороговые значения. А при отклонении от нормы система проинформирует администратора или его руководителя.

Кроме аналитики производительности приложений в систему заложен функционал аналитики безопасности. А именно: система предупредит администратора в том случае, если:

И даже если установленные антивирусные системы не видят распространение нового вируса в сети, Riverbed Cascade обнаружит распространение «червя» по появившемуся аномальному трафику.
Вопросы
Мы реализовали это решение (в комплекте с оптимизацией трафика) для золотодобывающей компании, для территориально распределённого банка, логистической компании, закончили проект для энергетической компании и ещё десятки проектов поменьше. Такая штука нужна в каждом ЦОДе, как мне кажется. В общем, если есть вопросы — задавайте на [email protected] либо в комментариях. Цены под вашу инфраструктуру могу тоже назвать в почте.

habr.com

Оптимизация трафика в частных облачных дата-центрах на Riverbed SteelHead

Дата: 21 июля

Время: 11:00-12:30 GMT+3

Спикер: Богдан Сиротенко, Sales Engineer BAKOTECH Group

Кому будет интересен вебинар: техническим специалистам и ИТ-менеджерам

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

О чем будет идти речь:

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

Участие бесплатное, предварительная регистрация обязательна.

ПОДЕЛИСЬ С ДРУЗЬЯМИ В СОЦ. СЕТЯХ:

bakotech.ua

Prostoy-Site | Все права защищены © 2018 | Карта сайта