Billich, >The cache filesets holds about 500M used inodes. Does a specific procedure exist, or is it good enough to just shutdown scale on the node I want to update? And maybe flush >the queues first as far as possible?
It is recommended to stop (mmafmctl device stop) the filesets and perform upgrade if the upgrade duration is short. But if the upgrade procedure takes too long, gateway node can be shutdown, other active gateway node(s) runs recovery automatically for the filesets owned by the gateway which was shutdown. >If a fileset has a zero length queue of pending transactions to home, will this avoid any policy scan when a second afm node takes responsibility for the fileset? Active gateway node(s) always runs recovery with policy scan even though queue length was zero on other gateway node(s), so it is possible that recovery on multiple filesets (assuming that in this case 20 filesets) trigger at the same time and which may impact the system performance. You could limit the number of parallel recoveries using the afmMaxParallelRecoveries option. For example set mmchconfig afmMaxParallelRecoveries=5 -i (default 0 means run recovery on all filesets parallelly), and reset to default later. ~Venkat (vpuvv...@in.ibm.com) From: "Billich Heinrich Rainer (ID SD)" <heinrich.bill...@id.ethz.ch> To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org> Date: 08/25/2020 08:43 PM Subject: [EXTERNAL] [gpfsug-discuss] AFM cache rolling upgrade with minimal impact / no directory scan Sent by: gpfsug-discuss-boun...@spectrumscale.org Hello, We will upgrade a pair of AFM cache nodes which serve about 40 SW filesets. I want to do a rolling upgrade. I wonder if I can minimize the impact of the failover when filesets move to the other afm node. I can't stop replication during the upgrade: The update will take too long (OS, mofed, FW, scale) and we want to preserve the ability to recall files (?). Mostly I want to avoid policy scans of all inodes on cache (and maybe even lookups of files on home??) I can stop replication for a short time. Also the queues most of the time are empty or contain just a few 100 entries. The cache filesets holds about 500M used inodes. Does a specific procedure exist, or is it good enough to just shutdown scale on the node I want to update? And maybe flush the queues first as far as possible? If a fileset has a zero length queue of pending transactions to home, will this avoid any policy scan when a second afm node takes responsibility for the fileset? Maybe I did already ask this before. Unfortunately the manual isn't as explicit as I would prefer when it talks about rolling upgrades. Thank you, Heiner -- ======================= Heinrich Billich ETH Zürich Informatikdienste Tel.: +41 44 632 72 56 heinrich.bill...@id.ethz.ch ======================== _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
