Блочные системы хранения данных: архитектура, протоколы iSCSI, FC и NVMe-oF, настройка LUN и multipath

Блочная система хранения отдаёт серверу секторы, а не файлы. Хост видит дисковое устройство, сам создаёт на нём файловую систему и полностью отвечает за целостность данных. Доступ к этому устройству идёт по протоколам iSCSI, Fibre Channel, FCoE или NVMe-oF, а логический том, который администратор презентует серверу, называется LUN.

Блочный доступ выбирают там, где нужны высокие IOPS и предсказуемая задержка: PostgreSQL и Oracle, диски виртуальных машин, кластерные файловые системы, RWO-тома в Kubernetes. Типичная задержка FC и iSCSI составляет 150-500 микросекунд, NVMe-oF поверх RDMA укладывается в 100 микросекунд. Файловый доступ по NFS или SMB даёт удобный общий каталог, но добавляет 0,5-2 миллисекунды и снимает с администратора часть контроля. Объектное хранилище с S3-совместимым API занимает свою нишу: бэкапы, логи, архивы.

Самая дорогая ошибка в работе с блочными СХД: считать, что покупка массива решает задачу. Производительность и отказоустойчивость появляются на уровне конфигурации LUN, политики multipath, выравнивания и проверенных тестов на сбой. Ниже разобраны архитектура массивов, протоколы передачи, пошаговая настройка и сценарии, где блоки выигрывают у файлового и объектного доступа.

Что такое блочная система хранения и чем она отличается от файловой и объектной

Блочное устройство адресует данные фиксированными порциями: 512 байт или 4 КиБ. Внутри нет каталогов, прав доступа и метаданных файлов, только линейное пространство секторов. Файловую систему создаёт хост: ext4, XFS, VMFS, NTFS, ZFS. Отсюда две практические особенности. Первая: размер блока ФС, выравнивание и очередь ввода-вывода остаются под вашим контролем. Вторая: один LUN нельзя одновременно смонтировать на чтение и запись с двух серверов обычной ФС, для общего доступа нужна кластерная файловая система - GFS2, OCFS2, VMFS, GPFS.

Терминологическая путаница встречается часто: SAN (Storage Area Network) - это сеть из FC-коммутаторов или выделенного Ethernet-сегмента, а не сама система хранения. Блочная СХД подключается к хостам через SAN, хотя существует и в варианте прямого подключения по SAS или NVMe. NAS относится к другому классу: сервер отдаёт уже готовые файлы по NFS или SMB. Классификация массивов, типов доступа и сетей разобрана в материале СХД в 2026: классификация, архитектура и практический выбор.

Ключевые отличия блочного, файлового и объектного доступа

Разница видна на конкретной задаче. PostgreSQL на блочном LUN сам управляет записью, знает реальный размер сектора и глубину очереди устройства. Тот же PostgreSQL на NFS зависит от реализации блокировок, поведения атрибутного кэша и сетевых задержек: fsync превращается в сетевой обмен, а p99 легко уходит за 5 миллисекунд. NFS удобен для файловых шар, для СУБД это компромисс с измеримой ценой.

Объектный доступ решает другую проблему. Объект записывается целиком, поэтому нет частичного изменения и связанных с ним блокировок. Взамен появляется масштабирование до миллиардов объектов и версионирование. Изменить один байт внутри объекта нельзя: правка означает запись новой версии.

Когда блочный доступ даёт преимущество

Сценарии, где блоки выигрывают:

• СУБД с интенсивными случайными операциями: 50-500 тысяч IOPS на один узел.
• Виртуализация: VMFS или LVM на LUN, десятки и сотни виртуальных машин на одном datastore.
• Кластеры с общей файловой системой: GFS2, OCFS2, Oracle RAC.
• Kubernetes с томами RWO и volumeMode: Block.
• Задачи с жёстким требованием к задержке: биржевые шлюзы, системы реального времени, in-memory базы.

На стенде с NVMe-oF поверх RoCEv2 массив отдаёт больше миллиона IOPS при задержке около 80 микросекунд. NFS-сервер среднего класса на 25 GbE даёт 80-120 тысяч IOPS и задержку порядка миллисекунды. Десятикратная разница по IOPS и по задержке объясняет, почему блоки держат позиции в нагруженных системах.

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

Архитектура блочных СХД: контроллеры, кэш, RAID и отказоустойчивость

