SAN в корпоративной IT-среде: практическое руководство по настройке iSCSI и Fibre Channel

SAN объединяет серверы-хосты и дисковый массив через выделенную сеть хранения и предоставляет блочные устройства LUN. Рабочий порядок настройки такой: собрать профиль нагрузки и требования SLA, выбрать iSCSI или Fibre Channel, подготовить два независимых пути, создать LUN, ограничить доступ через masking или host group, настроить Multipath I/O, проверить отказоустойчивость и включить мониторинг.

iSCSI подходит при зрелой Ethernet-инфраструктуре с выделенными интерфейсами или VLAN для storage traffic. Fibre Channel выбирают при наличии FC-коммутаторов, HBA и компетенций по сопровождению fabric. В обоих случаях хост должен видеть назначенные LUN через несколько независимых путей, а MPIO должен объединять эти пути в одно логическое устройство.

Точные команды и параметры зависят от модели массива, ОС, драйверов HBA или NIC и версии гипервизора. Перед изменениями сверяйте support matrix производителя, фиксируйте текущую конфигурацию, подтверждайте резервную копию и заранее определяйте план отката. Настройки сначала проверяют на тестовом хосте или непроизводительном LUN.

Кратко: порядок настройки SAN без критичных пропусков

Начните с описания нагрузки: емкость, IOPS, throughput, размер блока, соотношение чтения и записи, пиковая latency, RPO и RTO. После этого выберите транспорт, подготовьте отдельную сеть iSCSI или две FC fabric, создайте LUN и назначьте его конкретному хосту. На сервере выполните discovery, подключите каждый путь, включите MPIO, проверьте идентификаторы устройства и только затем передавайте LUN файловой системе, гипервизору или кластерному менеджеру.

Завершение работ подтверждается тестом отказа. По очереди отключите один кабель, порт, сетевой интерфейс, FC-коммутатор или путь к контроллеру, затем убедитесь, что I/O продолжается, приложение не теряет том, а путь возвращается после восстановления. После теста включите сбор latency, IOPS, throughput, queue depth, ошибок транспорта, состояния контроллеров и свободной емкости.

Что должно быть результатом настройки

SAN готова к рабочей нагрузке, когда выполнены проверяемые условия:

• хост видит только назначенные ему LUN, а чужие блочные устройства отсутствуют;
• каждый критичный том доступен минимум через два независимых пути;
• MPIO распознал модель массива и применил поддерживаемую политику path selection;
• отказ одного пути, порта или коммутатора не прерывает I/O и не переводит приложение в аварийное состояние;
• резервное копирование и тест восстановления завершились без ошибок;
• в мониторинг поступают latency, IOPS, throughput, queue depth, состояние путей, ошибки интерфейсов и свободная емкость;
• в эксплуатационной документации зафиксированы LUN, WWID, IQN или WWPN, схема путей, настройки MPIO и результаты failover-теста.

Где чаще всего допускают ошибки

• Подключают оба пути через один коммутатор, один кабельный маршрут или один контроллер массива. MPIO не устраняет общий компонент отказа.
• Передают SAN-трафик через пользовательскую сеть без контроля потерь, очередей и загрузки портов.
• Оставляют LUN без masking и тем самым показывают его нескольким хостам, которые не входят в один кластер.
• Форматируют общий LUN на нескольких независимых серверах обычной файловой системой. Это приводит к повреждению метаданных.
• Включают MPIO без проверки vendor-specific параметров, ALUA и поддерживаемой политики путей.
• Размечают каждый найденный путь как отдельный диск вместо объединения путей в один multipath device.
• Увеличивают queue depth без наблюдения за p99 latency и нагрузкой контроллеров.
• Проводят изменения на production без резервной копии, окна работ, ответственного инженера и критерия остановки.

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

Подготовка определяет, выдержит ли хранилище реальную нагрузку и сохранит ли доступ к данным при отказе оборудования. Сначала описывают приложения и пути I/O, затем сверяют компоненты по матрице совместимости. Один высокий показатель пропускной способности массива не компенсирует слабые HBA, перегруженные коммутаторы или неверно выбранную файловую систему.

