LUN в СХД: что это такое и как работает логический диск
У вас есть мощное хранилище на 50 терабайт. Как раздать его 20 серверам так, чтобы каждый видел только свой кусок, при этом никто не лез в чужие данные, а вы могли управлять всем из одной точки? Вот тут и появляется LUN — логический номер, который превращает физическое железо в гибкую систему виртуальных дисков.
LUN (Logical Unit Number) — это не сам диск и даже не том. Это скорее адрес или метка, которая указывает серверу на конкретный логический блок внутри системы хранения данных. Представьте многоквартирный дом: СХД — это здание, а LUN — номер квартиры, который позволяет почтальону (в нашем случае серверу) доставить данные точно по адресу.
LUN появился как часть протокола SCSI, где служил «подадресом» устройства по схеме Bus (шина) → Target (устройство) → LUN (логическая единица). Отработанная концепция прижилась настолько хорошо, что сегодня поддерживается в Fibre Channel, iSCSI и даже в современном NVMe-oF. По сути, это универсальный язык корпоративных хранилищ.
Как LUN устроен изнутри
Когда вы подключаете сервер к СХД через Fibre Channel или iSCSI, система хранения не показывает ему все свои физические диски сразу. Вместо этого администратор создает логические единицы — куски пространства с определенными параметрами. Каждому такому куску присваивается номер: LUN 0, LUN 1, LUN 2 и так далее.
Сервер при этом видит обычный блочный диск — /dev/sdb или E:, ничем не отличающийся от локального. Он не знает, что за этим номером может скрываться RAID-массив из десяти SSD, распределенный пул с автоматическим переносом данных между уровнями или даже реплицированное хранилище на двух площадках.
Вот в чем фишка: LUN позволяет абстрагировать физику. СХД может маппировать несколько физических дисков в один логический диск, а сервер видит всего одно устройство. При этом внутри системы хранения происходит магия — RAID-контроллеры, кэширование, дедупликация, сжатие. Но для операционной системы это прозрачно.
LUN и управление производительностью
Один из главных козырей LUN — гибкость в настройке. Допустим, у вас есть RAID-10 из быстрых NVMe-дисков. Вы можете выделить оттуда LUN 1 под базу данных с агрессивным кэшированием записи, LUN 2 — под файловое хранилище с приоритетом на чтение, а LUN 3 — вообще с отключенным кэшем для критичных транзакций.
Более того, в современных СХД LUN может быть не просто статичным разделом, а распределенным пулом, который объединяет SSD и HDD. Политика Tiering (многоуровневого хранения) работает на уровне LUN: горячие данные автоматически мигрируют на быстрые диски, холодные — на медленные и дешевые. Сервер при этом ничего не замечает — для него это все тот же диск с одним LUN ID.
Благодаря такому подходу можно делить RAID-массив на независимые фрагменты с разным кэшированием, производительностью и политиками доступа. Одно хранилище обслуживает и высоконагруженную СУБД, и архив логов, и тестовую среду — каждому по потребностям.
Mapping, zoning и контроль доступа
Создать LUN — это полдела. Нужно еще настроить, кто и как сможет к нему обращаться. В SAN-среде это делается двумя способами:
Zoning — разграничение на уровне коммутатора Fibre Channel. Вы группируете порты (например, порт сервера A и порт массива) в одну зону. Сервер B в эту зону не попадает и физически не видит этот LUN, даже если очень захочет.
Mapping (или LUN masking) — привязка на уровне самой СХД. Вы указываете, какой именно сервер (по WWN или IQN) может обращаться к конкретному LUN. Это второй уровень защиты: даже если zoning настроен неправильно, массив не даст чужому серверу доступ.
В iSCSI-средах работает похожая логика, только вместо WWN используются IQN (уникальные имена инициаторов). Настраиваете ACL (Access Control List) на таргете, прописываете там IQN нужного сервера — и готово. Другие серверы этот LUN просто не увидят при сканировании.
LUN, Volume и Disk Group: в чем разница
Тут часто возникает путаница, потому что разные вендоры называют вещи по-разному. Попробуем разобраться:
Disk Group (или Storage Pool) — это набор физических дисков, объединенных в RAID. Например, 8 дисков в RAID-6.
Volume — логический том, вырезанный из этой группы. Внутри одного Disk Group может быть несколько Volume. По сути, Volume и LUN — это часто одно и то же, просто разная терминология.
LUN — номер, который присваивается Volume при маппинге на сервер. Иногда Volume существует сам по себе, но пока ему не присвоен LUN ID и не настроен mapping, сервер его не увидит.
В некоторых СХД (например, Dell EMC) различие более явное: сначала создаете Storage Pool, потом LUN, потом маппите его на Host Group. В других системах (NetApp, например) работают с Volume, а LUN — это уже следующий уровень абстракции для блочного доступа через iSCSI или FC.
Запутались? Нормально. Главное помнить: LUN — это то, что видит сервер. Всё остальное — внутренняя кухня хранилища.
Практические сценарии использования
Как LUN применяются в реальной работе? Вот несколько типичных кейсов:
База данных — выделяете отдельный LUN с максимальной производительностью, RAID-10, агрессивным кэшем и приоритетом в QoS. БД получает стабильную низкую задержку и высокий IOPS.
Гипервизор — создаете несколько LUN под datastore VMware или Hyper-V Cluster Shared Volume. Виртуализация хранения и контейнеризация (тот же Kubernetes Persistent Volumes) часто опираются на LUN как базовую единицу блочного доступа.
Тестовая среда — быстро клонируете LUN продакшна через snapshot, маппите на тестовый сервер. Разработчики ломают что хотят, продакшн не страдает.
Изоляция отделов — маркетинг видит свой LUN 5, бухгалтерия — LUN 7, разработка — LUN 3. Никто не лезет в чужие данные, а вы управляете всем из одной консоли.
Multipath I/O — настраиваете два пути до LUN (через разные контроллеры или сетевые интерфейсы). Если один канал падает, трафик автоматически переключается на второй. Отказоустойчивость и балансировка нагрузки в одном флаконе.
Оптимизация и безопасность
LUN дает не только гибкость, но и контроль. Вы можете настроить QoS (Quality of Service) на уровне отдельного LUN: ограничить IOPS для бэкапов, чтобы они не душили продакшн, или наоборот, зарезервировать полосу для критичных систем.
Изоляция LUN работает и на уровне безопасности. Даже если злоумышленник получит доступ к одному серверу, он не сможет добраться до данных другого LUN без правильных учетных записей и маппинга. В корпоративных СХД можно включить шифрование на уровне LUN, настроить аудит всех операций доступа и даже интегрировать с Active Directory для централизованного управления правами.
Еще момент — performance tuning. Некоторые СХД позволяют настраивать размер блока (block size) для каждого LUN отдельно. Под БД обычно ставят 8KB или 16KB, под файловые системы — 64KB или больше. Неправильно подобранный размер блока может убить производительность на 30-40%, даже если железо мощное.
Автоматизация и provisioning
В крупных компаниях создание LUN вручную через GUI — это прошлый век. Современные СХД предлагают REST API, через которые можно автоматизировать весь процесс: создать LUN, настроить mapping, добавить в zoning, примапить на сервер. Всё это за минуту через Ansible, Terraform или Python-скрипт.
Динамическое создание LUN особенно актуально в DevOps-окружении: разработчик заказывает ресурсы через портал, система автоматически выделяет нужный объем, создает LUN, маппит на виртуалку — и через пару минут диск готов к работе. Никаких заявок, согласований и ожидания админа.
Подводные камни и типичные ошибки
Конфликт LUN ID — если вы случайно назначите один и тот же ID двум разным LUN на одном сервере, получите красивую панику в логах. Операционка просто не поймет, что происходит.
Забыли про zoning — создали LUN, примаппили на сервер, но забыли добавить порт сервера в FC-зону. Результат: сервер ничего не видит, а вы полчаса ищете проблему не там.
Проблемы с кэшем — включили write-back cache на LUN, а у СХД нет батарейки или UPS. При отключении питания потеряете данные в кэше. Либо используйте write-through, либо обеспечьте защиту питания.
Переполнение LUN — некоторые системы поддерживают thin provisioning (выделение места по мере необходимости). Если забыть следить за реальным заполнением пула, можно получить ситуацию, когда LUN думает, что у него есть 5TB, а физически свободно 100GB. Приложение пытается записать данные — бац, и всё падает.
Multipath без настройки — подключили два пути до LUN, но не настроили MPIO в Windows или multipath-tools в Linux. Система видит два разных диска вместо одного с двумя путями. Записываете данные на один, читаете с другого — привет, рассинхронизация.
LUN в виртуализированных средах
VMware, Hyper-V и Proxmox активно используют LUN для организации хранилищ. В VMware это называется VMFS datastore — по сути, LUN, отформатированный в специальную ФС для виртуалок. Преимущество: можно создать огромный LUN на несколько терабайт и размещать там десятки виртуальных машин.
В Hyper-V используют CSV (Cluster Shared Volume) — это тоже LUN, но с дополнительной логикой для кластерного доступа. Несколько нод одновременно могут работать с одним хранилищем без блокировок.
Kubernetes тоже умеет работать с LUN через CSI-драйверы (Container Storage Interface). Под каждый Persistent Volume можно выделить отдельный LUN, который автоматически маппится на ноду при запуске пода. Контейнер получает блочное хранилище, ничего не зная о том, что внутри там корпоративная СХД с RAID и репликацией.
Что дальше?
Технология LUN существует уже несколько десятилетий и никуда не денется. Да, появляются новые подходы — объектное хранилище, распределенные файловые системы, NVMe-oF с namespace вместо LUN. Но для задач, где нужен блочный доступ, низкая задержка и полный контроль, LUN остается золотым стандартом.
В современных дата-центрах LUN работает как клей между физическим железом и виртуальными окружениями. Это простой, понятный и предсказуемый способ раздать хранилище серверам, не теряя контроля и гибкости. Настроили правильно один раз — и забыли. Настроили неправильно — будете разбираться, почему продакшн тормозит.
