A Ceph la capacitat no la marca el clúster: la marca el disc més ple

El clúster deixa d'acceptar escriptures un dimarts a la tarda. Les màquines es queden clavades, l'hipervisor no penja i no hi ha cap disc trencat. Mentrestant, ceph df continua ensenyant desenes de teres lliures. Les dues coses són certes alhora, i aquí hi ha la lliçó: a Ceph la capacitat útil no és la suma dels discs. És el que càpiga al que s'ompli primer.

Escrivim això operant Proxmox VE amb emmagatzematge Ceph en producció, repartit en diversos centres de dades, així que venem exactament el que s'explicarà aquí. Convé dir-ho abans de començar, perquè la part més útil de l'article —el compte de la capacitat amb un node menys— es fa amb un full de càlcul i dues ordres, i no requereix comprar res a ningú.

El llindar no és del clúster: és de cada disc

Ceph té tres llindars d'ocupació, i tots tres s'avaluen per OSD, no sobre el total. Els valors per defecte que porta la documentació són 0,85 per a nearfull, 0,90 per a backfillfull i 0,95 per a full. Gairebé ningú no els toca, i està bé: el problema no és el número, és on es mesura.

La comprovació de salut OSD_FULL ho diu en una frase, i val la pena llegir-la a poc a poc perquè el subjecte és en singular i l'objecte en plural: «One or more OSDs have exceeded the full threshold and are preventing the cluster from servicing writes». Un o més OSD han superat el llindar i estan impedint que el clúster serveixi escriptures. No que aquell disc deixi d'acceptar dades: que el clúster deixi de servir escriptures.

Amb precisió: el que s'atura són les escriptures dels pools que tinguin algun grup de col·locació en aquell OSD. En un clúster hiperconvergit de manual —una sola regla CRUSH que reparteix sobre tots els discs de tots els nodes— això vol dir tot el que tens. Un disc de vint-i-quatre atura les màquines de dotze clients. Hi ha un detall curiós, a més, i l'apuntem perquè qui vagi a la documentació se'l trobarà: la pàgina de configuració del monitor és més dura que la de les comprovacions de salut i afirma que Ceph «prevents you from writing to or reading from OSDs», és a dir escriptures i lectures. Les dues pàgines són oficials i no diuen el mateix; a la pràctica, el que cau són les escriptures i les lectures continuen responent. El que veuràs a la consola de Proxmox és un grapat de màquines congelades.

Per què un disc s'omple abans que els altres

Perquè CRUSH no és un repartidor de forats. Col·loca els grups de col·locació amb una funció determinista sobre pesos, no buscant el disc que té més lloc lliure, i aquest és el seu mèrit: qualsevol client calcula on viu un objecte sense preguntar-ho a ningú. El preu és que la distribució és estadística. Amb pocs grups de col·locació per disc la variància es nota, els grups no pesen el mateix entre ells, i cada vegada que algú substitueix un disc de 4 TB per un de 8 TB el repartiment es torna a tòrcer.

Per a això hi ha el balancejador, i ve de fàbrica: la documentació diu que «the default mode is upmap» i que en aquell mode el balanceig automàtic està activat. Ajuda molt i no s'ha de desactivar. Però convé saber dues coses. La primera, que upmap optimitza la col·locació de grups, no de bytes, i això no és una interpretació nostra: la documentació té un apartat dedicat, titulat «Limitation: count-based balancing vs. size-based balancing», que ho diu amb totes les lletres —«Ceph's built-in balancer optimizes only by PG shard count, not by the actual size of the data stored in each PG»—. Si els teus grups són desiguals, el balanceig es queda a mitges. La segona, que té un requisit escrit: «to use upmap, all clients must be Luminous or newer». N'hi ha prou amb un client antic penjant d'aquell clúster —un servidor de còpies que ningú no ha tocat, un kernel vell muntant RBD— perquè l'opció no es pugui activar.