Какие данные собрать по нагрузке до создания LUN

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

Для каждого сервиса укажите владельца, критичность, требуемую емкость, допустимую latency и допустимое время восстановления. Не складывайте в один LUN базу данных, архивы и резервные копии, если для них различаются профили I/O и политики защиты.

Базовая отказоустойчивая топология

Отказоустойчивая схема содержит два контроллера массива, два независимых storage-пути, два порта на хосте и физически разнесенные подключения. Для iSCSI это два сетевых коммутатора или два изолированных набора портов. Для Fibre Channel это fabric A и fabric B, которые не объединяются в один общий отказной домен.

• Порт host NIC или HBA 1 подключается к fabric A.
• Порт host NIC или HBA 2 подключается к fabric B.
• Контроллер A предоставляет target-порты в обеих fabric или сетях.
• Контроллер B предоставляет target-порты в обеих fabric или сетях.
• Кабели, коммутаторы, блоки питания и трассы по возможности физически разделены.
• Каждый путь получает собственные параметры сети, WWPN или IP-адрес и отражается в таблице подключения.

Два IP-адреса на одном физическом коммутаторе не создают независимые пути. Та же проблема возникает, когда два HBA подключены к одной FC fabric, а массив имеет единственный доступный контроллер.

Для выбора архитектуры хранения полезно сопоставить SAN с DAS, NAS и HCI в отдельной матрице вариантов для виртуализации, баз данных и файловых сервисов.

План изменений, резервного копирования и отката

Перед настройкой назначьте ответственных за массив, сеть, FC fabric, ОС и приложение. Один инженер не должен менять все уровни одновременно без журнала действий. Зафиксируйте конфигурацию до начала работ:

1. Сделайте резервную копию данных и конфигураций массива, коммутаторов, HBA, NIC и гипервизора.
2. Выполните тест восстановления хотя бы одного файла и одного полного тома.
3. Соберите версии firmware, драйверов, multipath-компонентов и гипервизора.
4. Сформируйте таблицу хостов, инициаторов, портов, LUN, путей, владельцев и критичности.
5. Проверьте изменения на тестовом хосте или непроизводительном LUN.
6. Определите критерии остановки: потеря всех путей, рост ошибок, latency выше согласованного порога, изменение идентификатора устройства или ошибки записи.
7. Опишите возврат на старое хранилище и порядок проверки данных после отката.

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

Для временного тестового хоста, сервера мониторинга или отдельной лабораторной площадки можно использовать облачные серверы и хранилища Timeweb Cloud. Такой ресурс не заменяет корпоративный массив и FC fabric, но помогает проверить сценарии ОС, MPIO и наблюдения без изменений в production.

iSCSI или Fibre Channel: как выбрать протокол для корпоративного SAN

Оба протокола передают блочные устройства, но требуют разной инфраструктуры. iSCSI использует Ethernet и проще вписывается в среду, где уже есть сильная команда сетевой эксплуатации. Fibre Channel предоставляет отдельную fabric с собственными HBA, коммутаторами и правилами zoning. Решение принимайте по требованиям нагрузки, доступным навыкам, support matrix и стоимости сопровождения.

Когда выбирать iSCSI

iSCSI подходит для виртуализации, баз данных и серверных приложений, если Ethernet-путь имеет предсказуемую задержку и достаточную пропускную способность. Критичные LUN подключают через несколько NIC и независимые VLAN или физические коммутаторы.

• Выделите интерфейсы и подсети для storage traffic.
• Не смешивайте пользовательский и iSCSI-трафик без контроля очередей, потерь и загрузки портов.
• Согласуйте MTU на каждом участке, если включаете jumbo frames. Несогласованный MTU создает фрагментацию, потери или нестабильный login.
• Не принимайте LACP или другой агрегированный канал за два независимых пути MPIO.
• Используйте CHAP, когда требуется аутентификация инициатора, и mutual CHAP, когда массив должен подтверждать свою сторону.
• Маршрутизацию между подсетями добавляйте только после проверки задержки, MTU, ACL и поведения failover.

