За простыми UML- и ER-диаграммами архитектур скрываются витиеватые способы организации IT-инфраструктуры. Самый яркий пример — связь между веб-сервером и базой данных.
Какие есть варианты организации инфраструктуры с базами данных? Чем они отличаются и какие у них преимущества и недостатки? С такими же вопросами к нам приходят клиенты. Поэтому мы постарались расставить все по полочкам, а также показать, как связать сервер с базой данных через L3 VPN-соединение. Подробности под катом.
Типовые схемы
В зависимости от того, на чем базируется инфраструктура, есть несколько способов, как организовать соединение с базами данных. Самые основные — ниже.
Обратите внимание: в качестве основной машины с веб-сервером может быть не только выделенный, но и облачный сервер.
Рассмотрим каждую схему подробней.
→ Веб-сервер и база данных расположены на одной машине
Это самая распространенная и относительно дешевая архитектура: пользователю не нужно думать о связности между сервисами, веб-сервер просто общается с базой данных через локальные порты.
Главная проблема такого подхода — отсутствие отказоустойчивости. При отключении электропитания основного сервера упадет не только веб-сервер, но и база данных. Поэтому важно настроить автоматические бэкапы на отдельную виртуальную машину.
Также у архитектуры с одним сервером низкий уровень безопасности. Выделенный сервер доступен через публичный IP-адрес. Если злоумышленники взломают систему, то получат доступ к веб-серверу и базам данных.
Кроме того, чтобы обеспечить должный уровень безопасности и работы, систему должен администрировать квалифицированный сотрудник — это дополнительные затраты на содержание штата.
Еще один минус — отсутствие гибкости в масштабировании. Если ресурсов не хватает, а таблицы разрастаются, нужно самостоятельно создать резервные копии и перенести базы данных на отдельную машину. Бесперебойно это сделать сложно.
Возможно, эти тексты тоже вас заинтересуют:
→ Конфигуратор и PostgreSQL: что под капотом 1С PaaS-решения для организации работы в облаке
→ Как избежать распространенных ошибок при работе с СУБД
→ Не все типы репликации одинаково полезны, или почему две MySQL лучше одной
→ Базы данных расположены в облаке, а веб-сервер — на выделенном сервере
Эта архитектура решает проблему с масштабированием. Но она может быть дороже, поскольку предполагает наличие физической и виртуальной машин, которые нужно оплачивать и самостоятельно администрировать.
Если есть резервный сервер, при падении основного он продолжит работу, а база данных не пострадает, потому что находится в облаке. Тем самым можно достичь отказоустойчивости.
Кроме того, с базой данных в облаке можно «общаться» через серый 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 занят — он принадлежит шлюзу глобальному роутеру. Но вы можете выбрать любой другой.
Выделенный сервер, раздел Порты, VLAN — 1275
Создание сети для баз данных
Процесс создания сети для баз данных немного отличается: сначала нужно создать сеть и подсеть в определенном пуле, а после — базу данных. Рассмотрим каждый шаг подробней.
Для создания сети нужно выбрать пул и проект в облачной платформе, в которым вы планируете создать базу данных, и указать свободный CIDR.
Теперь нужно перейти в раздел Облачные базы данных, нажать Создать кластер и выбрать подсеть в глобальном роутере.
Готово — на карте сети можно увидеть связность между выделенным сервером и базой данных.
Карта сети, связность между выделенным сервером и базой данных через глобальный роутер Selectel.
Также, если перейти в раздел Сети, выбрать нужную сеть и открыть список портов, можно увидеть адрес операционной системы базы данных.
Этот адрес можно использовать для проверки соединения через ping.
Если вы хотите настроить связность с базой данных, которая была создана до глобального роутера, необходимо создать тикет в панели управления.
Настройка интерфейса выделенного сервера и проверка подключения
Последним этапом связность нужно настроить: назначить адрес 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
Готово — интерфейс сконфигурирован, у него есть своя подсеть и маршрут до базы данных через шлюз. Связность через глобальный роутер работает.
Комментарии (9)
Kirikekeks
00.00.0000 00:00-2А если сгорит ЦОД в Selectel останется собственный сервер. Вот за такой заголовок и такой текст имеет смысл поставить минус. Из минусомёта. И контрольный минус, что бы наверняка.
Doctor_IT Автор
00.00.0000 00:00+1Конечно, какой бы надежной ни была инфраструктура, всегда есть вероятность возникновения нештатных ситуаций, способных негативно повлиять на работу компании в целом.
Но для защиты серверных и технологических помещений в своих дата-центрах мы используем самые проверенные средства пожарной защиты, не экономя на надежности инфраструктуры и качества ОТВ. Высокий уровень защиты достигается за счет использования автономных центральных станций газового пожаротушения с веществом Хладон 125.
Подробнее о системах пожаротушения в дата-центрах мы рассказали в отдельной статье — читайте в нашем блоге: https://selectel.ru/blog/obzor-reshenij-dlya-pozharotusheniya-cod/
hogstaberg
00.00.0000 00:00Заголовок: "Способы организации инфраструктуры с базами данных: от простого к сложному и эффективному".
Содержание: реклама сервиса.
Doctor_IT Автор
00.00.0000 00:00Добрый день. В этом тексте мы хотели не только сравнить способы организации инфры с бд, но и ответить на вопросы клиентов — в частности, как связать managed databases с сервером через глобальный роутер. Об этом говорится в лиде статьи.
savostin
Интересно как это гарантирует безопасность? Если Вы про прямой доступ к базе по ip, то в обоих случаях он должен быть защищен файерволом.
Имхо, если злоумышленник имеет доступ к коду приложения, он имеет доступ и к базе. Более того, определить внедрение в базу в такой схеме сложнее, потому как для базы обращение выглядит вполне лигитимным, т.к. происходит со стороны приложения.
Doctor_IT Автор
Да, в случае, когда база данных расположена в облаке Selectel, а веб-сервер — на отдельной машине, уровень безопасности выше. Потому что они общаются между собой через приватное L3 VPN-соединение, через глобальный роутер, без выхода в интернет. Это значит, что обратиться к базе данных можно только через серый IP-адрес. То есть злоумышленнику будет не достаточно «получить доступ к коду приложения»
savostin
Да, под "кодом" приложения я имел в виду "код, расположенный на веб-сервере" или даже "получить доступ на исполнение кода приложения".
Да пусть хоть записками общаются. Если злоумышленник уже находится на веб-сервере, то выявить его злой умысел можно только косвенно (например выкачивает всю базу, а не должен), т.к. все его запросы к базе будут с ip приложения. Не вижу как эта схема "гарантирует" что-то больше, чем схема расположения на одном сервере приложение/веб-сервера и базы. Разве что у вас на сервере БД есть анализатор запросов или подозрительной активности со стороны приложения, в чем сомневаюсь. Да и умный злоумышленник не будет сразу слать тыщи запросов...
GrishinAlex
Как понял я, в первом случае (все на дедике) вы получаете доступ до объекта который имеет публичный адрес. А на нем находится вся ваша инфраструктура в том числе и БД как на блюдечке! И совсем не факт что он получил доступ к "коду приложения". Он просто получил доступ ко всей файловой системе, этого достаточно.
Во втором случае (на дедике только то что нужно), вы получаете доступ только к той части инфраструктуры которой нужно смотреть наружу - например веб-сервер, прокси сервер и тп. Дальше нужно проводить анализ инфраструктуры и продумывать следующие шаги атаки. Это выглядит более трудоемким.
Но да вы правы, при желании взломать можно все что угодно, это всего лишь вопрос времени и ресурсов.
savostin
Имхо имея доступ к файловой системе приложения, вы получаете доступ к бд, где бы она ни находилась. Разве что параметры доступа к бд хранятся в памяти, а не на диске.