За простыми UML- и ER-диаграммами архитектур скрываются витиеватые способы организации IT-инфраструктуры. Самый яркий пример — связь между веб-сервером и базой данных.
Какие есть варианты организации инфраструктуры с базами данных? Чем они отличаются и какие у них преимущества и недостатки? С такими же вопросами к нам приходят клиенты. Поэтому мы постарались расставить все по полочкам, а также показать, как связать сервер с базой данных через L3 VPN-соединение. Подробности в статье.
Типовые схемы
В зависимости от того, на чем базируется инфраструктура, есть несколько способов, как организовать соединение с базами данных. Самые основные — ниже.
Рассмотрим каждую схему подробней.
→ Веб-сервер и база данных расположены на одной машине
Это самая распространенная и относительно дешевая архитектура: пользователю не нужно думать о связности между сервисами, веб-сервер просто общается с базой данных через локальные порты.
Главная проблема такого подхода — отсутствие отказоустойчивости. При отключении электропитания основного сервера упадет не только веб-сервер, но и база данных. Поэтому важно настроить автоматические бэкапы на отдельную виртуальную машину.
Также у архитектуры с одним сервером низкий уровень безопасности. Выделенный сервер доступен через публичный IP-адрес. Если злоумышленники взломают систему, то получат доступ к веб-серверу и базам данных.
Кроме того, чтобы обеспечить должный уровень безопасности и работы, систему должен администрировать квалифицированный сотрудник — это дополнительные затраты на содержание штата.
Еще один минус — отсутствие гибкости в масштабировании. Если ресурсов не хватает, а таблицы разрастаются, нужно самостоятельно создать резервные копии и перенести базы данных на отдельную машину. Бесперебойно это сделать сложно.
→ Базы данных расположены в облаке, а веб-сервер — на выделенном сервере
Эта архитектура решает проблему с масштабированием. Но она может быть дороже, поскольку предполагает наличие физической и виртуальной машин, которые нужно оплачивать и самостоятельно администрировать.
Если есть резервный сервер, при падении основного он продолжит работу, а база данных не пострадает, потому что находится в облаке. Тем самым можно достичь отказоустойчивости.
Кроме того, с базой данных в облаке можно «общаться» через серый IP-адрес. Он не маршрутизируется в интернете и доступен только в пределах приватной сети глобального роутера. Это гарантирует безопасность, в отличие от схемы, когда база данных и веб-сервер расположены на одной машине.
→ Базы данных развернуты в Managed Databases, а веб-сервер — на выделенном сервере
В предыдущих схемах нужно администрировать не только серверы, но и базы данных. Если их много, то могут быть не только материальные, но и временные издержки: при запуске дополнительных кластеров баз данных, нужно потратить ресурсы на развертывание и настройку мониторинга, бэкапов и самого железа. А также позаботиться о соответствии баз данных требованиям регуляторов — например, 152-ФЗ.
Чтобы сократить время на создание и конфигурирование кластеров баз данных, можно воспользоваться сервисом Managed Databases.
Managed Databases — это сервис, который позволяет быстро разворачивать кластеры баз данных в облаке и обслуживать инфраструктуру по модели IaC, используя утилиту Terraform. Настройка, обслуживание и надежность обеспечиваются на стороне Selectel — о том, какие у этого преимущества, рассказали в статье.
Преимущества:
- не нужно самостоятельно настраивать операционную систему и служебные компоненты,
- безопасное хранение данных в соответствии с 152-ФЗ,
- реплики отказоустойчивого кластера уже настроены,
- экономия времени и средств при развертывании и масштабировании кластеров баз данных,
- не нужно самостоятельно подбирать и конфигурировать серверы для размещения баз данных,
- автоматическое резервное копирование с настраиваемой периодичностью — point-in-time.
Так, можно решить проблемы с масштабированием по мере роста инфраструктуры, надежностью и отказоустойчивостью. Это решение дороже предыдущих, но в перспективе оно позволит сэкономить на обслуживании баз данных.
Облачные базы данных
Позаботимся о настройках, надежности и поддержке инфраструктуры.
Как организовать соединение с Managed Databases
Теперь расскажем, как объединить IaaS- и PaaS-продукты в рамках приватной сети. Все просто: для решения задачи можно использовать глобальный роутер Selectel. Посмотрим на примере организации связности между выделенным сервером и базой данных в Managed Databases.
Создание глобального роутера
Представьте: у вас есть выделенный сервер и облачная база данных в пуле SPB-3 и ru-3 соответственно.
Для начала нужно перейти в панель управления, открыть раздел Сетевые сервисы и создать глобальный роутер, который будет объединять сервисы. После можно открыть карту сети и убедиться, что роутер есть и пока он ничего не связывает.
Создание сети для выделенных серверов
Теперь нужно создать сеть, которая будет объединять серверы одного региона.
Обязательно укажите VLAN — его можно посмотреть в разделе Порты своего сервера. В качестве CIDR можно указать любую свободную подсеть — например, 10.1.0.0/24 или 10.0.2.0/24. Учтите, что адрес шлюза 10.0.0.1 занят — он принадлежит шлюзу глобальному роутеру. Но вы можете выбрать любой другой.
Создание сети для баз данных
Процесс создания сети для баз данных немного отличается: сначала нужно создать сеть и подсеть в определенном пуле, а после — базу данных. Рассмотрим каждый шаг подробней.
Для создания сети нужно выбрать пул и проект в облачной платформе, в которым вы планируете создать базу данных, и указать свободный CIDR.
Теперь нужно перейти в раздел Облачные базы данных, нажать Создать кластер и выбрать подсеть в глобальном роутере.
Готово — на карте сети можно увидеть связность между выделенным сервером и базой данных.
Также, если перейти в раздел Сети, выбрать нужную сеть и открыть список портов, можно увидеть адрес операционной системы базы данных.
Если вы хотите настроить связность с базой данных, которая была создана до глобального роутера, необходимо создать тикет в панели управления.
Настройка интерфейса выделенного сервера и проверка подключения
Последним этапом связность нужно настроить: назначить адрес CIDR для «общения» с базой данных через глобальный роутер. Рассмотрим простой способ, который будет работать «до перезагрузки».
Для начала нужно подключиться к серверу — например, по SSH — и посмотреть список интерфейсов.
root@Turing:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:25:90:e5:e6:22 brd ff:ff:ff:ff:ff:ff
inet 94.26.231.176/24 brd 94.26.231.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::225:90ff:fee5:e622/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:25:90:e5:e6:23 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.0/29 scope global eth1
valid_lft forever preferred_lft forever
Обратите внимание на последний интерфейс eth1 — именно он смотрит в сторону VLAN, через который сервер «общается» с глобальным роутером. Его нужно настроить.
1. Назначаем для VLAN адрес CIDR, который указали при создании сети.
root@Turing:~# ip a a 10.1.0.2/24 dev eth1
root@Young:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:25:90:e5:e6:22 brd ff:ff:ff:ff:ff:ff
inet 94.26.231.176/24 brd 94.26.231.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::225:90ff:fee5:e622/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:25:90:e5:e6:23 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.2/24 scope global eth1
valid_lft forever preferred_lft forever
CIDR присвоен, но сейчас интерфейс выключен, значение триггера DOWN.
2. Поднимаем интерфейс в сторону VLAN, чтобы система «общалась» с подсетями через eth1.
root@Turing:~# ifconfig eth1 up
3. Добавляем маршрут до подсети базы данных (10.0.0.0/24) через шлюз глобального роутера (10.1.0.1).
root@Turing:~# ip r a 10.0.0.0/24 via 10.1.0.1
4. Проверяем связность через ping адреса базы данных, который предварительно узнали из списка портов.
root@Young:~# ping 10.0.0.66
PING 10.0.0.66 (10.0.0.66) 56(84) bytes of data.
64 bytes from 10.0.0.66: icmp_seq=1 ttl=62 time=1.26 ms
64 bytes from 10.0.0.66: icmp_seq=2 ttl=62 time=1.05 ms
64 bytes from 10.0.0.66: icmp_seq=3 ttl=62 time=1.11 ms
64 bytes from 10.0.0.66: icmp_seq=4 ttl=62 time=1.10 ms
64 bytes from 10.0.0.66: icmp_seq=5 ttl=62 time=1.06 ms
64 bytes from 10.0.0.66: icmp_seq=6 ttl=62 time=1.13 ms
64 bytes from 10.0.0.66: icmp_seq=7 ttl=62 time=1.11 ms
64 bytes from 10.0.0.66: icmp_seq=8 ttl=62 time=1.09 ms
64 bytes from 10.0.0.66: icmp_seq=9 ttl=62 time=1.08 ms
64 bytes from 10.0.0.66: icmp_seq=10 ttl=62 time=1.09 ms
Готово — интерфейс сконфигурирован, у него есть своя подсеть и маршрут до базы данных через шлюз. Связность через глобальный роутер работает.
