Обычно данные выделенных серверов хранят на локальных дисках, используют внешние специализированные системы хранения данных или СХД. Однако локальный диск нельзя подключить к нескольким «машинам», что может потребоваться в случае бесшовной миграции между серверами при использовании систем виртуализации вроде Proxmox Virtual Environment, VMware ESXi и других. А СХД достаточно дорогие. Кроме того, бывают сценарии, когда диски должны быть быстро масштабируемыми — тогда хорошим вариантом будет использовать сетевые диски облачной платформы.

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

Хорошая новость: виртуальные сетевые диски можно подключить к выделенным серверам. Можно сказать, это некий компромисс в гибкости ресурсов, когда нагрузка на CPU и RAM остается предсказуемой и достаточно выделенного сервера, но нужны масштабируемые по емкости и пропускной способности накопители. Как этого добиться, рассказываем под катом.

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

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

Общее описание схемы

Чтобы подключить выделенный сервер к виртуальным сетевым дискам, нам понадобятся сами диски и сам сервер. Но между ними должно быть связующее, в нашем случае — глобальный роутер, который позволяет объединить инфраструктуру в Selectel приватной сетью на уровне L3, и кое-что еще.

Глобальный роутер — это совокупность физически зарезервированных маршрутизаторов, размещенных в разных пулах и объединенных в один домен маршрутизации по IP/MPLS.

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

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


На самом деле, никакого rocket science — только работа в панели управления и корректная настройка сетевых интерфейсов на уровне операционных систем серверов. Но пойдем по порядку.

Этап 1. Предварительная настройка инфраструктуры

1. Для начала перейдем в раздел Продукты → Выделенные серверы и нажмем кнопку Создать сервер. Для примера соберем сервер в SPB-4 — выбор региона не имеет значения. Главное, чтобы у сервера был доступ в приватную сеть и, соответственно, к глобальному роутеру. Для этого настройте соответствующий фильтр в конфигураторе:


Итак, конфигурация выбрана. Назовем сервер test_netdrive, создаем его и конфигурируем VLAN. В нашем случае — локальный VLAN 3028, но номер вашего будет отличаться.

Сконфигурировать VLAN можно во вкладке Порты выделенного сервера:


Если это новый сервер в регионе, то VLAN будет выделен системой и назначен на сервер автоматически. Если у вас уже есть серверы в регионе, то вы можете выбрать существующий VLAN.

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

В качестве образа операционной системы выбираем актуальную Ubuntu 24.04. Для тестирования будет достаточно самой простой конфигурации: 1 vCPU и 1 ГБ RAM. Но это не все: на уровне настройки конфигурации нужно добавить виртуальные сетевые диски. Для примера возьмем три накопителя: HDD Базовый, SSD Универсальный и SSD Быстрый.

• Диск 1 — системный, который будет использован для развертывания ОС.
• Диски 2-4 — дополнительные, нужных типов.

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


3. Следующим шагом нужно настроить сетевую связность между выделенным и облачным сервером с сетевыми дисками. Для этого перейдем в раздел Продукты → Глобальная сетевая связность → Глобальный роутер и нажмем кнопку Создать глобальный роутер.

В открывшемся меню добавляем две локальной сети. Первая будет объединять подсеть облака с подсетью выделенных серверов, вторая — облачный сервер и виртуальные сетевые диск.

• netdrive — для выделенного сервера;
• netdrive_cloud — для облачного сервера и виртуальных сетевых дисков.

Этап 2. Настройка сетевых интерфейсов

1. Далее необходимо прописать маршруты, чтобы наш облачный сервер видел подсеть выделенного сервера из своей операционной системы.

Со стороны облака мы создаем статический маршруты для облачного сервера в нашей панели управления. Для этого нужно выбрать Автоматические сетевые настройки:


Статический маршрут для облачного сервера прописан в панели управления:


После изменения настроек перезагружаем облачный сервер через панель управления. Это можно сделать в разделе Продукты → Облачные серверы. За счет использования в облаке системы инициализации cloud-init настройки можно делать через панель управления и/или API, что удобно. А вот на выделенном сервере придется немного поработать руками.

2. Подключаемся к выделенному серверу по SSH, определяемся с сетевыми интерфейсами, прописываем необходимые настройки и маршрут до сети облака:


На этом этапе можно проверить, пингуется ли выделенный сервер со стороны облачного:


Связность есть — можем настроить iSCSI-таргет.

Этап 3. Настройка экспорта сетевых дисков

Почти все готово. Осталось настроить iSCSI-таргет на облачном сервере — по сути, софт, который делает накопитель доступным по сети. Вместе с этим, нужно сконфигурировать iSCSI-инициатор на стороне выделенного сервера. Именно он будет устанавливать соединение с таргетом и осуществлять ввод-вывод на блочное устройство.

iSCSI-таргет

