Sikertelen meghajtó cseréje egy mdadm tömbben az Ubuntun

Az ebben a bejegyzésben található információk az Ubuntu 18.04-en és az mdadm verzióján alapulnak, amely a tárolókban található; az írás idején a v4.1-rc1. Lehet, hogy más verziókra érvényes, de lehet, hogy nem.

Nemrég hirtelen meghajtóhiba történt az otthoni fájlszerveremben, amely kilenc meghajtóból áll egy mdadm RAID-6 tömbben. Ez mindig ijesztő, de szerencsére gyorsan sikerült beszereznem egy cseremeghajtót, amit már másnap szállítottak, így elkezdhettem az újjáépítést.

Bevallottan egy kicsit túl olcsó voltam, amikor eredetileg beállítottam a fájlszervert; a meghajtók közül csak kettő valódi NAS-meghajtó (Seagate IronWolf), míg a többi asztali meghajtó (Seagate Barracuda). Nem meglepő, hogy ez volt az egyik asztali meghajtó, amely feladta (csaknem három évnyi szolgáltatás után). Teljesen halott volt; Miután áthelyeztem egy asztali USB-házba, csak egy nyugtalanító kattanó hang hallatszott belőle, és sem az Ubuntu 20.04, sem a Windows 10 nem tudta észlelni.

Nos, térjünk rá a cserealkatrészre (és igen, az új meghajtó, amit vettem, egy IronWolf volt, tanulságból) – bármennyire is ijesztő az, hogy elveszítünk egy meghajtót egy futó tömbben, még ijesztőbb, ha nem ismerjük a megfelelő eljárást a cseréhez. Nem ez az első alkalom, hogy hibás meghajtót kell cserélnem egy mdadm tömbben, de szerencsére olyan ritka, hogy általában meg kell keresnem a megfelelő parancsokat. Ezúttal úgy döntöttem, hogy elkészítem a saját kis útmutatómat a későbbiekben.

Tehát először is, amikor megkapja a rettegett sikertelen eseményről szóló e-mailt az mdadm-től, azonosítania kell, melyik meghajtó hibásodott meg. Természetesen megmondja az eszköz nevét (az én esetemben /dev/sdf), de valószínűleg nem egyértelmű, hogy melyik fizikai meghajtóról van szó, mivel ezek a nevek megváltozhatnak a gép indításakor.

Ha még abban sem biztos, hogy melyik eszköznév hibásodott meg, a következő paranccsal kiderítheti (cserélje ki a /dev/md0 fájlt a RAID-eszközére):

Mint említettem, az én esetemben a /dev/sdf volt, úgyhogy folytassuk ezzel.

Ezután megpróbálhatja megtalálni a meghibásodott meghajtó sorozatszámát a következő parancs kiadásával:

(ha a smartctl nem található, telepítenie kell a smartmontools csomagot az Ubuntun)

A sorozatszám ezután összehasonlítható a meghajtók fizikai címkéjén található sorozatszámokkal, hogy kitaláljuk, melyik hibásodott meg.

Ezúttal azonban nem voltam szerencsés. A meghajtó teljesen lemerült, és még a SMART vagy más adatokat sem volt hajlandó megadni, beleértve a sorozatszámot is.

Mivel fizikai hozzáférésem volt a szerverhez (amire valóban szüksége van, ha fizikai meghajtót akar cserélni, gondolom ;-)), és a szerver valóban futott, amikor a lemez meghibásodott (és a RAID-6 redundanciájának köszönhetően továbbra is jól működött), az igazán primitív, de valójában nagyon hatékony és kézenfekvő módszert választottam: egyszerűen átmásolok egy nagy fájlt a szerverre, és megnézem, melyik HDD-t nézi. Néhány másodpercen belül azonosítottam a tettest.

Most, mielőtt kirántja a fizikai meghajtót, jó ötlet hivatalosan tájékoztatni az mdadm-et erről a szándékról a következő parancs kiadásával (az eszközneveket szükség szerint cserélje ki a sajátjára):

Siker esetén az mdadm egy üzenettel válaszol, hogy "forró eltávolította" a meghajtót, nyilván azért, mert a virtuális raideszköz éppen fut.

Ha az „eszköz vagy erőforrás foglalt” üzenethez hasonló hibaüzenettel meghiúsul, akkor előfordulhat, hogy az mdadm valójában nem regisztrálta a meghajtót teljesen meghibásodottként. Ehhez adja ki ezt a parancsot (ismét ne feledje, hogy az eszközneveket adott esetben sajátjára cserélje):

Ezt követően az előző paranccsal el kell tudni távolítani az eszközt a tömbből.

