Пользователь
0,0
рейтинг
18 июля 2014 в 17:50

Разработка → В MIT разработали технологию управления трафиком датацентра, которая многократно уменьшает задержки и очереди

Технология, названная Fastpass, была протестирована в одном из датацентров Facebook и показала очень впечатляющие результаты. Суть системы Fastpass — в добавлении специализированного узла управления трафиком, который играет роль «дирижёра», сообщающего серверам, когда им следует отправлять пакеты данных. Этот узел вычисляет оптимальное время отправки пакета данных с точностью до сотен наносекунд и оптимальный его путь в сети. В результате резко снижается количество коллизий пакетов и время их ожидания в очередях.

С использованием Fastpass медианный размер очереди пакетов падает с 4,35 мегабайт до 18 килобайт. Теоретически, Fastpass позволяет вообще избавиться от очередей, но на практике это пока невозможно из-за недостаточно точной синхронизации времени между серверами. Так же значительно уменьшается и пинг — с 3,56 миллисекунд до 230 микросекунд. Необходимость в повторной отправке пакетов в сети, управляемой Fastpass, уменьшается в два с половиной раза.



Плата за такое существенное улучшение характеристик сети не слишком высока: необходимость передавать дополнительный управляющий трафик по специальному протоколу Fastpass Control Protocol (FCP) приводит к незначительному уменьшению общей пропускной способности сети — с 9,43 до 9,28 гигабит в секунду.

Алгоритм, используемый в Fastpass, хорошо масштабируется — при росте количества запросов нагрузка на процессор растёт линейно. В ходе экспериментов сервер Fastpass с восемью ядрами управлял суммарным трафиком 2,21 терабит в секунду. Если реализовать его на специализированном железе, с помощью (FPGA или ASIC), производительность можно повысить ещё в несколько раз. Для дальнейшего масштабирования можно использовать иерархическую схему с несколькими серверами Fastpass.

Подробное описание алгоритма, протокола и архитектуры Fastpass, а так же исходники, можно найти в открытом доступе на сайте fastpass.mit.edu. Лично мне описание системы очень напомнило работу другого алгоритма, который решает похожую проблему но, в совершенно другой области — управлении автомобильным трафиком. Алгоритм управления работой перекрёстка, который разработал доцент Техасского университета в Остине Питер Стоун, рассчитан на беспилотные автомобили, способные в реальном времени обмениваться информацией между собой и управляющим движением компьютером. Потоки машин на таком перекрёстке будут пересекаться почти не мешая друг другу, каждый автомобиль, подъезжая к перекрёстку, будет лишь слегка притормаживать или разгоняться, а его траектория движения будет рассчитана заранее. Вот как это выглядит:



