Substitució d'una unitat fallida en una matriu mdadm a Ubuntu

La informació d'aquesta entrada es basa en Ubuntu 18.04 i la versió de mdadm inclosa als seus repositoris; en el moment d'escriure la v4.1-rc1. Pot ser vàlid o no per a altres versions.

Recentment vaig tenir una fallada sobtada de la unitat al meu servidor de fitxers domèstic, que consta de nou unitats en una matriu mdadm RAID-6. Això sempre fa por, però afortunadament vaig poder obtenir ràpidament una unitat de substitució que ja es va lliurar l'endemà per poder començar la reconstrucció.

És cert que era una mica massa barat quan vaig configurar originalment el servidor de fitxers; només dues de les unitats són unitats NAS reals (Seagate IronWolf), mentre que la resta són unitats d'escriptori (Seagate Barracuda). No en va, va ser una de les unitats d'escriptori que s'havia donat per vençuda (després de gairebé tres anys de servei, però). Estava completament mort; després de traslladar-lo a una carcassa USB d'escriptori, tot el que vaig treure va ser un so de clic inquietant i ni Ubuntu 20.04 ni Windows 10 van ser capaços de detectar-lo.

Doncs bé, a la peça de recanvi (i sí, la nova unitat que vaig comprar va ser una IronWolf, lliçó apresa) - tan espantós com perdre una unitat en una matriu en execució, encara fa més por si no coneixeu el procediment correcte per substituir-lo. No és la primera vegada que he de substituir una unitat fallida en una matriu mdadm, però, afortunadament, és tan rar que normalment he de buscar les ordres adequades. Aquesta vegada vaig decidir elaborar la meva pròpia petita guia per a una futura referència.

Per tant, en primer lloc, quan rebeu el temut correu electrònic d'esdeveniment d'error de mdadm, heu d'identificar quina unitat ha fallat. Per descomptat, us dirà el nom del dispositiu (en el meu cas /dev/sdf), però probablement no sigui obvi quina unitat física és realment, ja que aquests noms poden canviar quan s'inicia la màquina.

Si ni tan sols esteu segur de quin nom del dispositiu ha fallat, podeu utilitzar l'ordre següent per esbrinar (substituïu /dev/md0 pel vostre dispositiu RAID):

Com he esmentat, en el meu cas era /dev/sdf, així que continuem amb això.

A continuació, podeu provar de trobar el número de sèrie de la unitat fallada emetent aquesta ordre:

(si no es troba smartctl, cal que instal·leu el paquet smartmontools a Ubuntu)

El número de sèrie es pot comparar amb els números de sèrie de l'etiqueta física de les unitats per esbrinar quin ha fallat.

Aquesta vegada, però, no he tingut tanta sort. La unitat estava completament morta i fins i tot es va negar a proporcionar dades SMART o altres, inclòs el número de sèrie.

Com que tenia accés físic al servidor (que realment necessiteu si voleu substituir una unitat física vosaltres mateixos, suposo ;-)) i el servidor s'estava executant quan el disc va fallar (i va continuar funcionant bé gràcies a la redundància RAID-6), vaig seguir el mètode realment primitiu, però en realitat molt eficaç i obvi, de simplement copiar un fitxer gran al servidor i mirar-ho. En pocs segons vaig identificar el culpable.

Ara, abans de treure la unitat física, és una bona idea informar formalment a mdadm d'aquesta intenció, emetent aquesta ordre (substituïu els noms dels dispositius pels vostres segons correspongui):

En cas d'èxit, mdadm respondrà amb un missatge dient que ha "eliminat en calent" la unitat, aparentment perquè el dispositiu de raid virtual s'està executant en aquell moment.

Si falla amb un missatge d'error semblant a "dispositiu o recurs ocupat", pot ser que mdadm de fet no hagi registrat la unitat per haver fallat completament. Per fer-ho, emeteu aquesta ordre (de nou, recordeu substituir els noms dels dispositius pels vostres segons correspongui):

Després d'això, hauríeu de poder eliminar el dispositiu de la matriu amb l'ordre anterior.

