PowerScale: Isilon: OneFS: Efter opgraderingen kan det medføre påvirkninger af ydeevnen som følge af et postopgraderingsjob.

Som en del af OneFS-opgraderinger skal der ske en nødvendig og obligatorisk migrering af vores tidligere version af Inode-designet til en ny version. er der ingen måde at udsætte eller forhindre denne migrering.  Dette vil berøre hver enkelt fil på din OneFS-klynge, herunder brugerplads (/ifs) og alle systemtypefiler.

Denne procedure begynder, når OneFS-klyngeopgraderingen er "sendt" i opgraderingsprocessen.

Den store størrelse af dette job i nogle scenarier og implementeringer kan forårsage problemer med midlertidig ydeevne.
 

Når du har gennemført en OneFS-opgradering, startes et systemjob af typeopgradering, der opgraderer filsystemet efter en softwareversionsopgradering, automatisk og skal have tilladelse til at køre indtil opgraderingen er fuldført.  Hvis der er ændringer i inode-strukturen mellem OneFS-udgivelserne af opgraderingen, vil opgraderingsjobbet udføre inode-strukturændringer på alle filer.  Når dette sker, kan det køre opgraderingsjobbet muligvis forårsage midlertidige problemer med ydeevnen på grund af den øgede IOPS, der kræves for at udføre ændringer i inode-strukturen.  Dette kan afhjælpes ved at ændre politikken for opgraderingsjobbet til Lav fra den aktuelle standardværdi for mellem.

Hvilke systemer kan blive berørt?

Under dette vil tæt på alle filer på lagerplatformen blive migreret hurtigt til den nye inode-version. Det generelle lab-observerede pace for opdateringer på tværs af hardwareplatforme og brugen af standardjobpolitikken kan gå lige så hurtigt som mange millioner samlede filobjekter pr. time. Bemærk, at "filer" i denne sammenhæng ikke kun henviser til de "bruger uploadede" filer, som du kan se for eksempel under dine kvoter og rapportering. Dette omfatter også alle filer og objekter på systemniveau. 

Når migreringen er i gang, set som et job i CLI med navnet "Upgrade", der kører under standardpolitikken for mellem, er der en mulighed for, at en Isilon-klynge kan opleve midlertidige og midlertidige problemer med ydeevnen, mens denne opgradering opstår. Ud fra det begrænsede antal rapporter om dette, vi har observeret, ser det ud til, at opgraderings-inode-migreringen kan tage flere timer til dage baseret på en mellempolitik.

Dette kan afhjælpes ved at ændre politikken for opgraderingsjobbet fra den aktuelle standardværdi på mellem til lav.

Hvis der konstateres påvirkninger af ydeevnen, kan disse påvirkninger ændre politikken for opgraderingsjobbet fra mellem til lav. Hvis du ændrer politikken til Lav, reduceres den samlede indvirkning, som jobbet har, mens det kører, men det øger, hvor lang tid det tager at udføre jobbet.
 

Hvis du vil ændre politikken for et aktuelt kørende opgraderingsjob til Lav, skal du køre følgende kommando:

Hvis du vil ændre politikken for fremtidige opgraderingsjob til Lav, skal du køre følgende kommando:

Bemærk: Dette job er en vigtig del af denne særlige type opgradering. Selvom ting som prioriteten af jobbet kan ændres, kan det absolutte krav om, at dette job køres, ikke ændres. Hvis "jobbet" på nogen måde blev annulleret eller fejlet, genoptages det igen. Inode-ændringerne skal fuldføres.