С чего начинается любая борьба\война\противостояние? С недовольства, неудовлетворенности, желания достичь большего…
Так и ведомая мной война за микросекунды, война в отдельно взятой организации за «микрули» как конкурентное преимущество, началась с предрассудка о «Speed of Light Issue», мнения что сеть работает как работает и попытки ускорить ее это борьба за превышение скорости света (попытки гнать оптический сигнал быстрее остальных), т.е. благородная но бесполезная. Именно это выражение красовалось на всяческих встречах топ менеджмента и менеджеров среднего звена и становилось приговором, при виде которого все благоговейно кивали, и норовили списать неудачи…
Конечно я не бросился срочно паять варп-агрегат который будет передавать данные в виде частиц на любое расстояние за -1 секунду. Хоть и хочется но пока не придумал как ;). Посему не мудрствуя лукаво сел изучать структуру и состав сил противника и конечно-же диспозицию.
Стоит-ли напоминать что сеть характеризуется не только скоростью передачи информации но и задержками, которые характерны для любого участника цепочки передачи информации. Причем параметр задержки на столько важен что я считаю его ключевым. Приведу пример:
Два датацентра находятся на расстоянии в 100км нам необходимо передать данные и сделаем мы это с весьма приличной скоростью не смотря на отсутствие линий связи. Мы запишем наши данные на Blue Ray диски, много дисков — грузовик дисков. Предположим мы уместили все данные на 10 тысяч дисков BD-ROM односторонних 50ГБ каждый. Скажем группа админов записывала, маркировала, грузила а потом и разгружала-считывала эти диски в течении недели. Таким образом мы транспортировали данные со скоростью 7.1Gbps. Вроде результат очень даже неплохой, более того есть пространство для ускорения (пинать админов чтоб быстрее писали), но вот задержка в 7 дней это как-то не то совсем…
Вот задержки и были объявлены военными преступниками и приследуются беспощадно. Как всякий порядочный враг задержки захватили всё до чего смогли добраться:
К примеру типичный путь следования пакета, optimization: приложение->сокет->ядро->стек протоколов (UDP->IP, ARP резолв->Ethernet)->Сетевая карта(MAC уровень -> PHY уровень)->Свич->Сетевая карта(PHY уровень -> MAC уровень)->… прерывание....->ядро->стек протоколов (Ethernet->IP->UDP)->ядро->сокет->приложение. Как видите враг укрепился серьезно. Условно я склонен разделить этапы пути следования на:
1. Слабо контролируемые:
Ядро (Можем сделать предсказуемым при помощи rt расширений (линух), за известную цену стабильности) но обойти всяческие полезные объекты врятли удастся).
Стек протоколов (тут-уж и песни слова не выкинешь)
Сокет (раб ядра и стека)
Свич (не управляемый)
Сетевая карта (хоть мы и можем заменить ее на более шуструю контроля это не прибавит)
2. Хорошо контролируемые
Приложение (если код доступен)
Свич (управляемый и\или заменяемый)
Расстановка сил не в нашу пользу ?! Но даже при таком раскладе можно добиться значительного уменьшения задержек следуя разным подходам работая с каждым элементом (думаю сия тема раскрыта надежно и широко, хотя с удовольствием затрону вопрос при желании сообщества).
Затяжная позиционная война это развлечение на любителя и\или при соответствующей стратегической обстановке. Как говорится «Война-фигня, главное маневр» и маневр наш будет весьма не ординарным — мы заменим врага на друга, точнее на меньшего врага ;).
RDMA (Remote Direct Memory Access) да еще и в паре с InfiniBand — вот наше меньшее зло. Вероятно некоторые читатели, с этого места, начнут думать о дороговизне, проприетарности, экзотичности, переносимости и это их право. Скажу лишь что сводные затраты на оборудование основанное на инфини и высокопроизводительное\ с низкими задержками Ethernet оборудование будут сопоставимы притом инфини в ряде случаев более дешев. Сей вопрос достоен отдельного поста…
Вернемся к нашим новым враго-друзьям. RDMA. Принцип его работы довольно хорошо раскрывается его названием, он берет данные из памяти одной машины и записывает в память другой. Кто он? Адаптер! Да аппаратное устройство, совершенно без участия ОС, из одного не свопируемого буфера в другой.
Для сравнения худший случай традиционного соединения (от приложения до приложения) это порядка 100 микросекунд, из того что я наблюдал. Для RDMA — 30.
Осталась одна проблема — «языков не знаем» — не умеют наши программы говорить на RDMA, а переписывать дорого\лениво. (Должен сказать в моем случае переписывание оказалось выгодным.) Но проблему решили за нас при помощи библиотеки врапера заменяющго функции работы с сокетами — достаточно пере собрать вашу софтину с этой библиотекой. Она не заменит все вызовы на RDMA\InfiniBand только транспортировку данных, а для ОС всеравно будут отданы все соответствующие вызовы для поддержки работы соединения и тому подобное. Я намеренно не конкретизирую т.к. таковых существует несколько в том числе проприетарные например от Voltaire.
Примерно так выглядел один из маневров войны которая будет продолжаться пока я не спаяю варп-агрегат.
Так и ведомая мной война за микросекунды, война в отдельно взятой организации за «микрули» как конкурентное преимущество, началась с предрассудка о «Speed of Light Issue», мнения что сеть работает как работает и попытки ускорить ее это борьба за превышение скорости света (попытки гнать оптический сигнал быстрее остальных), т.е. благородная но бесполезная. Именно это выражение красовалось на всяческих встречах топ менеджмента и менеджеров среднего звена и становилось приговором, при виде которого все благоговейно кивали, и норовили списать неудачи…
Конечно я не бросился срочно паять варп-агрегат который будет передавать данные в виде частиц на любое расстояние за -1 секунду. Хоть и хочется но пока не придумал как ;). Посему не мудрствуя лукаво сел изучать структуру и состав сил противника и конечно-же диспозицию.
Стоит-ли напоминать что сеть характеризуется не только скоростью передачи информации но и задержками, которые характерны для любого участника цепочки передачи информации. Причем параметр задержки на столько важен что я считаю его ключевым. Приведу пример:
Два датацентра находятся на расстоянии в 100км нам необходимо передать данные и сделаем мы это с весьма приличной скоростью не смотря на отсутствие линий связи. Мы запишем наши данные на Blue Ray диски, много дисков — грузовик дисков. Предположим мы уместили все данные на 10 тысяч дисков BD-ROM односторонних 50ГБ каждый. Скажем группа админов записывала, маркировала, грузила а потом и разгружала-считывала эти диски в течении недели. Таким образом мы транспортировали данные со скоростью 7.1Gbps. Вроде результат очень даже неплохой, более того есть пространство для ускорения (пинать админов чтоб быстрее писали), но вот задержка в 7 дней это как-то не то совсем…
Вот задержки и были объявлены военными преступниками и приследуются беспощадно. Как всякий порядочный враг задержки захватили всё до чего смогли добраться:
К примеру типичный путь следования пакета, optimization: приложение->сокет->ядро->стек протоколов (UDP->IP, ARP резолв->Ethernet)->Сетевая карта(MAC уровень -> PHY уровень)->Свич->Сетевая карта(PHY уровень -> MAC уровень)->… прерывание....->ядро->стек протоколов (Ethernet->IP->UDP)->ядро->сокет->приложение. Как видите враг укрепился серьезно. Условно я склонен разделить этапы пути следования на:
1. Слабо контролируемые:
Ядро (Можем сделать предсказуемым при помощи rt расширений (линух), за известную цену стабильности) но обойти всяческие полезные объекты врятли удастся).
Стек протоколов (тут-уж и песни слова не выкинешь)
Сокет (раб ядра и стека)
Свич (не управляемый)
Сетевая карта (хоть мы и можем заменить ее на более шуструю контроля это не прибавит)
2. Хорошо контролируемые
Приложение (если код доступен)
Свич (управляемый и\или заменяемый)
Расстановка сил не в нашу пользу ?! Но даже при таком раскладе можно добиться значительного уменьшения задержек следуя разным подходам работая с каждым элементом (думаю сия тема раскрыта надежно и широко, хотя с удовольствием затрону вопрос при желании сообщества).
Затяжная позиционная война это развлечение на любителя и\или при соответствующей стратегической обстановке. Как говорится «Война-фигня, главное маневр» и маневр наш будет весьма не ординарным — мы заменим врага на друга, точнее на меньшего врага ;).
RDMA (Remote Direct Memory Access) да еще и в паре с InfiniBand — вот наше меньшее зло. Вероятно некоторые читатели, с этого места, начнут думать о дороговизне, проприетарности, экзотичности, переносимости и это их право. Скажу лишь что сводные затраты на оборудование основанное на инфини и высокопроизводительное\ с низкими задержками Ethernet оборудование будут сопоставимы притом инфини в ряде случаев более дешев. Сей вопрос достоен отдельного поста…
Вернемся к нашим новым враго-друзьям. RDMA. Принцип его работы довольно хорошо раскрывается его названием, он берет данные из памяти одной машины и записывает в память другой. Кто он? Адаптер! Да аппаратное устройство, совершенно без участия ОС, из одного не свопируемого буфера в другой.
Для сравнения худший случай традиционного соединения (от приложения до приложения) это порядка 100 микросекунд, из того что я наблюдал. Для RDMA — 30.
Осталась одна проблема — «языков не знаем» — не умеют наши программы говорить на RDMA, а переписывать дорого\лениво. (Должен сказать в моем случае переписывание оказалось выгодным.) Но проблему решили за нас при помощи библиотеки врапера заменяющго функции работы с сокетами — достаточно пере собрать вашу софтину с этой библиотекой. Она не заменит все вызовы на RDMA\InfiniBand только транспортировку данных, а для ОС всеравно будут отданы все соответствующие вызовы для поддержки работы соединения и тому подобное. Я намеренно не конкретизирую т.к. таковых существует несколько в том числе проприетарные например от Voltaire.
Примерно так выглядел один из маневров войны которая будет продолжаться пока я не спаяю варп-агрегат.