Block Storage и производительность

Краткое резюме

Блочное хранилище дает сырые устройства (LUN/том), поверх которых вы строите ФС, LVM/ZFS и т. д. Производительность определяется: типом носителя, протоколом доступа, очередями и глубиной, размером блока, схемой кодирования (RAID/EC), кэшами и барьерами, сетевой фабрикой, а также паттерном I/O конкретного приложения (рандом/последовательный, чтение/запись, sync/async). Цель — обеспечить нужные p95/p99 задержки и IOPS/пропускную с устойчивостью и предсказуемостью.

Таксономия блочного доступа

Локальный: NVMe (PCIe), SAS/SATA SSD/HDD. Минимальная латентность, отсутствие сетевых узких мест.

Сетевой:

iSCSI (Ethernet, LUN, MPIO, ALUA).
Fibre Channel (FC) (16–64G, низкие задержки, зоннинг).
NVMe-oF: NVMe/TCP, NVMe/RoCE, NVMe/FC — «нативный» NVMe по сети, меньше накладных.
HCI/распределенные (Ceph RBD, vSAN): удобная масштабируемость, но латентность выше, критична сеть/кодирование.

Выбор (сигналы):

p99 latency ≤ 1–2 мс, очень высокий IOPS → локальный NVMe/NVMe-oF.
Стабильная «средняя» латентность 2–5 мс, зрелая фабрика → FC или NVMe/FC.
Унификация на Ethernet, проще эксплуатация → iSCSI или NVMe/TCP.

Протоколы и их особенности

iSCSI: универсальность, MPIO/ALUA, чувствителен к настройке TCP (MTU, offload, qdepth).
FC: изоляция, потоки без потерь, зонирование по WWPN, HBA-очереди и кредиты.
NVMe-oF: параллельность через множество Submission/Completion Queues, низкая CPU-нагрузка, TLS возможен для NVMe/TCP (при необходимости).

RAID/EC и носители

RAID10 — минимальная латентность и предсказуемые IOPS; оптимален для БД/кошельков.
RAID5/6 — лучше по емкости, штраф на запись (write penalty), падает IOPS для sync-write.
Erasure Coding в распределенных массивах — выгодно по емкости, но запись «дороже».
NVMe SSD — p99 топовая; SAS SSD — компромисс; HDD — последовательная пропускная, но плохой рандом.

Файловые системы и выравнивание

XFS — отличный выбор под большие файлы/журналы БД; настраиваемый `agcount`, `realtime` для логов.
ext4 — универсален, внимательно к `stride/stripe_width` под RAID.
ZFS — CoW, проверка целостности, снапшоты/реплика, ARC/ZIL/SLOG; для sync-нагрузок — SLOG на NVMe с PLP.
Выравнивание: 1MiB-aligned разделы, корректные `recordsize`/`blocksize` под нагрузку.

Очереди, глубина и размер блока

IOPS растут с Queue Depth, но растет и латентность; цель — QD, дающий нужный IOPS при контроле p95/p99.
Размер блока: мелкие (4–16К) — больше IOPS, хуже пропускная; крупные (128К–1М) — лучше сквозная скорость.
NVMe qpairs: выделяйте по ядрам/NUMA; iSCSI/FC: qdepth HBA/инициаторов, MPIO-политики.
Барьеры и FUA: включенные write-barriers повышают надежность, но увеличивают p99; SLOG/PLP компенсируют.

Multipath и доступность

MPIO/DM-Multipath: агрегация путей, отказоустойчивость.

Политики: `round-robin` (баланс), `queue-length` (умнее), `failover` (актив-пассива).
ALUA: «предпочтительные» пути к активному контроллеру.
Важно: `no_path_retry`, `queue_if_no_path` — аккуратно, чтобы не «заморозить» I/O на долгие минуты.
FC зонирование: «одна инициаторная зона — один таргет» (reduces blast radius).
NVMe-oF: ANA (Asymmetric Namespace Access) — аналог ALUA.

TRIM/Discard и кэширование

