Лекция 9 (2012-12-10)

Имеет смысл зайти на uneex.ru и подписаться на рассылку, что-нибудь в духе lists.cs.msu.su/mailman/listinfo/uneex. В рассылке трафика немного, так что не будет ничего страшного если вы туда подпишитесь.

Примерно числа 17 будет готов список вопросов. В принципе там ничего сверхъестественного по сравнения с тем что говорил лектор не будет, достаточно просто ориентироваться в теме.

Тема сегодняшней лекции коммуникационные сети.

На следующей лекции можно либо ничего не рассказывать, либо устроить консультацию, либо какую-либо тему по заявкам. Можно поведать лектору пожелания по почте, или в рассылку, или иными средствами (контактные данные есть на uneex.org/eSyr).

Межпроцессорное, межузловое взаимодействие

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

1. взаимодействие для обмена данных с целью решения общей задачи -- сети в суперкомпьютерах чаще с ними ассоциируются
2. взаимодействия с целью обмена информацией чтобы кто-то мог эту информацию получить.

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

Соответственно, когда рассматриваются сети для решения задач, даже не сети, а коммуникации, там в жертву обычно приносится универсальность, а целью ставится производительность. Исторически наверное суперкомпьютинг существует лет 40, если считать от Cray 1. В начале это были просто большие машины, потом объединения больших машин. Объединениями они стали лет 35 назад.

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

Межпроцессорное взаимодействие

В плане межпроцессорного обмена обычно используются всякий специализированный интерконнект, потому что там все довольно локально. Ставится два процессора и между ними проприетарная шина. У Intel это QPI, второе или третье поколение. Шина не очень открытая, лектору известно про неё мало. До последнего момента вместо QPI был FrontSide Bus, до этого ещё и ещё. Служат они для поддержания когерентности кэшей и запросов в память.

Хотя на самом деле топологии они разные бывают.

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

и оптимизировать особо некуда, только два чипа сливать в один. Внизу северный мост NB.

До этого схема была более разнообразна.

Круто, мы соединили два процессора и чего-то этим добились. Так было во времена Pentium 3, ставился особо головастый мост который обслуживал два CPU. Штука не скейлится вообще, больше 4 CPU не воткнете, для этого нужен очень крутой северный мост. Чтобы это сделать нормально нужно туда добавлять дополнительные мемори контроллеры, и схема перестает скейлится вообще. Добавили два процессора, парочку контроллеров и сложность возросла на порядок, потому что нужно обеспечивать соединение все со всеми, то есть сложность увеличили в 8 раз.

Помимо того, что это сейчас Intel SB+, это ещё AMD K8. Фирма AMD довольно быстро (в 2003 что ли) перешла на подобную схему, когда у вас вместо симметричной схемы AMD перешла к NonUniform. Для взаимодействия между процессорами и между процессором и северным мостом используется HyperTransport. Это такой вариант внутрихостового интерконнекта в какой-то момент казалось что он может составить конкуренцию PCIe, но не случилось. Но идея в том, что вместо сильно специального интерконнекта, как FrontSide BUS параллельная шина на 64 бита, протокол не скейлится и предназаначен только для общения между процессором и северным мостом, то HyperTransport как и PCIe несмотря на то, что есть некая специфика особого ограничения на топологию не накладывает. Да, она должна быть древовидной, но не более того. Между процессорами и периферией честный HyperTransport, а между процессорами свой вариант для поддержания кешкогерентности но работает точно так же. Можно видеть как у этого интерконнекта появилась некая свобода и этой свободой пытались воспользоваться, вынося HyperTransport на уровень межузловой коммуникации -- объединять вычислительные системы, узлы по протоколу HyperTransport.

Процессоры с 1-2-4 линка с HyperTransport (кстати поэтому отличались сокеты ц32 и ц34??). то же самое у Intel там есть варианты которые касаются разное количество каналов в память northwood westmere с разным количеством ног xeon 1767 ног с дополнительными линками QPI.

Есть два узла давайте возьмем и объединим каким-то линком процессоры на этих двух узлах. В массы это не пошло. Была такая идея с PCIe, но это опять же исследовательские проекты, нельзя сказать, что это широко распространенный подход.

Есть ряд ограничений связанный именно с топологией, схема сильно скейлиться не будет, но это стало значительно лучше чем кастомная шина только для чего-то одного.

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

Ethernet

Причем Ethernet это такая чисто сеть созданная ради обмена данными, во имя факта передачи информации из одного места в другое, причем эти места могут быть как угодно далеко друг от друга, стек протоколов, TCP/IP, ISO, но это штука программная, а внизу все равно среда передачи данных, одной из которых является Ethernet. Он определен набором стандартов 802.3 и 802.1 .1 определяет общие положения, а .3 дает именно стандарты на среду передачи данных, которая либо медь, либо оптика.

Идея в следующем -- у вас есть сетевой адаптер, есть хост система и есть эфир. Чаще всего средой передачи данных является медь или оптика, раньше ещё был коаксиал но вы его скорее своего не застали. Акадо использует? Акадо использует не Ethernet, хоть и на коаксиале, там TokenRing.

Вы слушаете среду передачи данных, и из неё вылавливаете данные. Как именно вы это делаете не очень специфицировано, но сам факт такого общения породил некоторые особенности.

Обмен происходит фреймами. Фреймы эти имеют структуру которую вы сами знаете, там есть адреса по 6 октетов, далее EtherType или Size, дальше payload (минимальная длина из того 64 байт минимальный размер пакета), в начале ещё есть преамбула, потом CRC и IFGAP, итого 1500. Вы знаете почему EtherType или size -- если у вас чиселка меньше 1500 с копейками, то чиселка будет считать payload. Если же она больше 0x0800 то считается что там указан специальный тип, ка кон парсится зависит от него самого (карточка должна про него чего-то знать) и таким образом вкручиваются разные чудесные стандарты, позволяющие например жумба фреймы (иметь payload больше) VLAN и всякие радости недоступные на уровне линка. Если вы делаете какое-нибудь QNQ, то тайп будет 0x9100, первый номер VLAN, потом согласно стандарту 802.1 ac или ad, дальше 0x8AA, но про все это карточка должна быть в курсе, иначе она может их дропать.

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

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

Карточка может быть совсем тупая- -- ловить трафик и отправлять хосту, у которого есть процессор и мифический софт с драйвером который может сказать софту -- там пришли данные, забери их с сетевого адаптера. Есть два способа взаимодействия интерапты и поллинг, либо пассивно либо активно. Интеррапт возбуждается и его обработчик проверяет есть ли чего в буфере, в случае поллинга проверяем периодически есть ли что в буфере, хотя буфера в реальности может и не быть. В страшном сне 3 мегабитного Ethernetа вы просто читали из порта в наджеде что вам начнут приходить данные, так никто не делал, потому что так нельзя и сразу же появилась буферизация того что приходит. Кольцевой буфер с утерей невлезающих пакетов, потому что у нас протокол ненадежной доставки. Схема.

DMA, про него мы уже говорили -- кольцевой буфер на хосте. Вам должны дать диапазон адресов на хосте, сообщить его девайсу и девайс будет туда складывать в каком то виде отфильтрованные и сортированные пакеты. Ну и чтобы девай сам мог периодически сообщать что-то появилось или что-то поллить. В разные времена эффективен был то один то другой метод. В 100 мб Ethernetе были интеррапты и отсутствие DMA. Когда появился гигабит стало выжираться слишком много процессорного времени, потому что выкидывается контекст, включается драгоценный код обработки интеррапта.. в районе гигабит перешли на DMA и решили что поллинг хорошо. Это неплохо и он снижает латенси, потом посмотрели посмотрели решили что интеррапты тоже неплохо, их тоже оставили, просто сейчас используются для того, чтобы сказать в буфере есть данные посмотри, а не в буфере есть данные забирай.

Понятно что два двухпортовых адаптера больше 2 систем не соединим. Ставить везде многопортовые адаптеры штука нетривиальная и хотелось бы избежать. Потому что как только появляется больше 2 вариантов достижения пути, у вас появляются проблемы.

Spanning tree, про него видимо все знают, поэтому просто упомянем. Если будем бродкастить все пакеты начнется бродкаст шторм и все умрут, поэтому стали придумывать кривульки, которая кажется называется 802.1p, которая позволяет устраивать определенные правила поп поводу того куда слать какие то пакеты и находить поддерево графа чему очень радоваться и его использовать. Проблему можно решать на всех уровнях куча протоколов внешней и внутренней маршрутизации для решения той же проблемы на другом уровне. Штука дурацкая в том смысле что опять же его надо поддерживать.

Сейчас есть вариант стандарта 802.1ad который обеспечивает тот же сервис -- позволяет избежать бродкаст шторма, но делает это по другому.

Почему это вообще проблема, потому что изначально архитектурой сети не было предусмотрено что может быть больше одной связи и когда вы начинаете объединять несколько свитчей это начинает бродкастится на все порты и все ломается. Так в Ethernet решается много чего, написано чуть ли не три десятка стандартов современные свитчи должны их поддерживать.

Когда вы выполняете фильтрации но вам нужно использовать несколько маков. Есть опять же мультикастинг на уровне L2, есть куча разных расширений, которые хорошо бы все поддерживать в железе. когда у вас речь заходить про свитч все становится печально, потому что есть вланы, вы хотите на них политику, разные пакеты маркировать по разному, появляется много логик которые вы хотите иметь на втором уровне и от этого вам нужно городить что-то с железом. Если подниматься на уровень IP, начинается ад и израиль. Потому что с заголовками такая же фингня, у IPv6 он вообще переменного размера. У IPv4 он тоже переменного, но есть поле в котором говорится, какого он размера, а в случае v6 эти опции просто зачейнены. Это не способствует скорости работы L3 коммутаторов. Все это железо в результате имеет довольно увлекательную архитектуру.

Уже на L3 стоит задача обслуживания таблиц маршрутизации. Если IP попадает на такой-то префикс, то посылать на тот порт, а иначе на другой. Такая таблица может быть достаточно большой, десятки сотни тысяч записей. Обычно, правда, вы наверное все это знаете, обычно есть сабнеты и префиксы. схема. Чтобы эту структуру обрабатывать нелинейно, основной способ организации таблицы маршрутов -- строится дерево схема. В узлах биты префикса. Дерево с роутами глубиной примерно 25 получилось у нас. Оно хорошо разреженное. Поэтому оно в прямом виде не применяется, хоть по нему довольно очевидно показывается как происходит поиск.

Существуют разные способы компрессии, упоминавшаяся в лекции по память trie tcam и всё это просто потому что протокол такой, не способствует он тому чтобы поиск был быстрым.

Поэтому с одной стороны есть попытки сделать что-то человеческое из Ethernet. Последние предложенные дополнения к стандарту включают наконец-то flow control на уровне линка и поскольку Ethernet он везде пытаются из него что сделать, но он этому всячески сопротивляется введением всяких IPv6. Основная проблема со 100 гиабитами не в том что бы сделать содесы которые могут передавать столько, а в том чтобы поддерживать пактрейт соответствующий, с этим гораздо сложнее. С IPv6 в дереве будет 128 бит. По сути Ethernet может 100 гигабит когда не нужна маршрутизация.

Есть идея которая исходит и с точки зрения интерконнекта и комм сетей сделать что-то достаточно производительно и достаточно универсальное.

Infiniband

На данный момент одним из ярких представителей является Infiniband. можно было бы упомянуть про специализированные комм сети, которые используются в суперкомпьютерах.

В принципе топология Infiniband сетей это тоже множество свитчей которые как-то подключены схема. Это одна сабнет. У такой подсети должен быть сабнет менеджер, который производит инспекцию сети и занимается управлением -- назначает адреса ( у каждого адаптера есть LID, GID, GUID. Идея в чем -- в рамках стандартаInfiniBandопределен протокол по которому см может опрашивать устройства и управлять левел частью их линков в частности назначать адреса. см после того как очнулся может энумерировать всю сеть и рассказать всем как все посылать. он же может определенным образом настроить таблицы маршрутизации.

По поводу формата пакета -- он более приземленный.

local routing, global routing, tlh payloadm in crc v crc

Почему глобал роутинг необязателен? В случае Ethernetа для надежного конекшена используем TCP -- протокол 4 уровня. Вы должны иметь заголовки Ethernetа, IP, TCP и вся это радость занимает больше 54 байт, всем хватает, хороший такой оверхед. Если вы собираетесь пересылать пакеты по 4-8 байт, то всем становится грустно, потому что у вас 90-95 процентов коммуникаций это оверхеды.InfiniBand предоставляет возможность поддерживать надежное соединение уже на уровне банального линк леера. В рамках сабнета можете организовать надежное соединение между двумя узлами. Для этого на этом уровне вводится понятие Queue Path, Send Queue, Recieve Queue, Complition Queue соответственно для обмена вы помимо адреса указываете еще очередь в которую вы посылаете данное сообщение и можете иметь некий ????. Это поддерживаете на уровне самих адаптеров за счет буферизации сообщения для которых комплишн не пришел.

Как устроены все нормальные интерконнекты.

NIC Router (адаптер на несколько портов), кроссбар, приезжают данные, сидят в буфере. Если реализован трафик контрол и виртуальные каналы (вInfiniBandкак минимум два, хотя там до 16 виртуальных каналов, 15-ый считается системным и идет без буферизации) ... Так устроено почти все коммуникационное оборудование, меняется только количество размазанной в разных местах логики. В случае больших роутеров этом может быть лайнкардом, их может быть напихано много много и вместе будет называться циска нексус или куэр опт, в случае Infiniband это будет Infiniband свитч. Решение вы можете принимать в разных местах в принципе.

Сердес, потом буфер для классификации трафика, потом зачастую QoS (в InfiniBand раскидывается по виртуальным каналам, виртуальные каналы это буфер и идея о том, ка кони должны обслуживаться), например может быть что одни пакеты более разные чем другие, то есть системный трафик идет по каналу ноль, он должен быть приоритетен. Но вы можете и сами выделить у себя классы трафика. Когда у вас будет осуществляться арбитраж приоритет будет у того, кто лезет из соответствующего приоритетного виртуального канала. Можно делать несколько виртуальных каналов для разных вещей, например для IO и для обмена данными. Иногда из-за различных приоритетов трафика могут возникать проблемы типа дедлоков и голодания. В комм сетях это разруливается конфигурацией, в InfiniBand настройкой, в Ethernetе плохо.

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

Ib хорош тем, что решения на уровне L2 принимаются достаточно просто. Mellanox долго страдал что у них не было адаптивного роутинга, теперь они его сделали.

Дошло до того, что Ethernet заворачивают Ethernet в Infiniband.

Голодание может привести к дедлоку. Если есть два завязанных друг на друга потока и они идут навстречу друг другу, то они друг друга забивают. Для этого можно их положить в разные вирт каналы, которые будут арбитрироваться справедливо.

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