Pull to refresh
20
0
Андрей Врублевский @AVrublev

Пользователь

Send message
Действительно, репликация – это один из самых показательных случаев. Действительно, за счет подкрутки TCP на серверах можно добиться лучшей утилизации канала. Если репликация происходит между несколькими серверами придется настраивать каждый сервер. Ставя оптимизаторы, вы настраиваете все на одной железке. Также нужно настроить QoS таким образом, чтобы репликации не вытесняли другой трафик. В случае использования оптимизаторов конкуренция за полосу будет равной для всего трафика, но можно настроить полнофункциональный QoS на riverbed.

Судя по RTT в 200 мс, рассматриваемый канал достаточно протяженный (не собственность организации), а полоса пропускания огромная. Наверняка, аренда у него немаленькая. Трафик репликации жмется очень сильно. Если происходит полный backup то со второй прокачки к-т сжатия будет порядка 90%. Это означает, что можно арендовать уже не 10Gbps, а 1 Gpbs. Какая экономия за год? За три года? Плюс к этому на оптимизаторах можно настроить QoS по времени. Например, днем – репликации занимают 10%, ночью – 90%.

Репликация и/или уменьшения загрузки каналов связи — хорошее применение, но основная задача оптимизаторов – это ускорение работы сетевых приложений, эффект который заметен пользователям и непосредственно влияет на их эффективность. Ускорение сетевых приложений главным образом происходит за счет адаптации TCP под канал связи и проксирования ряда основных протоколов. При этом, как правильно замечено, устраняется болтливость приложений.

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

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

Второй случай. Оптический канал связи Москва — Хабаровск. Каждое соединение репликации между ЦОД проходит на скоростях менее 700 Кбит/c, а полоса пропускания канала 1 Гбит/c! Вопрос — за что платит организация?! За полосу которая недоступна. С оптимизаторами скорость соединений репликации возросла до 35 Мбит/c. Т.е. в 50 раз! Репликации проходят в 50 раз быстрее.
Отчасти вы правы, но давайте фантазировать. Для вашего примера – один удалённый офис с одним компьютером – нет смысла разворачивать такое решение. Я согласен.

Если у вас офисов больше чем один, и все они маленькие (с 1 компьютером), то для этого решения мы предложим поставить в центр аппаратное решение, а для филиалов софтверный клиент устанавливаемый прямо на рабочее место. Это решение гораздо дешевле. И в тоже время позволит поднять эффективность работы приложений и пользователя.

Если же у вас в офисе количество сотрудников приближается к 10 на точку – то в этом случае мы уже рекомендуем использовать минимальную аппаратную модель оптимизатора.

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

Кстати отличный пример – почти все глобальные корпорации, которые приходят в Россию, используют это оборудование для связи со своей штаб-квартирой или ЦОДом в Европе или Америке. Хотя не такая уж большая задержка между Москвой и Европой например.
Стоит. Срок окупаемости решений варьируется от 6 до 24 месяцев. В зависимости от того какие статьи доходности используются при расчете обоснования. Кроме того для маленьких каналов используется советующие достаточно маломощные модели оборудования, никто из пушки по воробьям не стреляет. И, наоборот, для репликации данных между ЦОДами на разных концах нашей страны или мира, надо использовать уже высокопроизводительное оборудование.
2

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity