Tilda Publishing
Привет, любопытный друг. Да, это Tilda. Потому что мы хотим быстро внедрять и управлять решением, а не ждать
в очереди разработчика. Контроль, предсказуемость и отказоустойчивость — наша главная идея.
get@work-system.ru
Для запросов и ТЗ
+7 495 108-54-54
с 9:30 до 18:00
Заказать звонок
Получить КП
Услуги
Серверы
Коммутаторы
IT-решения
Процессоры
Конфигуратор
О компании
get@work-system.ru
Для запросов и ТЗ

+7 495 108-54-54
с 9:30 до 18:00
Заказать звонок
Получить КП
Подберём типовое или произведем на заказ серверное оборудование, предоставим расчёт и поможем интегрировать в систему.

Заполните форму запроса слева или отправьте описание вашей задачи на почту get@work-system.ru

При отправке письма на почту укажите номер телефона вашего специалиста для обсуждения аналогов оборудования в случае необходимости

Как подключить СХД к серверу: подробная инструкция, схемы топологий и настройка отказоустойчивости

СХД — это устройство или платформа. SAN — сеть, по которой СХД предоставляет блочный доступ. NAS — файловый протокол. JBOD — расширение ёмкости без собственной логики управления.

Содержание

1
Как правильно подключить систему хранения данных (СХД) к серверу
2
Основные способы подключения дисковых массивов
3
Что проверить до подключения: совместимость, порты, кабели и топология
4
Схема и физическое подключение дискового массива к серверу
5
Пошаговая инструкция: программная настройка подключения СХД к серверу
6
Что делать, если сервер не видит LUN: диагностическое дерево
7
Проверка после подключения: что должно быть в норме
8
Настройка отказоустойчивости: MPIO, ALUA, резервные пути и тест аварии
9
Частые ошибки при подключении СХД к серверу
10
Задачи СХД: виртуализация серверов, 1С и резервное копирование
11
Как выбрать СХД и сервер под нагрузку
12
Помощь в выборе сервера и сетевого оборудования
13
FAQ по подключению СХД к серверу

Как правильно подключить систему хранения данных (СХД) к серверу

Подключение СХД к серверу — это не только кабельное соединение. Правильно подключить систему хранения данных означает пройти полный путь: проверить совместимость, выбрать протокол, выполнить физическую коммутацию по резервной схеме, создать RAID и LUN на стороне дискового массива, выполнить маппинг и настроить multipath. Только после этого внешнее хранилище становится надёжным рабочим томом. Без каждого из этих шагов подключение остаётся неполным — и риски простоя сохраняются.
Короткий ответ: из каких этапов состоит подключение СХД
  1. Проверить совместимость сервера, HBA/NIC, ОС и модели массива по HCL.
  2. Выбрать тип подключения: DAS, iSCSI, Fibre Channel — реже NAS для файловых задач.
  3. Выполнить физическую коммутацию по резервной схеме.
  4. Создать RAID/пулы и LUN на стороне СХД.
  5. Выполнить маппинг LUN серверу.
  6. Настроить инициатор, MPIO, файловую систему и мониторинг.
  7. Проверить отказоустойчивость и производительность.
Когда серверу нужна именно СХД, а не локальные диски
Локальных дисков хватает для одной изолированной системы. СХД становится необходимостью в нескольких случаях.

  • Виртуализация и кластеры — shared storage для нескольких хостов, live migration, высокая доступность. Требования к ёмкости для enterprise-виртуализации быстро выходят за пределы локального массива и зависят от числа ВМ, профиля I/O и политики резервирования.
  • Базы данных и 1С — низкая задержка, предсказуемый I/O, отдельные тома под БД и журналы транзакций.
  • Централизованное резервное копирование — большая ёмкость, потоковая запись, изоляция backup-нагрузки.
  • Масштабируемое хранение — рост ёмкости без замены сервера, миграция данных между узлами.
  • Высокая доступность — обслуживание без простоя, контроллеры с горячим резервом.
«На практике большинство проблем возникает не на этапе создания LUN, а из-за отсутствия резервных путей, ошибок VLAN/zoning и неподтверждённой совместимости драйверов.» — инженер по серверной инфраструктуре, Work System

Основные способы подключения дисковых массивов

Дисковые массивы подключают тремя принципиально разными способами: локально (DAS), через выделенную сеть хранения (SAN) или через файловый протокол (NAS). Выбор определяется бюджетом, требованиями к производительности, числом серверов и нужным уровнем отказоустойчивости. Ошибка в выборе архитектуры на старте обходится дороже, чем правильный выбор оборудования. Подробнее о том, что такое СХД и чем она отличается от смежных решений, — в отдельном материале.
DAS — прямое подключение СХД или JBOD к одному серверу
DAS (Direct Attached Storage) — прямое соединение массива с сервером без промежуточной сети хранения. Это самый простой и дешёвый сценарий.

Где применяется: один сервер, ограниченный бюджет, локальные задачи без требования к shared storage.

Плюсы: минимальная задержка, простота подключения, минимум оборудования. Технология SAS direct attach обеспечивает высокую пропускную способность на x4-wide links без Ethernet-оверхеда — конкретные показатели зависят от поколения интерфейса и конфигурации.

Минусы: слабая масштабируемость, нет совместного доступа для нескольких серверов, ограничен числом портов HBA.

Когда подходит дисковая полка по SAS: малый офис, одна бизнес-система, нет строгих требований к shared storage.

Варианты DAS-подключения
  • Через внутренний или внешний SAS HBA.
  • Через RAID-контроллер сервера.
  • Подключение JBOD/дисковой полки к серверу.
  • Подключение дисковой полки к двум контроллерам для резервирования путей.
SAN — блочный доступ по выделенной сети хранения
SAN (Storage Area Network) — отдельная среда передачи данных исключительно для блочного доступа к хранилищу. Среди актуальных вариантов в 2026 году — Fibre Channel, iSCSI поверх Ethernet 10+ Гбит/с и NVMe-oF для All-Flash массивов.

Где применяется: несколько серверов, виртуализация, кластеры, базы данных, критичные бизнес-системы.

Плюсы: масштабируемость, высокая доступность, централизованное управление томами, поддержка live migration.

Минусы: выше стоимость и сложность эксплуатации по сравнению с DAS.
NAS — когда нужен файловый, а не блочный доступ
NAS (Network Attached Storage) предоставляет файловый доступ по протоколам SMB и NFS, а не блочные тома. Это принципиальное отличие от SAN с LUN.

Серверу нужен NAS, когда задача — общий доступ к файлам, архивы, резервное копирование через файловый протокол. NAS не подходит для гипервизоров, работающих с VMFS/NTFS на блочном уровне, и для кластерных БД с жёсткими требованиями к задержке.
Каскадное подключение и расширение дисковых полок
Expansion shelf (дисковая полка расширения) подключается к основному массиву для наращивания ёмкости без замены контроллера. Важные ограничения: каждый производитель задаёт максимальное число каскадируемых полок; перегрузка шины (oversubscription) при каскадировании снижает производительность. Карту портов и пропускную способность нужно рассчитывать заранее.

Что проверить до подключения: совместимость, порты, кабели и топология

До физического подключения нужно проверить не только разъёмы. Несовместимость firmware, неподдерживаемая ОС, неверный стек multipath или неправильная топология портов — всё это приводит к проблемам, которые сложно диагностировать после монтажа. Час проверки до подключения экономит дни разбора инцидента после. Если вы ещё только определяетесь с конфигурацией, полезно выбрать систему хранения данных под конкретную задачу до этапа монтажа.
Проверка совместимости по HCL
HCL (Hardware Compatibility List) — официальный список совместимого оборудования от производителя СХД или гипервизора. Без проверки по HCL подключение ведётся вслепую.

Что проверить:
  • Совместимость модели СХД и сервера.
  • Поддерживаемые ОС: Windows Server, Linux (RHEL, SUSE, Ubuntu), VMware ESXi, Hyper-V.
  • Совместимость HBA/NIC, версий драйверов и firmware.
  • Поддерживаемые версии multipath-стека.

Официальные HCL-ресурсы вендоров: Dell Storage Compatibility Matrix (E-Lab Navigator), HPE Servers Support and Certification Matrices, Broadcom VMware Hardware Compatibility Guide, Cisco UCS Hardware Compatibility List.

Для VMware — обязательна проверка VMware Compatibility Guide (VCG) и обновление firmware через vSphere Update Manager. Для Hyper-V — Microsoft Windows Server Catalog. Для Linux — документация Red Hat, SUSE, Ubuntu.
Таблица инвентаризации: что собрать до окна работ
Скопируйте и заполните до начала монтажа:
Инвентаризация подключений
Параметр
Значение
Hostname
ОС / гипервизор
Модель HBA / NIC
Версия драйвера / firmware
IQN / WWPN
Switch / Fabric
Controller port
VLAN / Subnet
LUN ID
Размер тома
FS / Datastore
Path policy
Rollback note
Выбор правильной топологии резервирования
Минимальная отказоустойчивая схема: два независимых пути от сервера к СХД через разные HBA/NIC, подключённые к разным коммутаторам или контроллерам. Объединение двух путей на одном коммутаторе приводит к полной потере доступа к LUN при его отказе — это нарушение HA-архитектуры.

  • Один контроллер → нет отказоустойчивости на уровне контроллера.
  • Два контроллера, один путь → один коммутатор создаёт single point of failure.
  • Два независимых пути через разные коммутаторы/fabric → корректная схема.
  • FC: fabric A и fabric B — полностью изолированные.
  • iSCSI: два независимых Ethernet-пути через разные коммутаторы, разные VLAN.

Контр-примеры неправильных схем:
❌ Оба кабеля → один коммутатор: выход коммутатора из строя = полная потеря доступа.
❌ Оба пути → один контроллер СХД: выход контроллера из строя = нет failover.
✅ NIC1 → Switch A → Controller A; NIC2 → Switch B → Controller B: корректная HA-схема.
Кабели, трансиверы и используемые порты
  • Проверить типы портов на сервере и СХД: SFP, SFP+, QSFP.
  • Убедиться в совместимости трансиверов: DAC, AOC, оптика — по спецификации вендора.
  • Проверить длину и класс кабеля под расстояние в стойке и между стойками.
  • Зафиксировать карту портов: controller A/B, host port 1/2, switch A/B — до начала монтажа

Что подготовить заранее
Подготовка по протоколам
Протокол
Что подготовить
iSCSI
IP-адреса target-портов, VLAN-теги, подсети, план MPIO
Fibre Channel
WWPN всех HBA и портов СХД, схема zoning
SAS
Схема портов контроллера A/B, карта кабелей
Общее
Имена хостов/host groups, схема маппинга LUN, план окон работ, rollback

Схема и физическое подключение дискового массива к серверу

Физическое подключение дискового массива к серверу выполняется строго по схеме производителя с учётом резервирования по контроллерам и коммутаторам. Правильное подключение с помощью кабелей соответствующих типов — это не только правильно вставленные разъёмы, но и корректная трассировка по независимым путям с использованием нужных портов. Неправильная разводка создаёт single point of failure даже при двух физических кабелях: если оба пути идут через один коммутатор или один контроллер, отказоустойчивости нет. Схема подключения дисковой полки к серверу должна быть зафиксирована на бумаге до начала монтажа.
Шаг 1. Отключение риска ошибок перед кабелированием
  • Сверить схему подключения с документацией производителя.
  • Подписать кабели с обеих сторон перед монтажом.
  • Проверить питание, заземление, позиции в стойке.
  • Развести кабельные трассы по независимым PDU и физическим путям.
Шаг 2. Подключение по SAS
  1. Установить SAS HBA или RAID-контроллер в сервер.
  2. Определить внешние SAS-порты сервера и порты полки/СХД.
  3. Подключить контроллер A к серверному порту 1.
  4. При двухпутевой схеме подключить контроллер B ко второму порту или второму HBA.
  5. Проверить индикацию линка и обнаружение enclosure.
Шаг 3. Подключение по iSCSI
  1. Выделить отдельные сетевые порты под storage-трафик.
  2. Подключить NIC 1 к коммутатору/storage path A, NIC 2 — к path B.
  3. Настроить отдельные VLAN и подсети для iSCSI.
  4. Не объединять iSCSI-пути в LACP — используйте LACP только если это явно рекомендовано вендором СХД, так как это может конфликтовать с multipath best practice.
  5. Проверить доступность target-портов по IP после подключения.
Шаг 4. Подключение по Fibre Channel
  1. Установить FC HBA в сервер.
  2. Подключить HBA port 1 в fabric A, HBA port 2 — в fabric B.
  3. Подключить controller port A к fabric A, controller port B — к fabric B.
  4. Проверить SFP, скорость линка и логин в fabric.
  5. Зафиксировать WWPN всех портов в таблицу.
Шаг 5. Проверка линков и индикации
  • Link up на всех портах без ошибок.
  • Корректная скорость соединения (согласно спецификации HBA и СХД).
  • Нет CRC-ошибок и error counters на портах.
  • Все порты подписаны и внесены в схему подключения.

Пошаговая инструкция: программная настройка подключения СХД к серверу

После физической коммутации начинается логическая часть. Алгоритм подключения: обновить прошивки → создать пулы и RAID → создать LUN → зарегистрировать сервер на СХД → выполнить маппинг → настроить инициатор в ОС сервера → инициализировать диск и создать файловую систему → проверить, что сервер видит все пути корректно. Важный момент: без MPIO жёсткий диск может отображаться как несколько устройств или вовсе быть недоступен. Программное обеспечение — драйверы, DSM-пакеты, утилиты управления — должно быть установлено на сервере до начала настройки.

Сводная таблица шагов
Шаги программной настройки подключения СХД
Шаг
Действие
Где выполняется
Ожидаемый результат
Как проверить
1
Обновление firmware/драйверов
Сервер + СХД
Актуальные версии по HCL
Сверить с HCL
2
Создание RAID/пула
Интерфейс СХД
Пул создан, диски в online
GUI/CLI СХД
3
Создание LUN
Интерфейс СХД
LUN с нужным размером
GUI/CLI СХД
4
Регистрация хоста (WWPN/IQN)
Интерфейс СХД
Host object создан
GUI/CLI СХД
5
Маппинг LUN
Интерфейс СХД
LUN назначен хосту
GUI/CLI СХД
6
Настройка инициатора
ОС сервера
Сессии/пути активны
iscsiadm / Get-IscsiSession
7
Инициализация диска и FS
ОС сервера
Том доступен в ОС
lsblk / Disk Management
8
Проверка путей и MPIO
ОС сервера
2+ активных пути, один WWID
multipath -ll / MPIO
Шаг 1. Обновить прошивки, драйверы и утилиты управления
  • Firmware СХД — до версии, указанной в HCL.
  • BIOS/UEFI сервера.
  • Драйвер HBA/NIC — строго по HCL гипервизора или ОС.
  • Вендорские DSM/MPIO-пакеты.
  • CLI/GUI утилиты управления массивом.
Шаг 2. Создать RAID-группу, storage pool или disk group на СХД
Выбрать уровень RAID под задачу, учесть hot spare, разделить production- и backup-нагрузки при необходимости.
Как подобрать RAID под тип нагрузки

  • RAID 10 — БД, 1С, виртуализация. Высокие random IOPS, оптимален для нагрузок с частыми случайными операциями чтения/записи. Overhead по ёмкости — 50%. Итоговые IOPS зависят от типа дисков, кэша контроллера и профиля блока.
  • RAID 5/6 — архив, файловое хранение, backup repository. Эффективность ёмкости N-1/N-2. Производительность на последовательных операциях выше, на random write — ниже RAID 10. Конкретные показатели зависят от конфигурации.
  • Vendor-specific pools/tiering — если поддерживается массивом, позволяет автоматически перемещать горячие данные на быстрые носители.
Шаг 3. Создать LUN/Volume
  • Указать размер тома.
  • Указать тип provisioning: thick (всё пространство резервируется сразу) или thin (выделение по мере записи).
  • Выбрать block size/segment под профиль нагрузки, если применимо.
  • Включить ALUA/оптимизацию путей при поддержке массивом.
Шаг 4. Создать объект сервера на СХД
  • Для FC: добавить WWPN всех портов сервера.
  • Для iSCSI: IQN инициатора.
  • Для SAS: host mapping по порту/HBA, если требуется платформой.
  • При кластерных сценариях: объединить серверы в host group или cluster group.
Шаг 5. Выполнить маппинг LUN серверу
  • Назначить LUN конкретному серверу или группе.
  • Проверить LUN ID — он должен быть уникальным в рамках host group.
  • Не маппить один LUN разным серверам без кластерной файловой системы и механизма координации доступа.
  • Задокументировать соответствие host ↔ LUN.
Шаг 6. Настроить инициатор на сервере
Windows: iSCSI Initiator (iscsicpl.exe) → MPIO (mpio.cpl) → Device Manager.
Linux: iscsiadm, multipathd, lsscsi, lsblk.
VMware ESXi: Storage Adapters → Datastores → Path Selection Policy.
FC: rescan HBA, проверить fabric login, зафиксировать WWPN.
SAS: scan bus/enclosure, проверить обнаружение дисковой полки.

Минимальные действия для Windows Server
  1. Установить компонент MPIO (Диспетчер серверов → Компоненты).
  2. В mpio.cpl → Discover Multi-Paths → Add support for iSCSI devices, перезагрузка.
  3. В iscsicpl.exe → Discovery → Discover Portal (IP target-порта).
  4. Targets → Connect → установить галочку persistent session и Enable multi-path.
  5. В Disk Management (diskmgmt.msc): Online → Initialize Disk (GPT) → New Simple Volume → NTFS.

Проверка через PowerShell:
# Проверка iSCSI-инициатора
Get-Service MSiSCSI | Set-Service -StartupType Automatic
Start-Service MSiSCSI
(Get-InitiatorPort).NodeAddress

# Добавление target-порталов
New-IscsiTargetPortal -TargetPortalAddress <ip_portal_1> -TargetPortalPortNumber 3260 -InitiatorPortalAddress <ip_initiator_1>
New-IscsiTargetPortal -TargetPortalAddress <ip_portal_2> -TargetPortalPortNumber 3260 -InitiatorPortalAddress <ip_initiator_2>

# Просмотр таргетов
Get-IscsiTarget

# Проверка дисков
Get-Disk

# Проверка MPIO-сессий
Get-IscsiSession
Минимальные действия для Linux
# Установка пакетов (Debian/Ubuntu)
apt-get update && apt-get install open-iscsi multipath-tools

# Установка пакетов (CentOS/RHEL)
yum install iscsi-initiator-utils device-mapper-multipath

# Обнаружение target
sudo iscsiadm -m discovery -t sendtargets -p <IP>:3260
# Вывод: 192.0.2.1:3260,1 iqn.2024.com.example:target1

# Логин
sudo iscsiadm -m node -T iqn.2024.com.example:target1 -p <IP>:3260 --login

# Логин на все найденные target
sudo iscsiadm -m node --loginall=all

# Проверка сессий (ожидаемый результат: 2 активные сессии)
iscsiadm -m session

# Проверка путей multipath (ожидаемый результат: один WWID, два активных пути)
multipath -ll

# Обнаружение блочного устройства
lsblk -o NAME,HCTL,SIZE,TYPE,MOUNTPOINT

# Rescan шины (если устройство не появилось)
echo "- - -" > /sys/class/scsi_host/hostX/scan

# Автостарт после перезагрузки
iscsiadm -m node --loginall=automatic
systemctl enable iscsi.service
systemctl enable iscsid.service
Настроить /etc/multipath.conf по рекомендациям вендора СХД.

Минимальные действия для VMware ESXi
  1. Проверить адаптеры хранилища (Storage Adapters).
  2. Выполнить rescan всех адаптеров.
  3. Настроить PSP (Path Selection Policy) согласно рекомендациям вендора: Round Robin или Vendor-specific NMP Plugin.
  4. Создать datastore VMFS или настроить raw device mapping (RDM) при необходимости.
  5. Убедиться, что каждый ESXi-хост видит LUN и все пути через Storage Adapters → Rescan.
Шаг 7. Инициализировать диск и создать файловую систему
  • GPT — для всех новых томов (поддерживает объёмы >2 TB).
  • NTFS/ReFS — Windows Server (ReFS рекомендуется для backup и Hyper-V).
  • XFS/ext4 — Linux (XFS предпочтительнее для крупных томов и баз данных).
  • VMFS — VMware ESXi.
  • Размер allocation unit / block size выбирать под профиль нагрузки. Для ряда SQL и 1С-сценариев часто используют 64 KB — уточняйте рекомендации вашей СУБД и вендора.
  • Задать метки томов и придерживаться стандарта именования.
Шаг 8. Убедиться, что сервер корректно видит все пути и тома
  • Количество путей соответствует ожидаемому (минимум 2).
  • Активный/оптимальный путь определён корректно.
  • Идентификатор LUN/serial/WWID совпадает с зафиксированным.
  • Нет дублирующихся устройств.
  • Корректное отображение тома в ОС и приложениях.
  • После перезагрузки сервера: сессии и пути восстанавливаются автоматически.
Важно: названия пунктов меню, поддержка ALUA/DSM и порядок настройки зависят от конкретного вендора СХД. Перед настройкой сверяйтесь с официальным Admin Guide вашей модели массива: Dell EMC, NetApp, Huawei, HPE, IBM, Pure Storage.

Что делать, если сервер не видит LUN: диагностическое дерево

Это самый частый запрос после первичного подключения. Пройдите по шагам последовательно — большинство проблем диагностируется за 10 минут.

  1. Link up на всех портах? Проверить индикацию HBA/NIC, счётчики ошибок на портах коммутатора.
  2. Видны ли target portals / fabric login? iscsiadm -m session (Linux), Get-IscsiTarget (Windows), проверить login HBA в fabric (FC).
  3. Верен ли IQN / WWPN в host object на СХД? Сверить идентификатор инициатора с тем, что зарегистрировано в GUI/CLI СХД — это самая частая причина.
  4. Есть ли zoning / masking / mapping? Проверить FC zoning (show zone vsan), LUN masking и mapping в интерфейсе СХД.
  5. Выполнен ли rescan? На Linux: echo "- - -" > /sys/class/scsi_host/hostX/scan. На Windows: Disk Management → Action → Rescan Disks. На ESXi: Rescan adapters.
  6. Установлен ли и запущен ли MPIO/DSM? Проверить статус multipathd (Linux), MPIO Feature (Windows), Path Selection Policy (ESXi).
  7. Совпадает ли HCL / firmware / driver? Сверить версию драйвера HBA и firmware СХД с compatibility matrix.
  8. Появился ли WWID/serial? multipath -ll (Linux) — должен быть один WWID с несколькими путями.
  9. Нет ли duplicate devices? Если LUN виден как несколько дисков — MPIO не настроен или не активирован.
  10. Что в логах ОС / HBA? dmesg | grep -i scsi (Linux), Event Viewer → System (Windows), /var/log/messages.

Проверка после подключения: что должно быть в норме

Windows Server
# Активные iSCSI-сессии
Get-IscsiSession

# Список дисков
Get-Disk

# Проверка MPIO-устройств
Get-MSDSMGlobalDefaultLoadBalancePolicy

# Проверка томов
Get-Volume
Что считать нормой: статус диска = Online, тип раздела = GPT, файловая система создана, в MPIO — 2+ активных пути, диск виден как одно устройство (не несколько).
Linux
# Активные iSCSI-сессии
iscsiadm -m session
# Норма: 2 сессии (по одной на каждый путь)

# Мультипатиинг
multipath -ll
# Норма: один WWID, два (или более) active paths, policy Round Robin или vendor-specific

# Блочные устройства
lsblk -o NAME,HCTL,SIZE,TYPE,MOUNTPOINT
# Норма: устройство появилось один раз под именем /dev/dm-X

# После перезагрузки: проверить автостарт
systemctl status multipathd
iscsiadm -m session
VMware ESXi
  • Storage Adapters → Rescan: LUN виден, количество paths = ожидаемому.
  • Path Selection Policy: Round Robin (или vendor PSP) — настроена.
  • Datastore создан, доступен на всех хостах кластера.
  • VAAI: offload-операции активны (проверить через esxcli storage core device vaai status get).
FC и SAS: базовые проверки
  • FC: show flogi database на коммутаторе — все HBA залогинены в fabric.
  • FC: show zone — зоны активны, состав корректный.
  • SAS: enclosure видна (lsblk, GUI СХД), диски в статусе online.
  • Счётчики ошибок на портах коммутатора / HBA = 0 или не растут.

Настройка отказоустойчивости: MPIO, ALUA, резервные пути и тест аварии

Дисклеймер: Тестирование отказоустойчивости затрагивает производственную инфраструктуру. Выполняйте тесты только в согласованное окно обслуживания при минимальной нагрузке на систему.
Подключение СХД без multipath — неполная и рискованная схема. Два физических кабеля без корректно настроенного MPIO не обеспечивают высокую доступность: ОС просто видит два отдельных диска или, что хуже, конфликтующие устройства. Отказоустойчивость — это не «подключить два кабеля», а настроенный стек от физики до политики переключения путей.
Что такое MPIO и зачем он нужен
MPIO (Multipath I/O) — программный стек, который объединяет несколько физических путей к одному LUN в единое логическое устройство для ОС. Он обеспечивает автоматический failover при отказе пути и балансировку нагрузки. Без MPIO ОС может видеть один LUN как несколько разных дисков, что приводит к дублированию устройств и риску некорректной работы.
Как работает ALUA
ALUA (Asymmetric Logical Unit Access, стандарт SCSI-3) добавляет к MPIO интеллект: хост автоматически запрашивает состояния портов СХД SCSI-командами и получает ответ — Active/Optimized (максимальная производительность через «родной» контроллер) или Active/Non-Optimized (доступ через резервный контроллер, с задержкой). Без ALUA ручная настройка путей обязательна. Поддержка ALUA и необходимость vendor DSM зависят от конкретной модели массива — уточняйте в официальной документации вендора.
Настройка MPIO для iSCSI
  • Использовать persistent sessions для сохранения подключения после перезагрузки.
  • Каждый NIC подключить в отдельную подсеть/VLAN storage-трафика.
  • Установить vendor DSM или использовать native MPIO ОС — выбор зависит от вендора и модели массива.
  • Проверить политики failover после настройки — каждый путь должен быть виден как отдельная сессия.
