Ceph: el camino hacia 1 TiB/s

 (ceph.io)
4 puntos por GN⁺ 2024-01-21 | 1 comentarios | Compartir por WhatsApp
  • Clyso realizó pruebas de burn-in antes de convertir un clúster Ceph basado en HDD a una implementación NVMe de 10 PB, y logró 1.0 TiB/s de lectura en un único clúster de 630 OSD
  • El hardware final consistía en 68 Dell PowerEdge R6615 con 10 NVMe por nodo, pero la prueba de máximo rendimiento se hizo con los 63 servidores disponibles y 630 OSD
  • Los cuellos de botella iniciales se resolvieron corrigiendo los c-states de CPU en BIOS, la contención de mapeo IOMMU en el kernel y un problema con las flags de compilación de RocksDB en los paquetes Deb upstream de Ceph para Ubuntu; el tiempo de compaction se redujo unas 3 veces y las escrituras aleatorias de 4 KB mejoraron al doble
  • Los máximos con configuración de replicación 3X fueron 1025 GiB/s en lectura de 4 MB, 270 GiB/s en escritura de 4 MB, 25.5 M IOPS en lectura aleatoria de 4 KB y 4.9 M IOPS en escritura aleatoria de 4 KB; con erasure coding 6+2 se registraron 547 GiB/s en lectura de 4 MB y 387 GiB/s en escritura
  • El riesgo restante es un fenómeno en el que algunas PG entran en estado active+clean+laggy durante escrituras a gran escala, haciendo caer bruscamente el throughput; para obtener mayor throughput con más de 10 NVMe por nodo se necesita una red de 200GbE o superior

Diseño del clúster Ceph NVMe de 10 PB

  • El cliente quería convertir su clúster Ceph existente basado en HDD a una implementación NVMe de 10 PB, sin requisitos específicos para RBD, RGW o CephFS
  • Las condiciones de diseño incluían distribución en 17 racks, 4U de espacio por rack, energía, refrigeración, densidad y preferencia de proveedor
  • Los nuevos nodos debían integrarse al clúster existente sin interrupción del servicio, y la red ya era una configuración Ethernet rápida instalada
  • La propuesta inicial consistía en ubicar 34 nodos 2U de doble socket en 17 racks, pero finalmente se eligió una configuración basada en Dell diseñada por Clyso
    • La cotización final fue aproximadamente 13% más barata que la configuración original
    • La memoria por OSD se redujo, pero seguía alrededor de 12 GiB por OSD, y el throughput de memoria era más rápido
    • Usaba una configuración de un solo socket, más recursos totales de CPU, mayor throughput total de red, procesadores AMD más recientes y RAM DDR5
    • Al usar nodos más pequeños, se redujo a la mitad el impacto de una falla de nodo en la recuperación del clúster

Hardware y configuración base

  • Las especificaciones del sistema eran las siguientes
    • Nodes: 68 × Dell PowerEdge R6615
    • CPU: 1 × AMD EPYC 9454P 48C/96T
    • Memory: 192GiB DDR5
    • Network: 2 × 100GbE Mellanox ConnectX-6
    • NVMe: 10 × Dell 15.36TB Enterprise NVMe Read Intensive AG
    • OS: Ubuntu 20.04.6 Focal
    • Ceph: Quincy v17.2.7 upstream Deb packages
  • El cliente quería limitar el consumo eléctrico adicional por rack a unos 1000~1500 W
    • Se estimó que el TDP total de 4 nodos por rack sería de al menos 1120 W, más energía base, picos de CPU e ineficiencia de las fuentes de alimentación
    • Se consideró que, si era necesario, se podía reducir el cTDP del procesador para ahorrar unos 100 W por rack
  • Los servidores Dell 1U tenían una configuración cercana a la generación más reciente de sistemas usados en el laboratorio de rendimiento upstream de Ceph
    • Durante las pruebas se descubrió un problema de rendimiento que no existía en hardware de generaciones anteriores, pero que sí afectaba a este hardware

