GH GambleHub

Almacenamiento de bloques y rendimiento

Resumen breve

El almacenamiento en bloque proporciona dispositivos crudos (LUN/tom) sobre los que construye FS, LVM/ZFS, etc. El rendimiento se define por: tipo de medio, protocolo de acceso, colas y profundidad, tamaño de bloque, esquema de codificación (RAID/EC), cachés y barreras, fábrica de red, y patrón I/O de una aplicación específica (rand/serial, lectura/escritura, sync/async). El objetivo es proporcionar la latencia p95/p99 deseada y el ancho de banda IOPS/con estabilidad y previsibilidad.

Taxonomía de acceso en bloque

Local: NVMe (PCIe), SAS/SATA SSD/HDD. Latencia mínima, sin cuellos de botella en la red.

Red:
  • iSCSI (Ethernet, LUN, MPIO, ALUA).
  • Canal de fibra (FC) (16-64G, baja latencia, sonda).
  • NVMe-oF: NVMe/TCP, NVMe/RoCE, NVMe/FC es un NVMe «nativo» a través de la red, menos facturas.
  • HCI/Distribuido (Ceph RBD, vSAN): la escalabilidad conveniente, pero la latencia es mayor, la red/codificación es crítica.
Selección (señales):
  • p99 latency ≤ 1-2 ms, IOPS muy alto → NVMe/NVMe-oF local.
  • Latencia «media» estable 2-5 ms, fábrica madura → FC o NVMe/FC.
  • Unificación en Ethernet, es más fácil operar → iSCSI o NVMe/TCP.

Protocolos y sus características

iSCSI: versatilidad, MPIO/ALUA, sensible a la configuración TCP (MTU, offload, qdepth).
FC: aislamiento, flujos sin pérdidas, zonificación por WWPN, colas HBA y préstamos.
NVMe-oF: paralelismo a través de múltiples Submission/Completion Queues, baja carga de CPU, TLS es posible para NVMe/TCP (si es necesario).

RAID/EC y medios

RAID10 - latencia mínima y IOPS predecibles; óptimo para el BD/billeteras.
RAID5/6 - mejor capacidad, penalización de grabación (escritura penalti), IOPS cae para sync-write.
Código Erasure en arreglos distribuidos - rentable en capacidad, pero la escritura es «más cara».
NVMe SSD - p99 top; SAS SSD - Compromiso; HDD es un pase secuencial, pero un rand malo.

Sistemas de archivos y alineación

XFS es una excelente opción para archivos/registros de BD de gran tamaño; personalizable 'agcount', 'realtime' para los registros.
ext4 es universal, atento a 'stride/stripe _ width' bajo RAID.
ZFS - CoW, verificación de integridad, snapshots/réplica, ARC/ZIL/SLOG; para cargas sync - SLOG en NVMe con PLP.
Alineación: particiones 1MiB-aligned correctas 'recordsize '/' blocksize' bajo carga.

Colas, profundidad y tamaño de bloque

Los IOPS crecen con Queue Depth, pero también crece la latencia; el objetivo es un QD que da el IOPS deseado cuando se controla p95/p99.
Tamaño del bloque: pequeño (4-16K) - más IOPS, peor ancho de banda; grandes (128K-1M) - mejor velocidad de extremo a extremo.
NVMe qpairs: resaltar por núcleo/NUMA; iSCSI/FC: qdepth NVA/iniciadores, políticas MPIO.
Barreras y FUA: los write-barriers incluidos aumentan la fiabilidad, pero aumentan la p99; SLOG/PLP compensado.

Multipath y disponibilidad

MPIO/DM-Multipath: agregación de rutas, tolerancia a fallas.

Políticas: 'round-robin' (balance), 'queue-length' (más inteligente), 'failover' (activo-pasivo).
ALUA: rutas «preferidas» al controlador activo.
Importante: 'no _ path _ retry', 'queue _ if _ no _ path' - suavemente para no «congelar» I/O durante largos minutos.
Zonificación FC: «una zona de iniciación - un objetivo» (reduces blast radius).
NVMe-oF: ANA (Asymmetric Namespace Access) — аналог ALUA.

TRIM/Discard y almacenamiento en caché

TRIM/Discard libera unidades SSD (reduce el write-amp, estabiliza la latencia). Encienda regularmente (cron) o un disco en línea donde esté permitido.
Read-ahead es útil para lecturas secuenciales; dañino en el random.
caché de controlador Write-back - sólo con BBU/PLP; de lo contrario, el riesgo de pérdida de datos.

Pila de red (para iSCSI/NVMe-TCP)

VLAN/VRF individuales para storage factory; aislamiento del tráfico del cliente.
MTU 9000 end-to-end; RSS/RPS y pinning IRQ a NUMA.
QoS/priority para RoCE (si está perdido), ECN/RED para picos TCP.
Dos árboles de comida independientes a storage (TOR dobles, alimentadores de alimentación diferentes).

Sintonizar Linux/host (muestreo)

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 (fragmento '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
}
}

Benchmarking y creación de perfiles

fio - conjunto mínimo de perfiles:
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
Consejos:
  • Separe el calentamiento y la medición, fije la temperatura/thermal throttling.
  • Pruebe con LUN/volumen en lugar de FS (si el objetivo es hierro «crudo»).
  • Mida p95/p99 latency y 99. El 9% del tail son los que «matan» a la DB.

Monitoreo y SLO

