Waarom blijft de RAID-capaciteit ongewijzigd nadat elke schijf is vervangen?

De RAID-capaciteit blijft meestal ongewijzigd omdat een laag in de opslagstack nog steeds de oude grens toont. Bevestig dat elke vervanging een actief, volledig herbouwd lid is, en vergelijk vervolgens de gerapporteerde grootte van de fysieke schijven, lidpartities, RAID-apparaat, volumelaag en aangekoppeld bestandssysteem in die volgorde. De eerste laag die nog steeds de oude grootte rapporteert, is normaal gesproken de laag die uitgebreid moet worden.

Bevestig Dat Elke Vervanging een Actief Lid Is Geworden

Begin met de array-status in plaats van het capaciteitscherm. Een grotere schijf die nog steeds wordt vermeld als reserve, vervangingsdoel, herbouwapparaat of niet-beschikbaar lid, vergroot de gemeenschappelijke grootte van de RAID-groep nog niet. Noteer het serienummer, de rol, het aantal bruikbare sectoren, de herbouwstatus en foutentellers van elk lid voordat je iets wijzigt.

In een mirror kan de capaciteit normaal gesproken niet groeien totdat alle leden die de mirror definiëren groot genoeg zijn. In parity RAID moet elk lid dat deelneemt aan de huidige geometrie mogelijk ook de grotere componentgrootte tonen. De veilige vervangingsvolgorde is om één schijf te vervangen, te wachten op een schone herbouw, de array te verifiëren en pas daarna de volgende schijf te vervangen. De gids van ZimaSpace over het één voor één vervangen van elk mirrorlid legt uit waarom de bruikbare capaciteit vaak ongewijzigd blijft tijdens de tussenliggende fasen.

Vind de Eerste Opslaglaag Die Nog Steeds de Oude Grootte Rapporteert

Een NAS kan meerdere onafhankelijke capaciteitslimieten stapelen: fysieke schijf, partitietabel, RAID-lid, RAID-apparaat, encryptiemapping, LVM fysiek volume, logisch volume, opslagpool en bestandssysteem. Het vervangen van hardware verandert alleen de eerste laag. Elke laag erboven moet de grotere grens ontdekken of hierover geïnformeerd worden voordat de aangekoppelde share de extra ruimte kan gebruiken.

Schrijf de grootte op die bij elke laag wordt getoond in plaats van herhaaldelijk op een “uitbreiden”-knop te drukken. De juiste diagnose is de eerste overgang waarbij een lagere laag groter is, maar de volgende laag nog steeds de oude grootte heeft.

Controleer Of de Vervangingspartities Nog Steeds Eindigen op de Oude Grens

Veel vervangingsworkflows kopiëren de originele partitietabel zodat RAID-metadata op dezelfde offset begint. Dat beschermt uitlijning en lididentiteit, maar kan ook een groot ongebruikt gebied achter het oude partitie-einde achterlaten. De fysieke schijf is groter terwijl het RAID-lid dat aan de array wordt gepresenteerd nog steeds de oude grootte heeft.

Vergelijk sectoraantallen in plaats van afgeronde terabyte-labels. Schijven met dezelfde nominale capaciteit kunnen iets verschillende bruikbare sectoraantallen hebben, en een te kleine vervangingspartitie kan voorkomen dat de array een grotere gemeenschappelijke componentgrootte kiest. Maak geen partities zomaar opnieuw aan op een actief lid; behoud de startsector, partitie-type en RAID-metadata-indeling en voer alleen de platform-ondersteunde wijziging uit na een geverifieerde back-up.

Verifieer Dat de RAID-laag Werkelijk Is Vergroot

Een gezonde status en grotere leden bewijzen niet dat het RAID-apparaat zelf de nieuwe geometrie heeft overgenomen. Sommige opslagsystemen breiden automatisch uit na de laatste vervanging en herbouw; andere vereisen een aparte array-groeibewerking. In Linux md, bijvoorbeeld, moet het RAID-apparaat nog een expliciete groeistap doorlopen nadat de onderliggende lidapparaten de grotere grootte tonen.

Bevestig voordat je een groei start dat de array schoon is, elk verwacht lid actief is, er geen herbouw of scrub loopt en recente logs geen nieuwe lees-, schrijf-, time-out- of linkfouten bevatten. Een groeibewerking verandert geometrie of componentgrootte; deze mag niet worden gebruikt om een onopgeloste gedegradeerde status te verbergen.

Inspecteer Encryptie-, LVM- en Opslagpoolgrenzen Boven RAID

Als het RAID-apparaat groter is maar het logische volume ongewijzigd blijft, wachten de extra blokken in een tussenlaag. Een versleutelde mapping moet mogelijk het grotere apparaat opnieuw scannen. Een LVM fysiek volume moet mogelijk nieuwe extents herkennen voordat de volumegroep ze kan toewijzen, en het logische volume moet worden uitgebreid voordat het bestandssysteem kan groeien.

Sla de bestandssysteemlaag niet over omdat een capaciteits-tool vrije ruimte “ergens” in de stack rapporteert. Verifieer de grootte die elk mapping- en volume-object presenteert. In thin-provisioned of gepoolde systemen, onderscheid ongealloceerde poolruimte van vrije ruimte binnen het aangekoppelde bestandssysteem; ze zijn niet uitwisselbaar.

Breid het Bestandssysteem Alleen Uit Nadat Het Block-apparaat Groter Is

Een bestandssysteem kan alleen het block-bereik gebruiken dat het onderliggende apparaat momenteel presenteert. Ext4, XFS, Btrfs, ZFS en andere bestandssystemen hebben verschillende groeiregels, mount-statusvereisten en veiligheidscontroles. Identificeer eerst het bestandssysteem en de opslagstack, en gebruik dan de ondersteunde procedure in plaats van een commando van een ander platform te lenen.

ZFS is een nuttig voorbeeld waarom de laatste stap implementatiespecifiek kan zijn. Nadat alle mirrorleden zijn vervangen, moet een ZFS mirror mogelijk nog de nieuwe apparaatgrootte uitbreiden voordat de pool de ruimte toont. Btrfs kan eveneens vereisen dat de grotere apparaatgrens wordt herkend, ook al is de vervanging succesvol afgerond. De juiste actie hangt af van welke laag de lidapparaten beheert.

Stop Wanneer het Platform de Bestaande Indeling Niet Ter Plaatse Kan Uitbreiden

Sommige RAID-controllers, appliance-indelingen, partitieschema’s en bestandssystemen kunnen de huidige configuratie niet ter plaatse uitbreiden. Andere kunnen alleen bepaalde RAID-niveaus uitbreiden of vereisen dat alle leden exact overeenkomen. Als de beheersinterface geen ondersteunde groeipaden biedt, forceer dan geen commando’s van een andere opslagstack alleen omdat de schijfgroottes vergelijkbaar lijken.

Stop en plan een back-up en hercreatie-migratie wanneer lidgeschiedenissen conflicteren, de array gedegradeerd is, gezondheidsmeters stijgen, de partitie-indeling niet veilig kan worden gewijzigd of het platform geen methode voor ter plaatse uitbreiding documenteert. Na een ondersteunde groei, verifieer de nieuwe grootte op elke laag, voer de integriteitscontrole van het platform uit, bevestig normale applicatietoegang en bewaar de status voor en na als nieuwe basislijn.