Здравствуйте! Меня зовут Гордиенко Андрей, я ведущий специалист в отделе поддержки облачных услуг в Selectel. За пять лет работы в компании я накопил некоторый опыт учета запросов клиентов выделенных серверов и облачных услуг. В статье расскажу о настройках сети, панели управления, особенностях готовых решений Selectel, немного об OpenStack. Затронем ошибки, с которыми сталкиваются клиенты при кастомизации. Все необходимые скриншоты панели управления и схемы конфигурации серверов будут приложены.
Статья будет полезна начинающим проектировщикам инфраструктуры, администраторам, предпринимателям, которые планируют свой бизнес и хотят быть в курсе того, что и зачем делают их специалисты по IT‑инфраструктуре. Матерым админам с большим багажом знаний статья раскроет тонкости работы с ресурсами в Selectel, и расскажет, на что следует обратить внимание и почему, а также поможет избежать трудностей в работе.
Данная статья — вторая из серии публикаций, посвященных настройке сетей. Первая часть — «Основы настройки сети: определения, типовые схемы, особенности».
Используйте навигацию, если не хотите читать текст полностью:
→ Примеры
→ Базовые правила сетевой безопасности
→ Атаки на отказ в обслуживании
→ Выделенный сервер
→ Облачный сервер
→ Заключение
Примеры
Для чего вообще может потребоваться масштабирование и почему следует предпочесть облако? Почему не заказать сервер помощнее или взять еще один, дополнительный? Я, возможно, кого‑то расстрою, но сервер «с запасом» — плохое решение. Причин две: бесконечный рост нагрузки в случае успешного развития бизнеса и невозможность заранее точно рассчитать бюджет. Для лучшего понимания возьмем два базовых кейса.
Пример 1
Рассмотрим интернет-магазин, сайт которого размещен на выделенном сервере.
В июне ожидается поток туристов и увеличение количества заказов. Критически важно, чтобы веб‑ресурс «не упал», и все заявки своевременно обрабатывались. Встает вопрос о быстром масштабировании и переносе части нагрузки на облачные сервисы — серверы или базу данных. Можно воспользоваться Kubernetes, однако помним условие: точные расчет бюджета и оценка финансовых возможностей.
Начинаем с малого. Пока посещаемость невысокая, выделенный сервер с развернутым на нем интернет‑магазином и каким-то приложением вполне справляется. Но вот прошла рекламная компания… Трафик увеличивается кратно, надо что‑то предпринимать: снимать часть нагрузки, искать более отказоустойчивые решения.
Можно задействовать дополнительные серверы, каждый из которых будет отвечать за свою часть. Но как быстро их удастся ввести в работу? И что делать после падения потока посетителей?
Другой путь — для дополнительных возможностей или даже нового проекта подключить облачный сервер, который будет работать совместно с имеющимися. Он удобен благодаря почасовой оплате, возможности заморозки ресурсов после падения на них спроса и способности полностью приостановить работу в межсезонье — все это позволяет существенно экономить средства во время простоя.
Пример 2
Бизнес планирует расширять свои возможности. Необходимо добавить к имеющемуся сервису дополнительную функциональность или разработать услугу, которая будет работать совместно с основной.
Чтобы не вносить изменения в рабочий код или не разворачивать сырой продукт на приносящем доход сервере, как раз и пригодится облачная платформа. Можно создать тестовый стенд, развернуть на нем новое решение и не переживать, что его работа негативно повлияет на сервер, непосредственно выполняющий задачи бизнеса. Дополнительный же сервер можно перезагружать, проводить на нем эксперименты — одним словом, делать все необходимое для разработки и тестирования. Немаловажна и финансовая составляющая: сервер можно замораживать, тем самым существенно экономя средства.
Дополнительный пример
Краеугольный камень благополучного роста любого бизнеса или проекта — стабильность и отказоустойчивость. Максимально близко мы к этому подойдем позже — тогда уже ни выделенные, ни облачные серверы не будут нужны.
Мы не говорим о бизнес-гигантах, когда наряду с отказоустойчивостью требуются высочайшие вычислительные мощности. Подобный уровень подразумевает свою специфику, выходящую за рамки этой статьи. Но и такой вариант мы можем реализовать, основываясь на рассматриваемых примерах — суть одна.
Вводные по кейсу понятны. Перейдем к созданию виртуального сервера, после чего объединим его в локальную сеть с продовым.
Базовые правила сетевой безопасности
Вопросами безопасности следует озаботиться до установки связности серверов и описания всевозможных настроек. Разумеется, перечисленное ниже — не все, что известно о защите и надежности. Но именно на эти постулаты мы будем опираться при создании нашей инфраструктуры.
- Размещайте виртуальные машины в приватной сети за роутером или сервером, выполняющим его роль.
- Давайте публичный доступ к серверу лишь тогда, когда это действительно необходимо.
- Держите порты закрытыми — открывайте исключительно нужные.
- Разрешайте доступ только с доверенных IP‑адресов и подсетей.
Атаки на отказ в обслуживании
DDoS‑атаки актуальны как никогда. Наша инфраструктура не должна захлебнуться из-за одного выхода во внешнюю сеть. Раз мы зарабатываем на проекте в интернете, то просто обязаны предотвращать подобные угрозы. Никто за нас этого не делает.
Selectel бесплатно обеспечивает базовую защиту от DDoS на уровнях L3−L4 модели OSI.
Обратите внимание, что сюда не входит защита доменов — работа производится только с IP‑адресами, а фильтрация выполняется по протоколам TCP и UDP. Защита доменов работает на уровне L7, при этом фильтрация осуществляется по протоколам HTTP/HTTPS. Подобные меры подразумевают специализированные решения: Selectel предлагает продукты от вендоров Qrator и DDoS-Guard.
Балансировка трафика
Есть несколько способов защитить свой ресурс от атаки, направленной на отказ в обслуживании. В их основе, как правило, резервирование рабочего сервера другим аналогичным.
Со стороны нетехнических специалистов часто встречается недопонимание — когда речь заходит про защиту от DDoS, всплывает вопрос про бэкапы.
Бэкапы позволяют сохранить данные. Доступность же ресурса из сети при искусственной перегрузке обеспечивает именно резервный сервер.
Казалось бы: арендуемый сервер обязан быть безупречным и никакие бэкапы и резервы требоваться не должны. Однако такое представление ошибочно, оно может обернуться существенными финансовыми потерями, значительно превышающими стоимость подстраховки дополнительным сервером.
Selectel предлагает два решения этого вопроса.
- Облачный балансировщик — распределяет трафик между серверами в облачной платформе, но только в рамках одной зоны доступности — например ru-1a, ru-1b, ru-1c. Такой подход позволяет настроить базовые меры и распределить нагрузку на используемый домен между пулами, тем самым защитив от непредвиденных ситуаций на хостах.
- Отказоустойчивый балансировщик — распределяет нагрузку между дата‑центрами Selectel. Примеров может быть много: мощный выделенный сервер и резервный облачный, серверы в Москве и Санкт-Петербурге — ни одна зона доступности не будет перегружена. Управление параметрами такого балансировщика выполняется по запросам в тикет-системе.
Именно масштабы проектов и целей определяют выбор вида балансировщика.
Файрвол, или межсетевой экран
Второй способ частичной защиты инфраструктуры от атаки перегрузкой — фильтрация трафика и ограничение подключений. Такую защиту предоставляет любой файрвол, но в Selectel разработаны несколько специализированных решений.
- Базовый вариант — когда клиент использует один из серверов в качестве точки выхода во внешнюю сеть, при этом самостоятельно настраивает любой предпочитаемый файрвол, будь то брандмауэр для Windows или один из множества возможных вариантов на Linux.
- Файрвол для облачной платформы и базовый файрвол для выделенных серверов — два решения, которые пока находятся в стадии бета‑тестирования и предлагаются бесплатно. Настройка выполняется по классическому сценарию: все что не разрешено, то запрещено. Внедрение правила в базовый файрвол приводит к полному блокированию неразрешенного явно трафика. Облачный файрвол функционирует аналогично: его активация мгновенно прекращает любой трафик в сети, которая подключена к маршрутизатору.
- Физический файрвол — аппаратное устройство для управления трафиком. Selectel предлагает два решения: Fortinet FG-100E и межсетевой экран Selectel на базе UserGate. В нашей документации описано, как его можно развернуть в облаке, создав из образа сервер.
Подробнее прочитать о межсетевых экранах, моделях оплаты, а также найти дополнительные материалы можно в нашей документации.
Мы предоставляем все для защиты от DDoS‑атак, консультируем, даем развернутую и детальную информацию. На странице «Информационная безопасность как услуга» есть исчерпывающий перечень наших продуктов ИБ.
Следует помнить: защита ресурсов клиента также требует участия и с его стороны. На странице «Безопасность в Selectel» есть иллюстративная таблица, описывающая зоны ответственности.
Следует тщательно рассчитывать нагрузку на проект, подбирать инструменты сообразно его масштабам. Необходимо также соотносить затраты на безопасность с ущербом, в том числе репутационным, от недоступности сервиса из-за действий злоумышленников.
Далее мы рассмотрим функции балансировщика в комплексе работы кластера Kubernetes — как его точку доступа во внешнюю сеть. Физический файрвол можно воспринимать как обычный сервер, настройки которого выполняются по аналогии. Принципы маршрутизации и конфигурации внешнего доступа остаются неизменными. Облачные же решения не требуют дополнительных настроек — все параметры указываются в свойствах самой сети. Детали мы рассмотрим ниже, когда коснемся автоматической настройки сервера. Добавляя правила будем учитывать, что при совпадении условий верхнее правило перекрывает нижнее.
Выделенный сервер
Предположим, что мы планируем запустить стартап, либо у нас уже есть небольшое приложение или веб-сервер. Возьмем выделенный сервер стоечного типа с консолью и локальным портом.
Линейка Chipcore такими возможностями не обладает — добавить в локальную сеть можно только одну из множества предопределенных конфигураций.
Конфигурация сети сервера /etc/netplan/50-cloud-init.yaml:
network: ethernets: id0: addresses: - 212.41.13.140/24 gateway4: 212.41.13.1 match: macaddress: ac:1f:6b:28:87:24 nameservers: addresses: - 188.93.17.19 - 188.93.16.19 renderer: networkd version: 2
Сейчас у нас есть сервер с выделенным IP‑адресом и не настроенной локальной сетью. Так как нет других участников сети пока нет, настройкой локального порта займемся позже.
Конфигурация на Ubuntu 20 LTS по умолчанию настраивается в Netplan — утилите для конфигурации сетевых подключений в операционных системах на базе Linux. Вместо интерфейса id0 из нашего примера нужно указать правильный — это может быть, например, eth0 или eth1. При использование интерфейса вида idX не забудьте указать его MAC‑адрес, который можно подсмотреть с помощью команды ip:
ip link
Облачный сервер
Настал тот момент, когда к выделенному серверу требуется добавить облачный.
Это будет самая большая глава. На ее примере мы узнаем, как функционирует сеть в облачной платформе, фундаментом всех сервисов которой и являются облачные серверы. Именно на их примере можно предсказать как поведет себя любое готовое решение, например файловое хранилище, скажем через три года когда потребуется внести в него какие-либо изменения.
На примере облачных серверов мы можем глубже понять работу готовых решений в Selectel. Это поможет в будущем уверенно управлять сервисами даже после обновлений конфигурации или расширения кластера Kubernetes. Моя задача — помочь вам настроить все так, чтобы не возникало никаких неожиданностей.
Шаг 1. Создаем сеть
Перед развертыванием облачного сервера и переносом на него каких-либо сервисов, необходимо тщательно продумать способ их взаимодействия. Внешняя сеть — возможный вариант, однако такой способ имеет ряд существенных недостатков:
- низкий уровень безопасности;
- занимает внешний канал, который при высокой нагрузке будет использоваться еще и для локального трафика;
- требуется контроль не менее двух точек выхода во внешнюю сеть с тонкой настройкой межсетевого экрана — только так можно обеспечить безопасность.
В такой архитектуре трудно найти положительные моменты кроме того, что настройка сети чуть проще, так как не требует дополнительных маршрутов. Ранее мы упоминали базовые правила безопасной сети, от них и будем отталкиваться.
Создадим локальную сеть. Это можно сделать вместе с сервером, после чего добавить глобальный роутер. Или заранее в рамках глобального роутера, а уже после использовать ее при развертывание сервера.
Первый случай — на скриншоте:
Добавление локальной локальную сети к глобальному роутеру.
Обратите внимание: там, где сеть подключена к глобальному роутеру, есть соответствующая пометка. На сети без роутера пометки нет, но есть кнопка подключения. Следующим действием потребуется указать, какой IP‑адрес мы выделим роутеру, а какие — для VRRP. Этот вариант возможен, когда сеть уже в работе и потребовалось расширить облачную платформу.
VRRP (Virtual Router Redundancy Protocol) — сетевой протокол, который предоставляет механизм автоматической настройки резервных маршрутизаторов для повышения отказоустойчивости IP-сетей. Основная цель — обеспечение непрерывности сетевых услуг при отказе основного маршрутизатора.
Отдельно остановлюсь на VRRP. Это адреса резервных роутеров, между которыми будет мигрировать шлюз в случае выхода из строя одного из них. Selectel использует этот протокол для резервирования сети и обеспечения базовой отказоустойчивости. Отключить эти адреса нельзя, можно только использовать статические маршруты.
Второй вариант правильнее. Если мы создаем все с нуля, то предварительно подготовить сети — верное решение, так как заранее будем представлять схему и ясный план дальнейших действий. Рекомендую всегда иметь понятное и актуальное описание собственной инфраструктуры, иначе при ее развитии собирать все воедино будет сложнее.
В нашей документации подробно описано создание сети в глобальном роутере.
Нам нужно определиться с тем, какую маску подсети будем использовать в локальной сети. Я возьму маску для больших сетей /24 — так и понимать, и считать проще. Вы можете брать сети меньшей размерности, в зависимости от планов.
Если используется маленькая сеть, то нужно точно понимать масштаб проекта в перспективе. Хорошо бы иметь хотя бы небольшой запас. Если адресация закончится, всегда можно найти решение — например, добавить еще одну сеть к существующей или переместиться на другую сеть с бо́льшей адресацией. Разница в нагрузке на ротуер при использования сетей /29 и /24 несущественная.
Хорошим примером, когда точно следует использовать маленькую сеть может послужить работа с динамическими маршрутами. В BGP использовать сети больше /29 бессмысленно. Обычно можно ограничиться /30, но так как в Selectel два адреса забирает VRRP, остается минимум /29.
Назначаем выделенному серверу сеть 172.22.10.2/24. Пример конфигурации ниже:
network: ethernets: id0: addresses: - 212.41.13.141/24 gateway4: 212.41.13.1 match: macaddress: ac:1f:6b:28:87:54 id1: addresses: - 172.22.10.2/24 match: macaddress: ac:1f:6b:28:87:55 nameservers: addresses: - 188.93.17.19 - 188.93.16.19 renderer: networkd version: 2]
Выше приведен образец — вы должны привести свою актуальную конфигурацию к похожему виду. Чтобы изменения вступили в силу:
netplan apply
Проверяем параметры сети:
ip a 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether ac:1f:6b:28:87:54 brd ff:ff:ff:ff:ff:ff altname enp2s0f0 inet 212.41.13.141/24 brd 212.41.13.255 scope global eth0 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether ac:1f:6b:28:87:55 brd ff:ff:ff:ff:ff:ff altname enp2s0f1 inet 172.22.10.2/24 brd 172.22.10.255 scope global eth1
Отлично. Теперь создаем сети для облачной платформы. Облачные серверы будут расположены в двух зонах:
- Ru-1 192.168.0.0/24 — глобальный роутер 192.168.0.1, VRRP 192.168.0.253-254;
- Ru-9 192.168.100.0/24 — глобальный роутер 192.168.100.254, VRRP 192.168.100.252-253.
Создание подсетей для облачных платформ.
Глобальный роутер создан и теперь можно работать. Обратите внимание, что я намеренно создал сети с разными шлюзами (он же IP‑адрес глобального роутера). Далее раскрою для чего это сделано.
Шаг 2. Создаем серверы
Подготовка стенда
Сервера будет создано два — так же, как было создано две сети, чтобы продемонстрировать работу автоматической и ручной настройка маршрутов. Как изменится конфигурация сети, если поменять ее параметры «на горячую» и что будет, если мы создадим новые серверы с обновленными параметрами?
Давайте сразу настроим сети по‑разному, так как это может пригодиться в дальнейшем. Пусть одна из них работает со шлюзом по умолчанию через глобальный роутер, другая — через облачный.
Действия с облачными роутерами не пригодятся для объединения сетей, но помогут в понимании принципов их работы.
Что произойдет, когда мы будем работать с услугами, которые не предоставляют полного доступа — например, Kubernetes? Как поведет себя сеть в случае ошибочных настроек со стороны клиента?
Представим два случая.
- Нужен интернет внутри локальной сети — для этого потребуется добавить облачный роутер и подключить к нему сеть глобального роутера.
- Нужна изолированная сеть без внешнего доступа, чтобы исключить возможность взлома.
На самом деле, кейсов можно придумать множество, но для простоты ограничимся двумя.
Вариант сети
Начнем с варианта, который основан исключительно на локальной сети без внешнего доступа. Создав две виртуальные машины, мы получили хорошую возможность показать настройки сети как при помощи Cloud-init, так и вручную через правки конфигурационных файлов. Серверы возьмем также на базе Ubuntu 20 LTS. В зонах ru-1 и ru-9 — по одной сети.
Перед созданием сервера рассмотрим подробнее параметры сети, которая создается в карточке облачной платформы.
Обратите внимание, что у одной и той же сети есть два комплекта свойств. Первый относится к работе глобального роутера, второй — к облачной платформе.
Свойства приватной сети: порты.
На первой вкладке Порты мы можем посмотреть к каким сетевым интерфейсам была добавлена эта сеть. На данный момент у нас есть четыре порта: три, относящихся к глобальному роутеру (описаны выше), и один на уже существующем сервере. Сейчас нас интересуют три порта глобального роутера.
Свойства приватной сети: подсети.
Вкладка Подсети нас интересует больше. Мы видим саму сеть 192.168.0.0/24. Однако это не означает, что мы можем использовать для работы только ее. Это говорит о том, что именно с этой сетью OpenStack и Cloud-init будут взаимодействовать для автоматической настройки ее параметров. Дальше мы увидим, для чего требуется Cloud-init и почему все параметры сети изначально прописываются в файлах именно этой утилиты.
Обратите внимание на шлюз по умолчанию — сейчас он соответствует шлюзу глобального роутера. Ранее, когда мы создавали сети для облачной платформы, то назначили глобальному роутеру именно 192.168.0.1. Остальные параметры нас пока не интересуют, но мы к ним еще вернемся.
Создание серверов
Создаем серверы и в разделе Сеть выбираем заготовленную ранее подсеть.
Начнем с зоны ru-1. Последовательность действий неважна, но я хочу, чтобы в ru-1 была только локальная сеть, а в ru-9 трафик по умолчанию шел через облачный роутер. При этом можно использовать и любой другой шлюз — например, если создается виртуальная машина на routerOS. Я буду использовать облачный роутер.
Получаем следующую конфигурацию при создании сервера:
Конфигурирование сервера.
Проверяем, что же получилось на самом сервере. Напомню, что на выделенном сервере приходилось настраивать все вручную, облачная платформа же лишена этого недостатка.
Консоль управления сервером: получение таблицы маршрутизации с помощью утилиты ip.
Проверка сетевой связности
На этом этапе я использую скриншоты, так как не могу подключиться к создаваемому серверу извне — например, с другого сервера. Давайте проверим доступность выделенного сервера и глобального роутера в локациях ru-1 и SPB-5 — там, где они расположены физически.
Консоль управления сервером: проверка доступности IP‑адреса утилитой ping.
Все отлично! Связность присутствует не только внутри каждой локации, но и между ними. Давайте же проверим сетевую доступность серверов и выясним, что же пошло так или не так. Все примеры — на выделенном сервере.
Проверим работоспособность шлюза глобального роутера:
root@Boole:~# ping 172.22.10.1 PING 172.22.10.1 (172.22.10.1) 56(84) bytes of data. 64 bytes from 172.22.10.1: icmp_seq=1 ttl=64 time=1.12 ms 64 bytes from 172.22.10.1: icmp_seq=2 ttl=64 time=1.31 ms 64 bytes from 172.22.10.1: icmp_seq=3 ttl=64 time=0.714 ms ^C --- 172.22.10.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.714/1.049/1.310/0.248 ms
Доступ к глобальному роутеру в SPB-5 есть. Отлично! Однако в этом нет ничего удивительного — и сервер и роутер расположены в одной сети. Проверяем доступность ru-1:
root@Boole:~# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. ^C --- 192.168.0.1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2041ms
Зона ru-1 недоступна — так же, как и виртуальный сервер. Разберемся почему.
Дополнительная настройка сетей
Сетевое подключение у облачного сервера есть по причине, о которой мы говорили в самом начале, где обсуждали статические маршруты и их виды в рамках статьи.
При создание сети в облачной платформе мы указали default 192.168.0.1 — адрес, который прописан в параметрах сети и глобального роутера, и облачной платформы. Посмотрим конфигурацию маршрутов на облачном сервере:
Консоль управления сервером: получение таблицы маршрутизации с помощью утилиты ip.
В выводе маршрутов видно, что default указан так же, как и в карточке сети: 192.168.0.1. Значит весь трафик, который явно не перенаправляется куда‑то еще, идет на шлюз. Шлюзом является глобальный роутер, который знает обо всех участниках сети. Подытоживая: если мы отправляем весь трафик на глобальный роутер, то дополнительные маршруты не требуются.
Взглянем пристальнее на выделенный сервер:
root@Boole:~# ip r default via 212.41.13.1 dev eth0 proto static 172.22.10.0/24 dev eth1 proto kernel scope link src 172.22.10.2 212.41.13.0/24 dev eth0 proto kernel scope link src 212.41.13.141
В маршрутах видим default на внешний адрес — значит, весь трафик, который не указан в явном виде, отправляется на него. Из внешней же сети достучаться до адресов 192.168.0.0/24 не получится. Обратите внимание на подсказки: интерфейсы сетей локального и внешнего трафиков:
- 172.22.10.0/24 dev eth1
- 212.41.13.0/24 dev eth0
Весь остальной трафик перенаправляется на адрес по умолчанию. Добавляем маршруты согласно статье «Пример настройки доступа в интернет для выделенного сервера через облачный роутер» (раздел про определение маршрута на выделенном сервере).
Конфигурация выделенного сервера будет выглядеть следующим образом:
network: ethernets: id0: addresses: - 212.41.13.141/24 gateway4: 212.41.13.1 match: macaddress: ac:1f:6b:28:87:54 id1: addresses: - 172.22.10.2/24 match: macaddress: ac:1f:6b:28:87:55 nameservers: addresses: - 188.93.17.19 - 188.93.16.19 routes: - to: 192.168.0.0/24 via: 172.22.10.1 renderer: networkd version: 2
Добавили параметр routes, где явно указано, что сеть 192.168.0.0/24 нужно искать на шлюзе 172.22.10.1 — именно его мы выбрали в качестве шлюза для глобального роутера в SPB-5.
Проверяем доступность соседней локации, включая облачный сервер:
root@Boole:~# ping 172.22.10.1 PING 172.22.10.1 (172.22.10.1) 56(84) bytes of data. 64 bytes from 172.22.10.1: icmp_seq=1 ttl=64 time=2.00 ms 64 bytes from 172.22.10.1: icmp_seq=2 ttl=64 time=0.678 ms ^C --- 172.22.10.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.678/1.340/2.003/0.662 ms root@Boole:~# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.46 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.430 ms ^C --- 192.168.0.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.430/1.446/2.463/1.016 ms
Все локации доступны. Наконец, убеждаемся в сетевом соединении с облачным сервером:
root@Boole:~# ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. 64 bytes from 192.168.0.2: icmp_seq=1 ttl=63 time=0.620 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=63 time=0.339 ms 64 bytes from 192.168.0.2: icmp_seq=3 ttl=63 time=0.394 ms ^C --- 192.168.0.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2052ms rtt min/avg/max/mdev = 0.339/0.451/0.620/0.121 ms
Все отлично! Связанность установлена без нареканий, мы можем подключиться к облачному серверу через выделенный сервер:
root@Boole:~# ssh root@192.168.0.2 The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established. ECDSA key fingerprint is SHA256:8DSQDueXTCxopZ71GYqogPmuu8napn0Eu/pFjurfFy8. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.0.2' (ECDSA) to the list of known hosts. root@192.168.0.2's password:
В принципе, нас можно поздравить. Мы расширили свою инфраструктуру. Имеем одну точку выхода во внешнюю сеть. Можем в любой момент заморозить облачный сервер для снижения финансовой нагрузки. В целом, изначальный план выполнен.
Подведем итоги
У нас есть два сервера: основной выделенный и вспомогательный облачный. «Из коробки» запустился только облачный сервер: по умолчанию его шлюз указан на глобальном роутере, в то время как выделенный сервер первоначально направляет трафик во внешнюю сеть. Сначала мы протестировали работу сети без указания маршрутов, затем добавили их на выделенном сервере.
Маршруты — важная часть сетевой настройки между регионами. Схему всегда нужно держать в актуальном состоянии, чтобы ясно видеть, куда именно может получать доступ тот или иной сервис. Например, облачный сервер, который мы создали ранее, имеет доступ ко всему трафику в локальной сети — иногда это нежелательно.
Не будем останавливаться на достигнутом и продолжим расширять наш сервис.
Шаг 3. Добавляем еще один облачный сервер
Второй сервер я хочу добавить для того, чтобы было понятно, что происходит на стороне любого готового решения облачной платформы.
Для начала немного вводных
Отличие сетей в зонах ru-1 и ru-9 в том, что в ru-9 маршрут по умолчанию направлен не на глобальный, а на облачный роутер. Следовательно, если не вносить изменения, облачный роутер не будет знать о других участниках глобального роутера.
Рассмотрим два скриншота панели. На первом из них — настройка сети в карточке глобального роутера. Нас интересует ru-9.
Балансировщик нагрузки.
Пробежимся по свойствам. CIDR — сеть, которая прописана в роутере. Шлюз — IP‑адрес, присвоенный глобальному роутеру. В столбце служебных IP‑адресов отображены VRRP‑адреса, о котором мы говорили ранее. Важный момент — это шлюз 19.168.100.254, запомним его.
Переходим к карточке этой же сети в облачной платформе:
Сеть облачной платформы: порты.
Здесь ничего не изменилось: мы видим порты, созданные в этой сети. Сейчас сервера в ru-9 нет, по этой причине есть только глобальный роутер.
Сеть облачной платформы: подсети.
На этой картинке тоже никаких изменений: шлюз подсети соответствует шлюзу глобального роутера.
Однако мы помним условие, которое хотели выполнить. Сеть в ru-9 должна направить нас по умолчанию на облачный роутер или любой другой сервер, отличный от 192.168.100.254. Поясню для чего это может быть полезно.
- Самое простое: мы можем захотеть использовать вторую точку выхода во внешнюю сеть и присвоить серверу в ru-9 плавающий IP‑адрес, который назначается при помощи облачного роутера. В таком случае сервер будет размещен за собственным NAT. Этот подход может пригодиться, например, при запуске бота, который не будет пользоваться каналом основного сервера.
- Если мы используем Kubernetes, то наличие внешнего доступа в кластере — обязательное условие. Подробностей коснемся, когда мы подойдем к подключению кластера.
На самом деле, причин может быть несколько, мы упомянули о двух самых распространенных.
Итак, каков порядок действий?
Подключаем подсети к облачному роутеру, как описано в документации. Затем выбираем IP‑адрес для облачного роутера: 192.168.100.1 — он свободен. Занятые IP‑адреса можно посмотреть по такому же принципу, как на скриншоте выше. Если роутера нет — создаем, как описано в инструкции.
Сеть облачной платформы: порты.
Продолжаем изучение сети. Теперь видно новый порт, принадлежащий облачному роутеру. Как можно заметить, глобальный роутер и облачный — два разных устройства, это важный для понимания момент.
Создадим сервер с теми параметрами, которые есть сейчас, и проверим его доступность. Настройки аналогичны первому серверу. Шлюз указываем тот, что в карточке:
Консоль управления сервером: получение таблицы маршрутизации с помощью утилиты ip.
Проверяем доступность всех смежных локаций и серверов — все в порядке. Но интернета у нас на сервере нет, что ожидаемо, так как шлюз указан на глобальный роутер. Наша цель — добиться доступа во внешнюю сеть. Для этого поменяем свойства сети в карточке сервера: напротив Шлюз сети нажимаем на «карандаш» и устанавливаем шлюз в значение 192.168.100.1, которое является адресом роутера.
Поменять шлюз можно не только в панели управления. Кому-то может показаться более удобным использовать интерфейс командной строки OpenStack, как описано в документации.
openstack subnet show <subnet_ID>
<subnet_ID> — идентификатор подсети глобального роутера, который можно подсмотреть так:
openstack subnet list
В каждой сети есть прописанный диапазон адресов, который OpenStack может выделить для серверов. Этот параметр мы удаляем, чтобы освободить 192.168.100.1, поскольку если он расположен в allocation-pool, то может использоваться для серверов, но не для служебных целей.
openstack subnet set --no-allocation-pool \ --allocation-pool start=<first_pool_IP>,end=<last_pool_IP> \ <subnet_ID>
В коде выше <first_new_pool_IP> — первый IP-адрес из нового пула, <last_new_pool_IP> — последний IP-адрес из нового пула. Можно добавить несколько пулов, каждый из которых задается с помощью опции —allocation-pool start=<first_pool_IP>,end=<last_pool_IP>. Добавим 192.168.0.1, который мы освободили предыдущей командой, в качестве адреса роутера:
openstack subnet set --gateway <cloud_router_IP> <subnet_ID>
Здесь <cloud_router_IP> — IP-адрес облачного роутера. Проверим, все ли в порядке с параметрами.
openstack subnet show <subnet_ID>
Сети облачной платформы: подсети.
На скриншоте выше отмечен новый шлюз. Проверяем, что произошло с созданным сервером.
Консоль управления сервером: получение таблицы маршрутизации с помощью утилиты ip.
Как ожидалось, ничего не произошло. Все параметры как были, так и остались, шлюз по умолчанию все так же направлен на 192.168.100.254. Все связанности сохранены. Выделенный и первый облачный серверы доступны. Чтобы Cloud-init «подцепил» изменения, сервер необходимо выключить и включить снова (перезагрузка иногда не помогает) или поправить конфигурацию вручную, если перезапуск невозможен.
Выполняем отключение сервера и включение обратно по питанию:
Консоль управления сервером: получение таблицы маршрутизации с помощью утилиты ip.
После перезагрузки шлюз по умолчанию изменился, доступ к смежным локациям пропал, но появился выход во внешнюю сеть. Исправить ситуацию — чтобы иметь доступ и в локальную, и во внешнюю сеть — помогут, как и в случае с выделенным сервером, дополнительные маршруты.
В случае выделенного сервера мы прописывали все маршруты вручную. Однако в облачной платформе скорость создания и пересоздания дополнительных стендов или серверов значительно выше благодаря гибкости платформы.
Чтобы не терять преимущество в быстроте развертывания, следует отказаться от ручной настройки. OpenStack позволяет единожды подготовить сеть, после чего все создаваемые в ней серверы будут настраиваться автоматически.
Пример конфигурирования сети в панели управления (указываем статические маршруты):
Свойства сетей облачной платформы: статические маршруты.
Вкладка Статические маршруты позволяет нам автоматически задавать маршруты на сервере. На скриншоте — пример для выделенного сервера. Действуя аналогично, нужно добавить все остальные сети. В случае нашего стенда — сеть до облачного сервера в ru-1.
Исходящая подсеть — это сеть, которая настроена в зоне ru-9. Подсеть назначения — та, куда мы хотим попасть. Шлюз (next-hop) — адрес глобального роутера или любого другого устройства в рамках исходящей сети.
При помощи OpenStack в интерфейсе командной строки можно добавить маршруты:
openstack subnet set --host-route destination=<subnet>,gateway=<ip-address>
Подробнее о работе с подсетями — в документации OpenStack.
Свойства сетей облачной платформы: статические маршруты.
На скриншоте выше не обращайте внимание на неизвестные сети — я их добавил для будущего проекта, поэтому они отображаются в панели управления. Сейчас главное — усвоить, как в итоге должен выглядеть список статических маршрутов, которые мы хотели бы видеть на сервере в облаке.
Теперь переходим к серверу — выключаем его и включаем обратно:
Консоль управления сервером: проверка доступности IP‑адреса утилитой ping.
Та же самая магия: у нас есть все маршруты, доступ к внешним ресурсам, при этом мы ничего не настраивали внутри операционной системы.
Заключение
Внесение изменений
К особенностям работы сети услуг я подойду в профильных главах, но у нас теперь есть четкое понимание того, что произойдет, если мы внесем изменения в рамках сети, и как они повлияют на работу сервиса. Опишу тезисно.
- Каждое «готовое решение», которое вы будете использовать, — это облачный сервер, только скрытый от глаз пользователя.
- Карточки сети в разделах глобального роутера и облачной платформы отражают одну и ту же сеть — только параметры отвечают за работу разных услуг. Нужно четко это разграничивать.
- Глобальный и облачный роутеры — разные устройства. Они не имеют ничего общего, поэтому не надо пытаться назначить им единый IP‑адрес.
- В карточке сети есть важные параметры, такие как сетевой шлюз и статические маршруты, — на них опирается в своей работе Cloud-init. Помните: если после создания сервера с ошибочными значениями их можно поправить вручную, то в Kubernetes так не получится.
- Самое главное! Изменения в карточке сервера до его перезагрузки не влияют на работу сети. Например. Пять лет назад было создано хранилище с некоторыми параметрами. Теперь их «подкрутили». Как будут развиваться события? Очень просто — хранилище не сломается до момента его расширения или плановых работ с перерывом связи. Когда такое произойдет, уверяю вас, в большинстве случаев никто не вспомнит, что менялось и как было раньше. Придется детально разбираться и в авральном режиме восстанавливать сетевую работоспособность.
Что мы сделали
- Рассмотрели два кейса при которых может потребоваться масштабирование.
- Узнали об инструментах, при помощи которых можно организовать связанность между сервисами.
- Внимательно изучили глобальный роутер и с чем его едят.
- Выполнили первичную настройку выделенного сервера, рассмотрели возможную конфигурацию.
- Подключили к серверу две виртуальные машины, использовали при этом два разных варианта настроек.
- И главное — увидели как параметры сети могут повлиять на работу услуг.
Что сделаем в следующий раз
Рассмотренные примеры с двумя серверами, конечно, необязательные. Однако они нам пригодятся в следующей части, когда мы приступим к работе с кластерами. Тогда на практике рассмотрим добавление услуг в нашу новую схему сети.
ссылка на оригинал статьи https://habr.com/ru/articles/867384/
Добавить комментарий