TRIM/Discard освобождают блоки SSD (снижает write-amp, стабилизирует латентность). Включайте регулярно (cron) или онлайн-discard там, где допустимо.
Read-ahead полезен для последовательных чтений; вреден при рандоме.
Write-back кэши контроллера — только с BBU/PLP; иначе риск потери данных.

Сетевой стек (для iSCSI/NVMe-TCP)

Отдельные VLAN/VRF для сторадж-фабрики; изоляция от клиентского трафика.
MTU 9000 end-to-end; RSS/RPS и пиннинг IRQ к NUMA.
QoS/priоrity для RoCE (если lossless), ECN/RED для TCP-пиков.
Два независимых фэт-дерева до стораджа (двойные TOR, разные фидеры электропитания).

Тюнинг Linux/хоста (выборка)

bash
Scheduler for NVMe echo none     sudo tee /sys/block/nvme0n1/queue/scheduler echo 1024      sudo tee /sys/block/nvme0n1/queue/nr_requests echo 0        sudo tee /sys/block/nvme0n1/queue/add_random echo 0        sudo tee /sys/block/nvme0n1/queue/iostats

Read-ahead (sequential loads)
blockdev --setra 4096 /dev/nvme0n1

iSCSI: example of aggressive timeouts and retries iscsiadm -m node --op update -n node. session. timeo. replacement_timeout -v 10 iscsiadm -m node --op update -n node. conn[0].timeo. noop_out_interval -v 5 iscsiadm -m node --op update -n node. conn[0].timeo. noop_out_timeout -v 5

Multipath (фрагмент `multipath.conf`):

conf defaults {
find_multipaths yes polling_interval 5 no_path_retry 12
}
devices {
device {
vendor "PURE    DELL    NETAPP    HITACHI"
path_checker tur features "1 queue_if_no_path"
path_grouping_policy group_by_prio prio alua
}
}

Бенчмаркинг и профилирование

fio — минимальный набор профилей:

bash
Random read 4K, queue 32, 4 threads fio --name = randread --filename =/dev/nvme0n1 --direct = 1 --rw = randread\
--bs=4k --iodepth=32 --numjobs=4 --time_based --runtime=60

Random 4K entry (sync), log loads fio --name = randwrite --rw = randwrite --bs = 4k --iodepth = 16 --numjobs = 4\
--fsync=1 --direct=1 --runtime=60

Large block sequential recording (backups/dumps)
fio --name=seqwrite --rw=write --bs=1M --iodepth=64 --numjobs=2 --runtime=60

Советы:

Разделяйте прогрев и замер, фиксируйте температуру/thermal throttling.
Тестируйте на LUN/томе, а не на ФС (если цель — «сырое» железо).
Меряйте p95/p99 latency и 99.9% tail — именно они «убивают» БД.

Мониторинг и SLO

Метрики:

Латентность p50/p95/p99 (read/write), IOPS, throughput, queue-depth, device busy %, merges, discard.
На уровне сети: drops, retransmits, ECN-маркировки, интерфейсные ошибки.
На уровне массива: лаг репликации, rebuild/resilver прогресс, write-amp, wear-level SSD.

SLO (примеры):

LUN БД (OLTP): p99 write ≤ 1.5 мс, p99 read ≤ 1.0 мс, доступность ≥ 99.95%.
Логи/журналы: p95 append ≤ 2.5 мс, пропускная ≥ 400 МБ/с на том.
Бэкапы: seq write ≥ 1 ГБ/с (агрегировано), RTO восстановления ≤ 15 мин.

Алерты:

p99 latency > порога N минут, деградация IOPS при том же QD, рост read-modify-write в RAID5/6, перегрев/thermal throttle SSD, начавшиеся/застрявшие ребилды.

Kubernetes и CSI

PVC/StorageClass: параметры `reclaimPolicy`, `volumeBindingMode=WaitForFirstConsumer` (правильное размещение), `allowVolumeExpansion`.
Вендорные CSI-плагины: снапшоты/клоны, QoS/политики производительности, volume-topology.
AccessModes: RWO для БД/стейта, RWX — осторожно (обычно через файловые/сеть).
Topology/Affinity: pin подов к нодам рядом с стораджем (низкая латентность).
Важное: HPA/VPA не «вылечит» плохой диск; планируйте SLO томов, используйте PodDisruptionBudget для stateful-сетей.