D'aquí surt una regla de lectura que estalvia ensurts: la mitjana d'ocupació d'un clúster de Ceph és el número més inútil del panell. El que mana és el màxim. ceph osd df l'ensenya disc a disc, amb una columna VAR que és l'ocupació de cada disc dividida per la mitjana del clúster: 1,00 és ser just a la mitjana. Si el panell diu 68 % i hi ha un OSD al 91 %, el teu clúster és al 91 %.

L'ordre dels llindars és l'avís que ningú no llegeix

Mira una altra vegada els tres números: 0,85, 0,90 i 0,95. El del mig, backfillfull, no avisa de res. Apaga alguna cosa. La comprovació OSD_BACKFILLFULL diu que un o més OSD han superat el llindar —o el superarien si acabessin els backfills ja en marxa—, «which will prevent data from rebalancing to this OSD»: impedint que es recol·loquin dades cap a aquell disc. Fixa't en l'incís, perquè decideix la resta de l'article: Ceph no espera que el disc sigui al 90 %, fa la projecció i s'hi nega abans.

És a dir: el mecanisme que repara s'apaga cinc punts abans que el que serveix. Quan el disc més ple creua el 90 %, Ceph deixa de poder moure dades cap a ell, que és justament l'eina amb què s'arregla un desequilibri. Quan creua el 95 %, s'atura tot. Entre una cosa i l'altra, en un disc de 4 TB, hi ha uns 200 GB. Una màquina virtual mitjana. Una nit de creixement normal.

Que l'ordre importa ho demostra el mateix Ceph: té una comprovació dedicada, OSD_OUT_OF_ORDER_FULL, l'única raó de ser de la qual és avisar-te que «the utilization thresholds for nearfull, backfillfull, full, and/or failsafe_full are not ascending». Hi ha un avís oficial per al cas que algú deixi els llindars desordenats. Algú ho ha fet abans que tu, i a algú li ha fet mal.

El compte que gairebé ningú no fa: la capacitat amb un node menys

La documentació de Ceph planteja l'exemple amb un clúster de 33 nodes, un OSD de 3 TB a cadascun, 99 TB en total: «with a mon osd full ratio of 0.95, if the Ceph Storage Cluster falls to 5TB of remaining capacity, the cluster will not allow Ceph clients to read and write data». I afegeix la part que gairebé mai no es trasllada al pressupost: cal planificar comptant que diversos OSD fallin alhora i que el clúster continuï podent tornar a active+clean.

Traduït a la pime que té quatre o cinc nodes en comptes de trenta-tres, l'aritmètica és curta i la fem nosaltres aquí, no la documentació. Si el domini de fallada és el node i en perds un, quan Ceph acaba donant-lo per perdut ha de recrear als N−1 nodes que queden totes les rèpliques que vivien al que se'n va anar. El total de dades en brut no baixa: es redistribueix entre menys discs. Perquè cap no creui el 95 % després d'aquella reconstrucció, l'ocupació abans de la fallada no pot passar de 0,95 × (N−1) / N.

Amb quatre nodes, aquell 71 % és el sostre perquè ningú no creui el 95 % després de reconstruir. Però reconstruir cal poder fer-ho, i allà mana el llindar del mig: si l'ocupació projectada d'un OSD passa de 0,90, Ceph es nega a enviar-li dades i els grups es queden en backfill_toofull, és a dir a mig camí. El número que de debò et torna a active+clean és 0,90 × (N−1) / N: amb quatre nodes, 67 %. Aquesta és la columna del mig, i és la que cal mirar, perquè el criteri que demana la documentació no és «que no s'aturi», és que el clúster pugui recuperar-se a active+clean. La tercera columna hi afegeix el marge de no passar-te ni de l'avís mentre dura la reconstrucció. I tot això suposant nodes idèntics i repartiment perfecte, que no existeix: al màxim real de ceph osd df resta-li uns punts i tindràs el número honest.