Metodología de prueba y elección de benchmarks

  • Las pruebas de burn-in se realizaron desplegando un clúster Ceph temporal con CBT y ejecutando pruebas FIO
  • Se configuró osd_memory_target de 8 GB para los OSD
    • En producción se consideró posible usar un osd_memory_target más alto
  • El cliente no necesitaba pruebas de cargas block o S3, pero se usó el motor librbd de FIO en lugar de RADOS bench
    • En RADOS bench a gran escala es difícil determinar el número de instancias necesarias para saturar el clúster, y en el pasado se había requerido usar varios pools simultáneos
    • Para comparar con resultados existentes del laboratorio upstream, se usaron las mismas pruebas FIO basadas en librbd
    • También se consideró que FIO es una herramienta conocida y confiable
  • Se omitieron las pruebas de kernel RBD
    • El motor librbd evita problemas en los que un mount point antiguo obliga a reiniciar el sistema
    • Este clúster no tenía acceso IPMI, y el plazo para completar las pruebas era ajustado
    • Según pruebas anteriores, se esperaba que el rendimiento total fuera en general similar si había suficientes clientes
  • Los objetivos de prueba incluían replicación 3X y erasure coding 6+2
  • msgr V2 se probó tanto en modo no cifrado como en modo secure
    • ms_client_mode = secure
    • ms_cluster_mode = secure
    • ms_service_mode = secure
    • ms_mon_client_mode = secure
    • ms_mon_cluster_mode = secure
    • ms_mon_service_mode = secure
  • FIO primero llenaba los volúmenes RBD con escrituras grandes, y luego ejecutaba pruebas de IO de 4 MB y 4 KB durante 300 segundos cada una
    • En ejecuciones de depuración se redujo a 60 segundos
    • Se deshabilitaron procesos en segundo plano como scrub, deep scrub, PG autoscaling y PG balancing

Impacto del número de PG en el rendimiento

  • Pruebas anteriores en el laboratorio upstream habían confirmado que el número de PG puede afectar mucho el rendimiento
  • Con pocos PG, la acumulación aleatoria en grupos puede afectar el rendimiento, y parte de esto puede mitigarse con balancing adicional
  • En clústeres rápidos, la contención de locks de PG dentro de los OSD también puede desempeñar un papel importante en el rendimiento total
    • Este problema no es fácil de mitigar salvo aumentando el número de PG
  • Incluso en pruebas que usaban solo 60 OSD, el rendimiento de lectura aleatoria del pool RBD con replicación 3X escaló hasta 16384 PG
    • La escritura alcanzó su pico antes, pero hubo beneficios hasta 2048 PG
  • No se debe aplicar ciegamente un número alto de PG en producción
    • Valores predeterminados de Ceph como la longitud del PG log y los PG stat updates pueden influir
    • Es necesario reconsiderar si la práctica tradicional de 100 PG por OSD sigue siendo válida

Problemas iniciales de rendimiento y comportamientos extraños

  • Se pudo iniciar sesión por primera vez en el nuevo hardware la semana posterior al Thanksgiving en EE. UU., y el plan original era integrarlo al clúster existente tras 1 o 2 semanas de validación de burn-in
  • Las pruebas de rendimiento de bajo nivel al principio parecían buenas
    • Las pruebas de red con iperf se acercaban a 200 Gb/s por nodo
    • El rendimiento base de las unidades NVMe en algunos nodos también parecía razonable
  • El sistema operativo de los 68 nodos había sido desplegado por error en 2 unidades OSD, en lugar de las unidades de arranque internas Dell BOSS m.2
    • En vez de la prueba planeada de 3 nodos y 30 OSD, se terminó probando con solo 8 NVMe por nodo
  • Los primeros resultados de Ceph fueron mucho más bajos de lo esperado, incluso considerando la reducción en cantidad de OSD
    • Solo la lectura aleatoria se acercaba a un nivel apenas aceptable, pero no era suficiente
  • Al acotar a pruebas de un solo nodo y un solo OSD apareció un patrón anómalo
    • Un sistema que funcionaba bien en pruebas de un solo OSD empeoraba tras una prueba con 8 OSD
    • Luego, incluso las pruebas de un solo OSD mantenían mal rendimiento durante varias horas antes de recuperarse
    • Si no se ejecutaban pruebas multi-OSD, el rendimiento se mantenía alto
  • Al ejecutar FIO directamente sobre las unidades, el mismo problema no se reproducía
  • Durante pruebas con 8 OSD, un OSD específico consumía mucha más CPU que los demás
  • El perfil wallclock del OSD mostraba mucho tiempo en io_submit, un patrón que normalmente aparece cuando la cola de la unidad está llena y el kernel se bloquea

