Фабрика ЦОД как фактор производительности приложений

Некоторое время назад наша компания организовывала семинар, одной из тем которой была “Фабрика ЦОД как фактор производительности приложений”. Совпадение темы с названием этой статьи неслучайно. Статья является дополняющей и комментирующей слайды, представленные на семинаре.

При создании или модернизации ЦОД, как правило, приходится решать ряд задач. Причем, если площадок ЦОД несколько, то и задачи становятся сложнее. К примеру:

•   как распределить приложения между несколькими площадками и обеспечить возможность запуска любого приложения на любой из площадок?
•   как распределить приложения между несколькими системами хранения, обладающими различной производительностью и как уменьшить административную нагрузку при управлении несколькими СХД?
•   как, при появлении группы аналитических приложений, требующих от инфраструктуры большей производительности, обеспечить эту производительность?

Для решения этих задач можно выбрать разные инструменты. К примеру, можно использовать имеющиеся площадка ЦОД в режиме active-standby, статически распределить приложения между имеющимися СХД, а при необходимости получить больше IOPS — купить новую, более производительную СХД. Этот подход требует минимальных инженерных усилий на момент ввода в действие. Однако усложняется администрирование нескольких СХД, нет возможности задействовать все имеющиеся ресурсы площадок и систем хранения данных, а также возникает перерыв в сервисе, если одна из имеющихся систем хранения выходит из строя (и, как следствие, необходимо восстанавливать из резервной копии те приложения, которые размещали там свои данные).

С нашей точки зрения, применение распределенных СХД в такого рода задачах более оправдано и имеет меньше ограничений. А именно, оно позволяет:

•    предоставлять доступ к набору данных и, как следствие, возможность запускать приложения на любой из площадок ;
•    объединить дисковые ресурсы (в том числе, существующие) в единую СХД, обеспечивая автоматическое распределение наборов данных приложений в соответствии с требованиями производительности, а также предоставляя единую консоль управления;
•    масштабировать систему хранения по производительности и по объему, как вертикально (через добавление дисковых ресурсов в существующие узлы), так и горизонтально (через добавление новых узлов в кластер).

Говоря о производительности в СХД, нельзя не упомянуть такой фактор, как задержка (latency). Для примера, в традиционных FC СХД этот параметр привычно видеть на достаточно низком уровне (порядка нескольких мс), в том числе и за счет отсутствия сбросов пакетов — результат работы механизма кредитов (buffer-to-buffer и end-to-end). А что в случае распределенных СХД, которые в качестве транспорта используют не FC, а IP? Ведь, как известно, при использовании IP пакет может быть потерян, что приведет к его повторной передаче и, как следствие, к увеличению задержки.

Для начала предлагаю оговорить, о каких порядках величин задержки идет речь. В случае, если в СХД для передачи данных используется TCP с опцией Selective ACK (а в современных OS она включена почти всегда), то при потере пакета повторная его передача произойдет примерно через время, равное RTT (round-trip time). К примеру, в лабораторном стенде нашей организации, в фабрике leaf-and-spine из коммутаторов 10Gbit это время составляет порядка 0.1 мс. Соответственно, такого порядка задержка и может быть внесена. В случае же, если произойдет повторная потеря  пакета, время задержки увеличится еще больше.

В итоге, если фабрика без потерянных пакетов вносит задержку порядка 0.1 мс, а в результате сброса пакета добавляется еще 0.1 мс, то получается величина задержки, сравнимая с временем отклика SSD дисков, работающих в СХД (~ 0.5 мс). Соответственно, для уменьшения времени задержки в распределенных СХД необходимо задаться целью свести к минимуму количество сброшенных пакетов.

Теперь, когда задача сформулирована, стоит разобраться, в каких случаях сбрасываются пакеты?

Во-первых, такое может происходить при несогласованности скоростей (рис. 1):

Рис. 1

или в случае, когда несколько потоков объединяются в один, к примеру, несколько клиентов iSCSI проводят запись на СХД (рис. 2):

Рис. 2

или в случае, когда наблюдается всплеск трафика, который не помещается в буфер коммутатора (т.н. microburst).

Во всех этих ситуациях в фабрике должны работать некие механизмы, не допускающие сброс “полезных” пакетов. Что это могут быть за механизмы?

В этой статье я предлагаю рассмотреть следующие:

•   Datacenter Bridging (DCB)
•   Explicit Congestion Notification (ECN)
•   Flowlet
•   использование централизованного контроллера

Если вы можете предложить дополнительные инструменты — отмечайте это в комментариях.