iSCSI удобен при расширении числа хостов и автоматизации через привычные сетевые инструменты. Слабое место такой схемы, общий Ethernet-домен без контроля потерь, быстро проявляется ростом latency и retransmits.

Когда оправдан Fibre Channel

Fibre Channel выбирают при наличии выделенной fabric, HBA на серверах и команды, которая умеет сопровождать WWPN, zoning, SFP и firmware. FC отделяет storage traffic от обычной IP-сети, но не отменяет контроль доступа к LUN и настройку MPIO.

• Каждый хостовый HBA подключается к своей fabric.
• Порты массива распределяются между fabric A и fabric B.
• WWPN регистрируются на массиве и в конфигурации zoning.
• Состояние SFP, скорость линка, оптический бюджет и ошибки портов регулярно проверяются.
• Firmware HBA, FC-коммутаторов и массива сверяются с support matrix.
• Схема fabric, aliases, zones и host groups хранится в эксплуатационной документации.

FC дает предсказуемый транспорт при корректно собранной fabric. Ошибки в zoning или masking часто выглядят как проблема ОС, хотя причина находится на уровне доступа к порту или LUN.

Вопросы для принятия решения

1. Есть ли два независимых Ethernet-пути или две FC fabric?
2. Какую latency и пропускную способность требует приложение в пике?
3. Может ли Ethernet-сеть гарантировать нужные потери, MTU и queue depth?
4. Есть ли в команде опыт сопровождения HBA, WWPN и FC-коммутаторов?
5. Поддерживает ли массив нужный режим ALUA, MPIO и path policy на выбранной ОС?
6. Как увеличится число хостов, LUN и портов через год?
7. Как будет проходить обновление firmware без одновременной потери всех путей?
8. Какой вариант проще проверить нагрузочным тестом и восстановить после сбоя?

Выбирайте iSCSI при зрелой Ethernet-инфраструктуре и понятной модели изоляции. Выбирайте Fibre Channel при потребности в отдельной fabric и наличии команды для ее эксплуатации. Окончательное решение подтверждает пилот с реальной нагрузкой, а не название протокола.

Настройка SAN по iSCSI: от изолированной сети до подключения LUN

Настройку iSCSI разделяют на четыре слоя: сеть, массив, initiator хоста и multipath. Сначала проверяют транспорт, затем публикуют LUN, после этого выполняют discovery и login по каждому пути. Нельзя начинать с форматирования диска, пока не подтверждены target, доступ, идентификаторы и число путей.

Подготовка сети iSCSI

1. Определите две подсети, например 10.20.1.0/24 для пути A и 10.20.2.0/24 для пути B. Адреса приведены как пример, используйте согласованный план IP.
2. Назначьте отдельные NIC хоста или отдельные логические интерфейсы, если это поддержано производителем.
3. Создайте отдельные VLAN или подключите NIC к независимым коммутаторам.
4. Проверьте скорость линков, duplex, ошибки CRC, drops, pause frames и загрузку uplink-портов.
5. Согласуйте MTU на хосте, коммутаторах и портах массива. Jumbo frames включайте только после проверки всего пути.
6. Ограничьте доступ ACL так, чтобы initiator достигал только нужных target-портов.
7. Проверьте доступность каждого портала отдельно и зафиксируйте IP, VLAN, MAC и имя интерфейса.

Хост-01 NIC-A 10.20.1.21/24 -> Switch-A -> Array-Controller-A 10.20.1.10
Хост-01 NIC-B 10.20.2.21/24 -> Switch-B -> Array-Controller-B 10.20.2.10

Хост-02 NIC-A 10.20.1.22/24 -> Switch-A
Хост-02 NIC-B 10.20.2.22/24 -> Switch-B

Для проверки используйте ping с указанием интерфейса, тест пропускной способности в согласованное окно и counters коммутатора. Успешный ping не подтверждает стабильность iSCSI: ищите потери, retransmits и рост задержки при нагрузке.

Создание iSCSI Target, LUN и правил доступа