Снапшоты, клоны, Consistency Groups

Crash-consistent снапшоты — быстро, но возможны несогласованности БД.
App-consistent — через скрипты quiesce (fsfreeze, pre/post hooks БД).
Consistency Group (CG) — одновременно для нескольких LUN (транзакционные системы).
Клоны — быстрые dev/test среды без копирования.

Безопасность и комплаенс

iSCSI CHAP/Mutual CHAP, изоляция VLAN/VRF.
NVMe/TCP с TLS — для междатацентровых/многоарендных сценариев.
Шифрование «в покое»: LUKS/dm-crypt, self-encrypting drives (TCG Opal), ключи в KMS.
Аудит: кто маппил LUN, смена зон FC, изменения multipath.

DR и операции

Синхронная реплика (RPO≈0) — повышает латентность, короткие расстояния.
Асинхронная (RPO=N мин) — георасстояния, приемлема для большинства БД с журналами.
Runbooks: потеря пути MPIO, потеря контроллера, rebuild диска, деградация пула, переключение сайта.
Окна обслуживания: «rolling» контроллеров, лимиты ребилда, чтобы не съесть прод.

FinOps (стоимость за производительность)

$/IOPS и $/мс p99 — полезнее «$/ТБ» для OLTP.
Tiering: горячий OLTP — NVMe/RAID10; репорты/архив — HDD/EC.
Резервы и амортизация: планируйте рост на 30–50% IOPS; держите запас под ребилды/скрабы.
Egress/фабрика: отдельный бюджет на сторадж-сеть и обновления HBA/NIC.

Чек-лист внедрения

Выбран протокол (NVMe-oF/FC/iSCSI) и фабрика с изоляцией.
Спроектированы RAID/EC и пулы по типам нагрузок (OLTP/лог/бэкап).
Настроены MPIO/ALUA/ANA и таймауты; проверены failover/restore.
ФС/выравнивание под RAID, включен TRIM/Discard по регламенту.
Тюнинг очередей/qdepth/read-ahead; валидирован fio-профилями (randread/write 4k, seq 1M).
Мониторинг дисков/пути/латентности p95/p99, алерты на ребилды и throttle.
Снапшоты (app-consistent) и CG; тест DR/восстановления.
Шифрование и CHAP/TLS; ключи в KMS; аудит операций.
Kubernetes/CSI параметры, топология и QoS на тома.

Типичные ошибки

Один путь без MPIO → single point of failure.
RAID5/6 под sync-write OLTP → высокий p99 write.
Нет TRIM → рост write-amp и деградация SSD.
QD слишком большой → «красивые» IOPS и ужасный tail для БД.
Онлайн-discard на «горячих» томах с OLTP → скачки латентности.
`queue_if_no_path` без таймаута → «зависшие» сервисы при аварии.
Смешение NVMe и HDD в одном пуле → непредсказуемая латентность.

Специфика для iGaming/финтех

Кошелек/транзакционные БД: NVMe+RAID10, синхронный журнал на отдельном SLOG/NVMe, p99 write ≤ 1.5 мс, CG-снапшоты.
Очереди выплат/антифрод: последовательные логи → большие блоки, высокая пропускная, отдельные LUN под журнал и данные.
Пиковые TPS (турниры/матчи): pre-warm кэшей БД, headroom ≥ 30%, контроль thermal throttle, burn-rate SLO.
Регуляторика: шифрование LUN, лог аудита маппингов, DR-учения, отчетность по RPO/RTO.

Итог

Продуктивное блочное хранилище — это правильный протокол + корректно настроенные очереди и qdepth + адекватный RAID/EC + дисциплина кэшей/барьеров + изолированная фабрика. Закрепите все в runbook-ах, мерьте p95/p99, валидируйте fio-профилями, автоматизируйте снапшоты и DR — и получите предсказуемую латентность и IOPS, необходимых для критичных путей продукта и денежного потока.