Tres correcciones

  • Modo de rendimiento en BIOS y c-states

    • La primera corrección fue que el BIOS no estaba en modo maximum performance, por lo que los c-states de CPU estaban habilitados
    • Ceph es muy sensible a la latencia que producen las transiciones de c-state de CPU
    • Al deshabilitar los c-states con el modo maximum performance, el rendimiento mejoró 10~20%, pero no fue suficiente para alcanzar el objetivo

  • Contención de IOMMU

    • El segundo problema apareció en un perfil perf del lado del kernel
    • Durante ejecuciones malas, se dedicaba mucho tiempo a native_queued_spin_lock_slowpath y a la ruta de IOMMU DMA mapping
    • alloc_iova
    • iommu_dma_alloc_iova
    • iommu_dma_map_sg
    • nvme_map_data
    • nvme_queue_rq
    • Al deshabilitar IOMMU en el kernel, el rendimiento de lectura/escritura de 4 MB en la prueba de 8 nodos mejoró de forma significativa
    • Incluso después de esta corrección, el problema de escritura aleatoria de 4 KB persistía

  • Flags de compilación de RocksDB

    • El tercer problema fue que el rendimiento de escrituras aleatorias de 4 KB y de compaction en RocksDB era inferior a lo esperado
    • En el pasado, síntomas similares en Ceph estuvieron relacionados con dos causas
    • Compilación sin soporte de TCMalloc
    • Compilación sin las flags de cmake adecuadas ni optimización del compilador
    • Los paquetes upstream de Ceph para Ubuntu sí incluían TCMalloc
    • En los logs de compilación del paquete Ubuntu 17.2.7 se confirmó que RocksDB no se había compilado con las flags correctas
    • Canonical y Gentoo ya habían corregido este problema en sus propias compilaciones
    • Los usuarios de Debian/Ubuntu cephadm que usan el contenedor upstream no parecían estar afectados
    • Al compilar paquetes 17.2.7 custom corregidos, el tiempo de compaction se redujo unas 3 veces y el rendimiento de escritura aleatoria de 4 KB se duplicó

Pruebas de escalamiento en la primera semana de 2024

  • El 2 de enero, las pruebas de rendimiento se retrasaron por la respuesta a una falla a gran escala en otro clúster relacionado
  • Desde el viernes se volvió a configurar CBT y las pruebas, y esta vez se pudieron usar las 10 unidades por nodo
  • La cantidad de clientes FIO se aumentó para que, en promedio, hubiera aproximadamente 1 cliente FIO con io_depth 128 por OSD
  • La prueba de 3 nodos registró 63 GiB/s en lectura aleatoria de 4 MB
  • La prueba de 10 nodos registró 213.5 GiB/s
    • Fue un escalamiento casi lineal frente a los 3 nodos, alrededor de 98.4%
  • En ese momento solo estaban disponibles 63 de los 68 nodos
    • Se dejaron 32 nodos, 320 OSD, de un lado
    • En 31 nodos cliente se ejecutaron 10 procesos FIO por nodo
  • A escala de 320 OSD se alcanzaron 635 GiB/s de lectura y más de 15 millones de IOPS en lectura aleatoria de 4 KB
  • La latencia promedio y la tail latency se vieron consistentes en las pruebas de escalamiento
    • Se consideró que influyó haber aumentado el número de PG y de clientes FIO junto con los OSD
    • La prueba estaba en un estado de IO muy intenso, y se consideró que había entrado en un punto donde agregar más IO ya no aumentaba el rendimiento, sino solo la latencia

Logro de 1 TiB/s con 630 OSD

  • Como no había más nodos cliente separados para la prueba de capacidad completa, los procesos FIO se co-ubicaron en los nodos OSD
    • Hay una probabilidad de 1/63 de que un cliente se comunique con un OSD local, lo que da una pequeña ventaja de red
    • Por el contrario, co-ubicar clientes FIO en nodos OSD puede generar pérdida de rendimiento
  • El despliegue con CBT de 630 OSD en 63 nodos tardó unos 15 minutos
  • El primer intento alcanzó cerca de 950 GiB/s, muy próximo a 1 TiB/s
  • Luego se redujeron los OSD shards y los threads de async messenger, y se aplicó tuning de RocksDB de Reef
    • El rendimiento de lectura bajó un poco y el de escritura mejoró
    • El rendimiento de escritura aleatoria mejoró casi 20%
    • Parece que el mayor impacto vino del cambio de shards/threads
  • También se hicieron experimentos duplicando el número de PG y volviendo a aumentar la cantidad de clientes
    • La lectura aleatoria de 4 MB mejoró un poco al aumentar la cantidad de clientes
    • Los IOPS de lectura aleatoria pequeña empeoraron
    • Con 8 FIO por nodo, 504 procesos en total, el rendimiento de escritura secuencial cayó fuertemente
  • Cuando 504 procesos FIO realizaban escrituras de 4 MB, algunas PG entraron en estado active+clean+laggy
    • Aunque el throughput era solo una fracción de la capacidad del clúster, con el tiempo aumentaban las PG laggy
    • El clúster no se recuperaba de ese estado hasta que terminaba la carga de trabajo
    • Según la documentación de Ceph, en estado laggy una réplica no logra confirmar a tiempo un nuevo lease del primary, por lo que el IO se suspende temporalmente
  • Finalmente, la configuración predeterminada de Ceph —8 shards, 2 threads por shard y 3 msgr threads— fue la más adecuada para lectura de 4 MB
  • Bajo las condiciones de 256K PG, 630 OSD y 504 procesos cliente FIO, ceph -s mostró 1.0 TiB/s read
    • Los 630 OSD estaban todos en estado up/in
    • Los 262145 PG estaban todos en estado active+clean
    • Las operaciones de lectura mostradas fueron 266.15k op/s