На массиве сначала создают storage pool или volume, затем выделяют LUN. Имена должны отражать владельца и назначение, например prod-sql01-data01 или vmware-cluster01-ds02. Размер выбирайте с учетом роста, snapshots, репликации и свободного пространства пула.

1. Создайте или выберите storage pool, проверив RAID или схему защиты и доступный запас.
2. Создайте LUN и укажите размер, профиль производительности и политику снимков, если они поддерживаются массивом.
3. Создайте iSCSI target или target group.
4. Добавьте IQN каждого разрешенного initiator или группу хостов.
5. Привяжите LUN к target с назначенным LUN ID.
6. Включите CHAP для initiator, если это требуется политикой доступа, и храните секреты в защищенном хранилище.
7. Зафиксируйте имя target, IQN, IP-порталы, LUN ID, размер и владельца.

Доступ выдавайте конкретному IQN или группе хостов. Массовое разрешение по подсети упрощает старт, но увеличивает риск показать LUN неподходящему серверу. Mutual CHAP применяйте, когда его поддерживают массив, ОС и выбранный сценарий подключения.

Target IQN: iqn.2026-09.example:array01.prod
Initiator IQN: iqn.1993-08.org.debian:01:host01
Portal A: 10.20.1.10:3260
Portal B: 10.20.2.10:3260
LUN ID: 20
Назначение: база данных production

Подключение iSCSI Initiator на Linux, Windows и гипервизоре

Linux. Для Debian и Ubuntu обычно используют пакеты open-iscsi и multipath-tools. Установите компоненты из репозитория вашей ОС, укажите IQN initiator, выполните discovery каждого портала и включите автоподключение после перезагрузки.

sudo apt install open-iscsi multipath-tools
sudo systemctl enable --now iscsid open-iscsi multipathd
sudo iscsiadm -m discovery -t sendtargets -p 10.20.1.10
sudo iscsiadm -m discovery -t sendtargets -p 10.20.2.10
sudo iscsiadm -m node --login
sudo iscsiadm -m session

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

Windows Server. Включите службу Microsoft iSCSI Initiator, укажите IQN initiator, добавьте оба Discovery Portal и выполните login для каждого пути. Включите компонент MPIO и добавьте поддерживаемый Device Hardware ID после проверки рекомендаций производителя. Подробный порядок для Windows Server и Windows 11 приведен в руководстве по iSCSI Initiator, CHAP и MPIO.

Гипервизор. Добавьте штатный software iSCSI adapter или поддерживаемый storage adapter, укажите отдельные VMkernel или storage-интерфейсы, выполните binding путей и добавьте оба портала. После discovery назначьте политику path selection согласно профилю массива. Для VMware, Hyper-V и Proxmox полезно сверить порядок действий с практическим руководством по внешним хранилищам для виртуальных серверов.

Первичная проверка iSCSI-подключения

1. Проверьте login к каждому target-порталу и число активных sessions.
2. Сравните IQN initiator с записью на массиве.
3. Убедитесь, что ОС видит один и тот же LUN через одинаковый WWID или serial.
4. Проверьте, что отдельные SCSI-пути еще не используются как самостоятельные диски.
5. Убедитесь, что MPIO создал один multipath device с ожидаемым количеством путей.
6. Проверьте журналы ОС, ошибки NIC, counters коммутаторов и события массива.
7. Отключите один путь в контролируемом окне и подтвердите продолжение I/O.

Настройка Fibre Channel: fabric, zoning и LUN masking

FC-подключение строится в последовательности HBA и оптика, fabric A и fabric B, zoning, регистрация хоста на массиве, LUN masking, обнаружение на ОС и MPIO. Zoning ограничивает видимость портов в fabric. LUN masking решает, какие блочные устройства конкретный хост получает от массива. Эти механизмы не заменяют друг друга.

Подготовка HBA, портов массива и двух FC fabric

