понедельник, ноября 26, 2012

Что такое TCP Incast

TCP Incast - неприятная проблема, возникающая в датацетрах, связанная с работой протокола TCP.

Возникает при следующем сценарии: некий сервер шлет запрос кластеру машин. Все эти машины ему одновременно отвечают. Ответ может быть довольно большой, несколько десятков килобайт. Эти килобайты доходят до свитча, за которым находится наш кластер. Свтич, как это сейчас модно, самый обычный. И буфер у него небольшой. Та часть данных, что в буфер не влезла, будет сброшена. Протокол TCP гарантирует доставку, так что все потерянные пакеты будут посланы еще раз. Вопрос когда. Стандартный RTO (retransmission timeout) - 200 ms. Для какого-нибудь облачного сервиса это много. В результате получаем латентность, наша распределенная система работает слишком медленно.

Здесь описание TCP Incast с правильной картинкой: TCP Incast and Cloud application performance
Еще одно хорошее описание: Fine-grained TCP Retransmissions

Как с этим можно бороться. Простой и действенный способ - уменьшить RTO до 1 ms. Еще можно изменить протокол TCP: Data Center TCP (DCTCP)

Еще пара работ с анализом проблемы с красивыми картинками:
Understanding TCP Incast Throughput Collapse in Datacenter Networks[.pdf]
Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication[.pdf]

9 коммент.:

Анонимный комментирует...

Меня вообще давно удивляет, зачем в датацентрах для внутренних коммуникаций TCP?

В датацентре latency измеряется в микросекундах, потери пакетов примерно равны 0 - очевидно же, что TCP разрабатывался для совсем других задач.

Alena комментирует...

soonts

Меня вообще давно удивляет, зачем в датацентрах для внутренних коммуникаций TCP?

потому что commodity hardware

Анонимный комментирует...

Alena, commodity hardware работает на 1-2 OSI-уровня ниже, чем TCP. Поверх того же самого hardware прекрасно работает куча других протоколов, например RTP для realtime голоса/видео и µTP для больших файлов.

Alexander Solovets комментирует...

Можно подробнее про фразу "простой свитч, как сейчас модно"? Откуда такая информация?

Alena комментирует...

soonts

Alena, commodity hardware работает на 1-2 OSI-уровня ниже, чем TCP

Cтандартное железо обычно закупается со стандартным софтом. А так да, на него много что можно поставить.

Alexander Solovets

Можно подробнее про фразу "простой свитч, как сейчас модно"? Откуда такая информация?

Некоторое время назад Google опубликовал статью, в которой рассказывал, что они используют в своих датацентрах стандартное железо. С тех пор это стало модно. Например, по сслыке на DCTCP пишут "A consistent
theme in data center design has been to build highly available, highly performant computing and storage infrastructure using low cost, commodity components [18, 5]"

Rett Pop комментирует...

Внезапно :) "Алёна TCP"?

Tima комментирует...

На мой взгляд, проблема немного преувеличена. Чтобы с несколькими десятками килобайт влететь в нее, свич должен быть ну совсем помойным, или уже у нас в сторону центрального устройства уже линк загружен больше чем на 2/3.

И даже в такой ситуации, когда очевидно, архитекторы ДЦ оказались буратинами, можно из нее выкручиваться, делая дополнительный линк от центрального сервера на порт коммутатора в другом ASIC

Alena комментирует...

Rett Pop

Внезапно :) "Алёна TCP"?

Не-не-не :-)

Tima

На мой взгляд, проблема немного преувеличена. Чтобы с несколькими десятками килобайт влететь в нее, свич должен быть ну совсем помойным,

Несколько десятков килобайт на машину. Машин и 1000 может быть.

Анонимный комментирует...

получается, что на стороне сервиса этим никак нельзя управлять - надо настраивать именно железяки и именно на бекенде?
может запросы разнести с рандомным дилеем?