ЦОД. Часть 2

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

В данном контексте, под смежными системами мы будем понимать пользователей.

Итак, перемещение серверов из филиалов организации, имеющей территориально распределенную структуру, в ЦОД «облегчает» во многих смыслах информационную инфраструктуру филиалов, но, конечно же, не бесплатно – сеть WAN становится критически важным элементом. Во-первых, её отказ приводит к невозможности получить доступ к вспомогательным службам и приложениям в ЦОД. Во-вторых, из-за несоответствия пропускной способности «узких» каналов WAN и пропускной способности LAN в ЦОД в пограничном устройстве, находящемся между WAN и LAN, образуется очередь пакетов, которая уже сама по себе является причиной увеличения сетевой задержки, ну а та, в свою очередь, – среднего времени отклика приложений (ART). Ситуация еще больше усугубляется и тем, что переполнение очереди приводит также к сбросу пакетов, который является ещё одним фактором возрастания ART. Какие значения ART являются приемлемыми? Для разных приложений они разные. Например, для того чтобы качество речи при использовании IP-телефонии было бы комфортным для ведения разговора, задержка пакета, в который вставлена голосовая выборка (sample), при передаче из конца в конец не должна превышать 150 мс. В некоторых источниках утверждается, что для интерактивных приложений пользователь начинает ощущать дискомфорт при работе с ними, если круговая задержка (задержка из конца в конец и обратно) превышает 100 мс.

Забавную ситуацию мы наблюдали у одного клиента. При доступе к приложениям посредством сети WAN значение ART составляло примерно 3 сек., т.е. в 30 раз выше указанного порога. При этом пользователи, насколько нам известно, не особенно-то и возмущались. Это означает, что клиент имел талантливую команду сетевых администраторов, которые убедили пользователей, что такое значение ART является совершенно нормальным. Как известно, человек, т.е. пользователь ко всему может привыкнуть, особенно тогда, когда у него отсутствует выбор.

Большинство организаций, которые заботятся о своем бизнесе, конечно же, первую задачу – обеспечение двух маршрутов между удаленными площадками и ЦОД – давно уже решили. При этом, как правило, один из маршрутов является основным, по которому передается трафик в штатном режиме, а второй – запасным, который принимает нагрузку в том случае, когда происходит авария с основным. Возникает вопрос, а можно ли добиться того, чтобы эти два маршрута использовать одновременно? Да, такая задача решается довольно просто: в случае использования протоколов динамической маршрутизации – при определенных условиях применением функции ECMP, а при статической маршрутизации – с помощью механизма PBR.

И такое решение вполне устраивает многие организации. Однако оно обладает одним принципиальным ограничением, а именно: выбор того или иного маршрута принимается без учета характеристики самого маршрута в данный конкретный момент времени, то есть его динамических характеристик: степени загрузки (средней пропускной способности), величины средней задержки в сети и её отклонения от среднего значения, доли сбрасываемых пакетов. Другими словами, совершенно не гарантируется, что, например, голосовой трафик не может быть направлен по маршруту, в котором в данный момент времени существует задержка, превышающая пороговое значение в 150 мс.

Что же касается управления очередью в пограничном устройстве, то традиционные механизмы QoS могли бы справиться с этой задачей, если бы не существовало несколько обстоятельств. Во-первых, несколько различных приложений могут использовать один и тот же порт TCP/UDP. И в этом случае традиционные механизмы QoS не могут осуществить приоритезацию трафика одного приложения относительно другого. Во-вторых, одно и то же приложение может генерировать информационные потоки, различные по своим свойствам. И в этом случае традиционные механизмы QoS не могут помочь – для них эти информационные потоки не различимы. В силу этих обстоятельств традиционные (сетевые) механизмы QoS не могут предотвратить появление очереди, а следовательно, и возникновение задержки.

Могут ли всё-таки быть решены данные задачи по-другому? Об этом мы поговорим в следующей части блога.