1. Проверьте модель HBA, поддерживаемую скорость, firmware и драйвер.
2. Сверьте тип и длину SFP, оптические модули и патч-корды.
3. Соберите WWPN каждого HBA-порта хоста и каждого target-порта массива.
4. Подключите HBA-1 к FC fabric A, HBA-2 к FC fabric B.
5. Подключите target-порты контроллеров к обеим fabric, сохраняя распределение портов.
6. Проверьте состояние линков, скорость, ошибки CRC, loss of signal и registered fabric login.
7. Зафиксируйте физическую схему и имена портов до создания зон.

Host-01 HBA-A WWPN 10:00:00:aa:bb:cc:dd:01 -> Fabric-A
Host-01 HBA-B WWPN 10:00:00:aa:bb:cc:dd:02 -> Fabric-B
Array CTL-A port-1 WWPN 50:00:00:aa:bb:cc:01 -> Fabric-A
Array CTL-B port-1 WWPN 50:00:00:aa:bb:cc:02 -> Fabric-B

WWPN копируйте из нескольких независимых мест: интерфейса HBA, ОС, FC-коммутатора и массива. Ошибка в одном символе создает ситуацию, когда зона формально существует, но нужный порт остается невидимым.

Zoning: схема one initiator - one target

Для каждой зоны свяжите один WWPN инициатора с одним WWPN target-порта массива. Такая схема сокращает область видимости, упрощает диагностику и уменьшает последствия ошибки в конфигурации.

Soft zoning ограничивает видимость через базы имен и логические правила fabric. Hard zoning дополнительно фильтрует доступ на уровне аппаратной логики портов, если это поддерживает конкретный коммутатор. Термины и механика отличаются у производителей, поэтому проверяйте документацию выбранной платформы.

Не используйте zone с широким набором всех initiator и всех target без необходимости. Она усложняет поиск лишней видимости и повышает вероятность ошибочного доступа к LUN.

LUN masking и host group на массиве

1. Создайте объект хоста на массиве и добавьте WWPN обоих HBA.
2. Убедитесь, что WWPN относятся к одному серверу и не повторяются у другого хоста.
3. Создайте host group только для серверов, которые действительно работают как один кластер.
4. Назначьте хосту или host group нужные LUN и согласованные LUN ID.
5. Проверьте режим active-active, active-passive или ALUA для этой группы.
6. Сверьте список назначений с таблицей проекта и зафиксируйте владельца каждого LUN.

Минимально необходимый доступ снижает риск, при котором сервер получает чужой том. Обычный LUN базы данных не назначают нескольким независимым хостам ради удобства. Для общего доступа нужен кластерный менеджер и файловая система, которая поддерживает одновременную работу узлов.

Проверка видимости LUN через Fibre Channel

1. Проверьте login HBA в fabric A и fabric B.
2. Сверьте состояние зон и активную конфигурацию коммутаторов.
3. Убедитесь, что ОС обнаружила ожидаемые target-порты.
4. Выполните rescan устройств поддерживаемым способом для выбранной ОС.
5. Сравните WWID, serial и размер LUN по всем найденным путям.
6. Проверьте количество путей и отсутствие незапланированных LUN.
7. Передайте устройство в MPIO, а не размечайте каждый путь отдельно.

cat /sys/class/fc_host/host*/port_name
cat /sys/class/fc_host/host*/port_state
lsscsi
multipath -ll

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

LUN, masking и подготовка дисков на хосте

LUN проходит несколько уровней: его создают на массиве, назначают хосту через masking, обнаруживают в ОС, объединяют пути MPIO, затем передают файловой системе, LVM, datastore или кластерному слою. Ошибка на одном уровне может сделать данные недоступными или привести к повреждению метаданных.

Как выбирать размер и назначение LUN

Разделяйте LUN по типу нагрузки, критичности, владельцу, политике резервного копирования и требованиям к latency. Для базы данных часто выделяют отдельные тома под data, log и временные файлы. Для виртуализации группируют datastore по классу нагрузки и правилам защиты.

Оставляйте запас под рост и snapshots по правилам конкретного массива. Чрезмерное дробление увеличивает число объектов, правил masking и графиков мониторинга. Слишком крупный общий LUN затрудняет перенос, восстановление и локализацию нагрузки.

Разметка, файловая система и использование в виртуализации

