Как мы развиваемся

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

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

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

Запуская эти службы и сетевые функции на хостах, мы получаем большую свободу и гибкость при проектировании и создании нашего продукта и не ограничиваемся тем, что предлагают производители оборудования. Таким образом, у нас есть четкое разделение ответственности между командами и технологиями, и мы можем ограничить радиус поражения одним хостом в случае (большинства) ошибок. Это также означает, что мы можем и должны полностью владеть решением и настраивать его под наши нужды, но это и так в нашей ДНК.

Немного истории

Исторически сложилось так, что Hetzner использовал различные технологии для обеспечения подключения своих облачных продуктов.

На заре своего существования виртуальные серверы Hetzner vServers, запущенные в 2011 году, начинали с жестких дисков (HDD), нативных мостов Linux (Linux bridges) и статических маршрутов. Они обеспечивали поддержку стека двойного назначения со скоростью до 1 Гбит/с на хост. В итоге с такой конфигурацией работало примерно 25 000 экземпляров.

Следующий продукт был запущен в сентябре 2015 года в виде гиперконвергентной системы на базе Ceph. В нем был осуществлен переход на динамическую маршрутизацию через BGP и настройку моста Linux с использованием 1:1 NAT для IPv4 и полностью маршрутизируемых префиксов IPv6. Это обеспечило лучшую мобильность IP-адресов и обслуживание хостов без ущерба для клиентов. В 2016 году каналы связи с хостами были модернизированы до 2x 10 Гбит/с. Эта конфигурация просуществовала до 2018 года и выросла примерно до 50 000 экземпляров.

Когда в 2018 году был запущен Hetzner Cloud, мы отказались от NAT и перешли на прямую маршрутизацию IPv4. В июле 2019 года мы внедрили плоскость данных на базе Open vSwitch и добавили поддержку частных облачных сетей на основе инкапсуляции VXLAN. В ноябре 2020 года мы начали миграцию части публичной сети на Open vSwitch, что позволило нам в марте 2021 года запустить облачные брандмауэры с отслеживанием состояния (stateful) на основе потоков Open vSwitch и netfilter.

Компоненты хоста ВМ

Мы уже установили, что важные части стека сетевых технологий работают на хостах ВМ; но что они должны предоставлять для работы облачного сервера?

Для большинства серверов требуется доступность из Интернета, чтобы к системе и ее службам можно было получить доступ откуда угодно. Некоторые серверы используют частные сети — либо вместо публичной сети, либо вместе с ней, — которые соединяют серверы, балансировщики нагрузки и, возможно, выделенные серверы через частную виртуальную сеть, к которой имеют доступ только ваши системы. Трафик частной сети инкапсулируется с помощью протокола Virtual eXtensible LAN (VXLAN) и уникального идентификатора виртуальной сети (VNI) для каждой частной сети. Стек сетевых технологий хоста гарантирует, что только участники, подключенные к соответствующей частной сети, могут отправлять или принимать трафик.

Для управления доступом к вашим службам, доступным из Интернета, мы предоставляем функцию облачного брандмауэра (Cloud Firewall). Она позволяет контролировать доступ к определенным портам или протоколам сервера, а также ограничивать исходящий с сервера трафик. Это должно происходить как можно ближе к серверу, следовательно — на хосте. Создание брандмауэров с отслеживанием состояния (stateful firewalls) централизованно потребовало бы дополнительного оборудования и сетевых оверлеев для транспортировки «чистого» трафика на серверы, а также добавило бы массу сложностей для обеспечения высокой доступности и централизованного отслеживания соединений.

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

В большинстве образов cloud-init используется для настройки некоторых частей системы, например для настройки сети IPv6, запуска DHCP для интерфейсов частной сети, подключения облачных томов (Volumes) и т. д. Для выполнения этих задач cloud-init должен запрашивать информацию о локальной системе или конфигурации пользователя с нашего сервера метаданных, доступного по адресу http://169.254.169.254/. Помимо cloud-init, сервер метаданных используется многими интеграциями, включая, помимо прочего, наш драйвер CSI, hc-utils, инструменты дистрибутивов, такие как Afterburn и Ignition от Flatcar Linux, или Talos Linux.

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

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

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

Open vSwitch

Большая часть пути передачи сетевых данных реализуется с помощью Open vSwitch, или сокращенно OVS, — многоуровневого виртуального коммутатора с открытым исходным кодом. Его плоскость данных уже долгое время входит в состав ядра Linux, а пакеты для пользовательского пространства / плоскости управления доступны для всех основных дистрибутивов Linux.

Это стек сетевых технологий по умолчанию для некоторых сред виртуализации, и многие готовые решения поставляются с поддержкой OVS. Сюда входят, помимо прочего, Proxmox VE, OpenStack и oVirt, если назвать лишь несколько популярных. Однако мы не используем ничего из этого, а вместо этого управляем KVM и всеми сопутствующими компонентами с помощью инструментов собственного изготовления.

