I run four physical and one virtual CAVA server. Two physical boxes are old, Dell PowerEdge 750s running Windows Server 2003 and McAfee 8.0.i. Two physical boxes are newer, Dell R200s, running Server 2003 and McAfee 8.5.0i. The virtual CAVA server is on Server 2003, running McAfee 8.5.0.i and sits on Microsoft Hyper-V. The virtual CAVA server processes about 80% as fast as the older Dell PE750s; I see no errors or have any problems scanning files from the virtual CAVA server. I will most likely retire the PE750s this summer and spin up two more virtual CAVA servers.
With regards to your problem, you have tried running the CAVA sizing tool? Maybe the VM simply isn't fast enough? Take a look at the CAVA documentation in PowerLink.
I definetely think its a CAVA issue, as soon as I turned off CAVA a co-worker that was copying a file saw it speed up dramatically. I told him to copy it again, and turned it on, and it slowed it down quite a bit. It was about a 100MB file. SO I tihnk CAVA is definately doing something. I am running the CAVA check utility and it seemes sized correctly. there is just something amiss with either CAVA for the SAVSE thats setup.
So you are suspecting the issue with xls or doc file not being scanned may be due to CAVA? You may check whether it is having too much in the queue for scanning and whether increasing threads help or not. You may consider enabling Virus auditing on the data mover and check.
Anyway - technically CAVA should run on VM - although you need to understand that it needs the physical resources like network bandwidth, processing etc on the server. I always encourage my clients to use Physical server - but sometime back I tested it on a VM to work - however that was not a full blown production testing.
I am sure others will post their experiences and comments.
Please keep us posted on the issue with scanning that you have. Thanks, Sandip
I've currently installed two CAVA servers on ESX. 2 Vcpus, 2 gb of ram and they are lying on san datastore.
Cava version: 4.5.1
Sav for nas: 5.2
Now we've no user workload and trying to coping (or emcoping) some files to celerra shares, we've a lot of files not checked, even If we start viruschk on DM with 40 threads
PS: note that CPU activity is very very low, and we've only 400 mb of memory allocated on these servers.
I definetely think its a CAVA issue, as soon as I turned off CAVA a co-worker that was copying a file saw it speed up dramatically.
The actual CAVA function doesn't really kick in until after the file is saved. The check does not occur until the file has been completely written. The save response would return to the client in the same amount of time whether CAVA was on or off. What would be affected would be the ability to read the file immediately following saving it. The file would remain locked until the check was complete, and the client would literally hang waiting for CAVA to finish its scan, so it might seem that the file would be taking longer to read, but only immediately following a write of that file.
If you're saying that CAVA is slowing down your write operations, you may have a network bandwidth issue. CAVA, while trying to scan other files in your environment, may be bogging down your network. There are other issues that could be causing this contention, including backend filesystem layout and I/O between the Data Mover and the backend, but these are less likely than a network bottleneck. I'd start there in an investigation of this issue.
I've currently installed two CAVA servers on ESX. 2 Vcpus, 2 gb of ram and they are lying on san datastore.
Cava version: 4.5.1
Sav for nas: 5.2
Now we've no user workload and trying to coping (or emcoping) some files to celerra shares, we've a lot of files not checked, even If we start viruschk on DM with 40 threads
PS: note that CPU activity is very very low, and we've only 400 mb of memory allocated on these servers.
Thanks in advance
What displays when you do a server_viruschk {server_name}?
-- Do the checkers show as ONLINE?
Do the files ever get checked, or is it just really slow?
Has this ever worked?
-- If it did, what changed in your environment between when it worked and now?
Have you run the CAVA Sizing Tool to determine whether or not your servers are right-sized?
Have a look at Knowledgebase solution emc62326 and make sure you are set up in accordance with those best practices. If you're set up correctly and still not checking files, please open a Service Request.
While I agree that the problem could be network bandwidth, there's also performance latency inherent to the process of using the CAVA servers to actually check files. The CAVA server reads the bytes of the file over the network, passes those bytes up into memory, then runs the viruschecking process on said bytes. It then has to return either a "Clean", "Cleaned" or "Not Cleaned" back to the NAS. That process takes real network/CPU cycles - especially with files of 100MB.
I'm not 100% sure the check occurs on a complete write. I see CAVA requests for files that are held "open" in memory during the login process by clients when they map their home directories (and process their roaming profiles). That's probably not related to this problem, but I think it's worth noting.
What displays when you do a server_viruschk {server_name}?
-- Do the checkers show as ONLINE?
Do the files ever get checked, or is it just really slow?
Has this ever worked?
-- If it did, what changed in your environment between when it worked and now?
Have you run the CAVA Sizing Tool to determine whether or not your servers are right-sized?
Have a look at Knowledgebase solution emc62326 and make sure you are set up in accordance with those best practices. If you're set up correctly and still not checking files, please open a Service Request.
server_viruschk displays both SAV servers online...
It's so slow and but we're gonna implementing them now. They never checked anything.
CAVA Sizing tool told me to install 2 cava servers (like I did).
I have already opened a SR with EMC, they told me to try with a physical CAVA server.
I've never seen a mechanism to control from the CAVA-side. On a few occasions, we've found infected files in .iso that folks have downloaded. It's just my opinion, but I think a lot of old rules (file type, size, etc.) are going by the wayside, in regards to malware.
I replied in your other thread. Sure, your AV servers can exist in any DC, on any IP network, as long as the data mover can communicate with it. If you move the AV servers to a DC where they cannot talk to the datamovers (i.e., no network route exists between the DCs), then, NO the AV servers will not be able to provide AV services for the datamover.
If you have to migrate your AV servers from one DC to another, the easy way is to move them one at a time, during periods of lowest use (usually evenings). You would move the AV server to the new DC, then update the viruschecker.conf file with the new IP address, and re-read the configuration with server_viruschk -update. The CAVA service would re-read the config and start using the new IP address of the AV server. You would repeat this process - move the AV server, update the config file, re-read the config file - until all servers are on the new network.
If you cannot move them one at a time, you will either have to A) turn off CAVA or B) change the viruschecker.conf file to continue serving files without AV scanning (shutdown=no). If you don't the CIFS service will hang on customer writes (i.e., users cannot open or save new files via CIFS) until the NAS can talk to at least one AV server.
umichklewis_ac7b91
300 Posts
0
April 17th, 2009 11:00
With regards to your problem, you have tried running the CAVA sizing tool? Maybe the VM simply isn't fast enough? Take a look at the CAVA documentation in PowerLink.
daver3
46 Posts
0
April 17th, 2009 11:00
nandas
4 Operator
•
1.5K Posts
0
April 17th, 2009 11:00
Anyway - technically CAVA should run on VM - although you need to understand that it needs the physical resources like network bandwidth, processing etc on the server. I always encourage my clients to use Physical server - but sometime back I tested it on a VM to work - however that was not a full blown production testing.
I am sure others will post their experiences and comments.
Please keep us posted on the issue with scanning that you have.
Thanks,
Sandip
Rainer_EMC
4 Operator
•
8.6K Posts
0
April 17th, 2009 15:00
boyerr
12 Posts
0
April 21st, 2009 18:00
the que's never back up and the request response time seems to be acceptable with no visible performance hits.....
Peter_EMC
674 Posts
0
April 21st, 2009 23:00
Symantec advised the customer to change the windows registry of the W2K3 viruschecker server.
=> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpTimedWaitDelay 30
and
MaxUserPort 10000
to solve the bad performance.
riker82
75 Posts
0
November 30th, 2009 07:00
Can anyone help me?
I've currently installed two CAVA servers on ESX. 2 Vcpus, 2 gb of ram and they are lying on san datastore.
Cava version: 4.5.1
Sav for nas: 5.2
Now we've no user workload and trying to coping (or emcoping) some files to celerra shares, we've a lot of files not checked, even If we start viruschk on DM with 40 threads
PS: note that CPU activity is very very low, and we've only 400 mb of memory allocated on these servers.
Thanks in advance
BillStein-Dell
Moderator
•
285 Posts
0
November 30th, 2009 10:00
The actual CAVA function doesn't really kick in until after the file is saved. The check does not occur until the file has been completely written. The save response would return to the client in the same amount of time whether CAVA was on or off. What would be affected would be the ability to read the file immediately following saving it. The file would remain locked until the check was complete, and the client would literally hang waiting for CAVA to finish its scan, so it might seem that the file would be taking longer to read, but only immediately following a write of that file.
If you're saying that CAVA is slowing down your write operations, you may have a network bandwidth issue. CAVA, while trying to scan other files in your environment, may be bogging down your network. There are other issues that could be causing this contention, including backend filesystem layout and I/O between the Data Mover and the backend, but these are less likely than a network bottleneck. I'd start there in an investigation of this issue.
BillStein-Dell
Moderator
•
285 Posts
0
November 30th, 2009 10:00
What displays when you do a server_viruschk {server_name}?
-- Do the checkers show as ONLINE?
Do the files ever get checked, or is it just really slow?
Has this ever worked?
-- If it did, what changed in your environment between when it worked and now?
Have you run the CAVA Sizing Tool to determine whether or not your servers are right-sized?
Have a look at Knowledgebase solution emc62326 and make sure you are set up in accordance with those best practices. If you're set up correctly and still not checking files, please open a Service Request.
umichklewis_ac7b91
300 Posts
0
December 2nd, 2009 08:00
While I agree that the problem could be network bandwidth, there's also performance latency inherent to the process of using the CAVA servers to actually check files. The CAVA server reads the bytes of the file over the network, passes those bytes up into memory, then runs the viruschecking process on said bytes. It then has to return either a "Clean", "Cleaned" or "Not Cleaned" back to the NAS. That process takes real network/CPU cycles - especially with files of 100MB.
I'm not 100% sure the check occurs on a complete write. I see CAVA requests for files that are held "open" in memory during the login process by clients when they map their home directories (and process their roaming profiles). That's probably not related to this problem, but I think it's worth noting.
Thanks!
riker82
75 Posts
0
December 2nd, 2009 09:00
What displays when you do a server_viruschk {server_name}?
-- Do the checkers show as ONLINE?
Do the files ever get checked, or is it just really slow?
Has this ever worked?
-- If it did, what changed in your environment between when it worked and now?
Have you run the CAVA Sizing Tool to determine whether or not your servers are right-sized?
Have a look at Knowledgebase solution emc62326 and make sure you are set up in accordance with those best practices. If you're set up correctly and still not checking files, please open a Service Request.
server_viruschk displays both SAV servers online...
It's so slow and but we're gonna implementing them now. They never checked anything.
CAVA Sizing tool told me to install 2 cava servers (like I did).
I have already opened a SR with EMC, they told me to try with a physical CAVA server.
I've tried with no success...
driskollt1
131 Posts
0
December 16th, 2009 11:00
Does every file need to be checked? I'd probably set CAVA not to check files larger than 20 mb.
umichklewis_ac7b91
300 Posts
0
December 16th, 2009 13:00
deeppat
2 Intern
•
261 Posts
0
June 3rd, 2011 10:00
hello all,
I understand this is a pretty old Post now, but thought i will continue here rather then putting a new post again.
We 're in the process of migrating our celerra from one DC to another . This has 4 AV servers ,and all four are VMs.
Can they be moved to New DC? Whatever the functionality they are providing in current DC can they do it from the new DC.
what other things i need to take care of when doing this migration from the AV perspective.
umichklewis_ac7b91
300 Posts
0
June 3rd, 2011 14:00
I replied in your other thread. Sure, your AV servers can exist in any DC, on any IP network, as long as the data mover can communicate with it. If you move the AV servers to a DC where they cannot talk to the datamovers (i.e., no network route exists between the DCs), then, NO the AV servers will not be able to provide AV services for the datamover.
If you have to migrate your AV servers from one DC to another, the easy way is to move them one at a time, during periods of lowest use (usually evenings). You would move the AV server to the new DC, then update the viruschecker.conf file with the new IP address, and re-read the configuration with server_viruschk -update. The CAVA service would re-read the config and start using the new IP address of the AV server. You would repeat this process - move the AV server, update the config file, re-read the config file - until all servers are on the new network.
If you cannot move them one at a time, you will either have to A) turn off CAVA or B) change the viruschecker.conf file to continue serving files without AV scanning (shutdown=no). If you don't the CIFS service will hang on customer writes (i.e., users cannot open or save new files via CIFS) until the NAS can talk to at least one AV server.
Karl