Одиночный сервер обычно использует GPT и файловую систему поверх multipath device. LVM добавляют, когда требуется гибко расширять логические тома. Гипервизор получает LUN как datastore или другой штатный тип хранилища. Несколько узлов получают общий LUN только через кластерный менеджер или кластерную файловую систему.

1. Сначала убедитесь, что MPIO показывает один логический диск и все пути.
2. На одиночном Linux-сервере создайте GPT на multipath device, затем нужный слой LVM и файловую систему.
3. На Windows инициализируйте диск один раз после подтверждения MPIO и используйте постоянный идентификатор тома.
4. На гипервизоре создайте datastore штатным инструментом и проверьте path policy.
5. Для кластера применяйте только поддерживаемую файловую систему и менеджер блокировок.
6. Внесите точку монтирования, datastore или имя кластера в таблицу LUN.

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

Идентификаторы устройств и защита от смены путей

Имена вида /dev/sdX могут измениться после перезагрузки, добавления HBA или изменения порядка обнаружения. Для монтирования и автоматизации используйте WWID, UUID, serial и multipath device. Зафиксируйте связь между именем LUN на массиве, WWID, назначением и точкой монтирования.

ls -l /dev/disk/by-id/
udevadm info --query=all --name=/dev/mapper/mpathX
multipath -ll

В Windows проверяйте уникальные свойства диска через Disk Management или PowerShell, в гипервизоре используйте постоянный идентификатор устройства и имя datastore. Не меняйте имя multipath device вручную после подключения приложения.

Multipath I/O: настройка отказоустойчивости и балансировки путей

Multipath I/O объединяет несколько физических соединений с одним LUN в одно логическое устройство. При отказе кабеля, порта, коммутатора или контроллера MPIO убирает недоступный путь и продолжает передачу по рабочим. При доступной балансировке он распределяет I/O согласно политике массива.

Практические сценарии настройки multipathing для iSCSI и FC с примерами проверок собраны в отдельном руководстве по маршрутизации данных в SAN.

Режимы active-active, active-passive и ALUA

ALUA сообщает хосту, какие пути оптимальны для конкретного LUN. Если policy игнорирует этот статус, I/O может идти через межконтроллерный канал и создавать лишнюю latency. Round-robin, failover-only и vendor-specific policy выбирают по документации массива, а не по привычке инженера.

Настройка MPIO на Linux, Windows и гипервизорах

Linux. Установите multipath-tools, включите daemon, определите WWID и проверьте, что в карте присутствуют все пути. Конфигурация ниже показывает общий принцип, но vendor и product нужно заполнить по support matrix.

defaults {
    find_multipaths yes
    user_friendly_names no
}

defaults device {
    vendor  "VENDOR"
    product "PRODUCT"
    path_grouping_policy group_by_prio
    path_selector "service-time 0"
    prio alua
    path_checker tur
    no_path_retry queue
}

Параметры path_selector, prio, path_checker и no_path_retry нельзя переносить между массивами без проверки. Сначала сохраните исходный файл, примените поддерживаемый профиль и проверьте вывод multipath -ll.

Windows. Добавьте компонент MPIO, выполните автоматическое или ручное claim-правило для поддерживаемого Device Hardware ID и проверьте число путей в MPIO Properties. Не задавайте таймауты и режимы восстановления без рекомендаций поставщика массива.

Гипервизор. Используйте штатную path selection policy, сверьте ALUA и убедитесь, что все datastore видны через ожидаемое количество путей. Виртуальная машина должна продолжать I/O при отключении одного пути, но тест выполняют до массового запуска VM.

Тест failover и возврата пути в работу

1. Зафиксируйте состояние LUN, число путей, latency и ошибки до начала теста.
2. Запустите безопасную нагрузку, например тест чтения и записи на непроизводительном томе или контролируемую операцию приложения.
3. Отключите один кабель или порт на пути A.
4. Проверьте продолжение I/O, события ОС, состояние MPIO и latency.
5. Верните путь A и убедитесь, что он снова вошел в рабочую группу.
6. Повторите проверку для пути B, второго коммутатора и доступного контроллера.
7. Сравните время переключения с требованиями SLA и сохраните отчет.