Métricas:
  • Latencia p50/p95/p99 (read/write), IOPS, throughput, queue-depth, device busy%, merges, discard.
  • A nivel de red: drops, retransmits, etiquetado ECN, errores de interfaz.
  • En el nivel de arreglo de discos: Magic Replication, rebuild/resilver Progress, write-amp, wear-level SSD.
SLO (ejemplos):
  • LUN БД (OLTP): p99 write ≤ 1. 5 ms, p99 read ≤ 1. 0 ms, disponibilidad ≥ 99. 95%.
  • Registros/registros: p95 append ≤ 2. 5 ms, ≥ de 400 MB/s por volumen.
  • Backups: seq write ≥ 1 GB/s (agregado), RTO de recuperación ≤ 15 min.
Alertas:
  • p99 latency> umbral de N minutos, degradación de IOPS con el mismo QD, crecimiento de lectura-modify-write en RAID5/6, sobrecalentamiento/thermal throttle SSD, rebildes incipientes/atascados.

Kubernetes и CSI

PVC/StorageClass: parámetros 'reclaimPolicy', 'volumeBindingMode = WaitForFirstConsumer' (colocación correcta), 'allowVolumeExpansion'.
Complementos CSI vendedores: snapshots/clones, políticas de QoS/performance, volume-topology.
AccessModes: RWO para BD/state, RWX - cuidado (generalmente a través de archivos/red).
Topología/Affinity: pin pods a nodos junto al storage (baja latencia).
Importante: HPA/VPA no «curará» el disco malo; planificar volúmenes SLO, utilizar PodDisruptionBudget para redes stateful.

Snapshots, clones, Consistency Groups

Crash-consistent snapshots - rápido, pero las inconsistencias de la DB son posibles.
App-consistent - a través de los scripts quiesce (fsfreeze, pre/post hooks BD).
Consistency Group (CG) - Simultáneamente para varios LUN (sistemas transaccionales).
Clones - entorno rápido dev/test sin copiar.

Seguridad y cumplimiento

CHAP/CHAP Mutual iSCSI, aislamiento VLAN/VRF.
NVMe/TCP con TLS - para scripts multicéntricos/multicéntricos.
Cifrado «en reposo»: LUKS/dm-crypt, self-encrypting drives (TCG Opal), claves en KMS.
Auditoría: quién es el muppil LUN, cambio de zonas FC, cambios multipath.

DR y operaciones

Réplica sincrónica (RPO≈0): aumenta la latencia, las distancias cortas.
Asincrónico (RPO = N min) es una estación georreferenciada, aceptable para la mayoría de los DAB con revistas.
Runbooks: pérdida de path MPIO, pérdida de controlador, rebuild de disco, degradación de pool, conmutación de sitio.
Ventanas de servicio: controladores «rolling», límites de rebufo para no comer prod.

FinOps (costo por rendimiento)

$/IOPS y $/ms p99 - más útil «$/TB» para OLTP.
Tiering: OLTP caliente - NVMe/RAID10; reportes/archivos - HDD/EC.
Reservas y depreciación: planifique un crecimiento del 30-50% de IOPS; mantenga el suministro bajo rebildes/matorrales.
Egress/Factory: presupuesto separado para storage network y actualizaciones de HBA/NIC.

Lista de comprobación de implementación

  • Protocolo seleccionado (NVMe-oF/FC/iSCSI) y fábrica aislada.
  • Diseñado por RAID/EC y grupos por tipo de carga (OLTP/logs/backup).
  • Configurado MPIO/ALUA/ANA y temporizadores; comprobado failover/restore.
  • FS/alineación bajo RAID, incluye TRIM/Discard según el reglamento.
  • Afinación de colas/qdepth/read-ahead; validado por perfiles fio (randread/write 4k, seq 1M).
  • Monitoreo de discos/ruta/latencia p95/p99, alertas en rebiles y throttle.
  • Snapshots (app-consistent) y CG; prueba de DR/recuperación.
  • Cifrado y CHAP/TLS; claves en KMS; auditoría de las operaciones.
  • Kubernetes/CSI parámetros, topología y QoS por volumen.

Errores típicos

Un camino sin MPIO → punto único de falla.
RAID5/6 bajo sync-write OLTP → alto p99 write.
Sin TRIM → crecimiento de write-amp y degradación de SSD.
QD es demasiado grande → «hermoso» IOPS y terrible tail para la DB.
Discard en línea en volúmenes «calientes» con OLTP → saltos de latencia.
'queue _ if _ no _ path' sin tiempo de espera → servicios 'colgados' en caso de accidente.
La mezcla de NVMe y HDD en el mismo grupo → una latencia impredecible.

Características específicas para iGaming/Fintech

Billetera/transaccional DB: NVMe + RAID10, registro síncrono en un SLOG/NVMe separado, p99 write ≤ 1. 5 ms, snapshots CG.
Colas de pago/antifraude: registros consecutivos → bloques grandes, ancho de banda alto, LUN separados bajo registro y datos.
TPS pico (torneos/partidos): caché pre-warm BD, headroom ≥ 30%, control thermal throttle, burn-rate SLO.
Regulación: cifrado LUN, registro de auditoría de mappings, ejercicios de DR, informes RPO/RTO.

Resultado

El almacenamiento en bloque productivo es el protocolo correcto + colas correctamente configuradas y qdepth + RAID/EC adecuado + disciplina caché/barrera + fábrica aislada. Asegure todo en runbook-ah, mida p95/p99, valide con perfiles fio, automatice los snapshots y DR, y obtenga la latencia predecible y los IOPS necesarios para las rutas críticas del producto y el flujo de efectivo.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.