Почему мы создали глобальную сеть с MTU 9000 и что это дает

Когда мы начали проектировать сетевую инфраструктуру CubePath, у нас был выбор. Мы могли поступить так, как поступает большинство провайдеров: предоставить каждому региону свою собственную изолированную сеть со стандартным MTU 1500 и на этом остановиться. Это дешевле, проще, и, честно говоря, большинство клиентов не заметят разницы в первый же день.

Мы решили пойти другим путем. Мы инвестировали в создание глобальной частной сети с VLAN, охватывающей несколько регионов, и MTU 9000 (jumbo frames) по всем направлениям. Это стоило дороже. Это заняло больше времени. Но это открывает категорию архитектур, которые просто невозможны в стандартной сети, и мы считаем, что это важно.

В этом посте объясняется, почему мы сделали эти инвестиции и какие возможности это открывает для команд, разрабатывающих приложения на платформе CubePath.

Почему MTU 9000? Потому что 1500 байт на пакет — это узкое место.
Начнём с технической реальности. По умолчанию MTU в большинстве сетей составляет 1500 байт. Это стандарт, действующий с момента разработки Ethernet в 1980-х годах. Каждый пакет, отправляемый вашими серверами, содержит максимум 1500 байт фактических данных, плюс заголовки.

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

Возьмем, к примеру, резервную копию базы данных размером 1 ГБ. При MTU 1500 это примерно 700 000 пакетов, которые необходимо собрать, отправить, получить, проверить и подтвердить. Каждый из этих пакетов требует ресурсов процессора. Необходимо обрабатывать заголовки, вычислять контрольные суммы, обрабатывать прерывания. Умножьте это на сотни передач, происходящих каждый час в загруженной инфраструктуре, и вы увидите, что реальные вычислительные ресурсы расходуются на сетевые накладные расходы.

Теперь рассмотрим ту же передачу с MTU 9000. Каждый пакет содержит в 6 раз больше данных. Резервная копия объемом 1 ГБ сокращается примерно до 120 000 пакетов. Меньше нагрузки на ЦП, меньше прерываний, более высокая пропускная способность. В реальных тестах Jumbo-кадры улучшают производительность пакетной передачи на 15-30%. В рабочих нагрузках, постоянно перемещающих данные между узлами, таких как репликация баз данных, распределенное хранилище или трафик контейнеров «восток-запад», эта разница увеличивается в течение дня.



Мы проанализировали, что именно создают наши клиенты. Кластеры баз данных с потоковой репликацией. Распределенные хранилища с Ceph и GlusterFS. Кластеры Kubernetes с сотнями взаимодействующих друг с другом подов. Конвейеры обработки больших данных, перемещающие промежуточные результаты между узлами. Все это — рабочие нагрузки, где эффективность сети напрямую влияет на производительность и стоимость. Поэтому мы приняли решение: MTU 9000 повсюду, не как дополнительная опция, а как основа.

Почему многорегиональные VLAN? Потому что реальные архитектуры не размещаются в одном центре обработки данных.



Большинство провайдеров предоставляют вам частную сеть в пределах одного региона. Ваши серверы в Испании могут обмениваться данными между собой через частную сеть, и ваши серверы в Амстердаме также могут обмениваться данными через частную сеть. Но если Испании нужно связаться с Амстердамом? Вам придется использовать общедоступный интернет, создавать VPN-туннели или платить за какие-либо услуги межсетевого взаимодействия.

Это создает трение, которое подталкивает команды к более простым (и более хрупким) архитектурам. Если соединение двух регионов само по себе является проектом, люди его избегают. Они запускают все в одном регионе и надеются, что ничего не пойдет не так. Или они создают недоработанные системы аварийного восстановления, которые никогда не тестировались, потому что настройка сетевого уровня оказалась слишком сложной.

Мы хотели полностью устранить это препятствие. VLAN-сети CubePath охватывают разные регионы. Ваш сервер в Испании и ваш сервер в Амстердаме могут находиться в одной частной сети, как если бы они располагались в одной стойке. Никаких VPN, никаких туннелей, никакой специальной конфигурации. Просто серверы, которые видят друг друга с MTU 9000, через частную сеть, которая никогда не подключается к общедоступному интернету.

Это не просто функция для удобства. Она коренным образом меняет представление о том, какие архитектуры целесообразно строить.

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



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

Благодаря MTU 9000 в частной сети между регионами, ваша реплика в другом центре обработки данных остается близкой к основной даже при высоких нагрузках на запись. Это означает, что ваши реплики для чтения предоставляют актуальные данные, ваша целевая точка переключения на резервный сервер действительно работоспособна, а восстановление на определенный момент времени не происходит с задержкой в ​​несколько секунд.