Типовая блочная СХД среднего класса включает два контроллера, дисковые полки, интерконнект для зеркалирования кэша, порты FC 32 Гбит/с или Ethernet 25/100 GbE и защиту кэша батареей либо NVRAM. Полки подключаются по SAS 12 Гбит/с или NVMe. Пропускная способность интерконнекта между головами составляет 50-100 Гбит/с, и при active-passive трафик может проходить через него дважды, съедая часть производительности.

Кэш DRAM ускоряет запись: массив подтверждает операцию после попадания в кэш, а на диски данные уходят позже. Такой режим write-back даёт на случайных записях выигрыш в 5-20 раз и требует защиты: при отключении питания содержимое кэша должно сохраниться в NVRAM или успеть на диск за счёт конденсаторов. Кэш зеркалируется между головами, поэтому падение одного контроллера не теряет подтверждённые записи. Для последовательной записи, куда попадают бэкапы и видеопоток, предчтение для конкретного LUN лучше отключить, иначе кэш заполняется данными, которые больше не понадобятся.

RAID влияет на производительность сильнее, чем модель накопителей. Формула для случайной записи: полезные IOPS = (число дисков x IOPS диска) / штраф RAID. Штраф равен 2 для RAID 10, 4 для RAID 5 и 6 для RAID 6. Восемь SAS SSD по 200 тысяч IOPS в RAID 10 дают около 800 тысяч IOPS на записи, в RAID 6 - примерно 266 тысяч. Чтение в RAID 10 масштабируется почти линейно, в RAID 6 добавляет нагрузку на расчёт чётности.

Erasure coding применяют в распределённых системах: схема 8+3 означает восемь блоков данных и три блока чётности, то есть 27% накладных расходов против 100% при репликации в две копии. Восстановление полки из 8-терабайтных дисков занимает 6-12 часов, и всё это время массив работает в деградированном режиме. Группы больше 12 дисков в RAID 6 повышают риск второй потери во время ребилда.

Active-active и active-passive: что важно для multipath

В active-active с симметричным доступом оба контроллера обслуживают один LUN, и хост нагружает их одновременно. В active-passive у каждого LUN есть владелец: вторая голова принимает запросы, но передаёт их первой через интерконнект, добавляя 100-300 микросекунд задержки.

Современные массивы сообщают топологию через ALUA (Asymmetric Logical Unit Access): хост получает группы портов со статусами optimal и non-optimized. Драйвер multipath в Linux с параметром prio alua направляет трафик в optimal-группу и переключается на вторую при сбое. В VMware ту же задачу решают SATP VMW_SATP_ALUA и PSP round robin.

Неверная политика обходится дорого. Round-robin на active-passive массиве без ALUA отправит половину запросов через пассивную голову: задержка вырастет в 2-3 раза, а при смене владельца LUN хосты на 10-60 секунд увидят ошибки ввода-вывода. Файловые системы в такой ситуации нередко переходят в режим только для чтения.

Протоколы блочного доступа: iSCSI, Fibre Channel, FCoE и NVMe-oF

Протокол определяет транспорт, стоимость порта и достижимую задержку. Все четыре варианта передают одни и те же SCSI-команды, различается способ доставки.

iSCSI: настройка и типичные ошибки

iSCSI инкапсулирует SCSI в TCP, работает на обычном Ethernet и не требует HBA. Порядок настройки:

1. На СХД создать target, задать IQN вида iqn.2026-09.ru.company:storage01 и добавить в него LUN.
2. На хосте проверить собственное имя: cat /etc/iscsi/initiatorname.iscsi. Дубликат имени на втором сервере не даст ему подключиться.
3. Найти target командой iscsiadm -m discovery -t sendtargets -p 10.0.20.11:3260.
4. Выполнить вход: iscsiadm -m node -T iqn.2026-09.ru.company:storage01 -p 10.0.20.11:3260 -l.
5. Включить автоматический вход при загрузке, задав node.startup = automatic в /etc/iscsi/iscsid.conf.
6. Настроить CHAP: без аутентификации любой узел в сети с подходящим IQN получит доступ к данным.

Частые ошибки:

• Jumbo frames включены на СХД и хосте, но не на всех коммутаторах. Проверяют сквозным ping с флагом запрета фрагментации и размером 8972 байта, иначе крупные пакеты молча теряются, а ретрансмиссии TCP незаметно забирают половину полосы.
• Один путь до массива. Без multipath порт, коммутатор или кабель становятся единой точкой отказа.
• Сеть хранения в одном VLAN с офисным трафиком. Любой всплеск от бэкапа или обновления ломает предсказуемость задержки.
• Один сеанс на 1 GbE под СУБД. Такой канал даёт 110-115 МБ/с, для 25 GbE потолок составляет 500-600 МБ/с с учётом накладных расходов.