El cas de tres nodes mereix paràgraf a part, perquè és el més venut i el que trenca la taula. Amb rèplica 3 i domini de fallada per node, si cau un node no queden tres llocs diferents on posar tres còpies: Ceph no pot reconstruir, així que no s'omple res. Es queda degradat i esperant, amb min_size 2 deixant-te continuar treballant sobre dues còpies. L'avís de Proxmox sobre això és taxatiu i va justament en la direcció contrària a la temptació: «do not set a min_size of 1», perquè permetre E/S sobre un objecte amb una sola rèplica porta a pèrdua de dades i a grups incomplets. En tres nodes, doncs, qui mossega no és el node: és el disc solt. Si mor un OSD i el seu node continua viu, els seus grups es recreen als altres OSD d'aquell mateix node, perquè el domini de fallada no deixa treure'ls d'allà. Amb quatre discs per node això multiplica per 4/3 l'ocupació dels tres que queden, pitjor que perdre un node sencer de sis, i allà el compte es fa amb els discs d'un node i no amb els nodes. Ho desenvolupem a l'alta disponibilitat de Proxmox no evita la caiguda, l'escurça.

I hi ha un tercer factor que mou la taula sencera: l'esquema de protecció. Amb rèplica 3 escrius tres vegades el que ocupes; amb codificació d'esborrat escrius bastant menys, però necessites més dominis de fallada i pagues en escriptures petites. Aquell compte el vam fer sencer a rèplica 3 contra erasure coding, i convé tenir-lo al costat d'aquest, perquè l'ocupació en brut de què parla tot aquest article surt d'allà.

El que es fa a les tres de la matinada, i el que costa

Amb el clúster aturat i les màquines dels clients congelades, el primer que apareix a qualsevol cerca és pujar el llindar:

ceph osd set-full-ratio 0.96

Funciona, i no farem veure que mai no ho hem escrit. Com a maniobra és legítima: retorna l'escriptura durant l'estona justa per esborrar una instantània vella, moure un disc de lloc o encendre un OSD nou. Com a estat és una hipoteca, i convé saber contra quin sostre la signes: per damunt del full ratio del monitor hi ha un altre llindar que aplica el mateix OSD, osd_failsafe_full_ratio, que val 0,97 per defecte. Pujar-lo fins allà és enganxar l'un a l'altre i quedar-te sense res entre el llindar que atura les escriptures i la frenada del disc; i per damunt de 0,97 el clúster et contesta amb un OSD_OUT_OF_ORDER_FULL en vermell, el mateix avís del paràgraf anterior. Per això la maniobra és 0,96 i el rellotge posat: el que es puja en una emergència es baixa l'endemà, i això és una tasca amb data al calendari, no una intenció.

La sortida ordenada és afegir capacitat, i és aquí on el problema deixa de ser de Ceph. Un OSD més vol dir un forat de badia, o un node més vol dir unitats de rack, potència contractada i refrigeració per dissipar-la; això ja no es resol per consola, i ho expliquem a el colocation ja no es negocia en U, es negocia en kW. I encara que el ferro hi sigui, la reconstrucció no és gratis: moure teres entre discs competeix amb la producció per les mateixes cues d'entrada i sortida, que és exactament el que governa el planificador de l'OSD i el que expliquem a Ceph no rendeix el que diu la fitxa del disc. Recuperar espai amb el clúster ja angoixat és la pitjor hora per demanar-li rendiment.

Quatre ordres i un número en un full

ceph osd df
ceph df
ceph balancer status
ceph osd test-reweight-by-utilization

1. ceph osd df. Ordena per %USE i queda't amb el màxim, no amb la mitjana. La columna VAR és l'ocupació de cada disc dividida per la mitjana, així que 1,00 és la mitjana: si hi ha OSD per damunt d'1,15 tens un repartiment tort, no un clúster ple. Per calibrar-ho, el mateix reweight-by-utilization ataca per defecte els que superen la mitjana en un 20 %.
2. ceph df. Mira MAX AVAIL per pool, no l'AVAIL global, que és el que enganya. La documentació avisa que aquell valor és «a complicated function of the replication or the kind of erasure coding used, the CRUSH rule that maps storage to devices, the utilization of those devices, and the configured mon_osd_full_ratio setting»: la utilització dels dispositius i el full ratio ja són dins del número.
3. ceph balancer status. Comprova que és actiu i en mode upmap. Si et diu que no el pot fer servir, busca el client antic que ho impedeix abans que cap altra cosa.
4. ceph osd test-reweight-by-utilization. És la versió en sec: la documentació la descriu com la manera d'esbrinar a quants grups i OSD afectaria un reweight-by-utilization abans d'executar-lo. Mira-la abans de tocar pesos a mà.