Настройка multipath для FC
  • Установить поддержку HBA и vendor DSM.
  • Настроить path policy согласно рекомендации вендора СХД.
  • Fabric A и fabric B должны быть полностью изолированы: разные FC-коммутаторы, разные зоны.
  • Исключить single fabric design — это нарушение требований high availability.
Частая ошибка: два физических пути через один коммутатор или один контроллер создают ложное ощущение резервирования. Коммутатор в этом случае является единственной точкой отказа на уровне fabric. Требования к независимым коммутаторам для FC/iSCSI multipathing содержатся в официальных Storage Best Practices Guide вендоров (Dell EMC, HPE, NetApp) — уточняйте в документации вашего оборудования.
Тестирование отказа: формализованная приёмка
Сценарии тестирования отказоустойчивости СХД
Действие
Ожидаемый результат
Что не должно случиться
Что проверить после возврата пути
Отключить 1 кабель
I/O продолжается через второй путь
Приложение не теряет доступ, нет filesystem remount/read-only
Путь восстановлен, active paths = ожидаемому значению
Отключить 1 коммутатор/fabric
Автоматическое переключение на резервный fabric
I/O не прерывается, WWID не меняется
Оба пути активны после возврата коммутатора
Перезапустить controller B
I/O идёт через controller A
Нет потери данных, нет ошибок приложения
После возврата controller B пути восстановлены, нет дублей
Перезагрузить сервер
После boot сессии и пути восстановились автоматически
Не требуется ручное подключение
iscsiadm -m session / multipath -ll — норма

Частые ошибки при подключении СХД к серверу

Большинство инцидентов при подключении СХД — следствие нескольких типовых ошибок. Раздел построен как антипаттерны с быстрыми исправлениями.
Ошибка №1: Подключение в один путь
Симптом: при обрыве кабеля или отказе порта — полная потеря доступа к данным. Причина: single point of failure на уровне кабеля, HBA или коммутатора. Как исправить: минимум два независимых пути через разные HBA/NIC и разные коммутаторы.
Ошибка №2: Игнорирование HCL и совместимости firmware
Симптом: нестабильность, нераспознанные LUN, деградация производительности. Причина: неподдерживаемая комбинация HBA, драйвера и версии прошивки СХД. Как исправить: сверка по официальной matrix compatibility до монтажа.
Ошибка №3: Неправильная сеть для iSCSI
Симптом: потери пакетов, высокая задержка, нестабильное подключение. Причина: iSCSI-трафик в общей сети конкурирует с обычным. Как исправить: выделенные VLAN и подсети; Jumbo Frames — только при полной поддержке цепочки и по рекомендации вендора.
Ошибка №4: Неверный zoning/masking
Симптом: сервер не видит LUN или видит лишние устройства. Причина: широкие зоны с несколькими инициаторами и таргетами, ошибки в составе зоны. Множественные инициаторы в одной зоне могут вызывать RSCN-флуд и нестабильность fabric — это задокументированная проблема в FC-сетях. Как исправить: single-initiator zoning — одна зона на один HBA-порт сервера и один storage-порт.
Ошибка №5: Один LUN для нескольких серверов без кластера
Симптом: повреждение файловой системы, недоступность данных. Причина: нет координации одновременного доступа. Как исправить: отдельный LUN на каждый сервер либо кластерная конфигурация с поддерживаемой платформой.
Ошибка №6: Неправильный размер тома, FS и allocation unit
Симптом: деградация производительности без видимых причин. Причина: несоответствие block size профилю нагрузки. Как исправить: выбирать параметры под профиль нагрузки до форматирования, уточнять рекомендации вендора СУБД.
Ошибка №7: Нет резервного копирования перед миграцией
Симптом: риск потери данных при ошибке в процессе подключения или перенастройки. Как исправить: полный backup с проверкой восстановления до начала любых работ.
Ошибка №8: Нет теста аварийного переключения
Симптом: резервирование «на бумаге» не работает в реальной аварии. Как исправить: обязательный failover test в согласованное окно обслуживания до ввода в продакшен.
Типовые ошибки при подключении СХД к серверу
Ошибка
Симптом
Причина
Как проверить
Как исправить
Один путь
Полная потеря доступа при обрыве
Single point of failure
multipath -ll, MPIO
2 независимых пути
HCL/firmware
Нестабильность, LUN не виден
Несовместимость
Сверить с HCL вендора
Обновить firmware, сменить драйвер
iSCSI в общей сети
Потери пакетов, задержки
Конкуренция трафика
ping + iperf по storage-пути
Выделить VLAN/подсеть
Ошибки zoning/masking
Сервер не видит LUN
Неверная зона или маска
show zone vsan, LUN mapping
Single-initiator zoning, пересмотр mapping
Один LUN на два сервера
Повреждение FS
Нет координации доступа
Проверить mapping на СХД
Отдельный LUN или кластер
Неверный block size
Деградация производительности
Несоответствие профилю
fio или CrystalDiskMark
Переформатировать с правильным размером
Нет backup
Риск потери данных
Отсутствие регламента
Проверить наличие резервной копии
Backup + тест восстановления
Нет failover-теста
Резервирование не работает
Не проверялось
—
Плановый тест в окне обслуживания

