ЦОД. Часть 3

Если традиционные механизмы QoS, предназначенные для поддержки классов обслуживания CoS в соответствии с моделью DiffServ, принципиально не в состоянии управлять задержкой для индивидуальных информационных потоков, то есть не могут обеспечить приемлемое значение среднего времени отклика (ART) конкретного приложения для конкретного пользователя, то какие иные подходы можно было бы применить в таком случае?

Любимый способ, применяемый для этого организациями и предприятиями, весьма прост и заключается в увеличении пропускной способности каналов WAN. В какой степени он способен уменьшить среднее время отклика приложений (ART)?

Попробуем разобраться. Расширение пропускной способности каналов WAN влияет только на задержку в сети, которая, тем не менее, является одной из основных составляющих, вносящих свой вклад в среднее время отклика приложения (ART). В какой степени ве-лико это влияние? Вспомним, что задержка в сети, в свою очередь, включает:

• задержку распространения сигнала (propagation delay);
• задержку, связанную с передачей в канал связи кадра данных (serialization delay);
• задержку, вызванную обработкой пакета в сетевом устройстве (switching delay);
• задержку, обусловленную ожиданием пакета в очереди (queuing delay).

Задержка распространения сигнала зависит от скорости распространения электромагнитных волн в среде передачи и не зависит от величины пропускной способности канала WAN. Задержка распространения сигнала является величиной постоянной и оценивается примерно в 50 мкс на каждые 10 км.

Задержка, вызываемая обработкой пакета в сетевом устройстве, зависит от характеристик самого устройства и опятьтаки не зависит от величины пропускной способности канала WAN. Величина этой задержки обычно находится в пределах 2–10 мкс.
А вот задержка, связанная с передачей в канал связи кадра данных, действительно, обратно пропорциональна величине пропускной способности канала WAN, а также прямо пропорциональна размеру кадра данных. Так, например, при пропускной способности канала WAN в 2048 Кбит/с и размере кадра в 1024 байт величина задержки составит 4 мс. Другими словами, при типичной для наших условий пропускной способности канала WAN эта задержка хоть и зависит от нее, но заметным образом не влияет на величину суммарной задержки в сети.

Задержка, вызванная ожиданием пакета в очереди, также зависит от пропускной способности канала WAN. Однако, это влияние не столь уж велико. Действительно, размер очереди пакетов к отправке, а следовательно, и длительность ожидания в очереди, зависит от двух факторов – темпа передачи пакетов в канал WAN, который, как в примере выше, может составлять, 2,048 Мбит/с, и темпа прибытия пакетов, который в отдельные периоды времени может соответствовать производительности сетевого интерфейса, то есть возрастать примерно до 100 Мбит/с или даже 1000 Мбит/с. При таких обстоятельствах очередь, а значит и данный вид задержки, будет образовываться всякий раз, когда возникает необходимость отправить данные через канал WAN. Природа такой задержки носит стохастический характер, поскольку зависит от конкретных приложений, обслуживаемых сетью, и активности пользо-вателей. Ее величина как раз и может достигать нескольких секунд (что и наблюдалось в одной из организаций), что для многих приложений является попросту неприемлемым.

Иначе говоря, способ увеличения пропускной способности канала WAN с целью уменьшения задержки в сети и, соответственно, среднего времени отклика приложения (ART) не работает.

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

И такая концепция, действительно, реализована в некоторых устройствах, называемых WOC – WAN Optimization Controller.

Что касается задачи распределения нагрузки динамическим образом между несколькими каналами WAN – основным и резервным – в зависимости от их характеристик в конкретный период времени, то идея ее решения представляется очевидной. Поскольку современные протоколы маршрутизации не способны учитывать меняющиеся во времени параметры каналов WAN, то функцию выбора маршрута для передачи пакетов нужно изъять из маршрутизаторов и передать их, например, тем же устройствам WOC, которые в таком случае смогут определять вдоль какого из доступных маршрутов существуют необходимые условия для обслуживания с заданными требованиями информационных потоков. Таким образом, с помощью устройств WOC, хотя, правда, и не всех, при выборе маршрутов кроме топологии сети принимается в расчет еще два фактора – характер информационных потоков и динамические параметры каналов WAN.

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