NFS-datasets reorganiseren zonder de exportpaden die clients zien te wijzigen

NFS-datasets kunnen opnieuw worden ingedeeld zonder verouderde client-handles wanneer de voor de client zichtbare exportnaamruimte stabiel blijft terwijl de opslag achter die grens wordt verplaatst.

Het preventieve ontwerp bestaat uit het scheiden van het pad dat clients mounten van de fysieke datasetnaam die u later mogelijk wijzigt. Bouw een stabiele exportstructuur, koppel datasets er doelgericht in, behoud waar mogelijk de bestandssysteemidentiteit, laat clients leeglopen voordat u destructieve vervangingen uitvoert en controleer na de omschakeling hetzelfde exportpad. Als de server het onderliggende bestandssysteem moet verwijderen en opnieuw aanmaken, behandel dit dan als een identiteitswijziging en plan een gecoördineerde remount van clients in, in plaats van onzichtbare continuïteit te beloven.

Maak een stabiele exportnaamruimte boven de datasets

Gebruik een speciale NFS-exportroot waarvan de voor clients zichtbare namen niet elke interne ZFS- of Btrfs-datasetnaam weerspiegelen. Zo kunnen opslagbeheerders backend-datasets opnieuw indelen zonder elke client een nieuw mountpad te moeten leren.

Een bespreking van een NFSv4-ontwerp legt uit hoe bind mounts stabiele exports creëren onder een doelbewust beheerd pseudo-bestandssysteem.

Leg het clientpad vast als het compatibiliteitscontract. Interne datasetnamen kunnen later veranderen, maar alleen nadat de exportlaag opnieuw is gekoppeld en tegen hetzelfde pad is getest.

Leg de exportidentiteit vast in plaats van op detectievolgorde te vertrouwen

Noteer de bestandssysteem-UUID, het exportpad, de NFS-versie en de expliciete fsid-instellingen die door de huidige server worden gebruikt. Dezelfde zichtbare mapnaam is niet voldoende wanneer de NFS-server het onderliggende bestandssysteem na een verplaatsing anders identificeert.

SUSE merkt op dat NFS elk geëxporteerd bestandssysteem identificeert, in plaats van een export als een eenvoudige alias voor een pad te behandelen.

Gebruik expliciete identificatiegegevens alleen waar uw NFS-implementatie deze ondersteunt en houd elke waarde uniek. Kopieer een fsid niet naar twee gelijktijdig geëxporteerde bestandssystemen om ze alleen maar identiek te laten lijken.

Plaats de nieuwe dataset achter hetzelfde exportpad

Maak de vervangende dataset aan of ontvang deze op een tijdelijk serverpad, kopieer of repliceer de inhoud, controleer de rechten en koppel deze vervolgens tijdens een onderhoudsvenster aan de stabiele exportstructuur. Houd de oude dataset beschikbaar voor terugdraaien, maar niet actief onder dezelfde exportidentiteit.

Een NFS-exportvoorbeeld laat zien hoe aangekoppelde deelstructuren doelbewust moeten worden geëxporteerd wanneer meerdere bestandssystemen onder één NFS-naamruimte verschijnen.

Bij de omschakeling moet één serverzijdige koppeling worden gewijzigd, niet tegelijkertijd de client-mountdefinitie en de datasetidentiteit. Zo blijft het bewijsmateriaal voor probleemoplossing intact als de nieuwe structuur niet klopt.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Laat schrijvers leeglopen voordat u het onderliggende bestandssysteem vervangt

Stop of pauzeer services die actief via de NFS-mount schrijven en controleer vervolgens of geen enkele belangrijke client tijdens de omschakeling een langdurige bestandsbewerking uitvoert. Voer de laatste synchronisatie pas uit nadat schrijvers tot rust zijn gebracht.

IBM beschrijft waarom NFSv4-status stabiele opslag nodig heeft, omdat de clientstatus deel uitmaakt van de continuïteit en niet alleen de bestandsinhoud op de server.

Voor een homeserver is het doel eenvoudiger dan bij geclusterde failover: voorkom dat de bestandsidentiteit verandert terwijl applicaties actief zijn. Een korte, gecontroleerde pauze is veiliger dan database-, media- of backupclients te dwingen een live vervanging van het bestandssysteem te doorstaan.

Weet wanneer een remount van de client onvermijdelijk is

Als de herindeling het bestandssysteem verwijdert en opnieuw aanmaakt, een snapshot als nieuw bestandssysteem terugzet of de serverzijdige filehandle-identiteit wijzigt, plan dan een gecoördineerde unmount en remount nadat het serverpad stabiel is.

Een actuele NFS-probleemoplossingsgids stelt dat wijzigingen in de serveridentiteit verouderde handles veroorzaken en adviseert een stabiele serveridentiteit te controleren wanneer het probleem terugkeert.

Kondig geen onderhoud zonder remount aan wanneer de onderliggende identiteit daadwerkelijk verandert. Een gedocumenteerd remountvenster is beter dan applicaties tijdens normale schrijfbewerkingen met ESTALE te laten kennismaken.

Test het clientpad voordat u de oude dataset buiten gebruik stelt

Mount de export vanaf een nieuwe client en vanaf één bestaande, niet-kritieke client. Vergelijk vervolgens de mapidentiteit, rechten, representatieve leesbewerkingen, één omkeerbare schrijfbewerking en het door de applicatie verwachte pad. Herstart één client om te bewijzen dat de persistente mountconfiguratie niet is gewijzigd.

Een Arch Linux-geval liet zien dat een stabiele NFS-root ESTALE voorkomt na wijzigingen aan backend-bestandssystemen.

De herindeling is voltooid wanneer clients nog steeds het oorspronkelijke exportpad gebruiken en de oude dataset buiten gebruik kan worden gesteld zonder verborgen verwijzingen. Het gerelateerde ZimaSpace-artikel over verouderde handles na een datasetnaamwijziging is de herstelroute als ESTALE al is opgetreden.