Resultados de erasure coding 6+2

  • El clúster destino real anterior del cliente usaba una configuración de erasure coding 6+2, por lo que se necesitaban pruebas separadas
  • Para las pruebas EC se eligieron valores de PG, shards y clientes que habían funcionado bien en las pruebas anteriores
  • Como se observó que los threads de async messenger trabajaban intensamente, se experimentó con aumentarlos por encima del valor predeterminado
  • Con 4~5 threads async msgr se alcanzó el siguiente rendimiento
    • Lectura: más de 500 GiB/s
    • Escritura: casi 400 GiB/s
  • La razón por la que la lectura 6+2 EC es más lenta que la replicación 3X es la diferencia en overhead de red
    • En replicación, el OSD primary solo necesita leer los datos locales y enviarlos al cliente, por lo que el overhead de red es prácticamente 1X
    • En 6+2 EC, el primary debe leer 5 de los 6 chunks desde las réplicas para construir el object, y luego enviarlo al cliente
    • El overhead total de red de la solicitud es aproximadamente (1 + 5/6)X
  • En escritura ocurre lo contrario
    • En replicación 3X, el object que el cliente envía al primary es reenviado por el primary a dos secondaries, con un overhead total de red de 3X
    • En EC, basta enviar 7/8 de los chunks a los secondaries, por lo que en escrituras grandes muestra mejor rendimiento
  • Los IOPS de IO pequeño son un problema aparte
    • En lecturas/escrituras muy pequeñas, Ceph accede a todos los OSD que participan en el PG del object
    • Aunque los datos de interés estén solo en un chunk, obtiene datos de todos los OSD que participan en el stripe
    • Clyso revivió un PR que implementaba partial stripe reads para erasure coding en el verano de 2023, y tuvo un impacto grande
    • Todavía no está claro si podrá mergearse en Squid

Impacto del cifrado msgr

  • Para estimar el impacto si el cliente usaba cifrado a nivel msgr, también se realizaron pruebas de msgr v2 encryption
  • Se compararon los resultados con cifrado habilitado frente a los resultados anteriores, tanto en replicación 3X como en erasure coding 6+2
  • El mayor impacto apareció en lecturas grandes
    • Cayeron de alrededor de 1 TiB/s a unos 750 GiB/s
  • Los demás ítems mostraron una degradación de rendimiento más moderada, pero consistente
  • También se querían pruebas de PG scaling y kernel RBD, pero el sistema debía devolverse al cliente para realizar re-imaging e integración

Resumen del máximo rendimiento final

  • Los máximos alcanzados en las pruebas fueron los siguientes
Ítem 30 OSDs (3x) 100 OSDs (3x) 320 OSDs (3x) 630 OSDs (3x) 630 OSDs (EC62)
FIO co-ubicado No No No Sí Sí
Lectura 4 MB 63 GiB/s 214 GiB/s 635 GiB/s 1025 GiB/s 547 GiB/s
Escritura 4 MB 15 GiB/s 46 GiB/s 133 GiB/s 270 GiB/s 387 GiB/s
Lectura aleatoria 4 KB 1.9M IOPS 5.8M IOPS 16.6M IOPS 25.5M IOPS 3.4M IOPS
Escritura aleatoria 4 KB 248K IOPS 745K IOPS 2.4M IOPS 4.9M IOPS 936K IOPS
  • Al terminar las pruebas, todo el hardware fue re-imaged, y los nuevos OSD se desplegaron en el clúster HDD existente del cliente
  • La migración se controló con el script upmap-remapped de Dan, y alrededor del 80% de los datos existentes se trasladó a OSD basados en NVMe
  • Al principio se decidió no aplicar de inmediato todo el tuning usado en las pruebas, sino verificar primero el funcionamiento del clúster principalmente con la configuración predeterminada
  • Los datos de prueba podrán usarse más adelante para ajustar más el sistema si el cliente enfrenta problemas de rendimiento