Open vSwitch — это универсальное сетевое решение, предлагающее огромное количество функций, из которых мы используем лишь подмножество для наших сценариев использования и настройки. Он использует OpenFlow, открытый протокол, созданный для настройки плоскости данных сетевых устройств и определения того, как должны пересылаться пакеты. Для каждого направления связи должен существовать поток, определяющий, как следует обрабатывать пакеты и куда их необходимо отправить.

Это могут быть точные совпадения, например для связи со шлюзом через ARP, NDP, ICMP и т. д., трафик, предназначенный для других участников частной сети, или соединения с сервисом в Интернете.

Оркестрация Open vSwitch — Flusskrebs

Для обеспечения сетевого подключения наших серверов и балансировщиков нагрузки (Load Balancers), а также для настройки любых межсетевых экранов (Firewall), применяемых к серверу, нам необходимо установить требуемые потоки (flows) для Open vSwitch, чтобы обеспечить эти соединения и функции.

Распространенным решением для оркестрации Open vSwitch является проект плоскости управления Open Virtual Network (OVN), который был запущен вместе с самим OVS и предназначен для поддержки парка узлов, работающих под управлением Open vSwitch. Он предоставляет уровень абстракции, на котором можно настраивать логические маршруты и коммутаторы, которые затем преобразуются в OpenFlow.

В то время, когда Open vSwitch был внедрен в стек Hetzner Cloud, мы решили не идти по этому пути, а создать собственное кастомное решение под названием Flusskrebs (в буквальном переводе «речной рак» или «рак потока» 🦀). Оно написано на Python, предоставляет REST API, используемый локальной для хоста частью нашей плоскости управления облаком, и настраивает потоки, необходимые каждой ВМ или балансировщику нагрузки для корректной работы. Это включает в себя потоки для реализации любых правил межсетевого экрана, настроенных пользователем или нашим бэкендом, например, для блокировки исходящего SMTP по умолчанию.

Контроллер также выступает в качестве центрального DHCP-сервера для интерфейсов частных сетей на каждом хосте.

Сетевой стек хоста ВМ

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

Большинство хостов используют два интерфейса восходящей связи (uplink) со скоростью 10 Гбит/с, которые объединены в группу агрегации каналов (LAG) или бонд в Linux с использованием LACP, подключенные к двум физическим коммутаторам, образующим виртуальное шасси для повышения отказоустойчивости и пропускной способности. Для еще большего повышения отказоустойчивости в начале этого года мы начали миграцию на два нативных маршрутизируемых восходящих канала с использованием BGP, подключенных к двум независимым коммутаторам. Обратите внимание, что интерфейсы восходящей связи не подключены напрямую к мосту OVS, а система Linux осуществляет маршрутизацию между ними и OVS. Таким образом, доступность хоста не зависит от OVS, что упрощает установку и обслуживание хоста.

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

Входящий трафик в сторону сервера пересылается с использованием следующих потоков, по одному для каждого префикса IPv4 или IPv6 соответственно. Сетевой стек хоста идентифицирует себя перед ВМ с помощью хорошо известного «виртуального MAC-адреса шлюза», который всегда равен d2:74:7f:6e:37:e3.

Инфраструктурные сервисы, такие как DHCP-серверы и серверы метаданных, также подключены к Open vSwitch и работают вместе с каждым сервером внутри выделенного сетевого пространства имен Linux (Network Namespace) для каждого сервера.

Обратите внимание, что DHCP-сервер udhcpd, показанный на рисунке выше, отвечает только за публичный интерфейс любого сервера. Как описано выше, контроллер Flusskrebs содержит центральный DHCP-сервер, обрабатывающий все интерфейсы частных сетей. Потоки для подключения публичного DHCP-сервера столь же просты:

Наряду с Open vSwitch, для реализации функции с отслеживанием состояния (stateful) облачного межсетевого экрана используется отслеживание соединений netfilter в Linux. При использовании глобальной общей таблицы отслеживания соединений мы должны предотвратить ее переполнение и обеспечить справедливое использование для всех серверов и клиентов. Это делается с помощью ctcount — еще одного внутреннего проекта, который отслеживает записи отслеживания соединений и обеспечивает соблюдение лимита до 80 000 активных одновременных соединений на сервер. Если сервер достигает этого лимита, новые соединения не могут быть открыты до тех пор, пока предыдущее не будет закрыто.

Статус-кво

Эта плоскость данных на базе Open vSwitch сослужила нам хорошую службу и в основном служит по сей день, даже несмотря на более чем миллион облачных серверов. Тем не менее, мы столкнулись с некоторыми ограничениями и захотели улучшить масштабируемость, отказоустойчивость и гибкость с помощью более специализированного сетевого стека. За последние годы наша команда SDN создала упомянутое решение, которое адаптировано под наши нужды, при этом просто в эксплуатации и является прочным фундаментом для новых функций, таких как IPv6 для частных сетей.

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

На Саммите Hetzner у нас была сессия «Новый сетевой стек Hetzner Cloud — технический глубокий анализ того, как мы доставляем ваши пакеты», где мы рассказали о нашем текущем стеке и о том, что мы создали. Записи должны быть доступны в ближайшее время на странице Саммита.