1. Подключаемся к облачному серверу по SSH и устанавливаем targetcli:

apt update && apt install targetcli-fb

2. Запускаем targetcli:

targetcli

3. Далее все команды в этом пункте вводятся в интерфейсе targetcli:

cd /backstores/block
create dev=/dev/sdb name=basic
create dev=/dev/sdc name=universal
create dev=/dev/sdd name=fast

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

cd /iscsi
create

Командой выше мы создали сразу несколько сущностей iSCSI: target с автоматически сгенерированным IQN (iSCSI Qualified Name), target portal group (сокращенно, TPG) и iSCSI-портал, который привязывается ко всем сетевым интерфейсам и использует TCP-порт по умолчанию (0.0.0.0:3260).

В современных дистрибутивах Linux, к которым безусловно относится используемая нами Ubuntu 24.04, пакет targetcli устанавливается с настройками по умолчанию:

auto_add_default_portal 
auto_enable_tpgt

Это и позволяет использовать один лишь create — и дальше утилита все делает за нас. Сгенерированный в вашей инсталляции IQN портала будет отличаться от приведенного в примере, обратите на это внимание. Далее мы будем использовать наш IQN.

cd iqn.2003-01.org.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4/tpg1/luns

create /backstores/block/basic
create /backstores/block/universal
create /backstores/block/fast

Выполнив команды, мы сопоставили наши диски логическим единицам (logical unit-ам или LUN) iSCSI нашего target.

cd /iscsi/iqn.2003-01.org.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4/tpg1/
get attribute

Так мы переходим к настройкам iSCSI-портала и портальной группы и запрашиваем список атрибутов. Пока нас интересует только один – аутентификация. Она должна быть включена.

set attribute authentication=1
cd acls/
create iqn.2004-10.com.ubuntu:01:cf82f14213f1

Выполнив команды выше, мы включили аутентификацию на портальной группе iSCSI и создали новый IQN инициатора, который будет к нему подключаться. Но где его можно взять? Ответ кроется в тексте ниже в разделе iSCSI-инициатор в первом пункте. Кратко: его надо получить от сервера-инициатора iSCSI-подключения. У вас он будет отличаться, мы же в примере использовали свой.

cd iqn.2004-10.com.ubuntu:01:cf82f14213f1/
get auth
set auth userid=testnetdrive
set auth password=SecureP@$$w0rd1
saveconfig
exit

Таким образом, мы перешли к настройкам для нашего инициатора, запросили параметры аутентификации и задали логин с паролем. Пароль «SecureP@$$w0rd1» следует зафиксировать для дальнейшей настройки инициатора iSCSI. Рекомендуем использовать длинные и сложные пароли и применять генератор для их создания. Наш пример, конечно, не самый безопасный.

saveconfig
exit

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

4. После выхода из интерфейса targetcli будет сформирована конфигурация target. Проверяем:

cat /etc/rtslib-fb-target/saveconfig.json

5. Убеждаемся, что система прослушивает TCP-порт 3260 (по умолчанию для iSCSI):

ss -ptln | grep 3260

iSCSI-инициатор

Предполагается, что ОС на выделенном сервере — один из Linux-дистрибутивов. В нашем примере используется Ubuntu Linux 22.04.

1. Подключаемся к выделенному серверу по SSH и получаем IQN инициатора — он необходим для настройки серверной части:

cat /etc/iscsi/initiatorname.iscsi

Пример вывода:

cat /etc/iscsi/initiatorname.iscsi 
## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator.  The InitiatorName must be unique
## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames.
InitiatorName=iqn.2004-10.com.ubuntu:01:cf82f14213f1

И снова мы видим в выводе автоматически сгенерированное для сервера iSCSI Qualified Name (IQN). Имя генерируется при установке пакета open-iscsi, что, как правило, происходит при инсталляции операционной системы. Впрочем, вы можете переопределить это имя с помощью утилиты iscsi-iname. Но сейчас нас вполне устраивает существующее.

2. Еще раз проверяем доступность (по ICMP) облачного сервера через приватную сеть:

ping -c4 172.30.2.233
PING 172.30.2.233 (172.30.2.233) 56(84) bytes of data.
64 bytes from 172.30.2.233: icmp_seq=1 ttl=62 time=0.586 ms
64 bytes from 172.30.2.233: icmp_seq=2 ttl=62 time=0.392 ms
64 bytes from 172.30.2.233: icmp_seq=3 ttl=62 time=0.393 ms
64 bytes from 172.30.2.233: icmp_seq=4 ttl=62 time=0.375 ms

3. Опрашиваем портал на наличие target:

iscsiadm -m discovery -t sendtargets -p 172.30.2.233:3260

Обратите внимание: мы используем TCP-порт, который прослушивает iSCSI-таргет на стороне облачного сервера.

Пример вывода:

