D’on ve el creixement del disc d’un servidor VPN i com limitar-lo

El túnel deixa d’acceptar connexions, el servei es reinicia dues vegades i després no apareix res al seu registre. Aquest silenci és la pista, perquè el registre és el que va omplir el disc i el dimoni no té on escriure l’error que espereu. Qualsevol servei de llarga durada pot arribar a aquest estat, i esborrar un directori anomenat logs poques vegades ho arregla. La solució duradora és saber quin magatzem ha crescut, qui posseeix la seva retenció i si l’escriptor ha alliberat realment l’espai.

Trobeu el magatzem que ha crescut i la taxa a què ho ha fet

Comenceu amb dos nombres fàcils d’oblidar: blocs lliures i inodes lliures. Un sistema de fitxers pot informar de molt d’espai i tot i així refusar una escriptura perquè no li queden inodes, cosa que passa quan un servei crea un fitxer per sessió. Demaneu les dues lectures al mateix volum, perquè les respostes poden discrepar la mateixa tarda. Feu-ho mentre l’amfitrió està sa, perquè els nombres descriguin el funcionament normal i no una avaria.

df -h /var
df -i /var

Després atribuïu el creixement a un propietari. La xifra d’ús del propi journal només cobreix el journal i mai no veurà un dimoni que escriu en un camí del seu fitxer de configuració.

journalctl --disk-usage

El creixement al llarg del temps diu més que qualsevol lectura única. Un nivell de depuració deixat activat, un bucle de reintents que registra cada intent o un fitxer de captura que ningú no va aturar poden semblar normals en un moment i alarmants una hora després. Feu una lectura, espereu un període de molta feina, feu-ne una altra i dividiu per l’interval. Una taxa que podeu enunciar converteix la capacitat en una decisió i no en un incendi.

Què fa la rotació a un fitxer obert

Un fitxer de registre és un nom que apunta a un inode, i l’espai només torna quan es tanca l’últim descriptor obert. Reanomeneu el fitxer i l’escriptor continua omplint el mateix inode; esborreu-lo i l’escriptor continua omplint un inode sense cap nom. Aquest estat és la raó per la qual «he esborrat el fitxer i el disc segueix ple» descriu descriptors de fitxer i no un sistema de fitxers trencat. Reiniciar l’escriptor, o triar un mode de rotació que torni a obrir el fitxer, és el que realment retorna els blocs.

lsof +L1 | head

La política pertany al component que escriu el fitxer. El journal aplica els seus propis límits d’emmagatzematge des del seu fitxer de configuració, mentre que un servei basat en fitxers normalment es recolza en logrotate, ja sigui amb una regla de creació i un senyal de reobertura o amb un mode de truncament al lloc quan l’escriptor no pot reobrir. Confirmeu la decisió sense canviar res primer:

logrotate -d /etc/logrotate.conf

On pertoca el límit i quant ha de ser de gran

Poseu el límit on està configurat l’escriptor, no al punt de muntatge. Una quota a tot el volum protegeix l’amfitrió però no diu quin servei falla primer, i un script de neteja global tendeix a esborrar les proves que necessitarà el proper incident. Un límit del journal, un recompte de rotacions amb una mida màxima i la retenció de l’aplicació limiten cadascun un productor. Junts limiten el total; per separat, cadascun és una conjectura.

Dimensiona aquest límit a partir de la retenció que podeu defensar, no de l’espai lliure disponible. Si una revisió necessita una setmana d’intents de connexió, el journal ha de guardar una setmana a la taxa més alta esperada, i aquesta taxa és el nombre mesurat abans.

El registre de depuració és un mode temporal amb una hora d’inici registrada, no un pla d’emmagatzematge. Manteniu la qüestió de privadesa dins la mateixa decisió, perquè els registres de connexions porten adreces i identificadors. Una retenció més llarga també és una elecció de tractament de dades i l’ha de prendre algú que conegui les dues restriccions.

Verifiqueu el límit després d’un reinici

Un canvi de retenció que dura fins al proper reinici no és un canvi. Reinicieu l’escriptor, confirmeu que el nou límit s’aplica i comproveu que la rotació encara funciona després. Per al journal, un reinici i una lectura d’ús responen les dues preguntes:

systemctl restart systemd-journald
journalctl --disk-usage

Per a un servei basat en fitxers, executeu la tasca de rotació un cop a mà i confirmeu que el fitxer s’ha substituït i el descriptor s’ha reobert. Un escriptor que conserva el descriptor antic passa una comprovació superficial i falla la propera vegada que el volum s’omple. Vigileu l’espai lliure durant la prova, perquè un fitxer que s’ha reduït mentre l’espai no tornava vol dir que l’inode antic encara es reté.

Compareu la propera lectura amb aquesta

Torneu al cap d’una setmana i compareu la taxa de creixement amb la registrada. Una taxa coincident vol dir que el límit aguanta i la càrrega és estable; una taxa duplicada vol dir que alguna cosa ha canviat, i la pregunta útil és quina. Llegiu primer el contingut del registre per buscar fallades repetides, perquè un bucle de reintents és alhora símptoma i causa de volum. Després reviseu si hi ha res habilitat de nou, incloent-hi nivells de depuració activats durant un incident i mai desactivats.

Manteniu les còpies de seguretat fora del mateix volum, o accepteu que un disc ple s’endurà la còpia amb ell. Una còpia escrita a l’amfitrió que protegeix no és un pla de recuperació, i la seva retenció necessita la seva pròpia resposta.

Escriviu què es reté, on, durant quant de temps i qui ho elimina. Aquesta frase és el lliurable i és l’única part d’aquesta feina que sobreviu al proper reinici.