SLES Thin Pool heeft geen ruimte meer: ​​LVM veilig uitbreiden en schrijfbewerkingen herstellen

Wanneer een thin-provisioned volume op een SUSE Linux Enterprise Server de melding "geen ruimte meer op het apparaat" geeft, controleer Data%dan Meta%eerst de thin pool. Als het data-gebied vol is en de volumegroep nog vrije extenten heeft, breid dan de thin pool uit met lvextendde opgegeven grootte – niet alleen met de virtuele grootte van het bijbehorende thin logische volume. Een volledig vol metadata-gebied is een ander verhaal: mogelijk is offline reparatie nodig voordat normale schrijfbewerkingen kunnen worden hervat.

De onderstaande procedure maakt gebruik van LVM2-opdrachten die gedocumenteerd zijn voor Linux en het opslagmodel dat beschreven staat in de SUSE Linux Enterprise Server 15 SP7 Storage Administration Guide . De beschikbaarheid van opdrachten en de serviceconfiguratie kunnen verschillen in een ander SLES-servicepack of een geclusterde installatie. Maak een applicatieconsistente back-up en beperk zware schrijfbewerkingen voordat u de productieopslag wijzigt.

1. Controleer of de gegevensruimte of metadata vol is.

Voer de volgende opdracht uit op de host die eigenaar is van de actieve thin pool, waarbij vgdatau <volume-group name> vervangt door de naam van uw volumegroep:

sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata

Zoek de rij met thin-poolonder de SegType. Data%geeft de toegewezen datablokken weer; Meta%de toewijzingsmetadata van de pool worden gemeten. Dit zijn afzonderlijke capaciteitslimieten. Als de waarde Data%dicht bij 100 ligt, maar Meta%er ruim onder zit, zijn extra data-extents de meest directe oplossing. Als Meta%de waarde 100 is, gebruik dan de herstelmaatregelen in sectie 4.

Laten we als hypothetisch voorbeeld aannemen dat vgdata/pool0de pool 100 GiB groot is, met een datagebruik van 98,12% en een metadatagebruik van 40,26%. De pool loopt direct gevaar, zelfs als df -her voldoende ruimte wordt gerapporteerd binnen een gekoppeld thin volume. De virtuele grootte van een thin volume kan de fysieke capaciteit van de pool overschrijden, zoals de Expert Partitioner-documentatie van SUSE uitlegt.

Controleer ook recente fouten:

sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'

Interpreteer een lege grep-uitkomst niet als bewijs dat er geen mislukte schrijfbewerkingen hebben plaatsgevonden. Controleer ook de logbestanden van de applicatie, vooral als een database of virtuele machine aan het schrijven was toen de pool vol raakte.

2. Bevestig dat de volumegroep vrije fysieke afmetingen heeft.

Voordat u de omvang van het budget wijzigt, moet u nagaan of de volumegroep de uitbreiding kan financieren:

sudo vgs -o vg_name,vg_size,vg_free vgdata

In het hypothetische voorbeeld heeft de volumegroep van 200 GiB nog 40 GiB vrij. Een uitbreiding van de pool met 20 GiB is daarom in principe mogelijk, mits er rekening wordt gehouden met toewijzingsbeperkingen en ruimte voor eventuele groei van metadata. Houd een deel van de VG-ruimte in reserve in plaats van alle vrije extenten aan de pool toe te wijzen.

Als VG_FREEde waarde nul is, lvextendkan er geen fysieke capaciteit worden gecreëerd. Voeg een correct geïdentificeerd en voorbereid fysiek volume toe aan de VG, vergroot de onderliggende opslag en het bijbehorende LVM PV indien nodig, of maak blokken vrij voordat u het opnieuw probeert. SUSE documenteert het toevoegen van fysieke volumes bij het wijzigen van de grootte van een volumegroep . Voer de opdracht nooit uit pvcreateop een niet-geverifieerde schijf: dit kan bestaande opslagmetadata beschadigen.

3. Vergroot de dunne plas in plaats van het dunne volume.

Als Data%de beperkende factor niet is uitgeput wat betreft de metadata en er voldoende VG-extents beschikbaar zijn, breid dan de pool zelf uit:

sudo lvextend -L +20G vgdata/pool0

De +20Gsyntax voegt 20 GiB toe aan de huidige poolgrootte; de ​​uiteindelijke grootte wordt niet ingesteld op 20 GiB. In dit voorbeeld groeit de backing pool van 100 GiB naar 120 GiB. Met ongewijzigde toegewezen data zou 98,12 GiB in gebruik ongeveer 81,8% van de vergrote pool vertegenwoordigen. Het werkelijke percentage kan afwijken als er tijdens de bewerking nog steeds schrijfbewerkingen plaatsvinden.

Vervang dit niet . lvextend -L +20G vgdata/thin1Het vergroten van de virtuele adresruimte van een thin volume voegt niet noodzakelijkerwijs fysieke datacapaciteit toe aan de pool. Omdat deze opdracht de backing pool uitbreidt in plaats van het virtuele blokapparaat van het bestandssysteem, is een bestandssysteemwijziging normaal gesproken niet nodig voor deze specifieke bewerking. De gezaghebbende LVM thin-provisioning handleiding beschrijft het thin-pool uitbreidingsmechanisme en de beperkingen ervan.