Fibre Channel и FCoE: когда оправданы

Fibre Channel работает в выделенной сети, где потери кадров исключены буферизацией и кредитами. HBA с очередью на 1024 команды и коммутатор 32 Гбит/с дают стабильные 100-300 микросекунд без джиттера. Зонирование делают по WWN, придерживаясь схемы один инициатор - один target: так проще диагностировать проблемы и сложнее случайно открыть доступ.

Цена вопроса: HBA для сервера стоит порядка 800-2000 долларов, коммутатор на 24 порта 32 Гбит/с начинается от 10 тысяч долларов, плюс SFP-модули и обучение команды. FC выбирают там, где нужен Oracle RAC или кластер СУБД на 20-50 узлов и где джиттер задержки важнее стоимости.

FCoE передаёт FC-кадры поверх Ethernet и требует CNA (Converged Network Adapter) вместе с настройками DCB: priority flow control с классом no-drop, ETS и DCBX. Классический Ethernet теряет кадры при переполнении буфера, а FCoE потерь не прощает. Одна несогласованная настройка PFC на коммутаторе приводит к паузам или потере кадров. Сегодня FCoE уступает место NVMe-oF: конвергенцию проще построить на RoCEv2.

NVMe-oF: современный протокол для высоких нагрузок

NVMe-oF выносит нативный NVMe-протокол в сеть. Транспорты: RDMA (RoCEv2, InfiniBand, iWARP), TCP и FC-NVMe. Вместо одной очереди на устройство используется множество очередей и до 64 тысяч команд в каждой, поэтому один namespace держит миллион IOPS при задержке 50-100 микросекунд.

Требования к инфраструктуре: NVMe-накопители в массиве, сетевые карты с RDMA уровня ConnectX-5 и новее, коммутаторы с поддержкой PFC, ECN и алгоритма DCQCN для профиля без потерь. NVMe-oF поверх TCP проще: работает на обычных 100 GbE, но задержка растёт до 150-250 микросекунд. Для балансировки путей вместо ALUA применяют ANA (Asymmetric Namespace Access), а статусы namespace сообщают о предпочтительном пути.

Сценарии: обучение моделей на больших датасетах, in-memory СУБД (SAP HANA, Redis с персистентностью), потоковая аналитика, торговые системы. Если часть конвейера обращается к моделям по внешнему API, а не считает их на локальных GPU, нагрузка на массив ограничивается кэшем датасета. Единый доступ к моделям без VPN и с оплатой в рублях предоставляет агрегатор AiTunnel, и требования к дисковому вводу-выводу в таком конвейере пересчитывают заново.

Настройка LUN: пошаговый чек-лист и типичные ошибки

LUN представляет собой объект с набором параметров, которые влияют на всю цепочку от диска до приложения. Порядок действий:

1. Собрать RAID-группу или пул, выбрав уровень защиты: RAID 10 для записи, RAID 6 для ёмкости.
2. Решить, как выделять ёмкость: thin или thick.
3. Создать LUN с размером кратным полосе RAID и смещением по границе 1 МиБ.
4. Выставить политику кэша и предчтения под профиль нагрузки.
5. Включить LUN masking и привязать том к WWN или IQN нужных хостов.
6. Презентовать LUN хосту и выполнить rescan: iscsiadm -m session --rescan либо скан через /sys/class/scsi_host/hostN/scan.
7. Убедиться, что multipath собрал один том: multipath -ll показывает mpatha с двумя и более путями.
8. Создать файловую систему с правильными параметрами выравнивания.

Ошибки и их последствия:

• Thin provisioning без мониторинга. Пул переполняется, и все LUN пула одновременно получают ошибки ввода-вывода. Алерты на 70% и 85% и запас свободного места 20% обязательны.
• Малый queue depth. На iSCSI-пути в Linux по умолчанию стоит около 32 команд на устройство, для NVMe и современных массивов этот лимит снижает IOPS в разы: значение поднимают до 128-1024 через /sys/block/sdX/queue/nr_requests и параметры массива.
• Нет LUN masking. Любой хост в SAN с доступом к target может смонтировать ваш том.
• Один LUN на два хоста без кластерной ФС. Обе стороны пишут метаданные, и файловая система разрушается за минуты.
• Клонирование LUN вместе с виртуальной машиной без смены идентификаторов. Гостевая ОС видит тот же серийный номер диска, а кластерные сервисы путают узлы.

