ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
«юзин ¬ладислав
«юзин ¬ладислав
ћакаров јнтон
ћакаров јнтон

10 минут чтени€

¬ обычной корпоративной сети доступ к серверам из филиалов организации может осуществл€тьс€, чаще всего, подключением к серверам, расположенным в центральном офисе. Ќо при расположении серверной инфраструктуры в облаке параметры св€зи рабочих станций с серверами будут зависеть уже не от канала св€зи от каждого конкретного филиала до центрального офиса, а от канала св€зи всех отделений организации с ÷ќƒ облачного провайдера, чьими услугами пользуетс€ организаци€ дл€ формировани€ облачной инфраструктуры.

ѕереход в облака поставил перед разработчиками ѕќ и сетевыми инженерами р€д новых условий, вызывающих задержку сигнала, которые им приходитс€ учитывать дл€ формировани€ качественного доступа к данным в облаке. Ќапример, задержка длительностью 500мс приводит к снижению трафика Google на 20%, а задержка в 100мс сокращает продажи Amazon на 1%.

¬рем€ задержки может быть очень важным аспектом во врем€ работы с виртуальными рабочими столами (VDI), потоковым вещанием, трейдингом, передовыми web-сервисами, базами данных, терминальными приложени€ми. Ќо задержка не столь критична дл€ таких сервисов как электронна€ почта или работа с документами.


QoS и SLA

—уществует проблема обеспечени€ необходимого качества обслуживани€ (QoS). –азные виды трафика имеют различные требовани€ к рабочим характеристикам сети. „увствительность видов трафика была вз€та из и показана в таблице 1

“аблица 1. „увствительность различных приложений сетевым характеристикам

“ип трафика ”ровень чувствительности к сетевым характеристикам
ѕолоса пропускани€ ѕотери «адержка ƒжиттер
√олос ќчень низкий —редний ¬ысокий ¬ысокий
Ёлектронна€ коммерци€ Ќизкий ¬ысокий ¬ысокий Ќизкий
“ранзакции Ќизкий ¬ысокий ¬ысокий Ќизкий
Ёлектронна€ почта Ќизкий ¬ысокий Ќизкий Ќизкий
Telnet Ќизкий ¬ысокий —редний Ќизкий
ѕоиск в сети "от случа€ к случаю" Ќизкий —редний —редний Ќизкий
ѕосто€нный поиск в сети —редний ¬ысокий ¬ысокий Ќизкий
ѕересылка файлов ¬ысокий —редний Ќизкий Ќизкий
¬идеоконференци€ ¬ысокий —редний ¬ысокий ¬ысокий
ћультикастинг ¬ысокий ¬ысокий ¬ысокий ¬ысокий

–екомендации ћ—Ё-“ по обеспечению QoS дл€ сетей описываютс€ в рекомендаци€х Y.1540 - стандартные сетевые характеристики дл€ передачи пакетов в сет€х IP, и Y.1541 нормы дл€ параметров, определенных в Y.1540.

ƒанные рекомендации важны дл€ всех участников сети: провайдеров и операторов, пользователей и производителей оборудовани€. ѕри создании оборудовани€, планировании развертывани€ и оценке сетей IP, оценка качества функционировани€ сети все будут опиратьс€ на соответствие характеристик требовани€м потребителей.

ќсновные характеристики, рассматриваемые в рекомендации Y.1540:

  • производительность сети;
  • надежность сети/сетевых элементов;
  • задержка;
  • вариаци€ задержки (jitter);
  • потери пакетов.

ѕодробнее о данных характеристиках следует прочитать в вышеназванных рекомендаци€х. ¬ таблице 2 указаны нормы на определенными в Y.1540 характеристики и распределены по классам качества обслуживани€ (QoS).

“аблица 2 - Ќормы дл€ характеристик сетей IP с распределением по классам QoS

—етевые характеристики  лассы QoS
0 1 2 3 4 5
«адержка доставки пакета IP, IPTD 100 мс 400 мс 100 мс 400 мс 1 с Ќ
¬ариаци€ задержки пакета IP, IPDV 50 мс 50 мс Ќ Ќ Ќ Ќ
 оэффициент потери пакетов IP, IPLR 1х10 3 1х10 3 1х10 3 1х10 3 1х10 3 Ќ
 оэффициент ошибок пакетов IP, IPER 1х10 4 1х10 4 1х10 4 1х10 4 1х10 4 Ќ

