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


  1. savostin
    00.00.0000 00:00
    -1

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

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

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


    1. Doctor_IT Автор
      00.00.0000 00:00
      +2

      Да, в случае, когда база данных расположена в облаке Selectel, а веб-сервер — на отдельной машине, уровень безопасности выше. Потому что они общаются между собой через приватное L3 VPN-соединение, через глобальный роутер, без выхода в интернет. Это значит, что обратиться к базе данных можно только через серый IP-адрес. То есть злоумышленнику будет не достаточно «получить доступ к коду приложения»


      1. savostin
        00.00.0000 00:00

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

        Да пусть хоть записками общаются. Если злоумышленник уже находится на веб-сервере, то выявить его злой умысел можно только косвенно (например выкачивает всю базу, а не должен), т.к. все его запросы к базе будут с ip приложения. Не вижу как эта схема "гарантирует" что-то больше, чем схема расположения на одном сервере приложение/веб-сервера и базы. Разве что у вас на сервере БД есть анализатор запросов или подозрительной активности со стороны приложения, в чем сомневаюсь. Да и умный злоумышленник не будет сразу слать тыщи запросов...


        1. GrishinAlex
          00.00.0000 00:00
          +2

          Как понял я, в первом случае (все на дедике) вы получаете доступ до объекта который имеет публичный адрес. А на нем находится вся ваша инфраструктура в том числе и БД как на блюдечке! И совсем не факт что он получил доступ к "коду приложения". Он просто получил доступ ко всей файловой системе, этого достаточно.
          Во втором случае (на дедике только то что нужно), вы получаете доступ только к той части инфраструктуры которой нужно смотреть наружу - например веб-сервер, прокси сервер и тп. Дальше нужно проводить анализ инфраструктуры и продумывать следующие шаги атаки. Это выглядит более трудоемким.

          Но да вы правы, при желании взломать можно все что угодно, это всего лишь вопрос времени и ресурсов.


          1. savostin
            00.00.0000 00:00

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


  1. Kirikekeks
    00.00.0000 00:00
    -2

    А если сгорит ЦОД в Selectel останется собственный сервер. Вот за такой заголовок и такой текст имеет смысл поставить минус. Из минусомёта. И контрольный минус, что бы наверняка.


    1. Doctor_IT Автор
      00.00.0000 00:00
      +1

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

      Но для защиты серверных и технологических помещений в своих дата-центрах мы используем самые проверенные средства пожарной защиты, не экономя на надежности инфраструктуры и качества ОТВ. Высокий уровень защиты достигается за счет использования автономных центральных станций газового пожаротушения с веществом Хладон 125.

      Подробнее о системах пожаротушения в дата-центрах мы рассказали в отдельной статье — читайте в нашем блоге: https://selectel.ru/blog/obzor-reshenij-dlya-pozharotusheniya-cod/


  1. hogstaberg
    00.00.0000 00:00

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

    Содержание: реклама сервиса.


    1. Doctor_IT Автор
      00.00.0000 00:00

      Добрый день. В этом тексте мы хотели не только сравнить способы организации инфры с бд, но и ответить на вопросы клиентов — в частности, как связать managed databases с сервером через глобальный роутер. Об этом говорится в лиде статьи.