Предисловие
Здравствуйте. Меня зовут Гордиенко Андрей, я ведущий специалист в отделе поддержки облачных услуг в Selectel. Работаю в компании более пяти лет и накопил немалый опыт учета запросов клиентов как выделенных серверов, так и облачных услуг. В прошлом продолжительное время занимал должность сетевого инженера, добился определенных успехов, а теперь хочу поделиться знаниями с сообществом.
Мы подготовили материал, состоящий из трех частей. Цель трилогии — помочь всем, кому необходимо разбираться в особенностях сетей, в том, как их использовать для выстраивания новой инфраструктуры или улучшения существующей. В основе — накопленные знания при обработке клиентских запросов.
Первая часть посвящена знакомству с устройством сетей и возможными схемами соединения компонентов. Без этого не обойтись при дальнейшем изучении масштабирования и георезервирования.
Во второй части мы разберем работу сети в рамках объединения выделенного и облачных серверов. Это самая важная и полезная часть — мы сможем рассмотреть поведение облачной платформы в том или ином варианте использования.
Третья часть — заключительная, в ней мы погрузимся в работу готовых решений. Несмотря на обширность темы, немного теории и практики помогут понять, что может пойти не так в том или ином случае. Мы не будем вникать, как составить манифест для развертывания приложений на Kubernetes, не будем подключаться и тем более создавать базы данных. Однако точно добавим каждый сервис в нашу схему. В последней главе дополним примеры отказоустойчивыми решениями.
Все необходимые иллюстрации и схемы будут приведены для наглядности. Мы будем говорить в основном про облачную платформу, так как именно она предоставляет набор готовых сервисов и позволяет их гибко настраивать с помощью панели управления, Terraform и командной строки.
Обратите внимание, что каждая услуга, о который мы будем рассказывать, создается в отдельном регионе, зоне доступности или пуле. Сделано это намеренно, чтобы у читателя появилось понимание, как отказоустойчивость обеспечивается на практике.
Облачная платформа
Облачная платформа включает в себя много услуг и сервисов, которые условно можно разделить на четыре группы.
1. Облачные серверы — основа всей облачной платформы, на них построена большая часть услуг. Функционируют они на базе физических серверов, являющихся хостами виртуализации, которые «нарезаются» гипервизором на отдельные виртуальные машины. На самом деле, когда речь заходит о работе облачного провайдера, то чаще всего подразумеваются целые кластеры хостов, состоящих из множества физических серверов.
Технические характеристики хостов определяют доступные конфигурации виртуальных машин. Серверы могут предлагаться как с предустановленным набором компонентов, так и с произвольным, когда клиент сам выбирает вычислительные мощности. Например, могут потребоваться машины с увеличенным числом процессоров, дополнительным объемом оперативной памяти, наличием или отсутствием локальных дисков, а также другими особенными параметрами.
2. Облачные сети — термин в значительной степени условный. Тем самым мы подчеркиваем, что соединения создаются программным обеспечением, работающим на хостах.
Сети — один из важнейших элементов облачной платформы, своего рода кровеносная система, без которой не работал бы ни один сервер. Рассмотрим для примера облачные серверы. У клиента есть внешний адрес и виртуальная машина. В Selectel он получает готовые решения: Kubernetes, облачные базы данных, файловое хранилище, балансировщик и другие сервисы.
3. Наконец, третья основополагающая группа облачной платформы — это готовые решения, то есть совокупность технической инфраструктуры с предустановленной операционной системой, программным обеспечением и поддержкой. Клиент получает услугу, но не имеет доступа к ее управляющей части.
Для примера взглянем на кластеры Kubernetes. Можно как угодно работать с worker-нодами, но не получится повлиять на master-ноды. Мы сами обновляем ПО кластера, закрываем обнаруживаемые уязвимости, восстанавливаем при необходимости доступ клиента к кластеру. Невозможно что-то «испортить» на управляющем сервере — во власти пользователей только то, что не влияет на работу основной услуги.
4. Прочее — четвертая группа, к которой можно отнести сопутствующие инструменты: балансировщики нагрузки, Container Registry, менеджер секретов и другие вспомогательные средства. Останавливаться на каждом из них мы не будем — все подробно описано в нашей документации.
С тремя первыми группами мы будем плотно работать в процессе изучения этого цикла статей. Четвертую группу, «Прочее» оставляем читателю для самостоятельного исследования, потому что она не влияет прямо на масштабирование инфраструктуры.
Сети
Сети — один из основных сервисов, которые предоставляет Selectel. Кратко перечислим их виды, с которыми будем работать в рамках статьи.
Классификация и устройство
1. Внешние сети. Мы начнем с примера, где у выделенного сервера будет один внешний доступ, для чего возьмем IP‑адрес из общей сети.
2. Локальные сети по архитектуре разделяют на две группы.
- Сети уровня L2: два сервера работают внутри одного VLAN. Например, есть группа серверов в дата‑центре: используется один VLAN и одна адресация 192.168.0.0/24, при этом серверы видят друг друга без дополнительных настроек.
- Сети уровня L3VPN (актуальное название — глобальный роутер): серверы расположены в разных дата‑центрах с изолированной сетевой инфраструктурой.
L3VPN позволяет создавать безопасные и изолированные сети передачи данных на основе общей инфраструктуры. Протоколы маршрутизации управляют трафиком между удаленными узлами, не затрагивая общую сеть провайдера. Такой подход используется повсеместно для организации передачи данных между филиалами организаций, а также другими участниками бизнес‑сообщества.
В L3VPN применяется механизм инкапсуляции, обычно в виде MPLS (Multiprotocol Label Switching), который обеспечивает передачу пакетов данных с присвоением меток. Это позволяет не анализировать отдельные адреса назначения, что значительно повышает скорость и уменьшает задержки.
Если внешние сети не создают сложностей для клиентов, то локальные часто требуют более глубокого анализа и экспертизы, поскольку необходимо обеспечить безопасность инфраструктуры.
Локальная сеть позволяет создать безопасный сетевой контур с контролируемой точкой входа и выхода трафика — например, через облачный файрвол или сервер, выполняющий его функции. Обычно доступ к внешней сети необходим только одному серверу, в то время как остальные выполняют менее приоритетные задачи, уменьшая нагрузку на фронтенд. Яркий пример — кластеры Kubernetes, в которых локальная связность играет основную роль, а внешний адрес используется либо для управления, либо для балансировки нагрузки при доступе к приложению из внешней сети.
3. Выделенные сети подразделяются на две группы.
Публичные подсети — это общее понятие, которое позволяет заказывать сети размером от /29 и больше. Для выделенных серверов доступен размер от /28.
Публичные IP. Несмотря на схожесть названия с предыдущим пунктом, для заказа доступен только один IP‑адрес — это ограничение облачной платформы. В случае выделенных серверов стартовый IP предоставляется из общего диапазона — его нельзя расширить, но можно заменить на публичную подсеть /28 или больше.
Отличительная черта работы публичного IP заключается в том, что он функционирует за NAT. А еще его можно использовать только в сочетании с облачным роутером, который обеспечивает проброс портов и доступ в сеть в целом.
Таким образом, облачные серверы могут быть интегрированы в приватную сеть даже без доступа к интернету, который можно при необходимости подключить с использованием роутеров и публичных IP-адресов.
Сегментирование
Важно остановиться на таких понятиях, как пулы, зоны доступности и регионы. Эти термины играют ключевую роль в организации и распределении инфраструктуры.
- Пулы — это совокупности ресурсов, которые можно использовать для оптимизации работы приложений. Они обеспечивают эффективное распределение вычислительных мощностей и управляемых сервисов.
- Зоны доступности — изолированные области внутри региона, которые помогают повысить надежность и устойчивость сервисов. Наличие нескольких таких зон позволяет минимизировать риски потенциальных сбоев и обеспечить высокую доступность ресурсов.
- Регионы — географически распределенные группы зон доступности, позволяющие создавать избыточные системы и обеспечивать их масштабируемость.
Понять термины будет проще на конкретном примере. Посмотрим на организацию наших дата-центров на Северо-западе.
Мы создали несколько ЦОД, каждый из которых представляет собой отдельное здание с независимой сетевой инфраструктурой, и распределили их по зонам доступности. Зоны делятся на пулы, которые состоят из сегментов. В контексте нашей работы мы будем использовать термин «пул доступности».
Сегменты же представляют собой кластеры, которые содержат множество хостов с виртуальными машинами. Они имеют общую сеть, что позволяет легко настроить элементарное резервирование. Если один хост выходит из строя, остальные серверы, находящиеся в соседних сегментах, продолжают функционировать без перебоев.
Важно отметить, что каждая зона доступности изолирована от других и не имеет с ними общей сети, что обеспечивает дополнительную защиту. Сосредоточение серверов в одном сегменте могло привести к их появлению на одном хосте. Сегментирование же минимизирует риски и гарантирует более устойчивую работу нашей инфраструктуры.
Глобальный и облачный роутеры
Для обозначения ключевых компонентов современного сетевого взаимодействия маршрутизацию часто подразделяют на глобальную и облачную.
Глобальные роутеры объединяют облачные локальные сети в рамках проекта и осуществляют маршрутизацию трафика включая международные линии передачи данных. Так, физически изолированные дата-центры получают сетевую связность.
Облачные роутеры — часть вычислительных платформ. Они служат для соединения с внешней сетью и позволяют динамически настраивать сеть в зависимости от потребностей пользователей.
Возможности глобального роутера:
- Объединение изолированных локаций.
- Разделение на отдельный VLAN в каждой локации.
- Реплика на случай недоступности основного глобального роутера..
- Подключение BGP (Border Gateway Protocol, — это протокол динамической маршрутизации).
- Гибкая настройка статических маршрутов.
- Раздача трафика на все локации с одного устройства.
Глобальный роутер — виртуальный. Несмотря на то, что в его основе лежит физическое устройство, каждый клиент получает свой независимый экземпляр. Такое разделение гарантирует, что пересечение с маршрутами других клиентов никогда не случится. Ни конкуренты, ни случайные соседи по дата-центру не смогут перехватить трафик частной сети даже при совпадении адресации в используемых услугах.
В пределах одного виртуального роутера используется одна таблица маршрутизации, что накладывает некоторые ограничения при настройке. Адресация в разных VLAN/VXLAN не должна пересекаться или повторяться. Даже на домашнем роутере не получится настроить одну сеть на разных VLAN. Аналогично и глобальный роутер не позволит добавить в одну сеть одинаковые адресации и сделать вид, как будто есть связность L2, а не L3VPN.
Сетевые маршруты
На каждом устройстве, будь то любой роутер или сервер, существуют два видов маршрутов:
- статические,
- динамические.
Динамическая маршрутизация используется в глобальном роутере и никакого вмешательства со стороны пользователей не требует — ее рассматривать не будем, а познакомимся с особенностями статической маршрутизации.
Для упрощения и лучшего понимания условно разобьем статические маршруты на два типа:
- для подключения к определенной сети с точным указанием как сетевого адреса, так и шлюза;
- для обработки пакетов данных, адресованных к сетям, не находящимся в таблице маршрутизации (маршрут или шлюз по умолчанию).
Разные услуги используют различные сети — для доступа к ним потребуется задать маршрутизацию. Это можно сделать несколькими путями:
- Вручную на сервере. Такой способ доступен для облачной платформы, а для настройки выделенных серверов является вообще единственным.
- В свойствах сети облачной платформы указать автоматическую настройку — это можно сделать как через панель управления так и через клиента OpenStack.
Глобальный роутер осведомлен обо всех своих участниках и это его свойство изменить невозможно. Все сети, которые добавляются в глобальный роутер, между собой связываются автоматически. Если требуется контроль доступа между сетями, то его необходимо создавать при помощи маршрутов на самих серверах или устройствах, выполняющих роль маршрутизатора.
Схема будущей сети
Любая работа по выстраиванию распределенной инфраструктуры начинается с планирования схемы сетевых соединений. Мы планируем объединить:
- выделенный сервер,
- два облачных,
- файловое хранилище,
- базы данных,
- Kubernetes.
Один из облачных серверов будет сконфигурирован с использованием шлюза, который направляет трафик на облачный роутер. Другой подключится к глобальному роутеру через шлюз по умолчанию. Такой подход позволит эффективно распределять потоки данных, оптимизирует работу сети и упростит взаимодействие между различными сервисами.
Обратите внимание на региональное разделение. Каждый сервер и услуга создаются в отдельной зоне доступности. Как мы говорили в начале, такой пример поможет лучше понять возможности глобального роутера и принципы георезервирования. Умение работать с геораспределением будет иметь большое практическое значение в будущем: повышается надежность и скорость доступа к услугам, минимизируются риски в случае локальных сбоев.
В следующей части мы перейдем от теории к практике и реализуем нашу схему сети. Потребуется много работы в панели управления, конфигурационных файлах YAML и командной строке. Подпишитесь на нашу рассылку, чтобы не пропустить продолжение.