ѕримечание: Ќ не нормировано. –екомендаци€ Y.1541 устанавливает соответствие между классами QoS и приложени€ми:

  •  ласс 0 приложени€ реального времени, чувствительные к джиттеру, характеризуемые высоким уровнем интерактивности (VoIP, видеоконференции);
  •  ласс 1 приложени€ реального времени, чувствительные к джиттеру, интерактивные (VoIP, видеоконференции);
  •  ласс 2 транзакции данных, характеризуемые высоким уровнем интерактивности (например, сигнализаци€);
  •  ласс 3 транзакции данных, интерактивные;
  •  ласс 4 приложени€, допускающие низкий уровень потерь (короткие транзакции, массивы данных, потоковое видео)
  •  ласс 5 традиционные применени€ сетей IP.

“аким образом некоторые из облачных сервисов вполне могут попадать в классы 0 и 1, а значит следует учитывать врем€ задержки и старатьс€ сделать так, чтобы она не превышала 100 мс.


«адержки в сет€х

ѕодключение к облаку через VPN аналогично подключению к центральному офису организации по VPN, за исключением лишь того, что если в обычной корпоративной сети все филиалы организации подключались к центральному офису, то теперь подключение филиалов и центрального офиса в том числе будет осуществл€тьс€ к ÷ќƒ облачного провайдера.

ƒл€ проверки задержки в большинстве ќ— используетс€ команда ping, а дл€ проверки пути прохождени€ пакета команда tracert, которые подробнее рассмотрим ниже.

ѕредположим, что домашн€€ сеть €вл€етс€ подобием корпоративной сети малого предпри€ти€. ¬ таблице в приложении ј собраны данные из статьи с указанием расположени€ ÷ќƒ.

¬оспользуемс€ этими данными чтобы проверить задержку сигнала от текущей домашней сети, расположенной в городе ћосква, без учета VPN, до web-сервера некоторых компаний, владеющих, ÷ќƒ, расположенных в разных городах, тем самым провер€€ разницу в задержке в зависимости от расположени€ ÷ќƒ облачного провайдера.

ƒл€ проверки задержки воспользуемс€ " омандной строкой" Windows и командами ping и tracert.  оманда ping используетс€ дл€ проверки целостности и качества соединени€ в сети на основе протоколов TCP/IP.  оманда tracert строит маршрут через коммутационные узлы между компьютером и конечным сервером и выводит их IP-адреса и врем€

задержки. Ќа рисунках 1 и 2 представлена системна€ справка по командам, соответственно, tracert и ping.

—истемна€ справка по команде tracert —истемна€ справка по команде ping

ѕроведем тест проверки задержки до домена DataLine dtln.ru, расположенного ближе всего к домашней сети (рисунки 3 и 4).

Ping до сайта dtln.ru Tracert до сайта dtln.ru

 ак видно из результатов на рисунке 5.3, было передано и получено 4 пакета объемом 32 байта. ¬рем€ обмена одним пакетом составило 1 миллисекунду.

 оманда tracert вывела следующие данные:

  • 1, 2, 3 - номер перехода;
  • <1 мс <1 мс <1 мс врем€ ответа дл€ 3-х попыток (в данном случае все попытки менее 1 мс);
  • 185.3.141.232 IP-адреса (в данном случае IP-адрес домена

dtln.ru)

—огласно проверке данного IP на сайте 2ip.ru, данный домен базируетс€ по тому же адресу на карте, что и указано в таблице в приложении Ѕ. “аким образом можно сделать вывод, что web-сервер большинства компаний из списка веро€тнее всего находитс€ на территории одного из их ÷ќƒ, но даже если и нет, то позвол€ет сделать выводы о доступности ресурса.

јналогично проверим ping дл€ остальных компаний, результаты представим на рисунке 5.5. ¬ качестве опорного времени задержки будет использовано среднее и максимальное врем€ приема-передачи.

¬рем€ задержки сети до web-сайтов компаний

»з данных рисунка 5 можно сделать вывод, что среднее значение времени задержки в пределах ћосквы из сети, также наход€щейс€ в пределах ћосквы, чаще всего не превышает 10мс.

ћожно сравнить данные значени€ с ping до серверов Amazon Web Services в разных регионах с сайта cloudping.info (рисунок 6).

Ping серверов Amazon Web Services в разных регионах

VPN без шифровани€ теоретически позволил бы сократить эту задержку в св€зи с использованием "пр€мого туннел€" между "офисом" и ÷ќƒ. Ўифрование будет вносить уже свою задержку, проверить которую в данных услови€х нет возможности.

¬ локальных сет€х корпоративной сети и сети ÷ќƒ задержка исчисл€етс€ в микросекундах. ¬ сети ÷ќƒ предъ€вл€ютс€ высокие требовани€ к быстродействию сети, современные решени€ Ethernet дл€ ÷ќƒ должны быть широкополосными и поддерживать скорости 10, 25, 40, 50, 100 √бит/с, обеспечивать низкие задержки до 1-2 мкс дл€ св€зи серверов (через три коммутатора), и многие другие.