В стандартной сети с MTU 1500, подключенной к общедоступному интернету? Задержка репликации резко возрастает под нагрузкой, реплики отстают, и когда вам действительно нужно переключиться на резервный сервер, вы обнаруживаете, что ваш резервный сервер отстает от основного на несколько минут.

Восстановление после катастроф, которому вы действительно можете доверять
Восстановление после сбоев — это одна из тех вещей, о которых все говорят, что они у них есть, но мало кто действительно их тестировал. Основная причина этого — сложность сети. Если передача резервных копий в другой регион включает в себя настройку VPN-туннелей, конфигурирование шифрования, учет расходов на пропускную способность и надежду на то, что передача завершится до начала следующего окна резервного копирования, то команды просто… не делают это должным образом.

Когда ваши регионы подключены к одной и той же VLAN с MTU 9000, восстановление после сбоев становится намного проще. WAL-файлы передаются по частной сети в режиме реального времени. Ночные резервные копии передаются быстрее, поскольку Jumbo-кадры уменьшают накладные расходы. Стоимость сети равна нулю, поскольку частный трафик бесплатен. А поскольку это легко настроить, команды фактически тестируют свои процедуры восстановления, а не предполагают, что они работают.

Распределенное хранилище без узкого места в сети
Ceph, GlusterFS, NFS, iSCSI. Все эти протоколы хранения данных невероятно чувствительны к производительности сети. Скорость кластера хранения данных зависит только от скорости сети, соединяющей его узлы.

MTU 9000 уменьшает фрагментацию пакетов и позволяет передавать трафик хранилища со скоростью, близкой к скорости сетевого соединения. Если вы используете кластер Ceph на нескольких серверах, разница между MTU 1500 и MTU 9000 может означать разницу между приемлемой производительностью и постоянными узкими местами. Мы убедились в этом на собственном опыте у клиентов, использующих распределенные хранилища, и это одна из причин, по которой мы перешли на использование Jumbo Frames в сети в целом.

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

В CubePath обмен данными между узлами кластера происходит по частной сети. Сигналы активности между узлами Patroni, проверки Redis Sentinel, консенсус etcd в Kubernetes, проверки работоспособности HAProxy — всё это работает в быстрой, изолированной сети с MTU 9000. В результате обнаружение сбоев происходит быстрее, передача состояния при повышении уровня кластера происходит быстрее, и ваш кластер восстанавливается до того, как пользователи заметят какие-либо изменения.

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

Kubernetes с быстрой передачей трафика между Востоком и Западом.
Kubernetes генерирует огромный объем внутреннего сетевого трафика. Поды взаимодействуют друг с другом, сервисы разрешаются через DNS кластера, контроллеры входящего трафика маршрутизируют запросы к бэкэндам — все это трафик между узлами, идущий в направлении «восток-запад».

Когда трафик проходит по сети с MTU 9000, каждое взаимодействие между подами становится более эффективным. Боковые контейнеры сервисной сетки добавляют меньше накладных расходов. Большие объемы данных между микросервисами передаются быстрее. А если вы используете CNI, например Cilium или Calico, то производительность базовой сети напрямую влияет на скорость взаимодействия ваших подов.

Для управляемого Kubernetes от CubePath это означает, что кластерная сеть работает лучше сразу после установки. Для самостоятельного управления это означает, что вы используете сеть, которая не будет создавать проблем по мере роста кластера.

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

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

Решение, лежащее в основе инвестиций


Создание этой сети было непростым делом. Стандарт MTU 9000 требует сквозной поддержки на каждом коммутаторе, маршрутизаторе и сетевой карте на пути следования. Многорегиональные VLAN требуют межсоединений между центрами обработки данных, чего большинство провайдеров избегают из-за стоимости и сложности. Было бы проще и дешевле использовать стандартные сетевые решения и сосредоточиться на других функциях.

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

Репликация баз данных, распределенное хранилище, кластеры высокой доступности, сетевое взаимодействие контейнеров, аварийное восстановление. Все это ограничено качеством сети между вашими серверами. Мы хотели, чтобы CubePath представлял собой инфраструктуру, в которой вы проектируете архитектуру, исходя из того, что лучше всего подходит для вашего приложения, а не исходя из возможностей сети вашего провайдера.

Именно поэтому мы построили её именно так. И именно поэтому мы продолжаем инвестировать в расширение этой сети, добавляя новые регионы и наращивая мощности.

Что дальше?
Мы продолжаем расширять нашу сеть, добавляя новые регионы и увеличивая пропускную способность существующих межсоединений. По мере роста CubePath Managed Kubernetes и запуска кластеров GPU, требования к внутренней сети только возрастают, и инвестиции в MTU 9000 и многорегиональные VLANы окупаются еще больше.

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

cubepath.com
my.cubepath.com/register