El número del full és un de sol i no canvia gairebé mai: el percentatge d'ocupació en brut a partir del qual deixes de sobreviure a perdre un node. El treus de la taula de dalt, li restes els punts de desequilibri que t'ensenyi ceph osd df, i el poses com a llindar d'alerta a la monitorització. El mateix manual de Proxmox fa servir aquesta mateixa lògica quan explica com treure un OSD: «make sure that all OSDs have their Used (%) value well below the nearfull_ratio of default 85%». Còmodament per sota. No fregant-lo.

Quan això no et lleva la son

Si el teu clúster és al 40 %, els discs són tots iguals, el balancejador va en upmap i creixes 200 GB al mes, tens anys per endavant i cap decisió a prendre. Fes el compte una tarda, posa l'alerta i oblida-te'n. Tampoc no t'afecta si el creixement és pla perquè el que guardes són dades operatives amb retenció tancada: allà el problema no és la capacitat, és el temps que trigues a recuperar-les.

Sí que t'afecta, i força, en tres situacions concretes. Quan el creixement el generen màquines virtuals que ningú no esborra mai —instantànies d'abans d'una actualització que va sortir bé fa divuit mesos, clons de proves, el disc d'un servidor que algú va apagar fa un any i ningú no va esborrar—. Quan has anat ampliant el clúster amb discs de mides diferents, que és el normal quan compres cada any. I quan el nombre de nodes és petit, perquè és on la fracció (N−1)/N mossega de debò: la diferència entre quatre nodes i deu són catorze punts percentuals de disc que et pensaves que tenies i no tens.

Nota de fonts

Llindars i textos de les comprovacions de salut (OSD_FULL, OSD_BACKFILLFULL, OSD_NEARFULL, OSD_OUT_OF_ORDER_FULL): documentació oficial de Ceph, «Health checks». Valors per defecte 0,85 / 0,90 / 0,95 de mon_osd_nearfull_ratio, mon_osd_backfillfull_ratio i mon_osd_full_ratio, i l'exemple del clúster de 33 nodes amb 99 TB: «Monitor Config Reference», apartat «Storage Capacity». Definició de MAX AVAIL: «Monitoring a Cluster». Mode per defecte del balancejador i requisit de versió dels clients: «Balancer Module». Ordres ceph osd df, reweight-by-utilization i la seva versió en sec: «Control Commands». Valors per defecte de pool a Proxmox (mida 3, min_size 2), l'advertiment sobre min_size 1 i el de mantenir els OSD còmodament per sota del 85 % abans de retirar-ne un: manual de Proxmox VE, capítol «Deploy Hyper-Converged Ceph Cluster». Les cites es reprodueixen en el seu idioma original i es tradueixen al text. La taula de capacitat amb un node menys és un càlcul nostre, no una xifra publicada per Ceph: aplica 0,95 × (N−1) / N a la primera columna, 0,90 × (N−1) / N a la segona —la que decideix si la reconstrucció arriba a acabar— i 0,85 × (N−1) / N a la tercera. Suposa domini de fallada per node, nodes d'igual capacitat, repartiment perfecte, que el node caigut roman fora el temps suficient perquè Ceph reconstrueixi les seves rèpliques i que l'esquema de protecció cap als N−1 dominis que queden (amb codificació d'esborrat 4+2 sobre sis nodes, per exemple, perdre'n un tampoc no reconstrueix). Els percentatges de la taula estan truncats a la baixa. Amb discs desiguals o repartiment tort, el número real és pitjor. Les opinions sobre pujar el full ratio en calent i sobre què mirar a la monitorització surten d'operar Proxmox VE amb Ceph en producció, no de les fonts citades.