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]
понедельник, ноября 26, 2012
Что такое TCP Incast
Подписаться на:
Комментарии к сообщению (Atom)
Atom feed
9 коммент.:
Меня вообще давно удивляет, зачем в датацентрах для внутренних коммуникаций TCP?
В датацентре latency измеряется в микросекундах, потери пакетов примерно равны 0 - очевидно же, что TCP разрабатывался для совсем других задач.
soonts
Меня вообще давно удивляет, зачем в датацентрах для внутренних коммуникаций TCP?
потому что commodity hardware
Alena, commodity hardware работает на 1-2 OSI-уровня ниже, чем TCP. Поверх того же самого hardware прекрасно работает куча других протоколов, например RTP для realtime голоса/видео и µTP для больших файлов.
Можно подробнее про фразу "простой свитч, как сейчас модно"? Откуда такая информация?
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]"
Внезапно :) "Алёна TCP"?
На мой взгляд, проблема немного преувеличена. Чтобы с несколькими десятками килобайт влететь в нее, свич должен быть ну совсем помойным, или уже у нас в сторону центрального устройства уже линк загружен больше чем на 2/3.
И даже в такой ситуации, когда очевидно, архитекторы ДЦ оказались буратинами, можно из нее выкручиваться, делая дополнительный линк от центрального сервера на порт коммутатора в другом ASIC
Rett Pop
Внезапно :) "Алёна TCP"?
Не-не-не :-)
Tima
На мой взгляд, проблема немного преувеличена. Чтобы с несколькими десятками килобайт влететь в нее, свич должен быть ну совсем помойным,
Несколько десятков килобайт на машину. Машин и 1000 может быть.
получается, что на стороне сервиса этим никак нельзя управлять - надо настраивать именно железяки и именно на бекенде?
может запросы разнести с рандомным дилеем?
Отправить комментарий