Выделенный и облачный серверы: создание, настройка, сетевая связность

О чем эта статья и кому она будет полезна

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

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

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

Для чего вообще может потребоваться масштабирование и почему следует предпочесть облако? Почему не заказать сервер помощнее или взять еще один, дополнительный? Я, возможно, кого‑то расстрою, но сервер «с запасом» — плохое решение. Причин две: бесконечный рост нагрузки в случае успешного развития бизнеса и невозможность заранее точно рассчитать бюджет. Для лучшего понимания возьмем два базовых кейса.

Пример 1

Рассмотрим интернет-магазин, сайт которого размещен на выделенном сервере.

В июне ожидается поток туристов и увеличение количества заказов. Критически важно, чтобы веб‑ресурс «не упал», и все заявки своевременно обрабатывались. Встает вопрос о быстром масштабировании и переносе части нагрузки на облачные сервисы — серверы или базу данных. Можно воспользоваться Kubernetes, однако помним условие: точные расчет бюджета и оценка финансовых возможностей.

Начинаем с малого. Пока посещаемость невысокая, выделенный сервер с развернутым на нем интернет‑магазином и каким-то приложением вполне справляется. Но вот прошла рекламная компания… Трафик увеличивается кратно, надо что‑то предпринимать: снимать часть нагрузки, искать более отказоустойчивые решения.

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

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

Пример 2

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

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

Дополнительный пример

Краеугольный камень благополучного роста любого бизнеса или проекта — стабильность и отказоустойчивость. Максимально близко мы к этому подойдем позже — тогда уже ни выделенные, ни облачные серверы не будут нужны. 

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

Вводные по кейсу понятны. Перейдем к созданию виртуального сервера, после чего объединим его в локальную сеть с продовым. 

Базовые правила сетевой безопасности

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

• Размещайте виртуальные машины в приватной сети за роутером или сервером, выполняющим его роль.
• Давайте публичный доступ к серверу лишь тогда, когда это действительно необходимо.
• Держите порты закрытыми — открывайте исключительно  нужные.
• Разрешайте доступ только с доверенных IP‑адресов и подсетей.

Атаки на отказ в обслуживании

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

Selectel бесплатно обеспечивает базовую защиту от DDoS на уровнях L3−L4 модели OSI. 

Обратите внимание, что сюда не входит защита доменов — работа производится только с IP‑адресами, а фильтрация выполняется по протоколам TCP и UDP. Защита доменов работает на уровне L7, при этом фильтрация осуществляется по протоколам HTTP/HTTPS. Подобные меры подразумевают специализированные решения: Selectel предлагает продукты от вендоров Qrator и DDoS-Guard.

Балансировка трафика

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

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

Selectel предлагает два решения этого вопроса.

Именно масштабы проектов и целей определяют выбор вида балансировщика.

Файрвол или межсетевой экран

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

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

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

Выделенный сервер

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

Конфигурация сети сервера:

      
/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. Это адреса резервных роутеров, между которыми будет мигрировать шлюз в случае выхода из строя одного из них. Selectel использует этот протокол для резервирования сети и обеспечения базовой отказоустойчивости. Отключить эти адреса нельзя, можно только использовать статические маршруты. 

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

Нам нужно определиться с тем, какую маску подсети будем использовать в локальной сети. Я возьму маску для больших сетей /24 — так и понимать, и считать проще. Вы можете брать сети меньшей размерности, в зависимости от планов.

Назначаем выделенному серверу сеть 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. Создаем серверы

Сервера будет создано два — так же, как было создано две сети, чтобы продемонстрировать работу автоматической и ручной настройка маршрутов. Как изменится конфигурация сети, если поменять ее параметры «на горячую» и что будет, если мы создадим новые серверы с обновленными параметрами?

Предварительная настройка сетей

Давайте сразу настроим сети по‑разному, так как это может пригодиться в дальнейшем. Пусть одна из них работает со шлюзом по умолчанию через глобальный роутер, другая — через облачный.

Представим два случая.

На самом деле, кейсов можно придумать множество, но для простоты ограничимся двумя.

Начнем с варианта, который основан исключительно на локальной сети без внешнего доступа. Создав две виртуальные машины, мы получили хорошую возможность показать настройки сети как при помощи 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. Я буду использовать облачный роутер.

Получаем следующую конфигурацию при создании сервера:

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

Проверка сетевой связности

На этом этапе я использую скриншоты, так как не могу подключиться к создаваемому серверу извне — например, с другого сервера. Давайте проверим доступность выделенного сервера и глобального роутера в локациях ru-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=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 — адрес, который прописан в параметрах сети и глобального роутера, и облачной платформы. Посмотрим конфигурацию маршрутов на облачном сервере:

В выводе маршрутов видно, что 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. Поясню для чего это может быть полезно.

На самом деле, причин может быть несколько, мы упомянули о двух самых распространенных. 

Итак, каков порядок действий?

Подключаем подсети к облачному роутеру, как описано в документации. Затем выбираем IP‑адрес для облачного роутера: 192.168.100.1 — он свободен. Занятые 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>

На скриншоте выше отмечен новый шлюз. Проверяем, что произошло с созданным сервером.

Как ожидалось, ничего не произошло. Все параметры как были, так и остались, шлюз по умолчанию все так же направлен на 192.168.100.254. Все связанности сохранены. Выделенный и первый облачный серверы доступны. Чтобы Cloud-init «подцепил» изменения, сервер необходимо выключить и включить снова (перезагрузка иногда не помогает) или поправить конфигурацию вручную, если перезапуск невозможен. 

Перезагружаем серверВыполняем отключение сервера и включение обратно по питанию:

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

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

Чтобы не терять преимущество в быстроте развертывания, следует отказаться от ручной настройки. OpenStack позволяет единожды подготовить сеть, после чего все создаваемые в ней серверы будут настраиваться автоматически.

Пример конфигурирования сети в панели управления (указываем статические маршруты):

Вкладка Статические маршруты позволяет нам автоматически задавать маршруты на сервере. На скриншоте — пример для выделенного сервера. Действуя аналогично, нужно добавить все остальные сети. В случае нашего стенда — сеть до облачного сервера в ru-1. 

Исходящая подсеть — это сеть, которая настроена в зоне ru-9. Подсеть назначения — та, куда мы хотим попасть. Шлюз (next-hop) — адрес глобального роутера или любого другого устройства в рамках исходящей сети.

При помощи OpenStack в интерфейсе командной строки можно добавить маршруты: 

openstack subnet set --host-route destination=<subnet>,gateway=<ip-address>

Подробнее о работе с подсетями — в документации OpenStack.

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

Теперь переходим к серверу — выключаем его и включаем обратно:

Та же самая магия: у нас есть все маршруты, доступ к внешним ресурсам, при этом мы ничего не настраивали внутри операционной системы.

Заключение

Внесение изменений

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

Что мы сделали

Что сделаем в следующий раз

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