—корость интернет-канала

ѕередача видео через сети св€зи, будь то видео с камер наблюдени€ или же видеоконференции, €вл€ютс€ одними из самых требовательных с скорости передачи данных. ≈сли дл€ работы с документами может быт достаточно скорости в 100  бит/с, то дл€ передачи видео понадобитс€ уже примерно 2 ћбит/с.

ƒл€ некоторых приложений, таких как IP-телефони€, желательно, чтобы уровень задержек был низким, а мгновенна€ пропускна€ способность канала была больше определенного порогового значени€: не ниже 24  бит/с дл€ р€да приложений IP-телефонии, не ниже 256  бит/с дл€ приложений, обрабатывающих видеопоток в реальном времени. ƒл€ некоторых приложений задержки не так критичны, но, с другой стороны, желательна высока€ пропускна€ способность, например, дл€ передачи файлов.

Ќапример, компани€ Ivideon предлагает услуги облачного видеонаблюдени€, и у них на сайте даютс€ следующие требовани€ к интернет-каналу дл€ разного качества видеопотока. ƒанные представлены в таблице 3.

“аблица 3 “ребовани€ к интернет-каналу дл€ одной камеры видеонаблюдени€ при разных разрешени€ при частоте 25 кадров/сек

–азрешение \  ачество изображени€ –екомендуема€ скорость
1280х720 (1Mpx) /25к/с 1 ћбит/с
1920x1080 (2Mpx) /25к/с 2 ћбит/с
2048x1536 (3Mpx) /25к/с 2 ћбит/с
2592x1728 (4Mpx) /25к/с 2 ћбит/с

Ќо дл€ работы с терминальными сесси€ми достаточно канала в 128-256  бит/с на пользовател€. ƒл€ 50 пользователей понадобитс€ 6.25 ћбит/с.

 омпани€ 1cloud.ru при выборе ширины канала св€зи предлагает скорость соединени€ в диапазоне от 10 до 100 ћбит/с дл€ доступа к виртуальному серверу.

¬нутри облака сетевые соединени€ между виртуальными машинами имеют пропускную способность в 1 √бит/с.


RDP-сесси€

ƒл€ теста потреблени€ трафика при использовании удаленного подключени€ RDP был проведен эксперимент.

ƒва персональных компьютера наход€тс€ в одной локальной сети и подключены к интернету. ќдин выступает сервером удаленного доступа, второй подключаетс€ к нему посредством встроенной в Windows программы

"ѕодключение к удаленному рабочему столу" по протоколу RDP. Ќа сервере запускаетс€ видео в интернете. ƒл€ захвата трафика и анализа используетс€ ѕќ Wireshark

ѕараметры подключени€:

  • размер удаленного рабочего стола 1920х1080
  • глубина цвета 15 бит
  • выбранна€ скорость соединени€ 56  бит/с
  • дополнительные возможности отключены (рисунок 7)
ѕараметры взаимодействи€ с удаленным сервером

Wireshark программа дл€ захвата и анализа сетевого трафика. ƒанна€ программа работает с подавл€ющим большинством известных протоколов, имеет пон€тный и логичный графический интерфейс, и мощнейшую систему фильтров.

¬о врем€ подключени€ к удаленному рабочему столу программа замер€ла отправленные и поступившие пакеты данных. Ёти пакеты были отфильтрованы по IP-адресу сервера, а также по протоколу RDP. »нтерфейс программы представлен на рисунке 8.

»нтерфейс программы Wireshark

√рафик ввода/вывода данных по IP-адресу сервера по протоколу RDP представлен на рисунке 9.

√рафик ввода/вывода данных по протоколу RDP

Ќа графике на рисунке 9 видно два "всплеска" данных, т.е. две сессии подключени€ к серверу. ¬о врем€ первой сессии проводилась работа с т€желовесным графическим приложением. ¬о врем€ второй сессии было включено видео, затем производилс€ web-серфинг в браузере машины с некоторыми графическими материалами на странице.

 ак видно по графику, в пиковый момент была передача данных 5.5 ћбит/с. ¬ последние моменты web-серфинга 0,65 ћбит/с.

“аким образом можем сделать вывод, что протокол RDP не укладываетс€ в ранее за€вленный диапазон до 128  бит/с. ќднако стоит учитывать, что RDP-сесси€ изначально очень требовательна к сети и €вл€етс€, по сути, передачей видеотрафика.

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

Ќаиболее подход€щей темой дл€ дискуссий на тему вли€ни€ облачной инфраструктуры на сеть могут служить только качество обслуживани€ (QoS) и договор о предоставлении услуг SLA, но данные темы слишком обширны и требует более углубленного внимани€, а вопросы, св€занные с ними, требуют внимани€ соответствующих специалистов.