iscsiadm -m discovery -t sendtargets -p 172.30.2.233:3260
172.30.2.233:3260,1 <a href="http://iqn.2003-01.org">iqn.2003-01.org</a>.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4

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

4. Фиксируем IQN (все еще не забыли про iSCSI Qualified Name, которое мы обсуждали выше ?) у полученного target вручную:

export MY_PIQN="<a href="http://iqn.2003-01.org">iqn.2003-01.org</a>.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4"

Либо можно использовать небольшой скрипт:

export TARGET_ADDR=172.30.2.233
export MY_PIQN=$(iscsiadm -m discovery -t sendtargets -p $TARGET_ADDR:3260 | awk '{print $2}')

5. Настраиваем аутентификацию инициатора на созданном нами портале:

iscsiadm -m node -T $MY_PIQN --op update -n node.session.auth.authmethod --value CHAP
iscsiadm -m node -T $MY_PIQN --op update -n node.session.auth.username --value testnetdrive
iscsiadm -m node -T $MY_PIQN --op update -n node.session.auth.password --value "SecureP@$$w0rd1"

Помните тот пароль, который мы задали при настройке серверной части? Он используется здесь.

6. Аутентифицируемся iSCSI-инициатором:

iscsiadm -m node -T $MY_PIQN --login

Пример вывода:

iscsiadm -m node -T iqn.2003-01.org.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4 --login
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4, portal: 172.30.2.233,3260]
Login to [iface: default, target: iqn.2003-01.org.linux-iscsi.netdrive-iscsi.x8664:sn.3db1171034d4, portal: 172.30.2.233,3260] successful.

Согласно выводу, портал принял нашу пару логин-пароль и разрешил доступ к дискам.

7. Проверяем наличие блочных устройств, подключенных по iSCSI:

lsscsi

Пример вывода:

lsscsi 
[0:0:0:0]    disk    ATA      INTEL SSDSC2KB96 0150  /dev/sda 
[1:0:0:0]    disk    ATA      INTEL SSDSC2KB96 0150  /dev/sdb 
[8:0:0:0]    disk    LIO-ORG  basic            4.0   /dev/sdc 
[8:0:0:1]    disk    LIO-ORG  universal        4.0   /dev/sdd 
[8:0:0:2]    disk    LIO-ORG  fast             4.0   /dev/sde

Вывод сообщений ядра:

dmesg -T | tail -30<br><br>[Wed Apr 30 13:39:56 2025] Loading iSCSI transport class v2.0-870.

[Wed Apr 30 13:39:56 2025] iscsi: registered transport (tcp)
[Wed Apr 30 13:50:05 2025] scsi host8: iSCSI Initiator over TCP/IP
[Wed Apr 30 13:50:05 2025] scsi 8:0:0:0: Direct-Access     LIO-ORG  basic            4.0  PQ: 0 ANSI: 6
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: Attached scsi generic sg2 type 0
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] 31457280 512-byte logical blocks: (16.1 GB/15.0 GiB)
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] Write Protect is off
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] Mode Sense: 43 00 10 08
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[Wed Apr 30 13:50:05 2025] scsi 8:0:0:1: Direct-Access     LIO-ORG  universal        4.0  PQ: 0 ANSI: 6
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] Preferred minimum I/O size 512 bytes
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] Optimal transfer size 33550336 bytes
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: Attached scsi generic sg3 type 0
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: LUN assignments on this target have changed. The Linux SCSI layer does not automatically remap LUN assignments.
[Wed Apr 30 13:50:05 2025] scsi 8:0:0:2: Direct-Access     LIO-ORG  fast             4.0  PQ: 0 ANSI: 6
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] 20971520 512-byte logical blocks: (10.7 GB/10.0 GiB)
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] Write Protect is off
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] Mode Sense: 43 00 10 08
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] Preferred minimum I/O size 512 bytes
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] Optimal transfer size 33550336 bytes
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: Attached scsi generic sg4 type 0
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: LUN assignments on this target have changed. The Linux SCSI layer does not automatically remap LUN assignments.
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] 10485760 512-byte logical blocks: (5.37 GB/5.00 GiB)
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] Write Protect is off
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] Mode Sense: 43 00 10 08
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] Write cache: enabled, read cache: enabled, supports DPO and FUA
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] Preferred minimum I/O size 512 bytes
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] Optimal transfer size 33550336 bytes
[Wed Apr 30 13:50:05 2025] sd 8:0:0:0: [sdc] Attached SCSI disk
[Wed Apr 30 13:50:05 2025] sd 8:0:0:1: [sdd] Attached SCSI disk
[Wed Apr 30 13:50:05 2025] sd 8:0:0:2: [sde] Attached SCSI disk

Как мы видим, устройства /dev/sdc, /dev/sdd и /dev/sde подключены и готовы к работе!

А какие диски предпочитаете использовать вы? Поделитесь опытом в комментариях и напишите, как вам рассмотренный гибридный подход.