Thin или thick provisioning: что выбрать

Thin-том занимает место по мере записи данных, поэтому LUN на 10 ТБ физически может съедать 1 ТБ. Это упрощает планирование и экономит накопители, зато превращает пул в общий ресурс, требующий постоянного присмотра. Thick-том резервирует ёмкость сразу: предсказуемо, дороже, зато переполнение пула не застанет врасплох.

Практика: thin для VDI и стендов разработки, где много пустых блоков; thick для СУБД с ростом 10-20% в год. Переподписка выше 2:1 без автоматического расширения пула опасна. Возврат места работает через SCSI UNMAP (в VMware - автоматический UNMAP, в Linux - fstrim), но не все массивы и драйверы возвращают блоки одинаково эффективно. Проверить это можно, сравнив занятое место в пуле до и после fstrim.

Выравнивание и размер блока: почему это важно

Неверное выравнивание заставляет одну логическую запись занимать две полосы RAID, что добавляет операции чтения-изменения-записи. На HDD потеря достигает 30-50% IOPS, на SSD - 10-20%. Современные массивы и ОС по умолчанию выравнивают разделы по 1 МиБ, этого достаточно большинству задач. Проверку выполняют через parted с ключом align-check optimal.

Размер блока ФС подбирают под полосу RAID. Для RAID 6 с восемью дисками и полосой 64 КиБ общая полоса составит 512 КиБ: mkfs.xfs -d su=512k,sw=8 либо mkfs.ext4 -E stride=128,stripe-width=1024. Для PostgreSQL с блоком страниц 8 КиБ требуется, чтобы записи WAL не разрывали полосу чётности: WAL выносят на отдельный LUN.

LUN masking и доступ хостов

Маскирование ограничивает список инициаторов, которым виден том. На FC это привязка к WWPN адаптера, на iSCSI - к IQN. Схема зонирования один инициатор - один target уменьшает домен сбоя: при ошибках сразу видно, какой путь и хост затронуты.

Ошибки маскирования приводят к потере данных чаще, чем отказы накопителей. Типовые случаи: массив открыт всем хостам в зоне, тестовый стенд получил доступ к боевому LUN, клон datastore презентован двум кластерам vSphere. Правило простое: перед презентацией LUN проверяйте список инициаторов, а после клонирования сверяйте WWN и серийные номера. В VMware дополнительный уровень контроля даёт datastore cluster с политиками доступа и Storage I/O Control.

Multipath: настройка, политики и устранение ошибок

Multipath собирает несколько физических путей к одному LUN в единое устройство. Пути должны быть независимыми: две HBA в разных слотах, два коммутатора, по одному порту на каждой голове массива. Такая схема даёт восемь путей, и отказ любого элемента не прерывает ввод-вывод.

В Linux работу выполняет dm-multipath вместе с демоном multipathd. Конфигурация в /etc/multipath.conf для ALUA-массива строится так: в секции defaults задают path_grouping_policy group_by_prio, path_selector "service-time 0", path_checker tur, prio alua, failback immediate и no_path_retry 5. В секции devices для конкретного вендора повторяют prio alua и добавляют rr_min_io_rq 100. При включённых friendly_names том виден как /dev/mapper/mpatha, и файловую систему с LVM настраивают именно на этот путь, а не на /dev/sdX.

В Windows Server путями управляет MPIO с DSM-модулем вендора, в ESXi - Native Multipath Plugin. Логика та же: несколько путей, политика выбора, проверка состояния.

Выбор политики multipath: round-robin, failover, queue-length

• round-robin распределяет запросы по путям по очереди. Подходит для active-active и для ALUA-массивов, где обе группы optimal. Параметр rr_min_io_rq задаёт число запросов до переключения, и слишком маленькое значение на старых массивах вызывает лишние переключения.
• failover держит активным один путь, остальные в резерве. Рабочий вариант для active-passive без ALUA, минус - половина портов и HBA простаивает.
• queue-length балансирует по числу незавершённых запросов в очереди.
• service-time балансирует по времени обслуживания и даёт более ровную задержку, чем round-robin, когда пропускная способность путей различается.
• group_by_prio с prio alua направляет трафик только в optimal-группу и переключается автоматически при сбое.

Ошибка с самыми заметными последствиями: round-robin на массиве, где LUN принадлежит одной голове. Каждый второй запрос уходит через пассивный контроллер, задержка растёт в 2-3 раза, а смена владельца LUN вызывает паузу на 10-60 секунд.