Итак, начнем по порядку. DCB. Если быть точным, то из нескольких инструментов DCB для решения поставленной задачи нас будет интересовать один — Priority Flow Control (PFC). Суть его работы отражена на рис. 3:

Рис. 3

PFC дает возможность “ставить на паузу” определенный класс трафика при заполнении буфера до определенного предела, тем самым предотвращая сброс пакетов. Необходимо, однако, понимать особенности применения этого инструмента.

Во-первых, все коммутаторы фабрики и серверы должны поддерживать PFC. Если не соблюсти это условие, то на паузу будет ставиться полезный трафик, в то время как трафик с устройств, не поддерживающих PFC, будет занимать буферное пространство, и в целом ситуация только ухудшится.

Во-вторых, PFC подразумевает маркировку трафика на уровне заголовка 802.1q — то есть, требует L2-связности между всеми серверами. И, если в пределах одной площадки об этом еще можно подумать, то при наличии нескольких площадок трафик необходимо маршрутизировать (L3-связность) и применение PFC становится невозможным.

Рассмотрим следующий подход к минимизации сбросов пакетов в ЦОД — ECN. Принцип работы представлен на рис. 4 и 5:

Рис. 4

Рис. 5

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

Из описания вытекает особенность ECN: не требуется предварительная классификация трафика. Можно сказать, что ECN работает с гранулярностью “per-session”. Чем больше объем трафика, передаваемый в каждой отдельной сессии, тем больше пакетов из этой сессии будет отмаркировано на коммутаторах фабрики, тем активнее будет приостанавливаться эта сессия. То есть, ECN позволяет:

•   не допустить перегрузки буферов коммутаторов, приостанавливая активные сессии
•   “честно” разделить ресурсы фабрики между потоками трафика разного объема

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

Кроме того, ECN работает только с TCP. Если в ЦОД присутствует, к примеру, трафик UDP, то этот трафик останется без контроля. Если объем такого трафика небольшой по сравнению с TCP — то на этот недостаток можно закрыть глаза.

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

Более подробную схему испытаний можно найти в материалах семинара . Здесь же я просто кратко изложу результат. Включение ECNпозволило уменьшить время отклика на ~ 8 %. С одной стороны, это немного, а с другой стороны — это улучшение, которого можно добиться настройками оборудования без замены самого оборудования, так почему бы нет?

Перейдем к следующему инструменту, позволяющему уменьшить количество сброшенных пакетов в фабрике, а именно — Flowlet. Если кратко, то эта технология позволяет более полно задействовать каналы связи (и разгрузить буфер) при использовании LAG или ECMP. На рис. 6 отражена логика работы коммутаторов без поддержки Flowlet, на рис. 7 — с поддержкой Flowlet.

Рис. 6

Рис. 7

Из описания технологии следует ее ограничение — применима только на участках между коммутаторами ЦОД. Соответственно, подключение серверов остается без контроля — а ведь именно там, как описывалось в начале статьи, может наблюдаться перегрузка. Кроме того, не все производители поддерживают работу с ECMP, ограничиваясь только Flowlet для LAG. А это еще и дополнительное ограничение, связанное с L2, о котором тоже уже упоминалось ранее.

И последний в нашем списке инструмент, подразумевающий применение централизованного контроллера для выделения сессии интересующего нас трафика и применения политик к этой сессии. Этот подход имеет общую черту с ECN — нет необходимости заранее классифицировать трафик по IP-адресам или номерам портов. Отличие в том, какими средствами производится замедление сессий. В зависимости от задачи, это может быть применение WRED к стороннему трафику, а также гарантирование буферного пространства для интересного (например, iSCSI) трафика через Weighted round Robin (WRR). Схема работы контроллера приведена на рис. 8

Рис. 8

На схеме отражен результат работы контроллера – интересный трафик отмаркирован известным значением DSCP. На коммутаторе политики WRED и WRR могут быть описаны следующим образом:

WRED: для трафика, не являющегося интересным, задать порог сбрасывания 30%. Для интересного трафика – сделать этот порого выше. К примеру, 80%.

WRR: для интересного трафика гарантировать полосу пропускания не менее 50% от общей.

Подводя итог статьи, еще раз напомню. Для решения ряда задач, возникающих при построении ЦОД, подходят распределенные системы хранения данных. Их особенностью является использование IP в качестве транспорта и, как следствие, влияние сброса пакетов на время отклика СХД.

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

И, в завершение, я хотел бы наметить еще один подход, связанный с уменьшением времени отклика для СХД. Он не связан напрямую с фабрикой ЦОД, а лежит в плоскости приложений. Речь идет об использованииRDMA для обращения к СХД. Об этом подходе я расскажу в одной из следующих статей. Не переключайтесь!