Wanneer u het zwembad niet direct kunt uitbreiden

Als bestanden al verwijderd zijn uit een 'thin filesystem' en het verwijderen van verwijderde bestanden door de gehele stack wordt ondersteund, overweeg dan om verwijderde blokken terug te halen:

sudo fstrim -v /srv/data

Gebruik het werkelijke koppelpunt van een thin volume, niet het thin-pool apparaat. Een succesvolle trim kan de capaciteit verlagen Data%, maar het verwijderen van bestanden alleen zorgt er meestal niet voor dat blokken terugkeren naar de pool. Thin snapshots kunnen gedeelde blokken behouden en een pool die is ingesteld om verwijderde blokken te negeren, zal daar geen baat bij hebben. Beschouw trim niet als een betrouwbaar noodalternatief voor fysieke capaciteit, vooral niet als schrijfbewerkingen beginnen te mislukken. Verwijder oude snapshots pas nadat u hun eigendom, afhankelijkheden en bewaartermijnen hebt gecontroleerd; het verwijderen van snapshots is onomkeerbaar.

4. Beschouw een volledig metadatagebied als een herstelconditie.

Als Meta%het 100% bereikt, stop dan de schrijfbewerkingen van de applicatie en plan een gecontroleerde onderbreking. LVM waarschuwt dat uitputting van de metadata kan leiden tot inconsistentie in de thin pool-metadata en bestandssystemen. Het simpelweg vergroten van de poolgrootte, het opnieuw proberen van schrijfbewerkingen of het forceren van activering lost dit risico niet op.

De gedocumenteerde herstelprocedure omvat het offline deactiveren van de betreffende pool, het herstellen van de beperkte metadata met behulp van lvconvert --repair VG/ThinPool, het vergroten van de metadata-capaciteit met behulp van lvextend --poolmetadatasize, en vervolgens het controleren van elk getroffen bestandssysteem met de juiste offline tool. Een pool waarvan de metadata-LV kleiner is dan 2 GiB vereist bijvoorbeeld mogelijk een gecontroleerd doel zoals:

sudo lvextend --poolmetadatasize 2G vgdata/pool0

Dit is geen opdracht die u blindelings moet uitvoeren op een actieve, beschadigde pool. De grootte is slechts een voorbeeld, geen universele vereiste. Controleer eerst de huidige metadatagrootte, beschikbare extenten, correcte deactivering, herstelmedia en back-ups. Het herstel lvconvert --repairmoet worden gepland met expertise op het gebied van downtime en herstel; in de LVM-handleiding staat vermeld dat het proces kan mislukken en dat gegevens dan nog steeds onherstelbaar kunnen zijn. Bewaar de oude metadata LV totdat de pool en bestandssystemen zijn geverifieerd. Een LVM-configuratieback-up maakt vgcfgbackupgeen back-up van thin-pool metadata. Neem voor bedrijfskritieke gegevens contact op met SUSE-ondersteuning of uw storage recovery-team voordat u een reparatiepoging onderneemt.

5. Schakel automatische uitbreiding in en controleer vervolgens de schrijfbewerkingen.

Nadat het systeem stabiel is, configureert u een proactief groeibeleid in het activationgedeelte van /etc/lvm/lvm.conf. Dit voorbeeld start de uitbreiding bij 70% gebruik en vraagt ​​om een ​​groei van 20%; pas deze waarden aan op basis van de schrijfsnelheid en de beschikbare VG-capaciteit:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Zorg ervoor dat de instellingen op het juiste configuratiebereik worden toegepast en dat de pool wordt bewaakt:

sudo lvchange --monitor y vgdata/pool0

Automatische groei van thin pools is afhankelijk van LVM-gebeurtenisbewaking ( dmeventd) en voldoende vrije extenten. Controleer de bewakingsservice van uw SLES-installatie (bijvoorbeeld systemctl status lvm2-monitorwaar die unit aanwezig is) en bekijk de logboeken. Een drempelwaarde biedt geen garantie voor bescherming als schrijfbewerkingen de extensie overtreffen of de VG al vol is. Zie de handleiding voor automatische uitbreiding en de lvchange-bewakingsopties in de LVM-handleiding .

Controleer of de oplossing werkt.

Lees zowel het poolgebruik als de resterende capaciteit van de VG terug:

sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata

Data%Het aantal beschikbare plaatsen zou na de uitbreiding van de datapool moeten zijn gedaald, Meta%moet onder de limiet blijven en de pool moet actief zijn zonder nieuwe I/O-fouten. Controleer de status van het bestandssysteem en de applicatielogboeken en voer vervolgens een kleine, voor de applicatie geschikte schrijf- en leestest uit voordat u opgeschorte workloads vrijgeeft. Als de fouten aanhouden nadat er ruimte beschikbaar is, houd de betreffende workload dan offline totdat de integriteit van het bestandssysteem en de applicatie is gecontroleerd; meer capaciteit kan reeds mislukte of verloren schrijfbewerkingen niet herstellen.