#vscan scanner pool recommendations. (big environment)

1 messages · Page 1 of 1 (latest)

stone kestrel
#

We are using right now 10 vscan engines in one scan pool, since there is no real load balancing and we can already observe that some vscan engines are under higher load than others.
I were thinking about splitting up the scan engines and define different pools on the systems, especially when we have to add anyway more scanners in the hope that they would be used more equally.

MCC 1-4 gets a pool with the scan engines 1-6
MCC 5-8 gets a pool with the scan engines 7-12
instead of just having one pool with the future amount of 12 or 14 scan engines (per location)

The Netapp support sends me sadly just the TR and don't do a "under the hand" recommendation (which i can understand) so maybe here are some people who were facing similar issues? The in total 20 Scan engines are taking care about 12 MCC in two locations. 10 scan engines in every location + 6 bigger Scaleout Systems but mostly NFS so no vscan.

civic horizon
#

vscan is pretty hoplessly maintained. It worked well under 7-mode, then some genius thought they could take the very expensive NetApp CPU's and do vscan on-board, and then moved it back to where it was before but broke it in terrible ways compared to 7-mode where you could run the service centrally in the "admin vfiler" for all "vfilers"

#

at some point someone then decided to mirror all of the "cluster" vscan configurations to every svm, even if they don't use vscan (just like snapmirror schedules and other noise).

#

I gave up trying to get a working MCC config that works in site-failover because there are simply too many "DR" assumptions in the code

#

cluster pools will try to reach every interface on every svm, even if they aren't using vscan because the lookup done by the "av connector" isn't smart enough to return only interfaces that actually use vscan

#

multiple AD domains are basically impossible without lots of redundant av servers ... i just don't have to time to argue with NetApp about fixing it

stone kestrel
civic horizon
#

load is never going to balance out that great but the system does have some idea of what the av server load is. It can't be simply round-robin either

stone kestrel
#

In the end i made my decision already, and will go for different pools so i dont run in the case that the systems are using concentrated only 4 of 10 vscan engines. Even tho it means i have to changed the setup on quite some systems.

yeah i agree, but even when the system gets vscan is too busy it does not simply switch to the next ones it takes time.

civic horizon
#

the easiest thing is just to add cpu and memory to the vscan servers if the scan engine supports multiple threads

stone kestrel
#

they are at the limit how they configure it so they want to add additional engines 🙂

civic horizon
#

one could see if the vscan engine on the vscan server supports some lower "too busy" threshold

#

none of this matters as long as users aren't complaining... they don't notice a few 10's of ms slowness

stone kestrel
#

good idea. Well when they get more busy there will be users 😄 we had it in the past, we came from user complaints and even tho we dont even use mandatory scanning

civic horizon
#

when i've used multiple pools it still didn't affect non-pool scanners from trying to contact every svm

#

it's just a mess

summer depot
#

just curious what the vscan systems are spec'd for (cpu/mem/network) and how they're getting max'd out.
I have 4 scanners in my main production environment and server well over 700mil files via CIFS/SMB, rarely run into issues with the scanners

#

and multi-domain needs to be fixed cause it's a pita to use scanners in multiple domains

civic horizon
#

if you don't limit what's sent to the vscan servers to what the servers will scan as max file size, then things will timeout

#

which is generally, even in 2024, 2GB

#

if zip files have multiple zip files, wierd complexities that MS has added to powerpoint... all of these take time