Илья Сименко @ilya42
карма
524,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (28)

  • –1
    Коллизии? В датацентрах? Откуда?

    Арбитраж на уровне пакетов в масштабах датацентра звучит несколько фантастично. «Сотни наносекунд» — это в десятки раз меньше того времени, за которое свитч передаст пакет из порта в порт.

    Выглядит как нечто совершенно бесполезное (буфера переносятся на сервера), с огромным оверхедом. Где можно почитать про ту часть с тестированием на боевой сети фейсбука?
    • +5
      Свитчи бывают разные — года два назад был большой hype насчёт low-latency switching, как раз сотни наносекунд и обещали. На 10G можно примерно прикинуть — скорость канала должна давать порядка 600 ns на 64-байтный пакет.
      • –2
        Для cut-through свитчей размер пакета вообще по барабану (у них начало пакета покидает порт, пока хвост пакета еще только всасывается), для самых быстрых (Nexus 3k, ряд моделей от Arista) будет пара-тройка сотен наносекунд. Но они дороговато стоят с точки зрения датацентра, которому не важны сотни наносекунд или микросекунды задержки. Для задач фейсбука должно было бы хватить типовых свитчей с 10мкс задержки.
        • +4
          А, ясно. Скажите, а откуда у вас информация о том, что достаточно для facebook и какие у них там задачи?
          • –4
            Типовой big data. Hadoop'у в целом наплевать на задержки, ему бы полосу пошире.

            Кстати, в white paper по этой технологии говорится, что она предназначена для bulk трафика.
      • 0
        Так уже давно такие коммутаторы есть, называются cut-through правда они в основном FC были.
        Из Ethernet есть серия Cisco Nexus с такой технологией.
    • +2
      Что значит откуда, запишите данные с 1000 машинок в одну и получите гигантскую коллизию.

      А это вполне штатный режим работы для например интернет поиска или map-reduce/hadoop в момент выполнения reduce. А попросить их не писать одновременно, а регулировщика поставить вполне себе решение.
      • +2
        Речь идет про сетевой уровень, а там в XXI веке в проводной среде коллизии нетипичны. Арбитраж тут не на уровне соединений (это модно в случае SDN), а на уровне пакетов или их цепочек, чтобы пакеты не толкались в буферах аплинков.

        А я вот не понимаю, чего они такого добились, чего нельзя добиться тюнингом TCP на конечных узлах, чтобы правильно реагировал на возрастание задержек при буферизации и быстрее оправлялся от дропов.
        • +2
          Ну нужно просто сравнить стоимость оборудования 21 века, которое умеет резервировать цепочки пакетов, и стоимость 1 машинки которая это сможет сделать на более менее тупых свичах, которые ставят все интернет компании и станет все понятно.

          Очень легко сделать хорошую сеть без переподписки или на InfiniBand, только это стоимость дата центра увеличивает процентов на 30.

          Настройкой TCP этого сложно добиться, TCP не совсем для ситуация когда roundtrip < 0.1ms предназначен, у него эти окна там атджастятся секундами, у нас тоже свой самописанный протокол поверх UDP.
          • +1
            Не катит. Тут упоминается про «оптимальный его [пакета] путь в сети». Каким образом ваша «1 машинка» сообщит им о том, каким путем направить пакет? Откуда вообще та «1 машинка» будет знать топологию сети и расположение серверов? Соответственно, речь идет про вариации на тему либо MPLS, либо SDN/Openflow. А это уже не совсем тупые свитчи.

            Сеть с относительно несуществующей переподпиской реализуема и на ethernet. 16x10G вниз и 4x40G на аплинках.

            В случае винды алгоритм congestion management фактически прибит гвоздями, но на опенсорсных реализациях можно и на минимальный RTT настроить. Или наворотить своего поверх UDP — это в данном случае ничего не меняет.
            • +2
              Вот у нас вот так в последних дц сеть строится
              tech.yandex.ru/events/yac/2013/talks/1124/
              И у всех больших.

              Я не помню говорилось это в презентации или нет, или это особеность конкретного вендора, но каждый пакет префиксуется 3-4 циферками, в зависимости от размера сети, это делает OS. у свитча очень тупое поведение он должен убрать одну циферку из префикса и в этот интерфейс кинуть остаток пакета, следующий сделает так же. Свичи очень тупые и дешевые, но их много.
              • 0
                Да, CLOS фабрики повсюду, благо ни в одной адекватной новой инсталляции не бывает STP BLK портов.

                Segment Routing — это хорошо, но, помнится, Даниил говорил, что оно у вас еще в очень глубоком R&D.
                • +1
                  Я не noc, я маску нашел, поэтому половину аббревиатур выше не понимаю. но вот в последнем и самом большом dc оно строится так, у fb про чье внедрение речь я думаю оно так давно.

                  Ну и дополнение к предыдущему сообщению, на самом деле:
                  1) не надо сообщать каким путем направить пакет, часто достаточно сообщить когда. Для систем типа MR которые перекидываются блоками по 128MB у всех это есть прямо в userspace, просто знание сейчас херач блок, а сейчас нет. Тут чуваки сделали универсальное решение.
                  2) ну и про то что без MPLS и других букв нельзя выбрать куда интерфейс отправит пакет я тоже не особо верю. Потому как если это утверждение принять за истину то обычный bonding тоже сделать нельзя.
                  3) у нас почти у каждой машинки 2 интерфейса торчащие в разные сети, там тоже есть возможность выбирать.
                  • 0
                    1) Так это на практике работает? В смысле — с центральным арбитражем? Такое бывает внутри одного устройства (см. ASR9000), но вот в работоспособность схемы в распределенной сети я не особо верю. Это даже хуже, чем Openflow, где контроллер координирует каждое соединение — здесь мы работаем на уровне отдельных пакетов соединения.
                    2) Выбрать локально — не проблема. А вот сообщить стоящему за несколько хопов устройству, куда оно должно послать пакет, проблема. Когда-то давно был source routing, который давно предан забвению и рекомендован к безоговорочному отключению. Сейчас актуальны варианты, когда отправителя пакета вообще не интересует, каким путем пойдет пакет дальше по цепочке, это забота других устройств. Но выше вы описали segment routing, новомодный механизм, позволяющий отправителю давать инструкции вида «езжай прямо до перекрестка с такой-то улицей, затем поверни налево».
                    3) Я, кстати, задавал вашим бойцам ряд вопросов про подобное резервирование, ответа не было. Например, у получателя пакета отвалился один линк. Традиционная сеть отреагирует на это стремительно, информации надо распространяться от силы в пределах пары хопов. В случае segment routing — как быстро до всех отправителей дойдет, что старый маршрут уже не работает, и кто отправит им эту информацию?

                    Да, от свитчей в такой схеме не требуется многих талантов, но это все равно будут современные L3 свитчи, умеющие работать с метками и заглядывать в IP заголовок сквозь эти метки (надо, чтобы ECMP работал), и у многих типовых чипов на этом этапе возникают серьезные проблемы, если меток более четырех. Обычно столько меток и не потребуется, но Яндекс хочет одну метку на хост и еще одну на виртуалку, в результате чего остается лишь две транспортные метки. Но да, топовые ASICи могут видеть сквозь 16 меток.

                    Зато много дополнительной работы сваливается на конечные узлы. Но я верю, что оно может в итоге работать. А вот в то, что fastpath может работать — не верю. Bulk трафик неинтересен, обычно это очень мало соединений между малым числом узлов. Internet edge куда веселее с его многочисленными короткоживущими соединениями.
                    • 0
                      > Так это на практике работает?
                    • 0
                      > Так это на практике работает?
                      1) Не понял вопрос если честно. Если про fastpath, что работает, сам не пробовал. Для больших блоков в map/reduce системах очевидно работает.
                      2) и 3) Не вижу особых проблем. Как я говорил я не noc я маску нашел, так что не отвечу как устроено в конкретной железке, могу ответить как можно устроить. Очевидно, что если у вас в TCP пакетик потерялся то противоположная сторона узнает про это через например 0.5 секунды, и нет особо никаких проблем понять по статистике маршрута доходят пакеты или нет. Но скорее в таком роутинге есть еще какой-то свой протокол подтверждений, т.к. никто не гарантирует, что будет ходить TCP, т.е. использовать информацию из его подтвержений было бы не очень правильно. Учитывая что ты контролируешь сетевый драйвера всех конечных устройств там можно сделать все что угодно.

                      >А вот в то, что fastpath может работать — не верю
                      «Летательные аппараты тяжелее воздуха невозможны»
                      • 0
                        >Для больших блоков в map/reduce системах очевидно работает.
                        Для больших, которые передаются за десятки/сотни миллисекунд — может быть. В общем же случае, для множества слабо предсказуемых потоков и для заявленной цели (избежание даже микровсплесков, способных загрузить портовые буфера) — вряд ли.

                        >Очевидно, что если у вас в TCP пакетик потерялся то противоположная сторона узнает про это через например 0.5 секунды, и нет особо никаких проблем понять по статистике маршрута доходят пакеты или нет.
                        Ну так пакет мог потеряться где угодно в цепочке вплоть до самого первого свитча. И потеря одного пакета не обязательно говорит о проблеме, для TCP это лишь повод сбавить скорость. А вариант «определяем проблему на последнем линке по тому, что протокол маршрутизации не зафиксировал проблем нигде ближе» кажется мне каким-то недостаточно надежным.

                        >«Летательные аппараты тяжелее воздуха невозможны»
                        Ваш noc не верит в то, что полноценный openflow с безмозглыми форвардерами может работать (я тоже не верю). Многие верят.
                        • 0
                          > для TCP это лишь повод сбавить скорость
                          А для сетевого драйвера поставить вес тому маршруту на котором пакетики теряются меньше, в случае если один линк работает, а другой нет это сойдется в весах за очень малое время.

                          > Ваш noc не верит в то, что полноценный openflow
                          я не знаю что такое openflow поэтому эта цитата не вызывает у меня никаких эмоций. Учитывая что noc строить сеть на том принципе который я описал он в него верит, а я верю в том что описал facebook. С другой стороны я вполне пойму если noc в это не поверит по приниципу «в теории нет разницы между теорией и практикой, а на практике есть». В смысле я просто знаю что это возможно, а им с этой херней жить придется если они поверят.
  • +11
    В индии и не беспилотный транспорт так двигается %)
    • +1
      Теперь-то понятно как в индийских фильмах актёры умудряются «обходить» законы физики — они беспилотные роботы.
    • 0
      Ну вообще на видео есть светофоры, и часть водителей ожидает нужного сигнала:)
    • +5
      Это адски выглядит на видео, а я там водил… впечатления непередаваемые.
  • –3
    Можно я не буду ездить на беспилотниках, которые так проезжают перекрестки?
    • 0
      Глупо бояться.
      Чтобы исключить даже невероятный сбой в системе регулировки движения беспилотных автомобилей, достаточно изначально заложить в алгоритм размер автомобиля больше чем в реальности (размеры, которые учитываются при расчете коллизий) примерно на размер тормозного пути для максимально допустимой скорости на этом перекрестке, и эту ошибку сумеет разрулить автомобильный автопилот самостоятельно, без подключения 'к сети'.
      • +1
        Если заложить «настоящие» физически реализуемые параметры динамический габарит получается уж очень большой и такой красоты как на видео даже близко будет.
  • +1
    Суть системы Fastpass — в добавлении специализированного узла управления трафиком, который играет роль «дирижёра», сообщающего серверам, когда им следует отправлять пакеты данных.


    А разве тут не имеется в виду что тот самый сервер работает на L2? т.е. все сервера должны быть в одном broadcast-домене?
  • +1
    А потом у одного автомобиля пробивает колесо прямо перед перекрёстком…
  • 0
    А Token Ring (или другой маркерный протокол) не лучше? Понятно, что для этого надо менять все оборудование, а здесь — только поставить диспетчер.

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