Инструкции

Обычно данные выделенных серверов хранят на локальных дисках, используют внешние специализированные системы хранения данных или СХД. Однако локальный диск нельзя подключить к нескольким «машинам», что может потребоваться в случае бесшовной миграции между серверами при использовании систем виртуализации вроде Proxmox Virtual Environment, VMware ESXi и других. А СХД достаточно дорогие. Кроме того, бывают сценарии, когда диски должны быть быстро масштабируемыми — тогда хорошим вариантом будет использовать сетевые диски облачной платформы. Хорошая новость: виртуальные сетевые диски можно подключить к выделенным серверам. Можно сказать, это некий компромисс в гибкости ресурсов, когда нагрузка на CPU и RAM остается предсказуемой и достаточно выделенного сервера, но нужны масштабируемые по емкости и пропускной способности накопители. Как этого добиться, рассказываем в инструкции. Автор материала: Антонина Коробкова, продуктовый менеджер. Общее описание схемы Чтобы подключить выделенный сервер к виртуальным сетевым дискам, нам понадобятся сами диски и сам сервер. Но между ними должно быть связующее, в нашем случае — глобальный роутер, который позволяет объединить инфраструктуру в Selectel приватной сетью на уровне L3, и кое-что еще. Помимо глобального роутера, каждый линк в сети представлен в виде отдельного 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: 2. Запускаем targetcli: 3. Далее все команды в этом пункте вводятся в интерфейсе targetcli: Таким образом, мы создаем описание существующих блочных устройств для экспорта, а также даем им понятные именования. Командой выше мы создали сразу несколько сущностей iSCSI: target с автоматически сгенерированным IQN (iSCSI Qualified Name), target portal group (сокращенно, TPG) и iSCSI-портал, который привязывается ко всем сетевым интерфейсам и использует TCP-порт по умолчанию (0.0.0.0:3260). В современных дистрибутивах Linux, к которым безусловно относится используемая нами Ubuntu 24.04, пакет targetcli устанавливается с настройками по умолчанию: Это и позволяет использовать один лишь create — и дальше утилита все делает за нас. Сгенерированный в вашей инсталляции IQN портала будет отличаться от приведенного в примере, обратите на это внимание. Далее мы будем использовать наш IQN. Выполнив команды, мы сопоставили наши диски логическим единицам (logical unit-ам или LUN) iSCSI нашего target. Так мы переходим к настройкам iSCSI-портала и портальной группы и запрашиваем список атрибутов. Пока нас интересует только один – аутентификация. Она должна быть включена. Выполнив команды выше, мы включили аутентификацию на портальной группе iSCSI и создали новый IQN инициатора, который будет к нему подключаться. Но где его можно взять? Ответ кроется в тексте ниже в разделе iSCSI-инициатор в первом пункте. Кратко: его надо получить от сервера-инициатора iSCSI-подключения. У вас он будет отличаться, мы же в примере использовали свой. Таким образом, мы перешли к настройкам для нашего инициатора, запросили параметры аутентификации и задали логин с паролем. Пароль «SecureP@$$w0rd1» следует зафиксировать для дальнейшей настройки инициатора iSCSI. Рекомендуем использовать длинные и сложные пароли и применять генератор для их создания. Наш пример, конечно, не самый безопасный. Сохраняем результаты работы и выходим из утилиты. Строго говоря, сохраняться не обязательно, так как в нашем пакете в targetcli по умолчанию включена настройка автоматического сохранения при выходе, но мы подстрахуемся. 4. После выхода из интерфейса targetcli будет сформирована конфигурация target. Проверяем: 5. Убеждаемся, что система прослушивает TCP-порт 3260 (по умолчанию для iSCSI): iSCSI-инициатор Предполагается, что ОС на выделенном сервере — один из Linux-дистрибутивов. В нашем примере используется Ubuntu Linux 22.04. 1. Подключаемся к выделенному серверу по SSH и получаем IQN инициатора — он необходим для настройки серверной части: Пример вывода: И снова мы видим в выводе автоматически сгенерированное для сервера iSCSI Qualified Name (IQN). Имя генерируется при установке пакета open-iscsi, что, как правило, происходит при инсталляции операционной системы. Впрочем, вы можете переопределить это имя с помощью утилиты iscsi-iname. Но сейчас нас вполне устраивает существующее. 2. Еще раз проверяем доступность (по ICMP) облачного сервера через приватную сеть: 3. Опрашиваем портал на наличие target: Обратите внимание: мы используем TCP-порт, который прослушивает iSCSI-таргет на стороне облачного сервера. Пример вывода: Опросив портал, мы получили IQN, но уже target’а, которое генерируется на сервере при создании портальной группы. Оно нам потребуется для дальнейшей настройки. 4. Фиксируем IQN (все еще не забыли про iSCSI Qualified Name, которое мы обсуждали выше 🙂) у полученного target вручную: Либо можно использовать небольшой скрипт: 5. Настраиваем аутентификацию инициатора на созданном нами портале: Помните тот пароль, который мы задали при настройке серверной части? Он используется здесь. 6. Аутентифицируемся iSCSI-инициатором: Пример вывода: Согласно выводу, портал принял нашу пару логин-пароль и разрешил доступ к дискам. 7. Проверяем наличие блочных устройств, подключенных по iSCSI: Пример вывода: Вывод сообщений ядра: Как мы видим, устройства /dev/sdc, /dev/sdd и /dev/sde подключены и готовы к работе! Но если вдруг к концу этой инструкции вы поняли, что для ваших задач достаточно сетевых дисков для выделенных серверов, читайте другую статью.

Инструкции

Зарегистрируйтесь в панели управления