Что есть в 2025 году из протоколов подключения систем хранения?
FCP, Fibre Channel Protocol. Старый, постепенно отмирающий, но менять надежность и привычность FCP на DCB сложно. Не столько сложно технически, сколько организационно. Для внедрения нужно будет бить сетевиков палкой, чтобы не пытались рассказывать про LAG вне контекста Mellanox 6 (или 8, не помню).
iSCSI \ iSCSI Extensions for RDMA (iSER). C iSCSI работает вообще все, вопрос с какой скоростью и с какими настройками. iSER при этом под вопросом самого своего существования.
SMB Multichannel. Живее всех живых.
NVMe over Fabrics в ее вариантах – over FC, over Ethernet, over IB.
Поскольку речь про Proxmox, то SMB Multichannel, крайне удобная и рабочая конструкция для S2D, Storage Spaces Direct, тут рассматриваться не будет.
Подключение по FC сейчас, ввиду политики Broadcom, вещь неоднозначная.
Или, если у вас другой вендор системы хранения, читаем его документацию. Вообще, конечно, очень странно устроен Linux в части device-mapper-multipath. Точнее, у Hyawei пишется, что настройки нужно делать в alua, и не содержит указаний на настройки rr_min_io, хотя path_selector и выставлен в "round-robin 0". В главе про ESXi для AFA (all flash array) указано про rr=1, а тут нет. Но это настройки больше про скорость, а так и 1000 IOPS сойдет (но может быть не так просто).
Теперь к практике. Сделаю iSCSI target на Windows server, эта функция там из коробки лет 20, и добавлю к Proxmox.
Сначала спланирую сеть, как обычно – с извращениями.
Vlan 11, Windows server 172.16.211.151/24; Proxmox 172.16.211.162/24
Vlan 12, Windows server 10.0.12.151/24; Proxmox 10.0.12.162/24
LACP для iSCSI не рекомендован много кем, в том числе из-за сложностей с Multiple Connections per Session.
Добавляю новый свитч:
New-VMSwitch -Name Privet01 -SwitchType Private
Добавляю по 2 сетевые в обе VM -
Add-VMNetworkAdapter -VMName Proxmox -SwitchName Privet01 -Name V11
Add-VMNetworkAdapter -VMName Proxmox -SwitchName Privet01 -Name V12
Set-VMNetworkAdapterVlan -VMName Proxmox -Access -VlanId 11 -VMNetworkAdapterName V11
Set-VMNetworkAdapterVlan -VMName Proxmox -Access -VlanId 12 -VMNetworkAdapterName V12
и аналогично для второй VM
В этой конфигурации есть проблема. По умолчанию для VMNetworkAdapter включен VMQ. В некоторых сценариях и с некоторыми сетевыми картами эта функция работает очень плохо, вызывая какие-то разрывы, там, где не было ни единого разрыва, причем влияя на весь сетевой стек.
Я бы рекомендовал всем, кто использует Hyper-V и VMQ, проводить тестирование работы до запуска в продуктив.
В этой конфигурации есть еще одна проблема. После создания нового виртуального коммутатора и добавления двух сетевых карт в VM Windows server, первая сетевая карта в VM перестала получать адрес по DHCP, и основной адаптер стал (может, и был, я не проверил)
Microsoft Hyper-V Network Adapter #2
Первый раз такое вижу. Ситуация усугубляется тем, что старый интерфейс управления сетями в Windows server 2025 спрятали, а новый убогий.
Удалил вновь созданный виртуальный коммутатор, хотя он был SwitchType Private, все пересоздал, перезагрузил, сделал статичный IP внутри VM – вроде, работает.
Вопрос «что это было» не раскрыт.
Настройка VM Windows Server
Самое неудобное – это найти по MAC адресу, какая сетевая карта куда включилась.
Get-NetAdapter
вы думали
Set-NetIPAddress -InterfaceIndex 10 -IPAddress 172.16.211.151 -PrefixLength 24 ?
Ничего подобного.
New-NetIPAddress -InterfaceIndex 10 -IPAddress 172.16.211.151 -PrefixLength 24
New-NetIPAddress -InterfaceIndex 12 -IPAddress 10.0.12.151 -PrefixLength 24
И, конечно,
Install-WindowsFeature -Name FS-iSCSITarget-Server –IncludeManagementTools
Настройка Proxmox
ip a, только для того чтобы увидеть MAC адреса интерфейсов
nano /etc/network/interfaces
auto vmbr1.11
iface vmbr1.11 inet static
address 172.16.211.162/24
auto vmbr1
iface vmbr1 inet manual
bridge-ports eth2
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 11
не забываем про ifreload -a
И даже пинг не работает на таком свиче. Что-то прописать забыл. Очень неудобная история с системой интерфейсов в Proxmox. С одной стороны со схемой тут я переусложнил, с другой – в целом система настройки Linux bridge – vlan interface не самая удобная. Слишком много сущностей приходится прописывать.
Примечание. Не забыл. Прописал лишний раз – у меня же отдельный интерфейс отдан в VM, ему не надо настраивать vlan, как будто он в транк включен. Поэтому все проще, не забыть разрешить any any в windows firewall (в рабочих сетях так делать, конечно, не надо), и :
iface eth2 inet manual
auto vmbr2
iface vmbr2 inet manual
address 172.16.211.162/24
bridge-ports eth2
bridge-stp off
bridge-fd 0
аналогично настроить iface eth3, и заработало .
желательно сразу посмотреть ID инициатора -
cat /etc/iscsi/initiatorname.iscsi | grep InitiatorName=
Отдаем iSCSI target с Windows server
Тут ничего нового уже много лет. Server manager – files services – iSCSI – далее- далее – прописать (для стенда сойдет) IP адреса и готово. Конечно, с CHAP. Получаем iSCSI target с Windows server
Два НО.
Первое НО. Нужно заранее прочитать про Set-IscsiTargetServerSetting и сделать
Set-IscsiTargetServerSetting -IP 192.168 (что там у меня) -Enable $False
и проверить
netstat -an | findstr "3260"
Менять ли приоритеты для IPv6 или их отключать – ваше личное дело. Напоминаю, что чекбокс «отключить ipv6» не работает уже лет 10. Нужно делать как написано в Guidance for configuring IPv6 in Windows for advanced users
или сделать
Get-NetIPAddress | Select IPAddress
Set-IscsiTargetServerSetting для ipv6
и перепроверить по старой школе
netstat -an | findstr "3260"
Или по новой школе
Get-NetTCPConnection | where {$_.LocalPort -eq 3260}
Второе НО.
Для тестов не забыть сделать:
New-NetFirewallRule -DisplayName "001 permit any 172.16.211.162" -Direction Inbound -Action Allow -RemoteAddress 172.16.211.162
New-NetFirewallRule -DisplayName "001 permit any 10.0.12.162" -Direction Inbound -Action Allow -RemoteAddress 10.0.12.162
Подключаем iSCSI target с Windows server на Proxmox (Initiator) - отладка
В GUI подключение iSCSI находится в datacenter-storage, а не в управлении хостом.
Редактируем /etc/iscsi/iscsid.conf согласно статье Proxmox Multipath и рекомендациям вендора СХД. Или не редактируем!
открываем GUI и .. и видим фигу, потому что полей для авторизации \ CHAP нет, а без них никакого target.
Отключаю CHAP, и все равно ничего не видно. Как обычно, в GUI никаких деталей нет, поэтому проверять придется руками.
Начнем по встроенной инструкции по кнопке HELP в GUI -
pvesm status
pvesm scan iscsi 172.16.211.151:3260:3260
и получу iscsiadm: No portals found
Пойду почитаю Подключение iSCSI диска в Proxmox,
iscsiadm --mode discovery --type sendtargets --portal 172.16.211.151
и получу тот же - iscsiadm: No portals found
nc -z 172.16.211.151 3260
выдает ничего. Пинг есть.
Поиграем в отладку!
nc -v 172.16.211.151 3260 со стороны инициатора (proxmox) работает с выводом результата
[172.16.211.151] 3260 (iscsi-target) open
netstat -an | findstr "211" со стороны target (Windows) работает с выводом результата
TCP 172.16.211.151:3260 172.16.211.162:37638 ESTABLISHED
Осталось протереть глаза, и оказалось, что я, вводя разрешенные IP в target, ввел не 172.16.211.162, а 172.16.11.162
ввел нужные данные, и
pvesm scan iscsi 172.16.211.151:3260
выдал все что надо.
Иначе бы пришлось лезть в tcpdump с обеих сторон. Для Windows, после ухода на пенсию (deprecated) Microsoft Network Monitor и Microsoft Message Analyzer, пока что есть wireshark.
Верну обратно chap, user = user, password = password1234, добавлю через GUI, посмотрю что вышло в
/etc/pve/storage.cfg
Вышло как по руководству,
iscsi: mynas
portal 10.10.10.1
target iqn.2006-01.openfiler.com:tsn.dcb5aaaddd
content none
И затем в GUI делаем Datacenter – Storage – add – LVM –
То, что это делается на уровне DC, а не на уровне хоста, раздражает конечно. Как и vmotion диска на уровне VM – hardware.
При этом, даже когда я включил CHAP, но или ранее был сделан логин, или еще по каким-то причинам сессия не переподключилась, то можно сделать LVM том , но при попытке перенести на него тестовую VM – получить:
iscsiadm: initiator reported error (8 - connection timed out)
iscsiadm: Could not login to [iface: default, target: iqn.1991-05.com.microsoft:win25-target01-target, portal: 192.168.2.150,3260].
iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
iscsiadm: Could not log into all portals
После таких включений на стендах всегда надо перегружать initiator, да и target не повредит.
Подключаем iSCSI target с Windows server на Proxmox (Initiator) с CHAP
Для начала удалю все, что сделал до этого – пустой LVM и подключение iSCSI. Тоже неудобно, конечно – есть у тебя том, зачем на нем еще сущности типа LVM применять.
Удалить iSCSI подключение из управления DC нельзя, будет ошибка
delete storage failed: can't remove storage - storage is used as base of another storage (500)
При этом все сущности хранения лежат в одной куче – и iSCSI, и LVM, и все на уровне DC, а не ноды. Поэтому тут тоже надо сразу делать соглашение по именованию.
Удалю сначала LVM, тогда дает удалить и iSCSI.
Без ввода CHAP в GUI (его там нет) подключение к порталу проходит . Но при попытке создать LVM не возникает список томов для создания LVM.
Придется на ручном приводе (в норме, конечно, через Ansible)
nano (или vi) /etc/iscsi/iscsid.conf
Конфигурация содержит блоки:
1 # To enable CHAP authentication set node.session.auth.authmethod
2 # To set a CHAP username and password for initiator
3 # To set a CHAP username and password for target(s)
4 # To enable CHAP authentication for a discovery session to the target, set discovery.sendtargets.auth.authmethod to CHAP. The default is None.
5 # To set a discovery session CHAP username and password for the initiator
6 # To set a discovery session CHAP username and password for target(s)
Мне нужны
node.session.auth.authmethod = CHAP
node.session.auth.username = user
node.session.auth.password = password1234
и потом по вкусу
systemctl restart iscsid
iscsiadm -m node --portal "172.16.211.151" --login
после чего должны получить:
iscsiadm: default: 1 session requested, but 1 already present.
iscsiadm: Could not log into all portals
посмотрим, что там:
iscsiadm -m discovery -p 172.16.211.151 -t st
о, все работает, нужные порталы есть, не нужных порталов нет!
Если вы все сделали правильно, то в GUI появится возможность выбора base volume
И при попытке создать LVM вы получите ошибку –
create storage failed: command '/sbin/pvs --separator : --noheadings --units k --unbuffered --nosuffix --options pv_name,pv_size,vg_name,pv_uuid /dev/disk/by-id/scsi-360003ff44dc75adcbb96b955813029da' failed: exit code 5 (500)
Хотя должна была быть другая ошибка -
create storage failed: vgcreate vg01 /dev/disk/by-id/scsi-360003ff44dc75adc839073953a451b73 error: Cannot use device /dev/sdc with duplicates. (500)
Отключу один IP на windows target и проверю:
service open-iscsi status
systemctl restart iscsid.service
systemctl restart open-iscsi.service
/etc/init.d/open-iscsi restart
Ничего не помогает, сессия со стороны Linux до 10.0.12.151, была и осталась. Со стороны Windows target TCP сессий при этом нет.
И так ничего не получается.
И ладно, да и пошло все, семь бед – один reboot.
после ребута все хорошо, один путь, но при создании группы получаю ошибку, что группа уже создана!
create storage failed: device '/dev/disk/by-id/scsi-360003ff44dc75adcbb96b955813029da' is already used by volume group 'VGiscsi01' (500)
Удалю ее (на уровне хоста в disks – LVM) и пересоздам.
ВЖУХ И ВСЕ СОЗДАЛОСЬ.
Снова удалю, верну обратно два пути на target, перезагружу proxmox (видимо, самый надежный метод),
посмотрим, что там:
iscsiadm -m discovery -p 172.16.211.151 -t st , отлично, два портала на месте.
Создам еще раз LVM через GUI, и отлично, ошибка создания воспроизвелась,
create storage failed: command '/sbin/pvs --separator : --noheadings --units k --unbuffered --nosuffix --options pv_name,pv_size,vg_name,pv_uuid /dev/disk/by-id/scsi-360003ff44dc75adcbb96b955813029da' failed: exit code 5 (500)
И группа iscsiVG02 создалась! Хотя и не должна была!
Надо будет воспроизвести и баг репорт написать.
Подключаем iSCSI target с Windows server на Proxmox (Initiator) с CHAP и Multipath
Читаем ISCSI Multipath, видим что текст устарел, идем на Multipath. В втором окне не забываем открыть Подключение iSCSI диска в Proxmox – там как раз про multipath есть параграф.
В старом тексте есть абзац
# apt-get install multipath-tools
В новом тексте
apt install multipath-tools
Но почему-то в середине текста.
Окей, multipath-tools поставил,
nano /etc/iscsi/iscsid.conf поправил, lsblk посмотрел, wwid сравнил
/lib/udev/scsi_id -g -u -d /dev/sdc
/lib/udev/scsi_id -g -u -d /dev/sdd
остальные настройки прописал, только для 7.3-6. сервис был
systemctl restart multipath-tools.service
а в 9 стал
systemctl restart multipathd.service
или я опять что-то путаю.
Доделаю. multipath -r; multipath –ll; multipath -v3
Следующий раздел меня, конечно, удручает:
Multipath setup in a Proxmox VE cluster If you have a Proxmox VE cluster, you have to perform the setup steps above on each cluster node. Any changes to the multipath configuration must be performed on each cluster node. Multipath configuration is not replicated between cluster nodes.
Впрочем, на ESXi с прописыванием esxcli storage nmp satp list и esxcli storage nmp satp rule, на каждом хосте, все то же самое.
Далее далее, новая VG создалась. ВЖУХ и трансфер прошел.
На физическом сервере можно было померять скорость доступа и нагрузку на интерфейсы, но в nested среде особого смысла в этом нет.