Tareas pendientes y límites de escalamiento

  • Es necesario resolver el problema de PG laggy que aparece bajo grandes cargas de escritura
    • No es aceptable que Ceph colapse cuando crece la carga de trabajo de escritura
  • Estas pruebas confirmaron que Ceph puede saturar NICs de 2×100GbE
  • Para aumentar más el throughput al usar más de 10 unidades NVMe por nodo, se requiere 200GbE o superior
  • Los IOPS son más complejos
    • El número de PG puede tener un gran impacto
    • El modelo de threading de OSD también cumple un rol importante
    • En varias implementaciones se ha llegado a un límite de unos 400K~600K IOPS de lectura aleatoria por nodo
  • Como puntos de mejora se señalaron la interfaz entre async msgr y el kernel, y la forma en que los threads OSD se despiertan cuando entra nuevo trabajo en la shard queue
  • En el pasado se modificó código de OSD para obtener mejores resultados bajo cargas altas, pero a costa de empeorar la latencia con cargas bajas
  • Mejorar los IOPS requerirá enfoques en varias direcciones y posiblemente reescribir parte del código de threading de OSD

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-21
Opiniones de Hacker News

  • Ceph tiene una historia interesante.
    Lo crearon los fundadores de DreamHost por necesidades internas, y DreamHost en la práctica ya ofrecía servicios de ese tipo antes de que términos como IaaS y PaaS se consolidaran en la industria, como VPS, servidores administrados de SO/bases de datos/apps.
    Después escindieron Ceph y Red Hat lo adquirió.
    https://en.wikipedia.org/wiki/DreamHost

    • Todavía soy cliente de DreamHost, y recuerdo una entrada de blog o newsletter de aquella época que decía algo como “estamos intentando crear algo llamado Ceph; podría llegar a ser algo genial”.
      Era una época sin textos de marketing en los que cada frase se pulía para vender, sino en la que simplemente compartían algo con lo que estaban experimentando.
      Recuerdo que era un proyecto universitario de uno de los fundadores, al que se sumaron los otros fundadores dándole apoyo; tengo entendido que Docker tuvo un origen parecido.
    • Para agregar un poco más, también fue algo que creó Sage Weil, fundador de DreamHost, mientras cursaba el posgrado en UC Santa Cruz.
      UCSC fue un lugar del que salió mucha buena investigación en almacenamiento.

  • Buen artículo. En CERN también alcanzamos hace poco 1 TB/s, pero no con Ceph sino con EOS (https://cern.ch/eos).
    https://www.home.cern/news/news/computing/exabyte-disk-stora...
    Eso sí, nuestro clúster EOS tiene muchos más nodos y usa HDD en su mayoría. CERN también usa Ceph de forma extensa.

    • Excelente. Me da curiosidad saber cómo ven a Ceph. ¿La idea es migrar a EOS a largo plazo?

  • Me encantaban este tipo de experimentos. Trabajando como tech lead en Cisco, tuve el lujo de armar Kubernetes sobre bare metal y configurar GlusterFS y Ceph por mi cuenta para aprender y comparar cuál era mejor.
    Si no recuerdo mal, fue alrededor de 2017/2018; buenos tiempos. Este artículo también estuvo muy bueno.

    • Para mejorar los tiempos de respuesta de Aerospike, tuve que correr un montón de benchmarks comparando no solo tipos de instancias de AWS, sino incluso la velocidad de instancias individuales dentro del mismo tipo.
      Algunos SSD NVMe estaban más usados que otros y eso marcaba diferencias; era un trabajo realmente absurdo.
    • Así que eras de los que usaban Heketi. Yo tuve una experiencia parecida por la misma época y fue muy divertido. Todo era demasiado nuevo, y además estaba roto.

  • Ojalá alguien redujera más la escala de los nodos. El sistema descrito aquí tiene 10 discos por nodo y consume alrededor de 300 W/nodo, o sea unos 30 W por disco.
    El overhead es bastante grande, y para obtener aunque sea un poco de redundancia también se necesita una cantidad considerable de almacenamiento.
    Con algo de ingeniería, creo que se podría reducir todo a una décima parte. Algo como hacer una pequeña computadora de placa única con 4 carriles PCIe para NVMe, 2x10GbE (dos sockets SFP+), una CPU ARM o RISC-V lo bastante rápida, y agregar eMMC o una ranura SD para el arranque.
    Así se podría bajar hasta una escala de unos pocos nodos, y también se reduciría la exposición de perder 10 discos de una sola vez por una única falla.
    Creo que se podrían meter muchos de estos sistemas en un gabinete 4U y, opcionalmente, también incluir dentro del mismo gabinete dos switches completamente independientes que agreguen los nodos internos.

    • Hace tiempo ejecuté un clúster Ceph de 5 nodos con varias ODROID-HC2.
      Al ser procesadores armhf, la instalación fue realmente dolorosa, pero una vez que empezó a funcionar, andaba bien. Solo era lento por la única NIC de 1 Gb.
      En ese momento era simplemente para aprender.
      [0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
    • Con la interfaz de módulos de cómputo SODIMM de Nvidia ya se puede validar este concepto.
      Pronto voy a recibir dos ARM Turing RK1 de 7 W, cada uno con PCIe 3x4 capaz de 4 GB/s, y la placa de clúster Turing Pi 2 permite montar 4 en formato ITX.
      Con un costo total de 820 dólares, espero más de 3 Gbps por watt.
      Hasta ahora, el cuello de botella son los carriles PCIe. Incluso un SSD de 2 TB de 90 dólares se anuncia con 7 GB/s en PCIe 4x4, así que todavía no veo a las computadoras de placa única como la solución óptima.
      La línea Ampere Altra parece soportar PCIe 4x128 a 40 W, así que un blade 1U con red de 100G podría ser interesante.
      Dicho eso, incluso en homelabs he visto muchos bugs relacionados con ARM y optimizaciones faltantes, así que quizá sea difícil decir que una solución así ya está lista para centros de datos.
    • Con el aumento de switches 100 Gbps e interfaces de 100 Gbps de bajo costo, 10 Gbps se está volviendo cada vez más obsoleto.
      Hoy, para justificar una configuración de Ceph con interfaces de 10 Gbps, tendría que ser realmente pequeña y muy barata.
      A una escala tan pequeña, probablemente sea mejor poner almacenamiento NVMe local en cada servidor.
    • Haciendo unas cuentas raras, este clúster procesa aproximadamente 0.8 Gbps por watt.
      Es un cálculo aproximado del tipo 1 TB/s × 8 bits/byte × 1024 GB/TB ÷ 34 nodos ÷ 300 W.
      Un sistema ARM muy eficiente, como una Mac mini nueva, consume unos 10 W en uso interactivo y puede manejar una red de 10 Gbps, así que ronda 1 Gbps por watt para datos.
      Es decir, el clúster del artículo original está, a grandes rasgos, en un nivel de bits/segundo/watt similar al de un sistema ARM muy eficiente.
      No creo que usar nodos pequeños vaya a mejorar realmente la eficiencia; al contrario, probablemente termine costando más. Hoy el rendimiento por watt de los servidores potentes es bastante bueno.
      En cualquier caso, esto es software open source corriendo sobre hardware de propósito general, así que también se puede probar por cuenta propia con unos cientos de dólares.
    • En esta arquitectura, la principal fuente de ineficiencia probablemente sean los controladores NVMe.
      Cuando el sistema operativo y el dispositivo NVMe están lejos entre sí, el controlador tiene que inferir la intención de las solicitudes para gestionar el batching y la nivelación de desgaste lo mejor posible, lo que genera ineficiencias naturales.
      La nueva función FDP (flexible data placement) es un intento de resolver esto dándole más control al sistema operativo.
      Lo ideal sería subir esto hacia el sistema operativo host y exponer la flash lo más posible como “un enorme arreglo tonto de transistores conectado como dispositivo PCIe”.
      Si se eliminan capas de abstracción, creo que se podría lograr el paralelismo deseado del sistema componiéndolo con unidades de hardware tipo Atom que tengan una NIC integrada de 100 Gbps y una cantidad proporcional de flash.

  • En algún momento de la historia, la cantidad total de datos digitales almacenados en el mundo llegó por primera vez a 1 TiB.
    Es casi seguro que ese día ocurrió dentro de los últimos 60 años.
    Y ahora, en algún servidor de una organización bastante cualquiera, se mueve esa cantidad de datos cada segundo. Ni siquiera hablamos de un país o de un proyecto de investigación supranacional.

    • Me recuerda a una vez que hice el cálculo y me dio que mi PC de escritorio probablemente era más potente que todas las computadoras de la Tierra combinadas alrededor de 1978.
    • Al menos fue hace más de unos 20 años. Recuerdo a un viejo administrador de sistemas contando que gestionaba petabytes antes de 2003.

  • Es un artículo interesante. Nosotros operamos un clúster de almacenamiento Ceph para mantener una caché de capas de Docker.
    Después de pasar de EBS a Ceph, la diferencia de throughput fue enorme. El throughput de escritura subió de 146 MB/s y 3,000 IOPS a 900 MB/s y 30,000 IOPS.
    Lo mejor es que casi simplemente funciona. Salvo cosas ocasionales como hacer trim del sistema de archivos, casi no requiere atención.
    Fue una mejora enorme para el sistema de caché.
    [0] https://depot.dev/blog/cache-v2-faster-builds

    • Hice algo muy parecido hace casi 10 años. Para los mismos criterios de rendimiento, EBS costaba más de 10 veces lo que costaba un clúster Ceph sobre discos de los nodos.
      Al final nos mudamos a nuestro propio rack y volvimos a reducir el costo casi a una décima parte, y al desarrollar capacidad operativa interna ganamos libertad.
    • Me pregunto si EBS lo alojaban en bare metal. ¿Cómo están alojando Ceph: en bare metal propio/alquilado o en máquinas virtuales EC2?
      Con solo leer el blog no me quedó claro de inmediato.

  • Los peores problemas que tuve con almacenamiento dinámico dentro de clústeres no fueron problemas puros de I/O.
    Eran más bien casos en los que el software de controladores de almacenamiento de Kubernetes no manejaba bien problemas del mundo real, por ejemplo cuando un pod moría y el PVC no se adjuntaba hasta que vencía un timeout muy largo, mientras el pod quedaba en estado ContainerCreating hasta que se liberara el bloqueo del PVC.
    Esto ocurrió en varios clústeres usando rook/ceph y Longhorn.

  • Me da curiosidad saber si alguien ha corrido Ceph en un homelab. La última vez que lo revisé, los requisitos de hardware eran bastante altos

    • Los requisitos siguen siendo altos. Habiendo hecho despliegues tanto en producción como en homelab, diría que es mejor no hacerlo a menos que el objetivo sea simplemente ganar experiencia o montar una demo
      Cuando funciona bien es excelente, pero cuando hay problemas se convierte en un dolor de cabeza enorme
      Si te interesa el almacenamiento distribuido en sí, hay mejores opciones para una configuración de homelab
      seaweedfs ha sido muy estable durante años tanto a pequeña como a enorme escala, y de hecho migré a eso una configuración de Ceph en producción
      Longhorn también fue estable cuando estaba en el mundo de Kubernetes
      GlusterFS también sigue estando bien si entras sabiendo a qué te expones
    • Lo probé, y la interfaz web, el almacenamiento de objetos y el almacenamiento de archivos estaban muy buenos
      Pero era muy difícil obtener un rendimiento decente, y en un clúster pequeño los demonios de metadatos podían quedarse colgados con bastante facilidad
      Al final, cuando dejó de ser divertido, volví a usar ZFS en una sola máquina
    • Tengo experiencia usando Ceph tanto en el trabajo como en un entorno parecido a un homelab
      Primero hay que tener en cuenta que Ceph es un sistema de almacenamiento distribuido, así que la premisa básica es tener varios nodos
      Para aprender, también puedes virtualizar todo en una sola máquina, pero es mucho mejor si tienes máquinas físicas separadas
      Ceph, al igual que ZFS, prefiere tener acceso físico a los discos
      También necesita una conectividad de red decente. Creo que eso es lo que la gente suele tener en mente cuando piensa en los altos requisitos de hardware de Ceph
      Lo ideal es al menos 10GbE, y si quieres más rendimiento necesitarás más que eso. En particular, en tareas como el backfill puede haber mucho tráfico de red
      Si puedes conseguir equipo barato para homelab, 25Gbps está bien; 50Gbps es casi un callejón sin salida técnico, y 100Gbps funciona bien
      Aun así, para un homelab, una mini PC o NUC barata con 10GbE puede correrlo suficientemente bien, con un rendimiento aceptable y buen valor de aprendizaje
      Puedes instalar Ceph directamente en bare metal, o si quieres ir por la ruta de Kubernetes en el homelab, puedes usar Rook(https://rook.io/)
      Espero que ayude; si tienes más preguntas, avísame
    • En el sitio de Ceph hay una entrada de blog sobre instalar Ceph en varias Raspberry Pi 4
      A ese nivel, para nada se puede considerar hardware grande
      [1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
    • Estoy corriendo Ceph en mi lab. Usa bastante CPU, pero funciona bien si estás dispuesto a asumir una red rápida
      Como mínimo 10Gb, idealmente 40Gb o más; y si usas discos giratorios, conviene tener al menos 6 discos por nodo en varios nodos
      Si todo es SSD, probablemente puedas reducir mucho la cantidad de discos por nodo

  • Quería ver cómo se compara 1 TiB/s con el límite teórico del hardware real, así que hice el cálculo.
    Este clúster está compuesto por 68 nodos, y cada nodo es un Dell PowerEdge R6615 (https://www.delltechnologies.com/asset/en-us/products/server...).
    La configuración usada es un R6615 con 10 bahías para unidades U.2, y el enlace U.2 transmite datos por 4 lanes PCIe de 4.ª generación. Un lane PCIe es de 16 Gbit/s y, gracias a la codificación 128b-132b, el overhead es de alrededor del 3%, prácticamente despreciable.
    Por lo tanto, el ancho de banda máximo de enlace de un enlace U.2 es 16×4=64 Gbit/s, es decir, 8 Gbyte/s. Sin embargo, la unidad U.2 NVMe utilizada, la Dell 15.36TB Enterprise NVMe Read Intensive AG, parece tener un throughput de lectura de 7 Gbyte/s (https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...), así que el enlace U.2 de 8 Gbyte/s no es el cuello de botella.
    Como hay 10 unidades U.2 por nodo, cada nodo puede entregar hasta 10×7=70 Gbyte/s de I/O de lectura local.
    Pero el ancho de banda de red de cada nodo es solo de 200 Gbit/s (2×100GbE Mellanox ConnectX-6), es decir, 25 Gbyte/s. Esto significa que, en lecturas remotas, no se puede aprovechar toda la capacidad de 70 Gbyte/s de las unidades y que la red es el cuello de botella.
    Suponiendo que no haya cuellos de botella adicionales en la red, 68 nodos pueden ofrecer 68×25=1700 Gbyte/s de lectura por red. El autor efectivamente midió 1 TiB/s en el benchmark, más precisamente 1025 GiB/s=1101 Gbyte/s, así que está en torno al 65% del máximo teórico de 1700 Gbyte/s.
    Está bastante bien, pero si todos los nodos pudieran saturar por completo y al mismo tiempo sus enlaces de red de 200 Gbit/s, en teoría se podría mejorar un poco más.
    Al leer todo el artículo, me quedó la impresión de que la complejidad de Ceph le impone una carga bastante grande a la CPU. Es bastante inesperado que solo por no compilar los módulos con -O2 (el “Fix Three” enlazado por el autor: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453) “algunas cargas de trabajo puedan ser hasta 5 veces más lentas” (https://bugs.gentoo.org/733316) en workloads de I/O puro.
    También es raro que los threads de OSD desperdicien CPU en exceso intentando tomar spinlocks del IOMMU. Estoy de acuerdo con la conclusión de que el modelo de threading de OSD no es óptimo.
    Un benchmark sintético relativamente simple de 100% lectura no debería revelar contención entre threads. Al menos si esa parte de la arquitectura de software de Ceph estuviera bien diseñada. Como es un problema que se puede corregir, espero que los desarrolladores de Ceph le den mayor prioridad.

    • Quiero agregar que nunca había visto el problema de IOMMU en Ceph.
      El laboratorio upstream de Ceph tiene equipos de Dell con la generación anterior del mismo chasis 1U y procesadores AMD Rome, y no sufre este problema aun con un rendimiento similar a la misma escala, unos 30 OSD.
      El cliente dijo que ya había visto este problema antes en su propio centro de datos, y esperamos poder identificar la causa junto con AMD.
      El verano pasado hice algo de trabajo para reforzar temporalmente el modelo de threading existente de OSD. Cosas como doble buffering en el handoff entre async msgr y los threads worker, y activación adaptativa de threads.
      Bajo carga se pudo mejorar mucho el rendimiento y la eficiencia, pero a costa de aumentar la latencia con cargas bajas. Ceph, por defecto, es muy agresivo al despertar threads cuando entra nuevo I/O en un shard específico.
      Lo conversé con otro desarrollador core y ambos concluimos que tenía más sentido una reescritura completa del código de threading.
    • Este benchmark es de I/O aleatorio. Los discos tienen “apenas” un poco más de 1 millón de IOPS de lectura aleatoria 4K, lo que equivale a unos 5 GiB/s.
      Con 320 OSD, serían alrededor de 1.6 TiB/s.
      Al menos esos fueron los números que encontré. Tampoco es que haya muchas reseñas de estos discos NVMe empresariales.
      Aun así, parece una cifra que encaja bien con las NIC. A esta escala, la mayoría de los workloads probablemente se vean como I/O aleatorio en la capa de almacenamiento.
    • Creo que el overhead de PCIe TLP y los comandos NVMe explican la diferencia entre 7 GB/s y 8 GB/s.

  • Lo sorprendente es por qué eligieron nodos 1U, más difíciles de enfriar, con 10 SSD y NIC 2×100Gb.
    Si hubieran usado nodos 2U con 24 SSD y NIC 2×200Gb o 400Gb, podrían haber eliminado el cuello de botella de red y reducido el consumo gracias a ventiladores más grandes y lentos, y a menos paquetes de CPU. Incluso podrían tener más núcleos por socket.
    Con menos nodos aumenta el dominio de impacto ante fallas, pero con unos 34 nodos no me parece un problema tan grande.
    Con menos nodos, probablemente también se podría haber armado una red más plana con unos 4 switches.

    • Como mencionas, el dominio de impacto ante fallas es un factor principal y, en general, hace que aplicar parches y reemplazar hardware sea menos pesado.
      Los racks y switches ya existían y también se usan bastante para otros fines, así que el espacio físico adicional por Ceph es muy pequeño :)