Itt az ideje a meghajtó tényleges cseréjének. Ha nagyon- nagyon biztos benne, hogy a gépe és a vezérlője támogatja az üzem közbeni cserét, akkor ezt a gép leállítása nélkül is megteheti. Ez lenne a módja a kritikus termelési rendszereknek, amelyek valódi, megfelelő szerverhardveren futnak, amelyről biztosan tudja, hogy képes kezelni. Az otthoni fájlszerverem egy fogyasztói minőségű asztali alaplapon alapul, néhány félig névtelen SATA vezérlővel a PCIe bővítőhelyekben, hogy több SATA portot biztosítson.

Bár a SATA-nak általában támogatnia kell a hot swap-ot, nem akartam semmit kockáztatni ebben a beállításban, ezért a meghajtó cseréje mellett a gép leállítása mellett döntöttem.

Mielőtt ezt megtenné, érdemes megjegyzést fűzni a raid eszközhöz az /etc/fstab fájlba, hogy az Ubuntu ne próbálja meg automatikusan felcsatolni a következő rendszerindításkor, mert lefagyhat és helyreállítási módba kényszerítheti a leromlott RAID tömb miatt. Lehet, hogy ez nem nagy probléma, ha asztali rendszerről van szó, de a szervert fej nélkül futtatom monitor vagy billentyűzet csatlakoztatása nélkül, így ez egy kis gondot okozna.

Miután elindította a gépet a fényes új meghajtóval, használja az lsblk-t vagy más módszert az azonosítására. Ha mást nem változtatott, valószínűleg (de nem feltétlenül ) ugyanazt a nevet kapja, mint a kicserélt meghajtó. Az én esetemben megtörtént, így az új neve is /dev/sdf.

Mivel a tömböm nem fizikai eszközökön, hanem partíciókon alapul, át kellett másolnom a partíciós táblát egy működő meghajtóról az új meghajtóra, hogy megbizonyosodjak arról, hogy pontosan ugyanazok. Ha ehelyett fizikai eszközökön futtatja a tömböt, kihagyhatja ezt a lépést.

Erre a célra az sgdisket használtam, a /dev/sdc-ből a /dev/sdf-be másoltam a partíciós táblát. Ügyeljen arra, hogy megfelelő módon cserélje ki az eszközneveket, hogy megfeleljenek a sajátjának.

Itt figyelje meg a sorrendet: először a "to" meghajtót írja ki! Ez egy kicsit ellentmondásos számomra, de csak ügyeljen arra, hogy jól csinálja, nehogy újabb meghajtóhiba legyen a tömbben ;-)

Ezután az UUID-ütközések elkerülése érdekében hozzon létre új UUID-ket az új meghajtóhoz:

És most végre eljött az idő, hogy hozzáadjuk az új meghajtót a tömbhöz, és elindítsuk az újjáépítési bulit! (Rendben, ez nem igazán buli, valójában egy meglehetősen lassú és idegesítő folyamat, mivel nagyon-nagyon nem szeretné, ha egy újabb meghajtó meghibásodott volna. A sör azonban segíthet.)

Mindenesetre az új meghajtó tömbhöz való hozzáadásához adja ki ezt a parancsot (ismét ügyeljen arra, hogy az eszközneveket megfelelő módon cserélje ki a sajátjával):

Ha minden jól megy, a meghajtó akadozás nélkül felkerül a tömbbe. Úgy gondolom, hogy alapértelmezés szerint "hot spare"-ként van hozzáadva, de mivel ebből a tömbből hiányzik egy lemez (az, amelyik meghibásodott), azonnal használatba veszi, és elindul az újraépítési folyamat.

Így figyelheted a dolgot:

Ez valószínűleg eltart egy ideig; az én alantas szerveremen (nagyrészt fogyasztói hardveren és asztali meghajtókon alapulva, ne feledd) valamivel 100 MB/sec alatti sebességet tudott elérni. Ne feledje, hogy ez a RAID-6, tehát sok paritásszámítás szükséges az újraépítéshez; egy RAID-10 sokkal gyorsabb lett volna. Ez a konkrét gép AMD A10 9700E négymagos CPU-val rendelkezik (az "E" azt jelenti, hogy ez egy alul órajelű, energiahatékony modell, azaz nem szupergyors), csak hogy képet adjon arról, mire számíthat. A telepített kilenc 8 TB-os meghajtóval a teljes újraépítés valamivel több mint 24 órát vett igénybe.

Az újraépítés során felcsatolhatja a fájlrendszert a tömbre, és a szokásos módon használhatja, ha akarja, de én inkább hagyom az újraépítésre, amíg az elkészül. Ne feledje, hogy ha az egyik meghajtó meghibásodik, hamarosan egy másik következhet, tehát azt szeretné, hogy az újraépítés a lehető leggyorsabban megtörténjen, mivel nem szeretné, hogy egy másik meghajtó meghibásodjon ezalatt. Ezért ne terhelje más olyan IO-val, amely nem feltétlenül szükséges.

Ha kész, adja vissza az /etc/fstab fájlhoz, indítsa újra, és élvezze a fájlokat :-)