Задачи СХД: виртуализация серверов, 1С и резервное копирование

Выбор интерфейса, уровня RAID и политики MPIO напрямую зависит от задачи, которую решает СХД. Сценарий использования влияет на всё: от требований к latency и IOPS до политики резервных копий и защиты от потерь данных. Чтобы подобрать систему хранения данных под конкретную нагрузку, важно понимать профиль I/O ещё до выбора оборудования — настройка серверов и СХД под конкретную задачу начинается именно здесь.

Серверы 1С и БД: низкая задержка, предсказуемый random I/O, RAID 10, отдельные тома под БД и журналы транзакций, аккуратная настройка ОС под профиль нагрузки. Приоритет: IOPS над ёмкостью.

Виртуализация серверов: shared storage для нескольких хостов, MPIO на каждом узле, datastore VMFS или CSV, учёт boot storms при массовом запуске ВМ, RAID 10.

Резервное копирование: большая ёмкость, последовательная запись, RAID 5/6, изоляция backup-нагрузки от production-сети. Хранение резервных копий на отдельном томе снижает риск потерь данных при инцидентах. Приоритет: ёмкость.

Файловые сервисы и архивы: приоритет ёмкости над IOPS, RAID 6 и tiering при наличии, NFS для файлового доступа.

Видеонаблюдение: последовательная запись большими блоками, высокоёмкие HDD, RAID 5/6, отдельные политики retention. Приоритет: throughput при последовательном доступе, конкретные показатели зависят от конфигурации.

Как выбрать СХД и сервер под нагрузку

Выбор СХД — это не выбор бренда. Это выбор характеристик под конкретную задачу, бюджет и требования к масштабированию. Правильный вопрос не «какой бренд лучше», а «каких IOPS, ёмкости и уровня отказоустойчивости достаточно для наших задач на горизонте 3 лет».
Какие параметры важнее бренда
  • IOPS и latency — под профиль нагрузки (random для БД, sequential для backup).
  • Ёмкость raw/usable с учётом RAID overhead.
  • Количество контроллеров и портов — минимум два контроллера для HA.
  • Поддержка MPIO/ALUA.
  • Snapshot, replication, thin provisioning.
  • HCL-совместимость с вашей платформой: ESXi, Hyper-V, Linux, Windows Server.
Как оценить нагрузку до покупки
  • Тип приложений и профиль I/O.
  • Размер рабочего набора данных.
  • Пиковые и средние операции чтения/записи.
  • Рост ёмкости на 1–3 года.
  • Нужен ли shared storage для нескольких хостов.
Когда достаточно одного сервера с DAS
  • Малый офис, одна бизнес-система.
  • Нет требования к shared storage и live migration.
  • Бюджет не позволяет отдельную SAN-инфраструктуру.
Когда нужен SAN
  • Несколько серверов или хостов виртуализации.
  • Кластеры с требованием к общему storage.
  • Требование к масштабируемости ёмкости без замены серверов.
  • Высокая доступность и SLA с минимальным временем восстановления.

Помощь в выборе сервера и сетевого оборудования

Если нужен один сервер с DAS, кластер из двух узлов или полноценная SAN-инфраструктура — подбор каждого сервера, HBA и сетевого оборудования требует учёта совместимости, протокола и задачи. Мы помогаем подобрать конфигурацию под iSCSI, SAS или FC, включая коммутаторы и кабельную составляющую.

FAQ по подключению СХД