Способы организации инфраструктуры с базами данных: от простого к сложному

За простыми 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

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