Не работайте с отдельными SCSI-путями после объединения в multipath device. Форматирование, монтирование и операции приложения выполняются через общий логический диск.

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

Мониторинг производительности SAN должен охватывать всю цепочку: приложение, ОС, виртуализацию, MPIO, NIC или HBA, Ethernet или FC-коммутаторы, контроллеры массива, storage pool и диски. Одна latency на хосте не показывает причину сбоя. Сопоставляйте показатели по одному временному интервалу и учитывайте профиль нагрузки.

Какие показатели собирать на хосте и массиве

Queue depth измеряйте на хосте, HBA или NIC, контроллере и backend-пуле, если такие counters доступны. Сопоставляйте его с размером I/O и числом параллельных процессов. Высокая очередь при низкой загрузке дисков может указывать на ограничение пути или контроллера.

Как задать рабочие пороги и оповещения

Сначала соберите базовую линию для каждой критичной нагрузки. База должна включать обычные часы, резервное копирование и пиковые операции. Порог связывайте с SLA приложения и типом носителей, поэтому универсальное значение latency для всех SAN использовать нельзя.

• Создайте предупреждение, если p99 latency держится выше обычного уровня в 1,5-2 раза, например 10 минут.
• Поднимайте критичный алерт при потере всех путей к LUN, а не только при переходе одного path в down.
• Оповещайте о повторяющихся reset, CRC, retransmit и login errors.
• Контролируйте queue depth вместе с latency, иначе высокая очередь может выглядеть как нормальная загрузка.
• Задайте отдельные пороги для свободной емкости пула, snapshots и скорости заполнения.
• Отслеживайте перегрузку контроллера, рост backend latency и неравномерное распределение I/O.

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

Что включить в дашборд SAN

• Таблицу хостов с количеством LUN, WWID или IQN, числом paths и состоянием MPIO.
• Графики IOPS, throughput, average latency, p95 и p99 по каждому критичному LUN.
• Загрузку портов массива, NIC, HBA, Ethernet-коммутаторов и FC fabric.
• Queue depth и ошибки транспорта с разбивкой по хосту, порту и времени.
• Latency контроллеров, состояние cache, backend-пула и дисков.
• Свободную емкость, скорость роста, snapshots, репликацию и резервное копирование.
• Активные события fabric, path failover и изменения конфигурации.

Главный экран должен отвечать на четыре вопроса: какой сервис затронут, какой LUN используется, где появился рост задержки и сколько независимых путей осталось. Избыточные графики без привязки к владельцу и SLA замедляют реакцию.

Диагностика SAN: высокая latency, переполнение очереди и потеря путей

Начинайте диагностику с фиксации времени, хостов и LUN. Не перезапускайте сервис и не переключайте контроллер до сбора журналов, counters и состояния MPIO, если ситуация не угрожает данным. Причина может находиться в приложении, ОС, пути передачи, контроллере или backend-пуле.

Высокая latency: как локализовать узкое место

1. Определите конкретные хосты, LUN, приложения и временной интервал.
2. Сравните latency на хосте, в MPIO, на порту массива и в backend-пуле.
3. Проверьте IOPS, throughput, read/write ratio и размер блока.
4. Проверьте queue depth и число параллельных VM, процессов или потоков.
5. Для iSCSI проверьте retransmits, drops, MTU, ошибки NIC и загрузку uplink.
6. Для FC проверьте fabric login, CRC, loss of signal, SFP и активные события zoning.
7. Проверьте CPU steal, I/O wait и memory pressure на хосте виртуализации.
8. На массиве проверьте cache, controller utilization, backend latency, диски и свободное место.
9. Сопоставьте момент роста latency с backup, snapshot, replication или другим изменением.

Если latency выросла на хосте и контроллере одновременно, ищите нагрузку в массиве или пуле. Если на массиве задержка обычная, а на хосте высокая, проверяйте MPIO, HBA, NIC, коммутаторы, драйвер и виртуализацию.