Ara és el moment de substituir realment la unitat. Si esteu segurs que la vostra màquina i el vostre controlador admeten l'intercanvi en calent, podeu fer-ho sense apagar la màquina. Aquesta seria la manera d'anar en sistemes de producció crítics que s'executen amb un maquinari de servidor real i adequat que sabeu que pot gestionar-ho. El meu servidor de fitxers domèstic es basa en una placa base d'escriptori de grau de consum amb un parell de controladors SATA sense nom a les ranures PCIe per proporcionar més ports SATA.

Tot i que SATA en general hauria de suportar l'intercanvi en calent, no estava a punt d'arriscar res en aquesta configuració, així que vaig optar per apagar la màquina mentre substituïa la unitat.

Abans de fer-ho, és una bona idea comentar el dispositiu de raid al fitxer /etc/fstab perquè Ubuntu no intenti muntar-lo automàticament a la propera arrencada, perquè podria penjar-vos i obligar-vos al mode de recuperació a causa de la matriu RAID degradada. Potser no és un gran problema si es tracta d'un sistema d'escriptori, però executo aquest servidor sense cap sense monitor ni teclat connectat, així que seria una mica complicat.

Després d'arrencar la màquina amb la nova unitat brillant instal·lada, utilitzeu lsblk o algun altre mitjà per identificar-la. Si no heu canviat res més, probablement (però no necessàriament ) tindrà el mateix nom que la unitat que heu substituït. En el meu cas ho va fer, així que el nou també s'anomena /dev/sdf.

Com que la meva matriu es basa en particions en lloc de dispositius físics, necessitava copiar la taula de particions d'una unitat de treball a la nova unitat per assegurar-me que són exactament iguals. Si executeu la vostra matriu en dispositius físics, podeu ometre aquest pas.

Vaig utilitzar sgdisk per a aquest propòsit, copiant la taula de particions de /dev/sdc a /dev/sdf. Assegureu-vos de substituir els noms dels dispositius perquè coincideixin amb els vostres segons correspongui.

Observeu l'ordre aquí: primer enumereu la unitat "a"! Això és una mica contrari a la intuïció per a mi, però només assegureu-vos d'encertar-ho per no tenir una altra fallada de la unitat a la matriu ;-)

A continuació, per evitar conflictes d'UUID, genereu nous UUID per a la nova unitat:

I ara per fi ha arribat el moment d'afegir la nova unitat a la matriu i començar la festa de reconstrucció! (D'acord, no és realment una festa, en realitat és un procés bastant lent i inquietant, ja que realment no voleu que una altra unitat falli en aquest moment. La cervesa pot ajudar, però)

De totes maneres, per afegir la nova unitat a la matriu, emet aquesta ordre (de nou, assegureu-vos de substituir els noms dels dispositius pels vostres segons correspongui):

Si tot va bé, la unitat s'afegirà a la matriu sense problemes. Crec que en realitat s'afegeix com a "recanvi en calent" per defecte, però com que a aquesta matriu li falta un disc (el que ha fallat), es posa en ús immediatament i s'iniciarà el procés de reconstrucció.

Podeu vigilar-lo així:

Això probablement trigarà una estona; al meu servidor baix (basat en gran mesura en maquinari i unitats d'escriptori de grau de consum, tingueu en compte) va poder arribar a una mica menys de 100 MB/s. Tingueu en compte que això és RAID-6, de manera que hi ha molts càlculs de paritat implicats amb una reconstrucció; un RAID-10 hauria estat molt més ràpid. Aquesta màquina en particular té una CPU AMD A10 9700E de quatre nuclis (la "E" vol dir que és un model d'eficiència energètica amb poc temps, és a dir, no molt ràpid), només per donar-vos una idea de què esperar. Amb les nou unitats de 8 TB de la meva configuració, la reconstrucció completa va trigar una mica més de 24 hores.

Durant la reconstrucció, podeu muntar el sistema de fitxers a la matriu i utilitzar-lo de manera normal si ho voleu, però prefereixo deixar-ho a la reconstrucció fins que s'acabi. Tingueu en compte que si una unitat falla, pot ser que aviat se'n segueixi una altra, de manera que voleu que la reconstrucció es faci tan ràpid com sigui possible, ja que realment no voleu que una altra unitat falli durant això. Per tant, no el carregueu amb altres IO que no siguin estrictament necessaris.

Un cop fet, torneu-lo a afegir al vostre fitxer /etc/fstab, reinicieu i gaudiu dels vostres fitxers :-)