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 НВА/ініціаторів, 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/priority для 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, необхідних для критичних шляхів продукту і грошового потоку.