Переполнение очереди команд и неверный queue depth

Queue depth показывает число операций, ожидающих обработки на пути или устройстве. Большая очередь не гарантирует высокую производительность. Когда контроллер или диски не успевают обслуживать запросы, рост параллельности увеличивает p99 latency, таймауты и повторные операции.

Меняйте queue depth по одному параметру, фиксируйте исходное значение и проверяйте результат на одинаковом профиле нагрузки. Сверяйтесь с рекомендациями производителя массива, HBA, ОС и гипервизора. Не копируйте значение из другой модели массива.

Потеря пути, деградация MPIO и ошибки транспорта

1. Проверьте state каждого path в MPIO и время перехода в down.
2. Изучите логи ОС, iSCSI, FC-драйвера и multipath daemon.
3. Проверьте линк NIC или HBA, counters порта, кабель и SFP.
4. Для iSCSI проверьте login к target, ACL, MTU, drops и retransmits.
5. Для FC проверьте fabric login, активную конфигурацию zoning и ошибки оптики.
6. Проверьте состояние target-порта и контроллера массива.
7. После восстановления транспорта дождитесь возврата path и проверьте multipath map.
8. Только после подтверждения путей проверяйте приложение и его журналы.

Не удаляйте multipath device, не выполняйте повторное форматирование и не создавайте новый раздел при временной потере пути. Такие действия могут превратить транспортную проблему в повреждение данных.

Какие данные приложить к обращению в поддержку

• Временной интервал инцидента с указанием часового пояса.
• Затронутые хосты, приложения, LUN, WWID, IQN или WWPN.
• Графики latency, p95, p99, IOPS, throughput и queue depth до и во время сбоя.
• Состояние MPIO и полный список paths.
• Журналы ОС, multipath, iSCSI или FC-драйвера, коммутаторов и массива.
• Ошибки NIC, HBA, SFP, портов и fabric.
• Версии firmware, драйверов, ОС, гипервизора и массива.
• Изменения перед инцидентом: firmware, zoning, masking, snapshots, backup, migration.
• Список уже выполненных проверок, время действий и их результат.

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

Масштабирование и миграция SAN в 2026 году

Расширение SAN начинают с инвентаризации зависимостей, свободных портов, емкости, IOPS и лицензий. Миграция требует отдельного плана: способ переноса, консистентность, допустимый простой, возможность отката и проверка после переключения. Online migration и репликация зависят от массива, приложения и гипервизора.

Выбор метода миграции LUN

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

Проверки перед переключением и после него

До переключения выполните следующие проверки:

• резервная копия открывается, а тест восстановления завершен;
• целевой LUN имеет нужную емкость, производительность и запас;
• все paths видны, MPIO использует корректную policy и ALUA;
• блоковый размер, файловая система, datastore и кластерный слой поддерживаются;
• приложение остановлено или переведено в согласованный режим;
• записаны контрольные суммы или другой способ сверки данных;
• готовы команды возврата на прежний LUN.

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

Эксплуатационная документация SAN

Храните документацию в системе, доступной дежурной команде. Минимальный комплект включает:

• физическую схему хостов, HBA, NIC, коммутаторов, fabric и контроллеров;
• логическую схему VLAN, подсетей, порталов, WWPN, IQN и LUN;
• таблицу zoning, aliases, активных конфигураций и даты изменений;
• mapping и masking LUN, host groups, LUN ID и владельцев;
• WWID устройств, точки монтирования, datastore и кластерные зависимости;
• настройки MPIO, ALUA, path policy и версии драйверов;
• версии firmware, поддерживаемые сочетания компонентов и окна обновлений;
• политику резервного копирования, RPO/RTO и результаты тестов восстановления;
• результаты failover-тестов, критерии остановки и контакты для эскалации.

При добавлении хоста или LUN обновляйте схему, таблицу доступа, мониторинг и план резервного копирования одной заявкой. После каждого изменения повторяйте проверку видимости, MPIO и отказа одного пути. Такой порядок сохраняет предсказуемость SAN при росте числа серверов, томов и приложений.