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

7vudj4bxfj2u5iliwa5sutahvga.png


За простыми UML- и ER-диаграммами архитектур скрываются витиеватые способы организации IT-инфраструктуры. Самый яркий пример — связь между веб-сервером и базой данных.

Какие есть варианты организации инфраструктуры с базами данных? Чем они отличаются и какие у них преимущества и недостатки? С такими же вопросами к нам приходят клиенты. Поэтому мы постарались расставить все по полочкам, а также показать, как связать сервер с базой данных через L3 VPN-соединение. Подробности под катом.

Типовые схемы


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

jjc72yahd9ixwtvqvlio_gjelyy.png


Обратите внимание: в качестве основной машины с веб-сервером может быть не только выделенный, но и облачный сервер.

Рассмотрим каждую схему подробней.

Веб-сервер и база данных расположены на одной машине


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

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

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

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

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

Возможно, эти тексты тоже вас заинтересуют:

→ Конфигуратор и PostgreSQL: что под капотом 1С PaaS-решения для организации работы в облаке
→ Как избежать распространенных ошибок при работе с СУБД
→ Не все типы репликации одинаково полезны, или почему две MySQL лучше одной


Базы данных расположены в облаке, а веб-сервер — на выделенном сервере


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

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

Кроме того, с базой данных в облаке можно «общаться» через серый IP-адрес. Он не маршрутизируется в интернете и доступен только в пределах приватной сети глобального роутера. Это гарантирует безопасность, в отличие от схемы, когда база данных и веб-сервер расположены на одной машине.

Базы данных развернуты в Managed Databases, а веб-сервер — на выделенном сервере


В предыдущих схемах нужно администрировать не только серверы, но и базы данных. Если их много, то могут быть не только материальные, но и временные издержки: при запуске дополнительных кластеров баз данных, нужно потратить ресурсы на развертывание и настройку мониторинга, бэкапов и самого железа. А также позаботиться о соответствии баз данных требованиям регуляторов — например, 152-ФЗ.

Чтобы сократить время на создание и конфигурирование кластеров баз данных, можно воспользоваться сервисом Managed Databases.

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

Преимущества:

  • не нужно самостоятельно настраивать операционную систему и служебные компоненты,
  • безопасное хранение данных в соответствии с 152-ФЗ,
  • реплики отказоустойчивого кластера уже настроены,
  • экономия времени и средств при развертывании и масштабировании кластеров баз данных,
  • не нужно самостоятельно подбирать и конфигурировать серверы для размещения баз данных,
  • автоматическое резервное копирование с настраиваемой периодичностью — point-in-time.


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

kieqfnjmxqq0q_oksz6asgkgzba.png

Как организовать соединение с Managed Databases


Теперь расскажем, как объединить IaaS- и PaaS-продукты в рамках приватной сети. Все просто: для решения задачи можно использовать глобальный роутер Selectel. Посмотрим на примере организации связности между выделенным сервером и базой данных в Managed Databases.

Создание глобального роутера


Представьте: у вас есть выделенный сервер и облачная база данных в пуле SPB-3 и ru-3 соответственно.

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

ibnluv8uwcib8fxxj5xm1g5p-ia.png


Создание сети для выделенных серверов


Теперь нужно создать сеть, которая будет объединять серверы одного региона.

42ksspnzx06gahae5jbq6hh5zhm.png


Обязательно укажите VLAN — его можно посмотреть в разделе Порты своего сервера. В качестве CIDR можно указать любую свободную подсеть — например, 10.1.0.0/24 или 10.0.2.0/24. Учтите, что адрес шлюза 10.0.0.1 занят — он принадлежит шлюзу глобальному роутеру. Но вы можете выбрать любой другой.

bfyuomxbtzyxreu_c96dmg7hkyy.png


Выделенный сервер, раздел Порты, VLAN — 1275

Создание сети для баз данных


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

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

jqhqqjpacf1tdd9srvudm_viee8.png


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

_lkpj3tq6zyvry-dhfwc47u81ei.png


Готово — на карте сети можно увидеть связность между выделенным сервером и базой данных.

ncd9pus9iad2hdbqy2ccxdjych8.png


Карта сети, связность между выделенным сервером и базой данных через глобальный роутер Selectel.

Также, если перейти в раздел Сети, выбрать нужную сеть и открыть список портов, можно увидеть адрес операционной системы базы данных.

dwmhzla-1_2cx88br9kuh20tsdw.png


Этот адрес можно использовать для проверки соединения через ping.

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


Настройка интерфейса выделенного сервера и проверка подключения


Последним этапом связность нужно настроить: назначить адрес CIDR для «общения» с базой данных через глобальный роутер. Рассмотрим простой способ, который будет работать «до перезагрузки».

Для начала нужно подключиться к серверу — например, по SSH — и посмотреть список интерфейсов.

root@Turing:~# ip a
1: lo:  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:  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:  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:  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:  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:  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


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

© Habrahabr.ru