Диагностика ошибок multipath

Базовый набор: multipath -ll показывает состояние путей, dmesg и журнал ядра содержат сообщения о сбоях, iscsiadm -m session -P 3 выводит параметры сеансов, dmsetup ls --tree показывает карту устройств. Состояние путей удобно смотреть командой multipathd show paths format "%w %d %t %i %o".

Типовые проблемы:

• Дублирование путей. Один том виден как sda и sdb, таблица разделов читается с обеих сторон, изменения расходятся. Причина - отсутствие чёрного списка устройств в multipath.conf.
• Путь помечен failed, но трафик не переключился. Проверяйте path_checker: tur подходит большинству массивов, readsector0 требует чтения с диска.
• no_path_retry 0 или слишком короткий таймаут. При кратком пропадании пути ядро возвращает ошибку ввода-вывода, ext4 переводит ФС в режим только для чтения, Oracle или PostgreSQL останавливаются.
• Отсутствие prio alua. Трафик идёт по неоптимальному пути, производительность падает без явных сообщений об ошибках.

Проверка отказоустойчивости делается только в технологическое окно: отключают порт на коммутаторе или на массиве и смотрят, что multipath -ll перестроился за 5-15 секунд, а тест fio с iodepth 32 не выдал ошибок. Нагрузочный прогон запускают так: fio --name=randwrite --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --time_based --runtime=300. Multipath без проверенного failover даёт иллюзию защиты. Пошаговые конфигурации для iSCSI и FC, включая разбор таймаутов и приоритетов путей, собраны в руководстве по маршрутизации данных в SAN и распределённых файловых системах.

Практические сценарии: виртуализация, базы данных и Kubernetes

Блочные СХД в виртуализации: VMware и KVM

В VMware LUN презентуется хостам ESXi, поверх создаётся datastore VMFS-6. Для ALUA-массивов задают правило SATP VMW_SATP_ALUA и PSP round robin, а ограничение round-robin ставят в 1 IOPS для потоковой балансировки. Storage I/O Control включают на datastore с разнородными ВМ: он ограничивает шумных соседей и удерживает задержку в разумных рамках. RDM в режиме physical нужен кластерам MSCS и приложениям, которым требуется прямой доступ к LUN и собственные снапшоты. Автоматический UNMAP возвращает освободившиеся блоки массиву.

В KVM схема другая: LVM поверх multipath-устройства, virtio-scsi с числом очередей по количеству vCPU, cache=none и io=native для дисков СУБД. В lvm.conf настраивают фильтр, чтобы LVM видел только /dev/mapper/mpath*, иначе один том попадает в физические тома несколько раз и группы путаются.

Порядок цифр для планирования: 100 виртуальных машин со средней нагрузкой 50 IOPS дают 5000 IOPS, но одновременная загрузка всех ВМ после обновления хоста создаёт всплеск 30-50 тысяч IOPS. Без Storage I/O Control и без запаса по производительности массива такой всплеск превращается в получасовую деградацию. Как считать IOPS и задержку под конкретный гипервизор, разобрано в материале СХД для виртуализации в 2026 году.

Базы данных на блочных LUN: PostgreSQL и Oracle

Для PostgreSQL берут XFS на отдельном LUN, а WAL выносят на второй LUN: профили нагрузки различаются, WAL пишется последовательно и требует низкой задержки fsync, данные читаются случайно. Параметры выравнивания задают по полосе RAID, а pg_test_fsync помогает выбрать метод синхронизации. Для NVMe поднимают глубину очереди устройства и убеждаются, что на пути нет глобальных ограничений iSCSI.

В Oracle используется ASM поверх multipath-устройств, без файловой системы. Allocation unit 1 МиБ выбирают для OLTP, 4 МиБ для хранилищ и аналитики. Дисковые группы разделяют по назначению: DATA, RECO, FRA, GRID. ASM работает со всеми путями через драйвер multipath операционной системы, поэтому корректная настройка dm-multipath критична: при ошибке пути дисковая группа может перейти в состояние ограниченной доступности, и база остановится.

Общее правило для СУБД: не включайте TRIM на блочных томах с базой без тестов. Сброс заметно нагружает контроллер и на части массивов даёт всплеск задержки на секунды.

Kubernetes и блочные СХД: CSI и RWO

В Kubernetes блочное хранилище подключают через CSI-драйвер: StorageClass описывает массив, accessModes RWO, volumeMode Filesystem или Block. Для томов с топологией обязателен volumeBindingMode: WaitForFirstConsumer, иначе под может оказаться на узле без доступа к SAN. Для баз данных в подах применяют volumeMode Block и raw-устройство: это убирает накладные расходы файловой системы и упрощает выравнивание.

Особенности, о которых узнают на инцидентах:

• RWO не шарится между подами. Для RWX нужна кластерная ФС или NFS/CephFS, а это другой профиль производительности.
• CSI-драйвер iSCSI требует iscsid и multipathd на каждом узле, уникального initiator name и синхронизации имён с маскированием на массиве.
• reclaimPolicy Retain и VolumeSnapshot защищают от удаления тома вместе с PVC и дают снапшоты под бэкап.
• local PV на NVMe даёт задержку 60-100 микросекунд против 250-400 микросекунд у iSCSI 25 GbE, но привязывает под к узлу и требует отдельного планирования ёмкости.

Там, где поднимать собственный SAN смысла нет, управляемый вариант закрывает задачу быстрее: облачная платформа Timeweb Cloud предоставляет блочные тома, управляемый Kubernetes и базы данных, а масштабирование выполняется изменением параметров без пересборки инфраструктуры.

SAN или локальное хранилище: критерии выбора

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

Когда SAN оправдан

Признаки: кластер из трёх и более узлов, vMotion и HA с нулевым простоем, общая кластерная файловая система, централизованные снапшоты и репликация, разделение данных по уровням производительности. Пример: пять хостов VMware с 80 виртуальными машинами, где при отказе железа ВМ должна подняться на другом узле. Без SAN каждый хост держал бы свои диски, и перенос ВМ превратился бы в копирование данных.

Плата за это: два коммутатора, HBA, лицензии, отдельная сеть, обучение администраторов и регламент обновления прошивок. SAN не прощает самодеятельности: несовместимая версия драйвера или прошивки HBA способна уронить доступ ко всем томам сразу.

Когда локальные диски эффективнее

Одиночный сервер с базой, пограничные вычислители, стенды разработки, аналитика на локальных NVMe. Один накопитель PCIe 4.0 отдаёт 1-1,5 млн IOPS при задержке 60-100 микросекунд, что быстрее любого сетевого пути. Стоимость полезного терабайта без коммутаторов и HBA ниже в 2-4 раза. Потоковая реплика на второй сервер защищает от отказа узла дешевле полноценного SAN.

Риски известны: отказ сервера останавливает сервис, централизованных снапшотов нет, масштабирование ограничено слотами. Такой выбор требует явного плана восстановления с проверенным RTO, иначе экономия обернётся простоем. Развёрнутое сравнение протоколов и моделей доступа с расчётами приведено в статье NAS или SAN: выбор сетевого хранилища для инфраструктуры, а матрица выбора между DAS, NAS, SAN и HCI собрана в сравнительном обзоре DAS, NAS, SAN и HCI.

Заключение: как избежать ошибок при внедрении блочных СХД

Рабочая последовательность перед запуском блочного хранилища в продуктив:

1. Сформулировать требования: IOPS, p99 задержка, объём с ростом на три года, RPO и RTO.
2. Проверить совместимость: списки поддерживаемых HBA и драйверов для вашей версии ESXi, ядра Linux и Windows Server, а также совместимость прошивок массива и коммутаторов.
3. Спланировать сеть хранения отдельно: свои VLAN или VSAN, jumbo frames со сквозной проверкой, для RoCE - PFC, ECN и DCQCN.
4. Выбрать протокол по бюджету и требованиям к задержке, оценив компетенции команды.
5. Создать LUN с выравниванием, задать тип выделения, поднять queue depth, настроить masking.
6. Настроить multipath с prio alua и убедиться, что в optimal-группе собраны все пути.
7. Протестировать failover в технологическое окно: отключение пути, отключение головы, прогон fio с iodepth 32.
8. Включить мониторинг: заполнение пула, задержка на порт, число failed paths, длина очереди, алерты на thin-переполнение и рост задержки.
9. Зафиксировать в документации WWN и IQN, схему зонирования, маскирование, версии прошивок и параметры multipath.
10. Проверить восстановление: снапшот, клон LUN, развёртывание из бэкапа. Тест восстановления важнее теста производительности.

Три привычки снимают большинство рисков: менять параметры multipath и LUN при остановленном вводе-выводе, держать свободными 20% ёмкости пула и проверять каждый failover до того, как он случится сам. Конфигурации, записанные и протестированные заранее, экономят часы на инциденте.

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